← 返回 2026-02-11

智能体世界模型：面向智能体强化学习的无限合成环境 Agent World Model: Infinity Synthetic Environments for Agentic Reinforcement Learning

Zhaoyang Wang, Canwen Xu, Boyi Liu, Yite Wang, Siwei Han, Zhewei Yao, Huaxiu Yao, Yuxiong He 📅 2026-02-10 👍 53 2026-07-13 08:35
Agent训练 MCP 工具使用 强化学习 环境合成
arXiv HuggingFace PDF

用代码+数据库自动合成1000个可执行环境，用于大模型智能体的强化学习训练

前置知识

工具使用智能体 (Tool-Use Agent)

指能够调用外部工具（如API、数据库查询、搜索引擎）来完成复杂任务的大语言模型智能体。与纯文本生成不同，工具使用智能体需要在多轮交互中决定何时调用哪个工具、传递什么参数，并根据工具返回的观察结果进行推理和下一步行动。典型工作流程是 ReAct 模式：思考→行动→观察→再思考，循环往复直到任务完成。

本文的核心目标就是训练这样的工具使用智能体，理解工具使用的多轮交互特性是理解本文动机和方法的基础。

智能体强化学习 (Agentic RL)

将强化学习应用于训练LLM智能体的范式。智能体在环境中执行多轮工具调用获得轨迹，通过奖励信号优化策略。与监督微调不同，RL允许智能体探索不同的行动路径并从成功和失败中学习。在本文中采用 GRPO（Group Relative Policy Optimization）算法，对同一任务采样多个轨迹，用组内相对优势来更新策略。

本文的核心训练方法，理解RL如何应用于智能体训练对于把握全文技术路线至关重要。

MCP (Model Context Protocol)

Anthropic 提出的模型上下文协议，是一种统一的智能体与工具交互接口标准。MCP 将环境的工具集暴露为标准化的服务，智能体通过统一的 list_tools 和 call_tool 两个元工具与不同环境交互，无需硬编码任何环境特定的工具信息。这使得智能体可以动态发现和调用不同环境的工具集。

本文所有合成环境都通过 MCP 协议暴露接口，这是实现环境与智能体解耦的关键设计，也是实现在1000个不同环境中统一训练的技术基础。

代码驱动环境 vs LLM模拟环境

两种构建智能体训练环境的范式。LLM模拟环境让语言模型在每次状态转移时生成新的观察结果，灵活但存在幻觉问题且推理成本高。代码驱动环境用程序代码实现状态转移逻辑，配合数据库存储状态，状态转移由代码确定性执行，更可靠且高效。例如，代码驱动环境中调用下单工具就是执行一段Python代码操作SQLite数据库，结果是确定的；而LLM模拟环境中则是让语言模型想象下单后会发生什么。

本文的核心创新就是采用代码驱动而非LLM模拟的方式构建环境，这是本文与已有工作的本质区别。

GRPO (Group Relative Policy Optimization)

一种用于LLM对齐的强化学习算法，最初由 DeepSeek-Math 提出。核心思想是对同一任务采样一组 G 个轨迹，计算每个轨迹的奖励，然后用组内奖励的均值和标准差归一化得到优势函数 $A^{(k)} = (R^{(k)} - \bar{R}) / \sigma_R$。相比 PPO 不需要额外训练价值模型，更适合大模型RL训练。

本文采用 GRPO 作为训练算法，理解其工作原理有助于理解实验设计和奖励函数设计的逻辑。

POMDP (部分可观测马尔可夫决策过程)

一种形式化框架，将环境建模为 $(S, A, O, T, R)$ 五元组：状态空间 $S$、动作空间 $A$、观测空间 $O$、转移函数 $T: S \times A \rightarrow S \times O$、奖励函数 $R$。部分可观测意味着智能体只能看到观测 $O$ 而非完整状态 $S$。本文将每个合成环境形式化为 POMDP，其中数据库定义状态空间，接口层定义动作和观测空间，验证模块定义奖励函数。

这是本文环境合成的理论框架，理解 POMDP 有助于把握每个合成阶段对应的形式化含义。

研究动机

训练工具使用智能体需要在多样化的环境中进行大规模强化学习，但当前面临严重的环境瓶颈。使用真实世界环境进行训练成本极高——许多场景没有公开API，且RL训练通常需要智能体与环境交互数千次（Dulac-Arnold et al., 2021），这在真实环境中完全不可行。人工创建的环境数量极其有限：τ²-bench 只有3个环境，TheMCPCompany 只有5个环境，远不足以训练通用智能体。现有合成研究主要集中在任务合成（如 Self-Instruct、APIGen）和轨迹收集（如 AgentTrek），而非环境本身——这些方法将环境视为给定或用LLM模拟工具响应，智能体无法探索替代行动或从状态变化中获得真实反馈。另一类方法用LLM模拟环境状态转移，但存在幻觉问题（Kalai et al., 2025），每次环境步都需要一次LLM调用，对RL来说既不可靠又低效。

