代理工作流检查点

在处理 bug 修复时运行编码代理的团队，可以加一个修复门，在定位、打补丁和验证之间保留失败测试证据。这个门应先拦截不可应用的 diff、语法错误和构建失败，再在完整回归套件之前重跑最初失败的测试。失败尝试应向代理返回结构化诊断，并保存最早的决定性错误步骤，供复查使用。

EviACT 给出了这个流程的具体版本：它把 RED 失败测试证据映射到可疑代码跨度，用编译门过滤无效补丁，并在回归前运行目标测试。使用 GPT-4o 时，它在 Defects4J 2.0 上报告了 25.0% 的解决率，在 SWE-bench Verified 上为 40.4%，在可获取基线成本的情况下，每个 bug 的 API 成本低 70.1% 到 88.6%。TrajAudit 补上了审计轨迹：它通过预测把运行带偏的第一步来诊断仓库级代理运行失败，在 RootSE 上的定位准确率比基线高 24.4 个百分点以上，同时使用的 token 至少少 18%。

一种低成本上线方式是在现有代理运行器和 CI 系统外面加一层包装。先在最近失败的代理补丁上运行它，比较被接受的修复、构建失败率、完整回归调用次数和每个被接受补丁的 token 数，再决定是否把这些门设为代理生成 pull request 的必经步骤。

要求代理撰写正式规格的团队，应该先把规格当作程序工件测试，再相信验证器结果。实际做法是搭一个 harness，把需求转成对有效输入、无效输入、正确输出和错误输出的可执行检查，然后用隐藏样例和对抗样例去测试生成的规格。

Verus-SpecGym 说明了这个检查为什么重要。验证器可能会证明一个错误规格下的代码正确，所以规格必须和用户意图一致。这个基准给代理提供从 Codeforces 派生的任务、Verus 骨架、示例、文档和工具访问，然后用可执行的 Rust 检查评估生成的规格。报告中的最佳模型在 581 个任务上解出 77.8%，而 LLM-as-a-judge 的评估漏掉了可执行评估器抓到的 26% 失败。

落地路径很窄，也很实用：先从小的纯函数或服务级不变量开始，让产品负责人能写出示例和边界情况。只有当一个生成的规格在具体测试下接受有效行为、拒绝无效行为时，才把它当作可以进入证明工作的规格。

多代理工作流的团队可以加一套测试，用来覆盖声明的协作结构，包括可达代理、允许的工具调用、受限工具尝试和委派边。实现方式很直接：从代理入口提取清单，把它转成图，为每个义务生成见证场景，再根据运行时轨迹判断是否出现预期事件或违规。

这篇工作流测试论文在 OpenAI Agents SDK 风格的系统上演示了这套方法。它覆盖了 10 个派生自 SDK 的工作流，包含 49 个可达代理、47 个工具和 403 项结构义务；在给定的细化预算内，生成场景见证了 75 项允许工具义务中的 54 项，以及 48 项委派义务中的 36 项。受限工具探测在 248 项受限工具义务中发现了 23 次违规。

这适合已经手动检查工具权限，或者只依赖端到端任务成功的团队。第一步检查可以在工作流修改后跑进 CI，只对受限工具违规失败；允许调用和委派路径的覆盖阈值可以先按报告的指标设定，直到这些场景稳定下来。