跳转至

上下文管理常用策略

概述

上下文工程（Context Engineering）是一门兼具艺术与科学的学问——其核心在于：在智能体（Agent）执行轨迹的每一个步骤中，将恰到好处的信息填入上下文窗口（Context Window）。正如 Andrej Karpathy 所比喻的：LLM 好比 CPU，其上下文窗口则如同 RAM，而操作系统的职责，就是精心甄选哪些内容能够驻留其中。

Lance Martin（LangChain）将相关策略归纳为四类：写入（write）、筛选（select）、压缩（compress）和隔离（isolate）。本页将这四类策略映射到生产级智能体系统中最常被引用的五种策略，并结合 Manus、Anthropic、LangGraph 等的实现案例加以说明。

策略一：卸载上下文（写入文件系统）

核心思路：将信息保存在上下文窗口之外，按需检索，而非将所有内容都保留在活跃上下文中。

适用场景：长期记忆、草稿笔记、待办事项列表、工具调用引用、研究计划。

工作原理：智能体将数据写入文件、数据库或结构化状态对象，每一步骤仅检索所需内容，保持活跃上下文精简。

生产案例： - Manus 将文件系统视为"终极上下文"——容量无限、天然持久，且可被智能体直接操作。只要保留 URL，网页内容即可从上下文中移除；只要文件路径可用，文档内容也可省略。所有压缩策略都设计为可还原。 - Anthropic 的多智能体研究系统中，LeadResearcher 会在任务开始时将规划写入记忆（Memory），因为超过 200K Token 的上下文将被截断。子智能体（Subagent）将输出写入外部系统，并将轻量引用传回协调者，从而防止多阶段处理中的信息丢失。 - Claude Code 使用 CLAUDE.md 文件与记忆工具（公测阶段）进行结构化笔记。那个玩宝可梦游戏的 Claude 智能体，就是借助这一模式在数千个游戏步骤中保持精确计数的。 - Anthropic 的"think"工具为模型提供了一个草稿空间，用于记录不干扰活跃上下文、但可供后续参考的笔记。将该工具与领域专属提示词配合使用，在专业智能体基准测试中可带来高达 54% 的性能提升。

权衡：智能体需要学会何时写入、写入什么。检索会引入延迟。信息必须组织得足够好，才能在后续被找到。

策略二：压缩上下文（上下文压缩 / 摘要）

核心思路：对累积的上下文进行压缩，在减少 Token 数量的同时保留核心语义。

适用场景：长对话摘要、工具调用结果裁剪、智能体间交接时的摘要、删除无关的历史消息。

工作原理：由 LLM（或专用模型）对上下文进行提炼，保留关键决策、错误信息和状态，同时丢弃冗余的工具输出和中间步骤。

生产案例： - Claude Code 在上下文窗口使用量超过 95% 后自动触发压缩，对用户与智能体的完整交互轨迹进行摘要。它保留架构决策、未解决的 Bug 和实现细节，同时丢弃冗余的工具输出。压缩后，智能体以压缩上下文加最近访问的五个文件继续运行。 - LangGraph 的 DeepAgent 将摘要作为中间件使用——在智能体轮次之间设置专用的摘要步骤。 - Cognition（Devin） 使用一个专门用于智能体间交接摘要的微调模型，这充分说明该步骤所需的投入有多重要。他们的原则是：共享完整的智能体追踪记录，而非只传递单条消息。 - 上下文裁剪（Context Pruning）（更轻量的替代方案）：与基于 LLM 的摘要不同，裁剪使用启发式规则或专用模型过滤无关内容。Provence 是一个 1.75GB 的问答上下文裁剪器，可从文档中剔除 95% 的无关内容。工具结果清除——即在原始工具输出被处理后将其删除——是最安全、最轻量的压缩形式之一。

权衡：存在信息丢失的风险。判断哪些内容应保留、哪些应丢弃并不容易。Cognition 建议在生产环境中微调一个小型模型专门承担此任务；Anthropic 则建议先以最大化召回率为起点，再迭代提升精准率。

