TOUCAN: Synthesizing 1.5M Tool-Agentic Data from Real-World MCP Environments

1 · 背景:1.5M scale 在 tool-agentic 数据上意味着什么

1.1 已有方案的三角困局

过去一年内,围绕"怎么造出能教 LLM 调工具的数据"这件事,三条主流路线各自被卡在一个角落:

TOUCAN 在这张三角上的占位是: "用真实 MCP server 把规模一次堆到 1.5M,但放弃 RL,只做高质量 SFT distillation"。换句话说,它和 AWM/Agent-World 不是替代关系,而是把"现成多 teacher model + 真 MCP 联通"这一最廉价的合成形式做到极致。

1.2 为什么"真" MCP 比合成 schema 重要

论文反复强调一点(§1, §3): 过去的 tool-call SFT 数据集(ToolACE 等)用的是 schema 字符串而不是真的 server —— 也就是 LLM 看到 {"name":"get_weather", "params":...},然后 LLM 自己编一个 fake response。这意味着:

• tool error 不在分布里:真 MCP server 会返回 rate-limit / auth-fail / malformed-args,合成 schema 永远不会;
• tool chain 的语义依赖被压平:get_user(id) → get_orders(user.email) 这种"前一步的真输出决定下一步参数"在 schema 合成里就退化成 LLM 对 plausible-looking dict 的拟合;
• multi-turn 状态一致性丢失:同一 server 多次 call 之间的 stateful behavior 没有真的 backend 是无法演出的。

TOUCAN 的核心 commitment 就是 每条 trajectory 中的 tool response 都是 real MCP server 的真实回包(因此他们要在 onboarding 阶段筛掉所有需要第三方 credentials 的 server,把 ~2,800 减到 495)。这是和 #18 AWM 的最大哲学分歧:AWM 选择"用 SQLite + Python 当受控 backend"(可重置 / 可校验状态),TOUCAN 选择"就接到真 server 上,失败 trajectory 当噪声扔掉"。

1.5 · Motivation — 论文自报的"为什么旧数据集不够用"

这一节把论文 §1 / §2 / Table 1 里散落的 motivation 集中起来,用原文语言重述 — 这样后面读到结果时,可以反推每条数字到底回答了哪个 motivation。

1.5.1 论文自述的核心痛点 (摘自 abstract + §1)

"progress in the open-source community is constrained by the lack of high quality permissively licensed tool-agentic training data. Existing datasets are often limited in diversity, realism, and complexity, particularly regarding multi-tool and multi-turn interactions." — arXiv abstract

"While previous efforts have introduced datasets covering various tool-calling scenarios, they suffer from several limitations: restricted tool diversity, lack of authentic tool responses, focus on single-turn conversations between users and models, or insufficient scale, all of which constrain effective training of agentic capabilities." — §1 引言

1.5.2 论文 Table 1 对 4 个 baseline 数据集的逐条点名

论文 Table 1 直接把对手摆出来,用同一组属性逐列对比 — 这是 TOUCAN 的"立项依据"。下表把 Table 1 的关键发现重排,加入 TOUCAN 的对应解法:

1.5.3 三条具象痛点 — 为什么"schema 而非真 server"是问题

1. Tool error 不在 schema 数据的分布里: ToolACE / Nemotron 的 tool response 是 LLM 自己编的 plausible-looking JSON, 永远没有 rate-limit / auth-fail / malformed-args / timeout。但真 MCP server 在 25-40% 的调用里会返回这些 — Toucan trajectory 里这部分是"真的从 remote server 拿到错误,然后由 teacher LLM 学会优雅处理" → SFT 出来的模型才会有 error-handling 能力。
2. Tool chain 的语义依赖被压平: get_user(id) 的 真实输出决定 get_orders(user.email) 的参数 — 在 schema 数据里 LLM 看到的 user 是自己编的,所以下一步参数也是编的,整个 chain 是 plausible-looking 但 disconnected。Toucan 因为真接 server,这个依赖链是真的。
3. Multi-turn 状态一致性丢失: 同一 server 多次 call 之间的 stateful behavior(create_doc → edit_doc(doc_id) → list_docs 必须能看到刚才那条)在 simulated response 里无法演出 — 因为没有真 backend 维持状态。Toucan 的 35.2K Ext.3 multi-turn 数据里这种链条都是真的。

