编程Agent为什么越聊越费 token

最近用z-code搭博客、学东西，发现一个问题，同一个会话里聊得越久，token 消耗就越离谱。跑了30轮的博客会话，一次对话就能消耗5小时额度的15%左右，这谁顶得住。

后来朋友推荐我新开对话，我试了一下还真好用，token消耗明显降低了。顺带就去研究了一下 agent 的工作原理，记录一下。

根因是模型”无状态”

LLM 本身没有记忆，体感中的”连续对话”，底层其实是：每发一条消息，就把这个会话的完整历史原样重新发给模型一遍。它记不住上次聊到哪，所谓记忆的实现是每次都把之前所有内容重读一遍再接着说，没有”只发变化部分”这种优化。

看来以前我还是把agent想的太智能了。

第 N 轮的输入 = 前 N-1 轮的全部内容。所以二三十轮会话之后，每次发送的内容会达到一个非常大的数量级。

每次发消息，实际发出去的东西比”我打的那句话”要多得多。系统提示词、工作区说明（AGENTS.md）、挂载的所有工具的 JSON schema。

一个接了浏览器控制、桌面控制的 agent，光十几个工具的参数定义就上万 token。哪怕这一轮一次工具都不用，这笔钱也是照付的。

比如没做 tree-shaking 的 vendor.js，所有 import 的包全量打进 bundle，不用也在里面。

2. 全量对话历史（真正的大头）

之前每一轮的问答，加上每次工具调用的完整输出，比如读过的文件全文、grep结果、网页截图、页面 DOM 快照…这些东西一直留在历史里，后面每一轮对话都原样重发一遍。

一次截图、一次大文件阅读，几千 token 就进去了；之后几十轮里这些token会被重复计费几十次。

举个例子。设常驻底噪 15k token，每轮新增 5k。

第 1 轮输入 20k，第 2 轮 25k，第 3 轮 30k，第 30 轮输入就是 170k。

30 轮累计输入 ≈ 285 万 token，其中绝大部分是同一份历史被重复计费了几十遍。

所以消耗是随轮数平方增长的（O(N²)）。

超长会话”又慢又贵”还有个原因：上下文太长时模型推理本身就变慢，而且 agent 框架会在超过阈值时对旧内容做摘要压缩，触发压缩的那几轮开销也很大。

理解了账单构成，省法就有了。

一条线一个会话。不要让一个会话横跨多个不相关任务。
及时收尾，新开会话。感觉会话已经很长、下一个问题又是新话题，直接开新会话比续着问便宜很多。把会话总结成一篇笔记（我把每条工作线一份交接文档），新会话只带几千 token 的摘要，不带十几万的历史记录。
减少大输出。能精确定位片段就不要全文读文件，能精确描述问题就不要直接说“有bug”。提高自己的prompt质量。截图、DOM 快照这类大输出动作少做。
小活扔给子 agent。子 agent 在独立上下文里烧 token，主对话只收回一小段结论。之前子 agent 里干了约 1.8 万token的工作量，主对话只占 150token。
按需禁用 MCP 工具。工具 schema 是常驻成本，暂时用不到的 server 在客户端里关掉。

agent 的记忆是靠每轮重放全部历史来模拟的，所以token消耗随轮数平方增长。

省token可以通过总结文档，开新会话来实现。

感谢Aloha666给我的建议。