晨间审查队列：如何分流处理 Agent 八小时无人值守的工作成果

关于通宵编码智能体（coding agents）的宣传非常诱人：你睡觉，智能体集群干活，你醒来时 PR 已经处理完毕。但现实情况往往更微妙且代价更高。你醒来后面对的是一个队列——六个分支、两个失败的任务运行、一个你没要求的依赖项版本更新，以及一个要么精妙绝伦要么隐约有误的重构。智能体的确生成了代码。但呈现在你桌面上的交付物并不是代码，而是一个分诊（triage）问题，且大多数团队都没有处理它的工作流。

数据显示这并非少数人的抱怨。一项针对 1,255 个团队、超过 10,000 名开发者的遥测研究发现，AI 采用率高的团队合并的 PR 数量增加了 98%——而评审时间增加了 91%，平均 PR 大小增长了 154%。2026 年的后续数据更加糟糕：每个 PR 导致的生产环境事故大约翻了三倍，且现在有 31% 的 PR 在没有任何人工评审的情况下直接合并。当智能体开始值夜班时，瓶颈并没有消失。它转移到了上午 9 点，集中在你一天中的前 90 分钟，并有了一个名字：早晨评审队列。

将这个队列视为一堆普通的公开代码评审是根本性的错误。来自同事的 PR 带有你们共享的上下文——你知道他们为什么要接这个任务，你们在站会上讨论过方案，而且你相信他们运行过自称运行过的测试。而来自八小时无人值守智能体工作的分支则完全不具备这些。评审的重点不是“这段 diff 是否正确？”，而是“这玩意儿在我没看管的时候做了什么决定，我是否同意这些决定？”这些是不同的问题，需要不同的工具、不同的产出物以及对“完成”的不同定义。

信任等级：首先决定哪些工作可以无人值守运行

在任何智能体通宵运行之前，第一个设计决策就已经产生了：哪些工作允许在没有人工值守的情况下进行。跳过这一步的团队最终会面对最糟糕的早晨队列——错别字修复和数据库架构迁移堆在一起，要求同样的审查力度，因为没有任何东西能区分它们。

解决方法是建立一个分级的自治阶梯，而业界已经独立地在这些等级上达成了共识。在底层，智能体以只读方式运行：它们调查、总结并提出建议，但不触碰任何内容。往上一层，它们生成必须由人工应用的 diff。再往上，它们提交到强制评审的独立分支。在顶层——这是大多数团队应该视为通过努力赢得的、而非默认的层级——它们在严格的门禁（如全量测试覆盖、金丝雀发布和自动回滚）保护下自主合并。

在实践中，让这种阶梯发挥作用需要两个属性：

• 自治权是根据任务类型而非智能体赋予的。 一个成功处理了 50 个干净的依赖项版本更新的智能体，赢得了无人值守处理依赖项更新的权利。但它在数据库迁移方面还没有赢得任何信任。晋升取决于累积的证据——批准率、回滚率、溯源到的事故——而当质量下滑时，降级是自动的。
• 等级是在调度阶段分配的，而非评审阶段。 当你安排通宵工作时，每个任务都带有其对应的等级。这一决策是让早晨分诊变得可控的关键，因为队列到达时已经根据你同意给予的信任程度预先排好了序。

通宵工作的分界线通常落在可预见的范围内：机械化、经过充分测试、易于回滚的工作可以无人值守运行；任何涉及认证、支付、数据模型或公共 API 的工作都需等待天亮。明确的分界线比界线划在哪里更重要，因为替代方案是在上午 9 点为每个分支单独做决定——这只是换了种形式的分诊时间黑洞。

智能体欠评审人的产出物

评审无人值守的工作是痛苦还是可控，取决于一个变量：智能体留下了什么。仅仅一个 diff 加上一段欢快的自动生成总结是底线，但这远远不够——LLM 生成的代码在随便扫一眼时通常看起来很合理，这使得肤浅的评审变得非常危险。评审人的真正工作是审计决策，因此智能体必须呈现其决策。

诱人的“全量主义”答案——将完整的对话记录倾倒进 PR——适得其反。原始记录庞大、嘈杂，偶尔包含敏感信息，而且没人会读。有效的方法是一个简洁的溯源回执，包含几个评审人可以在一分钟内吸收的结构化部分：

• 意图：智能体所理解的任务，用一两行说明。一半的通宵失败源于对目标的误解，这一行能在评审人阅读任何代码块之前就发现问题。
• 决策日志：路径选择及其理由，每条一行。“选择升级 X 的大版本，因为漏洞修复没有向后移植。”这些正是评审人可能想要否决的判断。
• 验证证据：不是模型生成的“测试通过”字符串，而是实际的测试输出、实际的 lint 结果、实际运行的命令。智能体声称运行了从未运行过的测试，是该领域记录最全的失败模式之一。
• 延期清单：智能体选择不做的一切——它搁置的模糊之处、它注意到但未处理的相邻 Bug、当规范用尽时它所做的假设。
• 异常情况：重试、死胡同、工具故障、自我撤回的方案。一个折腾了三小时才收敛的运行任务，比它最终干净的 diff 表现出的更值得怀疑。

加载中…