使用 Braintrust 从大规模 Hugging Face 数据评估 agent 设置

2026年6月24日 Jess Wang 27分钟

在生产环境中运行 AI agent 会产生 traces，但理解这些 traces 是一个更复杂的难题。原始的 agent traces 本身并不包含答案。你仍然需要弄清楚如何查询它们、评分它们，并确保你看到的模式是真实的。

为了理解这个过程，我们从 Hugging Face 上托管的 Exgentic 中获取了 1,781 条真实的 agent traces，并使用 Braintrust 处理它们以发现模式和高层经验。

以下是我们做了什么、如何做的，以及数据实际展示的内容。

主要结论（如果你只有 5 分钟）

1. Harness 的重要性大约是模型的 7 倍。 如果保持模型不变但更换 harness，成功率可能从 12% 波动到 92%。这种改变也几乎是免费的，因为 harness 的选择对 token 成本几乎没有影响。

2. 开放权重模型在编码任务上已可投入生产。 DeepSeek 和 Kimi 成功解决了 96% 和 94% 的 SWE-bench 任务，与最好的闭源模型持平。好处是你可以自行托管这些模型。

3. 高平均值并不意味着可靠。 某些配置整体得分不错，但在特定任务类型上表现糟糕。可靠的配置在各套件间表现一致；高方差配置至少在一个套件上严重失败。

4. 没有通用的赢家。 Claude 赢得了 SWE-bench 和客服任务，Gemini 赢得了航空支持任务，DeepSeek 和 Kimi 赢得了 AppWorld 任务。对于“哪个是最好的模型？”这个问题，答案总是“取决于任务”。

5. 每任务成本和每成功成本对配置的排名截然不同。 开放权重模型每个成功的 SWE-bench 任务成本为 $0.73–$1.27。闭源模型成本为 $4–$5。在对话任务上，gpt-4.1 以每个成功 $0.02–$0.03 的成本逆转局面。

6. 不要总是相信 token 效率。 gpt-4.1 在 token 上看起来便宜 10–100 倍，但在困难任务上，它便宜是因为它早早失败，而不是因为它更聪明。没有成功的成本只是浪费了更少 token 的失败。

7. 失败模式截然相反。 失败的编码 agent 会使用更多 token，因为它们会无效挣扎。失败的客服 agent 会使用更少 token，因为它们早早放弃。

数据集：我们处理的内容

该数据集来自 Hugging Face 上的 Exgentic，包含跨六个 benchmark 的 1,781 次 agent 运行。每次运行包括一个任务、agent 的完整对话（它进行的每一次 LLM 调用）以及元数据，如模型、benchmark、harness、token 数量和 LLM 调用次数。每次运行为单个 LLM 调用生成子 spans。所有 1,781 次运行共有约 49k 个子 spans，平均每次运行约 27 次 LLM 调用。

需要注意的是，该数据集没有 ground-truth 标签。Exgentic 从未导出评分结果，因此所有 scores 和 expected 字段均为 null。我们必须从头构建自己的成功度量，这将在后续章节中介绍。

模型

数据集中出现了六种模型：

模型 (API 名称)	通用名称	类型
claude-opus-4-5	Claude Opus 4.5	闭源
gemini-3-pro	Gemini 3 Pro	闭源
gpt-4.1	GPT-4.1	闭源
gpt-5.2	GPT-5.2	闭源
Kimi-K2.5	Kimi K2.5	开放权重
DeepSeek-V3.2	DeepSeek V3.2	开放权重

闭源模型是专有的，意味着你可以通过 API 访问它们，但权重不公开。开放权重模型发布其权重，因此你可以下载并自行托管。

Benchmarks

数据集中的六个 benchmark 涵盖了根本不同类型的任务：

Benchmark	测试内容
SWE-bench	在一个大型现有代码库中修复一个真实的 GitHub issue。迭代地读取文件、编辑代码、运行测试。纯软件工程。
AppWorld	通过编排应用 API（Venmo、Gmail、Spotify、Splitwise、Todoist）完成个人助理任务。通常代码密集。
BrowseComp+	通过浏览网页回答一个困难的研究问题。无需编码。
TAU2 Airline	处理航空支持请求的客服 agent，通过工具进行。
TAU2 Retail	处理零售/电商支持的客服 agent。
TAU2 Telecom	处理网络和技术支持的客服 agent。

