![[AI 脈絡 #6] AI 代理程式的記憶體設計：將資訊放在脈絡之外（計畫檔案・記憶體・RAG） 封面圖](/assets/images/posts/9c901582-b6d3-47a4-a582-ff7c6393053d/1.jpg)
如果你一路讀到這裡，應該會看出一個共通模式：盡量減少放在脈絡視窗中的內容。第 3 篇的「在 /clear 前將狀態寫入檔案」、第 4 篇的「只放指標，不放全文」，以及第 5 篇的「將過程交給子代理程式，只把結論交給主要代理程式」，全都指向同一個方向。不過，我們還沒有好好處理這些檔案，也就是移到脈絡外的資訊，究竟要放在哪裡。
本篇要談的就是那個目的地：即使工作階段結束，仍必須保留的知識，要放在哪裡、如何放置。打個比方，脈絡視窗是工作台，檔案系統則是倉庫。工作台狹小又昂貴，工作階段結束後就會被清空。倉庫寬敞、便宜，而且會持續保留。良好的代理程式運作，歸根究柢就是設計工作台與倉庫之間的物流。
計畫檔案，長時間工作流程的生命線
最基本的外部化方式就是計畫檔案。開始工作時，讓代理程式把目標、已確定的決策與剩餘步驟寫入 PLAN.md 之類的檔案，並在進行過程中持續更新。
只靠這一個檔案，就能一次解決好幾個問題。首先，它能在工作階段重設後存活。不論是脈絡已滿而執行 /clear，還是闔上筆電、隔天開啟新的工作階段，只要讀取計畫檔案，就能接續工作。這和第 3 篇提到的 auto-compact 不確定摘要不同；它是由你直接控制保留內容的精確紀錄。
它還有附帶效果。代理程式如果在每個步驟更新並重新讀取計畫檔案，整體目標就會反覆出現在脈絡的最近位置。正如第 2 篇所見，模型的注意力會強烈集中在脈絡末端；我們可以反過來利用這項特性，持續讓「剛才正在做什麼」留在視野中。當你交辦數十個步驟的工作時，這正是避免代理程式中途忘記原始目標、轉而離題的解方。實務上，處理長時間工作的代理程式產品也會把待辦清單放在檔案中，持續反覆改寫。
記憶體，跨越工作階段累積的知識
如果計畫檔案能延長單一工作的生命週期，記憶體則會在整個專案中累積知識。包括 Claude Code 在內的代理程式都支援記憶體目錄功能，原理很簡單：把得知的事實逐一寫入檔案，只持續載入摘要索引，並在相關工作需要時才讀取全文。第 4 篇的指標原則在這裡同樣適用。
重要的是儲存標準。什麼都記，記憶體很快就會變成垃圾場。合格標準是「無法從其他地方推導出的資訊」。程式碼結構可以透過閱讀程式碼得知，因此淘汰；過去的提交紀錄由 git 記得，也淘汰。相對地，像是「這個專案的 dev 伺服器一定要從 main 工作樹啟動」這類運作規則、「使用者偏好敬語」這類偏好，以及經過反覆摸索才發現的環境特有陷阱，都值得寫入記憶體。因為這些內容沒有記錄在其他地方。
過時記憶體的問題也必須納入計畫。半年前記下的事實，不保證現在仍然正確。記憶體的讀寫規則應包含「如果參照的記憶體與現實不符，就更新或刪除」，才能避免錯誤記憶以第 2 篇所說的脈絡污染形式再次出現。
RAG，當倉庫大到圖書館規模時
計畫檔案與記憶體討論的是數十個檔案的規模。但如果倉庫大到像一座圖書館呢？公司內部 Wiki 數千頁、論文數萬篇、客戶詢問紀錄數十萬筆。你確定需要的資訊就在其中某處，但不可能把全部內容載入脈絡。
這時使用的技術就是 RAG（Retrieval-Augmented Generation，檢索增強生成）。收到問題後，先從倉庫搜尋相關片段，再只把找到的幾個片段放進脈絡來產生答案。搜尋通常會使用 embedding 技術。將文字轉換成語意空間中的座標後，「退款規定」這個問題和「付款取消政策」這份文件，即使表達不同，也可能位於相近座標，因此即使關鍵字沒有重疊，也能找出來。
有一段時間，RAG 被視為處理長文件的唯一正解，但在程式碼代理程式領域出現了有趣的反轉。人們確認，能使用工具的代理程式即使不使用 embedding 搜尋，也能透過反覆使用 grep 與探索檔案，相當有效地找出需要的程式碼。因此，現今實務上的取向是混合式：具有精確識別子的程式碼，代理程式直接探索更有優勢；用詞各異的自然語言文件堆，則適合 embedding 搜尋。無論哪一種，原則都相同：「不要全部載入，只在查詢時載入相關部分。」
總結
- 脈絡是工作台，檔案是倉庫。工作階段結束後仍須保留的知識，基本上應該從脈絡移到檔案中。
- 計畫檔案能讓長時間工作在工作階段重設後繼續，並反覆將目標暴露在脈絡的最近位置，避免偏離。
- 記憶體只記錄無法從其他地方推導的資訊，持續載入索引，並透過更新與刪除規則管理過時項目。
- 倉庫非常大時，就用 RAG 在查詢時只載入相關片段。程式碼適合直接探索，自然語言文件堆則適合 embedding 搜尋。
現在只剩系列的最後一篇。到目前為止，我們為了品質管理脈絡；最後一篇要談的是金錢。內容包括提示快取的原理：即使是相同的脈絡，建立方式不同也可能讓 API 成本相差數倍；以及為什麼不能任意修改脈絡的前半部。