Elastic：什么是上下文工程？

Elastic 中国社区官方博客

355人浏览 · 2026-06-05 09:57:20

Elastic 中国社区官方博客 · 2026-06-05 09:57:20 发布

什么是上下文工程（ context engineering ）？

上下文工程（ context engineering ）是向 AI 系统在正确的时间提供正确的信息的实践。可以把它想象成在为一位新同事准备简报：你不会把所有公司文件都堆在他桌上，而是会为他的具体任务精心挑选最相关的信息。

现代 AI agents 需要访问海量数据、文档、数据库、邮件、代码，但在一次处理中只能处理有限的信息量。上下文工程（ context engineering ）是一门智能选择、组织和传递 AI 完成良好决策所需信息的学科，同时避免用不必要的信息压垮它。做得好时，它的区别就在于：一个只给出泛泛回答的 AI，和一个能够基于你特定数据提供真正有帮助、准确答案的 AI。

为什么需要上下文工程（ context engineering ）？原始 LLMs 的局限性

LLMs 和推理模型（ RMs ）是现代应用中的强大组件，但它们存在一个根本性限制：LLM 的表现不仅仅取决于其内部的静态知识，还严重依赖在推理时刻提供的外部信息和工具。

默认情况下，LLMs 有四个主要约束：

静态知识：它们对世界的理解被冻结在最后一次训练时间之前，因此无法感知当前事件。
无法访问私有数据：它们没有原生能力访问你公司的实时专有数据：那些包含最有价值上下文的文档、指标和日志。
幻觉与缺乏对齐（ grounding ）：模型通过预测序列中下一个最可能的 token 来运行，这个过程优化的是语言连贯性，而不是事实验证，因此可能生成听起来合理但事实上错误信息。
上下文漂移与缺乏记忆：agents 在多步骤任务中表现不稳定，因为它们缺乏持久上下文或记忆。如果没有方式回忆先前决策，它们的推理会 “漂移”，导致信息不一致并在复杂工作流中失败。

这催生了上下文工程（ context engineering ），一种新兴实践，专注于构建可靠的、有状态的 AI agents。上下文工程（ context engineering ）将关注点从 prompt engineering（为单次交互设计提示）扩展到在 agents 执行多步骤复杂任务时管理完整上下文。上下文工程（ context engineering ）是管理模型有限注意力的艺术。这一实践包括设计围绕模型的信息架构：在任何时刻精心筛选其上下文窗口，并策略性决定来自用户消息、工具输出或其自身内部思考的信息，哪些进入 agents 有限的“工作记忆”。

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

关键区别：上下文工程（ context engineering ） vs 提示词工程（ prompt engineering ）

虽然这两个术语经常被混用，但它们实际上代表不同层级的抽象。提示词工程（ prompt engineering ）是一种战术性工作，即编写单条指令，以获得特定的、通常是一次性的回答。

从本质上讲，提示词工程（ prompt engineering ）是上下文工程（ context engineering ）的一个子集。上下文工程（ context engineering ）决定 LLM 的上下文窗口中填充什么内容，而提示词工程（ prompt engineering ）则关注在这个经过筛选的窗口内如何撰写具体的指令。

方面	提示词工程	上下文工程
主要目标	引出一个特定的、通常是一次性的回答	确保在不同任务和会话中实现一致、可靠的系统表现
范围	单次交互或即时指令文本	整个信息环境，包括记忆、工具和数据源
类比	提出一个措辞良好的问题	构建图书馆，并提供专家可使用的工具
核心活动	文字优化、指令编写	系统设计、数据编排、记忆管理

上下文工程（ context engineering ）的构建模块是什么？

指令 / 系统提示词（ system prompt ）

系统提示词（ system prompt ）建立了 agent 的基础上下文：它的身份、能力、约束以及行为规则。与每次交互都会变化的用户提示词不同，系统提示词相对稳定，并作为持续性的“人格”和规则手册。有效的系统提示词需要在三种相互竞争的需求之间取得平衡：具体性（足够清晰以避免模糊行为）、灵活性（足够通用以处理多样场景）以及简洁性（足够简短以保留上下文窗口空间）。最佳实践包括：

