Agent-World: Scaling Real-World Environment Synthesis for Evolving General Agent Intelligence

1 · 动机:为什么"环境"是 agentic RL 的新瓶颈

1.1 历史脉络:从 chat → tool-RL → agent-RL,环境的位置一路上移

2023 年的 RLHF 流水线里几乎不存在"环境"这个词:reward model 给一个 scalar,policy 在 chat 分布上做梯度,世界很安静。2024 ToolFormer / Search-R1 / ReTool 把"调用一个 tool 拿回结果"塞进 trajectory,但环境往往是 stateless(同一查询任意时刻打回相同结果)且 single-tool。

2025 之后两件事让环境"从配料变成主料":

• MCP (Model Context Protocol) 普及 —— 一个统一接口让 LLM agent 可以接入任意 stateful service(GitHub repo、Notion workspace、Postgres、Playwright 浏览器),所有 tool 都变成"读写一个外部数据库"的算子。
• Long-horizon agentic benchmark(τ²-Bench、MCP-Mark、GAIA)集体表明:即便是 GPT-5.2、Claude Sonnet-4.5,在多轮 stateful 的 tool orchestration 上也并不强(MCP-Mark 上 GPT-5.2 仅 53.1%,Gemini-3 Pro 50.8%)。这是 capability gap,不是"再 scale 几个 trillion token"能填上的。

论文的 thesis 一句话: 预训练 ≈ 文本数据驱动;agent post-training ≈ 环境驱动。环境的多样性、stateful 复杂度、可验证性,这三件事直接卡住 agent 的能力上限。

1.2 为什么手工 / LLM-纯模拟 / 程序化沙箱都不够 — 一张对比表

1.3 但即使你想这么做,事情也并不平凡

"让 agent 自动造出可训练的环境"这件事比它听起来难得多,几个关键 friction:

1. topic anchor 从哪来。如果 topic 是 LLM 想出来的,会塌缩到几个常见 vertical(GitHub、Notion);要广必须依赖真实分布(论文用 Smithery 上 ~2.8K MCP server + 0.5K tool docs + 0.2K 工业 PRD)。
2. database 不能让 LLM 凭空写。必须从 web 抓 — 但 web 信息分散、格式杂、有错。所以需要"iterative deep-research + database complexification"循环 N 次。
3. tool 必须能跑而不只是看起来像 schema。论文用 ReAct coding agent 同时生成 tool + unit test,然后 cross-validate(test pass rate > 0.5 才保留)。这是借鉴 self-play with execution feedback (Dong 2024) 的套路。
4. task 必须可判分。否则 RL 没有 reward。论文用两条互补路线:graph-based(可枚举 tool 序列 → 可枚举答案 schema)与 programmatic(LLM 写解题代码 + 验证代码,sandbox 多次跑通才保留)。
5. 多环境 RL 不能彼此打架。每个环境的 tool 名字、签名、state transition 都不一样,直接混训容易 catastrophic interference。论文的解法是:每条 trajectory 独立挂载自己的环境(dynamic per-task env),只在 batch 一级混合。
6. 训完之后怎么知道哪儿弱。这是 self-evolving arena 要解决的 — 用 diagnosis agent 看 failure trace,从分类树里指认弱环境,合成新任务,继续训。

你可以把整篇论文看作"把这六个 friction 各自工程化、串成一个闭环"的工作。它的功劳不在哪个单点,在于把"环境"作为一个生产要素的 supply chain 搭出来了。

2 · 背景速查

2.1 关键术语

2.2 GRPO 速查公式 (本文直接复用)

本文设 ε_low = 0.2, ε_high = 0.28,group 大小 G = 8,每 step 32 个 task,trajectory 上限 80K token,单步生成上限 32K token。

3 · Agentic Environment-Task Discovery

3.1 整体流水线

3.2 Discovery loop 的核心设计选择

(a) Theme 来自真实 MCP — 不是 LLM 凭空想

论文这一步看似平凡但极重要: topic 集合 𝓜 = M₁ (Smithery 上 ~2.8K MCP 服务) ∪ M₂ (open-source tool docs ~0.5K) ∪ M₃ (工业 PRD ~0.2K)。如果让 LLM 自己脑补 topic,集中度会非常糟糕(全是常见 vertical)。从真实分布抽样保证了 long-tail。

(b) Database complexification 𝜙: 多轮迭代

第一遍 mining 通常拿到的是表面数据,论文反复让 agent 在已有 𝒟 上"再深挖一层",直到 N 轮后数据库结构真正复杂(关联表、外键、多文件类型)。这一步比"一次性抓全"重要 — 它是把环境的 stateful 复杂度推上去的关键。

(c) Tool 必须能跑 — 用单元测试当过滤器

