AWM：让大模型造出可执行的世界，再用它训练 Agent

如果要教 Agent 取消订单，只有一段“应该调用哪些工具”的示范还不够。它还需要能够反复查询、取消、犯错、重新开始的订单系统，以及一个能判断它有没有取消错订单的裁判。

AWM 让大模型批量编写这样的系统：数据库保存状态，Python 工具执行动作，验证程序和模型共同检查结果。Agent 在这些系统里练习，并通过强化学习更新参数。

这里的“世界模型”主要是一套可执行代码。每次调用工具后的状态变化由程序实际算出来，而不是让另一个语言模型临场编一个返回值。

本文解读 Agent World Model: Infinity Synthetic Environments for Agentic Reinforcement Learning，以所读 41 页 PDF 的正文与附录为依据。方法见 §3，结果见 Tables 4–7。项目代码由作者公开。下文订单和梯度数值均为教学用简化示例。

1. 先把三个角色分清

角色	输入	产物	在本文训练实验中怎样变化？
环境生成模型	场景、任务与代码运行错误	数据库、工具代码、验证代码	通过生成和修复代码构造环境
可执行环境	Agent 的工具调用	工具返回值和新数据库状态	每个 episode 内修改状态；不同 rollout 隔离
被训练的 Agent	任务、工具说明、交互历史	下一次工具调用或回答	根据完成任务的奖励做 GRPO 更新

“生成环境”和“训练 Agent”是两件事。不能把生成环境代码的模型、执行工具的 Python 进程、被训练的 Qwen3 混成同一个学习对象。

2. 为什么要造环境，而不只造答案？

静态示范只能告诉模型一条路径。真正执行任务时，它可能输入不存在的 ID、重复调用接口，或者先修改了状态，后续操作的前提也随之变化。只有环境能够把这些后果持续反馈回来。

真实服务又不适合无限并行试错：账号与权限限制、外部副作用、恢复初始状态的成本，都可能成为瓶颈。

AWM 的核心假设是：只要合成环境足够多样，并且状态变化与反馈足够可信，模型就能从中学到可迁移的工具使用能力。因此，重点是环境生成流水线及其可用性，而非发明一种全新的 RL 损失。

3. 从一个场景生成什么？

论文 §3 的生成流程可以分成六步。

1. 生成场景。从网站领域种子出发，构造需要维护状态、支持增删改查的业务场景，再去重和控制类别分布。
2. 生成任务。每个场景设计 10 个任务，要求能够通过接口完成。主要假设用户已经登录，避免把任务变成纯 UI 操作。
3. 建立数据库。根据任务所需的实体、关系和初始条件生成 SQLite 表与种子数据。
4. 实现工具。先确定工具参数和返回结构，再生成通过 MCP 暴露的 Python 实现。MCP 在这里提供统一的工具调用接口。
5. 建立验证器。生成程序检查执行前后的相关数据库变化，再让模型结合检查结果与交互轨迹判断任务完成情况。
6. 执行与修复。实际运行生成的组件，把错误反馈给生成模型，最多进行 5 次修复重试。

最终得到 1,000 个环境、10,000 个任务、35,062 个工具。平均每个环境约有 18.5 张表、35.1 个工具、1,984.7 行代码。实际 RL 实验使用其中 526 个环境和 3,315 个任务，不能把“生成规模”直接当成“训练使用规模”。

① 先造练习场任务 → SQLite 数据
工具定义 → Python 代码这一阶段产出环境。

② Agent 进去尝试查询订单 → 调用取消接口
数据库发生真实的程序内变化每条轨迹有独立状态。

③ 检查结果并训练数据库差异 + 轨迹 → 奖励
组内比较 → 更新 Agent梯度更新的是策略模型。

4. 一个订单任务：从输入一直走到奖励

4.1 初始数据库与任务

教学任务：“取消我的未付款订单 7，其他订单保持原样。”假设环境已确认该用户身份，规则允许直接取消这张未付款订单。

订单 ID	用户	付款状态	订单状态
7	Alice	未付款	待处理
8	Alice	已付款	待处理

