prompt engineering 在应用 AI 领域备受瞩目几年之后，一个新术语开始崭露头角：context engineering。用语言模型做构建，越来越多地不是在找 prompt 里对的词和短语，而是在回答一个更宽泛的问题：「什么样的 context 配置最可能让模型产生我们想要的行为？」
Context 指从大语言模型（LLM）采样时包含的那组 token。手上的工程问题是：在 LLM 固有约束下优化这些 token 的效用，以稳定达成期望结果。有效驾驭 LLM 通常需要 在 context 中思考——换句话说：考虑 LLM 在任一时刻可用的整体状态，以及那个状态可能产生什么行为。
在这篇文章里，我们探讨 context engineering 这门新兴技艺，并提供一个经过打磨的心智模型来构建可操控、有效的 agent。
在 Anthropic，我们把 context engineering 看作 prompt engineering 的自然延伸。prompt engineering 指为获得最佳结果而编写和组织 LLM 指令的方法（参见我们的文档了解概览和有用的 prompt engineering 策略）。Context engineering 指在 LLM 推理期间策划和维护最优 token（信息）集合的一组策略，包括 prompt 之外可能进入 context 的所有其他信息。
在用 LLM 做工程的早期，prompting 是 AI 工程工作最大的组成部分，因为日常聊天之外的多数用例都需要为一次性分类或文本生成任务优化 prompt。顾名思义，prompt engineering 的核心是怎么写有效的 prompt，尤其是 system prompt。然而，随着我们走向构建更强大的 agent——在多轮推理和更长时间跨度上运作——我们需要管理整个 context 状态的策略（system 指令、工具、Model Context Protocol（MCP）、外部数据、消息历史等）。
一个在 loop 里跑的 agent 生成越来越多_可能_与下一轮推理相关的数据，这些信息必须被循环精炼。Context engineering 是一门艺术与科学：从那个不断演变的可能信息宇宙中，策划出进入有限 context window 的内容。
与写 prompt 这个离散任务不同，context engineering 是迭代的——每次决定传什么给模型时都发生一次策划。
为什么 context engineering 对构建强大的 agent 很重要
尽管 LLM 速度快、能处理越来越大的数据量，我们观察到 LLM 和人一样，在某个点上会失去焦点或感到困惑。对 needle-in-a-haystack 风格基准测试的研究揭示了一个概念——context rot：随着 context window 中 token 数量增加，模型从 context 中准确召回信息的能力下降。
虽然有些模型比别的模型退化得更平缓，但这个特征在所有模型上都存在。因此，context 必须被当作一种有限资源来对待，有着递减的边际收益。和人一样——人有有限的工作记忆容量——LLM 有一个「注意力预算」，在解析大量 context 时消耗。每引入一个新 token 就消耗一些预算，这增加了精心策划 LLM 可用 token 的必要性。
这种注意力稀缺源于 LLM 的架构约束。LLM 基于 transformer 架构，该架构让每个 token 能attend 到其他所有 token——跨整个 context。这产生 n 个 token 的 n² 个成对关系。
随着 context 长度增加，模型捕捉这些成对关系的能力被摊薄，在 context 大小和注意力焦点之间造成天然张力。此外，模型的注意力模式是从训练数据分布中发展出来的，而训练数据中短序列通常比长序列更常见。这意味着模型对 context 范围内的依赖关系经验更少、专用参数更少。
位置编码插值等技术允许模型处理更长序列——通过将它们适配到最初训练的更小 context，但对 token 位置理解有一些退化。这些因素造成的是一个性能梯度而非硬性悬崖：模型在更长 context 下仍然高度可用，但与较短 context 上的表现相比，信息检索和长程推理的精度可能下降。
这些现实意味着，深思熟虑的 context engineering 对构建强大的 agent 至关重要。
有效 context 的解剖
既然 LLM 受限于有限的注意力预算，好的 context engineering 意味着找到 最小 可能 的高信号 token 集，使某个期望结果的可能性最大化。实施这个原则说起来容易做起来难，但在下面这节里，我们概述这条指导原则在 context 的各个组件上实际意味着什么。
System prompt 应该极其清晰，用简单直接的语言把想法呈现在 agent 的 right altitude（合适高度）。合适高度是两个常见失败模式之间的 Goldilocks 区间。一个极端是，工程师在 prompt 里硬编码复杂、脆弱的逻辑来诱发精确的 agent 行为。这种方式制造脆弱性并随时间增加维护复杂度。另一个极端是，工程师有时提供模糊、高层的指导，未能给 LLM 期望输出的具体信号或错误地假设有共享 context。最优高度在两者间取得平衡：足够具体以有效引导行为，又足够灵活以给模型提供强有力的启发式规则。
一端是脆弱的 if-else 硬编码 prompt，另一端是过于笼统或错误假设共享 context 的 prompt。
我们建议把 prompt 组织成分明的段落（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），用 XML 标签或 Markdown 标题来划分这些段落，尽管随着模型变强，prompt 的具体格式可能越来越不重要。
不管你怎么组织 system prompt，都应该追求完整概述期望行为的最小信息集。（注意最小不一定意味着短；你仍需给 agent 足够的前置信息以确保它遵循期望行为。）最佳做法是先用最好的模型测试一个最小 prompt，看它在你的任务上表现如何，然后根据初始测试中发现的失败模式添加清晰的指令和示例来改善性能。
工具 让 agent 操作其环境并在工作中拉取新的额外 context。因为工具定义了 agent 与其信息/动作空间之间的契约，工具是否促进效率极其重要——既体现在返回 token 高效的信息，也体现在鼓励高效的 agent 行为。
在 Writing tools for AI agents – with AI agents 中，我们讨论了构建 LLM 能充分理解且功能重叠最小的工具。和设计良好的代码库中的函数一样，工具应该自包含、对错误健壮、在预期用途上极其清晰。输入参数同样应该描述性强、无歧义，并发挥模型的固有优势。
我们见到的最常见失败模式之一是臃肿的工具集——覆盖太多功能或导致用哪个工具的歧义决策点。如果一个工程师在给定场景下都不能明确说该用哪个工具，就不能指望 AI agent 做得更好。后面会讨论，为 agent 策划一个最小可用工具集也能在长交互中带来更可靠的维护和 context 修剪。
提供示例——即 few-shot prompting——是一项众所周知的最佳实践，我们继续强烈建议。然而，团队常把一堆边界情况塞进 prompt 试图讲清楚 LLM 在某个任务上应遵循的每一条规则。我们不推荐这样做。相反，我们建议策划一组多样的、典范性的示例，有效展现 agent 的期望行为。对 LLM 来说，示例就是「值千言的图」。
我们对 context 各组件（system prompt、工具、示例、消息历史等）的总体指导是：深思熟虑，保持 context 信息丰富但紧凑。现在让我们深入运行时动态检索 context。
Context 检索与 agentic search
在 Building effective AI agents 中，我们强调了基于 LLM 的工作流和 agent 之间的区别。自那篇文章以来，我们倾向于一个 agent 的简单定义：LLM 在 loop 中自主使用工具。
在与客户合作中，我们看到领域正汇聚到这个简单范式上。随着底层模型变强，agent 的自主性可以扩展：更聪明的模型让 agent 能独立导航细微的问题空间并从错误中恢复。
我们现在看到工程师在设计 agent context 方面的思路转变。如今许多 AI-native 应用采用某种形式的 embedding 式预推理检索来为 agent 的推理浮现重要 context。随着领域转向更 agentic 的方法，我们越来越多地看到团队用「just in time」context 策略来增强这些检索系统。
不是预先处理所有相关数据，采用「just in time」方法构建的 agent 维护轻量标识符（文件路径、存储查询、web 链接等），用这些引用在运行时通过工具动态加载数据到 context。Anthropic 的 agentic 编码方案 Claude Code 用这种方法在大型数据库上做复杂数据分析。模型可以写有针对性的查询、存结果、用 head 和 tail 等 Bash 命令分析大量数据而不把完整数据对象加载进 context。这种方式镜像人类认知：我们一般不记忆整个信息语料库，而是引入外部组织和索引系统——文件系统、收件箱、书签——按需检索相关信息。
除存储效率外，这些引用的元数据提供了一种高效精炼行为的机制，无论是显式提供还是直觉性的。对一个在文件系统中操作的 agent 来说，tests 文件夹里一个叫 test_utils.py 的文件暗示的用途不同于 src/core_logic/ 里同名文件。文件夹层级、命名约定、时间戳都提供重要信号，帮助人和 agent 理解如何以及何时使用信息。
让 agent 自主导航和检索数据还实现了渐进式披露——换句话说，允许 agent 通过探索增量发现相关 context。每次交互产出的 context 为下一个决策提供信息：文件大小暗示复杂度；命名约定提示用途；时间戳可以作为相关性的代理。Agent 可以一层层组装理解，只在工作记忆中保留必要内容，利用笔记策略做额外持久化。这个自管理的 context window 让 agent 聚焦于相关子集而非淹没在详尽但可能无关的信息中。
当然有取舍：运行时探索比检索预计算数据慢。不仅如此，还需要有主见和深思熟虑的工程来确保 LLM 有正确的工具和启发式规则来有效导航其信息版图。没有适当引导，agent 可能因误用工具、追死胡同或未能识别关键信息而浪费 context。
在某些场景下，最有效的 agent 可能采用混合策略：预先检索部分数据以求速度，再酌情做进一步自主探索。「正确」自主水平的决策边界取决于任务。Claude Code 是一个采用混合模型的 agent：CLAUDE.md 文件被朴素地预加载到 context，而 glob 和 grep 等原语让它导航环境并 just-in-time 检索文件，有效绕过了陈旧索引和复杂语法树的问题。
混合策略可能更适合内容不那么动态的场景，如法律或金融工作。随着模型能力提升，agentic 设计将趋向于让智能模型智能行事，逐步减少人工策划。鉴于领域快速进展，「做能用的最简单的事」可能仍然是我们对基于 Claude 构建 agent 的团队的最佳建议。
长程任务的 context engineering
长程任务要求 agent 在 token 数超出 LLM context window 的动作序列上保持连贯性、context 和目标导向行为。对于跨越几十分钟到数小时连续工作的任务——如大型 codebase 迁移或综合研究项目——agent 需要专门技术来绕过 context window 大小限制。
等更大的 context window 看似是个显而易见的策略。但在可预见的未来，所有大小的 context window 大概都会受到 context 污染和信息相关性问题的困扰——至少在追求最强 agent 性能的场景下如此。为了让 agent 在扩展的时间跨度上有效工作，我们开发了几种直接应对 context 污染约束的技术：compaction、结构化笔记和 multi-agent 架构。
Compaction
Compaction 是把一个接近 context window 上限的对话拿过来，总结其内容，然后用总结重新开启一个新的 context window。Compaction 通常作为 context engineering 中驱动更好长期连贯性的第一个杠杆。其核心是高保真地蒸馏 context window 的内容，使 agent 能以最小的性能退化继续。
比如在 Claude Code 中，我们通过把消息历史传给模型来总结和压缩最关键的细节来实现这个。模型保留架构决策、未解决的 bug 和实现细节，丢弃冗余的工具输出或消息。Agent 然后可以带着这个压缩 context 加最近访问的五个文件继续。用户得到连续性而不用担心 context window 限制。
Compaction 的艺术在于选择保留什么、丢弃什么——过于激进的 compaction 可能导致丢失微妙但关键的 context，其重要性只在后来才显现。对于实现 compaction 系统的工程师，我们建议在复杂的 agent trace 上仔细调你的 prompt。先最大化 recall 确保你的 compaction prompt 从 trace 中捕获每一条相关信息，然后迭代提升 precision——消除多余内容。
一个容易摘除的多余内容例子是清理工具调用和结果——一个工具在消息历史深处被调用过之后，agent 为什么还需要再看原始结果？最安全、最轻量的 compaction 形式之一是工具结果清理，最近作为 Claude Developer Platform 的一个功能上线了。
结构化笔记
结构化笔记，或称 agentic memory，是一种技术：agent 定期写笔记持久化到 context window 之外的内存。这些笔记在稍后被拉回 context window。
这个策略以最小开销提供持久记忆。像 Claude Code 创建 to-do list，或你的自定义 agent 维护一个 NOTES.md 文件——这个简单模式让 agent 能在复杂任务间跟踪进度，维护关键 context 和依赖关系，否则这些会在几十次工具调用中丢失。
Claude plays Pokémon 展示了记忆如何在非编码领域变革 agent 能力。Agent 在数千个游戏步骤间保持精确计数——跟踪目标如「过去 1,234 步我一直在 Route 1 训练 Pokémon，Pikachu 在目标 10 级中升了 8 级。」没有任何关于记忆结构的 prompt，它发展出已探索区域的地图，记住解锁了哪些关键成就，并维护战斗策略笔记帮助它学习哪些攻击对不同对手最有效。
context 重置后，agent 读自己的笔记并继续数小时的训练序列或地下城探索。这种跨总结步骤的连贯性使长程策略成为可能——如果只把所有信息放在 LLM 的 context window 里，这些策略是不可能的。
作为 Sonnet 4.5 发布的一部分，我们在 Claude Developer Platform 上以公开 beta 发布了一个 memory tool，通过一个基于文件的系统让 agent 更容易在 context window 之外存储和查阅信息。这让 agent 能随时间积累知识库、跨 session 维护项目状态、引用之前的工作而不必把一切放在 context 里。
Sub-agent 架构
Sub-agent 架构提供了另一种绕过 context 限制的方式。不是一个 agent 试图在整个项目上维护状态，专门的 sub-agent 可以用干净的 context window 处理聚焦任务。主 agent 用高层计划协调，subagent 做深度技术工作或用工具找相关信息。每个 subagent 可能大量探索——用掉数万 token 或更多——但只返回其工作的浓缩、蒸馏摘要（通常 1,000-2,000 token）。
这种方式实现了清晰的关注分离——详细搜索 context 隔离在 sub-agent 内部，主 agent 专注于综合和分析结果。这种模式在 How we built our multi-agent research system 中讨论过，在复杂研究任务上相比单 agent 系统有显著改善。
这些方法之间的选择取决于任务特征。例如：
- Compaction 为需要大量来回的任务维护对话流；
- 笔记在有清晰里程碑的迭代开发中出色；
- Multi-agent 架构处理并行探索有回报的复杂研究和分析。
即使模型继续改进，在扩展交互间保持连贯性的挑战仍将是构建更有效 agent 的核心。
结语
Context engineering 代表了我们用 LLM 做构建的方式的根本转变。随着模型变强，挑战不只是写出完美的 prompt——而是深思熟虑地策划每步进入模型有限注意力预算的信息。无论你是在为长程任务实现 compaction、设计 token 高效的工具，还是让 agent just-in-time 探索环境，指导原则不变：找到最小的高信号 token 集，使期望结果的可能性最大化。
我们概述的技术会随模型改进继续演变。我们已经看到更聪明的模型需要更少规定性工程，让 agent 能以更多自主性运作。但即使能力扩展，把 context 当作珍贵的有限资源对待仍将是构建可靠、有效 agent 的核心。
今天就上 Claude Developer Platform 开始 context engineering，通过我们的 memory and context management cookbook 获取有用的提示和最佳实践。
致谢
由 Anthropic Applied AI 团队撰写：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan 和 Jeremy Hadfield，团队成员 Rafi Ayub、Hannah Moran、Cal Rueb 和 Connor Jennings 贡献。特别感谢 Molly Vorwerck、Stuart Ritchie 和 Maggie Vo 的支持。