企业官网建设流程全解析

摘要

代码 Agent 能修复 GitHub Issue，不等于它能完成生产级工程。SWE-Serve 最新论文把评测推进到大模型推理服务场景：53 个任务全部来自 SGLang 的真实生产变更，覆盖模型支持、运行时执行、调度状态和服务 API。研究发现，在 19 个带端到端验证的任务中，约三分之一“其他测试全部通过”的补丁仍无法通过真实服务链路；移除端到端测试后，平均通过率会提高 23.4 个百分点。对研发团队而言，这揭示了一个关键事实：Agent 最容易交付的是局部正确，最难保证的是生产正确。

一、背景：传统编码评测漏掉了什么

SWE-bench 一类基准推动了代码 Agent 从生成函数走向仓库级修改，但生产推理系统有更复杂的正确性边界。一个改动可能在单元测试里运行正常，却在请求进入公开 API、经过调度器、模型执行、KV Cache 与持久状态后失败。并发请求、共享状态和性能约束，也很难通过局部测试完整覆盖。

SWE-Serve 因此没有把目标限定为“生成一个看起来合理的补丁”，而是评估 Agent 能否把功能贯穿完整生产路径。论文使用 2025 年 12 月以来合入 SGLang 的真实变更构造任务，并在封闭网络条件下执行，避免 Agent 直接检索上游答案。

二、技术要点：53 个生产任务如何构造

SWE-Serve 包含 53 个仓库级任务，分为六类推理工程工作。其中 12 个任务在 CPU 环境执行，41 个任务使用单张 H100 GPU；19 个任务包含严格的模型服务端到端测试，3 个任务设置了校准后的性能门槛。

这些任务来自 83 个已经合并的上游 Pull Request。37 个任务对应单次上游变更，另外 16 个任务整合了 2 至 6 个相关变更，避免用单个 PR 的边界人为切碎一个完整工程目标。

任务规模也并不轻量。论文给出的标准实现中位数需要修改 7 个文件、553 行代码，最大任务涉及 35 个文件和 6077 行代码。Agent 获得任务描述、指定提交版本和可用测试，但看不到标准补丁、变更编号与隐藏验证器。最终评分依靠可执行测试，而不是将生成代码与标准答案做文本比对。

三、最重要的发现：本地正确不等于生产正确

论文在 11 个模型、31 种模型与推理强度配置上进行测试，最佳配置的平均 pass@1 约为 75%。但总成绩并不是最值得关注的结论，真正重要的是端到端测试改变了哪些结果。

在 19 个具有端到端覆盖的任务中，部分 Agent 补丁通过了其他所有测试，却无法通过真实服务器的公开接口正确提供模型服务。论文汇总显示，排除端到端测试时平均通过率为 69.4%，纳入端到端验证后降至 45.9%。换一种统计方式看，移除端到端测试会让平均通过率上升 23.4 个百分点，而且 11 个模型的最佳配置全部出现提升。

一个典型案例是 Gemma 4 MoE 核心服务任务：33 个补丁中有 16 个通过了端到端测试之外的全部检查，却不能通过真实服务链路正确运行指定模型。局部代码、已有测试甚至集成组件都可能“全绿”，但用户实际调用仍然失败。

四、Agent 最容易在哪些地方失手

研究将请求到输出的运行路径分为请求 I/O、调度与生命周期、模型执行、KV Cache 与资源管理四个域。只涉及单一运行域的任务平均通过率为 69.0%，跨多个运行域的任务下降到 47.7%，相差 21.3 个百分点。

在 GPU 任务中，需要处理持久状态的任务通过率平均低 20.8 个百分点；明确测试并发协调的任务低 29.0 个百分点。提高模型推理强度可以改善整体表现，却不能稳定消除这些生产正确性差距。

原因并不神秘。Agent 通常能沿着显式错误、局部测试和类型信息快速找到修改点，但生产系统的契约分散在多个模块之间：调度器维护生命周期，缓存保存跨请求状态，公开 API 负责输入输出兼容，并发执行又引入时序问题。任何一层理解不完整，都可能产生“补丁合理、局部可测、上线失败”的结果。

五、研发视角：团队应该怎样调整 Agent 工作流

第一，验收标准必须从“测试通过”升级为“生产路径通过”。对于推理服务、支付、消息队列和数据管道等系统，至少要加入从公开入口到最终结果的端到端用例，并覆盖真实状态变化。

第二，把持久状态与并发测试设为 Agent 任务模板的默认项。除了普通成功路径，还应检查请求重试、多个请求共享资源、取消与超时、缓存回收、异常恢复以及重复调用的幂等性。

第三，隐藏关键验收测试。若 Agent 在修改过程中反复看到全部测试细节，容易针对断言做局部修补。保留一组独立的回归和端到端验证，可更接近真实代码审查与上线门禁。

第四，要求 Agent 输出验证证据，而不只是补丁。提交内容应包括影响范围、关键假设、执行过的测试、未覆盖风险以及性能变化。评审者由此可以把注意力放在跨模块契约上，而不是逐行重新理解生成代码。

第五，区分基准成绩与团队可用性。论文还指出，不同 Agent Harness 会影响成本、时间与 token 消耗，但模型专用 Harness 并未在其两组对比中自动获得更高 pass@1。团队应使用自己的仓库、硬件和生产流量模型做回归，而不是仅凭公开排行榜选型。

六、风险与限制

SWE-Serve 目前只基于 SGLang，执行环境限制为 CPU 或单张 H100，尚未覆盖多 GPU、多节点、解耦式部署和更复杂的分布式协调。因此，论文观察到的差距不能直接代表所有生产系统。

可执行测试也不能评估全部上线质量，例如可维护性、架构一致性、可观测性和长期运维成本。闭卷与轨迹审计能够减少直接检索答案，但无法完全排除模型在训练阶段接触过公开 SGLang 代码的可能。

结语

SWE-Serve 给代码 Agent 评测补上了一块长期缺失的拼图：不是问“补丁能不能通过局部测试”，而是问“功能能不能沿完整生产链路正确工作”。当端到端测试可以再刷掉约三分之一的表面合格补丁时，研发团队真正需要升级的并不只是模型，而是任务定义、验证体系与上线门禁。

参考来源

SWE-Serve: Benchmarking Agentic Engineering For Production Inference Serving
https://arxiv.org/abs/2609.26777