一文搞懂Token经济学：同样额度多干3倍活，只需理解消耗机制
王卓约 14 分钟01
Token 是模型处理文本的最小单元。不同模型的 tokenizer 略有差异，以 Claude / GPT 系列为例的粗略换算：
一段 200 行的 Python 脚本大约 2,000~4,000 tokens；一段 1000 字的中文约 1,200~1,800 tokens。
每当你在 AI 编程工具里敲一句话、或 AI 调用一个工具后准备回复，都是一次完整的 API 调用。每次调用发送的内容结构如下：
┌────────────────────────────────────────────────────┐│ ① System Prompt（系统指令） ~8k-20k tokens│ ├ 行为规则、安全约束│ ├ 工具定义（20+ 个工具的 JSON Schema）│ ├ 项目规则 / Memory / CODEBUDDY.md│ └ 项目上下文（目录结构、git status 等）├────────────────────────────────────────────────────┤│ ② 对话历史（所有之前的 turn） 累积增长│ ├ 你说的每句话│ ├ AI 的每次回复│ └ 每次工具调用的入参 + 返回结果├────────────────────────────────────────────────────┤│ ③ 当前输入（本轮新增） ~0.5k-2k│ └ 你刚打的那句话 + 附加的文件/上下文└────────────────────────────────────────────────────┘↓ 发给模型 ↓┌────────────────────────────────────────────────────┐│ ④ 模型输出 ~1k-8k│ ├ 思考过程（部分模型可见）│ ├ 文字回复│ └ 工具调用指令└────────────────────────────────────────────────────┘
关键认知：你打的那句话（③）通常只占总输入的 1%~5%。真正的大头是 ① 和 ②。
02
如果每次 API 调用都要从头全价计算所有输入 Token，成本会是这样：
假设：System Prompt 15k，每轮新增 2k（你的话 + AI 回复 + 工具结果）Turn 1: 15k + 2k = 17k 全价Turn 2: 15k + 4k = 19k 全价 （包含 Turn 1 的历史）Turn 3: 15k + 6k = 21k 全价...Turn 10: 15k + 20k = 35k 全价────────────────────────────10 轮总计输入：~260k tokens（全价） ← 二次增长 O(N²)
每一轮都把之前的所有内容重发一遍，重复付费。这就是为什么早期 API 用户感觉"聊几轮就烧光了"。
大模型用 Transformer 注意力机制处理文本，其中历史 Token 的 Key 和 Value 张量算完就不变了。把它们存起来，下次直接读取，不用重算。这就是 KV Cache。
以 Claude 为例，Token 有三档价格：
| 缓存写入 | ||
| 缓存命中 | ||
| 全价输入 |
具体到各模型的实际价格（每百万 token，美元）：
| $0.50 | ||||
| $0.30 | ||||
| $0.10 |
缓存读取只要基础输入价的 1/10。 对 Opus 来说，缓存命中的输入价格（0.5/M）
甚至比 Haiku 的基础输入价（1/M）还便宜。
注意：Claude Code 订阅产品（Pro/Max）与直接调用 API 的缓存机制有所不同。Claude Code 在产品层面为订阅用户实现了扩展缓存有效期（源码中为 1 小时），这是产品侧的优化，不等同于 API 的付费选项。
Turn 1: [System 15k: 写入×1.25] + [新增 2k: 全价]等价 = 15k×1.25 + 2k = 20.75k ← 首次略贵Turn 2: [System 15k: 命中×0.1] + [T1历史 2k: 命中×0.1] + [新增 2k: 全价]等价 = 15k×0.1 + 2k×0.1 + 2k = 3.7k ← 骤降！Turn 3: 等价 = 15k×0.1 + 4k×0.1 + 2k = 3.9kTurn 5: 等价 = 15k×0.1 + 8k×0.1 + 2k = 4.3kTurn 10: 等价 = 15k×0.1 + 18k×0.1 + 2k = 5.3k────────────────────────────────────────────10 轮总计：~62k 等价 tokens
无缓存 有缓存10 轮总输入 token ~260k 全价 ~260k（但大部分 ×0.1）等价成本 260k ~62k节省 — 76%增长曲线 O(N²) 近似 O(N)
越长的对话，缓存覆盖率越高，每轮边际成本越低。 这就是为什么"一个 Session 持续对话"远比"频繁开新 Session"划算。
缓存只能从头开始匹配。想象你的 Prompt 是一条链：
[System 指令] → [工具定义] → [Rules/Memory] → [msg1] → [msg2] → [msg3]如果链条中间任何一环变了，该环及之后的所有内容全部失效：
最省：只追加新消息[✅ System] [✅ Tools] [✅ Rules] [✅ msg1] [✅ msg2] [新 msg3]→ 只有 msg3 全价中等：修改了 Rules/Memory[✅ System] [✅ Tools] [❌ Rules] [❌ msg1] [❌ msg2] [❌ msg3]→ Rules 之后全部重算最贵：切换模型[❌ System] [❌ Tools] [❌ Rules] [❌ msg1] [❌ msg2] [❌ msg3]→ 不同模型的 KV 张量不互通，从头全价
API 层面（直接调用 Anthropic API）：默认 5 分钟过期，付费选项可延长至 1 小时。
Claude Code 产品层面（源码逻辑，claude.ts:408-413）：
普通用户：5 分钟
Pro/Max 订阅且未超额：延长至 1 小时
刷新机制：每次缓存命中都会重置过期计时。所以只要在过期前发一次匹配前缀的请求，缓存就能无限续命。
实操影响：午饭 1.5 小时回来 → 缓存过期 → 冷启动。可以设置定时脚本每 55 分钟发一句简单的话（如"ok"）来保活。
03
复杂度 ↑ 加载粒度 ↑ 单次成本 ↑││ ┌─────────────────────────────────────────────────────────┐│ │ 第四层：MCP 工具│ │ · 工具定义（JSON Schema）常驻在 System Prompt│ │ · 每次调用的返回结果永久留在对话历史│ │ · 每个工具 Schema ~200-500 tokens│ │ · 适合：需要外部能力（浏览器、数据库、部署等）│ ├─────────────────────────────────────────────────────────┤│ │ 第三层：Skills（完全按需）│ │ · 加载前零开销，仅 description 在可用列表（~50 tokens）│ │ · 加载后 SKILL.md 全文注入对话历史（5k-15k tokens）│ │ · 一旦加载无法卸载│ │ · 适合：复杂工作流（含指令文档 + 参考文档 + 可执行脚本）│ ├─────────────────────────────────────────────────────────┤│ │ 第二层：Rules（常驻 + 按需）│ │ · 常驻规则每轮都在 System Prompt，缓存后 ×0.1│ │ · 触发式规则仅在关键词匹配时注入，不触发时零成本│ │ · 适合：编码规范、格式约束、特定场景的模板│ ├─────────────────────────────────────────────────────────┤│ │ 第一层：Memory（全量常驻）│ │ · 所有条目全量注入 System Prompt，无筛选│ │ · 改动任意一条即打断缓存链│ │ · 适合：简短的用户偏好、项目约定（1-2 句话/条）│ └─────────────────────────────────────────────────────────┘│复杂度 ↓ 加载粒度 ↓ 单次成本 ↓
Memory 的机制是所有记忆条目全量拼接后注入 System Prompt，没有检索、没有筛选。
你有 20 条 Memory 记录：- "缩进统一用 4 空格" → 相关（写代码时）- "函数命名用 snake_case" → 相关（写代码时）- "部署脚本在 scripts/ 目录下" → 不相关（大部分时候）- "文档格式用 Markdown" → 不相关（大部分时候）- ...全部 20 条 → ~800 tokens → 每轮都带 → 但大部分场景只有 2-3 条相关
直接 Token 成本很低（几百 tokens），但有两个隐性影响：
位置效应：Memory 在 System Prompt 中，改动任意一条都会打断缓存链
噪声效应：无关的 Memory 占据模型的注意力权重，可能干扰输出质量
什么时候用 Memory：一句话能说清的偏好或约定，比如"SQL 中不等于用 <>"、"字符串格式化用 .format()"。不要把复杂的规范或工作流放在 Memory 里。
Rules（.mdc 文件）比 Memory 更结构化，支持三种加载模式：
| 常驻（always） | ||
| 触发式（requested/auto） | ||
| 手动（manual） |
实际案例：
code-style-guide.mdc → always → 每轮常驻 ~2k tokens（高频，几乎每个任务都用）api-gen-template.mdc → triggered → 提到"生成 API"时才注入 ~1.5k tokensmigration-check.mdc → triggered → 提到"数据迁移"时才注入 ~1k tokens
什么时候用 Rules：需要几百到几千字描述的编码规范、格式约束、特定场景模板。高频规则设为常驻，低频规则设为触发式。和 Memory 的区别在于：Rules 可以按需加载，Memory 只能全量常驻。
Skills 是最重的配置单元，通常包含：
SKILL.md：技能指令文档（可达 5k-15k tokens）
references/：参考文档
scripts/：可执行脚本
use_skill | ||
关键区别：Skills 不进 System Prompt，而是作为一条消息注入对话历史。所以：
加载前：零开销
加载后：首轮全价，后续缓存
不会影响 System Prompt 的缓存链
但一旦加载就无法卸载，5k-15k tokens 永久留在历史中
什么时候用 Skills：需要完整工作流的复杂任务，比如"数仓开发全流程（建表→改表→取数→审查）"。和 Rules 的区别在于：Skills 承载的是带脚本、带参考文档的完整工作流，而非单条规范。
MCP（Model Context Protocol）工具是外部能力的接入点，比如浏览器控制、数据库查询、部署服务等。
它的成本有两部分：
工具定义（JSON Schema）：每个工具的 Schema 约 200-500 tokens，常驻在 System Prompt 中。10 个闲置工具 = 2k-5k tokens 的固定税
工具调用结果：每次调用的返回结果永久留在对话历史中
单看 ×0.1 不多，但工具调用频繁时会快速累积。一个复杂任务调用 20 次工具，历史里就积累了 40k-100k 的工具结果。
什么时候该关注 MCP 成本：当你发现 Session 后期每轮都变慢、变贵时，大概率是工具调用结果把对话历史撑大了。解决方案见第五章。
把配置项按它们在 Prompt 中的实际排列顺序画出来：
缓存链条（断在哪里，后面全废）：[核心指令 ~4k] → [工具定义 ~6k] → [Rules(always) ~2k] → [Memory ~0.8k] → [项目文档 ~3k]↑ ↑ ↑ ↑ ↑全球共享缓存 Session 内稳定 改 Rule 断这里 改 Memory 断这里 改文档断这里
缓存是前缀匹配——断在越前面，后面废掉的越多。
04
复杂任务中，主 Agent 可能启动独立的子 Agent 来完成特定工作（如 code-explorer 搜索代码、reviewer 审查代码）。
Sub-Agent 几乎不能复用主 Agent 的缓存。 原因：
工具集不同 → 工具 Schema 不同 → 缓存前缀不同
消息历史独立 → 对话内容完全不同
可能用不同模型 → KV 张量不互通
主 Agent (Turn 8, 上下文 40k):[System 15k: 命中×0.1] + [历史 23k: 命中×0.1] + [新增 2k: 全价]等价成本 = 1.5k + 2.3k + 2k = 5.8k ← 大部分缓存Sub-Agent (Turn 1, 全新上下文):[System 10k: 写入×1.25] + [传入 prompt 3k: 全价]等价成本 = 12.5k + 3k = 15.5k ← 冷启动全价！
Sub-Agent 的核心价值不是省 Token，而是防止主上下文被工具结果无限膨胀。
05
前面四章讲的是"钱花在哪"，这一章讲怎么少花。分两个维度：配置侧（Session 开始前做好）和对话侧（Session 进行中注意）。
核心原则：配置类改动会打断缓存链，所以在 Session 开始前一次性配好，工作过程中不要改。
Rules
| 精减常驻 Rules | alwaysApply: true，低频规则用触发式 | |
| 合并同类规则 | ||
| 精炼规则内容 | ||
| 善用触发式关键词 | description 里写精准的触发关键词，避免误触发 |
❌ 所有 5 条规则都 alwaysApply: true→ 系统税 = 5k-15k tokens（其中大部分场景只用到 1 条）✅ 1 条高频规则 alwaysApply: true + 4 条触发式→ 系统税 = 1k-3k tokens（其余按需加载）→ 节省 60-80% 的 Rules 系统税
Skills
| 不要预加载 | ||
| 精简 SKILL.md | references/ 而非写进主文件 | |
| 写好 description |
Memory
| 定期清理 | ||
| 合并同类记忆 | ||
| 写法精炼 |
MCP 工具
| 禁用闲置工具 | ||
| 按项目配置 |
项目文档（CODEBUDDY.md）
| 精炼内容 | ||
| 用引用代替内联 |
量化效果：
优化前（所有 Rules 常驻 + 10 个 MCP + 30 条 Memory + 大 CODEBUDDY.md）：System Prompt ≈ 25k tokens → 后续每轮 = 25k × 0.1 = 2.5k 等价优化后（1 条常驻 Rule + 精简 MCP + 精炼 Memory + 精炼 CODEBUDDY.md）：System Prompt ≈ 12k tokens → 后续每轮 = 12k × 0.1 = 1.2k 等价每轮节省 1.3k 等价，100 轮节省 ~130k 等价 tokens
保护缓存（最重要）
| 一个 Session 干到底 | ||
| 别频繁切模型 | ||
| 超过一小时没说话？缓存已过期 |
减少无效 Token
| 一次说清需求 | ||
| 先描述再贴代码 | ||
| 别反复问"要不要继续" | ||
| 复杂任务写 plan 文件 |
你打的一句话 (50 tokens, <1%)│▼┌──────────────────────────────────────────────────────┐│ 一次 API 调用的总输入││ ┌──────────────────────┐│ │ System Prompt ~12-25k│ ← Turn 2 起缓存命中 ×0.1│ │ (指令+工具+Rules ││ │ +Memory+项目文档) │ 配置侧优化可压到 ~12k│ └──────────────────────┘│ ┌──────────────────────┐│ │ 对话历史 ~5k-100k │ ← 逐轮累积，缓存命中 ×0.1│ │ (消息+工具结果 ││ │ +触发式Rules/Skills) ││ └──────────────────────┘│ ┌──────────────────────┐│ │ 本轮新增 ~2k │ ← 唯一全价部分│ └──────────────────────┘││ 总计: 20k-125k tokens│ 等价成本: 4k-15k (缓存命中后)└──────────────────────────────────────────────────────┘│▼┌──────────────────────────────────────────────────────┐│ 模型输出 ~1k-8k tokens│ (回复 + 工具调用 → 结果回流到下轮历史)└──────────────────────────────────────────────────────┘
记住这三个数字：
System Prompt 是"固定税"：~12-25k tokens，但缓存后只要 ~1.2-2.5k 等价（配置侧优化可压低基数）
对话历史是"累积税"：线性增长，但缓存后只付 1/10
你打的字是"零头"：真正的成本在你看不见的地方
| 恰好相反 | |
一句话总结：AI 编程的 Token 成本不在于你说了多少，而在于两件事——配置侧：精简系统税（Rules 按需加载、禁用无用工具、精炼 Memory）；对话侧：保护缓存（一个 Session 干到底、不中途改配置、不频繁切模型）。两手都抓，同样的额度可以多干 3-5 倍。
感谢你读到这里，不如关注一下？👇