什么是上下文工程？

什么是上下文工程？

上下文工程是一种在正确的时间向 AI 系统提供正确信息的实践。可以把它想象成给一位新同事准备一份简报：你不会把公司的所有文档都堆在他的办公桌上，而是会根据他的具体任务，仔细选择最相关的信息。

现代 AI agent 需要访问大量的数据、文档、数据库、电子邮件和代码，但它们一次只能处理有限的信息量。上下文工程的核心是智能地选择、组织和提供 AI 做出良好决策所需要的准确信息，同时避免用不必要的信息让它不堪重负。做好上下文工程，就能让 AI 从只能给出泛泛的回答，变成能够基于你的具体数据提供真正有帮助且准确的答案。

更多阅读：什么是上下文工程 (Context Engineering)？

为什么需要上下文工程？原始 LLM 的局限性

LLM 和 推理模型 （RMs）是现代应用中的强大组件，但它们存在一个根本性的局限：LLM 的性能并不完全取决于其内部的静态知识。它在实际应用中的成功，很大程度上取决于推理时刻提供给它的外部信息和工具。

默认情况下，LLM 存在四个主要限制：

• **静态知识：**它们对世界的理解会冻结在最后一次训练的时间点，因此无法了解当前发生的事件。

• **无法访问私有数据：**它们无法原生访问你公司的实时专有数据，包括包含最有价值上下文的文档、指标和日志。

• **幻觉和缺乏事实依据：**模型通过预测序列中下一个最有可能出现的 token 来工作。这一过程针对语言连贯性进行了优化，而不是事实验证，因此可能生成听起来合理但事实上不正确的信息。

• **下文漂移和缺乏记忆：**由于缺乏持久的上下文或记忆，agent 在处理多步骤任务时会遇到困难。如果没有办法回忆之前的决策，其推理就会发生 "漂移"，导致它反复以不一致的方式重新推断信息，并在复杂工作流中失败。

这促成了上下文工程的出现。上下文工程是一种新兴实践，专注于构建可靠、有状态的 AI agents。上下文工程将关注点从提示工程进一步扩展。提示工程针对单次交互设计指令，而上下文工程则负责管理完整的上下文，让 agent 能够处理多步骤、复杂的任务。上下文工程是一门管理模型有限注意力的艺术。这一实践涉及设计围绕模型的整个信息生态系统：在任意时刻整理其 上下文窗口 ，并策略性地决定哪些来自用户消息、工具输出或其自身内部思考的信息能够进入 agent 有限的"工作记忆"。

上下文工程借鉴了成熟的软件工程原则。正如开发者在传统系统中设计数据库、API 和数据管道来优化信息流一样，上下文工程师设计驱动智能 agent 的信息架构。上下文工程师负责管理哪些信息占据 LLM 有限的工作记忆****（上下文窗口），以及哪些信息从持久记忆（例如 向量数据库 ）中检索。上下文工程认识到，即使是能力最强大的 LLM，也无法弥补结构不合理、不完整或不相关的上下文。

关键区别：上下文工程与提示工程

虽然这两个术语经常被交替使用，但它们代表了不同的抽象层次。提示工程是一种编写单条指令的技巧，用于获得特定的、通常是一次性的响应。

归根结底，提示工程是上下文工程的一个子集。上下文工程负责决定 LLM 的上下文窗口中填充什么内容，而提示工程则关注如何在这个经过整理的上下文窗口中设计具体的指令。

方面	提示工程	上下文工程
主要目标	获取特定的、通常是一次性的响应	确保系统在不同任务和会话中都能保持一致、可靠的性能
范围	单次交互或即时的指令文本	整个信息环境，包括记忆、工具和数据源
类比	提出一个措辞恰当的问题	建立图书馆，并为专家提供使用这些资源的工具
核心活动	文字润色、指令设计	系统设计、数据编排、记忆管理

上下文工程的构建模块有哪些？

指令 / 系统提示

系统提示建立了 agent 的基础上下文：包括它的身份、能力、约束条件和行为准则。与每次交互都会发生变化的用户提示不同，系统提示相对稳定，可以充当持久的 "个性" 和规则手册。有效的系统提示需要在三个相互竞争的要求之间取得平衡：明确性（足够清晰，以避免产生模糊行为）、灵活性（足够通用，以应对多样化场景）以及简洁性（足够简短，以保留上下文窗口空间）。最佳实践包括：

• 明确定义 agent 的角色（"你是一名金融分析师助手......"）

• 提供具体的期望行为示例，而不是抽象的规则

