从提示到编排：上下文工程与生产级 AI 系统上下文工程并非对提示工程的简单重命名，而是一门系统级工程学科。其目标是在恰当

从提示到编排：上下文工程与生产级 AI 系统

执行摘要

本文梳理大型语言模型（LLM）交互的演进，聚焦提示工程（Prompt Engineering）与上下文工程（Context Engineering）的关键差异，并评估“上下文工程”是否只是营销包装。

提示工程侧重单次、无状态的指令优化；随着应用复杂化，尤其是智能体（Agentic AI）的兴起，这种以提示为中心的方法在可扩展性、可靠性和状态管理上暴露出局限。

上下文工程并非对提示工程的简单重命名，而是一门系统级工程学科。其目标是在恰当的时间、以恰当的格式，为 LLM 提供完成任务所需的信息与工具：管理短期/长期记忆、集成检索增强生成（RAG）、灵活调用工具 API，并定义结构化输出（如 JSON Schema）。

本文结论: 上下文工程代表了从"提示调优"向"应用架构"的技术演进。构建复杂AI应用的关键不在于更巧的提问，而在于对模型推理所需信息环境的系统化管理。

什么是“上下文工程”（速览）

定义：在恰当的时间、以恰当的格式，动态准备模型完成任务所需的全部信息与工具；关注“模型需要知道与具备什么”，而不只是“提示怎么写”。
关键组件：
- 系统指令（角色与行为约束）
- 用户输入（当前需求）
- 记忆（短期对话历史与长期偏好）
- 检索信息（RAG，来自文档/数据库/API）
- 工具及其输出（外部函数/服务调用与返回）
- 结构化输出模式（JSON Schema 等）
与提示工程的区别：
- 关注点：提示工程重措辞；上下文工程重信息与能力的编排
- 形态：提示多为静态一次性输入；上下文为运行时动态组装
- 能力：提示侧重无状态；上下文管理记忆/检索/工具
- 目标：单轮优化 → 应用级的可靠、可扩展架构
一句话例子：客服智能体在回答“订单为何未到”前，先检索政策与知识库、查询物流 API、读取用户历史订单作为上下文，再按预设 JSON 模式输出“原因/证据/解决方案/下一步”。这套“先收集→再推理→再结构化输出”的流程，就是上下文工程。

第1节 LLM 交互的基础：提示工程大师课

理解提示工程是基础。本文将定义其核心理念，梳理关键技术与典型工作流程，并分析以提示为中心的方法在构建有状态应用时的局限，为后续引入上下文工程铺垫。

1.1 定义提示工程：指令的艺术

提示工程（Prompt Engineering）是指导生成式人工智能（Generative AI）模型产出期望结果的基础实践。其本质是设计和优化输入给模型的指令或问题（即"提示"），充当人类意图与机器输出之间的主要接口。

这一实践的核心原则是：AI 生成响应的质量直接取决于提示的结构优劣。这涉及到仔细选择词语、短语、格式和符号，以便为模型提供清晰的指令和充足的背景信息。

提示工程要求实践者融合语言技巧、创造性表达和反复试验，以创建有效的输入文本。它是一个持续的测试、评估与优化循环，需要灵活性和适应性。

1.2 提示工程技术分类法

提示工程师利用多种技术来提升 AI 模型在自然语言处理（NLP）任务上的表现。这些技术从简单到复杂，为与 LLM 的有效沟通提供了丰富的工具箱。

