管理工具上下文

工具定义和累积的 tool_result 块会消耗您的 "context window"（上下文窗口）。拥有大量工具或经过多轮对话的长时间运行智能体可能会在任务完成之前耗尽可用上下文。以下四种方法可在流程的不同环节解决这一问题。



四种方法

每种方法针对不同的上下文压力来源。请选择与您的令牌消耗位置相匹配的方法。



工具搜索

工具搜索会将工具定义保留在上下文窗口之外，直到 Claude 主动请求它们。您无需预先发送 50 个工具模式，只需发送一个 tool_search 工具，让 Claude 按需发现其余工具。这以少量延迟（额外一轮用于查找工具）换取基线上下文使用量的大幅降低。



程序化工具调用

程序化工具调用将一系列工具调用折叠为单个代码块，由 Claude 编写并在 Anthropic 的代码执行沙箱中运行。Claude 不再进行五次 tool_use 和 tool_result 的往返，而是生成一个脚本，在沙箱内调用所有五个函数。中间结果永远不会进入对话历史记录。



提示缓存

"Prompt caching"（提示缓存）不会减少上下文中的令牌数量，但会降低您在后续请求中为这些令牌支付的费用。如果您的工具定义是稳定的，只需缓存一次，即可在数千个请求中重复使用缓存的前缀。当工具集庞大但固定时，这是正确的选择。



上下文编辑

上下文编辑会在旧的 tool_result 块完成其使命后，将其从对话历史记录中移除。一个长时间运行的智能体循环可能会产生数百个中间结果，这些结果在当时有用，但现在已成为无用负担。上下文编辑让您无需重新开始对话即可修剪这些内容。



组合使用多种方法

这些方法可以组合使用。一个长时间运行的智能体可以使用工具搜索来保持工具集精简，使用提示缓存来分摊剩余定义的成本，并随着对话的增长使用上下文编辑来修剪过时的结果。每种方法解决问题的不同部分，因此同时使用它们不会产生冲突。

对于高流量智能体，一个合理的起点是：

1. 从第一天起就对工具定义启用提示缓存。缓存写入的费用比基础输入定价高 25%，但在第二次命中缓存的请求时即可收回成本。
2. 当您的工具集增长到大约 20 个以上工具，或基线上下文使用量变得明显时，添加工具搜索。
3. 当单个对话开始运行足够长、早期结果变得不再相关时，添加上下文编辑。
4. 如果您注意到重复出现的小型工具调用链可以作为单个批次运行，请考虑使用程序化工具调用。



后续步骤