OpenEnv ← Agent World Model: Meta 把 Snowflake AWM 1K 环境包装成标准 OpenEnv server

§1 · OpenEnv + AWM 的桥接背景

1.1 OpenEnv 是什么 — 30 秒回顾

OpenEnv 是 Meta PyTorch + HuggingFace 在 2025 年 10 月开源的 agentic RL 环境标准,核心立意是"让 RL trainer 不必关心环境长什么样,只调三个方法 —— reset() / step(action) / state()"。它的具体形式是:

• 每个 env 是一个 FastAPI server,封进 Docker 容器,容器之间互相隔离;
• 通信走 WebSocket(JSON 序列化的 Action / Observation),client 侧暴露 EnvClient 基类;
• action / observation 强类型(Action 基类 + Observation 基类,dataclass 风格);
• 支持 sync / async 两套 API,默认 async(async with EnvClient(...) as env),.sync() 包一层做同步;
• CLI 是 openenv init / openenv push:前者从模板搭新 env 骨架,后者一键推到 HF Spaces 部署。

架构图(README verbatim):

┌─────────────────────────────────────────────────────────┐
│                    Client Application                   │
│  ┌────────────────┐              ┌──────────────────┐   │
│  │  EchoEnv       │              │  CodingEnv       │   │
│  │  (EnvClient)   │              │   (EnvClient)    │   │
│  └────────┬───────┘              └────────┬─────────┘   │
└───────────┼───────────────────────────────┼─────────────┘
            │ WebSocket                     │ WebSocket
            │ (reset, step, state)          │
┌───────────▼───────────────────────────────▼─────────────┐
│              Docker Containers (Isolated)               │
│  ┌──────────────────────┐    ┌──────────────────────┐   │
│  │ FastAPI Server       │    │ FastAPI Server       │   │
│  │   EchoEnvironment    │    │ PythonCodeActEnv     │   │
│  │ (Environment base)   │    │ (Environment base)   │   │
│  └──────────────────────┘    └──────────────────────┘   │
└─────────────────────────────────────────────────────────┘

截至 2026-05,OpenEnv catalog 已经包含 30+ 个 first-party env(Echo / Coding / Atari / OpenSpiel / Chess / Connect4 / FinQA / Maze / Reasoning Gym / BrowserGym / TextArena / Wildfire / OpenSpiel / Terminus / TB2 / Unity ML-Agents / CARLA / Calendar / dm_control / kernrl / Julia / dpg-safety / Snake / Web Search / OpenCode / OpenApp / Jupyter / Git / SUMO-RL / Coding Tools / Chat / FinRL / REPL / Grid World / Agent World Model / ...)。Agent World Model 在列表最后一项(紧邻 OpenCode 之前),定位是"大规模 tool-use 合成 env / 1,000 scenario × 10 task"。

1.2 Snowflake AWM 是什么 — 链接到 #18

本仓库 #18 AWM 精读已经把原版讲透了,这里只复述跟 OpenEnv port 直接相关的部分:

AWM 当时的"原生"使用方式是:git clone Snowflake-Labs/agent-world-model → 直接跑 Python harness → harness 拉起 1,000 个 MCP server 子进程之一 → trainer 自己 wire 上 OpenAI-tool-call API。这套 harness 没有标准化的 wire protocol,要接到 TRL / SkyRL / ART 这类训练框架里都得自己写 adapter。OpenEnv port 干的事情就是: 把这块 adapter 写一次、所有人复用。

1.3 为什么这次 port 值得单独写一篇 note

• AWM 是 OpenEnv catalog 里少数"大规模 tool-use 合成 RL env" —— OpenEnv 自己的 starter env 大部分是玩具 env(Echo / Atari / Connect4 / Wordle / 2048 / Snake / Maze),AWM 是第一个真正可以 train 出 BFCL 提分模型的 LLM tool-use env;
• Port 后的 verifier 设计有意思 —— 原版 AWM 默认 code 模式,OpenEnv port 把 LLM-judge SQL 模式做成同一个 verify tool 的不同 verifier_mode 参数,在 wire protocol 上等价,这是 OpenEnv 风格的"reward backend 选择题"做法;
• OpenEnv 接了 6+ RL 框架(TRL, SkyRL, ART, Oumi, Unsloth, torchforge),因此 AWM 现在变成了"任意主流 RL trainer 都能拉起来的 1K env benchmark",这是分发力的质变;
• 它是 OpenEnv vs Prime Intellect Hub 路线对比的极佳样本 —— 同一份数据集(AWM 1K),Prime Intellect Hub 端 #31 是否已收录、收录形式是什么,可以做横向对照。

