辩论/竞争模式（Debate & Competition）

辩论/竞争模式（Debate & Competition）

模式概述

辩论/竞争模式是一种多 Agent 协作范式：多个 Agent 同时接收同一个问题，各自独立作答，然后互相看到对方的观点并展开质证。经过若干轮"提出→质疑→修正"的迭代后，通过投票或裁判机制产出最终答案。

一句话概括：让多个 Agent 像辩论赛一样对同一问题互相质证，用集体博弈代替单点判断，降低幻觉和推理错误。

这个思路最早由 Du 等人在 2023 年的论文 Improving Factuality and Reasoning in Language Models through Multiagent Debate（发表于 ICML 2024）中系统提出。核心发现是：让多个 LLM 实例各自提出答案并经过多轮辩论，在数学推理和事实验证任务上的准确率显著优于单模型。此后衍生出多个变体：MAD（Multi-Agent Debate，由 Liang 等人提出，强调发散思维）、ChatEval（用辩论做文本评估）、Free-MAD（无共识辩论，减少从众效应）等。

在 Agent 设计模式体系中，辩论模式属于多 Agent 协作模式的分支，与 Master-Worker（层级制分工）和 Handoff（顺序传递）并列。它的独特价值在于对抗性验证——Agent 之间不是分工合作，而是互相挑战，用竞争来提高输出质量。

核心模块

辩论模式由四个核心模块协作运行：

模块 1：角色初始化器

角色初始化器负责为每个 Agent 赋予不同的"思维方式"。辩论模式的有效性高度依赖 Agent 之间的差异性——如果所有 Agent 用相同的提示词，它们大概率会给出类似的错误答案，辩论就失去意义。

常见的角色分配策略：

• 视角差异：保守型 / 乐观型 / 批判型
• 专业差异：不同领域的专家（如经济学家 / 工程师 / 法律顾问）
• 思维差异：逻辑推理型 / 直觉判断型 / 证据核查型

模块 2：观点生成器

观点生成器是辩论的主体。在第一轮中，每个 Agent 独立回答问题；在后续轮次中，每个 Agent 会看到其他 Agent 的观点，然后决定是坚持自己的答案、修改答案，还是提出反驳。

关键设计点：每个 Agent 需要同时看到其他所有 Agent 的观点，而不是只看到部分信息。这样才能形成完整的信息对称博弈。

模块 3：收敛检测器

收敛检测器（Convergence Detector）判断辩论是否应该结束。常用的终止条件：

• 共识达成：所有 Agent 的答案趋于一致
• 轮数上限：通常设为 3-5 轮，超过后强制结束
• 论证停滞：连续两轮没有 Agent 改变观点

模块 4：决策聚合器

决策聚合器（Decision Aggregator）负责从多个最终观点中产出一个答案。常见的聚合策略：

• 多数投票（Majority Voting）：最多 Agent 支持的答案胜出，简单但容易被集体错误误导
• 加权投票（Weighted Voting）：根据 Agent 在辩论中的表现动态调整权重
• 裁判制（Judge）：由一个独立的裁判 Agent 或规则评估所有观点，选出最合理的答案

架构图

流程说明：

• 问题同时发送给所有 Agent，每个 Agent 独立生成初始观点
• 每轮辩论中，Agent 查看其他 Agent 的观点后更新自己的答案
• 收敛检测器决定继续辩论还是终止
• 终止后由决策聚合器产出最终答案

工作流程

1. 步骤 1（角色分配）： 为每个 Agent 设置不同的系统提示词，赋予差异化的角色。同时将待讨论的问题广播给所有 Agent。
2. 步骤 2（初始作答）： 每个 Agent 独立思考问题，生成第一轮观点。此时 Agent 之间互不可见。
3. 步骤 3（质证辩论）： 向每个 Agent 展示其他 Agent 的观点，Agent 需要评估对方的论点，决定是接受、修改还是反驳。每个 Agent 输出更新后的观点。
4. 步骤 4（收敛检测）： 检查所有 Agent 的答案是否趋于一致，或是否达到最大轮数。如果未满足终止条件，回到步骤 3 继续下一轮辩论。
5. 步骤 5（决策聚合）： 辩论结束后，通过投票、加权或裁判机制产出最终答案，附带主要论据来源。

循环终止条件：答案收敛（所有 Agent 一致）、达到轮数上限（通常 3-5 轮）、或论证停滞（连续两轮无变化）。

执行示例

问题："Python 和 Go 哪个更适合构建高并发微服务？"

第 1 轮（独立作答）：

• Agent A（保守型工程师）："Go 更适合。原生 goroutine 支持高并发，编译成二进制文件部署简单，内存占用低。"
• Agent B（创新型架构师）："Python 配合 FastAPI + asyncio 也能处理高并发，而且开发效率更高、生态更丰富。"
• Agent C（批判型审计师）："两个回答都忽略了关键上下文：团队技术栈是什么？当前的并发量级是多少？没有这些信息，任何推荐都不完整。"

第 2 轮（质证辩论）：

