AutoGen GroupChat两个Agent有分歧、第三个和稀泥，循环到max_rounds截断吐一个半成品——non-terminating conversation是生产环境最高频的failure mode，加termination condition和“家长介入”的边界到底该怎么划？

摘要与核心论点

多智能体群聊（GroupChat）在生产环境中最常见的失效，不是单个 Agent 答错，而是对话无法收敛：两个 Agent 在方案 A 与方案 B 之间反复拉锯，第三个 Agent 以“两者都有道理”的姿态和稀泥，轮次计数器一路涨到 max_rounds，系统被强制截断，最终吐出一个既未定稿也未报错的“半成品”。这类 non-terminating conversation 的隐蔽性在于它不抛异常、不打错误码，只在业务侧表现为“结果质量不稳定”。

本文提出一条贯穿全文的分析主线：多智能体系统的终止问题，本质是“终止判定权”的分配问题。谁有权宣布对话结束、依据什么信号宣布、宣布失败时如何降级，决定了 termination condition 与“家长介入”（human-in-the-loop / supervisor 介入）的边界。围绕这条主线，本文依次讨论失效的动力学机制、终止条件的四层设计、介入边界的量化划法、可观测性落地与前沿预判，并给出可直接照搬的配置与代码路径。

目录

一、问题定义：为什么“不终止”比“答错”更危险

先给术语一个可操作的定义。Non-terminating conversation 指多智能体对话在预算耗尽前未满足任何显式终止条件，系统只能依赖轮次上限、token 上限或超时等“外部截断”结束会话，且截断时不存在被多数参与者认可的输出。它与“答错”的区别在于：答错是单点错误，可被校验器捕获；不终止是过程性错误，错误发生在“没有形成结论”这一层，任何针对单条消息的校验都抓不住它。

AutoGen 的 GroupChat 机制为这类失效提供了温床。其经典实现中，一个 GroupChatManager 依据 speaker_selection_method（如 round_robin、auto、random）选择下一个发言者，并在每轮检查 is_termination_msg 回调；一旦达到 max_round，run() 返回 termination_reason 为 max_rounds 的 ChatResult。本文评述：这套设计把“终止”交给了两个东西——一个逐消息的布尔回调，和一个全局轮次上限。前者依赖 LLM 输出里出现特定标记（如 “TERMINATE”），后者是纯计数。二者之间没有任何“对话是否正在收敛”的状态判断，这正是半成品产出的结构性原因。

从生产视角看，不终止的代价被严重低估。它消耗的是三份预算：token 预算（每轮全员上下文重复计费）、延迟预算（用户等待被拉长到分钟级）、以及最关键的信任预算——用户拿到一个“看起来像答案、实际没定论”的输出，比拿到一个明确报错更糟，因为前者会污染下游流程而不自知。业界在讨论 agent 可靠性时，常引用“错误传播”“级联失败”等概念，但本文认为，多智能体场景下更应优先治理的是“无结论传播”：一个未收敛的中间态被当作终态写入数据库或触发动作，其破坏半径远大于一次显式失败。

需要强调的是，本文不主张“让对话尽量早停”。过早终止会牺牲多智能体本应带来的审议收益（deliberation benefit）。真正要设计的是一个有判别力的终止函数：它能在“还在有效收敛”与“已经陷入振荡”之间做出区分，并据此选择继续、收敛、升级人工或显式失败。这条判别线，就是全文反复回到的主线——终止判定权的分配。

二、失效动力学：分歧、和稀泥与截断的三体问题

2.1 分歧的两种形态：真分歧与伪分歧

两个 Agent 意见相左，并不必然是坏事。本文把分歧分为两类。真分歧指双方基于不同证据或不同目标函数得出互斥结论，例如一个 Agent 主张用悲观锁保证一致性、另一个主张用乐观锁换吞吐，二者都有可辩护的理由。伪分歧指双方其实在说同一件事的不同侧面，或仅仅因为措辞、粒度、假设不同而显得对立。伪分歧是振荡的主要燃料：因为不存在真正的冲突点，任何一方都无法“说服”对方，对话只能在表层反复重述。

区分二者的工程价值在于：真分歧需要“裁决机制”（投票、加权、外部裁判），伪分歧需要“对齐机制”（统一术语、显式列出假设、要求双方先复述对方观点）。把伪分歧当真分歧去裁决，会浪费轮次；把真分歧当伪分歧去对齐，会掩盖风险。本文评述：多数生产事故里，系统默认把所有分歧都当作需要“继续讨论”的真分歧，于是永远讨论不完。一个低成本的判别信号是“立场漂移率”——若连续两轮中某 Agent 的核心主张（可用关键实体与谓词抽取近似）没有变化，则更可能是伪分歧或已进入僵持。

