正在加载，请稍候
同一批任务、同一个模型、同一个 API 端点，只换编程工具，每成功任务成本能从 0.028 美元到 0.195 美元。差异主要来自框架的启动税与轮数，而不是模型本身。
同一批任务、同一个模型、同一个 API 端点，只把编程工具换掉，账单能差一个量级。2026 年 9 月 InfoQ 转述的三项基准把这件事量化了：每解决一个任务，Aider 的 architect 模式约 3,500 个词元，OpenClaw 约 29.2 万个。花在模型上的钱，很大一部分其实花在引导模型的软件上。
2026 年 6 月的独立基准测的是用量而非美元，覆盖面最广。它用 12 种配置跑相同的 12 个 Python 任务，全部经同一个 OpenRouter 接口、同一个模型，先在 DeepSeek V4 Flash 上跑，再用英伟达 Nemotron 3 Ultra 复跑一遍（后者在 OpenRouter 上有免费额度，可自行复现）。参测项目包括 Aider、Claude Code、Codex、Goose、Hermes、Kilo、Kimi Code、Nanobot、OpenClaw、Opencode 与 Qwen Code，Aider 的 architect 模式单独算一种配置。由于接口与模型完全相同，两个毫不相关的模型之间排名几乎不变——差异只能来自框架软件。
Composio 在 2026 年 8 月发布的对照测的是美元与成功率。30 个企业工作流覆盖 Airtable、Gmail、Google Calendar、Google Sheets、GitHub、Slack 与 PostHog，单项运行上限 900 秒，判分用的是程序化验证器而非大模型裁判，数据是隔离环境里的固定数据集并预置了干扰项与近乎相同的键。8 种框架共执行 240 次，其中 129 次成功完成工作流。
Artificial Analysis 的编码智能体指数统计上最扎实：综合 DeepSWE、Laude Institute 的 Terminal-Bench v2.1 与 Scale AI 的 SWE-Atlas-QnA 共 326 项任务，每项跑三次取平均，并报告单任务成本、用量与耗时；另有一组固定 Claude Opus 4.7、分别搭配 Claude Code、Cursor CLI 与 Opencode 的对照。口径本身也在动：截至 2026 年 9 月，该平台综合指数已迭代到 v4.3、Terminal-Bench 升级到 v4.0，引用名次时务必标清版本。
差距在 6 月基准里有一个明确的名字——启动税。在任务被处理之前，框架先把自己携带的负担发出去：系统提示词、工具说明、环境设置。原文给出的两个极值是 Aider 的 architect 模式约 700 个词元、OpenClaw 约 2.6 万个，相差近 40 倍。
如果这笔钱只付一次尚可接受，问题在于它被逐轮重复发送：一个每轮至少携带 2.6 万个词元、跑满 15 轮的框架，仅脚手架就消耗约 39 万个输入词元。作者用回归验证了这个乘法关系——固定开销乘以轮数能预测每项已解决任务的用量，在两个模型上的决定系数 R² 均为 0.99。另一个反直觉的细节是：所有参测框架的上下文增长速率相近，每轮只多几百个词元，贵的框架并不在囤积上下文，它只是基础开销更高。所以收紧预算的动作顺序很明确——先削提示词的最低开销与轮数上限，再谈复杂优化。
采购对照更适合看 Composio 的数据，因为它把成功率和钱放在一起。
| 框架 | 每成功任务成本（USD） | 通过率 |
|---|---|---|
| Pi Agent | 0.028 | 66.7% |
| Claude Code | 0.195 | 与 DeepAgents 相同（原文未给具体数值） |
| DeepAgents | 约为 Claude Code 的四分之一 | 与 Claude Code 相同 |
| Opencode | 原文未披露 | 46.7% |
两点值得记住。其一，DeepAgents 与 Claude Code 通过率完全相同，但每成功执行一次的成本只有后者的约四分之一——这说明要比的是「每成功任务成本」，而不是每任务成本或原始用量。其二，同一个模型上 8 种框架的通过率从 46.7% 到 66.7%，相差 20 个百分点。只按用量排序，会把框架排错名次。
两项框架实验都指向第二个机制：缓存。Composio 披露 Claude Code 的输入里只有 1.5% 来自缓存，Codex 约 70%，OMP 约 57%，而新输入的单价大约是缓存输入的五倍。6 月基准在自己的测试环境里看到了同类不对称：在 DeepSeek 的运行中，Codex 为整个测试套件计费的量超过 100 万，其中 77% 是缓存读取、按约正常价格的十分之一计费——按实际账单口径，Codex 每解决一项任务的成本低于 Claude Code，尽管后者传输的原始量只有它的一半。
作者认为 Claude Code 近乎为零的缓存占比来自服务路径而非提示词：在该测试环境中，它是唯一通过 Anthropic 风格 messages 端点与 OpenRouter 通信的框架，网关对这种协议格式的转换似乎压低了命中率。网关行为会变，因此这应被视为某条实际观测到的路径，而不是框架的固有属性。Artificial Analysis 干脆把这项差异写进成本模型：分别计算缓存输入与缓存写入的价格，而不是把所有提示词都按未缓存费率计费。命中率本身的调优方法不属于框架层问题，站内已另有专文展开（见 Claude API 成本优化：命中率、反模式审计与 effort 校准），本篇只把它作为比价时必须单独拆出的一项。
席位账与 90 天回本路径是另一个维度，我们在 桌面端 AI Agent 成本测算：token 单价只是冰山一角 里单独处理过；这一节只讲框架层的比价动作。
因为框架每一轮推理前都要重发自己携带的系统提示词、工具说明与环境设置。这笔固定开销是乘性的：乘以轮数之后，单个任务的差异被放大到数十倍。
不行。同模型下通过率能差 20 个百分点；通过率相同的两个框架，单次成功成本可能相差四倍。比价的分母应该是「通过验证的结果数」。
不能。它是端点协议与网关转换的产物，换一种端点风格，同一批流量本可获得更高命中率。必须在自己的实际链路上量。
只能当机制证据。单次运行、无方差估计、部分框架仅有 24/30 次可评分，这些限制决定了它无法替代你自己的实测数据。