从"提示词"到"上下文工程"：AI应用开发者的下一个高薪技能

为什么Context Engineering出现？

呐，前段时间Context engineering非常火，大家应该也知道，Openai的联合创始人Karpathy在推特也说到这个事了，一个超越了Prompt的一个AI工程，更像一个Operate System，大概就是这样比喻:大模型就是cpu , 记忆就是内存。反正都在炒，那咱们就跟着吃吧。

随着大型语言模型 (LLM) 从简单的指令遵循系统演进为复杂、多方面应用的核心推理引擎，用于与之交互的方法也必须发生演进。 “提示工程”一词虽然是基础，但已不足以捕捉设计、管理和优化现代人工智能系统所需的信息负载的全部范围。 这些系统不是在一个单一的、静态的文本字符串上运行；它们利用动态的、结构化的和多方面的的信息流。 为了解决这个问题，上下文工程出现了。

什么是上下文工程呢？

有些大佬也给出了一些理解：上下文工程它是一个类似于机器人的一个综合性、交叉专业的AI系统工程，它也是人工智能系统设计领域的下一次重大进化，从复杂度、效果、落地等角度来说，远远超越了传统的提示工程。但是它也只做两个核心的事：设计并优化指令和相关上下文管理。这两件事做好，足以使大型语言模型（LLMs）和高级 AI 模型能够有效地完成各种复杂任务。从更大大范围地定义，Context Engineering是对环境、输入数据和交互流程的设计，因为这些是系统必不可少的部分，都会影响 AI 系统的运行以及效果。

然而它与专注于为特定任务的单个提示的提示工程不同，上下文工程采取了一种整体方法来构建智能系统，这些系统能够维持状态、动态访问相关信息，并在多个交互和复杂工作流程中有效地运行。

从上图可以看到，Context Engieering，主要是Context，那Context包含哪些呢？这里我们简单来列举一下:

a) Instructions :开发人员的基本指令，通常称为系统提示。这可以是静态的，也可以是动态的;

b）Tools: agent可以访问哪些工具。这些的名称、描述和参数与提示中的文本一样重要.

c）Structured output：agent应以什么格式回复

d）Session context: 在文档中也称之为“短期记忆”。在对话的上下文中，最容易想到的是构成对话的消息列表。但是，您可能希望agent在整个会话中访问或更新其他更结构化的信息。agent可以读取和写入此上下文。此上下文通常直接放入传递给 LLM 的上下文中。如：消息、文件.

e) Long term memory： 这是应在会话（对话）中持续存在的信息，一般存在数据库中。

f) Runtime configuration context: 这不是agent的“状态”或“内存”的上下文，而是给定agent运行的配置。这不会由agent修改，通常不会传递到 LLM 中，而是用于指导agent的行为或查找其他上下文, 如：用户 ID、数据库连接。

Context Engineering 组件

既然Context engineering是一个AI系统工程，那可以把它划分几个重要的组件如：系统级设计、动态信息管理、多模态上下文优化。

系统设计：上下文工程将 AI 系统视为完整的生态系统，而不是单个的提示-响应交互。这包括设计系统指令（或系统提示），以定义 AI 应该如何行为的规则和指南，管理对话历史和记忆，以及整合外部数据源和工具

动态信息管理: 上下文工程的关键方面是汇集所有相关的背景、记忆和工具，以便 AI 能够有效地响应——跨越多个回合和任务。这涉及到创建能够根据每次交互的具体上下文动态检索和整合相关信息的系统

多模态上下文: 是因为随着人工智能系统变得越来越复杂，Prompt的效果已经见底了，并且研究者发现上下文工程已超越基于文本的交互，扩展到优化多模态模型上下文，将视觉、音频和其他数据类型纳入上下文框架。

这些组件涉及到多个不同技术，这个我们从上面的图也可以了解，这个图可能不是终极的形态，但是现阶段相对还是很准确，它包含了提示词工程、长短记忆、工具、RAG等。现在我们也从这几点来介绍一下。

