Context Engineering 完全指南
2026年1月更新新范式Context Engineering（上下文工程） 不是近年的发明，而是一门已经演进超过 20 年的学科。它超越了单一提示词优化，转向为 LLM 构建完整的动态信息生态系统，确保模型在正确的时间获取正确的信息。
本指南综合了 Anthropic Engineering 系列技术文章与 SII-GAIR 的学术研究 "Context Engineering 2.0: The Context of Context Engineering"。
一、什么是 Context Engineering？
1.1 正式定义
"Context is any information that can be used to characterize the situation of entities that are considered relevant to the interaction between a user and an application."
— Anind K. Dey, 2001
Context Engineering（上下文工程） 是设计和优化上下文收集、存储、管理和使用的系统性过程，以增强机器理解和任务执行能力。
形式化定义：
CE : (C, T) → f_context其中 C 是原始上下文信息，T 是目标任务，f_context 是优化后的上下文处理函数。
1.2 上下文工程的本质：熵减过程
💡 核心洞见
人类之间交流时，听者能够主动减少信息熵——通过共享知识、情感线索和情境意识推断缺失的上下文。机器目前缺乏这种能力。
因此，上下文工程的核心是：将高熵上下文转换为机器可理解的低熵表示所需投入的"努力"。
人类意图（高熵） → 上下文工程 → 机器可理解的表示（低熵）机器越智能，上下文工程就越自然，人机交互成本就越低。
1.3 Context Engineering vs Prompt Engineering
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 定义 | 针对最优结果编写和组织 LLM 指令 | 管理 LLM 推理期间最优 Token 集合的策略 |
| 范围 | 单一提示词 | 完整信息环境（含提示之外的所有信息） |
| 目标 | 单次响应优化 | 跨会话一致性能 |
| 方法 | 文案写作 | 系统架构设计 |
| 组成 | 提示文本 | 系统提示 + 工具 + 示例 + 外部知识 + 会话历史 + 用户配置 |
| 技能类型 | 创意写作 | 软件工程 |
Anthropic 观点
Context engineering 不仅包括 prompt engineering，还包括系统指令中使用的 few-shot 示例、附加的用户背景、检索系统拉取的知识、工具返回的信息，以及模型条件作用的所有其他内容。
二、上下文工程的四个时代
2.1 演进概览
2.2 四个时代详解
| 时代 | 智能水平 | 上下文角色 | 特征 |
|---|---|---|---|
| 1.0 | 被动执行者 | 上下文作为翻译 | 人类将意图翻译为结构化格式 |
| 2.0 | 主动代理 | 上下文作为指令 | 机器理解自然语言，推断隐含意图 |
| 3.0 | 可靠协作者 | 上下文作为场景 | 人机真正自然协作 |
| 4.0 | 体贴的主人 | 上下文作为世界 | AI 主动为人类构建上下文 |
当前位置
我们目前处于 Era 2.0，正在向 Era 3.0 过渡。
2.3 Era 1.0 与 2.0 的对比
| 方面 | Era 1.0 (1990s-2020) | Era 2.0 (2020-现在) |
|---|---|---|
| 技术背景 | 普适计算、情境感知系统、HCI | LLM、Agent、Prompt Engineering |
| 典型系统 | Context Toolkit、Cooltown | ChatGPT、LangChain、AutoGPT、Letta |
| 上下文模态 | 位置、身份、活动、时间、设备状态 | Token 序列、检索文档、工具 API、用户历史 |
| 核心机制 | 传感器融合、规则触发 | Prompting、RAG、CoT、记忆代理 |
| 上下文容忍度 | 相对较低 | 相对较高 |
| 类人程度 | 相对较低 | 相对较高 |
三、上下文的组成部分
3.1 形式化定义
对于给定的用户-应用交互，上下文定义为：
C = ∪ Char(e) , e ∈ E_rel其中 E_rel 是与交互相关的实体集合（用户、应用、环境、工具、记忆模块等），Char(e) 返回表征实体 e 的信息集合。
3.2 完整上下文结构
3.3 多模态上下文收集器
| 类别 | 设备/收集器 | 收集的模态 |
|---|---|---|
| 个人计算 | 智能手机 | 文本、图像、音频、位置、触摸 |
| 电脑 | 文本、图像、按键、光标 | |
| 沉浸技术 | 智能手表 | 心率、运动、音频 |
| AR/VR 头显 | 视频、注视、语音、场景上下文 | |
| 生理感知 | 脑机接口 | 神经信号、情感、认知负荷 |
| 皮肤传感器 | 温度、皮肤电反应 | |
| 环境系统 | 智能家居 IoT | 环境、声音、运动 |
| 在线行为追踪 | 文本、点击流、滚动 |
四、Sessions（会话）
来源
本节内容基于 Google DeepMind 2025 年发布的 Context Engineering: Sessions, Memory 白皮书。
Session（会话） 是上下文工程的基础元素，封装了单个连续对话的即时对话历史和工作记忆。
4.1 Session 的定义
Session 是一个自包含的记录，绑定到特定用户。它允许 Agent 在单个对话范围内维护上下文并提供连贯响应。
工作台类比
Session 就像你正在使用的工作台——堆满了当前项目所需的工具、笔记和参考资料。项目完成后，你不会把整个乱糟糟的桌面塞进仓库，而是选择性地整理归档最关键的文档。
4.2 Session 的两大组成部分
| 组件 | 说明 | 示例 |
|---|---|---|
| Events（事件） | 对话的构建块，按时间顺序记录 | 用户输入、Agent 响应、工具调用、工具输出 |
| State（状态） | 结构化的"工作记忆"或草稿本 | 购物车内容、当前任务进度、用户偏好 |
4.3 Event 类型
| 事件类型 | 说明 |
|---|---|
| 用户输入 | 来自用户的消息（文本、音频、图像等） |
| Agent 响应 | Agent 对用户的回复 |
| 工具调用 | Agent 决定使用外部工具或 API |
| 工具输出 | 工具调用返回的数据，Agent 用于继续推理 |
4.4 Session 持久化
生产环境中，Agent 的执行环境通常是无状态的。对话历史必须保存到持久化存储以维持连续的用户体验：
| 存储方案 | 适用场景 |
|---|---|
| 内存存储 | 开发和测试环境 |
| 托管服务 | 如 Vertex AI Agent Engine Sessions |
| 自托管数据库 | Redis、PostgreSQL、MongoDB 等 |
4.5 长上下文对话的权衡与优化
上下文腐化
随着对话增长，成本和延迟增加，模型可能出现"上下文腐化"——关注关键信息的能力随上下文增长而下降。
| 优化策略 | 说明 |
|---|---|
| Summarization（摘要） | 用摘要替换旧消息 |
| Trimming（裁剪） | 移除旧消息，保留最近的 N 条 |
| Sliding Window（滑动窗口） | 上下文达到限制时丢弃最旧内容 |
| Token-based Cutoff | 达到 Token 阈值时触发压缩 |
五、上下文收集与存储
5.1 指导原则
| 原则 | 说明 |
|---|---|
| 最小充分原则 | 只收集和存储支持任务所需的信息。上下文的价值在于充分性，而非数量 |
| 语义连续性原则 | 上下文的目的是维持意义的连续性，而非仅仅数据的连续性 |
5.2 存储策略
| 存储层 | 用途 | 技术选择 |
|---|---|---|
| 快速缓存 | 短期、频繁访问数据 | 内存缓存、边缘节点 |
| 本地存储 | 中期保留数据 | SQLite、LevelDB、RocksDB |
| 安全存储 | 敏感数据 | OS 钥匙串、HSM |
| 云存储 | 长期持久化、跨设备同步 | 云数据库、远程服务 |
5.3 长期任务的状态持久化
对于长时间运行的 Agent（如 Claude Code），任务可能跨越多个会话：
// 定期将任务状态写入长期记忆
await writeToMemory({
taskId: "project-refactor",
progress: "Completed 3/5 modules",
keyDecisions: [...],
nextSteps: [...]
});
// 恢复时读取
const state = await readFromMemory("project-refactor");结构化笔记示例（Claude Code）：
- 整体目标
- 关键知识
- 文件系统状态
- 最近操作
- 当前计划
六、上下文管理
6.1 文本上下文处理策略
| 策略 | 说明 | 优缺点 |
|---|---|---|
| 时间戳标记 | 为每条信息附加时间戳 | 简单，但缺乏语义结构 |
| 功能语义标签 | 标记为"目标"、"决策"、"行动"等 | 便于检索，但略显刚性 |
| QA 对压缩 | 将上下文重新格式化为问答对 | 检索高效，但破坏原始思路流 |
| 层次化笔记 | 树状结构：概念→子要点 | 呈现清晰，但难以表达因果关系 |
6.2 多模态上下文处理
| 策略 | 说明 |
|---|---|
| 映射到可比较向量空间 | 将不同模态（文本、图像、视频）投影到共享嵌入空间 |
| 组合不同模态进行自注意力 | 模态特定 Token 由单一 Transformer 联合处理 |
| 使用一种模态关注另一种（交叉注意力） | 一种模态的特征作为 Query，另一种作为 Key/Value |
6.3 分层记忆架构
Andrej Karpathy 类比
LLM 可以类比为操作系统：模型像 CPU，上下文窗口像 RAM——快速但容量有限的工作记忆。正如操作系统决定加载什么数据到 RAM，上下文工程决定什么信息应该进入窗口以支持有效推理。
| 记忆类型 | 定义 | 特征 |
|---|---|---|
| 短期记忆 | 高时间相关性的上下文子集 | 快速访问，可能很快变得无关 |
| 长期记忆 | 高重要性、经过处理和抽象的上下文 | 持久化存储，跨会话可用 |
| 记忆转移 | 从短期到长期的巩固过程 | 基于重复频率、情感重要性、与现有知识的相关性 |
6.4 上下文隔离
| 策略 | 说明 |
|---|---|
| 子代理隔离 | 每个子代理有独立的上下文窗口、系统提示和工具权限 |
| 轻量级引用 | 大信息存储在外部，只在模型窗口中暴露轻量级引用 |
| 功能维度分离 | 按功能（分析、执行、验证）或层级（规划、实现、审查）隔离 |
七、上下文抽象与自我构建（Self-Baking）
7.1 什么是 Self-Baking？
Self-Baking 是指 Agent 将原始上下文选择性地消化为持久化知识结构的过程：
原始上下文（对话、工具输出、文档） → Self-Baking → 结构化知识这类似于人类认知过程：情景记忆转化为语义记忆，重复行为抽象为习惯。
关键区别
没有 Self-Baking，Agent 只是回忆；有了 Self-Baking，Agent 能积累知识。
7.2 Self-Baking 策略
| 策略 | 说明 | 示例系统 |
|---|---|---|
| 添加自然语言摘要 | 存储完整上下文，定期生成摘要 | Claude Code、Gemini CLI |
| 使用固定模式提取关键事实 | 将信息提取到预定义格式（实体图、事件记录、任务树） | CodeRabbit |
| 渐进压缩为语义向量 | 将信息编码为密集数值向量 | H-MEM |
| 分层记忆架构 | 原始上下文在底层，逐步向上抽象为更高层表示 | HMT |
CodeRabbit 示例： 在代码审查前构建结构化案例文件，编码跨文件依赖、历史 PR 信息和团队特定规则，使 AI 能够推理完整系统上下文。
八、上下文使用
8.1 上下文选择因素
即使有扩展的上下文窗口，LLM 仍受限于输入 Token 的质量。经验表明，AI 编码性能在上下文窗口超过约 50% 填充时往往下降。
| 因素 | 说明 |
|---|---|
| 语义相关性 | 基于向量相似度选择与当前查询最相关的条目 |
| 逻辑依赖 | 当前任务依赖于之前步骤产生的信息 |
| 时效性与频率 | 最近使用或经常访问的条目更可能再次相关 |
| 信息重叠 | 过滤重复或冗余信息 |
| 用户偏好 | 基于用户交互历史调整权重 |
8.2 跨代理上下文共享
| 模式 | 说明 | 示例系统 |
|---|---|---|
| 嵌入上下文到提示 | 将前一代理的上下文直接包含在下一代理的输入提示中 | AutoGPT、ChatDev |
| 交换结构化消息 | 使用固定格式的结构化消息通信 | Letta、MemOS |
| 共享记忆间接通信 | 代理读写共享记忆空间 | MemGPT、A-MEM |
| 图结构记忆 | 将推理过程表示为任务图或语义图 | TME、G-Memory |
8.3 跨系统上下文共享
| 策略 | 说明 |
|---|---|
| 适配器转换 | 每个系统保持自己的格式，添加转换器 |
| 共享 JSON 模式或 API | 所有系统约定使用相同格式 |
| 自然语言摘要 | 通过人类可读摘要交换上下文 |
| 语义向量表示 | 将上下文表示为语义向量 |
8.4 主动用户需求推断
| 策略 | 说明 |
|---|---|
| 学习用户偏好 | 分析对话历史和存储的个人数据识别模式 |
| 从相关问题推断隐藏目标 | 分析用户查询序列推断更广泛的目标 |
| 基于用户困难主动提供帮助 | 检测用户可能卡住，主动提供有用工具 |
九、新兴工程实践
9.1 KV 缓存优化
| 实践 | 说明 |
|---|---|
| 保持前缀提示稳定 | 微小变化（如在系统提示开头添加时间戳）会使整个缓存失效 |
| 强制仅追加和确定性更新 | 修改或不一致序列化过去内容会破坏复用 |
| 手动插入缓存检查点 | 在服务框架不支持自动增量前缀缓存时 |
| 预热缓存 | 预测性加载（预取或推测加载）可能需要的上下文 |
9.2 工具设计
| 因素 | 说明 |
|---|---|
| 精确描述 | 模糊或重叠的描述常导致失败，结构良好的描述减少歧义 |
| 控制规模 | 过多工具使 Agent 不可靠；DeepSeek-v3 在超过 30 个工具时性能下降，超过 100 个几乎必然失败 |
| 保持工具列表稳定 | 动态加载工具常破坏 KV 缓存一致性 |
| 解码层面约束 | 通过遮蔽 Token logits 阻止无效选择 |
9.3 上下文内容管理
| 实践 | 说明 |
|---|---|
| 保留错误 | 不要隐藏 Agent 的错误；保留错误允许模型观察失败，对学习纠正行为至关重要 |
| 避免重复模式 | 传统 few-shot 在 Agent 设置中可能适得其反；Manus 引入小的结构化变化来打破重复模式 |
| 维护 todo.md | 定期更新任务列表，并在更新时用自然语言复述目标 |
9.4 多代理系统
| 实践 | 说明 |
|---|---|
| 明确任务分配 | 包含清晰目标、输出、工具指导和边界 |
| 调整规则 | 根据查询复杂度调整代理数量 |
| 搜索策略 | 从广泛探索到聚焦分析 |
| 扩展思考模式 | 代理显式写下推理过程提高准确性 |
十、上下文腐化与长时间任务挑战
10.1 上下文腐化（Context Rot）
警告
在多步骤交互中，污染物会在上下文中累积。模型开始偏离目标、重复自己，或做出越来越差的决策。 — Anthropic
随着 Agent-环境交互的积累，原本干净的上下文会逐渐被不相关信息、过时内容、矛盾指令污染。
10.2 长时间任务挑战
| 挑战 | 说明 |
|---|---|
| 存储瓶颈 | 如何在严格资源约束下保留尽可能多的相关上下文 |
| 处理退化 | Transformer 的 O(n²) 复杂度导致效率和理解质量下降 |
| 系统不稳定 | 随着记忆累积，小错误可能影响更多系统部分 |
| 评估困难 | 大多数基准只测试检索，不检查信息是否仍然相关、准确或有帮助 |
10.3 解决策略
| 策略 | 说明 |
|---|---|
| Compaction（压缩） | Claude Agent SDK 在上下文过长时自动压缩对话，保持重点同时保留关键细节 |
| Structured Note-taking（结构化笔记） | 定期将关键信息写出上下文窗口到外部记忆，需要时检索 |
| Sub-agent Architectures（子代理架构） | 将复杂任务分解给专门的子代理，每个有自己的聚焦上下文 |
十一、应用场景
11.1 CLI Agent（如 Gemini CLI）
上下文组织：
GEMINI.md文件记录项目背景、角色定义、工具依赖、编码规范- 通过文件系统层级实现继承和隔离
- 启动时加载静态信息，交互时增量积累动态上下文
上下文压缩：
- 用 AI 生成的摘要替换长交互历史
- 遵循预定义格式保留关键方面
11.2 深度研究 Agent
Tongyi DeepResearch 流程：
- 基于用户查询搜索网络
- 从相关页面提取关键信息
- 生成新子问题指导进一步搜索
- 整合多来源证据为连贯答案
上下文工程：
- 定期调用专门的摘要模型压缩累积历史
- 生成"上下文快照"保留关键证据并突出缺失信息
- 后续推理基于压缩快照而非完整原始历史
11.3 脑机接口
BCI 为上下文工程提供新途径：
- 更丰富的上下文维度：注意力水平、情感状态、认知负荷
- 更便捷的收集方式：减少显式用户操作，通过神经活动实现更即时的输入
十二、未来方向：语义操作系统
12.1 核心挑战
终身上下文工程的挑战不能仅通过"扩展上下文窗口"或"提高检索准确性"来解决。它需要构建一个能够像人类思维一样随时间成长的语义操作系统。
12.2 设计要求
| 要求 | 说明 |
|---|---|
| 大规模语义存储 | 作为自己的记忆库，支持高效存储 |
| 人类级记忆管理 | 主动添加、修改和遗忘知识 |
| 新架构 | 替代 Transformer 的平面时间建模，实现更强的远程上下文推理 |
| 可解释能力 | 追踪、纠正和解释推理链中的每一步 |
12.3 范式转变
核心原则
上下文不再是被动累积的，而是作为认知的核心元素被主动管理和演化。
这反映了一个根本性的范式转变：从数据存储到知识学习。
十三、工具与框架
13.1 上下文工程相关工具
| 工具/框架 | 用途 |
|---|---|
| LangChain | RAG、记忆、工具集成、上下文管道 |
| LlamaIndex | 文档索引与检索 |
| MCP | 标准化外部系统连接 |
| Letta | 记忆增强 LLM 代理 |
| MemOS | LLM 记忆操作系统 |
| Pinecone/Weaviate | 向量数据库 |
| Redis | 会话状态存储 |
13.2 2025-2026 趋势
| 趋势 | 说明 |
|---|---|
| 更大上下文窗口 | Claude 4.5 支持 100万 Token |
| 上下文缓存 | 重复上下文复用，降低成本 |
| 多模态上下文 | 图像、音频、视频作为上下文 |
| MCP 普及 | 标准化工具和数据连接 |
| 自适应上下文 | AI 自主决定需要什么上下文 |
| 终身上下文 | 跨会话、跨任务的持续上下文积累 |
十四、总结
从 Era 1.0 到 Era 4.0
核心要点
| 要点 | 说明 |
|---|---|
| 🎯 熵减本质 | 将高熵意图转换为低熵机器表示 |
| 📐 系统架构 | 收集 → 存储 → 管理 → 使用的完整管道 |
| 🧠 Self-Baking | 从存储记忆升级为积累知识 |
| 🔄 动态管理 | 主动管理上下文，而非被动累积 |
| 📊 分层记忆 | 短期/长期，按时效性和重要性组织 |
| 🛡️ 抗腐化 | 应对长时间任务中的上下文污染 |
"A person is the sum of their contexts."
随着机器智能逐渐接近并可能超越人类认知，AI 系统可能不仅理解我们，还能照亮和扩展我们对自己的理解。
📚 推荐阅读
- Effective context engineering for AI agents — Anthropic 对上下文工程的核心阐述
- Context Engineering 2.0 — SII-GAIR 学术论文，四个时代演进与理论框架
- Effective harnesses for long-running agents — 长时间运行 Agent 的上下文管理
更多文章参见 Anthropic Engineering 文章合集。