1. 从“让模型互怼”这个念头说起第一次冒出“让几个大模型坐在一起吵架”这个想法是在一次内部技术闲聊上。当时我们几个人正在对比几个主流开源模型在同一个问题上的表现有人随口说了一句“要是能让它们互相点评对方的答案是不是就能看出谁更靠谱”这句话一下子戳中了我。平时我们评测模型要么是跑分要么是人工看输出费时费力还容易带主观偏见。如果让模型自己当裁判、当辩手互相挑刺是不是能挖出一些单跑测试时看不到的东西这个项目的核心就是搭一个多模型辩论框架让 DeepSeek、Qwen、GLM 这三个模型围绕同一个议题分正反方进行多轮辩论最后由一个裁判模型来判定胜负。整个流程跑在一套云端 GPU 算力平台上我选的是蓝耘原因后面会细说。它解决的问题很直接给模型评测提供一个动态、对抗性的观察窗口而不是静态地看单次问答。适合谁参考如果你正在做模型选型、想观察不同模型在逻辑推理和语言组织上的差异或者单纯想玩一玩多智能体协作这套东西都能直接拿去改。我先把整体思路捋一遍。辩论赛不是简单地把三个模型 API 串起来轮流调用就完事它涉及角色分配、上下文管理、轮次控制、裁判逻辑、结果落盘这几个关键环节。每一个环节都有坑比如上下文长度爆炸、模型“复读”对方观点、裁判偏袒某一方等等。下面我会按实际搭建的顺序把设计思路、核心细节、实操过程和踩坑记录完整展开。2. 整体架构设计与选型考量2.1 为什么是“辩论”而不是“投票”最常见的多模型对比方式是让几个模型回答同一个问题然后人工或自动打分。这种方式的问题在于模型之间没有交互各自答各自的你很难看出它们在面对反驳时的表现。而辩论天然带有对抗性正方提出论点反方必须找到漏洞进行攻击正方再防守或反击。这个过程能暴露模型在逻辑一致性、论据组织、临场应变上的真实水平。我试过让三个模型分别回答“远程办公是否利大于弊”然后对比答案。结果发现大家的论点高度重合都是那几条常见理由区分度很低。但改成辩论后反方会针对正方举的具体案例进行拆解正方又得想办法圆回来输出的信息密度和多样性明显上了一个台阶。所以这个项目的第一个设计决策就是用对抗代替并行。2.2 模型角色分配与选型逻辑三个模型分别承担什么角色我斟酌了很久。最直接的方案是三个模型轮流当正方、反方和裁判跑三轮这样最公平。但实际跑下来发现裁判模型如果同时当过辩手它在评判时可能会对自己之前的论点有隐性偏好。所以最终方案是固定裁判辩手轮换。具体分配是这样的角色模型理由裁判GLM在长上下文理解和指令遵循上表现稳定适合做规则执行者辩手ADeepSeek推理链条清晰擅长拆解对方逻辑漏洞辩手BQwen语言组织能力强论点展开充分适合做立论方这个分配不是绝对的你可以根据自己手头的模型资源调整。核心原则是裁判模型要选指令遵循最稳的那个因为裁判需要严格按照格式输出判定结果一旦格式跑偏整个流程就断了。辩手模型则选风格差异大的这样辩论才有看头。2.3 云端算力平台的选择理由本地跑三个模型不现实显存根本不够。我选蓝耘的原因很简单按需付费、镜像环境齐全、网络延迟低。它的 GPU 实例支持自定义镜像我直接把 PyTorch 和 transformers 环境打包好上传开机就能跑。另外它的内网带宽足够三个模型如果都部署在同一内网的不同实例上API 调用延迟可以控制在几十毫秒级别辩论轮次之间的等待时间几乎可以忽略。如果你只是做实验也可以把模型量化后跑在单张卡上但那样三个模型互相抢显存推理速度会大打折扣。我的建议是至少两张卡一张跑裁判一张跑两个辩手分时复用或者三张卡各跑一个。蓝耘的按小时计费模式很适合这种短时高负载的场景跑完就释放成本可控。2.4 上下文管理策略辩论最大的技术难点是上下文膨胀。每一轮辩手发言都要把之前的全部对话历史塞进 prompt轮次一多token 数直接爆炸。我一开始没注意跑到第五轮的时候直接超了模型的最大上下文长度报错退出。解决方案是滑动窗口 摘要压缩。具体做法保留最近三轮的完整对话更早的轮次用裁判模型生成一段摘要把摘要和最近三轮一起塞进 prompt。这样既保留了辩论的连贯性又控制了 token 增长。实测下来八轮辩论的上下文长度可以稳定控制在 8K token 以内对三个模型来说都很轻松。3. 核心细节解析与实操要点3.1 辩论流程的状态机设计整个辩论流程我用一个简单的状态机来管理状态流转如下立论阶段正方先发言提出核心论点限时一轮。反驳阶段反方针对正方论点进行反驳限时一轮。自由辩论正反方交替发言共四轮每轮限时。总结陈词正反方各做一次总结限时一轮。裁判判定裁判模型根据全程记录输出胜负判定和理由。每个状态对应一个 prompt 模板模板里明确告诉模型当前处于哪个阶段、需要做什么、输出格式是什么。这里有个关键点prompt 里必须包含“禁止重复对方原话”的指令否则模型很容易偷懒直接把对方的话复述一遍就算反驳了。我加了这个指令后输出的原创性明显提升。3.2 Prompt 模板的设计技巧辩手 prompt 的核心结构是这样的你正在参加一场辩论赛你的立场是【正方/反方】。 当前辩题【辩题内容】 你的角色【立论/反驳/自由辩论/总结】 对话历史【滑动窗口内的历史记录】 你的任务【根据当前阶段的具体要求】 输出要求 1. 观点明确论据充分 2. 禁止重复对方原话必须用自己的语言重新组织 3. 每次发言不超过 300 字 4. 输出格式【观点】...【论据】...【结论】...裁判 prompt 则更强调格式约束你是一场辩论赛的裁判。以下是正反双方的完整辩论记录。 请你根据以下标准判定胜负 1. 论点清晰度30% 2. 论据充分性30% 3. 反驳有效性40% 输出格式必须为 【胜方】正方/反方 【理由】... 【最佳辩手】正方/反方注意裁判 prompt 里一定要加“必须严格按照格式输出”这句话否则模型可能会自由发挥导致后续解析失败。3.3 模型调用的参数配置三个模型的 API 调用参数需要分别调优。DeepSeek 的 temperature 我设成 0.7让它保持一定的创造性Qwen 设成 0.6偏稳重GLM 作为裁判temperature 设成 0.3确保判定结果稳定可复现。max_tokens 统一设成 512因为辩论发言不需要太长太长反而容易跑题。还有一个细节每个模型都要设置 stop 词。比如辩手输出到“【结论】”之后就应该停止裁判输出到“【最佳辩手】”之后停止。这样能避免模型画蛇添足输出一些无关内容。3.4 结果落盘与可视化每轮辩论的原始输出、时间戳、token 消耗量我都会落盘成 JSON 文件方便后续分析。可视化方面我用了一个简单的 HTML 页面把正反方的发言按轮次左右分栏展示裁判判定放在最下方。这样一眼就能看出辩论的走势。如果你不想自己写可视化也可以直接把 JSON 丢给任意一个模型让它生成一份辩论总结报告。我试过让 GLM 根据 JSON 生成一份“赛事回顾”效果还不错省了不少事。4. 实操过程与核心环节实现4.1 环境准备与模型部署第一步是在蓝耘上开实例。我选的是两张 A100 40G 的配置一张跑 DeepSeek 和 Qwen 的量化版本一张跑 GLM。镜像用的是 PyTorch 2.1 CUDA 11.8 的基础镜像然后手动装了 transformers、accelerate、fastapi 和 uvicorn。模型加载我用的是 transformers 的 pipeline三个模型分别加载到不同的端口from transformers import pipeline # 加载 DeepSeek deepseek_pipe pipeline( text-generation, modeldeepseek-ai/deepseek-llm-7b-chat, device0, torch_dtypeauto ) # 加载 Qwen qwen_pipe pipeline( text-generation, modelQwen/Qwen-7B-Chat, device0, torch_dtypeauto ) # 加载 GLM glm_pipe pipeline( text-generation, modelTHUDM/chatglm3-6b, device1, torch_dtypeauto )然后用 FastAPI 把每个 pipeline 包成一个 HTTP 接口方便辩论主程序调用。这里有个坑transformers 的 pipeline 默认是单线程的如果辩论主程序并发调用会排队等待。解决办法是在 FastAPI 里用asyncio.to_thread把推理调用放到线程池里或者直接用 vLLM 做推理后端吞吐量能提升好几倍。4.2 辩论主程序的编写主程序的核心是一个循环按照状态机依次调用不同的模型。我把它写成了一个 Python 类关键方法如下class DebateArena: def __init__(self, topic, rounds4): self.topic topic self.rounds rounds self.history [] self.summary def call_model(self, model_name, prompt): # 调用对应的模型接口 response requests.post( fhttp://localhost:{PORT_MAP[model_name]}/generate, json{prompt: prompt, max_tokens: 512} ) return response.json()[text] def build_prompt(self, role, stage): # 根据角色和阶段构建 prompt recent self.history[-6:] # 最近三轮 prompt PROMPT_TEMPLATE.format( rolerole, stagestage, topicself.topic, historyrecent, summaryself.summary ) return prompt def run(self): # 立论 pro_opening self.call_model(deepseek, self.build_prompt(正方, 立论)) self.history.append((正方, pro_opening)) con_opening self.call_model(qwen, self.build_prompt(反方, 立论)) self.history.append((反方, con_opening)) # 自由辩论 for i in range(self.rounds): pro_arg self.call_model(deepseek, self.build_prompt(正方, 自由辩论)) self.history.append((正方, pro_arg)) con_arg self.call_model(qwen, self.build_prompt(反方, 自由辩论)) self.history.append((反方, con_arg)) # 每两轮更新一次摘要 if i % 2 1: self.summary self.call_model(glm, self.build_summary_prompt()) # 总结陈词 pro_summary self.call_model(deepseek, self.build_prompt(正方, 总结)) self.history.append((正方, pro_summary)) con_summary self.call_model(qwen, self.build_prompt(反方, 总结)) self.history.append((反方, con_summary)) # 裁判判定 verdict self.call_model(glm, self.build_judge_prompt()) return verdict这个结构跑下来一场八轮辩论大概需要 3 到 5 分钟取决于模型推理速度。如果用了 vLLM可以压缩到 1 分钟以内。4.3 摘要压缩的具体实现摘要压缩是控制上下文长度的关键。我的做法是每两轮自由辩论结束后把之前的完整历史丢给 GLM让它生成一段 200 字以内的摘要重点保留双方的核心论点和关键论据。摘要 prompt 是这样的请将以下辩论记录压缩成 200 字以内的摘要保留双方的核心论点和关键论据忽略重复内容和寒暄语句。 辩论记录【历史记录】 摘要实测下来八轮辩论的原始历史大约 6000 字压缩后摘要只有 200 字左右加上最近三轮的完整记录总上下文控制在 3000 字以内token 消耗降低了 60% 以上。4.4 裁判判定的可靠性保障裁判判定是整个流程的最后一环也是最容易出问题的一环。我遇到过几种情况裁判输出格式不对、裁判判定理由过于笼统、裁判明显偏袒某一方。针对这些问题我做了三件事第一在裁判 prompt 里加入评分细则让裁判按维度打分而不是凭感觉给结论。第二要求裁判引用具体发言作为依据比如“正方在第三轮提出的XX论据有效反驳了反方的XX观点”。第三跑两次裁判判定如果两次结果不一致就取第三次三次两胜。这样虽然增加了调用次数但判定可靠性明显提升。5. 常见问题与排查技巧实录5.1 模型“复读”对方观点怎么办这是最常见的问题。模型在反驳阶段经常直接把对方的话复述一遍然后加一句“这是不对的”就算反驳了。解决办法是在 prompt 里明确禁止复述并且要求“必须提出新的论据或指出对方论据中的逻辑漏洞”。如果模型还是复读可以在后处理阶段检测输出与对方发言的相似度超过阈值就重新生成。5.2 上下文超长导致报错前面提到过用滑动窗口加摘要压缩可以解决。但还有一个隐藏问题摘要本身也会累积。如果你每轮都更新摘要摘要会越来越长。我的做法是摘要只保留最近一次生成的版本不叠加。另外如果模型支持 8K 上下文实际使用控制在 6K 以内比较安全留出余量给输出。5.3 裁判判定格式解析失败裁判模型有时候会输出“我认为正方获胜”而不是“【胜方】正方”。这种情况下正则解析会失败。我的处理方式是先用正则匹配如果匹配不到就用一个简单的规则兜底比如检测输出中是否包含“正方”或“反方”关键词取出现次数多的那个作为胜方。同时记录下解析失败的案例后续优化 prompt。5.4 模型调用超时或失败云端实例的网络偶尔会抖动导致 API 调用超时。我在调用层加了重试机制最多重试三次每次间隔 2 秒。如果三次都失败就跳过当前轮次用“【发言超时】”占位继续后续流程。这样不会因为单次失败导致整场辩论中断。5.5 常见问题速查表问题现象可能原因解决方法模型复读对方观点prompt 约束不足加入禁止复述指令后处理检测相似度上下文超长报错历史记录未压缩滑动窗口 摘要压缩裁判格式解析失败输出格式不稳定正则匹配 关键词兜底API 调用超时网络抖动或实例负载高重试机制 跳过占位辩论跑题prompt 未强调辩题每轮 prompt 都重复辩题模型输出过短max_tokens 设置过小调整到 512 以上实操心得辩论赛的 prompt 里一定要反复强调辩题因为模型在长对话中很容易忘记最初的话题。我试过在第五轮的时候正方已经开始讨论完全无关的议题了后来在每轮 prompt 开头都加上“当前辩题是XXX”跑题问题就基本消失了。6. 辩论结果的观察与分析6.1 三个模型的风格差异跑了几十场辩论后我总结出三个模型的一些风格特征。DeepSeek 在逻辑拆解上确实强它很擅长找到对方论据中的前提假设然后攻击这个假设。比如反方说“远程办公降低沟通效率”DeepSeek 会反问“沟通效率的定义是什么是频率还是质量”这种拆解很犀利。Qwen 则更擅长组织长链条的论证它的发言结构通常很完整从背景到论点再到论据层层递进。但在面对犀利反驳时它的应变速度不如 DeepSeek有时候会绕开对方的攻击点继续讲自己的论点。GLM 作为裁判整体表现比较中立但偶尔会给出一些模棱两可的判定比如“双方各有千秋”。后来我在 prompt 里加了“必须明确判定胜负不允许平局”这个问题就解决了。6.2 辩论赛对模型评测的价值这种对抗式评测最大的价值在于暴露模型的思维盲区。单跑测试时模型回答得头头是道但一旦有人反驳它可能就露馅了。我见过 DeepSeek 在立论时提出一个论据被 Qwen 反驳后它在后续轮次里完全忘记了自己之前的论据转而支持了一个与之前矛盾的立场。这种前后不一致的问题在静态评测里很难发现。另外辩论赛还能观察模型的“抗压能力”。有些模型在被连续反驳后输出质量会明显下降开始说车轱辘话。而有些模型则越战越勇反驳越来越精准。这些表现对模型选型很有参考价值。6.3 后续可以扩展的方向这套框架目前只支持三个模型如果你想加更多模型只需要在状态机里增加角色和对应的 prompt 模板即可。另外辩题可以从预设列表里随机抽取也可以让模型自己生成辩题这样每场辩论都是全新的。还有一个有意思的扩展方向让观众模型参与投票。在辩论结束后再调用几个模型作为“观众”让它们根据辩论记录投票选出胜方然后对比裁判判定和观众投票的一致性。如果差异很大说明裁判的判定标准可能有问题值得进一步分析。我个人在实际操作中的体会是这套东西最大的乐趣不在于谁赢谁输而在于看模型们如何“吵架”。有时候它们会提出一些人类辩手想不到的角度虽然不一定严谨但确实能给人启发。如果你也想搭一套建议先从最简单的两模型单轮辩论开始跑通了再逐步加轮次、加模型、加裁判。别一上来就搞全自动中间环节的调试量比你想象的大。 多模型辩论框架实战：DeepSeek、Qwen、GLM对抗式评测与云端部署
1. 从“让模型互怼”这个念头说起第一次冒出“让几个大模型坐在一起吵架”这个想法是在一次内部技术闲聊上。当时我们几个人正在对比几个主流开源模型在同一个问题上的表现有人随口说了一句“要是能让它们互相点评对方的答案是不是就能看出谁更靠谱”这句话一下子戳中了我。平时我们评测模型要么是跑分要么是人工看输出费时费力还容易带主观偏见。如果让模型自己当裁判、当辩手互相挑刺是不是能挖出一些单跑测试时看不到的东西这个项目的核心就是搭一个多模型辩论框架让 DeepSeek、Qwen、GLM 这三个模型围绕同一个议题分正反方进行多轮辩论最后由一个裁判模型来判定胜负。整个流程跑在一套云端 GPU 算力平台上我选的是蓝耘原因后面会细说。它解决的问题很直接给模型评测提供一个动态、对抗性的观察窗口而不是静态地看单次问答。适合谁参考如果你正在做模型选型、想观察不同模型在逻辑推理和语言组织上的差异或者单纯想玩一玩多智能体协作这套东西都能直接拿去改。我先把整体思路捋一遍。辩论赛不是简单地把三个模型 API 串起来轮流调用就完事它涉及角色分配、上下文管理、轮次控制、裁判逻辑、结果落盘这几个关键环节。每一个环节都有坑比如上下文长度爆炸、模型“复读”对方观点、裁判偏袒某一方等等。下面我会按实际搭建的顺序把设计思路、核心细节、实操过程和踩坑记录完整展开。2. 整体架构设计与选型考量2.1 为什么是“辩论”而不是“投票”最常见的多模型对比方式是让几个模型回答同一个问题然后人工或自动打分。这种方式的问题在于模型之间没有交互各自答各自的你很难看出它们在面对反驳时的表现。而辩论天然带有对抗性正方提出论点反方必须找到漏洞进行攻击正方再防守或反击。这个过程能暴露模型在逻辑一致性、论据组织、临场应变上的真实水平。我试过让三个模型分别回答“远程办公是否利大于弊”然后对比答案。结果发现大家的论点高度重合都是那几条常见理由区分度很低。但改成辩论后反方会针对正方举的具体案例进行拆解正方又得想办法圆回来输出的信息密度和多样性明显上了一个台阶。所以这个项目的第一个设计决策就是用对抗代替并行。2.2 模型角色分配与选型逻辑三个模型分别承担什么角色我斟酌了很久。最直接的方案是三个模型轮流当正方、反方和裁判跑三轮这样最公平。但实际跑下来发现裁判模型如果同时当过辩手它在评判时可能会对自己之前的论点有隐性偏好。所以最终方案是固定裁判辩手轮换。具体分配是这样的角色模型理由裁判GLM在长上下文理解和指令遵循上表现稳定适合做规则执行者辩手ADeepSeek推理链条清晰擅长拆解对方逻辑漏洞辩手BQwen语言组织能力强论点展开充分适合做立论方这个分配不是绝对的你可以根据自己手头的模型资源调整。核心原则是裁判模型要选指令遵循最稳的那个因为裁判需要严格按照格式输出判定结果一旦格式跑偏整个流程就断了。辩手模型则选风格差异大的这样辩论才有看头。2.3 云端算力平台的选择理由本地跑三个模型不现实显存根本不够。我选蓝耘的原因很简单按需付费、镜像环境齐全、网络延迟低。它的 GPU 实例支持自定义镜像我直接把 PyTorch 和 transformers 环境打包好上传开机就能跑。另外它的内网带宽足够三个模型如果都部署在同一内网的不同实例上API 调用延迟可以控制在几十毫秒级别辩论轮次之间的等待时间几乎可以忽略。如果你只是做实验也可以把模型量化后跑在单张卡上但那样三个模型互相抢显存推理速度会大打折扣。我的建议是至少两张卡一张跑裁判一张跑两个辩手分时复用或者三张卡各跑一个。蓝耘的按小时计费模式很适合这种短时高负载的场景跑完就释放成本可控。2.4 上下文管理策略辩论最大的技术难点是上下文膨胀。每一轮辩手发言都要把之前的全部对话历史塞进 prompt轮次一多token 数直接爆炸。我一开始没注意跑到第五轮的时候直接超了模型的最大上下文长度报错退出。解决方案是滑动窗口 摘要压缩。具体做法保留最近三轮的完整对话更早的轮次用裁判模型生成一段摘要把摘要和最近三轮一起塞进 prompt。这样既保留了辩论的连贯性又控制了 token 增长。实测下来八轮辩论的上下文长度可以稳定控制在 8K token 以内对三个模型来说都很轻松。3. 核心细节解析与实操要点3.1 辩论流程的状态机设计整个辩论流程我用一个简单的状态机来管理状态流转如下立论阶段正方先发言提出核心论点限时一轮。反驳阶段反方针对正方论点进行反驳限时一轮。自由辩论正反方交替发言共四轮每轮限时。总结陈词正反方各做一次总结限时一轮。裁判判定裁判模型根据全程记录输出胜负判定和理由。每个状态对应一个 prompt 模板模板里明确告诉模型当前处于哪个阶段、需要做什么、输出格式是什么。这里有个关键点prompt 里必须包含“禁止重复对方原话”的指令否则模型很容易偷懒直接把对方的话复述一遍就算反驳了。我加了这个指令后输出的原创性明显提升。3.2 Prompt 模板的设计技巧辩手 prompt 的核心结构是这样的你正在参加一场辩论赛你的立场是【正方/反方】。 当前辩题【辩题内容】 你的角色【立论/反驳/自由辩论/总结】 对话历史【滑动窗口内的历史记录】 你的任务【根据当前阶段的具体要求】 输出要求 1. 观点明确论据充分 2. 禁止重复对方原话必须用自己的语言重新组织 3. 每次发言不超过 300 字 4. 输出格式【观点】...【论据】...【结论】...裁判 prompt 则更强调格式约束你是一场辩论赛的裁判。以下是正反双方的完整辩论记录。 请你根据以下标准判定胜负 1. 论点清晰度30% 2. 论据充分性30% 3. 反驳有效性40% 输出格式必须为 【胜方】正方/反方 【理由】... 【最佳辩手】正方/反方注意裁判 prompt 里一定要加“必须严格按照格式输出”这句话否则模型可能会自由发挥导致后续解析失败。3.3 模型调用的参数配置三个模型的 API 调用参数需要分别调优。DeepSeek 的 temperature 我设成 0.7让它保持一定的创造性Qwen 设成 0.6偏稳重GLM 作为裁判temperature 设成 0.3确保判定结果稳定可复现。max_tokens 统一设成 512因为辩论发言不需要太长太长反而容易跑题。还有一个细节每个模型都要设置 stop 词。比如辩手输出到“【结论】”之后就应该停止裁判输出到“【最佳辩手】”之后停止。这样能避免模型画蛇添足输出一些无关内容。3.4 结果落盘与可视化每轮辩论的原始输出、时间戳、token 消耗量我都会落盘成 JSON 文件方便后续分析。可视化方面我用了一个简单的 HTML 页面把正反方的发言按轮次左右分栏展示裁判判定放在最下方。这样一眼就能看出辩论的走势。如果你不想自己写可视化也可以直接把 JSON 丢给任意一个模型让它生成一份辩论总结报告。我试过让 GLM 根据 JSON 生成一份“赛事回顾”效果还不错省了不少事。4. 实操过程与核心环节实现4.1 环境准备与模型部署第一步是在蓝耘上开实例。我选的是两张 A100 40G 的配置一张跑 DeepSeek 和 Qwen 的量化版本一张跑 GLM。镜像用的是 PyTorch 2.1 CUDA 11.8 的基础镜像然后手动装了 transformers、accelerate、fastapi 和 uvicorn。模型加载我用的是 transformers 的 pipeline三个模型分别加载到不同的端口from transformers import pipeline # 加载 DeepSeek deepseek_pipe pipeline( text-generation, modeldeepseek-ai/deepseek-llm-7b-chat, device0, torch_dtypeauto ) # 加载 Qwen qwen_pipe pipeline( text-generation, modelQwen/Qwen-7B-Chat, device0, torch_dtypeauto ) # 加载 GLM glm_pipe pipeline( text-generation, modelTHUDM/chatglm3-6b, device1, torch_dtypeauto )然后用 FastAPI 把每个 pipeline 包成一个 HTTP 接口方便辩论主程序调用。这里有个坑transformers 的 pipeline 默认是单线程的如果辩论主程序并发调用会排队等待。解决办法是在 FastAPI 里用asyncio.to_thread把推理调用放到线程池里或者直接用 vLLM 做推理后端吞吐量能提升好几倍。4.2 辩论主程序的编写主程序的核心是一个循环按照状态机依次调用不同的模型。我把它写成了一个 Python 类关键方法如下class DebateArena: def __init__(self, topic, rounds4): self.topic topic self.rounds rounds self.history [] self.summary def call_model(self, model_name, prompt): # 调用对应的模型接口 response requests.post( fhttp://localhost:{PORT_MAP[model_name]}/generate, json{prompt: prompt, max_tokens: 512} ) return response.json()[text] def build_prompt(self, role, stage): # 根据角色和阶段构建 prompt recent self.history[-6:] # 最近三轮 prompt PROMPT_TEMPLATE.format( rolerole, stagestage, topicself.topic, historyrecent, summaryself.summary ) return prompt def run(self): # 立论 pro_opening self.call_model(deepseek, self.build_prompt(正方, 立论)) self.history.append((正方, pro_opening)) con_opening self.call_model(qwen, self.build_prompt(反方, 立论)) self.history.append((反方, con_opening)) # 自由辩论 for i in range(self.rounds): pro_arg self.call_model(deepseek, self.build_prompt(正方, 自由辩论)) self.history.append((正方, pro_arg)) con_arg self.call_model(qwen, self.build_prompt(反方, 自由辩论)) self.history.append((反方, con_arg)) # 每两轮更新一次摘要 if i % 2 1: self.summary self.call_model(glm, self.build_summary_prompt()) # 总结陈词 pro_summary self.call_model(deepseek, self.build_prompt(正方, 总结)) self.history.append((正方, pro_summary)) con_summary self.call_model(qwen, self.build_prompt(反方, 总结)) self.history.append((反方, con_summary)) # 裁判判定 verdict self.call_model(glm, self.build_judge_prompt()) return verdict这个结构跑下来一场八轮辩论大概需要 3 到 5 分钟取决于模型推理速度。如果用了 vLLM可以压缩到 1 分钟以内。4.3 摘要压缩的具体实现摘要压缩是控制上下文长度的关键。我的做法是每两轮自由辩论结束后把之前的完整历史丢给 GLM让它生成一段 200 字以内的摘要重点保留双方的核心论点和关键论据。摘要 prompt 是这样的请将以下辩论记录压缩成 200 字以内的摘要保留双方的核心论点和关键论据忽略重复内容和寒暄语句。 辩论记录【历史记录】 摘要实测下来八轮辩论的原始历史大约 6000 字压缩后摘要只有 200 字左右加上最近三轮的完整记录总上下文控制在 3000 字以内token 消耗降低了 60% 以上。4.4 裁判判定的可靠性保障裁判判定是整个流程的最后一环也是最容易出问题的一环。我遇到过几种情况裁判输出格式不对、裁判判定理由过于笼统、裁判明显偏袒某一方。针对这些问题我做了三件事第一在裁判 prompt 里加入评分细则让裁判按维度打分而不是凭感觉给结论。第二要求裁判引用具体发言作为依据比如“正方在第三轮提出的XX论据有效反驳了反方的XX观点”。第三跑两次裁判判定如果两次结果不一致就取第三次三次两胜。这样虽然增加了调用次数但判定可靠性明显提升。5. 常见问题与排查技巧实录5.1 模型“复读”对方观点怎么办这是最常见的问题。模型在反驳阶段经常直接把对方的话复述一遍然后加一句“这是不对的”就算反驳了。解决办法是在 prompt 里明确禁止复述并且要求“必须提出新的论据或指出对方论据中的逻辑漏洞”。如果模型还是复读可以在后处理阶段检测输出与对方发言的相似度超过阈值就重新生成。5.2 上下文超长导致报错前面提到过用滑动窗口加摘要压缩可以解决。但还有一个隐藏问题摘要本身也会累积。如果你每轮都更新摘要摘要会越来越长。我的做法是摘要只保留最近一次生成的版本不叠加。另外如果模型支持 8K 上下文实际使用控制在 6K 以内比较安全留出余量给输出。5.3 裁判判定格式解析失败裁判模型有时候会输出“我认为正方获胜”而不是“【胜方】正方”。这种情况下正则解析会失败。我的处理方式是先用正则匹配如果匹配不到就用一个简单的规则兜底比如检测输出中是否包含“正方”或“反方”关键词取出现次数多的那个作为胜方。同时记录下解析失败的案例后续优化 prompt。5.4 模型调用超时或失败云端实例的网络偶尔会抖动导致 API 调用超时。我在调用层加了重试机制最多重试三次每次间隔 2 秒。如果三次都失败就跳过当前轮次用“【发言超时】”占位继续后续流程。这样不会因为单次失败导致整场辩论中断。5.5 常见问题速查表问题现象可能原因解决方法模型复读对方观点prompt 约束不足加入禁止复述指令后处理检测相似度上下文超长报错历史记录未压缩滑动窗口 摘要压缩裁判格式解析失败输出格式不稳定正则匹配 关键词兜底API 调用超时网络抖动或实例负载高重试机制 跳过占位辩论跑题prompt 未强调辩题每轮 prompt 都重复辩题模型输出过短max_tokens 设置过小调整到 512 以上实操心得辩论赛的 prompt 里一定要反复强调辩题因为模型在长对话中很容易忘记最初的话题。我试过在第五轮的时候正方已经开始讨论完全无关的议题了后来在每轮 prompt 开头都加上“当前辩题是XXX”跑题问题就基本消失了。6. 辩论结果的观察与分析6.1 三个模型的风格差异跑了几十场辩论后我总结出三个模型的一些风格特征。DeepSeek 在逻辑拆解上确实强它很擅长找到对方论据中的前提假设然后攻击这个假设。比如反方说“远程办公降低沟通效率”DeepSeek 会反问“沟通效率的定义是什么是频率还是质量”这种拆解很犀利。Qwen 则更擅长组织长链条的论证它的发言结构通常很完整从背景到论点再到论据层层递进。但在面对犀利反驳时它的应变速度不如 DeepSeek有时候会绕开对方的攻击点继续讲自己的论点。GLM 作为裁判整体表现比较中立但偶尔会给出一些模棱两可的判定比如“双方各有千秋”。后来我在 prompt 里加了“必须明确判定胜负不允许平局”这个问题就解决了。6.2 辩论赛对模型评测的价值这种对抗式评测最大的价值在于暴露模型的思维盲区。单跑测试时模型回答得头头是道但一旦有人反驳它可能就露馅了。我见过 DeepSeek 在立论时提出一个论据被 Qwen 反驳后它在后续轮次里完全忘记了自己之前的论据转而支持了一个与之前矛盾的立场。这种前后不一致的问题在静态评测里很难发现。另外辩论赛还能观察模型的“抗压能力”。有些模型在被连续反驳后输出质量会明显下降开始说车轱辘话。而有些模型则越战越勇反驳越来越精准。这些表现对模型选型很有参考价值。6.3 后续可以扩展的方向这套框架目前只支持三个模型如果你想加更多模型只需要在状态机里增加角色和对应的 prompt 模板即可。另外辩题可以从预设列表里随机抽取也可以让模型自己生成辩题这样每场辩论都是全新的。还有一个有意思的扩展方向让观众模型参与投票。在辩论结束后再调用几个模型作为“观众”让它们根据辩论记录投票选出胜方然后对比裁判判定和观众投票的一致性。如果差异很大说明裁判的判定标准可能有问题值得进一步分析。我个人在实际操作中的体会是这套东西最大的乐趣不在于谁赢谁输而在于看模型们如何“吵架”。有时候它们会提出一些人类辩手想不到的角度虽然不一定严谨但确实能给人启发。如果你也想搭一套建议先从最简单的两模型单轮辩论开始跑通了再逐步加轮次、加模型、加裁判。别一上来就搞全自动中间环节的调试量比你想象的大。