智能体成本实测：工具变动拖累缓存

Agent 的成本，可能集中在少数几轮工具环境变化上。作者检查了一次 20 轮会话的逐轮用量，发现其中 5 轮贡献了 94% 的缓存写入成本，而这些轮次恰好伴随 MCP 工具列表变化。

对经常给 AI 编程助手挂工具和插件的程序员，这个案例值得看：优化开销，不能只盯着提示词长度，还要检查缓存为什么失效。不过，标题里的「94% 成本」比正文证据更宽泛，读的时候需要分清口径。

20 轮会话里，究竟什么占了 94%

作者运行着一小组 Agent，并用一个 Python 脚本读取某次会话记录，按轮查看实际用量。这不是事前估算，但也不等于提供了可核对的货币账单。

这次会话共 20 轮，作者按以下权重折算出约 934k tokens 的「有效成本」：

• 普通输入按 1x 计算。
• 缓存读取按 0.1x 计算。
• 缓存写入按 2x 计算。
• 模型输出按 5x 计算。

这里的 934k 是不同类型 token 加权后的结果，不能直接当成原始 token 总量，更不能直接换算成人民币。原文没有说明具体模型、服务商和计价依据。

最关键的数据是：20 轮中的 5 轮，占轮次的 25%，却贡献了全部缓存写入成本的 94%。

94% 指缓存写入成本，正文没有证明这 5 轮占了整场会话总成本的 94%。

作者还报告，每轮都有约 146k tokens 的底座，来自加载的工具和插件。它提醒我们，用户输入框里的几句话，只是模型所接收内容的一部分。但这些底座 token 当轮属于普通输入、缓存读取还是缓存写入，会影响实际费用，不能一律按完整输入价格理解。

为什么工具列表变化会让成本突然上升

作者发现，昂贵的轮次并不对应更难的任务，而是与工具列表变化对上了：一个 MCP server 断开后重新连接，使缓存前缀失效，随后整段上下文被重新写入缓存。

缓存前缀，可以理解为请求开头那段能够重复使用的内容。命中时走较便宜的读取；失效后，则可能需要重新处理和写入。工具定义如果处在这段内容里，它的变化就可能影响复用。

因此，作者提出两条建议：断开当前不用的工具和插件；让会话期间的工具列表保持稳定。前者减少底座，后者减少重新写入的机会。

这两条建议适合连起来执行：开始任务前选好需要的工具，执行过程中尽量保持稳定。如果边聊边反复开关插件，反而可能触发作者所描述的问题。

原文还有一个计价表述上的矛盾：它说写入成本是读取的 2 倍，但按列出的权重，缓存写入是 2x，缓存读取是 0.1x，两者应相差 20 倍。具体适用哪种定价，原文没说清。

我的判断

我认同作者把优化对象从「提示词有多长」扩展到「缓存有没有持续命中」。对挂了多个 MCP 工具的 AI 编程环境，这比只删几句提示词更值得排查。

但「稳定工具列表胜过缩短提示词」仍是这个案例里的经验判断。作者没有提供关闭工具前后的对照实验，也没有给出压缩提示词与稳定工具列表各自节省多少的比较。

同样，工具断连与成本峰值同时出现，是排查线索；缺少完整请求记录和缓存机制细节，还不足以排除其他影响因素。不同 Agent、模型和服务商，也未必以相同方式组织或缓存工具定义。

可以复用的是测量方法，不能照搬的是 146k、934k 和 94% 这些结果。

作者自己也强调，这只是一个配置下的一次会话。文末推广了包含操作原则、任务模板和统计脚本的付费套件，但正文没有给出脚本源码，读者无法据此核验它如何适配会话格式、计算各项权重。

能拿来做什么

• 给日常 AI 编程会话做一次逐轮统计，分别记录普通输入、缓存读取、缓存写入和输出，再用实际服务的价格计算费用，不要只看 token 总量。
• 开始前端或 Node 开发任务前，检查启用的 MCP 工具和插件，只保留任务需要的部分，并尽量在会话开始前完成调整。
• 遇到成本异常升高，先对照当轮是否发生 MCP 断连、重连或工具列表变化，再判断是否需要缩短提示词。
• 用相近任务比较调整前后的费用与完成质量。省下开销的同时，也要确认工具减少后没有增加返工。