Tool-Use Agent 如何扩训练数据：拆解工具、任务与环境状态的 Scaling Law

训练 Tool-Use Agent 需要大量包含工具调用和状态变化的交互数据，但这类轨迹在互联网语料中并不常见，因此近年的一个主要方向是用 LLM 合成训练数据。

当数据规模继续扩大，问题也从“生成多少”进入“预算怎么分”：增加应用和 API，在已有工具集上生成更多任务，还是让同一道任务对应更多初始数据库状态和干扰数据？已有工作在扩展数据时往往同时改变这些因素，很难单独测量它们对下游表现的影响。

Apple 团队在论文 Scaling Laws for Tool-Use Agents via Controllable Environment Synthesis 中提出 SynthAPI，将这些因素拆成可控制变量。论文共生成 458,752 个任务，覆盖 64 个应用和 10,472 个 API，并围绕不同数据组成训练 849 个 Qwen3.5 2B、4B、9B 和 27B 模型，再据此拟合数据组成 Scaling Law。

把工具环境做成可控实验

SynthAPI 先生成 Agent 可以实际操作的应用，再在这些应用中生成训练任务。研究团队预先定义购物、音乐、效率、金融、健身、消息、工具和社交 8 类应用，由关闭联网能力的 Gemini 3.1 Pro 生成每个应用的名称、功能描述和功能列表。

随后，模型根据这些信息生成 db.py，使用 Python Enum 和 dataclass 定义应用所需的数据结构；再生成 apis.py，其中包含实际读取或修改数据库对象的 Python API。公开函数最终成为 Agent 可以调用的工具。

所有数据库访问都通过 create、read、update、delete 四种底层操作完成，并记录对应的变更日志。Agent 调用写 API 后产生的状态变化可以直接保存和检查，后续操作继续基于更新后的数据库执行。

最终生成的 64 个应用共包含 10,472 个 API，其中 6,266 个写 API、4,206 个读 API。SynthAPI 没有把全部 API 定义一次性放入上下文，而是提供四个固定的元工具：

• list_apps()：查看可用应用；

• list_tools(app)：查看应用中的工具；

• get_tool_documentation(app, tool)：按需读取工具说明；

• complete_task(answer=None)：结束任务并进入验证。

这种按需发现方式可以减少工具定义占用的上下文，并为训练环境和下游评测中的不同工具集合提供统一的交互接口。

有了应用，下一步还要检查 LLM 生成的任务是否真的可以执行。SynthAPI 将一条任务定义为：T = (x, v, Db⁰, π*)，其中：

• x：目标明确的任务指令；

• v：验证器，根据数据库状态判断任务是否完成；

• Db⁰：任务开始时的数据库状态；

• π*：特权解算器，用于检查当前任务是否存在可行执行路径。

数据库先生成完成任务所需的核心数据，再加入额外干扰数据。特权解算器在任务生成阶段可以读取完整数据库中的信息，例如直接获得对象 ID，但执行任务时仍使用与 Agent 相同的公开 API。

生成后的任务还要满足两个条件：v(Db⁰) = 0，任务开始时不能已经完成；以及：v(Exec(π*, Db⁰)) = 1，特权解算器执行后必须通过验证器。

这两项检查用于过滤初始状态已经满足目标，或者当前环境中无法完成的任务。最终留下的数据同时具有明确的初始状态、可执行过程和程序化成功条件。

图 1：SynthAPI 整体流程。左侧展示 Agent 在多步工具环境中完成任务的过程；中间是 SynthAPI 对工具、任务和初始数据库状态的可控合成；右侧展示这些数据组成变量如何进一步用于建立扩展定律。

把训练数据拆成四个变量

建立可执行环境后，论文把数据组成拆成四个可独立调整的变量：

• A：应用数量，控制工具集合的多样性；

• T：每个应用的任务数量，控制同一工具集合上的任务多样性；

• S：每条任务对应的初始数据库数量，控制相同目标对应多少种环境状态；

• D：数据库的数据深度，一批是完成任务需要的核心数据，其余 D−1 批为额外干扰数据。

训练实例总量为：N = A × T × S。D 改变单个环境中的数据复杂度，不改变训练任务数量。这样就可以在 N 不变时比较不同的数据分配方式：增加应用数量、增加已有应用中的任务，或者让同一道任务对应更多数据库状态。

