Agent辅助的SGLang开发：初步探索

SGLang 的开发正日益超越孤立的代码改动。同一个代码仓库如今涵盖 LLM 服务、分布式运行时、GPU kernel、扩散流水线、特定模型的执行路径以及生产事故处理。过去，其中许多工作流都依赖开发者个人的记忆：如何启动某个模型、如何阅读 profile trace、调试 CUDA 崩溃时先加哪条日志，或者一个性能 PR 应该包含哪些 benchmark。随着智能体工具逐渐成熟，这些经验可以被转化为可执行的 SKILL.md 文件、脚本、benchmark 契约和评审循环。

围绕 SGLang 智能体开发，已经涌现出一组同时面向 LLM 和扩散工作的技能：

• SGLang .claude/skills 在 SGLang 代码仓库内维护，涵盖仓库级开发工作流，例如 CUDA 崩溃调试、kernel 集成、测试、CI、性能分析、生产问题分诊以及源码树约定。
• SGLang diffusion .claude/skills 专注于扩散相关的工作流，包括新增扩散模型、对去噪路径进行 benchmark 和性能分析、调优性能选项，以及验证量化流水线。
• BBuf/AI-Infra-Auto-Driven-SKILLS 涵盖跨框架服务 benchmark、容量规划、profile 与流水线分析、模型算力模拟、SGLang 人工风格评审、生产事故分诊、面向 SGLang 及其他开源推理框架的 SOTA 循环，以及模型 PR 历史。
• kernel-design-agents 是 KDA 项目，也是 MLSys 2026 FlashInfer Kernel Contest 的获胜方案。
• BBuf/KDA-Pilot 将 KDA 风格的智能体内核工作流应用于 SGLang。其公开的 B200 扩散摘要现已追踪 10 个 SGLang 内核任务。大多数条目来自 KDA-Pilot 的公开基准账本，而 residual_gate_add 使用的是在原始任务基线变动后、由已合并的 SGLang 集成 PR 所报告的 B200 加速比。源自 KDA-Pilot 的工作现已落地于三个 SGLang 集成 PR 中。

综合来看，这些工作指向同一个方向：智能体的价值来自过程性工程知识，包括可执行的步骤、可复现的实验和可审查的证据。

1. TL;DR

• 在 SGLang 中，智能体最有用的场景是能够沿着定义明确的工作流持续推进。基准测试、性能剖析、内核 API 日志记录、添加扩散流水线、生产事故回放以及 SOTA 循环，都可以被编码为技能。
• SGLang 技能是一套可执行的开发流程。在 debug-cuda-crash、sglang-diffusion-benchmark-profile 和 llm-torch-profiler-analysis 中，重要内容包括预检、硬性失败门禁、产物契约、复现命令和结果格式。
• 性能剖析证据是性能工作的核心。SGLang 的 profiler 技能会生成固定的 kernel 表、重叠机会表和融合模式表。KDA-Pilot 将其扩展为同 ABI 的基线/候选对比、真实工作负载、正确性门禁、NCU 证据以及按 shape 划分的结果。
• 长时间运行的优化已经开始进入 Loop Engineering。SGLang SOTA Performance Loop 将“追逐 SOTA”拆解为公平基准测试、差距判定、性能剖析、打补丁和重新验证。Humanize/RLCR 增加了外部审查，而 Codex Goal 可以用更低的协调开销运行同样的循环。
• 审查变得更加重要。智能体可以运行更多实验，但它们也会产生更多看起来合理、却仍然需要仔细审查的改动。开发者越来越多地负责定义问题、选择证据、设计工作流，并判断结果是否已准备好进入生产路径。

2. 为什么 SGLang 非常适合智能体辅助开发

SGLang 是一个面向 LLM 和多模态模型的高性能服务框架。随着模型家族和硬件路径不断扩展，开发中会反复出现几个问题：

