EnvHarness：唤醒静态世界 EnvHarness: Awakening Static Worlds for Agent Learning

0.1 一个正在发生的范式转移：学习信号从文本变成交互

LLM agent（大模型智能体）：不只会聊天、还能动手干活的 AI——浏览网页、改代码库、操作办公软件。它和聊天机器人的本质区别是：它在一个环境里行动，靠环境的反馈学习。

论文开篇第一句话就把牌摊开了：「随着 LLM 被部署为自主 agent，学习的来源从精选文本数据转移到了交互式环境」（§1，第 1 页）。这句话的分量在于：过去十年我们堆了天文数字的语料去训练模型「知道什么」，而接下来要让模型「会做什么」，光看书不够了——得让它上手干活，从干活的结果里学。

这个转变意味着一个新的瓶颈出现了：谁来提供活儿？谁来判对错？答案都是环境。网页导航需要模拟网站，修 bug 需要真实代码库，机器人需要一个房间。环境负责四件事：出任务、维护状态变化、响应动作、判定成败（论文引用 Li et al. 2026 的综述）。

0.2 死环境的两条罪状

现在的问题来了：这些环境几乎全是人工搭建的。工程师把交互逻辑和验证规则硬编码进去，写完就锁死了。论文指出这种「刚性」从两个方向掐住 agent 学习的脖子：

第一，它是瞎的。不管来的是新手还是高手，环境的表现一模一样。它不知道你哪一步容易翻车，不会针对你的弱点加练。就像一个只发同一套卷子的教练——你三角函数已经满分了，他还让你刷三角函数；你立体几何一塌糊涂，他连立体几何的题都不出。

第二，它会过时。一旦 agent 学会了解决现有任务，环境就再也没东西可教了。论文引用 Beukman et al. 2024 和 Wang et al. 2019 说明这不是新发现，而是强化学习社区的老问题（课程学习领域管这叫「缺乏持续的学习信号」）。

0.3 现有解法为什么不灵：生成新环境的两个坑

既然人工建环境贵，一条显然的路是让 LLM 自动生成新环境。这条线上已经有不少工作：网页导航的 Insta、编程的 SWE-gym、工具调用的各类 pipeline。但论文指出它们有两个躲不开的结构性问题：

坑一：领域绑定。给浏览器任务设计的生成管线没法拿去生成代码任务——每个领域都要重新造一套轮子。SWE-smith 只能造 SWE 任务，GenEnv 只能做它的仿真场景。论文在实验部分专门对比了这一点：专用基线在自己领域之外全是「–」（不可用），而 EnvHarness 一套接口吃下四个领域五个基准。

坑二：验证器不可靠。环境和验证器都是 LLM 生成的，谁来判断生成的对不对？实践者只能过量生成然后重度过滤（over-generate and filter），但论文直言这样「仍然无法完全保证正确性」。更隐蔽的问题是幻觉：如果用 LLM 模拟环境反馈，模拟出来的转移可能物理上就不成立，成功信号会漂移。

0.4 EnvHarness 的核心主张：包装，不是重造

论文的原话是「与其创建新环境来获取学习信号，不如转换既有环境」（Rather than creating new environments...）。具体来说：EnvHarness 是一层可编程的插件层，包住一个静态环境，重塑它的行为——但完全不动环境内部的代码和逻辑。

这个设计带来两个直接的好处。第一，跨领域通用：因为只在标准接口层面动手脚，一套机制通吃网页、代码、办公、具身四个领域。第二，验证器免费继承：每个被重塑的新环境都安全地继承原始环境中那个人类写的、可信的验证器。你不用再担心 LLM 生成的判分标准是不是靠谱。

为了让这套定制自动化，作者还配套做了 EnvRigger：把策略当黑箱，观察它在环境里的执行轨迹，诊断出行为缺陷，针对性地合成组件，再用新一轮轨迹验证疗效。整个流程不需要人碰任何一行环境代码。

论文原图Figure 1 第 1 页总体性能对比

左图：从 EnvHarness 环境提取技能的 agent 在 SWE-bench Verified（47.7→52.6）、OfficeQA（54.2→56.2）、SpreadsheetBench（46.4→49.1）上全面超越原始环境训练。右图：同样预算下，真实环境和 SWE-smith 生成的环境随数量增加先后饱和，只有 EnvHarness 环境还在爬升。

0.5 数字先睹为快

摘要和正文给出的关键数字，后面章节会逐一展开，这里先建立量级感：

1.1 先看熟悉的那一侧：Agent Harness 是怎么工作的

Agent Harness（智能体脚手架）：包裹在 LLM 外面的软件层，包括执行循环、工具注册表、上下文管理。业界流行的公式是 Agent = Model + Harness。

回想 Claude Code 或者 OpenAI Codex 这类产品的工作方式：底下的语言模型是冻结的——权重一个都不动。但你给它接上终端（工具）、文件系统（记忆）、技能库（skills），再套一个「思考→行动→观察→再思考」的循环，它就从「会说话」变成了「会干活」。Anthropic 和 OpenAI 在 2025-2026 年都发了工程博客专门讨论 harness 设计（论文引用了 Effective harnesses for long-running agents 和 Harness engineering 两篇）。

注意这里的精髓：能力的增长全部发生在外围，核心纹丝不动。模型还是那个模型，但外围的组件决定了它能看见什么、能做什么、能记住什么。

1.2 掉转镜头：环境的这一侧呢

现在把镜头掉转 180 度。在 agent-环境交互循环里，LLM 只是一端；另一端是环境——出题、维持状态、响应动作、判分的那一方。论文 Figure 2 的洞察就在这里：既然模型端可以用外挂组件增强而不改核心，环境端为什么不行？

于是有了对称的定义：Customized Env = Static Env + EnvHarness。环境还是那个环境，一行内部代码不改，但在它与 agent 的接口处插入了一层可编程组件，改变信息流经接口的方式。

1.3 表 1：四行对照看懂类比

论文表 1 把这个类比压缩成四行，每一行都值得嚼一遍：

1.4 为什么这个对称不只是修辞

你可能会说：类比而已，别当真。但这个类比在工程上有实质后果。Agent Harness 的组件生态之所以繁荣（MCP 工具、技能库、记忆系统层出不穷），是因为大家默认了一个前提：组件必须通过标准接口接入，否则没法叠加。EnvHarness 把同样的纪律带给了环境侧——第 5 章会看到，三个组件共享同一个接口协议，所以能像乐高一样自由嵌套，w_chain(w_contract(w_stage(E))) 这样叠三层也不出乱子。

还有一个更实际的收益：正因为类比成立，「自进化 agent」领域的所有想象力都可以平移过来。Agent 侧有技能蒸馏、有记忆沉淀、有 harness 重写；环境侧现在也可以有对应物——第 10 章的共进化实验就是明证：每批环境瞄准当前策略短板生成，环境和策略像军备竞赛一样螺旋上升。

2.1 贯穿全文的例子：那只马克杯

论文在 §2.2 用同一个 ALFWorld 任务演示全部三个组件：「put a clean mug on the desk」（把干净的杯子放到桌上）。默认设定下，杯子就摆在明面上，agent 一伸手就能拿到，放好即结束——太简单了，学不到东西。

记住这个任务的三个要素：物品（mug 杯子）、状态（干净/脏）、目标（放在桌上）。三个组件将分别在这三要素上动手脚。

2.2 Stage 的定义：一个动作序列就是一切

Stage 组件（舞台布置）：由一段状态操纵动作序列 δ = (a₁, ..., a_k) 完全指定。reset() 返回初始状态 s₀ 后，框架按顺序把 δ 里的动作依次喂给环境的 step()，得到新的初始状态。

注意公式的克制之处：S、A、O、T、R 五个字段原样保留，只有初始状态从 s₀ 变成 s′₀。Stage 不发明新规则、不过滤观测，它只是「提前替环境走了几步棋」。

