你不该为这些 AI 绕路付费

并不是说，如果有机会，前沿 AI 公司就一定不会在向我们出售 token 时暗中操纵局面——毕竟，Anthropic 在 6 月实施了实质上相当于涨价 30%；DeepSeek 在 8 月上调了 API 定价；而 OpenAI 则在 9 月底不情愿地撤回了对其中档 token 额度的下调。因此，趋向紧缩的趋势如今已相当明显。

的确，当你的 AI 智能体在 45 分钟内耗尽每日令牌额度，产出一大堆未必称得上出色的代码，然后叫你 3-4 小时后再回来时，这种想法往往会再次浮现。在这种令人沮丧的时刻，人们难免会想，这些操作中的某些机制是否偏袒了服务提供商。毕竟，这可是让我们掏钱购买特别令牌补充包，甚至开启“自动充值”的好办法。

嗯，如果事实果真如此，那么在当前阶段，领跑的公司完全可以很有说服力地以此为挡箭牌：我们并没有完全弄清楚令牌在不同模型和运行框架的智能体工作负载中是如何使用的。它们也没有弄清楚。除了它们极其顺畅的支付引导流程外，这一切都还处于预 alpha 阶段；尽管这类产品已被广泛商品化，相关问题仍是前沿研究的素材。

浪费管理

AI 智能体在智能体工作流中进行推理时确实会浪费令牌（也因此浪费你的钱），这一事实是早已得到充分证实的：恰好一年前，我曾撰文介绍一项新研究，说明推理型 AI 模型会多么容易因“絮叨”而耗费令牌；今年早些时候，另有研究指出，思维链推理不过是“装饰性的”；而上周，Tsuga 产品负责人 Nils Bunge 在此处的一篇观点文章中宣称：

“一个团队消耗的令牌数量是另一个团队的两倍，并不意味着它创造的价值也一定是两倍。它可能是在处理更困难的工作、使用了性能过强而无必要的模型，或者依赖一个反复重试失败任务的智能体。”

鲜为人知的是，令牌还会以何种方式被浪费在不必要的任务或流程中；今天，一篇新论文又让我重新关注起这个问题。

这项新的美国学术合作研究*题为《AI 智能体如何浪费你的钱？》，提出了一个统一框架，能够量化智能体流程实际浪费了多少令牌。对于闭源模型，研究人员结合提供商的官方统计数据和指标，采用“影子”方法，逐项还原 AI 推理和行动过程中令牌的使用情况：

用于衡量 AI 令牌浪费的新方法。研究人员会记录每个智能体的推理过程、操作和成本，再检查其中是否存在重复内容、不必要的请求和本可避免的绕行。随后，他们会剔除已识别出的浪费，并再次测试智能体能否完成原始任务。 来源

如上所示，研究人员让智能体照常工作，同时拦截并记录它与 AI 服务提供商之间的通信，包括推理过程、工具使用情况、令牌消耗量和成本。随后，由大语言模型（LLM）评审员检查这些记录，将有用的工作与重复内容、不必要的搜索和绕行区分开来。之后，研究人员会剔除疑似浪费的部分，计算节省的令牌数量，再让智能体继续工作，以检验它能否仍然成功完成任务。

测试中，研究人员发现，智能体输出的令牌约有18%遭到浪费。在超过 45% 的任务中，一个智能体浪费的令牌比另一个成功完成同一任务所需的令牌还多。他们还发现，删去 41–46% 的不必要推理，对性能几乎没有影响，这表明在不显著影响结果的情况下，仍有望大幅节省资源。

论文指出：

“在收集到的所有执行轨迹中，约有 18% 的输出令牌被判定为浪费。

“值得注意的是，在超过 45% 的任务中，单个智能体浪费的输出令牌，超过了另一个成功完成同一任务的智能体所使用的全部输出令牌。”

此外，研究发现，智能体在摸索陌生工具以及尝试最终无果的方法时会浪费最多资源；增加推理力度也无法带来稳定的提升：在最高推理力度下，Kimi-K3 产生的推理令牌数量是低力度下的6.6 倍，但这并不能保证结果更好。

