三个 Agent 并行做代码审查：token 涨 2.6 倍，多花的钱在哪

引言

上周把代码审查从单 Agent 改成三个 Agent 并行，安全、性能、可读性各一个。第一版跑完，我先看的不是报告质量，是账单。同一批 40 个 PR，单 Agent 花了 26.4 万 token，三个 Agent 花了 68.9 万。有效发现从 31 条到 37 条，采纳从 24 条到 26 条。多花这么多钱只多捞回两个采纳项，按理说这个方案当场就该死掉。

真正让我停下来的是另一件事。报告里有 11 处结论互相打架，同一个文件同一行，安全 Agent 写建议删除，性能 Agent 写建议保留。人工光裁决这些矛盾就花了 40 分钟。钱的问题可以调参，结构的问题不能。

下面按我踩的顺序讲三个根因，以及最后怎么收口的。

一、先算一笔账

把两次跑的账摆在一起，结论就没有争议了。

• 单 Agent，40 个 PR，26.4 万 token，其中输入 21 万、输出 5.4 万，平均每 PR 6600 token，有效发现 31 条，人工采纳 24 条
• 三 Agent 并行，68.9 万 token，有效发现 37 条，采纳 26 条
• 增量换算，token 涨 161%，有效发现涨 19%，采纳只涨 8%
• 边际成本，每多一条被采纳的问题，多花 3.4 万 token

这个数说明并行本身不是错，错在三个 Agent 里的两个没被真正用起来。安全类的发现几乎全是新增的；性能类有一半和单 Agent 重合；可读性类里有三条是废话，比如把一个变量名从 data 建议改成 payload，而那个变量在上下文里本来就是数据。

换个口径看更清楚。按 PR 数量算单位成本，三个 Agent 是每 PR 1.72 万 token，单 Agent 是 6600，差 2.6 倍。这个数字后来成了老板问我为什么要三倍成本时的标准答案。

顺带说一下为什么是三个而不是五个。分工越细，单个 Agent 看到的上下文越窄，可读性那一路拿一份纯 diff 就够，安全那一路必须带依赖树，两者的输入成本差三倍。五个 Agent 意味着五次上下文装载，token 线性上涨，而发现数的曲线早在第三个分支就平了。三是我试过的性价比拐点。

二、三个 Agent 各写一套字段名，第一次合并就废了

第一版我没定输出 schema，觉得让模型自由发挥更好。结果三个 Agent 高高兴兴各写各的。

• 安全 Agent 输出 vulnerability 对象，字段是 file、line、cwe、severity
• 性能 Agent 输出 issue 对象，字段是 path、line_no、impact
• 可读性 Agent 输出 suggestion 对象，字段是 location、reason

合并脚本按 file 字段做 join，后两个 Agent 的字段根本不存在。运行时没有报错，因为 undefined 也能拼进字符串，最后 34% 的条目落进了一个叫无文件信息的桶里，人工全部忽略。这一条损失比 token 贵得多。

改法是合并前把 schema 定死，用结构化输出约束，字段固定为 file、line、severity、category、finding、evidence 六个。其中 evidence 必须引用原文片段，不接受这里可能有风险这种表述。改完条目落地率从 66% 到 94%，evidence 缺失的条目从 41% 降到 3%。

一句提醒，schema 要写成必填字段加枚举取值，别用自然语言写请尽量结构化。模型对前者服从，对后者客气。

三、第二轮开始全在互相说服，没有人写代码

原始设计是三轮讨论，提出、质疑、收敛。听起来很像那么回事。

实际跑下来，第二轮起输出风格就变了。我统计了我同意、我认为、需要指出这类话术的出现占比，第一轮是 8%，第二轮涨到 47%。同一时间，第二轮的有效新增发现只有 4.6 条，第三轮是 1.2 条。

成本上更难看。第三轮吃掉了全部 token 的 21%，换来 1.2 条发现。把这一轮砍掉，总数从 68.9 万降到 51 万，有效发现只掉了 1 条。

于是定了规则，最多两轮，第二轮只允许对第一轮的条目做反驳或补充证据，不允许新增条目。理由是新增条目该由第一轮的独立视角产生，第二轮的职责是校验而不是再创作。这条规则下去之后，输出里的话术占比回落到 12%，报告也短了一半。

四、没有裁决者，冲突的结论被原样拼进报告

11 处矛盾里最典型的一处是这样的。一个请求参数，安全 Agent 判定未做长度校验存在注入风险，性能 Agent 判定该分支是热路径、任何额外判断都会增加延迟。两边都对，但报告不能同时写建议加校验和建议不要加。

第一版的脚本干的事就是拼接，于是同一份报告里出现了互相否定的两条建议。人看到这种情况，第一反应是不信任整份报告，后面 30 多条正确发现也会被一起怀疑。

修法是加一个只做裁决的 Agent。输入是两个 Agent 的完整 finding 和 evidence，输出三选一，采纳 A、采纳 B、都保留但标注冲突。它不产生新发现，只做判断，所以 prompt 可以写得极窄。

加完裁决环节，人工处理矛盾的时间从 40 分钟降到 12 分钟。裁决 Agent 自己的消耗是 1.8 万 token，占比不到 4%，比人省下来的时间便宜太多。

小结

收口之后定下的三条规矩。

• 分工定死，每个 Agent 只对自己那一类下结论，不写跨类判断
• 回合定死，最多两轮，第二轮只许反驳不许新增
• 裁决权定死，冲突必须由裁决者输出，禁止脚本直接拼接

最终数字，token 从 68.9 万降到 52 万，有效发现 36 条，采纳 27 条，人工裁决时间 12 分钟。相比单 Agent，成本还是贵了一倍，但安全类发现翻了一倍多，这部分值不值，取决于那个仓库的历史漏洞记录有多难看。

多智能体协作最容易犯的错，是把多个模型聊天当成架构。真正的架构是分工、回合、裁决这三件事，聊天只是它的表现形式。