被忽略的隐性税:AI应用里看不见的6%固定损耗

📅 2026/4/26 ✍️ 小文 📖 约 1 分钟

你的账单上不会出现“框架开销”这一项,但它真实存在。本文拆解一次典型Agent请求中,被浪费的token从哪来,并给出把损耗压到5%以内的四个具体手段。

每个做Agent的团队都在优化token成本,但大多数人优化的对象错了。

他们盯着“回复太长”“上下文太大”,却没注意到:一次典型的Agent请求里,有5%~15%的token花在了你看不见的地方。

损耗从哪来

1. 系统提示每轮重发

一个3000 token的系统提示,在10轮对话里被发送10次。如果有缓存,成本会大幅降低;如果没有缓存,这部分是纯重复支出。

更隐蔽的是工具定义。一个挂了25个工具的Agent,工具schema本身可能有6000~10000 token,却在每一轮都要随请求发送。多轮任务里,tool schema的成本常常超过用户的实际输入。

2. 对话历史从不压缩

第15轮请求时,上下文里塞着前14轮的完整内容,包括那些中间失败的工具调用、报错堆栈、被否决的方案。

这些内容对当前的决策毫无价值,但每次都要付钱。

3. 工具的返回结果原样塞回

一个搜索工具返回了8000 token的HTML片段,模型只用到其中两句。剩下的7980 token在后续每一轮都跟着你走。

4. 思考过程也被计费

推理模型的思维链通常按输出计费,而输出单价是输入的数倍。过度使用高思考预算,在简单任务上是一种昂贵的选择。

5. 重试与无效调用

格式错误导致重试,每次重试都会重新发送完整上下文。一个3次重试的请求,实际成本是预期的3倍以上。

6. 影子调用

开发调试期的日志、评测、A/B分流、影子对比,都会真实计费。这些经常不在预算盘子里,月底账单出现“莫名多出来的20%”。

四个手段,把损耗压到5%以内

手段一:工具按需加载

不要把全部25个工具放在每次请求里。做法是两段式选择:

  1. 用极短的清单(工具名+一句话描述,约300 token)让模型先选工具;
  2. 只把选中工具的完整schema放进第二轮请求。

成本对比:25个完整schema(9000 token)× 每轮 → 300 token + 1个schema(500 token)。在工具多、轮次多的场景里,这一项能省50%以上。

手段二:历史分层压缩

不要“全保留”或“全截断”,用三层:

  • 最近3轮:完整保留(含工具调用细节);
  • 中段轮次:只保留用户意图与已确认的事实,工具输出替换为一句摘要;
  • 早期轮次:压缩成一段背景描述。

关键是保留失败记录但要减重——“尝试过用X方案,因为Y失败”这一句要留,报错堆栈不用留。

手段三:工具输出在入口处削减

在把工具结果送回模型之前,拦一道处理:

  • 按任务需要截取字段(只要日期和金额,不要整张订单);
  • HTML转纯文本;
  • 超长列表只给前N条 + “共M条”;
  • 数值做格式化压缩。

这一层可以做成通用的中间件,不需要动prompt。效果通常立竿见影,因为我们实测过:工具输出平均占请求token的40%以上,削减一半不影响任务成功率。

手段四:把“是否失败”做成显式信号

减少重试的最好方式不是加大重试次数,而是降低格式错误率:

  • 用结构化输出(schema约束)而非“请返回JSON”;
  • 校验失败时,把校验错误原文回传,让模型精准修正,而不是重发全流程;
  • 对必须成功的步骤,设置最大重试次数并转入人工/降级,避免无限循环。

怎么度量

给你一条可执行的公式:

损耗率 = (实际计费token - 有效token) / 实际计费token
有效token = 用户输入 + 最终回答 + 必要的推理依据

每周跑一次,按请求维度排序,取top 20的高损耗请求逐个看。绝大多数团队第一次跑,都会发现一个之前完全没注意到的泄漏点——通常是某个工具返回了巨长的原始数据。

优化成本不是把上下文砍短,是把重复与噪声从流程里挤出去。

📤 分享到