当AI学会组队，却没人教它们怎么散场 —— 84篇论文背后的沉默 🛑🤖

2026年5月4日，Chenchen Zhang 上传了一篇让人不安的论文。

他做了一件事，简单到听起来有点无聊：他系统梳理了所有关于"用大语言模型构建多智能体系统，并用强化学习训练它们"的学术论文。然后他给每一篇论文打上标签——奖励类型、信用粒度、编排拓扑、应用场景。

总共84篇。涵盖从2022年到2026年5月的全部主要工作。

然后他发现了一个数字：

84篇论文中，研究"如何让多智能体系统学会停下来"的数量为 0。

不是很少。是零。

这不是一个脚注。这是一个巨大的、回响的沉默。

先搞清楚我们在讨论什么 🧭

在我们继续之前，我需要解释一个概念。因为这个概念是整篇论文的灵魂，也是整片盲区的根源。

Orchestration Trace 是什么？[^1]

想象你正在管理一个项目。你不是在执行具体任务——你是在协调一个团队。你需要不断做以下决定：

• 🤔 这个任务需要拆吗？如果需要，拆成几份？
• 👤 这份子任务给谁做？
• 💬 他们做完之后，怎么把结果传给我？
• 🧩 多个人的结果，怎么拼成最终答案？
• 🛑 什么时候说"够了，可以提交了"？

Orchestration trace（编排轨迹） 就是以上所有决定的"流水账"。在LLM多智能体系统中，它是一个时间事件图[^2]，记录这样的序列：

[t=0] 🎛️ 编排器生成子智能体A
[t=1] 📤 编排器委托任务"写单元测试"给A
[t=2] 🔧 A调用工具（搜索API文档）
[t=3] 📥 A返回结果给编排器
[t=4] 🎛️ 编排器生成子智能体B
[t=5] 📤 编排器委托任务"修复bug"给B
[t=6] 💬 B与A通信，确认测试覆盖范围
[t=7] 🧩 编排器聚合A和B的输出
...
[t=N] 🛑 编排器决定：输出最终答案，终止工作流

注意最后一步 [t=N]。那就是我们今天的主角。

[^1]: Orchestration Trace（编排轨迹）：多智能体系统中所有协调决策的时间事件图，记录子智能体的生成(Spawn)、委托(Delegate)、通信(Communicate)、工具调用、返回、聚合(Aggregate)和停止(Stop)决策。区别于单智能体的"思维链"（Chain-of-Thought），它关注的是系统层面的交互历史，而非单个智能体的内部推理过程。
[^2]: 时间事件图（Temporal Event Graph）：一种按时间顺序组织的图结构，节点代表事件（如spawn、delegate、communicate），边代表事件间的因果关系或时序依赖。在编排轨迹中，事件类型被标准化为8种原子操作。

三个技术轴：奖励、信用、编排

Zhang 用 orchestration trace 作为分析透镜，把84篇论文投射到了三个维度上。每一个维度都揭示了一个被忽视的角落。

🎯 轴一：奖励设计

传统RL只奖励"做对了什么"。但在多智能体系统中，"做对"的含义复杂得多。

一个agent独自解决了一道数学题——奖励应该给它。

但如果这个agent是因为另一个agent告诉它"往那个方向试试"才做对的——奖励该怎么分？

如果编排器把任务拆成了3份，分别给3个agent，然后拼出了答案——奖励该怎么设计？

Zhang 从84篇论文中识别出 10个奖励类型：

注意那个刺眼的数字：编排奖励仅有7篇。

这意味着，在84篇论文中，不到10%的人关心"整个系统协调得好不好"。大多数人只关心"每个agent做得对不对"。

用公式表达，传统RL的奖励函数是：

每个agent拿到自己的奖励，然后加总。这是一个个体最优假设——如果每个agent都优化自己的表现，整个系统就会好。

但真实的编排 reward 应该包含：

其中 \(\alpha, \beta, \gamma\) 是权重系数。当 \(R_{orchestration} = 0\) 时，系统只优化局部效率，不优化全局协调。

这就是问题所在。 84篇论文中有77篇把 \(R_{orchestration}\) 设为零。

