EnvScaler：通过程序化合成扩展LLM Agent的工具交互环境 EnvScaler: Scaling Tool-Interactive Environments for LLM Agent via Programmatic Synthesis
自动化合成可执行的工具交互环境，用于训练LLM Agent解决多轮多工具复杂任务
前置知识
工具交互环境（Tool-Interactive Environment）
指LLM Agent在其中执行任务的沙盒环境，包含状态数据库、工具接口和交互规则。Agent通过调用工具来查询或修改环境状态，例如在电商后台中取消订单需要先查询订单状态、验证用户身份等。环境定义了工具的输入输出规范、状态转换逻辑和业务约束规则，是Agent训练和评估的基础设施。
本文的核心目标就是自动化构建这类环境，理解其组成结构（状态、工具、规则）是理解SkelBuilder和ScenGenerator两个模块设计的基础
监督微调（SFT）与强化学习（RL）
SFT是用高质量的示范轨迹对模型进行监督学习，让模型学习怎么做；RL则是让模型在环境中自主探索，通过奖励信号优化策略，学习做得更好。本文中SFT使用教师模型生成的轨迹作为学习目标，RL使用Reinforce++算法，以环境状态检查函数的通过率作为奖励信号。两种训练方式互补：SFT提供良好的初始化，RL进一步优化策略。
论文的核心实验就是将合成环境应用于SFT和RL训练，理解这两种训练范式才能理解实验设计和结果分析
环境骨架（Environment Skeleton）
指环境的程序化实现，包含三个要素：可执行程序文件（Fexec）实现状态和工具的完整逻辑、环境文档（Edoc）提供给Agent的规则说明、工具接口集（Σtool）暴露给Agent的工具名称和参数描述。骨架是环境的「骨架」，不包含具体的状态数据和任务场景。
SkelBuilder的核心输出就是环境骨架，理解其三要素组成才能理解后续ScenGenerator如何在此基础上生成完整的训练场景
轨迹验证函数（Validation Function）
用于判断Agent执行轨迹是否成功的函数，输入是环境的最终状态Sfinal，输出是True/False。不同于简单的工具调用序列匹配，验证函数检查的是环境状态是否满足预期条件，例如"订单是否已被取消"、"用户地址是否已更新"。这种方法能容忍多种等价的解决方案路径。
这是本文评估机制的核心创新，解决了传统表面匹配评估无法判断任务是否真正完成的问题
研究动机
训练LLM Agent需要丰富多样的工具交互环境，但现有环境获取方式存在严重局限。真实环境（如电商系统、航空公司后台）通常有访问限制，无法大规模用于训练。LLM模拟的环境容易产生幻觉和不一致，缺乏透明度和持久状态管理。手动构建的程序化环境虽然可控稳定，但覆盖范围有限且难以扩展。现有自动化方案要么只建模无状态函数、要么依赖预先收集的工具集或轨迹数据，缺乏自动评估机制。这导致环境合成在规模化、可控性和质量保障之间难以兼顾。
本文的目标是本文提出EnvScaler框架，目标是自动化合成多样化、可执行的工具交互环境，用于SFT和RL训练LLM Agent。具体目标包括：（1）无需依赖环境先验或预设工具集，从现有任务集中自动发现环境主题；（2）将环境描述自动转化为可执行的程序实现；（3）通过双Agent循环评估环境质量；（4）为每个环境自动生成初始状态、挑战性任务和基于规则的验证函数。
与已有工作不同的是，与现有工作相比，本文的独特切入角度在于：（1）任务驱动的环境发现——从现有开源任务集反向推断隐含的环境上下文，而非手动预设或从API文档推导；（2）程序化合成而非LLM模拟——通过代码实现环境逻辑，保证一致性和可复现性；（3）双Agent质量评估——测试Agent和检查Agent形成闭环，实际执行工具调用来验证环境行为是否符合预期；（4）状态检查而非序列匹配——验证函数检查环境最终状态而非工具调用序列，支持多种等价解法。
核心方法
EnvScaler的整体思路是将环境构建拆分为两个阶段：先构建环境骨架（SkelBuilder），再生成任务场景（ScenGenerator）。直觉上，一个完整的训练环境需要"基础设施"（状态定义、工具实现、业务规则）和"训练内容"（初始状态数据、具体任务、评估机制）。SkelBuilder负责前者，通过主题挖掘、逻辑建模、程序实现和质量评估四个步骤，自动化构建可执行的环境骨架。ScenGenerator负责后者，为每个骨架生成多样化的初始状态配置、基于状态的挑战性任务，以及细粒度的轨迹验证函数。两个阶段都以LLM作为核心合成工具，但通过程序化实现和双Agent评估保证输出质量。
本文的核心创新在于"任务驱动的环境发现"和"状态检查的轨迹评估"。与AgentScaler等依赖预收集工具集的方法不同，EnvScaler从现有任务集反向推断环境主题——假设大规模SFT任务数据中隐含了丰富的环境上下文，通过LLM二元过滤和反向推断来挖掘这些环境。另一个关键创新是双Agent评估机制：测试Agent在不了解实现细节的情况下生成工具调用，检查Agent则检查实际执行结果和状态变化是否符合预期。这比直接LLM评分更可靠，因为它是基于实际执行的。轨迹评估也从序列匹配改为状态检查，通过分解任务为多个验证条件，生成检查最终状态的函数，能捕捉部分完成且容忍等价解法。
方法步骤详情
EnvScaler的完整流程分为SkelBuilder和ScenGenerator两大阶段。SkelBuilder包括四步：（1）任务驱动环境发现——从API-Bank和ToolACE等任务集出发，LLM二元过滤保留领域特定、有状态的任务，反向推断环境描述，通过嵌入聚类去重；（2）逻辑规划——LLM丰富环境描述，推断状态定义Estate、领域规则Erule和工具操作列表；（3）程序建模——LLM将状态空间转化为类属性定义，为每个工具操作生成类方法实现，通过AST验证语法有效性，合并为完整Python类文件；（4）双Agent评估——测试Agent生成工具调用请求（正例或负例），检查Agent检查执行结果和状态变化，循环100轮，通过率低于0.85的环境被丢弃。ScenGenerator包括三步：（1）初始状态生成——LLM基于环境类定义生成JSON格式的初始状态配置；（2）任务生成——LLM基于初始状态、工具集和规则生成挑战性任务；（3）验证函数生成——LLM将任务分解为可验证的检查清单，为每个检查点生成终端状态验证函数，通过率作为轨迹奖励分数。
技术新颖性
EnvScaler的技术新颖性体现在多个方面。首先，任务驱动的环境发现是全新的思路——利用现有SFT任务数据中隐含的环境上下文，通过LLM反向推断环境主题，避免了手动预设或从API文档推导的局限。其次，双Agent循环评估机制创新性地将测试和检查分离：测试Agent只看到工具接口，检查Agent能看到实现细节，形成信息不对称的闭环评估。第三，状态检查函数相比序列匹配评估更鲁棒——将任务分解为多个验证条件，每个条件生成检查最终状态的函数，能捕捉部分完成（如任务5个条件完成了3个），且支持多种等价解法。第四，环境程序化实现保证了一致性和可复现性，避免了LLM模拟的幻觉问题。第五，整个流程高度自动化，从主题挖掘到质量评估全部由LLM驱动，无需人工干预。
实验结果
实验结果表明EnvScaler显著提升了LLM解决复杂工具交互任务的能力。在BFCL-v3 Multi-Turn基准上，Qwen3-8B从28.00提升到41.88（+13.00），Qwen3-4B从25.38提升到38.00（+12.62），Qwen3-1.7B从9.75提升到23.00（+13.25）。在Tau-Bench上，Qwen3-8B从38.19提升到44.81（+6.62），Qwen3-4B从33.44提升到41.06（+7.62）。在ACEBench-Agent上，Qwen3-8B从60.00提升到72.50（+12.50），Qwen3-4B从55.28提升到70.55（+15.27）。SFT平均带来8.67-11.57点的提升，叠加RL后进一步提升3-5点。环境质量评估显示，191个合成环境在工具-程序对齐（平均8.58）、功能正确性（平均8.97）和程序健壮性（平均8.60）三个维度都达到高质量水平。训练环境数量从0扩展到141个时，模型性能持续提升，最显著的改进发生在0到20个环境之间。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| BFCL-v3 Multi-Turn（多轮工具调用） | Overall Score | 41.88 (Qwen3-8B), 38.00 (Qwen3-4B), 23.00 (Qwen3-1.7B) | 28.88 (Qwen3-8B Base), 25.38 (Qwen3-4B Base), 9.75 (Qwen3-1.7B Base) | +13.00, +12.62, +13.25 |
| Tau-Bench（复杂规则推理） | Overall Score | 44.81 (Qwen3-8B), 41.06 (Qwen3-4B), 16.28 (Qwen3-1.7B) | 38.19 (Qwen3-8B Base), 33.44 (Qwen3-4B Base), 12.50 (Qwen3-1.7B Base) | +6.62, +7.62, +3.78 |
| ACEBench-Agent（多步骤工具协作） | Overall Score | 72.50 (Qwen3-8B), 70.55 (Qwen3-4B), 50.00 (Qwen3-1.7B) | 60.00 (Qwen3-8B Base), 55.28 (Qwen3-4B Base), 31.95 (Qwen3-1.7B Base) | +12.50, +15.27, +18.05 |
局限与改进
作者在论文中承认了五个主要局限性：（1）虽然LLM不直接作为环境模拟器，但整个构建过程依赖LLM合成，可能引入相对于真实系统的偏差（如业务逻辑、状态定义和任务设计）；（2）领域覆盖方面，EnvScaler主要针对领域特定的有状态环境，对开放环境（如网页搜索、信息检索）支持有限；（3）特征建模方面，只关注工具-状态交互，缺乏对真实系统特征的显式模拟（如接口延迟、网络波动、错误模式）；（4）模态方面，仅支持文本工具输入输出，未涉及图像、音频等多模态工具；（5）规模方面，受限于实验资源，当前仅合成约200个环境和7K场景。此外，从实验结果看，Tau-Bench上的改进相对有限，说明对深度推理任务的泛化能力仍需提升；小模型（1.7B）在RL阶段容易受到噪声奖励信号影响，直接RL效果不如SFT+RL。
独立分析的弱点
基于独立分析，EnvScaler存在几个可改进的弱点。首先，环境发现依赖于现有任务集的质量和多样性——如果源任务集覆盖不足，合成环境也会受限，可以考虑引入更多来源（如真实用户查询日志、领域文档）。其次，双Agent评估虽然比直接LLM评分更可靠，但仍依赖LLM判断"行为是否符合预期"，可能漏判复杂的规则违反，可以考虑引入更形式化的验证方法。第三，验证函数生成的质量直接影响RL奖励信号的准确性，当前由单个LLM生成可能存在噪声，可以考虑多模型投票或人类审核。第四，环境之间的多样性和去重仅基于文本嵌入相似度，可能遗漏语义相似但逻辑不同的环境，可以考虑引入更细粒度的相似度度量。第五，合成环境缺乏真实系统的复杂性（如并发、容错、性能约束），可能导致Agent在真实部署时表现下降。
未来方向
作者提出和基于成果可延伸的未来方向包括：（1）扩展环境类型——将框架应用于开放环境（网页浏览、信息检索）和多模态环境（涉及图像、音频的工具）；（2）提升环境复杂度——引入更真实系统特征，如接口延迟、网络波动、错误模式模拟；（3）扩大合成规模——利用更多计算资源合成更多环境和场景，探索规模化收益的上限；（4）优化训练策略——研究SFT和RL的最优组合方式，探索课程学习（从简单到复杂环境逐步训练）；（5）跨领域泛化——研究合成环境训练的Agent能否迁移到真实系统，以及如何缩小合成-真实差距；（6）自动化评估改进——开发更可靠的质量评估机制，减少对LLM判断的依赖。
复现评估
论文提供了良好的可复现性支持。代码已在GitHub开源（https://github.com/RUC-NLPIR/EnvScaler），包含完整的环境合成和训练流程。数据方面，使用了公开的API-Bank和ToolACE作为初始任务源，合成的191个环境和7K场景可从代码仓库获取。算力方面，训练使用Qwen3系列模型（最大30B参数），SFT约9K轨迹，RL使用Reinforce++算法，对中等规模研究机构可行。成本分析显示，合成单个环境约$1、单个场景约$0.06，总成本可控。复现难度中等——主要挑战在于需要LLM API访问（GPT-4.1用于环境构建，Qwen3用于训练）和GPU资源进行SFT/RL训练，但框架设计高度自动化，人工干预少。
论文图表
展示了一个电商订单取消场景的完整交互流程：用户提供取消需求，Agent调用find_user_id_by_email查找用户ID，再调用get_user_details获取用户详情和订单列表，最后调用return_delivered_order_items执行退货。图中还展示了环境的三个核心组成部分：规则/指南（如退货需物品状态为已送达）、数据库/状态（用户、订单、支付信息）、工具/API（get_order_details、cancel_pending_order等）。
这张图直观定义了本文研究的核心问题——工具交互环境是什么、Agent如何与环境交互、环境包含哪些要素，是理解全文的基础。