💬 Debate/讨论模式
1. 多Agent辩论提升决策质量
Debate模式是一种通过多Agent对抗性讨论来提升决策质量的高级协作范式。 与Orchestrator-Worker的单向分配不同，Debate模式让多个Agent从不同立场出发、相互质疑和论证， 通过辩论过程暴露盲点、消解偏见，最终达成更可靠、更全面的结论。
🔬 为什么辩论有效？
LLM作为单Agent做决策时存在固有局限：
- 确认偏误：倾向于寻找支持已有观点而非反对观点的证据
- 表面推理：缺乏深度对抗性思考，容易满足于第一反应
- 视角单一：受限于单一模型的训练数据和推理路径
辩论模式通过多视角对抗，迫使每个Agent反思和修正自己的观点，显著提升推理深度和结论可靠性。
2. 角色设定
Debate模式中，每个Agent被赋予明确的对立角色，从不同立场出发参与讨论：
| 角色 | 职责 | 行为特征 | System Prompt要点 |
|---|---|---|---|
| 🗣️ 正方 (Proposer) | 提出方案或观点，为方案的优越性辩护 | 主动、乐观、积极论证 | "你是方案倡导者，坚定地论证方案P的优势..." |
| 🔍 反方 (Opposer) | 质疑正方的论证，寻找漏洞和风险 | 批判、审慎、深挖弱点 | "你是批判性审查者，找出方案P中的任何缺陷..." |
| ⚖️ 裁判 (Judge) | 综合双方论点，做出最终裁决 | 中立、权衡、结构化判断 | "你是公正的裁判，依据双方论证做出最优决策..." |
| 📝 记录员 (Scribe) | 记录辩论过程，确保关键论点不被遗漏 | 客观、完整、结构化记录 | "你负责记录辩论的关键论点和论据，不参与论证..." |
根据场景需要，还可以引入更多角色：
🎭 扩展角色
| 角色 | 适用场景 | 作用 |
|---|---|---|
| Domain Expert (领域专家) | 技术/法律/医学等专业领域 | 提供权威事实性信息和领域规范 |
| Devil's Advocate (魔鬼代言人) | 高风险决策 | 故意提出极端反面观点，压力测试决策 |
| User Advocate (用户代言人) | 产品/体验决策 | 从终端用户视角提出期望和顾虑 |
| Ethics Reviewer (伦理审核) | 涉及伦理的决策 | 从道德、合规、公平性角度审查 |
3. 辩论流程设计
一个结构化的辩论流程是Debate模式成功的关键。过于松散的辩论可能发散失控，过于严格则失去灵活性：
🔄 标准辩论流程
| 轮次 | 阶段 | 参与者 | 输出 |
|---|---|---|---|
| R0 | 问题定义 & 双方初始立场 | Judge + Proposer + Opposer | 明确的议题 + 双方初始论点 |
| R1 | 正方论证 | Proposer | 详细论证方案优点，附支持证据 |
| R2 | 反方质疑 | Opposer | 逐一质疑正方论点，提出反证 |
| R3 | 正方回应 | Proposer | 回应质疑，修正或强化论点 |
| R4 | 反方最终陈述 | Opposer | 总结核心风险和建议 |
| Final | 裁判裁决 | Judge | 综合裁决 + 理由 + 改进建议 |
4. 共识达成机制
辩论的最终目标不是"分出胜负"，而是达成最优决策。共识达成需要结构化的机制：
| 机制 | 描述 | 适用场景 | 风险 |
|---|---|---|---|
| 裁判裁定 | 裁判综合双方论点做出最终决定 | 多数场景（最常用） | 裁判可能产生偏见 |
| 加权评分 | 对决策的多维度设立评分标准，正反方各自打分 | 可量化的决策（如技术选型） | 评分标准本身可能引发争议 |
| 协商修正 | 正反方协商出一个折中方案 | 双方分歧并非不可调和时 | 可能产生平庸的折中 |
| 二次辩论 | 第一轮未达成共识，调整议题后重新辩论 | 复杂议题需要多轮讨论 | 时间和Token消耗大 |
| 人工介入 | 自动辩论无法达成共识，升级到人类决策者 | 高风险、高影响力决策 | 引入延迟，削弱自动化优势 |
⚡ 防止辩论失控
- 设置轮次上限：建议3-5轮，超过上限自动触发裁决
- 论点重复检测：当检测到双方开始循环重复相同论点时，触发裁判干预
- Token预算控制：设置辩论的总Token上限，避免成本失控
- 分歧度监控：当双方分歧度不再缩小（收敛停滞）时，及时终止辩论
5. 辩论模式典型场景
| 场景 | 辩论对象 | 参与角色 | 预期收益 | 轮次建议 |
|---|---|---|---|---|
| 技术方案评审 | 架构方案A vs B | Proposer(A) + Proposer(B) + Judge | 暴露各方案的风险和隐性成本 | 3轮 |
| 代码Review增强 | 代码变更的合理性 | Author + Reviewer + Judge | 深度发现潜在bug和设计缺陷 | 2轮 |
| 安全风险评估 | 系统变更的安全性 | Proposer + Security Expert + Devil's Advocate | 发现被忽视的攻击面和威胁 | 3轮 |
| 产品需求优先级 | 需求A > B > C 的排序 | PM(A) + PM(B) + PM(C) + Judge | 平衡多方利益，减少主观偏见 | 3-4轮 |
| 策略决策 | 市场策略方向选择 | Proposer(方向1) + Proposer(方向2) + Judge | 多角度评估市场机会与风险 | 3-5轮 |
| 创意头脑风暴 | 多个创意的优劣 | 多个Creative Agent + Moderator | 碰撞产生更优质的创意 | 动态 |
💡 Debate模式最佳实践
- 从简单开始：先用正方+反方+裁判的三角色最小配置，验证效果后再扩展
- 裁判需有领域知识：裁判角色应注入足够的领域背景，否则难以做出有质量的裁决
- 保持结构化输出：要求每个Agent使用统一格式（论点+证据+置信度），便于裁判横向对比
- 记录辩论过程：将辩论记录作为决策依据存档，便于审计和改进
- 与Orchestrator-Worker结合：在Orchestrator决策关键节点引入Debate，提高决策质量