作者：来自ElasticTomás Murúa
了解上下文工程和提示词工程的区别，以及为什么同时掌握两者对于构建生产级 AI agents 和 RAG 系统至关重要。
Elasticsearch与行业领先的 GenAI工具和提供商有原生集成。查看我们关于超越 RAG 基础知识的网络研讨会，或使用 Elastic 向量数据库构建生产级应用的内容。
为了为你的用例构建最佳搜索解决方案，现在可以开始免费云试用或在本地机器上尝试 Elastic。
在 Web 开发的早期，网页设计是一个涵盖从视觉美学到用户工作流程的单一学科。随着行业的发展，它分裂成两个不同领域：用户界面 (UI) 和用户体验 (UX)。它们仍然相互关联，但每个都需要不同的专业知识和工具。
我们在 AI 中也看到类似的分化。自 2022 年 11 月 ChatGPT 推出以来，行业一直专注于优化提示词以改善大型语言模型 (LLM) 的交互。随着我们构建更复杂的 AI 系统，尤其是需要访问外部知识的 agents 和 Model Context Protocol (MCP) 工具，出现了两个不同的学科：提示词工程和上下文工程。虽然它们协同工作，但解决的是根本不同的挑战。
提示词工程关注你如何与模型交流。上下文工程关注模型在生成响应时可以访问哪些信息。
什么是提示词工程？
提示词是用于指导生成式 AI 模型输出的输入。提示词可以由文本、图像、声音或其他媒体组成。
提示词工程是不断优化你与模型交流方式以获得更好结果的迭代过程。它关注在单次交互中你使用的词语、结构和技巧。
以下是一些提示词工程技术示例：
![]()
常见技术包括少量示例提示（提供示例）、链式思维推理（要求模型展示其推理过程）和角色分配（赋予模型一个角色）。这些技术应对诸如歧义的挑战，即一个问题可能有多种解读，模型必须猜测用户意图的解读。
提示词工程的一个关键挑战是找到 Anthropic 所称的 “指令的正确高度”。在一个极端，工程师在提示中硬编码复杂且脆弱的逻辑以预见每种场景，这会导致系统脆弱且维护成本高。在另一个极端，工程师提供模糊指导，无法给模型具体信号，或错误假设共享上下文。最优高度在两者之间取得平衡：足够具体以指导行为，同时足够灵活以让模型应用良好判断。
提示词工程通常在单轮交互层面运作，优化你如何表述一个查询以获得最佳响应。这在简单交互中效果很好，但当任务需要外部知识、持久状态或多步推理时，会达到其极限。
欲深入了解提示词工程技术，请参考《The Prompt Report: 提示词技术系统调查》。
什么是上下文工程？
上下文工程是在 LLM 推理过程中策划和维护最优 token 集合的更广泛学科。提示词工程问的是，“我应该如何表述这个？”，而上下文工程问的是，“模型现在需要访问哪些信息？”
![]()
正如12-Factor Agents框架所解释的，LLM 是无状态函数，将输入转化为输出。在任意时刻，你对 LLM 的输入本质上是，“这是到目前为止发生的情况。下一步是什么？”每次交互都成为上下文：
- 你给模型的提示和指令。
- 通过检索增强生成（RAG）获取的文档或外部数据。
- 过去的状态、工具调用或其他历史。
- 关于结构化数据输出格式的指令。
这个区分很重要，因为现代 AI agents 并不是单轮操作。一个循环运行的 agent 会生成一个不断扩展的信息宇宙：工具输出、检索文档、对话历史、中间推理。上下文工程就是决定在任何给定时刻，来自这个信息宇宙的哪些内容进入模型有限工作内存的实践。
关于上下文工程的组件和最佳实践的全面探讨，请参考《什么是上下文工程？》和《你知道，为了上下文》。
主要区别：提示词工程 vs. 上下文工程
![]()
单轮 vs. 多轮
提示词工程优化单次交互。上下文工程考虑序列：前几轮建立了什么？工具输出携带了哪些信息？三步之后应该保留什么？随着任务从简单问答转向多步 agent 工作流，上下文工程成为主要挑战。
上下文窗口管理
上下文工程管理有限资源，有三种失败模式：
- 信息过少导致幻觉或错误响应。当 LLM 缺乏足够上下文时，无法确定语义上下文来生成准确响应。
- 信息过多导致上下文溢出。它会压垮 LLM 的注意力范围，降低整个上下文窗口的相关性，使模型难以判断哪些部分最重要。
- 分散或冲突信息会让模型混淆。更大的上下文窗口增加了出现冲突或无关信息的机会，从而干扰 LLM 回答。
关键区别：提示词工程将上下文窗口视为既定。上下文工程主动策划上下文窗口。
工具编排
提示词工程可以请求使用工具并描述工具应做什么。上下文工程决定可用哪些工具、传递给工具哪些信息，以及它们的输出如何流回上下文。
最常见的失败模式之一是工具集膨胀且功能重叠。如果人工工程师无法明确指出在特定情况下应使用哪个工具，则不能期望 AI agent 做得更好。上下文工程应用明确原则：策划最小可行工具集。每个工具应独立、自我容错且目的明确。工具还应高效使用 token，仅返回必要信息，而不是提供所有可用内容。
即时上下文 vs. 预检索
传统 RAG 系统会预处理并提前检索所有可能相关数据，在推理前将其加载到提示中。上下文工程越来越倾向即时策略，例如 Anthropic 的 Agent Skills，agent 会发现并动态加载到上下文中。
Agent 不会一次性加载所有内容，而是保持轻量引用（文件路径、存储查询、文档 ID），并在运行时使用工具动态加载数据。这类似人类认知：我们不会记住整本书，而是维护文件夹和书签等系统按需检索信息。
权衡在于速度与精度。预检索速度更快，但存在上下文溢出风险。即时检索速度较慢，但保持上下文窗口集中。最有效的 agents 通常采用混合方法：提前检索必要的基础上下文，同时在需要时允许进一步探索。
实际示例：图书推荐 agent
为了演示提示词工程和上下文工程如何协同工作，我们使用 Elastic Agent Builder 构建了一个图书推荐 agent，数据集包含在 Elasticsearch 中索引的 103,063 本书。
设置：
映射：
{
"mappings": {
"properties": {
"@timestamp": { "type": "date" },
"Authors": { "type": "text" },
"Category": { "type": "text" },
"Description": { "type": "text" },
"Price Starting With ($)": { "type": "double" },
"Published Date": { "type": "date", "format": "iso8601" },
"Publisher": { "type": "text" },
"Title": { "type": "text" }
}
}
我们测试了三个场景，以展示基于提示词质量和上下文管理的不同结果。
场景 1：提示词工程失败（歧义）
- 用户提示：“推荐一本好书 - Recommend a good book”
Agent 搜索了 “高评分流行书籍 - highly rated popular books”，返回的结果涉及拉布拉多犬和保罗·赖瑟喜剧书籍，都不符合典型的 “好书” 预期。
- 问题：Agent 必须猜测 “好” 的含义，没有任何筛选标准。LLM 根据其对 “好书” 的假设来解释请求，而不是根据用户偏好。
![]()
场景 2：上下文工程失败（信息过多）
- 用户提示：“从数据库检索所有书籍 - Retrieve all books from the database ”
生成的 Elasticsearch Query Language (ES|QL) 查询：
FROM books-dataset
| LIMIT 100
- 检索到的上下文：来自所有类别的 100 本随机书籍（烹饪、历史和小说混合在一起）
- 问题：信息过多且未筛选。Agent 带入了过多上下文，使得找到相关书籍变得困难，答案不完整。
![]()
场景 3：两种学科协同工作
- 用户提示：“我喜欢《指环王》或《基地》这样的科幻和奇幻小说。帮我找到符合这些偏好的书籍。”
Agent 执行了针对性搜索，检索到相关书籍：《王者归来》、《沙丘：科里诺家族》、《远方地平线》（收录《基地》和《沙丘》宇宙故事的合集）。
- 搜索查询：“类似《指环王》或《基地》的科幻和奇幻书籍”
![]()
Agent 推理
该 agent 通过智能工具使用和聚焦检索展示了上下文工程：
![]()
Agent 使用 platform.core.search 对 books-dataset 索引进行针对性搜索：“类似《指环王》《基地》的科幻奇幻书籍”。在 103,063 条文档中，它仅检索到最相关的匹配项。
为何有效
- 提示词工程：明确的类型说明和具体示例（《指环王》《基地》）消除了歧义。
- 上下文工程：聚焦检索，仅带入相关书籍，尽管数据集有 103,063 条目，但仍保持可管理的上下文窗口。
该 agent 在三种场景中使用相同工具，但输入质量决定了这些工具检索相关上下文的效率。
结论
提示词工程和上下文工程是不同但互补的学科。最初作为一般提示实践的领域，正在分化为需要不同专业知识的专门领域，就像网页开发中的 UI/UX 分裂一样。
对于简单问答，提示词工程技能可能足够。但随着系统复杂度增加，加入检索、工具和多步推理，上下文工程成为主要挑战。构建生产级 AI 系统的团队需要两种技能，而且越来越需要理解两种学科如何交互的实践者。
要深入了解 AI agents 的上下文工程策略，包括混合检索、语义分块和 agent 搜索模式，请参阅《AI agents 上下文工程中相关性影响》。
原文：Context engineering vs. prompt engineering - Elasticsearch Labs