明确定义 agent 的角色（“你是一个金融分析助手 ...”）
提供具体的行为示例，而不是抽象规则
使用结构化分隔符（XML 标签、markdown 区块）来组织指令，以提升模型理解能力
将关键约束（安全规则、输出格式要求）放在显著位置，因为模型存在位置偏置

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

长期记忆（ long-term memory ）

长期记忆使 AI 能够跨多个会话或对话保留信息。与在会话结束时即丢失的短期记忆不同，长期记忆允许 AI 在未来引用用户偏好、历史交互以及已学习的事实。

状态 / 历史（短期记忆）（ state / history / short-term memory ）

状态与历史构成 agent 在当前会话中的工作记忆：即正在进行的交互中所说、所做以及所学内容的记录。这种短期记忆支持对话连续性；agent 可以引用之前的交流，而无需用户重复上下文。然而，对话历史会随着交互长度线性增长，很快占满上下文窗口。

有效的上下文工程需要主动的记忆管理策略。总结（Summarization）将旧的交互压缩为简洁表示，同时保留关键事实和决策。窗口化（ windowing ）只保留最近的 N 条消息，丢弃较早历史，基于 “最近信息最重要” 的假设。选择性保留（ selective retention ）通过启发式方法识别并保留关键信息（用户偏好、已确认事实、未解决问题），同时清理常规对话噪声。

更复杂的方法使用情节式记忆结构，让 agent 将重要状态写入外部存储并按需检索，模仿人类不会在工作记忆中保留完整对话，但可以在需要时回忆具体细节。挑战在于保持一致性；过度激进的清理会导致 agent “遗忘”关键上下文并重复错误，而压缩不足则会导致上下文溢出和性能下降。

检索信息（ RAG ）

检索增强生成（ RAG ）（ RAG ）指 AI 从知识库（如企业内部文档或公开网站）中 “即时” 检索外部数据。RAG 使 AI 能够回答它原本未训练过的信息，从而确保回答既是最新的又是准确的。

语义分块（ semantic chunking ）

语义分块（ semantic chunking ）通过结构化信息来提升检索效果。它不再将文本按固定大小随机切分，而是将相关概念组合在一起（例如按段落、函数或逻辑章节）。当检索到一个块时，也会包含其上下文邻域，从而为 LLM 提供更连贯、更完整的上下文，提高推理能力并减少信息碎片化问题。

混合检索（ hybrid search ）

混合检索（ hybrid search ）在上下文工程中至关重要，因为依赖单一检索方式通常效果不佳。向量检索擅长寻找语义相似内容（例如 “夏季服装” 匹配 “适合热天的服饰”），但可能遗漏精确术语。关键词检索（如 BM25 ）擅长精确匹配（例如“SKU-123AB”），但无法处理同义表达。通过将两者结合为统一查询，混合检索确保 LLM 获得最准确、最平衡的上下文，同时捕捉用户的概念意图与关键字信息。

重排序（ reranking ）

重排序（ reranking ）解决大规模检索中的 “速度 vs 准确性” 权衡。初始检索（如混合检索）通常优化为快速返回大量候选文档（例如前 100 个）。随后使用更精确但计算更昂贵的 reranking 模型对这些候选进行重新评分。对于上下文工程而言，这一步至关重要，因为它确保最相关的片段被放置在上下文窗口的最前面，从而缓解 “中间遗忘问题”（ lost in the middle ），并将 LLM 的注意力集中在最高质量的信息上。

可用工具（ available tools ）

工具通过让 agent 与外部系统交互来扩展其文本生成之外的能力：执行代码、查询数据库、调用 API 或操作文件。从上下文工程（ context engineering ）的角度来看，工具带来了一个独特挑战：每个工具都需要描述信息（名称、用途、参数、使用示例），这些都会占用上下文窗口空间。随着工具库的增长，这种 “工具上下文开销（ tool context overhead ）” 会变得非常显著。一个拥有 100 个工具的 agent 可能在用户实际任务开始之前，就已经用掉上下文窗口 30%–40% 来描述可用能力。

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

