AI时代人审才是瓶颈？给并行 Agent 设计一套能扩展的审查流程

第一次同时跑三个编程 Agent 时，执行就不再是慢的那一环了。你把一个 bug 交给 Claude Code，把一次重构交给 Codex，把测试覆盖的缺口交给第三个 Runtime，四十分钟后三个分支都准备好了。然后真正的等待才开始，因为这三份结果现在都在等你。你读完第一份 diff、点了通过，另外两份就干等着。执行是并行的，审查是串行的，所以并行几乎没带来任何收益。

这是每个把并行 Agent 跑顺的团队都会踩的坑。瓶颈不会消失，它只是换了位置：从「Agent 写代码有多快」变成「人读、判断并接受结果有多快」。再加第四个 Agent 只会更糟：完成的工作排得更长，审查的人还是那一个。

解法不是审得更快，也不是更信任 Agent。解法是把审查当成工作流里一个明确设计的环节，而不是留在你脑子里的收尾动作。这篇文章讲的就是这套工作流，也是 HiFox 围绕的问题：把每次 Agent 运行的目标、diff、证据和审查都留在同一个任务里，让审查队列变成看得见、管得住的东西，而不是一堆打开的浏览器标签页。

为什么并行 Agent 会把瓶颈推到审查

审查是一条队列。完成的 Agent 运行按某个速率到达，人按某个速率清理，一旦到达速度超过清理速度，队列就会无上限地变长。事情就这么简单，也正是为什么「Agent 原始吞吐量」是个错误的优化指标。如果十个 Agent 一小时内完成，而你一小时只能认真接受三个改动，那你建的是一座装卸口只有一个拿夹板的人的工厂。

大多数工具把这件事藏起来了。一堆 pull request 能让你看到工作，却看不出哪些是真的在等决定、哪些还在跑、哪些已经合并。队列是真实存在的，只是散落在标签页、通知和记忆里。第一个设计目标就是让它可见，因为你看不见的瓶颈管不了。另有一篇讲审查容量怎么算的文章，推演了并发升高之后会发生什么。

运行模型：谁派活、谁执行、谁审查、谁验收

在动状态字段之前，先把四个角色说清楚。它们是不同的工作，把它们混在一起，审查就会显得混乱。

有人派活：把一句意图变成范围明确、带验收标准的任务。有东西执行：一个 Agent，在一台电脑上，在一个 Runtime 里跑，产出改动和一份它做过什么的记录。有人审查结果：读 diff 和证据，判断是否满足标准。有人验收：决定合并和发布，这和「代码看着没问题」是两个不同的决定。

HiFox 把这份契约浓缩成一句话，值得贴在便签上：Agent 负责调研、执行、测试和汇报；人负责定方向、授权和验收结果。自动化停在做团队判断的地方。派活和验收按设计由人来做，执行归 Agent。审查则是必须被工程化的那一环，因为队列就是在这里形成的。

一条有用的边界：合并的 PR 不等于被验收的结果。合并是一个 git 操作。验收是人判断这个改动是否完成了任务要求。当这两件事被压成一次点击，审查质量就掉到审查者那一刻还剩多少精力。

角色、状态和审查关卡

给队列一个形状：让任务只有少量状态，Agent 和人在这些状态之间移动。任务是工作的基本单位，装着目标、对话和运行记录。状态的意义在于：Agent 可以把任务推进到审查关卡前，但只有人能把它推过去。

关卡就是进入「待审查」以及从「完成」离开的那道转换。Agent 可以自己走到关卡前，但不能越过它。就这一条规则，让你能安全地同时跑十个 Agent：它们并行地把「待审查」这一列填满，你按能保证质量的节奏把它清空。这一列的长度就是你的瓶颈，被摆在了明面上。

这里有一组诚实的判断：凡是会交付给用户、或者涉及金钱、鉴权、数据迁移、公开 API 的改动，都要设关卡。用完就丢的验证性代码、反正要重新生成的样板代码、或者藏在还没人能访问的开关后面的工作，不用设。给所有东西都设关卡，只会把瓶颈推回到审查者身上，去审那些本来不需要人看的改动。另有一篇讲审批关卡的文章，讨论了高风险工作该把停止点放在哪里。

把审查设计成可扩展的

