目录
智能体执行任务离不开上下文支持。上下文工程是一门艺术与科学，核心是在智能体运行的每个环节，为其上下文窗口注入恰到好处的信息。本文拆解了上下文工程的四大核心策略 ——写入（Write）、筛选（Select）、压缩（Compress）、隔离（Isolate），结合主流智能体产品与相关论文案例进行解析，并阐述 LangGraph 如何为这些策略提供支持！
正如安德里亚・卡帕西（Andrej Karpathy）所言，大语言模型（LLM）堪称一种新型操作系统：LLM 本身如同中央处理器（CPU），而上下文窗口则类似于随机存取存储器（RAM），充当模型的工作内存。与 RAM 一样，LLM 的上下文窗口容量有限，无法承载所有来源的上下文信息。就像操作系统会精心筛选适合载入 CPU 内存的内容一样，上下文工程也扮演着类似的角色。卡帕西对其做出了精准概括：
“上下文工程是一门精妙的艺术与科学，旨在为下一步操作，在上下文窗口中填充恰好所需的信息。”
构建 LLM 应用时，需管理的上下文主要包括以下几类，而上下文工程正是覆盖这些类型的综合性方法：
- 指令类（Instructions）：提示词、记忆信息、少样本示例、工具描述等；
- 知识类（Knowledge）：事实、记忆数据等；
- 工具类（Tools）：工具调用产生的反馈信息。
2 智能体的上下文工程挑战
随着 LLM 推理能力与工具调用能力的提升，Agent相关研究在今年备受关注。智能体通过交替执行 LLM 调用与工具调用完成任务，尤其适用于长任务的复杂场景 —— 它会利用工具反馈来决策下一步行动。
然而，长任务与不断累积的工具反馈，会导致智能体消耗大量令牌（token），进而引发一系列问题：超出上下文窗口容量、成本与延迟飙升、智能体性能下降。德鲁・布鲁尼格（Drew Breunig）详细列举了长上下文可能导致的具体问题：
- 上下文污染（Context Poisoning）：幻觉信息混入上下文；
- 上下文干扰（Context Distraction）：上下文规模超出模型训练适配范围；
- 上下文混淆（Context Confusion）：冗余上下文影响响应结果；
- 上下文冲突（Context Clash）：上下文各部分信息相互矛盾。
正因如此，Cognition 公司强调了上下文工程的核心地位：
“上下文工程…… 实际上是构建 AI 智能体的工程师们的首要工作。”
Anthropic 也明确指出：
“智能体通常会参与数百轮对话，这需要精心设计的上下文管理策略。”
那么，当前行业是如何应对这一挑战的？我们将智能体上下文工程的常见策略归纳为四大类 —— 写入、筛选、压缩、隔离，并结合主流智能体产品与论文案例逐一解析，最后说明 LangGraph 对这些策略的支持方案。
3 上下文工程的四大核心策略
3.1 写入上下文（Write Context）
写入上下文指将信息存储在上下文窗口之外，为智能体执行任务提供支持。
3.1.1 草稿本（Scratchpads）
人类解决任务时会记笔记，以便后续相关任务参考，智能体也逐渐具备了这一能力。通过 “草稿本” 记录信息，是智能体在执行任务过程中持久化存储信息的一种方式 —— 核心是将信息保存到上下文窗口之外，确保智能体可随时调用。Anthropic 的多智能体研究工具就是典型案例：
“主研究员（LeadResearcher）首先梳理任务方案，并将其保存到记忆模块（Memory）中以持久化上下文；因为若上下文窗口超过 200,000 令牌，部分内容会被截断，而保留方案至关重要。”
草稿本的实现方式灵活多样：既可以是简单的文件写入的工具调用，也可以是会话期间持续存在的运行时状态对象中的一个字段。无论哪种方式，草稿本都能帮助智能体存储有用信息，助力任务完成。
3.1.2 记忆库（Memories）
草稿本主要用于支持智能体在单个会话（或线程）内完成任务，但有时智能体需要跨多个会话记忆信息！《Reflexion》论文提出了 “每轮智能体交互后进行反思，并复用这些自生成记忆” 的理念；《Generative Agents》则提出定期从过往智能体反馈中合成记忆。
这些理念已落地到多款热门产品中，例如 ChatGPT、Cursor、Windsurf 等，它们均具备基于用户与智能体的交互记录，自动生成跨会话持久化长期记忆的机制。
3.2 筛选上下文（Select Context）
筛选上下文指从外部数据源中提取相关信息，载入上下文窗口以支持智能体执行任务。
3.2.1 从草稿本筛选
从草稿本筛选上下文的方式，取决于草稿本的实现形式：
- 若为工具，智能体可通过工具调用直接读取；
- 若为智能体运行时状态的一部分，开发者可自主选择在每一步向智能体暴露状态中的哪些内容，从而实现对草稿本上下文暴露粒度的精细控制。
3.2.2 从记忆库筛选
智能体既然能存储记忆，就需要具备筛选与当前任务相关记忆的能力。这一功能的价值体现在多个场景：筛选少样本示例（情景记忆）作为期望行为参考、筛选指令（过程记忆）引导行为、筛选事实（语义记忆）提供任务相关上下文。
筛选记忆的核心挑战是确保相关性。部分热门智能体采用 “固定文件集” 策略，始终将特定文件载入上下文 —— 例如，许多代码智能体会通过特定文件存储指令（“过程记忆”）或示例（“情景记忆”）：Claude Code 使用CLAUDE.md文件，Cursor 和 Windsurf 则使用规则文件。
但如果智能体存储了大量事实和 / 或关系数据（如语义记忆），筛选难度会显著增加。ChatGPT 就是典型案例，它需要从海量用户专属记忆中筛选相关信息。
目前，行业常用 “嵌入（Embeddings）和 / 或知识图谱进行记忆索引” 的方式辅助筛选，但记忆筛选仍存在挑战。在 AI 工程师世界博览会上，西蒙・威利森（Simon Willison）分享了一个筛选失效的案例：ChatGPT 从记忆中提取了他的位置信息，并意外注入到用户请求生成的图片中。这种非预期的记忆检索可能让用户感觉 “上下文窗口不再属于自己”！
3.2.3 工具筛选
智能体需要使用工具，但过多工具会导致负载过载 —— 这通常是因为工具描述存在重叠，让模型难以判断该使用哪种工具。解决方案之一是对工具描述 应用检索增强生成（RAG）技术，仅获取与当前任务最相关的工具。近期多项研究表明，这种方法可将工具选择准确率提升 3 倍。
3.2.4 知识筛选
RAG 是一个内涵丰富的领域，也是上下文工程的核心挑战之一。Code Agents是大规模生产环境中应用 RAG 的典范。Windsurf 的瓦伦（Varun）精准概括了其中的难点：
“代码索引≠上下文检索…… 我们正在进行索引和嵌入搜索…… 通过 AST（抽象语法树）解析代码，并按语义相关边界拆分…… 随着代码库规模扩大，嵌入搜索作为检索启发式方法的可靠性会下降…… 我们必须结合多种技术，例如 grep / 文件搜索、基于知识图谱的检索，以及…… 一个重排序步骤 —— 按相关性对 [上下文] 进行排序。”
3.3 压缩上下文（Compress Context）
压缩上下文指仅保留执行任务所需的令牌，剔除冗余信息。
3.3.1 上下文总结（Context Summarization）
智能体交互可能涉及数百轮对话，且工具调用往往消耗大量令牌，而总结是应对这一挑战的常用方法。使用过 Claude Code 的用户可能都体验过这一功能：当上下文窗口使用率超过 95% 时，它会自动触发 “自动压缩（auto-compact）”，总结用户与智能体交互的完整轨迹。这种跨智能体运行轨迹的压缩可采用多种策略，如递归总结或分层总结。
在智能体设计的特定节点添加总结功能也十分有效。例如：
- 对特定工具调用（如消耗大量令牌的搜索工具）的输出进行后处理；
- 如 Cognition 所述，在智能体之间的知识交接环节进行总结，以减少令牌消耗。
但总结也存在挑战：若需要精准捕获特定事件或决策，普通总结可能无法满足需求。Cognition 为此专门使用了微调模型，足见这一步骤需要投入大量精力。
3.3.2 上下文裁剪（Context Trimming）
总结通常利用 LLM 提炼上下文的核心信息，而裁剪则是通过筛选或 “修剪”（如德鲁・布鲁尼格所述）来精简上下文。裁剪可采用硬编码启发式规则（如移除较旧的消息），也可使用专用模型 —— 例如德鲁提到的用于问答任务的训练型上下文修剪工具 Provence。
3.4 隔离上下文（Isolate Context）
隔离上下文指将上下文拆分，以更高效地支持智能体执行任务。
3.4.1 多智能体隔离（Multi-agent）
拆分上下文最流行的方式之一是在子智能体之间分配上下文。OpenAI Swarm 库的设计初衷就是 “职责分离”—— 由一组智能体分别处理特定子任务，每个智能体拥有专属的工具集、指令和上下文窗口。
Anthropic 的multi-agent researcher也印证了这一策略的有效性：多个具备独立上下文的智能体，其性能优于单一智能体 —— 主要因为每个子智能体的上下文窗口可专注于更具体的子任务。正如其博客所述：
“[子智能体] 以并行方式运行，各自拥有独立的上下文窗口，同时探索问题的不同方面。”
当然，多智能体架构也存在挑战：令牌消耗较高（如 Anthropic 报告称，其令牌用量可能达到普通聊天的 15 倍）、需要精心设计提示词以规划子智能体工作、以及子智能体之间的协调问题。
3.4.2 基于环境的上下文隔离（Context Isolation with Environments）
HuggingFace 的deep researcher展示了另一种有趣的上下文隔离方式。大多数智能体使用工具调用 API，返回可传递给工具（如搜索 API）的 JSON 对象（工具参数），进而获取工具反馈（如搜索结果）；而 HuggingFace 采用 CodeAgent，其输出包含所需的工具调用逻辑，代码在沙箱（sandbox）中运行，工具调用的筛选后上下文（如返回值）再传递回 LLM。
这种方式可在环境中实现上下文与 LLM 的隔离。HuggingFace 指出，这对于隔离消耗大量令牌的对象尤为有效：
“[CodeAget] 能更好地处理状态…… 需要存储图片 / 音频 / 其他文件供后续使用？没问题，只需将其赋值给状态中的变量，之后即可调用。”
3.4.3 基于状态的隔离（State-based Isolation）
值得一提的是，智能体的运行时状态对象也是隔离上下文的有效载体，其作用类似于沙箱。可设计带有特定 schema 的状态对象，将上下文写入不同字段：其中一个字段（如messages）可在智能体每一轮交互中暴露给 LLM，而其他字段则可隔离存储信息，供后续选择性使用。
4 LangSmith / LangGraph 的上下文工程实践
如何将上述策略落地？开始前，需具备两项基础能力：
- 数据观测与令牌追踪：了解智能体的数据流和令牌消耗情况，明确上下文工程的优化重点。LangSmith 专为智能体追踪 / 可观测性设计，是实现这一目标的理想工具；
- 性能测试能力：简单高效地验证上下文工程对智能体性能的影响（是提升还是损害）。LangSmith 支持智能体评估，可测试任何上下文工程方案的效果。
4.1 写入上下文支持
LangGraph 原生支持会话级（短期）记忆和长期记忆：
- 短期记忆：通过检查点（checkpointing）功能，持久化存储智能体所有运行步骤的状态，是理想的 “草稿本”—— 可在智能体运行的任意步骤写入和读取信息；
- 长期记忆：支持跨多个智能体会话持久化存储上下文，灵活性强 —— 既可以存储小型文件集（如用户档案、规则文件），也可以存储大规模记忆数据。此外，LangMem 提供了丰富的抽象工具，助力 LangGraph 的记忆管理。
4.2 筛选上下文支持
在 LangGraph 智能体的每个节点（步骤）中，均可调用状态数据，实现对每一步暴露给 LLM 的上下文的精细控制。
此外，LangGraph 的长期记忆可在每个节点中访问，并支持多种检索方式（如文件检索、基于嵌入的记忆集合检索）。关于长期记忆的详细介绍，可参考我们的 Deeplearning.ai 课程；若需针对特定智能体应用记忆功能，可查看 Ambient Agents 课程 —— 该课程展示了如何在管理邮件、从用户反馈中学习的长期运行智能体中，应用 LangGraph 记忆功能。
工具筛选方面，LangGraph Bigtool 库支持对工具描述进行语义搜索，适用于工具数量庞大的场景，可精准筛选与当前任务最相关的工具。此外，我们还提供了多个教程和视频，展示如何在 LangGraph 中应用各类 RAG 技术。
4.3 压缩上下文支持
LangGraph 是低代码编排框架，允许开发者将智能体设计为一组节点，定义每个节点的逻辑，并指定在节点间传递的状态对象。这种高度可控的设计提供了多种上下文压缩方式：
- 常用方案：将消息列表作为智能体状态，利用内置工具定期对其进行总结或裁剪；
- 灵活扩展：可通过多种方式添加上下文压缩逻辑，例如在特定节点添加总结节点，或在工具调用节点中嵌入总结逻辑，以压缩特定工具调用的输出。
4.4 隔离上下文支持
LangGraph 围绕状态对象设计，允许开发者自定义状态 schema，并在智能体每一步访问状态。例如，可将工具调用产生的上下文存储在状态的特定字段中，直至需要时再暴露给 LLM，实现上下文隔离。
除状态外，LangGraph 还支持通过沙箱隔离上下文：
此外，LangGraph 对多智能体架构提供了丰富支持（如管理智能体、Swarm 库），相关详细操作可查看多智能体应用教程视频。
5 总结
上下文工程(Context engineering )已成为智能体构建者必须掌握的核心技能。本文总结了当前主流智能体中常见的四大上下文工程模式：
- 写入上下文：将信息存储在上下文窗口之外，为任务提供支持；
- 筛选上下文：提取相关信息载入上下文窗口，助力任务执行；
- 压缩上下文：仅保留任务必需的令牌，精简上下文规模；
- 隔离上下文：拆分上下文，提升任务处理效率。
LangGraph 简化了这些策略的实现流程，而 LangSmith 则提供了便捷的智能体测试与上下文使用追踪功能。二者结合，形成了一套良性反馈循环：识别上下文工程的优化点→实现优化方案→测试效果→迭代改进，助力开发者构建更高效的智能体系统。
