多Agent协作查Bug：代码审查发现问题数从27提升到66的实践

1. 先讲清楚：我为什么把单Agent查Bug改成“组队查Bug”

先说结论：在11.6万行代码的模拟项目X上，让Claude以单Agent模式跑全量代码审查，表现最好的一次找到了27个Bug；而我让Claude自己组队、按模块分工协作，最终挖出了66个Bug。这个差距不是一两个漏网之鱼的问题，而是查Bug这件事本身在单兵作战模式下的天花板。

以前我处理中大型代码库的Bug排查，习惯做法是直接把整个仓库丢给一个AI助手，让它“帮我把所有潜在问题找出来”。在几万行以内的小项目上这招确实好使，两个小时内就能拿到一份像模像样的报告。但代码量一旦过了10万行，事情就开始变味：单个Agent的上下文窗口会被塞满，它只能跳跃式读取文件，后半程明显出现“注意力疲劳”——前面看过的文件里能发现的问题，到后面就不再提了；同一个Bug被重复报好几次，真正新的发现反而越来越少。

这个现象本质上可以类比成一个人连续审12个小时代码，到后半段眼睛在扫、脑子已经不转了。人受限于精力，Agent受限于上下文和注意力分配。多Agent协作的思路很直接：既然一个大脑干不动，那就拆给多个大脑并行干，每个Agent只看一小块代码，把深度做上去，然后再有一个角色做汇总交叉验证。这其实就是团队里peer review的常规做法，只不过这次把“人”换成了“Agent”。

这篇文章是做这个实测的全过程记录，包括我如何设计Agent角色、如何切分任务、如何统一输出格式、成本多少、踩了哪些坑。适合正在做AI辅助代码审查、想评估多Agent架构到底值不值得上的人参考。我不打算只贴一份“某某报告”，而是把整个可复现的方案拆给你看。

2. 单Agent基线先跑明白：27个是天花板还是偶然

我先把模拟项目X的情况交代一下。这是一个虚构的、约11.6万行代码的业务系统，Go语言为主，夹杂少量Python脚本和SQL迁移文件，共有800多个源文件，涉及用户认证、订单处理、库存同步、支付回调、定时任务、消息队列消费等模块。它不是那种杂乱无章的玩具项目，代码里有完整的目录分层，也有大量真实业务中常见的坏味道——重复代码、错误处理被忽略、并发竞争条件、资源未释放、配置硬编码等。

第一步先跑单Agent基线。我用同一个Claude对话实例，把整个代码仓库的路径、目录结构、所有源文件列表一股脑塞进上下文，然后给出统一的审查指令：“请分析该仓库全部代码，定位潜在Bug，按严重程度分级并给出文件行号与修复建议。”这一轮我跑了三遍，为了排除随机性。三次结果分别是找到22个、25个、27个Bug，27个是最好成绩。

这27个里，按严重级别分的话：严重（会导致崩溃、数据不一致、安全问题）8个，中等（逻辑错误、边界条件未处理）12个，轻微（资源泄漏、错误日志缺失、死代码）7个。看起来挺全面，但如果你真实维护过一个10万行级别的代码库，就会知道这个数字低得可疑。一个800文件的仓库，全量人工code review通常能拉出上百个问题列表，严重问题也不止个位数。单Agent能达到27个，说明它的确在认真看代码，但明显没有覆盖到全局。

我复看了一下三次单Agent运行的对话记录，发现两个规律。第一，它对项目中部和后部的文件明显查得粗，尤其是消息队列消费这块，三次运行都只报了1到2个问题，而实际上这个模块是我埋Bug比较密集的地方。第二，有些Bug它其实“看见了”但没有识别出来——比如某个函数里用了defer关闭资源后又手动close了一次，它判断为“冗余操作”而不是Bug，事实上第二次close会返回错误且可能导致状态机错乱。这种“看见了但没意识到是问题”的情况，是单Agent模式最大的盲区。

基线的结论很清楚：单Agent模式适合快速摸底，但深度和覆盖率都不够。要在11.6万行这种量级上拿到更完整的问题清单，必须换方案。