零样本提示（Zero-Shot Prompting）
在这种技术中，模型被要求执行一项任务，而提示中不提供任何先前的示例。它完全依赖模型在预训练阶段获得的知识来解释和响应提示。例如，直接向模型提问：“用简单的术语解释气候变化的概念、原因和影响。” 这种方法适用于通用任务，即我们相信模型凭借其固有的语言和概念理解能力就能生成创造性的输出。
少样本（及单样本）提示（Few-Shot and One-Shot Prompting）
与零样本提示不同，少样本提示在提示中包含少量（通常是2到4个）示例，向模型展示任务的期望格式、风格或模式。单样本提示则是只提供一个示例的特殊情况。例如，在解释气候变化之前，可以先提供光合作用和重力的解释作为范例，从而引导模型理解所期望的解释口吻和简洁程度。这种方法有助于模型更好地理解上下文和预期的输出结构，尤其适用于需要确保一致性和准确性的任务，如生成特定格式或领域的文本。
思维链提示（Chain-of-Thought, CoT Prompting）
这是一种常用技术，用于激发模型的推理能力。它鼓励模型将复杂问题分解为更小、更符合逻辑的步骤。通过加入“让我们一步一步地思考”等引导语，可提升在数学、逻辑或多步骤分析任务中的表现。例如，面对数学问题，CoT 会引导模型先列出步骤再计算，而不是直接给出答案。这种方法通过外化推理过程，提高结果稳定性并增强可解释性。
高级提示策略
除了上述基础技术，提示工程师还开发了多种更高级的策略来应对特定挑战：
- 角色扮演（Role-Playing）： 为模型分配一个特定的角色或身份，例如“你是一位经验丰富的旅行博主”或“作为一名营养学家”，以生成高度情境化和领域特定的响应。这种方法能有效引导模型的语气、风格和知识侧重点。
- 生成知识提示（Generate Knowledge Prompting）： 指示模型在解决主要问题之前，首先生成相关的背景知识。例如，在解释气候变化之前，先让模型列出相关的关键科学原理（如温室效应），然后利用这些原理进行解释。这有助于产出信息更充分、更准确的回答。
- 自洽性（Self-Consistency）： 让模型对同一个问题生成多个独立的回答，然后选择其中最连贯或最常出现的结论作为最终答案。这种方法通过“多数投票”的原则来提高复杂推理任务的稳健性。
- 元提示（Meta-Prompting）： 要求模型自己生成或优化用于完成特定任务的提示。这利用了模型自我指导的能力，可能通过让模型“思考如何提问”来提升最终输出的质量。

1.3 提示工程师的工作流程：一个迭代循环

提示工程的实践本质上是一个迭代过程。一个典型的提示工程工作流程包含以下几个关键步骤，形成一个持续优化的闭环：

起草初始提示（Drafting）： 根据手头的任务和期望的输出，创建第一个版本的提示。
测试提示（Testing）： 将提示输入 AI 模型，生成一个响应。
评估输出（Evaluating）： 检查生成的响应是否与预期目标一致，评估其准确性、相关性、格式和风格是否满足要求。
优化提示（Refining）： 基于评估结果对提示进行必要的调整。这可能包括增加清晰度（例如，明确说明需要的是摘要而非分析）、添加约束（例如，“用三句话描述”）、提供更多上下文或示例。
重复循环（Repeating）： 持续重复上述测试、评估和优化的过程，直到模型的输出质量稳定地达到期望的标准。

这个循环强调了实验和反馈的重要性。提示工程师需要不断尝试不同的想法和措辞，通过观察模型的反应来逐步完善提示，最终找到能够稳定引导模型产出高质量结果的最佳方案。

提示工程迭代工作流程图

1.4 以提示为中心的方法的内在局限性

尽管提示工程对于执行离散、定义明确的任务非常有效，但当面临构建规模化、复杂的 AI 应用时，其固有的局限性便开始显现。

首先，设计不佳的提示很容易导致模糊、离题或具有误导性的响应。这种方法的有效性高度依赖于工程师的经验和直觉，使得结果难以保证稳定。

其次，许多提示技巧，尤其是那些依赖精巧措辞的技巧，被认为是“脆弱的，并且无法很好地扩展到复杂的应用中”。一个在特定场景下表现良好的提示，在另一个稍有不同的场景中可能完全失效，这导致了持续的手动调整和维护成本。

然而，最根本的局限性在于，提示工程的核心关注点是单个、通常是静态的输入字符串。这种方法并未从根本上解决构建现代复杂应用所面临的核心挑战，例如：

