1. 从能跑通到敢上线AI代码审查的真实鸿沟很多团队第一次接触AI代码审查都是从一个简单的提示词开始的。把diff贴进对话框让模型找bug模型确实能说出一些东西甚至偶尔能指出一个空指针或者一个边界条件遗漏于是团队很兴奋觉得这事成了。但真要把这套东西接进CI流水线、让它对每一次PR自动发表评论、甚至卡住合并按钮问题就全冒出来了同一个PR跑两次结果不一样、模型对着无关紧要的命名风格大做文章、真正危险的并发问题反而漏掉、评论里全是建议考虑这种没法执行的废话。我在实际项目里踩过这一整套坑。单提示词方案的天花板非常明显——它本质上是一个一次性问答而代码审查是一个需要多轮推理、多视角交叉验证、还要对结果负责的工程任务。这两者之间的差距不是换个更强的模型或者把提示词写得更长就能填平的。LinkedIn工程团队公开分享过他们在这条路上的探索核心思路是用多智能体Multi-Agent架构把审查任务拆开让不同的agent各司其职再通过一个协调层把结果收敛成可执行的结论。这套思路对任何想把AI代码审查真正推到产线的团队都有参考价值。这篇文章不打算复述某篇论文而是把从提示词到产线这条路径上的关键决策点拆开讲清楚为什么单agent不够、多agent怎么分工、提示词在每个agent里扮演什么角色、结果怎么收敛、以及上线之后那些只有真跑过才知道的坑。适合已经试过基础AI审查、正在考虑工程化落地的开发者、Tech Lead和平台工程师。如果你还停留在贴diff问模型的阶段也能从里面看到下一步该往哪走。2. 单提示词审查为什么必然撞墙2.1 一个提示词要同时干四件互相冲突的事先看一个典型的单提示词审查指令长什么样你是一个资深代码审查员。请审查以下代码变更找出 1. 潜在的bug和逻辑错误 2. 安全问题 3. 性能问题 4. 代码风格和可维护性问题 请给出具体的修改建议。这个提示词看起来合理但它要求模型在一次前向推理里同时完成四种认知模式完全不同的任务。找bug需要的是反事实推理——如果这个变量是null会怎样找安全问题需要的是攻击者视角——输入能不能被构造来绕过校验性能分析需要的是复杂度建模风格检查需要的是规范匹配。这四种能力在模型内部的注意力分配上是互相竞争的结果就是每一样都做得不深。实测下来最典型的表现是模型会把大量篇幅花在风格问题上因为风格问题最容易看起来有内容而真正需要深度推理的并发bug、资源泄漏、边界条件反而被一笔带过。这不是模型能力不够是任务定义本身就把它的注意力稀释了。2.2 上下文窗口的硬约束与注意力稀释第二个墙是上下文。一个中等规模的PRdiff加上必要的文件上下文很容易到几千甚至上万token。单提示词方案为了塞进更多上下文往往要把整个文件贴进去但模型对长上下文的利用效率是递减的——中间部分的信息经常被忽略这就是常说的lost in the middle现象。更麻烦的是当你把diff、文件全文、项目规范、历史评论全部塞进一个提示词模型很难判断哪些信息是当前任务真正相关的。它可能因为看到了某个历史评论里的风格要求就对当前diff里完全无关的代码提出同样的要求。上下文越多噪声越大信噪比反而下降。2.3 结果不可复现同一个PR两次审查结论不同这是最让工程团队头疼的问题。单提示词方案下即使temperature设成0由于上下文组织方式、模型版本、甚至服务端的批处理差异同一个PR两次审查的结果也可能不同。对于要接进CI、要卡合并的审查系统来说不可复现是致命的——开发者会立刻失去信任上次说没问题这次又说有问题到底听谁的这三个问题叠加起来结论很清楚代码审查不是一个问答任务而是一个流水线任务。它需要分解、需要多视角、需要确定性的收敛逻辑。这正是多智能体架构要解决的问题。3. 多智能体拆解把审查任务切成可独立验证的单元3.1 分工原则按认知模式切而不是按文件切很多人第一反应是按文件或按模块来分agent比如agent A看前端agent B看后端。这个切法在代码审查场景下是错的因为一个bug往往横跨前后端按文件切会导致每个agent都只看到局部反而更容易漏掉跨模块问题。正确的切法是按认知模式切。LinkedIn那套思路里审查被拆成了几个职责单一的agent每个agent只负责一种推理模式Agent角色核心职责推理模式输出形态缺陷检测Agent找逻辑错误、空指针、边界条件反事实推理带行号的问题列表安全审查Agent找注入、越权、敏感信息泄露攻击者视角带风险等级的问题列表性能分析Agent找复杂度问题、N1查询、资源泄漏复杂度建模带影响范围的问题列表规范检查Agent检查命名、注释、项目约定规范匹配带规范条目的问题列表收敛Agent去重、排序、生成最终评论归纳与仲裁可执行的审查结论这样切的好处是每个agent的提示词可以写得非常聚焦上下文只需要包含它关心的那部分信息注意力不被稀释输出也更稳定。3.2 每个Agent的提示词该怎么写才不飘分工之后提示词的设计逻辑完全变了。单提示词时代追求全面多agent时代追求聚焦可验证。以缺陷检测Agent为例一个好的提示词应该包含三部分角色约束、输出格式约束、以及明确的不做什么。你是一个专注于逻辑缺陷的代码审查agent。 你的唯一任务是找出代码变更中可能导致运行时错误的问题 包括但不限于空指针解引用、数组越界、未处理的异常、 错误的边界条件、资源未释放。 不要评论代码风格、命名、注释。 不要评论性能问题。 不要给出建议考虑这类模糊表述。 对每个问题必须输出 - 文件路径与行号 - 问题类型从上述列表中选一个 - 触发条件什么输入或状态下会触发 - 置信度high/medium/low 如果没有任何问题输出NO_ISSUES。注意最后那句如果没有任何问题输出NO_ISSUES。这看起来是个小细节但极其重要。如果不加这句模型在没找到问题时也会硬凑几条出来因为它的训练目标倾向于给出有用的回答。明确允许它说没问题能大幅降低误报。3.3 协调层谁来决定哪个Agent说了算多个agent各自输出之后需要一个协调层来收敛。这里有个关键决策是让一个仲裁agent来综合还是用确定性规则来合并我的经验是能用规则的地方绝不用模型。去重、按行号排序、按置信度过滤这些都应该用代码做因为它们是确定性的、可测试的。只有两个agent对同一行代码给出了矛盾结论该信谁这种需要判断的地方才交给仲裁agent。一个实用的收敛流程是这样的收集所有agent的原始输出统一解析成结构化数据文件、行号、类型、置信度。按文件行号问题类型去重同一位置同一类型只保留置信度最高的。按置信度和问题类型排序high置信度的缺陷和安全问题排最前。对矛盾结论同一行一个agent说有bug另一个说没问题调用仲裁agent把两边的理由都给它让它给出最终判断和理由。生成最终评论每条评论必须包含可执行的修改建议不能是建议考虑。这个流程里第2、3步是纯代码第4步才用模型。这样既保证了大部分逻辑的确定性又保留了处理复杂矛盾的能力。4. 提示词工程在多Agent架构里的角色转变4.1 从写一个好提示词到设计一套提示词契约单agent时代提示词工程的核心是怎么把话说清楚让模型理解。多agent时代核心变成了怎么设计一套契约让agent之间的输入输出能对接。每个agent的提示词本质上是一份接口文档它规定了agent接收什么输入、输出什么格式、边界在哪里。缺陷检测agent的输出格式必须和收敛层的解析逻辑严格对应否则整个流水线就断了。这意味着提示词不能再是一段自然语言描述而应该是带schema约束的结构化指令。实践中我推荐用JSON schema来约束输出输出必须是合法的JSON格式如下 { issues: [ { file: string, line: number, type: null_deref | out_of_bounds | unhandled_exception | bad_boundary | resource_leak, condition: string, confidence: high | medium | low } ] }有了schema解析层就可以用标准JSON解析器处理不用写一堆正则去猜模型想表达什么。这一步做扎实后面所有的自动化都顺了。4.2 少样本示例给Agent看什么算好答案多agent架构下每个agent的任务很窄这反而让少样本示例few-shot变得非常有效。给缺陷检测agent两三个输入diff 正确输出的示例它的输出稳定性会有肉眼可见的提升。示例的选择有讲究要覆盖典型的正例和反例。正例是确实有bug正确识别出来了反例是看起来像bug但其实不是正确判断为NO_ISSUES。反例尤其重要因为它是抑制误报的关键。很多团队只给正例结果agent变得过度敏感什么都报。4.3 提示词版本管理产线化的隐形前提这一点经常被忽略但它是产线化的前提。提示词一旦上线它就成了系统的一部分任何修改都可能影响审查结果。如果没有版本管理某天有人改了一句提示词导致误报率飙升你连回滚都不知道回滚到哪。我的做法是把每个agent的提示词当成代码来管理存在版本库里每次修改走review上线时记录版本号审查结果里带上本次审查使用的提示词版本。这样出问题时可以快速定位是提示词变了还是代码变了。5. 把审查接进CI那些只有真跑过才知道的坑5.1 触发时机不是每个PR都值得全量审查一开始我们给每个PR都跑全量多agent审查结果成本和延迟都受不了。后来改成分级触发小改动少于50行且不涉及核心模块只跑缺陷检测agent。中等改动跑缺陷安全两个agent。大改动或涉及核心模块跑全量agent。分级规则用配置文件管理不同仓库可以有不同的策略。这个改动让平均审查延迟从几分钟降到几十秒成本也降了一大截。5.2 误报处理让开发者能一键驳回误报是AI审查最大的信任杀手。开发者看到一条明显错误的评论如果只能手动忽略几次之后他就会开始无视所有AI评论。所以必须给开发者一个一键驳回的入口并且驳回的理由要回流到系统里。我们做了一个简单的机制每条AI评论下面有有用/无用两个按钮点无用时可选原因误报/不相关/已修复。这些反馈定期汇总用来调整提示词和置信度阈值。跑了一个月之后误报率从最初的30%多降到了10%以下。5.3 延迟与成本多Agent不等于无限并行多agent架构天然适合并行但并行不是免费的。每个agent都是一次模型调用全量审查意味着4-5次调用。如果串行跑延迟会累加如果并行跑要考虑API的并发限制和成本。我们的做法是能并行的agent并行收敛层串行。缺陷、安全、性能、规范四个agent并行跑收敛层等它们全部返回后再执行。同时给每个agent设超时超时的agent直接跳过并在结果里标注该维度未完成审查而不是让整个流水线卡住。5.4 结果呈现评论要能直接指导修改最后一步是结果呈现。AI审查的评论如果只是这里可能有空指针开发者还得自己去想怎么改。好的评论应该直接给出修改方向第42行user.getName()在user可能为null时调用会抛NPE。建议改为Optional.ofNullable(user).map(User::getName).orElse()或在调用前加null检查。这种评论开发者看一眼就知道怎么改接受度远高于模糊的提示。生成这种评论需要在收敛层做一步建议生成把agent输出的问题描述转成可执行的修改建议。6. 上线之后持续迭代才是真正的开始6.1 用真实反馈校准置信度阈值上线不是终点。我们跑了两周之后发现medium置信度的问题里真正有价值的不到一半。于是把medium置信度的问题默认折叠只展示high置信度的开发者需要展开才能看到medium的。这个改动让评论区的噪声大幅下降。阈值不是拍脑袋定的而是用真实反馈数据算出来的。我们统计了每条评论的有用/无用比例按置信度分组找到那个有用率明显下降的临界点把阈值设在那里。6.2 定期回看被驳回的评论反推提示词问题被驳回的评论是最好的改进素材。我们每周会抽一批被驳回的评论人工看一遍归类原因是提示词没约束好是上下文给少了还是模型能力确实不够大部分问题都能通过调整提示词或补充上下文解决只有少数需要换更强的模型。6.3 多Agent架构的扩展方向这套架构跑稳之后扩展性很好。想加一个新维度的审查只需要新增一个agent、写好它的提示词和schema、在收敛层注册一下就行不影响现有agent。我们后来陆续加了测试覆盖检查和文档同步检查两个agent都是半天就接进去了。真正难的不是加agent而是保持每个agent的职责单一。一旦某个agent开始顺便也看看别的它的输出质量就会下降整个系统的稳定性也会受影响。这条边界要守住。7. 一些踩坑之后的个人体会多智能体做代码审查最大的价值不是更准而是更可控。单提示词方案像一个黑盒你不知道它为什么这次报了那个问题、下次又不报了。多agent方案把审查拆成了可观测、可测试、可回滚的单元每个agent的行为都能单独验证出了问题能定位到具体是哪个环节。另一个体会是提示词工程在多agent架构里不是变简单了而是变具体了。单agent时代你要写一个什么都懂的提示词很难写好多agent时代你要写四个只懂一件事的提示词每个都容易写好但你要保证它们之间的接口对得上。这是两种不同的难度后者更工程化也更适合团队协作。最后说一个容易被忽略的点别指望AI审查能替代人工review。它的定位是第一道筛子把明显的、机械性的问题挡在前面让人工review能聚焦在架构、设计、业务逻辑这些真正需要人判断的地方。把它当成一个不知疲倦但需要监督的初级审查员心态就对了。
