摘要NVIDIA新发布的SWE-Serve用真实推理服务任务证明本地检查通过不等于补丁能加载真实模型并通过公开接口。本文把论文数据翻译成测试团队可落地的端到端门禁。一个AI Coding Agent修改了模型服务代码。单元测试通过静态扫描通过仓库回归也通过。研发准备合并时测试只问了一句真实模型能加载吗服务器启动后答案变成了不能。9月23日NVIDIA发布SWE-Serve。它不是再考AI会不会修一个函数而是把53个任务放进真实推理工程模型注册、权重加载、解码、缓存、调度、OpenAI兼容接口、批量请求与分布式执行。最值得测试团队注意的不是排行榜而是一组差距在19个包含真实服务检查的任务里627个补丁如果拿掉E2E服务测试通过率是69.4%放回完整验证器后只剩45.9%。共有147个补丁从“通过”变成“失败”。这不是说所有AI补丁都有同样失败率。它是NVIDIA研究团队在SGLang任务集和指定硬件上的作者实验结果。但它非常准确地暴露了一个工程盲区仓库内部正确不等于生产接口正确。为什么本地测试接不住真实服务模型服务不是一个普通函数。一次请求会穿过配置解析、模型注册、权重加载、显存分配、Tokenizer、批处理、KV Cache、专家路由、结果排序和API序列化。Agent可能只修对了它看得见的局部配置类能实例化但真实权重键名对不上单请求返回正确批量请求顺序错位文本模型能加载图像输入路径失败本地Mock有logprobs字段真实接口却漏掉功能能跑显存峰值或延迟超过发布门槛。这些错误无法靠增加几个Mock完全解决因为Mock恰好绕开了最容易出错的整条链路。从Outcome Evaluation升级到生产正确性传统AI Coding评测通常把“补丁能否通过测试”作为Outcome。但如果测试集没有启动真实服务这个Outcome本身就不完整。生产级评测至少要回答五个问题Build代码能否安装、导入和编译。Regression旧行为是否保持。Live Serving真实模型是否能启动并从公开接口返回正确结果。BehaviorAgent是否修改了允许的文件是否通过删测试、降断言逃过检查。Performance延迟、吞吐、显存有没有越过校准门槛。用一个订单推荐服务理解E2E门禁假设Agent为推荐模型新增批量推理。单元测试只验证内部函数返回两个结果但真实HTTP接口还要保证订单与结果不串位。def assert_serving_contract(client): request { orders: [ {order_id: A100, items: [phone]}, {order_id: B200, items: [coffee]}, ] } response client.post(/v1/recommend, jsonrequest) assert response.status_code 200 rows response.json()[data] assert [x[order_id] for x in rows] [A100, B200] assert all(x[recommendations] for x in rows) assert response.headers[x-model-version]这段断言承担的是业务质量判断不是“服务返回200”就结束而是身份、顺序、内容和版本证据必须同时成立。进一步还要检查Tracedef assert_patch_behavior(change): assert not change[deleted_tests] assert not change[weakened_assertions] assert change[files_changed] change[allowed_files] assert change[live_server_started] is True assert change[model_loaded] is True隐藏验证器为什么重要SWE-Serve不会把Agent补丁与参考实现逐行比较而是用隐藏的功能与回归测试判断行为。这一点值得企业内部照搬。如果AI能看到所有验收用例它可能过度拟合测试甚至修改测试来让自己通过。更稳妥的做法是把评测集分成三层开发可见帮助Agent完成基本修改CI隐藏覆盖关键业务边界和负向路径发布前真实环境加载真实模型、真实协议和受控流量。每个任务还要做两个控制旧代码必须在“新增行为”测试上失败参考补丁必须通过完整验证。否则测试可能根本没有区分能力。性能门不能只写“比以前快”SWE-Serve首版中有3个任务在H100上执行校准性能门禁。这里的关键词是“校准”性能阈值必须绑定硬件、模型、输入长度、并发数与预热方式。企业里可以把门禁写成def quality_gate(metrics, baseline): assert metrics[correctness] 1.0 assert metrics[p95_ms] baseline[p95_ms] * 1.10 assert metrics[peak_vram_gb] baseline[peak_vram_gb] 1.0 assert metrics[error_rate] 0.001不要把厂商Benchmark数字直接搬进自己的CI。真正有效的是固定自己的硬件、数据集与基线观察同一条件下的回归。把这套方法接入CI/CD一次AI补丁进入流水线后可以按成本由低到高执行静态检查与单元测试历史回归容器内启动服务加载小模型跑接口契约在目标GPU上跑关键模型最后用影子流量验证延迟和稳定性。低成本检查失败就尽早停止。真实服务测试可以只覆盖高风险变更例如模型注册、缓存、调度、批处理和协议层。普通文档修改不需要占GPU。同时保留五类证据任务说明、Agent Trace、代码Diff、完整测试报告、硬件与模型版本。事故发生时团队才能回答“为什么当时允许它合并”。对测试工程师意味着什么过去我们把端到端测试理解成“从页面点到数据库”。到了AI推理服务端到端变成“从公开API进入经过真实模型加载和运行时再验证结果、顺序、性能与资源”。接口自动化、环境构建、日志分析、性能测试和CI/CD经验都没有过时只是测试对象变了。如果你准备转AI测试开发最有说服力的项目不是“让AI写了多少代码”而是设计一个故意会在真实服务中失败、却能通过Mock测试的补丁然后用E2E门禁把它拦住。这个项目比一张Agent Loop架构图更能证明你理解生产质量。