多智能体辩论框架横向对比

围绕「让两个 LLM Agent 就一个话题打辩论」这一需求,深度对比 4 个开源项目的架构、代码、可维护性与适用场景,并附一场实跑辩论 Demo。

对比项目 4 数据采集 2026-07-09 实跑辩论 Demo 部署 Cloudflare Pages

速览对比

一眼看清 4 个项目的关键差异。数据来自 GitHub API 实时抓取与源码阅读。

维度 cultural_debate DebateBox MAD AutoGen
定位学术论文复现(文化对齐)概念演示/原型学术研究(思维发散)通用多Agent框架
Star ⭐9159659,602
Agent 数2(无裁判)可配(默认3)3(正/反/主持)+兜底Judge2+可选Judge
有裁判机制有(Moderator+Judge)有(可配)
LLM 后端本地 transformers仅 OpenAI(旧SDK)仅 OpenAI(旧SDK)OpenAI/Anthropic/本地
License未声明Apache-2.0GPL-3.0MIT
最近更新2026-042023-06停滞2025-012026-04维护模式
在线 Demo已下线Colab + Studio
代码量中等(21个组合文件)极小(~200行)小(~250行)大(框架级)
上手难度
一句话结论: 想要「两个 Agent 辩论」的最小可运行实现,看 MADDebateBox;想要通用、可扩展、长期用的框架,看 AutoGen;做学术复现(文化/公平性)看 cultural_debate

① cultural_debate

ACL 2025 Oral 配套代码 —— 让两个开源小模型辩论,在文化对齐任务上达到大模型效果。

9 stars ⑂ 5 forks Python ACL 2025 Oral 更新 2026-04 License: 未声明
一句话
让两个 7-9B 开源 LLM 互相辩论反馈,在 NORMAD-ETI 文化礼仪任务上,小模型组合可逼近 27B 大模型的准确率与公平性。
核心发现
多 Agent 辩论既提升整体准确率,又改善跨文化群体公平性(parity);README 提"judge LLM"但实际代码无独立裁判,两 Agent 各自给最终答案。
辩论流程
固定 6 步串行:① 正方初判 → ② 反方初判 → ③ 正方给反馈 → ④ 反方给反馈 → ⑤ 正方终判 → ⑥ 反方终判
LLM 后端
纯本地推理,transformers + torch,需多 GPU 同时加载两个模型;temperature=0 确定性输出
数据集
内置 NORMAD-ETI(75 国、2.6K 条社交礼仪故事,三元分类 Yes/No/Neither)

核心代码:6 步辩论主循环

multi_llm/gemma_seallm.py
# [1] 正方初判
prompt1_1 = prompts["prompt_1"].replace("{{story}}", story)
outputs = model1.generate(**tokenizer1(prompt1_1, return_tensors="pt").to("cuda"),
                          max_new_tokens=1024, temperature=0.0)
generation1_1 = parse_response(tokenizer1.decode(outputs[0]), "Answer:")

# [3] 正方看到反方答案后给反馈
prompt1_2 = prompts["prompt_2"].replace("{{other_response}}", generation2_1) \
                               .replace("{{your_response}}", generation1_1)

# [5] 正方综合反馈后给最终答案
prompt1_3 = prompts["prompt_3"].replace("{{feedback}}", generation2_2)
generation1_3 = parse_final_answer(generation1_3)  # 归一化为 Yes/No/Neither

line["gemma_final"] = generation1_3
line["seallm_final"] = generation2_3

✓ 优点

  • 顶会论文配套,学术可信度高
  • "小模型辩论≈大模型"的结论有启发
  • 单文件结构清晰,易读
  • 内置数据集,开箱即跑

✗ 缺点

  • 无 License,法律复用受限
  • 无 requirements.txt,环境靠手猜
  • 需多 GPU,硬件门槛高
  • 21 个组合文件大量重复,难维护
  • 仅文化对齐单一任务,非通用框架
  • 无在线 demo

② DebateBox

~200 行的最小辩论实现,融合 Constitutional AI 的自我批评机制。

1 star ⑂ 0 forks Jupyter/Python Apache-2.0 更新 2023-06 停滞3年
一句话
借鉴 Anthropic Constitutional AI,让多个带人设的 GPT 角色接力辩论,每轮先自我批评再修订。
角色系统
预定义 8 个角色(3 个科学家 + 哲学家 + 煽动者 + 主持人 + 2 玩家),每个角色有独立 character(人设)和 principles(批评原则)
辩论流程
种子消息触发 → 第一个角色回复 → 视角切换(assistant 回复改写成 user 消息传给下一个)→ 每个角色执行 critique + revision 两步自我改进 → 循环 max_rounds 轮
调度模式
3 种:sequential(顺序)/ random_no_repeat(随机不重复)/ random_with_replacement(随机可重复)
LLM 后端
仅 OpenAI 旧版 SDK(openai<1.0 的 ChatCompletion.create),默认 gpt-4,temperature=1.0

