第 5 章 上下文预算治理：把 token 当成钱来管
上下文是一笔会悄悄变大的账单
前四章我们讲了怎么让单个 Agent 干得更好、怎么让它学会检查、怎么把活分出去。现在进入一个更隐蔽、也更"要命"的话题：上下文（context）管理。
先看一个真实的烦恼。
你给 Agent 配置了一堆"常驻"内容：指令文件、记忆索引、技能说明、hook 配置……每一样单独看都不大，也就几百个 token。但问题是——它们每个 session、每一轮对话，都要跟着送进模型一次。这就是所谓的"幽灵 token"（ghost tokens）：你根本感觉不到它们存在，但每一轮都在为它们付钱。
一个生产工作区发现，这类常驻上下文的基线每周悄悄上涨约 20%。没有单次明显的大变化，但积累下来，质量下降、成本攀升，而且没有任何东西会大声报警——问题就这么温水煮青蛙地恶化下去。
更糟的是无人值守的定时任务：它们半夜跑，没人看着，一个任务的 token 胃口变大，可能连续跑几周都没人发现。
这一章讲三个模式，专门对付"上下文账单失控"：
- Context Budget as a Governed Resource（上下文预算治理）：像管钱一样管上下文——测量、盯趋势、设上限。
- Context Window Anxiety Management（上下文焦虑管理）：对付模型自己的"怕用完"心理。
- Prompt Caching（提示词缓存）：让重复的内容不重复付钱。
模式一：上下文预算治理（Context Budget as a Governed Resource）
问题
如开头所说：常驻上下文在悄悄积累，没有一个地方在"记账"，出了问题也没人报警。
方案
把上下文预算当成像钱一样的受治理资源：测量它、追踪它的趋势、给它设上限。具体四步：
第一步：建一个基线计数器
把每一个常驻来源都量一遍：指令文件、记忆索引、技能描述、hook 命令字符串……每个来源单独记录。粗略估算就够了（比如"字符数除以 4"），重要的是持续记录，留下历史。
基线 = 求和(估算token(来源) for 来源 in 所有常驻来源)
记录(基线, 按来源细分)
if 基线 > 过去4-8周中位数 * (1 + 警戒幅度):
报警(增长最快的来源)第二步：盯趋势，而不只是设上限
绝对上限只能拦住"灾难"，拦不住"悄悄积累"——而悄悄积累才是最常见的失败方式。所以报警条件应该是：基线超过前 4-8 周中位数一定幅度（比如 10%-25%）。按来源细分是让报警"可行动"的关键：总数只告诉你"长了"，细分告诉你"该删谁"。
第三步：给无人值守的跑批设硬上限
每一个定时调用的 Agent 任务，都带上一个花费上限（类似 --max-budget-usd 的开关），大小设为正常一轮的 10-50 倍。这是防跑飞的保险带，不是用来精调的工具。
第四步：从结构上限制"发散"
运行任何多 Agent 工作流之前，先估算 Agent 数量，给每一层设上限。如果一个工作流的 Agent 数量会随着发现的数据（claim、文件、匹配结果）增长，那它就是一个"成本炸弹"——必须在设计上就拦住。
还有两个配套动作：给记忆和索引文件设明确的容量上限（比如多少行、多少 KB，超了就迁移到按主题拆分的文件）；给压缩过程留一条常驻指令，告诉运行时哪些东西必须保留（带理由的决策、进行中的编辑、未解决的问题），哪些可以丢弃，防止压缩时把关键信息悄悄删了。
证据
- 证据等级：
medium（中等）。 - 最有价值的发现：一个生产工作区当场抓住了约 20% 的周环比基线跳升，并当天定位到三个增长来源——这就是"按来源细分"的价值。
- 还有一个教训：一个研究型工作流单次运行 fan-out 超过 100 个 Agent，之后才开始设预算上限和 fan-out 边界。
怎么用
- 只要有任何文件会被自动加载进每个 session，或有任何 Agent 无人值守运行，就该用这个模式。
- 从基线计数器开始（一个下午的活），把趋势报警挂到已有的周期性复查上（每周审计是天然的宿主），最后再给定时任务加预算上限。
- 按来源细分是回报最高的部分：总数告诉你长了，来源告诉你删什么。
取舍
- 好处：成本和质量都可控；问题在变成灾难前就被发现。
- 代价：需要一点持续的维护（记录、审计）；阈值是经验值，要按自己的情况调。
模式二：上下文焦虑管理（Context Window Anxiety Management）
问题
这是个很有意思的现象，来自 Cognition AI（做 Devin 的公司）的观察：模型自己会有"上下文焦虑"。
像 Claude Sonnet 4.5 这类模型，会"意识到"自己接近上下文窗口的极限，然后开始提前收尾——主动总结进度、急着把任务结束掉，哪怕其实还有足够的空间。具体表现：
- 任务提前完成，走捷径。
- 明明还有上下文，却草草收工。
- 严重低估还剩多少 token 容量。
- 自己给自己压力"该收尾了"，而不是继续干活。
方案
用策略性的预算管理和激进的提示词，对抗这种焦虑驱动的行为：
1. 上下文缓冲策略
开一个大上下文窗口（比如 1M token 的 beta），但实际只用到 200k。这相当于给模型一段心理上的"跑道"——它知道自己离天花板还远，就不那么焦虑了。
2. 激进的"反提示"
在对话开头明确告诉模型："你还有很多上下文，不要急着完成任务。"在对话结尾再加一句："慢慢来，上下文不是约束。"直接压过它想总结、想收尾的冲动。
3. Token 预算透明化
明确告诉模型当前可用的 token 预算，定期安抚它"还有多少余量"，对抗它低估可用空间的天性。
# 缓解上下文焦虑的配置思路
def 设置上下文焦虑管理():
上下文缓冲 = 启用大上下文(1M token)
实际限制 = 把使用上限卡在(200k token)
提示词前缀 = "你有充足的上下文，不要赶进度..."
提示词后缀 = "慢慢来，上下文不是约束..."证据
- 来自 Cognition AI（2025 年 9 月关于 Devin + Sonnet 4.5 的经验分享），是生产一线的观察。
- 证据等级偏
emerging（新兴），但现象真实且普遍。
怎么用
- 当你的 Agent 出现"任务提前结束""明显走捷径""在还有余量时草草收尾"时，考虑用这个模式。
- 模型越强、上下文越大，越值得配上缓冲策略。
- 结合下一章的压缩模式一起用：既给足跑道，又控制实际用量。
取舍
- 好处：减少任务提前收尾；让模型在长任务里保持专注。
- 代价：要开着大窗口（可能涉及额外配置）；"反提示"需要针对具体模型调。
模式三：提示词缓存（Prompt Caching）
问题
长会话的 Agent 有个隐蔽的性能杀手：每一次调用，都要把整个对话历史重新发给 API。随着对话变长，这些静态内容被一遍遍重复处理——没有缓存的话，推理成本和延迟会呈二次方增长。
你可能想用"服务端状态"来优化，但有些场景不允许（比如零数据留存策略 ZDR），或者中途改配置（换沙箱、换工具、换工作目录）会破坏缓存。
方案
核心洞察：提示词缓存只对"完全一致的前缀"生效。如果本次请求的前 N 个 token 和上一次请求完全一样，缓存的计算结果就能直接复用。
所以策略是：永远追加新消息，而不是修改已有消息；并精心排列消息顺序，最大化缓存命中率。
排列原则很简单：
- 静态内容放最前（所有请求都一样，永远命中缓存）：
- 系统消息
- 工具定义（顺序要保持一致！）
- 开发者指令、项目指令
- 变化内容放最后（每次请求都不一样）：
- 用户消息
- 助手消息
- 工具调用结果（一轮轮追加）
缓存是在 token 级别工作的，不是消息级别——它逐 token 检查前缀匹配，与消息边界无关。所以只要前缀严格一致，就能命中。
证据
- 来自 OpenAI Codex 团队（Michael Bolin）对 Agent 循环的工程总结。
- 这是各大推理服务商（Anthropic、OpenAI）都提供的基础能力，实践验证充分。
怎么用
- 把"静态在前、动态在后"当成 Agent 提示词的标准结构。
- 工具定义的顺序一旦定下就别随便改——改顺序 = 缓存全失效。
- 中途要改配置（沙箱、工具）时，意识到这会打断缓存，尽量安排在会话边界。
取舍
- 好处：长会话成本显著下降、延迟降低。
- 代价：需要约束消息结构；对"每次内容都不同"的短任务没什么用。
三个模式怎么选
| 场景 | 推荐模式 |
|---|---|
| 常驻上下文在悄悄膨胀，没人记账 | Context Budget 治理 |
| Agent 长任务提前收尾、走捷径 | 上下文焦虑管理 |
| 长会话成本二次方上涨 | Prompt Caching |
| 有无人值守的定时 Agent | Context Budget 治理（必做） |
三个模式是互补的：预算治理管"总量"和"趋势"，焦虑管理管"模型心理"，缓存管"每一轮的成本"。它们可以同时用。
实践清单
- 给所有常驻上下文来源建基线计数器，按来源细分记录
- 设趋势报警（周环比中位数 +10%-25%），而不是只设天花板
- 每个定时任务带花费上限（正常一轮的 10-50 倍）
- 多 Agent 工作流先估算 Agent 数量，每层设上限
- 记忆/索引文件设行数/KB 上限，超限迁移到按主题拆分
- 压缩时明确"必须保留"和"可以丢弃"的内容
- 长任务给模型"上下文还很充足"的安抚，开缓冲
- 提示词按"静态在前、动态在后"排列，工具定义顺序固定
本章小结
- 上下文是 Agent 最宝贵的资源，但会悄悄膨胀——要像管钱一样管：测量、盯趋势、设上限。
- 模型自己会有"上下文焦虑"，会提前收尾——用缓冲和反提示对抗。
- Prompt Caching 只对"完全一致的前缀"生效——静态在前、动态在后，工具顺序固定。
- 三管齐下，让上下文账单不再失控。
下一章，我们讲"装不下了怎么办"——上下文压缩与精选：自动压缩、精选代码窗口、语义过滤、大文件渐进披露。