• LLM 路径非常复杂。单个性能问题可能横跨 Python 运行时、调度器、CUDA graph、Triton/CUDA kernel、FlashInfer/FlashAttention、分布式集合通信以及特定于模型的封装层。
• 扩散路径同样复杂。一次较慢的去噪过程可能涉及流水线/阶段划分、DiT 块、注意力后端、torch.compile 图断裂、CFG/SP 并行、VAE，或自定义融合 kernel。
• 验证成本高昂。许多改动必须在 H100、H200、B200 或 RTX 5090 上，用真实模型和真实工作负载进行测试。仅靠本地单元测试是不够的。
• 性能剖析结果很难手动复用。单个 trace 可能包含数百次 kernel 启动。手工阅读 Perfetto 可能会遗漏 kernel 到 Python 源码的映射，也很容易把 prefill 和 decode 搞混。开发者在阅读 profiler 输出时会积累经验，比如哪些 kernel 名称对应哪些模型逻辑、哪些启动模式暗示存在图断裂、哪些 NCCL/注意力/MLP 布局属于正常情况。如果这些知识只留在某个人的脑子里，下一个任务就无法复用。
• 性能结论在很大程度上取决于上下文。GPU 类型、shape、batch size、并行方式、精度、后端以及编译状态都可能改变结果。孤立的微基准测试往往无法证明模型层面的真实收益，因此需要一个端到端的长时间测试流程，在固定工作负载下反复验证吞吐量、延迟、内存、精度和稳定性。这一过程既耗费人力又耗时。

这些问题天然适合智能体来处理。启动服务器、修复工作负载、收集 trace、分诊 profile 行、添加测试以及记录实验结果，都有明确的输入和输出，非常适合脚本化和重复执行。开发者需要划定边界：相同的基准测试设置、相同的 profile 解读规则、相同的精度门槛，以及智能体应在何种条件下停止修改代码。

因此，这里讨论的智能体是一个受工程工作流约束的执行者。重复性的 SGLang 开发流程可以被固化为技能，让智能体负责重复执行、证据收集和状态跟踪。开发者仍然负责定义目标、判断证据，以及审查某项改动是否应进入真实的服务路径。

3. 从提示词工程到 SKILL：协议与示例

在 SGLang 框架中，一个有用的技能至少应回答以下问题：

SGLang 智能体相关技能覆盖不同层次。有些贴近源码改动，例如调试、测试、添加扩散模型，以及基准测试/性能分析工作流。另一些则面向跨框架基准测试、容量规划、计算模拟、生产事故分诊、PR 优化知识、SGLang 人工风格评审，以及更高层次的工作流，例如 Humanize/RLCR。

3.1 当前技能栈

常用的 SGLang 智能体相关技能可分为以下几组。

这些条目将容易遗漏的步骤转化为可执行的协议，使工作流能够运行、恢复并被审查。

3.2 近期优化与工作流示例

以下示例来自近期合并的 SGLang PR。该表聚焦于完整的工程路径：基准测试、性能剖析、问题定位、代码改动、测试与再验证。

在这些示例中，智能体主要通过执行工作流来做出贡献：运行基准测试、读取性能剖析、定位 Python 源码、修改代码、添加测试、重新验证，以及准备 PR 描述。如果没有技能，许多步骤都依赖人工提醒。一旦将其编码为技能，工作流就变得容易重复得多。

4. 性能剖析、审查与循环工程

在 SGLang 性能优化工作中，一个常见的错误是只看总运行时间，或者打开 Perfetto 看几分钟，然后凭直觉断定某些东西"应该被融合"。这对智能体来说风险更大，因为它们很容易把一个视觉上很热的 kernel 误认为是真正的瓶颈。

实践中，通常会同时使用两个 profiler 技能。llm-torch-profiler-analysis 负责第一层 trace 分诊，将全局 profile 转化为三张固定表格：

