SGLang 团队最近发布了一篇工程复盘，主题是 Agent-assisted SGLang development。
这篇文章讨论的问题很具体：SGLang 这样的高性能推理框架，想让 Coding Agent 真正帮上忙，不能只停在“帮我改一段代码”，而要把它接进 benchmark、profiling、patch、review、revalidation 这一整套工程循环里。
SGLang 现在同时覆盖 LLM serving、分布式 runtime、GPU kernel、diffusion pipeline、模型特定执行路径和生产环境排障。一个看似普通的性能改动，可能一路穿过 scheduler、CUDA graph、FlashInfer/FlashAttention、NCCL、Triton/CUDA kernel、模型 wrapper 和后端 fallback。仅靠一句 prompt 让 Agent 自由发挥，很容易得到一个看起来合理、实际很难 review 的补丁。
SGLang 团队的做法，是把老工程师平时靠经验完成的流程写成可执行资产：SKILL.md、脚本、benchmark 契约、profiling 证据格式和 review loop。Agent 负责复现、测量、整理证据和小步修改，人负责定义目标、判断证据、决定补丁能不能进主线。
为什么是 SGLang
SGLang 是一个高性能大模型与多模态模型服务框架。对这类系统来说，很多问题表面上只是“某个请求慢了”“某个模型跑不起来”“某个 kernel 可以优化”，真正排查时却会牵出一长串工程细节。
LLM 路径里，性能可能受 Python runtime、scheduler、CUDA graph、Triton/CUDA kernel、FlashInfer/FlashAttention、分布式通信和模型特定 wrapper 共同影响。Diffusion 路径同样复杂，一次 denoise 变慢，可能和 pipeline 切分、DiT block、attention backend、torch.compile graph break、CFG/SP parallelism、VAE，甚至某个 fused kernel 有关。
更难的是验证。GPU 型号、shape、batch size、并行方式、精度、后端和 compile 状态都会改变结果。一个 microbenchmark 跑赢了，不代表完整模型路径一定变快；一个本地单测通过，也不能证明它适合进入生产 serving 路径。
这些任务恰好包含大量重复执行：启动服务、固定 workload、跑 benchmark、抓 trace、整理 NCU 结果、定位瓶颈、补测试、复跑同一组实验。只要流程写得足够清楚，Agent 就可以承担很大一部分机械工作，让开发者把精力留给判断。
高性能推理框架也会放大 Agent 的问题。shape 少覆盖一个、dtype 漏掉一种、fallback 路径被改坏、CUDA graph 行为被破坏、benchmark 条件不公平，都会让“看起来不错”的补丁变成维护成本。SGLang 这篇复盘的重点，正是把 Agent 放进一个可审查的工程流程里。
SKILL.md 写成工程规程
SGLang 仓库里已经有一组 .claude/skills，覆盖 CUDA crash debugging、kernel integration、test/CI、profiling、生产排障和源码树约定。Diffusion 目录下还有单独的 .claude/skills，用于新增 diffusion 模型、跑 benchmark、profiling denoise 路径、调性能选项和验证量化 pipeline。
这些 skill 本质上是工程规程，不是普通提示词模板。它们会写清楚什么时候使用、前置检查是什么、什么情况下必须停止、要生成哪些 artifact、结果表格怎么填、失败时如何回退。
比如调 CUDA crash，Agent 不应该一上来就在代码里到处加日志。更稳的流程是先确认复现命令、模型路径、硬件环境和后端状态，再沿着 kernel API、wrapper、shape、dtype、fallback 逐层缩小范围。性能优化也是一样，先固定 workload 和 baseline，再谈 profile 和 patch。
SGLang 团队提到的 skill stack 里，有几类很典型。debug-cuda-crash 负责把瞬时 crash 变成可以离线分析的样本；llm-serving-auto-benchmark 和 llm-serving-capacity-planner 负责跨框架 benchmark 和容量解释；llm-torch-profiler-analysis、llm-pipeline-analysis 用来读 trace、拆 forward pass 和 layer；sglang-prod-incident-triage 面向线上事故包、失败请求和 replay；sglang-sota-humanize-loop 则把多轮 benchmark、profiling、patching 和 review 串成一个长循环。
BBuf 的 AI-Infra-Auto-Driven-SKILLS 把这套思路扩展到更广的 AI Infra 场景：跨框架 serving benchmark、容量规划、profile/pipeline 分析、模型 compute simulation、SGLang human-style review、生产事故排查、SOTA performance loop，以及模型 PR 历史分析。
普通团队其实也可以借鉴这一点。不要只给 Coding Agent 一段泛泛的系统提示词，而是把项目里最常重复、最容易出错、最依赖资深工程师经验的流程写下来：如何启动、如何复现、如何验证、什么情况下停止、最后交付什么证据。
具体 PR 说明了什么
SGLang 这篇复盘并没有停在方法论。文章列出了一组近期已经合入的 PR，能看到 Agent-assisted workflow 在真实工程路径里发挥作用的方式。
一个例子是 Router long-context tokenization deduplication，对应 SGLang PR #28744。它面向 DeepSeek-V4-Flash deployment，处理 cache-aware routing、chat-encoder parity、engine-side input_ids fallback 和 proxy body construction，避免 router 和 engine 重复 tokenization。文章给出的结果是，60k/125k-token prompts 的 idle TTFT 分别下降约 29%/41%；在 60k-token load 下，TTFT 下降 34%-49%。
另一个例子是 Qwen3-Next FlashInfer allreduce fusion，对应 PR #22664。在 H100 TP=4 上，request throughput 从 5.49 req/s 提升到 9.41 req/s，约 +71.4%；mean TTFT 从 456.24 ms 降到 167.54 ms。这个优化来自 profile-driven collective optimization：unfused cross-device reduce 主导 prefill，fused allreduce path 再通过 MMLU/GSM8K accuracy checks 验证。
Cohere2Moe NVFP4 fused-MoE path 对应 PR #27401。对 CohereLabs/command-a-plus-05-2026-w4a4，在 1x B300 上，相比此前的 SGLang default，request throughput 在 chat 上提升 +26%，在 summarization 上提升 +21%；在相同设置下，也超过另一个开源推理框架 +4.1%/+6.8%。
Diffusion 侧也有清晰案例。Spectral Progressive Diffusion 对应 PR #27524，在报告的 RTX A6000 设置下，FLUX.1、FLUX.2、Z-Image、Wan 和 Qwen-Image 的 denoising speedups 分别达到 1.63x、1.77x、2.07x、2.32x 和 1.6x。LTX-2 VAE decode channels-last-3d 对应 PR #27431，把 LTX-2 decode stage 从 5.41s 降到 3.84s，约 1.41x，同时 peak reserved memory 从 71.81 GiB 降到 62.12 GiB，节省约 9.7 GiB。
这些例子有一个共同点：Agent 的贡献不只是生成代码。它要运行 benchmark、读取 profile、定位源码、修改代码、添加测试、重新验证，并把 PR 需要的证据整理出来。没有这些固定流程，很多步骤都要靠人工提醒；一旦写进 skill，工作流就可以被重复运行。
Profiling 变成 Agent 的工作台
在 SGLang 这样的项目里，性能优化绕不开 profiling。一条 trace 里可能有几百次 kernel launch。手工读 Perfetto 或 NCU 报告，很容易把 prefill 和 decode 混在一起，也容易忽略某个 kernel name 对应的源码位置。
SGLang 复盘里提到，llm-torch-profiler-analysis 会把 global profile 先整理成三张固定表：Kernel Table、Overlap Opportunity Table 和 Fuse Pattern Table。第一张表回答哪个 stage、哪个 kernel 占了多少 GPU 时间，以及它们映射到哪段 Python source；第二张表看 exclusive/hidden time share、dependency risk 和剩余 overlap 空间；第三张表把 trace 和已有 fusion/overlap pattern 对齐，判断是否有可参考的优化路径。
这一步之后，还会用 llm-pipeline-analysis 继续往下拆。它读取 Chrome trace JSON 和模型 config.json，用 layer-boundary anchor kernels 把 trace 切成 forward passes、layers 和 kernel flows，再输出 Forward pass summary、Per-layer timeline、Layer cluster statistics 和 Compute flow table。
这个两步过程很关键。第一步避免凭直觉选一个“看起来很热”的 kernel；第二步把问题落到 steady-state forward pass、代表性 layer 和具体 kernel flow 上，避免只盯住全局热点，却漏掉模型结构里的 layer-type difference。
对 Agent 来说，这些固定表格就是工作台。它不能只交出一句“可能这里慢”，而要把可检查的证据摆出来。开发者再根据表格判断，是该看 memory bandwidth、Tensor Core utilization、eligible warps、stall reason，还是先排除 launch count、同步点和 graph break。
KDA-Pilot 把 kernel 优化放回真实路径
这篇复盘里最具体的一组例子来自 KDA-Pilot。
KDA 指的是 Kernel Design Agents，是 MIT HAN Lab 等团队做的 kernel agent 项目，也是 MLSys 2026 FlashInfer Kernel Contest 的获胜方案。BBuf/KDA-Pilot 把 KDA 风格的 agent kernel 工作流用到 SGLang 上。
让 Agent 直接写 CUDA 很容易出现 benchmark reward hacking：改 benchmark、只给 candidate 开 fast math、只优化一个 shape、破坏 numerical semantics，或者在真实 SGLang path 中没有收益。KDA-Pilot 的处理方式是把 kernel optimization 拆成受控任务，让 Agent 不能随意改整个 SGLang 仓库。
它的 workload 来自真实 SGLang diffusion models。流程会先跑 20 个 diffusion models，整理实际 kernel metadata，再固定 production rows、same local ABI、same build/export path、A/B interleaving、CUDA event 或 wall timing，同时做 correctness grid、NaN/Inf、poison output 和 fallback contracts 检查。
图 2 是KDA-Pilot 的证据链。kernel task 的 speedup 不能直接等同于完整模型收益，关键是 baseline、workload、正确性、profiling 和真实路径回测是否固定。
已经合入 upstream SGLang 的三个例子很有代表性。
PR #27392 面向 Qwen-Image 的 norm-scale-shift 路径。文章给出的结果是，目标 kernel group 在 profiler attribution 中提升 1.279x；在一张 B200 上，双方各跑五次交错实验，full-request speedup 为 1.125x，denoise-wall speedup 为 1.130x。
PR #29281 面向 Cosmos3 VAE causal Conv3D 的 cat/pad copy 路径。B200 上的 weighted kernel group 从 10.621 ms 降到 5.240 ms，约 2.03x；在启用 torch.compile 的 Cosmos3-Nano T2V 路径上，median E2E time 从 181.521 ms 降到 177.687 ms，约 1.021x。
PR #29361 面向 LTX-2.3 residual-gate update 路径。大 B200 LTX-2.3 rows 相比已有 Triton 路径提升约 1.108x 到 1.130x，周边 diffusion rows 最高到 2.587x；在 LTX-2.3 HQ T2V 上，E2E time 从 46644.08 ms 降到 45198.37 ms，约 1.032x。
这些数字放在一起，反而能看到高性能系统的真实面貌：kernel 级别的提升很大，端到端收益可能只有几个百分点。对推理框架来说，这不是坏结果。它说明 Agent 写出的 kernel 优化需要经受真实路径、正确性、fallback、wrapper、profiler attribution 和 review 的共同检验。
Loop Engineering 开始落到工程细节
SGLang 团队在文章里用了一个说法：Loop Engineering。
它指向一套可重复运行的工程循环：固定目标，运行实验，收集证据，做小步修改，复测结果，让人 review，再根据反馈进入下一轮。放在 SGLang 里，对应的就是 SOTA Performance Loop。
这里的 SOTA 指固定条件下的最佳可复现结果：相同模型、硬件、GPU 数量、precision、workload、SLA、framework commit 和 serving parameters。问题变成：在这些条件下，SGLang 能不能达到当前最佳可复现结果。
一个完整循环大致会这样跑：先定义 target boundary，例如某个模型、某组 B200/H100 配置、某个并行策略和精度；再做 fair search，在 patch SGLang 之前，把 SGLang 和对照框架都跑到各自可复现的最好结果；如果 SGLang 持平或领先，就记录 completion evidence；如果持续落后，再进入 profiling，用 kernel table、pipeline table、overlap/fuse table 和 NCU report 解释差距；只有证据支持的路径，才进入 patch 和 revalidation。
Humanize/RLCR 可以把外部 review 放进这个循环。Claude Code 运行 benchmark、读取 profile、修改 SGLang 代码并重新验证；Codex Review 在每一轮结束时检查 evidence、state 和 risk。OpenAI Codex 的 Goal mode 也被文章列为一种成本更低的 loop implementation：把 fair benchmark、gap decision、profile、patch、revalidate 和 artifact ledger 写进持久目标，让一个 Goal 承载执行、自检和重新验证。
工具本身不需要被神化。重要的是开发方式正在变化：过去散落在聊天上下文里的命令、结论、失败尝试和 profile 证据，被放进一个可持续运行的循环里。长周期优化不再是一轮一轮重新解释背景，而是在同一个实验条件下持续推进。
普通团队能学什么
SGLang 是高性能推理框架，很多细节离普通应用团队比较远。但这套方法并不只属于 AI Infra。
第一，把项目经验写成文件。如何本地启动服务，如何跑最小复现，哪些测试必须通过，哪些日志代表 fallback，哪些 benchmark 结果才可信，这些内容越清楚，Coding Agent 越容易进入项目。
第二，先固定 benchmark，再让 Agent 改代码。很多 Agent 任务失败，常见原因是目标和通过标准一直在变，和模型会不会写代码不是一回事。今天换一个 workload，明天换一个判断口径，最后得到的补丁很难 review。
第三，要求 Agent 产出证据。后端服务可以是压测、日志、trace 和测试结果；前端可以是截图、交互路径和视觉回归；数据任务可以是样本、口径和异常记录。补丁只是交付物的一部分，证据才决定它能不能进入下一轮。
第四，人要负责停止条件。什么时候不该继续优化，什么时候应该 fallback，什么时候一个收益不值得增加复杂度，这些判断很难完全交给 Agent。尤其是性能系统，追求局部指标很容易带来维护成本。
这样看，Coding Agent 更像一个能耐心执行流程、整理证据、持续复跑的工程助手。它把重复劳动接过去，工程师则把更多时间放在问题定义、证据判断、架构取舍和生产 review 上。
总结
SGLang 团队记录的是一次把 Coding Agent 放进真实 AI Infra 项目的尝试：先把经验写成流程，再让 Agent 按流程执行、记录和复跑，最后由人判断结果能不能进入主线。
这件事的变化比单个 kernel 提速更重要。Agent 可以加快实验循环，也会制造更多需要 review 的改动；在高性能系统里，每个 patch 都可能牵动 shape、dtype、分布式路径、CUDA graph、fallback、serving API、metrics 和生产稳定性。Agent 越会写代码，人越要看住 benchmark、公平性、证据和可复现性。
SGLang 这篇复盘留下的启发很朴素：工程师把经验写成流程，把重复执行交给 Agent，把时间留给判断。Coding Agent 在 2026 年更现实的落地形态，可能是先帮复杂系统把开发循环持续跑起来，而不是一次性替人完成复杂系统。
参考链接
-
LMSYS/SGLang 原文：https://www.lmsys.org/blog/2026-07-02-agent-assisted-sglang-development/ -
SGLang GitHub Repository：https://github.com/sgl-project/sglang -
SGLang .claude/skills：https://github.com/sgl-project/sglang/tree/main/.claude/skills -
SGLang diffusion .claude/skills：https://github.com/sgl-project/sglang/tree/main/python/sglang/multimodal_gen/.claude/skills -
BBuf/AI-Infra-Auto-Driven-SKILLS：https://github.com/BBuf/AI-Infra-Auto-Driven-SKILLS -
Kernel Design Agents：https://github.com/mit-han-lab/kernel-design-agents -
BBuf/KDA-Pilot：https://github.com/BBuf/KDA-Pilot -
Humanize：https://github.com/PolyArch/humanize -
OpenAI Codex Goal mode：https://developers.openai.com/codex/prompting#goal-mode
进技术交流群请添加AINLP小助手微信（id: ainlp2)
请备注具体方向+所用到的相关技术点 
关于AINLP
AINLP 是一个有趣有AI的自然语言处理社区，专注于 AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括LLM、预训练模型、自动生成、文本摘要、智能问答、聊天机器人、机器翻译、知识图谱、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLP小助手微信(id：ainlp2)，备注工作/研究方向+加群目的。
