工程经验2026 年 10 月 9 日5 分钟阅读AI Agent · 产品设计 · 工程协作

Agent 改得越快，人该怎样审得过来？

Block 的多仓库迁移案例提醒我们：并行写代码之后，还要设计检查、审核和放行的节奏。真正值得比较的是合格交付，而不是提交数量。

文章目录

代码写好了，为什么任务还没完成？#

假设一个团队要统一修改多个项目中的接口。Agent 可以同时生成很多份改动，但负责人仍需要判断：改动是否符合约定，相互依赖是否处理好，出了问题能不能撤回。

这时，新的问题可能不是“写得够不够快”，而是“已经写出来的东西，谁能及时看懂并接住”。

我的判断是：多 Agent 产品需要把审核当作一种有限的处理能力。增加执行数量之前，先确认检查、人工判断与发布是否跟得上。否则，进度条可能很漂亮，真正完成的工作却没有同比增加。

Anthropic 在 2026 年 10 月 8 日发布了对 Block AI 能力负责人 Bradley Axen 的访谈。其中描述的任务是跨仓库代码迁移：一次迁移可能涉及数百至数千个 PR，也就是提交给团队审核的代码改动。

据受访者介绍，Claude Fable 5 负责整体规划，Opus、Sonnet 等模型执行具体修改和测试；Buzz 工作区帮助人看到协作进度。合并到主分支、生产发布等动作仍由人负责，部署需要两人批准，代码还要经过安全检查。团队也把部分检查放在模型之外执行。

这说明了一种分工方式，却没有证明审核已经不再是瓶颈。原文没有公布人工审核时长、返工率、事故率或完整成本对照。接下来的审核队列与指标设计，是我基于这一案例提出的产品建议，不是 Block 已公开验证的成果。

如果界面只显示“正在执行”和“已完成”，一份测试刚通过、还没有人看过的修改，很容易被误认成已经交付。

我会把下面几个状态分开：正在修改、自动检查未通过、等待人工审核、需要补充说明、可以发布、发布后已确认。状态不必铺满整个屏幕，但负责人需要知道工作卡在哪一步，以及现在该由谁接手。

尤其要区分两种等待：一种是审核人还没空看，另一种是改动缺少证据，根本无法判断。前者需要调整任务量，后者需要让执行者补充材料。把它们混在一起，只会让系统不停催促同一个人。

对审核者而言，一份可接手的结果至少应说明：为什么修改、影响哪些地方、运行了什么检查、哪些情况没有验证。这里的目的不是再生成一篇长总结，而是减少人为了理解一份改动，重新调查整个任务的时间。

先拿一小批范围清楚的任务试跑，比一开始把所有仓库交给 Agent 更容易看出问题。

假设这批任务的自动检查都通过了，但审核者发现它们对同一个接口约定理解错误。此时应该先修改共同的任务说明，回收受影响的改动，再决定是否继续。让每个 Agent 各自重试，可能只是更快地产生同一类错误。

如果检查和审核都稳定，才逐步扩大并行量。扩大之后仍要观察等待时间。等待持续增加时，可以减少同时发出的任务，优先处理阻塞其他工作的变更，而不是把更多未审结果塞进列表。

这不是要求所有任务使用同样重的流程。格式整理与涉及数据结构的迁移，风险不同；检查严格程度、审核方式和放行要求也应不同。具体规则应由团队按业务风险确定，不能从一个客户案例直接照搬。

我会同时记录三组信息，而不只展示生成了多少代码：

这些是待验证的指标，没有预设达标数字。比较旧流程与新流程时，应尽量使用相近难度、相同验收规则的任务；不能拿简单改名任务的速度，替代复杂迁移的表现。

如果提交量上升而合格交付量没有增加，优先分析审核负担与返工原因。如果交付确实加快，但回滚增多，也不能只凭速度宣布成功。

设置一个“批准”按钮并不等于完成了治理。如果审核者看不到关键影响，只能依赖 Agent 自己说“没问题”，批准就很容易变成走过场。

我的产品建议是：高风险动作的权限限制由系统落实；审核界面展示检查证据和未解决问题；拒绝、补充材料与撤回都应有明确去向。模型的解释可以帮助人理解，但不能替代这些控制。

多 Agent 的价值，是让合适的工作并行发生。能否把它变成稳定交付，还要看团队有没有能力及时识别错误、做出判断并接住结果。审核不是最后贴上的一道手续，它本身就是产品流程的一部分。

一手来源： Anthropic《How Block orchestrates Claude Fable across thousands of pull requests》，2026 年 10 月 8 日，受访者为 Block AI 能力负责人 Bradley Axen，未给出发布时刻。
证据范围： 客户访谈；任务规模、系统设置及缺失的审核数据见上文。本文未复现，不能据此推算普遍收益或模型排名。
本文判断： 小批放量、状态划分与审核指标是产品建议，尚未验证业务效果。