多轮对话管理： 在持续的对话中，模型需要记住之前的交流内容。单纯的提示工程无法内在地管理这种对话历史或状态。
动态外部数据集成： 许多应用需要模型利用实时的、外部的信息（如数据库、API）。提示工程本身不提供动态获取和整合这些数据的机制。
状态管理： 复杂的智能体需要跟踪任务进度、用户偏好等状态信息。以提示为中心的方法是无状态的，无法满足这些需求。

这些挑战对于构建任何生产级的、强大的 AI 系统都至关重要，而提示工程作为一种交互策略，其设计初衷并未涵盖这些系统级的问题。

这种局限性揭示了一个更深层次的问题：提示工程本质上是一门在单次交互中优化人机沟通的学科。其迭代的工作流程，实际上是对一个复杂的、非确定性系统进行手动调试的过程。这暴露了其主要的架构限制——它是一种管理单个、无状态事务的战术，而非构建一个有状态、多事务系统的战略。

当应用需求从简单的问答机器人演变为需要记忆、使用工具并执行多步骤任务的复杂智能体时，这种"单次交互"的范式就成为了明显的瓶颈。为复杂应用的每一种可能状态都手动设计合适的提示，在计算复杂度和逻辑可行性上都是不现实的。

正是这一技术局限，为上下文工程这一新范式的出现创造了客观必要性。行业需要一种能够系统性地处理状态管理、动态信息集成和多步骤推理的方法论，而这正是传统提示工程力所不及的领域。

第2节范式转变：解构上下文工程

随着 AI 应用的复杂性不断提升，行业的需求已经超越了对单个提示的精雕细琢。一个新的、更系统化的学科——上下文工程——正在兴起，它将关注点从孤立的指令扩展到了整个信息生态系统。本节将介绍上下文工程，将其定义为一个超越单个提示的系统级学科。我们将详细剖析“上下文的构成”，分解生产级 AI 系统必须管理的多元化组件架构。“静态指令”（提示）与“动态编排”（上下文工程）之间的核心区别将是贯穿本节的主题。

2.1 定义上下文工程：从字符串到系统

上下文工程（Context Engineering）是一门设计和构建动态系统的学科，其目标是在恰当的时间、以恰当的格式，为大型语言模型（LLM）提供完成特定任务所需的一切信息和工具。

这代表了一个重要的转变：从精心制作单个、静态的提示字符串，转向架构化地管理围绕 LLM 的整个信息生态系统。它被认为是提示工程的超集（superset），意味着提示工程是上下文工程的一部分，而不是与之并列或对立的概念。

其核心思维方式从“如何对模型说话”转为“模型需要知道什么”。上下文工程的重点在于管理提示周围的一切元素，为模型有效回答问题做好准备。它关注如何填充模型的“上下文窗口”，而不仅仅是窗口内那句提问。

2.2 上下文的构成：一个多组件架构

在上下文工程的语境中，“上下文”远不止用户当前的查询。它是指模型在生成响应之前在其“上下文窗口”中看到的所有信息的总和。这个上下文是一个动态组装的信息包，而非静态的文本。一个精心设计的上下文通常包含以下关键组件：

系统提示/指令（System Prompt / Instructions）： 这是高层次的、持久性的指令，用于定义模型的角色（“你是一个专业的法律助理”）、个性、必须遵守的规则以及行为约束。它为整个交互过程设定了基调。
用户输入（User Input）： 用户提出的即时任务或问题，是触发模型生成响应的直接原因。
记忆（短期与长期）（Memory, Short- and Long-Term）：
- 短期记忆： 通常指当前的对话历史记录，作为一个缓冲区，保存最近的交流信息以维持对话的连贯性。
- 长期记忆： 跨会话的持久性知识，例如用户的偏好、过去项目的摘要等。这些信息通常存储在外部系统（如向量数据库）中，在需要时被检索出来，为跨时间的交互提供连续性。
检索到的信息（RAG）（Retrieved Information）： 这是通过检索增强生成（Retrieval-Augmented Generation）等技术，从外部知识源（如文档、数据库、API）动态获取的、最新的信息。它用于将模型的回答“锚定”在事实基础上，从而减少“幻觉”（即生成虚假信息）的发生。RAG本身被认为是“上下文工程的一种风格”。
工具及其输出（Tools and their Outputs）： 这包括模型可用的工具（如API、代码解释器、数据库查询功能）的定义，以及模型调用这些工具后返回的结果。这赋予了模型超越其内部知识的行动能力。
结构化输出模式（Structured Output Schemas）： 预先定义的输出格式（如JSON Schema），用于约束模型的响应，使其生成可预测的、机器可读的数据。这对于将LLM的输出集成到下游自动化流程中至关重要。