§2 · AWM-in-OpenEnv 的实际接口(逐字段)

本节内容全部来自官方文档页 environments/agent_world_model.html(2026-05 访问),代码段 verbatim。

2.1 Quick Start — Server 端

从 OpenEnv 仓库根目录起一个本地 AWM server(默认 8899 端口):

# From the OpenEnv root directory
PYTHONPATH=src:envs uv run uvicorn envs.agent_world_model_env.server.app:app \
    --host 0.0.0.0 --port 8899

注意几个细节: (1) 用的是 uv run uvicorn(uv 是更快的 Python package manager,OpenEnv 整个项目都默认 uv); (2) PYTHONPATH=src:envs 把 OpenEnv 的 core src 和环境目录都加进去; (3) app 的位置是 envs.agent_world_model_env.server.app:app —— 即 env 的 server 端代码在 envs/agent_world_model_env/server/。

2.2 Quick Start — Client 端(完整 episode)

import asyncio
from agent_world_model_env import AWMEnv
from openenv.core.env_server.mcp_types import CallToolAction, ListToolsAction

async def main():
    async with AWMEnv(base_url="http://localhost:8899") as env:
        # Reset to a scenario with a specific task
        result = await env.reset(scenario="e_commerce_33", task_idx=0)
        print(f"Task: {result.observation.task}")
        print(f"Tools available: {result.observation.num_tools}")
        print(f"Verifier support: {result.observation.has_verifier}")
        # {sql: True, code: True}

        # List available tools
        tools = await env.list_tools()
        for tool in tools[:3]:
            print(f"  - {tool.name}: {tool.description}")

        # Call a tool
        obs = await env.call_tool("search_products", query="headphones")
        print(f"Result: {obs.tool_result}")

        # Run verification
        result = await env.step(CallToolAction(
            tool_name="verify",
            arguments={"verifier_mode": "code", "final_answer": "optional answer"}
        ))
        print(f"Reward type: {result.observation.reward_type}")
        print(f"Reward: {result.reward}")
        print(f"Verify result: {result.observation.verify_result}")

        # End episode (destroys subprocess; set keep_session=True to preserve files)
        result = await env.step(CallToolAction(
            tool_name="done", arguments={"keep_session": False}))
        print(f"Episode done: {result.done}")

asyncio.run(main())

这 25 行完整覆盖了一次 episode 的所有阶段:reset → list_tools → call_tool(业务 tool) → step(verify tool) → step(done tool)。注意 verify 和 done 是特殊保留的 tool_name,业务 tool(search_products 等)和它们走同一个 CallToolAction 接口。

2.3 Action 类型 — 只有两种

三个特殊 tool_name:

这套设计哲学是 "verify is just another tool" —— RL trainer 不用引入新概念,verify 就是策略可以选择何时调用的一个工具,这跟 ReAct / tool-call 思路完全一致。对比之下,Prime Intellect 的 verifiers SDK 把 verify 做成 Env 的独立 verify() 方法,概念上跟 tool-call 分离。

2.4 Observation 字段(逐字段)

每次 step 返回的 StepResult.observation 包含以下 11 个字段:

2.5 Reward 设计 — 默认值 + 可在 reset 覆盖

默认 reward map:

这套默认值对 RL 来说不是 sparse reward:

• complete = +1.0,incomplete = +0.1 —— 给一个非零但小的 baseline,鼓励"尝试"而不是"放弃";
• format_error = −1.0 —— 显式惩罚不会调工具的失误,这是 BFCL 那条 AST-only 路线在 RL 里的体现;
• 系统错误 = 0.0 —— 把不可归因的 reward 信号清零,避免噪声反向梯度。

