最近在看 Context Engineering 相关的资料，刚好看到上海交大团队发布的《Context Engineering 2.0: The Context of Context Engineering》，从一个完全不同的视角阐释了 Context Engineering 的涵义和发展历程，很有意思的思路，这儿写篇文章分享一下。
我一直以为 Prompt Engineering、RAG 这些是 ChatGPT 时代才有的东西。结果这篇论文却提出，早在 20 年前就有人在研究怎么让机器感知“上下文”了。只不过那时候不叫这个名字，做法也完全不一样。论文的核心观点是Context Engineering 的本质不是技术创新，而是熵减（即弥合认知差距）。 我们现在写 Prompt、调 RAG、设计 Agent，和 20 年前的研究者其实在做同一件事，也就是帮机器理解人的意图。随着智能水平的提升，AI 能更自主地处理上下文信息，从而降低人机交互的成本。
熵减—— Context Engineering 2.0 的关键
论文用了一个物理学概念来解释 Context Engineering 的本质：熵减。
这儿所说的“熵”其实就是信息熵。什么是信息熵？可以用"猜谜游戏"来理解：比如我心里想一个 1 到 100 的数字，要你猜出来。如果我只告诉你“这是一个数字”，你需要问很多问题才能猜到答案——这就是高熵状态，不确定性很大。但如果我提示“这是 50 到 60 之间的偶数”，你只需问少数几个问题就能猜到——这就是低熵状态，不确定性较小。
人类对话中的隐性熵减
人在交流时，熵减过程是自然而然发生的。比如，我问同事：“那个文档改了吗？”
同事能明白“那个”指的是哪个文档，因为：
- 我们上午刚开过会，讨论了 API 文档；
- 我的电脑屏幕正对着他，他看到我在修改代码；
- 他知道我正在做集成任务，自然会关注 API 文档。
这些共同的背景、情境线索和场景理解，使人类能够主动弥补信息缺口，将高熵的“那个”具体化为“/docs/api.md”这样的文档。
机器为什么不能熵减？
但机器做不到这一点。我在测试 AI 编程时就有这种体会。我说：“帮我修改那个文件。”AI 工具会首先回复：“请问你指的是哪个文件？”
即使我们在前面的对话中已经提到过这个文件，甚至我的光标正停在该文件上，AI 工具依然无法像人类一样“脑补”出我的意图。论文对此有如下定义：
“Context Engineering 是将高熵的人类意图，手动压缩为低熵的机器输入的系统过程。”
这就是为什么我们需要表达得更清楚：
- 不是说“修改一下”，而是“在第 23 行添加错误处理”。
- 不是说“优化性能”，而是“使用缓存减少数据库查询次数”。
- 不是说“那个 bug”，而是“用户登录后跳转到 404 的问题”。
每当你把模糊的意图转化为精确的指令时，你就在进行熵减。
Context Engineering 的发展历程
如下图所示，论文将 Context Engineering 的发展历程划分为四代，并展示了机器智能与人类智能之间的差距随时间的变化。人类智能的提升相对平缓，几千年来认知能力并未发生质的飞跃；而机器智能则呈指数增长，发展速度越来越快。两者之间的差距（gap）正是 Context Engineering 存在的意义。机器越不智能，差距越大，人机交互越难；机器越智能，差距越小，人机交互就越自然。
Era 1.0（1990s-2020）：原始计算
早期的 Context Engineering 中，机器只能处理熵值极低的输入。1999 年，卡内基梅隆大学的 Anind Dey 开发了 Context Toolkit，这是首个系统化的上下文感知框架。它的功能包括：
- 获取 GPS 坐标：（37.7749，-122.4194）
- 读取时间戳：2025-01-15 14:30:00
- 检测设备状态：is_connected=true
系统会根据这些结构化数据执行预设规则，例如：“如果当前位置为办公室，则将手机静音。”
这种设计的最大问题在于：所有的熵减工作都由人类完成。你必须事先定义好所有规则，机器只是被动执行，完全不具备理解能力。
Era 2.0（2020-现在）：智能体
2020 年发布的GPT-3 是人工智能发展的一个重要转折点。机器开始能够处理自然语言输入。比如你可以让它：
- 重构这个函数，让代码更易读
- 帮我写一个测试用例
- 检查这段代码是否存在安全问题
AI 开始承担部分信息简化（熵减）的工作。比如，当你要求“优化这段代码”时，像 Claude Code 这样的 AI 编程工具会：
- 分析当前代码存在的问题（如重复逻辑、命名不规范）；
- 推断你可能期望的改进方向；
- 提供具体的重构建议。
与 Era 1.0 相比，这是一次质的飞跃。但机器在信息简化方面仍然存在局限。论文中引用了一项数据：在 AI 编程上，当上下文窗口占用率超过 50% 时，AI 的性能往往会急剧下降（Osmani，2025），其原因在于信息熵过高。
因此，Context Engineering 2.0 的核心不再是向 AI 输入更多信息，而是帮助 AI 有效地进行信息简化（降低熵）。在设计智能体时，需要对上下文的收集、存储、管理和使用等每一个环节进行精细化设计：
Era 3.0：人类级智能
未来到了 Era 3.0 阶段，人类无需主动进行熵减。你只需说一句“有点担心这个上线”，AI 就能理解你的意思，自动推断出你的隐含担忧。
论文还提到，脑机接口（BCI）可能成为一个重要发展方向。如果 AI 能直接读取神经信号，就不需要你把意图“翻译”为语言，而是可以直接从大脑活动中获取信息，这将实现终极的熵减。
Era 4.0：超人类智能
更激进的设想是机器终会超越人类智能。当机器比人类更聪明时，它反过来可以帮助人来“构建上下文”。比如，你问：“怎么优化这段代码？”AI 可能会这样回答：
“你可能没注意到，这个函数被调用了 10000 次，其中 90% 都是重复计算。我建议你引入缓存，而不仅仅是优化算法本身。”
它比你更了解你的代码，也更懂你的需求。这也意味着 AI 不再需要人类来减少信息熵，Context Engineering 可能也就消失了。
上下文收集存储
讲完 Context Engineering 的发展历程，我们再来看看它是如何运作的。论文中提到一个关键观点：不是收集得越多越好，而是要收集得“刚刚好”。
这里有两个设计原则：
- 最小充分性原则：只收集足够用的信息，避免冗余。
- 语义连续性原则：保持信息的语义连贯，而不是简单堆积数据。
举个例子。在 Era 1.0 时，系统只能收集非常基础的信息，比如 GPS 坐标、时间戳等。比如你的手机检测到“位置=办公室，时间=工作时间”，就会自动静音。这些数据都存储在本地，系统并不理解你的具体行为，只是按照规则执行。
到了 Era 2.0，Agent 能收集的信息丰富了许多：你的聊天记录、查看的代码、打开的文件，甚至屏幕截图等等。但新问题也随之出现了：信息量太大，AI 的上下文窗口无法全部容纳。
因此，现在的系统普遍采用“记忆压缩”。比如 Claude Code 会定期将对话历史压缩成摘要。原本可能有 50 条对话，压缩后只剩几句话：“用户在调试登录问题，已检查数据库连接，目前怀疑是 JWT token 过期。”这样就把高熵的原始对话转化为低熵的结构化笔记。
论文将这个过程称为“Self-baking”（自我烘焙）。我觉得这个比喻很贴切——就像把面团烘焙成面包，原料虽然多，但成品更紧凑、更易使用。
那 Era 3.0 会是什么样？论文的设想是 AI 不仅能记录你说了什么，还能感知你的情绪、眼神，甚至沉默时的意图。而且，存储方式也会像人脑一样，主动“遗忘”不重要的信息，只保留真正有价值的记忆。这样一来，你无需再手动管理上下文——AI 会自动判断该记住什么、该忘掉什么（注：DeepSeek OCR 的思想其实也正是这样）。
上下文管理
收集完上下文后，如何高效利用这些信息就是一个重要问题。虽然当前 LLM 的上下文窗口不断扩大，但容量限制依然很小。论文提出这儿的核心挑战在于将杂乱的原始信息整理为机器能够高效推理的低熵输入。
文本上下文的处理
我们与 AI 的日常对话，信息密度其实很低。比如，你和 Claude Code 进行了 30 轮交流，内容可能包括：
- 你的随口提问：“这段代码有问题吗？”
- AI 的试探性回答：“可能是这里的逻辑……”
- 你的确认：“对对对，就是这里。”
虽然对话内容很多，但真正有价值的信息可能只有几句。因此，系统通常会进行以下处理：
- 加标签：为对话内容打上“目标”“决策”“错误”等标签，便于后续检索。
- 重构为问答对：将零散的对话整理成“Q: 如何优化登录速度？A: 使用 Redis 缓存 Session”这样的问答形式。
- 分层笔记：将相关信息组织成层级结构，类似于做笔记。
论文还讨论了多模态上下文的处理。现在的 Agent 不仅要处理文本，还要处理图片、代码，甚至传感器数据。如何融合不同格式的信息？主要有两种方法：一是将所有信息转换为向量（Embedding）；二是通过注意力机制，让不同类型的信息“互相关注”。
分层记忆架构
论文将 LLM 的上下文窗口比作电脑的 RAM（内存），容量有限但访问速度很快。因此，系统需要一种“内存管理”策略：
- 短期记忆：用于当前任务的临时信息，用完即丢。
- 长期记忆：重要的知识和经验，需要永久保存。
举个例子，当你用 Claude Code 调试一个 bug 时，短期记忆保存的是“当前正在查看 login.ts 的第 45 行”，而长期记忆则记录“这个项目采用 JWT 认证”。
还有一个技巧是使用子 Agent。如果任务很复杂，可以让不同的子 Agent 各自处理一部分，避免把所有信息都塞进同一个上下文窗口。这样不仅能减少“上下文污染”，还可以提升系统的稳定性。
对于特别大的数据（比如一个 10MB 的日志文件），系统通常不会把整个文件都放进上下文窗口，而是只保存一个引用，比如：“用户提到了 /logs/error.log 文件，里面有 500 条错误记录”。需要时再去读取具体内容。
自我烘焙（Self-baking）
这是整个上下文管理中最关键的一步，即将原始、高熵的对话记录压缩为结构化知识。论文将这一过程称为“从回忆到知识积累”。
常见的实现方式有：
生成摘要：将 50 条对话浓缩为几段简明扼要的文字。
提取结构化数据：例如，CodeRabbit 会将代码评审结果保存为 JSON 格式，包含文件路径、问题类型、修改建议等字段。
转化为向量：将信息编码为语义向量，通过向量检索找到相关内容。
添加结构化解释：将原文和结构化解释存储到一起，便于提取关键信息。
这些结构化知识比纯文本更便于 AI 进行推理和关联。论文称其为“Agent 执行长期任务的认知基础设施”。
上下文使用
如果说前面的“收集”和“管理”是在为后续工作准备“弹药”，那么“使用”就是正式“开火”的环节。关键不是把所有信息都塞给 AI，而是选择最相关的部分。
上下文选择
论文中引用了一个重要数据：当上下文窗口填充率超过 50% 时，AI 的性能就会下降。我在使用 Claude Code 时也有类似体验——对话内容过长，AI 的回答就变得不够聚焦。
为什么会这样？因为无关信息太多，就像在一堆文档中查找资料，文档越多，找到关键内容就越难。论文将这种现象称为“上下文超载”。
因此，系统在选择上下文时需要非常精细：
- 语义相关性：通过 RAG（向量检索）找到与当前问题最相关的信息。
- 逻辑依赖性：如果讨论一个函数，相关的调用函数也要包含进来。
- 时效性：最新的信息通常更重要。
- 去重：避免重复加入相同的信息。
上下文共享
当多个 Agent 协作时，它们如何传递信息？论文中提到几种常见方式：
- 嵌入到 Prompt 中：将上一个 Agent 的结论直接写入下一个 Agent 的提示词中。
- 结构化消息：以 JSON 等结构化格式传递信息，例如：
{"task": "code review", "file": "login.ts", "issues": [...]}。 - 共享内存空间：类似于一个黑板，所有 Agent 都可以在上面写入或读取信息。
如果需要在不同系统之间共享上下文（如从 Cursor 切换到 ChatGPT），通常需要一个“适配器”来转换格式。也可以直接使用通用的语义向量，这样就无需关心具体格式。
主动推断需求
Era 3.0 的目标是让 AI 能主动理解你的真实需求。论文举了一个例子：如果你连续询问“Python 装饰器怎么用”和“如何进行性能调优”，AI 可能会推断出你其实关心的是“如何提升软件设计效率”，并主动为你推荐相关工具和方法。
这就像一位经验丰富的同事，能够从你零散的问题中看出你真正想解决的核心问题。
技术挑战
然而，要实现“终身上下文”——让 AI 记住你所有的历史交互——仍面临许多挑战：
- 性能问题：Transformer 模型的复杂度为 O(n²)，上下文越长，计算量越大。
- 存储瓶颈：如何在保证高精度的同时，压缩存储空间。
- 系统稳定性：上下文过长时，模型容易“崩溃”。
- 难以评估：上下文变长时，更难评估推理是否正确。
论文提出，未来需要一个“语义操作系统”，能够像人脑一样主动管理记忆——该记住的记住，该忘掉的忘掉。只有这样，AI 才能实现真正的长程推理能力。
KV 缓存优化
论文还提到一个工程细节：KV 缓存。简单来说，LLM 在生成文本时，会缓存之前 token 的注意力权重（Key-Value 对）。如果前缀相同，就无需重新计算，从而大幅提升速度。但这里有一个问题：前缀必须完全一致。比如，如果你在 system prompt 开头加了时间戳：
Current time: 2025-01-15 14:30:00
You are a coding assistant...
每次对话的时间都不同，KV 缓存就会失效。
论文引用了 Manus 的工程实践，指出通过保持前缀稳定，并强制只允许追加和确定性更新，可以显著提升推理速度。这也是一个熵减的例子：去除不必要的变化，保持信息的“低熵”结构。
小结
许多人认为“上下文工程”是 ChatGPT 时代才出现的概念，但这篇论文指出，它其实是一个长期演进的学科。从早期机器只能处理结构化数据，到如今大型语言模型能够理解自然语言，上下文工程一直在持续发展。
回顾发展历程，所有这些努力都指向同一个目标：弥合人类意图和机器理解之间的鸿沟。早期系统只能处理低熵的结构化输入，信息简化依赖人工完成；而现在的 AI 已能承担部分信息简化任务，能够理解自然语言和多模态信息，但我们仍然需要手动帮助机器降低信息熵，也就是需要精心设计 Prompt、优化 RAG、管理上下文等等。
未来，随着机器智能逐步接近甚至超越人类认知，角色或许会发生反转。AI 不再需要人类压缩和管理上下文，反而可能帮助人类更好地理解自身意图。届时，人机协作的方式也可能发生根本性变化。
论文地址：https://arxiv.org/abs/2510.26493，感兴趣的读者可以阅读全文。
欢迎长按下面的二维码关注 Feisky 公众号，了解更多云原生和 AI 知识。
