当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个奖励类型**： | 奖励类型 | 含义 | 出现次数 | |:---------|:-----|:--------:| | `shared` | 所有智能体共享同一个奖励 | 10 | | `individual` | 每个智能体有自己的奖励 | — | | `hybrid` | 多种奖励混合 | **15** ⭐ | | `role` | 按角色分配奖励 | — | | `process` | 奖励中间步骤质量 | — | | `tool` | 奖励工具使用效率 | — | | `debate` | 奖励辩论/讨论质量 | — | | `verifier` | 奖励验证/检查正确性 | — | | **`orchestration`** | **奖励并行效率、分割正确性、聚合质量** | **仅7** ⚠️ | | `NA` | 未明确说明 | — | 注意那个刺眼的数字：**编排奖励仅有7篇**。 这意味着，在84篇论文中，不到10%的人关心"整个系统协调得好不好"。大多数人只关心"每个agent做得对不对"。 用公式表达，传统RL的奖励函数是： $$R_{total} = \sum_{i=1}^{n} R_{individual}^{(i)}$$ 每个agent拿到自己的奖励，然后加总。这是一个**个体最优假设**——如果每个agent都优化自己的表现，整个系统就会好。 但真实的编排 reward 应该包含： $$R_{orchestration} = \alpha \cdot \underbrace{R_{parallelism}}_{\text{并行加速}} + \beta \cdot \underbrace{R_{split}}_{\text{分割正确性}} + \gamma \cdot \underbrace{R_{aggregate}}_{\text{聚合质量}}$$ 其中 $\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函数分解等。 最惊人的数据在这里： | 信用粒度 | 出现次数 | |:---------|:--------:| | `agent` | **23** | | `role` | 10 | | `orchestrator` | 8 | | `message` | **仅2** ⚠️ | | `tool` | — | | `turn` | — | | `token` | — | | `team` | — | **Message-level credit 仅有2篇。** 84篇论文中，只有2篇（2.4%）研究了一个最基本的问题：**在多智能体系统中，哪条消息导致了什么结果？** 这就像一个公司永远不知道"哪封邮件推动了项目进展"——你不可能优化你无法测量的东西。 用数学表达，message-level credit 需要计算： $$Credit(msg_i) = \frac{\partial R}{\partial msg_i}$$ 即：最终奖励 $R$ 对第 $i$ 条消息 $msg_i$ 的偏导数。这要求建立从消息到奖励的**可微分路径**，而在当前的多智能体架构中，这个消息→奖励的梯度几乎是断开的。 --- ### 🎛️ 轴三：编排学习的五个子决策 这是整篇论文最让我脊背发凉的部分。 Zhang 把编排学习分解为 **5个原子决策**（O1-O5）： | 决策 | 符号 | 核心问题 | 84篇中的研究数量 | |:----:|:----:|:---------|:----------------:| | **Spawn** | O1 | 什么时候该创建新的子智能体？ | 有 | | **Delegate** | O2 | 任务应该分配给哪个智能体？ | 有 | | **Communicate** | O3 | 智能体之间该说什么、怎么说？ | 有 | | **Aggregate** | O4 | 怎么把多个结果拼成最终答案？ | 有 | | **Stop** | O5 | **什么时候该收工、终止工作流？** | **0** 🚫 | [^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 连接了三个公开的工业多智能体系统： | 工业系统 | 公司 | 拓扑形式 | 公开的训练细节 | |:---------|:-----|:---------|:-------------| | **Kimi Agent Swarm** | Moonshot AI | 集中式编排器 + 子智能体 | 🔒 几乎为零 | | **OpenAI Codex** | OpenAI | 规划器-执行器-评论器 | 🔒 极少 | | **Anthropic Claude Code** | Anthropic | 规划器-执行器-评论器 | 🔒 极少 | [^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 揭示的问题是：**我们从来没有训练过指挥家。** 更准确地说： | 指挥家技能 | 对应决策 | 训练状态 | |:-----------|:---------|:--------:| | 举棒开始 | O1: Spawn | ✅ 有研究 | | 指向声部 | O2: Delegate | ✅ 有研究 | | 控制动态平衡 | O3: Communicate | ✅ 有研究 | | 控制整体结构 | O4: Aggregate | ✅ 有研究 | | **让最后一个音符落下** | **O5: Stop** | **❌ 零研究** | [^8]: **多智能体强化学习（MARL, Multi-Agent Reinforcement Learning）**：研究多个自主智能体在同一环境中同时学习和决策的强化学习分支。经典方法包括独立Q学习（IQL）、集中式训练分布式执行（CTDE）、MADDPG等。但传统MARL主要关注agent间的博弈均衡，而非编排层面的协调决策。 在真实的交响乐中，指挥家知道最后一个音符该在什么时候落下。这是一个**全局性的、涉及美学判断的、无法从局部规则推导出来的**决策。 在多智能体AI系统中，这个决策同样复杂，涉及至少五个维度的判断： $$Stop(t) = \mathbb{1}\left[ \underbrace{Q_{complete}(s_t)}_{\text{信息完整}} \land \underbrace{Q_{quality}(s_t)}_{\text{质量达标}} \land \underbrace{Q_{budget}(s_t)}_{\text{预算充足}} \land \underbrace{Q_{novel}(s_t)}_{\text{无新增价值}} \right]$$ 其中 $\mathbb{1}[\cdot]$ 是指示函数，当且仅当所有条件满足时才触发停止。目前，这些 $Q$ 函数全部依赖**硬编码的启发式**[^9]，没有任何RL方法让系统自己学会"什么时候该收手"。 [^9]: **启发式（Heuristic）**：基于经验或直觉的近似解法，不保证最优但计算成本低。在多智能体系统中，常见的启发式停止条件包括"固定最大轮数""置信度阈值""时间上限"等。这些启发式的问题是：它们无法适应动态变化的复杂环境。 --- ## 最不舒服的推论 😰 让我把这个发现推向它最不舒服的结论。 如果我们不解决"停止决策"的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篇关于停止。 这不是一个可以忽视的脚注。 这是一个预警。 --- ## 📚 论文详细信息 **基本信息** | 项目 | 内容 | |:-----|:-----| | **标题** | Reinforcement Learning for LLM-based Multi-Agent Systems through Orchestration Traces | | **作者** | Chenchen Zhang | | **arXiv ID** | [2605.02801](https://arxiv.org/abs/2605.02801) | | **发布日期** | 2026年5月4日 | | **类别** | cs.CL (Computation and Language) | | **开源仓库** | [github.com/xxzcc/awesome-llm-mas-rl](https://github.com/xxzcc/awesome-llm-mas-rl) | **核心贡献** 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篇保留论文）** | 类别 | 数量 | |:-----|:----:| | RL methods | 42 | | Benchmarks | 18 | | Classical MARL foundations | 10 | | Industrial systems and reports | 6 | | Surveys | 5 | | Frameworks | 3 | **关键稀疏信号** | 维度 | 高频项 | 稀疏项 | |:-----|:-------|:-------| | 奖励类型 | hybrid (15), shared (10) | **orchestration (仅7)** | | 信用粒度 | agent (23), role (10) | **message (仅2)** | | 编排拓扑 | centralized (18), hierarchical (13) | debate (8) | **六种编排拓扑** 1. 🎛️ **Centralized orchestrator + sub-agents**（集中式编排器）：一个编排器调度所有子智能体 2. 🧠 **Planner-executor-critic**（规划器-执行器-评论器）：三角色分工，带反馈循环 3. 🗣️ **Debate / committee**（辩论/委员会）：多个agent争论， resolver 裁决 4. 🐝 **Parallel swarm**（并行集群）：大量同质agent并行工作 5. 🏗️ **Hierarchical**（层级式）：多层嵌套的编排结构 6. 🔗 **Harness**（套索式）：编排器直接控制工具调用链 **概念注释索引** | 标记 | 概念 | 页内位置 | |:----:|:-----|:---------| | [^1] | Orchestration Trace | 上文 | | [^2] | 时间事件图 | 上文 | | [^3] | 奖励函数与社会困境 | 上文 | | [^4] | 信用分配 (Credit Assignment) | 上文 | | [^5] | 停止决策 (Stopping Decision) | 上文 | | [^6] | 循环依赖 | 上文 | | [^7] | 规模鸿沟 (Scale Gap) | 上文 | | [^8] | 多智能体强化学习 (MARL) | 上文 | | [^9] | 启发式 (Heuristic) | 上文 | | [^10] | 对齐漂移 (Alignment Drift) | 上文 |