今年6月，Andrej Karpathy 带火了一个词——上下文工程。
他支持用“上下文工程”（context engineering）取代“提示词工程”（prompt engineering）。而就在 Claude Sonnet 4.5 推出后的第二天，Anthropic 发布了一篇工程博客《AI 智能体的高效上下文设计》，呼应了 Karpathy 的观点：在每个工业级 LLM 应用中，真正关键的是“上下文工程”。
博客原文地址：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-Agents
Anthropic 明确指出：
构建 AI 应用的重心，已经从寻找合适的提示词，转向一个更根本的问题：怎样的上下文配置最有可能引导模型做出我们想要的行为？
接下来，带大家阅读整篇博客。
Anthropic理解的，上下文工程和提示词工程的区别
而工程问题在于如何在 LLM 固有的约束条件下优化这些 token 的效用，以持续实现期望的结果。有效驾驭 LLM 通常需要具备“上下文思维”。
换句话说：全面考虑 LLM 在任一时刻所能访问的整体状态，并预判该状态可能引发的行为。
Anthropic 认为，上下文工程是提示词工程的自然演进。
提示词工程专注于为获得最佳结果而编写和组织 LLM 指令的方法。而上下文工程指的是在 LLM 推理过程中策划和维护最优 token 集合（信息）的一系列策略，包括提示词之外可能出现的所有其他信息。
在 AI 工程的刚开始，提示词设计曾是 AI 工程的核心工作，因为绝大多数非日常聊天场景的应用都需要针对单次分类或文本生成任务进行优化的提示词。
就像它的名字那样，提示词工程主要关注如何编写高效的提示词，尤其是系统提示词。
然而，随着我们逐步构建能够在多轮推理和更长时间跨度内运作的更强大智能体，我们需要制定策略来全面管理上下文状态，包括系统指令、工具、模型上下文协议（MCP）、外部数据以及消息历史等。
在循环中运行的智能体会生成越来越多可能与下一轮推理相关的数据，这些信息需要持续地进行筛选和提炼。上下文工程正是一门从这一动态演变的信息海洋中，精准选取适合的信息放入有限的上下文窗口内容的艺术。
为何上下文工程如此重要
随着上下文长度增加，模型捕捉这些成对关系的能力会被稀释，也就是说在上下文长度与注意力集中之间会形成一种天然的权衡。此外，模型的注意力模式源自于训练数据中的分布：短文本和中等长度的文本远比特别长的文本更常见。这意味着模型对于全局上下文依赖关系（记住很久之前的文本并在后面用上）的经验较少，相关的专用参数也不足。
像位置编码插值这样的技术，能让模型通过扩展最初训练时较短的上下文来处理更长的序列，但会对标记位置的理解造成一定程度的下降。
这些因素导致模型性能呈现渐进式下降而非突然断崖式下跌：虽然在处理长上下文时模型依然具备较强能力，但在信息检索和长距离推理方面的准确度会略低于处理短上下文时的表现。
正因为这些问题，精心设计的上下文工程对于构建强大的智能体而言，至关重要。
高效上下文的结构
一端是采用硬编码 if-else 的提示，另一端则是过于笼统或错误的提示。我们建议将提示词分成若干清晰的部分（如<background_information>、<instructions>、## Tool guidance、## Output description等），并采用 XML 标签或 Markdown 标题等方式进行区分。不过，随着模型能力不断增强，提示词的具体格式可能逐渐变得不那么重要。
无论你决定如何构建系统提示，你都应该努力寻找完全概述预期行为的最小信息集。（注意，最小并不一定意味着短；你仍然需要预先为智能体提供足够的信息，以确保它遵守期望的行为。）
最好从使用可用的最佳模型测试最小提示开始，看看它在你的任务上的表现如何，然后根据初始测试中发现的失败模式添加清晰的指令和示例来提高性能。
工具允许智能体与其环境交互并在工作时引入新的额外上下文。因为工具定义了智能体与其信息/动作空间之间的契约，所以工具促进效率非常重要，既要返回 token 高效的信息，又要鼓励高效的智能体行为。
在《为 AI 智能体编写工具——用 AI 智能体》中，我们讨论了构建 LLM 能够很好理解且功能重叠最小的工具。与设计良好的代码库的函数类似，工具应该是自包含的、对错误具有鲁棒性，并且在其预期用途方面极其清晰。输入参数同样应该具有描述性、明确性，并发挥模型的固有优势。
我们看到的最常见失败模式之一是工具集过于庞杂，涵盖的功能太多，或者在选择使用哪个工具时难以决策。如果连人类工程师都不能明确说出在给定情况下应该使用哪个工具，就不能期望 AI 智能体能够做得更好。
就像我们稍后将讨论的，为智能体策划一个最小可行的工具集也可以导致在长时间交互中更可靠的维护和修剪上下文。
提供示例，也称为少样本提示，是我们继续强烈建议的众所周知的最佳实践。然而，团队通常会在提示中塞入一长串边缘案例，试图阐明 LLM 应该为特定任务遵循的每个可能规则。我们不建议这样做。相反，我们建议努力策划一组多样化的、规范的示例，有效地描绘智能体的预期行为。
我们对上下文的不同组成部分（系统提示、工具、示例、消息历史等），我们的总体建议是：要深思熟虑，确保信息充分的同时保持简洁。现在让我们深入探讨在运行时动态检索上下文。
上下文检索和智能体搜索
在《构建有效的 AI 智能体》一文中，我们强调了基于 LLM 的工作流程与智能体之间的区别。自从我们写了那篇文章以来，我们倾向于一个简单的智能体定义：LLM 在循环中自主使用工具。
如今，我们看到工程师思考为智能体设计上下文的方式发生了转变。
许多 AI 原生应用程序已开始采用基于嵌入的推理前检索技术，以便为智能体推理提供重要上下文。随着行业逐步转向更加强调自主性的智能体架构，我们看到越来越多的团队用“即时”上下文策略来增强现有检索系统的能力。
与预先处理所有相关数据不同，使用“即时”方法构建的智能体会保留轻量级标识符（文件路径、存储的查询、网络链接等），并在运行时通过工具动态调用这些引用，将所需数据实时加载至上下文。Anthropic 的智能体编码解决方案 Claude Code 正是采用这种方法，从而能够在大型数据库上进行复杂的数据分析。
模型可以编写有针对性的查询、存储结果，并利用像 head 和 tail 这样的 Bash 命令来分析大量数据，而无需将完整的数据对象加载到上下文中。这种做法模拟了人类的认知模式：我们通常不会死记硬背所有信息，而是借助文件系统、收件箱、书签等外部组织和索引系统，在需要时按需获取相关内容。
除了存储效率之外，这些引用的元数据还能有效引导行为的优化，无论是显式提供的信息还是基于直觉的判断。对一个在文件系统中运行的智能体来说，tests 文件夹中名为 test_utils.py 的文件的存在意味着与位于 src/core_logic.py 中的同名文件不同的用途。文件夹层次结构、命名约定和时间戳都提供了重要的信号，帮助人类和智能体理解如何以及何时利用信息。
让智能体自主导航和检索数据也实现了渐进式披露——换句话说，允许智能体通过探索逐步发现相关上下文。每次交互都会产生为下一个决策提供信息的上下文：文件大小暗示复杂性；命名约定暗示目的；时间戳则可作为判断信息相关性的重要依据。
智能体可以逐层积累理解，只在工作记忆中保留必要的内容，并借助笔记等方式进行长期记录。这种自我管理的上下文机制，使智能体能聚焦于关键的信息片段，避免陷入大量冗余或无关的信息之中。
当然，这里有一个权衡：运行时探索比检索预计算数据慢。
不仅如此，还需精心的工程设计并融入明确的工程判断，来确保 LLM 具有正确的工具和启发式方法，从而高效地在它的信息环境中导航。如果没有适当的指导，智能体可能会误用工具、追逐死胡同或未能识别关键信息，导致浪费上下文。
混合策略可能更适合动态内容较少的上下文，例如法律或金融工作。随着模型能力的提高，智能体的设计趋势将是让模型更自主地发挥智能，逐渐减少人类策划。鉴于该领域的发展太多迅速，“做最简单有效的事情”可能仍然是我们为在 Claude 之上构建智能体的团队提供的最佳建议。
针对长期任务的上下文工程
对于需要长时间连续操作的任务，例如大型代码库迁移或综合性的研究项目，智能体必须在动作序列中保持连贯性、上下文关联性和目标导向性，而这些序列的 token 数量往往会超出 LLM 的上下文窗口限制。所以说，智能体需要专门的技术来绕过上下文窗口大小限制。
等待更大的上下文窗口似乎是个简单直接的策略。
但在可预见的未来，所有大小的上下文窗口都可能受到上下文污染和信息相关性问题的影响——至少在需要最强智能体性能的情况下。为了使智能体能在更长时间跨度上有效工作，我们开发了一些直接解决这些上下文污染问题的技术：压缩、结构化笔记和多智能体架构。
压缩
压缩是将接近上下文窗口限制的对话进行总结，并用摘要重新启动新的上下文窗口的做法。压缩通常是上下文工程中最先使用的手段，来推动更好的长期连贯性。从本质上讲，压缩以高保真方式提炼上下文窗口的内容，使智能体能够在性能几乎不受影响的情况下持续运行。
例如，在 Claude Code 中，我们通过将消息历史传递给模型进行总结和压缩最关键的细节来实现这一点。模型保留架构决策、未解决的错误和实现细节，同时丢弃冗余的工具输出或消息。然后智能体可以继续使用这个压缩的上下文加上五个最近访问的文件。用户获得连续性，而无需担心上下文窗口限制。
压缩的艺术在于选择保留什么与丢弃什么，因为过于激进的压缩可能导致微妙但关键的上下文丢失，其重要性只有在以后才变得明显。对于实现压缩系统的工程师，我们建议在复杂的智能体轨迹上仔细调整你的提示。首先最大化召回率以确保你的压缩提示从轨迹中捕获每一条相关信息，然后通过消除多余内容来迭代提高精度。
一种容易处理冗余内容的方式是清理工具调用及其结果：一旦工具在消息历史深处被调用，为什么智能体需要再次看到原始结果？清除工具结果是一种既安全又轻量的压缩方式，该功能最近已作为 Claude 开发者平台的新特性正式上线。
结构化笔记
结构化笔记，也称为智能体记忆，是指智能体定期将信息以笔记形式记录下来，并持久地存储在上下文窗口之外的内存中，以便后续重新载入上下文窗口使用。
这种策略以最小的开销提供持久记忆。就像 Claude Code 创建待办事项列表，或你的自定义智能体维护 NOTES.md 文件一样，这种简单的模式允许智能体跨越复杂任务跟踪进度，维护关键上下文和依赖关系，否则这些将在数十个工具调用中丢失。
Claude 玩宝可梦展示了记忆如何在非编程领域显著提升智能体的能力。
作为我们 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上以公开测试版发布了一个记忆工具。该工具采用基于文件的系统，可更便捷地在上下文窗口之外存储和调用信息。这使得智能体能够逐步构建知识库，跨会话保持项目状态，并能随时参考过往工作内容，而无需将所有信息都保留在当前上下文中。
子智能体架构
子智能体架构提供了另一种绕过上下文限制的方法。与其依赖单一智能体在整个项目过程中维持状态，不如采用专业化的子智能体来负责具体任务，并各自拥有独立清晰的上下文空间。主智能负责统筹协调，制定高层计划，而子智能体则专注于执行深入的技术任务，或调用工具获取相关信息。每个子智能体可以在本地进行大量探索，使用数万个 token 或更多，但最终仅向主智能体返回精炼后的成果摘要（通常为 1,000-2,000 个 token）。
这种方法实现了清晰的关注点分离——详细的搜索上下文在子智能体中保持隔离，而主智能体专注于综合和分析结果。正如《我们如何构建多智能体研究系统》一文中所述，这一模式在应对复杂研究任务时，相比单智能体系统表现出显著的提升。
压缩技术有助于在需要频繁交互的任务中保持对话的连贯性； 笔记在具有明确里程碑的迭代开发中表现出色； 多智能体架构适用于那些通过并行探索能显著提升效率的复杂研究与分析场景。
即使现在模型的性能在持续提升，但在较长的交互过程中保持一致性仍将是构建更有效智能体的关键挑战。
结论
上下文工程代表了我们如何使用 LLM 构建的根本转变。随着模型变得更强大，挑战不仅仅是制作完美的提示——而是深思熟虑地策划在每一步进入模型有限注意力预算的信息。无论你是为长时间跨度任务实现压缩，设计 token 高效的工具，还是使智能体能够即时探索其环境，指导原则都保持不变：找到最小的高信号 token 集，最大化你期望结果的可能性。