2.2 和稀泥 Agent 的数学角色：它为什么让系统更慢

第三个 Agent 的“和稀泥”常被当作润滑剂，但在终止动力学里它是减速器。设对话状态为各 Agent 立场的分布，和稀泥 Agent 的输出通常是“双方都有道理，建议综合考虑”，这在信息论意义上几乎不降低立场分布的熵。更糟的是，它会被 GroupChatManager 的 auto 选择策略反复选中——因为它的消息“看起来最中立、最像推进”，而选择器本身由 LLM 驱动，倾向于挑“安全”的发言者。

这形成一个正反馈：和稀泥 → 分歧未解 → 选择器再挑和稀泥 → 分歧仍未解。轮次在涨，互信息不涨。本文认为，和稀泥 Agent 的存在本身不是问题，问题在于它没有携带裁决权却被允许发言。一个健康的群聊里，每个参与者要么提供新证据，要么行使裁决，要么被静音；只提供“综合意见”而不承担结论责任的角色，应当被降权或改造为裁判角色（judge），并赋予其明确的输出契约：必须给出 A/B/折中方案三选一，并附理由。

2.3 截断的代价：半成品是如何被“生产”出来的

当轮次触顶，max_rounds 触发，系统拿到的是最后一条消息或整个消息列表。若下游直接把最后一条消息当答案，就得到半成品；若下游做摘要，则得到一个“平均了所有立场”的模糊结论。两种处理都在掩盖一个事实：对话没有形成决议。本文评述：截断本身不是错误，错误在于截断没有被建模为一种独立的终态。它应当与“成功终止”“人工接管”“显式失败”并列，携带明确的语义（未收敛）和明确的后续动作（重试、降级、升级），而不是被静默地折叠进“正常返回”。

工程经验法则（本文整理，非单一文献结论）：把 termination_reason 当作一等返回值透传到业务层，凡取值不是“显式成功”的，一律禁止写入终态存储。仅此一条，可消除大部分“半成品被当成品”的事故。

三、终止条件的四层设计：从计数器到语义判据

终止条件不应是单一回调，而应是一个分层体系。本文给出四层结构，自下而上依次是：预算层、协议层、语义层、裁决层。下层保证“一定会停”，上层保证“停得有意义”。四层同时生效，任一上层触发即终止，下层作为兜底。

3.1 第一层：预算层（Budget）——保证有界

预算层是最朴素也最不可省略的一层，包含轮次上限、总 token 上限、墙钟超时、单 Agent 调用次数上限。它的职责不是“判断好坏”，而是“保证系统不会无限运行”。AutoGen 的 max_round 属于这一层，LangGraph 的 recursion_limit、CrewAI 的 max_iter 同理。本文评述：预算层的参数不应拍脑袋设定，而应基于“收敛所需轮次的分布”来定。做法是先在离线回放集上统计成功会话的轮次分位数（如 P50、P90、P99），把 max_rounds 设在 P99 附近，使绝大多数正常会话不受干扰，同时给异常会话一个明确的天花板。

# 预算层配置示例（伪代码，参数需按回放集标定）
budget = {
    "max_rounds": 12,          # 取成功会话轮次的 P99
    "max_total_tokens": 60000, # 按上下文窗口与成本预算反推
    "wall_clock_timeout_s": 90,
    "per_agent_call_limit": 5, # 防止单一 Agent 霸占发言
}

3.2 第二层：协议层（Protocol）——让“结束”成为可声明的动作

协议层要求参与者能以结构化方式声明“我认为可以结束了”。AutoGen 的 is_termination_msg 是这一层的雏形：检查消息中是否含 “TERMINATE”。但纯字符串匹配脆弱且易被绕过。更稳的做法是要求 Agent 输出结构化字段，例如 JSON 中的 {"action": "finalize", "answer": "...", "confidence": 0.8}，由编排器解析。本文评述：协议层的关键不是“检测到结束词”，而是“结束必须附带可校验的产物”。一个只有 “TERMINATE” 没有答案的终止，等于把问题抛回给调用方，应当被视为无效终止。

3.3 第三层：语义层（Semantic）——判断是否在收敛

语义层是四层中最有技术含量、也最容易被跳过的一层。它要回答的问题是：过去若干轮，对话是在向结论靠近，还是在原地打转？可用的信号包括：立场稳定性（关键主张是否反复）、消息间语义相似度（连续两轮是否高度重复）、新增信息量（是否出现新实体、新证据、新约束）、以及冲突度（互斥主张的数量是否在下降）。