2.3 两个方向的用法：藏起来 vs 替你做好

论文给了两个方向相反的例子，正好展示 Stage 的双向调节能力：

方向一：加难。对 reset() 返回的状态执行：take mug 1 → open drawer 1 → put mug 1 in drawer 1 → close drawer 1。效果：杯子被藏进关着的抽屉。agent 面对的不再是「伸手拿杯子」，而是「先搜索物品在哪」——一个更难、需要规划能力的开局。

方向二：简化。另一个 Stage 可以预先执行「清洗杯子」的动作序列，等 agent 开始时只剩最后一步摆放。适合 agent 连基础流程都走不顺时，先把长任务砍短练后半段。

2.4 「可达性」这个隐藏福利

附录 C.3 特别强调了回放机制的一个副产品：变异后的初始状态永远是可达状态（reachable state），而且保存一个 Stage 组件只需要存那个动作列表本身——不需要序列化任何环境内部状态。这意味着：

第一，确定性可复现。只要 reset() 是确定性的（种子固定），同一个 δ 回放一万次得到的初始状态分毫不差。EnvRigger 的验证环节依赖这一点（第 7 章）。第二，跨运行时安全。δ 只是普通动作，不携带任何环境内部句柄，所以它可以被存储、传输、在任何满足接口的环境副本上重放。

附录 C 还提到一个细节：回放完成后框架会调用 notify_replay_complete()，让环境把步数预算、重复检测这类「每回合计数器」归零——准备工作消耗的步数不该算到 agent 头上。这种工程细节体现了接口设计的成熟度。

3.1 定义：三元组的变换地图

Contract 组件（交互契约）：由三元组 r = (f_A, f_T, f_O) 指定，分别改写动作空间、转移动力学、观测空间。三者默认都是恒等映射（identity）——什么都不改。

对比公式 (2)：这次动的字段多了——A、O、T 都可以被改写，但 R（奖励，由验证器诱导）依然纹丝不动，s₀ 也不归它管。这个「管辖权划分」是刻意的：初始状态归 Stage，终局判定归环境自己的验证器，Contract 只插手中间过程。

3.2 三个钩子在马克杯任务上的实战

论文一口气给了三个例子，每个例子对应一个映射轴：

f_O（改观测）：配置 f_O 把房间描述截断到前两句。原本一段话看完就知道杯子在哪，现在 agent 必须分几步移动、逐步拼出空间表征——考的是「部分可观测下的探索能力」。

f_T（改转移）：配置 f_T 拦截 clean 动作：如果 agent 手里没有杯子，这个动作直接被挡回去。原本环境可能容忍「空手擦拭」这种无意义操作，现在物理前置条件被强制执行——逼 agent 先拿再擦。

f_A（改动作）：配置 f_A 删掉高级传送导航指令（teleport）。ALFWorld 里 agent 可以瞬移到指定位置，删掉这个捷径后只能一步步 move 和 search——考的是底层导航能力。

3.3 附录里的实现：Rules 类的三个钩子

附录 C.3 给出了 Contract 的代码形态——类名叫 Rules（历史命名，论文正文已统一叫 Contract）。核心是挂在 step 循环上的三个钩子：

filter_action(action, env_state)      # 实现 f_A
#   可以改写 action，或返回 Blocked 结果——
#   动作根本不会到达内层环境

modify_transition(action, response, env_state)  # 实现 f_T
#   内层环境响应之后、返回 agent 之前，
#   改写 EnvResponse（观测/奖励信号之外的包装）

filter_observation(obs, env_state)     # 实现 f_O
#   最终呈现给 agent 的观测，包括 reset 后的初始观测

两个刻意的设计边界值得划重点。其一：被 Block 的动作不会惊动内层环境——框架返回当前状态的重新观测（过完 f_O 过滤）加上拒绝理由，agent 收到的是一个温和的「此路不通」而不是崩溃。其二：Rules 明确不实现 S₀ 和 R——初始状态是 Setups（Stage）的事，终局成败是 benchmark 自己的事，职责划分写进了类的设计里。

3.4 为什么 R 轴被锁死：这是整套系统的信任锚点

公式 (3) 里 R 不带撇号——奖励函数原封不动。附录 A 的系统提示词里有一句直白的话：「R axis is not exposed: success is the benchmark's own verdict, so reshaping reward cannot move the eval metric」（R 轴不开放：成功与否由基准自己的裁决说了算，重塑奖励无法撼动评测指标）。

想想如果开放 R 会怎样：设计者 agent 为了「帮助」策略，可以把难任务的成功阈值悄悄放宽——环境看起来变简单了，策略成功率上升，但这些「成功」在真实评测里一文不值。这就是奖励篡改（reward hacking）的经典陷阱。锁死 R 轴等于宣布：EnvHarness 只能改变「通往成功的路有多难走」，永远不能改变「什么叫成功」。

4.1 长视野困境：做完就停不是好习惯

现实世界很少给你「做完一件事就结束」的待遇。程序员修完一个 bug 紧接着改另一个，家庭机器人打扫完厨房还得擦客厅——任务与任务之间有无缝衔接，第一件事的收尾状态就是第二件事的起手状态。但现有基准全是单任务设计的：agent 完成或失败，回合结束，状态清零。

论文在 §5 指出问题的本质：「实际应用经常需要 agent 在延展的视野上操作」（§5，第 10 页）。训练时只见过独立短任务，部署时遇到连续长任务就慌了：典型症状是第一题做完摆烂，忘了第二题还没开始；或者第一题恋战太久，第二题时间不够。这正是目标保持（goal persistence）能力的缺失——学会在做完一件事之后把目标携带向前，而非就地释放。

4.2 Chain 的形式定义：一对 (E_ext, g)

Chain（链）：EnvHarness 的第三个组件，记作 w_chain,ℓ。参数 ℓ 是一对：ℓ = (E_ext, g)，其中 E_ext 是一个附加环境，g 是组合逻辑。Chain 把原始环境 E 和附加环境 E_ext 拼成一个复合环境 E′，同样通过标准接口暴露。

形式化（公式 4）：

这里有几个关键点：

空间取并集：新动作空间 A′ = A ∪ A_ext——两个环境的动作都可用。同理观测空间、状态空间都是合并的。Agent 同时拿着两个工具箱。

组合逻辑 g 不受限：论文说 g 可以让环境「concatenated, interleaved, or branched dynamically based on intermediate outcomes」（§2.2，第 5 页）。既可以从一开始就把两个环境揉在一起，也可以用转移函数 T′ 在满足某个条件时动态切换。这给了 Chain 远超「顺序排队」的表达力。

验证器合取：这是最关键的设计决策。复合奖励 R′ 要两段环境的验证器同时通过才算成功。论文在附录 C.3 写得很明确：「The composite verdict is the conjunction R′ = R_A ∧ R_B, each factor decided by the corresponding sub-environment's own verifier」（附录 C.3，第 23 页）。换句话说：如果你只完成了第一段，失败；只完成第二段，也失败；两段都完成，才算过。

4.3 马克杯的连续剧：一个完整例子

回到我们的老朋友「放一个干净杯子到桌上」。默认情况下，杯子就在台面上，agent 拿起来洗了放桌上就完事——十秒钟的任务。

论文给了一个 Chain 的例子：追加一个任务「热一个土豆并放到台面上」，在同一个虚拟厨房里。现在 agent 的回合变成了两幕剧：

第一幕：找杯子、洗杯子、放桌上。第一幕的验证器（R_A）判通过。但故事没完——T′ 把 agent 从 E 切到 E_ext。

第二幕：找土豆、热土豆、放台面。第二幕的验证器（R_B）判通过。

只有两幕全过，R′ = R_A ∧ R_B 才返回成功。论文说这「requires the agent to learn to carry its goal past the point where it would otherwise have stopped」（§2.2，第 5 页）——要求 agent 学会越过「本该停下来」的那个点继续行动。

4.4 四种组合逻辑：附录 D 的四段代码