1.6 · Contributions — 论文显式列出的 3 件套

论文 §1 末尾的 "In summary, the contributions of our work are" 段落只列了 3 项 contribution(不是有些读者以为的 4-5 项 — 那是把 motivation/related-work 混进来的误判)。原文逐项:

1. TOUCAN Dataset — "The largest open-source tool-agent training dataset, covering parallel and multi-step tool calls, multi-turn dialogues, and edge-case tool use." 论文特别点名 Kimi-K2 / GLM-4.5 的 frontier 报告强调"large-scale trajectories with broad domain coverage"的价值 — TOUCAN 把这条做成开源对应物。
   • 1,527,259 trajectory · 495 真 MCP · 2,000+ tools · 567,262 multi-turn · 4 种 tool-call 场景 (S/P/MS/IR) 全覆盖
2. TOUCAN Pipeline — "A pipeline that leverages any MCP specifications to generate diverse tool-agent trajectories, supports tool execution through MCP servers, and can be seamlessly extended to new tools via the MCP standard."
   • 5 阶段(Onboarding → Synth → Filter → Trajectory → Post-filter) + 3 扩展(Irrelevance / Persona / Multi-Turn)
   • 关键设计: MCP standard 让 pipeline 对新 server "seamlessly extensible" — 不需要为每个新 tool 写 adapter
3. TOUCAN Checkpoints — "models fine-tuned on TOUCAN mixtures surpass closed-source counterparts on the BFCL V3 and MCP-Universe benchmarks."
   • 具象数字: Qwen2.5-32B + TOUCAN 在 BFCL V3 上 70.45% 险胜 GPT-4.5-Preview 70.32%
   • MCP-Universe 上 push Pareto frontier(具体落点见 §4.5)

2 · 数据合成 pipeline 全景

2.1 一图看完整条流水线

2.2 各阶段输入 → 输出

2.3 和 AWM / Agent-World 的并排对照

3 · 关键设计选择

3.1 Real-World MCP 来源 — 为什么是 495 而不是 2,800

onboarding 阶段的过滤非常严格(§3.1):

• 必须是 remote HTTP-accessible:本地需要 docker / npm 启动的 MCP server 一律不要 — 因为后面 trajectory 生成要并发跑几百个 worker,本地启动 server 不可扩展;
• 必须不需要第三方 credential:这条砍掉了 Gmail / Notion / Slack / GitHub auth 等大类(虽然真实,但跑不动);
• 必须 stability ≥ 阈值:被 Kimi-K2 在 stability 这维打低分的(connection 不稳 / 经常 timeout)在 task filter 后直接丢;
• 25 个 "featured" server 手动精选:覆盖 web search / file ops / data analysis / coding 等高频域,作为 quality anchor。

3.2 Task 多样性的三层保证

1. 5 个不同 LLM 出题(Mistral-Small, DevStral-Small, GPT-OSS, Kimi-K2, Qwen3-32B): 不同模型有不同的 prompt-following bias,多 model 出题降低了"全 dataset 都是 Kimi-K2 风"的风险;
2. 3 种采样策略并行(Single-Server / Multi-Server / Featured-Server): Single 训"用对工具", Multi 训"跨 server 组合", Featured 在 25 个精选 server 上深挖;
3. 6 维 Likert 评分(difficulty / uniqueness / quality / realism / verifiable / stability)— uniqueness 这一维专门为反 mode-collapse 设计,把"和池子里已有 task 太像"的 query 主动剔出。

3.3 验证器: 两层硬过滤

3.4 失败 trajectory 是否回流?