3. 组队方案怎么落地：我让Claude自己设计角色分工

既然决定走多Agent路线，第一步不是我自己硬编一个“主查”“复审”“汇总”的流程扔给Claude，而是先让它基于这个仓库自己提出团队设计方案。我给的原始提示词大致是这样的：

你是一名资深技术负责人。我准备对一个约11.6万行Go代码的仓库做全量Bug审查。 请设计一个多Agent协作方案：需要哪些角色、各自负责什么、任务如何切分、 如何避免重复劳动、最终汇总格式是什么。请给出你认为最优的分工。

Claude给出的方案经过我微调后，形成了最终执行配置：

这里最关键的决策是“角色分工让Claude自己提”。为什么这么设计？因为我自己预设角色很可能夹带个人偏见，比如我习惯按“数据层、业务层、接口层”去切，但Claude对代码库的全局认知是基于目录结构、函数调用关系、依赖方向综合判断的，它切出来的模块边界往往更贴近真实耦合度。实测下来，Claude提议的切分方式是按业务域走（认证域、订单域、库存域、支付域、消息域），每个域带上一部分公共基础库代码。这个划分比我自己拍脑袋的按层划分更合理，因为Bug往往是跨文件调用链上冒出来的，按业务域切分能让每个主查Agent持有完整的一条业务链路。

任务切分的细节也得说清楚。800多个源文件不能平均分配，否则一个简单配置目录和一个高复杂度消息队列模块的工作量完全不对等。我把文件列表交给总协调者，让它依据文件大小、依赖数量、历史改动频繁程度（我用git log统计了每个文件最近100次提交的改动次数）给文件打分，高分文件优先分配，每个主查Agent的文件数量控制在80到130个之间，力求工作负载均衡。

还有一个容易被忽略的设计：交叉复审不是把所有模块都复审一遍，那样成本直接翻倍甚至翻三倍，而是只挑“高风险区”。哪些算高风险？我定义了三条规则：一是与外部系统交互的文件（HTTP回调、RPC调用、消息写入）；二是涉及并发或状态共享的文件（goroutine、channel、带锁结构体）；三是主查报告中单个文件问题数排名前20%的文件。这三类区域多一个人看，哪怕只看一遍，也能拦下不少漏网的严重问题。

4. 实测跑完后：66个Bug到底是怎么被挖出来的

整个多Agent执行跑下来，总协调者输出的最终报告里列了66个独立问题。我先给出整体对比数据：

这里有个数据值得单独拎出来说：单个主查Agent平均只找到7.3个问题，远低于单Agent的27个。如果纯看“单个Agent的效率”，多Agent模式是退步的。但66的总数摆在那里——它靠的是“分工后每个Agent只盯着自己那一亩三分地，看得更细”，再加上交叉复审和汇总复核阶段又各自捞回来一批，最终把覆盖率拉上去了。

66个Bug按发现来源拆一下，就更能看出组队查Bug的真实收益结构：

• 模块主查Agent直接发现：41个，占62%。
• 交叉复审Agent补充发现：15个，占23%。这里面有10个是主查完全没碰到的文件里暴露的问题，5个是主查看过但判断成“非Bug”的问题。
• 汇总复核Agent合并时发现：10个，占15%。这个数字是最让我意外的——汇总阶段本来只负责去重合并，居然还能额外还原出一批Bug。原因是各主查在描述同一个跨模块问题时各写了一部分，单独看每个描述都不完整，但在汇总复核时，两个不完整的描述拼在一起，让问题的全貌突然清晰了。

66个Bug按类型分布：

多Agent不仅数量上赢了，还在“单Agent完全错过的类别”上有明显优势。比如跨模块耦合Bug，单Agent因为上下文跳跃读取，很难同时把一个调用方的逻辑和被调用方的实现完整关联起来；但按业务域切分后，主查Agent天然持有一整条调用链，这类问题很容易暴露。再比如并发竞争，单独看一个函数通常看不出问题，必须结合完整的读写路径才能确定。

