告别 Token 暴涨！AI Agent 深度上下文管理与降本实战(下)

在AI agent使用时，依靠良好的使用习惯与精准调用，可以解决大部分日常开发中的 Token 浪费。但面对长流水线、复杂 Agent 自动迭代等超大上下文场景，仅靠人工控制远远不够。 **下半部分将深入底层技术与架构设计，详细拆解 上下文缓存（Context Cache）和 上下文自动压缩/剪枝（Context Compression）
上篇：告别 Token 暴涨！AI Agent 深度上下文管理与降本实战(上)

上下文缓存机制

调用大模型时，不同推理请求可能出现输入内容的重叠（例如多轮对话或对同一本书的多次提问）。上下文缓存（Context Cache） 技术可以缓存这些请求的公共前缀，减少推理时的重复计算。核心优势在于：将一次性预处理好的高Token长文本（如文档、代码库、系统指令）的 KV Cache 保存下来。当后续请求包含相同的固定前缀时，模型无需重新计算这些 Token 的 Attention 权重，从而大幅降低 API 费用（通常可降低 50%~90%）并显著减少首字响应延迟（TTFT）。

频繁请求固定长上下文时使用

上下文缓存机制特别适合频繁请求、重复引用大量初始上下文的场景，例如：

• 大文件/长小说阅读助手：把一本几十万字的小说或长 PDF 传给 AI，随时向它打听任何细节或剧情走向。
• 个人全量笔记/日志检索：把过去积累的几年日记、学习笔记或读书心得全部挂载，随时帮你按主题总结或提炼。
• 企业规章与行政制度等问答类 Bot：员工随时查询复杂的报销流程、假期考勤以及员工手册中的具体条款。
• 大型游戏规则/通关攻略助手：预置整部桌游设定集或大型 RPG 庞大的系统指南，玩家遇到卡关或规则疑问随时随查。
• 长录音/会议纪要反复提炼：将两小时的部门开会录音或讲座视频丢给 AI，不断要求它按不同部门或主题提取待办事项。
• 复杂家电/车机电子说明书：遇到故障或不会用的功能时，车主或用户随时向装载了整本说明书的助手提问。

为满足不同场景的需求，上下文缓存提供两种工作模式，可以根据对便捷性、确定性及成本的需求进行选择：

• 显式缓存：需要主动开启的缓存模式。需要主动为指定内容创建缓存，以在有效期内实现确定性命中。除了输入 Token 计费，用于创建缓存的 Token 按输入 Token 标准单价的 125% 计费，后续命中仅需支付 10%的费用。
• 隐式缓存：此为自动模式，无需额外配置，且无法关闭，适合追求便捷的通用场景。系统会自动识别请求内容的公共前缀并进行缓存，但缓存命中率不确定。对命中缓存的部分，按输入 Token 标准单价的 20% 计费。

上下文缓存最佳实践

保持你的提示前缀稳定

由于LLM的自回归特性，即使是单个标记的差异也会使该标记之后的缓存失效。一个常见的错误是在系统提示的开头包含时间戳——尤其是精确到秒的时间戳。虽然这让模型能告诉你当前时间，但也会降低你的缓存命中率。在日常使用中，需要关注系统提示词、规范或约束提示词和工具定义的稳定性，不要在一个对话中随意更改。

上下文只追加

避免修改之前的操作或观察。确保你的序列化是确定性的。许多编程语言和库在序列化JSON对象时不保证键顺序的稳定性，这可能会悄无声息地破坏缓存。

用一个 “智能客服处理退换货流程” 的日常场景为例：
在多轮对话（或 Agent 执行步骤）中，前 3 步已经积累的上下文（系统提示词、用户的历史指令、模型的历史动作及系统的反馈）会被缓存（Cache Hit），模型在第 4 步只需要处理新增的部分（Cache Miss），从而大幅节省计算资源和响应时间。

系统提示词 (Instruction)：

“你是一个电商平台的客服 AI。你的职责是协助用户处理退货。请按以下顺序操作：1. 询问订单号；2. 验证订单状态；3. 询问退货原因；4. 生成退货标签并结案。”

**📌 前 3 步对话状态 **

