Anthropic发布《AI Agent 上下文工程指南》

在AI应用领域里，提示工程（prompt engineering）霸占焦点位置已经很久了，而现在一个新兴术语开始冒头：上下文工程（context engineering）‍。基于语言模型的构建工作，早就不满足于寻找完美的提示词句，转而要回答一个更宏观的问题：“怎样的上下文配置，最有可能让模型产生我们预期的行为？”

上下文（context），指的是大型语言模型（LLM）采样时所包含的那一堆符号（tokens）。当下的工程难题是：在LLM固有约束之下，怎么把这些符号的效用榨到极致，稳定拿到目标结果。想真正驾驭LLM，通常得具备上下文思维——说白了，就是把LLM在任意时刻手里有什么信息、这些信息可能引发什么行为，放在一起通盘考虑。

这篇文章就来聊聊这门新兴的上下文工程技术，并给出一套精炼的心智模型，帮你构建可控又高效的人工智能体（agents）。

上下文工程和提示工程，差在哪

在Anthropic看来，语境工程就是提示工程的自然演进。提示工程琢磨的是怎么写好、组织好LLM指令，拿到最佳结果（概述和实用策略可以参考我们的文档）；语境工程管得更宽——在LLM推理过程中，怎么策划并维护好最优的符号（信息）集合，提示之外所有可能进入语境的信息都算在内。

LLM工程刚起步那会儿，提示设计就是AI工程的核心活，因为除了日常聊天，大多数用例都要为单次分类或文本生成任务专门调优提示。人如其名，提示工程主要操心怎么写出有效的提示（系统提示尤其如此）。可现在我们转向构建能在多轮推理、更长时间跨度里运作的智能体，光写提示不够了——整个语境状态（系统指令、工具、模型语境协议MCP、外部数据、消息历史等）都得有策略地管起来。

循环运行的智能体会越产越多，其中不少数据和下一轮推理有关，这些信息必须一轮一轮地提炼。语境工程，就是从不断膨胀的信息宇宙里策划哪些内容该进有限的语境窗口——既是门艺术，也是门科学。

构建强大智能体，为什么离不开上下文工程

LLM的速度越来越快，能吃下的数据量也越来越大，但我们观察到，它们和人一样，到了某个节点就会走神或者陷入混乱。“大海捞针”式基准测试的研究就揭示了上下文衰减（context rot）‍现象：语境窗口里的符号越多，模型准确回忆语境信息的能力反而越往下掉。

有些模型衰减得慢一点，但这个特性普遍存在。所以语境必须被当成一种边际收益递减的有限资源。LLM和人的工作记忆有限是一个道理，解析大量语境时花的是“注意力预算”。每引入一个新符号都要扣一部分预算，精心策划LLM可用的符号因此更加必要。

注意力稀缺的根源在LLM的架构约束。LLM基于Transformer架构，每个符号都能关注整个语境里的其他符号，形成n²对关系（n是符号数）。语境一长，模型捕捉这些关系的能力就被稀释，语境规模和注意力聚焦之间天生存在张力。另外，模型的注意力模式来自训练数据分布，而短序列在训练数据里通常更常见，等于模型见跨语境依赖见得少、能用的专用参数也不足。

位置编码插值这类技术，是让模型适配训练时的小语境去处理更长序列，代价是对符号位置的理解会打折。这些因素叠出来的是一个性能梯度，而不是硬悬崖：长语境里模型依然高度可用，但信息检索和长程推理的精度，多半比不上短语境的表现。

这些现实摆在那里：想构建强大的智能体，认真做语境工程是绕不开的。

一条高效的上下文由什么构成

既然LLM的注意力预算有限，好的语境工程就意味着找到最小的高信号符号集合，让实现目标结果的可能性最大化。道理好懂，做起来难。下面就把这条原则放进各个语境组件里，看看具体意味着什么。

系统提示应该写得极其清楚，用简单直接的语言，并把思想以适合智能体的抽象高度呈现出来。合适的高度，是夹在两种常见故障模式中间的“金发女孩区”（Goldilocks zone）。一头是工程师在提示里硬编码复杂脆弱的逻辑，逼模型做出精确行为，结果带来脆弱性、维护也变复杂；另一头是给出模糊的高层指导，LLM的输出拿不到具体信号，上下文共享还容易冒出错误假设。最优高度就是平衡：够具体，能有效引导行为；够灵活，能给出强启发式的引导。

建议把提示组织成不同区块（比如<背景信息>、<指令>、##工具指导、##输出描述等），用XML标签或Markdown标题这类手段把区块划分开——虽说随着模型能力提升，提示的确切格式可能越来越无所谓。

不管系统提示怎么搭，都应该追求最小信息集，把预期行为完整讲清楚（注意：最小不等于短，该有的信息还是得给足，智能体才会按预期行为来）。最好先拿一个最小提示去测，再根据初测发现的故障模式补清晰的指令和示例，把性能改进上去。

工具是智能体跟环境打交道的方式，也在给工作引入新的额外语境。工具定义了智能体和它的信息/行动空间之间的契约，所以工具必须讲效率：返回的信息要符号高效，还要引导出高效的智能体行为。

