Harness Engineering（五）：当 Agent 的产出超过人的注意力

当一个 Agent 每天只提交一项小改动时，现有的 Pull Request 流程通常足以应对。人阅读 diff、运行测试、留下审查意见，Agent 再根据反馈修改。

当多个 Agent 并行搜索、实现、测试并处理反馈时，瓶颈就从代码生成转移到了人工审查。Pull Request 在队列中越积越多，分支冲突不断增加；一些原本正确的改动迟迟无法推进，只是因为没有人及时查看。

在 OpenAI 的 Harness Engineering 实验中，早期三名工程师平均每人每天推动约 3.5 个 PR。随着系统成熟，大部分代码审查逐渐转为 Agent 之间完成。Codex 可以自行读取反馈、修改代码、修复构建失败，并继续推动 Pull Request 直至完成。

但真正值得学习的不是“取消人工审查”，而是另一条判断：

当代码产出速度发生数量级变化，质量控制也必须从统一的人工处理，转向风险分级和系统化验证。

人工审查不应该承担所有质量责任

很多团队把“有人看过”视为安全保证，但人工审查本身并不稳定。改动过大、频繁切换上下文、时间压力和领域知识差异，都会影响审查质量。Agent 生成的改动越多，这些问题就越明显。

更可靠的质量体系应该把不同责任分开：

• 类型、格式、依赖边界由静态检查负责。
• 已知行为由单元测试和集成测试负责。
• 用户路径由浏览器验证和端到端测试负责。
• 性能与可靠性由指标、日志和 trace 负责。
• 反复出现的缺陷模式由专门的审查 Agent 检查。
• 产品取舍、安全边界和不可逆风险由人判断。

这样，人的注意力就不必消耗在机器已经能够稳定完成的检查上，而可以集中处理系统尚无法自动判断的问题。

Agent 之间的审查需要不同视角

只让实现代码的 Agent 在任务末尾“检查自己的工作”，往往只能发现表面问题。它仍然带着设计方案时形成的假设，容易忽略自己从一开始就没有意识到的错误。

OpenAI 明确提到了 Agent 自查和额外的 Agent 审查，但没有规定具体角色。团队在落地时，可以让不同的审查 Agent 分别关注：

• 架构审查 Agent：检查依赖方向、公开接口和业务领域边界。
• 测试审查 Agent：寻找未覆盖的失败路径，以及只适配当前实现的脆弱断言。
• 安全审查 Agent：检查权限、数据泄露风险和不可信输入。
• 产品审查 Agent：对照验收标准检查用户行为。
• 简化审查 Agent：寻找不必要的抽象、重复实现和范围过大的改动。

这些 Agent 不必使用不同模型，关键是为它们设置不同的目标、工具和证据要求。审查结果也不应只是笼统的“看起来没问题”，而要给出具体证据和可以直接处理的反馈。

加快合并之前，先确认系统有能力快速纠错

OpenAI 的案例提出了一个很容易被误用的判断：在代码产出速度很高的系统中，修正问题的成本可能低于等待成本，因此不必让每一次偶发测试失败都无限期阻塞合并。

这只有在一组前提成立时才合理：

• 改动范围小，Pull Request 生命周期短。
• 主分支始终可以部署，回归问题能够被快速发现。
• 测试失败能够区分真实问题和已知偶发问题。
• 回滚或修复成本低，不会造成不可逆外部影响。
• 每次失败都有明确的处理责任，不会留在队列中无人跟进。

支付、权限、数据删除、基础设施迁移等高风险改动显然不适合同一策略。它们需要更严格的人工审批、分阶段发布和恢复方案。

因此，团队不应使用一套合并门槛处理所有改动，而要根据实际风险分级。

风险	典型改动	合并策略
低	文档、内部工具、小范围样式	自动检查和 Agent 审查通过后快速合并
中	普通产品逻辑、可回滚接口	完整测试、运行验证，必要时加入人工审查
高	权限、支付、迁移、删除	强制人工审批、分阶段发布和明确回滚方案

这张三档风险表是本文给出的实践框架，并非 OpenAI 原文报告的合并策略。它想说明的也不是放宽质量要求，而是让审查强度与改动的实际风险相匹配。

Pull Request 应该携带验证证据

在高产出流程中，如果 Pull Request 只有代码 diff，大量理解和验证工作就会被转交给审查者。更完整的任务结果还应该说明：

• 修改解决了什么问题。
• Agent 如何复现原始问题。
• 运行了哪些测试和检查。
• UI、日志、指标或 trace 提供了什么证据。
• 哪些风险仍然存在。
• 是否需要人做出判断。

证据不一定要写成长报告。明确的命令、关键输出、修复前后截图和剩余风险，已经能够显著降低审查成本。

这样，Agent 提交的不只是代码，还包括对“任务已经完成”的证据。审查者不必重新梳理全部背景，只需判断这些证据是否足以支持合并。

自主程度应该逐级提高

团队可以逐步扩大 Agent 在 Pull Request 生命周期中的权限：

1. Agent 创建改动，人负责审查和合并。
2. Agent 自查并回应人类反馈，人决定是否合并。
3. 专门的审查 Agent 提供反馈，人只处理分歧和高风险项。
4. 低风险改动满足检查后自动合并，高风险改动继续交给人。
5. Agent 能发现构建失败、主动修复或回滚，只有在需要人工判断时才请求介入。

每一级都应该有真实数据支持，例如回归率、修复时间、人工介入率、偶发测试比例和回滚成功率。如果这些指标变差，问题不一定是 Agent 不够强，也可能是 Harness 缺少必要的检查、证据或恢复机制。

OpenAI 也特别提醒，这种高度自治依赖其代码库特有的结构和工具，不能在缺少同等投入的情况下直接推广。Agent 应该获得多少权限，要由工作环境已经证明的能力决定，而不是因为模型完成过一次令人印象深刻的演示。

追求最高代码产量不是最终目标。真正的目标，是把人的注意力留给最能创造价值的判断。下一篇将讨论高速生成的另一面：Agent 会迅速复制代码库中的现有模式，包括那些并不理想的模式，因此团队还需要持续控制代码库中的熵增。

本文整理自 OpenAI 的文章 Harness engineering: leveraging Codex in an agent-first world。核心观点来自原文，审查角色、风险分级和分阶段授权是本文的实践延展。

Harness Engineering 系列

• （一）当工程师开始设计 Agent 的工作环境
• （二）给 Agent 一张代码库地图
• （三）让软件运行状态对 Agent 可读
• （四）把工程规则变成可执行约束
• （五）当 Agent 的产出超过人的注意力（本文）
• （六）Agent 也会复制技术债务

相关阅读

• 生产级 Agent 的评估与监控 —— 如何用结果、trace 和评分器判断系统是否真的改进。
• 从个人提效，到 AI 原生团队 —— 当 AI 进入团队流程后，管理对象如何发生变化。