AI 代码审查早就不是“把一段代码贴给大模型让它找几个bug”的阶段了。我在过去大半年里眼见着团队从提示词实验一路走到产线接入最大的感悟是单点Prompt的惊喜感维持不了几天真正能扛住生产环境压力的是一套有分工、有协议、有边界的智能体系统。LinkedIn工程团队公开的多智能体代码审查框架把这个思路讲得非常完整——从提示词工程、Agent编排到CI/CD集成和效果评估每一步都有明确的取舍逻辑。这篇文章我就按自己落地时的拆解路径把整条链路掰开讲透希望能给正在做AI代码审查或想引入类似机制的同学一些可以上手的参考。很多人第一次接触AI代码审查时都会有一个错觉大模型这么强上下文窗口又大把整个diff丢给它让它一次把问题全找出来不就行了确实在小型项目、几百行diff的场景下这种做法看起来是有效的。但一旦进入真实产线仓库规模、代码风格、多个语言栈、长期维护的约束规则会迅速让这种“单一大提示词”模式崩溃。1. 从“把代码贴给大模型”到“让AI按产线标准审查”这一步到底发生了什么1.1 为什么单Prompt审查模式在真实仓库里撑不住单Prompt模式的核心问题是上下文膨胀。一个中型服务的一次PRdiff常常在几百到几千行再加上仓库结构说明、相关文件、历史审查规则、编码规范一次性塞进上下文的结果是模型开始“选择性失明”。你观察到的典型现象是它在最先看到的文件上找了一堆格式问题却在最核心的业务逻辑变更上毫无评论或者它把早期文件里的约定当成全局规则去审查后面的文件时产生大量误报。还有一个隐藏问题就是单一Prompt内部的指令冲突。你既想让模型关注正确性又想让模型关注性能、安全、可读性、测试覆盖这些指令在同一个上下文里是会互相干扰的。真实情况往往是安全规则压制住了可读性要求或者模型为了迎合“找问题”的目标把正常代码也挑出毛病。产线级的代码审查需要的是每个维度都有专职审查者而不是让一个模型同时扮演所有角色。这就是LinkedIn那套多智能体系统的出发点与其让一个Agent全知全能不如让多个Agent各管一段每个Agent只需要把一件事做到极致。他们内部把这种架构称为Multi-Reviewer Code Agent核心思路就是分而治之。1.2 LinkedIn选择多智能体的核心逻辑分而治之如果你去看LinkedIn的工程实践分享会发现他们对智能体的定义非常朴素一个Agent 一个明确的职责 一套专用提示词 一个可复用的调用入口。因为职责明确提示词可以做得非常专注上下文可以控制得很小输出质量也就稳定得多。这套系统里最常见的分工方式是一个Agent负责整体代码审查相当于总Reviewer多个Agent分别负责特定语言的最佳实践Java、Python、JavaScript/TypeScript、Kotlin、Swift还有一个Agent专门审查AI生成的代码描述甚至有一个Mock Review Agent专门用来生成测试用的模拟Review意见。你会发现这里没有哪个Agent在“管所有事”它们之间的关系更像是一家医院里的会诊专科医生各自出意见最后汇总到主诊医生手里。我拆这套设计的时候最明显的感受是智能体的价值不在于“智能”而在于“边界”。你把每个Agent的边界划清楚它们协作起来反而高效边界一旦模糊模型再强也会在产线上惹祸。2. 提示词在这里不是一段话而是一套协议LinkedIn这套系统里提示词工程占据的地位非常核心但它的形态和大多数人想象的不一样。它不是一个精心修饰的超长Prompt而是一套结构化的提示词协议。每个Agent都有一套独立的提示词同一套系统里可以存在几十套提示词彼此不混用。2.1 Review Agent提示词的标准骨架角色、范围、规则、格式我在实际落地中把一个Review Agent的提示词拆成了五个固定模块这与LinkedIn公开的做法基本一致角色设定Role告诉模型它是什么。比如“你是一个有10年经验的Java后端代码审查专家专注于并发控制和事务边界”。审查范围Scope明确它应该关注什么、不应该关注什么。比如“你只关注线程安全与死锁风险不需要评论代码格式”。规则列表Rules给它一组显式的正面/负面规则。这里非常关键——规则不应该泛泛而谈而应该具体到可以直接判定的程度。LinkedIn的做法是针对不同语言维护了不同的规则集每个规则都有一个可以被模型“验证”的描述。输出格式Format要求模型返回结构化的JSON或者带特定标记的文本便于后续流水线解析。LinkedIn用的是自定义的JSON结构每个Review评论包含文件路径、起始行号、结束行号、严重程度、标题和描述。Few-shot示例Examples给出2到3个历史审查案例作为“什么是合格comment”的锚点。这一步被很多人忽略但它的效果立竿见影——模型会照着示例的长度、语气、详细程度来输出。这里我直接给一个最小可用的参考模板以Python为例你是Python代码审查专家专注异常处理与资源泄漏问题。 审查范围 - 只关注资源释放、异常捕获边界、finally块使用。 - 不做代码风格、性能优化、安全漏洞方面的评论。 规则 1. 如果文件操作或网络连接没有使用with语句必须标记为高严重度。 2. 如果except子句捕获了Exception或BaseException但没有记录堆栈标记为中严重度。 3. 如果finally块中出现了return语句标记为高严重度。 输出要求 严格按JSON格式输出结构 {comments: [{severity: HIGH, location: {file: ..., line_start: 10, line_end: 12}, title: ..., description: ...}]} 示例 输入def load_config():\n f open(config.yaml)\n return yaml.safe_load(f) 输出{comments: [{severity: HIGH, location: {file: , line_start: 1, line_end: 2}, title: File handle leak, description: File is opened without context manager, use with open(...) to ensure it is closed on exceptions.}]}这个模板看起来简单但后面每一项选择都有原因。角色设定限制模型的“人格漂移”审查范围明确划出“什么不归我管”减少指令冲突输出格式强制模型从“写一段话”切换到“填一个结构”对下层的自动化处理极其友好。2.2 用模板变量承载上下文diff、file path、repo best practices提示词不能每次启动都手写一遍它需要是一个模板。我落地时参考LinkedIn的做法把上下文全部设计成模板变量。最核心的几个变量是{diff}本次PR的代码差异按文件块组织。{language_rules}对应语言的规则集不同的Agent从规则库中拉取不同的子集。{file_context}变更文件的关键信息比如文件路径、模块名、类名用于帮助模型理解所属模块。{repo_specific_practices}当前仓库特有的约定比如目录结构规范、命名规范、已知的坑。{recent_similar_fixes}相似问题的历史修复记录Few-shot用。其中“仓库特有约定”这个变量是我强烈建议每一个做代码审查系统的人都补上的。比如有些仓库有“所有public方法必须写docstring”“数据库查询禁止使用裸SQL”这类内部约定把它们放prompt里和把这些约定写死在规则集里是完全不同的两条路。放prompt里意味着后续更新不需要改代码只需改配置。2.3 语言级规则为什么必须拆开写LinkedIn的提示词体系里有个很值得借鉴的细节不同语言的代码审查提示词是相互隔离的。Java有Java的提示词Python有Python的提示词JavaScript有JavaScript的提示词Swift有Swift的提示词。每个提示词里嵌入了对应语言的最佳实践规则、常见错误模式、性能注意事项。这不是一个懒人式的大Prompt能替代的。因为不同语言的“正确代码”长得很不一样Java里要关注Lock与synchronized的差别、ExecutorService的关闭Python里要关注with语句、GIL的影响、asyncio的事件循环前端要关注组件生命周期和状态更新。你让一个Prompt同时覆盖所有这些语言它只会退化成“什么都懂一点什么都不深入”。我在做多语言团队落地时发现规则拆开还有一个额外的好处语言规则文件本身可以被团队Review和迭代。Java专家可以只维护Java那套提示词前端同事只维护TS那套提示词互不干扰。这比集中式维护一个大Prompt在运营效率上高出太多。2.4 输出结构化的收益从自由文本到可执行的审查结果如果把提示词比喻为给Agent的“工作说明书”那么输出格式协议就是“验收标准”。LinkedIn的Agent输出格式大致长这样{ review_comments: [ { category: correctness, severity: high, location: { file: src/controller/OrderController.java, line_start: 87, line_end: 95 }, title: Race condition on order status update, description: Multiple threads can read the same order status..., suggestion: ... }, { category: performance, severity: medium, ... } ] }结构化输出带来的第一个收益是自动化的门槛大幅降低。流水线解析JSON之后就能直接把Comment挂到PR的对应行上而不是用正则从一大段自然语言里抠。第二个收益是过滤和路由你可以按严重程度、分类、文件路径做灵活的过滤规则。比如“高严重度意见必须推送给作者中低严重度意见只在受限模式显示”。更重要的一点是结构化输出让你可以给每个Comment打上category标签。这直接催生了评估指标——你可以统计高严重度意见里有多少最终被人类开发者确认为有效从而对每个Agent、每条规则做量化评价。这是我见过最直接的提示词调优闭环。3. 多智能体之间的“编排”不是开个会而是流水线有了提示词协议剩下的问题就是“多个Agent怎么协作”。很多人一听到多智能体就想到“Agent之间互相聊天讨论”实际上在产线里你最好不要这么干——不可控、延迟高、容易漂移。LinkedIn的方式更接近流水线 并行工作流的组合。3.1 Reviewer Agent多个专职审查员并行跑在LinkedIn的框架里多个Reviewer Agent是相对独立运行的。整体Reviewer Agent负责宏观层面的问题比如逻辑错误、接口变更影响面、边界条件各语言的专项Agent并行跑各自语言相关的规则。这些Agent之间没有复杂的消息传递它们各自拿到相同的Diff各自用各自的提示词产出意见最后汇总成一份统一的Review结果。这个设计有一个非常实际的好处并发度高。每个Agent的输入上下文都很小因为只关注自己那部分规则模型推理速度快整个流水线可以在可接受的延迟内完成所有审查任务。我实测下来一个1000行上下的diff跑一个总Reviewer加三个语言Agent整体耗时在两分钟以内完全能接受。在实现上这里的“并行”最好像我这样处理用一个调度器触发所有任务等待所有结果返回后再做合并。合并时要做去重和冲突消解比如多个Agent在同一个文件同一行提出了不同意见需要按优先级只保留最相关的。3.2 Revision Agent让AI自己改自己提的问题但要加锁LinkedIn这个系统里最容易被忽略、但我觉得最有含金量的是Revision Agent。它负责接收Reviewer Agent的反馈自动生成修复后的代码。这等于让AI走完“发现问题 - 提出修复”的闭环而不仅仅是停留在“指指点点”。但这个Agent也是最容易翻车的。它在接收Review意见后要先在代码库中找到对应位置再生成补丁。这里必须有几条硬性约束只允许修改与问题直接相关的代码区域不允许顺手做无关重构。如果Review意见不明确或者模型置信度过低宁可不改也不胡改。必须设置最大迭代次数比如2到3轮防止Agent在“改A之后发现B被改坏了再改B又影响C”的循环里出不来。所有自动生成的修改都必须有一个人工Review环节兜底不能直接合入。我见过很多团队做自动修Bug的时候败在“过度修改”上——模型为了“改正”一个措辞问题把整个方法的逻辑都重写了。Revision Agent的提示词里最好明确加上一句“Minimal change principle, only apply the change requested by the reviewer, do not refactor unrelated code”。这句约束能帮你过滤掉一大批麻烦。3.3 Description Agent把PR描述从垃圾箱里捞出来这个Agent的设计初衷让我觉得LinkedIn团队是真的懂开发者体验。他们让一个专职Agent负责生成PR描述Pull Request Description并且把它做成一个独立Agent而不是Review系统里的顺带功能。原因是大多数开发者写PR描述时都会敷衍了事要么一行“fix bug”要么直接自动生成模板然后忘了填。Description Agent做的事是把Diff、相关Issue、提交历史、变更文件汇总起来生成一段结构化的PR描述变更原因、影响范围、测试计划、关联链接。虽然是“小功能”但它对团队的日常体验提升非常明显。Reviewer在看PR的时候不再是面对一个空荡荡的描述而是面对一份有上下文的变更说明审查效率会明显上升。我在实际落地时没有单独建一个Description Agent而是把它作为总Reviewer工作流里的一步。它用一个独立的提示词读取Diff和Git提交信息生成一个可编辑的PR描述草稿然后让开发者在创建PR时填充。这种做法的侵入性很低团队的接受度反而更高。3.4 Mock Review Agent测试流程的“假想敌”多智能体系统最大的运维难题是想测好完整流程却找不到稳定的Review意见来源。真实Review意见质量波动大不适合做回归测试。LinkedIn的解法是Mock Review Agent——一个专门生成模拟Review意见的Agent让它在测试环境里以预定好的格式、频率、严重程度产出问题。这个思路非常值得借鉴。以前我们调试代码审查流水线只能拿真实PR来试遇到模型输出格式漂移或者是网络超时根本没法区分是模型问题、调度问题还是网络问题。有了Mock Agent你可以像写单元测试一样写一组“虚拟Review意见”输入然后断言流水线的输出是否生成评论、是否过滤了指定文件、是否触发了Revision Agent。整个系统的可测试性立刻上一个台阶。我在自家系统里为每个Reviewer Agent配了一个对应的Mock版本只需要改一行配置切换。这让CI回归测试从理想变成了现实。3.5 智能体之间的消息协议一个实际的数据结构多个Agent要协作消息协议必须统一。我的建议是不要在智能体之间传自然语言消息而是定义一套互操作的数据结构。参考LinkedIn的做法我用的核心结构是这样{ event_id: review-20241101-001, pr: { number: 123, repo: platform/service-a, head_sha: a1b2c3d4, base_sha: d4e5f6a7, changed_files: [...] }, agent_name: java_reviewer, status: completed, comments: [...], meta: { model: claude-3.5-sonnet, latency_ms: 4200, tokens_used: 18500 } }这个结构的价值在于Agent之间、Agent和流水线之间都通过事件总线通信不再关心彼此是HTTP调用还是本地进程调用也不关心对方是用什么模型、什么框架实现的。它为后续的扩展留足了余地——今天你只有4个Agent明天你想加一个安全专项Agent只需要照着协议实现一个注册到调度器里即可。4. 从Demo到产线这步最难的从来不是模型而是工程化提示词做得再好、智能体编排得再顺在没有接入真实产线之前都只是Demo。LinkedIn这套系统能跑在内部生产环境靠的是一整套工程化设计而不只是模型能力。4.1 接入PR生命周期事件驱动、异步执行、只看增量接入产线的第一步是想清楚“什么时候触发系统”。LinkedIn的做法是在PR的特定事件上触发比如PR创建或代码更新时系统异步分析变更。注意这里的两个关键点事件驱动不要定时全量扫描仓库那既浪费算力又容易造成噪音。应当只在PR事件发生时启动审查流程。只看增量无论仓库多大系统只处理当前PR的Diff不扫描整个代码库。这样既控制成本也保证审查的聚焦性。这一点和代码审查的核心逻辑完全一致——你是Review“这次变更”不是Review整个项目。事件驱动的实现一般会通过Webhook或者Git仓库API轮询来捕获PR状态。捕获到事件之后立即把Diff提取出来塞给调度器调度器再并行派发给各个Agent。整个链路异步化PR不会因为AI审查而阻塞。对开发者来说AI评论就像是另一个审查者稍后上线而不是一个必须等待的关卡。4.2 质量与安全栅栏什么意见能上PR、怎么上、谁能关AI审查意见直接发到PR上是有风险的。最大风险有两个一是误报导致噪音开发者最终选择无视所有评论二是模型在评论里给出错误的技术判断误导开发者。LinkedIn在这方面的设计我非常认同——系统里的Review意见只有在限定条件下才会自动展示并且有完整的反馈闭环。我落地时采用的是分级策略高严重度HIGH意见如果有较高的模型置信度自动发布为PR内联评论中低严重度意见只在“受限模式”下发布比如仅对自己可见或者集中展示在一个单独构建/报告中所有AI评论都标记为“AI Generated”开发者可以一键“确认有效”或“标注误报”。每次人工反馈都会汇总回评估数据集成为之后微调规则、优化提示词的素材。还有一个容易被忽视的点评论的写入权限和关闭机制。AI评论不能被开发者直接关闭因为那是脚本发布的但开发者可以通过“忽略”“确认”等操作来驱动评论状态的流转。状态流转记录是评估系统的重要输入。4.3 成本、延迟和模型路由多智能体系统的成本不是一个Agent的调用成本而是“N个Agent × 每次调用的Token数 × 每天的PR数量”。如果每个PR都跑全套Agent月成本很容易冲到几千甚至上万美元。LinkedIn的应对方式是给不同任务分配不同模型。这条经验可以直接抄过来简单任务Mock Agent、描述生成、格式检查用小模型比如GPT-4o mini或者Claude Haiku级别。复杂任务总Reviewer、Revision用大模型比如Claude Sonnet或GPT-4o级别。部分任务甚至可以用纯规则引擎先过滤只有命中特定模式才升级到AI处理进一步省成本。延迟控制上我建议不要把同步等待做得太死。AI审查本质上是一个异步过程PR可以先合入或者先由人类审查AI意见随后补上。用“事后评论”的方式比“卡PR等待AI”的方式用户体验好得多。LinkedIn在内部文档里也强调过这一点——他们的目标是“辅助”而非“阻塞”。4.4 闭环评估没有评价指标就没有提示词优化代码审查系统的提示词迭代最大的痛点是不清楚“改了一版提示词效果到底是变好了还是变坏了”。LinkedIn的做法是构建了一个评估数据集从历史PR中抽取已有人工确认的问题集合并经过历史意见比对来判定AI评论的价值。这样你可以每次都跑同一个测试集看修改前后的精准率、召回率变化。我在自己的评估流程里会维护三类数据已知问题集有标记的历史PR diff集合。历史人工审查建议集合作为ground truth。AI反馈的人工评级数据每次开发者确认或误报都记录下来。每轮提示词修改都跑一遍这个数据集观察以下指标指标含义优化方向精准率AI提出的意见中被人类确认有效占比降低误报优先看高严重度意见召回率历史已知问题中被AI发现的占比提高覆盖率但注意与精准率的平衡平均严重度分布AI倾向报低危还是高危问题如果低危占比过高需要收紧Review Scope开发者手动修改率Reviewer对AI意见的采纳度如果过低需要返工提示词或规则我的经验是精准率优先于召回率。AI审查系统一旦误报率高开发者很快就会放弃它。宁可它少提一些意见也不要整天冒“安全性无关紧要”的噪音。5. 落地过程中最容易翻车的几个环节前面拆到这里你可能觉得思路已经清晰了。但真正把系统跑起来一定还会遇到很多文档里不会写的问题。我把自己踩过的、以及从LinkedIn实践里看出来的几个坑提前列在这里。5.1 提示词和Diff的编排顺序影响判断同样一个Diff放在提示词的不同位置模型的判断质量都不一样。我的实测是Diff必须放在提示词的正中间到中后段之间且要先给规则、后给Diff。如果一上来就把Diff贴进去模型容易在后续规则说明出现时“忘记”前面的代码内容。还有Diff中文件顺序也很重要。按文件的重要性从高到低排列比按Git默认的字母序要好——核心业务代码优先看到模型会把注意力优先分配给它。我曾经做过一个测试把配置文件和核心逻辑文件对调位置之后AI对核心逻辑的评论数量明显下降。这个细节虽然不起眼但优化成本极低值得做。5.2 AI评论的“自信胡扯”怎么压下去大模型在代码审查里有一种很讨厌的行为它会把“看起来像问题”的正常代码标成问题而且语气极度自信。这种自信胡扯如果直接发到PR上会非常影响开发者体验。我的做法是在提示词里明确加一句“如果你不确定或者缺乏足够上下文请输出空结果不要猜测问题。”回顾LinkedIn的设计他们其实也做了类似的事——Agent在无法给出确定性判断时可以选择不发表评论而不是强行凑数。同时把“低置信度意见”和“高置信度意见”分开展示低置信度的默认折叠也帮我过滤掉大量噪音。5.3 多人团队如何管理提示词版本提示词工程本质上就是代码。代码要版本控制提示词同样要。每个团队的提示词应该放在Git仓库里和代码一起走评审流程。谁要改提示词就提PR评审通过后合入然后重新跑评估集。不要用聊天工具里的“复制粘贴”来管理提示词——那会让你完全无法回溯为什么某些意见在某个时间点突然变了。LinkedIn的做法是把提示词定义为配置/代码资产和系统代码一同发布。我觉得这也是多智能体系统能长期演进的基础。如果提示词无法被版本化系统就永远处于“不可复现”的状态出问题都没法查。5.4 什么时候该设人工审批、什么时候可以放权最后是组织层面的话题。AI代码审查系统上线之后团队需要回答“AI的意见到底有多大权力”。我的建议也是LinkedIn实践的倾向是一开始把AI当作“补充审查者”而不是“守门员”。也就是说AI的意见可以作为提交前的自检清单也可以作为PRReview的辅助信息但不要一开始就强制“必须AI通过才能合入”。给团队一个适应周期收集大家对AI意见的反馈等精准率稳定在一个可接受的水平之后再把AI审查设置为可选的“准入门槛”。这样既减少了对抗情绪也给系统留出了优化空间。在具体操作上可以先在几个活跃仓库试点单独开一个CI任务展示AI审查报告通知但不阻塞。运行两周后主动找核心开发者聊聊使用感受让他们反馈最烦的评论类型和最想要的评论类型。第三个版本再逐步放开权限——比如高严重度问题设置为合并前必须处理。这种做法比我一开始直接硬性卡合并成熟得多。多智能体代码审查的价值不在于某一个Agent能做到多智能而在于你把“让AI看代码”这件事做成了一个可以被度量、被迭代、被管理的工程体系。提示词是这套体系的地基编排是骨架评估是眼睛。把这三件事想明白再复杂的系统落地剩下的都只是执行问题。我个人在跑这套流程的时候最大的感触是对AI审查系统的要求不是让它像一个大牛一样无所不知而是让它像一个靠谱的初级同事一样只在自己有把握的地方发言拿不准的地方宁可沉默。能做到这一点它在产线上就能帮团队省下大量时间。 多智能体AI代码审查落地实践：从提示词协议到产线编排
AI 代码审查早就不是“把一段代码贴给大模型让它找几个bug”的阶段了。我在过去大半年里眼见着团队从提示词实验一路走到产线接入最大的感悟是单点Prompt的惊喜感维持不了几天真正能扛住生产环境压力的是一套有分工、有协议、有边界的智能体系统。LinkedIn工程团队公开的多智能体代码审查框架把这个思路讲得非常完整——从提示词工程、Agent编排到CI/CD集成和效果评估每一步都有明确的取舍逻辑。这篇文章我就按自己落地时的拆解路径把整条链路掰开讲透希望能给正在做AI代码审查或想引入类似机制的同学一些可以上手的参考。很多人第一次接触AI代码审查时都会有一个错觉大模型这么强上下文窗口又大把整个diff丢给它让它一次把问题全找出来不就行了确实在小型项目、几百行diff的场景下这种做法看起来是有效的。但一旦进入真实产线仓库规模、代码风格、多个语言栈、长期维护的约束规则会迅速让这种“单一大提示词”模式崩溃。1. 从“把代码贴给大模型”到“让AI按产线标准审查”这一步到底发生了什么1.1 为什么单Prompt审查模式在真实仓库里撑不住单Prompt模式的核心问题是上下文膨胀。一个中型服务的一次PRdiff常常在几百到几千行再加上仓库结构说明、相关文件、历史审查规则、编码规范一次性塞进上下文的结果是模型开始“选择性失明”。你观察到的典型现象是它在最先看到的文件上找了一堆格式问题却在最核心的业务逻辑变更上毫无评论或者它把早期文件里的约定当成全局规则去审查后面的文件时产生大量误报。还有一个隐藏问题就是单一Prompt内部的指令冲突。你既想让模型关注正确性又想让模型关注性能、安全、可读性、测试覆盖这些指令在同一个上下文里是会互相干扰的。真实情况往往是安全规则压制住了可读性要求或者模型为了迎合“找问题”的目标把正常代码也挑出毛病。产线级的代码审查需要的是每个维度都有专职审查者而不是让一个模型同时扮演所有角色。这就是LinkedIn那套多智能体系统的出发点与其让一个Agent全知全能不如让多个Agent各管一段每个Agent只需要把一件事做到极致。他们内部把这种架构称为Multi-Reviewer Code Agent核心思路就是分而治之。1.2 LinkedIn选择多智能体的核心逻辑分而治之如果你去看LinkedIn的工程实践分享会发现他们对智能体的定义非常朴素一个Agent 一个明确的职责 一套专用提示词 一个可复用的调用入口。因为职责明确提示词可以做得非常专注上下文可以控制得很小输出质量也就稳定得多。这套系统里最常见的分工方式是一个Agent负责整体代码审查相当于总Reviewer多个Agent分别负责特定语言的最佳实践Java、Python、JavaScript/TypeScript、Kotlin、Swift还有一个Agent专门审查AI生成的代码描述甚至有一个Mock Review Agent专门用来生成测试用的模拟Review意见。你会发现这里没有哪个Agent在“管所有事”它们之间的关系更像是一家医院里的会诊专科医生各自出意见最后汇总到主诊医生手里。我拆这套设计的时候最明显的感受是智能体的价值不在于“智能”而在于“边界”。你把每个Agent的边界划清楚它们协作起来反而高效边界一旦模糊模型再强也会在产线上惹祸。2. 提示词在这里不是一段话而是一套协议LinkedIn这套系统里提示词工程占据的地位非常核心但它的形态和大多数人想象的不一样。它不是一个精心修饰的超长Prompt而是一套结构化的提示词协议。每个Agent都有一套独立的提示词同一套系统里可以存在几十套提示词彼此不混用。2.1 Review Agent提示词的标准骨架角色、范围、规则、格式我在实际落地中把一个Review Agent的提示词拆成了五个固定模块这与LinkedIn公开的做法基本一致角色设定Role告诉模型它是什么。比如“你是一个有10年经验的Java后端代码审查专家专注于并发控制和事务边界”。审查范围Scope明确它应该关注什么、不应该关注什么。比如“你只关注线程安全与死锁风险不需要评论代码格式”。规则列表Rules给它一组显式的正面/负面规则。这里非常关键——规则不应该泛泛而谈而应该具体到可以直接判定的程度。LinkedIn的做法是针对不同语言维护了不同的规则集每个规则都有一个可以被模型“验证”的描述。输出格式Format要求模型返回结构化的JSON或者带特定标记的文本便于后续流水线解析。LinkedIn用的是自定义的JSON结构每个Review评论包含文件路径、起始行号、结束行号、严重程度、标题和描述。Few-shot示例Examples给出2到3个历史审查案例作为“什么是合格comment”的锚点。这一步被很多人忽略但它的效果立竿见影——模型会照着示例的长度、语气、详细程度来输出。这里我直接给一个最小可用的参考模板以Python为例你是Python代码审查专家专注异常处理与资源泄漏问题。 审查范围 - 只关注资源释放、异常捕获边界、finally块使用。 - 不做代码风格、性能优化、安全漏洞方面的评论。 规则 1. 如果文件操作或网络连接没有使用with语句必须标记为高严重度。 2. 如果except子句捕获了Exception或BaseException但没有记录堆栈标记为中严重度。 3. 如果finally块中出现了return语句标记为高严重度。 输出要求 严格按JSON格式输出结构 {comments: [{severity: HIGH, location: {file: ..., line_start: 10, line_end: 12}, title: ..., description: ...}]} 示例 输入def load_config():\n f open(config.yaml)\n return yaml.safe_load(f) 输出{comments: [{severity: HIGH, location: {file: , line_start: 1, line_end: 2}, title: File handle leak, description: File is opened without context manager, use with open(...) to ensure it is closed on exceptions.}]}这个模板看起来简单但后面每一项选择都有原因。角色设定限制模型的“人格漂移”审查范围明确划出“什么不归我管”减少指令冲突输出格式强制模型从“写一段话”切换到“填一个结构”对下层的自动化处理极其友好。2.2 用模板变量承载上下文diff、file path、repo best practices提示词不能每次启动都手写一遍它需要是一个模板。我落地时参考LinkedIn的做法把上下文全部设计成模板变量。最核心的几个变量是{diff}本次PR的代码差异按文件块组织。{language_rules}对应语言的规则集不同的Agent从规则库中拉取不同的子集。{file_context}变更文件的关键信息比如文件路径、模块名、类名用于帮助模型理解所属模块。{repo_specific_practices}当前仓库特有的约定比如目录结构规范、命名规范、已知的坑。{recent_similar_fixes}相似问题的历史修复记录Few-shot用。其中“仓库特有约定”这个变量是我强烈建议每一个做代码审查系统的人都补上的。比如有些仓库有“所有public方法必须写docstring”“数据库查询禁止使用裸SQL”这类内部约定把它们放prompt里和把这些约定写死在规则集里是完全不同的两条路。放prompt里意味着后续更新不需要改代码只需改配置。2.3 语言级规则为什么必须拆开写LinkedIn的提示词体系里有个很值得借鉴的细节不同语言的代码审查提示词是相互隔离的。Java有Java的提示词Python有Python的提示词JavaScript有JavaScript的提示词Swift有Swift的提示词。每个提示词里嵌入了对应语言的最佳实践规则、常见错误模式、性能注意事项。这不是一个懒人式的大Prompt能替代的。因为不同语言的“正确代码”长得很不一样Java里要关注Lock与synchronized的差别、ExecutorService的关闭Python里要关注with语句、GIL的影响、asyncio的事件循环前端要关注组件生命周期和状态更新。你让一个Prompt同时覆盖所有这些语言它只会退化成“什么都懂一点什么都不深入”。我在做多语言团队落地时发现规则拆开还有一个额外的好处语言规则文件本身可以被团队Review和迭代。Java专家可以只维护Java那套提示词前端同事只维护TS那套提示词互不干扰。这比集中式维护一个大Prompt在运营效率上高出太多。2.4 输出结构化的收益从自由文本到可执行的审查结果如果把提示词比喻为给Agent的“工作说明书”那么输出格式协议就是“验收标准”。LinkedIn的Agent输出格式大致长这样{ review_comments: [ { category: correctness, severity: high, location: { file: src/controller/OrderController.java, line_start: 87, line_end: 95 }, title: Race condition on order status update, description: Multiple threads can read the same order status..., suggestion: ... }, { category: performance, severity: medium, ... } ] }结构化输出带来的第一个收益是自动化的门槛大幅降低。流水线解析JSON之后就能直接把Comment挂到PR的对应行上而不是用正则从一大段自然语言里抠。第二个收益是过滤和路由你可以按严重程度、分类、文件路径做灵活的过滤规则。比如“高严重度意见必须推送给作者中低严重度意见只在受限模式显示”。更重要的一点是结构化输出让你可以给每个Comment打上category标签。这直接催生了评估指标——你可以统计高严重度意见里有多少最终被人类开发者确认为有效从而对每个Agent、每条规则做量化评价。这是我见过最直接的提示词调优闭环。3. 多智能体之间的“编排”不是开个会而是流水线有了提示词协议剩下的问题就是“多个Agent怎么协作”。很多人一听到多智能体就想到“Agent之间互相聊天讨论”实际上在产线里你最好不要这么干——不可控、延迟高、容易漂移。LinkedIn的方式更接近流水线 并行工作流的组合。3.1 Reviewer Agent多个专职审查员并行跑在LinkedIn的框架里多个Reviewer Agent是相对独立运行的。整体Reviewer Agent负责宏观层面的问题比如逻辑错误、接口变更影响面、边界条件各语言的专项Agent并行跑各自语言相关的规则。这些Agent之间没有复杂的消息传递它们各自拿到相同的Diff各自用各自的提示词产出意见最后汇总成一份统一的Review结果。这个设计有一个非常实际的好处并发度高。每个Agent的输入上下文都很小因为只关注自己那部分规则模型推理速度快整个流水线可以在可接受的延迟内完成所有审查任务。我实测下来一个1000行上下的diff跑一个总Reviewer加三个语言Agent整体耗时在两分钟以内完全能接受。在实现上这里的“并行”最好像我这样处理用一个调度器触发所有任务等待所有结果返回后再做合并。合并时要做去重和冲突消解比如多个Agent在同一个文件同一行提出了不同意见需要按优先级只保留最相关的。3.2 Revision Agent让AI自己改自己提的问题但要加锁LinkedIn这个系统里最容易被忽略、但我觉得最有含金量的是Revision Agent。它负责接收Reviewer Agent的反馈自动生成修复后的代码。这等于让AI走完“发现问题 - 提出修复”的闭环而不仅仅是停留在“指指点点”。但这个Agent也是最容易翻车的。它在接收Review意见后要先在代码库中找到对应位置再生成补丁。这里必须有几条硬性约束只允许修改与问题直接相关的代码区域不允许顺手做无关重构。如果Review意见不明确或者模型置信度过低宁可不改也不胡改。必须设置最大迭代次数比如2到3轮防止Agent在“改A之后发现B被改坏了再改B又影响C”的循环里出不来。所有自动生成的修改都必须有一个人工Review环节兜底不能直接合入。我见过很多团队做自动修Bug的时候败在“过度修改”上——模型为了“改正”一个措辞问题把整个方法的逻辑都重写了。Revision Agent的提示词里最好明确加上一句“Minimal change principle, only apply the change requested by the reviewer, do not refactor unrelated code”。这句约束能帮你过滤掉一大批麻烦。3.3 Description Agent把PR描述从垃圾箱里捞出来这个Agent的设计初衷让我觉得LinkedIn团队是真的懂开发者体验。他们让一个专职Agent负责生成PR描述Pull Request Description并且把它做成一个独立Agent而不是Review系统里的顺带功能。原因是大多数开发者写PR描述时都会敷衍了事要么一行“fix bug”要么直接自动生成模板然后忘了填。Description Agent做的事是把Diff、相关Issue、提交历史、变更文件汇总起来生成一段结构化的PR描述变更原因、影响范围、测试计划、关联链接。虽然是“小功能”但它对团队的日常体验提升非常明显。Reviewer在看PR的时候不再是面对一个空荡荡的描述而是面对一份有上下文的变更说明审查效率会明显上升。我在实际落地时没有单独建一个Description Agent而是把它作为总Reviewer工作流里的一步。它用一个独立的提示词读取Diff和Git提交信息生成一个可编辑的PR描述草稿然后让开发者在创建PR时填充。这种做法的侵入性很低团队的接受度反而更高。3.4 Mock Review Agent测试流程的“假想敌”多智能体系统最大的运维难题是想测好完整流程却找不到稳定的Review意见来源。真实Review意见质量波动大不适合做回归测试。LinkedIn的解法是Mock Review Agent——一个专门生成模拟Review意见的Agent让它在测试环境里以预定好的格式、频率、严重程度产出问题。这个思路非常值得借鉴。以前我们调试代码审查流水线只能拿真实PR来试遇到模型输出格式漂移或者是网络超时根本没法区分是模型问题、调度问题还是网络问题。有了Mock Agent你可以像写单元测试一样写一组“虚拟Review意见”输入然后断言流水线的输出是否生成评论、是否过滤了指定文件、是否触发了Revision Agent。整个系统的可测试性立刻上一个台阶。我在自家系统里为每个Reviewer Agent配了一个对应的Mock版本只需要改一行配置切换。这让CI回归测试从理想变成了现实。3.5 智能体之间的消息协议一个实际的数据结构多个Agent要协作消息协议必须统一。我的建议是不要在智能体之间传自然语言消息而是定义一套互操作的数据结构。参考LinkedIn的做法我用的核心结构是这样{ event_id: review-20241101-001, pr: { number: 123, repo: platform/service-a, head_sha: a1b2c3d4, base_sha: d4e5f6a7, changed_files: [...] }, agent_name: java_reviewer, status: completed, comments: [...], meta: { model: claude-3.5-sonnet, latency_ms: 4200, tokens_used: 18500 } }这个结构的价值在于Agent之间、Agent和流水线之间都通过事件总线通信不再关心彼此是HTTP调用还是本地进程调用也不关心对方是用什么模型、什么框架实现的。它为后续的扩展留足了余地——今天你只有4个Agent明天你想加一个安全专项Agent只需要照着协议实现一个注册到调度器里即可。4. 从Demo到产线这步最难的从来不是模型而是工程化提示词做得再好、智能体编排得再顺在没有接入真实产线之前都只是Demo。LinkedIn这套系统能跑在内部生产环境靠的是一整套工程化设计而不只是模型能力。4.1 接入PR生命周期事件驱动、异步执行、只看增量接入产线的第一步是想清楚“什么时候触发系统”。LinkedIn的做法是在PR的特定事件上触发比如PR创建或代码更新时系统异步分析变更。注意这里的两个关键点事件驱动不要定时全量扫描仓库那既浪费算力又容易造成噪音。应当只在PR事件发生时启动审查流程。只看增量无论仓库多大系统只处理当前PR的Diff不扫描整个代码库。这样既控制成本也保证审查的聚焦性。这一点和代码审查的核心逻辑完全一致——你是Review“这次变更”不是Review整个项目。事件驱动的实现一般会通过Webhook或者Git仓库API轮询来捕获PR状态。捕获到事件之后立即把Diff提取出来塞给调度器调度器再并行派发给各个Agent。整个链路异步化PR不会因为AI审查而阻塞。对开发者来说AI评论就像是另一个审查者稍后上线而不是一个必须等待的关卡。4.2 质量与安全栅栏什么意见能上PR、怎么上、谁能关AI审查意见直接发到PR上是有风险的。最大风险有两个一是误报导致噪音开发者最终选择无视所有评论二是模型在评论里给出错误的技术判断误导开发者。LinkedIn在这方面的设计我非常认同——系统里的Review意见只有在限定条件下才会自动展示并且有完整的反馈闭环。我落地时采用的是分级策略高严重度HIGH意见如果有较高的模型置信度自动发布为PR内联评论中低严重度意见只在“受限模式”下发布比如仅对自己可见或者集中展示在一个单独构建/报告中所有AI评论都标记为“AI Generated”开发者可以一键“确认有效”或“标注误报”。每次人工反馈都会汇总回评估数据集成为之后微调规则、优化提示词的素材。还有一个容易被忽视的点评论的写入权限和关闭机制。AI评论不能被开发者直接关闭因为那是脚本发布的但开发者可以通过“忽略”“确认”等操作来驱动评论状态的流转。状态流转记录是评估系统的重要输入。4.3 成本、延迟和模型路由多智能体系统的成本不是一个Agent的调用成本而是“N个Agent × 每次调用的Token数 × 每天的PR数量”。如果每个PR都跑全套Agent月成本很容易冲到几千甚至上万美元。LinkedIn的应对方式是给不同任务分配不同模型。这条经验可以直接抄过来简单任务Mock Agent、描述生成、格式检查用小模型比如GPT-4o mini或者Claude Haiku级别。复杂任务总Reviewer、Revision用大模型比如Claude Sonnet或GPT-4o级别。部分任务甚至可以用纯规则引擎先过滤只有命中特定模式才升级到AI处理进一步省成本。延迟控制上我建议不要把同步等待做得太死。AI审查本质上是一个异步过程PR可以先合入或者先由人类审查AI意见随后补上。用“事后评论”的方式比“卡PR等待AI”的方式用户体验好得多。LinkedIn在内部文档里也强调过这一点——他们的目标是“辅助”而非“阻塞”。4.4 闭环评估没有评价指标就没有提示词优化代码审查系统的提示词迭代最大的痛点是不清楚“改了一版提示词效果到底是变好了还是变坏了”。LinkedIn的做法是构建了一个评估数据集从历史PR中抽取已有人工确认的问题集合并经过历史意见比对来判定AI评论的价值。这样你可以每次都跑同一个测试集看修改前后的精准率、召回率变化。我在自己的评估流程里会维护三类数据已知问题集有标记的历史PR diff集合。历史人工审查建议集合作为ground truth。AI反馈的人工评级数据每次开发者确认或误报都记录下来。每轮提示词修改都跑一遍这个数据集观察以下指标指标含义优化方向精准率AI提出的意见中被人类确认有效占比降低误报优先看高严重度意见召回率历史已知问题中被AI发现的占比提高覆盖率但注意与精准率的平衡平均严重度分布AI倾向报低危还是高危问题如果低危占比过高需要收紧Review Scope开发者手动修改率Reviewer对AI意见的采纳度如果过低需要返工提示词或规则我的经验是精准率优先于召回率。AI审查系统一旦误报率高开发者很快就会放弃它。宁可它少提一些意见也不要整天冒“安全性无关紧要”的噪音。5. 落地过程中最容易翻车的几个环节前面拆到这里你可能觉得思路已经清晰了。但真正把系统跑起来一定还会遇到很多文档里不会写的问题。我把自己踩过的、以及从LinkedIn实践里看出来的几个坑提前列在这里。5.1 提示词和Diff的编排顺序影响判断同样一个Diff放在提示词的不同位置模型的判断质量都不一样。我的实测是Diff必须放在提示词的正中间到中后段之间且要先给规则、后给Diff。如果一上来就把Diff贴进去模型容易在后续规则说明出现时“忘记”前面的代码内容。还有Diff中文件顺序也很重要。按文件的重要性从高到低排列比按Git默认的字母序要好——核心业务代码优先看到模型会把注意力优先分配给它。我曾经做过一个测试把配置文件和核心逻辑文件对调位置之后AI对核心逻辑的评论数量明显下降。这个细节虽然不起眼但优化成本极低值得做。5.2 AI评论的“自信胡扯”怎么压下去大模型在代码审查里有一种很讨厌的行为它会把“看起来像问题”的正常代码标成问题而且语气极度自信。这种自信胡扯如果直接发到PR上会非常影响开发者体验。我的做法是在提示词里明确加一句“如果你不确定或者缺乏足够上下文请输出空结果不要猜测问题。”回顾LinkedIn的设计他们其实也做了类似的事——Agent在无法给出确定性判断时可以选择不发表评论而不是强行凑数。同时把“低置信度意见”和“高置信度意见”分开展示低置信度的默认折叠也帮我过滤掉大量噪音。5.3 多人团队如何管理提示词版本提示词工程本质上就是代码。代码要版本控制提示词同样要。每个团队的提示词应该放在Git仓库里和代码一起走评审流程。谁要改提示词就提PR评审通过后合入然后重新跑评估集。不要用聊天工具里的“复制粘贴”来管理提示词——那会让你完全无法回溯为什么某些意见在某个时间点突然变了。LinkedIn的做法是把提示词定义为配置/代码资产和系统代码一同发布。我觉得这也是多智能体系统能长期演进的基础。如果提示词无法被版本化系统就永远处于“不可复现”的状态出问题都没法查。5.4 什么时候该设人工审批、什么时候可以放权最后是组织层面的话题。AI代码审查系统上线之后团队需要回答“AI的意见到底有多大权力”。我的建议也是LinkedIn实践的倾向是一开始把AI当作“补充审查者”而不是“守门员”。也就是说AI的意见可以作为提交前的自检清单也可以作为PRReview的辅助信息但不要一开始就强制“必须AI通过才能合入”。给团队一个适应周期收集大家对AI意见的反馈等精准率稳定在一个可接受的水平之后再把AI审查设置为可选的“准入门槛”。这样既减少了对抗情绪也给系统留出了优化空间。在具体操作上可以先在几个活跃仓库试点单独开一个CI任务展示AI审查报告通知但不阻塞。运行两周后主动找核心开发者聊聊使用感受让他们反馈最烦的评论类型和最想要的评论类型。第三个版本再逐步放开权限——比如高严重度问题设置为合并前必须处理。这种做法比我一开始直接硬性卡合并成熟得多。多智能体代码审查的价值不在于某一个Agent能做到多智能而在于你把“让AI看代码”这件事做成了一个可以被度量、被迭代、被管理的工程体系。提示词是这套体系的地基编排是骨架评估是眼睛。把这三件事想明白再复杂的系统落地剩下的都只是执行问题。我个人在跑这套流程的时候最大的感触是对AI审查系统的要求不是让它像一个大牛一样无所不知而是让它像一个靠谱的初级同事一样只在自己有把握的地方发言拿不准的地方宁可沉默。能做到这一点它在产线上就能帮团队省下大量时间。