可在 reset 时覆盖:

result = await env.reset(
    scenario="e_commerce_33",
    task_idx=0,
    reward_config={"complete": 1.0, "incomplete": 0.0, "format_error": 0.0}
)

典型的"稀疏 binary RL"做法是把 incomplete 设 0、format_error 设 0,只奖励 complete = 1.0,跟 RLVR 风格对齐。

2.6 Verifier 两种模式 — 同一个 tool 调用 / 不同 arguments

code 模式(默认,无 LLM 需求)

result = await env.step(CallToolAction(
    tool_name="verify",
    arguments={"verifier_mode": "code", "final_answer": "optional answer"}
))

跑一个 Python verifier 函数,比对 task 开始前的 SQLite snapshot 和 当前 SQLite 状态。这就是原版 AWM 论文里的"state-diff verifier"。determinstic, no LLM, free。final_answer 是 optional 的 —— 有些 task 除了改 DB 还要给一个最终答案字符串。

sql 模式(code-augmented LLM-as-a-Judge,文档推荐)

文档原话: "This mode is recommended for judge performance." —— OpenEnv 团队认为 LLM judge 在这套数据上判得更准。需要先配 LLM 凭证:

# Set LLM credentials via environment variables
# OPENENV_AWM_LLM_BASE_URL, OPENENV_AWM_LLM_API_KEY, OPENENV_AWM_LLM_MODEL

result = await env.step(CallToolAction(
    tool_name="verify",
    arguments={"verifier_mode": "sql"}
))

具体流程: 跑 SQL query 提取状态变化 → 把 diff 喂给 LLM judge → LLM 判断是否完成 task。这种 "SQL augmented LLM judge" 比 raw LLM judge 稳很多,因为 LLM 看到的不是原始 DB dump 而是结构化的状态 diff。注意 LLM 凭证是客户端 env var,不是 server 参数 —— 也就是说同一个 AWM server 实例可以同时服务 code mode 用户和 sql mode 用户。

这次 port 的设计亮点: 原版 AWM 论文里 sql 模式是默认主线,code 模式偏 fallback;OpenEnv port 把 code 模式做成默认,LLM 模式做成 opt-in。这一翻转直接降低了 RL 训练成本(默认就不需要付 judge LLM 的 API 费用)。这里"翻转"是 OpenEnv 文档的措辞推断,具体原版 AWM 的 default 模式选择未在公开来源直接比较,但 #18 笔记里读到的训练 recipe 是混用两种 verifier。

2.7 Session artifacts — done(keep_session=True) 保留什么

当客户端调 done(keep_session=True) 时,session 目录会保留以下 5 个文件:

这五个文件加起来等于一个可调试 / 可回放 / 可二次 verifier 的 minimum 工件包。{scenario}.db 配 {scenario}_initial.db 就是 verifier 的全部输入,因此事后任何人都可以独立重跑 verifier。trajectory.json 直接喂回任何 trajectory-based SFT / RL pipeline。这是非常工业级的设计。

默认 keep_session=False —— RL 训练时大多不需要存 artifact,直接清干净就行。

2.8 List scenarios — 元数据接口

async with AWMEnv(base_url="http://localhost:8899") as env:
    # List all 1,000 scenarios
    result = await env.step(CallToolAction(tool_name="__list_scenarios__", arguments={}))

    print(f"Total scenarios: {result.observation.total}")
    for scenario in result.observation.scenarios[:5]:
        print(f"  - {scenario['name']}: {scenario['num_tasks']} tasks")
        print(f"    Sample task: {scenario['tasks'][0][:80]}...")

这是 OpenEnv AWM 提供的额外便利接口(原版 AWM 需要 grep 数据集才能列出 scenarios)。每个 scenario 返回 name + num_tasks + tasks(list of task descriptions)。1,000 个 scenarios × 10 tasks = 10,000 个 task,与原始 AWM 数据集对齐。

§3 · Docker / 包装方式 / 大规模 RL 配置

3.1 Server 监控 — /stats endpoint

curl http://localhost:8899/stats

返回:

