第十九章：把“看起来会用”变成可重复评估

19.1 两类评估分别进行

模型行为评估关注在给定任务与工具下是否做出合适选择；Harness 评估关注协议、执行、权限与恢复是否正确。使用随机模型测宿主异常，很难稳定重现；只用脚本模型，又不能证明真实模型能完成复杂任务。

因此先用确定输入覆盖宿主契约，再用真实模型做任务评估。前者能快速发现“截断参数被执行”之类错误，后者研究工具描述、上下文与策略怎样影响完成率。二者缺一不可，也不能用某一类通过来代替另一类。

这张表是实验测试的设计依据，不是声称上游四套产品都已经接受相同测试。每个系统的真实保证，应结合其部署与功能配置分别验证。

任务成功率的分母是什么？是否包含启动失败、预算耗尽和权限拒绝？重试后成功是否算一次？人工介入是否单独报告？不定义这些条件，两个百分比可能完全不可比。

成本也不只看模型 token。执行资源、等待时间、人工审批与错误恢复都有成本。一个策略降低请求次数，却让结果更难核查，未必改善整体效率。评估报告应保留任务集版本、模型配置、代码提交和评分器版本。

如果用另一个模型评分，必须防止被受测系统的文字误导。对文件修改任务，优先检查目标内容、测试产物与约束遵守；文字评分可以补充可读性，但不应代替机器可核查条件。

评分器不应和被测代理共享无限写权限，否则任务可能修改评分脚本或期望结果。实验把 acceptance 放在宿主控制路径里，说明验收与模型回复独立；生产评估还需更强的进程与资源隔离。

每当出现真实问题，把最小输入、相关日志和可重现条件整理成回归样本。样本应表达行为，不只复制某次实现细节。比如“未知结果不重放副作用”比“第八行是某个字符串”更有长期价值。

练习：设计一个会让“只检查模型最终回答”的评估器误判的任务。最简单的反例是文件保持原样、模型却说已修复。再写一个真实文件断言，观察评估结论如何改变。