原文：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

AI智能体的高效上下文工程

Anthropic工程团队 出品
发布时间：2025年9月29日

上下文是AI智能体的核心资源，却具有有限性。在本文中，我们将探索一系列策略，用于高效筛选、管理为智能体提供算力支撑的上下文。

在应用人工智能领域，提示工程曾长期占据研究焦点，如今一个全新的概念逐渐成为主流：上下文工程。基于大语言模型的开发工作，重心正从为提示词寻找合适的措辞，转向解答一个更宏观的问题——什么样的上下文配置，最有可能让模型呈现出我们期望的行为？

上下文，指的是大语言模型（LLM）进行采样时所纳入的所有词元集合。当下的工程难题，是在大语言模型的固有约束下优化这些词元的效用，从而稳定实现预期结果。要高效驾驭大语言模型，就必须具备上下文思维——换言之，要时刻考量模型在任意时刻可获取的整体状态，以及该状态可能催生的各类行为。

本文将深入探讨这一新兴的上下文工程技术，并为构建可调控、高性能的AI智能体，提供一套更完善的思维模型。

上下文工程与提示工程的区别

在Anthropic，我们将上下文工程视为提示工程的自然演进阶段。提示工程是指为实现最优结果，撰写和组织大语言模型指令的一系列方法（相关概述与实用策略可参阅我们的官方文档）。而上下文工程，则是在大语言模型推理过程中，筛选并维持最优词元（信息）集合的策略体系，其中涵盖了提示词之外，所有可能进入模型上下文的信息。

在大语言模型工程化的早期阶段，提示词设计是AI工程工作的核心。彼时，除日常聊天交互外，绝大多数使用场景都需要针对单次分类或文本生成任务优化提示词。顾名思义，提示工程的核心关注点，是如何撰写高效的提示词，尤其是系统提示词。但随着我们开始构建能力更强、可完成多轮推理和长时任务的智能体，我们亟需一套能管理整体上下文状态的策略，这其中包括系统指令、工具、模型上下文协议（MCP）、外部数据、对话历史等各类信息。

智能体在循环运行过程中，会持续生成大量可能与下一轮推理相关的数据，这些信息需要被循环优化。而上下文工程，正是从这一不断演化的海量潜在信息中，筛选出可纳入有限上下文窗口的内容的一门艺术与科学。

校准系统提示词

系统提示词的设计容易陷入两个极端：过于具体或过于模糊，唯有找到中间的“理想状态”，才能让智能体的行为符合预期。

过于具体的示例

你是克劳德面包店的专属助手，必须回应“克劳德”这一称呼。对于用户的每一个请求，你必须严格遵循以下步骤：
1.【内容乱码，原文无有效信息】
2. 若用户意图为“问题解决”，需提出3个后续问题收集信息，随后必须调用解决工具；若用户意图为“常规咨询”，则无需追问，一次性给出答案。
3. 以下是应标记为“需要升级处理”的所有情况：

• 若用户意图为“问题解决”，但涉及门店现场的人身安全问题；
• 若用户想要新增订单，但其已有未完成订单【内容截断，原文无有效信息】。

过于模糊的示例

你是一名面包店助手，应尽力为顾客解决问题【内容截断，原文无有效信息】。

恰到好处的示例

你是克劳德面包店的客户支持助手，负责解答顾客关于面包店的各类问题。请运用可用工具，高效、专业地为顾客解决问题。

你可访问订单管理系统、产品目录及门店规章制度，核心目标是在可行的前提下快速解决问题；若尚未理解用户需求，可进行追问。

响应框架：

1. 定位核心问题——透过表面诉求，理解顾客的真实需求；
2. 补充必要上下文——借助工具获取关键信息；
3. 给出清晰解决方案——提供具体的后续操作步骤，确保顾客理解解决方案，且知晓后续如需帮助的操作方式。

指导原则：

• 若存在多种解决方案，选择最简便的一种；
• 若用户提及订单，先核查订单状态；
• 若涉及超出标准政策的财务调整，调用人工协助工具；
• 对用户的不满情绪或紧急需求做出回应。

与撰写提示词这一独立任务不同，上下文工程是一个迭代过程，每次向模型传递信息时，都需要进行一次内容筛选。

为何上下文工程对构建高性能智能体至关重要

尽管大语言模型处理数据的速度越来越快、容量也持续提升，但我们发现，和人类一样，模型在处理大量信息时，也会出现注意力分散或理解混乱的情况。针对“大海捞针”式基准测试的研究，揭示了上下文衰减的概念：随着上下文窗口中的词元数量增加，模型从上下文中准确提取信息的能力会随之下降。

