Google EnvHarness把「静态环境」用插件包成可训练 Agent让 LLM 在死物里学会决策Hugging Face 每日论文2026-08-22 精选 · 事实流论文EnvHarness: Awakening Static Worlds for Agent Learning作者Chengsong Huang、Zifeng Wang、Rujun Han、Jun Yan、Yanfei Chen、Ke Jiang、Peng Xia、Han Yu、Jiaqi Pan、Bhavana Dalvi Mishra、Jiaxin Huang、Burak Gokturk、Tomas Pfister、Chen-Yu LeeGoogleGitHubgoogle-research/envharness136 stars项目页https://envharness.com/arXiv2608.198802026-08-20一句话总结Google 这篇 8 月 20 日的论文解决了 Agent RL 训练里一个最朴素的问题当环境是静态的、没法改的时候怎么让它针对某个 Agent 的弱点变成可训练解法是把「环境修改」抽成一层可编程插件EnvHarness再用EnvRigger自动化生成这些插件二者构成「Agent 与环境共同进化」的闭环。在 5 个 benchmark、4 个领域的实验中EnvHarness 在未见过的实例上比原始环境最多高出 9.0 分执行步数减少9.8%——这意味着同样一个静态环境被插件「包」一下之后就能榨出更强的训练信号。一、要解决的真问题LLM Agent 训练的环境瓶颈过去三年 LLM Agent 论文几乎都默认一个隐含条件环境会响应。但工程化部署的现实是相反的——绝大多数真实任务环境是静态的SQL 数据库表结构固定Agent 不能改浏览器自动化DOM 结构由前端开发者决定代码仓库除非显式 fork否则 Agent 看不到修改后的状态操作系统 shell文件系统是别人管理好的。这就造成了一个尴尬的局面Agent 的策略在变强环境却原地踏步。强化学习最依赖的「奖励信号多样性」就枯竭了——RL 需要大量轨迹变体但固定环境的轨迹变体是有限的。Google 给出的解法思路很巧不改环境改 Agent 看到的「入口」。二、EnvHarness环境外再套一层「可编程插件」EnvHarness 是一个插件层harness layer外挂在静态环境外面对外暴露同样的接口但内部把 Agent 的行为做了重塑不动环境核心原环境的 verifier、状态机、奖励逻辑全部保留可编程注入用插件重写 Agent 的观察、重写它的动作映射、重写它的奖励 shape统一接口插件以标准协议挂载所以同一个环境可以接不同领域的 Agent。关键设计取舍「harness 与环境解耦」。以往改造环境的做法是改环境本身代价是不同任务要写不同的环境变体现在把改造放在 harness 层环境不变、插件可换、训练信号换思路。论文把这种结构称为「pluginable harness」——在软件工程里这就是经典的「中间件」思维但用在 RL 环境上是新的。三、EnvRigger自动生成插件让环境跟着 Agent 走仅有 EnvHarness 还不够——插件要人写就退化成「每个任务一组 hack」。Google 给的第二件工具是EnvRigger作用是自动合成 harness 组件。EnvRigger 的工作流是四步黑盒观察把目标策略当成黑盒输入一串任务让它跑出一堆轨迹失败诊断分析轨迹里 Agent 卡在哪、错在哪、把哪些状态判断错了插件合成根据失败模式生成对应的 harness 插件——比如「把这一类状态观察值换成更稀疏的表征」「把这一类动作重命名」「把这一类子任务奖励放大」新轨迹回归在合成出的插件上跑一组 fresh rollouts验证插件确实改善了 Agent 表现避免过拟合到某类样本。整个流程是policy 在变 → harness 在变 → policy 再变的循环所以论文核心叙事是「agent-environment co-evolution」——Agent 和环境共同进化。四、关键实验数字论文 abstract 给了两组核心数字评测数字Benchmark 覆盖5 个 / 4 个领域未见实例最大提升9.0 分执行步数减少9.8%解读这两组数字9.0 分是「未见实例」评估集不参与 harness 合成所以这 9 分不是过拟合而是泛化提升9.8% 步数减少说明 Agent 在改造后的环境里用更少的步数拿到更高的分这正是 harness 在「裁剪无效轨迹、放大有效信号」上的直接收益5 个 benchmark、4 个领域说明这套框架不是某个领域的玩具——从 web 自动化到代码到工具调用、再到推理任务都验证过。具体到三个基线的对比论文里没有数字细节但 abstract 明确说「优于原环境和领域特定生成 pipeline」——这意味着无论是 baseline 静态环境还是别的「环境增强」方案都被这套插件框架跑赢了。五、三个值得展开的工程机制5.1 插件与环境的解耦标准化接口EnvHarness 的插件不是「每个环境自定义」而是遵守标准接口。这带来两个工程红利可移植性同一个插件可以从 web 环境迁移到代码环境只要目标环境提供了同样的 hook可复用性训练过程中发现的「有用插件」可以组成一个插件库下一次新 Agent 来用现成的。5.2 EnvRigger 的「黑盒」特性EnvRigger 不需要访问 Agent 的内部梯度、参数或推理日志。论文 abstract 明确写「treat the target policy as a black box」。这非常重要——它意味着闭源 LLMGPT、Claude、Gemini作为 Agent 也能用策略升级了不需要重训 harness整个 pipeline 可以被作为 service 提供。5.3 Verifier 保留奖励信号不被插件污染所有插件只能在 Agent 输入/输出/奖励 shaping 层面改写不能动原环境的 verifier。这是论文一个反复出现的约束——目的是避免「奖励黑客」式的 hack插件发现了一个漏洞可以让 Agent 拿高分但实际并不解决问题。这一条对真实部署极关键——RL 训练里最容易翻车的就是奖励 hackingEnvHarness 把这道防线放在了架构里。六、这个工作对 Agent 训练的实际意义6.1 对研究者RL 训练的「环境多样性」问题有了工程级答案之前大家只能用 self-play、自动课程学习等方式扩轨迹EnvHarness 提供了一个显式、可编程、可版本管理的扩展维度跨环境迁移成为可能插件层统一了接口意味着训练好的 Agent 配合不同 harness 就能切换任务——这正是通用 Agent 的关键属性之一RLHF 与 RLHF-style 工具调用有清晰接口harness 层天然适合把人类反馈注入到 Agent 训练中。6.2 对工程团队可以在不动业务后端的前提下做 Agent 强化企业的 SQL、ERP、CRM 接口都能用 harness 包裹同一个 Agent 多个环境插件库可以让一个模型在不同业务系统间切换复用 RL 投资失败诊断自动化EnvRigger 的失败诊断模块可以单独抽出用对企业级 Agent 调试有帮助。6.3 局限依赖环境的 hook 暴露如果某个环境没有任何可观察/可重写的 hookharness 装不上黑盒策略分析有偏EnvRigger 只能从轨迹反推失败模式对极复杂决策链的诊断可能不够细致插件库的可解释性当插件组合很多时调参空间变大需要额外机制控制复杂度。七、与近一年同类工作对比工作核心机制是否动环境是否黑盒 AgentSelf-PlayAgent 内战否是Automatic Curriculum Learning自动出题否是Voyager (Minecraft)skill library否否白盒Toolformer 风格工具合成工具自动合成部分是EnvHarness环境插件化不改只包是EnvHarness 的差异化是对环境的「非侵入式增强」——其他工作要么改环境、要么改 Agent 内部而它是「把环境外面套一层东西」。这种思路在软件工程里叫「sidecar pattern」被搬到 RL 环境上是新的。八、给做 Agent 产品的人三条结论如果你在生产环境跑 Agent把环境外面加一层 harness 是性价比最高的改造不动后端、不会影响其他系统但能直接拿到「可训练」的接口把 Agent 失败轨迹归档未来用 EnvRigger 风格工具做插件合成失败日志是被低估的资产EnvHarness 的方法论直接告诉你怎么把它们变成训练信号关注 2026 下半年 Agent RL 框架的两个方向环境插件化 失败驱动课程学习这是从「环境不变 → Agent 自己进化」到「环境也跟着 Agent 进化」的范式转变。arXiv2608.198802026-08-20GitHubhttps://github.com/google-research/envharness项目页https://envharness.com/HF 链接https://huggingface.co/papers/2608.19880