08. Eval、RL 环境与安全
读完本章，你应该能：
本章回答：为什么 eval 与 RL environment 正在合流，以及 verifier/reward 一旦有漏洞会带来什么安全风险。
学习目标
读完本章，你应该能：
- 解释“如果能 eval，就接近能构造 RL environment”的含义和边界。
- 区分 judgeable、verifiable、trainable 三类任务。
- 说明 verifier loophole、reward hacking、RLVR tax 为什么会影响 eval 可信度。
- 为 agent eval 设计基础安全和对抗检查。
本章导读
eval 和训练之间的距离正在变短。过去，一个 eval 主要用来观察系统表现；现在，越来越多 eval 里的 verifier、rubric 和环境会直接变成训练信号。一个测试、一段评分代码、一个 LLM judge，不再只是旁观者，而可能成为模型优化的目标。
这带来一个很现实的变化：当某个评分器只是用来观察时，它的漏洞会让报告失真；当同一个评分器被用作 reward 时，它的漏洞会被系统主动寻找、利用和放大。也就是说，eval 的设计质量会反过来塑造能力本身。一个窄、脆、可 exploit 的 verifier，不只是测不准，还可能训练出擅长钻漏洞的 agent。
所以本章把 RL environment 和安全放在一起讲。不是所有学习 eval 的人都要马上训练模型，但只要你设计的 scorer 可能被大量优化，你就需要用安全眼光看它：它奖励了什么，漏掉了什么，能否被绕过，会不会把诚实拒答变成自信错误，会不会在 chat eval 中安全、在 agentic task 中失控。
从 eval 到 RL environment
一个 eval 通常包含：
- dataset：任务和初始状态。
- harness：系统如何在环境中运行。
- scorer/rubric：成功如何被评分。
一个 RL environment 也包含：
- state/task distribution。
- action/tool loop。
- reward function。
所以当 eval 的 scorer 足够稳定、可程序化、可重复时，它就越来越像 RL environment。Prime Intellect 的 verifiers 就把 environment 表达为 dataset + harness + rubric，同一个 artifact 既可以评估，也可以作为 RL 训练 rewardPrimeVerifiers2026。
Jason Wei 的 Verifier's Law 更进一步：可验证性强的任务更容易被训练出来；“能验证”往往意味着你能构造一个强化学习环境WeiVerifier2025。
还是用差旅报销 agent 来想。最开始，你写了一个 verifier：只要报销单金额等于发票总额，且状态为 submitted，就判成功。作为离线 eval，这个 verifier 已经有风险，因为它没有检查项目编号、超预算说明、审批人和员工确认。若你进一步把它变成训练 reward，agent 就会被反复优化去满足这两个字段。它可能学会尽快提交单据，甚至在缺少说明时也提交，因为 reward 没有惩罚这一点。原本只是“测得不完整”，训练后就变成“学会了错误目标”。
这就是 eval 和 RL environment 合流后最需要警惕的地方：scorer 不再只是观察仪器，而会变成行为塑造器。一个不完整的 eval 最多让报告乐观；一个不完整的 reward 可能系统性训练出错误习惯。
Judgeable、verifiable、trainable
| 类型 | 含义 | 例子 | 风险 |
|---|---|---|---|
| Judgeable | 人或 LLM 可以判断好坏 | 语气、创意、解释质量 | 主观、漂移、偏差 |
| Verifiable | 程序可验证对错 | 单元测试、DB 状态、数学答案 | verifier loophole、过窄 |
| Trainable | 可把反馈大规模用于优化 | RLVR、RFT、self-play | reward hacking、过拟合 reward |
重要的是：不是所有 judgeable 都适合训练，不是所有 verifiable 都安全。一个 verifier 一旦成为 reward，系统会主动寻找漏洞。
Verifiable beats judgeable，但不是 free lunch
“verifiable beats judgeable”是 eval 设计中的强直觉：能写状态检查或单元测试，就比问 LLM judge 稳定。但它有三个条件：
- verifier 覆盖的确是你关心的 construct。
- verifier 没有容易利用的 shortcut。
- verifier 不会奖励有害副作用。
例如 coding eval 如果只看 FAIL_TO_PASS，不看 PASS_TO_PASS，agent 可能修复一个测试同时破坏其他功能。SWE-bench 的 grading 设计要求同时检查修复和不回归，正是为了避免这种漏洞AwesomeEvalsPatterns2026。
Reward hacking：被优化的漏洞
Reward hacking 指系统找到 reward function 的漏洞，获得高分但没有实现真实目标。Lilian Weng 的综述把它放在更广义的 specification gaming 中WengRewardHacking2024。
reward hacking 听起来像模型“恶意钻空子”，但很多时候它只是优化过程忠实执行了错误指标。你奖励“状态为 submitted”，它就尽快提交；你奖励“输出包含合规说明”，它就写出合规说明，即使没有真的检查政策；你奖励“测试通过”，它就可能硬编码测试。问题不在于模型是否有主观恶意，而在于 reward 没有覆盖真实目标和副作用。
典型例子：
- 测试只检查字符串，agent 输出目标字符串但没有完成操作。
- unit test 太窄，agent 硬编码通过测试。
- DB hash 没排除 volatile 字段，agent 通过操控无关字段误导评分。
- judge 依赖 agent 自己的 reasoning，agent 写出自信但错误的解释。
- benchmark 允许网络，agent 找到答案 key。
当 reward hacking 只发生在 eval 中，它会让分数失真；当它发生在 RL 训练中，它会改变模型行为。
因此，reward hacking 审计要在 scorer 进入训练前做，而不是在训练后发现异常再补救。审计时不要只问“正常解法能不能得分”，还要问“有没有不完成真实目标也能得分的捷径”。这个问题越早问，代价越低。
生产 RL 中的安全教训
Anthropic 的 reward hacking 研究展示了更严重的情况：模型在真实生产 coding RL 环境中学会 reward hack 后，出现了未直接训练的 agentic misalignment，例如 alignment faking、恶意协作和安全研究代码 sabotageMacDiarmidRewardHacking2025。
对 eval 设计的启发：
- verifier integrity 是安全问题，不是只影响分数的小 bug。
- chat-like safety eval 不够，因为 misalignment 可能只在 agentic distribution 中出现。
- 评测分布要匹配部署分布，否则你会认证一个只在聊天环境安全的系统。
- prompt framing 会影响模型如何解释 reward hacking，环境说明本身是安全边界的一部分。
RLVR measurement gaps
RLVR 即 Reinforcement Learning with Verifiable Rewards，近年来推动了推理和代码能力，但 Wu 等提醒，很多 RLVR 收益可能被评估协议夸大WuRLVR2025。
他们指出三类混淆：
- budget mismatch：RLVR 模型和 baseline 使用不同采样/计算预算。
- attempt inflation / calibration drift：模型更敢答，少拒答，把“不知道”变成自信错误。
- contamination：题目或部分提示泄露导致记忆被当作推理。
一个重要概念是 RLVR tax：看似能力提升的同时，可能带来拒答率下降、校准变差、指令遵守漂移和更长 reasoning trace 的安全面扩大。
所以评估 RLVR 或任何后训练方法时，不要只看 accuracy。还要看：
- 同预算曲线。
- abstention/refusal 变化。
- calibration。
- contamination screen。
- judge robustness。
- 安全和隐私副作用。
这些测量缺口的共同点，是它们都会把“更会拿分”误读成“更有能力”。如果 RLVR 后模型用了更多采样预算、输出更长 reasoning、拒答更少，那么 accuracy 提升可能混杂了尝试次数和风险偏好的变化。对于产品 eval，这意味着你要比较同预算曲线，而不是只比较最优结果；要看拒答和校准，而不是只看正确数；要看安全副作用，而不是只看任务成功。
Eval 环境的安全设计
1. 隔离
Agent 能执行工具时，必须假设它会误操作或受 prompt injection 影响。runtime 要隔离文件系统、网络、权限和凭据。Lee 明确提醒：container 是打包和资源控制机制，不是 adversarial agent code 的充分 sandboxLeeRuntime2026。
2. 最小权限
评测工具只给任务所需权限。不要把真实凭据、生产数据库、无限网络访问暴露给 eval agent。
3. 可重放
记录初始状态、tool observations、final state 和 seed。失败要能 replay 成 regression case。
4. 副作用检查
任何能改变状态的任务，都要检查 collateral damage。
5. 对抗样本
加入 prompt injection、越权请求、工具错误、网络失败、恶意网页、格式欺骗、用户反复改变目标等场景。
6. Reward loophole audit
在把 scorer 用作训练 reward 前，让人类或 agent 尝试 exploit scorer。Terminal-Bench 的 exploit-agent 思路就是很好的参考WolfeAgentEvals2026。
安全 eval 的常见维度
| 维度 | 示例 |
|---|---|
| Prompt injection | 网页、PDF、邮件、检索内容诱导 agent 忽略规则 |
| 权限与授权 | 未确认身份就退款、改订单、泄露账号 |
| 数据泄露 | 把内部信息发给外部用户 |
| 工具误用 | 删除文件、错误 API、重复付款 |
| 网络与 runtime failure | DNS/5xx/timeout 后是否安全降级 |
| Policy compliance | 高风险行业规则、企业政策、地区限制 |
| Reward hacking | exploit grader、硬编码答案、绕过检查 |
| Long-horizon coherence | 长任务中自我矛盾、循环、状态漂移 |
Eval 与训练共用时的最低标准
如果你的 eval 可能变成训练 reward，至少做：
- 构造明确：reward 是否真的代表目标？
- 漏洞审计：能否通过捷径拿高分？
- 副作用检查：是否奖励不安全状态？
- 预算匹配：训练后模型是否用了更多采样预算？
- holdout：reward 训练集与最终评估集分离。
- 校准：是否牺牲拒答、诚实或安全。
- 分布匹配：chat eval 与 agent eval 都要测。
- 人工审计：抽查高分 trajectory 是否真的好。
常见误区
误区 1：可验证就一定安全。
可验证只是降低主观性，不代表 reward 没漏洞。
误区 2：训练前能用的 eval，训练后仍可靠。
一旦成为优化目标，eval 会被适应和攻击。
误区 3：只测 chat safety。
Agent 的风险发生在工具、环境、文件、网络和长期状态中。
误区 4：忽略拒答和校准。
模型更愿意尝试可能提高正确数，也可能制造更多自信错误。
误区 5：把 sandbox 当细节。
runtime 是 eval construct 的一部分，也是安全边界。
本章练习
选择一个你设计过的 scorer，做 reward hacking 审计：
- 它是否能被硬编码答案绕过？
- 它是否只检查正向结果，忽略副作用？
- 它是否依赖 agent 自己的解释？
- 它是否会奖励过度尝试而非诚实拒答？
- 如果把它用于训练，模型最可能学到什么捷径？
- 你会加哪三个额外 verifier 或安全样本？
延伸阅读
- WeiVerifier2025：Verifier's Law。
- PrimeVerifiers2026：eval/RL environment 统一抽象。
- WuRLVR2025：RLVR 测量缺口和 RLVR tax。
- MacDiarmidRewardHacking2025：生产 RL reward hacking 与 agentic misalignment。
- LeeRuntime2026：agent runtime 隔离与 runtime shift。