RAG技术

个人感觉RAG是上下文工程的雏形，为什么这么讲。因为RAG 代表了一种基本技术，它可以从外部知识源动态检索相关信息，并在生成响应之前将其纳入 AI 的上下文中。这使得 AI 系统能够访问超出其训练数据的最新信息，并提供更准确、上下文相关的响应。

高级检索

目前检索采用的技术都是相对复杂，如文档切分、分段，当他们与 BM25、bge 等编码召回技术结合使用时，可以将前 20 个片段检索失败率降低多达 49%，这些方法确保最相关的信息能够成功检索并纳入 AI 的工作上下文中。

全局状态管理

像 LlamaIndex 这样的上下文工程框架实现了全局状态/上下文管理，允许系统将工作流程上下文作为一种临时存储板，可以存储和检索在智能体步骤之间跨越的全局信息。这实现了长期记忆和多个交互之间的连续性。

工具集成和编排

Context Engineering的一个关键组成部分是让 AI 能够访问可以根据上下文动态调用的工具和功能,最后经过一系列业务逻辑，清晰地格式化工具输出，并提供后续指令以将结果纳入响应中。下图为N8N的一个编排流程示例图。

从上面的一个介绍，大家应该有一个意识了，Context Engineering是一个系统集成工作。如果还没意识到，我们就来看看Context Engineering和Prompt工程的一个区别吧，让大家有更深的印象。

Prompt工程和Context Engineering区别

这里我们从三个角度进行对比，一是他们的一个范围，二是他们在工程中的一个定位，三是他们的一个关系。

就范围而言，提示工程专注于为单个输入输出对制定清晰的指令，并在单个交互中运行，在整个系统中它就是一个独立的个体。但是Context Engineering却不然，它是贯穿整个流程、架构、系统，接受外界的输入(包含文本、图片、音频等)，能够调用外部的工具、记忆等，给到模型处理并将其存储，输出最终用户需要的结果。

就定位而言，提示工程是针对特定输入的临时处理，而Context Engineering则比提示工程占的定位高很多，它是专注于构建随着时间的推移维护上下文内容和状态的系统工程。

就它们直接关系而言，从上面的图可以看出来，提示词工程是Context Engineering的一个子集(或者说的很小的一个部分)，并且从上面的介绍也可知，它是在系统架构、用户交互等进行重构设计。

这是一个新的概念，但是吧，说不定大家已经开始这样做了，只是这帮大佬给这个新的AI系统或者AI工程赋予了一个新的名字。哈哈，瞎说的

言归正传，既然Context Engineering提出来了，它到底可以在哪些场景进行落地，怎么落地？

这里给出一些案例吧。

a) 企业内部OA系统: 企业信息流程，尤其是跨部门的工作，Context Engineering很合适。

b) Agent：现在agent其实就是这个模式，读取互联网数据、数据库、excel等，但是会有一个问题，就是一旦你长时间使用这个上下文，会出现幻觉、响应慢、记忆出现混乱。这里可能就需要Context Engineering来做一系列处理，如 写入、选择、压缩和隔离。

c) 企业知识工程：企业内部文档都很分散，这个时候它就很有用。

d) Coding：一个项目再庞大，对于Context Engineering也是养料,它的出现就是负责解决复杂系统的。

说了这么多，到底怎么使用？这里给大家安利下(不好意思，Llamaindex是真没找到)，但是langchain走在前面，提供了Context Engineering的一些模式或者方法，大家可以对照学习与使用。

LangChain 使用Context Engineering

Prompt方式

对于固定的指令可以参考：

import { createAgent } from "langchain";
const agent = createAgent({
model: "openai:gpt-4o",
tools: [...],
systemPrompt: "You are a customer support agent. Be helpful, concise, and professional.",
});

对于动态的指令可以参考：