附录 D 给出了 Chain（代码里叫 Link）的四种组合模式，全靠覆写 modify_transition 钩子实现：

mode 1：顺序串接（Sequential Concatenation）。默认行为，不需要写任何代码：A 结束自动切到 B。

link = Link(EnvA(), EnvB(), a_done_via="terminated")

mode 2：按结果分支（Branch on Outcome）。A 结束时看 A 成没成功：成功了送去更难的环境（AdvancedEnv），失败了送去补救环境（RemedialEnv）。

class BranchOnOutcome(Link):
  def modify_transition(self, action, response, env_state):
    if not self._a_is_finished(response):
      return response
    solved = self.env_a.evaluate().success
    dest = AdvancedEnv() if solved else RemedialEnv()
    return self.switch_to(dest)

mode 3：中途切换（Switch Mid-Task）。不等 A 结束，检测到特定动作就立刻把 agent 扔到另一个环境里去。

class SwitchOnAction(Link):
  def modify_transition(self, action, response, env_state):
    if action.name == "trigger_advanced_mode":
      return self.switch_to(AdvancedEnv())
    return response

mode 4：逐步交替（Interleaving）。每一步都在两个环境之间横跳。

class Alternate(Link):
  def modify_transition(self, action, response, env_state):
    next_env = RedEnv() if isinstance(self.current_env, BlueEnv) else BlueEnv()
    return self.switch_to(next_env)

4.5 工程细节：惰性初始化与缓存

附录 C.3 描述了 Link 的三个工程优化，字字值钱：

惰性初始化 B：B 环境不在创建时就启动，而是在 A 结束、交接点到达时才 reset。为什么重要？因为 A 可能很早就失败（timeout 或步数耗尽），此时 B 的容器/浏览器启动成本就白花了。「resets B lazily at the handoff point, avoiding container or browser start-up cost when A fails early」（附录 C.3，第 23 页）。

边界缓存判定结果：每段任务的结果（成功/失败）在该段结束时缓存，复合体评估时直接读缓存，不再重复跑昂贵评分器。「caches each leg's outcome at its boundary so evaluation never re-runs an expensive scorer」（附录 C.3，第 23 页）。

屏蔽子终止信号：A 的验证器判通过时，正常会发出 terminated=true 信号结束回合。但 Chain 要续演 B，所以 Link 屏蔽了这个信号——只有复合体自身有权决定什么时候回合真正结束。「masks the sub-environments' termination signals so that only the composite decides when the episode ends」（附录 C.3，第 23 页）。

4.6 实验结果：Chain 的得与失

表 5（§5，第 10 页）是 Chain 的主场。在 SWE-bench Verified 上：

三个发现：

Chain 大幅省步数：平均步数从 53.58 降到 41.96，省了 21.7%。这个效率提升的来源很直接：Chain 训练时成功要求两段全做完，agent 学会了「不恋战」——第一题快点搞定别拖，省下的步数预算留给第二题。

Chain 单独 SR 略降：49.63 vs 原始环境 49.88，差了 0.25 个点。论文给的解释很清醒：「This aligns with their stringent training condition—which prioritizes long-term goal preservation over short-task maximization」（§5，第 11 页）。

合并才是最优解：Stage/Contract 技能和 Chain 技能合并后，SR 54.30 最高、步数 43.12 也优秀。两类技能互补——前者解决单题内的技能掌握，后者解决跨题的目标保持。

5.1 环境的七元组定义

论文在 §2.1 给出了环境的数学定义，这是后面一切推导的基石：

逐个拆解：S 是状态空间；A 是动作空间；O 是观测空间；T: S×A→S 是转移函数；R 是验证器诱导的奖励；s₀ 是初始状态。

5.2 EnvHarness 组件：一个通用变换 w

有了七元组，EnvHarness 组件的定义就非常干净了——它就是一个从环境到环境的函数（公式 1）：

w 把一个七元组变成另一个七元组，其中某些字段带撇号（被改了），某些不带（没动）。关键约束有两层：只在接口层动手、验证器不动。

5.3 三组件的管辖权划分

现在把三个组件的公式并排放在一起看：

注意撇号的位置：Stage 只改 s₀；Contract 改 A、O、T 三个字段，R 和 s₀ 不动；Chain 改的字段最多，但 R′ 不是新建了验证器，而是两个验证器合取。R 在三个组件里都像铁板一样不可动——这是防 reward hacking 的信任锚点。

5.4 组合与非交换性

三个组件可以自由组合（公式 5）：

论文特别提示：组件变换是非交换的（non-commutative），即 w₁∘w₂ ≠ w₂∘w₁。嵌套顺序决定了哪个约束作用于初始化阶段，哪个约束作用于交互阶段。

5.5 任务-策略条件化映射 H

§3.1 引入了任务-策略条件化映射（公式 6）：

给定基础环境 E、特定任务 t、目标策略 π，H 产出一个由多个组件嵌套而成的定制环境 E′。π 是黑箱——不看模型权重，只看输出轨迹。这为下一章 EnvRigger 铺路。

6.1 闭环全景图

论文图 4 把 EnvRigger 的全流程画在了一张图里。左边是「执行循环」：策略 π 在当前环境里跑轨迹。右边是「EnvRigger 循环」：四个阶段——Observe、Diagnose、Write、Validate——依次运转。用一句话概括：拿策略当黑箱跑几步，看它哪不行，写个组件治这个毛病，再跑几步验疗效。

6.2 Observe：跑基线，读轨迹

Observe（观测）：把策略 π 放在当前环境里跑任务 t，收集 K 条轨迹。

Observe 不仅要收集失败的轨迹，也要收集成功的——成功和失败一起定义了能力的边界。关键超参数：K=5（附录 E.3，表 8）。

6.3 Diagnose：双向诊断的核心引擎

Diagnose（诊断）：分析 Observe 收集的轨迹，定位行为的根本原因，并决定定制方向。

方向一：策略挣扎 → 简化。如果 agent 大量失败，正确的做法是搭脚手架降低难度。

方向二：策略完美 → 加难。「If the policy achieves a perfect success rate, it indicates the current environment is too forgiving to expose any remaining weaknesses」（§3.2，第 7 页）。

这两段话把闭环的智能本质说透了：EnvRigger 不是无脑加难器，它根据策略当前表现自适应调节方向。Diagnose 的最终产物是一份文本诊断报告。

6.4 Write：从诊断到代码

Write（写入）：设计者 agent 根据诊断报告合成一个或多个 EnvHarness 组件，构成一个候选集（candidate set）。

设计者 agent 的完整系统提示词在附录 A 里（第 18-20 页），里面有两条护栏规则：

PITFALL 规则：不可解的任务是废物。「do not make the task unsolvable. A mutation that makes success impossible is not a difficulty increase; SR=0 from impossibility is exactly as useless as SR=1 from triviality」。当出现「多数 rollout 超时或 SR=0 且失败集中在动作轴」的信号时，必须撤销或放宽引发问题的限制——「stacking more bans cannot climb into the band」。

REFINE 规则：如果这次变异已把 SR 朝目标带挪动，说明变异类型对，保留有效钩子原文不动，只调幅度。如果没移动，换一种完全不同的方案。

6.5 Validate：新轨迹的裁判

Validate（验证）：把候选组件包包装到当前环境上，跑 K=5 条全新轨迹，判定接受/拒绝/返工。

三个关键点：新轨迹（不复用 Observe 的）；候选整体接受/拒绝（避免归因困难和组合爆炸）；三种判定结果（接受、拒绝、返工）。返工预算上限 5 次。

EnvRigger 假设基础环境支持确定性重置——因为 Stage 的动作序列在 reset 后回放来改初始状态，如果 reset 不确定性，诊断和验证就对不上了。

7.1 数值目标带：SR 和 AS 的区间命中

