不给模型出题，先给它造一个世界：AgentMercury 把 Agent 训练环境做成了一门可学习的生意

你有没有想过一个挺拧巴的事：我们天天说 Agent 要在"真实环境"里训练，可现在的训练环境是怎么来的？要么手工搭，要么围绕某个 benchmark 批量合成——先定任务，再造一个刚好能让这个任务跑起来的环境。

这就像是先写好考卷，再照着考卷盖一座学校。学校盖得再多，考的永远是那几道题。任务数量翻十倍，底下的世界可能还是同一个。

arXiv 2608.20634 这篇 AgentMercury 就是冲着这个拧巴劲来的。它的答案很直接：把顺序倒过来——先造世界，再让任务从世界里长出来。

核心摘要

这篇论文提出了 AgentMercury，一个从高层商业场景（business scenario）批量合成可执行环境的框架。核心思路是把环境构建从"任务中心"翻转为"场景驱动"：先实例化一个有实体、服务、工具、状态和跨服务约束的持久化世界，再从这个世界里采样出各种各样的任务。作者一口气造了 4,783 个可执行环境，横跨 14 个行业、50 个国家，拿去给 Qwen3.5-4B 做 RL 训练——结果 EnterpriseOps-GYM 从 12.3 涨到 15.7，更意外的是域外完全不相干的 AIME26 数学竞赛题从 45.9 涨到 56.0。最打动我的还不是这些数字，而是另一个实验：环境构建这件事本身也能学，微调 Qwen3.5-35B-A3B 之后，从商业简报直接写出可执行世界的成功率从 3.3% 干到 83.3%，追平最强 API 模型。这是一篇"范式叙事 + 扎实工程"的论文，故事讲得比技术本身大，但实验确实撑住了主线。

论文信息

  • 标题：AgentMercury: Your Agent Can Synthesize Verifiable Environments for Business Scenarios at scale
  • 作者：Minbyul Jeong, Chanwoong Yoon
  • 链接：https://arxiv.org/abs/2608.20634
  • 日期：2026 年 8 月 21 日

🎯 为什么需要这篇论文：缺了第三个角色

作者提了一个我觉得挺漂亮的框架性观察。现在的 Agent 系统里有两个被反复研究的角色：

  • 策略模型 π：决定 Agent 怎么行动
  • 世界模型 W：预测环境会怎么响应

但有个角色一直被当成"给定的"，就是环境本身。实体有哪些、服务怎么连、初始状态是什么、转移逻辑怎么写——这些在学习开始之前就被指定死了，没人把它当成一个需要被系统化构建（甚至被学习）的对象。

AgentMercury 给这个角色起了个名字：Planet。它的职责是决定"什么世界存在"。

这个三角色拆解乍看像概念包装，但你顺着想下去会发现它指向了一个真实的工程痛点。现在主流的 Agent 环境合成路线，不管是 AppWorld 还是 Tau 系列，本质都是 task-centric 的：围绕一组预定义任务去搭环境。问题是任务和世界被耦合死了——环境被优化成"让这批任务可执行、可测量"，而不是"一个能自然涌现各种任务的世界"。想扩规模就只能加任务，可加任务并不增加世界的多样性。

真实的企业场景恰恰相反。一个客户经理的日常不是一道道孤立的题，而是从 CRM、邮件、Slack、账单系统交织的持续工作流里不断冒出来的新目标。任务是从世界里"涌现"的，不是被"指定"的。

所以 AgentMercury 的选择是：拿商业工作流当试验场，因为它天然把结构化操作流程、用户意图、软件系统、持久状态搅在一起——这正是一个"世界"该有的样子。

🏗️ 方法：从场景到世界的流水线

先给一句话版本：输入一段商业场景描述，输出一个能跑、能交互、能确定性打分的世界，然后在这个世界里出题、跑轨迹、算奖励。

整个系统的数据流长这样：

\[\sigma \xrightarrow{\text{Planet}} w \xrightarrow{\text{Task}} (u, \rho) \xrightarrow{\pi} \tau \xrightarrow{\text{Grade}} r\]

\(\sigma\) 是场景，\(w\) 是可执行世界，\(u\) 是任务指令，\(\rho\) 是评分规范，\(\tau\) 是交互轨迹，\(r\) 是奖励。注意这个分解的关键点：世界只造一次，任务可以造很多次。这是和 task-centric 路线最本质的分野。

AgentMercury 的世界构建与交互流程