一个可落地的近似判据是“双轮停滞检测”：若连续两轮中，所有参与者的核心主张集合未发生变化，且消息相似度超过阈值，则判定为停滞，触发收敛或升级。本文评述：语义层不必追求精确的“收敛证明”，它只需要比纯计数器更早、更准地识别“已经没在推进”。在工程上，用轻量嵌入模型计算相邻轮次相似度，配合规则化的主张抽取，已足以覆盖大部分振荡场景，成本远低于每轮再调一次大模型做裁判。

3.4 第四层：裁决层（Adjudication）——把“结束”变成“决议”

裁决层解决的是“谁来拍板”。常见实现有三种：多数投票（适用于离散选项）、裁判 Agent（适用于开放结论）、外部规则（适用于有硬约束的领域）。本文评述：裁决层的引入必须伴随“裁决成本”的核算——每加一次裁判调用，就多一份延迟与费用。因此裁决不应每轮触发，而应由语义层的停滞信号触发，形成“平时不裁、僵持才裁”的按需结构。

四层之间的关系可以概括为：预算层是保险丝，协议层是正常出口，语义层是早期预警，裁决层是最终法庭。缺任何一层，系统要么停不下来，要么停得没有意义。延伸阅读可参考 AutoGen 官方文档中关于 termination 的说明（microsoft.github.io/autogen）与 LangGraph 的递归限制文档（langchain-ai.github.io/langgraph）。

四、“家长介入”的边界：何时该人管、何时该机器管

“家长介入”在本文中指人类或高权限 supervisor 对群聊的干预，包括审批、改写、强制裁决、终止。它的核心问题不是“要不要介入”，而是“边界划在哪”。边界划得太松，人工成本爆炸、系统失去自动化意义；划得太紧，半成品照样流出。本文提出一条判据：介入边界应划在“机器无法自证正确”的地方，而不是划在“机器可能出错”的地方。

4.1 三类必须介入的信号

第一类是不可逆动作：对话结论将触发写库、下单、发信、删改等不可撤销操作。此时无论置信度多高，都应有人工确认或至少双签。第二类是高风险分歧：裁决层给出的结论与某一方立场差距过大，或投票分布接近对半，说明结论不稳。第三类是语义层持续报警：连续多轮停滞且裁决层也无法收敛，说明问题超出系统能力边界。

本文评述：这三类信号的共同点是“错误的期望代价显著高于介入成本”。反之，对于可逆、低风险、且语义层显示仍在收敛的会话，不应轻易打断——频繁打断会破坏多智能体的审议节奏，也会让用户对系统产生“总要人兜底”的预期，削弱自动化价值。

4.2 介入的四种形态与成本阶梯

介入不是二元的“人管/不管”，而是有成本阶梯的。由低到高：通知（只告知不阻断）、审批（人点通过/拒绝）、改写（人修改结论后放行）、接管（人直接主导后续对话）。设计时应默认走最低档，仅在信号升级时逐级抬升。本文认为，把介入设计成阶梯而非开关，是控制人工成本的关键；很多团队一上来就全量审批，结果审批队列成为新瓶颈，反而催生“无脑点通过”的橡皮图章行为。

4.3 边界的动态调整：用数据而非直觉定阈值

边界不是一次设定就固定的。本文建议用“介入收益比”来动态校准：统计每类信号触发介入后，人工实际改写了多少比例。若某类信号触发 100 次、人工改写 0 次，说明该信号过敏感，应放宽；若人工改写比例极高，说明该信号抓得准，可考虑前移。这套方法把“家长介入”从经验判断变成可度量的运营指标。本文评述：这也是把 human-in-the-loop 从“道德正确”落到“工程可算”的关键一步——介入的价值必须能被量化，否则它永远是被削减的成本项。

五、工程落地：可观测性、降级路径与配置模板

再好的终止理论，落不了地就是空谈。本节给出三条可执行路径：可观测性、降级路径、配置模板。三者共同构成“终止工程”的最小闭环。

5.1 可观测性：把“是否收敛”变成可看的指标

首先要采集的指标包括：每会话轮次数、终止原因分布、语义停滞触发次数、裁决触发次数、介入档位分布、以及“半成品率”（终止原因为 max_rounds 且下游未人工修正的比例）。其中“半成品率”是最能反映系统健康度的北极星指标。本文评述：很多团队只监控延迟和错误率，但这两者对不终止几乎不敏感——不终止的会话往往“成功返回”，错误率为零，延迟也只是偏高。只有把终止原因作为维度拆开，才能看见问题。

# 终止原因埋点（伪代码）
emit_metric("groupchat.termination", {
    "reason": result.termination_reason,   # finalize / max_rounds / adjudicated / human / error
    "rounds": result.round_count,
    "stagnation_hits": trace.stagnation_hits,
    "adjudication_calls": trace.adjudication_calls,
    "intervention_level": trace.intervention_level,
})