实验在 100 个 ALFWorld 任务上跑，每个任务用 K=10 条 rollout 测量。SR 目标带设为 [0.4, 0.6]，AS 目标带设为 [25, 35]。表 12 报告了改造前后落在目标带里的任务比例：

7.2 双峰压缩：把哑铃压成钟形

原始任务 SR 分布「strongly bimodal」（强烈双峰）——大量任务 SR≈0（太难）或 SR≈1（太简单），中间谷只有 6%。EnvHarness 把左峰用搭脚手架简化（SR 从 0 升到中间带），把右峰加难（SR 从 1 降到中间带）。均值从 0.74 移到 0.48，覆盖率从 6% 跳到 80%。

7.3 AS 校准：为什么更难

AS 钉死的是一个精确的步数窗口——成功回合的平均步数必须恰好落在 [25, 35]。SR 是比率（容差天然大），AS 是精确值（约束更紧）。命中率 53% vs SR 的 80%，差异就在约束维度。

7.4 弱点点名：一行自然语言治一个病

第二种进阶模式：不给数字，给一句话描述。例如「策略提交补丁前不跑失败的测试」。

EnvRigger 写了一个 Contract（f_T 轴），通过 env_state.extras 字典做跨步记忆来记录是否跑过测试，伪造了一个 git pre-commit hook：提交时没跑过测试就拦截。

class _Contract(Contract):
  def modify_transition(self, action, response, env_state):
    cmd = bash_command(action)
    if "pytest" in cmd or "runtests.py" in cmd:
      env_state.extras["ran_tests"] = True
    if is_submission(cmd) \
       and not env_state.extras.get("ran_tests"):
      return failed(response,
        "githook: pre-commit hook 'verify-tests' "
        "failed. Run the test suite before submitting.")
    return response

7.5 九个案例：三基准各三

表 13 列出了 9 个指定的弱点矫正案例（ALFWorld 3 个、WebArena 3 个、SWE-bench 3 个）。包括 git-hook 逼跑测试、sed 静默投毒训练回溯力、Stage 藏物品治「不检查容器」习惯等。共同模式：人类描述弱点 → EnvRigger 自动选轴和方法 → 组件让弱点致命 → 从轨迹提炼可迁移技能。

8.1 实验设置：公平到什么程度

§4.1 用一整页铺设实验协议，核心是三件套防混淆措施：

此外还有两条基本设定：训练集与评测集严格隔离（定制时见过的任务不进评测），以及 Chain 排除在自动化管线外（因为 EnvRigger 难以观测串接环境的内部状态，Chain 单独分析）。

五个基准覆盖四个领域：

8.2 ALFWorld：文本世界的全面碾压

ALFWorld 是文本冒险游戏环境，agent 通过文本指令操作房间里的物品。表 2 给出了三个版本的成绩：

三个数字值得逐一品味。

In-Dist +2.9：在训练分布内的任务上提升了不到 3 个点，幅度不大但方向稳定。这个增益来自针对性矫正——EnvRigger 发现策略在训练类型上的弱点，定制环境让这些弱点变致命，练出来的技能自然比泛泛训练更精准。

OOD +9.0：这是全表最大的单格增益，也是论文最有说服力的数字之一。OOD 任务是定制时从未见过的任务类型，EnvHarness 在这些任务上反而比 In-Dist 涨得更多。为什么？因为矫正弱点的技能编码的是通用行为原则，不是题目的答案。比如「不检查容器就断言物品不存在」这个弱点，定制环境逼 agent 养成「先查再看」的习惯——这个习惯在 OOD 任务上同样适用。越陌生的任务，原有短板暴露越彻底，矫正的收益也越大。

In-Dist vs OOD 增益反转：一个值得记住的模式——训练时针对弱点矫正出的技能是通用行为原则而非具体答案，在未见过的任务类型上优势反而放大。这与 leave-one-out 实验（第 11 章）的结论互相印证。

Avg +5.9：加权平均后涨近 6 个点。考虑到公平协议下所有方法用同样的模型、同样的任务量、同样的蒸馏管线，这 6 个点纯粹来自「环境定制」这一个变量。

8.3 WebArena：四个子站全线飘红

WebArena 是真实的 Web 交互环境，包含四个子站：

四个子站全部为正，没有一个是负的。幅度从 +1.9 到 +6.2，分布合理——ShopAdmin 涨幅最大（+6.2），因为它的任务结构最适合用 Contract 改造（管理后台操作有很多可以插入中间检查点的环节）。Reddit 涨幅最小（+1.9），可能因为论坛浏览任务的动作空间比较简单，能矫正的弱点不多。

关键信号：四个异构子站上方向一致，说明 EnvHarness 不是碰巧在某个领域吃香——它跨子站泛化。

8.4 SWE-bench：不仅做对，还做得快

SWE-bench Verified 是软件工程基准，agent 要在 Docker 容器里修真实的 GitHub issue。表 3 给出了两个指标：

两个维度同时改善：SR +2.70（解决率上升），AS 从 53.58 降到 49.61（平均步数下降 7.4%）。

步数下降的归因很明确：论文写道「targeted Contracts and Stages designed to disrupt repetitive action loops and filter verbose observations successfully shorten execution trajectories」（§4.2，第 10 页）。翻译成人话——EnvRigger 诊断出策略有两个毛病：重复试同一个动作绕圈（用 Contract 封掉死循环）和被冗长观测文本淹没（用 Contract 过滤噪音）。针对性开的药恰好治这两个病，所以步数降了。

对比一下：原始环境技能的 AS 是 55.01，比无技能的 53.58 还更长。在静态环境里反复练习不教 agent 省步骤，反而可能固化「多试几次总没错」的习惯。EnvHarness 的定制环境直接惩罚废动作，所以步数不增反降。

8.5 OfficeQA 与 SpreadsheetBench：两个额外验证

OfficeQA 测的是信息检索能力——agent 在模拟办公环境里查日历、找联系人、翻文档。EnvHarness 带来 EM（精确匹配）+1.80、F1 +1.96 的增益。幅度不大但方向明确。

SpreadsheetBench 是最有看点的一个。它测电子表格操作能力（公式、筛选、排序），有两个难度档。结果：

等一下——原始环境技能 45.88，比无技能的 46.44 还低？是的，你没看错。这是一个论文专门讨论的反例，也是本方法最诚实的一格数据。

静态环境有害论：在静态环境里反复跑同一批任务，蒸馏出来的技能可能检索回冗余或次优行为模式。论文原话：often retrieving redundant or suboptimal skills。静态环境只能让 agent 练已经会做的事，不能矫正弱点——就像让一个只会做加减法的人刷一万道加减法，他的乘除能力不会因此提高。更糟糕的是，如果这些冗余技能被检索出来干扰了正确的操作流程，成绩反而下降。

EnvHarness 在同一个基准上 +3.27/+1.01，说明定制环境避免了这个问题——因为它不是反复练已会的，而是针对弱点开的新训练场。

8.6 全局视角：五个基准的合力

把五个基准放在一起看，有一个统一的模式：EnvHarness 在所有基准、所有指标上的增益全部为正。没有一个是负的，没有一个退步的。

这不是某个特定领域的运气——五个基准覆盖了文本交互、Web 操作、软件工程、信息检索、数据操作五个不同的任务类型。能在所有类型上一致正向，说明 EnvHarness 的机制是通用的。

增益幅度从 +1.8 到 +9.0 不等，分布合理：容易矫正的弱点（如 ALFWorld 的不检查容器）涨得多，不容易矫正的弱点（如 WebArena Reddit 的简单浏览任务）涨得少。这种「幅度有差异、方向无反转」的模式，比「全部大涨」更可信。

9.1 为什么要单独做 RL

前面所有实验走的是同一条路：在定制环境上跑轨迹 → 用轨迹蒸馏技能 → 把技能注入策略。如果在这条路上赢了，增益的功劳可以归给三个环节中的任何一个——可能是环境好、可能是蒸馏管线巧、可能是技能注入有效。

