多智能体评审工作流:用角色分工提升代码质量
一、单 Agent 自审的盲区
让一个 Agent 写完代码,再让它自己审。
结果往往"自己放行自己"。
它顺着刚写的思路找通过,看不见当初的漏洞。
这和"自己改自己作业"一样。
视角的单一,注定审不出深层问题。
质量需要第二双、第三双眼睛。
多智能体评审,是把审查拆成独立视角。
安全视角、性能视角、可维护性视角,各看各的。
互不共享上下文,避免互相迁就。
本文探讨多 Agent 的代码评审工作流。
二、多视角评审的机制
评审按"关注点"分角色,而非按人。
安全 Agent 专盯注入、越权、密钥。
性能 Agent 专盯 N+1、锁竞争、内存。
可维护性 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 ["循环内存在重复查询,疑 N+1"] if "for " in code else [] if __name__ == "__main__": code = "for u in users: execute(f'select * 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 资料来源索引,并在发布前将具体来源贴到对应断言之后。