这个分数，究竟证明了什么。

五项检查，一个明确的契约

一次运行只有在五项检查全部通过时才通过：预期行动、工具调用预算、只读边界、回答的证据支持，以及可选的预期数值。每次工具调用尝试均计数，被策略直接拦截的决策不计入工具调用。

回答必须引用请求工具的一次成功只读步骤；实际参数、指标与时间窗口一致，结果至少有一行，数值有限且注明来源，引用数值与答案相同。这些检查针对标量指标查询流程。

样例采用确定性策略

直接策略接受第一次成功回复；校验策略增加只读拦截、有限超时重试和证据验证。生成输出时，两者都不读取预期契约。工具回复和时钟都是合成的，没有语言模型参与。

通过这八个刻意设计的案例，并不能证明通用 Agent 质量。自由文本推理、SQL 语义正确性、来源真实性、并发 span 和实际权限执行，需要另外验证。记录中的 source 字段只是声明，不是来源认证。

配对、耗时与缺失信息

按案例比较时，请求、契约与时间模式须相同，不满足的记录单独列为不可配对。样例耗时取声明的工具回复耗时合计；真实记录的耗时由导入方提供，可包含步骤间隙，本站不独立校验其真实性。不同时间模式不会合并显示耗时。

本站不估算 token 费用，不给模型排名，也不声称差异具有统计显著性。小型样例集只用于展示具体失败模式。

格式与处理范围

浏览器输入最多 2 MB、200 次运行，每次最多 100 个顺序步骤。步骤 ID 在运行内唯一，策略与案例组合在记录包内唯一；重叠、逆序、越界的时间会被拒绝。评分从记录重新计算，不信任保存的 pass 字段。

文件在当前标签页处理；本站没有上传接口、统计 SDK 或模型集成。浏览器和下载包共用同一个评分核心。关闭标签页会丢弃导入数据，需要保留时请导出。

原始资料与后续实践

Langfuse 数据集文档可用于理解案例积累；OpenTelemetry Tracing API介绍 span 与事件。本站采用更小的顺序原生格式，编写适配前请先下载格式说明。