模型一模一样，Token 却相差 70 倍？三项实测揭开 AI 编程工具的成本黑洞

当团队评估 AI 编码智能体的成本时，往往会仔细审视模型。但最近的三项基准测试表明，智能体框架，也就是引导模型完成任务的软件，可能同样重要。 任何 Web 开发者都会熟悉其中的原因：每次推理请求都需要上下文。相关历史记录要么必须再次提供，要么需要由服务系统重新构建。因此，提供商在每一轮中都要处理大量相互重叠的文本，其中包括智能体框架的系统提示词和工具说明。 今年 6 月，一项独立的 基准测试 "使用两个模型，在相同的 12 个 Python 任务上比较了 12 种配置。8 月，Composio 比较了 "八种智能体框架，使用 DeepSeek V4 Flash 完成 30 个企业工作流。与此同时，Artificial Analysis 通过其 编码智能体指数 "持续追踪智能体框架与模型的组合。 三项基准测试测量了什么 Composio "公布了 30 个工作流，涵盖 Airtable、Gmail、Google Calendar、Google Sheets、GitHub、Slack 和 PostHog。每项任务的运行时间上限为 900 秒。结果由程序化验证器而非大语言模型裁判评分，测试使用隔离的固定数据，其中预置了干扰项和近乎相同的键。 Composio 报告了 240 次任务执行结果，其中 129 次成功完成了工作流。每次成功完成任务的成本从 Pi Agent 的 0.028 美元到 Claude Code 的 0.195 美元不等。DeepAgents 的通过率与 Claude Code 完全相同，但每次成功执行的成本仅为后者的四分之一。 这项对照实验并不完美，Composio 也对此进行了透明披露。Pi 通过两个模型提供商运行时使用了不同的推理设置，而 Prime Agent 的 30 次运行中只有 24 次可以评分。这些限制意味着，不能把它称为一次严格控制单一变量的实验。 6 月的基准测试衡量的是 Token，而不是美元，测试范围也更广。作者报告了 Aider、Claude Code、Codex、Goose、Hermes、Kilo、Kimi Code、Nanobot、OpenClaw、Opencode 和 Qwen Code 的运行结果，并将 Aider 的 architect 模式作为一种单独的配置计算。所有 12 种配置都通过 OpenRouter "运行相同的任务，因此每种智能体框架都使用了相同的 API 和模型。 测试套件先在 DeepSeek V4 Flash 上运行，随后又在英伟达的 Nemotron 3 Ultra 上运行。第二个模型在 OpenRouter 上提供免费额度，因此你可以免费重新运行这项测试。 文章报告称，每解决一项任务所消耗的 Token，从使用 architect 模式的 Aider 约 3500 个，到 OpenClaw 的 29.2 万个不等。这个范围之所以具有参考价值，是因为它非常稳定：在两个毫不相关的模型之间，排名几乎没有变化。这说明差异来自智能体框架软件，而不是模型行为。 Artificial Analysis 使用更大的统计样本研究了同一个问题。Artificial Analysis 发布了一项综合指数，涵盖 DeepSWE、Laude Institute 的 Terminal-Bench v2.1，以及 Scale AI 的 SWE-Atlas-QnA。总计包含 326 项任务，每项任务运行三次后取平均通过率。它会报告每种组合的单任务成本、Token 用量和耗时。此外，它还发布了一项对照比较，在固定使用 Claude Opus 4.7 的情况下，分别搭配 Claude Code、Cursor CLI 和 Opencode。 启动税 归根结底，这种差距源自 6 月基准测试中的一项指标：启动税。在提示词开始处理任何任务之前，智能体框架就会先发送自己携带的负担。这些负担包括系统提示词、工具说明和环境设置。基准测试报告称，使用 architect 模式的 Aider 约为 700 个 Token，而 OpenClaw 约为 2.6 万个。 如果这种 40 倍的开销只需支付一次，尚且可以接受，但重复发送的模式改变了这一点。作者指出，一个每轮至少携带 2.6 万个 Token、持续运行 15 轮的智能体框架，仅脚手架就会消耗约 39 万个输入 Token。 这个计算经测试也站得住脚。启动税乘以轮数，能够预测每项已解决任务的 Token 用量，在两个模型上的决定系数 R² 均为 0.99。希望降低智能体支出的开发者，应该先关注提示词的最低开销和轮数，再考虑更复杂的优化。 这张回归图需要附带一项说明。6 月的基准测试中，每种智能体框架、任务和模型组合只运行了一次，因此没有方差估计，而智能体的运行具有随机性。在这方面，Artificial Analysis 的结果更有分量，因为它针对 326 项任务各运行三次并取平均值。可以把 6 月测试发现的开销视为对其作用机制的证据，而在比较当前生产规模的组合时，规模更大的指数是更可靠的衡量工具。 昂贵的智能体框架并不是在囤积上下文，只是承担了更高的基础开销。 令人意外的是，有些因素并不能解释这种差距。所有智能体框架的上下文都以相近的速度增长，每轮增加几百个 Token，因此增长速度并不是造成差异的原因。昂贵的智能体框架并不是在囤积上下文，只是承担了更高的基础开销。 缓存 Token 改写了排行榜 两项智能体框架实验得出了第二个共同机制，而 Artificial Analysis 也在其方法中把它视为一项实质性因素。它也是平台团队最容易判断错误的因素。 Composio 披露，Claude Code 的输入 Token 中只有 1.5% 来自缓存，而 Codex 约为 70%，OMP 约为 57%。新输入的成本大约是缓存输入的五倍。因此，Claude Code 的 Token 消耗量与竞争对手相当，账单却并非如此。 6 月的基准测试在自己的测试环境中发现了类似的不对称现象。在 DeepSeek 的运行中，Codex 为整个测试套件计费的 Token 超过 100 万个。其中 77% 是缓存读取，收费约为正常价格的十分之一。按照实际账单的计价方式计算，Codex 每解决一项任务的成本低于 Claude Code，尽管后者使用的原始 Token 只有它的一半。 作者认为，Claude Code 几乎为零的缓存占比源于服务路径，而不是它的提示词。在该测试环境中，Claude Code 是唯一通过 Anthropic 风格的 messages 端点与 OpenRouter 通信的智能体框架。网关对这种协议格式的转换，似乎降低了缓存命中率，而相同流量通过 OpenAI 风格的端点原本可以获得更高的缓存命中率。网关行为会发生变化，因此应把它视为某条实际观测到的路径。 Artificial Analysis 并不是在测试中发现这一点，而是直接将这一假设纳入了成本模型。它提醒用户，提示词缓存命中率会随着提供商的路由方式产生很大差异。它的成本模型会分别计算缓存输入和缓存写入的价格，而不是把所有提示词 Token 都按未缓存费率计费。一