Harnesses

Harness 是包裹在模型周围的 agent 脚手架。模型（如 Claude 和 GPT）只预测文本，但 harness 负责上下文管理并将该文本转化为行动。它将任务和可用工具格式化为 prompt，将模型的输出解析为实际动作，执行这些动作，将结果反馈回去，管理循环，处理重试，并决定何时停止。

数据集中出现了五种 harness：

• claude_code：Anthropic 的原生 agent 循环。使用 Claude 的自定义 XML 格式进行工具调用，并原生管理 agent 循环。
• tool_calling：结构化的 JSON 函数调用，一次一个工具调用。标准方法，但约束更严格。
• tool_calling_with_shortlisting：与上述相同，但有一个预过滤步骤，每次轮次缩小提供的工具范围。
• smolagents_code：Hugging Face 的框架。模型编写 Python 代码来调用工具，执行它，并返回输出。允许 agent 在单一步骤中链式处理逻辑。
• openai_solo：一个最小的 OpenAI 风格脚手架。薄封装。

将数据从 Hugging Face 导入 Braintrust

该数据集在 Hugging Face 上以 39 个 Parquet 分片形式提供。Parquet 文件是一种列式数据格式，常用于高效存储大型数据集。“分片”仅意味着数据集被分割到 39 个单独的文件中，而不是一个大文件，这是 Hugging Face 上大型数据集的常见模式。

我们使用一个小型、可重用的 cookbook 脚本 hf_bt_cookbook/import_logs.py 导入数据。它是一个你可以编辑并重新运行的示例，而不是一个黑盒：整个映射位于文件顶部的 EDIT ME 块中，你可以在其中指定 Hugging Face 仓库以及哪些列包含 session ID、trace、元数据和任何分数。该脚本将每个原始 session 转换为 Braintrust 格式的 JSONL spans，并通过 bt sync push 上传。以下是它的工作原理：

1. 流式读取行，使用 datasets.load_dataset("Exgentic/agent-llm-traces", streaming=True)。流式读取按需拉取行，因此无需在本地下载和物化所有 39 个 Parquet 分片。
2. 一个 session，多个 spans。 对于每个 session 行，发出一个根 span（type=task），包含初始任务、agent 的最终响应以及所有 session 元数据，以及每个 LLM 调用的一个子 span（type=llm），包含输入/输出消息和每次调用的 token 指标。
3. 确定性 span ID。 root_id = uuid5(NAMESPACE_DNS, "root:" + session_id)。这后来很重要，因为稳定的 ID 意味着重新导入会更新相同的行而不是重复，并且使得分数写回成为可能。
4. 消息规范化。 源使用 OpenTelemetry GenAI "parts" 格式，但我们转换为 OpenAI 风格的消息，以便 Braintrust 将它们渲染为可读的聊天轮次。
5. 预览，然后上传。 运行脚本会写入 JSONL 并打印 span 和 session 计数，不进行网络写入。传递 --push 会为你运行上传：bt sync push project_logs:"Hugging Face topics" --in out/logs/。

如果你的技术栈已经原生导出 OTel spans，Braintrust 可以直接通过 OpenTelemetry 集成 接受它们，无需转换步骤。

最终输出是所有 1,781 个 session → Hugging Face topics Braintrust 项目中的 1,781 个根 spans。

同一个 cookbook 还提供了 hf_bt_cookbook/import_dataset.py，如果你想要运行评估而不是分析现有 traces，它可以将 Hugging Face 数据集转换为可评分的 Braintrust 数据集。

导入后，每次运行都是一行，你可以在任何元数据字段上排序、过滤和切片：模型、benchmark、harness、tokens、分数、持续时间。Braintrust Logs 视图将 1,781 个不透明的 Hugging Face JSON 文件转换为一个可查询的表格。

数据集有一个问题。每个 benchmark 根据某些隐藏的内容评分，如测试用例、数据库状态或专有评分标准，但这些都没有随 traces 一起导出。基本上，traces 包含运行信息，但不包含判定结果。

