提示词工程还没玩明白，又多了一个新词叫上下文工程！

这两年在AI圈子里，真的是新名词、新概念、新模型层出不穷，貌似隔段时间不出现一个新词感觉整个行业都退步了一样，大家都还在学习怎么使用好Prompt Engineering（提示词工程）的时候，这不Context Engineering（上下文工程）这个新词就出来了。

这篇内容来分享一下关于Context Engineering（上下文工程）这个新词的介绍、提示词工程和上下文工程的区别、以及二者在实际工作中的作用是什么，毕竟，现在AI圈子里面的新东西还是要跟上节奏学习的。

首先还是要先说一下这个背景，也就是为什么会提出一个Context Engineering（上下文工程）概念，以及它所解决的问题是啥。

我们其实还是要回到AI应用场景中来，对于AI Agents（AI 智能体）来说，简单的可以认为它是由多个工作流编排而生成的，而工作流编排中可能会设计到非常多环节，我们可以通过下图来理解（基于n8n来构建的Agent）

这种流程需要管理构成完整上下文的不同类型的信息：

• 系统指令，用于设定行为和规则
• 对话历史记录和用户偏好
• 从文档或数据库中检索信息
• 可用的工具及其定义
• 结构化输出格式和模式
• 实时数据与外部 API 响应

对应的技术架构示意图如下：

如果想让 AI Agent 做某件事，我们需要在不恰当的时机以不恰当的格式提供正确的上下文。

那其实就是上下文工程发挥作用的地方。

这不仅仅是与 LLM 对话；它还关于设置围绕它的整个环境，以便它能够做出好的决策。

实际操作中是这样的：

1. 用户输入：他们正在询问什么

2. 聊天历史：AI 具有记忆

3. 用户数据：偏好设置、历史行为、个性化

4. RAG 上下文：从文档、网站和向量数据库中提取

5. Tool Function：API、搜索、计算器，需要什么就有什么

6.  理由：Agent可以规划、反思和适应

关于短期记忆（Short-Term Memory）和长期记忆（Long-Term Memory）

• 短期记忆 ： 它主要是在当前的上下文窗口中
• 长期记忆 ：存储在独立的向量数据库中

对于大模型来说，提供给它完整结构化的的信息（上下文内容）比一个固定带有话术/措辞的内容（提示词）要重要，因为模型首先要先完整的理解这些信息，才能给出准备的答复，而完整的信息并不是一个简单的提示词，还包含了过去我们所沟通的历史信息，以及前期所设定的内容范围。

所以，很多时候，模型返回的信息不准确，通常不是模型的问题，而是我们给模型输入的内容缺少前后背景信息。

提示词是起点，上下文就是系统。

上下文工程与提示词工程的区别是什么？

提示词工程简单来说用于单次窗口对话，而对于复杂、系统化的工程来说，它不仅仅是一个单次对话那么简单，而是要包含所有前面的对话内容、内置的提示词信息等等

在上下文工程里面也是包含了提示词内容，可以说提示词工程是上下文工程其中的一个子集，比如：

我们让 ChatGPT “写一封专业的电子邮件”，那这个就是一个提示词，我们是在为单个任务编写指令，但如果你正在构建一个需要记住之前工单、访问用户账户详细信息并在多次交互中保持对话历史记录的客户服务机器人，那就是上下文工程。

上下文工程是构建动态系统，以在正确的格式中提供正确的信息和工具，使得 LLM 能够合理地完成任务。

大部分情况下，当Agent表现不可靠时，根本原因在于适当的上下文、指令和工具没有传达给模型。

与此同时，LLM 应用正从单一提示词模式发展到更复杂、动态的 AI Agent系统，因此，上下文工程正成为 AI 工程师可以发展的 最重要技能 

所以，在很多公司招聘中，除了提示词工程时，还会有上文下工程师，这也是一项职业技能。

大多数 AI 应用都同时使用提示工程和上下文工程，在上下文工程系统中，我们其实仍然需要精心编写的提示，而区别在于，这些提示现在与经过仔细编排的前提和背景信息一起运行，而不是每次都从头开始。

上下文工程在应用中的实践

当我们开始构建需要处理复杂、相互关联信息的 AI 应用时，上下文工程便从理论走向现实构建 AI 应用考虑一个需要支持内部业务系统、当前信息处理状态，并参考产品文档的客户服务机器人，同时还要保持友好的对话语气。这就是传统提示方法失效而上下文工程变得必要的地方。

