让两个（或多个）持对立观点的 agent 就同一问题展开多轮辩论，最后由一个 judge（agent 或人）裁决，或把辩论过程本身作为最终答案的来源。

实时交互场景（→ 用 03 Router 选个合适的模型就够）；简单事实查询（→ 用 07 Ensemble Voting 多次采样更快）；关键链路的生成任务（→ 用 08 Actor-Critic，一生一评，比两个立场互掐更可控）；上下文本来就长的多跳问题（→ debate 的 token 消耗会爆炸，用 17 Plan-and-Execute 更合理）。

我把第一个绕不过的案例放最前。MIT + Google 研究员 Yilun Du 等人的 ICML 2024 论文(arXiv 2305.14325)是所有 debate 研究绕不开的起点。核心实验：让两个 LLM 实例就数学题、化学事实、人物传记等问题展开 2-3 轮辩论。

关键观察：

· 在 MMLU 数学、GSM8K 等基准上，debate 比单次回答的准确率提升明显

· 在 factuality 任务（传记信息、化学事实）上，hallucination 下降

· 论文最核心的框架很朴素：agent A 给出答案 → agent B 给出答案 → 都拿到对方答案后 revise → 多轮后收敛

2025 年 4 月，ICLR 发了一篇官方 blogpost《Multi-LLM-Agents Debate —— Performance, Efficiency, and Scaling Challenges》。作者系统评测了 5 个主流 MAD 框架在 9 个基准上的表现，对比对象是更简单的 CoT 和 self-consistency。

· 核心结论：现有 MAD 方法并不稳定优于这些基线

· 加推理预算（更多轮次、更多 agent）也不能拉开差距 —— 也就是说 MAD 不 scale

· 作者的一个关键分析：LLM 本身对候选答案有偏好，可能让 debater 无法真正“基于 correctness”选择；pre-trained LLM 直接上 MAD 框架，in-context learning 或 SFT 才能真正让它学会 debate

我又追到 2026 年 4 月 Nature Scientific Reports 的一篇研究：在 MAD 里可以注入一个“只会 persuade 不讲事实”的 adversary，加 agent 数、加轮次、加简单的 prompt 防御都救不回来。换句话说：debate 的 robustness 本身是个未解决问题。

有意思的是，在通用推理场景上 debate 被按住的同时，AI safety 社区一直在另一条线上推进。我去年开始追这条线：Geoffrey Irving 2018 年提出“AI safety via debate”,2023 年在 Anthropic 发了 debate progress update,2025 年他在 UK AI Safety Institute 做了一个“prover-predictor game”的 debate 变体，对应解决了之前实验里发现的 obfuscated arguments 问题。

另一头，Anthropic 2025 年发布的《Recommendations for Technical AI Safety Research Directions》明确把 debate 和 prover-verifier games 列进 scalable oversight 的主力手段。2026 年 4 月，Anthropic 又发了一篇《Automated Alignment Researchers》—— 用 LLM 去 scale scalable oversight 本身。

from anthropic import Anthropic client = Anthropic()defargue(position, topic, opponent_last=""):    # 每轮都重新拼 context,双方上下文隔离     ctx = f"你支持 {position}。议题:{topic}。对方上一轮:{opponent_last}"     resp = client.messages.create(         model="claude-sonnet-4-5", max_tokens=768,         messages=[{"role": "user", "content": ctx}]     )    return resp.content[0].textdefjudge(topic, rounds):    # judge 用更强的模型,旁观所有轮次再裁决     resp = client.messages.create(         model="claude-opus-4-7", max_tokens=1024,         messages=[{"role": "user",                   "content": f"议题:{topic}\n辩论:{rounds}\n给结论。"}]     )    return resp.content[0].textdefdebate(topic, n_rounds=3):     rounds, last_pro, last_con = [], "", ""for _ inrange(n_rounds):         last_pro = argue("正方", topic, last_con)         last_con = argue("反方", topic, last_pro)         rounds.append((last_pro, last_con))    return judge(topic, rounds)

我看过的硬伤：① 延迟敏感的产品链路 —— 用户等不了 8-10 秒，把 debate 挪到后台评估环节。

② 我看过被滥用的场景：简单的事实性任务 —— self-consistency 多采样几次投票就够，省一大笔 token。

③ judge 资源受限 —— 其实如果裁判只能用和 debater 同一档的模型，别上 debate，准确率可能反而会掉。

我自己也踩过坑：④ 面对可能被“说服攻击”的场景 —— 老实讲，2026 Nature 那篇指出，对抗性 prompt 能把 debate 整体带偏，目前还没有稳的防御方案。

Debate：双方互相看到对方论点，彼此说服/反驳，judge 裁决。信息流是互通的。

Ensemble Voting：多个 agent 独立作答，不看彼此，最后投票。信息流完全隔离。

区别的本质：debate 利用“对抗”让问题被反复拷问；voting 利用“独立性”让误差彼此抵消。想提高上限用 debate，想压低方差用 voting。

Debate：两方对抗，立场预先被分配。结构是对立。

Round-Robin：我看 Round-Robin：多方（通常 4-5 个角色）按顺序发言，角色往往是职能型的(PM / Dev / QA)。结构是分工。

区别的本质：debate 靠摩擦出结论，round-robin 靠拼装出产物。MetaGPT 的 PM → 架构师 → 工程师是 round-robin，不是 debate；让“正方设计师”和“反方设计师”争论方案才是 debate。

Debate：两个同级 agent 站在对立面，judge 在外圈。对称博弈。

Actor-Critic：一个 agent 生成，另一个专门评审，不参与生成。非对称反馈。

区别的本质：debate 里两方都在“答题”，只是答出不同答案；actor-critic 里一方答题、一方改卷。我用下来的工程经验：评审类任务 actor-critic 更稳；选择类任务（A 还是 B）debate 更有戏。