一、核心概念：从提示工程到上下文工程
定义转变：上下文工程是提示工程的自然演进。重点从“如何写好提示词”转向“如何配置整体上下文状态，以最大化期望行为”。
上下文本质：指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开发者平台上开始进行上下文工程，并通过我们的记忆和上下文管理指南获取有用的提示和最佳实践。