• Kernel Table：按阶段汇总 GPU 时间占比、启动次数和 kernel 类别，并在可能的情况下将 kernel 映射回 Python 源码和 CPU 算子。
• Overlap Opportunity Table：利用独占/隐藏时间占比、依赖风险和 kernel 类别来识别剩余的重叠或可优化空间。
• Fuse Pattern Table：将 trace 与一个基于源码的模式目录进行对比，该目录收录了 SGLang、其他开源推理框架以及 kernel 库中的融合/重叠路径。

这些表格回答了第一组问题：哪个阶段和哪个 kernel 占用了多少 GPU 时间，它们映射到哪一行 Python 代码，以及是否存在可供借鉴的现有融合/重叠路径。如果 SGLang 落后于其他推理框架，profiler 表格应在任何代码改动开始之前解释这一差距。

下一步是 llm-pipeline-analysis。一旦全局热点已知，我们仍需了解它们属于哪次前向传播、哪种层类型以及哪条 kernel 流程。该技能读取 Chrome trace JSON 和模型 config.json，利用层边界锚点 kernel 将 trace 拆分为前向传播和层，然后生成若干表格以供深入分析：

• Forward pass summary：将冷启动与稳态分离，避免预热阶段成为优化目标。
• Per-layer timeline：报告墙钟时间、总时长，以及每一层中 MLA、MoE、GEMM、NCCL、MHC 和 Hadamard 等类别的占比。
• Layer cluster statistics：对于具有交替层结构的模型尤其有用，例如带有 compress_ratios 的 NSA/混合注意力模型，其中 C4_LIGHT、C128_HEAVY、HASH 或其他层类型可能主导延迟。
• Compute flow table：将代表性层展开为具体的 kernel 流程，包含热点程度、相对时间戳和输入维度，便于轻松跳回 Perfetto。

因此，性能分析变成了一个两步流程。首先，llm-torch-profiler-analysis 在完整 trace 中识别主要冲突。然后，llm-pipeline-analysis 将问题定位到稳态前向传播、代表性层和具体的 kernel 流程中。第一步避免了凭直觉选择方向。第二步避免了只盯着一个全局热点 kernel，而忽略了模型结构中不同层类型之间的差异。

4.1 Humanize/RLCR：将外部审查引入循环

Humanize 解决了长时间运行任务中的状态和审查问题。一个高风险的 SGLang 性能任务通常不会在一次实现中完成。它可能经历多轮基准测试、性能分析、打补丁、回滚、改变方向和再次验证。Humanize 将此过程分为两个阶段：

1. 先运行 gen-plan。humanize-gen-plan 会把一份草稿需求转化为结构化的 plan.md，其中包含目标描述、验收标准、正向/负向测试、路径边界、里程碑以及实现说明。
2. 接下来运行 RLCR 循环。humanize-rlcr 从 plan.md 启动该循环。在每一轮中，Claude Code 读取 .humanize/rlcr/<timestamp>/round-<N>-prompt.md，进行实现、提交，并撰写一份总结。随后 Codex Review 会检查状态文件、总结、git 洁净度、审查结果、未决问题、最大迭代条件以及其他关卡。仅仅一句声称“任务完成”的话，并不足以退出该循环。

这一机制为 SGLang SOTA Performance Loop 提供了执行与审查的基础。Claude Code 运行基准测试、读取性能剖析、修改 SGLang 代码并重新验证。Codex Review 在每一轮结束时检查证据、状态与风险。它非常适合那些将会成为 PR、影响服务正确性，或需要多日、多轮实验的任务。

在实践中，命令顺序应当明确，以免智能体直接跳入实现阶段：

1. Write a task draft under artifact_root/draft.md.
2. Run humanize-gen-plan to generate artifact_root/plan.md.
3. Start humanize-rlcr from artifact_root/plan.md.
4. Keep all decisions, summaries, and review state in the local Humanize workspace.

4.2 SGLang SOTA Performance Loop（循环工程）

单个技能可以稳定一项任务。然而，在十几轮实验之后，另一个问题就会出现：哪个候选方案最好、哪些方向已经失败、上一份 NCU 报告显示了什么、基准测试是否仍与基线匹配，以及何时停止。这种状态不能只存在于聊天上下文中。