本文的目标是本文旨在构建一个可扩展的环境合成管线（pipeline），自动生成大量可执行的工具使用环境，使智能体能够在其中进行高效的强化学习训练。具体目标包括：(1) 合成的环境必须是可执行的、可靠的——状态转移由代码而非LLM生成，避免幻觉问题；(2) 环境数量要达到千级规模，覆盖多种现实场景；(3) 环境必须支持并行隔离实例和快速重置，满足RL训练的效率要求；(4) 提供可靠的任务完成验证机制，为RL训练提供高质量奖励信号。

与已有工作不同的是，本文的独特切入角度是将环境合成分解为与软件开发对应的五个阶段：场景生成→任务生成→数据库设计→接口合成→验证代码生成。这种设计的核心洞见是：现实世界中的软件应用天然由数据库驱动、通过API接口暴露功能、有明确的功能需求和验证标准。AWM 通过模仿这一结构，用LLM逐步生成数据库 schema、MCP接口、后端代码和验证逻辑，实现了从仅有场景名称到完整可执行环境的自动化构建。与 DeepSeek-V3.2 和 Qwen Tongyi 的类似工作不同，AWM 完全开源了生成管线和环境；与 EnvScaler 等并发工作相比，AWM 不依赖预定义任务集或API文档，仅从100个种子场景名称出发，通过Self-Instruct风格扩展到1000个场景，实现了更大的规模（5倍于EnvScaler）和更强的SQL状态一致性保障。

核心方法

AWM 的整体思路可以用一个类比来理解：如果把训练智能体比作培养一个新员工，那么传统方法要么让员工在真实公司实习（真实环境，成本高），要么让一个讲师在白板上画流程图讲解（LLM模拟，不可靠），而 AWM 则是搭建了一个完整的模拟办公室——每个办公室有真实的数据库、完整的操作接口、明确的工作任务和验收标准。技术路线分为两大部分：第一部分是环境合成管线，从100个种子场景名称出发，经过五个阶段自动生成1000个可执行环境，每个环境是一个SQLite数据库驱动的MCP服务器；第二部分是在这些合成环境中进行大规模GRPO强化学习训练，采用混合奖励（步骤级格式正确性 + 任务级结果验证）和历史感知训练策略。

本文的核心创新在于三个层面的设计。第一，代码驱动的状态管理：与LLM模拟环境不同，每个环境的状态空间由SQLite数据库明确定义，状态转移由Python代码确定性执行。这意味着工具调用的结果是完全可复现的，不存在LLM的随机性和幻觉问题。第二，代码增强的LLM-as-a-Judge验证：单独的代码验证或LLM判断都有缺陷——代码验证在环境不完美时会产生假阴性，LLM判断则缺乏对实际状态变化的接地。AWM 将两者结合：先用验证代码从数据库状态差异中提取结构化信号，再将这些信号连同智能体轨迹一起交给LLM判断，实现了既精确又鲁棒的奖励评估。第三，历史感知训练：推理时智能体通常使用截断的交互历史（如只保留最近3轮），但训练时如果用完整历史会产生分布偏移。AWM在GRPO优化中直接应用与推理时相同的截断策略，消除了训练-推理不一致的问题。

方法步骤详情

AWM的环境合成管线包含五个顺序执行的阶段，每个阶段都包含自动化执行和自纠正机制。阶段一：场景合成——从100个热门域名种子集出发，用LLM生成场景描述，通过CRUD适用性分类器筛选和基于嵌入的去重（余弦相似度阈值0.85），得到1000个覆盖金融、旅行、零售、社交媒体等领域的有状态应用场景。阶段二：任务生成——对每个场景提示LLM生成10个多样化的用户任务，要求任务可通过API完成（排除纯UI操作）且假设已通过身份验证，共生成10,000个可执行任务。阶段三：数据库设计与数据合成——根据场景和任务集，LLM推断所需的实体/属性/关系，生成SQLite DDL语句定义表结构，然后合成满足所有任务前置条件的样本数据（如需要更新商品库存的任务必须有带库存的商品记录）。阶段四：接口合成——分两步：先生成接口规范（端点路径、参数类型、响应结构），再生成完整的Python实现文件，每个端点通过MCP协议暴露，工具执行触发数据库读写操作实现状态转移。阶段五：验证代码生成——为每个任务生成Python验证函数，比较执行前后的数据库状态，提取任务相关信号（如记录变化、期望结果），再由LLM-as-a-Judge结合轨迹上下文做出最终判断，返回{Completed, Partially Completed, Agent Error, Environment Error}四分类。所有阶段都支持最多5次自纠正迭代：如果生成的代码执行失败，错误信息会被反馈给LLM进行修复。

