内容概览
智能体执行任务离不开 上下文。上下文工程(Context Engineering)既是一门艺术,也是一门科学,其核心在于,在智能体运行轨迹的每个步骤中,精准地将恰好适量的信息注入其上下文窗口。本文将通过回顾多个热门智能体实例及相关研究论文,解构上下文工程的四大核心策略——“保存、筛选、压缩、隔离”,并深入探讨 LangGraph 如何为这些策略提供强大支持!
上下文工程概览
正如安德烈・卡帕西(Andrej Karpathy)所言,大语言模型(Large Language Models - LLMs) 可视为一种新型操作系统。LLMs 本身如同 中央处理器 (CPU),而其 上下文窗口 (Context Window) 则类似 随机存取存储器 (RAM - Random Access Memory),充当模型的工作内存。如同 RAM 容量有限且需选择性加载数据一样,上下文窗口也有其大小限制。操作系统会精心管理加载到 RAM 中的内容;与之类似,我们可以将上下文工程视为在模型工作内存中进行精细管理的角色。卡帕西对此做出了精辟总结:
“上下文工程是一门精妙的艺术和科学,目标是在上下文窗口中为下一步操作填充恰好适量的信息。”
LLM 应用中的常见上下文类型
在构建 LLM 应用时,我们需要管理哪些类型的上下文呢?上下文工程作为一个宽泛概念,适用于以下几种主要的上下文类型:
• 指令 (Instructions):提示词(Prompts)、内存信息、少样本示例(Few-shot Examples)、工具描述等。
• 知识 (Knowledge):事实(Facts)、存储的信息等。
• 工具反馈 (Tool Feedback):工具调用后返回的信息。
智能体的上下文工程策略
随着 LLM 在推理和工具调用方面的能力持续提升,人们对智能体 (Agents) 的兴趣在(2025)年激增。智能体通过交替执行 LLM 调用 和 工具调用 (Tool Calls),通常用于处理长期运行的任务。它们会利用工具反馈 (Tool Feedback) 来决定后续的操作步骤。
然而,长期任务与不断累积的工具反馈通常意味着智能体会消耗大量 令牌 (Tokens)。这可能导致诸多问题:超出上下文窗口限制、增加成本/延迟,甚至降低智能体的性能。德鲁・布罗伊尼格(Drew Breunig)清晰地概述了过长的上下文可能导致的性能问题:
• 上下文污染 (Context Contamination):当幻觉信息混入上下文时。
• 上下文干扰 (Context Distraction):当信息过多超出模型的训练理解范围时。
• 上下文混淆 (Context Confusion):当冗余信息干扰决策时。
• 上下文冲突 (Context Conflict):当上下文内容相互矛盾时。
鉴于这些挑战,Cognition 公司指出了上下文工程的关键性:
“上下文工程” 实际上是构建 AI 智能体工程师的首要任务。
Anthropic 公司也明确强调:
智能体通常需要处理数百轮的对话,这要求精心设计的上下文管理策略。
那么,业界如何应对这一挑战?我们将当前智能体上下文工程的常见策略归纳为四类:写入 (write)、筛选 (Select)、压缩 (Compress) 和隔离 (Isolate),并通过热门智能体产品和研究论文举例说明。最后,我们将探讨 LangGraph 如何赋能这些策略!
核心策略一:写入上下文
保存上下文指将信息存储到上下文窗口之外,辅助智能体完成后续任务。
草稿本/暂存区 (Scratchpad)
人类在解决问题时会做笔记并记住信息以供未来相关任务参考。智能体也正逐步获得类似能力!通过“草稿本/暂存区”(Scratchpad)做笔记,是智能体在执行任务时持久化信息的一种方式,便于后续调用。Anthropic 的多智能体研究提供了一个清晰的例子:
首席研究员先制定解决方案计划,并将其保存到内存(Memory)中以实现持久化。因为超过 200,000 令牌的上下文会被截断,而保留该计划至关重要。
草稿本的实现方式多样:可以是写入文件的工具调用;也可以是运行时状态对象中的一个字段,在会话期间持久化。无论采用哪种方式,草稿本都能帮助智能体保存对完成任务有益的信息。
长期记忆 (Long-term Memory)
草稿本有助于智能体在特定会话(或线程) 中解决问题,但有时智能体也需要在多个会话中记住重要信息!Reflexion 论文提出了在每次智能体轮次后进行反思 (Reflection) 并复用这些自生成记忆的思想。生成式智能体会定期从过往的智能体反馈集合中合成记忆 (Synthesizing Memories)。
LLM 可用于更新或创建记忆
这一概念已被 ChatGPT、Cursor 和 Windsurf 等热门产品应用。这些产品都具备基于用户与智能体的交互,自动生成可跨会话持久化的长期记忆 (Long-term Memory) 的机制。
核心策略二:筛选上下文
筛选上下文指将特定信息拉入上下文窗口,以协助智能体完成当前任务。
从草稿本中筛选
筛选草稿本信息的方式取决于其实现。如果是工具调用,智能体可通过调用读取工具来获取内容;如果是智能体运行时状态的一部分,开发人员则可精细控制在后续轮次中向 LLM 展示状态的哪些部分。
从记忆中筛选
智能体若具备存储记忆的能力,也需要具备筛选与当前任务相关记忆的能力。这在多方面至关重要:智能体可选择少样本示例(情景记忆 - Episodic Memory) 作为期望行为的范例;选择指令(程序记忆 - Procedural Memory) 引导行为;或选择事实(语义记忆 - Semantic Memory) 作为相关上下文。
挑战在于确保筛选的记忆具有相关性。一些流行智能体仅固定拉取一小部分文件。例如,许多代码智能体会使用特定文件保存指令(程序记忆),或在某些情况下保存示例(情景记忆)。Claude Code 使用 CLAUDE.md
;Cursor 和 Windsurf 则使用规则文件。
然而,如果智能体存储了大量事实和/或关系集合(例如,语义记忆),筛选挑战会显著增加。ChatGPT 是一个典型例子,它能存储并从海量的用户特定记忆中进行筛选。
嵌入(Embedding) 和/或 知识图谱(Knowledge Graph) 常用于记忆索引(Memory Indexing) 以辅助筛选。尽管如此,记忆筛选仍非易事。在人工智能工程师世界博览会(AI Engineer World’s Fair)上,西蒙・威利森(Simon Willison)分享了一个筛选失误的案例:ChatGPT 从其记忆中获取了他的位置信息,却意外将其注入到图像请求中。这种意外或不期望的记忆提取,可能会让用户觉得上下文窗口“不再专属”!
筛选工具
智能体依赖工具,但过多的工具选项可能导致负担。通常是由于工具描述重叠,引发模型在选择时的困惑。一种解决方法是对工具描述(Tool Descriptions) 应用 检索增强生成(Retrieval-Augmented Generation - RAG),仅获取与当前任务最相关的工具。近期研究论文表明,这可以将工具选择的准确性提高三倍。
筛选知识
检索增强生成(RAG) 本身就是一个重要的上下文工程挑战领域。代码智能体是 RAG 应用于大规模生产的优秀范例。来自 Windsurf 的瓦伦(Vaibhav)精辟地总结了相关挑战:
索引代码 ≠ 上下文检索…我们通过抽象语法树(Abstract Syntax Tree - AST) 解析代码,并沿着语义边界(Semantic Boundaries) 进行分块(Chunking)… 随着代码库规模增长,仅依赖嵌入搜索(Embedding Search) 作为检索启发式方法(Heuristic)变得不可靠…我们必须组合多种技术,如 grep / 文件搜索、基于知识图谱的检索,以及一个重排序(Re-ranking)步骤(其中 [检索到的] 上下文根据相关性排序)。
核心策略三:压缩上下文
压缩上下文旨在仅保留执行当前任务必需的令牌。
上下文总结
智能体的交互可能跨越数百轮次,并消耗大量令牌用于工具反馈。总结(Summarization) 是应对此挑战的常用策略。Claude Code 用户可能已经见过实际应用:当上下文窗口利用率超过 95% 时,它会自动运行“压缩”,对整个用户与智能体的交互轨迹进行总结。可以在智能体轨迹中应用各种总结策略(如递归或分层总结)。
总结可应用的几个关键点
在智能体设计的特定节点添加总结非常有用,例如,对产生大量令牌的工具调用(如搜索结果)进行后处理(Post-processing);又如,Cognition 公司提到在智能体间信息传递的边界进行总结,以减少令牌数量。若需要保留特定事件或决策细节,总结会面临挑战。为此,Cognition 公司采用了微调模型(Fine-tuned Model),这凸显了实现这一步骤所需的付出。
上下文裁剪
总结通常借助 LLM 提取核心信息,而裁剪(Pruning) 则侧重于过滤或 “修剪(Pruning)” 上下文。可采取基于规则的启发式方法(Heuristics),例如删除较早的历史消息。德鲁・布罗伊尼格(Drew Breunig)还提到了 Provence(一个用于问答的、经过训练的上下文修剪器)。
核心策略四:隔离上下文
隔离上下文是指将上下文进行分割,以帮助智能体专注于特定任务。
多智能体系统
隔离上下文最流行的方法之一是采用多智能体系统(Multi-Agent System),在不同子智能体之间分配上下文。OpenAI 的 Swarm 库的一个核心理念就是关注点分离(Separation of Concerns):一组智能体负责特定的子任务,每个智能体拥有专属的工具集、指令集以及自己独立的上下文窗口。
在多个智能体之间分割上下文
Anthropic 的多智能体研究为此提供了理由:具备隔离上下文的多个智能体协同工作,通常优于单个智能体。这很大程度上源于每个子智能体的上下文窗口能专注于更窄的子任务。正如其博客所述:
[子智能体] 并行运行(Parallel Execution),各自拥有独立的上下文窗口,同时探索问题的不同侧面。
当然,多智能体也有其挑战,包括令牌消耗增加(如 Anthropic 报告,相比普通聊天模式可高出 15 倍)、需要精心的提示词工程(Prompt Engineering) 来规划子智能体工作,以及子智能体之间的协调(Coordination)。
与模型隔离的环境上下文
Hugging Face 的研究员提出了另一个巧妙的上下文隔离示例。多数智能体使用工具调用 API,返回的 JSON 对象(包含工具参数)会被传递给实际工具(如搜索 API)以获取工具反馈(如搜索结果)。Hugging Face 采用 CodeAgent,其输出直接包含待执行的工具调用代码。该代码在沙箱(Sandbox) 环境中运行,工具调用的结果上下文(例如返回值)随后传回 LLM。
沙箱可以将运行环境上下文与 LLM 隔离,这使得运行环境中的上下文(尤其是大体积对象)能与 LLM 核心处理隔离。
智能体状态
值得一提的是,智能体的 运行时状态对象(Runtime State Object) 本身也是隔离上下文的有效方式。它可以起到类似沙箱的作用。开发者可以设计一个包含字段的模式,其中某些字段(例如 messages
)会在每个轮次展现给 LLM,而其他字段则隔离信息,仅在被显式调用时使用。
利用 LangSmith / LangGraph 实现上下文工程
如何实践上述策略?有两个基础准备非常关键。首先,拥有监控数据和追踪智能体令牌使用情况的能力,这有助于识别应用上下文工程的最佳位置。LangSmith 是智能体追踪(追踪/可观测性 Tracing/Observability)的理想工具。其次,需要一种简便的方法来测试上下文工程策略对智能体性能的影响。LangSmith 支持智能体评估(Agent Evaluation),可用来衡量相关工作的效果。
保存上下文
LangGraph 在设计之初就考虑了线程范围(Thread Scope) 的(短期)记忆和长期记忆(Long-term Memory)。其检查点(Checkpoint) 机制可持久化智能体在每一步的状态,这相当于一个“草稿本/暂存区”,允许您在智能体运行轨迹的任意步骤写入或读取状态信息。
LangGraph 的长期记忆机制支持在多个智能体会话间持久化上下文。它灵活性强,可用于保存少量文件(如用户配置文件或规则)或大型的记忆集合。此外,LangMem 提供了丰富的抽象,极大简化了 LangGraph 记忆管理的复杂性。
筛选上下文
在 LangGraph 智能体的每个节点(Node)(即执行步骤)中,您都可以访问当前状态。这使您能够在智能体的每个步骤中,精细控制呈现给 LLM 的具体上下文内容。
此外,LangGraph 的长期记忆在每个节点中都可访问,并支持多种检索(Retrieval) 类型(如获取特定文件、基于嵌入的记忆集合查询)
对于工具选择,LangGraph Bigtool 库提供了对工具描述进行语义搜索(Semantic Search) 的出色方案。这在管理大型工具集时,助力筛选与任务最相关的工具。
压缩上下文
LangGraph 作为底层的编排框架(Orchestration Framework),允许您将智能体设计为一组节点,定义每个节点内部的逻辑,并制定节点间传递的状态对象。这种高度可控性为实现上下文压缩提供了多种途径。
一种常见做法是将消息列表作为智能体状态,利用内置功能(如 StateGraph 的内置机制或特定节点)对其进行周期性总结或修剪。此外,您也可以在特定位置(如工具调用节点内部或轮次衔接处)添加逻辑,对工具反馈或智能体工作阶段进行后处理(Post-processing):例如,增设专门的总结节点,或在工具调用逻辑内添加总结步骤以压缩其输出。
隔离上下文
LangGraph 围绕状态对象(State Object)设计,允许您指定状态模式(Schema)并在每一步访问该状态。例如,您可以将工具调用的详细上下文(如大型 JSON 对象或二进制数据)存储在状态的某些特定字段中,使其与 LLM 隔离,直到后续步骤真正需要使用时才引入。
结尾
上下文工程已成为智能体构建者亟需掌握的核心技能。本文介绍了当今众多热门智能体中普遍应用的四大策略:
• 保存上下文:将信息存储到上下文窗口之外,供智能体后续任务使用。
• 筛选上下文:将相关信息拉入上下文窗口,辅助智能体进行当前任务。
• 压缩上下文:通过总结或裁剪,仅保留任务所需的核心令牌。
• 隔离上下文:通过多智能体、沙箱或状态管理进行上下文分割。
LangGraph 使实施上述策略变得便捷高效,而 LangSmith 则提供了一套强大的工具,用于测试智能体和追踪上下文使用情况。两者协同形成了一个良性反馈循环:LangSmith 帮助识别应用上下文工程的最佳点 -> LangGraph 实现策略 -> LangSmith 评估效果 -> 不断优化迭代。
如何学习大模型 AI ?
由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。
但是具体到个人,只能说是:
“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。
这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。
我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段(10天):初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么?
- 大模型是怎样获得「智能」的?
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例:向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段(30天):高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示(Embeddings)
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段(30天):模型训练
恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。
到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2:手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段(20天):商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身:基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例:如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。
如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。