上下文工程多组件架构图

2.3 动态编排 vs. 静态指令

上下文工程与提示工程最核心的区别在于其动态性。组装上述多维组件的系统是动态的，而非静态的。最终发送给 LLM 的完整“提示”（即整个上下文窗口的内容）是根据当前任务的即时需求，动态地、在运行时（on the fly）创建的。

这个过程由一个“LLM 编排层”（LLM orchestration layer）来执行，该层负责收集、构建和排序模型看到的所有信息。因此，上下文工程关注的是设计模型“思考过程”的整个流程和架构，而不仅仅是单次输入的措辞。

这种动态编排对于构建智能体系统（agentic systems）尤为关键。在一个设计良好的智能体系统中，其首要任务不是决定如何响应，而是首先收集必要的信息来扩展上下文，然后再调用 LLM 进行推理。行业实践已经表明，大多数智能体失败的根本原因不是模型本身的失败，而是

上下文的失败（context failures）——即系统未能向模型提供做出正确决策所需的充分信息。

上下文工程的出现，标志着业界对 LLM 在软件架构中角色的重新定位。LLM 不再被视为一个独立的终端应用（如一个聊天机器人），而是被看作一个功能强大、通用的，但本质上是无状态的推理引擎。上下文工程的实践，正是在这个无状态引擎的外部，构建一个有状态的应用层。

LLM 本身是无状态的，它只知道当前上下文窗口中提供的信息。而复杂的应用，如智能体或多轮对话机器人，本质上是有状态的，它们需要记忆历史、访问外部数据并执行多步计划。上下文工程所管理的各个组件——记忆 20、RAG 11、工具输出 19——都是将"状态"注入 LLM 上下文窗口的机制，以便其完成单步推理。而负责管理这些状态、并决定在下一步推理中哪些状态是相关的"编排层" 20，正是围绕 LLM 构建的传统应用逻辑。

因此，上下文工程不仅仅是为了让提示更有效，它是一门将一个无状态、非确定性的组件（LLM）集成到一个有状态、确定性的软件系统中的软件工程学科。这比单纯的提示词制作要复杂得多，需要系统设计、数据管理和 API 集成等多方面的技能。

动态编排vs静态指令对比图

2.4 表1：提示工程 vs. 上下文工程——一个比较框架

为了清晰地阐明这两种方法的区别，下表从多个维度对它们进行了系统性的比较。

维度 (Dimension)	提示工程 (Prompt Engineering)	上下文工程 (Context Engineering)
范围 (Scope)	关注单个输入-输出对。	关注整个信息生态系统。
主要目标 (Primary Goal)	在一次性任务中引出特定、高质量的响应。	确保在复杂、多步骤的工作流中实现一致、可靠的性能。
核心单元 (Core Unit)	提示（一个文本字符串）1。	上下文窗口（一个动态组装的数据包）12。
思维模式 (Mindset)	创造性的指令设计和文字打磨。	系统设计和信息架构。
关键组件 (Key Components)	指令、示例、思维链触发器。	记忆、RAG、工具、历史记录、模式定义。
性质 (Nature)	静态的或手动迭代的。	动态的和自动化的。
可扩展性 (Scalability)	脆弱；难以扩展到复杂应用。	从一开始就为一致性和可扩展性而设计。
类比 (Analogy)	给一个人指路。	构建一个带有实时数据的个人 GPS 导航系统。

