从“炼丹”到“建厂”：为什么说上下文工程（Context Engineering）才是AI应用的未来？
2025-7-10
| 2025-7-10
字数 5853阅读时长≈ 15 分钟
password
icon
AI summary
type
status
date
slug
summary
tags
category
在过去一年中，当我们审视业界对“提示工程”（Prompt Engineering）的讨论时，一个微妙但至关重要的分歧正在浮现。
一方面，像 Andrej Karpathy 这样的前沿实践者们正积极倡导使用“上下文工程”（Context Engineering）来更准确地描述他们的工作。他们认为，“提示工程”这个词远不足以涵盖构建可扩展 AI 系统所面临的复杂性，甚至略带嘲讽地称其为“给在聊天框里打字起的一个可笑又自命不凡的名字” (a laughably pretentious name for typing in the chat box)。 对他们而言，构建 Agent 系统的核心挑战并非雕琢静态的提示词，而是设计一整套能够动态生成最终上下文的数据架构与信息流。
另一方面，学术界和许多入门文献倾向于将“提示工程”作为一个广义的“伞形术语”（Umbrella Term），其定义宽泛到足以包括“支持性内容”或“上下文”。在这种视角下，所有在不改变模型权重的前提下操纵模型输入的技术，都被归为提示工程。
这种术语上的分歧，深刻地反映了该领域的成熟过程。随着 AI 应用从简单的单次问答，演进为需要处理复杂任务、管理长期记忆的智能体（Agent）系统，单纯优化静态指令的“炼丹术”已经捉襟见肘。“上下文工程”的出现，正是为了清晰地界定两种层次截然不同的活动：
  1. 编写指令的“技艺”（The Art of Instruction）：一种依赖直觉和反复试验的战术性技巧。
  1. 构建信息系统的“工程”（The Science of Architecture）：一门设计自动化、可扩展系统，为 AI 提供成功所需知识与工具的战略性学科。
本报告明确：尽管在学术定义上“提示工程”可能涵盖上下文，但在现代 AI 的工程实践中，上下文工程是一门专注于如何动态构建、管理和优化信息流的独立且更高阶的学科。从前者到后者的转变，代表了 AI 应用开发领域一次关键的演进——从业界最初关注的战术性指令构建，转向由可扩展、高可靠性系统需求驱动的战略性架构设计。

第一章：重新定义 Agent 数据流：上下文即一切 (Context is All You Need)

本章旨在建立“提示工程”与“上下文工程”的基础概念，并清晰界定二者的区别与联系。

1.1 提示工程：指令的“技艺”

提示工程是与大语言模型（LLM）交互的基础，其核心在于精心设计输入文本，以引导模型生成期望的输出。
定义
一个“提示”（Prompt）远不止一个简单的问题。它是一个结构化的输入，通常包含以下组件：
  • 指令 (Instructions)：告知模型需要执行的核心任务。
  • 主要内容/输入数据 (Primary Content/Input Data)：模型需要处理的文本或数据。
  • 示例 (Examples/Shots)：通过“上下文学习”（In-Context Learning）展示期望的输入输出格式。
  • 线索/输出指示器 (Cues/Output Indicators)：引导模型开始生成或遵循特定格式（如 JSON）的词语。
  • 支持性内容 (Supporting Content/Context)：为模型提供的额外背景信息，这正是“上下文工程”发展的概念萌芽。
核心技术
Prompt Engineer 运用一系列技术来优化输出，包括：
  • 零样本/少样本提示 (Zero/Few-Shot Prompting)：依赖模型预训练知识或提供少量示例进行学习。
  • 思维链 (Chain-of-Thought, CoT)：引导模型分解问题，进行逐步推理，显著提升逻辑和数学能力。
  • 高级推理技术：如思维树（Tree-of-Thought）、由简到繁提示（Least-to-Most Prompting）等，探索更复杂的解题路径。
“以提示为中心”方法的局限性
  • 脆弱性：微小的措辞变化可能导致结果剧变，使其更像一门“艺术”而非可复现的“科学”。
  • 扩展性差：手动迭代优化的过程，在面对海量用户和多样化场景时难以为继。
  • 用户负担：将构建详尽指令的负担完全压在用户身上，对于需要自主运行的系统而言不切实际。
  • 无状态性：本质上为单轮、“一次性”交互设计，难以处理需要记忆和状态管理的多步骤任务。

1.2 上下文工程的兴起：从“指令”到“环境”的范式转移