• 用户输入的消息 (Action 1)：
  “你好，我想退掉上周买的那双鞋。”
• 模型回复 / 系统反馈 (Observation 1)：
  “没问题！请提供一下您的订单号。”
• 用户输入的消息 (Action 2)：
  “订单号是 #12345678。”
• 模型回复 / 系统反馈 (Observation 2)：
  “已查询到该订单，商品为‘跑步鞋’，状态为‘已送达’，符合退货条件。请问您的退货原因是什么？”
• 用户输入的消息 (Action 3)：
  “尺码太小了，穿着挤脚。”
• 模型回复 / 系统反馈 (Observation 3)：
  “好的，已为您记录退货原因为‘尺码不合适’。正在为您生成退货寄件标签…”

**📌 第 4 步对话状态

🔹 Cache Hit（缓存命中区域）：
上述从 Instruction 到 Observation 3 的所有历史文本已经存在缓存中，大模型不需要重复计算和理解这部分内容。
🔻 Cache Miss（缓存未命中/新增区域）：
用户输入的消息 (Action 4)：
“顺便问一下，快递员什么时候上门取件？”
模型回复 (Observation 4)：
“您的退货标签已生成！快递员预计会在今天下午 2:00 - 4:00 之间上门取件，请保持电话畅通。”

💡 核心逻辑解读

• Cache Hit（蓝框）：模型在处理第 4 轮对话时，直接复用了前 3 轮对话建立的注意力机制（KV Cache），避免了重新“读取”之前的规则和对话记录。
• Cache Miss（红框）：模型只需关注用户最新的提问 Action 4，并结合已缓存的上下文生成最新的回答 Observation 4。
• 实际价值：上下文越长（比如长文档分析、多轮复杂 Agent 交互），这种前缀缓存带来的推理成本降低（通常可省 75% 以上）和首字延迟（TTFT）缩短就越明显。

使用多个缓存标记实现精细控制

在复杂场景中，提示词通常由多个重用频率不同的部分组成。使用多个缓存标记可实现精细控制。
例如，智能客服的提示词通常包括：

• 系统人设： 高度稳定，几乎不变。
• 外部知识： 半稳定，通过知识库检索或工具查询获得，可能在连续对话中保持不变。
• 对话历史： 动态增长。
• 当前问题： 每次不同。

如果将整个提示词作为一个整体缓存，任何微小变化（如外部知识改变）都可能导致无法命中缓存。
在请求中最多可设置四个缓存标记，为提示词的不同部分分别创建缓存块，从而提升命中率并实现精细控制。

上下文缓存过大解决方案

• 缓存压缩：在保持模型性能的前提下，将 KV 缓存的大小减少最多可达 75%。利用了低秩分解等方法，从而更高效地存储相同的信息；
• 滑动窗口缓存：不保存所有的对话记录，而是采用“滑动窗口”机制，只缓存最新的对话内容。这样一来，内存使用量就能大幅降低
• 分布式缓存：将 KV 缓存分布在多台服务器上，从而实现了几乎无限的上下文长度支持。

虽然上下文看着很高深，一般智能体提供已经提供了许多隐式缓存，已KIMI为例，Context Caching 采用全自动缓存机制，你只需像平常一样调用 API：

• 无需手动创建：系统会自动识别并缓存高频使用的初始上下文。
• 无需引用缓存 ID：调用 /v1/chat/completions 时按正常方式传入 messages 即可，系统会在后台自动匹配缓存。
• 无需管理 TTL：缓存的生命周期由系统自动管理，无需人工干预。
  系统会在合适的时机自动触发缓存优化。

上下文压缩

为什么需要压缩

不管当前的大模型多么强大， 它都有严格的输入 Token 上限（如OpenAI GPT约为128k ~ 200k），在多轮代码分析、工具调用后极易触发容量危机。但如何在不丢失核心控制逻辑与关键决策的前提下主动瘦身，保证 Agent 任务的稳定自愈与长效运行，是上下文压缩的核心挑战。

压缩原则

