2025 年的 AI 开发领域，一个新的术语正在迅速取代 “提示词工程（Prompt Engineering）” 成为行业焦点 ——上下文工程(Context Engineering)。这一概念由 Shopify CEO Tobi Lutke 率先提出，并迅速获得前 OpenAI 研究员 Andrej Karpathy 等技术领袖的力挺。Karpathy 在社交媒体上明确表示：“我支持 ’ 上下文工程 ’ 而非 ’ 提示词工程 '”，这一表态标志着LLM大模型应用开发从单点思维向系统思维的根本转变。

与提示词工程相比，上下文工程提供了更为全面和系统的方法论。Lutke 对上下文工程的定义是：“它更好地描述了核心技能 —— 为任务提供所有必要的上下文，使LLM能够合理地解决问题的艺术”。这一定义揭示了上下文工程的本质：它不是简单地构造几个提示词，而是精心设计和管理整个信息环境，使 LLM 能够在其中高效、可靠地运行。

在Agent开发中，上下文工程的核心价值在于解决了传统提示词工程的局限性。Karpathy 特别强调：“在工业级 LLM 应用中，上下文工程才是关键所在 —— 一门既讲科学又讲直觉的技术活，要把上下文窗口精确地填入下一步所需的信息”。这一观点得到了 DeepMind 高级 AI 工程师 Philipp Schmid 的认同，他指出：“如今很多 Agent 的失败，不是模型能力不足，而是上下文没设计好”。

1、什么是上下文工程？

上下文工程是提示词工程的升级版，本质上是优化你给 AI 模型提供的指令和背景信息，让它能更高效、准确地完成任务。几年前，有些 AI 专家觉得提示工程会过时，但事实恰恰相反，它不仅没消失，反而变得更重要，进化成了上下文工程。

很多人写过上下文工程的定义（比如Ankur Goyal、Walden Yan），但我想分享我的看法，并给一个具体指南，讲讲怎么在开发AI Agent时用上下文工程。

我不确定谁先提出"上下文工程"，但我们可以参考Dex Horthy的图，里面简要解释了这个概念。

图中，上下文工程涵盖了RAG、提示词工程、状态/历史、标准化输出、记忆等部分。

上下文工程不只是随便给 AI 扔一句问题（这叫“盲目提示”），而是像个建筑师一样，精心设计指令、用户输入、输出格式，甚至是外部工具和历史数据的使用，确保 AI 明白你的意图，产出你想要的结果。

从开发者角度看，上下文工程是个迭代过程，优化给AI模型的指令和上下文，达到预期结果。这包括用正式流程（比如评估管道）来衡量策略是否有效。

我给上下文工程下了个更广泛的定义：为LLM和高级AI模型设计和优化指令及相关上下文，让它们有效完成任务的过程。这不仅包括文本大模型，还包括优化多模态模型的上下文，这些模型越来越常见。这涵盖所有提示词工程工作和相关流程，它包括以下关键部分：

• 设计指令：调整指令/系统提示词，设计和管理提示链，告诉 AI 具体要做什么，比如“把复杂问题拆成小任务”。
• 用户输入：管理提示词的动态元素，提供清晰的问题或数据，比如“查询 OpenAI 的最新开发动态”，准备和优化少样本演示。
• 结构化输入输出：规定 AI 的输入和输出格式，比如用 JSON 格式返回结果。
• 工具调用：让 AI 用外部工具，比如获取当前时间或搜索网页。
• RAG 与记忆：通过 RAG 或记忆机制，从向量存储检索知识（长期记忆），提供相关背景或缓存历史查询。
• 管理状态与历史上下文：让 AI 记住之前的操作或状态（短期记忆），方便优化或修改。

上下文工程的目标是让 AI 的“上下文窗口”（Context Window）里的内容尽可能精准、有效，同时过滤掉无关或噪声信息。

这里我会带大家看一个具体例子，讲讲构建AI 智能体时上下文工程是什么样的。

2、上下文工程的实际应用

看看我最近做的一个例子：为个人用的多智能体深度研究应用做上下文工程。

我在n8n里构建了Agent工作流，工具不重要。完整的Agent架构像这样：

工作流中的“搜索规划智能体”负责根据用户查询生成搜索计划。

系统提示

这是我为这个子Agent写的系统提示：

