什么是上下文工程？

系统提示确定了代理的基础上下文：其身份、能力、限制和行为准则。与每次交互都会改变的用户提示不同，系统提示保持相对稳定，并充当持久的”个性“和规则手册。有效的系统提示语需权衡三种相互冲突的需求：具体性（足够清晰以避免行为模糊）、灵活性（足够通用以应对多样场景）以及简洁性（足够简短以节省上下文窗口空间）。最佳实践包括：

• 明确界定代理的角色（“你是一名金融分析助理……”）
• 提供所需行为的具体示例，而不是抽象的规则
• 用结构化的分隔符（像 XML 标签、Markdown 的章节标识）来整理指令，这样能让模型更好地理解
• 由于模型存在位置偏好，因此应将关键约束条件（安全规则、输出格式要求）置于显著位置。

高级技术包括基于运行时上下文激活的条件指令（例如，“如果用户询问个人信息，重定向到隐私政策”），以及指导代理推理过程的元指令（例如，“在提供分析之前逐步思考”）。系统提示尤其容易受到上下文窗口冲突的影响；随着对话历史记录、工具输出和检索到的数据的积累，设计不佳的系统提示会被排除在模型的有效注意力范围之外，从而导致行为偏离，即代理逐渐”忘记“其核心指令。

长期记忆能让 AI 在多个会话或对话中保留信息。短期记忆是短暂的，在会话结束后就会丢失，而长期记忆则不同，它能让人工智能回忆起用户的偏好、过去的互动和学到的知识，供未来参考。

状态和历史构成了代理在当前会话中的工作记忆：记录了在持续互动中说过的话、做过的事和学到的东西。这种短期记忆使对话具有连续性；代理可以参考以前的交流，而无需用户重复上下文。然而，对话历史会随着互动时长线性增长，迅速占用上下文窗口。

有效的上下文工程需要主动的内存管理策略。摘要将以前的交流压缩成简明的表述，同时保留关键事实和决定。窗口机制只保留最近的 N 条消息，丢弃更早的历史记录，因为最近的上下文最为重要。选择性保留应用启发式方法来识别和保留关键信息（用户偏好、既定事实、开放性问题），同时删除日常会话中的填充信息。

更精密的方法是使用情景记忆结构，在这种结构中，智能体将重要状态写入外部存储，并在需要时进行检索，模拟了人类并非将整个对话都保存在活跃的工作记忆中，而是能在需要时回忆起特定细节的情况。面临的挑战在于保持连贯性；过度激进的修剪操作会导致代理“遗忘”关键上下文信息，并重复犯错，而压缩不足则会引发上下文溢出，进而导致性能下降。

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

语义分块通过对信息进行逻辑结构化来提升检索能力。与将文本拆分成任意、固定大小的片段不同，语义分块是将相关概念组合在一起（例如，按段落、功能或逻辑部分进行划分）。当检索到相关的数据块时，其周围的数据块也会包括在内。这为 LLM 提供了更连贯完整的上下文，帮助其更有效推理，并缓解信息碎片化带来的问题。

混合搜索对于上下文工程至关重要，因为依赖单一检索方法往往无法搜索到所需的信息。向量搜索擅长查找概念上相似的信息（例如，“夏季服装”会找到“温暖天气的服装”），但它可能会遗漏特定的精确术语。关键字搜索（如 BM25）擅长查找精确匹配项（例如“SKU-123AB”），但在查找同义词时则不尽如人意。通过将两者结合在一个统一的查询中，混合搜索确保 LLM 获得最准确、最均衡的上下文，从而发现用户的概念意图和任何关键关键字。

重排序解决了大规模检索中固有的”速度与准确性之间的“权衡问题。初始搜索（如混合搜索）经过优化，可以快速检索大量可能相关的文档（例如，前 100 个）。然后使用重排序模型（通常计算成本更高但更准确）只对这个较小的子集进行重新评分。在上下文工程里，这非常关键。它能保证把最优质、最相关的片段放在上下文窗口的最前面。这对解决“中间信息被遗漏”的问题很有效，还能让 LLM 把注意力集中在质量最高的信息上。

通过支持与外部系统的交互，工具将代理的功能扩展到文本生成以外，例如执行代码、查询数据库、调用 API 或对文件执行操作。从上下文工程的角度来看，工具带来了一个独特的挑战，即每个工具都需要描述（名称、目的、参数、使用示例），这就占用了上下文窗口的空间。随着工具库的增长，这种“工具上下文开销”变得很大。在用户的实际任务开始之前，一个拥有 100 种工具的代理可能会在其上下文窗口中花费 30%–40% 来描述可用的功能。

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

• 保持工具描述简洁明了：包括工具的目的、所需参数和类型，以及一个典型示例。
• 设计可组合的工具：规模较小、重点突出的工具（如”search_documents“、”summarize_text“）比试图处理多种情况的单一工具组合起来更灵活。
• 实施工具分类或命名空间，以实现选择性加载：从事金融分析的代理不需要图像处理工具。
• 使用工具结果筛选：仅向代理返回必要信息，而不是原始 API 响应。数据库查询工具应该返回“找到 3 笔相关交易，总计 4,532 美元”，而不是完整的 SQL 结果集。