• 使用结构化分隔符（XML 标签、Markdown 章节）来组织指令，以便模型更好地理解

• 将关键约束条件（安全规则、输出格式要求）放置在显眼的位置，因为模型存在位置偏差

高级技术包括根据运行时上下文激活的条件指令（例如，"如果用户询问个人信息，则引导其查看隐私政策"）以及指导 agent 推理过程的元指令（例如，"在提供分析之前进行逐步思考"）。系统提示尤其容易受到上下文窗口竞争的影响；随着对话历史、工具输出和检索数据不断累积，设计不佳的系统提示可能会被挤出模型有效的注意力范围，从而导致行为漂移，使 agent 逐渐"忘记"其核心指令。

长期 记忆

长期记忆使 AI 能够跨多个会话或对话保留信息。与短期记忆不同，短期记忆是临时的，会在会话结束时丢失，而长期记忆能够让 AI 回忆用户偏好、过去的交互以及已学习的事实，以便在未来进行参考。

状态 / 历史记录（短期记忆）

状态和历史记录构成了 agent 在当前会话中的工作记忆：记录正在进行的交互中已经说过、做过和了解到的内容。这种短期记忆能够实现对话的连续性；agent 可以引用之前的交流，而不需要用户反复提供上下文。然而，对话历史会随着交互长度线性增长，很快消耗上下文窗口。

有效的上下文工程需要主动采用记忆管理策略。摘要 会将较早的交流压缩成简洁的表示，同时保留关键事实和决策。窗口化 只保留最近的 N 条消息，在假设最近的上下文最重要的情况下，丢弃更早的历史记录。选择性保留则通过启发式方法识别并保留关键信息（用户偏好、已确定的事实、未解决的问题），同时删除常规的对话填充内容。

更复杂的方法会使用情节记忆结构，让 agent 将重要状态写入外部存储，并在需要时进行检索。这模拟了人类的记忆方式：人类不会将完整的对话一直保存在主动工作记忆中，但可以在需要时回忆特定细节。挑战在于保持连贯性；过度激进的裁剪会导致 agent "忘记"关键上下文并重复犯错，而压缩不足则会导致上下文溢出和性能下降。

检索信息（ RAG ）

检索增强生成（RAG）是指 AI 从知识库中"即时"检索外部数据，例如公司内部文档或公共网站。RAG 使 AI 能够使用其最初训练时未接触过的信息来回答问题，从而确保其响应既及时又准确。

语义分块

语义分块通过以逻辑方式组织信息来改善检索。语义分块不是将文本拆分成任意的固定大小片段，而是将相关概念组织在一起（例如，按照段落、函数或逻辑章节进行分组）。当检索到相关文本块时，其紧邻的上下文也会一并包含。这能够为 LLM 提供更加连贯、完整的上下文，帮助其更有效地进行推理，并减少信息碎片化带来的问题。

混合搜索

混合搜索对于上下文工程至关重要，因为依赖单一的检索方法往往会失败。向量搜索擅长查找概念上相似的信息（例如，"夏季服装"可以找到"适合温暖天气的穿搭"），但可能会遗漏具体、精确的术语。关键词搜索（例如 BM25）擅长查找精确匹配（例如"SKU-123AB"），但无法很好地处理同义词。通过在一个统一的查询中结合两者，混合搜索能够确保 LLM 获得尽可能准确、平衡的上下文，同时捕获用户的概念意图以及任何关键的关键词。

重排序

重排序解决了大规模检索中固有的"速度与准确性"权衡问题。初始搜索（例如混合搜索）经过优化，可以快速检索大量潜在相关的文档（例如排名前 100 的文档）。随后使用重排序模型 ------ 这种模型通常计算成本更高，但准确性也高得多 ------ 仅对这个较小的文档子集重新评分。对于上下文工程而言，这一点至关重要，因为它能够确保最优质、最相关的文本片段位于上下文窗口的最顶部，这对于缓解 "中间遗失" 问题，以及让 LLM 将注意力集中在最高质量的信息上非常重要。

可用工具

工具通过与外部系统进行交互来扩展 agent 超越文本生成的能力，例如执行代码、查询数据库、调用 API 或操作文件。从上下文工程的角度来看，工具带来了一个独特的挑战：每个工具都需要一段描述（名称、用途、参数、使用示例），而这些内容都会占用上下文窗口空间。随着工具库不断增长，这种 "工具上下文开销" 会变得非常显著。一个拥有 100 个工具的 agent，可能会在用户真正开始任务之前，仅仅用于描述可用能力就消耗上下文窗口的 30%--40%。