每个候选 tool 𝑓̂ 配一组测试用例 Ĉ_f̂,准确率定义:

必须满足 (i) Python 编译通过 (ii) Acc > 0.5 (iii) 该环境至少有 1 个有效 tool 和 1 条有效 test。这是借鉴 SPELL / self-play with execution feedback 的过滤思路 — 不是相信 LLM 写出来的代码对,而是用执行结果当真理。

(d) Hierarchical taxonomy: 给"环境多样性"量化的语言

4 · Verifiable Task Synthesis: 两条互补合成路线

4.1 Graph-based: 适合"线性多步 tool 调用链"

对每个环境构造一个全连接加权有向图 𝐺 = (𝑉, 𝐸):

• Strong dep (w=3, 单向): tool 𝑓ⱼ 的输入必须依赖 𝑓ᵢ 输出 — 例: create_order → get_order_details
• Weak dep (w=2, 双向): 可以依赖也可以从 db 直接查
• Independent (w=1, 双向): 无参数依赖,作 fallback 保证连通

对图做带权 random walk 拿到 tool 序列 τ → 实例化参数(strong/weak 用前一个 tool 输出,independent 从 𝒟 采样)→ LLM 审一遍剪冗余 → sandbox 执行得到中间 trace 和最终结果 → LLM 反向写出"不暴露技术细节的" task description q_final + ground-truth a* + rubric 𝑅。

难度 scale:增大 walk 最大步数 + 提高 weak/independent 边采样概率 + 改写描述使其更抽象。

4.2 Programmatic: 适合"分支 / 循环 / 聚合"任务

graph-based 只能产生序列;programmatic 让 LLM 直接写 Python 解题脚本 π_code,可以包含 if-else、for、跨表 aggregation。同时 LLM 写一个 verifier 脚本 V_code 做多层断言(不只是 string match)。两个脚本都进 ReAct 循环 debug 直到 sandbox 通过。最终 task 也要 5 次 ReAct ≥2 次 pass V_code 才保留。

4.3 Worked example: 一个具体的 task 长什么样

5 · Multi-Environment Agent RL

5.1 数据流

5.2 Reward 设计

两种类型的 task 各有 reward:

注意是indicator 函数(0/1),不是连续 reward。这意味着 GRPO 内的 group advantage 来自"成功 vs 失败的 8 条 trajectory 比对",而非 partial credit。这种二值化 reward 在 long-horizon 下抗 reward hacking 但 explore 难度大,论文通过"必须 5 次 ReAct ≥2 次成功"的 task 筛选保证可解性,从而绕过这一问题。

5.3 为什么不混进 catastrophic interference

读者可能担心: 1,978 个环境同 batch,tool 名一样但语义不同(每个环境有自己的 list_files),agent 会不会学不会?

论文的处理:每个 task 在 prompt 里完整展开自己环境的 tool schema(包括签名、描述),agent 看到的总是"当前任务 + 当前 ℱ(m)"。所以模型实际学的是"conditional on tool schema 给出的 spec, 怎么 plan"这个元能力,不是某具体 tool 名→行为的映射。这本质上是 in-context 工具描述当 grounding。

6 · Self-Evolving Agent Arena

6.1 算法概览

6.2 Capability gap 信号是什么

这是这一节最关键的问题:diagnosis agent δ 到底吃什么、吐什么?

论文设定 δ 配 Python 解释器 + search tool,输入是:

1. per-task failure traces: tool 调用日志、中间观察、validator 反馈("第 5 步 schema 不匹配"、"final answer 缺 affected_rows 字段")
2. error 分布统计: 按 environment、按 taxonomy 类(L1/L2)聚合 fail rate
3. environment metadata: tool schema、database 描述

输出:

• 弱环境 ranked list 𝒲⁽ʳ⁾ ⊆ ℰ_arena
• 每个弱环境的 task-generation guideline 𝒢⁽ʳ⁾(m) — 类似"该环境多生成长 horizon、强 state-update 的题",或"erroneous tool-use 多发生在多步联合查询上,合成时多加这种 pattern"

所以 capability gap signal 是分类树 × failure pattern的二元组,不是单纯一个数值。这一点比"reward 低就多训"细致 — 它告诉数据合成器具体在哪种环境上生成什么 pattern 的题。

6.3 实测: 两轮 self-evolve 的收益

两个观察: (a) 在别人的 base model 上也能涨(EnvScaler-8B 共涨 +5.6 on MCP-Mark) — 说明 self-evolve 不依赖 Agent-World 自家初始化,是模型无关的训练范式; (b) MCP-Mark 收益最大 — 它对 stateful + 长 horizon 的要求最高,正是 diagnosis 最擅长定位的弱点。

7 · Worked Example: 一条 Memory Bank MCP 上 15-turn 的轨迹

