为什么 Claude Code 会在你的提示词之前发送 33k 个 token（以及应对方法）

了解 Claude Code 的 token 用量开销

所有智能体编程工具都会在看到你的提示词之前，预先加载上下文。模型需要知道自己是谁、可以调用哪些工具，以及所处的运行环境。Claude Code 属于这类工具中开销较大的一端。冷启动时，前置内容通常约为 33k 个 token ；而 OpenCode 这样的精简替代工具报告的用量则更接近 7k.

这个差距确实存在，但它并不是质量排名，而是一种设计选择。33k 换来的是更丰富的内置工具和更可靠的智能体行为；7k 换来的是更小的资源占用和更低的冷启动成本。两者都谈不上“正确”——它们只是能力与成本权衡曲线上的不同位置。

下面粗略列出 Claude Code 启动时的 token 预算去向。具体数字会随版本变化，因此应将其视为比例参考，而不是固定常数：

占比最大的部分几乎总是 工具定义。对于原以为系统提示词会占大头的人来说，这往往令人意外。

为什么工具模式定义如此庞大

模型可以调用的每个工具都会以结构化模式定义的形式提供——包括名称、描述，以及参数的完整 JSON Schema。算上嵌套参数的描述和枚举值，一个文档完善的工具就可能占用 500–1,500 个 token。Claude Code 默认启用的工具种类很多（文件读写、编辑、bash、glob、grep、网页抓取、任务/智能体创建、待办事项跟踪等），而且每次请求都会包含所有这些工具。

一个工具的精简模式定义大致如下：

{
  "name": "edit_file",
  "description": "Make a targeted edit to an existing file. Use this instead of rewriting the whole file when possible...",
  "input_schema": {
    "type": "object",
    "properties": {
      "path": { "type": "string", "description": "Absolute path to the file" },
      "old_string": { "type": "string", "description": "Exact text to replace, including surrounding context for uniqueness" },
      "new_string": { "type": "string", "description": "Replacement text" }
    },
    "required": ["path", "old_string", "new_string"]
  }
}

将它乘以十几个工具，再加上你连接的所有 MCP 服务器暴露的工具，模式定义载荷就会迅速膨胀。一个常见陷阱是：有人为了“试试看”安装了三个 MCP 服务器，每个都暴露 8–15 个工具，结果基准用量增加了 10k 个 token，而他们之后再也没有留意过。

你没有要求提供的环境上下文

Claude Code 在仓库内启动时，会注入环境信息，让智能体无需浪费一轮交互来询问基本问题。实际包含的内容通常有：

Working directory: /home/ryan/projects/api-gateway
Platform: linux
Git branch: feature/rate-limiting
Git status: 4 modified, 1 untracked
Recent commits: ...

这确实很有用——智能体因此已经知道你正在功能分支上工作——但它同样会消耗 token，而且在大型单体仓库中，目录快照的规模可能相当可观。

这些开销实际为你带来了什么

在设法消除这些开销之前，要客观看待其中的权衡。正是这 33k，让 Claude Code 能在第一次响应中，就结合正确的周边上下文编辑正确的文件、运行测试、为并行任务创建子智能体，并遵循项目约定——全程无需先进行一轮澄清提问。一个只使用 7k 个 token 的智能体往往必须 逐步获取 这些上下文，依靠额外的交互轮次。这意味着更多请求、更高延迟，有时整个会话的 token 总用量反而更多。

因此，比较的重点不是“33k 浪费，7k 高效”，而是：

• 请求更少、单次更大 （Claude Code）与 请求更多、单次更精简 （精简型智能体）
• 能力立即可用 与 按需逐步构建能力
• 每个会话的固定成本更高 与 每项任务的可变成本更高

对于一个包含五条消息的调试会话，固定开销可以得到很好的分摊。对于发完即走的一句话请求，它则显得浪费。放在各自的情境中，这两种感受都合理。

你实际能控制的因素