保持工具描述简洁但不含糊：包含工具用途、必需参数及类型，以及一个标准示例。
设计可组合的工具：更小、更专注的工具（例如 “search_documents”“summarize_text”）比试图覆盖多场景的单体工具更灵活。
通过工具分类或命名空间实现选择性加载：例如做金融分析的 agent 不需要图像处理工具。
使用工具结果过滤：只返回对 agent 有用的关键信息，而不是原始 API 响应。例如数据库查询工具应返回“找到 3 条相关交易，总计 $4,532”，而不是完整 SQL 结果集。

设计良好的工具还应在描述中包含错误处理机制，指导 agent 如何优雅地从失败中恢复，而不是让错误在工作流中级联扩散。

agentic search

agentic search 是一种专门的 “子 agent” 工具，用于在独立上下文中执行复杂的多步骤探索。例如，它可以将自然语言请求转换为精确的 ESQL 查询，查找数据，并仅向主 agent 返回简洁摘要，从而保持其工作记忆干净。

特定领域工作流（ domain-specific workflows ）

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

这种严格性是有意设计的；它防止了 LLM 推理本身的不确定性影响金融审批、医疗诊断或合规监管等关键任务。从上下文工程（ context engineering ）角度来看，这类工作流通过减少自由度来简化 agent 的任务。agent 不需要知道所有可能的工具和策略，只需要当前步骤所需的信息。这种聚焦的上下文提升了准确性和效率。

实现方式通常包括状态机或有向无环图（directed acyclic graphs - DAG ），其中 LLM 处理可变部分（解析用户输入、选择数据源、生成自然语言总结），而确定性逻辑控制整体流程。其权衡是灵活性降低；这些工作流在已知场景中表现出色，但在边缘情况超出预定义路径时表现较差。

动态工具发现（ dynamic tool discovery ）

动态工具发现（ dynamic tool discovery ）解决了 agent 拥有大量工具库时出现的 “提示词膨胀（ prompt bloat ）” 问题。与其在系统提示词中列出数百个工具描述（这会消耗宝贵的上下文窗口并降低工具选择准确性），这种策略在运行时通过对工具元数据进行语义搜索，只检索相关能力。

当 agent 收到任务时，它会使用任务描述作为输入查询工具注册表，检索语义最相似的 3–5 个工具。这种方式类似 “即时数据检索”：工具被保存在外部存储中，直到需要时才被调用，而 agent 的注意力始终集中在当前任务相关能力上，而不是被完整目录分散。

像 MCP（ Model Context Protocol ）这样的协议通过提供工具注册表来标准化这一模式，使工具能够被动态发现、理解和调用。然而，动态发现也引入了延迟（检索操作本身），并需要精细工程设计，以避免 agent 在工具描述模糊时选择次优工具或陷入错误路径。

用户提示词（ user prompt ）

用户提示词（ user prompt ）是直接触发 agent 行为并定义即时任务上下文的输入。与相对静态的系统提示词（ system prompt ）不同，用户提示词在每次交互中都会变化，并在大多数 LLM 架构中拥有最高的注意力权重。这种位置偏置（ positional bias ）意味着用户提示词通常会覆盖上下文中其他冲突信息。

有效的上下文工程（ context engineering ）会将用户提示词视为不仅仅是简单问题；它们可以包含显式上下文提示（时间戳、用户偏好、会话状态），在不膨胀系统提示词的情况下引导检索与工具选择。对于有状态 agent，用户提示词成为注入会话特定信息的入口 —— 例如，“基于我们关于季度指标的对话……” 会提示 agent 优先使用最近检索到的财务数据。然而，用户提示词也是上下文中最不可预测的部分，可能是模糊的、矛盾的甚至具有对抗性的。上下文工程（ context engineering ）必须通过查询理解模型（ query understanding models ）来应对这种不确定性，这些模型可以重写不清晰请求，通过安全过滤检测提示注入（ prompt injection ）攻击，并在无法可靠推断用户意图时启用回退策略。

结构化输出（ structured output ）

结构化输出（ structured output ）指 AI 需要以特定格式（如 JSON、XML 或表格）输出信息。通过定义结构化输出，AI 的响应可以保持一致性，并能够被其他程序或系统直接使用。

如需更深入了解这些概念，请阅读完整博客文章：上下文工程概述（ context engineering overview ）

上下文工程（ context engineering ）管道（ pipeline ）