上下文工程并非要取代提示工程，而是一个更高阶、更侧重于系统设计的必要学科。它承认，在工业级应用中，影响模型输出的远不止那一句指令。
定义：上下文工程 (Context Engineering)
一门设计、构建并优化自动化系统的学科，旨在为大型语言模型在正确的时间、以正确的格式，提供正确的知识与工具，从而可靠、可扩展地完成复杂任务。
如果说提示工程告诉模型如何思考，那么上下文工程则为模型提供了完成工作所需的知识和工具。
“上下文”的范畴
在上下文工程的视野里，“上下文”是一个完整的信息生态系统，涵盖了 LLM 在响应前看到的一切：
  • 系统级指令和角色设定。
  • 持久化的用户偏好与事实（长期记忆）。
  • 动态检索的外部数据（如 RAG 系统获取的信息）。
  • 可用的工具（API、函数）及其描述。
  • 期望的输出格式（如 JSON Schema）。

1.3 对比分析：战术 vs. 战略

关系：超集，而非竞争
提示工程是上下文工程的一个子集和最后环节。
  • 上下文工程 决定用什么内容填充上下文窗口 (Context Window)。
  • 提示工程 则负责优化窗口内那部分具体的指令文本。
比较维度
提示工程 (Prompt Engineering)
上下文工程 (Context Engineering)
主要目标
获取特定的、一次性的响应
确保系统在不同会话和用户间表现一致、可靠
核心动作
创意写作、措辞优化 (wordsmithing)
系统设计、LLM 应用软件架构
范围
单个输入-输出对
整个信息流，包括记忆、工具、历史记录
模式
制作清晰的指令
设计模型的完整思考环境
扩展性
脆弱，难以规模化
从设计之初就为规模化和可重用性而构建
所需工具
文本编辑器、聊天界面
RAG 系统、向量数据库、API 链、记忆模块等
调试方法
重写措辞、猜测模型行为
检查完整的上下文窗口、数据流、Token 使用情况

第二章：上下文工程的基石：RAG 架构演进

本章将阐述检索增强生成（RAG）作为实现上下文工程的关键架构模式，并探讨其从简单到复杂的演进路径。

2.1 RAG：不仅仅是检索

RAG 不仅是一种技术，更是现代上下文工程系统的基础架构，因为它直接解决了 LLM 的三大核心弱点：
  • 知识冻结：通过在推理时注入实时信息来解决知识过时问题。
  • 缺乏领域知识：将 LLM 连接到组织的内部私有数据。
  • 幻觉 (Hallucination)：通过将模型的回答“锚定”在可验证的证据上，提高事实准确性。
RAG 的工作流程
  1. 索引 (离线)：处理外部知识源，将其分割成块（Chunks），通过嵌入模型转换为向量，并存储于向量数据库中。
  1. 推理 (在线)：
    1. 检索 (Retrieve)：将用户查询转换为向量，在数据库中搜索最相关的文档块。
    2. 增强 (Augment)：将检索到的文档块与原始查询结合，构建一个内容丰富的最终提示。
    3. 生成 (Generate)：将增强后的提示送入 LLM，生成有理有据的回答。

2.2 RAG 的演进：从朴素到智能体化

RAG 自身也在快速进化，从简单的检索发展为复杂的、模块化的系统：
  • Naive RAG (朴素 RAG)：即上述基础实现，适用于简单的问答场景。
  • Advanced RAG (高级 RAG)：在检索前后引入优化步骤以提升质量。
    • 检索前处理：优化查询（如 HyDE、Step-Back Prompting）或改进文本分块策略。
    • 检索后处理：对检索到的文档进行重排序（Re-ranking）以提升相关性，或进行压缩（Compression）以适应上下文窗口。
  • Modular RAG (模块化 RAG)：将 RAG 视为可互换的模块化系统，催生了更复杂的模式。
    • 带记忆的 RAG：融合对话历史，处理多轮交互。
    • 路由 RAG：引入路由模块，根据查询意图决定使用哪个数据源或检索器。
    • 纠正性 RAG (Corrective RAG, CRAG)：增加一个评估器，如果检索质量不佳，则触发网络搜索等替代策略。
  • Agentic RAG (智能体 RAG)：这是 RAG 的顶峰形态。它将 RAG 集成到一个智能体循环（Agentic Loop）中，模型能够主动规划多步骤任务，与多个数据源和工具交互，并随时间推移综合信息。这正是上下文工程在实践中的终极体现。

2.3 向量数据库：上下文工程的“新基建”

本节分析支撑 RAG “检索”步骤的关键基础设施——向量数据库。

新兴的“上下文堆栈” (Context Stack)

