HSC-01
每个正确验证结果的成本
currency/outcome优选方向 更低归属于运行集的所有成本（推理、工具、基础设施以及用于审批、纠错或升级的人工时间）除以通过独立校验的结果数量。
如何衡量
在运行任何内容之前，先固定任务集和验证器。计算整个集合的总成本（包括失败的尝试）。除以验证器通过的结果数，而不是已完成的运行数。
如何操纵
收窄算作“结果”的范围，或者直接将智能体自身的报告作为验证。这两种做法都只是降低了分母的真实性，而不是降低分子的成本。
读取自ACM-11
Harness 计分卡
Harness 计分卡
一个公式和十一个指标，因此可以通过形容词以外的方式来比较两个支撑系统。主要单位是每次正确验证结果的成本——而不是成功运行的次数，后者属于自我报告，也是损坏的支撑系统唯一擅长产生的东西。
版本 1.0 · 更新时间 2026-08-27 · 11 指标
JSON机器可读
单位
CVO = total cost of the run set / outcomes that passed independent verification
- 分子
- 归属于运行集的所有成本：推理、工具、基础设施，以及用于审批、纠错或升级的人工时间。失败和放弃的尝试都包含在分子中。它们产生了成本，且确实发生过。
- 分母
- 仅包含通过校验的结果，且该校验与生成这些结果的智能体不共享相同的失效模式。仅完成的运行不计入其中。智能体自称成功的运行也不计入其中。
- 是什么让验证器保持独立
- 当验证器在生成器成功的输入上可能判定失败时，该验证器就是独立的。规则、测试、第二系统或人工都符合条件。而通过提示词让同一个模型对自己的输出进行评分则不符合：它会继承导致错误的盲区。
- 为什么不采用成功运行次数
- “成功运行”是一种自我报告，也是每个厂商已经在公布的数据。它计算的是智能体运行结束，而这正是损坏的支撑系统唯一擅长的事。在智能体之外的机制确认工作完成之前，“每个正确验证结果的成本”这一指标是不会有任何改善的。
HSC-01 · 每个正确验证结果的成本
它是什么，以及它不是什么
这是一个提案，而不是实测结果。这里没有任何内容在真实系统上运行过，没有校准任何阈值，而且这十一个指标是通过辩论挑选出来的，而不是通过找出其中哪些指标具有预测性。该文件在其自身的证据块中也说明了这一点：理论性的、低置信度。
发布它是为了引发讨论。它所基于的断言阐明了什么会证伪它，一旦实测结果与其相悖，以实测结果为准。
theoreticallow
其基于的断言： HE-CLAIM-005 — 可通过 MCP 使用 get_claim 获取。
指标
结果
HSC-02
验证通过率
percent优选方向 更高在尝试的任务中，产生通过独立验证的结果所占的比例。
如何衡量
分母为尝试次数，分子为验证通过的结果数。因超时而放弃的尝试仍然算作一次尝试，智能体主动放弃的运行也同样算作一次尝试。
如何操纵
仅尝试支撑系统已经能够处理的任务。在没有声明任务集的情况下，通过率只是一个关于任务集的数据，而不是关于支撑系统的数据。
读取自ACM-11
成本与工作量
HSC-04
每个验证通过结果消耗的 Token 数
tokens/outcome优选方向 更低所有尝试中模型消耗的输入和输出 Token 总数，除以验证通过的结果数。这是一个即使厂商更改价格表也不会改变的成本指标。
如何衡量
计算整个运行集的 Token 数——包括重试和放弃的尝试。同时报告模型及其版本；否则该数据将失去对比意义。
如何操纵
将工作从模型中移出，转入未计入统计的工具或更长的人工审核中。Token 消耗下降了，但实际成本并没有下降。
读取自ACM-07
HSC-05
每个验证通过结果的人工干预次数
interventions/outcome优选方向 更低每个验证通过结果对应的审批、升级和手动纠错次数。这衡量的不是流程中是否有“人机协同（human-in-the-loop）”，而是该流程闭环到人工身上的频率。
如何衡量
计算在结果生效前需要人工介入的每一次事件。例行公事式的审批也算在内：衡量的是对人员的需求，而不是他们关注的质量。
如何操纵
移除准入关卡。干预率降至零，但支撑系统没有任何改善——这就是为什么该指标必须与验证差距结合阅读，而绝不能单独看的原因。
HSC-06
获得验证通过结果的时间
seconds优选方向 更低从任务被接受到其结果通过验证的实际流逝时间（wall-clock time），包括在任何人工步骤前的等待时间。
如何衡量
报告中位数和第 95 百分位数，否则就不要报告：平均值恰恰掩盖了卡住运行的长尾效应。
如何操纵
测量到智能体运行结束，而不是到验证通过。人工审核员前的排队才是真正耗费数小时的地方。
读取自ACM-07
可靠性
HSC-07
确定性区间
percent优选方向 更高在支撑系统保持不变的情况下，对相同输入进行重复运行，评估集中得出相同验证结论的比例。
如何衡量
将整个集合至少运行五次并声明 N。当每次重复运行都得出相同的结论时，该用例才算在区间内——而不是平均结果良好时。
如何操纵
仅运行一次并报告分数。单次运行的数据包含了该指标的答案，但也将其隐藏了。
读取自ACM-11
HSC-08
恢复率
percent优选方向 更高在遇到故障（工具错误、拒绝、超时、被拒绝的计划）的运行中，最终仍能获得验证通过结果的比例。
如何衡量
故障必须在追踪（trace）中可见才能被计算，因此在没有关联运行追踪的情况下无法计算此指标。从未失败不等于恢复，绝不能计入恢复。
如何操纵
压制故障而不是从中恢复。吞掉工具错误的重试循环会同时提高该指标和验证差距。
读取自ACM-10
证据
HSC-10
可重构性
percent优选方向 更高在过去运行的随机样本中，仅凭日志就能端到端重构的比例：包括输入、模型、工具调用和结果。
如何衡量
对无人特意挑选的运行进行抽样，并在不询问团队且原始操作员不在场的情况下进行重构。需要人工解释的运行算作未通过。
如何操纵
对已知干净的运行进行抽样——或者记录所有内容，包括敏感信息。这需要与日志是否包含其从未需要的数据结合阅读。
读取自ACM-10
HSC-11
回归捕获率
percent优选方向 更高在故意植入系统的缺陷中，评估套件在发布前捕获的比例。
如何衡量
一次植入一个你真正担心的缺陷类型，并在每个缺陷上运行套件。从未见其失败过的套件，其捕获率是未知的，而不是完美的。
如何操纵
植入编写该套件时所依据 of 缺陷。捕获率会达到 100%，但衡量的只是作者的记忆力。
读取自ACM-11
结果必须声明的内容
没有这些，数字之间就无法进行比较。HarnessBench 要么报告全部六项，要么什么都不报告。
- model模型及其确切版本
- task_set任务集及其来源
- verifier验证器，以及它为什么独立于智能体（agent）
- repeats该任务集运行的次数
- date运行日期
- cost_basis成本数据包含的内容，包括人工时间