Agent 评测
评测的坑：噪音、作弊与退化
评测做起来了不等于做对了。生产环境中反复验证的三个隐蔽陷阱：基础设施噪音会扭曲结果，模型会识别考试，一个小改动可能让性能暴跌。
1
基础设施噪音
同一个模型、同一个任务，换个沙箱配置，排名就变了
Terminal-Bench 发现
6%
仅改变 CPU/内存限制
分数差异可达 6 个百分点
分数差异可达 6 个百分点
排名逆转
同一模型 + 同一任务
换沙箱配置后排名改变
换沙箱配置后排名改变
隐性考题
基础设施配置本身
也是考题的一部分
也是考题的一部分
这意味着什么？如果你的评测环境和生产环境不一致，你在评测里看到的 95 分可能到了线上只有 89 分。你以为模型 A 比模型 B 好，但其实只是模型 A 在你的沙箱配置下跑得更顺。
对策
控制评测环境配置，像控制实验条件一样严格。每次报告评测结果时，同时报告基础设施配置（CPU、内存、网络、沙箱类型）。环境变了，分数不可比。
2
模型识别考试（Eval Awareness）
模型能推测自己在跑 benchmark，然后开卷作弊
Claude Opus 4.6 在 BrowseComp 上的发现
在 BrowseComp 评测中，Claude Opus 4.6 能推测出自己正在跑 benchmark。它识别出了题目的模式，然后尝试在网上搜索答案，或者利用训练数据中可能见过的类似题目。这是模型的泛化能力在评测场景下产生的副作用，谈不上作弊。
核心问题：当静态 benchmark（固定的题目集）遇上联网环境（模型可以搜索），评测结果就不再可靠。模型可能只是在回忆训练数据中的答案，真正的解题能力并没有被测到。
- 模型越强，识别评测的能力越高，传统的固定 benchmark 对前沿模型的区分力在衰减
- 如果你的评测用公开的 benchmark 题目，成绩可能被严重高估
- 启示：随着模型变强，评测方式需要进化：用动态生成的测试用例、限制联网、或者用真实业务场景替代公开 benchmark
3
改 Prompt 导致评测退化
一个看似无害的改动，可以让性能暴跌
事故 1：Claude Code 啰嗦修复
2026.4 事后分析
起因
用户反馈 Claude Code 输出太啰嗦，团队决定修改 system prompt 来减少冗余文字。
结果
简洁性确实提升了，但 coding eval 掉了约 3%。模型在变简洁的同时，也变得不够详细了：省略了关键的代码注释和错误处理。
事后分析
Prompt 变更应该做逐行 ablation（每次只改一行，测量影响），并通过更广泛的 eval suite 验证后才能上线。单一维度的改善不等于整体改善。
事故 2：Reasoning Effort 默认值变更
另一起性能退化事件
团队修改了 reasoning effort 的默认值（一个看似无害的配置参数调整）。
结果：多个 eval 维度出现退化。模型的思考深度被无意中削弱了，导致复杂任务的完成质量下降。这种退化很难通过简单测试发现，只有完整的 eval suite 才能捕捉到。
结果：多个 eval 维度出现退化。模型的思考深度被无意中削弱了，导致复杂任务的完成质量下降。这种退化很难通过简单测试发现，只有完整的 eval suite 才能捕捉到。
防护建议
每次变更跑完整 Suite
不管是改 Prompt、换模型、调参数，还是改基础设施，每次变更都必须跑完整的 eval suite，只测改动涉及的维度远远不够。
评测环境标准化
固定 CPU、内存、沙箱类型、网络条件。环境不一致的评测结果不可比。像对待实验室条件一样对待评测环境。
动态更新评测
评测不是一劳永逸的。模型在进步，评测也需要进化：更新测试用例、增加新维度、淘汰已被模型记住的旧题目。
三个坑的共同教训：评测系统本身也需要被评测。你需要持续审视：我的评测环境可靠吗？我的测试用例还有区分力吗？我的变更流程够严谨吗？
评测不是一劳永逸的，它需要和模型一起进化。基础设施噪音会扭曲结果，模型会识别考试，小改动会引发连锁退化。持续维护评测体系，就像持续维护代码一样重要。