在《用AI智能体编写AI智能体工具》里，我们讨论过怎么构建LLM容易理解、功能重叠最少的工具。工具应该像设计良好的代码库函数：自包含、健壮、用途极其清晰。输入参数也一样，要有描述性、明确，最好还能顺着模型固有的优势走。

最常见的故障模式是工具集臃肿——功能覆盖太多，或者在“该用哪个工具”上留下模糊的决策点。人类工程师都确定不了特定情境该用哪个工具，就别指望AI智能体做得更好。后面会讲到，给智能体策划一套最小可行的工具集，长交互里的语境维护和修剪会更可靠。

给模型备好示例（也就是少样本提示）是人人皆知的最佳实践，我们至今强烈建议这么做。不过很多团队喜欢往提示里塞一长串边缘案例，试图把LLM执行特定任务该遵循的所有可能规则都讲明白。我们不推荐这个做法，反而建议策划一组多样化的规范示例，把智能体的预期行为描清楚。对LLM来说，示例就是那个“一图胜千言”的“图”。

对语境的各个组件（系统提示、工具、示例、消息历史等），我们的总原则是：想清楚再动手，让语境信息丰富又紧凑。接下来把话题推进到运行时动态检索语境。

上下文检索：让智能体自己去搜

在《构建高效AI智能体》里，我们强调过基于LLM的工作流和智能体的区别。从那篇发布以来，我们更倾向用一个简单的智能体定义：在循环中自主使用工具的LLM。

和客户的合作中，我们眼看着整个行业在向这个简单范式收敛。底层模型越强，智能体的自主性水平就可以放得越开：更聪明的模型，能让智能体独立闯过细碎的问题空间，出了错也能自己恢复。

工程师设计智能体语境的方式正在转变。眼下不少AI原生应用会在推理前跑一道基于嵌入的检索，先把重要语境捞给智能体。随着行业转向更智能体的打法，越来越多的团队开始用“即时”（just in time）语境策略来加强这些检索系统。

按“即时”方法搭起来的智能体，不会把所有相关数据预先处理好，而是维护一批轻量标识符（文件路径、存储查询、网页链接等），运行时靠这些引用通过工具把数据动态加载进语境。Anthropic的智能体编码方案Claude Code就是用这个方法对大型数据库执行复杂数据分析的：模型写定向查询、存结果，再用head、tail这类Bash命令分析大量数据，完整的数据对象根本不用灌进语境。这套路学的是人类认知：我们本来就记不住整个信息库，靠的是文件系统、收件箱、书签这些外部组织和索引系统，按需检索相关信息。

除了省存储，这些引用的元数据本身就是一套高效的行为优化机制（不管是明确给出的还是靠直觉感知的）。拿在文件系统里操作的智能体来说：tests文件夹里的test_utils.py，和src/core_logic.py里的同名文件，隐含的用途就不一样。文件夹层次、命名约定、时间戳都是重要信号，人和智能体都能靠它们理解信息该怎么用、何时用。

让智能体自主导航和检索数据，还顺带支持了渐进式披露（progressive disclosure）——即让智能体通过探索一步步发现相关语境。每次交互都会产出能指导下一步决策的语境：文件大小暗示复杂性，命名约定提示目的，时间戳可以当相关性代理。智能体就这样层层组装自己的理解，工作记忆里只维护必要内容，再用笔记策略实现额外的持久性。这种自我管理的语境窗口，让智能体盯住相关的那部分信息，而不是被详尽却可能无关的信息淹没。

当然，有代价要权衡：运行时探索比检索预计算的数据慢。而且还得做足深思熟虑的工程化，确保LLM手里有正确的工具和启发式方法，能在其信息景观里有效导航。引导不到位，智能体就可能误用工具、钻进死胡同、认不出关键信息，把语境白白耗掉。

有些场景下，最有效的智能体可能靠的是混合策略：一部分数据预先检索好换速度，要不要进一步探索由它自己定。“合适”的自主水平取决于任务。Claude Code就是采用这种混合模型的智能体：CLAUDE.md文件简单直接地预先放进语境，glob和grep这些原语让它能导航环境、即时检索文件，过期索引和复杂语法树的问题就这么绕开了。

内容动态性较低的语境（比如法律或金融工作），混合策略可能更合适。随着模型能力提升，智能体设计会趋向让聪明的模型自己聪明地行动，人工策划逐步减少。行业变化这么快，“做最简单有效的事”，大概仍然是我们给基于Claude构建智能体的团队的最佳建议。

长周期任务的上下文工程怎么做

长周期任务要求智能体在符号数超过LLM语境窗口的动作序列里，保持连贯性、语境和目标导向行为。碰上持续几十分钟到数小时的任务——大型代码库迁移、综合研究项目这类——智能体就得靠专门技术绕开语境窗口大小的天花板。

干等更大的语境窗口，看似是个明摆着的策略。但可以预见，窗口不管多大，都可能被语境污染和信息相关性困扰——至少在那些对智能体性能要求极高的场景里是这样。为了让智能体在拉长的时间跨度里照样有效工作，我们开发了几种直接对着语境污染约束下手的技术：压缩（compaction）‍、结构化笔记（structured note-taking）‍和多智能体架构（multi-agent architectures）‍。

