精准的 Token 估计是上下文预算管理的基础。
在实际应用中，Token 计数通常采用混合策略：
- 精确计数：使用上次 API 调用返回的
input_tokens值作为基准 - 粗估计：对于新增文本，可先用“字符数 / 经验系数”做粗估，但中文、代码、JSON 和不同 tokenizer 的差异很大；图像、音频、PDF 等多模态输入应以供应商 token counting API 或模型文档为准
- 输出预留：按任务期望输出、模型
max_tokens和上下文窗口保留缓冲，避免填满窗口导致截断或停止 - 跨版本迁移注意：截至 2026-05-17，Anthropic 官方价格页说明 Claude Opus 4.7 使用新 tokenizer，同一固定文本最多可能多消耗 35% tokens。从旧版本切换到新 tokenizer 时，需重新校准估算、
max_tokens与压缩触发阈值。
当需要动态确定模型上下文窗口大小时，系统通常采用优先级链：
- 模型能力查询：优先读取供应商模型元数据、token counting API、本地模型卡或部署平台配置
- 显式应用配置：按模型 ID、区域、账号层级和 beta flag 固化允许的上下文上限
- 请求/响应能力信号：某些 API 会通过 beta header、错误码或响应元数据暴露可用窗口
- 模型名称标记：只作为辅助提示，不能把后缀当成权威来源
- 保守默认值：无法确认时应 fail closed，要求显式配置，而不是假设 200K 或 1M
为不同组成部分预先分配 Token 预算：
| 组成部分 | 典型预算占比 | 说明 |
|---|---|---|
| 系统提示词 | 5-15% | 尽量精简 |
| 知识/检索内容 | 30-50% | 核心信息区 |
| 对话历史 | 20-30% | 动态调整 |
| 输出预留 | 15-25% | 确保足够空间 |
注：以上占比为常见起点，实际分配需结合任务类型、模型上下文长度、工具调用开销与期望输出长度进行调整。
图 6-5：Token 预算堆叠图
根据任务特点动态调整分配：
- 知识密集任务：增加检索内容预算
- 多轮对话任务：增加历史预算
- 长文生成任务：增加输出预留
系统提示词是最稳定的上下文部分，应该优化到最精简。
删除冗余
- 移除重复说明
- 合并相似指令
- 使用简洁表达
结构化表达
- 使用列表替代段落
- 使用表格组织规则
- 采用编号便于引用
模板复用
- 将通用部分模板化
- 动态部分参数化
- 条件加载可选内容
人工精简
最直接有效，逐字审查每句话的必要性。
LLM 辅助压缩
让模型帮助精简：
请将以下系统提示词压缩到 500 Token 以内，保持所有关键指令：
[原始提示词]
符号化表达
用简洁符号替代冗长说明：
原文：如果用户没有明确指定格式，请使用 Markdown 格式输出
精简：默认格式=Markdown
检索内容往往占用大量上下文，是优化重点。
- 提高检索精度，减少无关结果
- 使用重排序过滤低相关内容
- 根据置信度阈值截断结果
对检索结果进行二次压缩：
- 提取与查询相关的片段
- 生成针对性摘要
- 合并重复信息
按需检索，而非一次全部加载：
- 先用少量关键信息回答
- 如果需要更多细节再补充检索
- 避免预防性的大量检索
格式选择影响 Token 效率。
| 格式 | Token 效率 | 可读性 | 适用场景 |
|---|---|---|---|
| 纯文本 | 高 | 一般 | 连续内容 |
| Markdown | 中 | 好 | 结构化文档 |
| JSON | 低 | 中 | 数据交换 |
| XML | 最低 | 高 | 明确边界 |
- 非必要不使用嵌套结构
- 属性名尽量简短
- 避免冗长的 key 名称
- 考虑自定义简洁格式
在不减少模型能力的前提下，压缩 KV 缓存体积是实现更长上下文的关键路径。
DeepSeek-V2/V3 采用的 多头隐式注意力（Multi-head Latent Attention） 将 KV 缓存压缩到极致：
- 原始 KV 缓存占用：以 Llama-3.1-405B 为例，单个 Token 需要约 516KB 的 KV 缓存
- MLA 压缩后：每个 Token 的 KV 缓存仅需约 70KB，压缩比约 7 倍
- 实现原理：将 KV 映射到低维隐向量，再按需扩展到多个查询头，既保留了多头注意力的表达能力，又大幅降低显存需求
GQA（Grouped Query Attention） 和 MQA（Multi-Query Attention）：多个查询头共享一个或几个 KV 头组，线性降低 KV 缓存体积。
- GQA：8 个查询头共享 1 个 KV 头，KV 缓存减少约 8 倍
- MQA（极端情况）：所有查询头共享单个 KV 头，缓存最小化但精度可能下降
- 权衡：在精度损失与缓存收益间找到最优点，通常 GQA 是最佳选择
将 KV 缓存从 FP32 或 BF16 量化到 INT4 或 FP8：
- INT4 量化：降低位宽同时保留关键信息，从 BF16/FP16 量化到 INT4 理论上可将 KV 缓存显存需求降至约 1/4，有效上下文长度可放大约 4 倍
- 实现策略：对 KV 进行分段量化，采用动态范围缩放，降低量化误差
- 成本：推理时需额外的反量化开销，但总体 Token 吞吐仍能提升
减少重复内容的传输和计算。
许多模型支持 Prompt 缓存机制，这是优化成本和延迟的最有效手段之一。此外，基础设施层面的 KV 缓存共享技术为系统级优化提供了新机遇。
经济学原理：
- 存活时间（TTL）：缓存通常有较短的生命周期，每次缓存命中都会刷新该计时；Anthropic 当前提供 5 分钟（默认）与 1 小时（extended，在
cache_control中显式设置"ttl": "1h"字符串）两档，长时程 Agent 会话推荐使用 1 小时档。 - 成本不对称性：写入缓存（计算 KV Cache 并存入高速显存）通常比常规输入 Token 更贵（可能有 25% 溢价（5 分钟默认 TTL 写入约 1.25x 基价；1 小时 extended TTL 写入约 2x 基价）），但在随后的请求中读取缓存却能获得极大的折扣（如高达 90% 的降价）。频繁且连续的交互能够极大地放大这种收益。
基础设施级缓存：Radix Attention（SGLang）
Radix Attention 在系统级别实现全局 KV 缓存共享，超越单个会话的限制：
- 全局基数树：维护所有历史 KV 缓存的全局 Radix 树，每个节点代表一个 Token 序列的 KV 缓存切片
- 前缀匹配与重用：新请求到达时，系统自动检测其前缀是否在树中存在。若存在完全匹配的前缀（如相同的系统提示词 + RAG 文档），新请求可直接跳过 Prefill，仅执行 Decode 阶段
- 应用场景：系统提示词和 RAG 文档在多个请求间高度重复时，收益最大。客服、内部知识库等场景可能获得较高命中率，但具体比例必须用线上流量验证。
KV 缓存感知路由（KV-Cache-Aware Affinity Routing）
API 网关在接收请求时计算请求前缀的哈希，将其路由到缓存该前缀的 GPU 节点，避免冷启动：
- 哈希映射：对请求的系统提示词 + 前 k 个用户消息计算哈希
- 节点亲和性：根据哈希值选择已缓存该前缀的节点，若无则选择最近空闲的节点
- 成本效益：对于高重复的前缀（RAG 文档、系统提示词），可显著降低 Prefill 计算；具体节省比例取决于请求重复度、缓存生命周期和调度实现。
架构级最佳实践：
为最大化缓存命中率，系统设计需要严格保持“前缀一致性”。
- 使用消息，而非修改系统提示词：绝对不要将会变化的上下文（如当前时间、随时更新的文件状态）写入系统提示词（System Prompt）。正确的做法是保持系统提示词绝对冻结，并使用特定的标记形式将动态数据放入最新的用户消息中。
- 延迟加载工具：不要在中途动态添加或删除可用工具，这会改变前缀并使得迄今为止的全部缓存由于错位而失效。最佳做法是：始终将所有可用工具的轻量级“存根（Stubs，只包含名称和基础描述）”组装给模型，当模型尝试并确实需要调用时，再通过主动的检索工具获取该工具的完整参数要求，并将其作为附加消息传入。
- 跨模式保持工具稳定：如果系统拥有诸如“计划模式”与“执行模式”，不要在模式切换时尝试通过增删工具列表来加以限制。应保持全量的工具定义始终不变，仅仅通过添加一条普通的前置消息来指示模型改变其行为（如“你现在进入了计划模式，请只读而不要使用修改源代码的任何动作”）。
不同应用场景中，前缀缓存的收益差异显著：
- 复杂系统提示词：智能体、客服机器人和 RAG 管道通常携带数千 Token 的系统提示词，每次请求完全一致。前缀缓存可跳过这些 Token 的 Prefill 计算，TTFT 降幅需通过压测确认
- 代码补全与生成：需要将当前文件的数千行代码作为共享上下文，前缀缓存可避免对未修改的代码行重复计算
- 文档摘要与问答：文档内容在多次提问中保持不变，仅用户问题变化。将文档放在提示词前部、问题放在末尾，即可最大化缓存复用
- 多轮对话：聊天模板在每轮中回传所有历史消息，前缀缓存的收益随对话轮次递增——第 N 轮对话可复用前 N-1 轮的所有 KV 缓存
设计上下文时应始终考虑缓存特性：将频繁变化的内容（如用户输入、最新检索结果）放在提示词末尾，将稳定内容（如系统提示词、工具定义）放在前部。这一原则不仅适用于单轮请求，在多轮对话和智能体工作流中同样关键。
对于频繁使用的内容预先计算：
- 预生成摘要并存储
- 检索结果预处理
- 通用模板预填充
- Token 使用分布：各部分占比
- 使用效率：有效信息/总 Token
- 边界情况：接近上限的频率
- 成本追踪：Token 费用趋势
- 建立基准线
- 识别最大消耗点
- 针对性优化
- 验证效果
- 持续监控
上下文优化是一个持续的过程，需要在效果和效率之间找到最佳平衡点。
对于执行跨越数十分钟到数小时的长期任务（如大规模代码迁移或全面的研究项目），需要专门的技术来解决上下文窗口限制。以下介绍两种核心技术：
Compaction 是一种在上下文接近窗口限制时，将对话内容进行摘要，并以摘要重新初始化新上下文窗口的实践。
核心思路：高保真地提炼上下文窗口的内容，使智能体能够以最小的性能损失继续工作。
实现要点：
- 将消息历史传递给模型进行总结和压缩
- 保留架构决策、未解决的问题和实现细节
- 丢弃冗余的工具输出或消息
- 用压缩后的上下文加上最近访问的文件继续工作
分叉操作与缓存复用： 在执行压缩任务本身时，一个关键的优化设计是将压缩请求作为当前会话的“分叉（Fork 操作）”。即在压缩请求中尽量复用原会话稳定的系统提示词、知识库和工具定义作为前缀，仅将对话消息部分替换为原消息副本以及“请总结上述对话”的指令消息。缓存命中取决于供应商规则、最小 token 阈值、TTL、路由、cache control 位置以及前缀是否逐字节一致；因此工程上应监控 cache hit/miss 指标，而不能把分叉请求默认视为必然命中。
压缩的艺术：关键在于选择保留什么与丢弃什么。过于激进的压缩可能导致丢失细微但关键的上下文信息。
最佳实践：从最大化召回（recall）开始，确保压缩提示词捕获了跟踪中的每一条相关信息，然后迭代改进精度以消除多余内容。
结构化笔记是一种 Agent 定期将笔记持久化到上下文窗口外部存储的技术。这些笔记在后续需要时被拉回上下文窗口。
工作方式：
- 智能体创建待办事项列表或维护
NOTES.md文件 - 用于跟踪复杂任务的进展
- 保持关键上下文和依赖关系，否则这些信息会在大量工具调用中丢失
实际案例（思路说明）：在长时间交互任务中，智能体可以通过持续维护结构化笔记来跟踪关键状态（例如计数器、已完成步骤与下一步目标）。当上下文被重置后，读取笔记即可恢复工作状态并继续执行。
选择策略的指南：
| 技术 | 适用场景 |
|---|---|
| Compaction | 需要大量来回交互的任务 |
| Structured Note-taking | 有明确里程碑的迭代开发 |
| 子智能体架构 | 需要并行探索的复杂研究分析 |
在长时程智能体任务中，压缩是不可避免的有损操作。为降低信息损失，生产级系统通常在压缩前执行 记忆刷写（Memory Flush），并建立 压缩检查点（Compaction Checkpoint） 以支持任务恢复。
当上下文占用接近窗口限制的某个阈值（如 75%）时，系统在执行压缩前先触发一次记忆刷写：将需要长期保留的关键信息（决策、偏好、待办事项）写入外部持久化存储（如本地 Markdown 文件或数据库），确保这些信息不会在压缩过程中丢失。
上下文接近阈值 → 刷写关键记忆到外部存储 → 执行有损压缩 → 继续工作
这种“先存后压”的策略已被多个生产级智能体采用。其核心配置通常包括：刷写触发阈值、写入目标路径、以及哪些类型的信息需要优先保留。
将这三者串起来看，核心不是“上下文满了就压缩”，而是先判断能否继续保留原窗口，再决定是否先刷写记忆并建立检查点：
graph TD
A["上下文占用持续上升"] --> B{"是否接近安全阈值?"}
B -- "否" --> C["继续执行并监控预算"]
B -- "是" --> D{"近期信息是否仍高频被引用?"}
D -- "是" --> E["延后压缩\n优先裁剪旧工具输出"]
D -- "否" --> F["刷写长期记忆\n决策 / 待办 / 偏好 / 活跃文件"]
F --> G["创建压缩检查点\n摘要 + 结构化状态 + 文件索引"]
G --> H["执行有损压缩"]
H --> I{"压缩后还能安全恢复任务?"}
I -- "是" --> J["加载检查点摘要并继续工作"]
I -- "否" --> K["回退到最近检查点\n补充关键上下文后重试"]
E --> C
图 6-6：压缩、记忆刷写与检查点决策流
对于可能运行数小时的任务，仅靠压缩摘要可能不足以恢复完整的工作状态。压缩检查点在每次压缩时额外保存：
- 压缩摘要：对话历史的精简版本
- 结构化状态：当前的任务进度、待办清单、已完成步骤
- 活跃文件列表：最近读写的文件路径和关键片段
当任务需要恢复时（如会话中断后重启），系统可以从最近的检查点加载状态，而不是从零开始。这种机制对于跨越多次压缩的超长任务尤为关键。
长时程任务中，工具执行结果（如编译日志、API 响应）会随时间大量积累。分层裁剪策略按时间衰减处理这些输出：
| 时间距离 | 裁剪策略 | 示例 |
|---|---|---|
| 最近 3 轮 | 完整保留 | 最新的命令输出全文 |
| 4-10 轮前 | 软裁剪（保留首尾） | 前 1500 字符 + 后 1500 字符 |
| 10 轮以前 | 硬清空 | [旧工具结果已清空] 占位符 |
这种裁剪只作用于传递给模型的上下文，磁盘上的完整执行结果不受影响，后续仍可通过检索访问。结合提示词缓存的 TTL 机制，系统还可以在缓存过期后自动触发裁剪，降低重新缓存的成本。
在一些生产级智能体的开发中，为了应对超长任务和复杂工具调用，常会演化出一些专门的上下文缩减策略。
（关于相关思路的进一步讨论，请参见 13.5 案例分析：全自主智能体架构（示意））
将工具执行结果分为“完整版”和“紧凑版”两种形式...
随着对话进行，早期结果被替换为摘要...
即便使用摘要，也强制使用结构化 Schema...