那些 Token 都去哪儿了？

做 AI 编程助手这么久，我注意到一个挺有意思的现象：每次让 AI 完成一个很简单的小任务，看着输出的 token 数量，总有种被坑了的感觉。

前阵子看到有人记录了一次真实的 agent 任务：让 AI 关闭一个 GitHub issue。流程大概是：读 issue、改文件、跑测试、提交代码、发 PR。干得挺利索，结果也挺有用。

但是你猜用了多少 token？实际干活的部分，大概 10,300 个。

上下文处理了多少？大约 155 万。

这个数字值得停下来想一想。实际工作量和"基础设施开销"的比例，大概是 1:150。agent 其实并没有在用这 155 万 token 来思考。它只是拖着这些东西跑，就像搬家时卡车里塞满了用不上的家具。

如果你平时就在用 AI 编程 agent——不管是做 startup 开发、做 DevOps 自动化，还是单纯加速代码 review——这个比例悄悄地在吃掉你的预算，拖慢响应速度，还会让模型"断片"（就是上下文太长、噪音太多，模型开始丢失关键信息）。

那这些 token 到底花在哪了？

一个"臃肿"的 Session 是怎么形成的

看了不少 agent 运行的 session 数据之后，规律其实很明显。大部分 token 消耗根本不是模型在推理，而是来自上下文搭建——也就是 agent 运行所必须的那些"基础设施"。

工具目录大爆炸。 这是最狠的一个，而且特别容易悄悄发生。你接的 MCP（Model Context Protocol）服务器越多，塞进上下文窗口的工具定义就越多。有一个 session，接了 9 个 MCP 服务器，总共暴露了大约 260 个工具。其中有两个服务器中途接入，光一个服务器就列了大约 180 个工具名。这事儿每接一次就发生一次，然后就永远留在对话历史里了，赶都赶不走。每个后续轮次都要带着这些"行李"跑。

技能目录的"税"。 跟工具目录不同，工具目录是一次性开销，技能目录是每轮都要交的"税"。几十个技能，每个都带一段描述，每次交互都全部加载。这不会让 token 数猛地飙升，但它就是悄悄把"地板"垫高了。每次 session 都这样，累积起来挺可观。

系统提示词和基础设施开销。 在 agent 真正开始干活之前，很多配置下你可能已经用掉 10 万+ token 了。系统提示词、安全策略、工具 schema、格式要求——每轮都要加载。这些是必要的，但它们不是"工作"本身。

实际任务。 这里才是让人不舒服的部分：issue 原文、文件改动、测试输出、commit message——全部加一块儿可能也就几千个 token。任务本身很小，但它的工作间巨大。

为什么这事儿比你想象的严重

你可能想说："token 很便宜吧？"

是挺便宜——但如果你每天跑 20 个 agent session，每个都被一堆你不知道能控制的因素撑大，这个账就很快了。数学不会骗人。

而且不只是钱的问题。

上下文越大，延迟越高。每轮都要处理更多内容，响应时间自然就慢了。

更关键的是"上下文腐烂"的问题。当 agent 的工作上下文里塞满了它根本不需要的工具定义、技能描述、对话历史，它就开始分不清信号和噪音了。可能会忘掉 session 前面的重要信息，可能误解你的意思，可能基于早就埋进对话深处的过时信息做决定。

对于那些要快速迭代的创业团队来说，这不是小麻烦——这是可靠性问题。

怎么真正看清楚自己花了多少

大多数人的第一反应是猜。"这个 session 比较大，可能因为任务复杂吧。"通常不是。通常都是基础设施在作怪。

有三个真正有用的办法：

1. 看 API 返回的 usage 块。 模型的每次返回都带使用统计：output tokens（模型生成的）、input tokens（你发送的）、cache_read_input_tokens（从对话历史读取的）。这个 cache_read 就是证据。假设它显示 150 万 token，你输出只有 1 万——那你的开销比例一目了然。

2. 运行中检查 session 上下文状态。 大部分现代 agent 框架都有类似 /context 这样的命令，能实时显示上下文窗口里到底装了啥、分类如何。这能帮你抓到那些每轮都要交的"税"——技能目录和 schema——这些东西在最终轮次的 usage 块里跟实际任务混在一起，分不清楚。

3. 新增工具连接前先做审计。 在接一个新的 MCP 服务器或者给 agent 加新能力之前，先问自己：这玩意儿每轮要让我花多少 token？单个工具定义没问题。几十个服务器、上百个工具定义，那就是个悄悄吞噬预算的杀手。

真正能减少开销的办法

好了，现在说有用的。如果你发现自己的 agent session token 用量很大，从哪儿开始砍？

精简工具连接。 审计每个 MCP 服务器，问问它是不是真的在出力。如果一个服务器暴露了 50 个工具，你的 agent 只用了 3 个——这就是个信号。想想是不是真的需要一直开着这么多工具，能不能按任务阶段来分批次加载。

用专注型上下文，别用全局上下文。 别每次 session 都把整个工具目录和技能库塞进去。试试按任务类型配置不同的上下文。帮代码 review 的 agent 和写基础设施代码的 agent，需要的上下文根本不一样。

按 session 监控，别只看月账单。 看汇总数据会掩盖异常值。看每个 session 的 token 数量，规律就出来了——哪些任务会暴增、哪些连接在撑大体积、哪些技能从来不用但每次都加载。

考虑专门为效率设计的产品。 有些 agent 框架本身就更省 token。Vibe Hosting 的 AI 开发环境就是从这个角度出发设计的——给你 agent 工作流的能力，但不会让那些隐藏的开销悄悄吃掉你的利润空间。

总结一下

下次你跑一个 AI 编程 agent，感觉智能度和成本不太对劲——你很可能是对的。Token 并没有花在你以为的地方。大部分都在运载"工作间"——工具、技能、schema、对话脚手架——而不是在做实际的工作。

先测量。usage 块和 context 命令不会说谎。一旦你能看见 token 都去哪儿了，你就能做出有依据的决策：该砍什么。

大多数情况下，你会发现在不牺牲能力的前提下，优化空间其实挺大的。

你的 agent 不需要背着整个工具间跑。它只需要刚好够用的那几样工具。确保你给它的，就是它真正需要的。