Google EnvHarness 开源后 AI 评测沙箱的设计方向

Google Research 开源的 EnvHarness 给 AI Agent 评测带来一个值得关注的方向：不修改原环境内部代码，而是在统一的 reset/step 接口外增加可组合层，动态调整初始状态、可执行动作和任务组合，同时保留原来的成功判定。对工程团队来说，这比“多加几个随机题”更重要，因为它把评测环境本身也变成了可版本化、可回滚的实验对象。

官方仓库：https://github.com/google-research/envharness

项目页面：https://envharness.com/

EnvHarness 目前更适合作为研究原型和架构参考，而不是直接替换生产隔离平台。它解决的是“如何动态改造评测环境”，真正上线还要补齐进程隔离、网络策略、凭据边界、资源配额和审计留痕。

哪些信号说明静态评测环境开始失真

一套固定任务在早期很有价值，但当 Agent 已经记住常见路径、工具顺序或错误恢复方式时，分数继续上升不一定代表能力继续提高。以下信号值得启动动态环境试验：

• 同一批任务反复通过，但换一个初始状态就明显退化。
• 失败集中在特定动作组合，现有任务无法稳定复现。
• 评测脚本只能整体复制，不能只改变观测、动作规则或初始状态。
• 新增一个 benchmark 就要重写训练、评测和追踪流程。
• Agent 在原任务上形成捷径，原验证器仍通过，却不能迁移到保留集。

这些现象不等于必须采用 EnvHarness，但说明团队需要把“环境变化”从临时脚本提升为明确的接口层。

Setup、Rule、Link 分别改变什么

项目把被包裹环境抽象为 ActionableEnv，桥接层实现 reset、step、observe、evaluate、状态保存与恢复等接口。上层组件只通过这套契约工作，因此同一个设计器和评测流程可以跨不同 benchmark 复用。

最值得保留的设计原则是：改变环境给 Agent 看到什么、允许做什么、从哪里开始，但不要改掉负责判断任务是否完成的原验证器。否则新环境可能只是在修改答案标准，迁移回原任务时会失去可比性。

先用 smoke 任务做快速判断

试用时不要直接投入完整训练预算。先挑一个任务短、依赖少、验证器稳定的 benchmark，跑通环境检查、少量语料生成和小规模评测。官方仓库为各实验目录提供 README 与 smoke 脚本，团队应先按对应目录确认依赖，而不是把所有 benchmark 一次装进同一环境。

# 获取研究原型，并把试验固定在独立目录中。
git clone https://github.com/google-research/envharness.git
cd envharness

# 先按目标 benchmark 的 README 安装依赖，再检查环境桥接是否完整。
python scripts/check_env.py toy24

# 只运行少量任务的 smoke 协议，避免第一次试验就消耗完整预算。
bash experiments/toy24/reproduce_smoke.sh

快速判断不只看最终分数。至少确认四件事：同一任务能否从保存状态恢复；失败是否留下可读 trace；禁用某个组件后是否回到原环境；新技能能否在未改造的保留任务上继续生效。

生成代码必须落在独立隔离层

EnvHarness 的 Rule 可以由设计器生成真实 Python，并在隔离子进程中编译执行。这个做法让环境改造能力更灵活，也把风险从“配置写错”提升为“动态代码执行”。研究仓库中的隔离子进程是重要起点，但生产评测平台仍需按自己的威胁模型补全防线。

• 进程与文件：每个任务使用独立 worker，根文件系统尽量只读，写入限定到一次性工作目录。
• 网络：默认拒绝外连，只开放模型端点或任务明确需要的服务，并记录目的地址。
• 凭据：设计器、策略 Agent 和评分器使用不同权限；任务容器不能读取宿主机通用密钥。
• 资源：设置 CPU、内存、进程数、磁盘、执行时长和工具调用预算。
• 追踪：保存组件版本、任务 ID、动作、观测摘要、退出原因和验证结果，但清理敏感字段。
• 验证器：在策略执行结束后由独立上下文调用，避免答案或评分逻辑进入 Agent 可见范围。

回滚路径要比新增组件更简单

动态环境层越灵活，越需要确定性的停用方式。每个 Setup、Rule、Link 都应有不可变版本号和启用范围，评测记录中同时保存原环境版本与组件清单。发生异常时，优先回到“原环境 + 原验证器”的基线，而不是在线修改生成代码继续跑。

EnvHarness 强调组件可以堆叠，但生产平台不要默认无限堆叠。建议先限制每个试验只改变一种因素，再逐步组合；这样出现回归时，责任组件更容易定位。

告警和复盘应该看哪些指标

论文与项目页报告了多个 benchmark 上的改进，包括保留任务收益和交互步数下降。这些结果说明方向值得研究，但不能直接当作团队自己的收益预测。内部复盘至少同时观察：

• 原环境、改造环境、保留任务三组成功率，而不是只看训练内分数。
• 每个成功任务的交互步数、工具调用数与环境重置次数。
• 组件编译失败、超时、资源限制、验证器拒绝等失败类型分布。
• 同一策略在不同随机种子下的方差，避免一次幸运结果。
• 动态环境生成成本与最终能力收益，确认是否比人工补题更划算。

如果成功率提升只出现在被包装环境，回到原任务或保留任务后消失，说明组件可能教会了环境特定捷径。相反，如果迁移率稳定、交互步数下降且失败 trace 更容易解释，才有理由扩大试验。

采用前还要确认的现实边界

官方仓库明确说明 EnvHarness 不是受正式支持的 Google 产品，也不属于 Google 开源软件漏洞奖励计划。它目前适合研究、原型和内部评测平台验证。生产采用前，应自行评估依赖稳定性、模型供应商配置、benchmark 许可证、容器或浏览器依赖，以及生成代码的安全审查方式。

从设计方向看，EnvHarness 最有价值的启示不是某个单一分数，而是把 Agent、环境和验证器拆成三个可以独立演进的边界：策略负责行动，环境层负责构造学习压力，原验证器负责保持结果可信。团队如果能先把这三层隔离清楚，再谈动态生成环境，评测体系才不会因为灵活性增加而失去可解释性。

常见问题

EnvHarness 是通用容器沙箱吗？

不是。它重点解决环境接口的动态包装与学习任务生成，生产级容器、网络、密钥和资源隔离仍需由底层平台提供。

是否必须修改现有 benchmark？

需要实现对应的 ActionableEnv 桥接接口，但核心目标是不修改环境内部逻辑和原验证器。

什么时候不适合引入？

当现有任务还没有稳定验证器、状态无法保存恢复、失败 trace 不完整时，先补基础评测工程；否则动态层只会放大不可解释性。