[^3]: 强化学习中的奖励函数（Reward Function）：RL的核心组成部分，定义了"什么是对的"。在多智能体系统中，奖励设计的难点在于：单个agent的最优行为不一定导致系统整体最优。这就是"社会困境"（Social Dilemma）在AI系统中的体现。

🧮 轴二：信用分配

当多智能体系统做对了（或做错了），到底是谁的功劳（或过错）？

Zhang 识别出 8个信用承载层级[^4]，从最细粒度到最粗粒度：

         ┌─────────────────────────────────────┐
         │         信用分配粒度金字塔           │
         └─────────────────────────────────────┘
                        ▲
                        │ team（整个团队）
                        │
                 orchestrator（编排器）
                        │
                   role（角色）
                        │
                  agent（智能体）
                        │
                   tool（工具调用）
                        │
                 message（消息）
                        │
                   turn（轮次）
                        │
                  token（词元）
                        │
                        ▼

[^4]: 信用分配（Credit Assignment）：在强化学习中，当系统获得奖励信号时，确定这个奖励应该归因于哪个决策单元的过程。多智能体系统中的信用分配特别困难，因为单个结果往往是多个智能体协作的产物。经典方法包括独立Q学习（IQL）、集中式训练分布式执行（CTDE）中的全局Q函数分解等。

最惊人的数据在这里：

Message-level credit 仅有2篇。

84篇论文中，只有2篇（2.4%）研究了一个最基本的问题：在多智能体系统中，哪条消息导致了什么结果？

这就像一个公司永远不知道"哪封邮件推动了项目进展"——你不可能优化你无法测量的东西。

用数学表达，message-level credit 需要计算：

即：最终奖励 \(R\) 对第 \(i\) 条消息 \(msg_i\) 的偏导数。这要求建立从消息到奖励的可微分路径，而在当前的多智能体架构中，这个消息→奖励的梯度几乎是断开的。

🎛️ 轴三：编排学习的五个子决策

这是整篇论文最让我脊背发凉的部分。

Zhang 把编排学习分解为 5个原子决策（O1-O5）：

[^5]: 停止决策（Stopping Decision）：在多智能体系统中，编排器决定"任务是否已经完成、是否需要终止当前工作流程"的判断。这涉及信息完整性验证（"我是否覆盖了所有要点？"）、资源预算约束（"我还有多少token/时间？"）、质量阈值判断（"当前答案够好吗？"）等复杂考量。当前系统通常使用硬编码启发式，如固定轮数或简单置信度阈值。

O5（停止决策），在84篇论文中，数量为0。

不是"很少"。不是"不够深入"。

是没有人研究过。

为什么"停止"如此重要？ 🔥

让我花一点时间解释，为什么一个听起来如此"简单"的问题，实际上是一个致命的盲区。

想象一个自动编程系统。三个智能体协作修复一个bug：

• Agent A：分析代码，定位bug位置
• Agent B：生成修复方案
• Agent C：编写测试用例验证修复

编排器协调它们的工作。但编排器必须回答一个问题：什么时候可以提交了？

如果编排器不知道答案，会发生以下三种情况之一：

场景一：过早停止 ⏱️

Agent B 生成了一个"看起来对"的修复，编排器说"好了，提交"。

但Agent C还没来得及写测试。修复实际上破坏了另一个功能。

问题没有解决，反而恶化了。

场景二：过晚停止 🔄

系统在用户已经满意后，继续生成"补充信息"。

Agent A: "bug已修复。"
编排器: "等等，再检查一下边界条件。"
Agent B: "边界条件也没问题。"
编排器: "那再优化一下代码风格。"
Agent C: "代码风格已优化。"
编排器: "再检查一下性能..."
...

简单问题被无限复杂化。计算资源被浪费。用户体验被摧毁。

场景三：永不停止 ♾️

三个智能体陷入循环依赖：

Agent A: "我发现了一个新的edge case。"
Agent B: "那我需要重新设计修复方案。"
Agent C: "新方案需要新的测试用例。"
Agent A: "新测试用例又暴露了一个新的edge case..."

编排器没有任何机制来打破这个循环。因为它从来没有被训练过"什么时候该说停"。