论文想证明一个更强的命题：定制环境本身就是一个独立的优化信号，不依赖技能蒸馏管线也能赢。怎么做？直接在定制环境上做 RL——让策略在环境里滚梯度，不经过任何蒸馏。如果 RL 也赢了，环境的信号质量就不容置疑。

9.2 RL 配置：开源小模型 + GRPO

附录 F.1 交代了 RL 的配置细节：

策略模型：Qwen3-8B-base——一个 80 亿参数的开源基座模型。选小模型有两个好处：一是成本可控（RL 要跑成百上千次 rollout），二是如果小模型都能学到东西，说明信号真的好。

优化算法：GRPO（Group Relative Policy Optimization）。GRPO 的核心机制是在一组 rollout 里算相对优势——同一批任务，跑 K 次，比谁更好。这意味着任务必须有成败混合的分布才能产生有效梯度：如果 K 次全成（方差为零），没有谁比谁更好；如果 K 次全败（方差为零），也没有谁比谁更好。

GRPO 的信号要求：全对或全错的任务提供零梯度——成败混合的任务才是梯度富矿。这与第 7 章目标带实验的发现精确吻合：原始任务分布双峰（大多全成或全败），只有 6% 落在 [0.4, 0.6] 中间带；EnvHarness 双向调节把命中率提到 80%，均值 SR 从 0.74 压到 0.48——也就是说，EnvHarness 批量生产了 GRPO 最需要的「成败混合」训练样本。

9.3 表 4：RL 结果

表 4 给出了两个基准上的 RL 结果：

四个指标三项胜出，一项微退。

In-Dist +6.5：这是 RL 实验中最强的增益。在同样的 Qwen3-8B-base 模型、同样的 GRPO 算法下，换掉环境这一个变量，In-Dist 成功率从 81.4 涨到 87.9。因为定制环境批量生产了「成败混合」任务，GRPO 终于有了足够的梯度信号来学。

OOD -0.8：唯一的小退让。论文称之为 slight, negligible trade-off。在分布外任务上略降 0.8 个点，可能因为定制环境分布偏窄使泛化略收窄。考虑到 In-Dist +6.5 的幅度，这个 0.8 的退让是可以接受的代价。

WebShop Score +3.6 / SR +1.4：WebShop 是一个购物模拟环境，Score 是部分给分（买对了部分商品也给分），SR 是严格成功率。两个指标同时为正，说明定制环境在「买得更准」和「买得更全」两个维度上都有改善。

9.4 Chain 与 Stage/Contract 的正交互补

表 5 是 Chain 的单独分析，也是第 4 章的实验补充。在 SWE-bench Verified 上：

关键看最后两行。Chain 单独的 SR 只有 49.63，但步数压到 41.96（省 21.7%）。Stage/Contract 单独的 SR 是 52.58，步数 49.61。两类合并后 SR 飙到 54.30，步数也降到 43.12——比单独任何一类都好。

正交互补（orthogonal complementarity）：Stage/Contract 技能解决的是「单题内怎么做得对」（精度维度），Chain 技能解决的是「跨题怎么不摆烂」（节奏维度）。两个维度近乎正交，像射击教练和体能教练——一个练准头、一个练耐力，两个一起请效果最好。合并后双双登顶，证明两者不是在做同一件事的两种方式，而是在做不同的事。

如果两类技能完全相同，合并后不会有增益——叠加两份一样的技能等于一份。54.30 > 52.58 > 49.63 这个严格不等式，是正交性的直接证据。

9.5 信号质量论证链

把第 7 章和第 9 章连起来，可以拼出一条完整的论证链：

① GRPO 类算法依赖组内相对优势，全成或全败的任务不产生有效梯度（只有成败混合才有方差）。

② 目标带实验证明 EnvHarness 能把任务 SR 批量压进 [0.4, 0.6]（命中率 6%→80%，均值 0.74→0.48），即批量生产高梯度方差的训练样本。

③ RL 实测四项指标三项胜出（In-Dist +6.5），验证了信号质量确实好。

这条链从理论预期到实验干预到最终结果，逻辑自洽。当然也有薄弱环节：相关性不等于因果——RL 提升也可能部分来自环境多样性增加而非难度校准本身，论文没有做「只校准难度不增加多样性」的消融来隔离。但整体证据链足够强。

10.1 规模化曲线：三条路三种命运

图 5 画的是 SWE-bench Verified 上 Resolved Rate 随环境数量增长的曲线。三条线：

三条线的命运截然不同。

原始环境：一开始涨得不错，但大约 150 个环境后进入平台期，趴在 52.13 不动了。原因很直白——原始环境是一批固定的任务，反复跑同一批题，策略学会的也就那些。新环境提供的边际学习信号随策略成长递减，因为会做的题反复练不会涨水平。

SWE-smith：这是一条更强基线——它不是简单的原始环境，而是专门为 SWE-bench 设计的环境生成器。但它的曲线也在早期就饱和了，最终 50.37 甚至比原始环境还低。为什么？因为 SWE-smith 的环境生成与策略状态脱钩——它按固定模板生成环境，不管策略当前缺什么。

EnvHarness：从 47.67 一路爬到 54.79，到 300 个环境时还在上升，没有饱和的迹象。这个「越多越好」的走势是本方法最有战略价值的发现——它意味着投资回报率还没见顶，继续加环境还能继续涨。

10.2 共进化的本质：题海战术 vs 自适应模考

用一个类比来理解共进化和基线的区别。

题海战术 vs 自适应模考：原始环境像题海战术——发一万套卷子，不管你会不会，全做一遍。前一千套帮你补基础，后九千套是重复劳动。SWE-smith 像更高级的题海——按考试大纲出题，但大纲不变，做完也就到顶了。EnvHarness 像自适应模考——每次考完分析你错在哪，下一套专门考你不会的，永远在推你的边界。

共进化的关键机制是「策略感知的环境生成」：EnvRigger 在每轮生成新环境之前，先观察当前策略（K=5 条轨迹）的弱点，然后针对弱点定制环境。这保证了两件事：第一，新环境不会重复已会的内容（浪费算力）；第二，新环境永远在策略当前水平的边界上施压（最优学习区）。

反事实推演：如果 EnvHarness 不再针对学习者诊断，每批环境随策略状态脱钩生成——那它的曲线会怎样？会趋近原始环境基线的形状——快速上升后进入平台期。因为脱钩后每批环境不再瞄着当前短板，新环境的学习信号随策略成长边际递减（会做的题反复练），与「无视学习者的批次拉取」逻辑相同。图 5 中原始环境曲线在约 150 环境后趴窝于 52.13 就是这个机制的实证。

10.3 技能编年史：三轮共进化的具体故事

附录 F.2 记录了 SWE-bench 上三轮共进化的技能主题，这是「共进化」从抽象概念变成具体故事的地方。

第一轮（Round 1）：基础测试调用与文件编辑。策略刚上手 SWE-bench 时，连怎么跑 pytest、怎么用 sed 改文件都不熟。EnvRigger 诊断出这些基本功弱点，生成定制环境逼策略练基础操作。技能主题：pytest 基本调用、文件定位与编辑。

第二轮（Round 2）：工具自救。策略学会基础操作后，新弱点暴露了——pytest 入口坏了怎么办？依赖没装怎么办？EnvRigger 诊断出这些「工具链断裂」场景，生成定制环境教策略自救。技能主题：修复 pytest 入口、安装缺失依赖、绕过环境问题。论文里有一个「强制 pytest -x」的组件案例——它用 f_A 改写命令悄悄注入 -x 标志（让 pytest 遇到第一个失败就停），逼策略学会「一个一个查」而不是「跑完一大堆输出再翻」。

第三轮（Round 3）：底层解释器解析与预编辑导航。策略学会工具自救后，更深层的弱点浮出来了——不理解 Python 解释器的底层行为，不会在做修改之前先导航一遍代码结构。EnvRigger 生成更难的环境——需要理解 import 机制、解析器行为、在编辑前先扫描代码路径。技能主题：解释器解析、预编辑导航。