import * as z from "zod";
import { createAgent, dynamicSystemPromptMiddleware } from "langchain";
const contextSchema = z.object({
userId: z.string(),
});
const agent = createAgent({
model: "openai:gpt-4o",
tools: [...],
contextSchema,
middleware: [
dynamicSystemPromptMiddleware((state, runtime) => {
const userId = runtime.context.userId;
const messageCount = state.messages.length;
let base = "You are a helpful assistant.";
// Add context-specific instructions
if (messageCount > 10) {
base += "\nThis is a long conversation - be extra concise.";
}
return base;
}),
],
});
// Use the agent with context
const result = await agent.invoke(
{ messages: [{ role: "user", content: "Help me debug this code" }] },
{ context: { userId: "user_123" } }
);x

上下文管理

上下文处理那是相当重要哇，包括了如 write context、select context、compass context、isolate context 等内容，这也来一个个讲解下这些概念，让大家更加深刻理解。

write context: 当人类解决任务时，我们会做笔记并记住未来相关任务。代理也正在获得这些功能！通过“ 暂存器 ”记笔记是在代理执行任务时保留信息的一种方法。中心思想是将信息保存在上下文窗口之外，以便代理可以使用它。暂存器实现可以通过记忆来实现，它们可以是简单地写入文件的工具调用 。它也可能只是运行时状态对象中的一个字段，在会话期间保留。无论哪种情况，暂存器都可以让代理保存有用的信息以帮助他们完成任务。暂存本帮助代理在给定会话中解决任务，但有时代理会从记住多个会话中的事情中受益。 反射引入了在每次代理回合后进行反思并重复使用这些自我生成的记忆的想法。 生成智能体创建了从过去智能体反馈的集合中定期合成的记忆。

select context: 从暂存器中选择上下文的机制取决于暂存器的实现方式。如果它是一个工具 ，那么代理可以通过进行工具调用来简单地读取它。如果它是代理运行时状态的一部分，则开发人员可以选择在每个步骤中向代理公开哪些状态部分。这为在以后的回合中向 LLM 公开暂存器上下文提供了细粒度的控制级别。如果代理有能力保存记忆，他们还需要能够选择与他们正在执行的任务相关的记忆。这可能很有用，原因有几个，代理可能会选择少量示例（ 情景记忆 ）作为所需行为的示例、指示（ 程序记忆 ）来引导行为，或者事实（ 语义记忆 ）为代理提供与任务相关的上下文。但是提供的记忆就一定是这个步骤所需要的？这个不一定的，所以这里取选择记忆很有挑战。langchain提供了工具和模型的选择示例，如下所示。

import { createMiddleware, initChatModel } from "langchain";
const adaptiveModel = createMiddleware({
name: "AdaptiveModel",
wrapModelCall: (request, handler) => {
const messageCount = request.messages.length;
let model;
if (messageCount > 20) {
// Long conversation - use model with larger context window
model = initChatModel("anthropic:claude-sonnet-4-5-20250929");
} else if (messageCount > 10) {
// Medium conversation - use mid-tier model
model = initChatModel("openai:gpt-4o");
} else {
// Short conversation - use efficient model
model = initChatModel("openai:gpt-4o-mini");
}
return handler({ ...request, model });
},
});

tool 选择示例：

import { createMiddleware } from "langchain";
const permissionBasedTools = createMiddleware({
name: "PermissionBasedTools",
wrapModelCall: (request, handler) => {
const userRole = request.runtime.context.userRole || "viewer";
let filteredTools = request.tools;
if (userRole === "admin") {
// Admins get all tools
} else if (userRole === "editor") {
// Editors can't delete
filteredTools = request.tools.filter(t => t.name !== "delete_data");
} else {
// Viewers get read-only tools
filteredTools = request.tools.filter(t => t.name.startsWith("read_"));
}
return handler({ ...request, tools: filteredTools });
},
});

