|
|
@@ -0,0 +1,225 @@
|
|
|
+---
|
|
|
+title: Context Engineering：比提示词工程更底层的那件事
|
|
|
+author: Gamehu
|
|
|
+date: 2026-03-26 20:25:43
|
|
|
+tags:
|
|
|
+ - AI
|
|
|
+ - Context Engineering
|
|
|
+ - 大模型
|
|
|
+ - Prompt Engineering
|
|
|
+ - RAG
|
|
|
+categories:
|
|
|
+ - AI
|
|
|
+---
|
|
|
+
|
|
|
+<div class="tag-container">
|
|
|
+ <span class="ai-tag">AI</span>
|
|
|
+ <span class="sub-tag">Context Engineering</span>
|
|
|
+ <span class="sub-tag">大模型</span>
|
|
|
+</div>
|
|
|
+
|
|
|
+> 📎 **说明**：这篇文章是我在学习 [《Agentic 入门：让 AI 不再一把梭，而是像人一样反复干活》](Agentic-入门：让-AI-不再一把梭，而是像人一样反复干活.md) 时一起整理的。其实这篇关于 Context Engineering 的内容应该先发，但当时没整理好，所以后发了。
|
|
|
+
|
|
|
+**Context Engineering**（上下文工程）最早接触是去年Prompt Engineering 概念活了一段时间之后。
|
|
|
+在这之前好像AI应用开发的核心焦点一直是“提示词工程（Prompt Engineering）”。然而，随着大语言模型（LLM）从单次问答向能够自主运行的智能体（Agent）演进，一个全新的概念正逐渐占据主导地位：上下文工程（Context Engineering）
|
|
|
+。
|
|
|
+构建大语言模型应用，正在从“如何遣词造句写出完美的提示词”，转变为“如何配置上下文才能最大概率地生成模型所需的行为”
|
|
|
+。
|
|
|
+
|
|
|
+这篇文章是我自己的学习整理，目标只有一个：<span class="highlight-text">用人话把"上下文工程到底在解决什么问题"讲清楚。</span>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 一、先说问题：Prompt Engineering 到底卡在哪儿？
|
|
|
+
|
|
|
+用过 AI 的人应该都有这种体验：
|
|
|
+
|
|
|
+你认认真真写了一个很长的 Prompt，结果模型要么没懂你的意思，要么给出来的答案"飘"得很。你换了个角度再提问，它又忽然变得很靠谱。
|
|
|
+
|
|
|
+你开始怀疑：是我 Prompt 写得不好，还是模型本身忽强忽弱？
|
|
|
+
|
|
|
+这个问题背后藏着一个更根本的事情：<span class="highlight-text">模型能不能干好活，很大程度上取决于它"当下能看到什么"。</span>
|
|
|
+
|
|
|
+Prompt Engineering 做的事，说白了是"怎么把这个问题问清楚"。这是必要的，但它管不了一件事——当你需要处理的信息量超出单次对话能装下的量时，怎么办？
|
|
|
+
|
|
|
+比如：
|
|
|
+- 你有一本 500 页的技术文档，想让 AI 帮你答用户问题
|
|
|
+- 你的系统里有十几个上下文来源（用户历史、实时数据、业务规则、代码片段……）
|
|
|
+- 你的 Agent 要跑十几步任务，中间状态要一直传下去
|
|
|
+
|
|
|
+这些场景里，"怎么问"已经不是最核心的问题了，**"怎么喂"才是**。
|
|
|
+
|
|
|
+这就是 Context Engineering 要解决的事。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 二、那 Context Engineering 到底是什么？
|
|
|
+
|
|
|
+Anthropic 官方的说法是，它是**从 Prompt Engineering 演进来的**[《Effective context engineering for AI agents》](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)，但两者的关注点不同：
|
|
|
+
|
|
|
+- Prompt Engineering：**怎么写好这一句话**
|
|
|
+- Context Engineering：**怎么组织整个信息环境**
|
|
|
+
|
|
|
+后者更像是在做"信息架构"，你要决定：
|
|
|
+
|
|
|
+1. 哪些信息该放进上下文
|
|
|
+2. 这些信息按什么结构组织
|
|
|
+3. 什么时机、以什么方式把它们喂给模型
|
|
|
+4. 超出上下文窗口时，怎么选择性地保留和丢弃
|
|
|
+
|
|
|
+这件事听起来像工程，因为它**就是工程**。它不是让你背几个提示词公式，而是要你把整个信息流设计清楚。
|
|
|
+
|
|
|
+有一个比方我觉得很贴：
|
|
|
+
|
|
|
+> Prompt Engineering 是教你怎么跟一个人说话；Context Engineering 是在他开口之前，帮你决定他今天能看到哪些材料、能记得哪些背景、桌上摆的是什么资料。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 三、底层是什么？先聊 Self-Attention
|
|
|
+
|
|
|
+要真正理解"上下文"对模型意味着什么，绕不开一篇 2017 年的论文：《Attention Is All You Need》[《Attention Is All You Need》](https://arxiv.org/abs/1706.03762)，也就是提出 Transformer 架构的那篇。
|
|
|
+
|
|
|
+它里面最核心的东西是 **Self-Attention（自注意力机制）**。
|
|
|
+
|
|
|
+用一句话说：模型在生成每一个词的时候，会同时"扫一眼"上下文窗口里所有其他的词，计算"哪些词跟当前词最相关"，然后根据这个相关性来决定输出。
|
|
|
+
|
|
|
+这意味着：**模型的能力，很大程度上取决于窗口里装了什么**。
|
|
|
+
|
|
|
+你给它看的内容越准确、越有结构、越聚焦，它的注意力就越能集中在真正重要的部分。你塞一堆无关信息进去，它不会自动过滤掉，它只会"稀释"它的注意力。
|
|
|
+
|
|
|
+所以"上下文工程"这件事，在模型层面的物理底层，就是在跟 Self-Attention 机制博弈。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 四、RAG 里最容易踩的坑，Anthropic 想了个解法
|
|
|
+
|
|
|
+现在很多 AI 应用都在做 RAG（检索增强生成）——就是把一堆文档切片，存进向量数据库，等用户提问时捞出相关片段塞给模型。
|
|
|
+
|
|
|
+这条路方向没错，但有一个很隐蔽的问题：**文档切片会丢掉背景信息**。
|
|
|
+
|
|
|
+举个例子：你有一份技术文档，里面有一段话：
|
|
|
+
|
|
|
+> "这个接口的超时时间配置建议设为 5 秒。"
|
|
|
+
|
|
|
+这句话单独拿出来是完整的，但如果你不知道这是在说"内网服务调用"而不是"公网 HTTP 请求"，这条建议可能直接坑掉你。
|
|
|
+
|
|
|
+Anthropic 在 2024 年提出了 **Contextual Retrieval**[《Contextual Retrieval》](https://www.anthropic.com/news/contextual-retrieval) 来解这个问题。方案的核心是：
|
|
|
+
|
|
|
+在切片存储之前，先让模型给每个片段加一段 **"上下文注释"**，说明它来自哪个文档、属于哪个章节、要解决什么问题。然后把这个带注释的片段再做向量化。
|
|
|
+
|
|
|
+这样检索出来的内容，就不只是一句话，而是"一句话 + 它所在的语义背景"，命中质量会好很多。
|
|
|
+
|
|
|
+配合 **BM25 关键字检索**（而不是单纯依赖语义向量），精确度进一步提升。
|
|
|
+
|
|
|
+<span class="highlight-text">简单来说：不是切得多就能捞得准，要让每一块碎片都知道自己是从哪来的。</span>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 五、吴恩达的角度：上下文是动态的，不是一次性的
|
|
|
+
|
|
|
+上面说的 Contextual Retrieval 解决的是"单次检索"的质量问题。但如果放到更复杂的 Agent 场景里，还有另一个维度：**上下文不是一开始就完整的，它是在任务执行过程中逐渐积累的**。
|
|
|
+
|
|
|
+吴恩达在他的 Agentic Workflow 系列里[《Agentic AI》课程系列](https://www.deeplearning.ai/courses/agentic-ai/) 反复强调一件事：**让 AI 像人一样迭代**，而不是一把梭。
|
|
|
+
|
|
|
+在多轮 Agentic 工作流里，每一步的执行结果都会作为新的上下文，传入下一步。这意味着：
|
|
|
+
|
|
|
+- 你需要决定每一步结束后，哪些信息值得保留并传下去
|
|
|
+- 哪些信息已经过时了，可以丢掉
|
|
|
+- 什么时候需要从外部工具再捞一批新的上下文进来
|
|
|
+
|
|
|
+这不是写一个好的 Prompt 能解决的。这是系统设计层面的事。
|
|
|
+
|
|
|
+最近他提到的 **Context Hub** 工具，方向也是这个：为 Agent 提供实时的、动态组织好的文档上下文，而不是让 Agent 自己去翻一堆原始资料。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 六、Anthropic 的工程实践：XML 标签和 Prompt Caching
|
|
|
+
|
|
|
+具体到怎么组织上下文，Anthropic 在他们的工程实践里[《Effective context engineering for AI agents》](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) 给了两个很实用的工具：
|
|
|
+
|
|
|
+**① XML 标签**
|
|
|
+
|
|
|
+当你需要在上下文里放多个来源的信息（用户资料 + 业务规则 + 代码片段 + 历史记录），用纯文本堆在一起，模型很容易把它们"混为一谈"。
|
|
|
+
|
|
|
+用 XML 标签把它们显式分开，能让模型更清楚哪块是哪块：
|
|
|
+
|
|
|
+```xml
|
|
|
+<user_profile>
|
|
|
+ 用户是一个年营收 500 万的 SaaS 创业公司 CTO
|
|
|
+</user_profile>
|
|
|
+
|
|
|
+<business_rules>
|
|
|
+ 禁止直接推荐未上线的功能
|
|
|
+</business_rules>
|
|
|
+
|
|
|
+<user_query>
|
|
|
+ 我们应该怎么设计权限系统？
|
|
|
+</user_query>
|
|
|
+```
|
|
|
+
|
|
|
+这不是魔法，就是**把结构显式化**，让模型不用猜。
|
|
|
+
|
|
|
+**② Prompt Caching（提示词缓存）**
|
|
|
+
|
|
|
+如果你的系统里有一段很长的固定上下文（比如一份 300 页的产品手册），每次用户提问都要把这段内容完整喂给模型，成本很高。
|
|
|
+
|
|
|
+Prompt Caching 允许你把这段内容缓存在 API 层，后续调用直接复用，不重复计算。
|
|
|
+
|
|
|
+这是一个纯工程优化，但它非常关键——**它让"维持一个丰富的长期上下文"在成本上变得可行**。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 七、Karpathy 的那个比喻：上下文窗口是模型唯一的内存
|
|
|
+
|
|
|
+在 OpenAI 前首席科学家 Andrej Karpathy 的一个演讲里[《Software Is Changing (Again)》演讲](https://www.youtube.com/watch?v=yIPgptGZmDY)，他把上下文窗口比作大模型的"有限内存"。
|
|
|
+
|
|
|
+这个比方很直接：
|
|
|
+
|
|
|
+模型本体里存的是"知识"，但它在干活时看到的，只有上下文窗口里的内容。超出窗口的东西，它看不见，也不存在。
|
|
|
+
|
|
|
+这就是为什么：
|
|
|
+
|
|
|
+- 你聊了很长一段时间之后，模型开始"忘事"
|
|
|
+- 你让它处理一个超长文档，它只抓住了开头和结尾
|
|
|
+- 你的多轮 Agent 任务执行到一半开始乱套
|
|
|
+
|
|
|
+根本原因都一样：**窗口装不下了，或者装的东西不对**。
|
|
|
+
|
|
|
+上下文工程要做的，就是在这个有限的空间里，把最该出现的东西，用最合适的方式装进去。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 八、整理一张表：四个角度看上下文工程
|
|
|
+
|
|
|
+| 来源 | 核心关键词 | 解决的问题 |
|
|
|
+|:--|:--|:--|
|
|
|
+| **Anthropic** | Contextual Retrieval / XML 标签 / Prompt Caching | 如何结构化地组织海量背景，避免信息丢失 |
|
|
|
+| **Google (Transformer)** | Self-Attention | 模型本身如何在数学层面"读懂"上下文 |
|
|
|
+| **吴恩达** | Agentic Workflow / Context Hub | 如何在多轮任务里动态维护和更新上下文 |
|
|
|
+| **Karpathy/OpenAI** | Context Window / CoT | 上下文的物理边界和逻辑链条设计 |
|
|
|
+
|
|
|
+这四个角度，分别对应了上下文工程的不同层次：从底层的数学机制，到 RAG 质量，到多 Agent 协同，再到单次任务的推理链。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 九、我目前的几个实际感受
|
|
|
+
|
|
|
+老实说，我学这块内容之前，犯过不少低级错误：
|
|
|
+
|
|
|
+1. **把所有背景信息一股脑塞进 System Prompt**，然后发现模型越来越"飘"。后来才明白：不是信息越多越好，是**相关信息越精准越好**。
|
|
|
+
|
|
|
+2. **以为 RAG 只是检索 + 拼接**，直接切片存向量就完事了。后来真碰到上下文断裂的 bug 才明白：检索出来的片段需要"知道自己是谁"。
|
|
|
+
|
|
|
+3. **把 Prompt Engineering 等同于 Context Engineering**，以为把问题问好了就够了。后来才意识到在 Agent 场景里，问题怎么问已经排在"信息怎么组织"后面了。
|
|
|
+
|
|
|
+<span class="highlight-text">说白了，上下文工程是软件工程在 AI 时代的一个延伸——你不只是在写 Prompt，你在设计信息流。</span>
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 结尾
|
|
|
+
|
|
|
+这篇是我的学习整理，没有深入做代码实现，主要是把概念层面的东西先想清楚。
|
|
|
+
|
|
|
+如果你也在做 AI 应用，或者在带团队搭 AI 系统，我觉得最值得先读的是 Anthropic 那篇 **Contextual Retrieval** 的官方博文。它不只是讲了一个技术方案，更把"为什么 RAG 会失效"这件事解释得很清楚，对系统设计的帮助很大。
|
|
|
+
|
|
|
+这个领域每隔一段时间就有新东西出来，我也还在学习中。如果你有不同看法或者实践经验，欢迎来聊。
|