提示工程vs上下文工程对比表格

第3节演进还是重塑？对“上下文工程”术语的分析

关键问题是：“上下文工程”究竟是一次实质性的技术演进，还是仅仅为了市场营销而创造的一个新潮术语？本节将直接回应这一疑问。我们将追溯该术语的起源及其在行业内的传播过程，系统地呈现支持“重塑”和“演进”两种观点的论据，并最终给出一个明确的分析师结论。

3.1 一个术语的起源：行业采纳与关键声音

“上下文工程”这一术语的确切起源尚不明确，但它在2025年中期由 AI 社区的几位关键人物推广开来，并迅速获得关注。

Tobi Lütke (Shopify CEO): 他公开表示，与 LLM 交互的核心技能是“提供所有必要的上下文”，而不仅仅是制作巧妙的提示。这一观点强调了信息供给的重要性超越了指令本身。
Andrej Karpathy (前 OpenAI 及特斯拉 AI 负责人): 他将上下文工程描述为“为任务提供所有上下文以便 LLM 能够解决它的艺术”。他进一步区分了日常使用的简单提示与构建“工业级应用”所需的“填充上下文窗口的精巧艺术和科学”。
Harrison Chase (LangChain创始人): 他将其定义为“构建动态系统”，并指出这个术语越来越流行，因为它更准确地描述了AI工程师的实际工作内容。

这些行业领袖的共同看法是，随着 AI 应用的深化，从业者的工作重心已经发生了转移。术语的变迁反映了行业从早期的"氛围编程"（vibe coding）和临时性的实验，转向了更加系统化、可重复的工程实践。

AI交互范式演进时间线

3.2 “重塑”论：这只是“做得更好的提示工程”

持这种观点的人认为，“上下文工程”并非一个全新的范式，而只是对熟练的提示工程师早已在实践的最佳做法的一个更好、更正式的标签。

该论点指出，提供上下文信息，例如通过少样本示例或角色扮演，一直都是优秀提示工程的核心组成部分。从这个角度看，上下文工程只是将这些自然演化出的最佳实践（如记忆管理、RAG和工具集成）进行了形式化和系统化的总结。它被视为一种“包装”上的改变，而非实践本身的根本变革。

甚至有观点认为，这只是对“提示工程”的一次“品牌重塑”（rebranding），因为随着模型能力的增强，如何有效利用上下文变得比以往任何时候都更加重要。

3.3 “演进”论：一次必要的范式转变

与“重塑”论相对，更主流的观点认为，上下文工程代表了在范围、思维模式和所需技能上的重要转变，这种转变是由 AI 应用日益增长的复杂性所驱动的。

范围的扩展： 提示工程是上下文工程的一个子集。提示工程关注的是在上下文窗口内部做什么（即如何措辞），而上下文工程关注的是如何决定什么东西应该被放入上下文窗口。
思维模式的转变： 它标志着从“创意写作”到“系统架构”的转变。其重点是构建可靠、可重复和可扩展的系统，这与优化一次性提示的工程挑战截然不同。
需求的必然性： 这个新术语的出现是必要的，因为“提示工程”已不足以描述构建生产级 AI 系统所需的工作。这些系统需要管理记忆、检索数据和使用工具，而“提示工程”这个词汇无法涵盖这些系统级的任务。智能体 AI 的兴起和企业级应用的普及，共同催生了对新词汇的需求，以准确描述这一新兴的工程领域。

3.4 分析师结论：一个独特且关键的学科

综合分析多方观点和行业实践，我们可以明确得出结论："上下文工程"代表了一次真实且必要的技术演进，而非简单的品牌重塑或概念包装。

这一区分在实践中具有重要意义，因为它影响了AI工程师的技能要求：

提示工程师的核心能力：语言学直觉、创造性思维、实验精神，以及对模型行为的深度理解
上下文工程师的核心能力：软件架构设计、分布式系统管理、数据管道构建、API 集成，以及全栈工程能力

这个术语的价值在于，它准确反映了行业焦点的重要转变：