技术新颖性

AWM在技术新颖性上有几个值得关注的点。首先，它将软件工程的方法论引入环境合成——数据库设计、接口规范、测试验证的三阶段对应了真实软件开发中的数据建模、API设计和质量保证，这比从文档提取工具图或程序化生成等方法更贴近实际应用。其次，两层工具抽象设计（list_tools + call_tool）将智能体与具体环境细节解耦，使同一训练流程可无缝切换不同环境，这在1000个异构环境的训练中至关重要。第三，混合奖励设计中的步骤级格式正确性奖励（违反格式规则时立即终止并给予 $r_t = -1$ 的负奖励）不仅规范了工具使用行为，还通过提前终止无效轨迹提高了约27%的训练效率。第四，验证码增强的LLM-as-a-Judge是一个巧妙的设计——纯代码验证假设任务成功可从状态完全确定观测，但在实际中这个假设是脆弱的（即使是真实服务也会有瞬时故障和部分执行），而纯LLM判断又缺乏接地证据容易被表面成功的轨迹误导。代码增强方案让两者互补：验证代码提供结构化证据，LLM提供推理灵活性。

AWM总览图。从场景合成开始，逐步生成任务、数据库、接口和验证，获得完全可执行的环境，然后在合成环境中进行多轮RL训练
Figure 2: AWM总览图。从场景合成开始，逐步生成任务、数据库、接口和验证，获得完全可执行的环境，然后在合成环境中进行多轮RL训练
AWM格式错误率对比
Figure 5: AWM格式错误率对比
AWM合成场景的类别分布
Figure 6: AWM合成场景的类别分布
AWM场景描述的词云
Figure 7: AWM场景描述的词云
Spotify环境的SQLite数据库schema可视化（部分）
Figure 8: Spotify环境的SQLite数据库schema可视化（部分）
MCP环境中的智能体系统提示
Figure 9: MCP环境中的智能体系统提示
合成的Spotify环境代码（第1/2部分）：导入和核心数据库模型
Figure 23: 合成的Spotify环境代码（第1/2部分）：导入和核心数据库模型
合成的Spotify环境代码（第2/2部分）：Pydantic模型和端点示例
Figure 24: 合成的Spotify环境代码（第2/2部分）：Pydantic模型和端点示例
Spotify环境的统一MCP接口示例
Figure 25: Spotify环境的统一MCP接口示例
Spotify环境的合成验证代码（第1/2部分）
Figure 26: Spotify环境的合成验证代码（第1/2部分）
Spotify环境的合成验证代码（第2/2部分）
Figure 27: Spotify环境的合成验证代码（第2/2部分）

实验结果

实验在三个与训练分布差异较大的基准上验证了AWM的泛化能力。在BFCLv3（函数调用综合评测）上，AWM在所有模型规模上都提升了性能：4B模型从54.92提升到64.50（+9.58），8B模型从53.83提升到65.94（+12.11），14B模型从61.25提升到70.18（+8.93），全面超越Simulator（LLM模拟环境训练）和EnvScaler（并发的编程式合成方法）。提升广泛分布在非实时、实时、多轮等类别，仅在幻觉类别略有下降，推测原因是格式正确性奖励鼓励工具使用而惩罚拒绝回答。在τ²-bench（多轮对话智能体评测）上，8B模型的Pass@1从26.44提升到33.45，Pass@4从50.72提升到55.40，与EnvScaler竞争但总体优于Simulator。在MCP-Universe（真实MCP服务器评测）上，8B模型的总体成功率从6.70提升到11.17（+66.7%），在金融和导航领域取得大幅改善。与Simulator的对比尤其重要：同样的任务和工具集，编程式环境提供的学习信号比LLM模拟更稳定，同时大幅降低了RL延迟（Simulator每步需要一次LLM调用）。环境规模消融实验显示，从10个环境到100个再到526个环境，性能单调提升，且在相同数量下AWM始终优于EnvScaler。质量分析显示，AWM在任务可行性（3.99 vs 2.94）、数据对齐（4.84 vs 3.73）、工具集完整性（4.98 vs 2.89）三个维度上都优于EnvScaler。虽然环境包含约3倍于EnvScaler的代码量，但bug增长温和，且AWM的阻塞任务比例远低于EnvScaler（14.0% vs 57.1%），这对RL训练至关重要，因为阻塞任务会截断探索并注入系统性的错误负信号。