SGLang SOTA Performance Loop 是一个基于 Humanize/RLCR 构建的 Loop Engineering 工作流。在这里，SOTA 指的是在固定实验条件下可复现的最佳结果：相同的模型、硬件、GPU 数量、精度、工作负载、SLA、框架 commit 和服务参数。问题在于，SGLang 能否在这些条件下达到当前可复现的最佳结果。

图 1：SGLang SOTA Performance Loop。一个固定的公平基准测试首先建立一个可复现的基线。随后的差距判定、性能分析、流水线分析、补丁修复和重新验证均由 Humanize/RLCR 循环驱动。

一个完整的 SGLang SOTA Performance Loop 包含以下阶段：

1. 定义目标边界。例如，Qwen/Qwen3-Next-80B-A3B-Instruct-FP8、单节点 2x B200、FP8、SGLang TP=2，并在相同的 2-GPU 预算下与所要求的开源推理框架进行对比。
2. 首先运行公平搜索。在给 SGLang 打补丁之前，先在相同的工作负载和资源预算下，为 SGLang 以及每个所要求的开源推理框架搜索可复现的最佳命令。
3. 判定差距。如果 SGLang 已经持平或领先，记录完成证据。如果它持续落后超过阈值，则进入性能分析。
4. 利用性能分析来解释差距。不要急于修改代码。首先产出 kernel 表、流水线表、重叠/融合表，以及需要时的 NCU 报告。
5. 只修补有证据支持的路径，例如混合注意力、Mamba/GDN、radix cache、target verify、CUDA graph、MoE/EP、量化 kernel 或模型封装层。
6. 在同一工作负载上重新验证。每一轮都记录基准测试、性能剖析、准确率、失败的尝试、环境信息以及清理操作。

对于诸如在 2x B200 上运行 Qwen/Qwen3-Next-80B-A3B-Instruct-FP8 这样的目标，循环之所以重要，是因为基准测试结果、性能剖析轨迹、失败的补丁以及中间结论都需要始终关联到同一个模型、硬件、工作负载和框架 commit。如果这类任务被拆分成许多相互独立的提示词，就很容易丢失哪条命令产生了哪个结果，或者后续的性能剖析是否仍与最初的基线相匹配。带有证据和审查的循环能让各轮之间的条件保持一致。

4.3 Codex 目标：一种更低成本的循环实现

上述 SGLang SOTA 性能循环采用双角色设置：Claude Code 执行基准测试、性能剖析、打补丁和重新验证，而 Codex Review 在每一轮结束时进行检查。这种设置适合正式的 PR 工作，但每一轮都会同时消耗一个执行模型和一个审查模型，从而增加成本和等待时间。

Codex Goal 提供了另一种实现方式。一旦将“公平基准测试 -> 差距判定 -> 性能剖析 -> 补丁 -> 重新验证 -> 产物台账”写入一个持久化的 Goal，单个 Codex Goal 就能承载执行、自检和重新验证，无需双角色的执行/审查设置。SGLang SOTA 性能循环的核心约束依然保留：固定工作负载、证据驱动的补丁、在相同实验条件下重新验证，以及每轮之后更新产物清单。

两种方法的差异如下：

以下是来自 AI-Infra-Auto-Driven-SKILLS/prompts 的一个 2x B200 模型优化提示词示例。

Humanize/RLCR 版本：

Use the sglang-sota-humanize-loop workflow.

Task:
Optimize SGLang serving performance for Qwen/Qwen3-Next-80B-A3B-Instruct-FP8
on a single node with 2 NVIDIA B200 GPUs, FP8 precision, and initial SGLang
TP=2. SGLang should match or exceed the best reproducible result from the
requested open-source inference frameworks under the same 2-GPU budget, workload, SLA,
model, precision, and environment constraints.

Required workflow:
1. Create a draft task document under artifact_root.
2. Run humanize-gen-plan to turn the draft into a structured plan.md.
3. Start humanize-rlcr from that plan.md in the Claude Code session.
4. Keep benchmark, profile, patch, and revalidation decisions inside the same
   Humanize workspace.