审查并行 Agent 的产出，和审查同事的 PR 不是一回事。你要审的更多、它是成批到来的，而且你往往更不清楚它是怎么做出来的。有三个动作能压低每一条的审查成本。

把证据附在任务上，而不是留在记忆里。一次运行应该返回改动摘要、typecheck 和测试输出、构建结果以及已知限制，全部留档。当你打开一条「待审查」时，你读的是一份案卷，而不是在脑子里复原刚才发生了什么。这就是用任务级证据做审查和自己重跑一遍来重建信任的区别。

审决定，不审击键。机器能验证的属性——格式、类型安全、测试是否通过——应该在任务送到你面前之前就由机器把住。Google 的代码审查指南也是这个分工：把工具能验证的部分自动化，让人把注意力放在设计与契合度上。你稀缺的判断力应该用在「这是不是正确的改动」，而不是「它编译过了吗」。

限制在制品数量。对同时处于「进行中」的任务设一个硬上限，能防止「待审查」那一列变成你永远翻不过去的墙。这就是把看板 WIP 限制用到 Agent 上：已经有五个在等你，还开第六个，不会增加吞吐，只会把队列藏起来。顺便也建议监控正在运行的 Agent，这样在它到达关卡之前，你能分清是卡住了还是只是慢。

一个完整例子：从工单到合并的 PR

拿一个像真的一样的任务，SH-312：「给公开搜索接口加限流」。人在待办里把它写清楚，附上验收标准（每个 key 每分钟超过 N 次请求后返回 429、有文档化的响应头、有测试），然后移到「就绪」。

三个 Agent 正在这个空间里并行工作。其中一个领走 SH-312，把配置好的仓库克隆到一台电脑上，在独立的 worktree 里运行，这样它的分支永远不会和另外两个在跑的运行撞车。它写出限流器，补上测试，跑 typecheck 和测试套件，开一个标题里带任务 ID 的 PR，然后把 SH-312 移到「待审查」，附上改动摘要、通过的测试输出，并标注一个已知限制：计数器是进程内的，没有跨实例共享。

你打开的是任务，不是十五个标签页。证据就在那里，而那条已知限制的备注才是有用的部分：测试过了，但跨实例共享状态是一个需要你来做的设计决定。你留下评论，把它移到「要求修改」。这条评论会在同一个任务上启动一次后续运行；Agent 把计数器换成共享存储，返回更新后的证据。这一次你接受了。把 SH-312 移到「完成」是你的决定，会作为一次带你名字的状态变更被记录下来，而不是 git 合并的静默副作用。

与此同时，另外两个 Agent 正停在「待审查」。因为队列是一列而不是你的收件箱，你接下来按顺序清掉它们，不会丢线索。

留给人来做的那条线

并行 Agent 一直是个吞吐量的故事，直到审查成为约束，它才变成排队的故事。真正从多个 Agent 里拿到价值的团队，会把审查当成需要设计的基础设施：明确的状态、Agent 能到但不能越过的关卡、任务上的证据、先机器检查再人检查，以及一个在制品的上限。

你可以用 worktree、分支命名约定和纪律自己搭这套东西。也可以让 HiFox 来管这套工作流：可指派的 Agent、承载运行和证据的 任务，以及一块把「待审查」当作一列来清空的看板，让 Agent 去调研、执行、测试和汇报，而人保留最后一个决定。如果你已经在跑多个 Agent，这就是一个管理它们任务和结果的地方，而不是靠记忆。

常见问题

如果审查是串行的，并行跑 Agent 还省时间吗？ 只在完成的运行到达速度还没超过你能接受的速度之前省。超过之后，多出来的 Agent 只会让审查队列变长，不会让东西更早发出去。收益来自让审查可见，并且只给真正需要人看的改动设关卡。

每个 Agent 的改动都要人审吗？ 不用。会交付给用户、或者涉及鉴权、数据、金钱、公开 API 的改动要设关卡。低风险或者可以重新生成的工作，用机器检查放行就可以。什么都设关卡，只会把瓶颈推回到那些本来不需要人审的改动上。

合并 PR 不就是验收了吗？ 不是。合并是一个 git 操作；验收是人判断这个改动是否满足任务标准。在高吞吐时把两者分开，才能保住审查质量。另有一篇讲 human-in-the-loop 编程 Agent 的文章，讨论了人应该在哪一步保留决定权。