引言：当AI有了"工作记忆"——上下文工程的时代来临
引言：当AI有了"工作记忆"——上下文工程的时代来临
1.1 一个企业知识库的"失忆"故事
2024年春天，老张的公司启动了一个"知识库智能化"项目。
老张是谁？他是某中型制造企业的IT架构师，三十出头，擅长Java和分布式系统，但对AI一窍不通——至少他自己这么认为。项目目标很清晰：把过去二十年积累下来的产品手册、技术文档、SOP流程全部塞进一个AI问答系统，让一线工程师和销售能用自然语言"问"出答案。
他找了两个实习生，三周搞定。
技术栈很简单：用LangChain把文档切成chunk，embeddings存进向量数据库（他们选了Pinecone），接到GPT-4的API上，再写一个简单的Prompt："你是一个知识库助手，请根据以下上下文回答用户问题。如果不知道，就说不确定。"
效果惊艳。
上线第一周，公司CTO亲自测试：连续问了二十多个问题，从"我们的XX型号电机扭矩多少"到"采购流程中供应商准入标准是什么"，AI几乎全部答对，还附带了引用文档的链接。CTO在季度会议上激动地拍桌子："这是我们数字化转型的里程碑！"
但好景不长。
上线第三个月，老张开始收到各种"诡异"的反馈。
第一个问题是"重复"。一线工程师小王问"请帮我查一下A型传感器的校准周期"，AI给了一个准确答案。三分钟后小王追问"那B型呢"，AI居然又把A型的答案复述了一遍，仿佛完全不记得前几轮的对话。
第二个问题是"张冠李戴"。有人问"XX型号机器的维护手册在哪里"，AI信誓旦旦地给了一个PDF链接，点开一看——那是另一个型号的文档。两个产品线完全不同的设备，被AI"嫁接"在了一起。
第三个问题最致命：一位销售总监在演示中问了一个偏门问题："2021年我们和某客户签的合同里，违约金条款是怎么写的？"AI开始胡说八道，编造了一堆看起来很专业但完全虚构的条款。客户当时就在会议室里，场面一度非常尴尬。
老张懵了。模型没换，Prompt没动，为什么效果断崖式下跌？
他花了三周排查，最终发现了几个"凶手"：
- 文档量从最初的200份暴涨到12000份，向量检索的top-k片段开始混入不相关内容；
- 多轮对话累积了上百条历史消息，整个上下文被塞得满满当当，关键问题反而被淹没；
- 系统完全没有"状态"概念，用户的角色、权限、历史行为全部丢失；
- 每条检索结果都带着一堆模板化的metadata，挤占了大量token；
- 甚至Prompt本身也开始"漂移"——为了让AI表现得更好，团队不断往上加规则，Prompt从最初的3行膨胀到了80行。
老张最后在团队群里说了一句话："我们不是在做AI应用，我们是在用金锄头挖土豆。"
这个故事不是虚构的——它每天都在无数公司重演。
老张遇到的问题，表面上是"AI变笨了"，但本质上是：上下文没有被当成工程对象来设计。他有一套完整的向量检索系统，有一个看起来合理的Prompt，有一个能跑通的RAG流程，但他缺的是一种系统级的思维：把每一次调用LLM时进入模型"视野"的所有信息，当作一个需要被精心策划、压缩、检索、管理、淘汰的资源池来对待。
这就是上下文工程（Context Engineering）要解决的问题。
1.2 范式转移：从"写好提示词"到"管理上下文"
如果把2022年到2024年的AI应用开发史画成一条曲线，会看到一个非常清晰的拐点。
第一阶段（2022-2023上半年）：提示词工程时代。
那时候，ChatGPT刚发布，全民陷入"Prompt狂热"。所有教程都在教你"如何写好Prompt"——给角色、给示例、用CoT（思维链）、用ReAct、用few-shot。Prompt被视为一种"咒语"，写对了就灵，写错了就废。
这个阶段的典型思维是：AI的能力 ≈ 模型本身的能力 × Prompt的质量。
只要Prompt写得好，模型就能变聪明。所以大家拼命研究Prompt技巧，互相分享"咒语模板"。这个阶段诞生了大量Prompt工程师，也诞生了后来被戏称为"Prompt民工"的岗位。
第二阶段（2023下半年-2024）：RAG时代。
随着企业应用落地，大家发现单靠Prompt不够——模型不知道你的私有知识。于是RAG（Retrieval-Augmented Generation，检索增强生成）成为新风口。
这个阶段的典型思维是：AI的能力 ≈ 模型本身的能力 × 检索到的知识质量。
大家开始研究embedding模型选型、向量数据库性能、reranker策略、chunk大小。LangChain、LlamaIndex这类框架如日中天。
第三阶段（2024-至今）：Agent与上下文工程时代。
RAG解决了"知识从哪里来"的问题，但应用变复杂后，新的问题涌现：
- Agent开始多步推理，每一步都要把上一步的结果塞回Prompt；
- 多轮对话越来越长，历史消息撑爆上下文窗口；
- 工具调用、函数返回、多模态输入……上下文里的"杂物"越来越多；
- 用户希望AI能记住"他上次说过的偏好"。
大家逐渐意识到：真正决定AI应用表现的，不是Prompt本身，而是进入模型视野的整个上下文。
这个阶段的典型思维是：AI的能力 = 模型在给定上下文下能做出的最优决策。
Prompt只是上下文的一部分。甚至可以说，Prompt是上下文的"操作界面"——你通过它告诉模型"如何处理"即将到来的所有信息。
于是，"上下文工程"这个概念在2024年下半年被正式提出来。Anthropic的一篇博客和LangChain团队的多次演讲都强调过这个转向，它指的是：围绕如何构造、管理、优化进入LLM的信息流所进行的一系列工程实践。
用一个类比来说：
> 提示词工程像是写一份精美的演讲稿，而上下文工程是为演讲者搭建整个舞台——灯光、音响、提词器、观众反应、背景资料——让演讲者在正确的时机获得正确的信息。
老张团队后来意识到，他们的问题不是Prompt写得不好，而是从来没有"搭建舞台"。他们把12000份文档一股脑塞进向量库，把80行Prompt当成万能模板，把多轮对话原封不动地传给模型——这就像让一个演讲者站在空旷的广场上，既没有提词器，也看不到观众反应，只有一摞可能无关的稿子和一份又臭又长的提纲。
1.3 重新定义"上下文"：LLM视野中的一切
在LLM的语境下，"上下文"（Context）这个词需要被精确化。
很多人误以为"上下文 = Prompt"，这是一个致命的误解。实际上，每一次LLM调用时进入模型视野的全部信息，都是上下文的一部分。具体来说，至少包括以下十类：
1. 系统指令（System Instructions） 定义模型的角色、能力边界、输出格式、安全规则的部分。通常是Prompt最前面的那段文字，老张团队里就是那段"你是一个知识库助手……"。
2. 用户输入（User Input） 当前这一轮用户的直接问题或指令。
3. 对话历史（Conversation History） 多轮对话中，所有之前的用户消息和模型回复，按时间顺序排列。
4. 检索结果（Retrieved Context） 通过RAG或其他检索机制从外部知识库拉取的相关内容。这是企业应用中最庞大、最不可控的一块。
5. 工具调用记录（Tool Calls and Responses） 当Agent调用外部API、数据库、代码执行器时，工具的输入输出都会被纳入上下文。
6. 用户状态（User State） 用户的身份、权限、历史偏好、当前任务进度等结构化信息。
7. 长期记忆（Long-term Memory） 从过去的交互中提取并持久化存储的信息，下次调用时按需加载。
8. 元数据和模板（Metadata and Templates） 各种timestamp、版本号、token计数、引用编号等"杂物"。这些看似无关，但在实际系统中往往占据惊人的token量。
9. 多模态输入（Multimodal Inputs） 图像、音频、视频的编码表示，token化后也会占据上下文空间。一个看起来不起眼的图片，可能消耗几百甚至几千个token。
10. 思维链与中间推理（Chain-of-Thought） 如果让模型"先思考再回答"，它产生的中间推理步骤本身也消耗上下文——而且往往消耗得比你想象的多。
把这些全部加起来，就是LLM在这一次调用中"看到的全部世界"。
一个反直觉的事实是：模型对世界的全部认知，仅限于这一次调用中的上下文。 它不知道你昨天说过什么，不知道你的数据库里还有什么，不知道昨天那个实习生把Prompt改成了什么样——除非所有这些信息都被显式地塞进当前调用的上下文里。
这就引出了一个核心洞察：上下文是LLM的"工作记忆"（Working Memory）。
借鉴认知科学的术语：人类的"工作记忆"是指我们当下意识中能同时处理的信息——大约是"魔术数字7加减2"的容量。LLM的上下文窗口就是它的工作记忆。超过这个容量，信息会被截断；在这个容量内，信息的组织方式会深刻影响模型的推理质量。
而且，LLM的工作记忆比人类还更"娇贵"：
- 它没有"潜意识"来补偿遗忘；
- 它的注意力分布不均匀（中间的信息容易被忽略，著名的"Lost in the Middle"现象）；
- 任何错误信息一旦进入上下文，就会"污染"整个推理过程；
- 不同类型的信息会相互竞争token空间，多模态尤其如此。
理解了这些，你就会明白：为什么Prompt写得再漂亮，也救不了一个上下文混乱的系统。
1.4 上下文工程的五大支柱
既然上下文是LLM的工作记忆，那么"上下文工程"就是围绕这个工作记忆的设计、管理与优化工程。
具体来说，它由五大支柱构成。它们不是相互替代的关系，而是协同作战——一个复杂的AI应用往往需要同时调动多个支柱。
支柱一：长上下文利用（Long Context Utilization）
模型能看到的"视野"有多大，决定了它能处理多复杂的问题。从GPT-4的8K，到Claude的200K，再到Gemini的1M甚至2M——上下文窗口在飞速扩张。但更大的窗口不等于更好的效果。研究者发现，模型对上下文中不同位置的信息"注意力"是不一样的：开头和结尾最清晰，中间最模糊。这就是著名的"Lost in the Middle"现象。
这一支柱要解决的问题是：如何在给定的窗口容量内，最大化有效信息的密度和位置分布？ 涉及注意力机制的优化、关键信息的"锚定"策略、prompt placement等技术。第2-4章会从认知机制和物理极限两个角度深入探讨。
支柱二：压缩（Compression）
当你不得不把大量信息塞进上下文时，压缩就成了必备技能。但这里的"压缩"不是无损压缩（如zip），而是有损压缩——你需要在保留核心语义的前提下大幅减少token数。
技术包括：去重、模板化、向量化（注意：这里指的是把文本转成token向量的优化技巧，而非embedding）、去除冗余修饰、抽象概括等。第5-6章会系统讲解。
支柱三：摘要（Summarization）
压缩的"文艺版"。摘要不是简单删词，而是用更短的篇幅保留更完整的信息。摘要可以是历史的（把过去的对话压缩成几段）、可以是文档的（把长文档压成要点）、可以是工具调用的（把复杂的API返回压成关键字段）。
摘要的关键挑战是：如何让AI在摘要时知道"什么该保留、什么该丢弃"。这需要精细的提示设计、层级化的摘要策略，以及对下游任务的深入理解。第7章专门讨论。
支柱四：检索记忆（Retrieval Memory）
当上下文窗口装不下所有相关信息时，"按需检索"就成了唯一选择。这就是RAG的范畴。但今天我们谈的"检索记忆"已经远超传统RAG——它包括：
- 向量检索、关键词检索、混合检索；
- 多跳检索（multi-hop）；
- 层次化检索（先粗后精）；
- 跨模态检索；
- 检索结果的重排序（rerank）；
- 检索质量的自我评估。
第8-10章会带你从基础到高级，把检索记忆的工程细节讲透。
支柱五：状态管理（State Management）
老张系统里最缺失的一环。状态管理解决的是：如何在多次LLM调用之间，保持一致的"上下文状态"？
状态包括：
- 对话状态（当前是第几轮、上一轮的主题）；
- 任务状态（用户在做一件什么事，进度如何）；
- 用户状态（身份、权限、偏好）；
- 系统状态（哪些工具可用、哪些资源已加载）；
- 错误状态（上次调用失败的原因是什么）。
状态管理的技术栈非常广：Session管理、状态机设计、Redis/MongoDB的应用、上下文持久化、checkpoint机制等。第11-13章会系统展开。
为了帮助读者建立宏观心智模型，下面这张全景图展示了五大支柱的相互关系，以及它们如何共同服务于"在有限窗口内最大化有效信息"这一核心目标。
```mermaid flowchart TD GOAL[核心目标 最大化有效信息密度] P1[支柱一 长上下文利用 第2-4章] P2[支柱二 压缩 第5-6章] P3[支柱三 摘要 第7章] P4[支柱四 检索记忆 第8-10章] P5[支柱五 状态管理 第11-13章] P1 --> GOAL P2 --> GOAL P3 --> GOAL P4 --> GOAL P5 --> GOAL P1 -.协同.-> P2 P2 -.协同.-> P3 P3 -.协同.-> P4 P4 -.协同.-> P5 ```
注意图中的虚线箭头——这暗示了五大支柱之间存在"链式协同"：长上下文提供了"画布"，压缩和摘要在画布上"作画"，检索记忆从外部"调取颜料"，状态管理则"记录每一笔"。一个真正成熟的上下文工程系统，往往需要把这五者编排成一个流水线，而不是孤立使用。
举个简单的例子：一个Agent在处理"帮我整理上周的销售数据并写一份报告"这个任务时，会经历这样的上下文流转——
1. 用户状态管理加载用户身份和权限（第11章技术）； 2. 检索记忆从数据仓库拉取上周销售数据（第8章技术）； 3. 压缩工具调用的原始返回，保留关键字段（第5章技术）； 4. 长上下文利用把这片"画布"组织好，让AI清楚地知道"现在要做什么"（第3章技术）； 5. 摘要模块把AI写完的报告浓缩成要点，回写到长期记忆（第7章、第11章技术）。
这就是上下文工程的"交响乐"——单一乐器再好，也需要指挥。
1.5 三位工程师与他们的战场
为了让抽象概念落地，本书会引入三个贯穿始终的虚构角色。他们来自不同的应用场景，有着不同的痛点，但都殊途同归地走上了"上下文工程"这条路。
小明：客服机器人开发者
小明在某电商平台做AI客服。他面临的核心问题是多轮对话的语境保持。用户的诉求常常是"我昨天买的那件衣服还没到，能退款吗"，紧接着是"如果退款的话什么时候到账"，然后是"那我能换货吗"——这一连串问题背后是一个连贯的场景。传统的"无状态"对话设计让AI经常"断片"，小明需要构建一个有状态、能记忆、能推理的客服系统。
在第11章、第12章，你会跟着小明一起设计"分层记忆架构"；在第9章，你会看到他如何用"对话式RAG"改造客服流程。
小红：代码助手构建者
小红在一家AI创业公司做AI编程助手。她的核心战场是工具调用与多步推理。当用户说"帮我重构这个模块"时，AI需要先读代码、找依赖、规划重构方案、写新代码、跑测试——每一步都涉及工具调用，每一步的输出都会污染下一步的上下文。小红需要的不是更聪明的模型，而是更聪明的"上下文编排"。
你会在第13章看到她如何设计工具调用的"上下文节流"策略；在第5章，你会学到她处理长代码上下文的"分块"技巧。
老张：企业知识库架构师
老张就是我们在1.1节认识的那位。他要做的是大规模私有知识的精准问答。他的难题在1.1已经讲过——文档量大、检索混乱、多轮失效、状态缺失。他是本书"出场"最频繁的角色。
你会在第8章看到他如何重做检索流水线；在第7章，你会看到他如何设计"文档摘要+对话摘要"的双层压缩；在第15章，你会看到他和团队最终如何把整个系统改造成一个"上下文工程"的样板间。
这三个角色不是凭空想象的——他们代表了2024-2025年AI应用开发的三大典型场景：对话密集型、工具密集型、知识密集型。他们的故事会像一条条副线，串起本书的技术主线。
读者可以根据自己的实际场景，选择"跟随"某一个角色——他们的经历会比抽象概念更容易被你内化。
1.6 阅读地图：你的15章旅程
本书的设计遵循"先打地基，再学招式，最后看实战"的逻辑。
第一部分：地基篇（第2-4章）——认知机制与物理极限
这一部分从人类认知科学出发，类比LLM的"记忆机制"；然后深入Transformer的注意力机制，解释为什么LLM会有"Lost in the Middle"现象；最后讨论长上下文窗口的物理极限——Token不是越多越好，而是有"性价比拐点"。
读完后，你会理解：为什么上下文是有限的、昂贵的、且对位置敏感的。 这一部分是后面所有技术讨论的理论基础。
第二部分：瘦身篇（第5-7章）——分块、摘要、压缩
这一部分解决"上下文装不下"的问题。第5章讲文档分块（chunking）的各种策略；第6章讲无损和有损压缩；第7章讲摘要技术——从抽取式摘要到生成式摘要，从扁平摘要到层次化摘要。
这一部分是"内功"——当你不能改变窗口大小时，就要学会把信息"压扁"。
第三部分：外挂篇（第8-10章）——RAG与检索进阶
这一部分解决"上下文装得不够"的问题。第8章从基础的向量RAG讲起；第9章讨论高级RAG技术（self-RAG、agentic RAG、graph RAG等）；第10章讨论检索质量的评估与优化。
这是2024-2025年最热的领域，但本书不会只讲"如何搭一个RAG"，而是讲"如何让RAG成为上下文工程的一部分"。
第四部分：组织篇（第11-13章）——分层记忆、状态管理、工具交互
这一部分解决"上下文如何被有序管理"的问题。第11章讲分层记忆架构（短期/长期/情景/语义）；第12章讲状态机设计与持久化；第13章讲工具调用中的上下文编排。
这是最贴近"工程实践"的部分，老张、小明、小红的核心战场就在这里。
第五部分：拓展篇（第14-15章）——多模态与未来
第14章把上下文工程拓展到多模态场景——图像、视频、音频的上下文组织；第15章展望未来——上下文工程会不会演化成一种新的"操