本文首发【零一探秘公众号】
本文基于 Andrej Karpathy、Anthropic、Cognition 等行业观点，系统梳理了智能体（Agent）上下文工程的三大核心策略及实战经验。适合 AI 产品经理、开发者和对智能体感兴趣的朋友收藏、参考。
一、什么是上下文工程(Context Engineering)
LLM（大型语言模型）就像一种新型操作系统。LLM 相当于 CPU，而其“上下文窗口”则类似于 RAM，代表了模型的“工作内存”。
上下文可以通过多种方式进入 LLM，包括：
- 提示（如用户指令）
- 检索（如外部文档）
- 工具调用（如 API）
然而，和 RAM 一样，LLM 的上下文窗口有带宽和容量限制，无法无限制加载信息。因此，如何像操作系统管理内存一样，科学地“打包”和“管理”上下文，成为智能体开发的关键，这就是“上下文工程”。
二、上下文工程的三大发展阶段
- 提示工程（Prompt Engineering） 随着聊天机器人的兴起，提示工程成为引导 LLM 行为的首要手段。
- 检索增强生成（RAG） 为了让 LLM 连接外部数据源，RAG 作为第二阶段应运而生。
- 智能体与工具调用（Agent + Tool Calls） LLM 工具调用能力提升后，智能体（Agent）通过 LLM 与工具的反复交互，推动了上下文工程进入第三阶段。
Cognition 在构建智能体时强调了上下文工程的重要性：
“上下文工程”……实际上是构建 AI 智能体工程师的头号工作。
Anthropic 也指出：
智能体经常参与持续数百轮的对话，这需要仔细的上下文管理策略。
三、三大上下文工程核心策略
智能体上下文由工具调用的反馈填充，这些反馈可能超过上下文窗口的大小，导致成本和延迟激增。过长的上下文还可能降低智能体性能。Google 和 Percy Liang 的团队描述了不同类型的“上下文退化综合症”，因为过长的上下文会限制 LLM 回忆事实或遵循指令的能力。
有许多方法可以应对这个问题，这里将其分为三类：筛选（curate）、持久化（persist） 和 隔离（isolate）。
1. 筛选上下文（Curating Context）
筛选上下文涉及管理每一轮智能体可见的 token 数量，避免上下文膨胀。
智能体交互可能持续数百轮，还可能有大量 token 的工具调用。上下文摘要是常见的管理方式之一。 例如 Claude Code 在上下文窗口超 95% 时自动“压缩”。
摘要可以用在不同地方，比如对整个智能体轨迹进行递归或分层摘要。
也常常对工具调用反馈（如大量 token 的搜索工具）或特定步骤进行摘要（如 Anthropic 的多智能体研究系统会对已完成的工作阶段应用摘要）。
摘要若需保留特定事件或决策，需用更细致的设计。例如 Cognition 在 Devin 中用微调模型专门处理摘要。
2. 持久化上下文（Persisting Context）
持久化上下文涉及建立系统，长期存储、保存和检索上下文，支撑智能体“记忆”。
存储上下文
文件是存储上下文的简单方式。许多主流智能体采用了这种方式：Claude Code 用 CLAUDE.md，Cursor 和 Windsurf 用规则文件，一些插件（如 Cursor Memory Bank）/ MCP Server管理着一系列内存文件。有些智能体需要存储难以用少量文件捕捉的信息。为此出现了一些工具， Letta、Mem0 和 LangGraph / Mem 存储嵌入文档。Zep 和 Neo4J 用知识图谱对事实或关系进行连续/时序索引。
保存上下文
Claude Code 允许用户手动创建或更新记忆（如 # 快捷键），但许多场景下希望智能体自动完成。Reflexion 论文（arxiv.org/abs/2303.11… ChatGPT、Cursor、Windsurf 等产品采纳，实现自动生成记忆。
记忆也可在特定节点根据用户反馈更新。例如，人工审核工具调用结果并结合记忆更新，可以让智能体持续学习。
检索上下文
最简单的方式是把所有记忆加载进智能体的上下文窗口。例如，Claude Code 每次会读取所有 CLAUDE.md 文件到上下文。但记忆量大时需选择性检索，可用嵌入搜索或图谱检索。
3. 隔离上下文（Isolating Context）
隔离上下文涉及将上下文在不同智能体/环境间分区，优化 token 使用和任务协作。
上下文模式（Schema）
常见做法是用消息结构化智能体上下文。工具反馈会附加到消息列表，完整列表每轮传递给 LLM。
问题是，列表可能因大量 token 的工具调用而膨胀。用结构化的运行时状态（如 Pydantic 模型定义的 schema）往往更高效。这样可以更好地控制每轮 LLM 可见内容。例如，深度研究智能体用 schema 将 messages（每轮传递）与 sections（token 多，按需加载）分离。
多智能体（Multi-agent）
在多智能体系统中，一种常见做法是将任务拆分给多个子智能体，各自有独立上下文和指令。
Anthropic 研究表明：多智能体+隔离上下文的表现比单智能体高出 90.2%，主要归功于 token 使用。正如其在blog中提到的：
“[子智能体] 并行工作，各自拥有自己的上下文窗口，同时探索问题的不同方面。”
多智能体的问题包括 token 消耗（如比聊天多 15 倍）、子智能体规划的提示和上下文设置，以及子智能体协调。Cognition 因此反对多智能体。
一种折中做法是确保任务易于并行。Anthropic 的深度研究多智能体系统就是把并行应用在“研究”上，这比“写作”容易，因为写作需要整体结构连贯。
基于环境的上下文隔离
HuggingFace 的深度研究智能体是上下文隔离的又一例证。大多数智能体用工具调用 API，API 返回 JSON（参数），传递给工具（如搜索 API）获取反馈（如搜索结果）。
HuggingFace 用 CodeAgent 输出代码来调用工具。代码在沙盒中运行，执行反馈再传递给 LLM。
“[编码智能体允许] 更好地处理状态……需要存储图片/音频/其他内容以备后用？没问题，只需赋值给你的状态变量，之后可以随时引用。”
沙盒会存储执行过程中生成的对象（例如图片），将其与 LLM 上下文窗口隔离，但智能体可以用变量随时引用。
经验总结与建议
优先做数据监控：始终关注你的数据。开发智能体时要确保有 token 统计和追踪手段，这能帮助及时发现 token 过度消耗并定位高消耗的工具调用，是一切上下文工程的基础。
关注智能体状态设计：梳理智能体在运行时需要收集和使用的信息，定义良好的状态 schema ，避免无序堆叠消息列表。
在工具调用边界进行筛选： 工具调用是添加筛选的天然节点。比如，可以用小型 LLM 对 token 消耗大的工具调用结果进行摘要，从源头抑制上下文膨胀，无需对整个智能体轨迹做全局压缩。
并行任务可考虑多智能体：在问题易于并行、无需子智能体间紧密协作的场景下，可以考虑采用多智能体方案，正如 Anthropic 的多智能体研究者案例所示。
写在最后
智能体上下文工程还在快速演进。随着 LLM 持续进化，部分上下文工程手段可能会被淘汰。但在现阶段，合理的上下文管理、记忆机制和任务拆分，依然是提升智能体能力的关键。
希望本文能为你的智能体开发和产品设计带来启发！
参考链接：
[1] rlancemartin.github.io/2025/06/23/…
[2] www.anthropic.com/engineering…
[3] huggingface.co/papers/2402…
[4] docs.anthropic.com/en/docs/age…