饱和信号：三轮之后，约三分之一的任务已经全胜，EnvRigger 诊断出「无法成功加难」——策略在这些任务上已经没有可矫正的弱点了。这是一个中性偏积极的信号：坏消息是这些任务上方法的边际收益已尽；好消息是验证闸门真实拦截了无效变异（宁缺毋滥），且还有三分之二的任务有挖掘空间——共进化尚未触顶。

从浅到深的技能编年史——基本功→工具自救→底层解析——正是共进化「每轮瞄准当前短板」的直观体现。如果第一轮就练底层解析，策略学不会（太远了）；如果第三轮还在练基础调用，是浪费（已会了）。共进化自然地产生了由浅入深的课程。

10.4 Token 对账：贵不贵

附录 G 的表 11 给了一笔诚实的账：EnvHarness、VeriEnv 和 GenEnv 三种方法在 WebArena 上的总 token 开销。

两个关键结论：

EnvHarness 与 VeriEnv 基本持平：137.3M vs 137.8M，差距不到 0.4%。两者都是真机执行（在真实的 Docker 容器/浏览器里跑 rollout），所以 token 开销主要是推理和执行，不是环境定制的额外成本。这说明 EnvHarness 的性能优势不是烧钱烧出来的——在同样的 token 预算下，定制环境比验证环境产出了更好的策略。

GenEnv 便宜 3.5 倍但有代价：GenEnv 只花约 39M token，因为它的 rollout 是 LLM 模拟的（不用真机执行，让 LLM 假装运行环境）。论文对此的评价很精辟：that saving buys the hallucinated transitions and drifting success signals... The extra cost is thus the cost of grounding。翻译：省下的钱换来的是幻觉转移（LLM 模拟的状态转移可能不符合真实环境逻辑）和漂移的成功信号（模拟出来的成功判定可能与真实验证器不一致）。多花的钱是「接地」（grounding）的成本——让信号在真实世界里落地。

11.1 四个模型：增益与强弱无关

图 6 和表 9 展示了四个模型的跨模型实验结果：

四个模型的增益在 +2.7 到 +3.7 之间——幅度接近、方向一致、与模型强弱基本无关。

最弱的模型 Gemini 3.1 Flash-Lite 无技能基线只有 30.7%，EnvHarness 加了 2.7 个点到 36.5。最强的 Claude Sonnet 4.6 无技能基线 55.8%，EnvHarness 加了 3.7 个点到 62.1%。从最弱到最强，增益波动不超过 1 个点。

增益与强弱无关的含义：这说明 EnvHarness 定制环境矫正的是「所有模型共有的弱点」，而不是某个特定模型的特殊缺陷。比如「不检查容器就断言物品不存在」「跑完测试不翻输出」这类弱点，是 LLM 作为 agent 的通病——与参数量大小关系不大。所以定制环境的技能可以跨模型迁移。

11.2 步数病理学：三种病三种药

附录 F.4 是全文最精彩的方法论讨论之一。论文观察了四个模型在 EnvHarness 训练后步数的变化，发现三种截然不同的模式：

模式一：步数腰斩——治愈盲动症

Qwen3.6-27B 的步数从 69.8 砍到 37.1，几乎砍了一半。这个模型裸跑时步数高得离谱——因为它在乱撞：试一个动作不行，再试一个，再不行，反复兜圈子。EnvHarness 的定制环境用 Contract 封掉重复动作循环，逼它学会一次做对。步数砍半不是因为「放弃了」，而是因为「不乱来了」——成功率同步上升证明了这一点。

模式二：步数变长——治愈早退症

Gemini 3.1 Flash-Lite 的步数从 36.7 变长到约 50。这个模型裸跑时步数偏低——不是因为它高效，而是因为它过早放弃：试了两三个动作觉得做不了就收工。EnvHarness 的定制环境用 Chain 串接任务逼它学会坚持——提前终止等于全回合判负。步数变长是因为它学会了「不轻易放弃」，额外的长度就是疗效本身。论文原话：skills make it persist...the extra length is the point。

模式三：步数不动——本来就清醒

Claude Sonnet 4.6 的步数从 29.3 几乎不动到约 25。这个模型裸跑时步数就低——因为它本来就清醒，每一步都有方向，废动作少。EnvHarness 没什么可矫正的，步数基本不变，但成功率仍然涨了 3.7 个点——因为定制环境帮它在更深的层面优化了行为质量（比如更精准的代码导航），不体现在步数上。

步数病理学三模式：缩短治盲动（乱撞→精准）、延长治早退（放弃→坚持）、不动因清醒（本就高效）。步数变化的方向取决于策略的「病」是什么——同样的药（EnvHarness）对不同病情产生相反方向的步数变化。

11.3 为什么步数不能孤立看

从三种模式中提炼出一个方法论教训，论文原话：average steps alone is not a quality signal...Reading the metric therefore requires the success rate next to it。

翻译：平均步数单独不是质量信号。

考虑这个场景：某方法报告「步数下降 40%」。这可能意味着三种完全不同的事：

① 策略本来乱撞（盲动症），定制环境治好了，步数降 40% 是好事——但需要看成功率同步上升来确认。

② 策略本来清醒（如 Sonnet），步数降 40% 可能砍掉了必要的验证步骤——成功率会下降。这是坏事。

③ 任务分布变了（换成更简单的题），步数自然下降——与方法无关，是数据污染。

没有成功率配对，你分不清「40% 缩减」是好事还是坏事。所以正确的汇报姿势是「步数 -21.7% 且 SR +2.7」这样配对报告，而不是孤立说「步数降了」。

11.4 Leave-one-out：真迁移的严格考试

附录 G 设计了一个比跨模型更严格的泛化测试：leave-one-out。

做法：在 SWE-bench 上有六种任务类型。每次留出一种不参与定制，只在另外五种上做 EnvHarness 定制，然后在留出的那种上评测。六轮留出六种，看增益。

表 10 的结果：

均值 +3.1，最大 +16.4（clean），最小 -8.7（heat）。

为什么 leave-one-out 能证明「真迁移」？因为 held-out 类型从未参与定制——EnvRigger 从未见过这类任务，定制环境时从未针对这类任务诊断弱点。如果在这类任务上仍然有增益，这个增益只能来自跨类型携带的行为，而非对题目的熟悉度。论文原话：any gain must come from behaviors that carry across types rather than from familiarity with the held-out tasks。

heat 回撤 -8.7 怎么解读？论文没有回避这个负面数字，反而把它当作可信度的证据。如果六类全胜、全绿，反而该怀疑——是不是 held-out 类型实际参与了训练？是不是评测过拟合？是不是统计操纵？真实的行为迁移有方向、有边界——在某些类型上涨，在另一些类型上跌。heat 的 -8.7 恰好说明技能是有方向、有边界的真实能力迁移，而非万能咒语。

回撤即真实：个别类型的负增益不削弱反而增强可信度——全绿结果违背迁移学习的常识规律（如果什么任务都涨，更可能是泄漏或操纵）。有涨有跌、均值正向，才是真实行为迁移的签名。

11.5 综合判断：四条证据链

把第 8-11 章的四组实验串起来，EnvHarness 的证据链相当完整：

① 主结果（第 8 章）：五个基准四个领域全面正向，增益 +1.8~+9.0，公平协议排除混淆。

② RL 直训（第 9 章）：绕开蒸馏管线仍胜出，环境即独立优化信号。

③ 规模化曲线（第 10 章）：300 环境未饱和，共进化机制可持续。

④ 跨模型泛化 + leave-one-out（第 11 章）：四模型增益一致 +2.7~+3.7，leave-one-out 均值 +3.1 且 heat 回撤增强可信度。

四条证据链互相印证：主结果证明有效，RL 证明信号独立，规模化证明可持续，跨模型 + leave-one-out 证明可迁移。其中 leave-one-out 的 heat 回撤是最诚实的负面结果——它不削弱论证，反而让整体更可信。