论文随后围绕这些变量逐项做控制实验。主要扩展分析使用 AppWorld 和 SynthAPI-Holdout 组成的诊断评测集，仅这部分完整评测就执行了约 180 万个评测回合。

图 2：Qwen3.5-9B 上的三组数据组成实验。图 a 比较固定任务预算下应用数量 A 与单应用任务数 T 的分配；图 b 改变同一任务对应的初始数据库数量 S；图 c 改变数据库中的数据深度 D。横轴均为训练任务总量，纵轴为归一化诊断得分。

固定预算逐项测试

第一组实验只调整 A 和 T，并固定 S=1、D=2。每一种数据组成都单独训练一个模型。以 Qwen3.5-9B 为例，总任务数为 64～512 时，A=8 的配置表现最好；随着任务预算扩大，更多应用开始占优，从 4096 个任务开始，A=64 已明显优于更少应用的设置。2B、4B 和 27B 模型也观察到了相同趋势。

论文推测，小数据预算时，把更多任务集中在较少的工具和数据结构中，可能更容易取得早期收益；随着任务数量增加，扩大工具覆盖范围开始更有利。实验直接显示，高预算下更大的应用多样性开始占优；对于这一变化产生的原因，论文目前给出的是解释和假设。

论文还检查了单个应用的工具是否已经被任务覆盖完。即使每个应用生成了 1024 个任务，这些任务实际使用到的工具比例中位数仍只有 51%。因此，趋势变化不能简单归因于单个应用中的工具已经被任务穷尽。

附录中，论文又在 SimSAT 数据上重复检查 A 和 T 的关系：N=128、256、512 时，A=32 通常不如 A=8 或 A=16；到 N=1024 时，A=32 又超过 A=16。这个实验复现了“任务预算增加后，更高应用多样性开始占优”的局部趋势，但没有重新验证完整扩展定律。

接下来，论文调整 S。此时任务指令、验证器和特权解算器保持不变，只重新生成初始数据库。Agent 解决的目标相同，每次面对的环境状态不同。论文报告，32～512 个训练实例时 S=1 最好；512～4096 区间 S=2 最好；超过 4096 后，测试范围内 S=4 最好。

论文将这一结果归因于 Agent 需要学习在不同初始数据库状态中完成相同任务。在当前实验设置下，较高预算时，为已有任务增加数据库状态，比继续增加新的任务指令获得了更好的下游表现。

第三组实验调整 D。D=1 时，数据库只包含完成任务需要的最小状态；D=2 和 D=4 会加入更多额外干扰数据。高任务预算下，D=4 获得了更高的下游得分。论文同时保留了一个限制：当前评测基准对复杂数据库状态中的检索和决策可能还不够敏感。如果评测更强调高密度状态检索，D 可能呈现不同的扩展规律。因此，D=4 的优势目前只在这套实验和评测设置下成立。论文没有证明环境越复杂越好，也没有定位具体是哪类检索或决策能力从中受益。

从控制实验拟合扩展定律

完成 A/T、S、D 三组实验后，研究团队把这些变量放进同一个经验模型。论文共训练了 849 个 Qwen3.5 2B、4B、9B 和 27B 模型，用于覆盖不同的数据配置。

SynthAPI 的任务带有二元验证器，可以支持基于可验证奖励的强化学习。但数百种配置逐项运行强化学习的计算成本较高，因此论文中的扩展实验主要采用监督微调。研究团队使用 GLM-5.2 生成成功轨迹。每条任务最多尝试 4 次，只保留第一条通过验证器的轨迹；4 次全部失败则丢弃。最终数据约包含 5.9B Token，其中约 721M Token 是实际计算训练损失的 Agent 推理和动作输出。

根据前面的控制实验，论文构造了数据组成相关的经验扩展定律：P̂¹ₘ(A,T,S,D) = σ(c₀ + cₐlog₂(A·S·D)) · σ(b₀ + bₜlog₂T)ᵛ

其中，A、S、D 通过乘积 A·S·D 进入数据组成相关的性能上限项，T 进入任务扩展项，用来描述增加单应用任务数时接近该上限的过程。参数针对不同模型尺寸分别从实验数据中拟合。

