减少 Claude Code 的 token 消耗，又不丢它需要的上下文

Claude Code 的 token 都烧在哪

在 agent 循环里，token 成本由上下文主导，而不是答案本身。每一轮，agent 都会把它携带的上下文重新发一遍——如果这上下文塞满了早前 grep 并读进来的整文件，你就在为同样的 token 反复付费。大型代码库上，账单涨得飞快。

• 整文件读取：为了用其中几行，把几百行都拉进来
• 每轮重读同一批文件，把相同的 token 再计费一遍
• grep / glob 把大段低信噪比内容倒进窗口
• 上下文爆满逼出 auto-compact，又丢掉有用细节

每次检索一道硬性 token 预算

用 Context Engine，agent 只调一个 MCP 工具 codebase_context，并传入 tokenBudget。服务端跑混合检索（稠密 + 稀疏 + 符号图），重排去重，再拼装一个到预算即停的文件级上下文包。它返回相关片段而非整文件，并跳过 agent 已经看过的文件。

于是上下文窗口只装能回答当前问题的内容，同一段代码不会付费两次，每次调用的上限由你控制。简单扫描调低预算，硬任务调高预算。

为什么省 token 不等于降质量

省 token 的笨办法是给 agent 更少内容——但盲目截断会砍掉不该砍的，agent 就抓瞎，反而在重试里花更多钱。Context Engine 反着来：把预算优先花在信噪比最高的片段上。你不是发更少的上下文，而是发更好的上下文。这才是既压低 token、又保住质量的关键。

这个优先级顺序在预算紧张时最见效。当一次 codebase_context 调用不得不提前收尾，它已经把 token 花在了重排打分最高的片段上，被砍掉的恰恰是最不重要的部分——而不是像盲目截断那样，砍的是恰好排在后面加载的内容。

覆盖你用的每一个 agent

同一个按 token 预算的上下文包，Claude Code、Cursor、Codex、Windsurf 或任意 MCP 客户端都能用——各加一段配置即可。如果你同时跑多个 agent，它们都从同一份新鲜的代码库索引取数。

一个具体例子

假设一次会话是要在删除一个过时的 helper 之前，找出所有调用它的地方。放任不管的话，agent 可能会先 grep 这个名字，命中 40 处，然后把每个文件整个打开检查上下文——尽管这些文件里大多数只有一行用到这个 helper。等它读完这些文件，已经为几千行原本用不上的代码付了费，删除工作还没开始，上下文窗口就已经被挤得差不多了。

Context Engine 把这一切变成一次带着适度 tokenBudget 的 codebase_context 调用。检索找到全部 40 个调用点，重排后只返回每处调用周围的几行，而不是整个文件。agent 精准看到需要检查的内容，token 花费只是原来的一小部分，删除任务开始时上下文窗口依然干净，而不是提前塞满了搜索产生的噪音。

• 40 处 grep 命中变成 40 段简短相关的片段，而不是 40 个整文件
• token 花费只随调用点数量增长，与文件大小无关
• 上下文窗口留给真正的代码改动，而不是搜索残留
• 重命名、重构、依赖排查都适用同样的模式

怎么自己验证效果

最快的验证方式，是把同一个任务跑两遍——一遍让 Claude Code 自己搜索，一遍走 codebase_context——再对比模型服务商报出的这次会话 token 数。目录层级深、有生成代码、或仓库里挂着大型 lockfile 的项目，往往差距最明显，因为这些恰恰是 grep 和整文件读取会无谓拉进来的内容。免费额度足够在自己的仓库上跑几个真实任务，五分钟就能看到差别，不用凭猜测。