Kimi-K3 在五项基准测试中四种推理力度下的测试结果。加大推理力度并未持续提高成功率；有时，最高推理力度的表现甚至不如较低设置。

打个比方，这些智能体会话并不像是开着一辆性能强劲、却从未真正发挥其能力的汽车；它们更像是每次出行都把车加速到其最高速度，即使这样毫无益处，也不顾可能造成的负面影响。

这篇论文还考察了不同运行框架在造成令牌浪费方面的共同作用。研究发现，同一个 AI 模型 Kimi-K3 在相同任务上，根据所用框架的不同，推理量可能相差四倍以上，却未必能取得更好的结果。

研究发现，部分浪费源于基本的软件故障：OpenCode、Kimi Code CLI 和 OpenClaw 会反复在错误的 Python 环境中启动任务，导致错误，并因重试消耗令牌。Kimi Code CLI 还允许 AI 请求其自身软件会拒绝的超时时长，迫使 AI 进行更多代价高昂的尝试。

反直觉的是，提供更多工具的运行框架未必会造成更多浪费；一些反复出现的低效问题似乎源自模型本身，而非其所使用的框架。

‘[Several]一些看似显而易见的框架特性，并不能始终解释观察到的浪费差异。例如，如[below]所示，提供更多工具的框架未必会造成更多浪费。OpenClaw 提供的工具远多于其他框架，但其浪费程度仅属中等。此外，并非所有浪费都会随框架而变化。

‘[Below right]研究表明，在 SWE-bench Verified 测试中，Kimi-K3 会反复走上一条弯路：先写出它认为是项目原始修复方案的内容，随后又放弃这一方案。’

比较不同 AI 智能体运行框架中浪费令牌数量的测试结果。左：提供更多工具并不一定会增加浪费。右：无论使用哪种框架，Kimi-K3 都会反复尝试并放弃一个自认为是原始方案的软件修复方法；但在另一类任务中，这种情况很少发生。

作为补救措施，作者建议智能体运行框架在环境限制导致无法继续推进时，应识别出这一情况，向 AI 模型清楚说明限制，并停止执行，而不是任由反复失败的尝试继续消耗令牌。他们还提议利用对浪费令牌的测量结果，改进模型训练、推理策略和框架设计。

方法

为重建 AI 智能体的活动，研究人员追踪了模型与控制它的软件之间的每次交互，记录其推理过程、响应、工具请求和令牌开销；记录的详细程度因服务提供商而异：Kimi-K3 会公开完整的推理过程；Gemini 3.1 Pro 只提供摘要；Claude 则完全不公开。

每个工具的结果都会反馈给智能体，使研究人员能够追踪整个过程，直至任务完成或达到运行上限。

AI 智能体消耗令牌的四个示例。重复已知信息、进行相同的搜索以及添加毫无意义的道歉，都被计为浪费；而搜索未能成功则不一定意味着浪费，因为智能体可能有充分理由进行尝试。

智能体的请求经由代理转发，以便追踪其活动；为此只需对代码做少量修改。每个请求都会标记其基准测试、运行、任务和试验信息（OpenClaw 除外，因为它不支持此类标记；在这种情况下，每项测试都会使用一个单独的代理，该代理基于 LiteLLM 构建）。

四类行为

这项研究将令牌浪费归纳为四种反复出现的模式：重述（重复已知信息）；重复抓取（重复发出不必要的工具请求）；填充（添加无关文本）；以及绕道（采取看似合理、最终却毫无成效的方法）。

每段录制的会话都由大语言模型评审（LLMaJ**）进行检查。评审模型会获得原始任务、完整记录，以及识别全部四种浪费模式的标准。疑似浪费的内容会被标记并剔除，随后重新统计剩余的词元，以计算浪费比例和成本。之后，统计结果会与各供应商自己的分词器或计数工具以及其报告的输出用量进行核对（报告中只提到少量格式差异）。

测试