你是专业的研究规划师。任务是把复杂的研究查询（用<user_query></user_query>界定）分解成具体的搜索子任务，每个子任务专注不同方面或来源类型。

当前日期和时间：{{ $now.toISO() }}

每个子任务需要：
1. 唯一字符串ID（比如'subtask_1'、'news_update'）
2. 专注主查询某方面的具体搜索查询
3. 搜索来源类型（网页、新闻、学术、专业）
4. 时间相关性（今天、上周、最近、过去一年、所有时间）
5. 领域重点（如果适用，比如技术、科学、健康等）
6. 优先级（1最高到5最低）

每个子任务必须有所有字段（id、query、source_type、time_period、domain_focus、priority），除非时间周期和领域重点不适用，可以为null。

创建2个子任务，共同覆盖主题的全部内容。专注不同方面、视角或信息来源。

每个子任务包括：
id: str
query: str
source_type: str  # 比如"web"、"news"、"academic"、"specialized"
time_period: Optional[str] = None  # 比如"today"、"last week"、"recent"、"past_year"、"all_time"
domain_focus: Optional[str] = None  # 比如"technology"、"science"、"health"
priority: int  # 1最高到5最低

获取子任务信息后，添加start_date和end_date两个字段。根据当前日期和所选时间周期推断这些信息。格式如下：
"start_date": "2024-06-03T06:00:00.000Z",
"end_date": "2024-06-11T05:59:59.999Z",

这个提示词有很多部分需要仔细考虑，要给“规划智能体”提供准确的上下文，让它有效完成任务。这不是简单设计提示或指令，而是需要实验，给模型提供重要上下文，让它最好地执行任务。

我们把问题分解成上下文工程的核心组件。

指令

指令是给系统的高级指导，明确告诉它做什么。

你是专业的研究规划师。任务是把复杂的研究查询（用<user_query></user_query>界定）分解成具体的搜索子任务，每个子任务专注不同方面或来源类型。

很多新手甚至有经验的AI开发者到这里就停了。但看了完整提示就知道，要让系统按我们的想法工作，需要给多少上下文。这就是上下文工程：告诉系统更多问题范围和具体需求。

用户输入

系统提示里没显示用户输入，举个例子：

<user_query> OpenAI的最新开发新闻是什么？</user_query>

注意用了分隔符，这是为了更好地构建提示词结构，避免混淆，明确用户输入和我们希望系统生成的内容。有时输入的信息类型和希望模型输出的内容相关（比如查询是输入，子查询是输出）。

结构化输入和输出

除了高级指令和用户输入，我还花了很多精力在规划智能体需要生成的子任务细节上。这是给规划智能体的详细指令，让它根据用户查询创建子任务：

每个子任务需要：

1. 唯一字符串ID（比如'subtask_1'、'news_update'）
2. 专注主查询某方面的具体搜索查询
3. 搜索来源类型（网页、新闻、学术、专业）
4. 时间相关性（今天、上周、最近、过去一年、所有时间）
5. 领域重点（如果适用，比如技术、科学、健康等）
6. 优先级（1最高到5最低）

每个子任务必须有所有字段，除非时间周期和领域重点不适用，可以为null。

创建2个子任务，共同覆盖主题的全部内容。专注不同方面、视角或信息来源。

仔细看指令，我列出了希望规划智能体生成的必要信息，还有提示词和例子，帮助指导数据生成过程。这很重要，能给Agent提供关于预期输出的额外上下文。比如，如果不告诉它优先级是1-5，系统可能会用1-10的范围。这些上下文很重要！

接下来是结构化输出。为了从规划智能体得到一致的输出，我们还提供了子任务格式和字段类型的上下文。这是作为额外上下文传给智能体的示例：

每个子任务包括：id: strquery: strsource_type: str  # 比如"web"、"news"、"academic"、"specialized"time_period: Optional[str] = None  # 比如"today"、"last week"、"recent"、"past_year"、"all_time"domain_focus: Optional[str] = None  # 比如"technology"、"science"、"health"priority: int  # 1最高到5最低

另外，在n8n里可以用工具输出解析器，本质上是用来构建最终输出结构的。我用的选项是提供JSON示例：