有效的工具工程遵循以下几个原则：

• **保持工具描述简洁但明确：**包括工具的用途、带类型的必需参数，以及一个标准示例。

• **设计可组合的工具：**更小、更专注的工具（例如 "search_documents" "summarize_text"）比试图处理多种场景的单体工具更容易灵活组合。

• **使用工具类别或命名空间，以支持选择性加载：**正在进行金融分析的 agent 不需要图像处理工具。

• **使用工具结果过滤：**只向 agent 返回必要的信息，而不是原始 API 响应。数据库查询工具应该返回"找到 3 笔相关交易，总计 4,532 美元"，而不是完整的 SQL 结果集。

设计良好的工具还应该在描述中包含错误处理方式，教会 agent 如何优雅地从失败中恢复，而不是让错误在整个工作流中级联。

Agent 式搜索

Agent 式搜索是一种专门的"子 agent"工具，能够在其自身隔离的上下文中执行复杂的多步骤探索。例如，它可以将自然语言请求转换为精确的 ESQL 查询，找到数据，然后只向主 agent 返回简洁的摘要，从而保持主 agent 的工作记忆整洁。

特定领域的工作流

特定领域的工作流是为高风险、可预测的业务流程设计的预定义、确定性工具链，在这些场景中，可靠性和一致性比探索性灵活性更加重要。与动态推理每一步的通用 agent 不同，这些工作流遵循严格、经过验证的流程。例如："验证客户身份 → 检查信用记录 → 外部监管筛查 → 计算风险评分 → 生成合规报告。"每个步骤都有明确的成功标准、错误处理和回滚流程。

这种刚性设计是有意为之的；它可以防止基于 LLM 的推理所固有的不可预测性影响金融审批、医疗诊断或监管合规等关键任务。从上下文工程的角度来看，特定领域的工作流通过减少自由度来简化 agent 的任务。agent 不需要了解所有可能的工具和策略，只需要获取当前工作流步骤所需的具体信息。这种聚焦的上下文能够同时提高准确性和效率。

实现通常涉及状态机或有向无环图（DAG），其中 LLM 负责处理可变元素（解析用户输入、选择数据源、生成自然语言摘要），而确定性逻辑则控制整个流程。其权衡是适应性降低；这些工作流非常擅长处理已知场景，但当边界情况超出预定义路径时就会遇到困难。

动态工具发现

动态工具发现解决了 agent 访问大型工具库时出现的 "提示膨胀" 问题。与其在系统提示中列出数百个工具描述 ------ 这会消耗宝贵的上下文窗口空间，并降低工具选择的准确性 ------ 这种策略会在运行时对工具元数据执行语义搜索，只检索相关的能力。

当 agent 接收到一项任务时，它会使用任务描述作为输入查询工具注册表，为特定上下文检索语义上最相似的 3--5 个工具。这种方式类似于即时数据检索：工具在需要之前一直保存在外部存储中，而 agent 的注意力始终集中在适用的能力上，而不是被分散到一个完整的工具目录中。MCP（ 模型上下文协议 ）等协议通过提供可以动态发现、理解和调用工具的注册表，对这种模式进行了标准化。不过，动态发现也会引入延迟（搜索操作本身），并且需要经过仔细的工程设计，以防止 agent 选择次优工具，或者由于工具描述含义模糊而陷入无效路径。

用户提示

用户提示是触发 agent 行为的直接输入，并定义即时的任务上下文。与相对稳定的系统提示不同，用户提示会随着每次交互而变化，并且在大多数 LLM 架构中具有最高的注意力权重。这种位置偏差意味着，当上下文中的其他信息存在冲突时，用户提示往往会覆盖这些信息。

有效的上下文工程将用户提示视为不仅仅是简单的问题；它们还可以包含明确的上下文提示（时间戳、用户偏好、会话状态），在不让系统提示变得臃肿的情况下，引导检索和工具选择。对于有状态的 agent，用户提示会成为注入特定会话信息的入口 ------ 例如，"基于我们之前关于季度指标的讨论......" 会向 agent 表明应该优先使用最近检索到的财务数据。然而，用户提示也是上下文中最不可预测的元素，可能存在歧义、相互矛盾或对抗性内容。上下文工程必须通过查询理解模型、用于检测提示注入攻击的安全过滤器，以及当无法仅从输入中可靠推断用户意图时的回退策略，来应对这种可变性。

结构化输出

结构化输出是指 AI 需要按照特定方式进行格式化的信息，例如 JSON、XML 或表格。通过定义结构化输出，可以让 AI 的响应保持一致，并能够轻松地被其他程序或系统使用。

