解构上下文工程：智能LLM系统新视角

人工智能领域正经历一场变革，焦点从优化独立的提示语转向系统地构建围绕大型语言模型（LLM）的信息生态。随着AI应用从简单的聊天机器人进化为能够执行复杂任务的智能代理，模型输出的质量不再仅仅依赖于单一提示，而是更多地取决于所提供信息的质量。

上下文工程的演进：从提示到系统的范式转变

超越提示的时代

行业领袖普遍认为，为 LLM 提供完成任务所需的上下文信息是关键技能。Andrej Karpathy 将“上下文工程”定义为“用恰当的信息填充上下文窗口的艺术与科学”。这表明上下文工程在当前 AI 发展阶段占据核心地位。

本报告的核心观点是：大多数智能代理的失败并非源于模型本身，而是上下文的缺失。因此，AI 工程的核心挑战已转变为构建为模型提供信息的支持系统。当智能代理表现不佳时，通常是因为模型缺乏做出正确决策所需的上下文、指令和工具。理解和掌握上下文工程已成为构建可靠、强大且能创造卓越用户体验的 AI 应用的前提。

上下文工程：一种系统性的学科

上下文工程不仅仅是提示工程的简单升级，而是一门独特的系统级学科。它关注构建一个动态的信息供给系统，而非仅仅优化文本输入。上下文工程可定义为：一门旨在以正确的格式、在正确的时间，为 LLM 提供完成任务所需的一切信息和工具，从而确保其可靠完成任务的工程学科。

为了深入理解这一定义，我们可以将其分解为以下几个关键组成部分：

• 设计和构建动态系统：上下文工程是一项 工程 活动，而非一种沟通技巧。它关乎系统架构，而不仅仅是巧妙的措辞。上下文本身是主 LLM 调用 之前 运行的一个系统的 输出。这意味着工程师需要构建数据管道、内存模块和信息检索机制，这些系统在运行时动态地为 LLM 准备其“工作记忆”。
• 正确的信息和工具：这涵盖了两个方面。信息 指的是事实、数据、知识库中的内容，例如通过检索增强生成（RAG）获取的文档片段或用户历史偏好。工具 则指模型可以调用的能力，如 API 接口、函数或数据库查询功能。为模型同时提供知识和能力，是其完成复杂任务的基础。
• 正确的格式、在正确的时间：信息呈现方式和时机非常重要。在 格式 上，一份简洁的摘要通常优于原始的数据转储；一个清晰的工具模式（schema）比模糊的指令更有效。在 时间 上，按需提供上下文至关重要，避免在不需要时用无关信息干扰模型，从而导致“上下文分心”。
• 可靠地完成任务：这是上下文工程的最终目标。其价值在于将 AI 应用从不稳定的“廉价演示品”提升为能够创造“神奇产品”的可靠系统。通过精确管理上下文，可以显著提高输出的一致性，减少幻觉，并支持复杂、长周期的智能代理工作流。

提示工程与上下文工程的系统性比较

尽管上下文工程与提示工程都旨在优化 LLM 的输出，但二者在范围、性质和目标上存在根本区别。我们可以从系统层面进行深入比较。

• 范围（Scope）：提示工程通常聚焦于单次交互或单个文本字符串的优化。其目标是为特定问题找到最佳的表述方式。相比之下，上下文工程关注的是整个智能代理工作流的信息生态系统，涵盖从任务开始到结束的完整生命周期。
• 动态性（Dynamism）：提示通常是静态的模板，可能包含一些变量占位符。而上下文是动态生成的，它根据当前任务的具体需求，在运行时即时组装，并随着对话的进行而不断演变。例如，处理一封邮件可能需要动态查询日历、联系人和过往邮件记录。
• 输入构成（Input Composition）：对于提示工程师而言，其核心工作是围绕用户的查询来构建输入。但对于上下文工程师来说，用户的查询仅仅是需要构建的庞大“上下文包”（context package）中的一个组成部分。这个包还可能包括系统指令、检索到的文档、工具的输出和对话历史等。
• 核心类比（Analogy）：如果说提示是演员在舞台上说的一句台词，那么上下文就是整个电影的布景、背景故事和剧本，是它们共同赋予了这句台词深刻的含义和背景。

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。通过这种方式，系统可以避免使用过时的信息，从而显著减少上下文冲突和矛盾，提高代理在长时间跨度内的行为一致性。

检索增强生成（RAG）：上下文工程的基石

检索增强生成（RAG）是上下文工程中用于“选择”外部知识的核心技术。它通过将 LLM 与外部知识库连接，极大地扩展了模型的能力。

RAG 的基础架构

一个典型的 RAG 系统包含三个核心阶段：

