提示工程已死？上下文工程才是大模型开发的“黄金标准“，小白秒变AI大神！

几年前，包括一些顶尖的 AI 研究人员在内的许多人声称，提示工程（prompt engineering）很快就会消亡。

显然，他们大错特错。事实上，提示工程现在比以往任何时候都更加重要，其重要性甚至让它被重新命名为上下文工程（context engineering）。

没错，这又是一个花哨的术语，用来描述调整大型语言模型（LLM）所需指令和相关上下文，以使其有效执行任务的重要过程。

关于上下文工程，已经有很多人撰写了文章（Ankur Goyal、Walden Yan、Tobi Lutke 和 Andrej Karpathy 等），但我想分享我对这个主题的看法，并提供一个具体的、循序渐进的指南，将上下文工程应用于 AI 智能体工作流的开发中。

我不确定是谁首次提出了“上下文工程”这个词，但我们将以 Dex Horthy 的下图为基础，它简要解释了上下文工程的一些内容。

我喜欢“上下文工程”这个术语，因为它感觉更宽泛，能更好地解释提示工程中的大部分工作，包括其他相关任务。

对提示工程是否是一项严肃技能的疑虑在于，许多人将其与盲目提示（你在 ChatGPT 等 LLM 中使用的简短任务描述）混淆。在盲目提示中，你只是向系统提问。而在提示工程中，你需要更仔细地考虑提示的上下文和结构。也许它从一开始就应该被称为上下文工程。

上下文工程是下一个阶段，你将构建完整的上下文，这在许多情况下需要超越简单的提示，进入更严格的方法来获取、增强和优化系统的知识。

从开发者的角度来看，上下文工程涉及一个迭代过程，用于优化你提供给 LLM 的指令和上下文，以达到期望的结果。这包括建立正式的流程（例如，评估管道）来衡量你的策略是否有效。

鉴于 AI 领域的快速发展，我建议对上下文工程给出更广泛的定义：为 LLM 和高级 AI 模型设计和优化指令及相关上下文，使其有效执行任务的过程。这不仅包括基于文本的 LLM，还包括优化多模态模型的上下文，这些模型正变得越来越普遍。这可以涵盖所有的提示工程工作以及相关过程，例如：

设计和管理提示链（如果适用）
调整指令/系统提示
管理提示的动态元素（例如，用户输入、日期/时间等）
搜索和准备相关知识（即 RAG）
查询增强
工具定义和指令（在智能体系统中）
准备和优化少样本演示
结构化输入和输出（例如，分隔符、JSON 模式）
短期记忆（即管理状态/历史上下文）和长期记忆（例如，从向量存储中检索相关知识）
以及许多其他有助于优化 LLM 系统提示以实现所需任务的技巧。

换句话说，你在上下文工程中试图实现的是优化你在 LLM 上下文窗口中提供的信息。这也意味着过滤掉嘈杂信息，这本身就是一门科学，因为它需要系统地衡量 LLM 的性能。

每个人都在谈论上下文工程，但在这里，我们将通过一个具体的例子，向你展示在构建 AI 智能体时上下文工程是如何运作的。

上下文工程实战

让我们看一个我为个人使用而构建的多智能体深度研究应用程序中，近期上下文工程工作的具体例子。

我在 n8n 中构建了这个智能体工作流，但工具并不重要。我构建的完整智能体架构如下所示：

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

以下是我为这个子智能体整理的系统提示：

你是一名专业的调研规划师。你的任务是将一个复杂的调研查询（由 <user_query></user_query> 分隔）分解为具体的搜索子任务，每个子任务侧重于不同的方面或源类型。 当前的日期和时间是：{{ $now.toISO() }}对于每个子任务，请提供：1. 子任务的唯一字符串 ID（例如，“subtask_1”、“news_update”）2. 专注于主查询某个方面的具体搜索查询3. 要搜索的源类型（web、news、academic、specialized）4. 时间段相关性（today、last week、recent、past_year、all_time）5. 如果适用，提供领域焦点（technology、science、health 等）6. 优先级（1-最高到 5-最低） 每个子任务的所有字段（id、query、source_type、time_period、domain_focus、priority）都是必需的，除了 time_period 和 domain_focus，如果它们不适用，可以为空。 创建 2 个子任务，它们将共同提供对主题的全面覆盖。侧重于不同的方面、视角或信息来源。每个子任务将包含以下信息：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（最低）在获取上述子任务信息后，你将添加两个额外的字段。它们对应于 start_date 和 end_date。根据当前日期和选择的 time_period 推断此信息。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. 要搜索的源类型（web、news、academic、specialized）4. 时间段相关性（today、last week、recent、past_year、all_time）5. 如果适用，提供领域焦点（technology、science、health 等）6. 优先级（1-最高到 5-最低） 每个子任务的所有字段（id、query、source_type、time_period、domain_focus、priority）都是必需的，除了 time_period 和 domain_focus，如果它们不适用，可以为空。 创建 2 个子任务，它们将共同提供对主题的全面覆盖。侧重于不同的方面、视角或信息来源。