不回流。 不同于 AWM 在 GRPO 里把 V=0 的失败 trajectory 当负样本利用,TOUCAN 是纯 SFT distillation,失败 trajectory 直接扔掉(rule 层就过滤了)。这也是为什么它需要 1.5M raw → 119K SFT 这么夸张的"上 12.5× 数据冗余,只取 8% 入训"的设计 — 因为没有 RL 的负样本机制,质量只能靠多倒少进的过筛保证。

3.5 三个 Extension 机制 — 教 SFT 模型 "更难的事"

注意 Ext.1 的设计很巧妙:不需要再生成新 trajectory,只要把已有 trajectory 的 server metadata 和 query 错配,就自动得到"query 想做的事 server 做不到"的训练样本 — 教 SFT 模型该说 "我做不到" 而不是硬调一个无关工具。这条对修 BFCL V3 里"relevance / irrelevance" 子项尤其有用。

3.5 · 训练数据详细解构 — 119K SFT subset 的内部组成

这一节是本笔记最关心的一节。前面 §2 / §3 讲的是 1.5M raw trajectory 的来源,但真正训进 Qwen2.5 的是从 1.5M 里筛出的 119,287 条 SFT subset(精确数字来自 HF dataset card)。下面拆开这 119K 是怎么来的、按哪些维度切分。

3.5.1 HF dataset 上的 4 个公开 subset

打开 datasets.load_dataset("Agent-Ark/Toucan-1.5M") 你会看到 4 个 config — 这是 trajectory 在 teacher model 维度上的原始切分:

3.5.2 119K SFT subset 在 pipeline 维度上的拆分

论文 §4.1 末尾给出 119.3K = 28.3K + 40K + 15.8K + 35.2K 的明确拆分:

注意 40K Irrelevance + 35.2K Multi-Turn = 63% 的 SFT 数据来自扩展机制而非原始 pipeline。也就是说 — 论文真正认为有训练价值的是edge case(无解 / 多轮)而不是 vanilla tool-call(那部分 baseline Qwen2.5 已经会了)。这条解释了为什么消融里 Ext.1 (Irrelevance) 对 BFCL V3 Irrelevance 子项贡献 +30+ pp(见 §4.4)。

3.5.3 论文 §3.1 Stage 2 列出的 3 种 task 合成策略

原始 28.3K(以及其它扩展的种子)是由 5 个 LLM × 3 个采样策略产出的。三种策略对应不同能力难度梯度:

"Featured Server" 这 25 个手选的是哪些?论文 Appendix B.1 / Table 4 给出全表 — 涵盖 OKX (crypto)、Semantic Scholar (research)、PubMed、Flux ImageGen、Hotel Booking、Cloudflare Playwright (browser)、Exa Search、ClinicalTrials、LeetCode、Code Runner、Context7、Airbnb 等。设计意图: 跨域覆盖 + 每域至少 1 个深度 server 作为多 server 组合的可靠 anchor。

3.5.4 servers 域分布 — 495 个 MCP 都在干什么

论文 Figure 3 给了 495 server 按 LLM-annotated 域的分布(降序):

3.5.5 trajectory 复杂度统计(来自论文 Figure 4 + HF dataset card)

论文 Figure 4 的 8 张子图给出 trajectory 形态分布。本笔记把 HF dataset card 文字描述加上 figure 反推的近似值整理如下:

未在公开来源确认: 论文未给出"avg turns / avg tool calls / avg tokens per trajectory"的具体数字 — 只在 Figure 4 用 histogram 展示分布。如果你需要精确均值需要自己跑 HF SFT subset 的 messages 字段统计。

3.5.6 数据格式 (HF schema)

3 个 teacher subset (Kimi-K2 / OSS / Qwen3) 多 4 个字段:available_tools / question_quality_assessment / response_quality_assessment / metadata — 这些是给做 dataset analysis 的研究者用的,SFT 训练用不到。

4 · 训练 recipe + 评测全套

4.1 训练配置 — 全套 hyperparams

论文 Appendix C.2 / Table 5 给出全部 SFT hyperparam — 可直接复现不留白:

4.2 评测 benchmark 全景 — 4 个套件覆盖什么