设计精良的工具还会在说明中包含错误处理，教代理如何顺利地从故障中恢复，而不是在工作流中一连串地出错。

智能体搜索

智能体搜索是一种专门的“子智能体”工具，它在自身独立的上下文中执行复杂的多步骤探索。例如，它可以将自然语言请求转换为精确的 ESQL 查询，查找数据，并仅向主代理返回简明摘要，保持其工作内存的干净。

特定领域工作流

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

这种刚性是有意为之；它可以防止基于 LLM 的推理中固有的不可预测性影响关键任务的运行，如财务审批、医疗诊断或监管合规。从上下文工程的角度来看，领域工作流通过减少自由度来简化代理的任务。代理不需要所有可能的工具和策略，只需要当前工作流步骤所需的特定信息。这种有针对性的上下文提高了准确性和效率。

实施过程通常涉及状态机或有向无环图（DAG），其中 LLM 处理变量元素（解析用户输入、选择数据源、生成自然语言摘要），而确定性逻辑控制整个流程。这样做的代价是降低了适应性；这些工作流程在已知场景中表现出色，但在边缘情况超出预定义路径时则难以应对。

动态工具发现

动态工具发现解决了当代理访问大型工具库时出现的“提示膨胀”问题。这种策略不是在系统提示中列出数以百计的工具说明（会占用宝贵的上下文窗口空间并降低工具选择的准确性），而是利用对工具元数据的语义搜索，在运行时只检索相关功能。

当代理接收任务时，它使用任务描述作为输入查询工具注册表，检索出与该特定上下文语义相似度最高的3-5个工具。这种方法反映了即时的数据检索：工具在需要之前会保留在外部存储中，并且代理人的注意力始终集中在适用的功能上，而不是在详尽的目录中稀释。协议如 MCP（模型上下文协议）通过提供注册表来标准化这种模式，使工具可以被动态发现、理解和调用。然而，动态发现引入了延迟（搜索操作本身）并需要精心设计以防止代理选择次优工具或在工具描述模糊时追逐死胡同。

用户提示是触发代理行为的直接输入，并定义了即时任务上下文。与系统提示（相对静态）不同，用户提示会随着每次交互而变化，并且在大多数 LLM 架构中具有最高的关注权重。这种重要性偏差意味着用户提示往往会优先于上下文中其他地方的冲突信息。

有效的上下文工程将用户提示视为不仅仅是简单的问题；它们可以包含明确的上下文提示（时间戳、用户偏好、会话状态），在不增加系统提示的情况下指导检索和工具选择。对于有状态代理来说，用户提示成为注入会话特定信息的入口点。例如，“鉴于我们关于季度指标的对话……”这样的提示会向代理发出信号，使其优先处理最近获取的财务数据。不过，用户提示也是上下文里最不好预测的部分，它可能会模棱两可、自相矛盾，甚至还带有对抗性。上下文工程必须借助查询理解模型来应对这种可变性，这些模型能重新表述不清晰的请求；还需借助安全筛选器来检测提示注入攻击；并且在仅从输入无法可靠推断用户意图时，要采用备用策略。

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

要更深入地探索这些概念，请阅读完整的博客文章：上下文工程概述。

要理解上下文工程，最好把它看成是为支持 LLM 而搭建系统化流程管道的设计。该管道并非只是临时拼凑各种组件，而是针对特定任务量身定制，旨在于循环的每个阶段管理模型输入和输出的整个信息流。它通常分为三个核心阶段：

1. 上下文检索和生成：此阶段涉及主动从各种潜在输入中获取原始数据，例如从向量数据库检索文档、查询结构化 SQL 数据库或对外部服务进行 API 调用。
2. 上下文处理：收集完毕后，原始信息会被优化。这涉及使用分块、汇总、压缩和结构化等技术来转换数据，以最大化其信噪比。
3. 上下文管理：最后这个阶段规范信息在多次交互中如何存储、更新和利用。它对构建有状态应用程序至关重要，涉及短期（会话）和长期（持久）内存的策略。

最有效的策略是将信息保留在上下文窗口之外，并在代理需要时”及时检索“。这反映了人类的工作方式，即不会背诵整个图书馆，而是利用搜索引擎和文件系统按需查找所需资料。

对于智能体来说，这意味着要查询外部知识库。然而，找到合适的信息却并非易事。随着数据的增多，简单的语义搜索可能变得不可靠。有效的选择通常需要混合方法，将多种搜索技术（例如关键字、语义和基于图表的检索）相结合，以便从庞大而复杂的数据集中精确定位所需的确切上下文。