• 信息价值的非均匀分布：关键的决策点（如人员名单）的价值高于支撑性的证据（如新闻细节），更高于冗余的噪声（如网页导航栏、页脚广告等元素）；
• 语义完整性：“Sutskever 于 2024 年 5 月离开 OpenAI”不能压缩成“Sutskever 离开”——时间和公司名是不可丢失的关键信息；
• 任务相关性：同样的内容在“查找创始人名单”和“了解个人背景”两个不同的任务下，应该产生不同的压缩结果；
• 压缩即理解：有效的压缩需要深层的语义理解能力——用更精炼的表达来捕捉上下文的精髓。而且显式压缩的结果是可审查的、可跨会话复用的，如上下文中包含一段宠物店的巡查记录：“笼子 1：黑猫。笼子 2：白猫。笼子 3：黑猫。笼子 4：黑猫。笼子 5：白猫。⋯⋯”，在对话问题主要是统计时，可以归纳总结为“当前统计：黑猫 90 只，白猫 10 只，共100只猫”。

最理想情况下达到下图的上下文形式。

什么时候压缩

已Claude Code为例，定义了多个关键阈值常量，形成一个逐级收紧的等级：

假设有效窗口为100K，当100K * 85% = 85K前，Claude Code不会进行任何干预，当有效窗口超过85K时，Claude Code就会做出相应的压缩动作。

怎么进行压缩

其四个等级对应了四个压缩策略，Claude Code 的上下文管理采用四级渐进式压缩策略，从低成本到高成本依次递进，每一级都在前一级不足以释放空间时才被激活。

Level 1: Micro Compact（微压缩）

Micro Compact（微压缩） 是最轻量的压缩手段 。它不调用任何 LLM，而是直接清除旧的工具结果内容，是极轻量无损整理。当用户通过 Snip 工具标记不再需要的消息时，系统将其中的工具调用结果替换为简短的标记文本（如 [Old tool result content cleared]），从而释放令牌空间。
Micro Compact（微压缩）是“手动、局部、精确”的瘦身工具，用来清理刚刚用完的大体积数据包。

• 日常场景：你在聊天里贴了 50 家酒店的详细设施列表（包含早餐时间、床型、WiFi 密码）。
• 降级动作：Claude Code 在后台默默把那些“已确认不考虑/已查阅完毕”的庞大酒店详情表清空，只留下“已对比完毕”的标记。
• 对你的影响：完全无感，核心的路线和预算还在，只是把刚查完的无用废话清理掉了。

Level 2: Session Memory Compact（会话记忆压缩）

“自动、批量、按时间”的垃圾回收机制，旨在缓存失效时最大程度减轻网络和 Token 载荷 。是基于时间触发的大规模工具结果清理。当检测到距离上一次助手消息的时间间隔超过配置阈值时，意味着服务端缓存已过期，此时无论内容多么重要，全量重写都无法避免 – 既然如此，不如在请求之前主动清除旧的工具结果，减小重写负载。

• 日常场景：你们讨论了很久，终于确定了“全程预算控制在 5 万元内，且必须住含早酒店”。
• 降级动作：Claude Code 不占用当前的对话字数，而是在后台悄悄拿出一张外部的小便签纸（.claude/memory），把这条铁律写下来。
• 对你的影响：极速且省钱，即使聊天记录再长，这条规则已经被记录在案，不会因为对话拉长而被挤忘。
• 最大优势：不需要调模型做摘要，直接用已维护好的结构化记忆替代传统摘要，成本接近于零。

Level 3: Context Collapse（上下午折叠）

Collapse 是上下文重构级压缩。当启用 Context Collapse 特性时，系统会在上下文使用率达到 90% 时开始提交（commit）压缩操作，在 95% 时阻止新的 spawn。这一级别的设计理念是将上下文管理从"被动压缩"转变为"主动重构"。
Collapse 模式会抑制自动压缩的触发，因为两者在 93% 的临界点会产生竞争。Collapse 作为更精细的上下文管理系统，拥有更高的优先级。

