在OpenClaw案例中，哪些大型中間產物佔據了大量的上下文快取？

Question

Accepted Answer

在OpenClaw的實際案例分析中，大量中間產物，而非用戶輸入或模型輸出，被反覆寫入並重讀於歷史上下文快取，導致代幣消耗激增。這些主要包含巨大的工具執行結果、冗長的推理追蹤記錄、大型JSON快照、文件列表、瀏覽器抓取資料以及子代理的對話記錄。

這些龐大的中間產物一旦被保留在歷史上下文中，模型在每一輪呼叫中便會透過快取前綴重複讀取，即使新的輸入內容僅佔極小比例，也造成了高達近八成的總代幣消耗來自於此類重複讀取，而非處理新的用戶意圖。這種機制在Agent的工具呼叫循環中尤為顯著，因為工具鏈會產生大量短間隔呼叫，且前綴變化不大，使得緩存重放負擔持續累積。
巨大的工具執行結果與推理追蹤

在OpenClaw案例中，最顯著的成本驅動因素之一是工具執行結果（toolResult）與代理推理（assistant:thinking）的資料塊。例如，在某個消耗最高的會話中，toolResult:text 的字符量高達366,469字元，而 assistant:thinking 也達到了331,494字元。這些龐大的文本內容，雖然在單次工具調用中是必要的，但若未經適當管理便持續寫入長期上下文，將在每次模型呼叫時被重複載入，造成代幣的巨大浪費。
大型JSON快照與檔案列表

許多自動化任務會產生大量的結構化數據，例如大型閘道JSON日誌與檔案清單輸出。在分析會話中，曾出現約3.7萬字元的大型閘道JSON日誌，以及約4.1萬字元的巨大檔案清單輸出。這些數據雖然有助於代理理解工作環境，但其原始且未經精簡的完整內容，會使得上下文迅速膨脹。當這些大型JSON快照和文件列表被反覆載入時，直接促成了快取前綴的體積過大。
瀏覽器抓取資料與狀態快照

瀏覽器抓取資料（browser fetched data）和會話狀態快照（session/status state snapshot）也是佔用大量上下文快取的重要來源。案例中曾觀察到約2.9萬字元的瀏覽器快照與安全封裝，以及約3萬字元的會話/狀態快照結合大型提示結構。這類資料由於通常包含網頁的完整DOM結構或複雜的系統狀態資訊，其體積往往非常龐大，若未經壓縮或摘要處理便直接納入上下文，將導致每次迭代都需付出高昂的代幣成本來重新讀取。
子代理對話記錄

在涉及多個代理協作的場景中，子代理的完整對話記錄（sub-Agent conversation records）也會成為上下文快取的負擔。儘管文章沒有提供具體的字符量數據，但子代理的完整對話歷史，包含其思考過程、工具調用和輸出，若未經精簡或摘要，將如同主代理的推理追蹤一樣，在每次主代理呼叫時被重複讀取，進一步加劇了代幣消耗問題。

閱讀紀錄

隱藏 →

此記錄會在頁面關閉後消失

在OpenClaw案例中，哪些大型中間產物佔據了大量的上下文快取？

Loading

你覺得這篇文章有幫助嗎？

有幫助

沒幫助

回報問題

1

0

0

分享給好友