合成管线的统计数据
Table 1: 合成管线的统计数据
环境复杂度统计
Table 2: 环境复杂度统计
与现有编程式环境的对比
Table 3: 与现有编程式环境的对比
BFCLv3、τ²-bench和MCP-Universe基准上的结果
Table 4: BFCLv3、τ²-bench和MCP-Universe基准上的结果
按复杂度分层的基准任务分析（8B智能体）
Table 5: 按复杂度分层的基准任务分析（8B智能体）
100个采样环境的质量分析
Table 6: 100个采样环境的质量分析
不同生成模型下AWM合成管线的质量分析
Table 7: 不同生成模型下AWM合成管线的质量分析
按复杂度分层的AWM任务评估
Table 8: 按复杂度分层的AWM任务评估
三种验证策略的性能对比
Table 9: 三种验证策略的性能对比
代码增强LLM-as-a-Judge可靠性分析
Table 10: 代码增强LLM-as-a-Judge可靠性分析
历史感知训练分析
Table 11: 历史感知训练分析
GRPO训练超参数
Table 12: GRPO训练超参数
AWM环境间的代码级相似度
Table 14: AWM环境间的代码级相似度
AWM生成的100个随机采样场景
Table 15: AWM生成的100个随机采样场景
三个合成环境的示例任务
Table 17: 三个合成环境的示例任务
1000个合成环境的多样性分析
Figure 3: 1000个合成环境的多样性分析
AWM相对于环境数量的扩展曲线（4B模型）
Figure 4: AWM相对于环境数量的扩展曲线（4B模型）
案例研究1：智能体成功完成任务，验证器和判断器一致标注Completed
Figure 28: 案例研究1：智能体成功完成任务，验证器和判断器一致标注Completed
案例研究2：智能体成功完成任务，验证器误判为失败，判断器纠正为Completed
Figure 29: 案例研究2：智能体成功完成任务，验证器误判为失败，判断器纠正为Completed
案例研究3：智能体任务失败，无验证器的判断器误判为Completed，有验证器的判断器正确判定为Failed
Figure 30: 案例研究3：智能体任务失败，无验证器的判断器误判为Completed，有验证器的判断器正确判定为Failed
查看结构化数据
任务指标本文基线提升
BFCLv3 函数调用综合评测 (8B模型) Overall Score 65.94 53.83 (Base) +12.11 (+22.5%)
BFCLv3 函数调用综合评测 (14B模型) Overall Score 70.18 61.25 (Base) +8.93 (+14.6%)
τ²-bench 多轮对话评测 (8B, Pass@1) Pass@1 33.45 26.44 (Base) +7.01 (+26.5%)
τ²-bench 多轮对话评测 (8B, Pass@4) Pass@4 55.40 50.72 (Base) +4.68 (+9.2%)
MCP-Universe 真实MCP评测 (8B) Overall Success Rate 11.17 6.70 (Base) +4.47 (+66.7%)
MCP-Universe 真实MCP评测 (14B) Overall Success Rate 12.29 8.38 (Base) +3.91 (+46.7%)

局限与改进

作者承认的局限性包括：(1) 训练规模受限——由于计算资源限制，仅在1000个环境中的526个环境上训练，且主要聚焦Qwen3系列模型（4B/8B/14B）；(2) 缺乏自进化能力——当前管线通过固定流程合成环境，无法让训练后的智能体参与生成新环境实现自我改进；(3) 安全性评估缺失——AWM未评估对抗性扰动下的行为，也未训练访问控制（任务生成假设已完成登录），过度积极的智能体可能执行未授权操作；(4) 合成环境的现实差距——74%的环境包含至少一个bug（虽然RL训练中环境错误率稳定在约4%），主要是未处理边界输入（44%）和数据库约束冲突（14%）。从我自己的观察来看，还有以下局限：(5) 验证机制的天花板——任务成功判定最终依赖LLM-as-a-Judge，即使代码增强后GPT-5.1仍有9.2%的奖励翻转率，这对RL训练的稳定性是有影响的；(6) 缺乏与真实环境的直接对比——虽然在OOD基准上验证了泛化能力，但没有在完全相同的真实环境中对比合成训练vs真实训练的效果；(7) 环境多样性仍有上限——尽管覆盖了多个领域，但所有环境都遵循相同的CRUD+数据库模式，对于需要复杂推理、长链规划或多模态交互的场景覆盖不足。