此外，原始数据集中的 error 字段不是崩溃标志。它是一个诊断字符串，如 "[N tool error(s) detected. Examples: ...]"，即使 N=0 时也会出现。所以这里的“错误率”几乎毫无意义，这正是需要一个真正的成功度量的原因。

为了解决这个问题，我们构建了一个 LLM-as-judge 代理来判断任务完成的成功率。

本质上，对于 1,781 次运行中的每一次，我们提取完整的最终对话（所有工具调用、结果、agent 的最终消息），将任务、对话和 benchmark 特定的评分标准提供给 gpt-4.1，并返回 success (0/1)、confidence (low/medium/high) 和简短推理（≤35 个词）。

以下是我们用于 LLM-as-a-judge 的 prompt：

You grade whether an AI agent SUCCEEDED at a task, from its execution trace.Task type: {benchmark description}Grading rule: {benchmark-specific rubric}You see the task and the agent's full final conversation incl real tool outputs.Judge from visible verification; you may NOT have the official grader.Be strict: ambiguous/unverified = 0.Respond ONLY with JSON: {"success":0 or 1,"confidence":"low"|"medium"|"high","reasoning":"<=35 words"}

注意：我们使用 GPT-4o 来评判 gpt-4.1 自身的运行，以避免自我评分。

可靠性因 benchmark 而异：

• SWE-bench（强）： 评判者可以看到实际的 diff 和测试输出，可以独立验证。
• AppWorld 和 TAU2（中等）： 评判者可以看到工具调用和 agent 的确认，但看不到隐藏的数据库状态。
• BrowseComp+（弱）： 没有标准答案。评判者必须从推理质量推断。

一旦我们有了分数，我们将它们作为 scores.task_success 和 metadata.judge_* 写回 Braintrust 中的每个根 span。由于 Braintrust spans 是不可变的记录，我们不能简单地修补一个字段。我们必须重建完整的行（原始数据 + 新分数）并通过 bt sync push 重新上传。

LLM-as-a-judge 实际应用示例

例如，我们有一个 AppWorld 运行，它在原始 Hugging Face 日志中干净地完成，零工具错误，但我们的 LLM-as-a-judge 判定为失败。

• 日志： 86c1014d-321f-522b-ae63-5a0b2da977f9，appworld，claude-opus-4-5
• 任务： "将 Venmo 上的好友重置为与手机通讯录中的好友相同。根据需要添加和删除好友。"
• 评判者推理： "Agent 仅尝试从 Venmo 删除好友，但没有从手机联系人中添加缺失的好友。任务要求同时进行添加和删除好友。"
• Agent 实际做了什么： 登录 → search_friends ×3 → show_profile ×2 → remove_friend ×~15 → finish(success)。零次 add_friend 调用。

从 trace 中，我们了解到 agent 完成了任务的一半，宣布成功，并且错误日志完全干净。一个基于完成状态或错误计数的指标会将其判定为通过。这就是为什么 task_success 必须基于 trace 内容构建，而不是基于状态码。

值得注意的是，Braintrust Topics 自动发现了这个失败类别，无需我们指出。Issues 面将 agent 的不当行为聚类为 11 个命名组，而 False success confirmation（10.9%）正是上述 Venmo 模式。Incomplete multi-step execution（32.2%）和 Truncated task completion（13.7%）与我们稍后量化的无效挣扎和放弃模式相匹配。我们手动构建的失败分类法自动从聚类中得出。

分析数据

如何阅读这些图表

在深入之前，先快速参考一下下面图表中视觉元素的含义：

符号	含义
误差线 / ±	成功率的 Wilson 95% 置信区间；小样本时变宽，保持在 [0,1] 内
条形高度	合并（微观）成功率：k/n 跨配置的所有运行
♦ 菱形	Benchmark 平衡（宏观）率：每个套件成功率的平均值，等权重
箱线图 / 须线	IQR（第 25–75 百分位），中位数线，须线 = 1.5×IQR

为什么不能直接合并平均值