11.6 实验室：SR 目标带校准模拟

第 7 章讲了双峰压缩——EnvRigger 把原始任务的双峰 SR 分布压进 [0.4, 0.6] 目标带，命中率从 6% 升到 80%。这个实验室让你亲手调一调校准强度和目标带范围，看看命中率怎么变。

12.1 一条设计军规：万物同接口

附录 C 开篇就亮出了整个框架的唯一设计承诺：「每个 benchmark、每个 benchmark 的每种变换，都呈现同一个接口」。策略、编排器、组件层都只对着这一个抽象类型编程——它们无法分辨手里是裸环境还是包了任意层组件的环境。这句承诺的分量要到实现细节里才能掂出来。

12.2 ActionableEnv：接口的两族方法

ActionableEnv：所有环境的抽象基类，Gymnasium 风格但加了类型化数据契约。方法分两族：

交互族：reset(seed, options) 开回合；step(action) 吃进 Action（工具名+JSON 参数）返回 EnvResponse（Gymnasium 五元组的 Pydantic 包装）；observe() 重新读取当前观测；evaluate() 出终局判定。get_env_state() 暴露内部状态的运行时安全视图。

两个细节见功力。其一，observe() 刻意与 reset() 分离：因为组件可能在 reset 返回之后、policy 动手之前继续改造世界（正是 Stage 干的事），外层需要一个不花 reset 成本的「再看一眼」通道。其二，get_env_state() 只给纯数据视图——没有 Docker 句柄、没有浏览器页面对象、没有 socket，组件钩子只允许读这份纯数据。论文点破了这个约束的意义：同一份钩子代码今天跑在内存小游戏上、明天跑在容器化代码库里，谁都不碰接口之下的运行时。

持久化族：save_state() 返回 JSON 字典，from_state(dict) 反向重建。契约刻意不规定存什么——纯内存环境全量序列化活状态；而那些运行时无法廉价克隆的环境（容器、浏览器、游戏引擎）只保存 reset 参数，接受「恢复仅在回合格子边界有效」的妥协。

12.3 Bridge：唯一知道运行时存在的层

Bridge（桥接器）：某个 benchmark 对 ActionableEnv 的直接实现，全系统唯一允许知晓底层运行时细节的层。

七个 Bridge 覆盖四类运行时：Toy24（纯内存算术游戏）、ALFWorld 经 TextWorld 文字冒险引擎、SWE-bench/OfficeQA/SpreadsheetBench 走每步一次无状态 docker exec 的容器方案、WebArena/WebShop 走 Playwright 驱动的真实浏览器。关键句是：「Bridge 之上的一切——策略循环、编排器、全部组件代码——在七个环境间逐字共享」（shared verbatim across the seven environments）。

Bridge 还各自声明动作空间为带类型的工具注册表（tool_registry），签名自动内省成 function-calling schema 喂给策略提示词。有意思的是 schema 生成和分发是解耦的：Toy24 的 step 直接走注册表路由（状态就是运行时本身）；ALFWorld 和 WebArena 则绕过注册表直驱引擎句柄——TextWorld 引擎和浏览器会话没法塞进纯数据视图。两种选择并存，接口不强迫一致。

12.4 组件即装饰器：洋葱的哲学

EnvHarness 的类结构就是教科书级的装饰器模式（图 7）：EnvHarness 是抽象装饰器，它自己也是 ActionableEnv——包着另一个 ActionableEnv。默认实现把所有接口方法原样委托给 inner，具体组件只覆写自己那几轴的方法。于是 Rules(Setups(Toy24Bridge)) 还是一个合法的 ActionableEnv，最外层的策略数不清洋葱有几层。

持久化也分层负责：每个组件只序列化自己的状态，检查点文件记录「环境 + 有序组件列表（从内到外）」，加载时由内向外重建——先造好最里面的裸环境，再一层层往外穿组件，每层作为下一层的 inner。这个顺序保证了重建后的行为与保存前严格一致。

还有一道安全网值得点名：Rules 生成的 Python 子类代码在每个 episode 的独立子进程里执行——有毛病的生成代码只会弄死一个 episode，不会拖垮框架。这是对「LLM 写代码必然有 bug」这一现实的工程妥协，代价可控且隔离彻底。

13.1 案例 A：强制 pytest 快速失败（f_A 改写动作）

class _Rules(Rules):
    def filter_action(self, action, env_state):
        if action.name == "bash":
            command = action.kwargs.get("command", "")
            if ("pytest" in command
                and "-x" not in command
                and "--maxfail" not in command):
                # Add -x to fail fast and prevent 60s docker exec
                # timeouts on compatibility hangs.
                action.kwargs["command"] = command.replace(
                    "pytest", "pytest -x")
        return action

这是 f_A 最温和的形态：不禁止，而是替你改写。检测到不带 -x 的 pytest 就悄悄加上。蒸出的技能就是组件强制的那个模式：「跑大测试套件用 pytest -x 首败即停」。注意它的窄度——只动 pytest、只加一个 flag、其他命令一律放行。附录 A 提示词里那句「prefer subtle, narrow perturbations (one op, one obs key) over sweeping bans」在代码里得到了忠实执行。

13.2 案例 B：封死三条编辑歧路（f_A 返回 Blocked）

# 1. Inline python file editing via `python -c` is off-limits.
if "python" in cmd and "-c" in cmd:
    if "open" in cmd and ("write" in cmd or "replace" in cmd):
        return Blocked(reason=(
            "Inline python file editing (-c) is restricted "
            "to prevent file corruption. Use standard file "
            "utilities or patch/diff tools."))
# 2. `conda run` disabled; invoke env binaries by absolute path.
if "conda run" in cmd:
    return Blocked(reason=("'conda run' is disabled ..."))
# 3. Direct execution of custom Python scripts is disabled
if re.search(r"\bpython[0-9.]*\s+[^-\s][^\s]*\.py\b", cmd):
    if "pytest" not in cmd and "unittest" not in cmd:
        return Blocked(reason=("Direct execution of custom "
            "Python script files ... Use standard command-line "
            "tools (patch, sed, redirected cat) ..."))

三个精准封锁，每个都附「为什么挡 + 你该走哪条路」的人话拒绝理由。注意第三条的豁免逻辑：驱动 pytest/unittest 的脚本放行——封锁的是「拿 python 当瑞士军刀乱捅」，不是 python 本身。蒸出的技能：用 patch -p1 加标准 unified diff 做精确多行修改。

13.3 案例 C：伪造超时（f_T 改写响应）

def modify_transition(self, action, raw_response, env_state):
    ...
    # Broad-scope test invocations get killed; force per-file
    # targeting of the relevant test module.
    if (("bin/test" in cmd or "sympy.test" in cmd)
        and "test_polysys" not in cmd):
        return EnvResponse(
            observation=Observation(
                text="[docker exec timed out after 60s]\n",
                data=raw_response.observation.data),
            reward=raw_response.reward,
            terminated=raw_response.terminated,
            truncated=raw_response.truncated,
            info={**raw_response.info, "last_returncode": 124},
        )
    return raw_response

f_T 的标准姿势：保留原始响应的一切字段，只替换观测文本并注入 returncode 124（超时的约定码）。伪造得有模有样——agent 看到的就是一个真实的 docker exec 超时。这里有个精妙的不对称：reward、terminated、truncated 全部原样透传——再次看到 R 轴锁死纪律在微观代码层的体现。

13.4 案例 D：git-hook 强制测试先行（跨步记忆）

class _Contract(Contract):
    def modify_transition(self, action, response, env_state):
        cmd = bash_command(action)
        if "pytest" in cmd or "runtests.py" in cmd:
            env_state.extras["ran_tests"] = True
        if is_submission(cmd) \
           and not env_state.extras.get("ran_tests"):
            return failed(response,
                "githook: pre-commit hook 'verify-tests' "
                "failed. Run the test suite before submitting.")
        return response