每个子任务包括：
id: str
query: str
source_type: str  # 比如"web"、"news"、"academic"、"specialized"
time_period: Optional[str] = None  # 比如"today"、"last week"、"recent"、"past_year"、"all_time"
domain_focus: Optional[str] = None  # 比如"technology"、"science"、"health"
priority: int  # 1最高到5最低

然后工具会从这些示例自动生成模式，让系统解析和生成合适的结构化输出，比如：

[
 {
   "action": "parse",
   "response": {
     "output": {
       "subtasks": [
         {
           "id": "subtask_1",
           "query": "OpenAI recent announcements OR news OR updates",
           "source_type": "news",
           "time_period": "recent",
           "domain_focus": "technology",
           "priority": 1,
           "start_date": "2025-06-24T16:35:26.901Z",
           "end_date": "2025-07-01T16:35:26.901Z"
         },
         {
           "id": "subtask_2",
           "query": "OpenAI official blog OR press releases",
           "source_type": "web",
           "time_period": "recent",
           "domain_focus": "technology",
           "priority": 1.2,
           "start_date": "2025-06-24T16:35:26.901Z",
           "end_date": "2025-07-01T16:35:26.901Z"
         }
       ]
     }
   }
 }
]

这看起来复杂，但现在很多工具都支持结构化输出，不需要自己实现。n8n让上下文工程这部分变得简单。这是很多AI开发者忽略的点，希望上下文工程能让这些技术更清晰。当Agent输出不一致，需要用特殊格式传给工作流下一个组件时，这是很强大的方法。

工具

我们用n8n构建智能体，很容易在上下文里加入当前日期和时间，像这样：

当前日期和时间：{{ $now.toISO() }}

这是n8n里的简单函数，通常会做成专用工具，让内容更动态（比如只在查询需要时获取日期时间）。这就是上下文工程：迫使开发者决定是否传递上下文，以及何时传给LLM，消除应用中的假设和不准确。

日期和时间是系统的重要上下文，否则处理需要当前日期时间的查询时表现不好。比如，让系统搜索上周OpenAI的最新新闻，它会猜测日期，导致查询不好，搜索结果不准确。有了正确的日期时间，系统能更好推断日期范围，这对搜索Agent和工具很重要。我把这作为上下文的一部分，让LLM生成日期范围：

获取子任务信息后，添加start_date和end_date字段。根据当前日期和所选时间周期推断这些信息，格式如下：
"start_date": "2024-06-03T06:00:00.000Z",
"end_date": "2024-06-11T05:59:59.999Z",

我们关注架构中的规划智能体，不需要加太多工具。另一个有用的工具是检索工具，根据查询检索相关子任务，下面讨论这个想法。

RAG & 记忆

我建的深度研究应用第一个版本不需要短期记忆，但有个版本会为不同用户查询缓存子查询，这能优化工作流速度。如果用户之前用过类似查询，可以把结果存在向量存储里，搜索时就不用重新生成子查询，节省LLM API的延迟和成本。

这是聪明的上下文工程，让应用更动态、便宜、高效。上下文工程不只是优化提示，还是为目标选择正确的上下文。还可以更有创意地维护向量存储，把现有子任务加入上下文。有创意的上下文工程是优势！

状态与历史上下文

深度研究Agent v1没展示，但项目的重要部分是优化结果生成最终报告。很多时候，Agent系统需要修改部分或全部查询、子任务，以及从网络搜索API获取的数据。这意味着系统会多次尝试解决问题，需要访问之前的状态和历史上下文。

在我们的用例中，这可能是让Agent访问子任务状态、修订（如果有）、工作流中每个Agent的过去结果，以及修订阶段需要的其他上下文。传递什么内容取决于优化目标，这里需要做很多决策。上下文工程不简单，需要多次迭代。这就是为什么评估很重要：不衡量怎么知道上下文工程有没有用？

3、高级上下文工程[展望]

本文没涵盖上下文工程的其他方面，比如上下文压缩、管理技术、安全性，以及评估上下文有效性。未来文章会分享这些主题的想法。

上下文可能变低效（充满陈旧不相关的信息），需要特殊评估流程发现这些问题。

我认为上下文工程会成为AI开发者的重要技能。除了手动上下文工程，还可以构建自动化方法。我见过一些工具尝试这样做，但这个领域需要更多进展。

4、如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】