采购一直在看错那一栏
选 AI 编程工具时，团队通常先比较底层模型的报价。三项在六月与八月分别进行的独立实测指向了另一个结论：决定最终账单的，更多是引导模型完成任务的那层软件——也就是 Agent 框架本身，而不是模型。
信息平台在 9 月 12 日发布的一篇实测综述把三组数据并排放在一起，结论相当集中：同一底层模型、同一批任务，不同框架的 token 消耗最多相差 70 倍。
六月那组：3500 与 292000
六月的一项独立基准把十二种配置放进同一批 Python 任务，横跨两个模型——DeepSeek V4 Flash 与 Nvidia 的 Nemotron 3 Ultra，全部经由同一个网关调用，确保每个框架面对同一套接口与模型。第二个模型提供了免费额度，因此可以不计成本重跑。
结果按「每解出一个任务消耗的 token」计算：表现最省的配置约为 3500 个 token，表现最费的配置为 292000 个，差距约 70 倍。更值得注意的是这个排序的稳定性——在两个互不相关的模型之间，名次几乎没有移动。这直接把矛头指向框架软件，而不是模型行为。
「启动税」与上下文地板
差距来自一个可以单独测量的量：启动税。在提示真正开始干活之前，框架要先送上自己的行李——系统提示、工具描述与环境设置。
同一组基准报告称，最省的配置在这部分约为 700 个 token，最费的配置约为 26000 个，相差约 40 倍。一次性支付 40 倍尚可接受，但重发模式让它变成了累计成本。一个携带 26000 token 地板的框架跑满十五轮，光在脚手架上就要花掉约 390000 个输入 token。
这个算法经得起检验：把启动税乘以轮数，用来预测每解出任务的 token 数，在两个模型上拟合优度都达到 0.99。对想削减 Agent 开支的开发者来说，先看提示地板与轮数，比先动其他变量更有效。
同样值得记下的是：并没有出现「贵的框架在囤上下文」这种现象。所有框架的上下文增速都相近，大约每轮几百个 token。拉开差距的不是增长速度，而是地板高度。
八月那组：成本差倍数，质量差百分点
八月的另一项对比把八种框架放在同一个模型、三十条企业工作流上，跑了约 2400 次运行，其中 129 条工作流成功完成。按「每个成功任务的成本」计算，最低约为 0.028 美元，最高约为 0.195 美元。
质量那一栏的量级完全不同。同一模型下，各框架的通过率从 46.7% 到 66.7%，相差约二十个百分点。另有第三方对 326 项任务做了跟踪，平均每项任务尝试三次，同时报告成本、token 与耗时。
把这两栏放在一起看，可以得到一个更准确的表述：框架选择让成本变动以倍数计，让成功率变动以百分点计。这是量级不同，不是方向不同。
缓存：账单的隐藏开关
第三组数据把注意力引向缓存。有分析显示，某个框架只有约 1.5% 的输入 token 来自缓存，另一个约为 70%，还有一个约为 57%。而全新输入的成本约为缓存输入的 五倍。
解释这一差异时，有一个细节值得单独拎出来：命中率低的那一方，是当时那批里单独走特定风格接口与网关通信的框架。网关对这种协议格式的转换，似乎降低了缓存命中率，而同样流量走另一种风格的端点本可以获得更高命中率。这意味着缓存命中率不只取决于框架，也取决于服务路径与网关行为——把它当成某条实际观测到的路径，而不是普适规律更稳妥。
另有一项小样本对比也值得一提：四种成本跨度很大的框架各跑十项任务，最终都只解出了同一项。省的那个消耗约 80 万个 token，贵的那个消耗约 1500 万个。样本太小，不足以支撑广泛概括，但作为方向提示足够。
把采购指标换一栏
这组数据最实用的含义，是把比较单位从 token 改成「每个已验证结果的成本」。同一模型的原始 token 消耗并不能预测账单，因为地板高度与缓存命中率会把排序彻底打乱。
由此可以推出三条可执行的纪律。其一，先量提示地板与平均轮数，这是最能预测成本的量。其二，把缓存命中率纳入选型，并意识到它同时受框架与网关端点影响。其三，接受「便宜」不等于「划算」——最便宜的框架未必最适合需要多轮检查的陌生代码库，而最贵的框架在描述清楚的小改动上可能只是反复确认一次调用就能确定的事。
还有一个结论值得单独记下：自己拥有框架并不等于解决成本问题。自建 Agent 的团队仍然要为推理付费，成本控制的战场已经从模型合同转移到了平台层。
需要保留的谨慎同样明确：这组结论建立在有限样本上，其中一个关键对比只在一个模型上跑了十项任务；质量结论与成本结论的量级不同，不能互相替代；缓存与网关的观察属于特定路径下的实测，换一个服务路径结论可能变化。相关工具的长期成本曲线与在不同企业代码库上的稳定性，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。