独立分析的弱点

独立分析的弱点及其改进方向如下。(1) 合成质量与人工审查的差距：74%的环境有bug，虽然大部分不影响核心功能，但14%的环境存在阻塞任务。改进方向可以引入更强的代码生成模型（如专门的代码智能体）或人工审核关键组件，也可以设计更细粒度的单元测试来自动捕获边界情况。(2) 验证机制对环境不完美的容错有限：虽然代码增强方案缓解了纯代码验证的假阴性问题，但Table 10显示Qwen3.5作为裁判的奖励翻转率高达23.7%，说明在开源模型上验证可靠性仍然不足。改进方向可以探索多数投票机制（如5次判断取多数）或多裁判集成。(3) 工具抽象过于简化：所有环境都抽象为list_tools + call_tool两个元工具，这虽然统一了接口但丢失了工具间的结构关系（如前置依赖、互斥关系），可能限制智能体学习更复杂的工具编排模式。改进方向可以在元工具之上引入工具图或工作流描述。(4) 训练与评测的环境分布差异较大：AWM训练环境都是CRUD+数据库模式，但评测基准包含对话交互（τ²-bench）、函数调用（BFCLv3）、浏览器自动化（MCP-Universe）等，虽然取得了OOD泛化效果，但MCP-Universe上绝对性能仍然较低（8B仅11.17%），说明合成环境与真实世界场景的差距仍然显著。

未来方向

作者在论文中提出了几个未来方向：(1) 自进化范式——让训练后的智能体参与合成新环境，形成环境生成→训练→环境改进的闭环；(2) 管线优化——当前自纠正仅处理运行时错误，可以引入LLM主动检测逻辑不一致性和隐藏bug；(3) 跨场景任务合成——当前每个环境独立，合成跨越多个环境的任务（如在电商环境下单后在物流环境追踪）是一个有前景的方向。基于本文成果还可以延伸出以下方向：(4) 将AWM的合成能力扩展到多模态场景（如包含图像、UI界面的环境），当前所有环境都是纯文本+数据库；(5) 探索课程学习策略——按环境复杂度逐步增加训练难度，可能比随机混合1000个环境更高效；(6) 研究合成环境的可迁移性——在AWM上训练的智能体能否进一步在真实环境中微调，以及合成训练是否比随机初始化提供更好的起点；(7) 引入对抗性训练——在合成环境中注入恶意工具输出、数据库损坏等对抗场景，提升智能体的鲁棒性。

复现评估

复现评估如下：代码和环境完全开源（https://github.com/Snowflake-Labs/agent-world-model），这是本文的重要优势。管线使用GPT-5作为生成模型，每100个样本的总成本约57美元（场景0.43 + 任务0.56 + 数据库3.59 + 样本数据13.75 + 接口规范23.74 + 环境代码12.81 + 验证2.21），生成1000个环境的总成本估计约570美元，这是可承受的。Table 7验证了管线的模型无关性：Claude-4.5-Sonnet达到99%的环境代码成功率，开源Qwen3.5-122B-A10B也能达到77%成功率。RL训练部分需要每步启动1024个隔离环境实例，每个实例是一个独立的MCP服务器+SQLite数据库，对计算资源有一定要求但主要是GPU（用于模型推理和梯度更新）而非环境本身。训练使用AgentFly和verl框架，超参数在Table 12中有完整记录。总体而言，复现的主要门槛是：(1) 需要GPT-5 API访问权限（或等效的强模型）用于环境合成；(2) 需要足够的GPU资源支持1024个并行环境实例的RL训练；(3) 基准评测需要适配不同格式（τ²-bench、BFCLv3、MCP-Universe各有不同的工具调用格式）。代码和数据的开源使得复现可行性较高。

论文图表

Agent World Model (AWM) 是一个合成环境生成管线，合成1000个多样化的代码驱动智能体环境，配有数据库，用于训练工具使用智能体
Figure 1: Agent World Model (AWM) 是一个合成环境生成管线，合成1000个多样化的代码驱动智能体环境，配有数据库，用于训练工具使用智能体

概念图展示了AWM的三大特性：代码驱动的环境、SQL状态一致性、1000个即用环境。通过三个彩色标签突出显示这三个核心卖点。

这是论文的核心概念图，一目了然地展示了AWM的定位和三大优势，是理解全文贡献的最佳入口。