compass context：其实就是上下文的压缩总结。Agent交互可以跨越数百个回合 ，并使用token密集型工具调用。总结是管理这些挑战的一种常见方法。如果您使用过 Claude Code，您就会看到这一点。Claude Code 在您超过 95% 的上下文窗口后运行“ 自动压缩 ”，它将总结用户与代理交互的完整轨迹。这种跨代理轨迹的压缩可以使用各种策略，例如递归或分层摘要。

总结通常使用 LLM 来提炼最相关的上下文片段，而修剪通常可以过滤。

import { createMiddleware, RemoveMessage } from "langchain";
import { REMOVE_ALL_MESSAGES } from "@langchain/langgraph";
const trimMessages = createMiddleware({
name: "TrimMessages",
beforeModel: (state) => {
const messages = state.messages;
if (messages.length <= 10) {
return;  // No trimming needed
}
// Keep system message + last 8 messages
return {
messages: [
new RemoveMessage({ id: REMOVE_ALL_MESSAGES }),
messages[0],  // System message
...messages.slice(-8)  // Recent messages
]
};
},
});
const agent = createAgent({
model: "openai:gpt-4o",
tools: [...],
middleware: [trimMessages],
});

isolate context: 隔离上下文的最流行方法之一是将其拆分为子代理。OpenAI Swarm 库的动机是“ 关注点分离 ”，代理团队可以处理子任务。每个代理都有一组特定的工具、说明和自己的上下文窗口。

Huggingfacez自己也提供了一个Agent框架，采用的也是这种方式。因为大多数代理使用工具调用 API，它返回 JSON 对象（工具参数），这些对象可以传递给工具（例如搜索 API）以获取工具反馈（例如搜索结果）。HuggingFace 使用 CodeAgent，它输出包含所需工具调用的代码。然后，代码在沙盒中运行。然后从工具调用中选定的上下文（例如，返回值）被传递回 LLM。

总的来说，write context意味着将其保存在上下文窗口之外，以帮助代理执行任务。select context意味着将其拉入上下文窗口以帮助代理执行任务。compass context涉及仅保留执行任务所需的令牌。isolate context将其拆分以帮助代理执行任务。

局限与挑战

好了，讲完了，现在来看看这么好的东西，现在有哪些挑战？

a) 记忆评估面临重大挑战，限制了对能力的有效评估。 基本的局限性包括缺乏用于评估记忆性能的连贯、严格的方法，尤其是在超出训练数据泛化方面。 缺乏专门为长期记忆评估设计的标准化基准测试是另一个重大障碍，现有框架通常无法捕捉到人类智能所需的全部记忆能力。

b) 架构约束大大增加了评估工作，因为大多数基于当代 LLM 的代理以根本无状态的方式运行，独立地处理交互，而没有随着时间的推移真正地累积知识 ，尽管通过注意力标记机制在工作记忆方面取得了进展，从而实现了灵活的记忆表示控制 。这种限制阻碍了真正的终身学习评估——这是人类水平智能的一个基石，涉及在不同背景和延长时间范围内持续的知识获取、保留和再利用。

c) 当将特定于记忆的性能与其他智能方面分离时，会出现方法论问题，这给确定失败是源于不充分的记忆机制还是推理限制带来了挑战。 现实世界应用中动态的记忆使用对评估提出了挑战，因为受控的实验室测试无法充分捕捉复杂场景中的记忆系统性能，而信息相关性在这些场景中会不可预测地变化。

最近这几年，经济形式下行，IT行业面临经济周期波动与AI产业结构调整的双重压力，很多人都迫于无奈，要么被裁，要么被降薪，苦不堪言。但我想说的是一个行业下行那必然会有上行行业，目前AI大模型的趋势就很不错，大家应该也经常听说大模型，也知道这是趋势，但苦于没有入门的契机，现在他来了，我在本平台找到了一个非常适合新手学习大模型的资源。大家想学习和了解大模型的，可以**点击这里前往查看**