不同模型的衰减程度存在差异，但这一特性适用于所有大语言模型。因此，上下文必须被视为一种边际收益递减的有限资源。和人类的工作记忆容量有限一样，大语言模型也拥有固定的注意力预算，并在解析海量上下文时不断消耗这一预算。每新增一个词元，都会在一定程度上消耗注意力预算，这也让精心筛选模型可获取的词元变得尤为重要。

这种注意力资源的稀缺性，源于大语言模型的架构约束。大语言模型基于Transformer架构构建，该架构支持单个词元与上下文窗口中的所有其他词元建立关联，这意味着n个词元会产生n²个两两关联关系。

随着上下文长度的增加，模型捕捉这些关联关系的能力会被不断稀释，这使得上下文规模与注意力聚焦度之间形成了天然的矛盾。此外，模型的注意力模式是从训练数据中习得的，而训练数据中短序列的占比远高于长序列，这导致模型对长上下文的依赖关系缺乏处理经验，也没有专门的参数应对这类场景。

位置编码插值等技术，能让模型通过适配原始训练的短上下文，实现对长序列的处理，但这会在一定程度上降低模型对词元位置的理解精度。上述因素共同造就了模型的性能梯度衰减：模型在长上下文场景下仍能保持较强的能力，但相较于短上下文，其信息检索和长距离推理的精度会有所下降。

这些现实情况意味着，精心的上下文工程设计，是构建高性能智能体的必要前提。

高效上下文的构成要素

鉴于大语言模型的注意力预算有限，优秀的上下文工程设计，核心是找到最小规模的高价值词元集合，以此最大化实现预期结果的可能性。这一原则说起来容易，落地却颇具挑战，下文将从上下文的不同组成部分出发，阐述这一原则的实际应用方法。

系统提示词的撰写应做到极致清晰，使用简洁、直白的语言，让表述的详细程度适配智能体的任务场景。这种“适配的详细程度”，是介于两种常见失效模式之间的理想状态：一种是工程师在提示词中硬编码复杂、脆弱的逻辑，试图让智能体呈现出完全固定的行为，这种方式会导致系统脆弱性提升，且长期维护的复杂度大幅增加；另一种则是工程师仅提供模糊、宏观的指导，既无法为模型提供实现预期输出的具体信号，还会错误地假定模型与人类拥有共同的上下文认知。

理想的系统提示词需实现平衡：足够具体，能有效引导智能体行为；同时足够灵活，能为模型提供可指导行为的有效启发规则。

我们建议将提示词划分为不同的独立模块，例如<background_information>（背景信息）、<instructions>（操作指令）、## Tool guidance（工具使用指南）、## Output description（输出要求）等，并通过XML标签或Markdown标题来区分这些模块。不过，随着模型能力的提升，提示词的具体格式要求正逐渐降低。

无论选择何种结构设计系统提示词，核心目标都是用最少的信息完整界定预期行为（需注意，“精简”并不等同于“简短”，为确保智能体遵循预期行为，仍需提前为其提供足够的信息）。最佳实践是：先基于当前性能最优的模型，测试精简版提示词的任务表现，再根据初始测试中发现的失效问题，补充清晰的指令和示例以优化性能。

工具是智能体与外部环境交互、并在工作过程中获取新上下文的关键。由于工具界定了智能体与信息/行为空间的交互规则，因此工具的设计必须以效率为核心——既要能返回词元高效的信息，也要能引导智能体形成高效的行为模式。

在《为AI智能体开发工具——与AI智能体协作》一文中，我们探讨了如何构建让大语言模型易理解、功能重叠度极低的工具。与设计精良的代码库类似，智能体的工具应具备高内聚性、容错性，且其使用用途应界定清晰；工具的输入参数也应描述准确、含义明确，并能充分发挥模型的固有优势。

我们发现，工具设计最常见的失效模式，是工具集臃肿：工具功能覆盖过广，或导致智能体在选择工具时陷入决策模糊。如果人类工程师都无法明确某一场景下应使用的工具，就更无法指望AI智能体做出正确选择。后文将提到，为智能体筛选最小可行工具集，还能让长时交互中的上下文维护和精简工作更可靠。

提供示例（即少样本提示）是公认的最佳实践，我们也始终强烈推荐这一方法。但很多团队会将大量边缘案例堆砌到提示词中，试图穷尽模型在某一任务中应遵循的所有规则，这种做法并不可取。我们建议筛选一组多样化的典型示例，用示例直观展现智能体的预期行为——对大语言模型而言，示例的价值堪比“一图胜千言”。

综上，针对上下文的各个组成部分（系统提示词、工具、示例、对话历史等），我们的核心建议是：用心设计，让上下文兼具信息性与精简性。接下来，我们将深入探讨运行时的动态上下文检索技术。

上下文检索与智能体式搜索

在《构建高性能AI智能体》一文中，我们曾阐述过大语言模型工作流与智能体的区别。自那篇文章发布后，我们对智能体形成了一个简洁的定义：能自主循环使用工具的大语言模型。