观察一个完整的 RAG 系统，我们会发现其组件形成了一个连贯的多层次架构：数据摄入、分块、嵌入、向量数据库（索引与检索）、重排序器、压缩器，最后是 LLM。 这个清晰的数据流可以被抽象地称为“上下文堆栈”。
这个堆栈的出现标志着 AI 应用开发正在走向成熟。不同的技术供应商开始专注于堆栈中的特定层面：
  • 数据库层 (Database Layer)：Pinecone, Weaviate, Milvus, Qdrant
  • 应用编排层 (Orchestration Layer)：LangChain, LlamaIndex
  • 专用模块层 (Specialized Modules)：Cohere (重排序), Jina AI (嵌入)
因此，理解新的 AI Agent 架构，就意味着要理解这个新兴的上下文堆栈，了解其各个层次以及不同组件间的权衡。这对于工程师和架构师进行技术选型至关重要。

向量数据库选型考量

数据库
关键差异点
理想用例
Pinecone
全托管、Serverless、API 简单、低延迟
需要快速部署、零运维、实时应用的团队
Weaviate
内置模块化、原生混合搜索、多模态支持
需要结合关键词过滤、处理图文等多模态数据的复杂应用
Milvus
为大规模设计、支持多种索引算法、高吞吐量
需要处理海量（数十亿级）向量的企业级应用
Qdrant
强调高级过滤和有效载荷 (payloads)、内存效率
需要基于复杂元数据进行精确过滤的场景

第三章：上下文工程化：如何精选信息进入窗口？

本章探讨上下文工程的核心挑战：在有限的上下文窗口内，如何判断和提取最有价值的信息。

3.1 从原始数据到相关分块

高级分块策略

分块（Chunking）是 RAG 流程中最关键也最容易被忽视的一步。糟糕的分块会破坏语义完整性。
  • 内容感知分块：
    • 递归字符分割：按段落、句子、单词的层次结构进行分割，尽可能保持文本结构。
    • 文档特定分块：利用 Markdown 标题、代码函数或法律条款等文档自身结构进行分割。
  • 语义分块 (Semantic Chunking)：最先进的方法之一，使用嵌入模型检测文本中语义主题的转变点，确保每个分块在主题上高度内聚。

通过重排序提升精度

检索的“召回”与“精排”：
  1. 第一阶段 (召回)：使用向量搜索等快速方法，广泛召回大量（如前 100 个）候选文档。
  1. 第二阶段 (精排/重排序)：使用计算成本更高但更强大的交叉编码器（Cross-Encoder）模型，对候选集进行重新打分，选出最相关的少数几个（如前 5 个）文档。
交叉编码器之所以效果更好，是因为它将查询和文档同时输入模型进行深度交互，能捕捉更细微的语义关系。

3.2 核心困境：“迷失在中间” (Lost in the Middle)

上下文工程必须面对 LLM 的一个根本性认知局限。
  • 定义：LLM 在处理长上下文时，表现出一种 U 型性能曲线。当关键信息位于上下文窗口的开头或结尾时，模型能高效利用；而当关键信息被“埋藏”在中间时，模型性能会显著下降。
  • 启示：简单地将所有可能相关的信息塞进上下文窗口是适得其反的。这不仅会因引入无关信息而分散模型注意力，还可能导致关键信息因处于“中间地带”而被忽略。
上下文工程的核心矛盾： 一方面，我们需要提供丰富全面的上下文以获得高质量响应。另一方面，LLM 的上下文窗口有限，且存在“迷失在中间”等认知缺陷，过长的上下文反而会降低性能。
所有高级的上下文工程技术——无论是重排序、压缩还是智能体隔离——其根本目的都是为了有效管理这一矛盾。

3.3 优化上下文窗口：压缩与摘要

这些技术用于主动管理上下文，确保最有价值的信息被优先呈现。
  • 上下文压缩：旨在缩短或精简检索到的文档，只将最相关的信息传递给 LLM，以降低成本、延迟，并缓解“迷失在中间”的问题。
    • 过滤式压缩：用一个 LLM 或嵌入相似度对每个文档的相关性做“是/否”判断。
    • 内容提取式压缩：遍历每个文档，用 LLM 从中提取仅与查询相关的句子。
  • 摘要作为压缩策略：对于非常长的文档或对话历史，可以利用 LLM 生成摘要注入上下文，这在长时程运行的智能体中至关重要。

3.4 智能体系统的上下文管理

智能体（Agent）的出现，将上下文管理提升到了一个新高度。它不再是手动的试错，而是构建一个自动化的在环系统（System-in-the-Loop），在 LLM 看到提示之前就为其准备好一切。

