一、核心概念从提示工程到上下文工程定义转变上下文工程是提示工程的自然演进。重点从“如何写好提示词”转向“如何配置整体上下文状态以最大化期望行为”。上下文本质指LLM推理时包含的全部token集合系统指令、工具、MCP协议、外部数据、消息历史等。核心挑战上下文是有限资源需在注意力预算约束下优化token效用。二、为什么需要上下文工程注意力稀缺Transformer架构下n个token产生n²对关系长上下文会摊薄注意力导致“上下文衰退”信息召回能力随token数增加而下降。性能梯度模型在长上下文上仍可用但精确度下降尤其影响信息检索和长程推理。结论必须像管理人类工作记忆一样精心策划上下文内容。三、有效上下文的构建原则组成部分关键策略系统提示采用“合适抽象层级”——既不过度具体脆弱易碎也不过于模糊缺乏约束使用XML/Markdown分区从最简提示开始迭代。工具设计功能自包含、重叠最小、描述清晰避免工具集过于庞大导致决策模糊返回token高效的信息。示例少样本精选多样化、典范性示例而非罗列大量边缘案例示例对LLM“一图胜千言”。总体原则追求“最小但充分”的高信息量token集合同时保持上下文信息丰富且紧凑。四、上下文检索与智能体搜索从预检索到即时加载传统方法在推理前嵌入检索“即时”策略让智能体维护轻量标识符文件路径、查询、链接运行时动态加载数据。渐进式披露智能体通过自主探索逐步发现上下文利用文件结构、命名规范、时间戳等元数据辅助决策。混合策略部分数据预先加载如CLAUDE.md部分通过glob、grep等工具即时检索兼顾速度与灵活性。风险与权衡自主探索较慢需精心设计工具和启发式避免误用工具或陷入死胡同。五、面向长周期任务的上下文管理技术1. 压缩Compaction当对话接近上下文窗口上限时让模型对历史进行高保真摘要丢弃冗余工具输出保留架构决策、未解决错误等关键信息。技巧先最大化召回再迭代优化精确度最轻量做法是清除老旧工具调用结果已作为Claude平台特性推出。2. 结构化记笔记Agentic Memory智能体定期将笔记写入上下文外的持久存储如NOTES.md后续按需拉回。效果示例Claude玩Pokémon在数千步中追踪训练进度、地图探索、战斗策略实现跨重置的长期连贯性。Anthropic已发布公开测试版记忆工具支持基于文件的上下文外存储。3. 子智能体架构Sub-agent Architectures主智能体负责高层的计划和协调专门子智能体处理聚焦任务各自维护干净上下文。子智能体可消耗数万token深入探索但只返回精炼摘要1000-2000 token实现关注点分离。在复杂研究任务中显著优于单智能体系统。选择指南压缩适合需要大量来回交互的对话式任务。记笔记适合有清晰里程碑的迭代开发。子智能体适合并行探索收益高的复杂研究与分析。六、总体结论与趋势核心原则不变在所有场景下目标都是“找到最小的、高信息量的token集合最大化期望结果的概率”。未来方向模型越智能所需的规定性工程越少自主性越高。但无论模型如何进步“将上下文视为珍贵有限资源”的理念将长期适用。务实建议在Claude上构建智能体的团队应遵循“做最简单可行之事”并持续利用压缩、记忆、子智能体等工具应对长周期挑战。七、核心贡献总结维度要点范式跃迁提示工程 → 上下文工程关注全局状态配置而非单个提示。资源观上下文是有限注意力预算需精打细算。工程实践系统提示、工具、示例、检索策略、长周期管理五方面给出具体指导。长周期方案压缩、记笔记、子智能体三套成熟技术。设计哲学让智能模型自主行动人工干预最小化但需提供正确工具和启发式。这里是自己的论文阅读记录感兴趣的话可以参考一下如果需要阅读原文的话可以看这里如下所示上下文对于AI智能体而言是至关重要但却有限的资源。在本文中我们将探讨有效策划和管理驱动智能体的上下文的策略。在应用AI领域经历了几年对提示工程的关注之后一个新术语崭露头角上下文工程。使用语言模型进行开发正日益从“为提示找到恰当的措辞”转变为回答一个更广泛的问题“什么样的上下文配置最有可能使模型产生我们期望的行为”上下文指的是在对大语言模型LLM进行采样时所包含的token集合。我们面临的工程问题是在LLM的固有约束下优化这些token的效用以持续达成期望的结果。有效地驾驭LLM通常需要“在上下文中思考”——换句话说就是考虑LLM在任何给定时间可用的整体状态以及该状态可能产生哪些潜在行为。在本文中我们将探讨新兴的上下文工程艺术并提供一个用于构建可控、高效智能体的更精炼的思维模型。上下文工程 vs. 提示工程在Anthropic我们将上下文工程视为提示工程的自然演进。提示工程指的是为了获得最佳结果而编写和组织LLM指令的方法请参阅我们的文档以了解概述和有用的提示工程策略。上下文工程则是指在LLM推理过程中策划和维护最优token信息集合的策略其中包括提示之外可能进入上下文的所有其他信息。在LLM工程的早期提示工程是AI工程工作的最大组成部分因为日常聊天交互之外的绝大多数用例都需要针对一次性分类或文本生成任务进行优化的提示。顾名思义提示工程的主要关注点是如何编写有效的提示尤其是系统提示。然而随着我们转向构建能够在多轮推理和更长时间跨度上运行的更强大的智能体我们需要管理整个上下文状态系统指令、工具、模型上下文协议MCP、外部数据、消息历史等的策略。在循环中运行的智能体会产生越来越多可能与下一轮推理相关的数据而这些信息必须被循环地提炼。上下文工程是一门艺术和科学旨在从不断演变的庞杂可能信息中策划出哪些内容将放入有限的上下文窗口。为什么上下文工程对于构建强大智能体至关重要尽管LLM速度很快并且能够处理越来越大的数据量但我们观察到LLM和人类一样在某个特定点会出现注意力分散或困惑的情况。关于大海捞针式基准测试的研究揭示了“上下文衰退”的概念随着上下文窗口中的token数量增加模型从该上下文中准确回忆信息的能力会下降。虽然某些模型的性能退化比其他模型更平缓但所有模型都表现出这一特性。因此必须将上下文视为一种边际收益递减的有限资源。就像人类的工作记忆容量有限一样LLM在解析大量上下文时也有一个“注意力预算”。每引入一个新token都会在一定程度上消耗这个预算因此更加需要精心策划可供LLM使用的token。这种注意力稀缺性源于LLM的架构限制。LLM基于Transformer架构该架构使得每个token都能关注整个上下文中的所有其他token。这意味着n个token会产生n²对关系。随着上下文长度的增加模型捕捉这些成对关系的能力会被摊薄从而在上下文大小和注意力聚焦之间形成一种天然的张力。此外模型的注意力模式是从训练数据分布中习得的其中较短的序列通常比较长的序列更常见。这意味着模型在处理上下文范围依赖关系方面的经验和专门参数都较少。诸如位置编码插值等技术允许模型通过将长序列适配到原本训练时使用的较短上下文来处理更长的序列尽管会对token位置的理解造成一定的性能损失。这些因素形成了一个性能梯度而不是一个断崖式下降模型在较长上下文中仍然保持强大的能力但与处理较短上下文时的表现相比其信息检索和长程推理的精确度可能会有所下降。这些现实情况意味着深思熟虑的上下文工程对于构建强大的智能体至关重要。有效上下文的构成鉴于LLM受到有限注意力预算的约束良好的上下文工程意味着找到尽可能小的、高信息量的token集合以最大化期望结果的可能性。实施这一实践说来容易做来难在接下来的部分中我们将概述这一指导原则在上下文不同组成部分中的实际含义。系统提示应该极为清晰使用简单直接的语言并以“合适的抽象层级”向智能体呈现想法。合适的抽象层级是介于两种常见失败模式之间的“黄金地带”。一种极端情况是工程师为了精确触发智能体的特定行为在提示中硬编码复杂、脆弱的逻辑。这种方法会带来脆弱性并随着时间的推移增加维护复杂性。另一种极端情况是工程师有时会提供模糊、高层次的指导未能向LLM传递期望输出的具体信号或者错误地假设了共享的上下文。最佳的抽象层级是在两者之间取得平衡既要具体到能有效引导行为又要灵活到能为模型提供强有力的启发式方法来指导行为。我们建议将提示组织成不同的部分如background_information、instructions、## Tool guidance、## Output description等并使用XML标记或Markdown标题等技术来划分这些部分尽管随着模型能力的提升提示的确切格式可能变得越来越不重要。无论你决定如何构建系统提示你都应力求用最少的信息完整地勾勒出期望的行为。请注意“最少”不一定意味着“简短”你仍然需要预先向智能体提供足够的信息以确保它遵循期望的行为。最好的做法是首先用现有最好的模型测试一个最简提示看看它在你的任务上表现如何然后根据初步测试中发现的失败模式添加清晰的指令和示例来提升性能。工具使智能体能够与其环境交互并在工作过程中引入新的、额外的上下文。由于工具定义了智能体与其信息/行动空间之间的契约因此工具必须促进效率既要通过返回token高效的信息也要通过鼓励智能体高效的行为这一点至关重要。在《用AI智能体为AI智能体编写工具》一文中我们讨论了构建能被LLM良好理解且功能重叠最小的工具。与设计良好的代码库中的函数类似工具应该是自包含的、对错误具有鲁棒性并且对其预期用途极为清晰。输入参数同样应该具有描述性、无歧义并发挥模型的固有优势。我们观察到的最常见失败模式之一是工具集过于庞大覆盖了太多功能或者导致在选择使用哪个工具时出现模糊的决策点。如果人类工程师无法明确判断在特定情况下应该使用哪个工具那么就不能指望AI智能体能做得更好。正如我们稍后将讨论的为智能体策划一组最小可行工具也能在长时间交互中实现更可靠的维护和上下文裁剪。提供示例即少样本提示是一个众所周知的最佳实践我们继续强烈推荐。然而团队通常会在提示中塞入一长串边缘案例试图详尽阐述LLM在特定任务中应遵循的所有规则。我们不推荐这种做法。相反我们建议努力策划一组多样化、典范性的示例以有效描绘智能体的预期行为。对于LLM来说示例就是“一图胜千言”的“图”。我们对上下文不同组成部分系统提示、工具、示例、消息历史等的总体指导是深思熟虑保持上下文信息丰富但又紧凑。现在让我们深入探讨在运行时动态检索上下文。上下文检索与智能体搜索在《构建高效的AI智能体》一文中我们强调了基于LLM的工作流与智能体之间的区别。自那篇文章以来我们逐渐倾向于一个简单的智能体定义LLM在循环中自主使用工具。在与客户的合作中我们看到该领域正在向这一简单范式收敛。随着底层模型能力的增强智能体的自主水平可以相应提升更智能的模型使得智能体能够独立应对微妙的问题空间并从错误中恢复。我们现在正看到工程师设计智能体上下文的方式发生转变。如今许多AI原生应用采用某种形式的基于嵌入的推理前检索来为智能体提供重要上下文以供其推理。随着该领域向更具智能体特性的方法过渡我们看到越来越多的团队用“即时”上下文策略来增强这些检索系统。采用“即时”方法构建的智能体不会预先处理所有相关数据而是维护轻量级的标识符文件路径、存储的查询、网页链接等并在运行时使用工具通过这些引用将数据动态加载到上下文中。Anthropic的智能体编码解决方案Claude Code就使用这种方法在大型数据库上进行复杂的数据分析。该模型可以编写有针对性的查询、存储结果并利用head和tail等Bash命令来分析大量数据而无需将完整的数据对象加载到上下文中。这种方法模仿了人类的认知我们通常不会记住整个信息库而是引入外部组织和索引系统如文件系统、收件箱和书签以便按需检索相关信息。除了存储效率之外这些引用的元数据还提供了一种有效细化行为的机制无论是显式提供的还是隐式体现的。对于在文件系统中运行的智能体来说位于tests文件夹中名为test_utils.py的文件与位于src/core_logic/中同名文件的目的暗示是不同的。文件夹层次结构、命名规范和时间戳都提供了重要的信号帮助人类和智能体理解如何以及何时利用信息。让智能体自主导航和检索数据还能实现“渐进式披露”——换句话说允许智能体通过探索逐步发现相关上下文。每次交互都会产生为下一步决策提供信息的上下文文件大小暗示复杂性命名规范暗示用途时间戳可作为相关性的代理指标。智能体可以逐层构建理解只在工作记忆中保留必要内容并利用记笔记策略来增强持久性。这种自我管理的上下文窗口使智能体能够专注于相关的子集而不是淹没在海量但可能无关的信息中。当然这需要权衡取舍运行时探索比检索预先计算好的数据要慢。不仅如此还需要有主见且深思熟虑的工程来确保LLM拥有正确的工具和启发式方法以便有效地在其信息空间中导航。如果没有适当的指导智能体可能会因误用工具、追逐死胡同或未能识别关键信息而浪费上下文。在某些情况下最高效的智能体可能会采用混合策略预先检索一些数据以保证速度并自行决定是否进行进一步的自主探索。决定“合适”自主水平的边界取决于具体任务。Claude Code就是采用这种混合模型的智能体CLAUDE.md文件被直接预先放入上下文而glob和grep等原语则允许它导航其环境并即时检索文件有效地规避了索引过时和复杂语法树的问题。混合策略可能更适合内容动态性较低的场景例如法律或金融工作。随着模型能力的提升智能体设计将趋向于让智能模型自主智能地行动人工策划将逐步减少。鉴于该领域的快速发展“做最简单可行的事情”很可能仍然是我们对在Claude之上构建智能体的团队的最佳建议。面向长周期任务的上下文工程长周期任务要求智能体在token数量超过LLM上下文窗口的一系列行动中保持连贯性、上下文和以目标为导向的行为。对于需要持续工作数十分钟到数小时的任务如大型代码库迁移或综合研究项目智能体需要专门的技术来规避上下文窗口大小的限制。等待更大的上下文窗口似乎是一种显而易见的策略。但在可预见的未来各种规模的上下文窗口可能都会受到上下文污染和信息相关性问题的困扰——至少在要求最强智能体性能的情况下是如此。为了使智能体能够在延长时间范围内有效工作我们开发了几种直接解决这些上下文污染约束的技术压缩、结构化记笔记和多智能体架构。压缩压缩是指将一段接近上下文窗口限制的对话对其内容进行摘要并使用该摘要重新启动一个新的上下文窗口的做法。压缩通常是上下文工程中驱动更好长期连贯性的首要手段。其核心在于压缩以高保真的方式提炼上下文窗口的内容使智能体能够以最小的性能损失继续运行。例如在Claude Code中我们通过将消息历史传递给模型来总结和压缩最关键细节的方式来实现这一点。模型会保留架构决策、未解决的错误和实现细节同时丢弃冗余的工具输出或消息。然后智能体可以使用这个压缩后的上下文加上最近访问的五个文件来继续工作。用户可以获得连续性而无需担心上下文窗口的限制。压缩的艺术在于选择保留什么和丢弃什么因为过于激进的压缩可能会导致丢失微妙但关键的上下文而这些上下文的重要性可能在之后才会显现。对于实施压缩系统的工程师我们建议在复杂的智能体轨迹上仔细调整你的提示。从最大化召回率开始确保你的压缩提示捕捉到轨迹中的每条相关信息然后通过迭代来消除多余内容以提高精确度。一个容易实现的多余内容示例是清除工具调用和结果——一旦工具在消息历史深处被调用过智能体为什么还需要再次看到原始结果最安全、最轻量的压缩形式之一是工具结果清除该功能最近已作为一项特性在Claude开发者平台上推出。结构化记笔记结构化记笔记或称智能体记忆是一种技术智能体定期将笔记写入到上下文窗口之外的持久化存储器中。这些笔记在之后被重新拉回上下文窗口。这种策略以极小的开销提供了持久记忆。就像Claude Code创建待办事项列表或者你的自定义智能体维护一个NOTES.md文件一样这种简单的模式允许智能体在复杂任务中跟踪进度维护那些否则会在数十次工具调用中丢失的关键上下文和依赖关系。Claude玩Pokémon的例子展示了记忆如何改变非编码领域中的智能体能力。该智能体在数千个游戏步骤中保持着精确的记录——跟踪目标比如“在过去1234步中我一直在1号道路训练我的Pokémon皮卡丘已经升了8级距离10级的目标更近了。”无需任何关于记忆结构的提示它就能绘制探索过的区域地图记住已解锁的关键成就并维护战斗策略的战略笔记帮助它学习哪些攻击对不同对手最有效。在上下文重置后智能体会读取自己的笔记并继续多小时的训练序列或地牢探索。这种跨摘要步骤的连贯性使得长周期策略成为可能而如果将所有信息都放在LLM的上下文窗口中是无法实现的。作为Sonnet 4.5发布的一部分我们在Claude开发者平台上发布了一个公开测试版的记忆工具通过基于文件的系统更轻松地在上下文窗口之外存储和查阅信息。这允许智能体随时间积累知识库在会话间维护项目状态并引用之前的工作而无需将所有内容都保留在上下文中。子智能体架构子智能体架构提供了另一种绕过上下文限制的方法。不必让一个智能体试图在整个项目中维护状态专门的子智能体可以以干净的上下文窗口处理聚焦的任务。主智能体协调高层计划而子智能体执行深入的技术工作或使用工具来查找相关信息。每个子智能体可能会进行大量探索使用数万甚至更多token但只返回其工作的精炼摘要通常在1000-2000 token。这种方法实现了清晰的关注点分离——详细的搜索上下文保留在子智能体内部而主智能体则专注于综合和分析结果。这种模式在《我们如何构建多智能体研究系统》一文中讨论过在复杂研究任务上显示出相比单智能体系统的显著改进。这些方法之间的选择取决于任务特征。例如对于需要大量来回交互的任务压缩能维持对话流畅性对于具有明确里程碑的迭代开发记笔记表现出色多智能体架构能够处理复杂的研究和分析其中并行探索能带来显著收益。即使模型不断改进在扩展交互中保持连贯性的挑战仍将是构建更高效智能体的核心。结论上下文工程代表了我们在使用LLM进行开发方面的根本性转变。随着模型变得更加强大挑战不仅仅在于设计完美的提示——而在于在每个步骤中深思熟虑地策划哪些信息进入模型有限的注意力预算。无论你是在为长周期任务实施压缩、设计token高效的工具还是让智能体即时探索其环境指导原则始终如一找到尽可能小的、高信息量的token集合以最大化期望结果的可能性。我们概述的这些技术将随着模型的改进而持续演进。我们已经看到更智能的模型需要更少的规定性工程允许智能体以更高的自主性运行。但即使能力不断提升将上下文视为宝贵而有限的资源仍将是构建可靠、高效智能体的核心。立即在Claude开发者平台上开始进行上下文工程并通过我们的记忆和上下文管理指南获取有用的提示和最佳实践。