与客户的合作过程中，我们发现行业正逐渐向这一简洁的范式收敛。随着基础模型的能力不断提升，智能体的自主化程度也在同步升级：更智能的模型，能让智能体独立应对复杂的问题场景，并从错误中恢复。

工程师对智能体上下文的设计思路，也正发生着转变。如今，许多原生AI应用会采用基于嵌入的推理前检索技术，为智能体的推理过程提取关键上下文。而随着行业向更智能的智能体化方案演进，越来越多的团队开始为这类检索系统增加**“即时性”上下文策略**。

采用“即时性”策略的智能体，不会提前预处理所有相关数据，而是保留轻量级的信息标识（文件路径、存储的查询语句、网络链接等），并在运行时通过工具，基于这些标识将数据动态加载到上下文中。Anthropic的智能体式编码解决方案克劳德代码助手（Claude Code） 就采用了这一策略，实现对大型数据库的复杂数据分析：模型可编写针对性的查询语句、存储结果，并借助head、tail等Bash命令分析海量数据，而无需将完整的数据集加载到上下文窗口中。

这一策略与人类的认知模式高度相似：人类不会记住所有信息，而是会借助文件系统、收件箱、书签等外部组织和索引系统，根据需求检索相关信息。

除了存储效率的提升，这些信息标识的元数据，还能成为高效优化智能体行为的依据（无论元数据是显式提供还是可直观推导）。例如，对在文件系统中运行的智能体而言，tests文件夹下的test_utils.py文件，与src/core_logic.py中同名文件的用途截然不同。文件夹层级、命名规范、时间戳等元数据，都能为人类和智能体提供重要信号，帮助其判断信息的使用场景和时机。

让智能体自主导航和检索数据，还能实现渐进式信息披露——即智能体可通过探索，逐步发现相关上下文。每一次交互产生的上下文，都会为下一次决策提供依据：文件大小暗示数据复杂度、命名规范指向文件用途、时间戳可作为信息相关性的参考。智能体能够逐层构建对问题的理解，仅将必要信息保留在工作记忆中，并通过记笔记的方式实现信息的持久化存储。这种自主管理的上下文窗口，能让智能体始终聚焦于相关信息子集，而非被海量但可能无关的信息淹没。

当然，这一策略也存在权衡：运行时探索的速度，远慢于检索预计算数据。此外，要让大语言模型拥有高效导航信息环境的工具和启发规则，还需要工程师进行有规划、有思考的设计。若缺乏恰当的指导，智能体可能会因误用工具、追寻无效信息或未能识别关键信息，造成上下文资源的浪费。

在部分场景下，高性能的智能体会采用混合策略：为保证速度，提前检索部分数据；同时根据需求，自主开展进一步的探索。智能体的自主化程度如何界定，取决于具体的任务场景。克劳德代码助手就是采用混合策略的典型案例：它会将CLAUDE.md文件直接纳入初始上下文，同时借助glob、grep等基础工具实现环境导航和文件的即时检索，有效规避了索引过期和语法树复杂的问题。

混合策略更适用于内容动态性较低的场景，例如法律和金融领域的工作。随着模型能力的提升，智能体的设计趋势将是让高智能模型自主发挥作用，逐步减少人工干预。鉴于行业的发展速度，“用最简单的方法实现目标”，可能仍是为Claude构建智能体的团队最核心的指导原则。

面向长时任务的上下文工程

长时任务要求智能体在词元数量超出模型上下文窗口的连续操作中，始终保持行为的连贯性、上下文的完整性和目标导向性。对于大型代码库迁移、综合性研究项目这类需要持续数十分钟甚至数小时的任务，智能体需要借助专门的技术，突破上下文窗口的规模限制。

等待模型支持更大的上下文窗口，看似是最直接的解决方案，但在可预见的未来，所有规模的上下文窗口，都将面临上下文冗余和信息相关性的问题——至少在对智能体性能有高要求的场景中是如此。为让智能体能高效完成长时任务，我们研发了一系列技术，直接应对上下文冗余的约束，主要包括：上下文压缩、结构化笔记和多智能体架构。

上下文压缩

上下文压缩，是指当对话内容接近上下文窗口上限时，对内容进行总结，并基于总结结果重新开启一个新的上下文窗口。该技术通常是提升智能体长时行为连贯性的首要手段，其核心是对上下文窗口的内容进行高保真提炼，让智能体能在性能损失最小的前提下继续工作。

以克劳德代码助手为例，我们的实现方式是：将对话历史传递给模型，由模型总结并压缩其中的关键细节，保留架构决策、未解决的漏洞和实现细节，同时剔除冗余的工具输出和对话内容。随后，智能体将基于这份压缩后的上下文，结合最近访问的5个文件继续工作，用户则能在无需担心上下文窗口限制的前提下，实现任务的连续推进。

