一张关于日常 AI 编程助手使用的完整地图:会话、工具、skill、MCP、子代理——每样东西如何进入上下文窗口,又各自怎么计费。全文的流程梳理与计费核算以 Claude Code 为例,价格为其官方每百万 token(MTok)牌价[1],文中以「旗舰 / 主力 / 轻量」指代其三档模型;企业合同价可能与牌价不同,但各项之间的比例关系一致。文中的花费案例来自一份真实使用记录(详见第 9 节)。
基本循环:API 什么都不记得 上下文窗口里装了什么 四种价格,以及 KV cache 读/写到底是什么 逐项拆解:工具、skill、MCP、子代理、图片 热会话 vs 冷会话(5 分钟规则) 五种常见使用模式及各自的花费 推荐的使用模式:三条降本杠杆 最坏的使用模式 真实案例:半个月的账单拆解 一页降本速查表
1. 基本循环:API 什么都不记得
最重要的一个事实,也是下面所有成本的根源:模型服务器在两次请求之间不保留任何记忆。完整的聊天历史保存在用户电脑上的编程助手里。每一轮,它都把全部历史重新发一遍——系统提示、所有历史消息、所有历史工具结果——再加上新消息。服务器把这些全部读完,然后写出回答。

图 1 —— 请求循环。关键点:蓝色箭头每次都携带完整历史。所以真正的成本驱动是"上下文大小 × 轮数",而不是任何单条消息。
2. 上下文窗口里装了什么
上下文是一个"栈"。顺序很重要,因为缓存作用在前面的部分("前缀")——稳定的东西排在前面,不断增长的历史排在后面。

图 2 —— 上下文栈。蓝色各层是"装了东西"就要在每个会话交的房租;橙色层是日常工作不断堆积的地方。
3. 四种价格,以及 KV cache 读/写到底是什么
KV 缓存是什么
读一遍很长的前缀,对模型来说是很重的计算。所以服务器提供一笔交易:处理完一段前缀之后,可以把处理结果暂存起来(即"KV 缓存")。如果下一个请求以完全相同的字节开头,服务器就跳过重复计算,只收一小笔"复用费"。
- CACHE WRITE(缓存写)
"处理这段前缀,并且存下来。"价格是普通输入价的 1.25 倍。第一次会发生,存的副本过期或作废之后也会再发生。 - CACHE READ(缓存读)
"这一段已经存过了——直接复用。"价格是普通输入价的 0.1 倍。会话之后每一轮为整个历史付的就是这个。 暂存副本在最后一次请求后存活 5 分钟(编程助手用的是默认的 5 分钟生存期)[2]。每个新请求都会重置这个 5 分钟计时。
价格表(每百万 token,牌价)[1]
| 旗舰模型 | ||||
| 主力模型 | ||||
| 轻量模型 |
缓存到底省不省钱?算一笔完整的账
比较"有缓存 vs 无缓存"时,必须把缓存写的 25% 溢价也算进缓存的成本,否则会高估节省。用第 9 节的真实案例(半个月,旗舰模型)算完整账:
| 合计 | $6,000 | $1,440 |
缓存读为什么会变大
它是一个乘法:上下文大小 × 往返次数。一个装着 20 万 token 的会话再跑 50 次往返,就要重读 1,000 万 token = 在旗舰模型上是 $10——哪怕只打了三个短问题。
缓存写为什么会变大
三个原因,日常工作里都很常见。注意:写本身不是浪费(新内容总要处理一次),浪费的是同样的内容被反复重写和写了却从未复用:
- 闲置间隔。
停下超过 5 分钟;暂存副本过期;下一轮要按 1.25 倍输入价把整个前缀重写一遍——这部分是纯重复劳动。 - 新内容。
每个新的工具结果 / 消息都要写入缓存一次(不可避免,也是健康的)。 - 多个独立上下文。
每个并行会话、每个子代理、每个 workflow 工作单元,都有自己的前缀,各写自己的一份缓存。
4. 逐项拆解每种操作
下面所有内容都遵循同一条规则:操作返回的任何东西都会追加进历史,从那一刻起,之后的每次往返都会重读它。所以一个大返回的真实成本 = 它的大小 × 它之后还有多少轮。
4.1 工具调用(Read、Bash/PowerShell、Grep、Edit …)
发生了什么:模型发出一个工具请求(按OUTPUT计费,因为它是模型生成的文本)。本地执行工具。结果文本追加进历史(先按CACHE WRITE计费一次,之后每轮按CACHE READ计费)。
Read | ||
Read | ||
Bash | ||
Grep | ||
Grep |
算例:读一个 10,000 token 的文件,之后在旗舰模型上再跑 30 次往返:
写一次:10k × $12.5/M = $0.125 + 重读 30 次:300k × $1/M = $0.30 → 一次文件读取总计 ≈ $0.43。一个长会话里这样读十个文件 ≈ $4.3。这就是"只读需要的部分"的意义。
4.2 Skill
始终要付的(很小):每个已安装 skill 的名字 + 一行描述,放在每个会话的系统提示里——每个几十 token。20 个 skill ≈ 1–2k token 的固定房租。
被调用时才付的:当用户输入 /skill-name,或模型判断某个 skill 适用时,它的完整 SKILL.md 正文(以及它要求读取的文件)会加载进历史——通常 1k–10k token,每个会话一次,之后和其他内容一样被重读。
作用域规则:"始终要付"的是两类——全局 skill(装在用户主目录下)和工具内置 skill,它们的描述进入每个会话。项目 skill(放在某个项目的目录下)则不是全部读取:只有当会话在该项目目录树内启动时才会加载;会话可以同时看到当前目录与其上层目录里的 skill(同名时最具体的目录优先),但其他无关项目的 skill 完全不会被读取、也不产生任何费用。这就是全局列表要保持精简、场景化 skill 应下放到项目目录的原因。
4.3 MCP server
三层成本,从"永远在付"到"按次付":
- 房租server 使用说明 + 工具名,始终加载。
每个注册的 server 都会把它的使用说明和工具名列表注入该作用域内的每个会话——不管用没用。如果开启了延迟加载(只预载工具名字,完整 schema 按需拉取),这一层会小很多;但挂 10 个 server 的使用说明,依然是每个会话实打实的房租。 - 首次使用时工具 schema。
某个工具第一次要用时,它的完整参数定义被拉进上下文。 - 每次调用调用返回。
这是大头。一次邮件搜索可能返回几十 KB 的 JSON(正文、header、元数据);一次 Slack 历史查询、一个 Jira issue 详情——同理。这些 JSON 落进历史,之后每轮都被重读。
经验法则:MCP 贵不是因为调用了它。贵在(a)从不调用的 server 也在每个会话里交房租;(b)一个肥大的 JSON 返回,会在会话余下的每一轮里持续花钱。
4.4 子代理与 workflow
发生了什么:子代理是一个独立、全新、小巧的上下文。它自己跑自己的往返(自己的缓存写 + 读 + 输出,用它自己的模型),只有最终总结回到主会话的历史里。
好处主会话保持苗条:子代理内部的 30 次文件读取完全不碰主上下文——回来的只有约 1k token 的总结。
注意每个代理为自己的前缀写一份自己的缓存。一个铺开 100 个代理的 workflow 就是 100 次独立的缓存写。每个代理小、用便宜模型时没问题;每个代理都背着大 prompt 跑旗舰模型时就贵了。
最佳用法:探索、批量提取、机械检查 → 交给轻量模型上的子代理(每 token 便宜 10 倍)。困难的推理留在主会话。
4.5 模型选择与 effort
同样形状的会话,在主力模型上便宜 2 倍,在轻量模型上便宜 10 倍——四种价格全部同比例。effort 设置主要改变OUTPUT(思考 + 正文长度)——effort 越高想得越久。输出是单价最贵的 token 类型(旗舰模型上 $50/M),但量通常最小;第 9 节的案例里,输出约占 $1,440 中的 $300。
警告:会话中途切换模型会作废全部缓存(新模型必须把所有内容重写一遍)。要切就在任务之间切,别在一个任务中间切。
5. 热会话 vs 冷会话——5 分钟规则
"热" = 轮次间隔不到 5 分钟,缓存一直活着。"冷" = 停顿更久,缓存过期,下一轮必须把整个前缀重写一遍。同样的工作,账单差别很大。

