Opponent Processor / Multi-Agent Debate Pattern

单智能体决策可能存在以下问题：

• 证实性偏差：智能体仅寻找支持初始假设的证据
• 视角局限：单个上下文窗口会遗漏替代方案
• 审查不足：缺乏用于捍卫决策的对抗性压力
• 未审视的假设：智能体不会对自身的推理过程提出质疑

生成具有对立目标或视角的对立Agent，让它们就彼此的立场展开辩论。Agent之间的冲突会暴露盲点、偏见以及未被考虑到的替代方案。

核心机制：创建具有对立动机或角色的Agent，让它们互相评判对方的工作，随后综合结果。

graph TD
    A[主任务] --> B[Agent 1: 支持者]
    A --> C[Agent 2: 批评者/审核者]
    B --> D[提出解决方案]
    C --> E[质疑解决方案]
    D --> F[辩论 / 迭代]
    E --> F
    F --> G[综合决策]

示例配置：

• 支持方 vs. 反对方：一个Agent主张采纳方案，另一个主张否决
• 乐观派 vs. 保守派：不同的风险容忍度
• 用户代表 vs. 企业审核员：利益冲突
• 前端开发人员 vs. 后端开发人员：不同的技术视角

实现模式：

1. 定义具有明确激励机制的对立角色
2. 为两个Agent赋予相同的context，但配置不同的系统prompt
3. 让它们独立工作（使用不关联的上下文窗口）
4. 收集它们的输出结果
5. 自动综合结果，或人工审核差异

转录内容中的具体示例（费用报销）：

“我设置了两个子Agent，一个代表我自己，一个代表公司。它们通过‘对抗’来确定合理的实际报销范围。就像是一个审计子Agent和一个支持丹的子Agent。”

其他适用场景：

• 代码评审：作者辩护方 vs 安全审计方
• 架构决策：简洁性倡导者 vs 前瞻性保障倡导者
• 内容审核：言论自由方 vs 安全合规方
• 资源分配：不同部门代表方

历史灵感（来自转录内容）：

早期Reddit论坛的讨论中，有人将子Agent设定为：前端开发、后端开发、设计师、测试开发、产品经理——所有角色围绕实现方案展开辩论。

优点：

• 减少偏见：对立观点可暴露认知盲区
• 决策更优：对抗压力能提升决策质量
• 非关联语境：独立推理避免群体思维
• 权衡关系显性化：迫使各方明确阐述相互冲突的价值取向
• 制衡作用：无单个Agent拥有不受挑战的权威

缺点：

• Token成本翻倍及以上：多个Agent处理相同信息
• 执行速度较慢：相较于单一决策模式，辩论过程耗时更久
• 可能引发冲突：若缺乏解决机制，Agent可能陷入僵局
• 需进行综合整合：需要方法来调和对立观点
• 简单任务过度设计：并非所有决策都需要辩论