管理工具上下文
在工具搜索、程序化工具调用、提示缓存和上下文编辑之间进行选择，以管理上下文膨胀。
工具定义和累积的 tool_result 块会消耗您的 "context window"（上下文窗口）。拥有大量工具或经历多轮对话的长时间运行的智能体，可能会在任务完成之前耗尽可用的上下文。有四种方法可以在流程的不同环节解决这一问题。
四种方法
每种方法针对不同的上下文压力来源。请选择与您的令牌消耗去向相匹配的方法。
| 方法 | 减少的内容 | 适用场景 | 了解更多 |
|---|---|---|---|
| 工具搜索 | 预先加载的工具定义 | 大型工具集（20 个以上工具），其中大多数工具并非每轮都需要 | 工具搜索工具 |
| 程序化工具调用 | tool_result 往返 | 可以作为单个脚本执行的工具调用链 | 程序化工具调用 |
| 提示缓存 | 重复工具定义的令牌成本 | 在大量请求中保持稳定的工具集 | 结合提示缓存的工具使用 |
| 上下文编辑 | 历史记录中的旧 tool_result 块 | 早期结果已不再相关的长对话 | 上下文编辑 |
工具搜索
"Tool search"（工具搜索）会将工具定义保留在上下文窗口之外，直到 Claude 请求它们为止。您无需预先发送 50 个工具模式，而是只发送一个 tool_search 工具，让 Claude 按需发现其余工具。这以少量的 "latency"（延迟）（查找工具需要额外一轮）为代价，换取基线上下文使用量的大幅降低。
程序化工具调用
"Programmatic tool calling"（程序化工具调用）将一系列工具调用折叠为单个代码块，由 Claude 编写并由 Anthropic 的代码执行沙箱运行。Claude 无需进行五次 tool_use 和 tool_result 的往返，而是输出一个脚本，在沙箱内调用全部五个函数。中间结果永远不会进入对话历史。
提示缓存
"Prompt caching"（提示缓存）不会减少上下文中的令牌数量，但会降低您在后续请求中为这些令牌支付的费用。如果您的工具定义是稳定的，只需缓存一次，即可在数千个请求中重复使用缓存的前缀。当工具集庞大但固定时，这是正确的选择。
上下文编辑
"Context editing"（上下文编辑）会在旧的 tool_result 块完成其用途后，将其从对话历史中移除。一个长时间的智能体循环可能会产生数百个中间结果，这些结果在当时很有用，但现在已成为累赘。上下文编辑让您无需重新开始对话即可将其裁剪掉。
组合使用多种方法
这些方法可以组合使用。一个长时间运行的智能体可以使用工具搜索来保持工具集精简，使用提示缓存来分摊剩余定义的成本，并使用上下文编辑在对话增长时裁剪过时的结果。每种方法解决问题的不同部分，因此同时使用它们不会产生冲突。
对于高流量智能体，一个合理的起点是：
- 从第一天起就为您的工具定义启用提示缓存。缓存写入的价格比基础输入价格高 25%，在第二个命中缓存的请求时即可收回成本。
- 当您的工具集增长到大约 20 个工具以上，或基线上下文使用量变得明显时，添加工具搜索。
- 当单个对话开始变得足够长，以至于早期结果变得不再相关时，添加上下文编辑。
- 如果您注意到存在可以作为单个批次运行的重复性小型工具调用链，请考虑使用程序化工具调用。
后续步骤
Was this page helpful?