目录
很多用 Claude Code 或者各类终端 Agent 写代码的开发者，最近都在吐槽同一件事。
明明自己只是让 AI 查了个小函数，或者改了两行样式，几轮对话下来，后台提示额度又快见底了。如果按 API 用量计费，月底账单一拉，常常莫名其妙飙到几百美元。大家的第一反应往往是模型变贵了，或者觉得自己代码写得太频繁。
如果把每次请求的底层数据包拆开看一眼，你会发现一个让人倒吸一口凉气的真相：
你的账户里有将近一半甚至七成以上的 Token 开销，根本不是在帮你分析逻辑或者生成代码。这些真金白银全耗在了 AI 每次开口前，一遍又一遍反反复复朗读给它自己的自我介绍和背景说明书上。
在黑客新闻（Hacker News）社区曾经有一篇讨论度极高的对比评测。有开发者专门抓取了 Claude Code 和 OpenCode 这两款工具在启动阶段的标记消耗：数据对比极其刺眼，在用户还没有敲下任何实际业务需求之前，Claude Code 仅仅是初始化环境，就已经悄无声息地吞掉了将近 33,000 个 Token；而在精简架构的开源工具里，这个初始数字只要 7,000 左右。
这意味着每次你刚打开终端，还没开始干活，底层的计费计数器就已经为你跑完了三万多字的基础开销。
搞清楚这笔糊涂账到底是怎么算出来的，是每一个重度使用 AI 编程的人必须补上的一课。
一、 那几万个 Token 究竟装了什么
很多人以为，自己给模型发一句“帮我看看这个报错”，上传的数据包就真的只有这十几个字。
在普通网页对话框里可能确实接近这个状态，但在真实的终端 Agent 体系里，情况完全不同。为了让大模型表现得像一个熟悉你电脑操作系统的全能程序员，客户端在暗地里为你打包了一个极其庞大的背景环境。
这个背景包主要由三堆沉重的内容拼装而成：
| 注入层级与内容类别 | Token 估算消耗 | 核心构成与具体项 |
|---|---|---|
| 1. 系统人格与全局安全边界 | ~4,000 – 8,000 | 身份声明、安全禁令、交互准则、阶段性汇报契约 |
| 2. 工具全量函数声明 (Tool Definitions) | ~15,000 – 20,000 | Read, Write, Edit, Bash, Grep, Glob 及全部 MCP 工具参数 Schema |
| 3. 工作区与上下文环境快照 | ~5,000 – 10,000 | 项目目录树、Git 状态、全局规则文件、环境变量与环境记忆 |
⬇️ 单次请求开局基线：30,000+ Tokens（尚未输入一行有效代码与提问，起步已消耗 3 万 Token）
- 第一堆是巨幅的系统人格与行为准则：告诉大模型它叫什么名字，必须遵守哪些安全规则，遇到危险命令要怎么拒绝，什么时候该简短回答，什么时候该分步排查。光是这一套行为框架，在底层往往就占去了几千个 Token。
- 第二堆是所有工具的完整函数描述（Tool Use Schemas）：Agent 之所以能查你的目录、读你的文件、跑终端命令，全靠大模型的函数调用机制。模型自己其实不知道电脑里有什么工具，客户端必须在每一次对话的开头，把所有可用工具的名称、参数类型、可选字段、输入限制以及错误说明，完完整整、一字不漏地全部序列化成一段巨大的 JSON Schema，塞进上下文的最前端。
- 第三堆则是你自己的配置文件：你的项目规则文件（
CLAUDE.md/AGENTS.md）、当前目录的结构树、Git 状态摘要，甚至连环境变量和历史记忆，都会被一股脑打包塞进去。
最要命的是，这种“自我介绍”在很多场景下不是发一次就结束了。
只要你中途派生了一个子代理（Subagent）去后台跑测试，或者开了一个分支任务去检索另外几个文件，每个新派生出来的代理进程，都会在它自己的上下文里，把这三万多字的自我介绍从头到尾再复制一遍。
如果有 7 个子任务在并行跑，光是这套背景说明书，就凭空消耗了 20 多万个 Token。
二、 缓存的蜜糖与陷阱：Prompt Caching 为什么频频失效
这时候熟悉技术的朋友可能会反驳：Anthropic 官方不是推出了 Prompt Caching（提示词缓存） 技术吗？相同的背景不是能享受低至一折的读取优惠吗？
缓存机制确实帮大家省了不少钱，但很多人没有算清楚它的隐性门槛与命中条件：
| 计费环节 | 标准单价（以旗舰级 Sonnet 模型为例） | 缓存折扣 | 关键前提 |
|---|---|---|---|
| 首次写入缓存 (Cache Write) | $3.75 / 百万 Token | +25% 溢价 | 需完整处理并序列化前缀 |
| 缓存命中读取 (Cache Read) | $0.30 / 百万 Token | -90% 折扣 | 必须在 5 分钟生命周期内命中 |
| 常规输入 (Uncached Input) | $3.00 / 百万 Token | 基准价 | 缓存未命中或被破坏 |
官方设立了一个约 5 分钟的过期时间窗口（Cache TTL）。这就带来了一个极其隐蔽的成本陷阱：
- 密集写代码时：如果你正在全神贯注地密集交互，每隔一两分钟发一条指令，这套 3 万多字的系统提示确实能稳稳命中缓存，花销看起来微乎其微。
- 思考与调试间歇：程序员的日常工作从来不是连续敲键盘的打字机。你让 AI 写完一段复杂逻辑，往往需要停下来看十分钟代码，或者切到浏览器里测一下真实效果，又或者去喝杯咖啡构思下一个模块。只要你的停顿时间超过了 5 分钟，之前的缓存就会被静默清空。等你再次回到终端输入一个“继续”，系统又必须把那 3 万多字的说明书重新按原价、甚至加上首次写入溢价，彻彻底底重新计算一遍！
更隐蔽的杀手是前缀破坏（Prefix Invalidation）：
Prompt Caching 机制极其挑剔：它要求整个文本序列从第一个字符开始完全一模一样才能命中缓存。
如果你的自动化脚本在系统提示的最前端动态插入了一个随时在跳动的毫秒级时间戳，或者每轮对话因为并发排序改变了工具注册的先后顺序，整条缓存链条就会当场失效，随后的所有请求都会退化成全额计费。
三、 几百小时日志实测：真实开销占比
我对这笔账的敏感，也是在真实开发里被狠狠教训出来的。
前段时间我手上同时跑着好几份订阅，日常用 Claude Code、Codex 配合各种自动化工作流。有几天我在做开源网关 Magpie 的多模型动态路由调优，后台挂着几个长期会话做监控。那几天我明显感觉额度掉得快得出奇。
一开始我以为是某个推理模型太消耗计算量，后来我抓出网关的全部调用日志，把所有的输入与输出做了分词统计：
[Token 消耗真实构成分析]
■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 72% 系统人格 + 工具描述 + 全局规则文件重复传递
■■■■■■■■ 21% 检索历史上下文 + 冗长错误日志堆栈
■■■ 7% 真实业务代码与核心解答
在这几千次交互里，真正用于业务代码逻辑的 Token 占比不到三成。整整七成的开销，全在周而复始地重复发送我写在项目根目录下的全局规则文件，以及那几个没怎么用过的第三方工具说明。
我当时为了图省事，把团队的工程规范、发布禁令、浏览器操作指南甚至样式要求，全写进了一个巨大的引导文件里。结果不管当前任务是改一个字母还是重构一个模块，系统每轮对话都要把这几万字的大全集在各个子代理之间搬运一遍。
更糟糕的是，我当时写的一个状态栏探针，每隔几秒钟会在上下文里更新当前会话的运行时长。这个毫秒级的动态数字正好嵌在最前面，无意中直接破坏了整套缓存的前缀匹配。
我本以为自己搭了一套全自动的极客开发流，实际是在拿真金白银给模型的自我介绍充当背景音乐。
四、 四步给你的 Agent 账单彻底瘦身
如果你也想把这种无谓的隐藏浪费堵住，建议立刻按下面这四步给你的环境做一次全面体检：
1. 规则文件的物理拆分（从单体臃肿到按需加载）
不要在全局根规则（如 CLAUDE.md）里堆砌万字百科全书。把那些低频的操作指南剥离出去，只保留最核心的停止点与安全边界：
- 常驻根规则（< 150 行）：只写架构边界、核心技术栈、文件操作禁忌和核心提交契约；
- 低频流程（按需唤起）：关于浏览器交接、发布打包、技术表达审改的详细说明，全部封装成独立的技能（Skills）或局部 Reference。只有当具体任务确实命中对应场景时，才由工具局部读取那几百字，绝不让普通写代码的会话扛着发布脚本的全部说明书。
2. 严格保护缓存前缀的绝对静态
检查所有会注入到上下文里的内容：
- 绝对禁止将动态时间戳、随机数、易变的环境变量写在系统提示词的最前列；
- 固定前缀结构：将长期不变的内容（系统身份、核心约束、固定工具描述）死死锁定在上下文最前端；
- 将动态变量、当前活跃文件内容、用户最新输入的 Query 安排在队列末尾。只有这样，底层的缓存机制才能稳定命中，享受 90% 的成本折扣。
3. 克制子代理（Subagent）的无序并发
很多开发者看到工具支持派生代理就特别喜欢多开，动不动让系统并发启动五六个后台会话。每一次派生不是简单的函数调用，它是在复制一套完整的上下文生态：
- 对于几行代码的局部验证，或者目标明确的单文件修改，优先在主会话里直接执行，不要动辄呼叫后台并行群；
- 把高开销的独立代理，留给真正需要隔离环境的大型重构或长流程调研。
4. 网关层意图分流（Model Routing）
如果你的业务调用量很大，不要让昂贵的主力旗舰模型去通吞所有的前置环境嗅探：
- 借助开源 AI 网关（如 Magpie）或者本地路由脚本，把任务做意图分层；
- 让响应极快、单价极低的轻量高吞吐模型去处理早期的文件检索、路径确认和环境准备；
- 只有当真正需要深度推理和核心架构推导的那一刻，再把整理干净的精炼上下文递交给旗舰模型。
五、 结语
使用新工具的快乐，往往很容易掩盖掉系统设计上的粗糙与浪费。
大模型确实赋予了单兵作战极其强悍的生产力，但越是强大的能力，越需要精细化的工程边界去驾驭。
真正成熟的技术人，不会只看终端里光标飞速跳跃的快感，更会算清楚每一次系统调用背后真实的代价。看清账单背后的秘密，把每一份算力和费用，都结结实实地花在解决真实业务问题的刀刃上。