这种策略通过向外部存储器（如”scratchpad“文件或专用数据库）写入信息，为智能体提供了卸载信息的地方。例如，智能体可以将其多步骤计划保存到文件中，然后再引用，这样就可以防止计划被挤出上下文窗口。这样，智能体就能保持状态并跟踪长期运行任务的进度，而不会使其工作记忆变得杂乱无章。

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

• 摘要： 使用 LLM 将冗长的对话或文件提炼为简明摘要。例如，可以将工具的完整、包含大量标记的输出替换为其结果的简短摘要。
• 修剪：使用硬编码规则过滤上下文，例如删除对话中最旧的消息或清除不再需要的冗余工具输出。

对于高度复杂的任务，单个智能体可能会力不从心。隔离涉及将问题分解，并将子任务分配给专门的”子智能体“，每个子智能体都有自己的简洁、重点突出的上下文窗口。主要智能体负责协调这个团队，只接收每个”专员“提炼后的最终输出。这种方法能使每个智能体的上下文保持相关性和可管理性，从而提高复杂研究或分析任务的整体表现。

通过遵循这些原则，上下文工程旨在为 LLM 提供尽可能小的高信号词元集，从而最大限度地提高成功结果（相关输出）的机会。

从根本上说，上下文工程受到一个基本制约因素的影响，那就是 LLM 的注意力预算有限。上下文窗口（以词元计量）决定了模型一次可处理的最大信息量。虽然现代模型支持越来越大的上下文窗口（100,000、100 万，甚至 200 万个词元），但仅仅填充这个空间并不能保证表现会更好。

LLM 基于变换器架构运行，其中每个词元都必须关注其他所有词元。随着上下文的增加，这会产生计算开销，也就是从业者所说的”上下文腐烂“，即随着信息负荷的增加，模型保持注意力和回忆具体细节的能力也会下降。这一现象反映了人类认知的极限，更多信息并不总意味着更好的决策。

仅仅扩大窗口就会带来巨大挑战：

• 成本和延迟增加：变换器架构注意力机制的计算复杂度随序列长度呈二次方增长（$O(n^2)$），使得更大的上下文成本和速度呈指数级增长。
• 性能下降（“中间信息被遗漏”）：LLM 对长上下文窗口开头或结尾处的信息显示出很强的回忆能力，但对位于中间的信息则表现出明显的性能下降。
• 噪音与干扰：更大的上下文窗口会增加包含无关“噪声”信息的可能性，这会分散模型的注意力并降低输出质量。人们常常称之为“大海捞针”问题。

这种悖论强调了对智能化策划的需求，而不仅仅是蛮力，使得上下文工程在某种程度上成为一门精细的技艺。

上下文工程的主要驱动力是确保智能体能够成功且可靠地完成其任务。如果没有准确、相关的上下文和正确的工具，智能体可能会因为出现幻觉、选择错误的工具或无法执行多步骤计划而无法正常运行。这就是上下文工程要解决的根本问题。

上下文工程系统中的输出质量指的是智能体响应与用户意图、事实准确性和任务要求的高度契合，而不仅仅是单纯的流畅性或一致性，而这些是 LLM 自然可以实现的。高质量的输出在很大程度上取决于高质量的输入上下文，这直接体现了“垃圾进，垃圾出”的原则。

上下文工程通过几种机制提高输出质量：

• 检索质量确保智能体访问的是准确且相关的源材料，而不是产生幻觉或依赖过时的训练数据。
• 上下文结构影响模型提取和合成信息的有效性。
• 分块良好、语义连贯的上下文比零散的片段能产生更准确的推理。
• 信噪比很重要：包含五个高度相关的文档比包含这五个加上二十个不甚相关的文档更有效，因为无关信息会分散模型的注意力。

输出质量还取决于系统提示中的指令清晰度和明确的格式要求（JSON 等结构化输出可减少解析错误）。衡量质量需要针对特定任务进行评估：RAG 系统的事实准确性、智能体的任务完成率、对话系统的用户满意度评分。上下文工程通过使输入-输出关系可观察和可调节，实现系统性质量改进；您可以测量哪些上下文组合产生更好的输出，并相应地优化检索、排序和筛选机制。

上下文窗口中的每个词元都会产生费用：计算资源、API 费用和延迟。上下文工程对这三者都有直接影响：

• 成本优化：减少提示中不必要的词元可以大幅降低高流量应用程序的 API 成本。
• 降低延迟：更小、更集中的上下文意味着更快的推理速度和更灵敏的应用程序响应。
• 质量提升：有针对性的高信号上下文始终优于大量、无重点的信息转储。

生产型 AI 系统必须具备韧性。上下文工程不完善会导致多种失效模式：

• 上下文中毒：当幻觉或错误嵌入上下文，并在后续互动中累积时，就会发生上下文中毒。
• 目标偏离：当智能体因积累无关信息而偏离其原始目标时出现的情况
• 容量溢出：当上下文窗口充满低优先级数据时，关键信息被截断。

良好的上下文工程通过验证、修剪和结构化内存管理来避免这些问题。将上下文当作精心策划的资源，而不是被动的信息累积器。