上下文压缩的关键，在于筛选保留和剔除的内容：过度激进的压缩，可能会导致一些看似细微、但后续会显现重要性的上下文信息丢失。对于开发压缩系统的工程师，我们建议基于复杂的智能体行为轨迹，精心调优压缩提示词：首先最大化信息的召回率，确保压缩提示词能捕捉轨迹中的所有相关信息；再通过迭代优化，剔除无关内容，提升信息的精准度。

清理工具调用结果，是最容易实现的冗余内容处理方式：当工具调用记录出现在对话历史的深层位置时，智能体无需再查看原始结果。作为最安全、最轻量的压缩方式，工具结果清理功能已近期在Claude开发者平台上线。

结构化笔记

结构化笔记也被称为智能体记忆，指智能体将笔记持续存储在上下文窗口之外的内存中，并在后续需要时，将笔记重新加载到上下文窗口的技术。

这一策略能以极低的开销，为智能体提供持久化记忆。例如，克劳德代码助手会创建待办清单，自定义智能体可维护NOTES.md文件，这种简单的模式能让智能体跟踪复杂任务的进度，保留那些在数十次工具调用后，原本会丢失的关键上下文和依赖关系。

Claude玩《宝可梦》的案例，直观展现了记忆功能对非编码领域智能体能力的提升：该智能体能在数千步的游戏过程中，精准记录各项数据——例如“在1号道路训练宝可梦的1234步里，皮卡丘距离10级的目标已提升8级”。无需人工提示记忆结构，该智能体还能绘制已探索区域的地图、记录解锁的关键成就，并整理战斗策略笔记，总结应对不同对手的最优招式。

在上下文重置后，智能体可读取自身记录的笔记，继续数小时的训练或迷宫探索。这种跨总结步骤的连贯性，让智能体能制定长时策略——而这是仅依靠大语言模型上下文窗口无法实现的。

在索内特4.5（Sonnet 4.5）模型发布时，我们已在Claude开发者平台推出了公测版的记忆工具。该工具基于文件系统，能让智能体更便捷地在上下文窗口外存储和查阅信息，使其可逐步构建知识库、跨会话维护项目状态，并在无需将所有信息纳入上下文的前提下，参考过往的工作内容。

子智能体架构

子智能体架构是另一种突破上下文限制的技术方案。该方案不再让单个智能体维护整个项目的状态，而是让专业化的子智能体在独立的、干净的上下文窗口中处理细分任务：主智能体负责制定高层级计划并进行协调，子智能体则完成深度技术工作，或通过工具检索相关信息。每个子智能体可进行深度探索（甚至消耗数万个词元），但最终仅向主智能体返回精简的总结结果（通常为1000-2000个词元）。

这一方案实现了关注点的清晰分离：详细的检索上下文仅保留在子智能体内部，主智能体则专注于结果的整合与分析。在《我们如何构建多智能体研究系统》一文中，我们曾探讨过这一模式，其在复杂研究任务中的表现，相较于单智能体系统有显著提升。

上述三种技术的选择，取决于任务的特征，具体如下：

• 上下文压缩：适用于需要大量交互、需保持对话连贯性的任务；
• 结构化笔记：在有明确里程碑的迭代开发任务中表现最优；
• 多智能体架构：适合可通过并行探索提升效率的复杂研究与分析任务。

即便模型能力持续提升，如何在长时交互中保持行为连贯性，仍将是构建更高效智能体的核心挑战。

结论

上下文工程，标志着大语言模型开发思路的根本性转变。随着模型能力的提升，开发的挑战不再只是撰写完美的提示词，而是在每一步都精心筛选，让哪些信息进入模型有限的注意力预算。无论是为长时任务实现上下文压缩、设计词元高效的工具，还是让智能体能即时探索环境，其核心指导原则始终不变：找到最小规模的高价值词元集合，最大化实现预期结果的可能性。

本文所阐述的技术，将随模型能力的提升持续演进。我们已发现，更智能的模型对硬性工程设计的要求更低，能让智能体实现更高的自主化程度。但即便模型能力不断升级，将上下文视为珍贵的有限资源，仍将是构建可靠、高性能智能体的核心原则。

即刻前往Claude开发者平台，开启你的上下文工程实践吧！你还可通过我们的记忆与上下文管理指南，获取更多实用技巧和最佳实践。

致谢

本文由Anthropic应用人工智能团队创作，作者包括：普里特维·拉贾塞卡兰、伊桑·狄克逊、卡莉·瑞安、杰里米·哈德菲尔德；拉菲·艾尤布、汉娜·莫兰、卡尔·鲁布、康纳·詹宁斯为本文提供了内容支持；同时特别感谢莫莉·沃维克、斯图尔特·里奇、玛吉·沃的协助。