环境是agent的老师，但这个老师不会备课

LLM agent的能力来源正在从文本数据转向交互环境。翻网页、改代码、操作办公软件，agent都要靠环境给出反馈才能学会。可这些环境几乎都是人手工搭好的，搭完之后就永远静止：不管来的是哪个agent、agent进步了多少，环境的行为都一样。

静态带来两个直接后果。第一，环境看不见特定agent的弱点，给不出针对性训练信号；第二，一旦agent把手头任务学会，环境就再没什么可教的了。训练进入平台期，瓶颈出在"老师"身上。

生成环境的路，没走通

既然手工环境贵又静态，一个自然的想法是让模型自动生成环境。但论文指出这类方法有两道坎。第一，生成管线高度领域特定：为网页导航写的管线搬不到编程场景，为工具使用写的管线搬不到另一个领域。第二，正确性难以保证：环境是LLM生成的，验证器也是LLM生成的，实践里只能大量生成再暴力过滤，仍无法保证结果可靠，而且验证成本很高。

换句话说，现成环境是"僵的"，生成环境是"虚的"。EnvHarness想找一个中间位置：改造现有的可信环境，但不动它一根汗毛。

EnvHarness：把agent harness的思路用在环境上

Agent harness是给冻结的LLM装上工具、记忆、skill等外部组件，让它能干超出纯文本生成的事，模型权重一行不改。EnvHarness把这个思路搬到交互的另一端：给冻结的环境装上可编程插件层，让环境变得可控，底层实现完全不碰。

论文的类比表格很直白：

形式化地说，一个环境可以表示成状态空间、动作空间、观测空间、转移函数、奖励和初始状态的元组。EnvHarness组件是一个环境无关的变换，它只改初始状态、过滤暴露出的动作和观测空间、更新转移机制，全程在reset/step标准接口层面操作，因此底层模拟器和评判逻辑原封不动——每个重塑后的环境都安全继承原benchmark里人工构建的可信验证器。

论文具体实现了三类组件：

Stage改初始状态。它把一串动作作用到reset()产生的初始状态上，要么提前完成部分子目标缩短任务地平线，要么引入障碍逼agent先练特定技能。论文里的例子是"把干净的杯子放到桌上"：一个Stage先把杯子藏进抽屉，agent就得先搜索再拿取，而不是一眼看到直接执行。

Contract改写交互。它有三个可配置的映射，分别作用于动作空间、转移函数和观测空间。典型用法包括：给动作加前置条件（没拿起杯子就不让执行清洁动作）、截断观测（房间描述只给前两句，逼agent多步构建空间认知）、删掉高级传送导航命令（逼agent一步步移动和搜索）。

Chain串联环境。它把另一个环境和当前环境组合成一个更长的episode，组合逻辑可以是拼接、交错或按中间结果动态分支。接上一个"加热土豆并放到台面"的后续任务，成功判定要求两个环境都被验证，agent就得学会把目标坚持到原本会停下来的地方之后。

三类组件共享同一套接口，因此可以自由叠加。同一个杯子任务，Stage把杯子藏进抽屉、Contract截断观测、Chain追加后续任务，三层套起来就是一个原环境从未提供过的训练场景。这些变换不可交换，嵌套顺序决定了初始化和交互阶段各自施加哪些约束。

EnvRigger：自动诊断弱点，自动重塑环境

组件本身是策略无关的——同一个组件对任何策略都成立。但选哪个组件、参数怎么定，必须针对具体策略的行为来。EnvRigger就是干这个的，它把策略当黑盒，走四个阶段：

Observe阶段在基础任务上跑策略，收集一批成功和失败的轨迹。失败暴露要补的短板，成功划定这些短板的边界——哪些能力已经具备、从哪里开始出问题。

Diagnose阶段分析轨迹找根因，关注重复动作死循环、长观测解析失败、误读工具约束这类系统性问题。诊断结果决定定制方向：策略挣扎就拆解步骤、简化任务；策略成功率已经100%，说明环境太宽松，暴露不出弱点，就要往难里改。

Write阶段根据诊断合成一个或多个组件。单个弱点常常需要组合拳，比如一个Stage改初始状态加一个Contract过滤后续交互，一起作为候选集输出。如果诊断发现策略依赖某个绕过学习的脆弱捷径，EnvRigger就写一个Contract在特定条件下封锁这个动作，逼策略去探索并掌握本该学会的技能。

Validate阶段用新组件包住环境，跑fresh rollout评估。验收标准只有一条：候选环境是否真能培养缺失能力，同时保持可解。可解但不具挑战性的拒绝，信号尺度不对的退回Write阶段修订，直到修订预算耗尽。通过的组件才被加入EnvHarness。

这个写-验证循环的价值在于：进入agent skill库的环境都是被fresh rollout验证过的，能教agent它真正缺的东西。而静态环境只让agent反复练已经会的行为，产出的skill常常冗余甚至有害。

五个基准，四项领域

实验覆盖ALFWorld（文本具身）、WebArena（网页交互）、SWE-bench Verified（软件工程）、OfficeQA和SpreadsheetBench（办公自动化）。技能学习（SL）范式下，EnvRigger和策略agent用同一个模型骨干（ALFWorld和WebArena用Gemini-3.1-Flash-Lite，其余用Gemini-3.5-Flash），避免"蒸馏更强外部模型"的嫌疑。训练和评测实例严格不相交。