API 层原语（Anthropic）：Claude API 提供两个原生上下文压缩原语： - compact_20260112（Beta 请求头 compact-2026-01-12）：服务端压缩，在可配置的 Token 阈值处触发（最小 50K，默认 150K）。返回一个类型化的压缩块，替换先前的对话轮次。instructions 参数会完全替换默认摘要提示词——自定义指令必须包含完整框架，而非仅作补充。与任务核心相关的高层事实通常会保留；附录中的细节（表格单元格、精确措辞等）通常不会保留。 - clear_tool_uses_20250919（Beta 请求头 context-management-2025-06-27）：精准替换 tool_result 内容块为简短占位符，同时保留 tool_use 记录、用户消息和智能体推理内容，不产生推理成本。关键参数：trigger（Token 阈值）、keep（保留最近几条结果，默认 3）、clear_at_least（每次触发的最小清除 Token 数——对缓存失效经济性至关重要）、exclude_tools（豁免特定工具，例如记忆工具）。与记忆工具配合使用时，务必设置 exclude_tools: ["memory"]，以防智能体丢失刚刚保存内容的追踪记录。

策略三：检索上下文（RAG 与即时加载）

核心思路：按需将相关上下文拉入窗口，而非预先加载所有内容。

适用场景：使用 RAG 检索上下文数据、用检索结果填充提示词、按需加载文件。

工作原理：智能体维护轻量标识符（文件路径、URL、已存储的查询），并通过工具在运行时动态加载数据。这与人类的认知方式如出一辙——我们不会背诵整个语料库，而是借助归档系统和书签来定位信息。

生产案例： - Claude Code 采用混合方案：CLAUDE.md 文件预先加载，而 glob 和 grep 则支持即时文件检索，有效规避了索引过期的问题。 - 工具 RAG（Tool RAG）：将 RAG 应用于工具描述，仅为当前任务选取最相关的工具。研究表明，当工具数量超过 30 个时，这一方法可将工具选择准确率提升高达 3 倍。"Less is More"论文发现，在 Llama 3.1 8b 上使用动态工具选择可带来 44% 的性能提升。 - Windsurf 综合使用 AST 解析、嵌入向量搜索、grep/文件搜索、知识图谱检索和重排序，实现大规模代码上下文的高效检索。

权衡：运行时探索比预计算检索更慢。智能体需要良好的启发式规则，以避免追逐死胡同。元数据（文件名、目录结构、时间戳）提供了帮助智能体高效导航的重要信号。

策略四：隔离上下文（多智能体 / 隔离机制）

核心思路：将上下文拆分到多个智能体或线程中，每个智能体拥有专注、干净的上下文窗口。

适用场景：并行研究任务、复杂工作流中的关注点分离、防止无关子任务之间的上下文冲突。

工作原理：主控智能体将任务分解为子任务并派生子智能体，每个子智能体拥有各自的上下文窗口。子智能体返回精简摘要（通常为 1,000–2,000 Token），而非完整的执行追踪记录。

生产案例： - Anthropic 的多智能体研究系统：子智能体并行运行，各自拥有隔离的上下文窗口，分别探索问题的不同方面。在 Anthropic 内部研究评测中，该方案比单智能体 Claude Opus 4 高出 90.2%。Token 用量约为对话模式的 15 倍，因此该模式最适合高价值任务。 - HuggingFace 的 CodeAgent：使用沙箱环境将工具调用结果与 LLM 上下文隔离。代码在沙箱中运行，仅将选定的返回值传回智能体。这对图像、音频等 Token 密集型对象尤为有效。 - 智能体运行时状态：基于 Pydantic 模式的状态对象可实现上下文隔离——每轮仅将 messages 字段暴露给 LLM，其他字段则按需选择性使用。

重要注意事项（来自 Cognition/Walden Yan）： - 缺乏共享上下文的子智能体会基于相互冲突的假设做出决策。原则：共享完整的智能体追踪记录，而非只传递单条消息。 - 行动隐含着决策。当子智能体在彼此不知情的情况下并行工作时，其输出可能不一致。 - Claude Code 的子智能体被刻意限制为仅回答问题，不编写代码，原因正是它们缺乏主智能体的完整上下文。 - 多智能体并行最适合广度优先任务（研究、信息收集），而非高度相互依赖的任务（大多数编码任务）。

策略五：缓存上下文

核心思路：将频繁使用的上下文元素（系统提示词、工具描述、智能体指令）存入缓存，以降低成本和延迟。

适用场景：缓存输入 Token、将智能体指令和工具描述作为稳定前缀进行缓存。

工作原理：Anthropic、Google 等提供商提供提示词缓存功能。缓存 Token 的成本大幅降低——以 Claude Sonnet 为例，缓存输入 Token 的费用为 $0.30/MTok，而未缓存时为 $3.00/MTok（相差 10 倍）。

