丢掉沙箱，让LLM当世界模型：ESAT如何用API说明书训出能打的调用智能体
你有没有遇到过这种场景：想给一个开源Agent项目接入新业务API，先别急着想调优，第一步是啥？搭一个能跑通的沙箱环境。要把"转账API"训明白，你得真有一套账户系统、流水表、风控服务，再往里塞几个能查能改的测试账号。光把数据造出来就够喝一壶了。
这就是Apple这篇论文想正面刚的问题——Environment-free Synthetic Data Generation for API-Calling Agents（arXiv:2607.16900）。它的核心主张很激进：训练API调用智能体，根本不需要真的把环境搭起来。 只给一份API规格说明书，让LLM自己"脑补"出整个世界的反馈，照样能把Agent训到能打。
读完之后我的第一反应是——这个想法不算新，但把"无环境模拟"做到这种工程化程度，并且真在AppWorld/OfficeBench上跑出大幅提升，确实有点东西。看完细节你会发现它有几个反直觉的地方，包括：纯合成数据训出来的模型，在AppWorld上能打过用真环境数据训出来的模型。
📌 核心摘要
- 痛点：现有API调用智能体训练方法严重依赖真实可执行环境和后端数据库，给新API做数据生成时基础设施和"造数"双重卡脖子。
- 方案：ESAT（Environment-Free Synthetic Agentic Trajectory）三阶段流水线——任务合成（Task Synthesis）→ 轨迹合成（Trajectory Synthesis）→ 轨迹过滤（Trajectory Filtering），全程零真实API执行。
- 关键效果：在AppWorld上，Qwen3.5-9B训后Test-N提升50.5个点（25.2→75.7），Test-C提升50.3个点（15.4→65.7），超过用真AppWorld环境数据训出的AWT baseline；在OfficeBench上Qwen3.5-2B涨60.5个点（9.1→69.6）。
- 我的判断：这是一篇"工程系统化程度很高"的论文，单个idea（LLM当模拟器）业界早有人在做，但ESAT把任务生成、轨迹合成、过滤判别全链路串起来，并且用数据本身证明了stateful simulator的必要性（拿来打Nemotron/ToolACE/ToolAlpaca）。值得做Agent训练基础设施的人细读。
📖 论文信息
- 标题：Environment-free Synthetic Data Generation for API-Calling Agents
- 作者：Seanie Lee, Sanjoy Chowdhury, Chao Jiang, Cheng-Yu Hsieh, Ting-Yao Hu, Alexander T Toshev, Oncel Tuzel, Raviteja Vemulapalli
- 机构：Apple
- 链接：arXiv:2607.16900
- 提交日期：2026-07-18
🤔 为什么要"无环境"生成数据？
先说个背景：过去一年，合成数据做Agent训练的工作井喷（ToolLLM、APIGen、AgentTuning等），但这些方法有个共同假设——要有一个能跑通的环境。要么调用真实API，要么搭一个完整的sandbox。
问题在哪？两个：
第一，基础设施成本。一个新业务域，意味着新数据库、新后端服务、新鉴权系统。哪怕只是想给Agent加5个新API，工程量也够一个小团队干一两个月。
第二，状态多样性。调用类Agent的训练数据必须有"演化状态"——同一个用户，先查询余额再转账再查流水，每一步API返回的"世界状态"必须前后一致。要造这种数据，光造账号不够，还得造交易记录、得让记录之间能因果串联。
合成数据路线看似避开了人工标注，结果把成本转移到了"造环境+造状态"上。这是ESAT要打破的耦合关系。
它的核心猜想很直白：现代LLM在预训练里见过太多"世界知识"——银行账户怎么运作、电商订单怎么流转、邮件如何存档——它已经隐式学会了一个世界模型。那干脆把这个能力直接用来当API的执行反馈。
"Given API specifications, input arguments, task instructions, and prior interaction history as context, an LLM can synthesize realistic execution results that mimic feedback from a live environment."
用人话讲：只要把"API签名 + 用户任务 + 之前的调用历史"喂给LLM，它就能像写小说一样"接续"出合理的API响应。让LLM扮演沙箱本身。
🏗️ ESAT流水线：三阶段拆解
ESAT（Environment-Free Synthetic Agentic Trajectory）分三步走。论文里的pipeline图是一个TikZ绘制的三阶段架构图（Task Synthesis → Trajectory Synthesis → Trajectory Filtering），我用文字+表格把核心逻辑拆开：
阶段一：任务合成（Task Synthesis）
只输入：API规格说明书（API名、用途、输入输出schema）。
桶化生成（Bucketized generation）：把任务生成组织成"配置桶"，每个桶是一个属性组合： - 难度（easy/medium/hard） - 动作类型（read/write/mixed） - 任务焦点（约束满足/推导/迭代/开放） - App数量（1/2/3） - 每个App的API数量范围
随机打乱桶顺序，每个桶采样多次生成任务。用这种方式保证任务的多样性不会坍缩到"全是简单读操作"这种偏分布。
逆频率采样：维护每个App和API的累计使用次数，采样时按"用得越少概率越高"的方式挑选App和API，强制覆盖长尾。论文里有个数字很能说明问题：在1017个合成API上，最低1次覆盖率达到99.6%，但要求至少20次覆盖时跌到49.2%（看后面的图）。这说明生成任务的"全谱覆盖"没问题，但单API的"深度"是个真正的工程挑战。
任务改写（Task rewriting）：直接从API规格生成的任务经常很"程序化"——"先调用A，传入X参数，然后调用B……"。这种描述不像真实用户说话，所以再让LLM改写成"意图级"请求："帮我把这200块转给Alice"。改写后还要过一道judge判pass，否则退回原版。
任务过滤：每个生成的任务让judge LLM检查well-formed、solvable、和桶配置一致。
阶段二：轨迹合成（Trajectory Synthesis）
这是ESAT最核心的环节，也是和"传统LLM当模拟器"工作最大的区别。
核心思路：teacher agent（GLM-5.1-FP8）一边解决任务一边调用API，但每一个API响应不是从真实环境来的，而是simulator LLM（同一个GLM-5.1-FP8）现场"编"出来的。
为了让编出来的响应"像真的"，simulator的输入context被精心设计成6样东西：
- 完整的API规格（让simulator知道每个字段约束）
- 当前API调用的参数
- 用户任务本身
- 该App之前的调用历史与模拟响应（关键！维持stateful一致性）
- 虚拟用户的姓名、邮箱、电话
- 当前日期时间
第4点是ESAT和Simia等工作的关键差异。Simia是把整条轨迹一次性让LLM生成，ESAT是显式分步——teacher发请求，simulator回一条，再发一条，再回一条。每一步都校验。
Simulator的4条铁律（在system prompt里固化）：
- Data consistency：跨轮次保持状态（之前给artist X分配的歌必须还在X名下）
- Data diversity：列表类结果混入任务相关和不相关项，模拟真实噪声
- Data realism：数值范围、唯一标识符等字段约束要遵守
- Schema compliance：响应严格匹配API规格中的schema
质量校验链（避免LLM编飞了）： - 调用前：参数类型/必填项程序化校验，不通过直接返回错误（不浪费simulator） - 调用后：schema check（不通过就用schema错误作为feedback重prompt） - schema过了之后：judge LLM检查语义一致性和状态连续性（不通过就用judge的反馈refine） - 限定最大重试次数
轨迹终止条件（任一触发就停）： - Agent显式调用"任务完成"API - 超过设定的最大步数 - 调用了生成任务时没规划的App的API - Simulator连续重试失败
阶段三：轨迹过滤（Trajectory Filtering）
让Gemini-3.1-Pro做trajectory-level judge，评判agent是否真正解决了任务。每条轨迹judge多次，只有多数票通过才保留。
论文里有个细节值得拎出来：他们专门做了个对比实验，Qwen3-8B训在ESAT-S52-AW7数据上——不过滤时Test-N是61.4、用GLM-5.1过滤降到58.5（反而变差）、用Gemini-3.1-Pro过滤升到64.9。
也就是说过滤不是越严越好，而是要"用更聪明的模型做更狠的淘汰"。GLM-5.1太"宽容"，误杀不够；Gemini砍掉更多低质量样本，下游性能反而提升。这个结论挺反直觉的——直觉上"judge更狠"应该不会让数据变差，但实际是judge太弱等于在用噪声做监督。
🧪 实验：数据真的能训出能打的Agent吗？
评测基准： - AppWorld：457个API，9个app，平均每个任务涉及10个唯一API、45次调用。Test-Normal（168题）+ Test-Challenge（417题，含2个held-out app测泛化）。 - OfficeBench：20个API、8个app，专注办公自动化（拉表格数据、排会议、发邮件）。评测26个2-app题+46个3-app题。
实验设计： - Teacher/生成：GLM-4.7-FP8（任务合成）+ GLM-5.1-FP8（teacher+simulator）+ Gemini-3.1-Pro（过滤） - 训练：8个开源模型（Qwen3 1.7B/4B/8B/14B + Qwen3.5 2B/4B/9B/27B） - ESAT数据三套： - ESAT-AW7：用AppWorld 7个app的340个API生成9K轨迹（严格排除Test-C的2个held-out app） - ESAT-S52：用52个合成app共1017个API生成6K轨迹（完全独立于AppWorld） - ESAT-S52-AW7：上面两个合并 - 对照：AWT（用真AppWorld环境在90个训练任务上各跑8次，过verifier滤出634条成功轨迹）
AppWorld主结果
我直接把核心数字搬过来（表1+表2合并版）：
| 模型 | 数据 | Test-N | Test-C |
|---|---|---|---|
| Gemini-3.1-Pro（zero-shot） | - | 95.3 | 86.8 |
| GLM-5.1-FP8（zero-shot） | - | 86.5 | 81.9 |
| GPT-4o（zero-shot） | - | 48.8 | 30.2 |
| Nemotron-3-120B（zero-shot） | - | 51.8 | 37.3 |
| Qwen3-8B | zero-shot | 21.1 | 7.8 |
| Qwen3-8B | AWT（真环境数据） | 55.7 | 39.1 |
| Qwen3-8B | ESAT-S52-AW7 | 64.9 | 49.1 |
| Qwen3-8B | ESAT-S52-AW7 + AWT | 69.9 | 54.4 |
| Qwen3.5-9B | zero-shot | 25.2 | 15.4 |
| Qwen3.5-9B | AWT | 71.2 | 53.8 |
| Qwen3.5-9B | ESAT-S52-AW7 | 75.7 | 65.7 |
| Qwen3.5-27B | zero-shot | 73.2 | 53.2 |
| Qwen3.5-27B | AWT | 83.5 | 63.7 |
| Qwen3.5-27B | ESAT-S52-AW7 | 84.2 | 79.0 |
几个值得拎出来的点：
1. ESAT纯合成 > AWT真环境数据。除了1.7B这种小到没法学的小模型，Qwen3-4B/8B/14B在ESAT-S52-AW7上都比AWT高——Qwen3-8B高9.2/10.0个点，Qwen3-14B高4.7/10.4个点。考虑到ESAT-S52还是完全在合成API上生成的数据，能打过真环境数据，这事本身就够反直觉。
2. 4B模型用ESAT训完能吊打120B Nemotron和GPT-4o。Qwen3-8B ESAT-S52-AW7训完Test-N 64.9/49.1，Nemotron-3-120B zero-shot 51.8/37.3，GPT-4o 48.8/30.2。一个8B模型打120B的SOTA级闭源。这就是论文标题里"effective knowledge transfer"的实证。
3. Qwen3.5-27B训ESAT-S52-AW7后Test-C 79.0，距离GLM-5.1-FP8 zero-shot 81.9只差3个点。一个27B小模型接近teacher的水平，这蒸馏效率对工业部署很有意义。
4. ESAT + AWT不是简单加和。对Qwen3系列，在ESAT-S52-AW7基础上再加AWT微调，Test-N再涨4-15个点；但对Qwen3.5系列没增益。论文脚注里点了一下，可能是Qwen3.5基础能力已经够强，额外AWT数据是噪声而非信号。
OfficeBench主结果
OfficeBench没有训练集，ESAT用20个API、8个app生成1.7K轨迹（ESAT-OB）：
| 模型 | 数据 | 2-app | 3-app |
|---|---|---|---|
| Gemini-3.1-Pro | zero-shot | 90.0 | 77.7 |
| GLM-5.1-FP8 | zero-shot | 76.7 | 57.1 |
| GPT-4o | zero-shot | 74.5 | 50.9 |
| Qwen3-4B | zero-shot | 49.8 | 38.9 |
| Qwen3-4B | ESAT-OB | 75.7 | 55.9 |
| Qwen3.5-2B | zero-shot | 9.1 | 0.7 |
| Qwen3.5-2B | ESAT-OB | 69.6 | 40.9 |
| Qwen3.5-9B | zero-shot | 68.6 | 46.4 |
| Qwen3.5-9B | ESAT-OB | 83.6 | 63.2 |
注意Qwen3.5-2B这种"小到不能指望它做事"的模型，ESAT-OB训完在2-app题上从9.1直接蹦到69.6，涨了60.5个点——对一个2B模型来说，这就是从"几乎全错"到"接近GPT-4o"。
跟现有合成数据集的对比
ESAT还跟三个代表性合成数据集对打：ToolAlpaca、ToolACE、Nemotron（1.5M轨迹规模）。在OfficeBench 3-app上：
| 模型 | 数据 | 3-app |
|---|---|---|
| Qwen3-4B | zero-shot | 38.9 |
| Qwen3-4B | ToolAlpaca | 2.1 |
| Qwen3-4B | ToolACE | 3.0 |
| Qwen3-4B | Nemotron | 0.5 |
| Qwen3-4B | ESAT-OB | 55.9 |
嗯你没看错，ToolAlpaca/ToolACE/Nemotron这三种"业界主流合成数据集"在OfficeBench上把模型训崩了——从zero-shot 38.9直接掉到0.5-3.0。论文也专门在Qwen3-4B 2-app上把数据列出来了：zero-shot 49.8 → ToolAlpaca 11.3，降幅78%。
这事挺值得琢磨的。我的判断是——这几个数据集训练场景都偏"短horizon + 无状态"或者"单轮 + rubric-based"（Nemotron每个响应是对照rubric编的，不维护跨调用的state），把它们灌给一个本来能zero-shot做对的模型，反而把它的长程规划能力"污染"掉了。这反过来印证了ESAT的核心论点：stateful simulator是必要条件，不是锦上添花。
Judge质量与Simulator质量
论文做了三层独立验证：
1. 跟真环境对拍：拿GLM-5.1在真AppWorld跑了720条轨迹（90训练任务×8次），同时让Gemini当judge独立评这720条。judge precision 95.2%——当ESAT说一条轨迹正确时，它在真环境里基本也是正确的。这个数字对数据筛选很关键：recall可以放一放，precision必须高，否则错的样本进训练集就污染了。
2. 跟人对拍：200条轨迹（100 accept + 100 reject），人类标注员用同样标准评。95%一致率、Cohen's kappa 0.90——这在NLP里是near-perfect agreement。
3. Simulator自检：拿GPT-5.1对1K条成功轨迹（~27K次API调用）的模拟响应做了一致性评判——93.7%有效。
不过Simulator的失败率会随输出长度上升：
图：Simulator失败率随输出长度上升——短响应（<250 token）仅2%失败，2K+ token时飙到23%。这是论文唯一的明显短板，根因是GLM-5.1-FP8长文本生成能力本身。
| 输出token长度 | 失败率 |
|---|---|
| <250 | 2% |
| 250-500 | 3% |
| 500-1K | 8% |
| 1K-2K | 18% |
| 2K+ | 23% |
也就是说，短响应下Simulator近乎完美，长响应下每4-5次调用就有1次失败。这跟GLM-5.1-FP8自身的长文本生成能力直接相关——作者也承认换更强的frontier model做simulator理论上能缓解。
📊 数据质量：API覆盖看ESAT有没有"造假"
一个很自然的怀疑是——既然Simulator是LLM编的，那它编的轨迹会不会集中在某几个"好编"的API上，长尾API根本没覆盖？
论文用三张图分别看了AppWorld、合成的52个app、OfficeBench的API覆盖情况，横轴是"至少被N条轨迹覆盖到的API数量"：
图：AppWorld 340个API的覆盖情况。横轴是"至少N条轨迹覆盖过"，纵轴是达到该阈值的API数及其占比。99.7%的API至少被1条轨迹覆盖，要求20次覆盖仍有74.4%。
AppWorld共340个API：99.7%的API至少被1条轨迹覆盖、95%的API至少被5条轨迹覆盖、要求至少20次覆盖时还有74.4%（253个API）。意思是用9K轨迹基本把AppWorld的API谱扫了一遍。
图：52个合成app共1017个API的覆盖。99.6%至少1次覆盖，要求20次时跌到49.2%——API数量稀释了轨迹密度，但长尾仍被合理覆盖。
合成app场景的1017个API：99.6%至少1次覆盖、要求20次时跌到49.2%。这个跌幅比AppWorld大（74.4% vs 49.2%）——但合理，因为合成API数量是AppWorld的3倍，6K轨迹被稀释了。即使如此，对一半以上的API提供了"够用"的覆盖深度。
图：OfficeBench仅20个API，1.7K轨迹基本把每个API覆盖20+次。
OfficeBench只有20个API，数据全部覆盖，没讨论价值——就提一句。
任务分布的均衡性
我还看了两个有意思的分布图——任务焦点和任务难度：
图：四种任务焦点分布基本均匀（约束满足21%/推导25%/迭代32%/开放22%），归功于"桶化生成"设计——每个桶独立采样避免LLM偏好简单任务的倾向。
四种焦点（约束满足21%、推导25%、迭代32%、开放22%）分布相当均匀，没有出现"全是迭代型任务"这种偏分布。
图：难度分布基本三等分（easy 34%/medium 31%/hard 35%），验证了逆频率采样和桶化生成的均衡性。
难度分布也基本三等分（easy 34%/medium 31%/hard 35%），这要归功于"桶化生成"的设计——每个桶被独立采样，避免了LLM偏好简单任务的人尽皆知的倾向。
🔬 我的判断
论文做对了什么
1. 把"LLM当世界模型"工程化到了一个工业可用程度。这事在学界不新鲜（Simia、ToolEmu都做过），但ESAT把任务生成、轨迹合成、状态维护、过滤判别做成完整pipeline，每一步都有质量校验，并且给出了一套可量化的质量指标（simulator 93.7%有效、judge 95.2% precision、95%人类一致）。这不是"一个idea"而是一份能复现的方案。
2. 实证反驳了"合成数据必须依赖真环境"。在AppWorld上，纯合成API（S52）训出的模型在大多数尺寸上超过AWT。这件事如果成立，意味着很多团队的Agent训练基础设施可以大幅简化。
3. 对stateful simulator的必要性给出了硬证据。ToolAlpaca/ToolACE/Nemotron把模型训崩的对比实验，是这个工作最锋利的一刀。
4. 蒸馏路径有效。Qwen3.5-27B ESAT训完接近GLM-5.1-FP8 teacher，这意味着用一个超大teacher + 4-27B小student的组合就能达到接近teacher的效果，工业部署的算力账能算得过来。
论文的局限
1. Simulator的天花板是LLM本身的能力。当API响应需要长输出（2K+ token）时失败率飙到23%。如果你的业务场景就是"返回一个长列表"，那ESAT路径上还有硬骨头要啃。论文也提到"potentially be addressed by using more powerful frontier models"——但frontier model贵啊，这个成本账不一定比搭一个真环境便宜。
2. 评测benchmark都是合成的。AppWorld和OfficeBench虽然复杂，但终究是research benchmark。一个真实生产API（比如微信支付）涉及的鉴权、限流、幂等性、时序约束，LLM在没真调过的情况下能不能编得像，这是开放问题。论文没有做这种"真业务API"的迁移性验证。
3. 训练模型限于Qwen3/Qwen3.5系列。不是说这些模型不好，但蒸馏到非Qwen系列（比如Llama、Mistral）的效果没验证。如果要做Agent基础设施的"通用训练底座"，跨模型家族的泛化是必须验证的。
4. Gemini-3.1-Pro当judge的成本没说。论文用Gemini当filter，每条轨迹judge多次，训练19K条轨迹做几次judge——这个API成本可能比搭环境还贵（如果你的环境本身不复杂）。论文没披露cost breakdown。
给做Agent训练的人的实际启发
- 如果你的业务API数量在20-50个，状态空间小：ESAT路线立刻可上，省掉真环境造数据的时间。
- 如果你的业务API数量上千、响应结构复杂：先在长尾API上验证simulator的保真度，再决定是否走纯合成路线。
- 如果你的目标模型是某个闭源模型的蒸馏版：用ESAT做蒸馏pipeline值得一试，Qwen3.5-27B vs GLM-5.1-FP8的差距已经很小。
- 如果你的训练数据需要"新API扩展"：ESAT的"52个合成app"思路直接可借鉴——合成一份API规格，零环境成本生成新任务。
💭 一点碎碎念
读完这篇我最大的感受是——LLM-based simulator这条路从"有趣的idea"正式进入了"工程化可用"阶段。但也别过度乐观。
真实业务里的API调用往往涉及：异步回调、并发幂等、限流退避、敏感数据脱敏——这些东西LLM能不能在"脑补"层面模拟得像，需要逐场景验证。ESAT证明了"原则上可行"，但距离"所有场景都work"还有距离。
另一个值得想的点：ESAT-AW7的效果已经超过AWT，这是否说明在AppWorld这种"环境可控制"的benchmark上，simulator已经学到了比"真环境执行"更本质的pattern？ 一种可能是simulator在生成轨迹时天然倾向于"叙事合理"，而真环境执行会混进一些噪声调用。这是个值得深挖的研究问题。
收尾再说个观察：论文8个作者全部来自Apple，且没有任何GitHub/代码链接——跟学术界典型"开源代码+arXiv"的玩法不同。考虑到Apple的ML研究风格，这篇可能更接近一份"内部方法论外发"，而不是追求复现性的研究。读的时候要意识到：复现这套pipeline，你至少要能用上GLM-4.7/5.1-FP8和Gemini-3.1-Pro这种规模的闭源模型。如果只能调用开源模型，simulator的质量天花板会低一截，ESAT的相对优势可能缩小。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我。