我们内部开始认真研究多智能体辩论机制是因为在模拟项目X里碰到了一次很典型的失败。当时产品负责人提了个需求把客服售后判责流程交给 Agent 来做。我给一个争议样本跑了一遍单 Agent 很快给出不符合换新条件的结论推理链写得有板有眼还引用了一个条款编号。结果我随手翻了翻原文发现它引用的编号压根对不上结论自然也不成立。真正让人抓狂的不是出错而是出错时那股不容置疑的自信。这个体验让我彻底意识到一件事单 Agent 的推理链再长也只是一条推理链。想让决策更稳得让多条立场对立的推理链互相攻击、互相证伪。红蓝对抗正是这一类机制的典型代表它把多智能体辩论从学术实验搬到了工程决策里。这篇文章我会从底层逻辑讲起把角色设计、辩论协议、成本控制和一些踩坑经验全部过一遍适合正在搭建 Agent 决策链路、对单点判断不放心、想给决策做质控的朋友。1. Agent 的自信与正确是两回事问题从哪来1.1 续写式生成决定了它会优先选择流畅而非正确大模型本质上是一个连续续写的概率系统。你在输入框里抛出一个决策问题它内部每一轮都在根据已经写出的内容挑一个概率最高的词接下去。这带来一个隐蔽的问题在有歧义、信息不完整的决策场景里模型最擅长的其实是编出一段看起来像模像样的推理而不是给出尽了最大可能接近真实的结论。我对这个特征印象很深是因为我们在模拟项目X里跑过一批信息缺省的测试样本。有些样本其实缺少关键事实比如商品的购买凭证没上传、售后记录里出现了一条矛盾时间戳。单 Agent 在这种输入下不会停下来问这里缺凭证我没法判断它反而会顺着上下文用训练数据里的常见模式把缺口填上。说白了模型从概率分布里猜了一个在过去常见的数据里最常出现的走向然后用流畅的推理把它包装成结论。这个行为模式和一个人面试时口才特别好是同一个道理他能把完全不成立的逻辑说得滴水不漏不是因为逻辑对而是因为话说得顺。所以自信只是续写过程的副产物它和正确之间没有任何必然联系。1.2 自查式反思经常只是表面修补很多人第一反应是让 Agent 自己检查自己也就是所谓的自我反思。做法很简单先生成一版答案再追加一句请检查上述回答中的错误并改进。这个思路直观但我实测下来的效果很一般。我们拿一组 30 条样本做过对比单 Agent 自查后能把事实性错误真正修正的比例大概只有两成剩下八成里一半是在调整措辞另一半更离谱——把原本正确的答案改错了。原因其实不难理解让同一个模型检查自己它用的还是同一套权重、同一个训练先验、同一份上下文。它并没有另一个视角去重新审视问题只是在一个已经生成的解释上继续续写。你让它自查它大概率会续写出另一段更克制、更严谨的表述但严谨感不等于有了新依据。它看不到自己没看到的东西这就像让一个写字的人审自己的稿子眼睛会自动跳过自己常犯的错。1.3 多路径采样只有配合对抗才有意义既然一条路径不稳那就采样多条路径。这也是不少人用过的自洽性投票同一个问题让模型生成 N 个答案然后多数表决。投票对有明确正确答案的任务是有效的因为它可以把分散的错误概率抹平。但换到开放性的高风险决策投票就有个大问题N 个答案来自同一个底座模型共享同一套先验偏差。当它们想到一块儿去的时候投票只会让错误的共识再吃一次强化。多智能体辩论不一样的地方在于它引入了一个角色结构让其中一方必须扮演反对者。反对者不会顺着你的推理走下去它对每个结论都追问一句你凭什么这么判断有没有反例有没有别的解释这样一来原本的同源单一路径就被拆成了两套竞争性路径。防守方要么被逼着把方案里的漏洞补上要么就要拿出更强的证据来解释为什么自己是对的。这一步就是从单 Agent 的一条路走到黑变成红蓝双方的相互证伪。这也是后面所有工程设计的出发点。2. 红蓝对抗的底层逻辑对抗性证伪为什么更有效2.1 从证实偏差到竞争性假设人类决策里有个根深蒂固的毛病叫证实偏差一旦结论写成文字我们接下来的注意力就会自动偏向找支持这个结论的证据。单 Agent 生成答案时也有这个倾向。它先续写出一个可能的结论后面所有的推理都会朝着解释这个结论为什么对的方向走。红蓝对抗的底层逻辑就是用一个强制角色去制造竞争性假设。红队的任务不是补充支持证据而是专门生成与蓝队结论相反的假设、相反的边界条件、相反的解释路径。蓝队要是忽略这些它就输蓝队要是能回应这些说明方案里被隐藏的假设真正被翻出来晒过了。这里面有个很关键的点对抗性证伪的效率远高于自我证实。你很难靠我再想想发现自己漏了什么但你很容易在别人给你一个具体的反例时意识到哦这个情况我没考虑。Agent 之间也是一样一个具体攻击点能迅速逼出防守方的盲区。2.2 收益结构决定了辩论不会变成各说各话很多人会觉得让两个 Agent 吵架最后不过是各说各话。但我看到的多数失败案例问题恰恰出在没有把收益结构设计好。红蓝对抗能成立是因为每一方都有明确的收益约束红队的收益是找到新的、具体的漏洞。如果它只是重复我觉得不靠谱裁判会给低分。蓝队的收益是让方案在攻击后变得更完整。如果它只会复述原方案裁判同样会给低分。裁判的收益是给出一个能被执行的最终决策。它不能和稀泥。这就像代码评审。评审人如果只说这段代码有问题但不指出哪一行有什么问题这种评审毫无价值只有指出这个分支缺少空指针判断的评审才能真正逼作者改出好代码。红蓝对抗本质上就是一种强结构的评审系统它把发现问题和修复问题两件事拆分到不同角色身上再用打分机制强制两边都认真干活。2.3 机制有效的三个前提我落地过几版这样的系统也读过不少团队的分析最后发现这机制能不能起作用完全压在这三个前提上第一红队要具备二阶攻击能力。它不能只是简单地否定而要能针对蓝队论据的隐含前提、引用的数据、涉及的边界条件发起攻击。提示词里必须写清楚你的攻击要落到具体句子或具体依据上。第二蓝队要具备可修改性。也就是说蓝队的输出结构里必须有一项是修改后的完整方案而不是让它只在原文上补几段话。很多项目做辩论做成了讨论,就是因为蓝队没有真正被要求产出新的决策文本。第三裁判必须可审计。裁判不能只给一个分数或一句我同意红队观点它必须给出分维度的理由并且理由要能对应到具体文本。否则整个机制就失去了做决策的目的变成两个 Agent 在昂贵地聊天。这三个前提我在每次上线前都会当成验证清单去过一遍。如果小样本上这三个前提不成立我不会继续加轮数而是先回去改提示词和输出结构。3. 角色设计的工程化写法红队、蓝队与裁判的提示词3.1 红队质疑者的攻击面规划红队的提示词是最不能偷懒的。我见过太多人直接把你是红队请找出问题丢给模型结果收回来一堆我认为这个方法存在风险这种正确的废话。我在项目里会把红队的攻击面拆成四类让它按类出牌一是事实性攻击针对方案里引用的数据、条款、时间、来源二是逻辑性攻击针对推理链里的跳跃、以偏概全、因果倒置三是边界性攻击主动构造反例和极端场景问如果用户没上传凭证怎么办如果系统日志本身错了怎么办四是目标性攻击质疑这个决策目标本身是不是问错了。红队的系统提示词我一般会写成下面这样你是辩论中的红队职责是对蓝队给出的决策方案发起攻击。你的攻击必须具体禁止泛泛而谈。 攻击要求 1. 每一条攻击必须指出方案中对应的原文或对应依据。 2. 每一条攻击必须包含一个具体反例、遗漏场景或证据矛盾不能只表达怀疑。 3. 优先攻击事实、逻辑、边界、目标四类不要重复已经出现过的质疑点。 4. 如果本轮没有新的攻击点请明确输出无新增质疑。这里面第 3 条和第 4 条特别重要。不让红队重复是为了防止它在多轮辩论里重复输出同一批问题要求它明确写无新增质疑是在为后面的收敛判定提供信号。3.2 蓝队守卫者的输出结构蓝队的提示词核心不是辩护而是修复。很多人会误解防守方的职责以为要让它把方案讲得更有说服力。实际恰恰相反蓝队最重要的是听见质疑后真的改方案。我会要求蓝队输出固定的四个部分你是辩论中的蓝队负责给出并持续修订决策方案。你的职责是对抗红队攻击并输出更可靠的方案。 输出格式 1. 逐条回应红队质疑每条标明采纳或不采纳。 2. 对采纳的质疑给出具体修改 diff说明修改了哪一句、改成了什么。 3. 对不采纳的质疑给出明确的反驳理由禁止情绪化表达。 4. 输出修订后的完整决策方案方案必须是可以直接执行的文本。这个结构解决了两个问题。一是让裁判能快速看出谁听进了谁的话争议点是不是真的闭合了二是防止蓝队防御过度——有些蓝队被怼几轮之后会把方案改得越来越保守所有条件都加上限制最后变成一条什么都做不了的免责声明。固定输出格式至少能让你从文字上看见它在怎么改。3.3 裁判程序约束比内容更聪明裁判是这套机制里最容易被低估的角色。模型当裁判有个通病谁字多、语气坚定它就觉得谁更有道理。所以我一般会给裁判加两道程序约束。第一道约束是先引用后打分。裁判在给任何维度打分之前必须先引用方案中的原文或红队攻击的具体表述不得只写我认为综合来看。这能强迫裁判把判断锚在文本上。第二道约束是给最终决策而不是给意见。裁判的输出除了分数还必须包含一条最终决策文本这个文本是给下游执行的不能是建议双方继续讨论这种话。评分维度我一般会用这五档逻辑一致性、事实准确性、风险覆盖度、可行性、证据充分性。每个维度 1 到 5 分。如果事实准确性维度低于 3 分我会把决策自动挂起转人工或转外部工具核验不允许直接走完流程。4. 辩论协议的执行细节回合、上下文截断与收敛判定4.1 回合节奏三轮是比较好的默认值辩论不是回合越多越好。我测试下来绝大多数决策问题在两到三轮红蓝交锋之后就已经收敛再往上走红队开始挤牙膏蓝队开始打转成本倒是直线上升。我默认用的是这样的四步流程第 0 轮蓝队基于初始上下文给出首版方案。第 1 轮红队针对首版方案发起攻击。第 2 轮蓝队逐条回应并给出修订版方案。第 3 轮红队对修订版做复审确认哪些攻击已被解决哪些仍未解决。三轮之后裁判做最终评分和裁决。如果红队在第 3 轮没有新增质疑流程可以提前走完如果红队在第 3 轮又炸出了全新的攻击面那才考虑追加一轮。追加轮数一定要走显式判断逻辑不能靠运气管够就无限循环。4.2 上下文截断喂给模型的是摘要不是全文多轮辩论最大的工程坑是上下文膨胀。第一轮双方各写一千字第二轮就要带着上一轮的全量文本再各写一千字到第三轮光是历史文本就占了很大比例模型要么开始忘掉前面的规则要么回答质量随长度明显下降。我的办法是不让模型读全量历史只让它读结构化的争议记录。这个记录是一个紧凑的列表每个争议点只保留四样东西编号、质疑摘要、是否为新增质疑、上一轮的处理状态。加上蓝队上一轮的完整方案文本就足够红蓝双方继续了。结构化记录用 JSON 来组织非常顺手{ round: 2, issues: [ { id: 1, type: fact, claim: 条款编号引用错误, status: adopted, resolved: true } ], current_plan: 蓝队最新修订后的决策方案文本 }这样每轮喂进去的 token 基本可控而且裁判最后看到的也是一份干净的争议演进记录而不是几千字的聊天流水账。4.3 收敛判定写得越小越好我踩过最大的坑之一就是没有显式的收敛判定。当时我把最大轮数设成 5以为足够结果有样本真的跑满 5 轮每轮都还能产出一点新内容但决策质量并没有提升反而因为修改太多方案变得越来越拧巴。现在我至少会用三种终止信号任何一个触发就停def should_stop(round_no, max_rounds, diff_token_rate, new_attack_count): if round_no max_rounds: return True if new_attack_count 0: return True if diff_token_rate 0.05: return True return Falsediff_token_rate 是蓝队修订前后 token 级差异占方案总长度的比例。如果蓝队上一轮几乎没改说明双方已经达成某种平衡再来一轮意义不大。我也会看裁判得分提升量连续两轮得分提升低于 0.1 分就直接收口。5. 选型与成本不是所有任务都值得辩论5.1 什么样的任务值得引入红蓝对抗红蓝对抗不是银弹它有明显的适用边界。我在项目里会拿一份清单来判断第一决策代价要高。如果答错了只是推荐位展示问题不值得上一套完整辩论但如果是赔付金额、代码上线、合规判断这类高代价决策就值得。第二存在明确的对立利益视角。比如售后场景里的消费者视角和商家视角本身就对立很适合红蓝对抗而这个新闻标题该怎么起这种问题立场模糊收益也模糊。第三事实可以被外部核验。如果连事实都无从查起辩论的事实准确性维度就很容易变成双方互相空转。第四对时延和预算有容忍度。一次完整辩论通常要调用多次模型无法做到几十毫秒响应。5.2 和投票、反思、ReAct 的边界划分我会把这些方案放在同一个坐标里看核心变量是任务有没有外部标准答案。当任务有明确标准答案时自洽性投票性价比最高又快又稳。当任务需要查知识、读多份文档时ReAct 这类带工具调用的方案更合适它能边查边改。但当任务没有标准答案且要在一个模糊空间里做高风险取舍时投票会放大共识偏见ReAct 又缺乏一个专门挑战结论的机制。这个时候红蓝对抗的价值才会体现出来。我把自己的选型逻辑总结成一张表直接抄作业就行任务特征推荐机制理由有标准答案要求速度单 Agent 自洽性投票成本低收敛快需要检索大量资料ReAct / 工具增强事实边界清晰高风险、立场对立、无唯一答案红蓝对抗 裁判强制暴露盲区任意类型但预算极紧单 Agent 自查接受一定错误率5.3 成本模型与两阶段预筛红蓝对抗的成本是可以提前估算的。一次完整决策基本等于红队攻击、蓝队修订、蓝队终稿、裁判裁决这几次调用的总和再乘以回合数。按一个中大型商业模型接口来算单次调用输入 2000 token、输出 1000 token三轮下来一次决策大概要消耗两万到三万个 token。如果决策量大这个成本是真的会咬人的。我后来做了两阶段预筛先用一个相对便宜的模型快速评估任务的风险度如果风险度不高直接走普通推理只有高风险样本才进入完整红蓝对抗。实测下来大约能省下六七成的调用量而且高风险的决策质量没有明显下降。判断要不要深挖这个动作本身是低风险的交给轻量模型足够。6. 我们踩过的坑四种失效模式与修复方式6.1 同源偏见导致的理性漂移最让我惊讶的失效模式是红蓝双方在一轮轮辩论之后居然慢慢统一到同一个错误结论上。我以为只要立场对立结论就会被拉回真实结果发现双方用的是同一个底座模型训练先验一模一样。红队的攻击里带着同样的偏见蓝队的防守也同样带着辩论走几个来回两边就在一个没有事实锚点的空间里达成了新的共识。对此我做了三件事第一在条件允许时用异质模型组合比如让红队用开源小模型、蓝队用主流商用接口哪怕只是模型差异先验也会被拉开。第二给红队注入外部领域知识视角比如让红队站在真实用户的立场上而不是站在通用模型的立场上。第三在裁判评分里加了一条单边置信检查当红蓝双方意见完全一致时自动把方案转交给外部工具做事实核验不允许凭双方都同意就放行。6.2 红队为杠而杠蓝队疲于防守第二种坑是红队开始低质量输出。它每一轮都能找到问题但都是泛泛的这里不够严谨那里有潜在风险。这些质疑本身没什么证据价值却会消耗蓝队的上下文窗口和预算让蓝队花大量篇幅去回应一些空话。修复方式是我在生产环境里加的攻击配额和质疑去重池。每轮红队最多新增三个质疑点且必须说明属于哪个攻击面裁判对质疑质量打分如果一个质疑连续两轮被打为低质量攻击就直接从争议记录里移除。这样红队会被迫只挑真正重要的点打不再靠数量凑业绩。6.3 裁判被论证长度和语气带偏裁判是最容易出问题的环节。模型裁判天然喜欢写得更长、说得更决绝的那一方哪怕那一方的论据细看根本不成立。我们跑过一个专门测试把红队和蓝队的文本互相换成对方的名字再让裁判打分。结果相当难看——只要名字标签换掉分数跟着换说明裁判在审的不是内容是身份。现在的做法是盲评加立场置换双重保险。盲评阶段裁判看到的文本不标发言者只有编号立场置换阶段把双方文本交换后再打分一次。两次结果差异超过一定幅度就触发人工复审。这个机制简单有效成本多不了多少但能把裁判的偏见拦掉一大半。6.4 上下文膨胀与角色漂移这里说的是另一种贵而不干活的情况。当辩论上下文变长红队和蓝队会慢慢忘记自己是来干什么的。红队开始替蓝队出主意蓝队开始主动承认对方说得有道理然后疯狂让步。角色漂移一旦发生对抗的意义就消失了。我现在用三个手段来压住它一是每轮调用都把系统提示词重新注入强调身份和职责二是用结构化争议记录代替全量历史减少上下文对身份的稀释三是把工具输出、检索结果和辩论正文分离开不让外部信息污染角色记忆。6.5 成本失控不设上限的辩论是无底洞最后这个坑是我刚开始最有感触的不设轮数的辩论理论上能一直进行下去。模型会不断发现新的边角蓝队会不断做局部修补看起来双方都很努力实际上只是在原地制造 token。所以无论怎么调参我都会给硬性的最大轮数上限并且上线前用真实样本跑一遍收益-轮数曲线找到收益拐点把上限卡在拐点之后一轮。这四条失效模式我整理成了一张表方便团队排查问题典型现象修复策略同源偏见双方有共识地走向错误异质模型组合、单边置信触发核验为杠而杠攻击点数量多、质量低攻击配额、质疑质量打分、低质质疑移除裁判偏见谁字多谁赢换标签就换分盲评、立场置换复评上下文膨胀角色漂移、成本飙升结构化摘要、系统提示重注入、硬顶轮数7. 进阶让事实进场辩论才不会变成文字游戏7.1 引入外部工具作为事实仲裁者纯文本辩论有一个天花板双方都在用模型记忆里的知识互搏而模型记忆是会错的。要突破这个天花板就得让事实从外部进来。我的做法是在辩论中加入事实主张抽取环节。红队攻击时如果提到某条款应该是什么蓝队回应时如果引用了某数据是多少这些句子都会被抽出来变成待核验的声明。系统把它们送去检索工具或业务数据库检索结果直接进入裁判的上下文成为事实维度的打分依据。这样做之后辩论的性质起了变化它不再是一场比赛谁能把话说得更圆而是一场比赛谁能把证据摆得更准。红队不再是纯粹的嘴炮攻击蓝队也不能靠话术硬撑。这是我把这套机制从能跑推到可信最关键的一步。7.2 从一对一对抗升级到角色池场景多了之后一套通用红队会越来越不够用。售后判责需要用户视角的红队代码评审需要边界条件视角的红队合规判断需要条款视角的红队。我后来的做法是建一个角色池里面有逻辑红队、事实红队、用户视角红队、合规红队等等再根据任务标签激活对应角色。裁判同样可以升级。当前面跑的是高价值决策时我会用三个不同模型的裁判各评一轮三个结果不一致就触发复核而不是让单一裁判一锤定音。这个陪审团方案成本会再高一截但真正落到高赔付、高风险的决策上这笔钱是值得的。7.3 决策留痕是把辩论机制当资产经营的关键所有辩论过程我都要求留痕谁提了什么质疑、蓝队改了什么、裁判给了几分、最终决策是什么。这些记录不只是审计用的更是我们持续优化机制的数据来源。我们在调试阶段做过一件事把历史辩论样本里的好裁判裁决整理成标注集用来评估新版本提示词的质量也把蓝队修复后得分提升明显的样本收集起来作为调优蓝队策略的正例。辩论机制运行得越久这笔留痕资产就越值钱甚至能反哺整个人工评估体系。最后说一个我始终保留的习惯每次做这类决策链路改造我都会先挑 30 条有代表性的老样本跑一套小规模的两轮版本亲手看一遍红队输出的攻击质量、蓝队有没有真改、裁判能不能给出可执行结果再决定要不要上完整版。红蓝对抗这套东西思路不难理解难的是每个角色都容易在自己的岗位上偷懒你得靠协议设计和评测数据把它们的懒惰一个一个堵回去。
我们内部开始认真研究多智能体辩论机制是因为在模拟项目X里碰到了一次很典型的失败。当时产品负责人提了个需求把客服售后判责流程交给 Agent 来做。我给一个争议样本跑了一遍单 Agent 很快给出不符合换新条件的结论推理链写得有板有眼还引用了一个条款编号。结果我随手翻了翻原文发现它引用的编号压根对不上结论自然也不成立。真正让人抓狂的不是出错而是出错时那股不容置疑的自信。这个体验让我彻底意识到一件事单 Agent 的推理链再长也只是一条推理链。想让决策更稳得让多条立场对立的推理链互相攻击、互相证伪。红蓝对抗正是这一类机制的典型代表它把多智能体辩论从学术实验搬到了工程决策里。这篇文章我会从底层逻辑讲起把角色设计、辩论协议、成本控制和一些踩坑经验全部过一遍适合正在搭建 Agent 决策链路、对单点判断不放心、想给决策做质控的朋友。1. Agent 的自信与正确是两回事问题从哪来1.1 续写式生成决定了它会优先选择流畅而非正确大模型本质上是一个连续续写的概率系统。你在输入框里抛出一个决策问题它内部每一轮都在根据已经写出的内容挑一个概率最高的词接下去。这带来一个隐蔽的问题在有歧义、信息不完整的决策场景里模型最擅长的其实是编出一段看起来像模像样的推理而不是给出尽了最大可能接近真实的结论。我对这个特征印象很深是因为我们在模拟项目X里跑过一批信息缺省的测试样本。有些样本其实缺少关键事实比如商品的购买凭证没上传、售后记录里出现了一条矛盾时间戳。单 Agent 在这种输入下不会停下来问这里缺凭证我没法判断它反而会顺着上下文用训练数据里的常见模式把缺口填上。说白了模型从概率分布里猜了一个在过去常见的数据里最常出现的走向然后用流畅的推理把它包装成结论。这个行为模式和一个人面试时口才特别好是同一个道理他能把完全不成立的逻辑说得滴水不漏不是因为逻辑对而是因为话说得顺。所以自信只是续写过程的副产物它和正确之间没有任何必然联系。1.2 自查式反思经常只是表面修补很多人第一反应是让 Agent 自己检查自己也就是所谓的自我反思。做法很简单先生成一版答案再追加一句请检查上述回答中的错误并改进。这个思路直观但我实测下来的效果很一般。我们拿一组 30 条样本做过对比单 Agent 自查后能把事实性错误真正修正的比例大概只有两成剩下八成里一半是在调整措辞另一半更离谱——把原本正确的答案改错了。原因其实不难理解让同一个模型检查自己它用的还是同一套权重、同一个训练先验、同一份上下文。它并没有另一个视角去重新审视问题只是在一个已经生成的解释上继续续写。你让它自查它大概率会续写出另一段更克制、更严谨的表述但严谨感不等于有了新依据。它看不到自己没看到的东西这就像让一个写字的人审自己的稿子眼睛会自动跳过自己常犯的错。1.3 多路径采样只有配合对抗才有意义既然一条路径不稳那就采样多条路径。这也是不少人用过的自洽性投票同一个问题让模型生成 N 个答案然后多数表决。投票对有明确正确答案的任务是有效的因为它可以把分散的错误概率抹平。但换到开放性的高风险决策投票就有个大问题N 个答案来自同一个底座模型共享同一套先验偏差。当它们想到一块儿去的时候投票只会让错误的共识再吃一次强化。多智能体辩论不一样的地方在于它引入了一个角色结构让其中一方必须扮演反对者。反对者不会顺着你的推理走下去它对每个结论都追问一句你凭什么这么判断有没有反例有没有别的解释这样一来原本的同源单一路径就被拆成了两套竞争性路径。防守方要么被逼着把方案里的漏洞补上要么就要拿出更强的证据来解释为什么自己是对的。这一步就是从单 Agent 的一条路走到黑变成红蓝双方的相互证伪。这也是后面所有工程设计的出发点。2. 红蓝对抗的底层逻辑对抗性证伪为什么更有效2.1 从证实偏差到竞争性假设人类决策里有个根深蒂固的毛病叫证实偏差一旦结论写成文字我们接下来的注意力就会自动偏向找支持这个结论的证据。单 Agent 生成答案时也有这个倾向。它先续写出一个可能的结论后面所有的推理都会朝着解释这个结论为什么对的方向走。红蓝对抗的底层逻辑就是用一个强制角色去制造竞争性假设。红队的任务不是补充支持证据而是专门生成与蓝队结论相反的假设、相反的边界条件、相反的解释路径。蓝队要是忽略这些它就输蓝队要是能回应这些说明方案里被隐藏的假设真正被翻出来晒过了。这里面有个很关键的点对抗性证伪的效率远高于自我证实。你很难靠我再想想发现自己漏了什么但你很容易在别人给你一个具体的反例时意识到哦这个情况我没考虑。Agent 之间也是一样一个具体攻击点能迅速逼出防守方的盲区。2.2 收益结构决定了辩论不会变成各说各话很多人会觉得让两个 Agent 吵架最后不过是各说各话。但我看到的多数失败案例问题恰恰出在没有把收益结构设计好。红蓝对抗能成立是因为每一方都有明确的收益约束红队的收益是找到新的、具体的漏洞。如果它只是重复我觉得不靠谱裁判会给低分。蓝队的收益是让方案在攻击后变得更完整。如果它只会复述原方案裁判同样会给低分。裁判的收益是给出一个能被执行的最终决策。它不能和稀泥。这就像代码评审。评审人如果只说这段代码有问题但不指出哪一行有什么问题这种评审毫无价值只有指出这个分支缺少空指针判断的评审才能真正逼作者改出好代码。红蓝对抗本质上就是一种强结构的评审系统它把发现问题和修复问题两件事拆分到不同角色身上再用打分机制强制两边都认真干活。2.3 机制有效的三个前提我落地过几版这样的系统也读过不少团队的分析最后发现这机制能不能起作用完全压在这三个前提上第一红队要具备二阶攻击能力。它不能只是简单地否定而要能针对蓝队论据的隐含前提、引用的数据、涉及的边界条件发起攻击。提示词里必须写清楚你的攻击要落到具体句子或具体依据上。第二蓝队要具备可修改性。也就是说蓝队的输出结构里必须有一项是修改后的完整方案而不是让它只在原文上补几段话。很多项目做辩论做成了讨论,就是因为蓝队没有真正被要求产出新的决策文本。第三裁判必须可审计。裁判不能只给一个分数或一句我同意红队观点它必须给出分维度的理由并且理由要能对应到具体文本。否则整个机制就失去了做决策的目的变成两个 Agent 在昂贵地聊天。这三个前提我在每次上线前都会当成验证清单去过一遍。如果小样本上这三个前提不成立我不会继续加轮数而是先回去改提示词和输出结构。3. 角色设计的工程化写法红队、蓝队与裁判的提示词3.1 红队质疑者的攻击面规划红队的提示词是最不能偷懒的。我见过太多人直接把你是红队请找出问题丢给模型结果收回来一堆我认为这个方法存在风险这种正确的废话。我在项目里会把红队的攻击面拆成四类让它按类出牌一是事实性攻击针对方案里引用的数据、条款、时间、来源二是逻辑性攻击针对推理链里的跳跃、以偏概全、因果倒置三是边界性攻击主动构造反例和极端场景问如果用户没上传凭证怎么办如果系统日志本身错了怎么办四是目标性攻击质疑这个决策目标本身是不是问错了。红队的系统提示词我一般会写成下面这样你是辩论中的红队职责是对蓝队给出的决策方案发起攻击。你的攻击必须具体禁止泛泛而谈。 攻击要求 1. 每一条攻击必须指出方案中对应的原文或对应依据。 2. 每一条攻击必须包含一个具体反例、遗漏场景或证据矛盾不能只表达怀疑。 3. 优先攻击事实、逻辑、边界、目标四类不要重复已经出现过的质疑点。 4. 如果本轮没有新的攻击点请明确输出无新增质疑。这里面第 3 条和第 4 条特别重要。不让红队重复是为了防止它在多轮辩论里重复输出同一批问题要求它明确写无新增质疑是在为后面的收敛判定提供信号。3.2 蓝队守卫者的输出结构蓝队的提示词核心不是辩护而是修复。很多人会误解防守方的职责以为要让它把方案讲得更有说服力。实际恰恰相反蓝队最重要的是听见质疑后真的改方案。我会要求蓝队输出固定的四个部分你是辩论中的蓝队负责给出并持续修订决策方案。你的职责是对抗红队攻击并输出更可靠的方案。 输出格式 1. 逐条回应红队质疑每条标明采纳或不采纳。 2. 对采纳的质疑给出具体修改 diff说明修改了哪一句、改成了什么。 3. 对不采纳的质疑给出明确的反驳理由禁止情绪化表达。 4. 输出修订后的完整决策方案方案必须是可以直接执行的文本。这个结构解决了两个问题。一是让裁判能快速看出谁听进了谁的话争议点是不是真的闭合了二是防止蓝队防御过度——有些蓝队被怼几轮之后会把方案改得越来越保守所有条件都加上限制最后变成一条什么都做不了的免责声明。固定输出格式至少能让你从文字上看见它在怎么改。3.3 裁判程序约束比内容更聪明裁判是这套机制里最容易被低估的角色。模型当裁判有个通病谁字多、语气坚定它就觉得谁更有道理。所以我一般会给裁判加两道程序约束。第一道约束是先引用后打分。裁判在给任何维度打分之前必须先引用方案中的原文或红队攻击的具体表述不得只写我认为综合来看。这能强迫裁判把判断锚在文本上。第二道约束是给最终决策而不是给意见。裁判的输出除了分数还必须包含一条最终决策文本这个文本是给下游执行的不能是建议双方继续讨论这种话。评分维度我一般会用这五档逻辑一致性、事实准确性、风险覆盖度、可行性、证据充分性。每个维度 1 到 5 分。如果事实准确性维度低于 3 分我会把决策自动挂起转人工或转外部工具核验不允许直接走完流程。4. 辩论协议的执行细节回合、上下文截断与收敛判定4.1 回合节奏三轮是比较好的默认值辩论不是回合越多越好。我测试下来绝大多数决策问题在两到三轮红蓝交锋之后就已经收敛再往上走红队开始挤牙膏蓝队开始打转成本倒是直线上升。我默认用的是这样的四步流程第 0 轮蓝队基于初始上下文给出首版方案。第 1 轮红队针对首版方案发起攻击。第 2 轮蓝队逐条回应并给出修订版方案。第 3 轮红队对修订版做复审确认哪些攻击已被解决哪些仍未解决。三轮之后裁判做最终评分和裁决。如果红队在第 3 轮没有新增质疑流程可以提前走完如果红队在第 3 轮又炸出了全新的攻击面那才考虑追加一轮。追加轮数一定要走显式判断逻辑不能靠运气管够就无限循环。4.2 上下文截断喂给模型的是摘要不是全文多轮辩论最大的工程坑是上下文膨胀。第一轮双方各写一千字第二轮就要带着上一轮的全量文本再各写一千字到第三轮光是历史文本就占了很大比例模型要么开始忘掉前面的规则要么回答质量随长度明显下降。我的办法是不让模型读全量历史只让它读结构化的争议记录。这个记录是一个紧凑的列表每个争议点只保留四样东西编号、质疑摘要、是否为新增质疑、上一轮的处理状态。加上蓝队上一轮的完整方案文本就足够红蓝双方继续了。结构化记录用 JSON 来组织非常顺手{ round: 2, issues: [ { id: 1, type: fact, claim: 条款编号引用错误, status: adopted, resolved: true } ], current_plan: 蓝队最新修订后的决策方案文本 }这样每轮喂进去的 token 基本可控而且裁判最后看到的也是一份干净的争议演进记录而不是几千字的聊天流水账。4.3 收敛判定写得越小越好我踩过最大的坑之一就是没有显式的收敛判定。当时我把最大轮数设成 5以为足够结果有样本真的跑满 5 轮每轮都还能产出一点新内容但决策质量并没有提升反而因为修改太多方案变得越来越拧巴。现在我至少会用三种终止信号任何一个触发就停def should_stop(round_no, max_rounds, diff_token_rate, new_attack_count): if round_no max_rounds: return True if new_attack_count 0: return True if diff_token_rate 0.05: return True return Falsediff_token_rate 是蓝队修订前后 token 级差异占方案总长度的比例。如果蓝队上一轮几乎没改说明双方已经达成某种平衡再来一轮意义不大。我也会看裁判得分提升量连续两轮得分提升低于 0.1 分就直接收口。5. 选型与成本不是所有任务都值得辩论5.1 什么样的任务值得引入红蓝对抗红蓝对抗不是银弹它有明显的适用边界。我在项目里会拿一份清单来判断第一决策代价要高。如果答错了只是推荐位展示问题不值得上一套完整辩论但如果是赔付金额、代码上线、合规判断这类高代价决策就值得。第二存在明确的对立利益视角。比如售后场景里的消费者视角和商家视角本身就对立很适合红蓝对抗而这个新闻标题该怎么起这种问题立场模糊收益也模糊。第三事实可以被外部核验。如果连事实都无从查起辩论的事实准确性维度就很容易变成双方互相空转。第四对时延和预算有容忍度。一次完整辩论通常要调用多次模型无法做到几十毫秒响应。5.2 和投票、反思、ReAct 的边界划分我会把这些方案放在同一个坐标里看核心变量是任务有没有外部标准答案。当任务有明确标准答案时自洽性投票性价比最高又快又稳。当任务需要查知识、读多份文档时ReAct 这类带工具调用的方案更合适它能边查边改。但当任务没有标准答案且要在一个模糊空间里做高风险取舍时投票会放大共识偏见ReAct 又缺乏一个专门挑战结论的机制。这个时候红蓝对抗的价值才会体现出来。我把自己的选型逻辑总结成一张表直接抄作业就行任务特征推荐机制理由有标准答案要求速度单 Agent 自洽性投票成本低收敛快需要检索大量资料ReAct / 工具增强事实边界清晰高风险、立场对立、无唯一答案红蓝对抗 裁判强制暴露盲区任意类型但预算极紧单 Agent 自查接受一定错误率5.3 成本模型与两阶段预筛红蓝对抗的成本是可以提前估算的。一次完整决策基本等于红队攻击、蓝队修订、蓝队终稿、裁判裁决这几次调用的总和再乘以回合数。按一个中大型商业模型接口来算单次调用输入 2000 token、输出 1000 token三轮下来一次决策大概要消耗两万到三万个 token。如果决策量大这个成本是真的会咬人的。我后来做了两阶段预筛先用一个相对便宜的模型快速评估任务的风险度如果风险度不高直接走普通推理只有高风险样本才进入完整红蓝对抗。实测下来大约能省下六七成的调用量而且高风险的决策质量没有明显下降。判断要不要深挖这个动作本身是低风险的交给轻量模型足够。6. 我们踩过的坑四种失效模式与修复方式6.1 同源偏见导致的理性漂移最让我惊讶的失效模式是红蓝双方在一轮轮辩论之后居然慢慢统一到同一个错误结论上。我以为只要立场对立结论就会被拉回真实结果发现双方用的是同一个底座模型训练先验一模一样。红队的攻击里带着同样的偏见蓝队的防守也同样带着辩论走几个来回两边就在一个没有事实锚点的空间里达成了新的共识。对此我做了三件事第一在条件允许时用异质模型组合比如让红队用开源小模型、蓝队用主流商用接口哪怕只是模型差异先验也会被拉开。第二给红队注入外部领域知识视角比如让红队站在真实用户的立场上而不是站在通用模型的立场上。第三在裁判评分里加了一条单边置信检查当红蓝双方意见完全一致时自动把方案转交给外部工具做事实核验不允许凭双方都同意就放行。6.2 红队为杠而杠蓝队疲于防守第二种坑是红队开始低质量输出。它每一轮都能找到问题但都是泛泛的这里不够严谨那里有潜在风险。这些质疑本身没什么证据价值却会消耗蓝队的上下文窗口和预算让蓝队花大量篇幅去回应一些空话。修复方式是我在生产环境里加的攻击配额和质疑去重池。每轮红队最多新增三个质疑点且必须说明属于哪个攻击面裁判对质疑质量打分如果一个质疑连续两轮被打为低质量攻击就直接从争议记录里移除。这样红队会被迫只挑真正重要的点打不再靠数量凑业绩。6.3 裁判被论证长度和语气带偏裁判是最容易出问题的环节。模型裁判天然喜欢写得更长、说得更决绝的那一方哪怕那一方的论据细看根本不成立。我们跑过一个专门测试把红队和蓝队的文本互相换成对方的名字再让裁判打分。结果相当难看——只要名字标签换掉分数跟着换说明裁判在审的不是内容是身份。现在的做法是盲评加立场置换双重保险。盲评阶段裁判看到的文本不标发言者只有编号立场置换阶段把双方文本交换后再打分一次。两次结果差异超过一定幅度就触发人工复审。这个机制简单有效成本多不了多少但能把裁判的偏见拦掉一大半。6.4 上下文膨胀与角色漂移这里说的是另一种贵而不干活的情况。当辩论上下文变长红队和蓝队会慢慢忘记自己是来干什么的。红队开始替蓝队出主意蓝队开始主动承认对方说得有道理然后疯狂让步。角色漂移一旦发生对抗的意义就消失了。我现在用三个手段来压住它一是每轮调用都把系统提示词重新注入强调身份和职责二是用结构化争议记录代替全量历史减少上下文对身份的稀释三是把工具输出、检索结果和辩论正文分离开不让外部信息污染角色记忆。6.5 成本失控不设上限的辩论是无底洞最后这个坑是我刚开始最有感触的不设轮数的辩论理论上能一直进行下去。模型会不断发现新的边角蓝队会不断做局部修补看起来双方都很努力实际上只是在原地制造 token。所以无论怎么调参我都会给硬性的最大轮数上限并且上线前用真实样本跑一遍收益-轮数曲线找到收益拐点把上限卡在拐点之后一轮。这四条失效模式我整理成了一张表方便团队排查问题典型现象修复策略同源偏见双方有共识地走向错误异质模型组合、单边置信触发核验为杠而杠攻击点数量多、质量低攻击配额、质疑质量打分、低质质疑移除裁判偏见谁字多谁赢换标签就换分盲评、立场置换复评上下文膨胀角色漂移、成本飙升结构化摘要、系统提示重注入、硬顶轮数7. 进阶让事实进场辩论才不会变成文字游戏7.1 引入外部工具作为事实仲裁者纯文本辩论有一个天花板双方都在用模型记忆里的知识互搏而模型记忆是会错的。要突破这个天花板就得让事实从外部进来。我的做法是在辩论中加入事实主张抽取环节。红队攻击时如果提到某条款应该是什么蓝队回应时如果引用了某数据是多少这些句子都会被抽出来变成待核验的声明。系统把它们送去检索工具或业务数据库检索结果直接进入裁判的上下文成为事实维度的打分依据。这样做之后辩论的性质起了变化它不再是一场比赛谁能把话说得更圆而是一场比赛谁能把证据摆得更准。红队不再是纯粹的嘴炮攻击蓝队也不能靠话术硬撑。这是我把这套机制从能跑推到可信最关键的一步。7.2 从一对一对抗升级到角色池场景多了之后一套通用红队会越来越不够用。售后判责需要用户视角的红队代码评审需要边界条件视角的红队合规判断需要条款视角的红队。我后来的做法是建一个角色池里面有逻辑红队、事实红队、用户视角红队、合规红队等等再根据任务标签激活对应角色。裁判同样可以升级。当前面跑的是高价值决策时我会用三个不同模型的裁判各评一轮三个结果不一致就触发复核而不是让单一裁判一锤定音。这个陪审团方案成本会再高一截但真正落到高赔付、高风险的决策上这笔钱是值得的。7.3 决策留痕是把辩论机制当资产经营的关键所有辩论过程我都要求留痕谁提了什么质疑、蓝队改了什么、裁判给了几分、最终决策是什么。这些记录不只是审计用的更是我们持续优化机制的数据来源。我们在调试阶段做过一件事把历史辩论样本里的好裁判裁决整理成标注集用来评估新版本提示词的质量也把蓝队修复后得分提升明显的样本收集起来作为调优蓝队策略的正例。辩论机制运行得越久这笔留痕资产就越值钱甚至能反哺整个人工评估体系。最后说一个我始终保留的习惯每次做这类决策链路改造我都会先挑 30 条有代表性的老样本跑一套小规模的两轮版本亲手看一遍红队输出的攻击质量、蓝队有没有真改、裁判能不能给出可执行结果再决定要不要上完整版。红蓝对抗这套东西思路不难理解难的是每个角色都容易在自己的岗位上偷懒你得靠协议设计和评测数据把它们的懒惰一个一个堵回去。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
