多智能体辩论机制最近在社区里被聊得很多也确实是个让人眼前一亮的方向。以前我们调 Agent总在提示词、模型参数、RAG 召回这些老路上打转现在突然冒出一条新路与其让单个模型自己反复自省不如直接拉两个或多个角色出来让他们吵一架。这个“吵”的过程就是红蓝对抗。我自己最早接触这个概念是在阅读某团队关于多角色协作的工作时当时第一反应是这不就是把安全领域的红蓝对抗搬到模型推理里了吗后来深入做下来才发现这背后其实藏着一套非常清晰的博弈逻辑和工程方法论不是简单加个提示词脚本就能跑出效果的。这篇文章想跟你聊聊这套机制的核心逻辑它到底解决什么问题、角色之间如何互动、裁决机制怎么设计、以及我在实际搭建过程中踩过哪些坑。无论你是正在做 Agent 应用层开发还是对大模型对齐、决策质量优化感兴趣这篇文章应该都能给你一些可以直接上手的思路。1. 为什么需要“打一架”从单智能体到多智能体辩论的演进逻辑先想一个问题为什么单个 Agent 的决策质量总容易到瓶颈就算我们把提示词写得再细、把思维链拉得再长模型本质上仍是一条单通道的信息加工流。它不是不行而是存在一个天然的盲区自己生成的内容自己很难挑出毛病。这跟人一样写完代码自己 review 十遍往往还不如同事扫一眼抓出的 bug 多。早年大家用 Self-Consistency自我一致性、Self-Refine自修正这类方法本质上都是让同一个模型从不同角度审视自己的输出。Self-Consistency 是多次采样取多数票Self-Refine 是让模型自己批评自己再改进。这两个方案在实际项目中都验证过有效但天花板很明显。原因很简单同一套参数、同一个分布下采样出来的修正结果偏差方向往往是高度一致的模型只是在自己犯过的错误附近原地打转。多智能体辩论机制做得不一样它把“说的”和“审的”彻底分离。红方负责输出一个方案并强调其合理性蓝方则负责挑刺、找漏洞、提反例。两边基于同一批事实或上下文各自提出论证然后在一个裁决者的主持下达成交替辩论。这本质上把单模型内部的隐式“思考分歧”显式化成外部多方的“话语交锋”逼迫每个角色在自己的角色约束下思考而不是在一个混合了自证与质疑的模糊目标里混着答。这里面还有一个更底层的动机数据分布本身是不对称的。大部分模型训练数据中“正面陈述”和“论证一个观点”的内容远多于“系统性驳斥一个方案”的内容。所以当你让模型“请检查你的回答是否正确”时它的批判能力其实是不及格的。但当你定义一个独立的批判角色给它明确的反方立场和责任时情况就完全不同了——批判的强度被角色化后模型在推理时拥有了更明确的边界和动机批判的深度和密度都会显著提升。我在项目中观察到一个现象单 Agent 自问自答时模型经常会走“中间路线”——既不敢完全肯定也不敢真正否定于是输出一堆含糊的“可能”“或许”“需要考虑”。但红蓝对抗起来之后蓝方的输出会非常果断直接说“这个方案在约束条件下不成立因为边界条件 X 没被满足”。这种对抗性使得每个候选方案的强项和弱项都被充分暴露接下来的裁决才能做到有据可依。从系统架构的角度看多智能体辩论也天然契合了模块化设计的思路。红方、蓝方、裁决方可以是同一个模型的三次调用也可以是三个不同模型各自运行甚至可以配不同的系统提示词和内外部记忆。这意味着你能在几乎不动底层模型的前提下把决策质量往上抬一截这在工程上是很划算的一件事。2. 红蓝对抗机制的完整拆解角色分工与协作流程把辩论机制落地首先要做的一步是把角色定义清楚。角色定义越模糊对抗效果越差。我把这套系统拆成三个角色加一个循环。2.1 红方方案提出者红方承担的是“论证者”角色。它会基于任务指令和上下文做出一个尽量完整、自信的决策或方案。红方最重要的输出不是答案本身而是“论据链”我基于哪些事实、为什么选择这个方案、我预期它能满足什么约束。给红方的指令模板我一般会强调三点明确立场不能模棱两可、提供约束验证方案如何满足给定的硬性约束、指出适用前提方案在什么条件下是有效的。如果你不给红方立场的强制要求模型大概率会输出一个“看起来正确”的平庸答案这在对抗循环里等于白跑一轮。这里有个容易被忽视的小细节初始回答的长度。我一开始让红方直接输出完整方案结果蓝方经常挑不出实质问题因为模板里有很多正确的废话。后来改成“先给结论再给三条核心理由”对抗质量立刻上来了。信息密度高的短回答比信息全面但松散的长回答更容易被有效挑战。2.2 蓝方质疑者与压力测试器蓝方的目标是找漏洞。它不是简单地跟红方唱反调而是要基于实际上下文找出逻辑断层、假设不成立的地方、约束冲突或遗漏的场景。蓝方输出一般包含指出的具体问题、该问题可能导致的实际后果、以及改进方向的建议。蓝方指令设计的核心在于要让蓝方“基于证据”批判而不是“基于立场”批判。如果不做这个约束模型很快会把所有问题归结为“风险不可控”“建议谨慎处理”这种空话。我给蓝方的限定是任何质疑必须对应到红方输出的具体句子或结论并且要给出一个反例或边界情形来支撑它的质疑。没有具体指摘对象的质疑直接视为无效输出。2.3 裁决者收敛机制的核心辩论不能无限循环必须有个裁判来收敛。裁决者的输入是红蓝双方的历轮发言记录输出是最终决策。裁决者需要判定哪些质疑是真实有效的、哪些反驳是强词夺理、哪些信息是冗余的、最终的结论应该站在哪一边。裁决者的输出格式我会强制为结构化 JSON包含 final_answer、decision_reasoning、风险提示 三个字段。这样后续可以程序化地判断、记录、甚至做多轮辩论间的结果对比。2.4 迭代循环辩论轮次的设计辩论流程是一个标准循环红方初稿、蓝方质疑、红方回应与修改、蓝方复评直到达到最大轮次或者裁决者认为“方案已收敛”。这里的关键是轮次的交互粒度。让红方每一次都重写完整方案会让上下文越滚越长成本急剧膨胀而且后期轮次的修改往往只动了皮毛对决策质量贡献很小。一种更高效的设计是分两阶段前两轮做“粗粒度对抗”让蓝方从整体框架上质疑后面几轮只做“定点补丁”红方只被要求回复针对蓝方质疑的具体段落修改。这个模式既保证了对抗深度又控制了 token 消耗实测下来决策质量和成本曲线要健康得多。3. 从零搭建一个辩论式 Agent 系统核心伪代码与参数选择理论讲清楚了下面进入工程落地。我直接给出一套可以快速启动的最小实现思路选用 Python 伪代码展示核心流程你在此基础上替换不同的模型接口或消息协议即可。3.1 定义角色提示词实现的第一步是定义红蓝方以及裁决者的提示词。角色提示词可以单独以模板文件管理方便后续做版本迭代。RED_SYSTEM_PROMPT 你是一位严谨的方案论证者。 你需要基于给定的上下文提出一个尽可能合理的决策或方案。 要求 1. 明确给出你的结论。 2. 给出最多三条核心理由每条理由必须对应具体事实或逻辑。 3. 指出你的方案成立的前提条件。 4. 不要使用模糊表述不要回避约束条件。 BLUE_SYSTEM_PROMPT 你是一位严格的审查者负责对给定方案进行压力测试。 你的任务是找出方案中潜在的逻辑断层、与约束条件的冲突、信息盲区以及反例场景。 要求 1. 你的质疑必须直接引用对方方案中的具体内容或结论。 2. 对每一条质疑必须给出一个具体的反例或边界情形。 3. 不要泛泛而谈“风险较大”要指出风险发生的具体路径。 4. 如果方案确实没有明显问题请说明评估依据不要强行制造问题。 JUDGE_SYSTEM_PROMPT 你是一位公正的决策协调者。 你会收到方案提出者和审查者的多轮讨论记录。 请基于讨论内容给出最终决策。 必须输出JSON格式 { final_answer: 最终决策内容, decision_reasoning: 决策依据说明采纳或拒绝了哪些观点, risk_note: 最终方案仍需注意的风险点 } 这里有个细化的小细节在大多数开源模型中蓝方提示词里的第4条反而非常关键。如果不写这一条模型很容易陷入“鸡蛋里挑骨头”的模式导致红方后面每一轮都在应对一些无关紧要的质疑整体辩论效率直线下降。3.2 主流程实现核心循环逻辑是三层嵌套对话生成、批判循环、最终裁决。def run_debate(task_context, max_rounds3): messages [] # 阶段一红方初始方案 red_prompt [ {role: system, content: RED_SYSTEM_PROMPT}, {role: user, content: task_context} ] red_solution call_llm(red_prompt) messages.append({role: red, content: red_solution}) # 阶段二蓝方质疑与红方回应循环 for i in range(max_rounds): blue_prompt [ {role: system, content: BLUE_SYSTEM_PROMPT}, {role: user, content: ( 以下是当前方案\n red_solution \n\n请输出你的质疑与反例。 )} ] blue_critique call_llm(blue_prompt) messages.append({role: blue, content: blue_critique}) if i max_rounds - 1: break refine_prompt [ {role: system, content: RED_SYSTEM_PROMPT}, {role: user, content: ( 这是你之前的方案\n red_solution \n\n这是审查者给出的质疑\n blue_critique \n\n请回应这些质疑并输出修订后的完整方案。 )} ] red_solution call_llm(refine_prompt) messages.append({role: red, content: red_solution}) # 阶段三裁决 judge_prompt [ {role: system, content: JUDGE_SYSTEM_PROMPT}, {role: user, content: format_debate_record(messages)} ] final_decision call_llm(judge_prompt, response_formatjson) return final_decision, messages这个流程里我刻意省略了模型调用接口的细节因为不同模型服务商 API 不一样。你只需要关注数据流的走向红方生成原文、蓝方按原文输出质疑、红方带着质疑回来修订、最后裁决者一次性读取全程记录。3.3 参数选择的经验值搞定流程之后最直接的一个问题是模型参数怎么设置我基于反复实验给你三个可以直接对照的经验值。首先说温度参数temperature。红方的温度不宜过低建议设置在 0.5~0.7 之间因为红方承担的是方案发散的任务温度太低容易陷入重复和保守蓝方的温度建议设置在 0.3~0.4批判任务需要的是稳定性和准确性而不是发散性裁决者的温度直接调到 0裁决阶段要的是确定性任何创造性的发挥对最终决策都是减分项。然后是轮次上限。我调试下来最舒服的是 2~3 轮。第一轮蓝方指出硬伤红方修改第二轮蓝方做复核此时大部分实质问题已经暴露到第三轮时往往已经是“挤牙膏”式的边缘优化。超过三轮后对话历史越来越长而新信息的边际收益迅速衰减。在很多场景下两轮对抗加一次裁决已经能覆盖 90% 的质量提升空间。还有个容易被忽略的参数是输出长度上限max_tokens。蓝方输出一定要给足长度否则它会倾向于只挑一个问题点就截止了。我给蓝方设置的最小输出长度是 800 tokens目的就是强迫它尽量完整地列举出方案的多处风险。红方修订阶段的输出长度则要比初始方案更长因为它除了要复述方案还要对质疑做出回应。4. 提升决策质量的关键裁决设计、记忆机制与收敛策略上面那一版实现已经能跑通了但真正决定系统上限的是裁决设计和记忆策略。这里单独拿出来展开说因为这些细节是文档里很难找到的基本都是项目里调出来的经验。4.1 裁决者不是“聊天记录总结器”这是我觉得最核心的问题。很多人直接把红蓝两方的历史输出一股脑塞给裁决者让它给答案结果得到的裁决往往偏向红方——因为红方修订后的方案占据了对话后半段的注意力。所以我在实践中加入了“结构化对抗摘要”的步骤。在把历史记录交给裁决者之前先让一个独立的总结模块提取红蓝双方的核心论点矩阵红方核心依据 1. 约束条件 A 与逻辑链条 B 推导出方案 C 2. 数据 D 支持预期目标可达性 蓝方核心质疑 1. 约束条件 A 在场景 E 下可能失效反例... 2. 预期目标可达性忽略了变量 F 的干扰影响路径... 红方回应 1. 已澄清条件将适用边界限定为... 2. 增加补偿策略 G...裁决者看到的是提炼后的论点而不是原始对话流水账。这个动作让裁决准确率提升非常明显因为它有效消除了“对话惯性”对裁决的干扰。4.2 引入历史记忆让辩论不“失忆”另一个问题是每轮辩论之间的孤立性。如果在一次任务中你需要连续决策多个子问题前一个决策已经被裁决后一个决策还从零开始辩论系统就白白浪费了已经沉淀下来的判断经验。我的做法是维护一个跨轮次的决策记忆库存储每个子问题最终决策的摘要和主要争议点。下一轮辩论时将“之前被否决的候选方案及其原因”注入上下文作为蓝方的初始提示语以下是本任务先前阶段中已被否决的方案要点 - 方案 X 被否决原因与约束 A 冲突 - 方案 Y 被否决原因未能覆盖场景 E 请在你的质疑中优先检查当前方案是否包含同类问题。这个策略特别适合那种“任务链条很长”的 Agent 应用比如自动化工作流编排、长文档决策分析。它让红蓝对抗从“单点审校”升级为了“累积式审校”。4.3 轮次收敛的提前终止机制辩论不能干等 max_rounds 到期。我在实际运行中增加了提前终止的逻辑当蓝方连续一轮输出的内容被判定为“无新信息”时立即触发裁决。判断“无新信息”的办法很简单——计算本轮蓝方输出与前两轮的语义相似度超过阈值就停止。这样能省下不少无谓的 token 消耗同时避免模型陷入自我重复的怪圈。具体实现我建议用 embedding 模型算相似度而不建议直接让模型自评。因为自评本身又会引入一次模型调用和不确定性embedding 相似度则是一个可解释、可调节量化的指标阈值从 0.82 起步调试即可。4.4 红方的“记忆性修正”与“全局修正”分离最后聊一个我在多轮辩论中踩过坑后才补上的修改把红方修改方案的方式分成两种。一种是在蓝方质疑基础上的“记忆性修正”——只改与质疑相关的部分另一种是“全局修正”——重新审视整个方案。如果红方每次都在全局层面上重写很容易出现改掉一个已知问题而引入另一个新问题的“修补震荡”。我的做法是在前几轮只允许记忆性修正并且明确要求红方“仅在你认为与质疑相关的部分做修改并说明修改前后逻辑变化”。最后一轮如果需要再允许全局修正。这样做的效果是方案演进路径更加稳定裁决者面对的候选方案之间差异不会过大决策的可解释性也更强。5. 实战避坑我踩过的 6 个坑与排查实录这套机制远不是“两个模型互相骂两句再找个裁判来判高下”那么简单。真正落地时有六个问题特别容易让新手破防我把排查思路一并整理出来直接对应到具体的调试步骤。5.1 蓝方“强词夺理”狂潮现象蓝方就每个细节都提出质疑无论红方怎么补充它都能挑出新毛病导致辩论无法收敛。排查过程先看蓝方输出中是否有很多“缺乏具体指摘对象”的表述。我排查后发现是系统提示词中缺少“禁止无依据质疑”的约束。修复方式就是在 BLUE_SYSTEM_PROMPT 中强调每一条质疑必须引用原方案中的具体句子并给出反例场景。修复后蓝方输出质量有了明显提升辩论效率回到合理水平。5.2 红蓝双方互相“捧场”现象蓝方变成了“好的方面但我认为这里其实没什么大问题”红方再回“谢谢指正我认为你提得很好”辩论彻底沦为聊天。这个问题的根因在于模型本身就偏好和谐与正面回应。我的处理办法是在提示词中明确告诉蓝方如果它没有提出任何有实质价值的质疑那么这轮辩论记录将不会进入裁决者的输入并暗示其角色价值未被体现。同时我会在裁决输入中过滤掉客套话部分只保留结构化的质疑与回应内容。5.3 裁决者被蓝方带偏现象裁决结果过度偏向质疑方即使红方的方案其实已经考虑过这些问题。这个问题的典型原因有两个。一个是裁决前输入的记录太原始、太长裁决者很难抓住主线另一个是蓝方的质疑语气往往比红方更笃定、更强烈模型天然记住的是尖锐的观点。我解决的办法就是前面说的“结构化对抗摘要”——先让摘要模块把双方观点拧成清单再做裁决。5.4 辩论后方案的修改幅度过大导致偏离原始目标现象红方初稿本来基本可用经过两轮对抗后给出的方案却跟初始需求越走越远。排查后发现是提示词中的“请根据质疑修订方案”指令过于开放。红方为了回应质疑会把方案往“绝对安全”方向带丧失了对原始目标的专注。修复方式是在修改指令中强制加入“你的修订必须保持初始方案的核心结论不变仅调整受到影响的部分”并且增加一个“问题回应”与“方案主体”分离的输出结构。5.5 上下文溢出现象第三轮、第四轮辩论时中间历史太长直接给出“context length exceeded”。这个问题最严重影响使用体验。两个角色各有长输出再加上每轮都重新传入对方的内容token 膨胀得非常快。我的处理方式是先做中期摘要在每轮对抗结束后将对话历史压缩为论点摘要、尚未解决的分歧和已确认的一致性三种信息再作为下一轮的上下文输入。这套策略让同样的 token 预算能支撑更多有效轮次。5.6 辩论结果不稳定同一次任务跑两遍结果不一致现象同一输入跑两次一次裁决方案是 A一次裁决方案是 B。原因往往出在温度设置和采样随机性上。裁决阶段必须设置温度 0同时尽量保持输入不变才能确保结果的稳定可复现。若业务上对可解释性有硬性需求还可以将辩论过程中的每一次中间输出都持久化存储之后做结果审计时可以直接还原决策路径。6. 后续还能往哪个方向扩展这套机制目前在我自己的项目里已经稳定运行了一段时间。最直接的价值体现在两个场景一个是那些“错误代价较大”的决策类任务另一个是“答案没有绝对标准、需要综合多方考量”的开放式任务。前者比如自动化代码审查、系统变更方案评估后者比如产品路线图生成、报告的结构化评审。现在这个框架本身也已经有了不少值得深挖的扩展方向。比如多角色不仅仅局限于红蓝两方还可以引入“用户代理”“数据代理”“合规代理”等不同的立场。再比如引入差异化模型蓝方用一个参数更小、但指令遵循能力更强的模型红方用能力更强的模型这能在成本不受太大冲击的条件下兼顾质量。还有一点是我最近在尝试的让裁决者输出的不只是最终答案而是带权重的备选方案排序——这样在主决策失败时我们可以直接回退到第二优选项而不必重新跑一套辩论系统。我在把这个方案分享给团队时经常说一句话多智能体辩论的核心价值不在于让模型“吵出真理”而在于让每个候选方案的“证据链”被充分暴露出来让决策过程变得透明、可审计、可改进。只要你对决策质量有要求这套多角色对抗的思路就一定有它的用武之地。
多智能体辩论机制最近在社区里被聊得很多也确实是个让人眼前一亮的方向。以前我们调 Agent总在提示词、模型参数、RAG 召回这些老路上打转现在突然冒出一条新路与其让单个模型自己反复自省不如直接拉两个或多个角色出来让他们吵一架。这个“吵”的过程就是红蓝对抗。我自己最早接触这个概念是在阅读某团队关于多角色协作的工作时当时第一反应是这不就是把安全领域的红蓝对抗搬到模型推理里了吗后来深入做下来才发现这背后其实藏着一套非常清晰的博弈逻辑和工程方法论不是简单加个提示词脚本就能跑出效果的。这篇文章想跟你聊聊这套机制的核心逻辑它到底解决什么问题、角色之间如何互动、裁决机制怎么设计、以及我在实际搭建过程中踩过哪些坑。无论你是正在做 Agent 应用层开发还是对大模型对齐、决策质量优化感兴趣这篇文章应该都能给你一些可以直接上手的思路。1. 为什么需要“打一架”从单智能体到多智能体辩论的演进逻辑先想一个问题为什么单个 Agent 的决策质量总容易到瓶颈就算我们把提示词写得再细、把思维链拉得再长模型本质上仍是一条单通道的信息加工流。它不是不行而是存在一个天然的盲区自己生成的内容自己很难挑出毛病。这跟人一样写完代码自己 review 十遍往往还不如同事扫一眼抓出的 bug 多。早年大家用 Self-Consistency自我一致性、Self-Refine自修正这类方法本质上都是让同一个模型从不同角度审视自己的输出。Self-Consistency 是多次采样取多数票Self-Refine 是让模型自己批评自己再改进。这两个方案在实际项目中都验证过有效但天花板很明显。原因很简单同一套参数、同一个分布下采样出来的修正结果偏差方向往往是高度一致的模型只是在自己犯过的错误附近原地打转。多智能体辩论机制做得不一样它把“说的”和“审的”彻底分离。红方负责输出一个方案并强调其合理性蓝方则负责挑刺、找漏洞、提反例。两边基于同一批事实或上下文各自提出论证然后在一个裁决者的主持下达成交替辩论。这本质上把单模型内部的隐式“思考分歧”显式化成外部多方的“话语交锋”逼迫每个角色在自己的角色约束下思考而不是在一个混合了自证与质疑的模糊目标里混着答。这里面还有一个更底层的动机数据分布本身是不对称的。大部分模型训练数据中“正面陈述”和“论证一个观点”的内容远多于“系统性驳斥一个方案”的内容。所以当你让模型“请检查你的回答是否正确”时它的批判能力其实是不及格的。但当你定义一个独立的批判角色给它明确的反方立场和责任时情况就完全不同了——批判的强度被角色化后模型在推理时拥有了更明确的边界和动机批判的深度和密度都会显著提升。我在项目中观察到一个现象单 Agent 自问自答时模型经常会走“中间路线”——既不敢完全肯定也不敢真正否定于是输出一堆含糊的“可能”“或许”“需要考虑”。但红蓝对抗起来之后蓝方的输出会非常果断直接说“这个方案在约束条件下不成立因为边界条件 X 没被满足”。这种对抗性使得每个候选方案的强项和弱项都被充分暴露接下来的裁决才能做到有据可依。从系统架构的角度看多智能体辩论也天然契合了模块化设计的思路。红方、蓝方、裁决方可以是同一个模型的三次调用也可以是三个不同模型各自运行甚至可以配不同的系统提示词和内外部记忆。这意味着你能在几乎不动底层模型的前提下把决策质量往上抬一截这在工程上是很划算的一件事。2. 红蓝对抗机制的完整拆解角色分工与协作流程把辩论机制落地首先要做的一步是把角色定义清楚。角色定义越模糊对抗效果越差。我把这套系统拆成三个角色加一个循环。2.1 红方方案提出者红方承担的是“论证者”角色。它会基于任务指令和上下文做出一个尽量完整、自信的决策或方案。红方最重要的输出不是答案本身而是“论据链”我基于哪些事实、为什么选择这个方案、我预期它能满足什么约束。给红方的指令模板我一般会强调三点明确立场不能模棱两可、提供约束验证方案如何满足给定的硬性约束、指出适用前提方案在什么条件下是有效的。如果你不给红方立场的强制要求模型大概率会输出一个“看起来正确”的平庸答案这在对抗循环里等于白跑一轮。这里有个容易被忽视的小细节初始回答的长度。我一开始让红方直接输出完整方案结果蓝方经常挑不出实质问题因为模板里有很多正确的废话。后来改成“先给结论再给三条核心理由”对抗质量立刻上来了。信息密度高的短回答比信息全面但松散的长回答更容易被有效挑战。2.2 蓝方质疑者与压力测试器蓝方的目标是找漏洞。它不是简单地跟红方唱反调而是要基于实际上下文找出逻辑断层、假设不成立的地方、约束冲突或遗漏的场景。蓝方输出一般包含指出的具体问题、该问题可能导致的实际后果、以及改进方向的建议。蓝方指令设计的核心在于要让蓝方“基于证据”批判而不是“基于立场”批判。如果不做这个约束模型很快会把所有问题归结为“风险不可控”“建议谨慎处理”这种空话。我给蓝方的限定是任何质疑必须对应到红方输出的具体句子或结论并且要给出一个反例或边界情形来支撑它的质疑。没有具体指摘对象的质疑直接视为无效输出。2.3 裁决者收敛机制的核心辩论不能无限循环必须有个裁判来收敛。裁决者的输入是红蓝双方的历轮发言记录输出是最终决策。裁决者需要判定哪些质疑是真实有效的、哪些反驳是强词夺理、哪些信息是冗余的、最终的结论应该站在哪一边。裁决者的输出格式我会强制为结构化 JSON包含 final_answer、decision_reasoning、风险提示 三个字段。这样后续可以程序化地判断、记录、甚至做多轮辩论间的结果对比。2.4 迭代循环辩论轮次的设计辩论流程是一个标准循环红方初稿、蓝方质疑、红方回应与修改、蓝方复评直到达到最大轮次或者裁决者认为“方案已收敛”。这里的关键是轮次的交互粒度。让红方每一次都重写完整方案会让上下文越滚越长成本急剧膨胀而且后期轮次的修改往往只动了皮毛对决策质量贡献很小。一种更高效的设计是分两阶段前两轮做“粗粒度对抗”让蓝方从整体框架上质疑后面几轮只做“定点补丁”红方只被要求回复针对蓝方质疑的具体段落修改。这个模式既保证了对抗深度又控制了 token 消耗实测下来决策质量和成本曲线要健康得多。3. 从零搭建一个辩论式 Agent 系统核心伪代码与参数选择理论讲清楚了下面进入工程落地。我直接给出一套可以快速启动的最小实现思路选用 Python 伪代码展示核心流程你在此基础上替换不同的模型接口或消息协议即可。3.1 定义角色提示词实现的第一步是定义红蓝方以及裁决者的提示词。角色提示词可以单独以模板文件管理方便后续做版本迭代。RED_SYSTEM_PROMPT 你是一位严谨的方案论证者。 你需要基于给定的上下文提出一个尽可能合理的决策或方案。 要求 1. 明确给出你的结论。 2. 给出最多三条核心理由每条理由必须对应具体事实或逻辑。 3. 指出你的方案成立的前提条件。 4. 不要使用模糊表述不要回避约束条件。 BLUE_SYSTEM_PROMPT 你是一位严格的审查者负责对给定方案进行压力测试。 你的任务是找出方案中潜在的逻辑断层、与约束条件的冲突、信息盲区以及反例场景。 要求 1. 你的质疑必须直接引用对方方案中的具体内容或结论。 2. 对每一条质疑必须给出一个具体的反例或边界情形。 3. 不要泛泛而谈“风险较大”要指出风险发生的具体路径。 4. 如果方案确实没有明显问题请说明评估依据不要强行制造问题。 JUDGE_SYSTEM_PROMPT 你是一位公正的决策协调者。 你会收到方案提出者和审查者的多轮讨论记录。 请基于讨论内容给出最终决策。 必须输出JSON格式 { final_answer: 最终决策内容, decision_reasoning: 决策依据说明采纳或拒绝了哪些观点, risk_note: 最终方案仍需注意的风险点 } 这里有个细化的小细节在大多数开源模型中蓝方提示词里的第4条反而非常关键。如果不写这一条模型很容易陷入“鸡蛋里挑骨头”的模式导致红方后面每一轮都在应对一些无关紧要的质疑整体辩论效率直线下降。3.2 主流程实现核心循环逻辑是三层嵌套对话生成、批判循环、最终裁决。def run_debate(task_context, max_rounds3): messages [] # 阶段一红方初始方案 red_prompt [ {role: system, content: RED_SYSTEM_PROMPT}, {role: user, content: task_context} ] red_solution call_llm(red_prompt) messages.append({role: red, content: red_solution}) # 阶段二蓝方质疑与红方回应循环 for i in range(max_rounds): blue_prompt [ {role: system, content: BLUE_SYSTEM_PROMPT}, {role: user, content: ( 以下是当前方案\n red_solution \n\n请输出你的质疑与反例。 )} ] blue_critique call_llm(blue_prompt) messages.append({role: blue, content: blue_critique}) if i max_rounds - 1: break refine_prompt [ {role: system, content: RED_SYSTEM_PROMPT}, {role: user, content: ( 这是你之前的方案\n red_solution \n\n这是审查者给出的质疑\n blue_critique \n\n请回应这些质疑并输出修订后的完整方案。 )} ] red_solution call_llm(refine_prompt) messages.append({role: red, content: red_solution}) # 阶段三裁决 judge_prompt [ {role: system, content: JUDGE_SYSTEM_PROMPT}, {role: user, content: format_debate_record(messages)} ] final_decision call_llm(judge_prompt, response_formatjson) return final_decision, messages这个流程里我刻意省略了模型调用接口的细节因为不同模型服务商 API 不一样。你只需要关注数据流的走向红方生成原文、蓝方按原文输出质疑、红方带着质疑回来修订、最后裁决者一次性读取全程记录。3.3 参数选择的经验值搞定流程之后最直接的一个问题是模型参数怎么设置我基于反复实验给你三个可以直接对照的经验值。首先说温度参数temperature。红方的温度不宜过低建议设置在 0.5~0.7 之间因为红方承担的是方案发散的任务温度太低容易陷入重复和保守蓝方的温度建议设置在 0.3~0.4批判任务需要的是稳定性和准确性而不是发散性裁决者的温度直接调到 0裁决阶段要的是确定性任何创造性的发挥对最终决策都是减分项。然后是轮次上限。我调试下来最舒服的是 2~3 轮。第一轮蓝方指出硬伤红方修改第二轮蓝方做复核此时大部分实质问题已经暴露到第三轮时往往已经是“挤牙膏”式的边缘优化。超过三轮后对话历史越来越长而新信息的边际收益迅速衰减。在很多场景下两轮对抗加一次裁决已经能覆盖 90% 的质量提升空间。还有个容易被忽略的参数是输出长度上限max_tokens。蓝方输出一定要给足长度否则它会倾向于只挑一个问题点就截止了。我给蓝方设置的最小输出长度是 800 tokens目的就是强迫它尽量完整地列举出方案的多处风险。红方修订阶段的输出长度则要比初始方案更长因为它除了要复述方案还要对质疑做出回应。4. 提升决策质量的关键裁决设计、记忆机制与收敛策略上面那一版实现已经能跑通了但真正决定系统上限的是裁决设计和记忆策略。这里单独拿出来展开说因为这些细节是文档里很难找到的基本都是项目里调出来的经验。4.1 裁决者不是“聊天记录总结器”这是我觉得最核心的问题。很多人直接把红蓝两方的历史输出一股脑塞给裁决者让它给答案结果得到的裁决往往偏向红方——因为红方修订后的方案占据了对话后半段的注意力。所以我在实践中加入了“结构化对抗摘要”的步骤。在把历史记录交给裁决者之前先让一个独立的总结模块提取红蓝双方的核心论点矩阵红方核心依据 1. 约束条件 A 与逻辑链条 B 推导出方案 C 2. 数据 D 支持预期目标可达性 蓝方核心质疑 1. 约束条件 A 在场景 E 下可能失效反例... 2. 预期目标可达性忽略了变量 F 的干扰影响路径... 红方回应 1. 已澄清条件将适用边界限定为... 2. 增加补偿策略 G...裁决者看到的是提炼后的论点而不是原始对话流水账。这个动作让裁决准确率提升非常明显因为它有效消除了“对话惯性”对裁决的干扰。4.2 引入历史记忆让辩论不“失忆”另一个问题是每轮辩论之间的孤立性。如果在一次任务中你需要连续决策多个子问题前一个决策已经被裁决后一个决策还从零开始辩论系统就白白浪费了已经沉淀下来的判断经验。我的做法是维护一个跨轮次的决策记忆库存储每个子问题最终决策的摘要和主要争议点。下一轮辩论时将“之前被否决的候选方案及其原因”注入上下文作为蓝方的初始提示语以下是本任务先前阶段中已被否决的方案要点 - 方案 X 被否决原因与约束 A 冲突 - 方案 Y 被否决原因未能覆盖场景 E 请在你的质疑中优先检查当前方案是否包含同类问题。这个策略特别适合那种“任务链条很长”的 Agent 应用比如自动化工作流编排、长文档决策分析。它让红蓝对抗从“单点审校”升级为了“累积式审校”。4.3 轮次收敛的提前终止机制辩论不能干等 max_rounds 到期。我在实际运行中增加了提前终止的逻辑当蓝方连续一轮输出的内容被判定为“无新信息”时立即触发裁决。判断“无新信息”的办法很简单——计算本轮蓝方输出与前两轮的语义相似度超过阈值就停止。这样能省下不少无谓的 token 消耗同时避免模型陷入自我重复的怪圈。具体实现我建议用 embedding 模型算相似度而不建议直接让模型自评。因为自评本身又会引入一次模型调用和不确定性embedding 相似度则是一个可解释、可调节量化的指标阈值从 0.82 起步调试即可。4.4 红方的“记忆性修正”与“全局修正”分离最后聊一个我在多轮辩论中踩过坑后才补上的修改把红方修改方案的方式分成两种。一种是在蓝方质疑基础上的“记忆性修正”——只改与质疑相关的部分另一种是“全局修正”——重新审视整个方案。如果红方每次都在全局层面上重写很容易出现改掉一个已知问题而引入另一个新问题的“修补震荡”。我的做法是在前几轮只允许记忆性修正并且明确要求红方“仅在你认为与质疑相关的部分做修改并说明修改前后逻辑变化”。最后一轮如果需要再允许全局修正。这样做的效果是方案演进路径更加稳定裁决者面对的候选方案之间差异不会过大决策的可解释性也更强。5. 实战避坑我踩过的 6 个坑与排查实录这套机制远不是“两个模型互相骂两句再找个裁判来判高下”那么简单。真正落地时有六个问题特别容易让新手破防我把排查思路一并整理出来直接对应到具体的调试步骤。5.1 蓝方“强词夺理”狂潮现象蓝方就每个细节都提出质疑无论红方怎么补充它都能挑出新毛病导致辩论无法收敛。排查过程先看蓝方输出中是否有很多“缺乏具体指摘对象”的表述。我排查后发现是系统提示词中缺少“禁止无依据质疑”的约束。修复方式就是在 BLUE_SYSTEM_PROMPT 中强调每一条质疑必须引用原方案中的具体句子并给出反例场景。修复后蓝方输出质量有了明显提升辩论效率回到合理水平。5.2 红蓝双方互相“捧场”现象蓝方变成了“好的方面但我认为这里其实没什么大问题”红方再回“谢谢指正我认为你提得很好”辩论彻底沦为聊天。这个问题的根因在于模型本身就偏好和谐与正面回应。我的处理办法是在提示词中明确告诉蓝方如果它没有提出任何有实质价值的质疑那么这轮辩论记录将不会进入裁决者的输入并暗示其角色价值未被体现。同时我会在裁决输入中过滤掉客套话部分只保留结构化的质疑与回应内容。5.3 裁决者被蓝方带偏现象裁决结果过度偏向质疑方即使红方的方案其实已经考虑过这些问题。这个问题的典型原因有两个。一个是裁决前输入的记录太原始、太长裁决者很难抓住主线另一个是蓝方的质疑语气往往比红方更笃定、更强烈模型天然记住的是尖锐的观点。我解决的办法就是前面说的“结构化对抗摘要”——先让摘要模块把双方观点拧成清单再做裁决。5.4 辩论后方案的修改幅度过大导致偏离原始目标现象红方初稿本来基本可用经过两轮对抗后给出的方案却跟初始需求越走越远。排查后发现是提示词中的“请根据质疑修订方案”指令过于开放。红方为了回应质疑会把方案往“绝对安全”方向带丧失了对原始目标的专注。修复方式是在修改指令中强制加入“你的修订必须保持初始方案的核心结论不变仅调整受到影响的部分”并且增加一个“问题回应”与“方案主体”分离的输出结构。5.5 上下文溢出现象第三轮、第四轮辩论时中间历史太长直接给出“context length exceeded”。这个问题最严重影响使用体验。两个角色各有长输出再加上每轮都重新传入对方的内容token 膨胀得非常快。我的处理方式是先做中期摘要在每轮对抗结束后将对话历史压缩为论点摘要、尚未解决的分歧和已确认的一致性三种信息再作为下一轮的上下文输入。这套策略让同样的 token 预算能支撑更多有效轮次。5.6 辩论结果不稳定同一次任务跑两遍结果不一致现象同一输入跑两次一次裁决方案是 A一次裁决方案是 B。原因往往出在温度设置和采样随机性上。裁决阶段必须设置温度 0同时尽量保持输入不变才能确保结果的稳定可复现。若业务上对可解释性有硬性需求还可以将辩论过程中的每一次中间输出都持久化存储之后做结果审计时可以直接还原决策路径。6. 后续还能往哪个方向扩展这套机制目前在我自己的项目里已经稳定运行了一段时间。最直接的价值体现在两个场景一个是那些“错误代价较大”的决策类任务另一个是“答案没有绝对标准、需要综合多方考量”的开放式任务。前者比如自动化代码审查、系统变更方案评估后者比如产品路线图生成、报告的结构化评审。现在这个框架本身也已经有了不少值得深挖的扩展方向。比如多角色不仅仅局限于红蓝两方还可以引入“用户代理”“数据代理”“合规代理”等不同的立场。再比如引入差异化模型蓝方用一个参数更小、但指令遵循能力更强的模型红方用能力更强的模型这能在成本不受太大冲击的条件下兼顾质量。还有一点是我最近在尝试的让裁决者输出的不只是最终答案而是带权重的备选方案排序——这样在主决策失败时我们可以直接回退到第二优选项而不必重新跑一套辩论系统。我在把这个方案分享给团队时经常说一句话多智能体辩论的核心价值不在于让模型“吵出真理”而在于让每个候选方案的“证据链”被充分暴露出来让决策过程变得透明、可审计、可改进。只要你对决策质量有要求这套多角色对抗的思路就一定有它的用武之地。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