Evidence and safety requirements:
- Before patching, run a fair bounded search for SGLang and the requested open-source inference framework set.
- Check relevant open PRs in sgl-project/sglang and BBuf/sglang before choosing
  the SGLang baseline.
- If SGLang is behind by more than 1%, profile before patching.
- Prioritize evidence around hybrid attention, Mamba/GDN, radix cache, target
  verify, and CUDA graph.
- Record benchmark commands, profile artifacts, failed attempts, and cleanup
  evidence for every round.
- Patch only evidence-supported SGLang code paths.
- If a PR is needed, push/open it only against BBuf/sglang and include benchmark,
  GSM8K, and full MMLU accuracy tables.

artifact_root:
/workspace/sglang-agent-artifacts/b200_qwen3_next_80b_a3b_instruct_fp8_sota_humanize

Codex Goal 版本：

/goal Keep optimizing SGLang serving for
`Qwen/Qwen3-Next-80B-A3B-Instruct-FP8` on a single node with 2 NVIDIA B200
GPUs until SGLang matches or exceeds the best reproducible result from the
requested open-source inference frameworks under the same 2-GPU budget, FP8 precision,
workload, SLA, model, and environment constraints. The current Codex Goal is the loop: fixed fair
benchmarking, gap decision, profiling, pipeline analysis, evidence-backed
patching, revalidation, final report, and optional PR preparation all happen
inside this Goal. Completion requires benchmark evidence, profile evidence when
SGLang was behind, correctness/accuracy evidence, a final artifact manifest,
and no regression in environment safety constraints.

model_id: Qwen/Qwen3-Next-80B-A3B-Instruct-FP8
root_dir: /workspace
target_hardware: single-node 2x NVIDIA B200
minimum_gpu_count: 2
precision_quantization: FP8
initial_deployment: SGLang TP=2
artifact_root:
/workspace/sglang-agent-artifacts/b200_qwen3_next_80b_a3b_instruct_fp8_sota_goal

Requirements:
- Use the current Codex Goal as the only persistent loop.
- Before patching, run a fair bounded search for SGLang and the requested
  open-source inference frameworks under the same 2-GPU budget.
- If SGLang is behind by more than 1%, profile in the same Goal, then use
  llm-torch-profiler-analysis, llm-pipeline-analysis, and ncu-report-skill when
  needed before patching.
- Focus on hybrid attention, Mamba/GDN, radix cache, target verify, and CUDA graph.
- Update the artifact manifest, benchmark evidence, profile evidence, failed
  attempts, and next-step decision after every round.
- Stop and report a blocker if resources are unavailable, evidence is
  untrustworthy, the budget is exhausted, or no defensible next patch exists.

Goal 版本保留了相同的基准、profile、精度和产物要求。区别在于，执行与审查被合并为一个持续存在的目标。在明确的硬性停止条件下，它能够以更少的编排承载相同的 SGLang SOTA Performance Loop。

5. 面向 SGLang 系统的基于 KDA 的 CUDA Kernel 优化

在对 LLM 和扩散模型进行模型层面的优化之外，kernel 优化面临着一个更为严苛的扩展性问题。不存在独立于硬件和工作负载的单一最优 kernel。同一个算子可能在 H100、H200、B200 或 B300 上偏好不同的实现；不同的模型架构暴露出不同的张量形状和布局约束；而服务负载会改变 batch size、序列长度、精度格式、wrapper 开销、同步行为和回退路径。在实践中，搜索空间是硬件、模型和工作负载定义的笛卡尔积。

这带来了组合优化的负担。对于每个候选 kernel，开发者需要提取有代表性的生产数据行、构建相同 ABI 的测试框架、运行 A/B 测量、检查跨形状分桶的正确性、读取 NCU 指标、判断某个分桶是否值得专门化，然后在真实的 SGLang 路径中重新验证。对每一个硬件/模型/工作负载组合手动完成这些工作代价高昂。而这恰恰是智能体擅长的重复性、证据密集型工作流——只要人类定义好不变量并审查最终路径。