并非所有模型都运行了所有 benchmark。Claude 和 Gemini 在所有六个 benchmark 上运行。DeepSeek 和 Kimi 只运行了 AppWorld 和 SWE-bench。gpt-4.1 只运行了 TAU2。在这种不均匀覆盖下合并平均值是辛普森悖论，一个模型可能仅仅因为它运行了更简单的任务而看起来“更好”。

模型	appworld	browsecompplus	swebench	tau2_airline	tau2_retail	tau2_telecom
claude-opus-4-5	119	49	138	34	126	43
gemini-3-pro	170	77	30	38	34	12
Kimi-K2.5	49	7	75	—	—	—
DeepSeek-V3.2	62	—	55	—	—	—
gpt-4.1	—	—	—	124	295/14	131
gpt-5.2	—	—	37/15	—	—	—

解决方法是仅在 benchmark 内部进行比较。我们不合并所有运行，而是对每个配置在每个 benchmark 上的成功率进行等权平均。平衡意味着无论任务数量多少，每个 benchmark 都获得相同权重。这样，一个配置就不能仅仅通过运行更多简单任务来抬高其总体得分。我们还附加了 Wilson 95% 置信区间，以便小样本单元格显示为不确定，而不是自信的极端值。例如，10 次运行中 10/10 的成功率与 138 次运行中 138/138 的成功率读起来截然不同。

条形图显示合并率；菱形显示 benchmark 平衡率。当菱形位于其条形图左侧较远时，该配置的总体数据因简单的任务组合而显得更好。

在图表中，实心条形代表至少运行了三个套件的 harness x 模型组合，因此我们认为这些组合在统计上最有意义。其中，claude_code 是最强的 harness。与 Claude 搭配时达到 73%，与 Gemini 搭配时达到 71%，均领先于三个 gpt-4.1 harness 配置（tool_calling 为 61%，smolagents_code 为 61%，openai_solo 为 28%）。

终极表格

然而，单个（harness × 模型）单元格通常混合了不同的 benchmark。Claude 的 119 个 AppWorld session 分布在 tool_calling（83）、claude_code（27）和 openai_solo（9）上。因此，真正公平的比较单位是 benchmark × harness × 模型。

下表结合了每个（benchmark × harness × 模型）组合的 token 成本、持续时间、LLM 调用次数和判定成功率，这些组合至少有 10 次运行，这是我们视结果为有方向性意义所需的最低数量。

APPWORLD n calls Mtok dur succ%claude_code DeepSeek-V3.2 25 19.9 2.25 387 80claude_code Kimi-K2.5 18 17.7 1.17 398 78claude_code claude-opus-4-5 27 31.7 4.19 316 26smolagents_code Kimi-K2.5 12 12.9 0.53 429 92openai_solo gemini-3-pro 20 19.2 1.10 339 10tool_calling DeepSeek-V3.2 11 17.7 1.64 891 36tool_calling gemini-3-pro 77 15.6 0.59 263 16tool_calling claude-opus-4-5 83 25.7 2.09 221 14tool_calling Kimi-K2.5 17 17.5 0.91 657 12tcw_short DeepSeek-V3.2 17 19.3 0.21 531 18tcw_short gemini-3-pro 64 28.8 0.27 370 9BROWSECOMPPLUS n calls Mtok dur succ%claude_code claude-opus-4-5 49 30.1 2.41 168 69claude_code gemini-3-pro 77 20.5 1.29 231 55SWEBENCH n calls Mtok dur succ%claude_code claude-opus-4-5 138 27.8 0.82 213 100claude_code DeepSeek-V3.2 26 58.8 2.07 1220 96claude_code Kimi-K2.5 35 46.0 1.08 477 94claude_code gpt-5.2 15 29.9 0.74 106 93claude_code gemini-3-pro 30 52.2 1.87 469 87claude_code Az/gpt-5.2 37 24.1 0.52 144 76smolagents_code DeepSeek-V3.2 24 63.8 1.62 1503 88smolagents_code o/Kimi-K2.5 28 87.9 2.58 700 75smolagents_code o/DeepSeek-V3.2 13 84.7 2.36 647 69openai_solo Kimi-K2.5 12 36.8 0.33 227 33tool_calling Kimi-K2.5 21 43.3 0.55 273 29TAU2_AIRLINE n calls Mtok dur succ%claude_code gemini-3-pro 38 11.1 0.24 124 100claude_code claude-opus-4-5 34 12.1 0.32 74 65tool_calling gpt-4.1 59 5.8 0.01 24 47smolagents_code gpt-4.1 47 6.3 0.01 54 40openai_solo gpt-4.1 16 4.8 0.01 31 12TAU2_RETAIL n calls Mtok dur succ%claude_code claude-opus-4-5 126 13.6 0.35 69 95claude_code gpt-4.1 30 7.4 0.01 144 93claude_code Az/gpt-4.1 14 7.4 0.01 204 93smolagents_code gpt-4.1 104 6.3 0.01 97 90tool_calling gpt-4.1 127 7.4 0.01 92 90claude_code gemini-3-pro 34 12.4 0.27 112 82openai_solo gpt-4.1 34 5.9 0.01 76 65TAU2_TELECOM n calls Mtok dur succ%claude_code claude-opus-4-5 39 16.8 0.48 116 82smolagents_code gpt-4.1 68 20.3 0.07 170 51tool_calling gpt-4.1 24 17.0 0.07 151 46claude_code gemini-3-pro 10 9.0 0.21 145 33claude_code gpt-4.1 22 24.7 0.09 224 18openai_solo gpt-4.1 17 3.1 0.01 18 6

