一篇 9 月 18 日提交的 arXiv 论文（arXiv:2609.21267）记录了一个生产环境里的真实两难：一个服务数万月活用户的生产分析 agent 在持续进化，但它每改一版就要重跑完整评测，成本越来越高。论文基于 574 次历史评测运行，系统比较了四种省钱方案——随机采样、历史缓存、固定代表子集、基于 IRT 的自适应测试。
[1][2]结果分两层。第一层是精度：多维 2PL 自适应测试胜出，只跑 200 题（完整评测的 38.5%），MAE 只有 1.03 个百分点。第二层是现实：论文团队最终部署的并不是最优方案，而是难度分层的固定子集——理由是操作简单。而且这个固定子集无需重新标定就能迁移到另外五个 agent 家族，标定窗口短到一天依然稳定。论文还据此给出了一套生产环境反复评测的实操建议。
这篇论文的价值在于它把"评测"从学术问题拉回了工程问题。学术界关心的是 benchmark 能否衡量能力，生产环境关心的是：每次改一行 prompt、换一个模型版本，我该花多少钱、多长时间才能确认没把产品改坏。完整 agent benchmark 动辄跑上数小时甚至数天，一个快速迭代的 agent 产品根本等不起——所以"用 38.5% 的工作量拿到 1pp 精度的 MAE"这个数字，对任何在生产环境里维护 agent 的团队都是直接的诱惑。而它用的方法（IRT 自适应测试、历史缓存）在标准化考试领域已经成熟了几十年，现在被第一次系统地搬进生产 agent 评测。
更值得留意的是论文里"最优 vs 务实"的落差：理论上 2PL 自适应更好，团队却选了固定子集。这不是妥协，而是生产决策的真实形状——自适应测试的维护成本（每轮题目池管理、标定更新）超过了它带来的精度增益；固定子集虽然精度略低，但可迁移、可解释、不依赖标定基础设施。这个落差恰恰是这篇论文最有信息量的部分：对大多数团队来说，"够好且可维护"胜于"最优但脆弱"。
当然，局限要讲清楚：这是单一家公司的一个 agent 产品的部署经验，574 次运行来自它自己的 benchmark；MAE 1.03pp 是在该评测的口径下，不同任务、不同 agent 形态的误差结构可能完全不同；固定子集的可迁移性只验证了五个同源 agent 家族，不是所有 agent。但论文本身没有夸大——它把部署选择、精度与成本明确分开报告，这正是评测类工作最该有的诚实。
[1][2]