核心代码:辩论主循环 + 视角切换

src/debate.py
def debating_loop(self, seed_message, max_rounds, steps, mode):
    for debater in self.protagonists[1:]:
        debater.append_to_chat(seed_message)
    msg = seed_message
    for _ in range(max_rounds):
        if mode == "sequential":
            debaters = self.protagonists
        elif mode == "random_no_repeat":
            debaters = random.sample(self.protagonists, k=len(self.protagonists))
        for debater in debaters:
            # 回复的 role 是 "assistant",传给下一个 agent 前被改成 "user"
            msg = self.debating_step(msg, debater, steps)

def debating_step(self, input_msg, character, steps):
    input_msg["role"] = "user"        # 视角切换
    output_msg = character.reply(input_msg, steps=steps)
    return output_msg

核心代码:Constitutional AI 自我改进

src/chatbox.py
def reply(self, user_msg, steps=["critique", "revision"]):
    self.chat_step(user_msg)              # 先正常回复
    refined = self.self_improve(steps)    # 再自我批评+修订
    return refined

def self_improve(self, steps):
    for principle in self.principles:
        if "critique" in steps:
            self.chat_step({"role":"user","content": principle["critique"]})
        if "revision" in steps:
            self.chat_step({"role":"user","content": principle["revision"]})
    return self.chat[-1]

✓ 优点

  • 代码极简(~200行),最适合教学/入门
  • 融合 Constitutional AI,有自我批评深度
  • 角色 + 原则可配置,扩展简单
  • 3 种调度模式可实验
  • Docker 开箱即用

✗ 缺点

  • 3 年未更新,基本停滞
  • 仅支持 OpenAI,且用废弃旧版 SDK
  • 无 Web UI / 无在线 demo
  • 无胜负裁决/共识达成机制
  • 无 requirements.txt
  • 上下文截断粗暴,长辩论丢信息

③ MAD (Multi-Agents-Debate)

多智能体辩论的"开山之作",提出针对"思维退化"的针锋相对机制。

596 stars ⑂ 65 forks Python GPL-3.0 论文 arXiv:2305.19118 更新 2025-01
一句话
首个探索 LLM 辩论能力的工作。针对 self-reflection 的"思维退化(DoT)"问题,让多个 agent 处于"针锋相对"状态互为外部反馈。
核心角色
正方(Affirmative/"魔鬼") + 反方(Negative/"天使") + 主持人(Moderator) + 兜底 Judge(裁判)
辩论流程
正方陈述 → 反方异议 → 主持人裁决(输出JSON) → 若无定论继续轮 → max_round 用尽则 Judge 兜底选最终答案
早停机制
Moderator 一旦给出非空 debate_translation 即结束(默认 max_round=3)
记忆设计
每个 agent 维护私有 memory_lst(只含自己视角的历史),保证视角隔离
在线 Demo
曾有 Gradio 翻译 demo,但临时链接已下线(404);可本地 python interactive.py 交互

核心代码:辩论主循环 + Judge 兜底

code/debate4tran.py → Debate.run()
def run(self):
    for round in range(self.max_round - 1):
        if self.mod_ans["debate_translation"] != '':
            break  # 主持人已定论,早停
        # 正方读到反方上轮发言后反驳
        self.affirmative.add_event(
            self.save_file['debate_prompt'].replace('##oppo_ans##', self.neg_ans))
        self.aff_ans = self.affirmative.ask()
        self.affirmative.add_memory(self.aff_ans)
        # 反方反驳
        self.negative.add_event(
            self.save_file['debate_prompt'].replace('##oppo_ans##', self.aff_ans))
        self.neg_ans = self.negative.ask()
        self.negative.add_memory(self.neg_ans)
        # 主持人裁决
        self.moderator.add_event(self.save_file['moderator_prompt']
            .replace('##aff_ans##', self.aff_ans)
            .replace('##neg_ans##', self.neg_ans))
        self.mod_ans = eval(self.moderator.ask())  # ⚠️ eval 解析 JSON

    if self.mod_ans["debate_translation"] == '':
        # 终极杀招:Judge 兜底
        judge = DebatePlayer(model_name=self.model_name, name='Judge', ...)
        judge.add_event(self.save_file['judge_prompt_last1']
            .replace('##aff_ans##', aff_ans).replace('##neg_ans##', neg_ans))
        ans = eval(judge.ask())