然而，让智能体直接编写 CUDA 很容易导致基准测试的奖励黑客行为：修改基准测试、使用更轻量的 wrapper、启用基线未使用的快速数学、只优化一种形状、破坏数值语义，或者在真实的 SGLang 路径中毫无收益。

KDA-Pilot 将 kernel 优化拆分为隔离的任务，使智能体无法自由修改整个 SGLang 代码库：

• 工作负载来自真实的 SGLang 扩散模型。该流程首先运行 20 个扩散模型并汇总实际的 kernel 元数据。
• 基线从上游 SGLang main 复制而来，并记录了来源谱系。
• 基线和候选版本必须使用相同的本地 ABI 以及相同的构建/导出路径。
• 基准测试使用固定的生产数据行、A/B 交错执行，以及 CUDA event 或 wall 计时。
• 正确性覆盖生产数据行、一个规范回归网格、NaN/Inf 检查、毒化输出检查以及回退契约。
• 每次迭代都会刷新任务提示词、基准测试证据、KernelWiki 和 ncu-report-skill。
• 允许按形状特化的分发，但每个分桶都必须记录其条件、路径、延迟和回退方案。

一个具体的快照能让规模更直观。公开的 KDA-Pilot B200 扩散摘要目前列出了 10 个被跟踪的 SGLang kernel 任务。大多数行在 KDA-Pilot 账本中都有稳定的 B200 数值证据，在提取出的生产数据行上，wall-geomean 加速比范围为 1.1341x 到 2.7499x。residual_gate_add 行显示为 1.11x，与已合并的上游 LTX-2.3 B200 结果一致。

截至 2026 年 6 月 27 日，已有三项源自 KDA-Pilot 的优化合入 SGLang 上游。第一项是 SGLang PR #27392，针对 Qwen-Image-2512 的 B200 原生扩散 norm-scale-shift CUDA 快速路径。当周晚些时候又合入了两项：SGLang PR #29281，针对 Cosmos3 VAE 因果 Conv3D cat/pad 拷贝路径；以及 SGLang PR #29361，针对 LTX-2.3 residual-gate 更新路径。

关键结论并不是每一个单独的 kernel 优化成果都能转化为大幅度的端到端提升。而是同一套 KDA-Pilot 证据包——固定的生产行、正确性门控、同 ABI 对比、profiler 归因以及真实模型验证——能够将一个 kernel 任务从孤立的基准测试推进到可审查的 SGLang 服务路径中。

图 2：由 KDA-Pilot 优化的 10 个被跟踪的 SGLang 扩散 kernel 任务的 B200 证据。大多数行报告的是 KDA-Pilot 的 wall-geomean 加速比；wall time 包含 Python 调度、wrapper 开销、kernel 启动以及通过 cuda.synchronize() 可见的同步开销，这比纯粹的 kernel 设备时间更接近真实调用路径。

阅读图表和任务表时应牢记其实验设置：它们报告的是在抽取出的生产行上的 kernel 任务加速比，而非完整的模型端到端收益。它们仍然有用。一旦基线、工作负载、正确性、性能剖析和审查都固定下来，智能体就能在真实框架 kernel 上产出可审查的增量改进。

KDA-Pilot 实验中有两条规则值得保留：

• 不要给基准奖励作弊留下空间。当基线和候选方案使用不同的 ABI、不同的 fast-math 设置或不同的封装路径时，结果就会变得不可靠。另一个常见问题是在看到结果之后更改基准的 shape 集合，例如删除候选方案较慢的那些 shape。此类结果不应被采用。
• 接近 Roofline 的桶应当允许做出不执行或回退的决策。一个好的内核优化任务不应迫使智能体在每一种形状上都取胜。对于巨大的连续桶或已经接近带宽上限的路径，记录一次回退可能比增加更多复杂度更好。

