多智能体评审工作流用角色分工提升代码质量一、单 Agent 自审的盲区让一个 Agent 写完代码再让它自己审。结果往往自己放行自己。它顺着刚写的思路找通过看不见当初的漏洞。这和自己改自己作业一样。视角的单一注定审不出深层问题。质量需要第二双、第三双眼睛。多智能体评审是把审查拆成独立视角。安全视角、性能视角、可维护性视角各看各的。互不共享上下文避免互相迁就。本文探讨多 Agent 的代码评审工作流。二、多视角评审的机制评审按关注点分角色而非按人。安全 Agent 专盯注入、越权、密钥。性能 Agent 专盯 N1、锁竞争、内存。可维护性 Agent 专盯复杂度、重复、命名。每个 Agent 只看自己维度输出该维度的发现。主评审汇总各视角去重后给作者。这样覆盖度远高于单人且互不掩盖。下面是评审的并行关键在视角独立。各 Agent 不读彼此结论避免从众。汇总时再交叉验证剔除误报。三、生产级实现下面用代码描述多视角评审的调度。from dataclasses import dataclass from typing import Callable dataclass class Review: dimension: str findings: list[str] def run_agent(name: str, fn: Callable[[str], list[str]], code: str) - Review: 单维度独立评审互不共享结论避免视角从众 return Review(name, fn(code)) def aggregate(reviews: list[Review]) - list[str]: 汇总去重输出统一意见 seen: set[str] set() out: list[str] [] for r in reviews: for f in r.findings: if f not in seen: seen.add(f) out.append(f[{r.dimension}] {f}) return out def security_scan(code: str) - list[str]: return [检测到拼接 SQL建议参数化] if execute( in code else [] def perf_scan(code: str) - list[str]: return [循环内存在重复查询疑 N1] if for in code else [] if __name__ __main__: code for u in users: execute(fselect * from o where id{u}) revs [ run_agent(安全, security_scan, code), run_agent(性能, perf_scan, code), ] for line in aggregate(revs): print(line)真实系统会给每维度配专属提示与工具。安全维度接 SAST 结果性能维度接 profiling。Agent 做语义补充工具做确定性兜底。四、多智能体评审工作流的代价与边界多视角评审覆盖广但成本显性。算力与延迟。每维度一次模型调用N 维度 N 倍开销。应并行执行且低优先级维度可抽样。不是每次评审都需全维度满跑。维度选择的噪音。维度太多意见碎片化。应聚焦高频风险维度其余按需开启。避免评审报告长而空。误报叠加。多 Agent 各自误报汇总后更吵。汇总时应交叉验证同类问题去重。并标注置信度作者优先看高危。不能替代人审。架构合理性、业务适配模型难判。多 Agent 是扩覆盖不是免人审。关键路径仍要人工终审。多视角评审的责任归属要清楚。多个 Agent 各给意见汇总后若仍漏了关键问题容易变成大家都看了等于没人负责。建议在汇总时给每条发现标注来源维度与置信度最终由主评审人或指定 Agent定夺优先级而非简单堆砌。另一个实践是维度可配置不同变更类型启用不同维度安全变更强开安全视角性能敏感变更强开性能视角避免每次全维度满跑浪费算力。最后评审意见要能一键定位到代码行并支持作者已处理/有异议的回应闭环让评审真正推动修改而非停留在评论区。五、总结多智能体评审本质是用视角分离换覆盖度。机制上每维度独立审、汇总去重避免单一盲区。工程上并行降本、交叉验误、关键留人审。落地路线先定高频风险维度各维度独立跑并配工具汇总去重标置信关键路径人工终审。多双眼睛看代码才少漏洞。资料说明本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论不应视为行业事实。可参考 0730 资料来源索引并在发布前将具体来源贴到对应断言之后。