智能体上下文管理框架

LangChain 等框架提出了一个包含四种策略的上下文管理模型：
  • 写入 (Write)：将信息持久化。
    • 便笺 (Scratchpads)：会话内的临时记忆，用于记录中间步骤。
    • 记忆 (Memory)：跨会话的长期存储，记录关键事实或用户偏好。
  • 选择 (Select)：动态检索上下文。
    • 根据当前子任务，使用 RAG 从知识库、工具库或记忆中选择最相关的信息。
  • 压缩 (Compress)：优化上下文。
    • 利用摘要或修剪技术管理不断增长的上下文，防止窗口溢出和“迷失在中间”。
  • 隔离 (Isolate)：分割上下文。
    • 多智能体系统：将复杂问题分解，分配给拥有独立、聚焦上下文的子智能体。
    • 沙盒环境：在隔离环境中执行工具调用，只将必要的执行结果返回主上下文窗口。

第四章：超越检索：智能体架构中的数据流编排

随着 LLM 从被动的“响应者”演变为主动的“执行者”（即 AI Agent），其核心挑战从“信息检索”转向了对内部工作流与数据流的精心设计与编排。

4.1 工作流 (Workflow) vs. 智能体 (Agent)

在架构层面，我们可以对智能体系统进行两种区分：
  • 工作流 (Workflows)：遵循预定义的、确定性的代码路径。数据流向是固定的，适用于可靠性要求高的任务。
  • 智能体 (Agents)：由 LLM 在运行时动态地指导决策。数据流向不确定，适用于需要探索和适应性的任务。
复杂的系统通常是二者的混合体。管理这一切的核心，我们称之为编排层 (Orchestration Layer)。

4.2 核心架构模式

  1. 链式工作流 (Prompt Chaining)
      • 数据流：输入 -> 模块A -> 输出A -> 模块B -> ...
      • 工作原理：将任务分解为一系列线性的、顺序执行的模块。
  1. 路由工作流 (Routing)
      • 数据流：输入 -> 路由器 -> [模块A | 模块B | 模块C] -> 输出
      • 工作原理：一个“路由器”LLM 负责分析输入，并决策接下来应调用哪个具体模块。
  1. 编排器-工作者模式 (Orchestrator-Workers / Multi-agent)
      • 数据流：一个中心的“编排器”智能体分解总任务，并将子任务分发给多个专职的“工作者”智能体，最后汇总结果。
      • 工作原理：每个工作者拥有独立的上下文和工具，专注于特定领域，实现高度的模块化和关注点分离。

4.3 决策与规划机制

在上述架构中，智能体如何决定“下一步做什么”？
  • ReAct (Reason + Act) 框架：这是许多现代智能体的基础推理循环。
      1. 思考 (Thought)：LLM 分析当前任务和信息，制定行动计划。
      1. 行动 (Action)：LLM 决定调用一个工具并生成所需参数。
      1. 观察 (Observation)：系统执行工具，并将结果返回给 LLM。
      1. LLM 接收新观察，再次进入思考环节，直至任务完成。
  • 规划 (Planning) 与反思 (Reflection)
    • 对于更复杂的任务，智能体首先会进行规划，将宏大目标分解为一系列子任务清单。
    • 先进的智能体还包含反思机制，在执行后评估结果质量，如果发现问题，可以自我修正，重新规划路径，形成反馈循环。

4.4 框架与工具：以 LangGraph 为例

这些复杂的架构模式需要强大的框架来支持。LangGraph 作为 LangChain 的扩展，通过将智能体应用构建成一个状态图 (State Graph)，完美地解决了数据流编排问题。
  • 状态 (State)：一个所有节点共享的中央数据对象。
  • 节点 (Nodes)：代表工作流中的一个计算步骤（如调用 LLM 或工具）。
  • 边 (Edges)：定义数据在节点间的流向。
    • 条件边 (Conditional Edges)：实现路由逻辑的关键，根据一个节点的输出来决定图的下一跳走向。
  • 检查点 (Checkpointer)：提供持久化机制，自动保存每一步的状态，支持构建可中断、可恢复的长时间运行任务。
与其他 Agent 框架如 CrewAI 相比，LangGraph 提供了更底层的控制，允许开发者以图的形式精确定义循环和分支，而 CrewAI 则提供了更高层次的抽象，专注于角色扮演和任务委派。 选择哪种框架取决于应用所需的控制粒度和开发速度。

第五章：上下文工程的未来：更智能的桥梁

