7 步流水线：验证 AI 代理编写的代码

这是目前最热门的话题。代理每天产出数百次提交，没有人能全部审查。

OpenClaw 的开发者 Peter，有时一天推送超过 3000 次提交。这远超任何人能处理的上限，已经成为一项人类单靠自己根本无法完成的任务。

一开始我以为无解。后来读了 Ryan Carson 的”Code Factory”，思路豁然开朗：与其试图阅读所有代码，不如构建一套由机器来验证代码的结构。

将合并规则写入单一 JSON 文件

把哪些路径属于高风险、哪些检查必须通过，全部写在一个文件里。关键在于，这样可以防止文档与脚本之间出现偏差。

• 高风险路径需要 Review Agent 加上浏览器截图作为佐证
• 低风险路径通过策略门控和 CI 后即可合并

在 CI 之前先跑资格检查

对那些连审查都没通过的 PR 跑构建，纯属烧钱。在 CI 扇出之前加一个 risk-policy-gate，仅此一项就能大幅削减不必要的 CI 成本。

• 固定顺序：策略门控 → Review Agent 确认 → CI 扇出
• 不合格的 PR 根本进不了测试/构建阶段

永远不要信任旧提交的”通过”状态

这是 Carson 最着重强调的一点。如果旧提交的”通过”状态残留，最新代码就会在没有验证的情况下被合并。每次推送都重新触发审查，若 SHA 不匹配则阻断门控。

• Review Check Run 仅在与 headSha 匹配时有效
• 每次 synchronize 事件都强制重新执行

重新运行请求只从唯一来源发出

当多个工作流同时请求重跑时，会产生重复评论和竞态条件。看似小问题，但不解决，整条流水线都会抖动。

• 用 Marker + sha:headSha 模式防止重复
• 若该 SHA 已提交过，则跳过请求

让代理来处理修复

当 Review Agent 发现问题时，Coding Agent 自动打补丁并推送到同一分支。Carson 文章中最犀利的洞察：锁定模型版本。否则每次结果不一致，可重现性就没了。

• Codex Action 修复 → 推送 → 触发重跑
• 锁定模型版本确保可重现性

只自动关闭机器人之间的对话

绝不碰有人工参与的会话线程。没有这个区分，审查者的评论就会被淹没。

• 仅在当前 head 重跑通过后才自动解决
• 有人工评论的线程始终保持开放

留下可见、可验证的证据

如果 UI 发生了变化，光截图不够。要求 CI 可验证的证据。把生产故障转化为测试用例，确保同样的失败不再重演。

• 回归 → 找到测试套件缺口 → 补充测试用例 → SLA 跟踪

Carson 的工具选择

以下是 Carson 选用的工具，供参考：代码审查代理选用 Greptile，修复代理选用 Codex Action，三个工作流文件各司其职：greptile-rerun.yml 负责标准重跑，greptile-auto-resolve-threads.yml 负责过期线程清理，risk-policy-gate.yml 负责预检策略。

正确性之外：视觉验证

以上步骤都是在检查代码逻辑对不对。但实际上，还需要验证输出呈现的样子。

有两种方案值得关注。

Nico Bailon 的视觉说明器将终端 diff 渲染成 HTML 页面，而非 ASCII 字符，让变更集一眼就能看明白。

Chris Tate 的代理浏览器走的是另一条路。它逐像素对比真实浏览器截图，捕捉 CSS 和布局的异常。结合 bisect，可以精确定位到底是哪次提交引入了回归。

我在构建 codexBridge 的过程中一直在思考这个问题。仅靠会话日志来追踪哪个代理写了哪段代码是不够的，需要一套便于检索的搜索结构。

结语

“谁来验证代理写的代码”这个问题，答案不是人类，而是一套让机器来判断机器所产出的证据的结构。这就是答案。