从：将 AI 视为需要通过巧妙对话来说服的智能对话者
到：将 AI 视为需要被集成到复杂业务系统中的可编程组件

它明确了构建生产级AI应用的核心挑战——从"如何优雅地提问"转向"如何系统地管理模型所需的信息"。这种转变体现了AI应用开发从手工调试向工程化系统设计的演进。

关于"提示工程"与"上下文工程"的争论，实际上反映了 AI 工程领域走向成熟的必然过程。这种术语演变标志着整个行业从实验阶段向工业化阶段的技术演进：

实验阶段特征（2022-2023）：

个体开发者通过巧妙提示实现有趣的演示
"快速而粗糙"的创意驱动开发
提示工程作为核心技能

工业化阶段特征（2024-至今）：

企业级生产系统的规模化部署
严格的可靠性、一致性和安全性要求
系统架构能力成为关键竞争力

当企业试图将概念验证转化为关键业务流程（如客户服务、企业搜索）时，他们遇到的挑战已经不是提示措辞的优化，而是系统性的工程问题：如何通过 RAG 减少幻觉、通过记忆模块维持上下文连续性、通过工具集成实现与现实世界的可靠交互。

因此，这场术语之争远非简单的文字游戏——它代表了行业专业化的必然趋势。"上下文工程"术语的出现，为定义生产级 AI 开发的新问题和新技能创造了必要的共享词汇，标志着 AI 应用开发正式进入了系统工程时代。

第4节技术总结与发展趋势

本节总结多模块AI系统的技术要点，并对相关技术的发展趋势进行客观分析。

4.1 技术实践要点

构建复杂AI系统时，以下几个方面值得重点关注：

系统架构考虑：

将大语言模型视为系统中的一个组件，而非独立应用
在设计阶段就考虑数据流和状态管理
平衡功能复杂性与系统可维护性
建立清晰的组件边界和接口

数据和质量管理：

重视数据质量对系统性能的影响
建立适当的数据预处理和清理流程
考虑数据的结构化和组织方式
实施持续的质量监控和改进

开发和运维实践：

采用渐进式的开发和部署策略
建立完善的测试和评估机制
重视错误处理和系统的健壮性
保持对技术演进的关注和适应能力

4.2 核心洞察与关键转变

4.2.1 三个关键洞察

通过对实践转型过程的深入分析，我们识别出三个关键洞察：

训练与推理对齐是基础
- 结构化训练数据是实现有效上下文工程的基石（沿用常规 messages JSONL 即可，无需特殊“工具标签”格式）
- 推理时的格式对齐直接影响模型性能
- 不对齐会导致系统退化到简单的提示工程水平
渐进式升级策略可行
- 不必推倒重来，可以在现有基础上逐步演进
- 三阶段迁移策略（包装→重构→编排）提供了清晰的路径
- 风险可控，投入产出比合理
简洁实现优于复杂架构
- 大多数应用场景下，简单的解决方案就足够
- 过度设计的监控和评估体系往往没有必要
- 实际可用比理论完整更重要

4.2.2 思维模式的转变

从技术角度来看，这种演进体现了几个关键的变化：

技术重心的转移：

从优化单一输入文本转向管理整个信息生态系统
从依赖经验调试转向采用工程化的设计方法
从孤立的AI交互转向与业务系统的深度集成

系统复杂度的增加：

需要处理更多的数据源和外部依赖
状态管理和错误处理变得更加重要
对开发团队的技能要求也相应提高

4.3 技术发展方向：自动化工作流架构

一些研究者认为，上下文工程可能进一步演进为自动化工作流架构（Automated Workflow Architecture）。在这种模式下，系统可以根据目标自动生成和管理上下文流水线，而不需要人工设计每个环节。

这种方向的核心思路是：开发者只需提供高层次目标和可用工具，系统能够自主编排推理过程。不过，这种完全自动化的方案目前仍处于研究阶段，在生产环境中的可行性和可靠性还需要更多验证。

从提示到编排：上下文工程与生产级 AI 系统