论文用 4 个 benchmark(没有 ToolACE-eval / Nexus / 内部 eval — 全部都是社区标准):

4.3 BFCL V3 — 全 5 子项 breakdown(Table 2 全数据)

下表是论文 Table 2 的完整数据。BFCL V3 把 "function-calling" 拆成 5 个子项:Non-live AST(传统单步)/ Live AST(社区贡献的真实场景单步)/ Multi-Turn(2024-09 新增的多轮)/ Relevance(该调时调对)/ Irrelevance(不该调时拒答)。

关键观察:

1. 32B + TOUCAN 在 Multi-Turn 单项 46.50 反而超过了 GPT-4.5-Preview 的 45.38 — 这是论文里我认为最被低估的数字:在最难的 BFCL V3 子项上击败 1T 参数闭源模型。
2. Non-live AST: 7B 反退步(84.19 → 78.52,-5.67)— 这是 SFT 在小模型上典型的"形式过拟合 trade-off": 学会了真 MCP 调用风格,反而丢了 BFCL 简单格式的 prior。14B/32B 上这个问题消失。
3. Relevance 子项 7B 倒退 (72.22→66.67) — 同上,小模型容量不足以同时记住"该拒答"和"该调用"两种行为。
4. Irrelevance 全线大涨(7B: +7.25 / 14B: +7.50 / 32B: +5.42) — Ext.1 的 40K irrelevance 数据精准命中,这是论文消融 Table 6 上 Irrelevance 子项从 baseline 68.46 → 77.85 (+9.39) 的直接因果证据。
5. 胜负毛细看: 32B + TOUCAN 在 Overall 上 70.45 vs GPT-4.5 70.32 = +0.13 pp。同时 Multi-Turn 上 46.50 vs 45.38 = +1.12 pp。论文卖点是 "32B SFT 超过 1T 参数闭源",但 GPT-4.1 (68.69) 已经接近,Qwen3-32B (无 TOUCAN, 69.25) 也很接近 — TOUCAN 增益从 61.73 → 70.45 是真实的,但相对赛道的 ceiling 没有跳跃。

4.4 BFCL V3 Ablation — 4 extension 的逐项贡献(Table 6)

论文 Appendix C.3 / Table 6 在 14B 模型上做了 ablation,逐步加 4 类 SFT 数据看 BFCL V3 各子项变化:

消融最关键发现 — Ext.1 是单独最大贡献者:

• 只加 Single-Turn 反而炸 Irrelevance(68.46 → 46.88,-21.58 pp)— 因为 28.3K 全是"该调工具"的数据,SFT 后模型变得 over-eager,什么都想调 → irrelevant 子项崩;
• 加 Ext.1 (Irrelevance) 一举修复: 46.88 → 77.85 (+30.97 pp),不仅修复 baseline,还超过 baseline 9.4 pp;
• Ext.2 (Diversify) 在 BFCL V3 上几乎没贡献(Overall 64.74 → 64.56,反而 -0.18)— 这是论文里没明说的"Ext.2 在 BFCL V3 上 noop"。Ext.2 的实际收益体现在 τ-Bench / τ²-Bench(language style 多样性);
• Ext.3 (Multi-Turn) 在 Multi-Turn 子项稳贡献(32.50 → 35.25,+2.75 pp),这是预期内的 — 教会模型 multi-turn state 保持。

4.5 τ-Bench / τ²-Bench — 全 4 域 breakdown(Table 3 全数据)

这是这次精读补完最有意思的一块 — 此前笔记只给了 Avg,现在拆出 airline / retail / telecom 三域:

关键观察:

