同一个模型换个智能体框架，单个任务贵九倍

采购评审会上，两份报价并排放着，一份折到每个任务两毛二美元，一份两美元。两家用的是同一款模型、同一个版本、同一个推理档位、同一套工具，中间没有模型差价。差价来自包在模型外面那一层：怎么把上下文递进去、什么时候调工具、失败了重放哪一段。这一层在工程里叫智能体框架。

先把来源和口径说清楚，否则这些数字很容易被当成行业结论用。一家叫 Tokenstead 的评测站把同一个模型放进三个框架，跑同一套 28 个任务，任务只有一个通过标准：验证脚本以退出码零结束。Kimi Code 过了 22 个，中位 token 6.1 万，单任务 0.22 美元；Hermes Agent 过了 21 个，6.7 万 token，0.28 美元；Claude Code 过了 20 个，34 万 token，2.00 美元。成功率相差八个点，成本相差九倍。

这几行不能当成一次独立复现来读。排行榜自己写明，数据取自 Composio 的公开测试，它做的是把同一批任务换个口径重新计价，把每行的 token 单价附在行上，让人能自己乘回去。独立性上的短板留在那里，所以下面每一条推断都只用成本那一半，成功率那一半单独标成不可靠。

Composio 原测试的规模大一点：八个框架，25 个任务，同一个 Kimi K3，工具集和推理档位都固定。最高通过率 88%，最低 68%；总成本最低的是 Hermes，20 个任务合计 9.28 美元，折到每个成功任务 0.46 美元。两组数据放在一起看，方向一致：通过率挤在一个窄区间里，成本摊开成一个宽区间。

两个变量的分布不一样

这件事值得当成结构变化看，是因为成功率与成本这两个变量的形状不同。成功率已经挤进 68% 到 88% 这个窄带：今天的前沿模型装进任何一个做得像样的框架，大部分任务都能做对。成本却摊开了一个数量级，同一批任务、同一个模型，从 0.22 美元到 2.00 美元。

买方习惯比模型，因为模型有榜单、有版本号、有发布会。框架什么都没有，它藏在工程里，在采购单上通常写成“实施细节”，一行字带过。而账单恰好由这一行字决定。

这不是说框架比模型重要。模型决定任务能不能做对，框架决定做对一次要付多少钱、要等多久。2025 年之前，前一个问题没有答案，所有注意力都在模型上；2026 年下半年，前一个问题在大多数常规任务上已经有了答案，注意力还没转过来。

九倍是怎么长出来的

机制不神秘，是一个乘法。一个任务要跑多少轮，乘以每轮要把多少历史重新递一遍，得到的就是输入 token 的量。设一个任务跑 20 轮，每轮带 8,000 token 的上下文（系统提示、工具定义、对话历史、上一次读到的文件），输入侧就在 16 万 token 上下，而且越到后面单轮越贵，因为历史只会变长。

把这个算式拉开看更清楚。假设每轮新增 4,000 token 的工具输出，框架不做任何压缩，第 k 轮的输入要带上前面所有轮的内容，20 轮跑完，输入总量约 84 万 token。换一个框架，每六轮把历史摘要压到 6,000 token，总量降到 30 万左右。相差接近三倍，只来自一个压缩策略，模型一个字没变。这两个数字是算式示例，不是实测，用来说明量级从哪来。

框架真正动的是四件小事：工具返回的结果截不截断、历史压不压缩、子任务要不要另起一个干净的上下文、失败重试是重放整段还是从断点接。四件事各自省下的比例都不大，乘在一起就是倍数。

反过来看也成立。框架可以很激进地省 token，但每省一次都拿掉一部分模型需要的信息，成功率就会掉，掉到某个点上，省下来的钱还不够付返工。排行榜里 Claude Code 那一行是另一个方向的偏离：它多花了五倍多的 token，成功率反而低一个点，说明有些框架的上下文策略既不省也不准，只是因为默认配置没人动过。

延迟也由同一个乘法决定

同一份成绩单里还有时间：同一个模型，单任务中位耗时 179 秒、297 秒、348 秒。这三个数跟 token 数量不是同一条曲线，因为差的那一段不全在推理上，也在工具调用之间怎么等、能不能并发、失败了要不要从头再来。排队论里等待时间随利用率放大，模型调用也一样：串行的轮数越多，尾部的等待越难预测。所以评估框架时把成本和时间一起看，只报成本的框架通常把延迟藏在了并发里。

我们账本上的分布印证同一件事

过去五个月，我们自己的智能体系统发出 189,417 次模型调用，消耗 134 亿输入 token，模型真正写出来的内容占 5.01%。钱的绝大部分花在“把上下文重新递过去”这个动作上，不花在生成上。这个比例不是模型选的，是运行时选的。同一份账单我们之前拆过一次，结论是缓存与上下文布局比模型单价更能决定支出。今天这份跨框架的排行榜补上了另一半：同样的布局差异，在不同框架之间会放大成倍数。

这条内部证据的价值在于它说明差异是结构性的，不是某一家厂商的配置意外。只要上下文的组织方式不同，账单就会不同，跟模型供应商是谁无关。

