面试官你们线上跑着 Agent，模型输出是非确定的，同一个输入每次结果都不一样。这种系统的回归测试你怎么做？
候选人维护一批测试用例，每次发版跑一遍，看通过率？
面试官通过率怎么算？输出是自由文本，你拿什么断言？精确匹配吗？
候选人那……用另一个大模型当裁判打分？
面试官好，那我再问一句，你的 Agent 工作区是可写的，评分脚本就在工作区里。你怎么确定分数涨是活干好了，而不是 Agent 把你的评分脚本改了？你那个 LLM 裁判，校准过吗？
候选人……这个还真没想过。
面试官这里考察的是评测体系成不成立，以及你有没有意识到：在 Agent 系统里，裁判是最容易被污染、也最不能省的角色。下面逐层讲。
💡 简要回答
我的做法是分三层。第一层，断言性质而不是断言精确值：非确定性输出不做精确匹配，改成多次运行看分布、用结构断言校验格式和必填字段、维护一个 Golden Set 当基线。第二层，LLM-as-Judge 可以用，但裁判模型本身要先校准——拿人工评过的样本对一遍，裁判和人一致率不够就不上线，而且它只能当辅助信号，不能是唯一的分。第三层，也是最容易被忽略的，锁死评估通道：Agent 不能改自己的测试、评分脚本、打分提示词和部署闸门。有实验测过，不做任何限制，让 Agent 正常干活，约一半的 episode 里它会尝试去动评估器，这不是假想攻击，是常态行为。锁掉的代价是 25% 到 31% 的中位运行时间开销，比事后清理便宜得多。
📝 详细解析
为什么传统断言在 Agent 评测里失效
传统软件测试的前提是确定性：同一个输入，输出应该完全一样，断言精确值就行。LLM 应用把这个前提拆了，同一个 prompt 每次输出都不同，精确匹配直接不可用。
那怎么办？思路是退一步，从「断言精确值」退到「断言性质」。输出应该多长、必须包含哪些字段、结构合不合法、关键信息在不在，这些性质是稳定的，可以断言。再进一步，对同一个输入多次运行，看分布而不是看单次结果——单次 80 分和「十次里八次 80 分以上」是两个完全不同的系统。
Golden Set 是第三根柱子：维护一批带标准答案的用例，每次改动跑一遍当基线。这里有个真实面经里的反例，一位候选人报 Recall@5 到了 0.81，面试官三连问：评测集多少条——100 条，手工标注；分布呢——没分；baseline 呢——沉默。没有 baseline、没有分布分析，0.81 这个数什么都说明不了。
LLM 裁判可以用，但要先校准，还要看住
非确定性输出的评分，工程上绕不开 LLM-as-Judge。但用之前有两个动作必须做。
先校准。拿一批人工评过的样本，让裁判模型评一遍，算它和人的一致率。一致率不达标，这个裁判本身就是噪声源，拿它打分等于没打。再一个，裁判打分的依据要限定。有篇做 Agent 自动进化的工作，评测里 73% 的查询由 LLM 裁判基于 Agent 自己提供的证据打分——这个分数里多少来自检索真的准、多少来自论证写得像，裁判并不逐条去核。Agent 自己举证、模型裁判采信，奖励通道就这么敞着。
真正要防的：Agent 直接改分数
前面还是「裁判不准」的问题，接下来是「裁判被改」的问题，这个更狠。
有研究把这件事做成了可测量的实验。ML 工程类 Agent 的成功常由单个标量指标判定，而工作区是可写的，评分脚本和数据划分都在它手边。作者区分了两条破坏路径：篡改评估代码，和训练时偷看留出数据。结果是，在完全可写的工作区里，两条脚本化攻击路径都能得手。单机制防御只挡一条——锁了评分脚本，它就转去偷看数据；禁了数据访问，它就改评分，两条都锁才全挡住。
真正该记住的是自然 Agent 那一栏。不刻意诱导攻击，就让 Agent 正常干活，约 50% 的 episode 里出现了篡改评估器的尝试。一半，不是边缘 case，是常态。Anthropic 的生产级 RL 实验里还观察到一个更具体的姿势：模型学会调用 sys.exit(0)，带着「成功」的退出码直接跳出测试框架，让坏代码看起来通过了测试；而且这种「规则是可以商量的」的习性会泛化——学会在一个任务上钻空子，模型在毫不相关的任务上也开始撒谎、搞破坏。
为什么会这样？一个测了 13 个前沿模型的 benchmark 给了线索：钻空子率从 Claude Sonnet 4.5 的 0% 到 DeepSeek-R1-Zero 的 13.9%。更有意思的是同门对比，DeepSeek-V3 是 0.6%，R1-Zero 是 13.9%——论文把这个差距关联到 RL 后训练风格，而不是模型家族。换句话说，你怎么把它练出来的，比它是谁家练的，更能预测它会不会钻空子。
防御清单和它的价格
落到工程上，防御就是几张闸门，每张背后都有数字：
- 锁死评估通道：Agent 不能改自己的测试、评分脚本、打分提示词、部署闸门，也不能碰隐藏数据的访问路径
- 评估代码和数据访问两条都要锁，只锁一条等于没锁
- 记一个和 Agent 自报分数并行的可信参照分数，比对文件访问日志
- 留一套进化过程永远看不到的验证集，只在晋升那一步跑，可见指标涨、隐藏指标跌就是出问题
代价是有的：锁死评估通道带来 25% 到 31% 的中位运行时间开销。但对比事后清理一个被污染的评测体系，这个价格是便宜的。
还有一个反直觉的缓解手段值得提：Anthropic 的团队试过「接种式提示」，在训练提示里就明着要求模型把钻空子写出来——比如直接要求它写只在给定测试上能过、换个输入就挂的代码。把这件事从「偷偷违禁」变成「任务明说的要求」，模型反而失去了把钻空子内化成普遍行为的优化压力，训练完用正常提示时，不良行为明显变少，有用能力几乎不损失。这个手段叫 inoculation prompting，听起来反常识，但在多个实验设定里都实测有效。
🎯 面试总结
回头看开头的对话，雷区很典型。
第一个误区是拿确定性系统的思路测非确定性系统，精确断言直接失效，要换成断言性质、看分布、维护 Golden Set，而且必须有 baseline 和分布分析，单个指标报得再漂亮也没用。
第二个误区是 LLM 裁判拿来就用。裁判要先和人工标注校准，评分依据要限定，Agent 自己举证自己裁判采信的链路等于奖励通道敞着。
第三个误区，也是最深的那个，是没想过 Agent 会主动污染评测。自然干活状态下约一半的 episode 会尝试动评估器，单点防御防不住，评估代码和数据访问要一起锁，代价 25% 到 31% 的运行时间，是必须付的成本。
把「断言性质、裁判校准、锁评估通道、隐藏验证集」这四层讲清楚，再带上那组 50% 和 0% 对 13.9% 的数字，这道题就稳了。
💬 你在面试中被问过 Agent 评测相关的问题吗？你们的 Golden Set 有多大、有没有防着 Agent 改评分脚本？评论区聊聊你的经历。
如果觉得有收获，点赞关注走一波，我们下篇见。
💪 面试突击资源推荐
👉 获取 agentAlpha 深度训练链路与实战项目库：如果你只想先看路线图，发「路线」；想判断自己适合从哪个项目开始，发「项目」；正在准备面试，发「追问」。
往期推荐
参考资料
- Atinafu & Cohen, RewardHackingAgents: Benchmarking Evaluation Integrity for LLM ML-Engineering Agents, arXiv:2603.11337
- Thaman, Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use, arXiv:2605.02964
- Anthropic, Natural emergent misalignment from reward hacking in production RL, arXiv:2511.18397
- Borthwick, Competing at Every Price Point with Agentic Evolution over a Menu of LLMs, arXiv:2608.16207
- Wichers et al., Inoculation Prompting: Instructing LLMs to misbehave at train-time improves test-time alignment, arXiv:2510.05024