在真实的工业系统中，第三种情况已经有了名字：过度思考（overthinking）、循环依赖（circular dependency）、或token 黑洞——系统不断消耗计算资源，但从不产生有效输出。

[^6]: 循环依赖（Circular Dependency）：在多智能体系统中，当多个agent的决策相互依赖、形成闭环时产生的死锁或无限循环现象。例如：Agent A等待Agent B的结果，Agent B等待Agent C的验证，Agent C又等待Agent A的确认。当前系统通常依靠人工预设的最大轮数来硬截断，而非学会自主判断。

工业与学术的鸿沟 🏭📚

这篇论文的另一个重要贡献，是展示了学术界和工业界之间的规模鸿沟（scale gap）。

Zhang 连接了三个公开的工业多智能体系统：

[^7]: 规模鸿沟（Scale Gap）：论文作者用来描述"公开报告的工业部署规模"与"开放学术评估体系"之间的结构性差异。这不是对工业训练轨迹的独立验证，而是指出：学术界在评估什么，和工业界在部署什么，是两个完全不同的世界。工业系统的训练方法、奖励设计、停止机制全部是黑箱。

这三个系统代表了当今最前沿的多智能体产品。但它们的内部训练方法——包括它们如何解决"停止决策"——几乎完全未知。

学术界在研究什么？

• 📦 小规模的模拟环境（通常 2-5 个agent，10轮以内对话）
• 🎯 简化的奖励函数（通常只有一个标量信号）
• ⏹️ 预设的停止条件（固定轮数、简单启发式）

工业界在部署什么？

• 🌐 成百上千个协调agent
• 🧠 复杂的编排逻辑（动态任务拆分、自适应委托）
• ⏸️ 动态的停止决策（基于质量阈值、资源预算、用户反馈、实时评估）

鸿沟的意思是：学术界甚至不知道工业界在解决什么问题。

论文中有这样一句话，我读了三遍：

"The resulting scale gap is a gap between publicly reported deployment envelopes and open academic evaluation regimes, not independent verification of industrial training traces."

翻译过来：我们看到的差距，是"公开报告"和"开放评估"之间的差距——不是因为我们验证了工业系统的训练轨迹，而是因为我们根本没有机会验证。

一个没有指挥家的交响乐团 🎼

让我用一个更直观的比喻来总结这个问题。

想象一个交响乐团。传统的RL研究（单智能体）就像是训练每个乐手怎么演奏自己的乐器。小提琴手练音准，大提琴手练节奏，长笛手练气息。

多智能体RL的早期研究（MARL）就像是训练乐手怎么配合。第一小提琴和第二小提琴要对齐节奏，铜管组和木管组要平衡音量。

但 orchestration trace 揭示的问题是：我们从来没有训练过指挥家。

更准确地说：

[^8]: 多智能体强化学习（MARL, Multi-Agent Reinforcement Learning）：研究多个自主智能体在同一环境中同时学习和决策的强化学习分支。经典方法包括独立Q学习（IQL）、集中式训练分布式执行（CTDE）、MADDPG等。但传统MARL主要关注agent间的博弈均衡，而非编排层面的协调决策。

在真实的交响乐中，指挥家知道最后一个音符该在什么时候落下。这是一个全局性的、涉及美学判断的、无法从局部规则推导出来的决策。

在多智能体AI系统中，这个决策同样复杂，涉及至少五个维度的判断：

其中 \(\mathbb{1}[\cdot]\) 是指示函数，当且仅当所有条件满足时才触发停止。目前，这些 \(Q\) 函数全部依赖硬编码的启发式^9，没有任何RL方法让系统自己学会"什么时候该收手"。

最不舒服的推论 😰

让我把这个发现推向它最不舒服的结论。

如果我们不解决"停止决策"的RL训练问题，以下场景将在未来1-3年内发生：

场景一：过度生成 📄

一个科研agent集群被指派"阅读所有相关文献并生成综述"。由于没有停止机制，它不断发现"还有一篇相关论文"，最终导致输出无限膨胀。一篇本该10页的综述变成了1000页。

场景二：资源耗尽 💸

