【Anthropic】Context Engineering 框架：从原则到工具维度实践
- 从 Prompt Engineering 到 Context Engineering
- Context Engineering 的黄金法则
- 工具维度的高级实践：三项特性
- 分层策略与实施
- 长时任务的整体策略
- 核心思想
原文 A：Effective Context Engineering for AI Agents 原文 B：Advanced Tool Use on the Claude Developer Platform
从 Prompt Engineering 到 Context Engineering
传统的 prompt engineering 关注单个提示词的编写。但随着 AI agent 从单轮对话演进到多轮任务执行，问题的焦点发生了根本性变化：不是「如何写一个好提示」，而是「在整个推理过程中，什么配置的上下文最有可能产生我们想要的行为」。
Context engineering 是一个更宽泛的概念——在 LLM 推理阶段，精心策划和维护最优的 token 集合。这个集合涵盖系统指令、工具定义、外部数据、对话历史等所有成分。而在构建大规模 agent 系统时，工具定义本身往往成为最大的 token 消耗源——传统「一次性加载所有工具」的模式下，工具定义可能在处理实际请求之前就已吃掉 50,000+ token。
Context Rot：有限的”注意力预算”
Transformer 架构的每个 token 对都维持 n² 的两两关系（pairwise attention）。这意味着随着上下文长度增加，模型经历所谓的「context rot」——准确度下降。
简单讲：每多一个 token，就在用掉有限的「注意力预算」。当上下文变长时，这个预算被拉扯得越来越薄，模型在关键信息上的专注力随之衰减。低质量的 token 不只是浪费空间，它还在稀释高质量信息的权重。
Context Engineering 的黄金法则
找到最小的、高信号密度的 token 组合，使其最大化目标行为的可能性。
这个原则贯穿以下几个维度：
系统提示设计
系统提示不应该是”僵硬到处处是规则”也不应该”模糊到只有启发式建议”。要在具体性和灵活性之间找平衡：
- 用清晰的结构（XML 标签或 Markdown 分节）组织指令
- 明确 agent 的目标和约束
- 提供足够的上下文让 agent 自主决策，而不是规定每一步
样例选择策略
不要堆砌所有边界情况，而要选择多样、规范的样例：
- 覆盖关键的路径和决策点
- 样例之间差异大，让 agent 学到泛化模式
- 丢掉那些冗余或过度特化的边界情况
工具维度的高级实践：三项特性
在 context engineering 的大框架下，工具配置是最容易被忽视但最值得优化的维度。Anthropic 针对工具使用的瓶颈发布了三项测试版特性，都指向同一个目标：用结构化手段削弱工具定义的 token 代价。
特性一：工具搜索（Tool Search）——解决定义爆炸
允许 Claude 动态发现工具，而非一次加载全部定义。通过标记 defer_loading: true，该工具在代理真正需要时才被加载，而不是在启动时就堆入上下文。
性能收益：
- Token 消耗减少 ~85%：在测试场景中从约 77K token 下降到 8.7K token
- 准确率显著提升：Opus 4.5 在知识检索任务中从 79.5% 提升到 88.1%
- 与缓存兼容：可与提示缓存配合使用，进一步提升成本效率
本质上，工具搜索是把惰性加载的思想从软件工程搬到了 LLM 推理中。当工具数量众多时，这个特性尤其关键。
特性二：编程工具调用（Programmatic Tool Calling）——解决推理碎片化
传统工具使用需要多轮 API 调用；此特性让 Claude 通过代码编排多个工具，中间结果不进入 Claude 的上下文窗口。
工作机制：
代理在执行环境中直接协调多个工具调用，控制流程和条件分支，类似于编写脚本。这样复杂的协调逻辑就保留在确定性的执行环境中，模型只需专注于决策。
性能收益：
- Token 消耗减少 37%：在复杂研究任务中
- 消除多轮推理开销：对于多步骤工作流至关重要
- 准确率改进：知识检索准确率从 25.6% 提升到 28.5%
- 支持并行执行：多个工具可并行调用，而非顺序执行
典型场景：预算合规性检查需要处理数千条支出行项。传统方法会将所有行项塞入上下文，导致推理变差；编程调用则将逻辑留在执行环境中，模型只关注决策和控制。
特性三：工具使用示例（Tool Use Examples）——解决理解歧义
超越 JSON Schema 定义，提供具体的使用样板，帮助模型理解格式约定、参数关联关系、可选字段的包含方式和实际调用模式。
性能收益：
- 准确率从 72% 提升到 90%：在复杂参数处理的内部测试中
这看似简单的优化，能显著减少模型的「猜测成本」，特别是在字段组合和边界情况处理上。
分层策略与实施
三项特性的最佳使用方式是分层应用，而非盲目全量启用：
- 诊断性能瓶颈（是 token 消耗、推理轮数还是格式理解？）
- 针对最严重的瓶颈优先应用特性（例如工具众多则先用工具搜索）
- 根据需要补充其他特性
对于工具多、任务复杂、格式复杂的真实 agent 场景，往往需要三个特性同时发力。这反映了对工程现实的理解：不同 agent 的主要瓶颈不同，盲目优化错误的维度比不优化还糟。
长时任务的整体策略
Agent 在执行长链路任务时容易吃光 token 预算。结合 context engineering 和工具优化，有三种方法缓解：
Compaction（压缩）
当对话历史接近上下文上限时：
- 总结关键的架构决策和思路
- 丢掉冗余的中间输出
- 用更紧凑的格式重启上下文
这样既保留了 agent 需要的”脑子里”的东西，也释放了 token 空间。
结构化笔记（Structured Note-Taking）
Agent 维护一个持久的外部记忆（比如 NOTES.md 文件）：
- 记录重要的决定、进度、架构细节
- 在需要时查询而非依赖上下文中的历史
- 让 agent 的”长期记忆”不受 token 窗口限制
多 Agent 架构（Sub-agent Architecture）
任务复杂到无法一个 agent 完成时，拆分成多个专精的子 agent：
- 每个子 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 的注意力聚焦在真正重要的决策上。