当前位置：首页 > news >正文

多智能体评审工作流：用角色分工提升代码质量

news 2026/7/30 4:45:24

多智能体评审工作流：用角色分工提升代码质量

一、单 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）定夺优先级，而非简单堆砌。另一个实践是"维度可配置"：不同变更类型启用不同维度，安全变更强开安全视角，性能敏感变更强开性能视角，避免每次全维度满跑浪费算力。最后，评审意见要能一键定位到代码行，并支持作者"已处理/有异议"的回应闭环，让评审真正推动修改而非停留在评论区。