上下文工程（ context engineering ）的实践最好被理解为一种为 LLM 构建的系统化管道设计。它不是简单地将各种组件临时拼接在一起，而是针对特定任务进行定制，用于在每一个循环阶段管理进出模型的完整信息流。这个管道通常分为三个核心阶段：

上下文检索与生成（ context retrieval and generation ）：这一阶段涉及主动从多种可能的输入源获取原始数据，例如从向量数据库中检索文档、查询结构化 SQL 数据库，或调用外部服务的 API。
上下文处理（ context processing ）：在收集到数据之后，对原始信息进行优化处理。其目标是最大化信噪比，常用方法包括分块（ chunking ）、总结（ summarization ）、压缩（ compression ）以及结构化（ structuring ）等。
上下文管理（ context management ）：这一最终阶段负责控制信息在多次交互中的存储、更新与使用。它是构建有状态应用的关键，涉及短期（会话级）记忆与长期（持久化）记忆的管理策略。

上下文工程（ context engineering ）是如何工作的？

所有上下文工程（ context engineering ）管道的共同点，是一组用于动态管理模型 “所看到内容” 的策略。这种实践将上下文窗口视为一种有限资源，必须通过选择、过滤和排序数据来主动优化，而不是被动地填充原始、未处理的信息。这些策略可以分为四个主要类别。

选择（ selection ）：检索正确的信息

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

对于 AI agent 来说，这意味着查询外部知识库。然而，找到正确的信息是一个重大挑战。随着数据规模增长，简单的语义搜索可能变得不可靠。有效的选择通常需要一种混合方法（ hybrid approach ），结合多种搜索技术，例如关键词检索、语义检索以及图结构检索，从而在庞大且复杂的数据集中精确定位所需上下文。

写入（ writing ）：创建外部记忆

这一策略让 agent 可以通过写入外部存储（如“草稿文件”或专用数据库）来卸载信息。例如，agent 可以将多步骤计划保存到文件中，并随时回读，从而避免该计划被挤出拥挤的上下文窗口。这使 agent 能够在不污染工作记忆的情况下维持状态并跟踪长任务进度。

压缩（ compression ）：让上下文更高效

压缩技术的目标是在保留关键信息的同时减少上下文窗口中的 token 数量。

总结（ summarization ）：使用 LLM 将长对话或文档压缩为简洁摘要。例如，将工具输出中大量 token 的完整结果替换为其简短总结。
裁剪（ trimming ）：通过硬编码规则过滤上下文，例如删除对话中最早的消息，或清除不再需要的冗余工具输出。

隔离（ isolation ）：分离关注点

对于高度复杂的任务，单个 agent 可能会不堪重负。隔离策略通过将问题拆分，并分配给多个专门的 “子 agent”，每个子 agent 拥有独立且干净、专注的上下文窗口。主 agent 负责协调这些子 agent，只接收每个专家的最终压缩输出。这种方法确保每个 agent 的上下文都保持相关且可管理，从而提升在复杂研究或分析任务中的整体表现。

通过遵循这些原则，上下文工程（ context engineering ）的目标是为 LLM 提供尽可能少但高信号的 token 集合，从而最大化成功输出（有用结果）的概率。

核心技术挑战：上下文窗口（ context window ）

理解上下文窗口（ context window ）

在其基础之上，上下文工程（ context engineering ）受到一个根本性约束的影响：LLMs 的注意力预算是有限的。上下文窗口（ context window，以 token 计）定义了模型一次能够处理的信息最大量。尽管现代模型支持越来越大的上下文窗口（100,000、1,000,000，甚至 2,000,000 tokens），但简单地填满这些空间并不意味着性能更好。

LLMs 基于Transformer 架构（ transformer architecture ）运行，其中每个 token 都需要与其他所有 token 进行注意力交互。随着上下文增长，这会带来计算开销，并产生实践者所说的“上下文腐化（ context rot ）”：随着信息负载增加，模型维持注意力和回忆特定细节的能力会下降。这种现象类似于人类的认知限制；信息越多，并不总意味着决策更好。

简单扩展上下文窗口会带来显著挑战：