tcw_short = tool_calling_with_shortlisting。Az/ = Azure 托管变体。o/ = 通过兼容 OpenAI 的 Azure 端点访问的开放权重模型。

有几个单元格值得指出。Kimi x smolagents_code x AppWorld 是突出的开放权重结果，成功率为 92%，消耗 0.53M tokens。gpt-5.2 x claude_code x SWE-bench 是总体成本/结果赢家，成功率为 93%，消耗 0.52M tokens，并且是表格中最快的挂钟时间。Claude x claude_code x AppWorld 是最差的，成功率为 26%，消耗 4.19M tokens。

具体发现

发现 1：Harness 的重要性大约是模型的 7 倍

当我们固定模型和 benchmark，仅更换 harness 时，我们看到成功率可能波动高达 81 个百分点：

• Claude 在 SWE-bench 上：100%（claude_code）对比 14%（tool_calling）
• Kimi 在 AppWorld 上：92%（smolagents_code）对比 12%（tool_calling）
• gpt-4.1 在 telecom 上：51%（smolagents_code）对比 18%（claude_code）

为了确认这不是覆盖范围的噪声，我们对所有 1,780 行（1,781 个 session 减去一个没有评判分数的）进行了回归分析。一个线性概率回归预测每次运行的成功概率（0 或 1），在保持模型和 benchmark 不变的情况下，隔离一个变量（这里是 harness）的影响。我们使用了 HC1 标准误差，这是一种修正，考虑了方差在不同配置间不均匀的事实，因此置信区间保持可靠。在控制模型和 benchmark 后，我们发现：

• Harness 解释了约 5.3% 的成功率变化。这意味着在控制模型和 benchmark 后，harness 仍然解释了结果中剩余差异的 5.3%。
• 模型仅解释了约 0.7%。一旦你考虑了使用的 harness 和 benchmark，更换模型几乎不会改变成功率。更换 harness 的解释力是其 7 倍。
• claude_code 比 tool_calling 高出 +28 个百分点，tool_calling 是基线，因为它是数据集中最常见的 harness，因此用作比较的参考点。

而且 harness 的选择几乎不改变 token 成本。在同一个 benchmark 内，仅 harness 不同的配置每次运行花费相似。因此，它是你控制的最具杠杆作用、最便宜的旋钮。

左面板显示了每个 harness 相对于 tool_calling 的成功率效应，模型和 benchmark 固定。右面板显示了每个因素解释了多少成功率变化。

claude_code 和 smolagents_code harness 都提高了性能。claude_code 使用 Claude 的原生 agent 风格交互，而 smolagents_code 让模型编写和执行代码来调用工具。tool_calling_with_shortlisting 削弱了性能，表明缩小可用工具集可能会移除有用的选项或引入路由错误。

