大模型测试的下半场

Agent eval 的对象应该从 answer 扩展到 trajectory

单看最终答案无法区分模型是真会做，还是被工具、prompt、harness 或随机性兜住了。Agent 完成任务时会搜索、读文件、写代码、跑测试、调用 API，这些中间动作决定了结果是否可靠。trajectory 能暴露模型是否查证、是否读对文件、是否验证修改、是否在证据不足时停止。对 Agent 来说，过程不是附属信息，而是能力的一部分。只看 answer 会把“会做”和“碰巧做对”混在一起。

Delegation Intelligence 本质是任务判断力

强 Agent 不需要把所有知识都存在参数里，也不需要所有问题都靠内部推理解决。更重要的是判断任务应该交给什么能力：时效性信息要搜索，复杂计算要写代码模拟，代码修改要跑测试，资料冲突要交叉验证，证据不足要停下来。一个凭记忆自信回答的模型可能偶尔答对，但在真实任务中风险更高。会选择工具、会验证、会停止，才是更可靠的 Agent 行为。

旧 benchmark 的测量对象已经被工具改变

知识问答在 web search 存在时，不再只是测模型记忆，而是测模型能否识别时效性、查找来源并比较证据。长链推理题在 code interpreter 存在时，也不再只是测脑内推理深度，而是测模型是否知道该写程序模拟。工具使用不是作弊，而是任务求解方式的一部分。继续只测闭卷知识或纯脑算，会高估参数记忆和手算能力，低估工具选择、验证和任务分解能力。

Pass@k 看上限，Pass-all-k 看稳定性

Pass@k 只要求 k 次尝试中至少一次成功，适合展示模型上限，但不适合衡量生产可靠性。生产环境更关心多次运行是否都能完成任务。Pass@k 和 Pass-all-k 之间的差距可以反映路径稳定性：差距越大，说明模型越依赖随机性或偶然路径。一个模型偶尔答得很漂亮，但经常漏掉验证步骤，实际使用成本很高。稳定性应该和正确率一起进入 Agent eval。

harness 和 token cost 都应成为显式指标

Agent 表现强烈依赖 harness，包括 prompt 模板、工具定义、执行权限和环境结构。如果换一套 harness 后分数大幅波动，说明模型能力与脚手架耦合很重。token cost 也不只是费用问题，它反映模型是否能快速定位关键文件、避免无效搜索、及时停止。50k token 做对和 5k token 做对不是同一种能力。Agent eval 应同时报告 accuracy、trajectory、stability、harness variance 和 cost。