1. RAG 系统

上下文工程可以说始于检索增强生成 (RAG) 系统。RAG 是最早让 LLMs 接触到其原始训练数据之外信息的技术之一。

RAG 系统使用先进的上下文工程技术来更有效地组织和呈现信息。它们将文档分解为有意义的片段，按相关性对信息进行排序，并在令牌限制内包含最实用的细节。

在 RAG 之前，如果你想让 AI 回答关于你公司内部文件的问题，你必须重新训练或微调整个模型。RAG 通过构建能够搜索你的文件、找到相关片段，并将它们与你的问题一起包含在上下文窗口中，改变了这一点。

这意味着 LLMs 突然能够分析多个文档和来源，以回答通常需要人类阅读数百页才能回答的复杂问题。

2. AI Agent

RAG 系统为外部信息打开了大门，但 AI 代理通过使上下文动态和响应式，将这一点进一步推进。代理在对话过程中使用外部工具，而不仅仅是检索静态文档。

AI 决定哪个工具最能解决当前问题。一个代理可以开始对话，意识到需要当前的股票数据，调用金融 API，然后使用这些最新信息继续对话。

3. AI 编程助手

例如如 Cursor 代表了上下文工程最先进的应用之一，因为AI编程助手处理高度结构化、相互关联的信息时，结合了 RAG 和AI Agent的技术。

这些系统不仅需要理解单个文件，还需要理解整个项目架构、模块之间的依赖关系以及代码库中的编码模式。

当你要求代码助手重构一个函数时，它需要了解该函数的使用位置、期望的数据类型以及更改可能如何影响项目的其他部分。

在此，上下文工程变得至关重要，因为代码具有跨越多个文件甚至多个存储库的关系。一个好的编码助手会维护关于你的项目结构、你最近所做的更改、你的编码风格以及你正在使用的框架的上下文信息。

上下文工程可能存在的问题

好了，上面其实基本讲清楚了关于上下文工程相关的内容，以及在实际应用场景中是怎么体现出上下文的作用的，那反过来说，这东西难道就没有其它问题吗？毕竟，如果我们要做一个很复杂的、超长链路的Agent服务时，中间要处理的上下文信息可能要非常庞大，Token数量也会用的非常庞大。

带着这个疑问，找到了一篇关于上下文工程中异常/失败问题的论述，博客放在文末了，该兴趣的读者可以直接查看原版，这里我总结归纳为几点：

总体来说，会出现四个上下文异常/失败问题：

第一：上下文污染

上下文污染是指幻觉或其他错误进入上下文，并被反复引用。

这个问题的一种特别严重的表现形式是“上下文中毒”——上下文（目标、摘要）的许多部分被关于游戏状态的错误信息“污染”，这通常需要很长时间才能纠正。结果，模型可能会执着于实现不可能或不相关目标。

第二：上下文干扰

上下文干扰是指当上下文变得过长时，模型过度关注上下文，忽视了在训练过程中所学到的内容。

在AI Agent工作流程中，随着上下文增长，即模型收集更多信息并积累历史，累积的上下文可能会变得令人分心，而不是有所帮助。 

第三：上下文混淆

上下文混淆是指模型在生成低质量响应时，使用了上下文中多余的内容

如果把某些内容放入上下文中 模型就必须关注它，这可能是无关紧要的信息或由无用的工具定义，但模型 会 将其纳入考虑范围。

大型模型，尤其是推理模型，在忽略或丢弃冗余上下文方面正变得越来越好，但我们持续看到无用的信息让Agent陷入困境。

总之来说，越长的上下文能够容纳更多的信息，但这种能力伴随着弊端，就是容易混淆。

第四：上下文冲突

上下文冲突是指你在当前上下文中积累的新信息或工具与其他上下文中的信息发生冲突。

这是一个更麻烦版本的《 上下文混淆 》：这里的坏上下文并非无关紧要，它直接与其他提示中的信息冲突。

微软和 Salesforce 团队从多个基准测试中获取提示，并将他们的信息“分片”到多个提示中。可以这样理解：

有时，在按下回车键之前，你可能会坐下来在 ChatGPT 或 Claude 中输入段落，考虑每一个必要的细节。

其他时候，你可能会从一个简单的提示开始，然后在聊天机器人的回答不令人满意时添加更多细节。微软/Salesforce 团队修改了基准测试提示，使其看起来像这些多步骤的交流：

图片

本文转载自​​​DataForAI​​​，作者：​​DataForAI​​​