【Anthropic】Context Engineering 框架：从原则到工具维度实践
在有限 token 预算下，通过 context engineering 设计原则和工具使用高级特性，系统性地优化 AI agent 的上下文配置
- 从 Prompt Engineering 到 Context Engineering
- Context Engineering 的核心原则
- 工具维度的高级实践：三项特性
- 分层策略与实施
- 长时任务的整体策略
- 核心
- 评价
原文 A：Effective Context Engineering for AI Agents 原文 B：Introducing Advanced Tool Use on Claude Developer Platform
从 Prompt Engineering 到 Context Engineering
传统的 prompt engineering（prompt 工程）关注单个提示词的编写。但随着 AI agent（人工智能代理）从单轮对话演进到多轮任务执行，问题的焦点发生了根本性变化——不是「如何写一个好的提示词」，而是「在整个推理过程中，什么配置的上下文最有可能产生我们想要的行为」。
Context engineering（上下文工程）是一个更宽泛的概念——在 LLM（大语言模型）推理阶段，精心策划和维护最优的 token 集合。这个集合涵盖系统指令、工具定义、外部数据、对话历史等所有成分。而在构建大规模 agent 系统时，工具定义本身往往成为最大的 token 消耗源——传统「一次性加载所有工具」的模式下，工具定义可能在处理实际请求之前就已吃掉 55,000+ token。
Context Rot：被稀释的注意力预算
Transformer 架构的每个 token 对都维持 n² 的两两关系（pairwise attention）。这意味着随着上下文长度增加，模型经历所谓「context rot（context 腐化）」——准确度下降。内部测试中，这个现象表现为信息检索精度在长上下文中显著衰减。
简单讲，每多一个 token，就在用掉有限的「注意力预算」（attention budget）。当上下文变长时，这个预算被拉扯得越来越薄，模型在关键信息上的专注力随之衰减。低质量的 token 不只是浪费空间，它还在稀释高质量信息的权重。
Transformer 设计造成了「context size 和 attention focus 之间的自然张力」——模型在训练中接触的长序列数据有限，导致它「在处理 context-wide 依赖时经验不足」。这是技术架构带来的硬性约束，不是通过提示技巧能绕过的。
Context Engineering 的核心原则
找到最小的、高信号密度的 token 组合，使其最大化目标行为的可能性。
这个原则跨越以下几个维度：
系统提示设计
系统提示不应该是「僵硬到处这是规则」也不应该是「模糊到只有启发式建议」。要在具体性和灵活性之间找平衡——即所谓「Goldilocks zone」（恰到好处区域）：
- 用清晰的结构（XML 标签或 Markdown 分节）组织指令
- 明确 agent 的目标和约束
- 提供足够的上下文让 agent 自主决策，而不是规定每一步的操作细节
目标是用「最小的信息集合完整勾勒期望行为」，既要避免过度约束导致灵活性丧失，也要防止信息不足导致行为不可预测。
样例选择策略
不要堆砌所有边界情况，而要选择多样、规范的样例：
- 覆盖关键的路径和决策点
- 样例之间差异大，让 agent 学到泛化模式
- 丢掉那些冗余或过度特化的边界情况
对语言模型而言，「examples are pictures worth a thousand words」（一张示例图胜过千言万语）。精心挑选的远比塞入大量样例更有价值——冗余样例不仅不增加信息，还占用宝贵的上下文空间。
即时上下文检索
避免预加载所有相关数据，应该让 agent 采用「just-in-time（刚好及时）」的上下文策略。Agent 维护轻量级标识符，在运行时动态通过工具加载数据到上下文。
这种方法反映人类认知——我们不会「memorize entire corpus of information」（记忆整个信息语料库），而是建立外部组织和索引系统，按需访问。文件层级、命名约定、时间戳都提供有价值信号，帮助 agent 理解信息的关联性。
混合策略通常效果最佳：某些数据预先检索，agent 然后用 glob 和 grep 等工具自主探索额外信息。
工具维度的高级实践：三项特性
在 context engineering 框架下，工具配置是最容易被忽视但最值得优化的维度。Anthropic 针对工具使用的瓶颈发布了三项测试版特性，都指向同一个目标——用结构化手段削弱工具定义的 token 代价。
三特性解决三个相互独立的根本问题：工具定义爆炸、推理碎片化、理解歧义。
特性一：工具搜索（Tool Search）——解决定义爆炸
允许 Claude 动态发现工具，而非一次加载全部定义。通过标记 defer_loading: true，该工具在 agent 真正需要时才被加载，而不是在启动时就塞入上下文。
性能收益：
- Token 消耗减少 85%：从约 77,000 token 下降到约 8,700 token
- 准确率显著提升：Opus 4.5 在知识检索任务中从 79.5% 提升到 88.1%，Opus 4 则从 49% 提升到 74%
- 与缓存兼容：可与 prompt caching 配合使用，进一步提升成本效率
本质上，工具搜索是把 lazy loading（惰性加载）思想从软件工程搬到了 LLM 推理中。当工具数量众多时，这个特性尤其关键——Anthropic 内部测试曾经记录到 131,000 token 的定义开销。
何时启用：
- 工具定义消耗超过 10,000 token
- 工具选择准确率存在问题
- 构建基于 MCP（Model Context Protocol）的多服务器系统
- 可用工具数量在 10 个以上
特性二：编程工具调用（Programmatic Tool Calling）——解决推理碎片化
传统工具使用需要多轮 API 调用，中间结果会进入 Claude 的上下文窗口，造成大量「context pollution from intermediate results」（中间结果的污染）。此特性让 Claude 通过代码编排多个工具，处理输出并控制哪些信息进入自己的上下文窗口。
工作机制：Agent 在执行环境中直接协调多个工具调用，控制流程和条件分支，类似于编写脚本。这样复杂的协调逻辑保留在确定性的执行环境中，模型只需专注于决策和高层控制。
性能收益：
- Token 消耗减少 37%：在复杂研究任务中从 43,588 降至 27,297 token
- 减少多轮推理开销：消除 19+ 次 inference passes（推理轮次），对于多步骤工作流至关重要
- 准确率改进：知识检索准确率从 25.6% 提升到 28.5%，GIA 基准测试从 46.5% 提升到 51.2%
- 支持并行执行：多个工具可并行调用，而非顺序执行
典型场景：预算合规性检查需要处理数千条支出项。传统方法会将所有行项塞入上下文，导致推理变差、调用频繁；编程调用则将逻辑留在执行环境中（使用 asyncio.gather() 并行获取），模型只关注决策和控制，最终返回仅 1KB 的结果——只有 2-3 个超预算的人员。
何时启用：
- 处理大型数据集且只需要聚合或摘要结果
- 多步骤工作流包含三个或以上依赖的工具调用
- 在 Claude 看到结果前需要过滤、排序、转换工具输出
- 跨多个项目运行并行操作
特性三：工具使用示例（Tool Use Examples）——解决理解歧义
超越 JSON Schema 定义，提供 input_examples 数组，包含具体的使用样板。这帮助模型理解格式约定、参数关联关系、可选字段的包含方式和实际调用模式。
示例场景：对于支持工单 API，示例可以展示：
- 格式约定：日期使用 YYYY-MM-DD 格式
- ID 约定：用户 ID 遵循 USR-XXXXX 模式
- 嵌套结构模式：如何构造 reporter 对象
- 可选参数关联：严重 Bug 需要完整联系信息加上快速升级和紧缩 SLA
性能收益：
- 准确率从 72% 提升到 90%：在复杂参数处理的内部测试中
这看似简单的优化，能显著减少模型「guessing cost」（猜测成本），特别是在字段组合和边界情况处理上。JSON Schema 只定义了什么在结构上是有效的，不能表达实际使用模式。
何时启用：
- 复杂的嵌套结构
- 工具有大量可选参数
- API 有领域特定的约定传统
- 多个相似工具，示例可以阐明该使用哪一个
分层策略与实施
三项特性的最佳使用方式是诊断后分层应用，而非盲目全量启用：
- 诊断性能瓶颈（是 token 消耗、推理轮数还是格式理解）
- 针对最严重的瓶颈优先应用特性（例如工具众多则先用工具搜索）
- 根据需要补充其他特性
对于工具多、任务复杂、格式复杂的真实 agent 场景，往往需要三个特性同时发力。这反映了对工程现实的理解——不同 agent 的主要瓶颈不同，优化错误的维度可能比不优化还糟。
针对每项特性的最佳实践：
- 工具搜索：使用清晰、描述性强的工具名称和描述，保留 3-5 个最常用工具始终加载，其余延迟加载，并在系统提示中添加关于可用工具的引导
- 编程调用：清晰记录返回格式以便 Claude 编写正确的解析逻辑，opt-in（主动选择）那些能从编程编排中受益的工具，特别是那些可以并行运行或幂等的工具
- 使用示例：使用真实数据（真实城市名称、合理价格），展示多样性（最小、部分、完整规范模式），每个工具保持 1-5 个示例简洁，聚焦正确用法不明显时的歧义
长时任务的整体策略
Agent 在执行长链路任务时容易吃光 token 预算。结合 context engineering 和工具优化，有三种方法缓解：
Compaction（压缩）
当对话历史接近上下文上限时，系统可以实现压缩——总结谈话内容并启动新的上下文窗口。这个技巧能让「agent 在性能损失最小的情况下继续工作」。
艺术在于平衡 recall（召回）和 precision（精度）——先最大化召回以捕获相关信息，然后消除冗余内容，比如重复的工具输出。关键点是保留关键架构决策和思路，丢弃冗余的中间输出，用更紧凑的格式重启上下文。这样既保留 agent 需要的「脑子里」的东西，也释放了 token 空间。
结构化笔记（Structured Note-Taking）
Agent 维护一个持久的外部记忆，比如 NOTES.md 文件，然后在需要时查询而非依赖上下文中的历史。这个简单模式允许「tracking progress across complex tasks」（跨复杂任务追踪进度），维护关键上下文和依赖关系，否则这些信息会丢失。Agent 定期将笔记写入上下文窗口外部，稍后检索，让它的「长期记忆」不受 token 窗口限制。
Anthropic 发布了一个 memory tool，基于文件进行信息的存储和查找——这正是结构化笔记的工具化实现。
Sub-Agent 架构（子代理架构）
当任务复杂到单个无法完成时，拆分成多个专精的子 agent，每个处理聚焦任务并保持上下文简洁。主 agent 在高层规划上协调，每个子 agent 可能使用数千 token 广泛探索，但只返回工作的精炼摘要。
这创造了「separation of concerns」（关注点分离）——详细搜索被隔离，主 agent 专注于综合结果。子 agent 处理领域特定的深入工作，主 agent 维持全局视图并协调进度。
核心
Context engineering 本质上是一种资源管理思维的迁移——把我们对 CPU、内存的管理直觉搬到 token 上来。软件工程里有一条古老法则——premature optimization is the root of all evil（过早优化是万恶之源），但它的前提是资源充裕。当资源有限时，节约就不是过早优化，而是基本设计原则。token 窗口就是这样一种硬性约束——不管模型上下文窗口扩展到多大，attention 的 n² 代价决定了「塞满」永远是下策。
Anthropic 三项工具特性的核心洞察是：agent 工具使用的三个根本瓶颈相互独立且都很关键。工具搜索解决定义爆炸、编程调用解决推理碎片化、使用示例解决理解歧义。它们不是竞争关系，而是互补的——不同 agent 的主要瓶颈不同，需要根据具体症状组合应用。
更深层的启示是：设计 agent 系统时，最重要的问题不是「我能给模型什么信息」，而是「我应该拿走什么信息」。每一个 token、每一个工具定义、每一个例子都在和其他信息竞争模型的注意力。删减往往比补充更能提升 agent 的表现。这种「极简主义」的 context 观，在大规模系统和长时任务中尤其关键。当 token 预算有限时，优先级就变得清晰——只留下高信号密度的内容，让 agent 的注意力聚焦在真正重要的决策上。
最终目标是实现从简单函数调用向「intelligent orchestration」（智能编排）的跨越——让 agent 能够跨大量工具和数据集处理复杂工作流，同时保持高效和准确。
评价
说得到位的部分：
文章对 context rot（context 腐化）的技术原因解释到位——Transformer 的 n² 代价机制和训练数据长序列暴露不足，这两个因素构成了问题的底层硬约束。这把现象从「模型在长上下文中变笨」这种模糊描述，变成了可以分析和工程化的技术问题。
三项工具特性针对不同瓶颈的划分很精准。工具搜索、编程调用、使用示例分别对应「信息量太大」「中间结果污染」「语义理解歧义」三个独立问题。工具准确率提升的基准数据（Opus 4.5 从 79.5% 到 88.1%、编程调用减少 37% token）让收益可量化，不是空泛的「性能提升」。
分层策略（先诊断再针对性应用）体现工程思维——没有推销「一把梭哈」的一刀切方案，而是强调瓶颈识别优先级。这对实践者有现实指导价值——盲目优化错误维度确实可能比不优化还糟，因为 token 是零和资源。
长时任务的三种策略（压缩、结构化笔记、子 agent 架构）覆盖了问题空间的不同侧面。压缩应对上下文窗口硬限制，结构化笔记解决持久记忆需求，子 agent 架构处理任务复杂度。这三种可以组合使用，不是互斥的。
值得质疑或深入的部分：
三项特性之间的互动关系讨论不够。优化一个瓶颈是否可能暴露另一个瓶颈？例如启用工具搜索后，token 预算更充裕，agent 可能会调用更多复杂的 nested tools，此时编程调用是否变得更重要？又或者使用示例提升了调用准确率，减少了纠正循环，这又如何影响长时任务中的 token 累计？文章提到它们互相独立，但实际部署中可能存在更复杂的权衡。
Compaction 的艺术「平衡 recall 和 precision」缺乏可操作指导。什么时候应该优先召回什么场景优先精度？不同任务类型（代码生成、知识检索、多步推理）应该用什么标准？文章给出了动机，但没有方法论。
编程调用示例中的 budget compliance 场景有些特殊——最终返回只有 1KB 结果，但 API 调用本身仍然会触发外部系统的完整查询。如果这些调用有延迟或成本，token 节省可能被运维开销抵消。文章没有讨论边界条件——什么规模的「大到难以塞入上下文」才值得启用编程调用？1000 行、10000 行、还是 100000 行？
对于结构化笔记，文章提到「定期写入上下文窗口外部」，但没有界定「定期」的具体触发机制——是按 token 阈值、按步骤节点、还是按时间间隔？子 agent 架构也有类似问题——什么时候任务应该拆分？评估标准不明确。
没说到或隐含假设：
没有讨论多 agent 环境下的上下文隔离成本。子 agent 架构能够隔离复杂度，但主 agent 是否需要加载所有子 agent 的工具定义？如果是，工具搜索特性是否可以应用在 agent 之间？文章的架构视角停留在单 agent 内部的上下文管理，没有扩展到多 agent 系统层面。
对横向扩展涉及有限。所有优化都是纵向的——在单个 agent 内部压缩 token、提高效率和分区任务。但如果服务需要支持成千上万的并发用户，这些优化措施在系统级如何复用？每个用户独立的上下文工程实践是否会导致配置爆炸和管理复杂度？
安全性和可观测性没有提及。编程调用让 Claude 写并执行任意代码，这对安全策略意味着什么？如何审计 agent 在执行环境中做了什么？Compressed context 会丢失哪些调试信息？这些问题在生产系统中很关键，但文章聚焦纯性能维度。
Prompt caching 与三项特性的协同效应讨论不足。文章提到工具搜索与缓存兼容，但编程调用——中间结果留在执行环境——是否会减少 cache hits？使用示例增加的 token 开销如何与缓存收益权衡？系统设计时需要综合考虑这些权衡，但文章没有提供决策框架。