Tīrtha Bench：程序员选AI模型该看的数据

大多数模型排行榜把不同测试集、不同提示词、不同评分器得出的数字并排比较，然后直接排名。这种做法在通用能力上或许能凑合，但一旦要把模型接入编程 Agent、让它调用工具，"哪个模型最聪明"就不是正确的问题了。真正的问题是：哪个模型能做出正确的工具调用、频率多高、速度多快、每得到一个正确答案要花多少钱、以及在哪个托管商上跑。Tīrtha Bench 试图用一个统一的测试回答这串问题。

Tīrtha Bench：68个模型参与测试，保留全部原始结果行

一条规则：同样的测试、同样的评分器

多数排行榜把不同来源的数字放在一起排名，Tīrtha 拒绝了这种做法。它的规则只有一条：一个模型只与跑过完全相同测试、用相同方式评分的模型比较。

核心测试包含 800 个工具调用任务，取自伯克利公开的 BFCL 数据集——400 个单次调用、200 个多工具选择、200 个需要并行调用的任务——外加 120 个作者专门编写的陷阱提示词，用来诱导模型做出错误的工具调用。共享表格上的每个模型都完整跑完了这套测试。

目前共有 68 个模型参与测试，其中 8 个进入了同一套 800 任务 + 120 陷阱的共享对比。最高准确率为 95.4%，由 Grok 4.7 和 Claude Opus 5.5 并列取得。页面上每个标签都来自一条可悬停查看的固定规则，而不是主观判断。作者自家的产品也放在同一张表上，按任务类型拆分测量。

BFCL（Berkeley Function Calling Leaderboard） 是加州大学伯克利分校推出的函数调用评测基准，专门衡量模型能否根据自然语言指令正确生成结构化的工具/函数调用。它覆盖单次调用、多函数选择、并行调用、多轮对话等场景，并提供官方检查器对模型输出做程序化评分。由于工具调用是 Agent 的核心能力，BFCL 已成为该领域被引用最多的公开测试集之一。本文所用的 800 个任务即取自 BFCL，并额外加入作者自编的陷阱提示词，因此读者在对比其他榜单时需注意：BFCL 原始分数与本榜单分数并非同一口径。

共享测试能揭示排行榜看不到的东西

托管商的影响被严重低估

同一个开放模型 gpt-oss-120b，在同样的 800 个任务上，因四家不同提供商而得到 63.9% 到 78.0% 不等的分数。Llama 3.3 70B 的差距更刺眼：在一个托管商上拿到 93.4%，在另一个上只有 69.5%。

这意味着一个常见的采购路径存在风险：从排行榜上选中某个模型，然后找最便宜的托管商购买——你拿到的可能根本不是排行榜上那个模型的表现。对于把模型接入生产环境的团队来说，托管商选择和模型选择几乎是同等重要的决策变量。

托管商（inference provider） 指实际部署并对外提供模型推理服务的云厂商或推理平台，如 Together、Fireworks、Groq 以及各家自建端点。同一个开放权重模型（如 gpt-oss-120b、Llama 3.3 70B）可被多家托管商以不同方式服务，差异来源包括量化精度（FP8、INT4 等）、推理引擎与批处理策略、上下文长度限制、系统提示词注入以及采样默认值。这些工程细节不会体现在模型卡上，却会显著改变工具调用的准确率与延迟。因此“模型选型”与“托管商选型”实际上是两个独立决策，采购时应对目标托管商单独验证。

看每个正确答案的成本，而非标价

便宜但错误率高的模型，每个正确调用的实际成本可能反而更高。Tīrtha 把每次运行的实际花费除以答对的次数，得到"每 1000 次正确调用的美元成本"。结果跨度达到 65 倍：从 0.09 美元到 5.63 美元。在准确率对成本的散点图上，左上角是最优区域，黄色带标示出效率前沿。

单一数字会掩盖版本间的结构变化

