NeurIPS 2026 | 从「先出题」到「先探索」：重新思考工具调用代理的数据合成

在训练 Tool-Calling Agent 的过程中，我们反复遇到一个看似简单、却非常关键的问题：训练数据从哪里来？ Tool-Calling Agent 需要根据用户意图调用外部 API、整合中间结果，并最终给出答案。要通过 Reinforcement Learning 训练这样的 Agent，我们需要大量任务，每个任务都应当带有正确的中间 tool calls 和可以被验证的最终答案。即使是数据效率较高的 RL 方案，也往往需要数千个这样的任务；而目前主流的 agent benchmark，每个通常只提供几十到几百个任务。 一个自然的想法是让 LLM 来合成任务。但很快我们就会遇到下一个问题：一个由 LLM 想象出来的任务，它的 ground truth 真的正确吗？更进一步，如果这些任务依赖真实世界的 API，而 API 的返回结果随时可能变化，我们又该如何在训练中反复复现同一个环境？ 我们逐渐意识到，问题的关键可能并不在于 “如何生成更好的任务”，而在于生成任务的顺序本身。 换句话说，我们认为： 与其先出题、再寻找答案，不如先在真实 API 上探索，再根据已经观察到的结果反向出题 。 在我们的 NeurIPS 2026 工作 Firefly: Illuminating Large-Scale Verified Tool-Call Data Generation from Real APIs 中，我们沿着这一思路，构建了一个从真实 MCP Server 生成可验证 tool-call 数据的 pipeline，并配套了一个可离线复现的 Retrieval-Augmented Tool-Call Simulator。基于这一 pipeline，我们得到了覆盖 240 个 server、993 个工具的 5,144 个可验证任务。我们希望，这项工作不仅能够提供一份可用的训练数据，也能为 “如何大规模构造可验证的 Agent 训练数据” 这一问题提供一个新的思路。 论文地址：https://arxiv.org/abs/2605.17558 代码与数据：https://github.com/leoleoasd/firefly-neurips-2026 会场时间：Thu, Dec 10, 2026・10:00 AM EST in Hall C1・Atlanta Poster Session 3 01 ｜ 规模、真实与可验证：现有训练数据的三重困境 目前，构造 Tool-Calling 训练数据的方式大致可以分为三类：人工标注、纯模拟环境下的合成，以及基于真实工具的前向合成。在实际工作中，我们发现这三类方法各有所长，但都很难同时做到规模化、真实性和可验证性。 图 1：可规模化、真实、可验证，现有三类方法各缺一角。 1.1 ｜ 人工标注：足够可靠，却难以规模化 人工标注能够保证用户意图的自然性和答案的正确性，Tau-Bench 系列、API-Bank 等工作都采用了这一方式。但人工标注成本高、领域依赖强，很难覆盖真实 API 的长尾。以 Tau2-Bench 为例，每个领域仅有 50 到 115 个任务；MCPMark 提供 127 个任务，MCP-Atlas 公开了 500 个任务。这些数量适合评估，却远不足以支撑 RL 训练。 人工构造可验证任务的价格也不低。根据 Epoch AI 对行业的访谈，AI 实验室购买一个 RL 任务通常要花 200 到 2,000 美元，独家授权的价格还要再高 4 到 5 倍。这样的价格和独家条款，使这类数据主要集中在少数大厂手中。 1.2 ｜ 纯模拟环境：足够可扩展，却偏离真实 API 为了突破规模限制，一类工作让 LLM 同时扮演 “用户” 和 “工具”：工具的返回结果同样由 LLM 生成。这样的环境易于扩展，但 LLM 编造的工具输出往往与真实 API 的行为存在差异。真实世界中的字段格式、边界情况、报错方式乃至数据本身，都很难被准确模拟。在这样的环境中训练出的 Agent，学到的可能是 “如何与模拟器交互”，而不是 “如何与真实世界交互”。 1.3 ｜ 前向合成：足够真实，却缺乏可验证的 ground truth 另一类工作使用真实工具，采用我们称之为 Forward Generation 的流程：先把所有工具的描述交给 LLM，由它写出一个需要调用这些工具的用户任务；再由另一个 solver 模型针对这个任务 rollout 出一条 tool-call 轨迹，solver 的最终答案就被当作该任务的 ground truth。考虑下面这个简单的例子： Which domain was registered first, amazon.com or netflix.com, and how many years apart were they registered? 在 Forward Generation 中，这个问题是先被写出来的，出题的 LLM 并不知道工具实际会返回什么。由此带来两种失败。第一，任务本身可能无法完成：它要求的最终状态在真实工具上根本不可达。第二，solver 可能做错，比如查错了域名或者算错了年份差，而它的答案会被原样当作 ground truth。换句话说，这类任务的 ground truth 没有任何机制保证它是对的。 图 2：Forward Generation 的流程，以及它的两种失败方式。 1.4 ｜ Environment Drift：即使有了可验证的任务，也难以训练 更进一步，即便我们已经拥有了基于真实工具、并且可以验证的任务，直接在 live API 上做 RL 训练仍然非常困难。许多 MCP 工具依赖搜索索引、天气、金融数据、DNS 记录等外部数据源，它们的输出会随时间变化；server 可能下线；RL rollout 中的大量重复调用也可能触发 rate limit。结果是，同一个任务在今天和下周可能得到不同的工具返回，训练和评估都难以复现。 图 3：直接在 live server 上做 RL 的三个问题。 因此，构造 可规模化、真实、可验证 的训练任务，并配套一个在 RL 过程中保持可复现的环境，仍然是一个开放问题。这使我们开始思考：是否存在一种方式，让 ground truth 的正确性不再依赖事后过滤，而是在数据生成的那一刻就被保证？ 02 ｜ 反转合成流程：让 ground truth 的正确性成为一种构造性质 我们的核心观察是：Forward Generation 之所以难以保证 ground truth 正确，很大程度上是因为 “出题” 发生在 “观察” 之前。如果把顺序颠倒过来，问题可能会变得简单得多。 2.1 ｜ Back-Chaining：先探索，再出题 回到上面的域名例子。在 Firefly 中，这个任务并不是先被写出来的。恰恰相反，一个强 LLM 首先在真实的 MCP Server 上进行探索，它调用了 networkcalc-mcp 中的 whois 查询工具，分别查询了 amazon.com 和 netflix.com，并实际观察到了它们的注册年份：1994 和 1997。只有在这之