5. 为什么多Agent能找到单Agent漏掉的Bug：三个核心机制

第一个机制是上下文隔离。单Agent模式下，整个仓库的代码都是它的“即时上下文”，但它实际能同时保持深度理解的代码可能只有几百行。看到800个文件时，很多文件只是在过场，根本没有进入深度推理圈。多Agent模式下，每个主查只看80到130个文件，上下文压力小一个量级，它能对每个文件逐行咀嚼，甚至回头重新打开之前看过的文件做二次核对。深度和广度不可兼得，多Agent相当于用“人海战术”把“广度”拆散成多份“深度”。

第二个机制是交叉复审的对抗式纠偏。单Agent审查时，它对代码会形成一种“作者的直觉”——看多了某段代码后，会把一些明显不合理的地方合理化，比如“这个变量名虽然叫config，但函数里明显在当临时容器用，可能是有意设计”。这种自我合理化在人工Code Review里也常见，审自己写的代码永远比审别人的代码更容易漏。交叉复审Agent没有这层“作者滤镜”，它拿到的是别人的审查结论和原始代码，天然用挑剔的眼光找不一致。实测中那15个被补充发现的Bug里，有5个就是主查写了“此处逻辑无误”但复审Agent认为存在隐患并给出反证。

第三个机制是汇总复核的信息拼图效果。前面提到的10个“汇总阶段新增Bug”本质上是因为各主查对同一个问题各持一半证据。比如有一个数据库死锁隐患，订单域主查看到的是“事务A持有连接后未及时提交”，支付域主查看到的是“事务B在等待一张被事务A持有的表锁”，两个报告各自成立但都不是完整问题。汇总复核Agent在合并时把这两段描述放在一起，才意识到这是同一个死锁场景的两侧视角，补充成一条完整的严重Bug。

还有一个不太容易量化的因素：随机性带来的多样性。单Agent跑三次，三次查到的问题集合重合度超过七成，基本上是在同一片区域反复打转。多Agent模式下8个主查Agent各自独立跑，每个Agent的有效注意力和推理路径都不一样，相当于8个不同背景的人在同时审，问题集合的多样性显著增加。多样性本身就是覆盖率的一部分。

6. 代价与适用边界：不是所有代码库都值得上多Agent

先算一笔实账。这次全量审查的token消耗约5800万，按API价折算大约是几百元的量级；耗时3小时左右（并行调用下各Agent同步推进，实际墙钟时间并不长，主要是汇总复核阶段消耗较多）。单Agent模式token消耗约420万，耗时45分钟，成本只有多Agent模式的十分之一。如果只是例行检查一个小型工具库或者临时排查几个严重Bug，多Agent方案显然是杀鸡用牛刀。

什么情况值得上多Agent？我给自己定了一个筛选规则：

我在模拟项目X上之所以值得跑多Agent，核心判断依据是“这是交付前的一次全量体检”，且代码量过了10万行。在这种场景下，多花几十分钟时间和几百元token成本，换来的是问题发现率直接翻倍，ROI非常高。但如果你是一个没上线的个人项目，只是想粗略看看有没有明显Bug，单Agent完全够用了。

我个人的经验判断是：多Agent很适合作为“阶段性质检工具”在关键节点启动，而不是日常每次提交都跑。日常小检查用静态分析工具加单Agent，一周跑一次深度体检用多Agent，两者搭配，成本和覆盖率都能兼顾。

7. 真正落地时容易翻车的细节：我在这次实测里踩过的坑

第一个坑是并行调用的限流问题。多Agent方案执行初期，我并行启动了8个主查Agent，瞬间把API调用频率拉满，结果触发限流，多个Agent中途退化成半翻译半生成的状态，输出质量明显下降。解决方法是给每个Agent加人为错峰：启动时间延后15秒到1分钟不等，并限制同时间最多4个Agent在跑。这个细节直接影响结果稳定性，建议做多Agent的人一定要在编排层设计好并发上限，别一股脑全开。

