多智能体协作正成为提升大模型推理可靠性的关键手段。单个 LLM 往往”一条道走到黑”，而让多个 Agent 分工、互审、辩论，能显著减少幻觉与逻辑漏洞。本文拆解反思（Reflexion）与辩论（Debate）两种协作模式，并给出可落地的 Python 骨架。
一、为什么单个 Agent 会”一条道走到黑”
把复杂任务交给一个 Agent 时，它通常会基于第一次冒出来的思路一路写下去：先生成一个答案，就默认它是对的，缺少”回头检查”的环节。这带来三类典型问题。
- 首答偏差：模型对最先想到的解法过度自信，不会主动寻找替代路径。
- 无自我校验：生成代码或推理链后，不会执行”这步真的对吗”的审查。
- 视角单一：一个人（一个角色）容易漏掉相反证据，尤其在数学、安全和长链条推理上。
多智能体协作的本质，是把”生成”和”审查”拆给不同角色，用结构化的对话逼出更稳的结果。下面两种模式最常用：反思让 Agent 自己纠错，辩论让两个 Agent 互相挑刺。
举个具体例子：让单 Agent 写一条”删除三个月前日志”的 SQL，它可能顺手写出 DELETE FROM logs 漏掉时间条件，库里所有日志瞬间清空，而它自己不会察觉异常。如果加一个审查角色，对方一眼就能指出”少了 WHERE 时间过滤，这是破坏性操作”，错误在发布前就被拦下。这种”第二双眼睛”正是协作最朴素也最管用的价值。
二、反思模式（Reflexion）：让 Agent 自己纠错
Reflexion 的核心是一个闭环：Actor 先产出答案，Critic（可由另一个提示或 LLM-as-Judge 充当）评估对错并给出反馈，反馈被写回”记忆”，Actor 下一轮带着上次的教训重做。它不需要微调模型，纯靠提示与上下文完成自我修正。
下面是一个最小可运行的反思骨架（用伪装的 call_llm 代表任意模型调用）：
def reflexion(task, max_rounds=3):
memory = [] # 存放历史反馈
for i in range(max_rounds):
prompt = f"""任务：{task}
历史反馈（请避免重复犯错）：
{chr(10).join(memory)}
请给出本轮答案。"""
answer = call_llm(prompt)
feedback = call_llm(f"检查下面答案是否正确并给出改进建议：\n{answer}")
if "通过" in feedback:
return answer
memory.append(feedback) # 关键：把批评写回记忆
return answer # 达到上限仍返回最新结果注意 memory.append(feedback) 这一行——它让下一轮能看到”上次哪里错了”。反射模式特别适合有明确对错标准、可自动验证的任务，比如单元测试能否跑通、SQL 是否能执行。
三、辩论模式（Debate）：两个 Agent 互相挑刺
辩论模式让 Agent A 和 Agent B 就同一问题各自给出结论并互相质问，最后由一个裁判（Judge）综合双方论据给出终答。它不依赖”参考答案”，而是用视角冲突暴露薄弱环节，对开放性问题、方案选型、安全性审查尤其有效。
def debate(task, rounds=2):
a = call_llm(f"请就『{task}』给出你的观点与依据。")
b = call_llm(f"请就『{task}』给出你的观点，并指出对方可能遗漏的角度。")
for _ in range(rounds):
a = call_llm(f"对方观点：{b}\n请反驳并修正你的结论：{task}")
b = call_llm(f"对方观点：{a}\n请反驳并修正你的结论：{task}")
verdict = call_llm(f"任务：{task}\n观点A：{a}\n观点B：{b}\n请给出最终结论。")
return verdict辩论的价值在于”对抗性”：当 A 必须回应 B 的质疑时，它被迫补全证据链。相比单一 Agent，输出更稳、幻觉更少，代价是多消耗几倍推理调用。
四、反思 vs 辩论：怎么选
两种模式不是替代关系，而是按任务特性选型：
| 维度 | 反思 Reflexion | 辩论 Debate |
|---|---|---|
| 角色数 | 1 个（自我循环） | 2+ 个（互审） |
| 验证方式 | 自带对错反馈 | 视角对抗 |
| 成本 | 低（轮次少） | 高（多次调用） |
| 最适合 | 有可验证标准的任务 | 开放/方案/安全审查 |
| 典型场景 | 代码生成、数学题 | 技术选型、风险评估 |
五、实战：最小协作编排骨架
把两者组合，就是一个通用编排器：先反思收敛，再辩论定稿。下面用 Python 串起整体流程，真实项目里可把 call_llm 换成任意 SDK。
def collaborate(task):
# 1) 反思：先自我纠错一轮
draft = reflexion(task, max_rounds=2)
# 2) 辩论：两个视角互审
verdict = debate(f"{task}\n初稿：{draft}", rounds=1)
# 3) 终检：用评测视角再扫一遍
score = call_llm(f"给下面结论打分(1-5)并指出硬伤：\n{verdict}")
return verdict, score
final, score = collaborate("为 10 万 QPS 的订单服务设计限流方案")
print(score)生产环境要加三个护栏：限制总轮次防失控、给每轮加超时与重试、把中间结论落日志方便复盘。协作越深，可观测性越重要。
六、什么时候用、什么时候别用
多智能体协作不是银弹，用错地方只会变慢变贵：
| 适合上协作 | 建议单 Agent 直出 |
|---|---|
| 高代价错误（安全/金融） | 简单摘要、翻译 |
| 需要多视角权衡 | 明确有标准答案 |
| 结果要可解释可审计 | 实时低延迟场景 |
| 容得下额外成本 | 预算极紧的批量任务 |
七、和记忆、评测、工具调用配合
多智能体协作很少孤立存在，它通常和三类能力组合：用智能体记忆系统把反思反馈沉淀为长期经验，用LLM-as-Judge 自动评测当 Critic 给结构化打分，用工具调用与自主编排让 Agent 能查库、跑测试，再用MCP 协议统一接外部工具。记忆负责”记得错”，评测负责”判对错”，工具负责”做对事”，协作负责”逼出更优解”。
落地顺序建议：先单 Agent + 工具调用跑通主链路（参考 Dify+Ollama 私有知识库 的搭建思路），再加记忆与评测，最后才引入反思/辩论协作——避免一上来就把系统复杂度拉满。
八、上生产必须加的三道护栏
协作让结果更稳，但调用次数成倍增加，不加护栏很容易把延迟和成本一起拉爆。实战里至少要有三道防线。
- 轮次上限与预算上限：反思/辩论的循环必须设最大轮次和单次 token 预算，到顶就返回当前最优，杜绝无限自我对话烧钱。
- 超时与重试：每个 Agent 调用都该有超时，失败走指数退避重试；其中一个角色卡死不应拖垮整条流水线。
- 全链路日志：把每轮的提问、回答、批评落盘，出问题时能复盘”第二轮为什么改坏了”，也方便后续用评测集回归。
护栏到位后，协作才真正”可控”。否则多智能体只会把单 Agent 的小错误，放大成多个 Agent 共同制造的混乱。
九、小结
多智能体协作提升 LLM 可靠性，靠的不是更大的模型，而是更好的”工作机制”：反思让 Agent 自我纠错，辩论让多个视角互相挑刺。选型上，有验证标准用反思、需多视角用辩论；落地时务必加轮次上限、超时与日志三道护栏，并和记忆、评测、工具调用组合。一个常见的反模式是刚起步就堆三个 Agent、上辩论再上反思，结果系统复杂难调、成本失控。更稳妥的节奏是：先把单 Agent 加工具调用跑通主链路，再加记忆与评测，最后才引入协作。协作是放大器，基础链路稳，它才放大收益；基础链路飘，它只会放大事故。