这个公式来自前面的控制实验观察和后续经验拟合，不是从理论上推导出的通用定律。为了检查外推能力，作者把训练计算量最高的 25% 实验全部留出，只使用其余数据拟合参数。留出实验最高达到拟合区间最大训练计算量的约 16 倍。

在这些高计算量实验中，考虑数据组成的扩展定律对归一化诊断得分的平均绝对误差为 0.0285；只使用总任务数量 N 的基线模型为 0.1706。论文同时指出，将数量基线从任务数换成 Token 数或训练计算量后，结论不变。这里的 0.0285 表示归一化诊断得分的平均绝对预测误差，不能理解为 Agent 成功率预测误差 2.85%。

这组实验说明，在 SynthAPI 的实验设置中，仅用任务数、Token 或训练计算量描述数据规模，会遗漏数据组成带来的差异；将工具数量、环境状态和数据复杂度纳入模型后，对高预算实验的下游表现拟合得更准确。

图 3：数据组成扩展定律及其向更高训练计算量的外推。实心点为参与拟合的实验，空心点为留出的高计算量实验；虚线区域表示外推范围。论文在四种模型尺寸上留出训练 FLOPs 最高的 25% 实验，最高测试到拟合区间之外约 16 倍的训练计算量。

验证数据配方

建立扩展定律后，论文又构造了两组任务数量完全相同的数据，检查前面的分析能否用于选择训练数据组成。两组数据都包含 32,768 个训练任务：

SubOpt 主要在已有应用中增加更多任务；Opt 根据前面的扩展分析，减少每个应用的任务数量，把更多预算分给应用多样性、初始数据库状态和数据复杂度。

在下表中报告的 4B、9B 和 27B 模型以及 AppWorld、ASTRA-Bench、BFCL、SynthAPI-Holdout 四组评测中，SynthAPI-Opt 的结果均高于 SynthAPI-SubOpt。以 AppWorld Test-C 为例：

• 4B：38.4% → 45.0%

• 9B：53.0% → 56.2%

• 27B：73.8% → 74.1%

SynthAPI-Holdout 上，4B 从 51.3% 提高到 56.0%，9B 从 56.0% 提高到 63.0%。

图 4：不同训练数据配置在 AppWorld、ASTRA-Bench、BFCL 和 SynthAPI-Holdout 上的原始成功率。重点比较 SynthAPI-SubOpt 与 SynthAPI-Opt：两者任务预算相同，但 Opt 覆盖更多应用、更多初始数据库状态，并采用更高的数据深度。

整套实验依次完成：生成可控环境 → 固定预算拆分数据变量 → 分别训练模型 → 拟合扩展定律 → 在相同任务预算下重新配置数据并验证。

论文随后继续扩大 SynthAPI 数据集，并在 AppWorld、BFCL 和 ASTRA-Bench 上与已有方法比较。这部分结果用于检查 SynthAPI 数据训练出的模型能否泛化到外部 Tool-Use 评测。

不过，各基线方法的数据规模和训练方式并不完全一致。例如部分方法使用较小数据集上的监督微调 + 强化学习，而 SynthAPI-Big 使用规模更大的监督微调数据。因此，这些结果不能直接用于比较不同数据生成方法的数据效率，也不能单独隔离 SynthAPI 合成方法本身的效果。

这条规律验证到了哪里？

完整扩展定律目前只在 SynthAPI 这一条数据生成流水线上建立。SimSAT 只重复验证了 A/T 随任务预算变化的局部趋势，没有重新验证 S、D 和完整的联合 Scaling Law。

SynthAPI 的任务目标明确，不覆盖需要 Agent 在执行过程中向用户追问的用户在环场景；对长邮件链、长笔记等具有真实语义深度的数据覆盖也有限。849 个扩展实验采用专家成功轨迹的监督微调，论文没有验证相同规律在强化学习后训练中是否继续成立。

此外，SynthAPI 的训练任务只使用单个应用内的工具，全部实验也运行在研究用模拟环境中。论文中的 API、任务、数据集和训练流程不代表 Apple 已部署的产品或生产系统。

因此，这篇论文目前建立的是一套面向有状态 Tool-Use Agent 的可控实验方法：分别测量工具、任务和数据库状态随训练规模变化的影响，并据此拟合经验 Scaling Law。其核心结果是，训练数据规模不能只用任务数量描述，数据组成同样会影响下游表现的扩展规律。