Agent 能调用 list_orders()、get_order(id) 和 cancel_order(id)。它不能绕过工具直接修改数据库。

一次正确轨迹是：

Agent → get_order(7)
环境  → {owner: Alice, payment: unpaid, status: pending}

Agent → cancel_order(7)
环境  → {ok: true, status: cancelled}

Agent → “订单 7 已取消。”

工具执行后，订单 7 的状态成为 cancelled，订单 8 保持 pending。这里没有训练发生：这只是采样一条轨迹，得到一次试做的结果。

4.2 为什么既看数据库，也看轨迹？

验证代码可以检查三个条件：

target_cancelled = after[7].status == "cancelled"
other_unchanged = after[8] == before[8]
target_owned_by_user = before[7].owner == "Alice"

代码擅长回答“哪一行变了”。但任务可能还有用户确认、回复内容等过程要求。AWM 因此让裁判模型结合程序检查结果和完整轨迹，输出 Completed、Partially Completed、Agent Error 或 Environment Error。（§3；Table 6）

对应的主要任务奖励是：完成为 1，部分完成为 0.1，其余为 0。附录另外规定格式错误可以立即得到 −1 并终止；不能把格式惩罚与普通未完成任务混为一谈。

例如，Agent 只在回答中宣称“取消好了”，数据库没有变化，就不能仅凭这句话得到完成奖励。反过来，程序故障导致取消接口崩溃，也应与 Agent 选择错误区分。

5. 奖励如何变成梯度？

5.1 同一道题独立做四遍

为了手算，把真实的多轮 token 序列压缩成一次二选一决策：正确取消订单 7，或错误处理订单 8。设错误轨迹未完成任务，奖励为 0。

四次尝试都从初始数据库重置开始，不是对同一份已经取消过的订单连续操作四遍。

rollout	简化决策	最终奖励 \(R_i\)	组内优势 \(A_i\)
1	正确取消 7	1	+1
2	正确取消 7	1	+1
3	错误处理 8	0	−1
4	错误处理 8	0	−1

奖励均值为 \(\mu=0.5\)，按总体标准差计算 \(\sigma=0.5\)。忽略数值稳定项：

\[ A_i=\frac{R_i-\mu}{\sigma}. \]

优势就是“这次比同组平均水平好多少”。这里没有教师给出正确动作文本，而是Agent 自己尝试，环境给最终分数，组内比较确定提高或降低哪些尝试的概率。

5.2 先算一个确实能求导的损失

设唯一可训练参数为 \(z\)，正确动作概率是 \(p=\operatorname{sigmoid}(z)\)，当前 \(p=0.4\)，所以 \(z\approx-0.4055\)。

在一次更新刚开始、新旧策略相同、裁剪尚未生效时，GRPO 的策略项与下面这个加权对数概率损失具有相同的一阶梯度：

\[ L(z)=-\frac14\left[2\log p-2\log(1-p)\right]. \]

把 \(p=0.4\) 代入，得到 \(L\approx0.2027\)。这个损失可以是负数；它是带正负优势的策略目标，不是普通答案交叉熵。

利用

\[ \frac{\partial\log p}{\partial z}=1-p,\qquad \frac{\partial\log(1-p)}{\partial z}=-p, \]

可得

\[ \frac{\partial L}{\partial z} =-\frac14[2(1-p)+2p]=-0.5. \]

用教学学习率 \(\eta=0.1\) 做一次梯度下降：