便宜模型救不了这件事

一个常见的推论是，等模型单价再降一半，这个问题自然消失。方向反了。单价下降会释放出更贵的用法：更长的上下文、更多的轮数、更少的截断，因为每一步看起来都还便宜。任务复杂度和用量一起上升，账单跟着上升。Gartner 在八月给出的判断是，每个智能体工作流的推理成本到 2028 年要涨五倍以上，原因写得很直白：单元经济学在变好，总成本反而在上升。

它没有说透的是这个倍数在不同框架之间的分布。轮数与上下文量都由框架管，所以单价下降的红利不会平均落到每一套系统上。用量保守的框架会把红利留住，用量激进的框架会把它花掉，然后向财务解释为什么单价比去年低了三成，账单却涨了。

小样本里，倍数可靠，比例不可靠

这份证据的边界必须说清楚，否则容易拿它当行业结论。任务集 25 到 28 个，单个模型，单个供应商，编辑整理而非同行评审。在 28 个任务上，八个百分点就是两个多任务，换一次采样就可能抹平，所以“哪个框架更准”这类结论在这份数据上站不住。

九倍不一样。成本是连续量，中位数对个别异常任务不敏感，6.1 万对 34 万的差距不会因为多两个任务就消失。这也是读任何智能体评测的通用规则：样本小的时候看倍数，不要看比例；要看比例，先把任务集扩到三位数，再按任务类型分层。

还有一个容易踩的坑：不同排行榜之间成功率互相矛盾，经常是因为任务集不同，而不是谁测错了。同一个框架在代码任务上强，在浏览器任务上弱，混在一个平均数里就消失了。比较之前先对齐任务集，对不齐就只比成本。

采购上该改的三件事

第一，报价单位换成“每个成功任务”。按席位买、按 token 买，都把一个由框架决定的变量留在了合同外面。谈的时候要三样东西：任务集、验证脚本、每任务 token 中位数。三样缺一样，这个价格就没法跟别家比。

第二，把框架当成可换的工程件。模型受数据驻留和合规约束，往往换不动；框架多数是开源的，或者至少能在自己的环境里跑，换它的代价小得多，收益是数量级的。这一条对自建团队尤其成立：你改不了模型的解码策略，但你能改历史压缩的阈值。

第三，自己跑一遍。任务不用多，二十个真实工单、二十个真实代码改动，配一个能自动判定的通过条件，半天就能得到属于自己的一行数字。排行榜只能告诉你差距存在，不能告诉你差距在你这儿是三倍还是九倍。

一个可以被证伪的预测

如果机制是“轮数乘上下文”，那么任务越长、工具越多，框架之间的差距越大，不会越小。接下来一年应该看到两件事：短任务上各框架的成本趋于一致，长任务上的差距从个位数倍数走向两位数；以及“上下文管理”会变成框架的卖点，不再只是模型参数表上的数字。

这条预测能被推翻。拿一个 40 轮以上的真实任务，在两个框架里各跑十次，如果成本差距落到两倍以内，上面这套机制解释就是错的，得去找别的原因。

我们的判断

我们的判断是，2026 年下半年智能体的成本竞争已经从模型层转到运行时层。模型层的价格战把单价压到不再是采购决策里的主要变量，剩下的变量是每个任务跑多少轮、每轮带多少历史。这两件事由框架决定，而框架是买方自己能改的。

这也解释了一个反复出现的现象：企业换了更便宜的模型，账单没降。它们换的是单价，没有换用量。用量是框架的函数，框架没动，账单就不会动。

组织上还有一个前提要补。框架归谁改，决定了这件事能不能落。放在算法团队手里，它是一堆没人负责的默认配置；放进平台团队的职责表，它才成为一个能被测量、能被调参的组件。今天多数企业把模型配额写进了预算，把框架留在了代码仓库的角落里，而账单恰恰由角落决定。

三个动作本周可以做完。从生产日志里取出过去三十天的调用数和 token 数，算输入占总支出的比例，超过八成说明问题在上下文，不在模型。拿三个真实任务在两个框架里各跑一遍，记录轮数和每轮输入 token，得到自己的一行数字。下一次采购把计价单位从席位改成成功任务，把验证口径写进合同附件。

留给买家的问题是：你的 AI 账单里，花在生成上的钱占几个百分点？这个数说不出来，下一次降本你就无法判断该改模型还是改框架，于是只能再谈一次单价，再等一个季度看账单有没有动。

参考来源

Tokenstead, agent harness benchmark（同一模型跨框架的任务成本与成功率，行数据取自 Composio 测试）

Composio, 8 best AI agent harnesses（Kimi K3，8 个框架 × 25 任务，含每成功任务成本）

RuntimeWire, 6x token gap between harnesses（同一任务集，中位 token 6.1 万对 34 万）

Gartner, 智能体工作流推理成本到 2028 年涨五倍以上（单元经济学变好、总成本上升）

OOMeta, 我们的智能体账单：95% 花在重读（五个月 189,417 次调用、134 亿输入 token、输出占 5.01%）