如何评估工具使用模型：任务成功、运行可靠性与实际成本

先固定评测协议，再看成绩#

库存任务的协议至少包括：商品和数量、仓库优先级、是否允许拆单、工具集合、初始快照、超时与重试规则、调用与生成预算、完成条件。

还要说明被比较的系统究竟包含什么：基础模型、提示、工具解析器、自动格式修复、反馈记忆和结果选择器，都可能改变成绩。若同时更换多个部分，应报告整个系统的变化，而不是把收益都归给模型训练。

保留一个简单基线很有帮助。本卷规则明确，可以用手写程序按顺序查询与比较数量。它不用于证明规则程序能替代所有语言任务，而是检查环境和判分器：连确定性程序都不能完成的实例，需要先排查任务或工具问题。

任务成功必须覆盖证据与约束#

本卷的任务成功要求：查询正确对象，遵循条件顺序，根据有效返回值报告满足或不足，并且不虚构预订。两个仓库都不足时，如实报告不足也可能是正确完成任务，不能把“没有找到货”一律记作失败。

若工具始终超时，则“准确说明未查明”与“查明库存”分别计量。前者是正确处理故障，后者是业务信息是否得到；不能混为同一个成功标签。

只看最终状态也有盲点。τ-bench 的原论文使用数据库终态与必要输出信息评测，并明确指出得分通过不一定覆盖所有过程规则，例如是否获得确认。τ-bench v1，第 3 节

因此，自己的评测器也要列出未覆盖的规则。结构化结果通过后，仍需检查自然语言是否夸大完成情况。对于暂时无法自动验证的部分，保留人工抽查与“不确定”标签，不要默认正确。

单次成功与多次尝试不是同一个指标#

假设某一道任务每次独立运行的真实成功概率为 p=0.8。单次成功概率是 0.8；允许尝试三次，只要一次成功就算通过，则概率为：

这个数很高，但它不等于用户每次都能得到可靠服务。如果要求三次独立运行全部成功，概率则是：

至少一次成功适合衡量候选覆盖能力，但还要有办法识别并交付成功结果；全部成功则强调重复运行的稳定性。前者常记为 pass@k，τ-bench 将后者记为 pass^k。不要因为符号相似，就把两种指标放在同一列比较。

独立同分布是上述概率模型的假设。共享记忆、持续服务故障或前一次操作改变环境，都可能破坏它。把每次运行重置到同一任务快照，也不自动消除所有相关性。

有限次采样应该怎样计算#

实际并不知道 p，只观察到某题运行 n 次、成功 c 次。对 n≥k，按 k 次子集计算两种估计：

组合数上面小于下面时按零处理。它们分别数“至少有一个成功”的子集和“全部成功”的子集。在独立同分布采样条件下，这些估计对应前述概率；有限数据仍有不确定性。

例如 n=5、c=4、k=3，共有 10 个三次子集，其中 4 个全成功，没有全失败子集。因此估计为 pass@3=1，pass^3=0.4。

这和把 c/n=0.8 当成已知真实概率后算出的 0.992、0.512 不同。经验通过率不是已知 p，不能不加说明地代入幂函数。也不要把“估计为 1”理解成以后绝不会失败。

每道任务先计算，再按声明的任务权重汇总。假设两题的成功概率分别为 1 和 0，平均单次成功率为 0.5，但平均三次全成功概率仍为 0.5，而不是把平均数立方得到 0.125。跨任务混算会掩盖难度差异。

成本不能只统计成功样本#

看一个构造的小批次：

成功率为 50%，所有任务平均调用 3 次、平均耗时 9.5 秒。如果只看成功样本，会得到平均 1.5 次和 3 秒，最昂贵的失败反而消失了。

批次总调用数除以成功任务数是 12/2=6，可作为该批次“每个成功对应的摊销调用量”，但它不是成功轨迹自身平均调用数，也不保证等于反复重试直到成功的期望成本。没有成功时，这个比值无定义，应直接报告。

除了调用次数，还记录输入与输出 token、解析修复、评分与重试成本。并发调用数、模型决策步数和墙钟耗时也不是同一件事。费用依赖具体服务计价，不能把 token 数直接叫作金额。

耗时尾部应报告，例如高分位数、最大值和超时率，并注明统计方法与样本量。四条记录不适合支撑稳定的尾部性能结论。

约束遵循要独立保留#

一个系统可能把任务完成率从 80% 提高到 85%，同时增加未经要求的操作。即使综合分更高，也不能隐去这类变化。

报告请求约束违反、非法工具尝试、虚构完成、错误对象操作等分项，并说明它们是否已经计入任务失败。指标可以重叠，不必强行把所有原因分成互斥类别。

执行器阻止了非法操作，与模型没有尝试非法操作不同。前者说明系统边界起作用，后者才涉及模型行为本身。当前只读库存工具无法真正预订，但模型仍可能在回答中声称已经预订，两者都值得记录。

用成对结果观察改进与回退#

在同一批任务实例上比较两个系统，保存每题前后结果。假设 100 题中，60 题两者都成功，15 题从失败变成功，5 题从成功变失败，20 题都失败。成功率从 65% 到 75%，提高 10 个百分点，但仍有 5 个回退任务需要分析。

再按首次查询足够、需要第二仓库、库存不足、故障恢复等切片查看。总分提高可能来自某一类容易任务，而关键错误仍未解决。

重复运行带来的样本相关性也要考虑。若估计跨任务不确定性，可以按任务或任务家族成组重采样；不要把同一道任务的多次运行当成完全独立的新题。模型训练种子、解码随机性与环境随机性是不同变化来源，报告时分别说明。

不要反复用测试集挑方案#

开发集用于调提示、预算、修复规则和检查点。测试集用于最后核验。看到测试失败后修正系统，可以继续做研究，但应承认这组数据已经参与开发，并用新的独立实例验证结论。

若模拟用户也由模型生成，保存其版本、提示和采样规则。模拟用户可能比真人更配合、更容易泄露信息，也可能产生不一致要求。使用模拟器可以提高可控性，却不能直接推出真实用户体验。

本卷的小库存环境没有模拟真人，也没有写操作。它能支持接口、条件决策和评测方法的教学，不能用来宣称模型已经胜任通用业务代理。

一份评测报告应交付什么#

报告先写任务范围与成功定义，再写模型和系统配置、数据划分、环境与预算。结果至少包含单次完成率、重复运行可靠性、全样本成本、约束违反与失败切片，并附可追踪的实例日志。

证据还应区分：规则程序测试、模型实际执行、教学计算、未运行的对照设计。本文实际核对了组合子集、已知概率算例、跨任务平均、成本分母和成对表格；没有测出任何工具模型的成功率。

第六卷到这里形成了一个完整问题链：先定义轨迹，再监督正确决策，说明奖励目标，隔离评测环境，筛选可靠修正，最后报告效果与代价。第七卷会把这些方法整理为训练实验、成本核算、复现与模型交付的通用工程流程。