AI Agent 的有效 Context Engineering
发布日期： 2025年9月29日 作者： Anthropic 应用 AI 团队：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan 和 Jeremy Hadfield，Rafi Ayub、Hannah Moran、Cal Rueb 和 Connor Jennings 参与贡献。特别感谢 Molly Vorwerck、Stuart Ritchie 和 Maggie Vo。
摘要与核心内容
文章提出 Context Engineering 是构建 AI Agent 时代超越 Prompt Engineering 的演进方向。Context Engineering 被定义为：在 LLM 约束下优化 Token 的效用，以持续达成预期结果。作者强调"用 Context 思考"——考虑在任何给定时间 LLM 可用的整体状态。
Context Engineering 与 Prompt Engineering
Prompt Engineering 聚焦于编写和组织指令，主要是系统提示。Context Engineering 更为广泛，涵盖了在推理过程中策划和维护最优 Token 集合的策略——包括系统指令、工具、MCP、外部数据、消息历史等。作者将其描述为从不断变化的可能信息宇宙中筛选进入有限 Context Window 的内容的"艺术与科学"。
为什么 Context Engineering 很重要
LLM 会经历 Context 衰减——随着 Token 数量增加，模型准确回忆信息的能力下降。文章将其与人类"有限的工作记忆容量"进行类比，描述了 LLM 的"注意力预算"。这源于 Transformer 架构的约束——每个 Token 都要关注其他所有 Token，形成 n^2 的成对关系。模型在较长序列上的训练经验也较少。位置编码插值有助于处理较长序列，但会有一些退化。
指导原则是：找到最小的高信号 Token 集合，最大化预期结果的可能性。
有效 Context 的解剖结构
系统提示应使用简洁、直接的语言，处于"正确的高度"——介于两种失败模式之间的黄金地带：
- 硬编码复杂、脆弱的逻辑，导致脆弱性
- 提供模糊、高层级的指导，无法给出具体信号
建议包括使用 XML 标签或 Markdown 标题将提示组织成不同的部分，并力求用最少的信息完整勾勒出预期行为。从使用最佳模型的最小提示开始，然后根据观察到的失败模式添加指令。
工具应通过返回 Token 高效的信息和鼓励高效的 Agent 行为来提升效率。工具应自包含、对错误鲁棒、且用途极其清晰。一个常见的失败模式是"臃肿的工具集"，存在模糊的决策点。文章指出："如果人类工程师都无法明确判断在给定情况下应该使用哪个工具，就不能期望 AI Agent 做得更好。"
**示例（Few-shot Prompting）**被强烈建议，但文章警告不要在提示中塞满边界情况。相反，团队应策划"多样化、典型的示例"来有效展示预期行为。对于 LLM，示例被描述为"胜过千言万语的'图片'"。
Context 检索与 Agent 搜索
文章引用了一个简单的 Agent 定义："LLM 在循环中自主使用工具。"
该领域正在向**"即时"Context 策略**转变——Agent 不再预先处理所有相关数据，而是维护轻量级标识符（文件路径、存储查询、网页链接），并在运行时使用工具动态加载数据。Claude Code 在大型数据库的复杂数据分析中使用了这种方法——模型编写有针对性的查询、存储结果，并使用 Bash 命令分析数据，而无需将完整数据对象加载到 Context 中。
这映射了人类认知——我们使用"外部组织和索引系统，如文件系统、收件箱和书签"来按需检索相关信息。
渐进式信息披露允许 Agent 通过探索逐步发现相关上下文。来自引用的元数据提供信号——文件夹层次结构、命名约定、时间戳帮助人类和 Agent 理解如何以及何时利用信息。
权衡在于：运行时探索比预计算检索更慢，且需要适当的工程设计来确保 Agent 拥有正确的工具和启发式方法。
混合策略可能最为有效——预先检索一些数据以获得速度，同时进行进一步的自主探索。Claude Code 采用了这种模型——CLAUDE.md 文件预先放入 Context，而 glob 和 grep 等原语允许即时导航。
文章指出，"做最简单的有效方案"可能仍然是构建 Agent 团队的最佳建议。
长周期任务的 Context Engineering
对于跨越数十分钟到数小时的任务，讨论了三种技术：
**压缩（Compaction）**涉及在对话接近 Context Window 限制时进行总结，并用总结重新开始。在 Claude Code 中，消息历史传递给模型进行总结和压缩关键细节。Agent 保留架构决策、未解决的 Bug 和实现细节，同时丢弃冗余输出。文章警告"过于激进的压缩可能导致微妙但关键的上下文丢失"。建议方法：先最大化召回率，然后迭代提高精确率。工具结果清除被描述为最安全、最轻量的压缩形式之一。
**结构化笔记（Agent 记忆）**涉及 Agent 定期将笔记写入 Context Window 外的持久化存储，稍后再拉回。文章以 Claude 玩 Pokemon 为例，Agent"在数千个游戏步骤中维持精确的计数"，并绘制地图、记住成就、维护战斗策略笔记。在 Context 重置后，Agent 读取自己的笔记并继续多小时的序列。
子 Agent 架构使用专门的子 Agent 处理聚焦的任务，拥有干净的 Context Window。每个子 Agent 可能会广泛探索，但只返回"精炼的摘要"（通常 1,000-2,000 Token）。这实现了关注点分离，在复杂研究任务上"相比单 Agent 系统有显著改进"。
选择取决于任务特性：
- 压缩适合需要大量来回交互的任务，维持对话流程
- 笔记适合有明确里程碑的迭代开发
- 多 Agent 架构适合并行探索能带来收益的复杂研究和分析
结论
Context Engineering 代表了一种根本性转变——挑战在于"在每一步精心策划什么信息进入模型有限的注意力预算"。指导原则是：找到最小的高信号 Token 集合来最大化预期结果。随着模型的改进，更智能的模型需要的规范性工程更少，但"将 Context 视为宝贵的有限资源，始终是构建可靠、高效 Agent 的核心"。