论文 Figure 2：上半部分是"世界如何从外到内形成"——商业场景 σ 依次落地为公司身份 C、服务图 G、状态模式 Σ、种子初始状态 s₀ 和世界级不变量 R，共同诱导出状态/动作/观察空间和转移函数；下半部分是"世界内部交互如何展开"——策略基于历史行动，环境确定性转移，episode 结束后由 Verifier 用任务 rubric 和世界不变量打分。底部五个关键属性值得记住：确定性世界、部分可观察、不变量不被强制执行、可执行验证、职责分离。

世界的形式化与生成顺序

一个世界被定义为：

\[w = \langle S, A, \Omega, T, O, s_0, R \rangle\]

\(S, A, \Omega\) 是状态、动作、观察空间，\(T\) 是可执行转移函数，\(O\) 是观察函数，\(s_0\) 是种子初始状态，\(R\) 是世界级不变量。

Planet 不是一口气把世界吐出来的，它的生成过程被因式分解成一条链：

\[\text{Planet}(w|\sigma) = p(C|\sigma) \cdot p(G|C) \cdot p(\Sigma|G,C) \times p(s_0|\Sigma) \cdot p(R|G,\Sigma,s_0)\]

场景先生成公司身份（C，行业、地域、业务上下文），再生成服务图（G，有哪些服务、依赖关系、接口），再生成状态模式（Σ，实体、属性、关系 schema），然后播种初始状态 \(s_0\)，最后是约束集合 \(R\)。前四步决定"这个世界是什么结构"，最后一步决定"这个世界必须满足什么规矩"。结构和规矩分离，这个设计后面会反复用到。

最让我眼前一亮的设计：不变量不强制执行

这里的 \(R\) 是个很有意思的东西。它是世界级不变量——世界要求成立的属性，但转移过程本身不会替 Agent 强制执行它。

举个例子。一个跨服务不变量可以要求"上游创建了一个订单事件之后，下游账单系统必须存在对应记录"。但环境不会自动帮你建这条记录——它就在那儿等着，等 Agent 自己通过调用工具把这件事做对。Episode 结束后，Verifier 用确定性的 SQL 检查器去数据库里验证：这条记录到底在不在。

为什么这个设计重要？因为真实工作流里的坑恰恰在这里。跨系统一致性不是模拟器送的，是 Agent 的责任。如果环境替你强制了，Agent 永远学不会"主动维护一致性"这件事。

还有一个细节：\(R\) 有两个视图。可见视图 \(R_{vis}\) 通过世界内文档或政策条款呈现，Agent 得自己在交互中发现这些规矩，而不是开局就拿到 oracle 答案；隐藏视图 \(R_{hid}\) 装着可执行的验证条件，只给评分器用。同一个不变量，两张脸。

任务实例化与确定性评分

任务是从世界里采样的，不是造世界时的输入：

\[(\Delta s_0, u, \rho) \sim \text{Task}(\cdot | s_0, R)\]

\(\Delta s_0\) 是任务特定的状态播种（交互开始前应用到世界上），\(u\) 是自然语言用户目标，\(\rho\) 是任务级评分断言。同一个世界结构可以从不同的状态种子长出不同的任务——世界造一次，任务随便生。

评分也是确定性的：

\[r(\tau) = \text{Grade}(s_H, \tau; \rho, R_{hid}) \in [0, 1]\]

只要可能，验证都走底层数据库状态的确定性检查，不依赖模型裁判。而且因为转移函数是被执行而不是被预测的，给定初始种子和动作序列，轨迹可以完全复现——同一条轨迹可以回放、可以脱离原始交互过程重新评分。说实话，做过 RL 环境工程的人都知道这个性质有多值钱：没有确定性，你的 reward 就是一笔糊涂账。

数据规模：世界有多大

环境的规模是这篇论文"at scale"招牌的底气。整体环境库 4,783 个可执行环境，跨 14 个行业、50 个国家。实际用于 RL 的语料子集统计如下（Table 4）：

统计项 数值
任务总数 43,300
可执行世界/公司数 4,326
每个世界的任务种子数 10
独特行业描述 2,287
独特工具 842
独特状态表 222
服务组合 148
每个世界的工具数 10–26（平均 16.1）
每个任务涉及的服务数 1–5（平均 2.9）
每个任务的程序化断言数 2–10（平均 5.4）

任务侧的 persona 有 6 种角色（客户经理、协调员、销售经理、运营协调员、客服主管、分析负责人），最常见的服务组合是 CRM + 邮件 + Slack。一个值得记住的数字：59.9% 的任务带跨系统动作风险（25,991/43,300）——不是在一个系统里自嗨，是真的要跨服务操作。

合成语料构成与训练足迹