上下文工程本质上是一座复杂的桥梁，是一套用以弥补 “LLM 不会读心术，它们只会读 Token” 这一残酷现实的补偿机制。它的演进方向，预示着我们离真正智能的 AI 还有多远。
  • Graph RAG 的兴起：
    • 利用知识图谱的 Graph RAG，不仅能检索离散信息块，还能检索它们之间的显式关系。 这使得模型能够进行更复杂的多跳推理，为答案提供更丰富的上下文和逻辑支撑。
  • 智能体自主性的增强：
    • 像 Self-RAG 和 Agentic RAG 这样的系统，将赋予 LLM 更多管理自身上下文的责任，模糊了上下文工程系统与 LLM 本身之间的界限。
  • 超越固定上下文窗口：
    • 针对“迷失在中间”问题的研究正在探索新的模型架构（如改进的位置编码）和训练技术。 这些突破可能会从根本上改变我们今天面临的约束。

终极目标：让桥梁“隐形”

人工智能研究的长期目标，是创造出具有更强大内部世界模型和推理能力的 AI，从而减少对此类庞大外部上下文“脚手架”的依赖。上下文工程的演进，恰恰是衡量我们朝此目标迈进的关键指标。 当这座桥梁因为对岸（AI自身能力）的进步而变得越来越不被需要时，我们或许就迎来了通用人工智能的黎明。

参考

  1. www.microsoftpressstore.com, https://www.microsoftpressstore.com/articles/article.aspx?p=3192408&seqNum=2#:~:text=Prompt engineering involves understanding the,as additional context or knowledge).
  1. Core prompt learning techniques | Microsoft Press Store, https://www.microsoftpressstore.com/articles/article.aspx?p=3192408&seqNum=2
  1. Prompt Engineering for AI Guide | Google Cloud, https://cloud.google.com/discover/what-is-prompt-engineering
  1. arXiv:2402.07927v2 [cs.AI] 16 Mar 2025, https://arxiv.org/pdf/2402.07927
  1. What is Prompt Engineering? - AI Prompt Engineering Explained - AWS, https://aws.amazon.com/what-is/prompt-engineering/
  1. Which Prompting Technique Should I Use? An Empirical Investigation of Prompting Techniques for Software Engineering Tasks - arXiv, https://arxiv.org/html/2506.05614v1
  1. The rise of "context engineering" - LangChain Blog, https://blog.langchain.com/the-rise-of-context-engineering/
  1. Context Engineering - LangChain Blog, https://blog.langchain.com/context-engineering-for-agents/
  1. A Systematic Survey of Prompt Engineering in Large Language Models: Techniques and Applications - arXiv, https://arxiv.org/html/2402.07927v2
  1. Unleashing the potential of prompt engineering for large language models - PMC, https://pmc.ncbi.nlm.nih.gov/articles/PMC12191768/
  1. Retrieval Augmented Generation (RAG) for LLMs - Prompt Engineering Guide, https://www.promptingguide.ai/research/rag
  1. What Is Retrieval-Augmented Generation aka RAG - NVIDIA Blog, https://blogs.nvidia.com/blog/what-is-retrieval-augmented-generation/
  1. Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training - arXiv, https://arxiv.org/html/2311.09198v2
  1. Mastering Chunking Strategies for RAG: Best Practices & Code Examples - Databricks Community, https://community.databricks.com/t5/technical-blog/the-ultimate-guide-to-chunking-strategies-for-rag-applications/ba-p/113089
  1. How to do retrieval with contextual compression - Python LangChain, https://python.langchain.com/docs/how_to/contextual_compression/
  1. How do I choose between Pinecone, Weaviate, Milvus, and other vector databases?, https://milvus.io/ai-quick-reference/how-do-i-choose-between-pinecone-weaviate-milvus-and-other-vector-databases
  1. Retrieve & Re-Rank — Sentence Transformers documentation, https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html
  1. Lost in the Middle: How Language Models Use Long Contexts - Stanford Computer Science, https://cs.stanford.edu/~nfliu/papers/lost-in-the-middle.arxiv2023.pdf
  1. LLMs Get Lost In Multi-Turn Conversation - arXiv, https://arxiv.org/pdf/2505.06120
  1. How to do retrieval with contextual compression - LangChain.js, https://js.langchain.com/docs/how_to/contextual_compression/
  1. LLM Agents - Prompt Engineering Guide, https://www.promptingguide.ai/research/llm-agents
相关文章 :
工程
  • LLM
  • Agent
    • 加锁文章 Spring AI还是Langchain4j
    Loading...
    目录
    0%