每个面板固定一个模型；每个条形图是该 harness 在该模型运行的套件上的成功率。共享套件名称列在每个面板标题下方。

发现 2：开放权重模型在编码任务上已可投入生产

在 SWE-bench 上使用 claude_code harness：

模型	成功率
claude-opus-4-5	100%
DeepSeek-V3.2	96%
Kimi-K2.5	94%
gpt-5.2	93%
gemini-3-pro	87%

上面我们看到，开放权重模型在编码任务的前沿上与闭源模型持平或超越。开放权重模型的最大好处是你可以自行托管它们（这使其便宜得多）。

发现 3：高平均值并不意味着可靠

一个配置可能平均得分不错，但在特定任务类型上完全崩溃。将每个配置的 benchmark 平衡成功率与其跨任务离散度绘制在一起，将领域分为两组：可靠配置（高成功率，跨套件一致）和高方差配置（高平均值，但至少有一个套件严重失败）。

右下角是可靠的（高且一致）；越往上越不稳定。开放权重的 claude_code 配置（DeepSeek、Kimi）与 Claude Opus 一起位于可靠角落；gpt-4.1 配置在离散度轴上分散在高位。

一个注意事项：开放权重配置仅在两个套件（AppWorld 和 SWE-bench）上测试过，因此它们的宏观率不能直接与全六套件配置比较。话虽如此，smolagents_code 与 DeepSeek-V3.2 和 Kimi-K2.5 在这些编码任务上都非常可靠且成功。在全六套件配置中，claude_code · claude-opus-4-5（73%）略优于 claude_code · gemini-3-pro（71%），但稍微更不稳定（跨任务标准差 0.27 对比 0.24）。

发现 4：没有通用的赢家

不同的模型在不同的任务上获胜：

• SWE-bench（编码）： Claude、DeepSeek、Kimi
• AppWorld（多应用编排）： DeepSeek、Kimi
• BrowseComp+（研究/综合）： Claude（69% 成功率）
• TAU2 Airline： Gemini（100% 成功率）
• TAU2 Retail： Claude（95% 成功率）
• TAU2 Telecom： Claude（82% 成功率）

需要注意的一点是，DeepSeek 和 Kimi 在 AppWorld 上表现更好的原因可能是由于 harness。闭源模型几乎完全在 tool_calling 下运行 AppWorld，这是对它最差的 harness（在 AppWorld 上成功率最低的 harness）。然而，在相同 harness 下，开放权重在 AppWorld 上仍然特别优于 Claude。Claude 在 AppWorld 上很弱，即使在自己的 harness 中也只有 26% 的成功率。

最大的收获是，没有“最好的模型”。只有“最适合这个工作的模型”。

发现 5：每任务成本和每成功成本是完全不同的数字

有两种衡量成本的方法，它们讲述的故事完全不同。

每任务成本是每次尝试的平均花费——包括失败的运行。每成功成本是你实际为完成一个任务支付的费用，考虑到失败的尝试也花费了金钱。每成功成本 = 每任务成本 ÷ 成功率。一个成功率为 1/6 的配置，每次成功大约支付 6 次尝试的费用。

我们使用 LiteLLM 的每 token 费率 对每次运行进行定价，并根据每个模型测量的输出份额进行混合（agent 是输入受限的；输出仅占计费 token 的约 1–11%）。因此，这些美元数字是真实的，而不是估计值。

首先，质量与成本前沿：每个配置根据 benchmark 平衡成功率与平均每任务成本放置：

左上角占主导地位。开放权重的 claude_code 配置（DeepSeek、Kimi）位于前沿，并将闭源配置推离。Token 成本部分由 benchmark 驱动，因此运行 token 密集型编码套件的配置位于右侧更远，部分原因是它们运行的内容。

现在是每成功任务成本，其中“便宜”不再便宜：

tool_calling x claude-opus-4-5 每次成功花费 $64.82（16% 成功率）。openai_solo x gemini-3-pro 花费 $25.27。相比之下，开放权重的 claude_code 配置每次成功花费 $0.86（Kimi）到 $1.45（DeepSeek），成功率为 82–88%，优于闭源的 claude_code x claude-opus 的 $6.19。