论文 Figure 5：(A) 完整语料 43,300 个任务来自 4,326 个合成公司环境，行业、工具、状态表、服务组合的分布都做了可视化；(B) 200 个 RL 训练步里模型实际只见到 3,200 个任务（占 7.4%），但靠 shuffle 采样保住了 53.5% 的环境覆盖、62.9% 的行业覆盖、75.8% 的工具覆盖——只用一小部分任务仍能维持世界层面的多样性；(C) 从场景到梯度的完整任务生命周期。

🧪 实验：域内涨是本分，域外涨才是看点

训练设置：模型用 Qwen3.5-4B 和 Qwen3.5-35B-A3B，主 RL 算法是 GRPO（带 Dr. GRPO 的系数细节），另用 SAO（single-rollout asynchronous optimization）验证环境不挑算法。每个 benchmark 跑 3 次独立评估报 mean ± std。关键前提：训练环境与所有评测 benchmark 完全独立构建——这句话是后面所有域外结果可信度的地基。

EnterpriseOps-GYM：域内基本盘

模型 Teams CSM Email ITSM Calendar HR Drive Hybrid Avg.
GPT-5 † 26.3 36.4 49.0 18.9 41.3 17.9 34.0 23.5 30.9
Kimi-K2-Thinking † 30.0 7.1 51.0 12.2 15.4 8.2 39.6 15.7 22.4
Qwen3.5-4B 20.8 9.2 23.9 6.8 10.4 9.5 6.2 11.7 12.3
Qwen3.5-4B + GRPO + Ours 23.0 5.6 33.3 7.4 13.1 10.8 15.6 17.0 15.7
Qwen3.5-35B-A3B 33.9 7.6 53.2 14.6 18.6 11.4 35.9 23.5 24.8
+ GRPO + Ours 39.8 11.1 53.8 15.6 21.9 17.7 41.2 23.7 28.1
+ SAO + Ours 39.1 12.5 54.8 16.5 22.6 17.7 39.1 24.1 28.3

（† 来自 EnterpriseOps-GYM 原数据；训练组数字为 3 次评估均值）

4B 平均分 12.3 → 15.7，涨了 27.6%，最大增益在 Drive 和 Email，各 +9.4。35B 两种算法都涨，且 8 个域全部提升。

但注意一个不太体面的数字：4B 的 CSM 域从 9.2 掉到 5.6。作者如实报了，没有藏起来，这点比很多只挑好消息的论文强。CSM 这种客服管理域为什么掉，论文没给出解释——我猜测是训练分布里 support 类任务的占比和评测域的难度结构不匹配，但这只是猜。

域外迁移：这才是真正的卖点

Benchmark 4B Base 4B + GRPO 变化
AIME26（数学） 45.9 56.0 +10.1
HMMT（数学） 28.5 35.4 +6.9
LiveCodeBench（代码） 36.6 44.0 +7.4
SciCode（科学计算） 22.6 25.7 +3.1
Tau3-Airline 48.8 58.7 +9.9
Tau3-Retail 70.4 73.6 +3.2
Tau3-Telecom 92.5 91.9 -0.6
BFCL（工具调用） 30.3 31.7 +1.4
GPQA-Diamond 76.5 77.5 +1.0

在 CRM、Slack 这些商业软件环境里做 RL，数学竞赛题涨了 10 个点。

看到这个数我愣了一下。AIME26 和商业工作流八竿子打不着，唯一的解释是：多步工具交互里练出来的长程规划、状态跟踪、约束满足能力，确实是一种跨域可迁移的通用推理能力。Tau3-Telecom 基本持平（92.5 → 91.9）反而增强了可信度——说明迁移不是无脑普涨，饱和的地方就是涨不动。

35B 那边还有个点值得说：BFCL 从 31.1 涨到 42.1，涨了 11 个点，是工具调用能力的直接证据。更隐蔽的收获是方差收缩——基座在 Tau3-Telecom 上是 49.1 ± 49.8（等于说这模型一半时间在发疯），SAO 训练后 65.5 ± 23.8。策略不只是更强了，还更稳定了。做线上系统的人都知道，后者往往比前者值钱。

跨 checkpoint 的域外表现

论文 Figure 3：Qwen3.5-4B + GRPO 在各训练 checkpoint 上的域外 benchmark 曲线，虚线是基座水平。AIME26、HMMT、LiveCodeBench、SciCode 都是渐进爬升，不是某个 checkpoint 的运气爆发——排除了单点评测噪声的解释。tau3-airline 和 tau3-retail 中途有深跌再拉回，这个抖动作者没展开讨论，算是个小瑕疵。

