2025年07月07日
如何理解上下文工程（Context Engineering）？
上下文工程：构建智能LLM系统的权威指南
第一部分：从提示到系统的范式转移
本部分旨在阐明上下文工程的“是什么”与“为什么”，将其定位为人工智能发展中由日益增长的复杂性和大型语言模型（LLM）应用雄心所驱动的必然演进。
第一章 引言：超越提示
人工智能领域正经历一场深刻的范式转移，其焦点正从精心制作独立的提示（Prompt）转向系统地构建环绕于大型语言模型（LLM）的完整信息生态系统。随着AI应用从简单的聊天机器人演变为能够执行复杂、多步骤任务的智能代理（Agent），模型输出的质量越来越不依赖于某个巧妙的提示，而是取决于提供给它的信息质量 ¹。
这一转变得到了行业领袖的广泛认同。Shopify的首席执行官Tobi Lütke将这项关键技能描述为“为任务提供所有必要的上下文，使其能够被LLM合理地解决” ¹。著名AI研究者Andrej Karpathy也认可并推广了“上下文工程”（Context Engineering）这一术语，称之为“用恰到好处的信息填充上下文窗口的精妙艺术与科学” ³。这些观点共同确立了上下文工程在当前AI发展阶段的核心地位和可信度。
本报告的核心论点是：大多数智能代理的失败并非模型本身的失败，而是上下文的失败 ¹。这个论断重新定义了AI工程的核心挑战，将工程师的注意力从模型调优转向了为模型提供信息的支持系统。当一个智能代理表现不佳时，根本原因往往是模型未能获得做出正确决策所需的恰当上下文、指令和工具 ²。因此，理解和掌握上下文工程，已成为构建可靠、强大且能创造“神奇”用户体验的AI应用的先决条件。
第二章 上下文工程的定义
上下文工程（Context Engineering）并非提示工程（Prompt Engineering）的简单升级版 ⁸，而是一门独特的、系统级的工程学科 ⁹。它关注的是构建一个动态的信息供给系统，而非仅仅是优化文本输入。
综合多个权威来源，上下文工程可以被正式定义为：一门设计和构建动态系统的工程学科，旨在以正确的格式、在正确的时间，为大型语言模型（LLM）提供完成任务所需的一切信息和工具，从而确保其可靠地完成任务 ¹。
为了深入理解这一定义，我们可以将其分解为以下几个关键组成部分：
“设计和构建动态系统”：这强调了上下文工程的本质是一项工程活动，而非一种沟通技巧。它关乎系统架构，而不仅仅是巧妙的措辞 ¹。上下文本身是主LLM调用
之前运行的一个系统的输出 ¹。这意味着工程师需要构建数据管道、内存模块和信息检索机制，这些系统在运行时动态地为LLM准备其“工作记忆”。“正确的信息和工具”：这涵盖了两个方面。信息指的是事实、数据、知识库中的内容，例如通过检索增强生成（RAG）获取的文档片段或用户历史偏好。工具则指模型可以调用的能力，如API接口、函数或数据库查询功能 ¹。为模型同时提供知识和能力，是其完成复杂任务的基础。
“正确的格式、在正确的时间”：这突显了信息呈现方式和时机的重要性。在格式上，一份简洁的摘要通常优于原始的数据转储；一个清晰的工具模式（schema）比模糊的指令更有效 ¹。在
时间上，按需提供上下文至关重要，避免在不需要时用无关信息干扰模型，从而导致“上下文分心”（Context Distraction） ¹。“可靠地完成任务”：这是上下文工程的最终目标。其价值在于将AI应用从不稳定的“廉价演示品”（cheap demo）提升为能够创造“神奇产品”（magical product）的可靠系统 ¹。通过精确管理上下文，可以显著提高输出的一致性，减少幻觉（Hallucination），并支持复杂、长周期的智能代理工作流 ¹³。
第三章 从提示工程到上下文工程的演进：系统性比较
尽管上下文工程与提示工程都旨在优化LLM的输出，但二者在范围、性质和目标上存在根本区别。超越“图书管理员与提问者”的简单类比 ⁸，我们可以从系统层面进行深入比较。
范围（Scope）：提示工程通常聚焦于单次交互或单个文本字符串的优化 ¹。其目标是为特定问题找到最佳的表述方式。相比之下，上下文工程关注的是整个智能代理工作流的信息生态系统，涵盖从任务开始到结束的完整生命周期 ⁵。
动态性（Dynamism）：提示通常是静态的模板，可能包含一些变量占位符。而上下文是动态生成的，它根据当前任务的具体需求，在运行时即时组装，并随着对话的进行而不断演变 ¹。例如，处理一封邮件可能需要动态查询日历、联系人和过往邮件记录。
输入构成（Input Composition）：对于提示工程师而言，其核心工作是围绕用户的查询来构建输入。但对于上下文工程师来说，用户的查询仅仅是需要构建的庞大“上下文包”（context package）中的一个组成部分 ¹。这个包还可能包括系统指令、检索到的文档、工具的输出和对话历史等。
核心类比（Analogy）：如果说提示是演员在舞台上说的一句台词，那么上下文就是整个电影的布景、背景故事和剧本，是它们共同赋予了这句台词深刻的含义和背景 ¹⁵。
为了更清晰地展示二者的区别，下表提供了一个多维度的比较分析。
表1：提示工程与上下文工程的比较分析
| 维度 | 提示工程 (Prompt Engineering) | 上下文工程 (Context Engineering) |
|---|---|---|
| 范围 | 单次交互，单个输入字符串 | 整个智能代理工作流，完整的信息生态系统 |
| 性质 | 静态或半静态，基于模板 | 动态，实时组装，随任务演进 |
| 目标 | 引导LLM给出一次高质量的回答 | 赋能LLM可靠、持续地完成复杂任务 |
| 核心产物 | 优化的提示模板、指令集 | 数据管道、RAG系统、内存模块、状态管理器 |
| 核心技能 | 语言学、逻辑推理、指令设计 | 系统架构、数据工程、软件开发 |
| 核心类比 | 提出一个精准的问题 | 为研究员建造一座信息完备的图书馆 |
AI工程的重新定义
从提示工程到上下文工程的演变，不仅仅是术语的更替，它深刻地重塑了“AI工程师”这一角色的内涵。如果说提示工程的核心在于设计完美的输入字符串，那么其所需技能更偏向于语言学和逻辑构建。然而，当任务转变为构建能够从数据库、API、内存等多个来源动态组装这一输入字符串的系统时，核心技能便转向了软件工程和系统架构 ¹。
这一转变解释了为何像LangChain和LlamaIndex这样的框架会变得如此流行 ²。它们并非简单的“提示词助手”，而是为
上下文工程提供支持的框架。这些工具提供了构建动态上下文组装系统所需的架构模式，如链（Chains）、图（Graphs）和代理（Agents）。
因此，上下文工程的兴起标志着AI开发从一个以模型为中心的、相对小众的领域，走向了主流的软件工程学科。核心挑战不再仅仅是模型本身，而是环绕模型构建的整个应用技术栈。这要求AI工程师不仅要懂得如何调用LLM的API，更要具备构建和维护其所需的全栈基础设施的能力。
第二部分：上下文的剖析与原则
本部分将详细解构“上下文”的组成要素，并阐述有效管理上下文所需遵循的基本规则。
第四章 上下文窗口的剖析
Andrej Karpathy将LLM比作一种新型操作系统，其中LLM本身是CPU，而其上下文窗口（Context Window）则相当于计算机的RAM（随机存取存储器）⁶。上下文窗口是模型在生成回应前所能“看到”或“记住”的全部信息，是其有限的工作记忆 ¹⁷。上下文工程的艺术，就在于精确地管理这块“RAM”的内容。
一个完整的“上下文包”是提供给模型的所有信息的总和 ¹，其构成要素可以分解如下：
指令（Instructions / System Prompt）：这是上下文的基础层，是一组定义模型行为的初始指令 ¹。它设定了模型的角色（Persona）、行事风格、必须遵守的规则和约束，以及最终要实现的目标。这相当于智能代理的“宪法”或操作手册。
用户提示（User Prompt）：用户提出的直接问题或任务指令 ¹。这是触发智能代理工作的直接输入。
对话历史（Conversation History / Short-Term Memory）：在多轮对话中，之前的交流内容为当前交互提供了直接的语境 ¹。由于上下文窗口的限制，这部分内容通常需要通过修剪或摘要的方式进行管理。
长期记忆（Long-Term Memory）：这是一个跨会话的持久化知识库，记录了从多次交互中学习到的信息，如用户偏好、过往项目摘要或被明确告知需要记住的事实 ¹。
检索到的信息（Retrieved Information / RAG）：为了克服LLM的知识截止（Knowledge Cutoff）问题并使其回答基于事实，系统会动态地从外部知识源（如文档、数据库、API）中获取相关信息 ¹。这是上下文工程中最为关键的技术之一。
可用工具（Available Tools）：这部分内容定义了LLM可以调用的所有函数或内置工具的模式（Schema）和描述，例如send_email或query_database ¹。它赋予模型行动的能力，而不仅仅是知识。
工具输出（Tool Outputs）：当模型调用一个工具后，其返回的结果必须被重新注入到上下文中，以便模型能够基于该结果进行下一步的推理和行动 ⁵。
结构化输出模式（Structured Output Schema）：通过提供一个预期的输出格式定义（如JSON Schema），可以引导模型生成结构化、可预测且易于程序解析的结果 ¹。
第五章 “LLM即操作系统”框架
“LLM即操作系统”（LLM as an Operating System）这一强大的类比，为理解和实践上下文管理提供了一个坚实的理论框架 ⁶。
LLM作CPU，上下文窗口作RAM：Karpathy的这一核心类比，将上下文窗口定位为一个有限且宝贵的资源，即模型的工作记忆 ⁶。上下文工程的核心任务，就如同操作系统管理RAM一样，是高效、精确地决定哪些信息应该在何时被加载到这个工作记忆中。
内核上下文与用户上下文：Letta公司提出的框架进一步深化了这一类比，将上下文划分为两个层面，类似于传统操作系统中的内核空间和用户空间 ²¹。
内核上下文（Kernel Context）：代表智能代理的受管理、可变的持久状态。它包含了核心的内存块（Memory Blocks）和文件系统（Files），LLM可以观察这些内容，但只能通过受控的“系统调用”（System Calls），即特定的特权工具，来进行修改。这一层为代理提供了稳定性和结构化的状态管理。
用户上下文（User Context）：代表“用户空间”或消息缓冲区（Message Buffer），是动态交互发生的地方。它包含用户消息、助手回复以及对非特权的“用户程序”工具的调用。这一层为代理提供了与外部世界交互的灵活性。
系统调用与自定义工具：这一区分清晰地界定了智能代理如何与其内部状态和外部世界进行交互。系统调用（如memory_append、open_file）用于修改内核上下文，从而改变代理的持久状态。而自定义工具（如web_search、api_call）则负责将外部信息引入用户上下文，供模型在当前回合使用 ²¹。这个分层模型为构建复杂且状态一致的智能代理提供了清晰的架构指导。
第六章 上下文工程的指导原则
有效的上下文工程遵循一系列核心原则，这些原则主要源自Cognition AI等前沿实践者的经验总结，旨在构建可靠、一致的智能代理系统 ⁵。
原则一：连续与全面的上下文（Continuous and Comprehensive Context）：也被称为“看到一切”（See Everything）的理想状态。该原则要求，智能代理在执行每一步操作时，都应能访问其完整的操作历史，包括之前的用户交互、工具调用输出、内部思考过程（即“代理轨迹”），以及所有中间结果 ⁵。这能有效防止“对话遗忘症”，确保每一个决策都是在充分知情的基础上做出的。
原则二：避免无协调的并行（Avoid Uncoordinated Parallelism）：该原则指出，让多个子代理或子任务在没有一个共享且持续更新的上下文的情况下并行工作，几乎不可避免地会导致输出不一致、目标冲突和最终的失败 ⁵。每个并行的单元都在自己的信息孤岛中运作，它们的决策无法相互感知，最终导致结果的割裂。
原则三：动态与演进的上下文（Dynamic and Evolving Context）：上下文并非一成不变的静态信息块。它必须根据任务的进展动态地组装和演变 ⁵。这意味着系统必须具备在运行时（runtime）按需获取或更新信息的能力，例如从知识库中检索最新文档，或在对话中持续追踪用户的偏好变化。
原则四：完整的上下文覆盖（Full Contextual Coverage）：必须为模型提供它可能需要的所有信息，而不仅仅是用户最新的问题 ⁵。工程师需要将提供给LLM的整个输入包（包括指令、数据、历史记录等）都视为需要精心设计的“上下文”。不应让模型去猜测缺失的信息，因为这会增加幻觉和错误的风险。
上下文工程：智能代理可靠性危机的解决方案
这些原则的提出，并非纯粹的理论构建，而是对早期智能代理开发实践中“可靠性危机”的直接回应。许多早期的智能代理设计，如Auto-GPT，倾向于采用复杂的、并行的多代理架构，其核心假设是任务分解是解决复杂问题的关键。然而，实践证明，这些系统在现实场景中表现得极其脆弱和不可靠 ²²。
深入分析其失败根源，可以发现核心问题在于上下文碎片化（Context Fragmentation）。在并行架构中，每个子代理都在各自的信息孤岛中运作，缺乏对其他代理工作进展和决策的全局视野 ⁵。
上下文工程的原则，特别是“连续与全面的上下文”和“避免无协调的并行”，正是对这种早期架构思潮的深刻反思和修正。它们揭示了一个根本性的道理：系统的可靠性源于信息的一致性，而不仅仅是任务的分解。
因此，业界逐渐转向所谓的“单线程解决方案”（single-threaded solution）²²，即采用拥有统一、持续演进的上下文的线性或图状工作流。像LangGraph这样的框架正是为此而生，它通过显式的状态管理，确保了信息在代理的各个执行节点之间顺畅流动和共享 ²。
综上所述，智能代理架构从复杂的并行系统向更注重上下文共享的线性系统的演进，是上下文工程原则在实践中应用的直接结果。这门学科为构建能够在长周期任务中稳定、可靠运行的智能代理，提供了坚实的理论基础和架构范式。
第三部分：核心策略与技术实现
本部分是报告的技术核心，将详细阐述上下文工程的“如何做”，涵盖具体的方法、架构和技术细节。
第七章 上下文管理的四大支柱
为了系统地管理上下文，我们可以借鉴LangChain提出的一个清晰且实用的框架，该框架将上下文管理策略分为四大支柱：写入（Write）、选择（Select）、压缩（Compress）和隔离（Isolate） ⁶。这个分类法为我们提供了一个全面的技术路线图。
写入（Write）：持久化上下文
该策略的核心是将信息保存在即时的上下文窗口之外，以供未来使用，从而构建代理的记忆能力。暂存区（Scratchpads）：用于存储会话内的短期记忆。这就像人类在解决复杂问题时使用的草稿纸，代理可以在执行任务的过程中记录中间步骤、观察结果或临时想法 ⁶。
记忆系统（Memory Systems）：用于构建跨会话的长期记忆。这使得代理能够“记住”过去的用户偏好、项目历史或关键事实。实现技术包括“反思”（Reflection）机制，即代理自我生成记忆并在后续任务中重用，以及基于用户交互自动生成和更新的持久化记忆库 ¹。
选择（Select）：检索上下文
该策略旨在在正确的时间，将正确的信息从外部存储中拉取到上下文窗口中。从记忆/暂存区中选择：当代理需要回忆过去的知识时，它必须能够有效地查询其持久化的记忆库或暂存区 ⁶。
从工具中选择：当代理拥有大量可用工具时，一次性将所有工具的描述都放入上下文会造成干扰和资源浪费。一种高效的方法是，对工具描述本身应用RAG技术，根据当前任务动态检索并提供最相关的几个工具 ⁶。研究表明，这种方法可以将工具选择的准确率提高三倍。
从知识中选择：这是检索增强生成（RAG）的核心功能，即从外部知识库（如文档、数据库）中动态获取事实信息，以增强模型的回答能力 ⁶。
压缩（Compress）：优化上下文
该策略的目标是在保留核心信息的前提下，减少上下文所占用的令牌（token）数量，以适应有限的上下文窗口。摘要（Summarization）：利用LLM自身的能力，对冗长的对话历史、大段的文档内容或工具的详细输出进行总结，提炼出关键信息 ²。这可以是递归的或分层的，以处理极长的信息流。
修剪（Trimming）：采用基于启发式规则的方法来删减上下文。最常见的例子是，在对话历史过长时，简单地移除最早的几轮对话 ⁶。
隔离（Isolate）：分区上下文
该策略通过将上下文分解到不同的部分，来提高模型的专注度并管理任务的复杂性。多代理系统（Multi-agent Systems）：在精心设计的系统中，可以将一个大任务分解给多个子代理，每个子代理拥有自己专属的、隔离的上下文、工具和指令。这使得每个代理都能更专注于其狭窄的子任务 ⁶。
沙盒环境（Sandboxed Environments）：将消耗大量令牌的操作（如代码执行、文件处理）在一个隔离的环境中运行，只将最终的关键结果返回到主LLM的上下文中。这可以有效隔离“重型”上下文对象，保持主上下文的整洁 ⁶。
第八章 高级记忆架构
记忆是构建能够学习和适应的智能代理的关键。本节将深入探讨实现复杂记忆系统的架构，这是“写入”和“选择”策略的高级应用。
短期记忆：短期记忆主要通过对话历史缓冲区和暂存区来实现，其目标是维持单个任务或对话会话中的状态一致性 ¹。例如，在一个多步骤的预订流程中，代理需要记住用户之前选择的日期和目的地。
长期记忆：长期记忆的目标是让代理超越单次会话的限制，实现持久化的学习和个性化。
实现技术：
自动记忆生成：系统可以根据用户与代理的交互自动生成并存储记忆。例如，如果用户多次询问关于某个特定主题的问题，系统可以生成一条记忆，记录“用户对[主题]感兴趣”。像ChatGPT和Cursor等产品已经内置了此类机制 ⁶。
反思机制：代理在完成任务后，可以自我反思其行为和结果，并将学到的经验教训合成为新的记忆，供未来使用。
对话摘要：定期对过去的对话进行摘要，并将摘要作为长期记忆的一部分存储起来，以便在未来的交互中快速回顾关键信息 ²。
结构化记忆（时间知识图谱）：这是一种更为先进的记忆架构，它不仅存储事实，还存储事实之间的关系，并为每个信息点附加时间戳。这种**时间知识图谱（Temporal Knowledge Graph）**能够让系统区分信息的时效性，例如，用户的地址在去年是A，但今年更新为了B。通过这种方式，系统可以避免使用过时的信息，从而显著减少上下文冲突和矛盾，提高代理在长时间跨度内的行为一致性 ⁴。Zep等工具提供了实现此类高级记忆服务的能力 ⁴。
第九章 检索增强生成（RAG）：上下文工程的基石
检索增强生成（RAG）是上下文工程中用于“选择”外部知识的最核心、最普遍的技术。它通过将LLM与外部知识库连接，极大地扩展了模型的能力。
9.1 RAG的基础架构
一个典型的RAG系统包含三个核心阶段 ²⁴：
索引（Indexing）：这是一个离线预处理阶段。首先，将原始文档（如PDF、网页）分割成更小的、语义完整的文本块（Chunks）。然后，使用一个嵌入模型（Embedding Model）将每个文本块转换为一个高维向量。最后，将这些向量及其对应的原始文本块存储在一个专门的向量数据库（Vector Database）中。
检索（Retrieval）：当用户提出查询时，系统首先使用相同的嵌入模型将用户查询也转换为一个向量。然后，在向量数据库中进行相似性搜索，找出与查询向量最接近的N个文本块向量。这些文本块被认为是与查询最相关的内容。
生成（Generation）：最后，系统将用户的原始查询和检索到的N个相关文本块一起组合成一个新的、内容丰富的提示，并将其提交给LLM。LLM基于这个增强的上下文来生成最终的、有事实依据的回答。
9.2 高级检索与排序策略
基础的RAG架构虽然有效，但在生产环境中往往需要更复杂的策略来提升检索质量。
混合搜索（Hybrid Search）：该策略结合了两种搜索范式：语义搜索（基于向量）和关键词搜索（如传统的BM25算法）。语义搜索擅长理解概念上的相似性（例如，搜索“如何保持健康”能匹配到关于“均衡饮食和锻炼”的文档），而关键词搜索则能确保精确匹配专有名词或特定短语。将两者结合，可以取长补短，获得更全面和精准的检索结果 ²⁷。
上下文检索（Contextual Retrieval）：这是由Anthropic公司提出的一项关键创新。传统RAG直接对孤立的文本块进行嵌入，这可能导致上下文信息的丢失。上下文检索则在嵌入之前，先使用一个LLM为每个文本块生成一个简短的、描述其在整个文档中上下文的摘要。然后，对这个“文本块 + 上下文摘要”的组合进行嵌入。这种富含上下文的嵌入极大地提高了检索的准确性，实验表明，它可以将检索失败率降低高达49% ²⁸。
重排序（Re-ranking）：在检索阶段之后、生成阶段之前增加一个重排序步骤。这个步骤使用一个独立的、通常更强大的模型（如交叉编码器 Cross-Encoder）来对初步检索到的文档列表进行二次排序。重排序模型会更精细地评估每个文档与查询之间的相关性，从而将最关键的信息排在最前面，为最终的生成模型提供一个更高质量的输入 ²⁷。
9.3 RAG与微调：一个战略决策框架
对于AI架构师来说，选择RAG还是微调（Fine-tuning）来定制化LLM是一个关键的战略决策。这并非一个“非此即彼”的选择，而是根据具体需求使用正确工具的问题。
RAG的优势：
知识更新：非常适合整合实时、动态变化的知识。当外部知识库更新时，RAG系统能立即获取最新信息，而无需重新训练模型 ³²。
减少幻觉：通过提供可验证的事实依据，RAG显著降低了模型捏造事实的可能性 ³³。
数据隐私：允许企业将专有或敏感数据保留在安全的内部数据库中，只在查询时按需检索，避免了将数据用于模型训练带来的泄露风险 ³²。
成本与技能：实现成本相对较低，对数据工程和基础设施技能的要求高于对深度学习专业知识的要求 ³²。
微调的优势：
教授新技能/风格：最适合用于教模型一种新的行为模式、说话风格或特定领域的专业术语（如法律、医学）³²。微调改变的是模型的“内在能力”，而不是它所知道的“事实”。
嵌入品牌声音：可以使模型的输出在语气、格式和风格上与组织的品牌形象保持高度一致 ³³。
混合方法：最强大的系统往往是两者的结合。首先，通过微调来让模型掌握特定领域的语言和风格（学会“如何说”）。然后，在运行时使用RAG为其提供最新的事实信息（告诉它“说什么”）³³。
下表为技术领导者提供了一个清晰的决策框架，以根据项目需求选择合适的定制策略。
表2：RAG与微调的决策框架
| 决策标准（需要问的问题） | 优先考虑RAG | 优先考虑微调 | 考虑混合方案 |
|---|---|---|---|
| 回答是否必须包含实时/动态数据？ | 是 | 否 | 是 |
| 目标是教授新的风格或领域语言吗？ | 否 | 是 | 是 |
| 数据隐私和安全是否至关重要？ | 是 | 相对次要 | 是 |
| 运行时计算资源是否受限？ | 否（RAG增加运行时开销） | 是（微调增加训练开销） | 取决于具体实现 |
| 团队具备何种技能？ | 强于数据/基础设施工程 | 强于机器学习/深度学习 | 具备两种技能 |
第十章 上下文优化与过滤
即使有了强大的检索机制，如何管理有限的上下文窗口并避免常见的“上下文失败模式”仍然是一个核心挑战 ⁶。
上下文失败模式
根据Drew Breunig等人的研究，常见的上下文失败模式包括 ⁶：
上下文投毒（Context Poisoning）：当一个幻觉或错误的事实被引入上下文后，它会“毒化”后续的生成过程，导致模型基于这个错误的假设进行推理，从而产生一连串的错误。
上下文分心（Context Distraction）：当上下文中充满了大量信息，尤其是与核心任务不太相关的细节时，模型可能会“分心”，忽略了最初的关键指令。
上下文混淆（Context Confusion）：无关或多余的上下文信息可能会对模型的回答产生意想不到的负面影响，使其偏离正确的方向。
上下文冲突（Context Clash）：当上下文中的不同部分包含相互矛盾的信息时，模型会感到困惑，不知道应该相信哪一部分，最终可能导致逻辑混乱或不一致的回答。
解决方案
为了应对这些失败模式，工程师需要采用一系列优化和过滤技术。
表3：常见的上下文失败模式及其工程解决方案
[TABLE]
这些策略的核心思想是：确保进入LLM工作记忆（RAM）的每一条信息都是经过精心筛选、高度相关且格式优化的。这正是上下文工程从理论走向实践的关键所在。
第四部分：应用、挑战与未来方向
本部分将理论与实践相结合，通过具体的案例研究展示上下文工程的实际应用，同时探讨其面临的挑战、风险，并展望未来的发展趋势。
第十一章 上下文工程实践：案例研究
通过分析不同领域的应用，可以更深刻地理解上下文工程的价值和实现方式。
11.1 AI编程助手
问题：早期的AI编程实践，被戏称为“凭感觉编程”（Vibe Coding），即通过模糊、直觉式的提示与AI交互。这种方式在构建真实、可扩展的软件项目时会彻底失败，因为AI编程助手缺乏对整个代码库的上下文理解 ³。
解决方案：上下文工程将项目文档、代码规范、设计模式和需求本身视为一种需要被“工程化”的资源 ³。
构建全面的蓝图：开发者会创建详细的“产品需求提示”（PRPs - Product Requirements Prompts），其中包含了文件结构、测试要求、编码风格、依赖关系和代码示例 ³⁸。
全代码库感知：系统通过多种检索技术（如关键词搜索、嵌入式语义搜索和基于代码依赖图的图搜索）来访问和理解整个代码库，从而掌握项目特有的编程范式和依赖关系 ³⁹。
自动化上下文管理：开发的趋势正从桌面应用中需要开发者手动复制粘贴代码片段的“手动上下文管理”，转向命令行工具（CLI tools）中AI能自动分析代码库并找出所需上下文的“自动化上下文管理” ⁴⁰。
11.2 企业搜索与知识管理
问题：传统的企业搜索引擎基于关键词匹配，无法理解用户的真实意图、角色和其所处的业务背景 ⁴¹。
解决方案：上下文工程构建的智能搜索系统，能够理解谁在搜索（例如，财务部门的员工和销售部门的员工关心的“合同”截然不同）以及为什么搜索（根据用户最近的活动推断其意图）⁴¹。
注入业务背景：通过构建知识图谱、本体论等语义层，将业务上下文注入到结构化和非结构化数据中，使机器能够理解数据背后的商业逻辑 ⁴²。
整合内外信息源：利用RAG技术，从企业内部的各种知识源（如CRM、ERP、Wiki、文档管理平台）和外部数据流（如市场数据、新闻资讯、监管文件）中动态检索信息 ⁴³。
从“查找”到“综合”：这种方式将企业搜索从一个简单的信息查找工具，转变为一个能够综合多源信息、生成洞察的“研究助理” ⁴³。
11.3 自动化客户支持
问题：通用的LLM不了解特定公司的产品细节、退货政策或客户的个人历史，因此其回答往往不准确或毫无帮助 ⁴⁵。
解决方案：基于RAG的聊天机器人是上下文工程的典型应用。系统在回答用户问题前，会实时从企业的知识库（如FAQ文档、产品手册、库存数据、客户历史记录）中检索相关信息，从而提供精准、个性化且基于最新事实的回答 ⁴⁵。
- 业界实例：DoorDash和LinkedIn等公司已经部署了复杂的RAG客户支持系统。特别是LinkedIn，他们通过构建一个由过往支持工单组成的知识图谱，显著提升了检索相关解决方案的准确性，并将每个问题的平均解决时间减少了28.6% ⁴⁹。
11.4 个性化推荐引擎
问题：传统的推荐系统（如协同过滤）通常难以理解用户即时的、具体的意图，推荐结果较为宽泛。
解决方案：上下文工程利用RAG来创建动态的、对话式的个性化推荐体验。
多维上下文融合：系统会结合用户的即时上下文（当前的自然语言查询，如“给我推荐一部适合雨天看的悬疑电影”）、长期上下文（用户的历史观看记录和偏好画像）以及物品上下文（电影数据库中的详细信息），进行综合检索 ³¹。
生成式推荐：在检索到相关的候选电影后，LLM会生成一段自然的、解释性的推荐语，而不是仅仅展示一个物品列表。例如，“考虑到您喜欢希区柯克式的悬疑，并且想找一部氛围感强的电影，您可能会喜欢《后窗》……” ⁴⁷。
第十二章 缓解大型语言模型的基础缺陷
上下文工程是解决LLM两个最根本性缺陷的主要手段：幻觉和知识截止。
12.1 对抗幻觉
问题：当LLM不确定或其内部知识不包含相关事实时，它倾向于“编造”看似合理但不真实的信息，即产生幻觉 ⁵³。
解决方案：上下文工程，特别是RAG，是目前对抗幻觉最有效的策略。
提供事实依据：通过为LLM提供从可信知识库中检索到的、可验证的文档，并明确指示它仅根据这些提供的上下文来回答问题，可以极大地减少幻觉的发生 ⁵³。
诚实地“承认无知”：一个关键的设计模式是，当RAG系统未能检索到与问题相关的任何上下文时，应指示模型明确回答“我不知道”或“我无法在提供的资料中找到答案”，这远比提供一个错误的答案要好 ⁵³。
可追溯性与调试：对每一次交互中检索到的上下文和最终生成的答案进行结构化日志记录，对于调试和追踪剩余幻觉的根源至关重要 ⁵⁷。
12.2 克服知识截止
问题：LLM的知识是静态的，被“冻结”在其训练数据截止的那个时间点。因此，它对截止日期之后发生的任何事件都一无所知 ⁵⁸。
解决方案：这是上下文工程的经典应用场景。
简单修复（时间感知）：一个非常简单但有效的技巧是，在每次会话开始时，将当前日期作为一个系统消息提供给LLM。这个简单的步骤可以帮助模型将其推理和回答“锚定”在当前的时间背景下 ⁵⁸。
稳健修复（知识更新）：对于获取最新事件或数据的需求，RAG是根本性的解决方案。通过从实时更新的外部数据源（如利用Perplexity进行网络搜索 ⁶²，或连接到新闻数据库）进行信息检索，可以动态地为LLM的静态知识库“打补丁”，从而有效地绕过知识截止日期 ⁶⁰。
第十三章 挑战、陷阱与缓解措施
尽管上下文工程前景广阔，但在实践中，这种系统级的方法也带来了新的挑战和潜在的陷阱。
技术挑战
延迟与成本（Latency and Cost）：每一次的检索、摘要、重排序和LLM调用都会增加系统的响应时间和运营成本。对于需要实时交互的应用来说，优化这些数据管道的性能和成本是一个关键的工程挑战 ¹¹。
系统复杂性（Complexity）：构建和维护这些动态的上下文组装系统，远比编写一个简单的提示模板要复杂得多。它需要强大的数据架构、软件工程和DevOps技能 ²²。
上下文窗口管理（Context Window Management）：尽管模型的上下文窗口越来越大 ¹⁷，但它始终是有限的。如何通过有效的压缩、选择和过滤策略来管理这块宝贵的“RAM”，仍然是核心挑战之一 ⁶。随着上下文窗口被填满，模型的性能可能会下降，出现“大海捞针”的问题 ⁶³。
概念陷阱
上下文失败模式：如前文所述的投毒、分心、混淆和冲突等问题，是设计不良的上下文系统常见的失败原因 ⁶。
误解用户意图：如果系统在第一步就错误地理解了用户的查询意图，那么整个后续的上下文检索和组装流程都将是徒劳的，甚至会产生误导性的结果 ¹¹。
责任与信任（Responsibility and Trust）：当一个经过复杂上下文工程的系统给出了错误的建议并造成损失时，责任应该由谁承担？系统的复杂性造成了“责任分散”（problem of many hands）的困境 ⁶⁴。此外，为了建立用户信任，确保系统的透明度，让用户了解AI是基于哪些信息做出判断，变得至关重要 ¹¹。
第十四章 上下文工程的未来
上下文工程作为一个新兴的学科，仍在快速发展。未来的趋势指向更智能、更自动化和更强大的系统。
自适应与自反思系统（Adaptive and Self-Reflective Systems）：未来的智能代理将能够主动地进行自我上下文工程。这包括能够动态请求其完成任务所需上下文类型的模型，或者能够“反思”和审计自己当前上下文的自反思代理，从而主动识别和标记潜在的幻觉风险 ¹²。
多模态RAG（Multi-Modal RAG）：上下文将超越文本的范畴。未来的RAG系统将能够从图像、音频、视频甚至代码等多种模态中检索和整合信息，从而构建一个更丰富、更全面的上下文环境，以应对更复杂的现实世界问题 ²⁵。
工作流工程（Workflow Engineering）：这是在上下文工程之上的一个更高层次的抽象。工作流工程关注的不再是优化单次LLM调用的上下文，而是设计一个由多个LLM调用、工具使用和其他非LLM步骤组成的最佳序列，以可靠地完成一个复杂的宏观任务。在这个工作流中，每一步都有其自身经过完美上下文工程的输入 ²⁰。
RAG与科研的未来：RAG技术本身也在成为推动科学研究的有力工具。例如，研究人员正在探索使用RAG系统，通过分析现有科学文献的上下文，自动生成有价值的“未来工作”建议，从而加速科学发现的进程 ⁶⁵。
结论
上下文工程代表了AI应用开发领域的决定性转变，它将行业的重心从优化孤立的提示，转移到了构建为LLM提供动力的整体信息系统上。它不再是一个可选项，而是构建可靠、可扩展和真正智能的AI系统的核心纪律。
通过将LLM视为一个需要精心管理其“工作记忆”（RAM）的“操作系统”，上下文工程提供了一套系统的原则和策略——包括写入、选择、压缩和隔离——来精确控制流入模型的信息流。以RAG为代表的核心技术，有效地解决了LLM固有的幻觉和知识截止两大缺陷，使得AI系统能够基于实时、可验证的事实进行推理。
从AI编程助手到企业知识管理，再到客户支持和个性化推荐，上下文工程正在将AI从有趣的玩具转变为能够解决实际业务问题的战略资产。尽管它带来了新的技术挑战，如系统复杂性、延迟和成本，但其带来的可靠性和能力提升是无与伦-伦比的。
展望未来，该领域将朝着更加自动化和智能化的方向发展。自适应系统、多模态RAG和工作流工程等前沿方向，预示着一个AI能够更主动地管理自身上下文、更深入地理解复杂世界的新时代。最终，上下文工程的目标是实现一个终极愿景：AI系统不仅能回答问题，更能预测信息需求，维护组织记忆，并应用特定领域的逻辑，通过对上下文的深刻、工程化的理解，成为人类真正的智能伙伴 ⁴³。掌握上下文工程，就是掌握了构建下一代AI系统的钥匙。
引用的著作
The New Skill in AI is Not Prompting, It’s Context Engineering - Philschmid, 访问时间为 七月 7, 2025， https://www.philschmid.de/context-engineering
The rise of “context engineering” - LangChain Blog, 访问时间为 七月 7, 2025， https://blog.langchain.com/the-rise-of-context-engineering/
Context Engineering is the New Vibe Coding (Learn this Now) - YouTube, 访问时间为 七月 7, 2025， https://www.youtube.com/watch?v=Egeuql3Lrzg
What is Context Engineering, Anyway? - Zep, 访问时间为 七月 7, 2025， https://blog.getzep.com/what-is-context-engineering/
Context Engineering: Elevating AI Strategy from Prompt Crafting to …, 访问时间为 七月 7, 2025， https://medium.com/@adnanmasood/context-engineering-elevating-ai-strategy-from-prompt-crafting-to-enterprise-competence-b036d3f7f76f
Context Engineering - LangChain Blog, 访问时间为 七月 7, 2025， https://blog.langchain.com/context-engineering-for-agents/
Context Engineering : r/LocalLLaMA - Reddit, 访问时间为 七月 7, 2025， https://www.reddit.com/r/LocalLLaMA/comments/1lnldsj/context_engineering/
simple.ai, 访问时间为 七月 7, 2025， https://simple.ai/p/the-skill-thats-replacing-prompt-engineering#:~:text=Context%20Engineering%20is%20essentially%20a,before%20they%20even%20start%20reading.
Context Engineering: A Framework for Robust Generative AI Systems - Sundeep Teki, 访问时间为 七月 7, 2025， https://www.sundeepteki.org/blog/context-engineering-a-framework-for-robust-generative-ai-systems
Forget Prompts — It’s Context Engineering That Matters - Finance Magnates, 访问时间为 七月 7, 2025， https://www.financemagnates.com/trending/forget-prompts-its-context-engineering-that-matters/
Context Engineering: The Future of AI Prompting Explained - AI-Pro.org, 访问时间为 七月 7, 2025， https://ai-pro.org/learn-ai/articles/why-context-engineering-is-redefining-how-we-build-ai-systems/
What Is Context Engineering in AI? Techniques, Use Cases, and Why It Matters, 访问时间为 七月 7, 2025， https://www.marktechpost.com/2025/07/06/what-is-context-engineering-in-ai-techniques-use-cases-and-why-it-matters/
LLM Agent Context Engineering Principles: Robust AI Architectures - Topmost Ads, 访问时间为 七月 7, 2025， https://topmostads.com/llm-agent-context-engineering-principles-2/
What Is “Context Engineering”? Meaning & How It Works - Ramp, 访问时间为 七月 7, 2025， https://ramp.com/blog/what-is-context-engineering
What’s this ‘Context Engineering’ Everyone Is Talking About?? My Views.. : r/ClaudeAI, 访问时间为 七月 7, 2025， https://www.reddit.com/r/ClaudeAI/comments/1lnxk1r/whats_this_context_engineering_everyone_is/
Context Engineering for Agents - YouTube, 访问时间为 七月 7, 2025， https://www.youtube.com/watch?v=4GiqzUHD5AA
什么是上下文窗口？ - IBM, 访问时间为 七月 7, 2025， https://www.ibm.com/cn-zh/think/topics/context-window
What is a context window? - IBM, 访问时间为 七月 7, 2025， https://www.ibm.com/think/topics/context-window
Context Engineering — Simply Explained | by Dr. Nimrita Koul | Jun, 2025 | Medium, 访问时间为 七月 7, 2025， https://medium.com/@nimritakoul01/context-engineering-simply-explained-76f6fd1c04ee
Context Engineering - What it is, and techniques to consider - LlamaIndex, 访问时间为 七月 7, 2025， https://www.llamaindex.ai/blog/context-engineering-what-it-is-and-techniques-to-consider
Anatomy of a Context Window: A Guide to Context Engineering | Letta, 访问时间为 七月 7, 2025， https://www.letta.com/blog/guide-to-context-engineering
Context Engineering for LLM Agents: Skip Multi-Agent Complexity - Topmost Ads, 访问时间为 七月 7, 2025， https://topmostads.com/context-engineering-llm-agents/
Reducing LLM Hallucinations: A Developer’s Guide - Zep, 访问时间为 七月 7, 2025， https://www.getzep.com/ai-agents/reducing-llm-hallucinations
Retrieval-Augmented Generation: A Comprehensive Survey of Architectures, Enhancements, and Robustness Frontiers - arXiv, 访问时间为 七月 7, 2025， https://arxiv.org/html/2506.00054v1
Retrieval-Augmented Generation for Large Language … - arXiv, 访问时间为 七月 7, 2025， https://arxiv.org/pdf/2312.10997
RAG vs. Fine-tuning - IBM, 访问时间为 七月 7, 2025， https://www.ibm.com/think/topics/rag-vs-fine-tuning
Learning to Filter Context for Retrieval-Augmented Generation - DhiWise, 访问时间为 七月 7, 2025， https://www.dhiwise.com/post/learning-to-filter-context-for-retrieval-augmented-generation
Introducing Contextual Retrieval - Anthropic, 访问时间为 七月 7, 2025， https://www.anthropic.com/news/contextual-retrieval
Building a Contextual Retrieval System for Improving RAG Accuracy, 访问时间为 七月 7, 2025， https://techcommunity.microsoft.com/blog/azure-ai-services-blog/building-a-contextual-retrieval-system-for-improving-rag-accuracy/4271924
Efficient RAG with Compression and Filtering | by Kaushal Choudhary | LanceDB - Medium, 访问时间为 七月 7, 2025， https://medium.com/etoai/enhance-rag-integrate-contextual-compression-and-filtering-for-precision-a29d4a810301
Advanced RAG for Search and Recommendations with personalization | by Byte-Sized AI Blog | Medium, 访问时间为 七月 7, 2025， https://medium.com/@mksupriya2/advanced-rag-for-search-and-recommendations-with-personalization-9b0b5e337ffc
RAG vs. Fine-Tuning: How to Choose | Oracle India, 访问时间为 七月 7, 2025， https://www.oracle.com/in/artificial-intelligence/generative-ai/retrieval-augmented-generation-rag/rag-fine-tuning/
RAG vs. LLM fine-tuning: Which is the best approach? - Glean, 访问时间为 七月 7, 2025， https://www.glean.com/blog/rag-vs-llm
RAG vs Fine-Tuning: Navigating the Path to Enhanced LLMs - Iguazio, 访问时间为 七月 7, 2025， https://www.iguazio.com/blog/rag-vs-fine-tuning/
RAG vs. fine-tuning - Red Hat, 访问时间为 七月 7, 2025， https://www.redhat.com/en/topics/ai/rag-vs-fine-tuning
Fine-Tuning vs RAG: Key Differences Explained (2025 Guide) - Orq.ai, 访问时间为 七月 7, 2025， https://orq.ai/blog/finetuning-vs-rag
Context Engineering — The Hottest Skill in AI Right Now - YouTube, 访问时间为 七月 7, 2025， https://www.youtube.com/watch?v=ioOHXt7wjhM
coleam00/context-engineering-intro: Context engineering is the new vibe coding - it’s the way to actually make AI coding assistants work. Claude Code is the best for this so that’s what this repo is centered around, but you can apply this strategy with any AI coding assistant! - GitHub, 访问时间为 七月 7, 2025， https://github.com/coleam00/context-engineering-intro
Lessons from Building AI Coding Assistants: Context Retrieval and Evaluation | Sourcegraph Blog, 访问时间为 七月 7, 2025， https://sourcegraph.com/blog/lessons-from-building-ai-coding-assistants-context-retrieval-and-evaluation
Context Engineering Across AI Code Generators - Varun Singh, 访问时间为 七月 7, 2025， https://www.varunsingh.net/post/context-engineering-across-ai-code-generators
It’s all about context: Why context is crucial for effective enterprise search | IntraFind, 访问时间为 七月 7, 2025， https://intrafind.com/en/blog/it-is-all-about-context
Enterprise AI Architecture Series: How to Inject Business Context into Structured Data using a Semantic Layer (Part 3), 访问时间为 七月 7, 2025， https://enterprise-knowledge.com/enterprise-ai-architecture-inject-business-context-into-structured-data-semantic-layer/
Context Engineering: A Framework for Enterprise AI Operations | Shelly Palmer, 访问时间为 七月 7, 2025， https://shellypalmer.com/2025/06/context-engineering-a-framework-for-enterprise-ai-operations/
Top Enterprise Search Use Cases - AlphaSense, 访问时间为 七月 7, 2025， https://www.alpha-sense.com/blog/product/enterprise-search-use-cases/
RAG in Customer Support: Enhancing Chatbots and Virtual Assistants - Signity Solutions, 访问时间为 七月 7, 2025， https://www.signitysolutions.com/blog/rag-in-customer-support
RAG chatbot: What it is, benefits, challenges, and how to build one - Tonic.ai, 访问时间为 七月 7, 2025， https://www.tonic.ai/guides/rag-chatbot
Top 7 RAG Use Cases and Applications to Explore in 2025 - ProjectPro, 访问时间为 七月 7, 2025， https://www.projectpro.io/article/rag-use-cases-and-applications/1059
RAG in Chatbots: Revolutionizing Customer Service - Valanor, 访问时间为 七月 7, 2025， https://valanor.co/rag-in-chatbots/
10 RAG examples and use cases from real companies - Evidently AI, 访问时间为 七月 7, 2025， https://www.evidentlyai.com/blog/rag-examples
Enhancing Recommendation Systems with RAG - MyScale, 访问时间为 七月 7, 2025， https://myscale.com/blog/rag-enhances-recommendation-systems-personalization/
RAG for RecSys: a magic formula? | Shaped Blog, 访问时间为 七月 7, 2025， https://www.shaped.ai/blog/rag-for-recsys-a-magic-formula
Case Studies - Gen AI – Personalized Recommendation, 访问时间为 七月 7, 2025， https://www.factored.ai/case-studies/recommender-generative-ai
Advanced Prompt Engineering for Reducing Hallucination | by Bijit Ghosh | Medium, 访问时间为 七月 7, 2025， https://medium.com/@bijit211987/advanced-prompt-engineering-for-reducing-hallucination-bb2c8ce62fc6
Beyond Traditional Fine-tuning: Exploring Advanced Techniques to Mitigate LLM Hallucinations - Hugging Face, 访问时间为 七月 7, 2025， https://huggingface.co/blog/Imama/pr
Preventing LLM Hallucination With Contextual Prompt Engineering — An Example From OpenAI | by Cobus Greyling, 访问时间为 七月 7, 2025， https://cobusgreyling.medium.com/preventing-llm-hallucination-with-contextual-prompt-engineering-an-example-from-openai-7e7d58736162
Trapping LLM “Hallucinations” Using Tagged Context Prompts - arXiv, 访问时间为 七月 7, 2025， https://arxiv.org/pdf/2306.06085
How Contextual Errors Lead to LLM Hallucination—and How to Fix Them - LLUMO AI, 访问时间为 七月 7, 2025， https://www.llumo.ai/blog/how-contextual-errors-lead-to-llm-hallucinationand-how-to-fix-them-contextual-hallucination
Solving the LLM Knowledge Cutoff Issue with One Simple Message - Medium, 访问时间为 七月 7, 2025， https://medium.com/@scott.boring.sb/solving-the-llm-knowledge-cutoff-issue-with-one-simple-message-2c6fa811694c
Key Concepts and Considerations in Generative AI | Microsoft Learn, 访问时间为 七月 7, 2025， https://learn.microsoft.com/en-us/azure/developer/ai/gen-ai-concepts-considerations-developers
Essential LLM Guide for Beginners: Understanding Knowledge Cutoff, Context Window, and Prompt Engineering, 访问时间为 七月 7, 2025， https://jsonobject.hashnode.dev/essential-llm-guide-for-beginners-understanding-knowledge-cutoff-context-window-and-prompt-engineering
Ep 153: Knowledge Cutoff - What it is and why it matters for large language models, 访问时间为 七月 7, 2025， https://www.youreverydayai.com/knowledge-cutoff-what-it-is-and-why-it-matters-for-large-language-models/
Knowledge cutoff date (my biggest problem with LLMs) : r/ChatGPTCoding - Reddit, 访问时间为 七月 7, 2025， https://www.reddit.com/r/ChatGPTCoding/comments/1flx5zn/knowledge_cutoff_date_my_biggest_problem_with_llms/
What does large context window in LLM mean for future of devs? - Reddit, 访问时间为 七月 7, 2025， https://www.reddit.com/r/ExperiencedDevs/comments/1jwhsa9/what_does_large_context_window_in_llm_mean_for/
Full article: Challenges and future directions for integration of large language models into socio-technical systems - Taylor & Francis Online, 访问时间为 七月 7, 2025， https://www.tandfonline.com/doi/full/10.1080/0144929X.2024.2431068
FutureGen: LLM-RAG Approach to Generate the Future Work of Scientific Article - arXiv, 访问时间为 七月 7, 2025， https://arxiv.org/abs/2503.16561