在多智能体协作推理中，让多个大语言模型分别扮演正方、反方和裁判来辩论，确实能提高复杂问题的回答准确率。然而实际部署时经常出现一种现象：辩论进行到第三轮之后，发言内容开始偏离原始问题，模型开始争论无关的细节、重复之前已经确认的结论，甚至围绕某个措辞互相攻击。跑题不仅浪费大量推理令牌，还会把最终答案引向错误方向。解决这个问题不能只靠给模型更强的人员提示词，需要引入结构化的主持人模型和议程控制机制。
一、跑题现象为什么难以靠模型自身避免
自回归语言模型每轮只根据当前上下文生成下一段发言，没有全局目标函数来约束内容走向。在长上下文中，较早的原始问题会被大量中间发言稀释，模型更容易受最近发言影响。如果某个反方突然提出一个看似相关实则偏颇的类比，其他智能体可能跟随这个类比继续展开，而不会主动回到原始问题。下面这段记录展示了一个典型的跑题过程。
# 模拟多智能体辩论的发言记录
debate_history = [
{"role": "正方", "content": "该方案能降低30%的内存占用，因为采用惰性加载。"},
{"role": "反方", "content": "惰性加载在低端设备上可能造成首屏延迟。"},
{"role": "正方", "content": "低端设备的定义本身就很模糊，不同年代设备差异巨大。"},
{"role": "反方", "content": "设备差异确实存在，比如十年前的中端机和现在入门机。"},
{"role": "正方", "content": "十年前的中端机运行现代框架本来就困难，讨论意义不大。"}
]
# 第三轮之后焦点从内存占用变成了设备定义，原始问题被丢弃
这种偏移会自我强化。因为上下文窗口有限，当无关内容占据过多空间时，真正有效的问题定义、约束条件和已核实证据可能被截断。模型无法主动清理上下文，只能继续在污染后的上下文中生成回复。即使后面重新加入原始问题提示，模型也容易把讨论范围扩展到与原始问题只有微弱关联的领域。
另一个原因是辩论智能体通常被赋予角色提示词，例如“你是坚定反方，必须反驳对方”，这种对抗性目标会让模型为反驳而反驳，而不是为逼近真相而发言。即使观点已经被反驳到无法继续，反方也可能抓住措辞问题继续纠缠。此时唯一有效的办法不是继续加入更多提示词，而是在系统结构上设置质量闸门。
二、主持人模型：让每一轮发言接受相关性裁决
主持人模型是一个独立的大模型调用，不直接参与观点输出，而是在每轮发言后对内容做裁决。输入包括原始问题、辩论议程当前阶段、已有发言记录和候选新发言；输出包括相关性评分、冲突标记、是否采纳该发言、是否终止辩论。如果不采纳，主持人的裁决理由会写入日志，但该发言本身不会进入主上下文，从源头阻止跑题内容扩散。
class Moderator:
def __init__(self, llm_client, relevance_threshold=0.7):
self.llm = llm_client
self.threshold = relevance_threshold
def evaluate(self, question, stage, history, candidate):
prompt = f"""原始问题：{question}
当前议程阶段：{stage}
已有发言摘要：{history[-3:]}
候选发言：{candidate}
请判断候选发言是否与原始问题及当前阶段相关，并返回JSON：
{{"relevance": 0.0到1.0, "conflict": "none或redundant或contradiction", "accept": true或false, "reason": "简要理由"}}
"""
result = self.llm.call(prompt)
data = parse_json(result)
if data["relevance"] < self.threshold or data["conflict"] == "redundant":
data["accept"] = False
return data
主持人模型的评分维度不能只做关键词匹配。比如两个发言都包含“缓存”这个词，但一个在讨论缓存失效策略，另一个在讨论缓存穿透攻击。如果问题只要求比较两种缓存库的内存占用，后一个就属于跑题。主持人需要理解语义相关性，并且把历史发言中已经确认的结论作为判断冗余的基础。因此主持人本身也需要足够强的模型能力，通常使用与辩论智能体同量级或更高级别的模型。
主持人的裁决动作可以分三档：接受、忽略、降级。接受的发言进入主上下文；忽略的发言完全不进入，只记录原因；降级的发言会被压缩成一句话摘要放入旁路日志，供后续需要时检索，而不占用主窗口。这样即使偶尔误杀了有价值但表达啰嗦的发言，也不会完全丢失信息。
三、议程控制：把讨论装进有限状态机
主持人模型负责单轮质量，议程控制负责全局节奏。一个完整的辩论推理过程可以拆分为五个阶段：问题定义、论点提出、反驳质询、证据核查、综合收敛。每个阶段都有明确的发言类型要求。例如问题定义阶段只允许澄清问题边界、术语定义和约束条件；论点提出阶段只允许给出核心主张和支撑理由；反驳质询阶段只允许指出对方论证中的逻辑漏洞或事实错误；证据核查阶段只允许引用可验证的数据、代码运行结果或文档；综合收敛阶段只允许总结已经达成的共识和未解决的差异。
AGENDA_STAGES = ["problem_definition", "argument", "rebuttal", "evidence", "synthesis"]
class AgendaController:
def __init__(self):
self.stage_index = 0
self.round_count = 0
self.consensus_score = 0.0
def next_stage(self):
if self.stage_index < len(AGENDA_STAGES) - 1:
self.stage_index += 1
self.round_count = 0
return AGENDA_STAGES[self.stage_index]
def should_advance(self, moderator_result):
# 当主持人判断连续两轮没有新的有效冲突，且当前阶段共识分足够高时推进
if moderator_result.get("conflict") == "none":
self.round_count += 1
else:
self.round_count = 0
return self.round_count >= 2
有限状态机带来的好处是发言可以被预先分类。每个智能体在发言前会被注入当前阶段的约束提示词，例如在证据核查阶段，提示词会明确禁止继续提出新论点，只能引用外部证据。如果某个智能体仍然试图提出新论点，主持人会以阶段不匹配为由将其驳回。这样即使模型想跑题，也会受到双重拦截。
阶段推进策略可以是固定轮数，也可以是自适应推进。固定轮数简单但可能过早结束或拖沓；自适应推进根据主持人对冲突和共识的判断来决定是否进入下一阶段。例如在反驳质询阶段，如果主持人连续两轮报告没有发现新的有效冲突，就可以进入证据核查阶段。需要避免阶段切换过于频繁，否则智能体来不及展开有效论证。
四、工程实现要点与效果评估
实现主持人模型与议程控制时，上下文管理是最直接的工程挑战。如果每一轮都把全部历史发言传给主持人，令牌成本会成倍增加。可以使用滑动窗口加摘要混合策略：主上下文保留最近K轮完整发言，更早的发言被压缩为每条不超过两行的摘要。主持人评估时使用主上下文加当前阶段的议程摘要，而不是完整历史。
主持人偏见是另一个需要注意的问题。主持人模型如果与辩论智能体使用同一个基座模型，可能会对某些论证风格产生偏好，或者在评分时受到发言顺序影响。可以通过轮换主持人、使用不同模型家族、对主持人输出做结构化解码来降低偏见。另外，主持人的相关性阈值如果设置过高，会把一些跨领域的合理类比也判为跑题，因此初期可以先在人工标注的跑题样本上校准阈值。
评估效果时，除了最终答案准确率，还要记录平均辩论轮数、被主持人驳回的发言比例、每个阶段的平均停留轮数、最终结论与原始问题的语义相似度。下面的示例展示一个简单的评估记录结构。
{
"task_id": "q_1024",
"question": "比较缓存库A和B在低内存场景下的表现",
"stages_used": 5,
"total_rounds": 14,
"rejected_utterances": 6,
"rejection_rate": 0.3,
"final_relevance": 0.92,
"answer_correct": true
}
实际测试中，加入主持人模型和议程控制后，多智能体辩论在令牌消耗上通常会增加约百分之二十到百分之三十，但答案准确率提升明显，尤其在需要多步推理和证据引用的任务上。跑题率从无约束辩论时的约百分之四十下降到百分之十以下。对于预算有限的项目，可以先只启用主持人模型，在跑题严重的任务上再叠加议程控制，这样能用较小成本获得大部分收益。
多智能体辩论不是简单的让多个模型自由聊天，它需要明确的讨论结构和质量闸门。主持人模型解决每一轮发言是否该被采纳，议程控制解决整个讨论按照什么阶段推进。两者结合后，辩论推理才能从热闹的脑暴变成可靠的推理流水线。