第二个坑是输出格式五花八门。虽然我在每个角色提示词里都规定了“按表格输出、字段含文件路径、行号、严重级别、问题描述、修复建议”，但实际跑完，8个主查Agent的输出格式还是各有各的脾气：有的用列表，有的写成长段落，有的把文件路径写得简略到无法直接定位。这给汇总复核Agent造成了额外的解析负担。后来我在总协调者的提示词里加了一条“所有子Agent输出必须使用Markdown表格，文件路径必须完整，不许用缩写”，问题才基本收敛。实际执行中，格式规范不能只在初始提示词里写一遍，最好在派发任务时重复一遍，或者直接给一个模板样例，让Agent照着填。

第三个坑是“信誓旦旦的误报”比想象中多。多Agent模式因为每个Agent对代码的理解深度更高，反而更容易产出一类看起来很专业的误报，比如把某个刻意设计的补偿逻辑当成Bug、把兼容历史数据的字段判成类型错误。汇总复核Agent并不总能识别这些误报，因为它只看到最终合并后的描述，看不到Agent推理时的原始依据。我做了一轮人工抽检，发现66个报告里大约有8个属于误报或重复归类。如果你直接把这66条全部交到开发手里去修，那会浪费不少时间。所以多Agent产出的报告，必须保留“人工终审”这一步，我最后实际交付给修Bug环节的清单是58个确认真实问题。

第四个坑是提示词版本混乱。这次实测里我改了4版提示词：第一版角色定义太宽泛，导致主查Agent倾向“宏观总结”而不是“逐行找Bug”；第二版加了输出格式要求，第三版加了“宁可多报不可漏报”的倾向性指令，第四版才达到理想状态。改提示词最麻烦的是你不知道哪一版改动导致了哪个结果变化，所以我每跑一版都会把原始提示词和输出报告一起存档，方便回溯。建议如果有条件，固定一个基线提示词之后，用Git管理这些prompt版本，每次只变一个变量。

还有一些小的实用技巧，顺手分享一下：

• 单Agent助手的“发现数量”和“提示词里要求的严格程度”强相关。我在做基线时，分别用“请审查代码”和“请审查代码，宁可误报也不漏报，把每个可疑点都列出来”跑过对比，后者的产出数量能多40%左右。这个指标值得在跑多Agent之前先测一次。
• 按模块切分时，把测试文件单独拎出来不给主查Agent，让它们专注业务代码，不然它们会把大量注意力花在测试用例本身写得规不规范上，浪费上下文。
• 汇总复核阶段的提示词里一定要写明“两条报告如果指向同一段代码或同一个调用链，必须合并”，否则同一个跨模块Bug可能以两三条的形式出现在最终报告里，数字虚高，误导统计。

8. 留个心法：多Agent不是自动化的终点，是“更认真看一遍”的起点

这次在模拟项目X上跑出来的66个Bug，比我预想的多，也比单Agent基线的27个多很多。但我不打算把话说满——多Agent并不能保证把所有Bug都找出来，它只是把覆盖率推到了一个工程上更可用的水平。你在真实的团队协作里见过“三个开发者交叉审一个模块”有多强大，就能理解这个结果；反过来，三个高效的开发者也可能同时漏掉同一个隐蔽问题，多Agent同样如此。

我个人的实操体会是，多Agent方案最大的价值还不是那66这个数字，而是它改变了“AI查Bug”这件事的工作方式：从“一个全能AI做全量扫描”变成了“一队专业AI分域深挖、相互对账”。后者更接近真实团队的质量保障流程，也更容易在各个环节介入人工审核。它让你在代码量越来越大的项目里，仍然对代码质量保持掌控感。

如果你也想在自己负责的仓库上跑一次多Agent查Bug，我的建议是别一上来就追求复杂编排，先拿一个中等大小的模块做小规模试点，一个主查配一个交叉复审，让它俩跑一遍，看看额外捞回来的Bug到底值不值那些token和时间。试完再决定要不要把整个仓库铺开。多Agent这套打法有没有用，最终还是要看你手头的代码库和你要守的质量底线。