6. 实践规则

1. 在启动智能体之前先定义任务边界。“优化 SGLang”太宽泛了。“在固定的Qwen/Qwen3-Next-80B-A3B-Instruct-FP82x B200 上，在固定1000->1000和8000->1000工作负载下，追平另一个开源推理框架”才是一个可执行的目标。

2. 在阅读性能剖析结果之前，先固定基准测试。如果工作负载在结果已知之后还能被更改，智能体可能会无意中优化一个更容易的问题。SOTA 循环和 KDA-Pilot 都是先固定工作负载，再进行补丁修改。

3. 根据 kernel 的计算特征来解读 NCU 结果。对于内存受限的 kernel，重点关注 DRAM/L2 吞吐量、加载/存储效率以及内存管道利用率。对于计算受限的 GEMM/attention kernel，重点关注 Tensor Core 利用率、SM 忙碌率、可调度 warp 以及主要停顿原因。对于小型延迟受限的 kernel，检查启动次数、单 kernel 持续时间、同步点以及可能的融合机会。仅凭一张 trace 截图是不够的；下一步代码改动应当有具体指标作为支撑。

4. 在信任一份性能剖析之前，先检查后端和回退门控。如果一次 LLM 运行悄悄切换了 attention 后端、禁用了 CUDA graph，或者走了与基准测试不同的封装路径，那么该 trace 就不再描述目标服务路径。同样的规则适用于扩散模型：如果日志显示回退到了 diffusers 后端，那么该 trace 就不能作为原生 SGLang 扩散的证据。这些硬性停止条件应当写入技能中。

5. Kernel 优化必须使用相同的 ABI、封装和编译标志。特别是，候选方案不应悄悄走一条更轻量的路径，--use_fast_math 也不应只在单侧启用。

6. 评审比以前更重要了。智能体可以创建更多 PR，也可能制造更多看似合理的错误。对于像 SGLang 这样的高性能系统，评审需要检查 shape、dtype、分布式执行、CUDA graph 行为、回退行为、精度、服务 API、指标以及基准测试设置。

智能体时代的 SGLang 开发不会把开发者从系统中移除。更现实的变化是把开发者体验写入工作流，把重复性执行交给智能体，把判断、设计和评审留给人。节省下来的时间可以投入到更困难的性能问题、模型路径和生产稳定性上，或者反过来用于改进智能体工作流本身。对于一个开源推理框架来说，这类基础设施值得持续投入。

7. 致谢

我们感谢帮助构建 SGLang 智能体技能的 SGLang 团队成员和贡献者：Xiaoyu Zhang（BBuf）、Lianmin Zheng、Liangsheng Yin、Ke Bao、fzyzcjy、Kangyan Zhou、DarkSharpness、Mick、Alison Shao、Baizhou Zhang、Bingxu Chen、Cheng Wan、Ratish P、shuwenn、ykcai-daniel、Yuhao Yang 和 Artem Savkin。

我们感谢 KDA 团队：Dongyun Zou、Ligeng Zhu、Sihao Liu、Junxian Guo、Yixin Dong、Zijian Zhang、Hao Kang 和 Song Bian。

我们感谢 Humanize 团队和贡献者：Sihao Liu、Ligeng Zhu、Zijian Zhang、Zenus Zhang、shinan6、DYZhang、Chao Liu、Zhou Yaoyang、gyy0592、AcrossForest、Emin、Qiming Chu、jiaxiaoyu、tastynoob 和 zhenwei。

8. 参考文献

• SGLang GitHub 仓库
• SGLang .claude/skills
• SGLang 扩散模型 .claude/skills
• AI-Infra-Auto-Driven-SKILLS
• AI-Infra-Auto-Driven-SKILLS 提示词
• 内核设计智能体（KDA）
• KernelWiki 技能
• ncu-report-skill
• KDA-Pilot
• SGLang 扩散模型高级优化，LMSYS 博客
• OpenAI Codex 提示技巧：目标模式
• Humanize