• Telecom 域是软肋:7B 上 TOUCAN 反而把 telecom 从 16.70 砍到 10.50 (-6.20 pp);14B/32B 上 telecom 几乎完全 noop(20.18 → 20.18 / 21.11 → 20.20)。原因可能: 495 个 MCP server 里 Communication Tools 类只有 7 个(§3.5.4 域分布),trajectory 训不到 telecom-specific 多轮对话 policy。
• Retail / Airline 涨幅显著:Retail 在所有 size 上 + 4 ~ 8 pp。原因: TOUCAN 里 web search / dev tools / data analysis 类对应到 retail 操作(查商品 / 改订单)有大量 transfer。
• τ²-Bench 涨幅整体小于 τ-Bench:7B 上 τ² 只涨 +1.69 vs τ 涨 +7.45 — 因为 τ²-Bench 加了更难的 user policy,SFT 学的是 tool-call 形式,policy 推理还需要 RL。这条解释了为什么作者在论文 §5 future work 里明确提到要做 "reinforcement learning gym"。

4.6 MCP-Universe — Pareto 但无绝对数

论文 Figure 7 + Figure 8 用 bar chart + Pareto 散点展示。没有列绝对数字表,所以本笔记给出从 Figure 反推的可读数:

具体子域 (Location Navigation / Repository Mgmt / Financial Analysis / 3D Designing / Browser Automation / Web Searching):TOUCAN-tuned 在 Web Searching / Repository Mgmt / Browser Automation 上对同 size baseline 优势最明显;在 3D Designing / Financial Analysis 上 TOUCAN-tuned 没明显优势 — 和 §3.5.4 servers 域分布偏置一致(crypto/finance/3D 类 server 数量少)。

5 · 🔍 开源现状 — repo 实地清点

这是这篇 paper 最让人惊喜的部分 — 几乎所有中间产物都开源了,而且 license 干净。逐项清点:

5.1 和 #18 AWM / #03 Agent-World / #20 SETA 的开源度横向

结论: TOUCAN 的开源完整度和 AWM 是当前 agentic data 这一线最高的两家,显著高于 Agent-World(paper-only)。SETA 因为是 RLVR-Docker 路线,可比性稍弱但也接近全开。

5.2 License 分析 — 这套栈能直接商用吗?

结论 — 全栈商业 friendly: 数据 (Apache-2.0) + 代码 (MIT) + 权重 (跟 Qwen2.5 = Apache-2.0)。无 CC-BY-NC 传染、无 Llama license 前缀、无 OpenAI 输出条款风险(因为 5 个 task-synth model 都是开源 LLM,不是 GPT 系列)。这是 2026 上半年极少数能同时满足"数据 + 模型 + 训练栈"三层全 Apache/MIT 的 tool-agentic 训练资源 — 详细对比可参考 #31 Prime Intellect Hub §License 的"安全栈推荐" 章节。

5.3 复现 checklist — 你需要什么 / 可以跳过什么

5.4 27 个 HF ckpt 实地清点 — 官方 3 个 + 社区 24 个

截至本笔记写作时(2026-05),HF 上 Agent-Ark org + 全网搜索 "Toucan-Qwen" 共可见 27 个 fine-tune 衍生 ckpt:

5.5 datagen 目录 → 论文 Stage 映射

GitHub repo TheAgentArk/Toucan/datagen/ 是 pipeline 复现的入口。子目录到论文 Stage 的映射:

5.6 自托管 / 复现一句话总结

• 只想用数据 SFT 自己的模型: datasets.load_dataset("Agent-Ark/Toucan-1.5M", "SFT") 就能拿到 119K 高质量 SFT subset(parquet 格式,messages 已是 chat-format);
• 想跑 inference 比 baseline: 三档 ckpt 直接从 HF 拉,GGUF 量化版可在 4090 上跑 32B q4;
• 想从头重跑 pipeline: 需要(1)各 teacher model 的 API 密钥 或 部署(GPT-OSS-120B / Kimi-K2 / Qwen3-32B 都有公开 endpoint);(2)能联通 495 个 remote MCP server 的网络环境 — Smithery 上挂了 hosted version;(3)算力堆 1.5M trajectory 的生成 — 论文没给具体小时数,但根据 #03 / #18 / #19 经验估计是 数千 GPU·小时 + 五位数 USD API 费用。

6 · 与同类工作的横向矩阵

