原作者：Anthropic应用人工智能团队 发布时间：2025年9月29日
本文是学习Anthropic文章《Effective context engineering for AI agents》的理解笔记。
1、什么是上下文工程（Context Engineering）？
上下文（Context）指的是从大型语言模型（LLM）中进行采样时所包含的一组标记（Tokens）。 上下文工程要解决的问题是，在大型语言模型固有的约束条件下，如何筛选和维护构成上下文的Tokens集合，以持续实现预期结果。
2、上下文工程与提示词工程的关系
Anthropic将上下文工程（Context Engineering） 视为提示词工程（Prompt Engineering）的自然演进。其中，提示词工程指的是为实现最优结果而编写和组织大语言模型（LLM）指令的方法；而上下文工程则是指在大语言模型推理过程中，筛选并维护最优标记（token，即信息）集合的一系列策略，这些标记不仅包括提示词本身，还涵盖了可能进入模型上下文的所有其他信息。
在利用大语言模型开展工程开发的早期阶段，提示词设计是人工智能工程工作的核心环节。因为除日常对话交互外，绝大多数应用场景都需要针对 "一次性分类" 或 "文本生成" 这类任务优化提示词。正如其术语字面含义所示，提示词工程的核心关注点在于如何编写高效的提示词，尤其是系统提示词（System Prompt）。
然而，随着我们逐步向 "开发更强大的智能体（Agent）" 迈进 ------ 这类智能体需支持多轮推理，且能在更长时间维度内运行 ------ 我们亟需一套策略来管理整个上下文状态，其中包括系统指令、工具、模型上下文协议（MCP）、外部数据、消息历史等。
一个循环运行的智能体，会不断生成可能与下一轮推理相关的数据，而这些信息必须经过周期性优化。从这个持续演化的潜在信息库中，筛选出可纳入有限上下文窗口的内容。这正是上下文工程科学与艺术所在。
3、为什么上下文工程至关重要？
1）上下文腐烂（Context Rot） 由于大模型的Transformer 架构，使得"上下文规模" 与 "注意力集中度" 之间存在天然的矛盾。 随着上下文窗口中标记（token）数量的增加，大模型从该上下文中准确召回信息的能力会随之下降。
2）模型的注意力模式是从训练数据分布中学习而来的，而在训练数据中，短序列通常比长序列更为常见。这就导致模型对 "全上下文依赖关系" 的处理经验更少，也缺乏专门应对此类关系的参数。
因此，要构建高性能智能体，精心设计的上下文工程至关重要。
4、上下文工程的构成要素
系统提示词、工具、少样本示例、上下文检索、记忆管理
1）系统提示词 核心原则：清晰直白的语言描述，两个策略：恰当粒度、模块化
- 恰当粒度：避免两个极端。
在一个极端场景中，我们发现有些工程师会在提示词中硬编码复杂且脆弱的逻辑，以触发智能体的特定行为。这种方式会导致系统稳定性差，且随着时间推移，维护复杂度会不断增加。 在另一个极端场景中，工程师有时会提供模糊、宏观的指导 ------ 这类指导既无法为大型语言模型提供关于 "预期输出" 的具体信号，也错误地假定了（模型与人类之间存在）共享上下文。 而最优粒度需要实现一种平衡：既要足够具体，能有效引导行为；又要具备足够灵活性，为模型提供强有力的启发式规则以指导其行动。
- 模块化
建议将提示词划分为不同的板块（例如 【背景信息】、【指令】、## Tool guidance【工具使用说明】、## Output description【输出说明】等），并采用 XML 标签或 Markdown 标题等方式划分这些板块。
无论你选择以何种方式构建系统提示词，核心目标都应是提炼出 "能完整界定预期行为的最小信息集"。（注："最小" 并不等同于 "简短"；为确保智能体遵循预期行为，你仍需提前为其提供足够的信息。）最佳实践是：先使用当前性能最优的模型，对一份精简的提示词进行测试，观察其在你的任务中的表现；随后，根据初始测试中发现的失效场景，补充明确的指令和示例，以提升模型性能。
2）工具
- 提升工具效率
工具能让智能体与所处环境交互，并在工作过程中引入新的额外上下文。因此，既要确保返回的信息符合 "Tokens高效性"（即用更少Tokens传递关键信息），又要引导智能体产生高效行为。
- 功能独立无歧义
工具应具备 "功能独立完整""抗错误能力强""用途明确无歧义" 的特点。 工具的输入参数也应遵循相同原则：描述清晰、含义明确，并能充分发挥模型的固有优势。
3）少样本示例
推荐筛选出 "类型多样、具有代表性的示例集"，通过这些示例精准传递智能体的预期行为。
4）上下文检索
- 即时上下文策略
"即时" 方案构建的智能体不会预先处理所有相关数据，而是保留轻量化标识符（如文件路径、存储的查询语句、网页链接等），并借助这些引用，在运行时通过工具将数据动态加载到上下文中。
- 混合策略
预先检索部分数据以保证速度，同时自主决定是否进行进一步的自主探索。
5）记忆管理
长期任务要求智能体在 "标记（token）数量超出大语言模型（LLM）上下文窗口" 的动作序列中，始终保持行为的连贯性、上下文的一致性以及目标导向性。对于需持续数十分钟至数小时完成的任务（例如大型代码库迁移、综合性研究项目），智能体需要借助专门技术来规避上下文窗口大小的限制。
为让智能体在长时间跨度内高效工作，Anthropic开发了几种可直接应对 "上下文污染" 约束的技术：压缩（compaction）、结构化笔记（structured note-taking）与多智能体架构（multi-agent architectures）。
- 压缩技术
压缩技术（Compaction）指的是：当对话内容即将达到上下文窗口上限时，对其内容进行总结，并以该总结重新启动一个新上下文窗口的操作。在上下文工程中，压缩技术通常是提升长期任务连贯性的首要手段。其核心作用是，以高保真度提炼当前上下文窗口的内容，让智能体能够继续运行，且性能下降程度最小。 压缩技术的关键之处，在于判断 "哪些内容需保留、哪些需剔除"。如果压缩时过度 "激进"，可能会丢失那些看似细微、但实则关键的上下文 ------ 这类信息的重要性往往要到后续环节才会显现。对于开发压缩系统的工程师，建议：在复杂的智能体交互轨迹（agent traces）上，仔细调试压缩提示词。首先应最大限度保证 "召回率"（recall），确保压缩提示词能捕捉到交互轨迹中所有相关信息；之后再逐步优化 "精准度"（precision），剔除多余内容。
- 结构化笔记
结构化笔记是指智能体定期将笔记写入上下文窗口之外的持久化存储区域，并在后续需要时将这些笔记重新调入上下文窗口的技术。 该策略能以极低的开销实现持久化记忆。正如 Claude Code 会创建待办事项列表（to-do list），或自定义智能体会维护NOTES.md文件一样，这种简洁的模式可帮助智能体跟踪复杂任务的进展，留存关键上下文与依赖关系 ------ 若不采用此方式，这些信息可能会在数十次工具调用后丢失。
- 多智能体架构
多智能体架构为突破上下文限制提供了另一种思路。该架构并非让单个智能体维护整个项目的状态，而是由专门的子智能体负责特定任务 ------ 每个子智能体都拥有独立且简洁的上下文窗口。主智能体（main agent）依据宏观规划进行协调，子智能体则专注执行深度技术工作，或通过工具获取相关信息。每个子智能体可能会进行大量探索（过程中可能消耗数万个标记），但最终仅向主智能体返回一份精简的工作总结（通常为 1000-2000 个标记）。这种方法实现了清晰的 "关注点分离"：详细的搜索上下文仅保留在子智能体内，主智能体则专注于综合与分析结果。这种模式在复杂的研究任务中表现显著优于单智能体系统。
选择何种方法需根据任务特性决定：
- 压缩技术（Compaction）适用于需大量双向交互的任务，可维持对话连贯性；
- 笔记技术（Note-taking）在有明确里程碑的迭代开发任务中表现突出；
- 多智能体架构（Multi-agent Architectures）则适合复杂研究与分析任务
5、总结
上下文工程标志着我们利用大语言模型进行开发的方式发生了根本性转变。随着模型能力不断提升，核心挑战已不再仅仅是设计完美的提示词 ------ 而是要审慎筛选每一步进入模型有限注意力预算的信息。 无论上下文中何种要素的构建，核心指导原则始终不变：找到规模最小的高信号Tokens集合，以最大限度提升达成预期结果的可能性。