生产案例： - Manus 将 KV 缓存命中率视为生产级智能体最重要的单一指标。关键实践：保持提示词前缀稳定（即使单个 Token 的差异也会使缓存失效）、让上下文只追加不修改、使用确定性序列化，并显式标记缓存断点。 - Gemini 为大型稳定前缀提供 Context Caching（上下文缓存）。 - Manus 的"掩盖而非移除"模式：与其动态增减工具（这会使 KV 缓存失效），Manus 使用上下文感知状态机在解码时屏蔽 Token logits，在不修改工具定义的前提下约束工具选择。

权衡：缓存失效十分隐蔽——系统提示词中的时间戳、非确定性 JSON 序列化以及动态工具列表，都会在不知不觉中拉低缓存命中率。这要求在提示词和上下文设计上保持严格的纪律性。

策略对比

策略 最适合 主要风险 代表案例
卸载（写入） 长任务、持久化记忆、大型工具输出 检索开销、组织复杂性 Manus 文件系统、Anthropic 记忆工具、Claude Code CLAUDE.md
压缩（摘要） 长对话、智能体交接 信息丢失 Claude Code 自动压缩、LangGraph DeepAgent、Cognition 微调摘要模型
检索（RAG） 大型知识库、动态数据、大量工具 延迟、检索质量 Claude Code 即时加载、工具 RAG、Windsurf 代码检索
隔离（多智能体） 广度优先研究、可并行任务 上下文冲突、15 倍 Token 成本 Anthropic 研究系统、HuggingFace CodeAgent
缓存 稳定的系统提示词、重复的工具描述 缓存失效、前缀不稳定 Manus KV 缓存、Gemini Context Caching

各策略的成本与性能权衡

Shen 等人（2026）提出了效率前沿（Efficiency Frontier）框架——一种统一的、感知部署环境的方法，用于基于联合优化的成本和性能来选择策略。在 5,000 个 HotpotQA 实例上的评测得出以下关键发现：

  • 低复用部署（每个语料库查询次数少）优先采用检索：无需预处理开销，且在 F1 相当的情况下具有成本竞争力。
  • 高复用部署优先采用记忆压缩：预处理成本随查询次数的增加而摊薄，在质量相当的情况下 Token 成本可比全上下文方案降低 50% 以上。
  • 全上下文提示词在成本上几乎不是最优选择——通过感知部署环境的策略选择，在性能相当的情况下可减少约 25% 的 Token 用量。
  • 各策略之间存在转折点，取决于复用参数 N（共享同一预处理步骤的查询数量）。

完整决策指南请参见效率前沿框架。

按优先级选择策略

优先级 推荐方案
可并行任务 无论上下文大小，优先评估多智能体隔离方案
降低成本 优先采用缓存和压缩策略
低延迟 重点优化缓存并采用并行处理
高精准度 构建完善的检索与记忆系统

检索效率基准

评估检索质量时，应追踪实际使用条目与检索条目的比率： - 效率低于 40%：检索噪声过多——收紧检索条件 - 效率在 50%–70% 之间：处于甜蜜区间，所有关键信息均已涵盖 - 效率高于 80% 但仍遗漏关键信息：检索范围过窄——放宽检索条件

Windsurf 通过综合使用嵌入搜索（语义相似度）、grep（精确匹配）、知识图谱（概念关系）和 AST 解析（代码结构），实现了比单一检索技术高 3 倍的准确率。

实施路线图

第一周：基础阶段（快速见效）

从度量开始——无法测量的东西无从优化。部署全面的日志记录，捕获每次智能体交互、Token 用量、缓存命中率和故障模式。

高影响、低投入的优化措施： 1. 优化工具描述的清晰度和辨识度，让智能体能区分相似工具 2. 添加基本错误保留机制——将失败尝试保留在上下文中以防止重复犯错（实现成本为零） 3. 部署生产护栏，保障安全性和可靠性

这些改动通常能以 20% 的投入带来 80% 的收益。

第一个月：基础设施建设

  1. 实现动态工具检索：当工具数量超过 20 个时，每次查询只向智能体展示最相关的工具
  2. 添加可逆压缩——存储 URL 而非网页内容，存储文件路径而非文件内容（节省 Token 同时保留恢复路径）
  3. 在上下文容量达到 80% 时触发自动摘要，防止硬性失败
  4. 构建简单的记忆系统，配备基本的文件存储，让智能体无需将信息全部加载到上下文中即可访问

高级阶段：规模化

仅在掌握基础之后： 1. 多智能体架构，用于真正可并行的任务——Anthropic 的研究显示，以 15 倍 Token 成本换取 90% 的性能提升 2. 注意力引导：通过待办事项列表和目标复述，减少长时间运行任务中的偏移 3. 评测洞察：在用户察觉之前捕捉新出现的故障模式

参见

参考资料