定位: TOUCAN 占据 "真 env + 超大 SFT 规模 + 全开源" 这个空格 — 这恰好是上面其它工作都没占的位置(AWM 真 env 假但全开,Agent-World 真 env 但不开,Nemotron/ToolACE 假 env 大规模但弱真实)。

7 · 局限 / 个人 take

7.1 "1.5M scale" 是 marketing number 吗?

部分是。 1,527,259 是所有 teacher model × framework 组合 raw 产出的总量,真正进入 SFT 的只有 119,300(约 8%)。HF 上的 4 个 subset 是按 teacher 切分的(Kimi-K2 519K / OSS 457K / Qwen3 552K / SFT 119K) — 三个 teacher subset 之间有相当大的重叠(同一 query 被 3 个 teacher 各跑一遍)。真正 SFT 上有效的"unique high-quality trajectory"是 119K 这个量级,这才是与 Nemotron 310K / ToolACE 26K 公平对比的数。所以 IBM blog 上的 "5× Nemotron" 说法实质上是 1.5M raw vs 310K 全量的对比,不完全公平 — 但 119K SFT 的质量密度确实高(每条都过双层过滤)。

7.2 "real-world MCP" 真的"真"吗?

真,但是"窄"。 495 个 server 都是 public + no-auth + HTTP-only + stable 的 — 也就是多半是 mock-data 或 read-only public API 性质(public weather, public dataset query, file conversion utility 等),并不是生产中带 stateful database 的 Notion/Linear/Gmail 类。所以 "真实度" 比合成 SQLite 高,但比 SETA 在 Docker 里跑真 git+linux command 要低一档。可以把它定位成 "中等真实度,极大规模"。

7.3 训出来的模型公开榜上能查到吗?

可以,但需要小心 selection bias:

• BFCL V3 上 32B = 70.45 这个数字在 BFCL 的 v3 leaderboard 上是 Berkeley 维护的,可以查到(论文有截图);
• τ-Bench / τ²-Bench 的对比数都是论文自己跑的(用 BFCL 提供的 evaluation harness),没有第三方独立复测;
• MCP-Universe 上只有 Pareto 图,没有绝对数 — 想看具体落点需要去 MCP-Universe 自己的 leaderboard(目前 Toucan-32B 在 25-30% 区间);
• 没有任何 frontier 厂商的 model card 直接引用过 Toucan(对比 #19 MCP-Atlas 被 Claude Opus 4.7 system card 引 77.3% 这种待遇)。

7.4 论文没回答的几个问题

7.5 校订风险条 — BFCL V3 vs V4 的不可直接对比性

7.5 一句话评价

TOUCAN 不是一篇方法创新型的 paper — 它的所有技术(多 teacher distill / Likert filter / rule+LLM 双过滤 / persona inject / multi-turn 切分)都不新。但它是"把已有方法做到工业流水线规模,并 100% 全开源"这件事的当前 ceiling。如果你想 SFT 自己的 7B-32B 模型让它会调 MCP,直接拉 HF 上的 SFT subset 跑 2 epoch 是 2026 上半年最理性的起点。

附:阅读路径建议

这篇笔记之前已读过 → 推荐 follow-up:

1. 如果你已读 #18 AWM: TOUCAN 是 AWM 的"真 env 大规模 SFT 版" — 两者是互补的(AWM 选 RL+合成,TOUCAN 选 SFT+真);
2. 如果你已读 #03 Agent-World: TOUCAN 把 Agent-World 没做的"把 1.9K env 真的转成可训 SFT 数据并公开"这步补上了 — 虽然 server 数 (495) 不如 Agent-World (1,978),但 trajectory 是真公开的;
3. 如果你已读 #20 SETA: TOUCAN 的 SFT vs SETA 的 RLVR 形成方法学正交 — 同样追求"真 tool"但一个走规模化 distill,一个走小规模 RL;
4. 读完 TOUCAN 后,有兴趣可以追 #21 看 MCP-Universe 这条评测线 — TOUCAN-32B 大概落在哪里。