5.2 降级路径：终止之后做什么

终止不是终点，而是分岔口。本文建议为每种终止原因预定义降级动作：finalize 直接放行；adjudicated 放行但标记低置信；max_rounds 不写终态，转人工或重试（换 speaker 选择策略、换模型、缩小任务）；human 按介入档位处理；error 走标准重试。关键在于：每种原因都有明确的下游契约，而不是统一返回一个字符串让调用方猜。

本文评述：降级路径的设计应遵循“宁可显式失败，不可静默半成品”的原则。显式失败会触发告警和重试，半成品只会悄悄流入。把 max_rounds 从“正常返回”重新归类为“可重试的软失败”，是性价比最高的一次改造。关于多智能体编排的更多工程实践，可参考 LangChain 官方博客（blog.langchain.dev）与 Anthropic 的 agent 设计文章（anthropic.com/research）。

5.3 配置模板：一份可直接改的终止策略

termination_policy:
  budget:
    max_rounds: 12
    max_total_tokens: 60000
    wall_clock_timeout_s: 90
  protocol:
    require_structured_finalize: true   # 必须带 answer 字段
    reject_empty_finalize: true
  semantic:
    stagnation_window: 2                # 连续 2 轮
    similarity_threshold: 0.92          # 相邻轮次相似度
    require_new_evidence: true
  adjudication:
    trigger: on_stagnation               # 仅停滞时触发
    method: judge_agent                  # 或 majority_vote
    max_calls: 1
  intervention:
    default_level: notify
    escalate_on: [high_risk_disagreement, irreversible_action, adjudication_failed]
  fallback:
    on_max_rounds: retry_then_human      # 不写终态
    on_error: retry_standard

这份模板的价值不在于参数本身，而在于它把四层终止与介入阶梯显式写进了配置。团队可以在此基础上按回放集标定阈值。本文评述：配置化的意义是让终止策略可评审、可 diff、可回滚，而不是散落在各 Agent 的 prompt 里靠“记得加 TERMINATE”来维持。

六、对比与局限：不同编排范式的终止能力横评

不同多智能体编排范式对终止的支持差异很大，选型时应把“终止能力”作为显式维度，而非只看功能列表。下表为本文基于各框架公开文档整理的定性对比（非严格基准测试，仅供选型参考）。

本文评述：没有一种范式天然解决不终止问题，差别只在“把终止逻辑放在哪”。图编排把控制流显式化，最利于审计；GroupChat 把控制流交给 LLM 选择器，最灵活也最易失控。选型时应问三个问题：终止路径能否被画出来、终止原因能否被透传、语义判据能否被插入。三者皆否的范式，不建议用于高风险生产场景。

局限也要说清楚。本文的四层模型主要面向“有明确结论形态”的任务（选型、定稿、决策），对于开放式创作、头脑风暴类任务，“收敛”本身就不是目标，强行加终止判据反而有害。此外，语义层的阈值高度依赖领域与模型版本，跨场景迁移时需重新标定。本文不主张一套参数打天下，而主张一套可标定、可观测、可回滚的方法论。

七、结论与展望：把“终止”当作一等公民

回到开头那条主线：多智能体的终止问题，本质是终止判定权的分配。两个 Agent 分歧、第三个和稀泥、循环到截断，表面是 prompt 问题，深层是系统里没有任何角色被赋予“宣布结束并承担责任”的权力。本文给出的解法是四层终止（预算、协议、语义、裁决）加介入阶梯（通知、审批、改写、接管），核心是把终止从“隐式的副作用”提升为“显式的一等公民”。

展望未来，本文认为有三个方向值得关注。其一，学习式终止：用历史会话训练一个轻量收敛预测器，替代手工阈值，把语义层从规则升级为模型。其二，终止即契约：在 Agent 协议层标准化 finalize 消息格式，使跨框架的终止语义可互操作。其三，介入的自动化：把“家长”的部分裁决权委托给可审计的规则引擎，人只保留不可逆动作的最终否决权。这三条都指向同一个判断：终止不是对话的附属品，而是多智能体系统可靠性的地基。

对工程团队而言，最务实的起点不是重构整个编排，而是先做三件事：把 termination_reason 透传到业务层、把 max_rounds 重新归类为软失败、把“半成品率”加入监控。这三步成本极低，却能立刻止住大部分“半成品被当成品”的出血。剩下的，才是四层模型与介入阶梯的逐步落地。

主要参考文献

文章声明

本文内容仅为作者学习、思考、经验、笔记的总结，仅供技术交流与参考。文中观点仅代表笔者个人思辨，不构成任何学术建议、商业建议或专业建议。所有数据来源已标注，引用时请以原始文献为准。