核心代码:Agent 私有记忆封装

code/utils/agent.py
class Agent:
    def __init__(self, model_name, name, temperature, sleep_time=0):
        self.memory_lst = []  # 私有记忆,只含自己视角

    def add_event(self, event):    # 当前轮上下文(user)
        self.memory_lst.append({"role": "user", "content": f"{event}"})
    def add_memory(self, memory):  # 持久记忆(assistant)
        self.memory_lst.append({"role": "assistant", "content": f"{memory}"})

    @backoff.on_exception(backoff.expo, (RateLimitError, APIError), max_tries=20)
    def query(self, messages, max_tokens, api_key, temperature):
        response = openai.ChatCompletion.create(...)  # 旧版 SDK
        return response['choices'][0]['message']['content']

✓ 优点

  • 领域开山之作,论文可溯源
  • 架构精巧:Moderator 早停 + Judge 兜底
  • 私有记忆隔离视角,设计合理
  • ~250 行,代码极简易读
  • GPL-3.0,License 明确
  • 有交互脚本 interactive.py

✗ 缺点

  • 依赖严重过时(旧版 openai SDK + 已下线模型)
  • eval() 解析 LLM 输出,极脆弱
  • API key 需硬编码,无环境变量管理
  • 核心代码 2023 年后基本无更新
  • 仅翻译/QA 两类任务,扩展需自写 prompt
  • 在线 demo 已下线

④ AutoGen (Multi-Agent Debate 模式)

微软出品的通用多 Agent 框架,近 6 万 Star,官方提供 debate 设计模式。⚠️ 已进入维护模式。

59,602 stars ⑂ 8,973 forks Python MIT ~533 贡献者 更新 2026-04 维护模式
一句话
微软开源的通用多 Agent 编排框架,官方文档专设「Multi-Agent Debate」设计模式,支持 Core 手写与 AgentChat 高层两种实现路径。
⚠️ 重要状态
AutoGen 已进入维护模式,不再有新功能,微软转向新的 Microsoft Agent Framework(MAF)。用于生产需评估迁移成本。
双层 API
Core(底层、事件驱动、异步,debate 官方示例用此) + AgentChat(高层、GroupChat/Selector 即开即用)
debate 架构
每个辩论方是一个 RoutedAgent,通过自定义消息协议(AnswerMessage / CritiqueMessage)通信,Runtime 负责消息路由
LLM 后端
OpenAI / Azure OpenAI / Anthropic / 本地模型,多后端支持
在线 Demo
官方文档含 Open in Colab + AutoGen Studio 可视化拖拽

核心代码:Core API 实现两 Agent 辩论

官方文档示例(简化骨架)
from autogen_core import (AgentId, MessageContext, RoutedAgent,
    SingleThreadedAgentRuntime, message_handler, type_subscription)
from autogen_ext.models.openai import OpenAIChatCompletionClient

# 1. 定义消息协议
@dataclass
class AnswerMessage:
    content: str
@dataclass
class CritiqueMessage:
    content: str

# 2. 定义辩论 Agent
@type_subscription("debate")
class DebateAgent(RoutedAgent):
    def __init__(self, model_client, system_message, max_rounds=3):
        super().__init__("Debate Agent")
        self._model_client = model_client
        self._system_message = system_message
        self._max_rounds = max_rounds
        self._round = 0

    @message_handler
    async def handle_answer(self, message: AnswerMessage, ctx):
        # 收到对方答案 → 生成批评
        self._round += 1
        return [CritiqueMessage(content=critique_text)]

    @message_handler
    async def handle_critique(self, message: CritiqueMessage, ctx):
        if self._round >= self._max_rounds:
            return []  # 结束
        return [AnswerMessage(content=revised_answer)]  # 修正后回击

# 3. 注册并运行
async def main():
    runtime = SingleThreadedAgentRuntime()
    model = OpenAIChatCompletionClient(model="gpt-4o")
    await DebateAgent.register(runtime, "Affirmative",
        lambda: DebateAgent(model, "You argue the affirmative side."))
    await DebateAgent.register(runtime, "Negative",
        lambda: DebateAgent(model, "You argue the negative side."))
    await runtime.start()
    await runtime.send_message(AnswerMessage(content="..."), AgentId("Affirmative","debate"))

✓ 优点

  • 生态最成熟,近 6 万 Star,533+ 贡献者
  • 官方专设 debate 设计模式文档 + Colab
  • Core + AgentChat 双路径,灵活度最高
  • 多模型后端支持
  • 消息协议 + runtime 路由,架构最"正统"
  • AutoGen Studio 可视化搭建

