多智能体系统把规划、搜索、反思拆给多个独立的 LLM，能力强但通信贵、工作流难改、backbone 不参与训练； 工具集成推理（TIR）把工具调用压进单模型，却只有一条固定的 ReAct 循环。 这篇论文让同一个模型在同一条生成流里轮流扮演不同角色，先把 OAgents 的协作轨迹蒸馏成 CoA 序列做 SFT，再用 Agentic RL 优化任务成功率。
MAS 把「谁负责什么」放在模型外面：多个 LLM 实例靠消息传递协作。它强在角色分工和工具编排，但通信、工作流工程和静态 backbone 都是外部成本。
TIR 把工具调用放进单模型的 ReAct 循环，端到端可训练，却只支持「think-action-observation」这一种流程，难以表达并行子任务、角色批判和多工具调度。
CoA 的做法是把角色切换也变成 token 流的一部分：模型按需激活 Thinking / Plan / Reflection / Verification 与 Search / Crawl / Code Generate，工具仍在外部执行，但协作上下文留在同一条流里。再用多智能体蒸馏和 DAPO 把这种能力训进 Qwen2.5 backbone。
先看清 MAS、TIR、ReAct 各自把「智能」放在哪，才能理解 CoA 想搬动的是什么。
复杂 agent 任务通常不是一次问答：要拆解、要查资料、要写代码、要回头检查。论文构造的训练轨迹跨度达到 5–20 hops，每个 hop 是一次 agent–tool 交互（§3.2）。这类任务需要的是多角色、多工具、多轮的协作，而不是单轮 ReAct 循环。
现有多智能体系统（Multi-Agent System, MAS）把角色放在模型外：每个 agent 往往是独立的 LLM 实例，靠消息传递协作。它强在角色分工和工具编排，但通信是外部开销，工作流要靠 prompt / workflow engineering 固定，backbone 通常不参与训练。
TIR 则相反：把工具调用放进单模型的 ReAct 循环，端到端可训练，也少了多实例通信。但一条「think-action-observation」流水线容纳不下多角色协作——它没有原生的机制让模型在同一任务里切换成规划者、检索者、批评者，再把它们的状态汇总起来。
MAS 有协作但不可端到端训练；TIR 可端到端训练但只有单 agent 循环。CoA 的目标是把前者的角色协作搬进后者的单模型训练框架里，而不是再设计一个更复杂的 agent 框架。
MAS 把协作放在模型外，TIR 把工具调用放进模型内；CoA 想把「协作」也放进去。
代表：OAgents、OWL、DeepResearch。常见做法是多个 LLM 实例 + 编排器 + 消息传递。
强项：角色分工清楚，工具种类多，复杂任务的上限高；GPT-4.1 这类强 backbone 的单步能力很强。
盲区：通信和工作流是外部开销；backbone 静态，不能从任务结果里做数据驱动的更新；换领域往往要重写 prompt / workflow。
代表：Search-R1、ReTool、WebThinker。通过 SFT / RL 让模型在推理中调用搜索、代码执行等工具。
强项：单模型端到端，工具调用策略可训练；相比 MAS，少掉多实例通信，token 开销通常更低。
盲区：基本上是单 agent 的 ReAct 循环；并行子任务、角色批判、多工具之间的动态调度，都没有原生的表达方式。
Table 1：论文对四种范式的四项能力对照。原表逐格转录，“✓”表示支持，“✗”表示不支持。
| Paradigm | Tool Integration | End-to-end Execution | Multi-agent Collaboration | Data-centric Optimization |
|---|---|---|---|---|
| ReAct | ✓ | ✗ | ✗ | ✗ |
| Multi-Agent System | ✓ | ✗ | ✓ | ✗ |
| Tool-Integrated Reasoning | ✓ | ✓ | ✗ | ✓ |
| Chain-of-Agents | ✓ | ✓ | ✓ | ✓ |
这张表是论文的范式主张，不是实验结果。它想说明的缺口很具体：ReAct 能调工具，但靠 prompt 拼装，不是端到端训练出来的策略；MAS 有协作，但协作发生在多个模型实例之间；TIR 把工具调用训练进模型，却没有多角色协作；只有 CoA 同时占了四格。
核心不是新网络结构，而是把「谁在什么时候说话」变成可训练的序列格式。
论文把 CoA 拆成两类角色。角色型 agent 负责高层推理和协调，工具型 agent 负责具体执行。所有角色共享同一个模型参数，切换只体现在当前生成的内容和标签上。
工具仍在模型外执行；CoA 内化的是角色调度和协作上下文，不是把搜索引擎或 Python 解释器塞进参数里。
φt 不是另一个模型实例，而是当前 token 流里被激活的角色。模型在同一条上下文里继续写：先产出角色的思考，再产出工具调用，工具返回的 observation 拼回同一条流，然后继续下一个角色。论文把这称为「single decoding (inference) process」。
<think> Ccot </think><tools> αm(αp) </tools><observation> Ot </observation><reflection> Ft </reflection> … <answer> At </answer>
<think> 是推理，<tools> 是工具动作，<observation> 是环境返回，<reflection> 是反思，<answer> 是最终答案SFT 的目标函数对工具返回的 observation 做 masking（Eq. 7）。模型要学的是「下一步该想什么、该调什么工具」，而不是复述搜索结果或 sandbox 输出。论文给出的理由是防止环境噪声传播（§3.2）。
点任意片段，或按「下一步」。注意第 3 段：observation 会拼回上下文，但 SFT loss 不算它。
覆盖：角色名（Thinking / Plan / Reflection / Verification 与 Search / Crawl / Code Generate）、SFT 序列标签（<think>、<tools>、<observation>、<reflection>、<answer>）、observation masking 的位置。
没覆盖：真实工具返回内容、具体任务的跳数、多轮错误修正、RL 阶段的 token 级奖励。五个片段的顺序是按论文范式拼出的示意，不是附录 C 案例的逐字轨迹。
这条流水线的关键不是 SFT / RL 本身，而是「教师轨迹怎么变成学生能学的序列」。
论文用的教师是 OAgents，一个开源多智能体系统（§3.2）。OAgents 执行任务时，作者记录每个 agent 的激活、动手前的推理状态和输出，把「谁在什么状态下做了什么」按顺序抽成一条 CoA 轨迹。这不是词级知识蒸馏，而是agent 级 / 序列级的行为蒸馏：学生学的是角色激活顺序和决策模式，不是教师的词概率分布。
原始轨迹质量参差，所以有四道渐进过滤。注意第 3、4 道不是简单删除，而是下采样 / 上采样——它们改变的是数据分布，不只是数据量。
§3.2：四阶段渐进过滤（据原文整理，不是原表）。
| 阶段 | 规则 | 目的 |
|---|---|---|
| 复杂度过滤 | 总 agent–tool 交互少于 5 次的轨迹直接丢弃。 | 去掉过于简单的任务。 |
| 质量过滤 | 错答案、冗余工具输入、未严格遵循指令的样本移除；QA / search 用 LLM 判，code 看测试是否全过，math 对 golden answer。 | 去掉“脏数据”，即使答案碰巧正确。 |
| 反思增强 | 缺少 reflection 的轨迹下采样；math / code 任务直接丢弃无反思的轨迹。 | 优先保留带自我批评、自我修正的样本。 |
| 纠错上采样 | search / QA 中 <double_check> 初判可信度低、但最终答对的轨迹上采样。 | 让模型多见“先错后改”的过程。 |
Web agent 的 SFT 数据共 16,433 条：MHQA 8,826 条 + Web Agent 7,607 条；RL 数据为 169,615（MHQA）+ 10,427（Web）（§4.1）。Code agent 的 SFT 数据正文写约 47k 条（§4.2），RL 数据 47,560 条（Table 9）。轨迹的平均跳数在 4.35–7.29 之间（Table 2 / Table 3 未转录，只引用 Avg. Hops 列），比常见的 2–3 hop benchmark 长得多。
RL 之前先筛题。Web agent 用 Qwen2.5-72B 在无工具条件下对每题采样 32 次，算 exact-match pass rate rq；rq > 0.3 的题被排除（§3.3）。理由很直接：这些题要么不需要工具就能做，要么已经被参数知识污染，训 RL 学不到真正的工具使用。Code agent 则用 7B AFM 每题采样 8 次，8 次全对的题丢弃（§3.3）。
训练算法是 DAPO。Web RL 每轮 64 个 prompt、每个 prompt 8 条 rollout，单条 rollout 最多 24 steps / 32k tokens；Code RL 每个 prompt 8 条 rollout、最多 8 次 tool call；两者都用 VeRL（§4.1 / §4.2）。
<code>…</code> 格式正确，且测试全过
Web 的 scoreanswer 来自 LLM-as-Judge（Qwen2.5-72B）的二元判断；论文没有给 format reward，理由是高质量 SFT 冷启动已经保证了格式。Code 的 scoreformat 检查每次调用是否包在 <code>\n```py\n…```\n</code> 里，数学题则用 Math-Verify 做答案抽取和校验（§3.3）。
AFM 的 backbone 仍是 Qwen2.5 系列；CoA 的“架构”体现在一条序列怎么组织角色、工具和 observation。
论文的贡献在训练与推理协议，不在网络结构：32B AFM 直接用 Qwen2.5-32B-Instruct，code agent 用 Qwen2.5-Coder-32B-Instruct（§4.1 / §4.2）。真正的改动集中在三处：system prompt 里的角色与工具说明、SFT 序列的标签格式、以及 loss 对 observation 的 mask。
覆盖：MAS 的多实例/消息传递、CoA 的单模型 token 流、角色标签与工具调用的关系、observation 的 mask 位置。
没覆盖：OAgents 的具体 agent 数量与消息协议、Figure 3 的轨迹转换细节、Figure 4 的 SFT/RL 训练框架。图中把工具画成 Search / Crawl / Python 是为了对应 §3.1 的角色表，不代表每个任务都会同时调用这三种工具。
一个容易误解的点：CoA 不是“只调用一次工具的模型”。它仍会多次调用外部工具，也会把每次 observation 拼回上下文；它省掉的是多个 LLM 实例之间的消息传递，以及这部分通信带来的 token 开销（§3.1）。Figure 5 的效率对比也是在这个意义上成立的（§5.1）。
先看原表，再看两个反直觉点：RL 的增益在数学上最大；效率优势取决于你拿谁当基线。
Table 7：web agent 基准，Pass@1；节选 32B 对照行（完整表未转录）。OAgents 是 GPT-4.1 backbone；DeepResearch 的 Backbone 列原文写「-」，未报告；AFM 是 Qwen2.5-32B-Instruct；GAIA 用 103 条 text-only 子集，BrowseComp 1,266 条，HLE 用 500 条 text-only 子集（§4.1）；表中“-”为原文未报告。
| 方法 | Backbone | GAIA Avg | WebWalker | BrowseComp | HLE |
|---|---|---|---|---|---|
| Qwen2.5-32B-Instruct | — | 6.8 | 3.1 | 0.6 | 5.4 |
| OAgents | GPT-4.1 | 58.3 | - | 13.7 | 20.2 |
| DeepResearch | — | 67.4 | - | 51.5 | 26.6 |
| WebDancer | QwQ-32B | 51.5 | 47.9 | 3.8 | 7.2 |
| WebSailor | Qwen2.5-32B | 53.2 | - | 10.5 | - |
| AFM-SFT | Qwen2.5-32B | 50.5 | 61.5 | 10.0 | 16.3 |
| AFM-RL | Qwen2.5-32B | 55.3 | 63.0 | 11.1 | 18.0 |
同 32B 参数规模内（backbone 不同），AFM-RL 的 GAIA 55.3 高于 WebSailor 53.2（+2.1 个百分点，55.3 − 53.2）和 WebDancer 51.5。但把其他 agent 框架放进来，OAgents 58.3（GPT-4.1 backbone）、DeepResearch 67.4（backbone 原文未报告）都在 AFM 之上；BrowseComp 上 OAgents 13.7、DeepResearch 51.5 也高于 AFM 的 11.1。这不是同 backbone 的比较，不能直接读成“单模型打败多智能体”。
Table 11：数学基准，32B 节选（完整表未转录）。AIME24 / AIME25 / AMC23 报 avg@16；MATH500 / OlympiadBench 报 Pass@1；“Avg.” 是五列平均，混合了两种口径。注意 AFM-SFT 行的 Avg. 栏写 60.0，但五列复算为 (41.0+31.0+82.8+78.9+51.1)/5 = 57.0；同表其余各行的 Avg. 都与五列简单平均一致（AFM-RL 78.0、ReTool 74.4、SimpleTIR 71.5、Qwen2.5-Coder 36.6）。
| 方法 | AIME24 | AIME25 | MATH500 | AMC23 | OlympiadBench | Avg. |
|---|---|---|---|---|---|---|
| Qwen2.5-Coder-32B | 13.3 | 10.0 | 73.0 | 50.6 | 35.9 | 36.6 |
| ReTool-32B | 67.0 | 49.3 | 93.2 | 96.1 | 66.4 | 74.4 |
| SimpleTIR-32B-Multi | 59.9 | 49.2 | 92.9 | 91.6 | 63.7 | 71.5 |
| AFM-SFT | 41.0 | 31.0 | 82.8 | 78.9 | 51.1 | 60.0 |
| AFM-RL | 66.7 | 59.8 | 94.6 | 96.6 | 72.1 | 78.0 |
AFM-RL 的 AIME25 59.8 比 ReTool-32B 的 49.3 高 10.5 个百分点（59.8 − 49.3），比 SimpleTIR-32B-Multi 的 49.2 高 10.6 个百分点（59.8 − 49.2）；五列平均 78.0 比 ReTool 的 74.4 高 3.6 个百分点（78.0 − 74.4）。AIME24 上 ReTool 的 67.0 仍高于 AFM-RL 的 66.7——不是每一列都翻过去。另外，AFM-SFT 的 Avg. 栏 60.0 与五列复算 57.0 不一致：按表内 Avg. 栏，SFT→RL 的平均增益是 +18.0（78.0 − 60.0）；按五列复算则是 +21.0（78.0 − 57.0）。两处并列，本页不替原文选择。
Table 12：代码生成基准，Pass@1；节选 32B 对照行（完整表未转录）。表中两组 AFM 行没有标参数量；正文的 47.9 / 32.7 对应 32B 推断（依据：§4.2 的 32B 设置与 Table 12 最后一行的数值对应）。表头把这两组未标参数的 AFM 行也归入「TIR Methods From Qwen-2.5-32B Family Models」，但 §4.2.2 给出的增益 15.3 − 6.8 = 8.5、24.7 − 11.5 = 13.2 说明它们是 7B 行，表头与正文不一致。
| 方法 | LiveCodeBench v4 | LiveCodeBench v5 | CodeContests | Avg. |
|---|---|---|---|---|
| Qwen2.5-Coder-32B | 28.7 | 28.1 | 0.6 | 11.5 |
| Retool | 19.0 | 23.4 | 10.3 | 10.5 |
| AFM-SFT | 37.0 | 43.1 | 22.4 | 20.5 |
| AFM-RL | 43.0 | 47.9 | 32.7 | 24.7 |
32B AFM-RL 在 LiveCodeBench v5 上 47.9、CodeContests 32.7，均高于 Retool 的 23.4 / 10.3；这两列也是正文点名引用的数字（§1 Introduction / §4.2）。Table 12 还有两组未标参数的 AFM 行：AFM-SFT 为 v4 28.0 / v5 26.3 / CodeContests 13.3（Avg. 13.5），AFM-RL 为 29.0 / 28.7 / 18.8（Avg. 15.3）。按 §4.2.2 的 8.5（15.3 − 6.8）与 13.2（24.7 − 11.5）两组增益，这两行是 7B 结果，不要和 32B 行混在一起读。
Figure 5 比较的是 10 个随机 GAIA 样本上的「每成功任务」开销。切换基线，AFM 的相对降幅会变——这就是为什么效率数字必须带对照，而不能只写一个孤立的 84.6%。
组 1（OAgents → AFM）：AFM 24,047 tokens，OAgents 156,400 tokens。相对降幅 = (156,400 − 24,047) / 156,400 = 132,353 / 156,400 = 0.8462468 = 84.62468% → 显示为 84.6%。
组 2（WebThinker → AFM）：AFM 24,047 tokens，WebThinker 55,957 tokens。相对降幅 = (55,957 − 24,047) / 55,957 = 31,910 / 55,957 = 0.5702593 = 57.02593% → 显示为 57.0%。
工具调用合计（Search + Crawl/Visit）：OAgents 7.4 + 2.8 = 10.2；WebThinker 2.3 + 23.0 = 25.3；AFM 2.4 + 2.4 = 4.8。AFM 比 OAgents 少 10.2 − 4.8 = 5.4 次，比 WebThinker 少 25.3 − 4.8 = 20.5 次。
这里没有分布，只有三个方法的单点汇总值，因此不适用总体标准差（÷N）；JS 与手算都保留一位小数。
以上只引用相关单元格；Table 9 / Table 13 均未完整转录。
论文的数据和设定本身给出四条边界；它们不推翻结果，但决定了这套方法适合什么场景。
CoA 的 SFT 数据来自 OAgents 的成功轨迹（§3.2）。从 §3.2 与实验设置看，论文只用了 OAgents 作为教师，没有报告其他教师或教师质量消融；按这个训练流程，学生能学到的协作模式首先受教师覆盖范围限制。推断（依据：§3.2 只使用 OAgents，未报告教师消融）。
AFM 仍要调用外部 Search / Crawl / Python；Figure 5 的 token 统计是 10 个随机 GAIA 样本、每成功任务的平均值（§5.1）。它证明的是「同样的任务成功能少花 token」，不是「所有场景都更快」。推断（依据：§5.1 的 10 样本设定；§5.1 未给端到端延迟分解）。
§5.2 的反向验证很具体：只在代码/数学上训练的 code-agent 模型，能零样本调用没见过的 web 工具（先搜索、再用 Python 计算）；反过来，web-agent 模型虽然会在正确时机发起 Python executor / Visual inspector 调用，却常因格式细节（三反引号、完整 JSON 字段）解析失败。所谓“未见工具泛化”，取决于工具对格式的严格程度，不是普遍能力。推断（依据：§5.2 的反向验证只覆盖 web 与 code/math 两类工具，未测更多工具类型）。
推理时 AFM 最多 12 次 tool call（§4.2.1，原文指的是 code agent）；web agent 的 RL 预算是 24 steps / 32k tokens，code agent 8 次 tool call（§4.1 / §4.2）。更长的工具链会被预算截断。另外，web RL 的奖励是 Qwen2.5-72B 的二元判断（§3.3），§3.3 只描述二元 judge，未报告 judge 偏差或换 judge 的敏感性——对开放式答案，这层判定本身是一个未消融的变量。推断（依据：§3.3 只描述二元 judge，未给 judge 消融）。
一句话总结：CoA 把“多智能体怎么协作”内化成了一条可训练的 token 流，但没有把工具能力、世界知识或教师的盲区一起内化。如果任务需要无法用 role prompt 表达的外部工作流、教师 MAS 本身不可用、或工具链远超 12 次调用，这套蒸馏路线就不划算；如果奖励只能靠一个未校准的 LLM judge，RL 阶段也会把这个偏差放大。