每一個AI助手功能都是一個緩存失效面

作者李亞飛是OpenClacky（一個用Ruby編寫的開源AI助手）的創始人。他們希望構建一個具備技能、記憶、子助手、瀏覽器自動化、動態模型切換和長時間運行會話等功能的AI助手，卻發現每個功能都以不同方式使提示緩存變得更糟。真正的架構問題不是如何調用LLM、添加另一個工具或協調更多智能體，而是在產品不斷變化的同時保持緩存前綴穩定。每個AI助手功能都是一個緩存失效面：技能加載新的系統上下文，對等智能體工作流分叉前綴，瀏覽器自動化添加易變的工具輸出，壓縮重寫歷史，模型切換可能碎片化緩存命名空間。如果正在構建一個強大的助手，而緩存命中率遠低於預期，這很可能就是原因。

經過兩年和三代架構（前兩代失敗）的演進，他們得出了七個工程決策，能夠在不犧牲功能的情況下，在實際任務中達到90%以上的緩存命中率。全文詳細介紹了哪些地方出了問題、嘗試過的方法以及真正有效的方案。

第一代：RAG一切（2024年初至2025年初）。他們構建了一個教科書式的RAG系統，將用户的代碼庫、文檔和對話歷史嵌入向量存儲中。每次查詢都經過混合檢索、重排序和查詢重寫。聽起來合理，但實際上成本不斷攀升，數據始終過時。代碼庫更新需要重新嵌入，實時同步不可靠，向量存儲落後於實際代碼。他們在為越來越錯誤的索引支付越來越高的費用。90%的召回率不夠，因為錯誤在多步驟中快速累積。據估計，97%的召回率可能是助手產生淨收益的最低要求。此外，向量數據庫增加了另一個可能崩潰或引入延遲的組件。對於在本地倉庫上工作的編碼助手，他們徹底放棄了RAG，不再使用嵌入、向量存儲或檢索流水線，而是讓助手直接讀取文件或使用grep搜索。

第二代：多智能體協調（2025年中）。他們採用SWEBench排行榜上的方案：規劃者、編碼者、審查者和測試者智能體通過消息總線協調，每個角色有特定的提示詞。SWEBench得分不錯，但產品很糟糕。每個智能體交接都是緩存缺失，子智能體有自己的系統提示和緩存命名空間。上下文傳遞需要序列化狀態，每次交接都清空接收智能體的緩存前綴。一個智能體4分鐘完成的任務，四個智能體需要14分鐘，成本提高6倍，調試是噩夢。他們得出結論：單一邊界模型已經是通用型，劃分智能體工作不是分工，而是倍增開銷。角色的多智能體協調被放棄，改為一個主智能體、一個對話、一個緩存命名空間，子智能體僅作為通過單一穩定工具調用的獨立技能執行上下文。

第三代：七個決策。第三代從一個問題開始：如果我們圍繞單個智能體的緩存命中率優化一切會怎樣？不是作為成本技巧，而是作為架構原則。高緩存命中意味着模型看到一致的上下文、響應更快、成本更低。以下是前三個決策：

決策1：歷史增長破壞前綴匹配 → 雙緩存標記。提示緩存通過前綴匹配工作，但歷史單調增長、工具調用重試和中途模型切換都會打破單標記緩存。他們使用雙標記：每輪標記兩個連續消息，形成滾動雙緩衝。這樣，即使在工具調用重試時，第二個標記通常也能倖存。標記選擇邏輯硬性跳過系統注入的消息（如session context塊），因為它們不會在下一輪以相同形式存在。

決策2：動態會話狀態破壞系統提示 → 凍結系統提示。系統提示在會話開始時構建一次，然後字節凍結。任何動態信息（當前日期、工作目錄、模型ID、新技能、用户偏好）都不能放在系統提示中，而是作為帶有系統注入標記的用户消息注入歷史。這樣，即使這些信息變化，也不會使所有後續緩存失效。注入時機至關重要：必須在系統提示構建之後進行，否則會導致跳過系統提示構建。

決策3：技能和子助手膨脹歷史 → 單一元工具。invoke_skill是16個工具中工作最多的一個，它從可搜索的技能工作區讀取技能文件並填充工具定義。關鍵設計是：技能描述不是預先填充在工具定義中，而是在調用時從SKILL.md讀取。這保持了緩存前綴的穩定，因為工具定義不會因新技能安裝而變化。技能名稱在會話開始時渲染到系統提示中，然後凍結，因此新技能只在下一次會話中自動發現，但用户明確請求時仍可通過invoke_skill執行。

文章到此中斷，但作者承諾提供實現每個決策的代碼鏈接。