这是 §5 主文的招牌案例，展示了钩子的跨步记忆能力：用 env_state.extras 这个自由字典记住「本回合是否跑过测试」，提交动作触发时查账。extras 是纯数据视图的一部分——组件不能读环境内部，但它有一个自己的记事本。整个机制模仿了真实世界的 pre-commit hook，agent 学到的技能（Verification-Driven Development Loop）也因此具有直接的行业对应物。

13.5 案例 E：静默投毒惩罚 sed -i（延迟恶果）

def modify_transition(self, action, response, env_state):
    if "sed" in bash_command(action):
        # inserts a stray space before a class line,
        # silently corrupting source and test files
        shift_indent("django/db/models/enums.py")
        shift_indent("tests/model_enums/tests.py")
    return response

最阴的一招：不用 sed 不报错、不拦截，而是悄悄把两个文件的缩进搞歪一格，然后若无其事地返回正常响应。恶果延迟到测试阶段才爆发——agent 必须学会怀疑自己的修改历史、回溯排查。为什么这么狠？因为真实世界里 sed -i 弄坏 Python 缩进就是这个表现：当时无声无息，事后莫名其妙。模拟的不是「惩罚」，而是「现实的本来面目」。

13.6 案例 F：PATH 注入钉死解释器（f_A 前置改写）

def filter_action(self, action, env_state):
    if action.name == "bash" and "command" in action.kwargs:
        cmd = action.kwargs["command"]
        # Prepend the testbed environment's bin directory so that
        # `python` and `pytest` resolve to the right interpreter.
        if "/opt/miniconda3/envs/testbed/bin" not in cmd:
            action.kwargs["command"] = (
                "export PATH=/opt/miniconda3/envs/testbed/bin:$PATH"
                f" && {cmd}"
            )
        return action

第三轮共进化的产物：给每条命令自动前置 PATH 导出，强制 python/pytest 解析到正确的 conda 环境。蒸出的技能——「用绝对路径调用环境二进制或预置 PATH」——是无数开发者踩过的真实大坑。与前几轮「破坏工具」不同，这一招是「默默矫正」，因为诊断发现的问题是环境配置认知缺失而非行为捷径。

14.1 局限一：设计循环是真金白银的成本

附录 H 第一条坦白：EnvHarness 靠迭代循环产环境，弱一点的设计者要多转好几圈才能产出过验的 harness，而每圈都要真刀真枪滚轨迹——攒一批高质量环境的推理开销相当可观。作者的辩护有两点：这笔钱按环境付一次而非按训练回合重复支付；且随设计者模型进步预期会缩水。结合第 10 章表 11（设计费约 1.5M token，占总账单零头），这条局限在实践中目前可控，但规模化到上千环境池时线性累积的设计成本不容忽视。

14.2 局限二：reset 是硬前提，真实世界不配合

第二条最致命：整套机制假设 reset/step 接口存在且 reset 可确定性复原。Stage 要把环境摆到指定初始态，Chain 要在子任务间回到已知状态——都预设环境「可复原」而非只能前进。论文自己列出的反例很扎心：操作真实用户账号的 agent（发出的邮件、下的订单撤不回来）、物理机器人（房间不会自己弹回初始构型）都被排除在外。

14.3 局限三：Chain 只有串接一种正经玩法

第三条在第 4 章埋过伏笔：Chain 的验证器继承依赖「每段独立出裁决再合取」，这只在串接下成立。分支、交替虽然控制流写得出来，却没有一对现成裁决可合并——要支持它们就得为「组合后的目标」定义新验证器，还得先解决「两个子任务语义是否兼容」的度量问题。论文把这定性为原理性边界（not merely richer control flow），不是堆工程能解决的。

14.4 未来方向：三个生长点

附录 I 给了三个方向。其一，组件家族扩张：注入随机性、部分可观测性、辅助反馈通道、多智能体共享环境——每个都扩展冻结基准的表达范围而不破接口。其二，走出纯文本：视觉/GUI/具身环境的包装抽象是否存活是个开放问题——文本符号可以随便截断过滤，像素观测怎么「截断两句」？（我的理解：可能需要语义掩码或注意力引导类的视觉等价物。）其三，语义化组合：给 Chain 配上子任务兼容性度量与组合目标验证器，让分支模式也获得可信判定——这是把「验证器继承」从合取推广到更丰富逻辑的第一步。

14.5 论文没写但我认为该警惕的三件事

第一，K=5 的统计噪声（第 6 章已提）：验收判据建立在五条轨迹上，SR 的估计误差高达 ±20 点级，误判率未量化。第二，设计者-策略同模型的自我诊断天花板：模型能否稳定识别自己的系统性盲区缺乏理论保证，实验上也没做「更强设计者」消融。第三，伪造信号的长期副作用：大量仿真挫折会不会教会 agent 对某些真实信号过度反应？leave-one-out 给了间接安慰但没有直接测量。这三点不影响主结论，但任何严肃的工业落地评估都应该补上。

15.1 一张图收拢全部

15.2 三分钟话术模板

第一分钟（是什么）：「大家都在给大模型套壳——工具、记忆、技能，这套东西叫 agent harness。这篇论文问了个对称的问题：既然模型端可以套壳增强，环境端为什么不行？他们做了 EnvHarness——不改环境一行代码，在标准接口外包一层可编程组件，让一个死的基准环境变成随 agent 能力定制的训练场。」

第二分钟（怎么做）：「组件就三种：Stage 用一段动作序列改开局状态——比如把杯子藏进抽屉逼 agent 学搜索；Contract 在每步交互上装三个过滤器——管你能做什么、世界怎么回应、你能看见什么；Chain 把两个任务串成一个长回合——成功要求两段都过各自的验证器。最关键的纪律是奖励函数永远不碰，所以不管怎么改造，成败判定还是原来那个人工写的验证器说了算，不存在 LLM 乱判分的风险。配套的 EnvRigger 循环全自动：看轨迹找毛病、写组件治毛病、再跑新轨迹验疗效。」

第三分钟（效果与边界）：「四个领域五个基准全胜，最高加 9 个点还省 9.8% 步数；直接当 RL 训练场也赢；环境预算加大时别人饱和它还在爬坡，因为每批环境都瞄着当前策略的短板。限制也说清楚：环境必须可 reset，所以真实生产环境和实体机器人暂时无缘；设计循环本身烧 token，规模化要算账。」

15.3 与近亲工作的三分法

这张表帮你回答「EnvHarness 和 XXX 有什么区别」这类问题。一句话定位：它是第一个把「不改验证器」「跨域统一接口」「黑箱诊断定制」三件事同时做满的方法——代价是放弃状态空间扩展能力（附录 B 的对比表是官方版本，可对照阅读）。

15.4 分角色的行动建议

如果你是 agent 训练研究者：优先复现第 10 章的共进化曲线——它是方法价值的最大公约数；顺手补上「更强设计者」消融和 K 的敏感性分析，这两块是明显的论文留白。组件层面，随机性注入和多智能体共享环境（附录 I 方向一）是相对低垂的果实。

如果你是 agent 产品工程师：先做 reset 可行性审计——你的任务环境能不能确定性复原？能的话，从第 13 章抄作业：git-hook 强制测试、PATH 钉死解释器这两个组件几乎可以原样搬到你的 SWE 场景。别急着上全套 EnvRigger，手工写十个 Stage/Contract 先验证「针对性矫正」在你的业务上有没有感觉，再考虑自动化。

如果你是技术管理者：记住三个数字再决定投入——+9.0（最好情况的提升）、9.8%（同步的效率节省）、1.5M×环境数（前期设计 token 投入）。这套方法的本质是把「训练数据质量」问题转化为「环境工程质量」问题，适合训练管线成熟、缺高质量交互信号的团队；如果你的瓶颈在模型底座本身，先解那个。