研究测试的模型包括 Kimi-K3、Gemini 3.1 Pro、GPT-5.6 Terra、GPT-6 Astra、Claude Sonnet 5 和 Claude Fable 5.1。测试所用基准包括 τ²-bench（航空公司和零售业客户服务）、SWE-bench Verified（软件工程）、Claw-Eval 和 MCP-Atlas（通用工具使用）。

此外，研究还在不同推理等级下测试了 Kimi-K3，并比较了五种智能体运行框架：OpenCode、OpenClaw、OpenHands、Hermes 和 Kimi Code CLI。后几项比较用于评估模型、任务、推理投入和运行框架设计如何影响词元浪费；另有测试会剔除疑似浪费的内容，以检验此举对性能的影响。

为了确定各模型造成的金钱浪费，研究将不必要文本和工具调用的成本与总输出成本进行比较，并对四项基准测试的结果取平均值。研究还单独评估了 Kimi-K3 的内部推理，因为它是唯一一个公开完整推理过程的模型：

测试结果比较了六种 AI 模型的输出成本浪费情况，数据为四项基准测试的平均值。左图：总体浪费率，另行显示 Kimi-K3 的内部推理。右图：任务成功与失败时的浪费率；总体而言，任务失败时产生的浪费更多。

如上所示，用于生成答案和调用工具的费用中，有 11% 至 24.9% 被判定为浪费；GPT-6 Astra 表现最佳，Claude Sonnet 5 表现最差。对 Kimi-K3 而言，答案生成和工具使用过程中约有六分之一的词元被浪费，而在内部推理过程中，这一比例升至四分之一以上。

任务失败时通常会产生更多浪费，不过 Kimi-K3 的推理过程恰恰相反；同时，没有明确证据表明，把更多词元花在不必要的工作上能提高任务成功的可能性。

另一项测试尝试在 AI 仍在工作时减少词元浪费：每一步都会使用 AI 评审模型**，从模型的推理中删除重复信息和无用文本，然后才允许任务继续进行：

测试结果显示，删除不必要的 AI 推理对两项基准测试成功率的影响。删除 41%–46% 的推理内容几乎不影响性能，而删除全部推理内容则会导致失败次数大幅增加。

在 SWE-bench Verified 测试中，研究删去了 41% 的推理内容，性能没有下降，成功率反而略有上升，从 89% 升至 89.5%。在 MCP-Atlas 测试中，研究删去了 46% 的推理内容，成功率仅小幅下降，从 65% 降至 62.3%。

换句话说，AI 工作时，几乎一半的推理内容都可以删去，而不会严重损害它完成任务的能力。

最后^†，研究使用不同的智能体运行框架，让 Kimi-K3 执行相同任务。如下所示，推理输出量的差异超过四倍，但性能并未因此持续改善：

测试结果比较了 Kimi-K3 在两项基准测试中使用不同智能体运行框架时的词元消耗。蓝色表示内部推理，橙色表示回答和工具调用。在编程任务中，使用 Mini-SWE 生成的推理内容是使用 Hermes 时的四倍以上。

部分浪费源于基本的软件故障。OpenCode、Kimi Code CLI 和 OpenClaw 在错误的 Python 环境中启动编程测试，导致出现错误并需要重试。

结论

这只是对一篇论文的浅略介绍；论文篇幅较长，方法严谨细致，值得深入阅读。

这个主题确实让我想到一件我经常意识到的事：我们与前沿供应商对这些流程的实际了解之间存在着巨大鸿沟，而各家公司却乐于把产品包装得仿佛它刚刚在代码检查工具中待了整整三个月，并以优异成绩通过了检查。

就目前而言，至少眼下，一旦出现不良结果，我们只能怪自己，因为我们买下的这种产品，几乎所有人都知道它还处于深度实验阶段，且难以预测。

* 据称，University of Illinois Urbana-Champaign、Northeastern University、University of California (Los Angeles) 和一位独立研究人员的贡献相同。

* 据我所能判断，论文并未说明使用的是哪种模型。

^†这里指的是本文，而不是论文。论文篇幅较长，超出了我通常会介绍的范围，而且包含的测试更多、内容也更深入，无法在此一一涵盖。更多详情请参阅上方链接中的原始 PDF。

首次发表于2026年11月6日，星期五