为什么环境工程是 RL 的前置条件？
- 瓶颈位置: RL 训练的瓶颈往往不在算法，而在环境是否足够真实、可重置、可并行;
- 现实约束: 真实 Agent 的电话、付款或文件修改可能昂贵且不可逆，不能靠无限重试弥补一次错误;
- 训练需求: 评估环境可以提供验证器，但训练还需要让 Agent 反复试错、承受动作副作用，并在数百万次交互中保持稳定;
- 定位: 环境工程不是训练完成后的附属品，而是 RL 的前置条件;
仿真保真度为什么决定策略能否上线？
- 定义: 保真度指仿真环境与真实部署场景有多相似;
- 失真后果: 若仿真里的客服总按固定套路回话、错误信息与生产环境对不上，模型会学到一套只在仿真里管用的“应试策略”，一上线就暴露问题;
- 最常见的失败方式: 不是算法不行，而是练习场与考场并不相同;
- 工程成本: 构建高保真环境常常比训练本身更贵、更难——一个能大规模并行、可复现、反馈真实的环境，往往需要投入比调整模型多得多的工程资源;
- 例证: 多工具训练需要自建 MCP 沙盒与代码解释器沙盒，正是因为真实 API 有速率限制、会封号、有副作用，根本无法直接用于训练，必须先构建稳定、可控、可重放的“影子世界”;
- 环境的另一半: 环境不仅要模拟“世界怎么变”，还要能判定“做得好不好”，这就是奖励函数的输入，见奖励设计;
- 优先问题: 在动手调算法之前先问“我的仿真环境真的像真实世界吗”，这个答案比选 PPO 还是 GRPO 重要得多;
造不出环境时怎么让模型扮演环境？
- 前提: 很多场景里高保真环境不是“贵”，而是根本造不出来——真实 API 有副作用不能乱调，真实用户不能拿来试错，物理世界更是没法快进;
- 第一层次，模型合成工具调用的返回值: ZeroSearch 直接用一个 LLM 扮演搜索引擎，学生模型发出搜索 query，由这个“模拟引擎”生成并返回检索结果;
- 课程式设计: 训练初期让模拟引擎返回高质量、强相关的文档，随训练推进逐步掺入噪声、降低返回质量，促使学生学会从真实搜索引擎那种不完美的结果中提取有用信息;
- 结果: 训练全程没见过真实搜索引擎的模型，直接对接真实搜索时依然表现良好;
- 第二层次，模型仿真整个环境的动态: DreamGym 把环境动态蒸馏进一个推理式的“经验模型”——给定当前状态与 Agent 的动作，它逐步推理出状态转移和反馈信号，从而在不访问真实环境的情况下批量合成 rollout 用于在线 RL;
- 对话类场景: 客服、销售类 Agent 的训练普遍用 LLM 扮演用户（用户模拟器），τ-bench 系列评测正建立在这个思路上——同一个模型模拟器既能当考场，也能当练习场;
- 风险: 模拟器的世界知识就是训练的天花板，模拟器的系统性偏差会被策略照单全收;
- 更糟的情况: RL 会主动寻找并利用模拟器的漏洞，进行 reward hacking;
- 稳妥做法: 混合——用模型模拟承担大部分交互量，辅以真实环境的交互，并用真实环境交互定期校准模拟器的偏差;
环境、任务分布与评估隔离如何安排？
- 任务来源: 从真实业务日志提炼任务蓝图，去除身份信息后重新生成虚构的人物、订单、文件与状态，与 SFT 数据合成一致，见SFT 数据合成;
- 环境要求: 必须可重置、可并行、可复现，并在状态转移后给出可信的验证结果;
- 隔离要求: 训练环境和评估环境可以共享任务生成器与验证代码，却不能共享同一批任务;
- 例证: SWE-Gym、τ²-bench、AndroidWorld 都要求测试用例、隐藏状态和参考解法留在验证器一侧;
- 先修检查: 先用少量 rollout 检查“任务是否可完成、验证器是否能区分对错”，再扩大采样规模;
- 验证器偏差的后果: 如果验证器本身有系统性偏差，RL 只会更快地利用它;
- 环境工程顺序: 任务蓝图 → 可重置模拟器 → 确定性验证器 → 训练/评估隔离 → 少量真实交互校准;
确定性验证器为什么也需要成本核算？
- 直觉: 用 Lean kernel、测试运行器或容器执行做验证似乎很“便宜”，因为没有模型推理;
- 现实: CPU 验证速度可能远慢于 GPU 生成速度;
- 后果: 吞吐量取决于并行的验证器 worker 数量，而不是继续堆 GPU;