• 日常场景：你们已经连续聊了 3 天，前面关于“前 10 天欧洲段行程”的细节讨论（比如哪天几点坐什么火车、吃什么餐厅）已经极其庞大，Token 马上要爆了。
• 降级动作：Claude Code 意识到微压缩不够用了，于是花了几秒钟重新审视前 3 天的对话，把前 10 天的打卡细节打包压成一段精炼的行程报告：“1-10天：已完成法意瑞行程预定，总花费 1.8 万，住宿已落实”，替换掉原有的几万字聊天记录。
• 对你的影响：细节被删除了，但关键结论和后续进度完美保留，你可以顺畅地接着聊第 11 天的行程。
• 设计哲学： Collapse 代表了一种不同的思维方式——不是"空间不够了才压缩"，而是"在空间压力出现之前就主动重构"。这类似于操作系统的内存预取策略，在内存耗尽之前就开始整理碎片。

Level 4: AutoCompact（自动压缩）

AutoCompact 是最彻底的压缩级别 – 调用 LLM 对完整对话进行摘要。当以上三级都无法有效释放空间，且令牌用量超过自动压缩阈值时，系统启动 AutoCompact。
这是最后的兜底手段，也是最"昂贵"的——它需要一次额外的 API 调用来生成摘要。

• 日常场景：你在同一个终端里让 AI 整理并修改一整本十几万字的内容（如撰写电子书或总结海量文档），随着反复沟通，上下文空间被彻底占满。
• 降级动作：系统后台会自动开辟一个无工具权限的临时子窗口（Fork），调用 LLM 将此前所有的漫长对话记录提炼、浓缩为一份固定格式的结构化摘要，并替换掉旧的原始记录。
• 对你的影响：你在终端里的对话完全无需中断，AI 依然能基于压缩后的摘要“记住”之前的核心决策与细节，同时 Token 消耗大幅降低，避免了因空间超限而报错崩溃。

各策略对比

总结

虽然大模型的上下文空间在不断扩大，但在面对复杂 Agent 迭代与长流水线任务时，Token 的消耗速度依然惊人。想要真正实现“降本增效”，除了在上篇中提到的良好操作习惯（如及时开启新会话、手动总结与分支提取、合理规划模型选型以及精准引用工具）外，更需要理解底层架构对上下文的治理机制。

下半部分涉及的技术原理看似深奥枯燥，但核心只有两条主线：

1. 上下文缓存（Context Cache）—— 尽量复用，减少重复计算

   • 原理：通过缓存公共前缀（系统提示词、知识库、历史指令等）的 KV Cache，避免模型对重复文本进行二次 Attention 计算，最高可降低 90% 的成本并大幅缩短首字延迟。
   • 运行模式：分为显式缓存（主动创建、命中确定）与隐式缓存（系统自动识别、无感优化）。
   • 最佳实践：必须保持提示词前缀的稳定（如避免在开头写入精确到秒的时间戳）、确保序列化数据（如 JSON 键顺序）的确定性，并善用多个缓存标记来实现精细化控制。

2. 上下文压缩（Context Compression）—— 逐级瘦身，突破容量瓶颈

   • 原理：基于信息价值非均匀分布与语义完整性原则，当上下文触及容量阈值时，在不丢失核心控制逻辑的前提下主动削减冗余。
   • 四级渐进式策略（以 Claude Code 为例）：
     • Level 1 微压缩（Micro Compact）：极轻量无损整理，直接清除旧的工具输出，仅留标记。
     • Level 2 会话记忆压缩（Session Memory Compact）：零模型成本，借助外部文件（如 .claude/memory）记录核心铁律，替代传统摘要。
     • Level 3 上下文折叠（Context Collapse）：主动重构策略，在空间占满前调用模型将漫长历史重构成精炼报告，保留核心结论。
     • Level 4 自动压缩（AutoCompact）：终极保底手段，开辟临时窗口对完整对话生成结构化摘要，防止程序崩溃。

这些底层技术与架构原理虽然比较枯燥，但深入了解后，我们就能在日常开发与 Agent 调优中做到“心中有数”。配合上期提到的及时开启新会话、手动总结分支、合理选型以及精准引用工具等良好习惯，我们不仅能从源头精准控制 Token 消耗，更能在面对复杂大文本或长迭代任务时游刃有余！

参考：
AI代理的上下文工程：构建Manus的经验教训
Claude Code 上下文压缩机制深度解析
第7章：上下文管理 – Agent 的工作记忆
《深入理解 AI Agent》