如果你仔细查看上面的指令，我决定将所需信息的列表结构化，并提供一些提示/示例，以更好地帮助引导数据生成过程。这对于为智能体提供关于期望结果的额外上下文至关重要。例如，如果你不告诉它你希望优先级为 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 示例，如下所示：

{ "subtasks": [ { "id": "openai_latest_news", "query": "latest OpenAI announcements and news", "source_type": "news", "time_period": "recent", "domain_focus": "technology", "priority": 1, "start_date": "2025-06-03T06:00:00.000Z", "end_date": "2025-06-11T05:59:59.999Z" }, { "id": "openai_official_blog", "query": "OpenAI official blog recent posts", "source_type": "web", "time_period": "recent", "domain_focus": "technology", "priority": 2, "start_date": "2025-06-03T06:00:00.000Z", "end_date": "2025-06-11T05:59:59.999Z" },...}

然后，该工具将自动从这些示例生成 schema，从而允许系统解析并生成适当的结构化输出，如下面的示例所示：

[ { "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 开发者出于某种原因忽略的被低估的方面。希望上下文工程能让这些重要技术受到更多关注。这是一种非常强大的方法，特别是当你的智能体获得不一致的输出，而这些输出需要以特殊格式传递给工作流中的下一个组件时。

工具

我们正在使用 n8n 构建我们的智能体，因此很容易将当前日期和时间放入上下文中。你可以这样做：

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

这是一个在 n8n 中调用的简单、方便的函数，但通常会将其构建为专用工具，以帮助使事情更具动态性（即，仅在查询需要时获取日期和时间）。这就是上下文工程的意义所在。它迫使你，作为构建者，做出具体的决定：何时以及将什么上下文传递给 LLM。这很棒，因为它消除了应用程序中的假设和不准确性。

日期和时间对于系统来说是重要的上下文；否则，它在处理需要当前日期和时间知识的查询时往往表现不佳。例如，如果我要求系统搜索上周发生的 OpenAI 最新开发新闻，它只会猜测日期和时间，这会导致次优查询，从而导致不准确的网络搜索结果。当系统拥有正确的日期和时间时，它可以更好地推断日期范围，这对于搜索智能体和工具来说很重要。我将其作为上下文的一部分，以允许 LLM 生成日期范围：

在获取上述子任务信息后，你将添加两个额外的字段。它们对应于 start_date 和 end_date。根据当前日期和选择的 time_period 推断此信息。start_date 和 end_date 应使用如下所示的格式："start_date": "2024-06-03T06:00:00.000Z","end_date": "2024-06-11T05:59:59.999Z",

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

RAG 与记忆

我构建的这个深度研究应用程序的第一个版本不需要使用短期记忆，但我们已经构建了一个版本，它为不同的用户查询缓存子查询。这有助于在工作流中实现一些加速/优化。如果用户之前已经使用了类似的查询，则可以将这些结果存储在向量存储中并对其进行搜索，以避免为我们已经生成并存在于向量存储中的计划创建新的子查询集。请记住，每次调用 LLM API 都会增加延迟和成本。

这是一种巧妙的上下文工程，因为它使你的应用程序更具动态性、更便宜、更高效。你看，上下文工程不仅仅是优化你的提示；它是选择适合你目标目标的正确上下文。你还可以更具创意地维护向量存储以及如何将这些现有子任务引入上下文。富有创意和新颖的上下文工程是你的护城河！

状态与历史上下文

在我们的深度研究智能体 v1 中没有显示，但这个项目的一个重要部分是优化结果以生成最终报告。在许多情况下，智能体系统可能需要修改全部或部分查询、子任务，以及可能从网络搜索 API 中提取的数据。这意味着系统将多次尝试解决问题，并且需要访问以前的状态以及系统中可能存在的所有历史上下文。

这在我们的用例中意味着什么？在我们的示例中，它可以是让智能体访问子任务的状态、修订（如果有）、工作流中每个智能体过去的成果，以及其他任何在修订阶段必要的上下文。对于这种类型的上下文，我们传递的内容将取决于你所优化的目标。这里将会有很多决策。上下文工程并非总是直截了当的，我想你可以开始想象这个组件需要多少次迭代。这就是为什么我继续强调其他领域的重要性，例如评估。如果你不衡量所有这些事情，你怎么知道你的上下文工程工作是否有效？

总结

本文没有涵盖上下文工程的许多其他方面，例如上下文压缩、上下文管理技术、上下文安全以及评估上下文有效性（即衡量上下文随时间变化的有效性）。我们将在未来的文章中分享更多关于这些主题的想法。

上下文可能会稀释或变得低效（即充满陈旧和不相关的信息），这需要特殊的评估工作流来捕捉这些问题。

我预计上下文工程将继续发展，成为 AI 开发者/工程师的一项重要技能。除了手动上下文工程之外，还有机会构建自动化有效上下文工程流程的方法。我见过一些尝试这样做的工具，但这个领域需要更多的进展。请继续关注我即将发布的文章中关于这方面的更多想法。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～