管理工具上下文

工具定義和累積的 tool_result 區塊會消耗您的「context window」（上下文視窗）。擁有許多工具或進行多輪對話的長時間執行代理程式，可能會在任務完成之前耗盡可用的上下文。有四種方法可以在管線的不同階段解決此問題。



四種方法

每種方法針對不同的上下文壓力來源。請選擇與您的 token 消耗來源相符的方法。



工具搜尋

工具搜尋會將工具定義保留在上下文視窗之外，直到 Claude 主動請求它們。您不需要預先傳送 50 個工具結構描述，而是傳送單一的 tool_search 工具，讓 Claude 按需探索其餘工具。這會以少量的延遲（額外一輪來查詢工具）換取基準上下文使用量的大幅降低。



程式化工具呼叫

程式化工具呼叫會將一連串的工具呼叫摺疊成單一程式碼區塊，由 Claude 撰寫並在 Anthropic 的程式碼執行沙箱中執行。Claude 不會進行五次 tool_use 和 tool_result 的往返，而是發出一個腳本，從沙箱內呼叫全部五個函式。中間結果永遠不會進入對話歷史記錄。



提示快取

「Prompt caching」（提示快取）不會減少上下文中的 token 數量，但會降低您在後續請求中為這些 token 支付的費用。如果您的工具定義是穩定的，只需快取一次，即可在數千個請求中重複使用快取的前綴。當工具集龐大但固定時，這是正確的選擇。



上下文編輯

上下文編輯會在舊的 tool_result 區塊完成其用途後，將它們從對話歷史記錄中移除。長時間的代理程式迴圈可能會產生數百個中間結果，這些結果在當時很有用，但現在已成為無用的負擔。上下文編輯讓您可以在不重新啟動對話的情況下修剪它們。



組合使用多種方法

這些方法可以組合使用。長時間執行的代理程式可能會使用工具搜尋來保持工具集精簡、使用提示快取來分攤其餘定義的成本，並在對話增長時使用上下文編輯來修剪過時的結果。每種方法解決問題的不同部分，因此同時使用它們並不會產生衝突。

對於高流量代理程式，合理的起點如下：

1. 從第一天起就對您的工具定義啟用提示快取。快取寫入會比基本輸入定價高出 25%，但在第二次命中快取的請求時即可回本。
2. 當您的工具集增長到大約 20 個以上工具，或基準上下文使用量變得明顯時，加入工具搜尋。
3. 當個別對話開始執行得夠長，以致早期結果變得不相關時，加入上下文編輯。
4. 如果您注意到有重複性的小型工具呼叫鏈可以作為單一批次執行，請考慮使用程式化工具呼叫。



後續步驟