管理工具上下文

工具定义和累积的 tool_result 块会消耗您的上下文窗口。具有许多工具或许多轮次的长期运行代理可能会在任务完成之前耗尽可用上下文。四种方法在管道的不同位置解决这个问题。

四种方法

每种方法针对不同的上下文压力来源。选择与您的令牌流向相匹配的方法。

工具搜索

工具搜索将工具定义保留在上下文窗口之外，直到 Claude 请求它们。与其预先发送 50 个工具架构，不如发送单个 tool_search 工具，让 Claude 按需发现其余的。这用少量延迟（一个额外的轮次来查找工具）换取基线上下文使用的大幅减少。

程序化工具调用

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

提示缓存

提示缓存不会减少上下文中的令牌数量，但会减少您在后续请求中为它们支付的费用。如果您的工具定义是稳定的，请缓存一次，然后在数千个请求中重用缓存的前缀。当工具集很大但固定时，这是正确的选择。

上下文编辑

上下文编辑从对话历史中删除旧的 tool_result 块，一旦它们完成了目的。长代理循环可能会产生数百个中间结果，这些结果在当时很有用，但现在是累赘。上下文编辑让您可以在不重新启动对话的情况下修剪它们。

组合方法

这些方法可以组合使用。长期运行的代理可能会使用工具搜索来保持工具集精简，使用提示缓存来分摊剩余定义的成本，以及使用上下文编辑来修剪陈旧的结果，随着对话的增长。每种方法解决问题的不同部分，因此一起使用它们没有冲突。

高容量代理的合理起点：

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

后续步骤