✗ 缺点

  • 已进入维护模式,最大风险
  • 学习曲线陡峭(Core 异步+消息协议)
  • 生态碎片化(0.2 vs 0.4,Studio 版本冲突)
  • debate 官方示例偏底层,代码量大
  • 框架重,仅要"两个agent辩论"有点杀鸡用牛刀

打分对比

从 6 个维度横向打分(满分 10)。基于实际调研,非主观偏好。

cultural_debate

代码可读性
7.0
易上手
5.0
功能完整
4.0
维护活跃
6.0
通用性
3.0
社区规模
1.0

DebateBox

代码可读性
9.0
易上手
7.0
功能完整
5.0
维护活跃
1.0
通用性
4.5
社区规模
0.5

MAD

代码可读性
8.5
易上手
6.5
功能完整
7.5
维护活跃
4.0
通用性
5.0
社区规模
6.0

AutoGen

代码可读性
6.0
易上手
3.5
功能完整
9.5
维护活跃
5.5
通用性
9.5
社区规模
10
解读: 没有全能选手。MAD 在"小而美"维度最均衡;DebateBox 代码最易读但已死;AutoGen 功能最全但偏重且进入维护模式;cultural_debate 仅适合特定学术场景。

实跑辩论 Demo

以下是一场真实运行的两角色辩论,话题为「AI 是否会取代人类的工作」,3 轮交锋 + 主持人总结。演示了正反方如何互相质询、修正观点,最终收敛。

🗣️ 辩题:AI 是否会取代人类的工作?

正方:AI 将大规模取代人类工作 · 反方:AI 是工具,不会取代而是重塑 · 3 轮 + 主持人总结
第一轮 · 立场陈述
正方 · 立场陈述 主张:将大规模取代

我的立场是:AI 将大规模取代人类工作。证据有三:第一,生成式 AI 已能完成编程、写作、设计、翻译等"白领知识工作"的核心产出,而这些恰是过去十年就业增长最快的领域。第二,成本结构不可逆——一个 AI 实例的边际成本趋近于零,而人类员工的边际成本持续上升,企业有强烈经济动机用 AI 替代。第三,历史规律显示,凡是能被"清晰定义输入输出"的工作,最终都会被自动化。AI 正在让越来越多"看似需要创造力"的工作变得可定义、可自动化。

反方 · 立场陈述 主张:重塑而非取代

我不同意"大规模取代"这个判断。正方混淆了"任务自动化"与"岗位消失"。AI 取代的是任务(写一段代码、画一张图),而非岗位(一个工程师要理解需求、做架构权衡、与团队协作、对结果负责)。历史上每次技术革命都消灭了旧任务,却创造了更多新岗位——拖拉机消灭了锄地,但创造了农机维修、农业调度、食品加工等更多岗位。AI 也不例外。更重要的是,AI 本身需要大量人类来训练、对齐、审计、运营——这些"AI 相关工作"正在爆发式增长。所以本质是重塑,不是取代。

第二轮 · 质询与反驳
正方 · 质询反方

反方说"AI 取代任务而非岗位",但这个论点正在被现实击穿。当 AI 能完成一个岗位上 80% 的任务时,企业不再需要 10 个人,只需要 2 个人加 AI。这不是"重塑",这是岗位总量缩减。反方还提到"AI 创造新岗位",但请正视一个不对称性:被淘汰的是 50 岁的流水线工人和中级文案,而新创造的"AI 训练师""提示词工程师"需要全新技能——被淘汰的人和能胜任新岗位的人,不是同一批人。结构性失业是真实且痛苦的。反方如何回应这个"技能错配"问题?

反方 · 反驳正方

正方的"技能错配"论点我有力地承认——这确实是真问题,但它证明的是需要转型与再培训,而非"取代"。请注意正方悄悄把立场从"取代"滑向了"岗位总量缩减",这是两个不同命题。我反问正方:你如何解释,过去 3 年 AI 能力暴涨,而全球失业率并未随之飙升?美国 2025 年失业率仍在历史低位。更根本的是,人类需求是无限的——AI 满足了旧需求,人类会创造出 AI 无法独立满足的新需求(深度陪伴、个性化教育、复杂谈判、价值判断)。经济规律告诉我们:需求创造就业。只要人类需求不枯竭,就业就不会被"取代",只会迁移。正方的悲观,低估了人类创造新需求的能力。

第三轮 · 最终立场
正方 · 最终立场(吸收反方观点后修正)