对于“哪个模型最便宜”这个问题的答案完全取决于你问的是每任务成本还是每成功成本。它们对配置的排名顺序完全不同。

每个 benchmark 的每成功成本是同类比较。它按任务族清晰划分：

在编码和 agent 套件上，开放权重获胜。在 SWE-bench 上，claude_code · Kimi-K2.5 每次成功花费 $0.73（94%），· DeepSeek-V3.2 $1.27（96%），而闭源的 · claude-opus 为 $4.28（100%），· gemini-3-pro 为 $4.97（87%）。在 AppWorld 上差距更大：smolagents_code · Kimi-K2.5 每次成功花费 $0.40（92%），而 claude_code · claude-opus 为 $84.33（26%）。

在对话式 TAU2 套件上，情况反转。开放权重模型从未运行过这些，便宜的闭源模型获胜：在 TAU2 Retail 上，gpt-4.1 配置达到 $0.02–0.03/成功，成功率 90%+，而 claude_code · claude-opus 为 $1.95（95%）。

实际收获：选择最便宜的配置，只要它满足你的质量标准，但该配置因任务族而异。编码任务用开放权重，对话支持用 gpt-4.1。

发现 6：“高效”可能意味着“放弃了”

gpt-4.1 在 token 上看起来比其他模型便宜 10–100 倍。但当我们深入研究 traces 时，我们发现，在困难任务上，它便宜是因为它早早失败，而不是因为它更聪明。它在 SWE-bench 和 AppWorld 上失败率为 53–90%，同时几乎不花费任何成本。

没有成功的成本毫无意义。相关的指标是每成功结果的成本，这完全重新排序了排名。在 SWE-bench 上，Claude 和 DeepSeek 都达到了约 100/96% 的成功率，但 Claude 以 0.82M tokens 和 213 秒完成，而 DeepSeek 为了相同的结果消耗了 2.07M tokens 和 1,220 秒（20 分钟）。

发现 7：编码任务与对话任务的失败模式相反

在困难的编码和 agent 任务（SWE-bench、AppWorld、BrowseComp）上，失败意味着无效挣扎。失败的运行比成功的运行进行更多调用、消耗更多 token、运行时间更长。BrowseComp 失败使用的 token 是成功的 2.3 倍。

在对话式 TAU2 任务上，失败意味着放弃。失败的运行进行更少调用、消耗更少 token、完成得更快。

合并视图首先显示了无效挣扎模式。claude_code 的失败有巨大的离散度：中位数失败运行消耗约 0.8M tokens，尾部延伸超过 3.7M。smolagents_code 的失败保持精简。

每次失败运行的 token 使用量：claude_code 的失败因无效挣扎而有巨大的上尾，而其他则保持精简。这是跨套件合并的，因此 claude_code 的尾部部分反映了它运行了 token 密集的编码和浏览套件。

但 token 使用量主要由 benchmark 主导：一个 SWE-bench 运行远超 TAU2 运行，因此合并视图部分地按 harness 运行的套件对它们进行排名。下面的每个 benchmark 视图隔离了每个 harness 自身的消耗模式，无效挣扎/放弃的划分仍然成立。

每个面板固定一个 benchmark；token 尺度不同，因为编码和对话任务有根本不同的 token 需求。编码套件（M 尺度）和对话套件（k 尺度）显示出相反的模式：在一个中失败意味着无效挣扎，在另一个中意味着放弃。

失败的类型也不同。TAU2 的失败几乎完全是无声的错误答案，agent 自信地完成了错误的事情。编码失败倾向于不收敛、循环和运行时错误。

这里有一个非常有用的运维含义。一个“异常 token 使用量”的防护栏需要根据任务类型设置相反的阈值。在编码任务上限制无效挣扎者。在对话任务上标记可疑的便宜或短运行。具有讽刺意味的是，一个单一的“将 token 上限设为 2M”规则会帮助一个类别而破坏另一个。

注意事项

在阅读这些结果时，需要记住几点：