先看总体表现。

左图是三个代表性基准上agent的最终成绩，灰色是基础agent（不给skill），蓝色是学自原始环境，橙色是学自EnvHarness环境——每个基准上橙色都更高。右图是SWE-bench Verified上的环境扩展曲线，横轴是环境数量，纵轴是解决率：EnvHarness曲线持续向上，真实环境和生成环境则明显走平。

逐表看数据。ALFWorld和WebArena的结果在Table 2：

ALFWorld上，EnvHarness环境的skill把平均分从61.7提到68.3（+5.9），其中分布外（OOD）子集从60.7涨到70.4，单点提升9.0分——这是全文最大的增益。WebArena平均从38.7到41.6（+3.1），Shop Admin子集从44.1到50.8（+6.2）。对比专用生成管线：ALFWorld上EnvHarness平均超GenEnv 5.7分、OOD超8.5分；WebArena上超VeriEnv 2.0分。

软件工程和办公自动化在Table 3：

SWE-bench Verified上，解决率从47.67到52.58（+2.70），比专用生成管线SWE-smith高2.46分；每episode平均步数从原始环境的55.01降到49.61，少5.40步（约9.8%），而学自原始环境的skill反而把步数拖到55.01。OfficeQA的EM从54.23到56.20（+1.80），SpreadsheetBench的Pass@1从46.44到49.15（+3.27）。

有个细节：SpreadsheetBench上学自原始环境的skill（45.88）反而低于无skill基线（46.44），SWE-bench上学自原始环境的skill拉长了执行轨迹。静态环境只会让agent重复它已经会的行为，练出来的skill有时是负资产。EnvHarness的写-验证循环则保证每个被采纳的环境都对agent有增量价值。

不只是skill学习

RL场景同样受益。论文用Qwen3-8B-base当策略，GRPO优化，在ALFWorld和WebShop上对比"纯原始环境训练"和"EnvHarness环境训练"：ALFWorld分布内成功率81.4→87.9（+6.5），WebShop得分75.6→79.2、成功率66.0→67.4。重塑后的环境提供的训练信号独立且有效，不是辅助数据那么简单。

Chain组件的长视界价值单独验证过：把两个随机配对的基础环境串成扩展episode，训练出的skill在单环境测试上把平均步数从53.58压到41.96，配合Stage/Contract skill（组合后成功率54.30）兼顾了最高成功率和效率——两条skill互补。

环境扩展实验很能说明机制。相同预算下，EnvHarness每批50个环境都针对"带着已有skill的策略"合成，环境和策略共同演化，300个环境时解决率47.67→54.79（+7.12）且仍在上升；同样预算下原始环境只有52.13，生成环境50.37，双双触顶。对准学习者当前能力边界去扩展，比无条件堆环境数量有效得多。

跨模型泛化也做了。Gemini 3.1 Flash-Lite、Qwen3.6 27B、Gemini 3.5 Flash、Claude Sonnet 4.6四个模型（策略与EnvRigger同骨干）全部获益，比学自真实环境的skill高2.7到3.7个绝对点，增益幅度与策略强弱基本无关——最弱和最强模型上环路都没崩。变的是诊断内容，不是环路适用性。

EnvRigger还能接受显式约束。给一个自然语言弱点描述，比如"策略不跑测试就提交补丁，修复从未被验证"，EnvRigger会生成一个Contract：提交代码前强制先运行测试套件，否则拒绝。从新轨迹里蒸馏出的skill是"改完代码先跑相关测试确认失败存在，补丁后再跑确认修复"，通用原则加可执行步骤，没有过拟合到单个任务。

局限与论文自己的解释

论文承认三个主要限制。一是设计循环成本：EnvRigger迭代合成环境要反复rollout，弱设计者需要更多轮次，消耗可观的时间和推理算力。不过这笔成本每个环境只付一次，不是每个训练episode都付，而且会随设计agent变强而下降。二是要求环境可重置：Stage要把环境放到指定初始状态，Chain要在子任务之间恢复已知状态，这排除了背后是活服务或不可撤销操作的环境——真实用户账号里发出的邮件、下的订单无法撤销，物理机器人的环境也无法回到初始构型。三是Chain只会顺序拼接：子任务之间没有语义相关性概念，组合验证靠各段验证器的合取，分支或共享中间状态的workflow表达不了。要做语义组合，得先有子任务兼容性度量，以及定义在组合目标上的验证器。

未来方向上，论文认为Stage、Contract、Chain只是第一组组件，agent harness已经长出了远超初始件的能力集，环境侧同样可以期待注入随机性或部分可观测性、暴露辅助反馈通道、把多个agent放进共享环境的组件。另一个方向是走出纯文本环境——视觉、GUI驱动或具身环境里，观测不再是符号，需要能指定和验证非文本状态的组件。

EnvHarness的价值在于换了个视角：环境构建从"从零创作"变成"包裹改造"。手里的静态benchmark不用重建，接口层加一圈插件，再让一个自动循环盯住agent的弱点持续调整，环境就重新变得有东西可教了。