吸收反方观点后,我修正立场:我不再坚持"AI 会让人类无工可做"的极端版本。但我仍坚持核心主张——AI 会大规模取代特定类别的工作,尤其是那些"输入输出可被清晰定义、且不涉及复杂人际与价值判断"的岗位。短期内(5-10 年),初级文案、初级程序员、客服、数据录入等岗位会经历实质性的岗位数量下降。反方说的"新需求创造新就业"在长期成立,但短中期的转型阵痛是真实的,不应被"长期乐观论"掩盖。我的最终立场:取代会发生,且主要集中在可定义性高的岗位;重塑也会发生,但两者并存,取代的痛感先于重塑的红利到来。

反方 · 最终立场(吸收正方观点后修正)

吸收正方观点后,我也修正:我承认"任务自动化 → 岗位缩减"在特定领域确实成立,且短期转型阵痛比乐观者预估的更痛。正方对"技能错配"的指出是负责任的。但我仍坚持核心立场:AI 是工具,本质是重塑而非取代。理由收敛为两点:其一,历史上没有一项通用技术(GPT)最终导致人类就业总量永久下降,蒸汽机、电力、计算机都是先阵痛后扩张;AI 作为 GPT,大概率遵循同一规律。其二,"取代"暗示人类在产出环节被完全剔除,但只要存在需求侧的无限性 + 价值判断的人类独占性,人类就不会被取代,而是被推向价值链更高处。最终立场:短期有阵痛与局部取代,长期是重塑与岗位升级;真正该担心的不是"有没有工作",而是"转型期谁被落下"。

主持人 · 总结裁决
主持人 · 综合裁决

本场辩论双方在 3 轮交锋中都实现了立场修正,这正是多智能体辩论的价值——不是分出胜负,而是通过对抗收敛到更精确的共识

共识点:双方最终都承认"短期局部取代 + 长期重塑"同时成立。分歧从第一轮的"取代 vs 不取代"二元对立,收敛到第三轮的"转型节奏与阵痛分配"的具体分歧。

遗留分歧:正方强调取代的痛感先于红利、技能错配是硬约束;反方强调需求无限性保证长期就业不枯竭、价值判断是人类独占护城河。

裁决:反方略占优——因为反方成功将辩题从"是否取代"重构为"如何平稳转型",这是一个更有建设性的框架。但正方对短期阵痛的警示是反方无法否定的真实贡献。本场无绝对胜负,达成有效收敛

关于这场 Demo: 这场辩论由两个角色(正方/反方)各持立场,经 3 轮"陈述→质询→修正"后由主持人总结。这正是 MAD 框架(正/反/主持人)的辩论协议,也是本报告推荐用于"两个 Agent 辩论"的核心范式。你可以看到:双方在吸收对方观点后都修正了立场,这正是多 Agent 辩论相比单模型自问自答的核心优势——外部反馈打破思维退化

选型建议

根据你的具体场景,对号入座。

场景:快速理解多 Agent 辩论原理
→ 选 MAD 或 DebateBox
两者都在 ~250 行内实现了完整辩论循环。MAD 有 Moderator+Judge 机制更完整,DebateBox 有 Constitutional AI 自我批评更独特。读源码 1 小时即可理解全部逻辑。
场景:做正式产品/长期项目
→ 选 AutoGen(但评估迁移)
功能最全、多后端、社区最大。但需注意它已进入维护模式,若项目周期长,建议同步评估微软新的 Microsoft Agent Framework。
场景:学术复现/小模型研究
→ 选 cultural_debate
ACL 2025 Oral 配套,专注文化对齐与公平性,内置数据集。适合研究"小模型辩论≈大模型"这一方向,但需多 GPU。
场景:只要两个 Agent 辩论,别太重
→ 参考 MAD,自己写 50 行
核心逻辑极简:给两个 agent 塞正/反方 system prompt,轮流发言,可选加个 judge 总结。不必引入任何框架,用任意 LLM SDK 即可。本报告的 Demo 就是这个思路。
场景:需要裁判/共识达成
→ 选 MAD(内置)或 AutoGen(可配)
只有 MAD 和 AutoGen 内置了裁决机制。MAD 的 Moderator 早停 + Judge 兜底设计精巧;AutoGen 可自由加 judge agent,灵活但需手写。
场景:非 OpenAI 后端(本地/Anthropic)
→ 选 AutoGen 或 自己写
DebateBox 和 MAD 都硬编码了旧版 OpenAI SDK,换后端要改源码。cultural_debate 是纯本地但需 GPU。只有 AutoGen 原生多后端。或者——自己写,最省事。