如果想更深入地了解这些概念，请阅读完整的博客文章：上下文工程概述。

上下文工程流水线

上下文工程的实践最好理解为一个为 LLM 提供支持的系统化流水线设计。它不是简单地临时组合各种组件，而是针对特定任务进行定制，并旨在管理整个循环中每个阶段与模型之间的信息流。这个流水线通常可以分为三个核心阶段：

1. **上下文检索与生成：**这一阶段涉及主动从各种潜在输入中获取原始数据，例如从向量数据库中检索文档、查询结构化 SQL 数据库，或调用外部服务的 API。

2. **上下文处理：**信息收集完成后，需要对原始信息进行优化。这包括使用分块、摘要、压缩和结构化等技术转换数据，以最大限度地提高信噪比。

3. **上下文管理：**最后这个阶段负责管理信息在多次交互中的存储、更新和使用方式。这对于构建有状态的应用至关重要，并涉及短期（会话）和长期（持久）记忆的相关策略。

上下文工程是如何工作的？

所有上下文工程流水线都包含一系列动态管理模型"看到什么"的策略。这种实践将上下文窗口视为一种有限资源，需要通过选择、过滤和排序数据来主动进行优化，而不是被动地填充未经处理、未经过滤的原始信息。这些策略可以分为四个主要类别。

选择：检索正确的信息

最强大的策略是将信息保存在上下文窗口之外，并在 agent 需要时 "即时" 检索。这类似于人类的工作方式：我们不会记住整个图书馆的内容，而是使用搜索引擎和文件归档系统，按需找到所需要的信息。

对于 AI agent 来说，这意味着查询外部知识库。然而，找到正确的信息是一项重大挑战。随着数据量不断增长，简单的语义搜索可能变得不可靠。有效的选择通常需要采用混合方法，结合关键词、语义和基于图的检索等多种搜索技术，从庞大而复杂的数据集中精准定位所需的上下文。

写入：创建外部记忆

这种策略为 agent 提供一个可以将信息卸载到外部记忆中的位置，例如 "草稿" 文件或专用数据库。例如，agent 可以将多步骤计划保存到文件中，并在之后参考该文件，从而避免计划因为上下文窗口过于拥挤而被挤出。这使 agent 能够在不占用工作记忆过多空间的情况下保持状态，并跟踪长期运行任务的进度。

压缩：提高上下文效率

压缩技术可以减少上下文窗口中的 token 数量，同时保留关键信息。

• **摘要：**使用 LLM 将冗长的对话或文档提炼成简洁的摘要。例如，可以用一段简短的结果摘要替代工具完整且消耗大量 token 的输出。

• **裁剪：**使用硬编码规则过滤上下文，例如删除对话中最早的消息，或清除不再需要的重复工具输出。

隔离：分离关注点

对于高度复杂的任务，单个 agent 可能会不堪重负。隔离是指将问题拆分，并将子任务分配给专门的 "子 agent"，每个子 agent 都拥有独立、干净且专注的上下文窗口。主 agent 负责协调这个团队，只接收每个专家提炼后的最终输出。这种方式能够让每个 agent 的上下文保持相关且可控，从而提高复杂研究或分析任务的整体性能。

通过遵循这些原则，上下文工程旨在为 LLM 提供尽可能少的高信号 token，以最大限度地提高成功获得预期结果的可能性：相关的输出。

核心技术挑战：上下文窗口

理解上下文窗口

从根本上来说，上下文工程受到一个基本约束的影响：LLM 的注意力预算是有限的。上下文窗口以 token 为单位进行衡量，它定义了模型一次能够处理的最大信息量。虽然现代模型支持越来越大的上下文窗口（100,000、100 万，甚至 200 万个 token），但简单地填满这个空间并不能保证获得更好的性能。

LLM 基于Transformer 架构运行，其中每个 token 都必须关注其他所有 token。随着上下文不断增长，这会带来计算开销，以及实践者所说的"上下文腐化"：随着信息负载增加，模型保持注意力并回忆特定细节的能力会下降。这种现象类似于人类的认知局限；更多的信息并不总是意味着更好的决策。

单纯扩大上下文窗口会带来一系列重大挑战：

• **成本和延迟增加：**Transformer 架构的注意力机制的计算复杂度会随着序列长度呈二次方（ $O(n2)O(n^2)$ O(n2)）增长，使更大的上下文变得成本更高、速度更慢。

• 性能下降（"中间遗失"）：LLM 对上下文窗口最开始或最后的信息表现出较强的记忆能力，但对于位于中间的信息，性能会出现明显下降。