论文 Appendix B/C 有完整的 environment card + trajectory,这里抽出一个具体的来还原。

这条轨迹有几个特征值得记住:

• 真实 stateful: T11 的 action:decide 改了状态,T13 又把它持久化到 markdown 文件,T15 的 final answer 字段必须与 sandbox 中实际持久化结果一致。
• 多种 file 类型: json (mcp-config) + markdown (active-context) + 自定义 progress-log。这就是论文 Figure 4 里强调"file type diversity"的实操体现。
• "读-推-写"模式: 真实 agent 任务的骨架往往是这种 read-then-modify。Stateless single-tool benchmark(如老 BFCL)拿不出这种结构。

8 · 实验关键结果

8.1 Headline 数字 (Table 1 摘录)

8.2 怎么读这些数字

• τ²-Bench 上 Agent-World-14B (65.4) ≈ Qwen3-235B-A22B (58.5) + 全部 environment-scaling baseline 之和 — 14B 模型 + 这套环境训出来,直接打过 235B 大杂烩,说明环境多样性 > 参数量在 stateful tool use 上更划算。
• 但和顶级 proprietary 还有距离: Claude Sonnet-4.5 / Gemini-3 Pro 在 τ² 上 84+,Agent-World-14B 65 — gap 还在 ~20 点。论文不掩饰这点。
• BFCL-V4 上 Agent-World-14B (55.8) 超 DeepSeek-V3.2-685B (54.1) — 真实 RL 信号比纯 SFT 大模型在 tool-call 协议上的优势。
• MCP-Mark 上即使 Agent-World-14B 也只 13.3 — 这个 benchmark 是真硬,所有模型都在挣扎。说明环境多样性提升了,但单条任务的 long-horizon 推理上限还要靠 backbone 升级或更强 RL。

8.3 Environment scaling curve

两个突变点: 10 → 100 涨 8.4 点; 100 → 500 涨 4.2 点;500 之后边际递减。这暗示了"环境数量"的 scaling law 形状: log-linear 段 + 高原段。

9 · 与同类工作对比

10 · 局限 / 个人 take / 待验证问题

承认的 + 没明说的局限

• 1,978 个环境的 long-tail 质量参差: 论文承认 cross-validation 用 Acc > 0.5 作阈值,但没汇报 tool 实际错误分布。如果 long-tail 环境里 tool 真实错率高,RL 在那部分本质是 noisy reward。
• Verifier 自己也是 LLM 写的: graph-based 用 rubric LLM-judge,programmatic 的 V_code 也是 LLM 生成 + ReAct 修。所以"verifiable" 的可信度上界 = LLM 判分能力。
• MCP-Mark 仍只 13.3: 论文最关键的 benchmark 上,即便最大模型加 self-evolve 也仅勉强超 GPT-OSS-120B(4.7),距离前沿仍远。
• Self-evolve 收益快速递减: round 1 涨幅 +6.8,round 2 仅 +1.8。这条路不一定能滚很多轮。
• Cold-start 用了 40K SFT trajectories(in-house Doubao-Seed-1.8 蒸馏),不是 from scratch 的 RL。
• 没汇报训练成本: 1,978 环境 + sandbox 并发 + 32 task × 8 rollout / step + max 80K traj — 实际 GPU 时间和成本不知道。

我的疑问 (落地后想验证)

1. "环境数量"这条 scaling 轴的渐近曲线在 2K 已开始放缓,把 ℰ 扩到 20K 还能涨吗?如果不行,这就是有限的 scaling axis,而非新的 scaling law。
2. Diagnosis agent δ 输出的 𝒲⁽ʳ⁾ 和 𝒢⁽ʳ⁾ 用什么 prompt 写的?换 base model 做 δ 是否得到一致诊断?如果 δ 自己幻觉,整个 self-evolve 就是噪声放大器。
3. Per-task 把环境 tool schema 全展开进 prompt,在 80K context 限制下 1,978 环境的 schema 平均要占多少 token?是否在某些环境下 prompt 已经吃掉一大半 budget?
4. 论文 reward 用 indicator 0/1,group 大小 G=8 — 在难任务上很多 group 全 0,GRPO advantage 退化;论文是怎么处理"全失败 group"的?(可能是提前过滤,但没说清)
5. 把 GRPO 换成 DAPO/ReSPO 这类更新 RL 算法,能不能再涨?或者这个范式对 RL 算法已经接近 ceiling,瓶颈在环境本身?
6. 论文用 LLM-judge 做 graph-based reward 但没做 reward hacking 评估;agent 学会 "format 完美但语义错误" 来骗 judge 的情况是否被监测过?

记忆点

精读笔记 v1 · 2026-05-07 · 配套论文 PDF 在 /data/szhang967/papers/paper-notes/agents/AgentWorld_2604.18292.pdf