这组文章在解决什么问题
Agent 的上下文不是免费的、静止不动的聊天记录，而是一份运行时资产：系统要在每一轮重新组装它，把它传给模型，处理其中的 token，并尝试复用已有计算。在典型的托管 API 路径中，这些活动还会按 Provider 的用量口径计量或计费；在自托管部署中，它们则体现为计算、显存、吞吐与容量成本。一次对话在产品界面里看起来只是多了一条消息，在运行链路里却可能再次携带此前积累的大部分内容。
这组文章讨论的因此不是“如何把一次请求压到最短”，而是一个任务从开始到交付的整体经济性：哪些内容值得反复保留，哪些结构能够复用，什么时候较高的前期处理成本能换来后续收益，什么时候删掉内容反而破坏复用、增加延迟或损害任务质量。
我们会沿着机制、架构、经济性、运维四层逐步展开。目标不是把所有上下文都变短，而是让每一段上下文都有明确用途，让延迟、成本、质量和可恢复性成为可以解释、测量与选择的工程变量。
一份上下文为什么会产生经济问题
一轮完整请求可以抽象成：
[system][tools][project][history][tool results][new input]
它包含系统规则、工具定义、项目指令、历史消息、工具执行结果和本轮新输入。Claude Code 对上下文窗口的说明也展示了这些运行时组成，而不是把上下文描述成模型自行保留的聊天记忆。到了后续轮次，常见形态不是“重新开始”，而是在一个很大的既有前缀后，只追加一小段新增后缀（new suffix）。内容越积越多，系统就越需要回答：大前缀是否稳定，旧计算能否复用，新追加内容是否真的有价值？
模型接收输入并建立中间状态的阶段叫输入预填（prefill），随后逐个 token 生成输出的阶段叫逐 token 生成（decode）。生成过程内部可以使用键值缓存（KV Cache），保留此前输入与已生成 token 的注意力键值状态，避免重复计算；Hugging Face 的缓存机制说明给出了这一机制层语义。托管 API 还可能提供提示词缓存（Prompt Cache），按 Provider 规则复用跨请求完全匹配的前缀。所谓稳定前缀（stable prefix），就是在可缓存边界内保持不变的前缀 token 序列。两类缓存相关，但不是同一个产品层概念。本系列只建立决策所需的共同语言，不再重讲完整的 Q/K/V 推导。
于是，成本不只来自“这一轮有多少 token”。一个稳定前缀可能很长，却能在后续请求形成缓存命中（cache hit）；一次看似积极的删减，则可能改变前缀并造成缓存未命中（cache miss）。因此“上下文越短一定越便宜”并不成立。真正要比较的是整个任务中的预填、生成、失败重试、质量损失以及恢复工作；Provider 若分别计量/计费，还要把缓存写入与读取纳入账单，自托管系统则应比较实际计算与容量占用。《Don’t Break the Cache》也从长时程 Agent 任务评估缓存策略，但其发现只适用于论文采用的模型、基准与工作负载，不能当成普遍定律。
贯穿全系列的 coding agent
我们只使用一个贯穿案例：让 coding agent“定位失败测试、修改实现、运行完整测试并交付结果”。
第一轮，它接收系统约束、工具说明和项目指令；随后读取测试、实现与配置文件，把读取结果加入历史；运行测试后，命令输出继续累积。若第一次判断错误，它会探索另一条分支；若中途等待用户或外部环境，空闲间隔可能影响缓存；若上下文逼近窗口上限，还要在继续追加、裁剪（prune，即删除部分旧上下文）或压缩（compaction，即用更短的新状态或摘要替换旧历史）之间选择。
这个任务看起来只交付一个补丁，运行时却经历了项目规则、工具定义、文件读取、测试输出、推理分支、空闲间隔与压缩结果的持续累积。用同一个案例观察全程，才能看到局部省下的 token 为什么可能在后面以重读文件、重跑测试、缓存失效或错误修改的形式付出更大代价。
阅读路线
如果你第一次接触这个主题，建议按 00 → 08 顺序阅读。01–02 先建立机制和共同语言；03–04 把问题放回工具与会话架构；05–07 比较缓存失效、上下文管理和预算决策；08 最后把这些判断落到生产运维。若你已经在排查线上成本，可先读 08 建立观测框架，再回到 02、05 寻找结构原因。
九篇文章之间的关系
- 00 Reading Guide 定义问题、案例和阅读地图。
- 01 The Context Bill 拆解一轮请求到底处理、缓存和支付了什么。
- 02 Stable Prefix 解释为什么缓存命中首先取决于请求结构，而不只是模型开关。
- 03 Tool Loadouts 研究工具定义如何扩大上下文，并改变前缀的稳定性。
- 04 Sessions Are Trees 区分产品里的会话、恢复与分支，以及底层是否真的能够复用缓存。
- 05 The Price of a Miss 讨论有效期、路由、模型切换与空闲间隔怎样制造隐藏成本。
- 06 Append, Prune, or Compact 比较继续追加、裁剪和压缩的任务级代价。
- 07 Context Budgeting 把质量、延迟、成本与恢复能力放进同一个决策框架。
- 08 Cache Observability 用用量、时延、请求形状和变更事件解释缓存为什么命中或失效。
这不是九个独立技巧的合集，而是一条生命周期链：先理解机制，再设计架构；架构决定经济性，最终由运维数据验证。后篇会复用前篇的术语和 coding agent 状态，不把同一概念换一套名字重新包装。
适合谁读
本系列面向正在构建 Agent 产品的产品经理和应用工程师。你最好已经调用过模型 API，知道消息、工具调用与 token 的基本概念；不需要负责推理基础设施，也不需要预先掌握注意力公式。
产品经理可以用它判断“功能更多”和“上下文更重”之间的关系，工程师可以用它检查请求布局、工具装载、会话分支和压缩策略。若你只想优化一条孤立提示词，这组文章会比需要的范围更大；若你关心长任务为什么越来越慢、越来越贵或越来越不稳定，它正是为这个问题准备的。
读完之后应该能做什么
读完整组文章，你应该能够：
- 画出一个 Agent 请求的组成，指出可稳定复用的前缀与每轮新增的后缀；
- 区分 KV Cache、Prompt Cache、会话历史和上下文窗口，避免把产品概念混为一谈；
- 判断新增工具、切换模型、恢复分支、长时间空闲或重排消息可能带来的缓存影响；
- 在追加、裁剪与压缩之间比较任务级收益，而不是机械追求单轮 token 最少；
- 为一次长任务建立上下文预算，并用质量、延迟、成本和可恢复性解释取舍；
- 设计最小可用的观测面板，从缓存读写用量、命中率、首 token 延迟和请求变更定位异常。
最终，你应当能回答一个更有用的问题：不是“这一轮还能删多少”，而是“为了可靠完成任务，哪部分上下文值得在什么时候，以什么形态继续存在”。
系列边界
本系列涉及的 Provider 行为，以 2026-07-26 可查的官方资料为事实基线，不把某一家 API、某一个模型或某一种部署渠道的行为外推为普遍规律。例如 OpenAI 与 Anthropic 都以可复用的提示词前缀描述缓存能力，但具体触发条件、缓存控制和用量字段应分别以 OpenAI Prompt Caching 与 Anthropic Prompt Caching 为准。本文刻意不记录易变的价格数字。
LLM101 已有的 Prompt Cache 长文是本系列的知识地基，完整 Q/K/V 机制请直接回到那篇文章，本系列不重复推导。Earendil 的文章帮助我们形成提问方式、案例节奏和编辑结构，但它不是 Provider 行为或量化结论的事实权威。论文实验若在后文出现，也只按其特定模型、工作负载与实验设置解读，不包装成普遍定律。
下一篇：The Context Bill：Agent 每一轮到底在为什么付费
参考资料
- 为什么 Claude Code 和 Codex 这么吃额度：从 KV Cache 到 Prompt Cache
- Prompt Caching In Agents — Earendil
- Prompt Caching — OpenAI API
- Prompt Caching — Claude API
- Don’t Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks
- Explore the context window — Claude Code Docs
- Caching — Hugging Face Transformers