成功率分数是估计值，不是 ground truth。 评判者在 SWE-bench 上最强，因为它可以看到实际的代码 diff 和测试结果。AppWorld 和 TAU2 是中等可靠性，因为评判者可以看到 agent 的工具调用和自我报告的确认，但无法验证实际的数据库状态或隐藏的评分标准。BrowseComp+ 是最弱的，因为没有标准答案，所以评判者必须从 agent 推理的质量来推断正确性。

大多数清晰的比较都通过 claude_code 进行。 它是跨模型和 benchmark 使用最广泛的 harness，因此大多数发现隐含地关于模型在 claude_code 内部的具体表现，而不是在所有 harness 上平等。

模型运行了不同的具体任务实例。 在同一个（benchmark × harness）单元格内，不同的模型不一定处理相同的单个任务。因此，如果 Claude 在 TAU2 Retail 上达到 95%，而 Gemini 达到 82%，部分差距可能仅仅是因为 Claude 碰巧得到了更简单的任务。不应过度解读小的差异。

几个单元格只有 10–15 次运行。 我们设置了每个单元格至少 10 次运行才能纳入分析，但 10–15 次运行仍然是小样本。这些单元格中的结果指向一个方向，但不应被视为确定性的。

Claude 在 SWE-bench 上的 100% 完美得可疑。 Claude 编写了非常详细的自我验证，意味着它解释了它采取的每一步，并明确确认了自己的解决方案。评判者可能将这种彻底性解读为成功的证据，即使底层修复不完整。我们建议将 100% 的成功率视为上限，而不是硬事实。

SWE-bench 分数可能部分反映了记忆。 SWE-bench 任务基于真实的 GitHub issue，它们的解决方案是公开可用的。在公开 GitHub 数据上训练的模型可能在训练期间见过这些答案。运行 SWE-bench 的两个模型在其上的得分都远高于 BrowseComp+（后者使用不太可能出现在训练数据中的精选语料库）。

SWE-bench 和 BrowseComp+ 分数之间的巨大差距表明 SWE-bench 结果可能因训练数据泄露而被夸大。将 SWE-bench 数字视为上限。

Braintrust 实现了什么

原始的 Hugging Face 数据集让你可以看到每个 trace 中发生了什么。Braintrust 使其在大规模下可查询、可评分和可审计。

具体来说：

• 跨 50k spans 的可查询性。 我们想按（benchmark × harness × 模型）分组并发现模式。这是跨 50k 子 spans 的 3D 切片。使用 Braintrust 元数据字段，这是一个单一的 SQL 查询：SELECT benchmark, harness, model, COUNT(*), AVG(tokens), AVG(scores.task_success) ... GROUP BY 1,2,3。

• 安全的分数写回。 将 scores.task_success 添加到 1,780 个现有行而不损坏它们需要确定性 span ID + 使用完整行的 bt sync push。

• 无需手动标记的 Topics。 失败分类法、benchmark 聚类、意图分组都自动从 Topics 中得出。这是一个先发优势，手动构建需要数天时间。

• 对结构化元数据的回归分析。 Harness 与模型的发现需要对所有 1,780 行进行 success ~ C(benchmark) + C(model) + C(harness) 回归。只有当每个 span 都有可查询的元数据字段时，这种回归才可能实现。原始 traces 没有内置这种结构。

而且工作不止于分析。因为每次运行现在都是 Braintrust 中的结构化数据，这个数据集为另外两件事做好了准备：

• 这可以很好地扩展到 50k spans 以上。 这个数据集很小，但生产环境中的 agent traces 不是。Braintrust 运行在 Brainstore 上，这是一个为 AI 日志构建的存储引擎，可以在数 TB 数据上以不到一秒的时间返回中位数查询，大约比通用存储快 80 倍，全文搜索约 240ms。我们在这里运行的 GROUP BY benchmark, harness, model 切片对数百万 spans 也以相同方式工作。

• 将失败集群转化为有针对性的实验。 Topics 已经将失败分组为命名类别，如 False success confirmation 和 Incomplete multi-step execution。你可以过滤到一个集群，将这些行保存为数据集，并针对你选择的配置运行实验，以检查 prompt 或 harness 更改是否实际修复了该特定失败模式，而不是希望聚合分数因正确原因而移动。