• total_sessions: 当前活跃 WebSocket session 数
• max_idle_time_config: idle 阈值(默认 600s)
• cleanup_interval_config: 清理 daemon 扫描间隔(默认 5s)
• scenarios breakdown: 哪些 scenario 当前有 session
• max_idle_s: 当前实测最大 idle 秒数

背景清理 daemon: 当 total_sessions > ALLOWED_IDLE_SESSIONS(默认 3,000)时,把 idle > MAX_IDLE_TIME(默认 600s)的 session 自动 kill。这套设计针对的就是大规模 RL rollout 出现 stuck session 导致内存爆炸的现实问题。

3.2 大规模 RL 设计 — 单 server 撑 10,000 session

文档原话:

AWM is designed for large-scale agentic RL. A single server supports thousands of concurrent WebSocket sessions, each with its own isolated environment subprocess.

压测脚本(verbatim):

# after server started, then in another terminal:
PYTHONPATH=src:envs uv run python examples/agent_world_model/example_stress_test.py \
    --scale 1024 --concurrency 64 --min-turns 3 --max-turns 20 \
    --think-min 3.0 --think-max 30.0

这个命令的语义: 1,024 个并行 episode,每个 episode 3–20 多轮 tool 调用,每轮模拟 LLM "think" 3–30 秒,concurrency=64 是 client 端的并发 worker 数。这是模拟 RL on-policy rollout 阶段的 LLM 推理延迟(LLM 推理慢,env 必须能扛住 client 端的高并发空转)。

这 1,024 episode 并不会同时拉起 1,024 个 env subprocess —— concurrency=64 意味着 client 最多 64 个 in-flight,server 端 env subprocess 应该会在 episode 之间复用 / 起新进程。具体 subprocess lifecycle 未在文档直接说明,但 READY_TIMEOUT=180s 和 MAX_PORT_RETRIES=5 暗示了 spawn-on-demand 模式。

3.3 Server 配置表 — 全部可经 env var 调

10,000 默认 MAX_CONCURRENT_ENVS 是非常激进的数字 —— 假设每个 env subprocess 占 50MB,理论上一台 server 撑 500GB RAM 的工作集。但实际 RL 训练时 concurrent active session 不会真的拉到 10K,主要是给 client 端波动留 headroom。3,000 这个 idle session 阈值更现实,触发清理时差不多 150GB,符合一台 256GB 训练节点的容量。

3.4 Docker 打包方式 — 走 OpenEnv 标准

OpenEnv 的统一打包标准是: 每个 env 一个 server/Dockerfile,容器内跑 FastAPI server,容器外用 LocalDockerProvider 或 KubernetesProvider 拉起。AWM env 自己的 Dockerfile 文档没有 verbatim 贴出,但根据 OpenEnv README 的环境模板:

my_env/
├── .dockerignore        # Docker build exclusions
├── __init__.py          # Export YourAction, YourObservation, YourEnv
├── models.py            # Define Action, Observation, State dataclasses
├── client.py            # Implement YourEnv(EnvClient)
├── README.md
├── openenv.yaml         # Environment manifest
├── pyproject.toml
├── outputs/             # Runtime outputs (logs, evals) - gitignored
│   ├── logs/
│   └── evals/
└── server/
    ├── your_environment.py  # Implement YourEnvironment(Environment)
    ├── app.py               # Create FastAPI app
    ├── requirements.txt
    └── Dockerfile

AWM env 在仓库里应该是 envs/agent_world_model_env/,跟此结构对齐(从 envs.agent_world_model_env.server.app:app 的 import path 可推断)。具体的 envs/agent_world_model_env/server/Dockerfile 内容、镜像大小、tag 名称未在公开来源(文档页 + README)直接看到;但根据 OpenEnv 一键发布机制,该 env 必然能用 openenv push 推到 HF Spaces,而 HF Space ChilleD/agent_world_model_env 正是公开示例。

3.5 公开 HF Space — 0 部署成本试用

不想本地起 server 的话,文档明确提供了 HF Space 入口:

# 直接连公开 HF Space(可能比较慢)
AWM_BASE_URL=https://chilled-agent-world-model-env.hf.space
# 或
async with AWMEnv(base_url="https://chilled-agent-world-model-env.hf.space") as env:
    ...