图 3 —— 5 分钟规则。一次冷恢复的价格是一次热轮次的 12.5 倍(写 $12.5/M vs 读 $1/M)。两个闲置间隔就让同样 5 轮的账单翻了一倍多。注:算例为简化,假设上下文恒为 20 万 token,忽略了每轮的少量新增写入与输出费用——它们在两种情形下相同,不影响对比结论。
6. 五种常见使用模式及各自的花费
| A. 快问快答 | |||
| B. 专注工作会话 | |||
| C. 被打断的会话 | |||
| D. 铺开(子代理 / workflow) | |||
| E. 大杂烩 |
7. 推荐的使用模式:三条降本杠杆

图 4 —— 推荐流程。主会话 = 小而热;子代理用便宜模型吸收大批量读取;/clear 在任务之间给计价器归零。
8. 最坏的使用模式

图 5 —— 最坏模式不是一个大错误,而是六个小"方便"乘在一起。倍数为量级示意,非精确测量。
9. 真实案例:半个月的账单拆解(旗舰模型,16 个自然日)
数据来自一份真实的重度使用记录(各项数字均已取整),日常任务包括代码、文档、数据分析与批量子代理。
| INPUT | ||||
| OUTPUT | ||||
| CACHE WRITE | ||||
| CACHE READ | ||||
| 合计 | $1,440 |
无缓存对照(完整算账,含写溢价):同样的 token 流若完全不用缓存,5.7 亿前缀 token 全按 $10/M 输入价 = $5,700,加输出 $300,合计 = $6,000。有缓存实付 $1,440,净省 $4,560(76%)——细节见第 3 节。
降本应瞄准的位置:缓存写这一行($600)对应的手段是减少闲置后的冷恢复、缩小/降级代理集群。缓存读这一行($520)对应的是更小的前缀(少挂全局 MCP、控制工具返回、/clear)和每个任务更少的轮数。输出($300)大部分是真实工作——不用管它。
10. 一页降本速查表
| 重写整个前缀 | ||
如果这篇帮你看清了 AI 助手的账单,建议收藏备查——下次账单异常时,对着第 10 节速查表逐条排查就行。也欢迎留言聊聊:你踩过最深的"漏钱坑"是哪一个——冷恢复、肥大的 MCP 返回,还是从不 /clear?
附录:参考链接
[1] Anthropic 官方模型定价文档:
https://platform.claude.com/docs/en/pricing
[2] Anthropic prompt caching 官方文档:
https://platform.claude.com/docs/en/build-with-claude/prompt-caching
说明:牌价与缓存倍率(默认 5 分钟生存期下缓存写 = 输入价 × 1.25、缓存读 = 输入价 × 0.1,写入后复用一次即回本:1.25 + 0.1 = 1.35 < 2.0)以上述官方文档为准,企业合同价可能与牌价不同。案例 token 量来自一份为期半个月的真实使用记录,文中数字均已取整。
夜雨聆风