1. 从提示词到产线为什么代码审查需要多智能体代码审查这件事做过几年开发的人都有体会——它从来不是“看一眼代码有没有语法错误”这么简单。一个合格的审查者需要在几分钟内同时完成好几件事判断这段逻辑是否覆盖了边界条件、命名是否表意清晰、有没有隐藏的性能陷阱、是否违反了团队约定、测试用例是否充分、以及最容易被忽略的——这段代码三个月后别人还能不能看懂。人类审查者做这些事靠的是经验积累和上下文直觉但人有个致命问题会累、会漏、会碍于情面放水。LinkedIn 工程团队搞的那套多智能体代码审查系统本质上就是在解决这个“人会累”的问题。他们不是简单调一个 API 让大模型看看代码而是把审查这件事拆成了多个角色每个角色有自己的提示词、自己的关注面、自己的输出格式最后再汇总成一份可操作的审查意见。这套思路在业内通常被称为“多智能体协作”但落到代码审查这个具体场景里它其实更像是一个流水线上的质检工位——每个工位只盯一个维度但合起来覆盖了整条产线的质量要求。我最初接触这个方向是在一个十几人规模的研发团队里当时我们尝试用单模型做代码审查效果很不稳定。同一个 PR有时候能挑出空指针风险有时候连明显的资源泄漏都视而不见。后来分析原因才发现单模型在面对长 diff 时注意力会被稀释而且“审查代码”这个提示词本身太宽泛模型不知道优先看什么。LinkedIn 这套多智能体方案给我的启发是与其让一个模型做所有事不如让多个模型各做一件事每个模型的提示词都收窄到具体维度输出也结构化最后用规则或另一个模型来汇总。这套方案适合谁来参考我认为三类人最值得看一是正在搭建内部代码审查工具链的工程效能团队二是想用 AI 辅助自己 review 代码但不知道怎么设计提示词的普通开发者三是做 AI Agent 编排、想了解多智能体在真实产线怎么落地的人。它不要求你一开始就上全套基础设施哪怕你只是在本地用几个提示词模板手动跑一遍也能感受到“分维度审查”和“一锅炖审查”的差距。2. 多智能体拆解每个角色到底在干什么2.1 为什么不是“一个超级提示词”搞定所有事很多人第一反应是我写一个超长的提示词把命名规范、安全漏洞、性能问题、测试覆盖全列进去让模型一次性输出不就行了我试过结论是——在短 diff 上勉强能用一旦 diff 超过两三百行模型就开始“选择性失明”。这不是模型能力问题而是注意力机制和上下文窗口的固有特性。你把十个维度的要求塞进一个提示词模型在生成时会在这些维度之间来回跳跃最后每个维度都只覆盖了一部分。LinkedIn 的做法是把审查维度拆开每个维度对应一个独立的智能体。常见的拆分方式包括逻辑正确性审查、安全性审查、性能与资源审查、可读性与命名审查、测试覆盖审查。每个智能体拿到的是同一份 diff但提示词完全不同。逻辑审查的提示词会强调“找出边界条件遗漏和状态不一致”安全审查的提示词会强调“检查输入校验、权限判断和敏感数据暴露”性能审查则会关注“循环内重复计算、不必要的内存分配、N1 查询”。这种拆分的核心优势在于每个智能体的提示词可以写得非常具体甚至可以附带该维度的检查清单和反例。比如安全审查智能体的提示词里可以直接写“如果看到字符串拼接 SQL必须标记为高风险如果看到用户输入直接拼进命令必须标记为严重”。这种具体程度在单提示词里是做不到的因为会和其他维度的要求互相干扰。2.2 智能体之间的协作模式并行还是串行拆成多个智能体之后下一个问题是怎么组织它们。LinkedIn 的方案里我观察到两种模式并存并行审查和串行审查。并行是指所有智能体同时拿到 diff各自独立输出审查意见最后汇总。串行是指前一个智能体的输出会作为后一个智能体的输入比如先做逻辑审查再把逻辑审查的结论交给安全审查做二次判断。并行模式的好处是快适合在 CI 流水线里做第一道过滤。串行模式的好处是深适合在合并前做最终把关。实际产线里通常是混合的并行跑一轮快速审查把明显问题挑出来然后对高风险 PR 再跑一轮串行深度审查。这里有个经验并行审查的智能体数量不要超过五个否则汇总阶段的噪声会很大审查意见之间互相矛盾的情况会显著增加。还有一个容易被忽略的点是智能体之间的“通信协议”。如果每个智能体输出的格式都不一样汇总起来会非常痛苦。LinkedIn 的做法是强制所有智能体输出结构化结果通常是一个 JSON 数组每个元素包含文件路径、行号、问题类型、严重程度、建议修改方案。这个结构统一之后汇总智能体或者规则引擎就能很容易地做去重、排序和优先级合并。2.3 提示词设计的核心原则收窄、举例、给格式多智能体方案里提示词的质量直接决定审查质量。我总结下来有三个原则最关键。第一是收窄每个智能体的提示词只关注一个维度不要贪多。第二是举例在提示词里给出该维度的正例和反例模型对例子的敏感度远高于抽象描述。第三是给格式明确告诉模型输出应该长什么样包括字段名、字段类型、严重程度的枚举值。举个例子逻辑审查智能体的提示词可以这样写你是一个专门审查逻辑正确性的资深工程师只关注边界条件、状态一致性和错误处理不要评论命名和格式。如果发现数组访问没有判空标记为 high如果发现异常被吞掉没有日志标记为 medium。输出格式为 JSON 数组每个元素包含 file、line、severity、issue、suggestion 五个字段。这种提示词写出来之后模型的输出稳定性会大幅提升。还有一个实操心得提示词里要明确告诉模型“如果某个维度没有问题返回空数组不要强行找问题”。我早期版本的提示词没有这句话结果模型为了“交差”经常编造一些不存在的问题浪费了大量审查时间。加上这句话之后误报率明显下降。3. 从本地脚本到产线流水线落地路径拆解3.1 最小可行版本本地手动跑通多智能体审查如果你不想一上来就搞复杂的基础设施可以先在本地用最朴素的方式跑通流程。准备一个 Python 脚本读取 git diff然后依次调用多个提示词模板每个模板对应一个审查维度。调用方式可以用任何你熟悉的大模型 API关键是把 diff 和提示词拼在一起发出去拿到结构化输出后打印出来。这个阶段不需要考虑并发和缓存重点是验证提示词的效果。我建议先拿自己过去一周的 PR 做测试看看每个智能体能不能稳定地挑出你当时确实犯过的错误。如果某个智能体总是漏报或者误报就回去改它的提示词加例子、加反例、加格式约束。这个迭代过程通常需要两到三轮每轮改完都要用同一批 PR 做回归测试确保改动没有引入新的问题。本地版本还有一个好处是可以快速对比不同模型的效果。同一个提示词换一个模型跑输出质量可能差很多。我实测下来逻辑审查和性能审查对模型能力要求较高安全审查和命名审查相对宽松一些。你可以根据每个维度的实际表现来分配模型资源重要的维度用更强的模型辅助维度用轻量模型。3.2 接入 CI让审查在每次提交时自动触发本地跑通之后下一步是接入 CI 流水线。通常的做法是在 PR 创建或更新时触发一个 job这个 job 拉取 diff调用审查服务然后把结果以评论形式贴回 PR。这里有几个工程细节需要注意。第一是 diff 的获取方式不要用 git diff 的原始输出最好用 git diff --unified0 或者解析成结构化格式否则模型会被大量的上下文行干扰。第二是超时控制审查服务不能阻塞 CI 太久一般设置 60 到 120 秒的超时超时后降级为只跑快速审查。第三是结果去重和合并。多个智能体可能对同一行代码提出相似意见汇总时需要做去重。简单的做法是按文件路径和行号分组同一组内保留严重程度最高的那条。复杂一点的做法是用一个汇总智能体来做语义去重但这样会增加延迟和成本。我的经验是先用规则去重规则覆盖不了的再交给汇总智能体。还有一个产线特有的问题误报处理。任何自动审查工具都会有误报关键是给开发者一个方便的反馈渠道。LinkedIn 的方案里有一个“忽略此建议”的按钮开发者点击后这条建议会被记录后续同类建议会被降权。这个反馈闭环非常重要没有它开发者很快会对审查结果失去信任直接全部忽略。3.3 产线级优化缓存、并发和成本控制当审查量上来之后成本和延迟会成为主要矛盾。优化手段主要有三个方向。第一是缓存同一个 diff 的审查结果可以缓存起来如果 PR 只是 rebase 或者改了 commit messagediff 没变就直接复用缓存结果。第二是并发多个智能体的调用可以并行发出把总延迟从串行的 N 倍降到接近单次调用的水平。第三是分级不是每个 PR 都需要跑全套审查可以根据改动文件类型和改动量来决定跑哪些智能体。成本控制还有一个容易被忽略的点提示词的长度。diff 本身可能很长如果每个智能体都把完整 diff 塞进提示词token 消耗会非常大。实际产线里通常会对 diff 做预处理比如只保留改动行和前后各三行上下文或者按文件切分每个文件单独审查。LinkedIn 的方案里还用了 diff 摘要技术先用一个轻量模型把 diff 压缩成一段描述再把描述发给审查智能体这样能大幅降低 token 消耗但会损失一些细节适合对精度要求不高的维度。4. 实操中踩过的坑和排查技巧4.1 智能体输出格式不稳定怎么办这是最常见的问题。你明明在提示词里写了“输出 JSON”但模型有时候会在 JSON 外面包一层解释文字有时候字段名拼错有时候严重程度用了不在枚举值里的词。解决办法分三层。第一层是在提示词里加更强的格式约束比如“只输出 JSON不要有任何其他文字第一个字符必须是 [最后一个字符必须是 ]”。第二层是在代码里做容错解析用正则提取 JSON 部分字段名做模糊匹配严重程度做映射。第三层是加一个格式修复智能体把不合规的输出丢给它让它转成标准格式。我实测下来第一层能解决百分之八十的问题第二层解决百分之十五剩下百分之五才需要第三层。所以不要一上来就搞格式修复智能体先把提示词和解析逻辑做好。4.2 多个智能体意见冲突怎么处理比如逻辑审查智能体说某段代码有边界问题性能审查智能体说这段代码没问题你该信谁我的处理原则是严重程度高的优先安全审查的结论优先于其他维度逻辑审查的结论优先于性能审查。如果两个智能体对同一行代码给出了矛盾的建议就在 PR 评论里同时展示两条让开发者自己判断。不要试图用规则自动裁决所有冲突有些冲突本身就是有价值的信号说明这段代码确实值得多看一眼。4.3 开发者不信任自动审查结果怎么办这个问题比技术问题更难解决。我的经验是第一不要一开始就全量开启先在小范围团队里试用收集反馈把误报率降到可接受水平再推广。第二审查意见要给出具体的修改建议不要只说“这里有问题”要说“建议改成这样”。第三允许开发者一键忽略并且忽略后不再重复提醒。第四定期回顾被忽略的建议如果某类建议被大量忽略说明提示词需要调整。还有一个技巧是让审查结果可解释。每条建议都附带“为什么这么判断”的简短说明比如“检测到数组访问前没有判空根据历史数据这类问题在线上导致过空指针异常”。这种解释能显著提升开发者的信任度。4.4 常见问题速查表问题现象可能原因排查方向解决建议审查结果为空diff 获取失败或提示词过于严格检查 diff 是否为空检查提示词是否要求“无问题返回空数组”打印 diff 长度放宽提示词中的判定条件误报率高提示词过于宽泛或缺少反例检查提示词是否收窄到单一维度是否给了反例增加反例明确“以下情况不算问题”输出格式混乱提示词格式约束不够强检查是否明确要求纯 JSON 输出加强格式约束增加容错解析审查延迟高串行调用或 diff 过长检查调用方式是否并行diff 是否做了预处理改为并行调用对 diff 做摘要或切分同一问题重复报告多个智能体覆盖了同一维度检查各智能体的提示词是否有重叠调整提示词边界汇总阶段做去重开发者大量忽略建议不可操作或误报多检查建议是否具体误报率是否过高增加修改建议允许一键忽略并记录反馈5. 提示词模板参考与迭代方法5.1 逻辑审查智能体提示词模板你是一个专门审查逻辑正确性的资深工程师。只关注边界条件、状态一致性、错误处理和资源管理不要评论命名、格式和性能。如果发现数组或对象访问前没有判空标记为 high。如果发现异常被捕获但没有日志或没有重新抛出标记为 medium。如果发现循环条件可能导致死循环标记为 high。如果某个维度没有问题返回空数组不要强行找问题。输出格式为 JSON 数组每个元素包含 file、line、severity、issue、suggestion 五个字段。只输出 JSON不要有任何其他文字。这个模板的关键在于“只关注”和“不要评论”这两个约束它们把智能体的注意力锁死在逻辑维度上。severity 的枚举值也要在提示词里明确避免模型自创等级。5.2 安全审查智能体提示词模板你是一个专门审查安全问题的资深工程师。只关注输入校验、权限判断、敏感数据暴露和注入风险不要评论命名、格式和性能。如果发现用户输入直接拼接到 SQL 或命令中标记为 critical。如果发现敏感数据被写入日志或返回给前端标记为 high。如果发现权限判断缺失或可以被绕过标记为 critical。如果某个维度没有问题返回空数组。输出格式为 JSON 数组字段同上。只输出 JSON。安全审查的严重程度整体要比其他维度高一档因为安全问题的后果通常更严重。critical 这个等级只在安全维度使用这样汇总时可以优先处理。5.3 提示词迭代的实操方法提示词不是写一次就完事的需要持续迭代。我的做法是建立一个“审查案例库”每次发现误报或漏报就把对应的代码片段和期望的审查结果记录下来。迭代提示词时用这个案例库做回归测试确保改动解决了目标问题同时没有破坏已有的正确行为。案例库不需要很大积累到三五十个案例就能覆盖大部分常见场景。迭代频率建议是每两周一次每次只改一个智能体的提示词改完跑一遍案例库观察通过率变化。如果通过率下降就回滚。这种小步快跑的方式比一次性大改要稳妥得多。6. 多智能体方案的成本与收益权衡6.1 什么团队适合上多智能体审查多智能体审查不是没有成本的。它需要你维护多个提示词、一个汇总逻辑、一套反馈机制还要承担比单模型更高的 token 消耗。所以它更适合那些已经有了一定工程效能基础、PR 量大、且对代码质量有持续要求的团队。如果团队只有三五个人PR 一周不到十个那用单模型加一个好提示词就够了没必要上多智能体。另一个判断标准是误报容忍度。多智能体方案在降低漏报的同时通常会带来更多误报因为多个智能体各自判断总有一些会过度敏感。如果团队对误报非常敏感那可能需要先优化单模型方案把误报降到很低之后再考虑多智能体。6.2 成本控制的几个实用手段第一按需触发。不是每个 PR 都跑全套审查可以根据改动文件类型来决定。比如只改了文档就跳过所有审查只改了测试就只跑逻辑审查。第二分级模型。安全审查和逻辑审查用强模型命名审查和格式审查用轻量模型。第三缓存复用。同一个 diff 的审查结果缓存起来避免重复计算。第四diff 预处理。只保留改动行和必要上下文减少 token 消耗。我实测下来这四种手段组合使用能把多智能体审查的成本控制在单模型方案的 1.5 到 2 倍左右但漏报率能降低一半以上。对于中大型团队来说这个投入产出比是划算的。6.3 收益的衡量方式衡量多智能体审查的收益不能只看“发现了多少问题”还要看“这些问题如果漏到线上会造成多大损失”。我的做法是跟踪两个指标一是审查阶段发现的问题数量二是线上因代码问题导致的故障数量。如果前者上升、后者下降说明审查有效。如果前者上升但后者没变说明审查可能在挑一些无关紧要的问题需要调整提示词的严重程度判定。还有一个软性指标是开发者的反馈。定期收集开发者对审查结果的评价看看他们认为哪些建议有价值、哪些是噪声。这个反馈比任何技术指标都更能反映审查系统的实际价值。7. 从代码审查延伸多智能体还能用在哪代码审查只是多智能体协作的一个应用场景这套“分维度、并行审查、结构化汇总”的思路可以迁移到很多其他领域。比如文档审查可以拆成事实核查、逻辑连贯性、术语一致性、格式规范几个智能体。比如需求评审可以拆成完整性、可行性、优先级、依赖关系几个智能体。甚至在设计评审里也可以拆成视觉一致性、交互合理性、无障碍访问几个维度。迁移的关键在于找到合适的维度拆分方式。拆分的原则是每个维度有明确的判断标准维度之间尽量正交每个维度的输出可以结构化。只要满足这三点就可以套用多智能体的框架。我在实际项目里试过把这套思路用在 API 设计评审上拆成命名规范、参数设计、错误码、版本兼容性四个智能体效果比单模型评审好很多尤其是错误码和版本兼容性这两个容易被人类忽略的维度。最后分享一个我在迭代提示词时的小技巧把每个智能体的提示词当成一个“新人培训手册”来写。想象你带了一个刚入职的工程师你要告诉他只看什么、不看什么、什么情况算严重、什么情况可以放过。用这种心态写出来的提示词通常比抽象描述有效得多。