\[ z'=z-\eta\frac{\partial L}{\partial z} =-0.4055+0.05=-0.3555, \qquad p'=\operatorname{sigmoid}(z')\approx0.4121. \]

结果：正确动作的概率从 40% 提高到约 41.21%。数据库本身没有被梯度更新，变化的是 Agent 参数。下一轮再用更新后的 Agent 生成新尝试。

真实 AWM 使用多轮 GRPO，还包含新旧策略概率比、裁剪、KL 约束及大量 token；上述二选一损失只用于展示更新方向，不能代替实际训练代码。论文设置学习率为 \(7\times10^{-7}\)，每个任务采样 16 条 rollout，也不是例子的 0.1 和 4 条。

5.3 一个容易漏掉的细节：训练时看见的历史要对齐

Agent 执行时可能只保留最近若干轮，以免工具输出塞满上下文。若训练算某一步概率时却额外提供完整历史，模型就在“拥有更多信息”的条件下学习。

AWM 的 history-aware 训练让每一步的训练输入与采样时相同，实验使用滑动历史窗口 3；损失只落在相应轮次的 Agent 输出上，工具返回作为条件。Table 7 显示，在使用历史限制的设置下，对齐这一点明显影响结果，例如 4B 的 τ² pass@1 从不对齐设置的 9.35 提高到 22.57。

6. 实验到底改善了什么？

Table 4 的整体分数如下，均按原表报告百分数；箭头表示同规模基础模型到 AWM 训练后。

模型	BFCL v3	τ²-Bench pass@1	MCPMark
Qwen3-4B → AWM-4B	54.92 → 64.50	15.83 → 22.57	6.15 → 6.70
Qwen3-8B → AWM-8B	53.83 → 65.94	26.44 → 33.45	6.70 → 11.17
Qwen3-14B → AWM-14B	61.25 → 70.18	36.69 → 39.03	8.38 → 12.29

例如 8B 的 BFCL 提高 12.11 个百分点，τ² 提高 7.01 个百分点。这支持了“合成环境训练可以迁移到外部工具任务”的判断。

但它不是所有指标都最好：同表 EnvScaler-8B 的 τ² 为 39.39，高于 AWM-8B 的 33.45；8B 的 BFCL 部分子项也有退步。MCPMark 的绝对成功率仍低，且实验排除了需特定认证等条件的部分环境。

奖励质量同样关键。Table 6 中，8B 的代码辅助模型裁判在 BFCL / τ² / MCPMark 上得到 65.94 / 33.45 / 11.17，优于该实验的纯代码与纯模型裁判。这说明两种检查具有互补性，但没有证明裁判已不会误判。

7. 最值得保留的贡献，以及它的边界

我认为最有价值的是：把“合成数据”推进为“合成可重置、可执行、可验证的交互系统”，让训练能够覆盖模型实际会走到的错误状态。

作者明确承认三点局限：生成过程固定，尚未形成自进化循环；自动修复主要捕捉运行错误，语义错误仍会遗漏；训练只覆盖部分环境和 Qwen3 的有限规模。

Table 5 对 100 个环境的代码审查也提示不能把“能运行”当作“无 bug”：不同模型审查发现 74%–83% 的 AWM 环境存在 bug，但任务被判定受阻的比例约为 11.5%–14%。这与实际 rollout 中约 4% 的环境执行错误率是不同口径，不能相互替换。

我的分析与改进设想：

具体问题	可以怎样改	代价与验证方式
工具能运行但违反业务规则	加入状态不变量，例如退款总额不得超过实付金额	需要更可靠的规则来源；测违规状态发生率和误拒率
固定任务没有针对当前 Agent 的弱点	根据失败轨迹增加任务，再继续训练	防止过拟合少数错误；在独立环境上测迁移，比较等预算随机加题
模型裁判可能被表面回复影响	分别报告数据库目标、过程约束和语言回复的核验结果	验证成本增加；用人工抽样检查奖励误判率

这些是有待验证的扩展，不是 AWM 已完成的实验结论。

8. 放回四篇论文里看

论文	“世界”由什么提供？	主要更新什么？
AWM（本文）	合成数据库与可执行工具	Agent 的 RL 参数
Agent-World	现实主题与数据支撑的合成环境，并按失败补题	SFT 初始化后持续做 Agent RL
DynaWeb	学出来的网页状态预测模型	先 SFT 世界模型，再 RL 训练 Agent
R-WoM	教程约束下的语言模型想象	推理时选动作，框架不做参数更新

记住 AWM 的一条链就够了：生成代码 → Agent 实际执行 → 检查状态变化 → 奖励更新 Agent。它的成败取决于这个练习场是否既多样，又能提供可信反馈。