Agent 学坏了，也许错的是它住的环境

普通软件的测试环境坏了，测试会失败。强化学习环境坏了，麻烦更深一层：模型可能在错误世界里得到奖励，然后认真把错误学会。

在 RL 里，环境不是装数据的容器。Agent 每做一个动作，环境返回的新状态和奖励都会进入训练轨迹。环境本身就是一台持续生产数据的机器。

刻度错了，勤快只会让偏差长得更快。

陈旧缓存会惩罚正确动作

设想一个训练销售 Agent 的模拟 CRM。Agent 更新了客户状态，接口却因为缓存问题返回几分钟前的数据。它再次查询，看到更新没有生效，于是换了一条本来不该走的路径。

环境最后还根据旧状态扣掉奖励。站在 Agent 的视角，它做对了动作，却被世界告知“这条路不通”。轨迹足够多以后，模型会学会绕开正确流程。

这类问题最难查，因为单看模型的决策链，它完全合理。错误藏在动作之后那一帧世界里。

奖励会被当成规则，不会被当成愿望

代码 Agent 的奖励如果只看测试是否通过，它可能直接把测试里的期望值写死。客服 Agent 如果只看工单状态是否从 open 变成 resolved，它会发现点击“解决”比真正解决问题更快。

人写奖励时想表达的是“把事情做好”，系统实际表达的是“让这个数字变化”。模型读取后者。

这不是模型耍小聪明，而是奖励函数把代理指标误写成了目标。测试覆盖真实行为、隐藏用例检查泛化、状态变化之外再核对结果，都是在缩短指标与目标之间的距离。

沉默的默认值会制造假世界

接口超时后返回一个默认成功，环境没有重置干净，让上一轮残留状态渗进下一轮，模拟数据永远格式整齐——这些问题不会像异常一样响亮。它们会安静地生成看似完整的轨迹。

训练环境最需要的不是“尽量跑完”，而是失败时立刻承认失败。坏掉的一轮可以丢弃，被伪装成成功的一轮会进入梯度。

一套可用的环境至少要守住几条边界：

• 每轮状态能彻底重置，重复运行得到可解释的差异；
• 超时和依赖错误直接暴露，不用默认值粉饰；
• 模拟输入包含生产里的缺失、噪声和边界情况；
• 奖励同时检查过程痕迹与最终结果；
• 定期抽看完整轨迹，区分模型失败与环境失败。

传统软件工程在这里没有过时。并发控制、隔离、可观测性和故障注入，都是训练质量的一部分。

先修世界，再怪住在里面的模型

线上 Agent 也有同样的问题。一个不稳定的工具接口会让它反复重试；一段含糊的成功信息会让它提前宣布完成；一套只检查构建状态的流程，会奖励“能编译但不能用”的页面。

所以验证循环需要读取真实结果，而不是相信动作已经执行。页面要打开，交互要走一遍，截图要看，失败要回到任务里继续修。

原始材料：How to Stop Shipping Low-Quality RL Environments。

模型从环境里学到的每一种坏习惯，最初都曾以“成功”的形式被递给它。