• Agent A（回应 C）："同意需要看具体场景。但如果只看高并发本身，Go 的并发性能确实优于 Python。我补充一点：Go 在 10 万级并发连接时的内存占用大约是 Python 的 1/5。"
• Agent B（修正观点）："Agent A 的性能数据有说服力。我调整观点：如果并发量级在万级以上，Go 是更好的选择；如果并发量级在千级以下且开发速度优先，Python + FastAPI 是更务实的选择。"
• Agent C（总结）："现在两个观点已经不再对立：高并发选 Go，中低并发且重开发效率选 Python。分界线大约在万级并发。"

第 3 轮（共识达成）： 三个 Agent 都接受了"按并发量级选择"的结论，辩论终止。

最终答案："万级以上并发选 Go（性能优势明显），千级以下并发且重视开发效率选 Python + FastAPI。关键决策因素是实际并发量级和团队技术栈。"

适用场景

适合的场景

1. 需要多角度分析的决策任务：市场分析、产品方案评估、投资决策——不同视角的 Agent 各有侧重，讨论能覆盖更全面的考量。
2. 事实验证与知识问答：新闻核查、医学诊断辅助、法律风险评估——多个 Agent 独立判断后交叉验证，降低单模型的幻觉风险。
3. 复杂推理任务：数学问题求解、代码 Bug 定位、论文审稿——研究表明多 Agent 辩论在数学推理上的准确率比单 Agent 高 15-20%。
4. 高风险场景：合规审查、安全评估——批判型 Agent 能主动挑战乐观假设，发现潜在风险。

不适合的场景

1. 需要快速响应的场景：客服对话、实时翻译——多轮辩论增加 10-30 秒延迟，无法满足实时性要求。
2. 答案明确无歧义的场景："1+1 等于几""北京是哪个国家的首都"——没有讨论空间，辩论只是浪费资源。
3. 成本敏感的场景：辩论模式的 LLM 调用量约为单 Agent 的 3-5 倍（Agent 数 x 轮数），大规模部署时成本显著。
4. Agent 差异不足的场景：如果所有 Agent 使用完全相同的提示词，辩论退化为"多个副本重复同一个错误"，甚至因从众效应加剧错误。ICLR 2025 的研究指出，同质化 Agent 群体中的辩论可能导致准确率下降。

典型实现

以下伪代码展示辩论模式的核心机制：

# 辩论模式核心循环伪代码

def debate(question, agent_configs, max_rounds=3):
    """多 Agent 辩论主循环"""
    # 步骤 1：初始化 Agent，每个 Agent 有不同的系统提示词
    agents = [
        {"name": cfg["name"], "prompt": cfg["system_prompt"], "opinion": ""}
        for cfg in agent_configs
    ]

    # 步骤 2：第一轮——各自独立作答
    for agent in agents:
        agent["opinion"] = llm.generate(
            system=agent["prompt"],
            user=f"请回答以下问题：\n{question}"
        )

    # 步骤 3-4：多轮质证辩论
    for round_num in range(2, max_rounds + 1):
        for agent in agents:
            # 收集其他 Agent 的观点
            others = "\n".join(
                f"- {a['name']}: {a['opinion']}"
                for a in agents if a["name"] != agent["name"]
            )
            # 让 Agent 看到他人观点后更新自己的答案
            agent["opinion"] = llm.generate(
                system=agent["prompt"],
                user=f"其他人的观点：\n{others}\n\n请评估并更新你的答案。"
            )

        # 收敛检测（简化实现：检查答案是否一致）
        if all_opinions_converged(agents):
            break

    # 步骤 5：决策聚合——多数投票或裁判
    return aggregate(agents)

代码中的核心结构：外层循环控制辩论轮次；内层循环让每个 Agent 看到其他人的观点后更新自己的答案；all_opinions_converged 做收敛检测；aggregate 做最终决策聚合。实际项目中，llm.generate 替换为具体的 LLM API 调用。

优劣势分析

边界说明：辩论模式的收益在"有歧义、需要权衡"的问题上最大。对于答案明确的问题，额外开销没有回报。另外，ICLR 2025 的一项研究（Zhang 等人）指出，当前的 MAD 方法在多个基准测试上并未稳定超过简单的单 Agent 策略，实际效果高度依赖任务类型和 Agent 配置。

与相关模式的对比

选择建议：需要高可靠性判断时选辩论模式；任务可拆分成子任务时选 Master-Worker；任务有清晰的阶段划分时选 Handoff。

常见误区

思考题

参考资料

1. Du, Y., Li, S., Torralba, A., Tenenbaum, J. B., & Mordatch, I. (2024). "Improving Factuality and Reasoning in Language Models through Multiagent Debate." ICML 2024. https://arxiv.org/abs/2305.14325
2. Liang, T., He, Z., Jiao, W., et al. (2023). "Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate." arXiv:2305.19118. https://arxiv.org/abs/2305.19118
3. Zhang, H., Cui, Z., et al. (2025). "Multi-LLM-Agents Debate - Performance, Efficiency, and Scaling Challenges." ICLR Blogposts 2025. https://iclr-blogposts.github.io/2025/blog/mad/
4. Wynn, A., Satija, H., & Hadfield, G. (2025). "Talk Isn't Always Cheap: Understanding Failure Modes in Multi-Agent Debate." arXiv:2509.05396. https://arxiv.org/abs/2509.05396
5. Multi-Agent Debate 代码仓库（ICML 2024）: https://github.com/composable-models/llm_multiagent_debate