压缩
所谓压缩，就是把快到语境窗口限制的对话总结一遍，再用这份总结重新初始化一个新的语境窗口。想提升长期连贯性，压缩通常是语境工程的第一招。压缩的精髓在于以高保真的方式蒸馏语境窗口的内容，让智能体继续干活时性能掉到最小。

拿Claude Code举例：我们把消息历史传给模型，让它总结、压缩出最关键的细节。架构决策、未解决的漏洞和实施细节会被保留，冗余的工具输出或消息则被丢掉。之后智能体带着压缩过的语境和最近访问的五个文件接着干。用户拿到了连续性，不用操心语境窗口限制。

压缩这门手艺，功夫全在“留什么、丢什么”上，因为压缩过头可能丢掉细微却关键的语境（它的重要性也许要到后面才显现）。给实现压缩系统的工程师一条建议：在复杂的智能体轨迹上精心调提示，先把召回最大化，确保压缩提示抓到轨迹里所有相关信息，再一轮轮提高精度，把冗余内容消掉。

最容易摘到的冗余果实，是清除工具调用及其结果——工具都已经在消息历史深处被调用过了，智能体为何还要再看一遍原始结果？最安全、最轻量的压缩形式就是工具结果清除，最近已作为功能在Claude开发者平台发布。

结构化笔记
结构化笔记（也叫智能体记忆）是让智能体定期写笔记、把记忆持久化到语境窗口之外的技术。这些笔记之后会被拉回语境窗口里。

这个策略花最小的开销，换来持久记忆。就像Claude Code创建待办列表，或自定义智能体维护一份NOTES.md文件，模式简单，但智能体从此能跟住复杂任务的进度，那些横跨大量工具调用、本来必丢的关键语境和依赖也保住了。

Claude玩Pokémon这件事，展示了记忆在非编码领域能把智能体的能力改造成什么样。这个智能体在数千游戏步骤里保持精确计数——像“过去1234步我一直在Route 1训练Pokémon，Pikachu已向10级目标提升了8级”这样的目标它都盯着跟踪。没人给它任何记忆结构的提示，它自己画出了已探索区域的地图，记住了已解锁的关键成就，还维护着战斗策略的战略笔记，摸清哪些攻击对不同对手最有效。

语境重置之后，智能体读一遍自己的笔记，就能接着跑几小时的训练序列或地下城探索。这种跨过总结步骤仍然在线的连贯性，撑起了长周期策略——只把一切留在LLM语境窗口里是绝对做不到的。

配合Sonnet 4.5发布，我们在Claude开发者平台公开测试了记忆工具：它用基于文件的系统，让语境窗口外的信息更好存、更好查。智能体从此能随时间积累知识库，跨会话维护项目状态，引用之前的工作也不用把所有内容都留在语境里。

子智能体架构
子智能体架构提供了另一种规避语境限制的办法。与其让一个智能体死撑整个项目状态，不如派一批专用子智能体，各拿一个干净的语境窗口去处理聚焦任务。主智能体用高层计划做协调，子智能体去干深度技术活、或用工具查找相关信息。单个子智能体可能广泛探索、用掉数万甚至更多符号，但回报的只有浓缩摘要（一般1000-2000符号）。

这么干实现了关注点分离——详细搜索的语境留在子智能体那边，主导智能体专心综合和分析结果。这个模式在《我们如何构建多智能体研究系统》里讨论过，结果显示复杂研究任务上，它比单智能体系统有明显改进。

这几种方法怎么选，取决于任务特性。比如：

• 要维持对话流、来回交流特别多的任务，适合用压缩；
• 里程碑清晰的迭代开发，适合记笔记；
• 并行探索收益显著的复杂研究和分析，交给多智能体架构。

就算模型持续改进，在拉长的交互里保持连贯性，这个挑战仍会是构建更高效智能体的核心。

最后说两句

语境工程代表我们构建LLM的方式来了个根本转变。模型能力越强，挑战就越来越不只是打磨出完美的提示——而是深思熟虑地策划：每一步哪些信息配进入模型那份有限的注意力预算。不管你是在为长周期任务实现压缩、设计符号高效的工具，还是让智能体即时探索环境，指导原则不变：找到最小的高信号符号集合，让拿到目标结果的可能性最大。

我们概述的这些技术，会随模型改进继续演化。已经能看到：更聪明的模型需要更少的规定性工程，智能体可以以更高的自主性运作。但就算能力一直扩，把语境当成宝贵而有限的资源来对待，仍是构建可靠、高效智能体的核心。

想动手的话，可以马上在Claude开发者平台开启语境工程之旅，我们的记忆和语境管理手册里有实用的提示和最佳实践。

致谢

本文由Anthropic应用AI团队撰写：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan和Jeremy Hadfield执笔，团队成员Rafi Ayub、Hannah Moran、Cal Rueb和Connor Jennings也有贡献。特别感谢Molly Vorwerck、Stuart Ritchie和Maggie Vo的支持。