训练动态

论文 Figure 4：训练过程中的四个健康度指标。raw reward 稳步上升；response length 先升后降（先学会展开解决多步任务，再学会收敛）；truncated-response ratio 显著下降；degenerate-response ratio 全程贴零。这组图是用来堵"reward hacking"质疑的——奖励上涨没有伴随输出退化或病态膨胀。

全篇最狠的实验：造世界这件事本身也能学

这是我觉得这篇论文最值钱的部分。问题换成：给你一个高层的商业简报（只有行业、地域、业务描述），让模型直接写出一个可执行世界，成功率多少？

评测设置：30 个 held-out 商业简报，12 个结构验证器，全过才算成功。结果（Table 3）：

模型 Zero-shot Recipe 条件
Claude Opus 4.8 83.3% 80.0%
GPT-5.4 66.7% 66.7%
DeepSeek-V4-Pro 83.3% 86.7%
GLM-5.2 80.0% 76.7%
Qwen3.5-35B-A3B（基座） 3.3% 20.0%
Qwen3.5-35B-A3B + 微调 83.3% 10.0%

基座 zero-shot 只有 3.3%——基本写不出能跑的世界。在 29,823 条构建轨迹上微调后，直接拉到 83.3%，追平最强 API 模型。统计检验 p = 1.2×10⁻¹⁰，没得争。

但真正让我停下来的是右下角那个数字：微调后的模型给了 recipe 反而崩到 10.0%，30 个生成里 27 个跨服务验证失败。

你再品一下。没微调的时候，recipe 是救命稻草（3.3% → 20.0%）；微调内化之后，同一个 recipe 成了干扰源。作者的解释我很认同：提示和学习是两种质性不同的机制。构建流程一旦被烧进参数，外部再塞一份"指导手册"反而会打乱已经学到的生成策略。这个发现对做 Agent 工程的人有直接警示——别以为给微调过的模型加更详细的 prompt 总是好事，有时候你是在跟它内化的策略打架。

失败分析也有料：失败集中在跨服务结构约束上，典型模式是 invariant 的 trigger 和 target 被错放进同一个服务里。这种错误从生成的文本语法上根本看不出来，必须靠可执行的 oracle 去抓。这反过来论证了"可执行验证"在整个框架里不是可选项，是地基。

顺带挑个刺：正文说 API 模型 zero-shot 均值 80.7%，但表里四个 API 模型算下来是 78.3%，正文还提到"五个模型"但表里只有四个。数字对不上，可能是版本更新时表和文没同步，不影响主结论，但审稿该抓。

💡 我的判断

这篇论文的真实定位是什么？我的看法：底层突破谈不上，但它把一个正在形成的共识清晰地形式化并推到了规模。

环境合成这条线，今年大家都在做——从 task-centric 往 world-centric 转的方向感，做 Agent RL 的人多少都有体感。AgentMercury 的贡献在于三件具体的事：把"环境构建"确立为显式的 Planet 角色并给了干净的形式化；用"不变量不强制执行 + 事后确定性 SQL 验证"解决了跨服务约束的训练信号问题，这个设计是真精巧；以及用 3.3% → 83.3% 的实验证明了环境构建本身是个可学习能力——这等于说 Planet 也可以是个 learned policy，为闭环留好了接口。

问题也有几个。其一，域内 12.3 → 15.7 的绝对水平离 GPT-5 的 30.9 还差得远，这套环境能不能把头部模型也推高，论文没回答。其二，闭环没合上：环境合成目前还是离线数据生成，不能根据策略的失败模式定向造世界，作者自己也承认。什么时候 Planet 能看着 Agent 的短板出题，这个故事才算讲完。其三，商业场景这个选择既是优势也是天花板——迁移到 AIME 是惊喜，但能不能迁到具身、迁到开放式软件工程，完全没有证据。其四，SAO 在 4B 上不稳定被直接移出主表，虽然作者解释得坦诚，但"环境不挑算法"的说法严格来说只在 35B 规模上成立。

对工程的启发很直接：如果你在搭 Agent 训练环境，别再问"我要造哪些任务"，先问"我的世界长什么样、有哪些不变量该让 Agent 自己负责"。以及，确定性可回放 + 事后 SQL 验证这套组合，值得抄。

结尾留个追问：论文设想了一个自适应课程的闭环——Agent 监控自身失败、识别能力缺口、提出新场景，Planet 把它编译成可执行世界再喂回训练。如果这条路走通，"环境工程"这个工种可能真的要被模型自己接管了。从 3.3% 到 83.3% 那个实验看，这不是科幻。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我