你无法重写 Claude Code 的核心工具集，但有三个调整项能显著改变基准用量。

1. 大幅精简 CLAUDE.md

CLAUDE.md 会在每次请求中完整注入。它是前置内容中 100% 由你掌控的部分，也是我看到浪费最多的地方——动辄 4k 个 token 的文件，写满了模型默认就会遵循的理想化风格指南。

让内容精简，并确保每条都有实际作用。优先保留：

# Project: api-gateway

- Package manager: pnpm (never npm)
- Tests: `pnpm test` — must pass before any commit
- Do NOT edit files in /generated
- API errors use the AppError class in src/errors.ts

删除模型本来就会做的事情（“编写整洁的代码”“添加注释”）。一个实用的经验法则是：如果删除某一行不会改变智能体的行为，那它就只是在白白消耗 token。对于深度上下文，将其放在引用文件中，让智能体 按需 读取，而不是粘贴到记忆中。

2. 禁用不用的 MCP 服务器和工具

对大多数人来说，这是效果最显著的做法。检查实际连接了哪些服务器：

claude mcp list

如果发现某些服务器是几个月前添加的，而且从未使用，就移除它们：

claude mcp remove some-unused-server

你也可以限定允许使用的工具，从而避免将相应的模式定义放入上下文。在项目或用户设置中：

{
  "permissions": {
    "allow": ["Read", "Edit", "Bash", "Grep", "Glob"],
    "deny": ["WebFetch"]
  }
}

每排除一个工具，就少了一份需要在每轮交互中付费发送的模式定义。实际使用中，禁用一个提供大量内容的 MCP 服务器，比任何提示词调整都更能帮我节省 token。

3. 充分利用提示词缓存

这是最关键的一项，它会改变整个成本计算方式。系统提示词、工具定义和稳定的项目上下文 在同一会话的每次请求中都保持一致 ——因此非常适合使用提示词缓存。缓存的输入 token 比新输入的 token 便宜得多，所以在第一次调用后，那段 33k 的前置内容基本就不再那么重要了。

Claude Code 会自动使用缓存，但你可以让上下文中稳定的部分真正保持稳定，从而帮助它更好地利用缓存：

• 避免改写 CLAUDE.md ，尤其是在会话进行期间——一旦改动，其后的缓存就会失效。
• 将静态上下文放在前面；把经常变化的细节放在消息中，而不是前置内容中。
• 顺序很重要：缓存基于前缀工作，因此越靠前的内容发生变化，越会使后续所有内容的缓存失效。

实际结论是：为了控制成本，优化你的 首次 请求的 token 数，但要围绕缓存命中来优化整个 会话 。在真实工作会话中，一个稳定且能顺利命中缓存的 33k 前缀，往往比一个每轮都会重建、因而从不命中缓存的 7k 前缀更便宜。

如果你运行的是高调用量的智能体工作负载，并且密切关注每个 token 的成本，那么更低价的 API 访问服务——例如 AI Prime Tech 为 Claude 模型提供的服务——也能在这里与良好的缓存使用习惯叠加，进一步节省成本。

实用要点

• 约 33k 的启动开销主要来自工具模式定义，而非系统提示词。 工具定义和 MCP 服务器占据了预算的大头。
• 这是一种权衡，而不是浪费。 这些开销换来的是立即可用的能力和更少的对话往返；更精简的智能体则将成本从固定成本转移到可变成本。
• 首先检查你的 MCP 服务器。 移除未使用的服务器并禁用未使用的工具，是效果最显著的单项削减措施。
• 确保 CLAUDE.md 中的内容有实际作用。 删除模型默认就会执行的内容；按需引用详细文档，而不是将其粘贴进去。
• 围绕缓存命中进行设计，而不只是缩小首次请求。 稳定且能顺利命中缓存的前置内容，胜过每轮都要重建的极小前置内容。
• 按会话衡量，而不是按消息衡量。 应结合整个任务来评估开销，因为固定成本会在整个任务中得到分摊。