#多角色评审与辩论式 Agent

#提出问题

多 Agent 不一定都要执行工具。很多时候，它最大的价值是提供多个独立视角。

一个模型写出的方案，看起来可能很完整，但它通常不擅长主动推翻自己。多角色评审的思路是：让不同 Agent 从不同责任出发审查同一个问题，再由仲裁者收束。

这类系统常被称为 debate、critique、review board 或 council。它适合辅助决策，但不适合无限讨论。

#场景

看一个产品团队准备上线 AI 客服自动回复。

候选方案是：

对低风险工单自动生成回复并直接发送；高风险工单转人工。

如果只让一个 Agent 评估，它可能会给出平衡但泛泛的建议。多角色评审可以拆成：

这里的 Agent 不一定需要工具。它们的任务是提出风险、反例、缺失信息和修改建议。

#分析问题

#多角色评审适合什么

多角色评审适合“需要判断和取舍”的问题，而不是“直接执行”的问题。

它的价值不是多数投票，而是提高问题暴露率。一个 Security Agent 提出的阻断风险，可能比四个 Agent 的赞同更重要。

#角色设计

角色不是人格标签，而是评审标准。

一个有效角色要定义：

• 它代表什么责任。
• 它必须检查哪些风险。
• 它不能讨论哪些无关内容。
• 它的输出格式。
• 它是否有阻断权。

例如 Security Agent 的输出不应该是泛泛说“注意安全”，而应该按风险分类：

{
  "blockingRisks": [
    {
      "risk": "自动回复可能泄露其他租户数据",
      "evidence": "方案没有说明知识库检索的租户权限过滤",
      "requiredChange": "在检索层加入 tenantId 过滤并记录引用来源"
    }
  ],
  "nonBlockingSuggestions": [],
  "questions": []
}

#辩论不是自由聊天

辩论式 Agent 最容易失控。多个模型轮流发言，如果没有结构，常见结果是：

• 重复观点。
• 为了显得有贡献而制造小问题。
• 被前一个 Agent 带偏。
• 讨论越来越抽象。
• 成本快速上升。

更稳的方式是结构化轮次：

1. 各角色独立评审，不互相看结论。
2. Arbiter 合并问题，去重、分级。
3. 必要时只针对冲突点开启第二轮。
4. 最终输出决策建议和必须修改项。

#收益和成本判断

收益：

• 提高风险发现率。
• 让不同责任视角同时进入决策。
• 减少单 Agent 自我确认。
• 适合作为上线门禁和设计评审辅助。

成本：

• 需要维护角色标准。
• 调用成本随角色数量增长。
• 需要去重和仲裁。
• 评审意见可能过度保守。
• 不能替代真实测试、权限校验和人工责任。

#列举方案

#独立评审

最推荐的基础形态是独立评审。

同一份方案 -> 多个 Reviewer 独立输出 -> Arbiter 合并

每个 Reviewer 不看其他人的意见，避免互相影响。适合安全、合规、PR Review 和产品方案评审。

#反方 Agent

有时只需要一个强反方角色。

Proposal Agent -> Critic Agent -> Revision Agent

Critic 的任务不是平衡评价，而是专门找失败样本、反例和不可上线条件。适合方案早期打磨。

#多轮辩论

当问题本身存在重大取舍，可以进行有限轮辩论。

Round 1: 各自提出观点
Round 2: 只回应冲突点
Round 3: Arbiter 总结可执行决策

轮次必须有限，且每轮都有明确问题。不要让 Agent 自由讨论到“达成共识”。

#红队评审

安全、合规、Prompt Injection 和 Agent 工具风险适合红队评审。

红队 Agent 的目标是找攻击路径，不是给产品建议。它应该输出可复现风险：

• 攻击输入。
• 触发路径。
• 影响范围。
• 阻断建议。
• 是否必须上线前修复。

#PR Review Board

代码场景可以设计多个 Reviewer：

• Correctness Reviewer：行为是否正确。
• Security Reviewer：权限、注入、数据泄漏。
• Performance Reviewer：复杂度、缓存、查询。
• Maintainability Reviewer：边界、可读性、测试。

最终由 Arbiter 只保留高信号问题，避免把风格偏好当阻断项。

#决策判断

#方案选型表

#反模式

第一种反模式：用多数投票代替判断。

多 Agent 不是民主投票。一个高置信阻断风险可能推翻多个“看起来可以”的意见。

第二种反模式：角色定义成性格。

“你是严谨的人”“你是乐观的人”不如“你负责检查租户隔离、敏感字段、日志脱敏和工具越权”有效。

第三种反模式：让 Reviewer 直接修改产物。

评审和执行最好分开。Reviewer 输出问题和建议，是否修改由主流程决定。

第四种反模式：无限辩论。

没有轮次、议题和停止条件的辩论会消耗成本，还可能让结论越来越模糊。

第五种反模式：只保留最终综合意见。

合并后的结论要保留关键原始证据。否则人类无法判断 Arbiter 是否误删了重要风险。

#结论收束

多角色评审的价值，是让系统在执行前暴露更多盲点。

它适合方案评审、上线门禁、PR Review、安全红队和产品决策。它不应该替代测试、权限、审批和人类责任，也不应该演变成无边界讨论。

#工程清单

• 角色标准：每个 Reviewer 的责任和检查项是否明确。
• 独立性：首轮评审是否避免互相影响。
• 输出格式：风险、证据、建议、优先级是否结构化。
• 阻断规则：什么问题必须阻断上线或执行。
• 仲裁策略：Arbiter 如何去重、分级和保留少数意见。
• 轮次限制：是否限制讨论轮数和每轮议题。
• 证据保留：综合结论是否保留关键原始意见。
• 噪音控制：是否过滤风格偏好和低置信建议。
• 人工复核：高风险结论是否进入人工确认。
• Eval：是否统计 Reviewer 命中真实问题的能力。