Context Engineering 完全指南
Context Engineering新范式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 阈值时触发压缩 |
五、四大核心技术体系（基于 LangChain 框架）
业界实际落地 Agent 时，对于 Context 的调度实现通常被划分为四大核心技术策略（以 LangChain 设计框架为代表）。这四项技术不仅能够最大化模型的使用效率，更是解决大语言模型 Token 调用成本、降低干扰的关键点。
5.1 保存（Save Context）
不仅是即时的交互记录，还需要对产生的上下文进行筛选和总结并持久化（如内存、高速缓存或数据库中）。
- 典型表现：ChatGPT 的 Memory 功能。在使用聊天时，它会识别并触发
Update saved memory，将关于用户的核心事实存入记忆库，未来对话随时唤起。这也是上下文工程持久化的基本盘。
5.2 选择（Select Context）
把所有相关资料不加筛选丢给模型会导致杂乱、矛盾和昂贵的成本。最核心的策略是“按需选择”。
- 静态选择：永远重要、每次执行都必须遵守的核心信息。如 Cursor 的
.cursorrules或 Claude Code 的claude.md，用于硬性规定项目背景和代码规范。它像 AI 脑中的核心系统指令。 - 动态选择：根据当前任务“精准提取”那几页需要的资料。例如在庞大的可用工具库中只选取最相关的 3 个工具组装进 Context；或最为人熟知的 RAG (检索增强生成) 技术。
5.3 压缩（Compress Context）
当 Agent 运行时间拉长，它的反馈、工具调用和读取的代码文件极易“撑爆”或挤满上下文窗口，从而显著降低长期表现。
- 防爆机制：以 Claude Code 为例，它设计了
Auto Compact机制。当 Context 上下文余量不足（如到达 95%）时，它会主动发起总结任务，基于对话提炼关键信息，进而丢弃原始冗长数据并有效降载。用户甚至可以调整策略要求“压缩时必须保留测试日志和代码改版记录”。
5.3.1 分级压缩：按「信息损失 × 调用成本」排序
「压缩」不是一个动作，而是一条降级流水线。直接让模型总结整段历史确实能大幅缩短上下文，但它同时付出两项代价：摘要必然丢细节，且多一次模型调用。因此正确的顺序是先做免费且可恢复的操作，最后才做花钱且有损的：
| 顺序 | 步骤 | 触发条件 | 做什么 | 代价 |
|---|---|---|---|---|
| 1 | 大结果转存 | 单批工具结果超过阈值 | 超大结果写入磁盘，上下文里只留文件路径 + 前若干字符预览 | 无 API 调用，完全可恢复 |
| 2 | 旧消息归档 | 消息条数超过阈值 | 全量写入归档文件，只保留最初几条 + 最近若干条，中间插入标记说明归档位置 | 无 API 调用，可从归档恢复 |
| 3 | 旧结果占位 | — | 最近几条工具结果保持完整，更早且较长的替换为占位符（已转存的保留路径） | 无 API 调用 |
| 4 | 历史摘要 | 前三步后仍超阈值 | 请模型生成只含事实的状态摘要，替换历史 | 一次额外 API 调用，有损 |
为什么工具结果优先处理：大文件可以重新读取、旧命令可以重新执行、最新结果比早期结果更贴近当前工作——它们天然比对话本身更适合被裁剪，且裁剪是可逆的。
5.3.2 三个必须守住的工程细节
⚠️ 切点必须保护「工具调用—结果」的配对
裁剪历史时，assistant(tool_use) 和它对应的 user(tool_result) 必须同进同退。留下孤立的工具结果会让下一次 API 请求直接判定为无效——这是自建压缩逻辑最常见的崩溃原因。
实现上要在计算切点后做一次校正：若切点落在配对中间，向前或向后移动直到配对完整。
2. 当前请求要单独传递。 工具结果通常也用 role=user 承载，因此压缩时无法从消息里可靠识别「本轮用户请求」。正确做法是在入口处就把它捕获并作为独立参数带进压缩流程，摘要中明确区分「当前请求」与「历史摘要」两块。否则压几次之后，Agent 会忘记自己正在做什么。
3. 模型主动请求压缩时，必须先补齐本轮所有工具结果。 一次响应可能同时包含「写文件」和「请求压缩」两个调用。若立即压缩，会留下孤立结果，或丢失已发生的副作用记录——导致模型重复执行同一次写入。正确顺序是：执行完整批工具 → 为每个 tool_use 补上 tool_result → 再压缩这个已闭合的回合。
5.3.3 兜底：字符估算不等于 token
用字符数估算上下文大小既快又免费，但它只是近似——API 仍可能返回「超长」错误。因此需要一层被动补救：捕获该错误后立即摘要较早历史、只保留最近几条消息，然后重试。
关键是限制补救次数（通常一次）。若补救后仍失败，应当抛出而非无限重试——否则会陷入「压缩→失败→再压缩」的死循环。
5.4 隔离（Isolate Context）
复杂任务中如果将所有的运行历史丢入同一个上下文池，极易产生互串和幻觉。上下文隔离主要应用于 Multi-Agent 架构 中。
- 分治策略：在 Anthropic 的研究型多智能体系统中，总指挥 (Lead Agent) 只负责协调派发和归纳，它调用的诸多子智能体 (Sub Agents，如专属于查 PDF、搜索网络) 各自拥有独立的记忆流、工具集。由于 Context 物理隔离互不干扰，整体推理路径极其清晰准确。
六、上下文收集与存储
6.1 指导原则
| 原则 | 说明 |
|---|---|
| 最小充分原则 | 只收集和存储支持任务所需的信息。上下文的价值在于充分性，而非数量 |
| 语义连续性原则 | 上下文的目的是维持意义的连续性，而非仅仅数据的连续性 |
6.2 存储策略
| 存储层 | 用途 | 技术选择 |
|---|---|---|
| 快速缓存 | 短期、频繁访问数据 | 内存缓存、边缘节点 |
| 本地存储 | 中期保留数据 | SQLite、LevelDB、RocksDB |
| 安全存储 | 敏感数据 | OS 钥匙串、HSM |
| 云存储 | 长期持久化、跨设备同步 | 云数据库、远程服务 |
6.3 长期任务的状态持久化
对于长时间运行的 Agent（如 Claude Code），任务可能跨越多个会话：
// 定期将任务状态写入长期记忆
await writeToMemory({
taskId: "project-refactor",
progress: "Completed 3/5 modules",
keyDecisions: [...],
nextSteps: [...]
});
// 恢复时读取
const state = await readFromMemory("project-refactor");结构化笔记示例（Claude Code）：
- 整体目标
- 关键知识
- 文件系统状态
- 最近操作
- 当前计划
七、上下文管理
7.1 文本上下文处理策略
| 策略 | 说明 | 优缺点 |
|---|---|---|
| 时间戳标记 | 为每条信息附加时间戳 | 简单，但缺乏语义结构 |
| 功能语义标签 | 标记为"目标"、"决策"、"行动"等 | 便于检索，但略显刚性 |
| QA 对压缩 | 将上下文重新格式化为问答对 | 检索高效，但破坏原始思路流 |
| 层次化笔记 | 树状结构：概念→子要点 | 呈现清晰，但难以表达因果关系 |
7.2 多模态上下文处理
| 策略 | 说明 |
|---|---|
| 映射到可比较向量空间 | 将不同模态（文本、图像、视频）投影到共享嵌入空间 |
| 组合不同模态进行自注意力 | 模态特定 Token 由单一 Transformer 联合处理 |
| 使用一种模态关注另一种（交叉注意力） | 一种模态的特征作为 Query，另一种作为 Key/Value |
7.3 分层记忆架构
Andrej Karpathy 类比
LLM 可以类比为操作系统：模型像 CPU，上下文窗口像 RAM——快速但容量有限的工作记忆。正如操作系统决定加载什么数据到 RAM，上下文工程决定什么信息应该进入窗口以支持有效推理。
| 记忆类型 | 定义 | 特征 |
|---|---|---|
| 短期记忆 | 高时间相关性的上下文子集 | 快速访问，可能很快变得无关 |
| 长期记忆 | 高重要性、经过处理和抽象的上下文 | 持久化存储，跨会话可用 |
| 记忆转移 | 从短期到长期的巩固过程 | 基于重复频率、情感重要性、与现有知识的相关性 |
7.4 上下文隔离
| 策略 | 说明 |
|---|---|
| 子代理隔离 | 每个子代理有独立的上下文窗口、系统提示和工具权限 |
| 轻量级引用 | 大信息存储在外部，只在模型窗口中暴露轻量级引用 |
| 功能维度分离 | 按功能（分析、执行、验证）或层级（规划、实现、审查）隔离 |
八、上下文抽象与自我构建（Self-Baking）
8.1 什么是 Self-Baking？
Self-Baking 是指 Agent 将原始上下文选择性地消化为持久化知识结构的过程：
原始上下文（对话、工具输出、文档） → Self-Baking → 结构化知识这类似于人类认知过程：情景记忆转化为语义记忆，重复行为抽象为习惯。
关键区别
没有 Self-Baking，Agent 只是回忆；有了 Self-Baking，Agent 能积累知识。
8.2 Self-Baking 策略
| 策略 | 说明 | 示例系统 |
|---|---|---|
| 添加自然语言摘要 | 存储完整上下文，定期生成摘要 | Claude Code、Gemini CLI |
| 使用固定模式提取关键事实 | 将信息提取到预定义格式（实体图、事件记录、任务树） | CodeRabbit |
| 渐进压缩为语义向量 | 将信息编码为密集数值向量 | H-MEM |
| 分层记忆架构 | 原始上下文在底层，逐步向上抽象为更高层表示 | HMT |
CodeRabbit 示例： 在代码审查前构建结构化案例文件，编码跨文件依赖、历史 PR 信息和团队特定规则，使 AI 能够推理完整系统上下文。
九、上下文使用
9.1 上下文选择因素
即使有扩展的上下文窗口，LLM 仍受限于输入 Token 的质量。经验表明，AI 编码性能在上下文窗口超过约 50% 填充时往往下降。
| 因素 | 说明 |
|---|---|
| 语义相关性 | 基于向量相似度选择与当前查询最相关的条目 |
| 逻辑依赖 | 当前任务依赖于之前步骤产生的信息 |
| 时效性与频率 | 最近使用或经常访问的条目更可能再次相关 |
| 信息重叠 | 过滤重复或冗余信息 |
| 用户偏好 | 基于用户交互历史调整权重 |
9.2 跨代理上下文共享
| 模式 | 说明 | 示例系统 |
|---|---|---|
| 嵌入上下文到提示 | 将前一代理的上下文直接包含在下一代理的输入提示中 | AutoGPT、ChatDev |
| 交换结构化消息 | 使用固定格式的结构化消息通信 | Letta、MemOS |
| 共享记忆间接通信 | 代理读写共享记忆空间 | MemGPT、A-MEM |
| 图结构记忆 | 将推理过程表示为任务图或语义图 | TME、G-Memory |
9.3 跨系统上下文共享
| 策略 | 说明 |
|---|---|
| 适配器转换 | 每个系统保持自己的格式，添加转换器 |
| 共享 JSON 模式或 API | 所有系统约定使用相同格式 |
| 自然语言摘要 | 通过人类可读摘要交换上下文 |
| 语义向量表示 | 将上下文表示为语义向量 |
9.4 主动用户需求推断
| 策略 | 说明 |
|---|---|
| 学习用户偏好 | 分析对话历史和存储的个人数据识别模式 |
| 从相关问题推断隐藏目标 | 分析用户查询序列推断更广泛的目标 |
| 基于用户困难主动提供帮助 | 检测用户可能卡住，主动提供有用工具 |
十、新兴工程实践
10.1 KV 缓存优化
| 实践 | 说明 |
|---|---|
| 保持前缀提示稳定 | 微小变化（如在系统提示开头添加时间戳）会使整个缓存失效 |
| 强制仅追加和确定性更新 | 修改或不一致序列化过去内容会破坏复用 |
| 手动插入缓存检查点 | 在服务框架不支持自动增量前缀缓存时 |
| 预热缓存 | 预测性加载（预取或推测加载）可能需要的上下文 |
10.2 工具设计
| 因素 | 说明 |
|---|---|
| 精确描述 | 模糊或重叠的描述常导致失败，结构良好的描述减少歧义 |
| 控制规模 | 过多工具使 Agent 不可靠；DeepSeek-v3 在超过 30 个工具时性能下降，超过 100 个几乎必然失败 |
| 保持工具列表稳定 | 动态加载工具常破坏 KV 缓存一致性 |
| 解码层面约束 | 通过遮蔽 Token logits 阻止无效选择 |
10.3 上下文内容管理
| 实践 | 说明 |
|---|---|
| 保留错误 | 不要隐藏 Agent 的错误；保留错误允许模型观察失败，对学习纠正行为至关重要 |
| 避免重复模式 | 传统 few-shot 在 Agent 设置中可能适得其反；Manus 引入小的结构化变化来打破重复模式 |
| 维护 todo.md | 定期更新任务列表，并在更新时用自然语言复述目标 |
10.4 多代理系统
| 实践 | 说明 |
|---|---|
| 明确任务分配 | 包含清晰目标、输出、工具指导和边界 |
| 调整规则 | 根据查询复杂度调整代理数量 |
| 搜索策略 | 从广泛探索到聚焦分析 |
| 扩展思考模式 | 代理显式写下推理过程提高准确性 |
十一、上下文腐化与长时间任务挑战
11.1 上下文腐化（Context Rot）
警告
在多步骤交互中，污染物会在上下文中累积。模型开始偏离目标、重复自己，或做出越来越差的决策。 — Anthropic
随着 Agent-环境交互的积累，原本干净的上下文会逐渐被不相关信息、过时内容、矛盾指令污染。
11.2 长时间任务挑战
| 挑战 | 说明 |
|---|---|
| 存储瓶颈 | 如何在严格资源约束下保留尽可能多的相关上下文 |
| 处理退化 | Transformer 的 O(n²) 复杂度导致效率和理解质量下降 |
| 系统不稳定 | 随着记忆累积，小错误可能影响更多系统部分 |
| 评估困难 | 大多数基准只测试检索，不检查信息是否仍然相关、准确或有帮助 |
11.3 解决策略
| 策略 | 说明 |
|---|---|
| Compaction（压缩） | 上下文过长时自动压缩对话，保持重点同时保留关键细节（分级流水线见 5.3） |
| Structured Note-taking（结构化笔记） | 定期将关键信息写出上下文窗口到外部记忆，需要时检索 |
| Sub-agent Architectures（子代理架构） | 将复杂任务分解给专门的子代理，每个有自己的聚焦上下文 |
11.4 压缩与记忆的边界
这两者容易混为一谈，但职责完全不同——混淆会导致要么该留的被压没了，要么临时信息污染了长期记忆：
| 维度 | 压缩（Compaction） | 记忆（Memory） |
|---|---|---|
| 管理对象 | 当前会话的上下文预算 | 跨会话可复用的知识 |
| 生命周期 | 会话内 | 会话之外持久存在 |
| 信息取舍 | 允许丢弃可恢复的细节 | 选择性保留，不是无损备份 |
| 触发时机 | 接近上下文上限时 | 回合结束时提取候选 |
| 典型内容 | 早期工具结果、中间过程 | 用户偏好、项目事实、外部资料线索 |
判断某条信息该进哪边，用一个问题：下次全新会话还需要它吗？
- 「用户偏好用 tab 缩进」→ 需要 → 进记忆
- 「这次任务不要创建文件」→ 只约束本次 → 不进记忆，压缩时可丢
⚠️ 召回的记忆是背景知识，不是新指令
把长期记忆注入上下文时，必须显式声明它的权限等级：召回内容仅供参考，与当前用户请求冲突时以当前请求为准。
否则旧记忆会变成隐形指令——用户明明改了要求，Agent 却在执行三个月前存下的偏好。这是记忆系统最容易被忽视的安全边界。
十二、应用场景
12.1 CLI Agent（如 Gemini CLI）
上下文组织：
GEMINI.md文件记录项目背景、角色定义、工具依赖、编码规范- 通过文件系统层级实现继承和隔离
- 启动时加载静态信息，交互时增量积累动态上下文
上下文压缩：
- 用 AI 生成的摘要替换长交互历史
- 遵循预定义格式保留关键方面
12.2 深度研究 Agent
Tongyi DeepResearch 流程：
- 基于用户查询搜索网络
- 从相关页面提取关键信息
- 生成新子问题指导进一步搜索
- 整合多来源证据为连贯答案
上下文工程：
- 定期调用专门的摘要模型压缩累积历史
- 生成"上下文快照"保留关键证据并突出缺失信息
- 后续推理基于压缩快照而非完整原始历史
12.3 脑机接口
BCI 为上下文工程提供新途径：
- 更丰富的上下文维度：注意力水平、情感状态、认知负荷
- 更便捷的收集方式：减少显式用户操作，通过神经活动实现更即时的输入
十三、未来方向：语义操作系统
13.1 核心挑战
终身上下文工程的挑战不能仅通过"扩展上下文窗口"或"提高检索准确性"来解决。它需要构建一个能够像人类思维一样随时间成长的语义操作系统。
13.2 设计要求
| 要求 | 说明 |
|---|---|
| 大规模语义存储 | 作为自己的记忆库，支持高效存储 |
| 人类级记忆管理 | 主动添加、修改和遗忘知识 |
| 新架构 | 替代 Transformer 的平面时间建模，实现更强的远程上下文推理 |
| 可解释能力 | 追踪、纠正和解释推理链中的每一步 |
13.3 范式转变
核心原则
上下文不再是被动累积的，而是作为认知的核心元素被主动管理和演化。
这反映了一个根本性的范式转变：从数据存储到知识学习。
十四、工具与框架
14.1 上下文工程相关工具
| 工具/框架 | 用途 |
|---|---|
| LangChain | RAG、记忆、工具集成、上下文管道 |
| LlamaIndex | 文档索引与检索 |
| MCP | 标准化外部系统连接 |
| Letta | 记忆增强 LLM 代理 |
| MemOS | LLM 记忆操作系统 |
| Pinecone/Weaviate | 向量数据库 |
| Redis | 会话状态存储 |
14.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 的上下文管理
Don't build multi agents — Cognition 关于多智能体应该串行流转并对 Context 进行高度工程化的深刻探讨 更多文章参见 Anthropic Engineering 文章合集。