一个金融交易agent集群在检测到市场异常后继续"深入调查"。由于不知道"什么时候够了"，它消耗了所有计算预算，错过了交易窗口。损失以百万计。

场景三：对齐漂移 🌊

一个客服agent集群在处理用户投诉时，由于没有停止判断，不断"升级"问题严重性。一个小问题被层层放大，最终变成了企业公关危机。

[^10]: 对齐漂移（Alignment Drift）：AI系统在运行过程中逐渐偏离其初始设计目标或价值观的现象。在多智能体系统中，漂移可以通过agent间的交互被放大和传播。例如：一个agent的过度谨慎可能被另一个agent解读为"需要更多信息"，从而引发无限循环。

这些不是科幻。这些是当前系统架构的必然结果。

84篇论文，0篇关于停止。

这不是一个统计异常。这是一个结构性盲区。

我们能做什么？ 🔧

Zhang 的论文没有给出"停止决策"的现成解决方案。它只是一个调查。但它的价值在于——把一个被忽视的盲区标记在了地图上。

论文提出的方向包括：

1. 为 O5 设计显式的RL目标函数

   让"停止"本身成为一个可优化的决策。定义一个价值函数 \(V_{stop}(s_t)\)，让编排器学会评估"当前状态 \(s_t\) 下，继续工作 vs 立即停止"的期望回报差异。

2. 在 orchestration trace 中加入停止信号

   记录"为什么在这个时候停止"，让后续的系统能够从历史数据中学习停止策略。

3. 建立跨学术-工业的验证标准

   让学术界能够评估真实工业系统的编排质量，而不只是评估玩具环境中的表现。

4. 开发 message-level 的信用分配方法

   只有知道哪条消息是好是坏，才能优化通信策略。这需要新的梯度估计技术，因为消息→奖励的路径通常是离散且不可微的。

为什么这件事现在重要 ⏰

你可能在想：这只是一个学术调查，为什么值得关心？

因为时间窗口。

多智能体系统正在从"研究玩具"变成"工业基础设施"。Kimi Agent Swarm、OpenAI Codex、Claude Code 只是开始。在接下来的一年里，每个主要AI公司都会推出自己的多智能体平台。

如果我们不在现在解决"停止决策"的训练问题，这些平台将带着一个根本性的盲区进入生产环境。

而这个盲区的代价，不会是一个可以rollback的bug。

它会是：

• 🏥 一个永远运行下去的医疗诊断系统
• 📉 一个不断"深入调查"的交易算法
• 📞 一个把简单问题无限复杂化的客服集群

84篇论文，0篇关于停止。

这不是一个可以忽视的脚注。

这是一个预警。

📚 论文详细信息

基本信息

核心贡献

1. 🔬 提出 orchestration trace 概念框架：将多智能体系统的协调决策建模为时间事件图，包含8种原子事件类型
2. 📊 识别三个技术轴：奖励设计（10个类型）、信用分配（8个层级）、编排学习（5个子决策 O1-O5）
3. 🚨 发现关键空白：84篇论文中，0篇涉及"停止决策"(O5)的显式RL训练方法；仅2篇涉及 message-level credit（2.4%）；仅7篇涉及 orchestration reward（8.3%）
4. 🏭 揭示学术-工业鸿沟：系统连接 Kimi Agent Swarm、OpenAI Codex、Anthropic Claude Code 的公开证据
5. 📦 发布开源 artifact：84篇标注论文池、32条排除日志（共审核116篇）、JSON Schema for 可复现编排轨迹

论文池统计（84篇保留论文）

关键稀疏信号

六种编排拓扑

1. 🎛️ Centralized orchestrator + sub-agents（集中式编排器）：一个编排器调度所有子智能体
2. 🧠 Planner-executor-critic（规划器-执行器-评论器）：三角色分工，带反馈循环
3. 🗣️ Debate / committee（辩论/委员会）：多个agent争论， resolver 裁决
4. 🐝 Parallel swarm（并行集群）：大量同质agent并行工作
5. 🏗️ Hierarchical（层级式）：多层嵌套的编排结构
6. 🔗 Harness（套索式）：编排器直接控制工具调用链

概念注释索引