这是 OpenEnv 整套生态的核心便利 —— HF Spaces 免费 host(CPU tier),任何研究者都能在自己的 colab 里直接连远端 env 跑实验,不用配 Docker、不用 GPU、不用申请配额。代价是延迟(每个 tool call 走 public internet,数百 ms 起步)。

§4 · 与原始 AWM (#18) 的差异 — port 改了什么,没改什么

4.1 没改的部分 — 数据 / verifier 算法 / 数学

这次 port 是一次纯 wire protocol 转换,Snowflake 原版的全部"科研意义"内容(scenario 合成方法、数量、verifier 设计、SQLite-as-state)都没动。所以 #18 笔记里 §3-§6 的"数据合成 pipeline / verifier 设计 / 训练 recipe"对 OpenEnv port 全部成立 —— 任何在 OpenEnv 上拿 AWM 训出的模型,跟直接拿原版 harness 训应该等价(模 wire-protocol-noise)。

4.2 真正改了的部分 — wire protocol + 工程化

• protocol 标准化: 任何 OpenEnv-兼容的 RL trainer 都能直接用 AWM,不用写 adapter;
• verify-as-tool: 把 verifier 从 harness 内化为 policy 可调的 tool,理论上让 RL 也能学"何时 verify"这一决策 —— 这是一个微妙的语义升级;
• subprocess 隔离 + idle cleanup: 解决了大 batch RL 时 env crash / hang 的内存泄漏问题;
• HF Space hosting: 试用门槛从"clone + setup"降到"pip install + URL";
• artifact pack 标准化: trajectory.json + 2 DB + server.py + log,事后任何人能独立 reproduce + re-verify。

4.3 "verify 作为 tool"是不是真的更好?— 双面分析

支持论点: 把 verify 当 tool,policy 可以学到"什么时候我自己觉得 task 做完了" —— 这跟 critic-free RL 里"learn to stop"的思路一致。OpenAI 的 SWE-bench 风格训练里,模型学会自己说 I'm done 后总比硬 turn-cap 表现好。

反对论点: 把 verify 当 tool 也意味着策略可以"作弊地"调一次 verify 看看 reward 信号,然后基于这个反馈修改后续行为 —— 这在 RL 里属于 process-level reward leak,可能让模型学到"调一次 verify 看结果,失败的话回去改,直到成功"的 hack 行为。AWM 默认 reward incomplete = +0.1(失败也给一点),理论上能让 policy 多调几次 verify 而不被罚太狠。具体 verify 是否限制每 episode 只能调一次、是否给重复调 verify 设惩罚未在文档直接说明。从 quick-start 代码看,verify 可以多次调用(注释 "can be called multiple times with different modes"),这意味着 reward leak 风险存在。

§5 · 在生态里的位置 — OpenEnv vs verifiers vs Toolathlon-Gym

5.1 三套主流 RL env 标准的 2026-05 现状

OpenEnv 收 AWM 的意义:AWM 第一次从"单家 Snowflake 自循环"被拉进了一个真的多 RL trainer 共用的标准。Prime Intellect Hub 上能否找到 AWM env #31 没有明确确认,但即使有,也是 Prime 自家 verifiers 格式,不直接被 TRL/SkyRL/ART 用。

5.2 verifiers 和 OpenEnv 已经互桥

本仓库 #31 Prime Intellect Hub 已经提到,verifiers SDK 在 v1 加了 OpenEnv 桥接(OpenEnvAdapter),把 OpenEnv 的 client 包成 verifiers 的 Env。这意味着:

• verifiers 用户可以直接 import OpenEnv 上的 AWM,跑 prime-rl 训练;
• OpenEnv 用户可以反向用 verifiers 上的 task-set / harness 抽象,接 OpenEnv server。

这是非常健康的"标准之间合作"现象 —— 不像之前 OpenAI Gym vs Farama Gymnasium 那种分叉,OpenEnv 和 verifiers 选择互相 wrap。具体桥接代码未在 OpenEnv 文档页直接给出,需要去 verifiers repo 看 OpenEnvAdapter 实现。

5.3 vs Toolathlon-Gym — 不直接竞争

Toolathlon-Gym 是给 Toolathlon bench(#21 提及)用的 RL gym,scope 是真实 MCP server 上的 long-horizon 任务,跟 AWM(全合成 / 短任务 / 大规模)的设计目标互补。AWM 的优势是规模 + 速度 + verifier 确定性,Toolathlon-Gym 的优势是分布跟实际 MCP 用法贴近。理论上理想的 RL 训练 pipeline 是:先 OpenEnv-AWM 大规模冷启 → 再 Toolathlon-Gym fine-tune long-horizon。

5.4 OpenEnv catalog 里 AWM 的同类

OpenEnv 30+ env 里,跟 AWM 最像的是:

• Coding Tools Environment — Python tool-use,smaller scope
• BrowserGym Environment — browser 任务,跨域
• OpenApp Environment — app simulation,scope 不同
• Web Search Environment — search tool,单一 vertical
• Calendar Environment — 单一 tool 域

对比下来 AWM 是 OpenEnv catalog 里规模最大的 LLM tool-use RL env(1,000 env × 10 task),其他都是玩具 env(Echo / Wordle / 2048)或vertical-specific env(Calendar / FinRL)。AWM 在 OpenEnv 里相当于"大规模 tool-use benchmark suite"的官方答案。

§6 · 开源 + 使用方式(5 行 quick start)

6.1 最短上手路径(连公开 HF Space)

pip install openenv-core
pip install git+https://huggingface.co/spaces/ChilleD/agent_world_model_env  # 推测安装路径,未在公开来源逐字确认

import asyncio
from agent_world_model_env import AWMEnv
from openenv.core.env_server.mcp_types import CallToolAction

async def main():
    async with AWMEnv(base_url="https://chilled-agent-world-model-env.hf.space") as env:
        result = await env.reset(scenario="e_commerce_33", task_idx=0)
        print(result.observation.task)

asyncio.run(main())

上面的客户端 pip 安装路径是基于 OpenEnv 通用模式推测 —— OpenEnv 标准做法是 pip install git+https://huggingface.co/spaces/<org>/<env>(README 里 Echo env 就是这样),AWM 应该一致,但文档页未 verbatim 给出 pip 命令。

6.2 本地起 server(完整自主)

# 1. clone OpenEnv
git clone https://github.com/meta-pytorch/OpenEnv.git
cd OpenEnv
uv pip install -e .   # core 包

# 2. 起 AWM server
PYTHONPATH=src:envs uv run uvicorn envs.agent_world_model_env.server.app:app \
    --host 0.0.0.0 --port 8899

# 3. 另一终端跑 client
PYTHONPATH=src:envs uv run python examples/agent_world_model/example_usage.py

这是研究复现 / debugging / 大规模 RL 训练时的标准路径。example_usage.py 文档说支持本地和远端两种 base_url,AWM_BASE_URL=https://chilled-agent-world-model-env.hf.space 切到 HF Space。

6.3 接到 RL trainer — 以 TRL 为例

OpenEnv 在 HF TRL 文档里有 官方 example。原则上把 AWMEnv 替换上去就能跑 —— 任何接受 OpenEnv EnvClient 的 trainer (TRL / SkyRL / ART / Oumi / Unsloth / torchforge) 都立刻可以拿 AWM 训。具体 TRL × AWMEnv × GRPO 的 example code OpenEnv 文档未直接给,需要按 TRL OpenEnv 通用模板自己写一个;但因为 protocol 完全标准化,改动量应该很小(替换 base_url + reward 字段映射)。

6.4 License 一览

整套商用 friendly:BSD-3 + Apache-2.0 都允许商用、修改、再分发,无 NC 限制。

6.5 引用

OpenEnv 文档明确给出 BibTeX(verbatim):

@article{wang2026agentworldmodelinfinity,
  title={Agent World Model: Infinity Synthetic Environments for Agentic Reinforcement Learning},
  author={Zhaoyang Wang and Canwen Xu and Boyi Liu and Yite Wang and
          Siwei Han and Zhewei Yao and Huaxiu Yao and Yuxiong He},
  year={2026},
  eprint={2602.10090},
  archivePrefix={arXiv},
  primaryClass={cs.AI},
  url={https://arxiv.org/abs/2602.10090},
}

注意:OpenEnv 的引用建议只引 Snowflake 原 paper,没有要求引 OpenEnv 本身 —— 这暗示 OpenEnv 团队把这次 port 当工程贡献,不当学术贡献。

§7 · 局限 / 诚实分析 / 待验证项

7.1 安全警告 — 文档自己 admit

文档 §Warning 原话:

AWM treats verifier code and scenario code from the curated AgentWorldModel-1K dataset as trusted. Verifier code (server/_verifier_runner.py) is run in a subprocess sandbox (rlimits, restricted builtins, import allowlist); scenario subprocesses run without per-process sandboxing and rely on the container as the outer isolation boundary. The codes are synthetically generated and carefully curated, however, there is no guarantee of absolute safety. We recommend only academic research use.

翻译: (1) verifier 跑在带 rlimits + builtin 白名单 + import 白名单的 subprocess 沙箱里; (2) scenario 子进程没有进程级沙箱,只靠 Docker 容器隔离; (3) 代码是 LLM 合成 + 人工 curate 的,无绝对安全保证; (4) 官方仅推荐学术研究使用,不要在生产环境 / 不可信用户输入场景部署。

这是一个明显的局限 —— AWM 的 scenario 代码本身就是 LLM 生成的 Python,虽然 Snowflake 做了 curation,但理论上每个 scenario 都能跑任意 Python(os.system / subprocess 等),只靠 Docker 兜底。在多租户 RL 训练集群里,这意味着不能让外部用户上传 AWM scenario。

7.2 未确认 / 待验证项清单

7.3 个人 take — 这次 port 解决了什么 / 没解决什么

解决了:

• ✅ AWM 从 Snowflake 自循环走向多 trainer 共用标准;
• ✅ Verifier code/sql 两种模式做成同一接口下的 mode 参数,降低试用门槛;
• ✅ Session 管理 / cleanup daemon / 1024 并发压测 —— 大规模 RL 部署侧的工程缺口补齐;
• ✅ HF Space 零部署试用入口;
• ✅ Artifact 标准化(5 文件 session_dir),debug 友好。

没解决:

• ✗ AWM 本身的分布问题(全合成 ≠ 真实 MCP)没改 —— 这是 #22 TOUCAN / #03 Agent-World 试图解决的方向,跟 OpenEnv port 无关;
• ✗ verify-as-tool 的reward leak 风险(policy 可反复调 verify 探 reward 信号)未在文档讨论;
• ✗ scenario 沙箱缺失 —— 容器是唯一边界,不适合多租户;
• ✗ 没有打包 RL recipe —— 用户得自己写 TRL/SkyRL trainer 配置,没有"5 行训出 Arctic-AWM-8B"的 one-shot 例子;
• ✗ 无评测 leaderboard —— OpenEnv 文档不报告"训完模型的 BFCL/τ-bench 分数",得回原版 AWM 论文看(#18 §7)。

7.4 跟其他 note 的 cross-link

7.5 一句话总结

OpenEnv × AWM 是 把 Snowflake 已开源的 1K 合成 RL env 包装成业界统一标准的 wire protocol(WebSocket + FastAPI + Action/Observation 强类型),换来"任何 OpenEnv-兼容 RL trainer 即插即用"的分发力。科研内容零变化,工程价值很大。对于做 LLM tool-use RL 的研究者,这意味着 AWM 现在不再需要写 Snowflake-specific adapter —— 一行 pip install 加一个 base_url 就接进训练循环;对 RL 框架作者来说,意味着 OpenEnv catalog 里第一次出现一个真正能 train 出 BFCL 提分模型的 tool-use env,玩具 env 时代结束。

本文基于 OpenEnv 官方文档页(2026-05-18 抓取)+ Snowflake AWM 原始 paper #18 笔记 + OpenEnv GitHub README(2026-05-18 抓取)整理。所有 verbatim 代码段来自 https://meta-pytorch.org/OpenEnv/environments/agent_world_model.html。"未确认"标记 5 处,见 §7.2。