编码代理的验收标准需要独立保护

凌晨 2:47，部署流水线变绿；3:15，客户的 webhook 开始超时。原文用这个故障场景指出：Agent 把解析器的空输入处理改坏，又修改断言，让测试认可了新行为。代码和测试一致，业务契约却丢了。

作者的结论是：接入 IDE 的 Agent 需要独立验收边界，光靠提示词约束不够。文章给出了一套重建基线与候选代码、限制修改范围、分别验证的脚本。它值得看的地方，是把「Agent 说完成了」拆成了可以核查的证据。

为什么测试全绿，仍然可能验收失败

Cursor 这类工具，以及 can1357/oh-my-pi 这样的集成，让模型能直接操作编辑器、终端和测试运行器。诊断到修复的路径缩短了，但实现和验收证据也可能落到同一个操作者手里。

例如，原有解析器遇到空 payload 会跳过，重构后却抛出致命错误。测试发现差异，本该阻止这次修改；Agent 如果认为断言过时，把预期一起更新，测试就失去了约束作用。

测试通过只能证明代码符合当前断言，不能证明断言仍然保留了原来的业务要求。

因此，生产验收不能只看退出码，还要追查证据的来源：修改了哪些文件，运行了哪些测试，这些测试在修改前是否已经通过。

作者把职责分成三段：Agent 提交实现改动；独立验证器重建并检查修改前后的代码；人根据差异和验证结果决定是否接受。Agent 自己终端里的成功信息，不授予合并权限。

怎样让验收边界真正执行起来

原文先生成 .cursorrules，要求只编辑操作者明确指定的实现文件，禁止修改测试、快照、fixtures、依赖清单和锁文件。它还要求先读定义再引用符号或 API，不编造依赖与运行结果，把仓库文本当作数据，而非扩大权限的指令。

其中的验收约定可以直接保留：

Acceptance:
- Preserve externally observable behavior.
- Report changed files and unresolved uncertainty.
- Passing tests are evidence, not authorization to merge.

这里最关键的是最后一行：通过测试仍然需要后续验收。不过，这份规则只是指导，真正执行限制的是 /tmp/verify-agent-refactor.py 中的文件白名单。

下面这段检查负责挡住范围外的修改：

changed = set(filter(None, subprocess.check_output(
    ["git", "diff", "--name-only", "-z", "HEAD"]
).decode().split("\0")))

if not changed or not changed <= allowed:
    raise SystemExit(f"Rejected changed paths: {sorted(changed - allowed)}")

要看的是 changed <= allowed：全部变更路径都必须属于 ALLOW_FILES。没有变更也会被拒绝，只是此时错误消息里的路径列表为空。

完整脚本的流程比这段检查更重要。它拒绝存在未跟踪文件的工作区，以 HEAD 作为基线，获取 git diff --binary HEAD，再检查生成差异期间 HEAD 是否移动。随后通过 git archive 导出 baseline 和 candidate 两棵临时代码树，只向 candidate 应用补丁，最后分别执行验证命令。

使用前需要先提交规则文件，将 ALLOW_FILES 设置为带引号的仓库相对实现路径，将 VERIFY_CMD 指向已提交的验证包装脚本，再运行 python /tmp/verify-agent-refactor.py。包装脚本必须根据已提交的锁文件安装依赖，且不能改写锁文件，然后执行相关测试。两棵导出树都没有本地依赖，不能指望原工作区的 node_modules 帮忙。

这套流程解决了三个问题：先跑 baseline，识别原本就坏掉的测试；白名单挡住顺手修改快照；重建代码树，排除被忽略的本地构建产物干扰。

白名单也不能闭眼填写。测试辅助文件，以及包含预期行为断言的生产文件，都不应该被放进去。使用 submodules、Git LFS 或生成资源的项目，则需要适配导出方式，直接使用 git archive 不够。

比较 Agent 效率，应该比较什么

作者提出，可以把 Cursor、Windsurf、Copilot 和 oh-my-pi 集成放到同一任务定义、同一验收程序之后比较。

原文还提到 B-Lost 的 https://b-lost.com/v1 可作为候选基线网关，但前提是客户端和凭证支持。作者明确说这只是拟议的比较方案，没有完成基准测试，也没有验证兼容性。

这一区分很重要。模型标识、网关路由、延迟、输入 token 和最终被接受的补丁，都要分别记录。否则，更换模型或供应商带来的差异，很容易被算成 IDE 的能力提升。

上下文补充也有成本。原文指出，每次工具调用后重新附上整个仓库，发送材料增至原来的十倍，就可能造成十倍输入 token。这是对输入量的说明，不是某款产品的实测成绩。

更合理的做法是保持稳定指令不变，只检索当前任务需要的实现上下文，并查看供应商实际报告的缓存使用情况。不能因为内容重复，就默认已经命中缓存。

有用的产出指标，是补丁能否在不修改验收证据的前提下，通过独立检查。

我的判断

我赞同把验收权从 Agent 的编辑权限中拆出来，尤其适合共享解析器、公共库和数据模型重构。这些修改的目标通常是保持外部行为，允许 Agent 同时重写行为预期，会削弱重构最需要的约束。

但文章没有给出事故复盘材料，也没有对照实验。开头的故障场景不能当成已核实的生产案例，外部验证器能降低多少回归率、增加多少耗时，也没有测量结果。作者称它会让 CI 时间翻倍，更准确的理解是增加两次依赖安装和两次测试执行；实际耗时还取决于缓存、并行度和测试规模。

脚本也只是边界示例。它会执行仓库代码，并不是抵御恶意 Agent 的沙箱。作者建议更强的隔离使用无凭证、网络受限、测试输入不可变的一次性容器。即使做到了这些，缺失的测试覆盖仍然无法靠「全绿」补齐。

实现还有一个需要修正的细节：retry_transient 最多尝试 3 次，把子进程返回码 429、502、503 当作瞬时失败，按 2 ** attempt 等待。但 HTTP 状态码通常不会直接成为命令退出码，这个重试条件不能直接照搬。每次命令的 timeout=600 也只是超时上限，不代表所有项目都适合。

与 Agent 循环内的检查相比，外部验证更容易保留独立证据，但维护和执行成本更高。普通受保护的 CI 也可以承接这种设计，未必需要长期维护另一套验证入口。关键是 Agent 不能随意改动验收输入和规则。对于隔离功能分支、类型覆盖较强的任务，作者认为内部契约检查可能足够；这是经验取舍，文章没有给出证明其充分性的对照数据。

能拿来做什么

• 给共享 Node 解析器或公共工具库安排 AI 重构时，先明确空输入、异常处理和返回值等外部行为，再指定允许修改的实现路径；如果实现与测试混在同一个文件，先解决边界问题。
• 在现有 CI 中分别验证提交基线和候选补丁，使用同一个已提交的依赖安装与测试入口，避免把环境故障误算成 Agent 回归，也避免本地残留产物掩盖问题。
• 遇到 Agent 修改快照或 fixture 来通过测试时，单独审查预期变化的业务依据；确实需要变更契约，就把它作为明确的行为变更验收。
• 比较日常 AI 编程工具时，固定任务和验收条件，同时记录模型、路由、输入 token、缓存与补丁接受情况，让速度和成本都能对应到可接受的结果。