• **噪声和干扰：**更大的上下文窗口增加了包含无关 "噪声" 信息的可能性，这些信息会分散模型的注意力，并降低输出质量。这通常被称为 "大海捞针" 问题。

这一悖论进一步说明，我们需要的是智能的信息整理，而不仅仅是蛮力扩展，这也使上下文工程成为一门需要精细打磨的技术。

为什么上下文工程对 AI agent 和应用至关重要

任何 AI agent 面临的首要挑战都是正确完成任务。性能、成本和延迟之间的权衡属于次要优化，只有在解决准确性这一核心问题之后才能进行。上下文工程按照以下优先级依次解决这些需求：

准确性和可靠性

上下文工程的主要目标是确保 agent 能够成功且可靠地完成任务。如果没有准确、相关的上下文以及正确的工具，agent 就会因为产生幻觉、选择错误的工具，或者无法执行多步骤计划而失败。这是上下文工程所解决的基础问题。

输出质量

在经过上下文工程的系统中，输出质量是指 agent 的响应与用户意图、事实准确性和任务要求的契合程度，而不仅仅是语言流畅性或连贯性 ------ LLM 天然就能做到后两点。高质量的输出关键取决于高质量的输入上下文；"垃圾进，垃圾出"原则在这里同样适用。

上下文工程通过以下几种机制改善输出质量：

• 检索质量确保 agent 获取准确、相关的源材料，而不是产生幻觉或依赖过时的训练数据。

• 上下文结构会影响模型提取和综合信息的效率。

• 经过良好分块且语义连贯的上下文能够产生比碎片化文本片段更加准确的推理结果。

• **信噪比很重要：**包含 5 个高度相关的文档，其效果优于在这 5 个文档之外再加入 20 个关联度一般的文档，因为无关信息会分散模型的注意力。

输出质量还取决于系统提示中的指令清晰度，以及明确的格式要求（JSON 等结构化输出可以减少解析错误）。质量评估需要针对具体任务进行：对于 RAG 系统，可以评估事实准确性；对于 agent，可以评估任务完成率；对于对话系统，可以评估用户满意度。上下文工程通过让输入与输出之间的关系变得可观测且可调优，实现系统化的质量改进；你可以衡量哪些上下文组合能够产生更好的输出，并据此优化检索、排序和过滤。

性能、成本和延迟之间的权衡

上下文窗口中的每个 token 都会产生成本：计算资源、API 费用和延迟。上下文工程会直接影响这三个方面：

• **成本优化：**减少提示中的不必要 token，对于高并发应用来说，可以将 API 成本降低数个数量级。

• **降低延迟：**更小、更聚焦的上下文意味着更快的推理速度和响应更迅速的应用。

• **提高质量：**有针对性的高信号上下文，其效果始终优于大量且缺乏重点的信息倾倒。

可靠性和错误恢复

生产环境中的 AI 系统必须具备韧性。糟糕的上下文工程会导致多种失败模式：

• **上下文污染：**当幻觉或错误信息被写入上下文，并在后续交互中不断累积和放大时，就会产生上下文污染。

• **目标漂移：**当不断积累的无关信息导致 agent 逐渐偏离最初的目标时，就会发生目标漂移。

• **容量溢出：**当上下文窗口被低优先级数据填满，导致关键的信息被截断时，就会发生容量溢出。

良好的上下文工程通过验证、裁剪和结构化的记忆管理来避免这些问题。它将上下文视为一种需要仔细整理的资源，而不是被动积累的信息。

开始使用 Elasticsearch 进行上下文工程

Elasticsearch 是实现上下文工程的理想平台，因为它将许多所需组件统一到一个完整、协调的系统中。它既是向量数据库、搜索引擎、NoSQL 文档存储，也是更多能力的集合，全部集于一体。这让你可以将所有数据存储在一个地方，并使用业内最强大的查询语言，为任何类型的问题提供最相关的上下文。

Elastic Agent Builder 目前已作为技术预览版本提供。开始使用 Elasticsearch 实现上下文工程：

• 使用 Elastic 进行上下文工程

• 开始免费试用 Elasticsearch Cloud

• 阅读 Agent Builder 文档

• **探索 Jupyter notebook：**在 GitHub 上查看 你的第一个 Elastic Agent

• 观看点播研讨会： Elastic AI agent 和 MCP

• 在本地试用 Agent Builder

• LangChain 的上下文工程中间件

• LlamaIndex RAG 框架

原文：What is Context Engineering? Architecting Reliable AI | Elastic