1. 索引（Indexing）：这是一个离线预处理阶段。首先，将原始文档（如 PDF、网页）分割成更小的、语义完整的文本块（Chunks）。然后，使用一个嵌入模型（Embedding Model）将每个文本块转换为一个高维向量。最后，将这些向量及其对应的原始文本块存储在一个专门的向量数据库（Vector Database）中。
2. 检索（Retrieval）：当用户提出查询时，系统首先使用相同的嵌入模型将用户查询也转换为一个向量。然后，在向量数据库中进行相似性搜索，找出与查询向量最接近的 N 个文本块向量。这些文本块被认为是与查询最相关的内容。
3. 生成（Generation）：最后，系统将用户的原始查询和检索到的 N 个相关文本块一起组合成一个新的、内容丰富的提示，并将其提交给 LLM。LLM 基于这个增强的上下文来生成有事实依据的回答。

高级检索与排序策略

基础的 RAG 架构虽然有效，但在生产环境中往往需要更复杂的策略来提升检索质量。

• 混合搜索（Hybrid Search）：该策略结合了两种搜索范式：语义搜索（基于向量）和 关键词搜索（如传统的 BM25 算法）。语义搜索擅长理解概念上的相似性，而关键词搜索则能确保精确匹配专有名词或特定短语。将两者结合，可以取长补短，获得更全面和精准的检索结果。

• 上下文检索（Contextual Retrieval）：由 Anthropic 公司提出的一项创新：传统 RAG 直接对孤立的文本块进行嵌入，可能导致上下文信息的丢失。上下文检索则在嵌入之前，先使用一个 LLM 为每个文本块生成一个简短的摘要，描述其在 整个文档中上下文。然后，对这个“文本块 + 上下文摘要”的组合进行嵌入。这种富含上下文的嵌入极大地提高了检索的准确性。

• 重排序（Re-ranking）：在检索阶段之后、生成阶段之前增加一个重排序步骤。重排序模型会精细地评估每个文档与查询之间的相关性，从而将最关键的信息排在最前面，为最终的生成模型提供一个更高质量的输入。

RAG 与微调：一个战略决策框架

对于 AI 架构师来说，选择 RAG 还是微调（Fine-tuning）来定制 LLM 是一个战略决策。这并非一个“非此即彼”的选择，而是根据具体需求使用正确工具的问题。

• RAG 的优势：

  • 知识更新：非常适合整合实时、动态变化的知识。当外部知识库更新时， RAG 系统能立即获取最新信息，而无需重新训练模型。
  • 减少幻觉：通过提供可验证的事实依据， RAG 显著降低了模型捏造事实的可能性。
  • 数据隐私：允许企业将专有或敏感数据保留在安全的内部数据库中，只在查询时按需检索，避免了将数据用于模型训练带来的泄露风险。
  • 成本与技能：实现成本相对较低，对数据工程和基础设施技能的要求高于对深度学习专业知识的要求。

• 微调的优势：

  • 教授新技能/风格：最适合用于教模型一种新的行为模式、说话风格或特定领域的专业术语（如法律、医学）。微调改变的是模型的“内在能力”，而不是它所知道的“事实”。
  • 嵌入品牌声音：可以使模型的输出在语气、格式和风格上与组织的品牌形象保持高度一致。

• 混合方法：最强大的系统往往是两者的结合。首先，通过 微调 来让模型掌握特定领域的语言和风格（学会“如何说”）。然后，在运行时使用 RAG 为其提供最新的事实信息（告诉它“说什么”）。

上下文优化与过滤

即使有了强大的检索机制，管理有限的上下文窗口并避免常见的“上下文失败模式”仍然是一个挑战。

上下文失败模式

根据研究，常见的上下文失败模式包括：

• 上下文投毒（Context Poisoning）：当幻觉或错误的事实被引入上下文后，会“毒化”后续的生成过程，导致模型基于错误的假设进行推理，产生一连串错误。
• 上下文分心（Context Distraction）：当上下文中充满了大量信息， 尤其是与核心任务不太相关的细节时，模型可能会“分心”，忽略了最初的关键指令。
• 上下文混淆（Context Confusion）：无关或多余的上下文信息可能会对模型的回答产生意想不到的负面影响，使其偏离正确的方向。
• 上下文冲突（Context Clash）：当上下文中的不同部分包含相互矛盾的信息时，模型会感到困惑，不知道应该相信哪一部分，最终可能导致逻辑混乱或不一致的回答。

解决方案

为了应对这些失败模式，工程师需要采用一系列优化和过滤技术。总的来说，确保进入 LLM 工作记忆（RAM）的每一条信息都是经过精心筛选、高度相关且格式优化的。