DeepSeek^广告 V4.1 Flash 的整体得分与 V4 Flash 打平，差异在噪声范围内。但拆开看，新版本落入陷阱的比例大幅下降（陷阱规避率从 73% 提升到 88%），并行调用处理也更好。如果只看总分，这次升级中最有价值的部分恰好被隐藏了。

审核模型本身也被纳入评测

Agent 架构中越来越常见的一种模式，是用一个小型的是/否模型在工具调用真正执行前进行审批。Tīrtha 对这些"检查器"模型做了同样的评测，包括它们放行了多少次错误调用——这个指标直接关系到安全边界。

检查器模型（guard/approval model） 是 Agent 流水线中的一道前置关卡：在主模型生成工具调用之后、真正执行之前，由一个轻量的是/否分类模型判断该调用是否安全、是否与用户意图一致，不通过则拦截或要求重试。它的价值在于用低成本模型为高风险动作（删除文件、发起支付、执行 shell 命令）提供额外保险。但这也引入新的失效模式：检查器可能放行错误调用（假阴性），也可能误拦合理调用（假阳性），二者需要分别度量。评测检查器时，“放行了多少次本该拦截的错误调用”比总体准确率更能反映安全边界。

每个模型都有独立页面与完整原始数据

点击任意模型即可进入其专属页面：与跑过同一测试的模型相比的排名、一行解读、按任务类型的准确率拆分、各指标上的位置，以及保留的全部原始结果——包括失败的运行，并做了标记。以 Grok 4.5 为例：93.4% 准确率、98.3% 的陷阱通过率、1.85 秒、每个正确答案 0.0015 美元，每项都附有排名。

外部复现：差三个任务

一个无法复现的基准只是声明。Tīrtha 公开了发送的每一个请求，并有人做了复现。Mikhail Maslenik 在自己的机器上、用同一模型的量化副本跑了这 800 个请求，并用伯克利的官方检查器评分，得到 90.6%；Tīrtha 自己的结果是 91.0%，800 个任务中相差三个。

复现也暴露了问题：公共测试集中有两个条目，其预期答案会惩罚合理的回复；此外 Tīrtha 的评分器是自行重写的伯克利版本。作者表示将改用官方检查器重新评分，以便直接对比，两个问题条目也在页面上加了脚注。

基准复现（replication） 指第三方在独立环境中重跑同一测试并比对结果，是判断基准可信度的关键环节。复现的常见变量包括模型版本与量化副本是否一致、采样参数（temperature、top_p）是否相同、评分器实现是否等价，以及请求是否逐条公开。即便全部对齐，LLM 输出的随机性也会带来数个任务的波动，因此“相差三个任务”在 800 任务规模下通常被视为落在噪声范围内。复现的另一价值是暴露测试集本身的缺陷，例如预期答案不合理或评分器与官方实现存在偏差，这类问题往往只有外部独立运行才会被发现。

下一步：从单次调用走向真实工作

单次工具调用是简单的部分。真实的编程工作是长会话，Mikhail 指出的正是模型在长会话中崩溃的地方：一个直接指令——"连接本地服务器并更新它"——某个模型把整个预算花在读取无关文件上，始终没有连接；而一个免费模型在几分钟内完成连接、更新并拉取了日志。

基于这类反馈，下一个赛道 Real Work 将测量四件事：

首次真实动作之前的工作量：在模型完成被要求的事情之前，打开了多少文件、做了多少次调用、消耗多少 token 和秒数，以及它最终是否做到。
上下文填充：同一任务分别从干净上下文、半满的真实会话历史、以及压缩之后开始。
耐力测试（Mikhail 设计）：用 45 分钟构建一个小型同步工具，对端服务器在中途改变数据格式、每十次请求失败一次、并把指令藏在数据里。
能解释分数的日志：每一步、每次重试、每次恢复，放在同一时间轴上，让低分变成可修复的故事。

作者也承认尚未解决真实工作评测中的公平性问题：一次 45 分钟任务的运行只是一个样本，早期运气好的模型看起来会很自律。需要多少个随机种子，排名才有意义？这个问题仍然开放，他们向社区征集答案，也欢迎任何人跑完那 800 个任务后把数字并排放在一起比较。