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