成本与延迟增加：Transformer 架构中的注意力机制计算复杂度会随着序列长度呈二次增长（$O(n^2)$），这使得更大的上下文不仅更昂贵，而且更慢。
性能下降（“中间遗忘”问题， lost in the middle ）：LLMs 对于上下文窗口开头和结尾的信息表现出较强的记忆能力，但对于位于中间的信息，其性能会明显下降。
噪声与干扰：更大的上下文窗口更容易引入无关的“噪声”信息，这些信息可能干扰模型判断，从而降低输出质量。这通常被称为“草堆找针（ needle in a haystack ）”问题。

这种悖论进一步强化了对智能筛选的需求，而不是单纯依赖暴力扩展，使得上下文工程（ context engineering ）更像是一门精细的技艺。

为什么上下文工程（ context engineering ）对 AI agents 和应用很重要？

任何 AI agent 面临的首要挑战都是正确完成任务。性能-成本-延迟的权衡只是次级优化问题，必须在“准确性”这个核心问题解决之后才有意义。上下文工程（ context engineering ）正是按照这一优先级来解决问题的。

准确性与可靠性

上下文工程（ context engineering ）的主要驱动力，是确保 agent 能够成功且可靠地完成任务。如果缺乏准确、相关的上下文以及正确的工具，agent 就会通过幻觉、错误选择工具或无法执行多步骤计划而失败。这是上下文工程（ context engineering ）所要解决的基础问题。

输出质量

在上下文工程（ context engineering ）系统中，输出质量指的是 agent 的回答在多大程度上符合用户意图、事实准确性以及任务要求 —— 这不同于 LLM 自然具备的流畅性或连贯性。高质量输出高度依赖高质量输入上下文；“垃圾进，垃圾出”的原则在这里完全适用。

上下文工程（ context engineering ）通过多种机制提升输出质量：

检索质量（ retrieval quality ）确保 agent 获取的是准确且相关的原始材料，而不是产生幻觉或依赖过时训练数据。
上下文结构（ context structure ）影响模型提取和综合信息的效率。
良好分块且语义连贯的上下文比碎片化信息片段更能支持准确推理。
信噪比至关重要：只包含五个高度相关文档，通常比这五个文档外再加二十个弱相关文档表现更好，因为无关信息会干扰模型注意力。

输出质量还依赖于系统提示词中的指令清晰度以及明确的格式要求（例如结构化输出 JSON 可以减少解析错误）。质量评估必须依赖任务特定指标：RAG 系统中的事实准确性、agents 的任务完成率、对话系统中的用户满意度评分。上下文工程（ context engineering ）通过让输入-输出关系变得可观测和可调优，从而实现系统性质量提升；可以测量不同上下文组合带来的输出差异，并据此优化检索、排序和过滤策略。

性能-成本-延迟权衡

上下文窗口中的每一个 token 都有成本：计算资源、API 费用以及延迟。上下文工程（ context engineering ）直接影响这三者：

成本优化：减少提示词中不必要的 token，可以在高频应用中将 API 成本降低数个数量级。
延迟降低：更小、更聚焦的上下文意味着更快的推理时间和更高响应速度的应用。
质量提升：经过精心筛选的高信号上下文，通常明显优于大而无重点的信息堆叠。

可靠性与错误恢复（ reliability and error recovery ）

生产环境中的 AI 系统必须具备韧性。不良的上下文工程（ context engineering ）会导致多种失败模式：

上下文污染（ context poisoning ）：当幻觉或错误信息被写入上下文，并在后续交互中不断累积、放大
目标漂移（ goal drift ）：当不断累积的无关信息使 agent 逐渐偏离最初的目标
容量溢出（ capacity overflow ）：当上下文窗口被低优先级数据填满，导致关键信息被截断或挤出

良好的上下文工程（ context engineering ）通过验证、裁剪以及结构化记忆管理来防止这些问题。它将上下文视为需要精心管理的资源，而不是被动累积的信息容器。

在 Elasticsearch 上开始上下文工程（ context engineering ）

Elasticsearch 是实现上下文工程（ context engineering ）的理想平台，因为它将许多必要组件统一在一个一致的系统中。它同时是向量数据库、搜索引擎、NoSQL 文档存储等等，集于一体。这使得你可以将所有数据存储在同一个地方，并使用业界最强大的查询语言，为任何问题提供最相关的上下文。

Elastic Agent Builder 目前以技术预览版形式提供。你可以开始使用 Elasticsearch 实现上下文工程（ context engineering ）：