真正有效的 AI 代理記憶體架構

2026年2月，我為一套 AI 代理協調框架建構了語意記憶系統。該系統將15,800個檔案中的49,746個文本區塊索引至本機 SQLite 資料庫，透過混合 BM25 與向量搜尋並以倒數排名融合（Reciprocal Rank Fusion）進行檢索，再利用任務嵌入向量與代理近期動作之間的餘弦相似度來偵測代理是否偏離任務。¹ 嵌入模型僅8 MB，資料庫僅83 MB。整套系統在筆記型電腦上運行，完全不依賴雲端。

我在建構之前沒有讀過任何論文。我只是在解決遇到的問題：代理在不同工作階段之間遺失上下文、重複犯過的錯誤、偏離任務卻無法被偵測。架構從這些失敗中自然浮現。

2026年3月，五篇研究論文不約而同地驗證了相同的架構。

摘要

• 趨同現象：2026年3月發表的五篇論文，各自獨立驗證了生產環境建構者數月前已部署的代理記憶體模式——以 RRF 融合的混合檢索、以結構化 Markdown 儲存技能、透過軌跡挖掘分析失敗模式，以及透過閘控記憶體防止漂移。
• 研究證據：Structured Distillation 在4,182組對話上測試了20種向量搜尋配置與20種 BM25 配置。純向量搜尋在統計上不顯著，純 BM25 則導致效能下降。唯有混合跨層檢索有效。² 我的系統恰好採用了這套架構。
• 生產環境數據：49,746個區塊、15,800個檔案、83MB 資料庫、8MB 嵌入模型、12次漂移事件在餘弦閾值0.30下以100%精確率被偵測。¹
• 研究數據：Memento-Skills 使用以 Markdown 檔案儲存的技能，在 Humanity’s Last Exam 上達到116%的相對提升。³ Trajectory-Informed Memory 在複雜任務上提升了28.5個百分點。⁴ SuperLocalMemory 在零雲端呼叫的條件下於 LoCoMo 上達到74.8%。⁵
• 這意味著什麼：這些模式是正確的。當建構者與研究者在毫無協調的情況下趨同於同一架構，該架構很可能是此問題空間的最佳解。代理記憶體並非一個等待突破的研究問題，而是一個已有成熟方案、只是多數團隊尚未落實的工程問題。

五篇論文驗證同一套代理記憶體架構

混合檢索是唯一可行的架構

Sydney Lewis 在六個軟體工程專案的4,182組對話（包含14,340次交流）上測試了40種檢索配置。² 研究將每次交流從平均371個 token 壓縮至38個 token，採用結構化四欄位格式，接著測試向量搜尋與 BM25 關鍵字搜尋的所有組合。

結果毫無懸念。經 Bonferroni 校正後，全部20種純向量配置在統計上均不顯著。全部20種純 BM25 配置則導致顯著退化。唯有跨層混合檢索（結合兩者）產出可靠結果，MRR 達到0.759，相比逐字檢索的0.745——壓縮11倍卻不損失檢索品質。²

我的系統使用 FTS5 BM25 進行關鍵字搜尋，搭配 sqlite-vec 進行256維向量搜尋，再以倒數排名融合整合結果。¹ 選擇這套架構的原因很單純：純向量搜尋會漏掉精確的技術術語（函式名稱、錯誤代碼、檔案路徑），而純關鍵字搜尋則無法捕捉語意相似性。混合方案源自除錯檢索失敗的經驗，而非文獻閱讀。Lewis 的論文為實務中顯而易見的結論提供了統計學證明。

以 Markdown 檔案儲存技能

Memento-Skills 提出了一套基於記憶的強化學習框架，將可重用技能儲存為結構化 Markdown 檔案。³ 透過讀寫反思學習循環（Read-Write Reflective Learning），系統在執行時選取相關技能（Read），並從新經驗中更新技能庫（Write）。該系統在 General AI Assistants 基準上達到26.2%的相對提升，在 Humanity’s Last Exam 上更達到116.2%的相對提升，且完全未更新模型參數。適應完全透過外部化技能的演進來實現。³

我在十個月前就建構了同樣的東西。我的協調框架中的 Learner v2 系統透過檔案路徑指紋從工作階段歷史中偵測語意工作流程模式，生成帶有 frontmatter 中繼資料的結構化 Markdown 技能檔案，並儲存供未來工作階段自動啟用。⁶ 技能庫目前包含48個技能，涵蓋部落格評估、夜間檢查到部署驗證等各類功能。每個技能最初只有幾行內容來處理特定失敗，隨著代理遇到新的邊界案例而逐步成長。

Anthropic 的 Thariq Shihipar 證實了相同的模式：「大多數技能一開始只有幾行和一個注意事項，隨著 Claude 遭遇新的邊界案例而逐步成長。」Anthropic 目前有數百個技能在使用中，歸類為九個類別，與我獨立發展出的類別高度吻合。⁷

這種趨同並非巧合。Markdown 檔案之所以是代理技能的正確抽象，在於它們人類可讀、可納入版本控制，且載入上下文時無需序列化開銷。模型能以處理程式碼的相同文本處理能力來讀取、修改和擴展這些檔案。不需要微調、不需要參數更新、不需要訓練流程。技能檔案本身就是記憶。

軌跡挖掘識別失敗模式

IBM Research 提出的 Trajectory-Informed Memory Generation 引入了一套四階段流程，從代理執行軌跡中萃取學習經驗。⁴ 系統分析代理推理中的語意模式、識別失敗與恢復決策、生成策略與最佳化建議，並將客製化的學習成果注入未來提示中。在 AppWorld 場景中，系統在目標完成率上提升了最高14.3個百分點，複雜任務更提升了28.5個百分點——相對提升149%。⁴

我則是手動完成了相同的工作。在2025年5月至2026年2月間超過500次自主編碼工作階段中，每當需要人工介入時，我都會回顧該階段的對話紀錄與 hook 遙測資料，根據鏈條中第一個未被偵測的失敗來歸因主要根本原因。七種模式涵蓋了94%的所有失敗：捷徑螺旋（23%）、信心幻象（19%）、差不多就好高原（15%）、隧道視野（14%）、幽靈驗證（12%）、延遲債務（9%），以及空洞報告（8%）。⁸

IBM 的論文將我手動完成的工作自動化了。他們的四階段流程是對同一過程的形式化：觀察軌跡、識別失敗模式、萃取經驗、注入未來執行。輸出格式不同（他們的系統生成自然語言建議，我的系統生成攔截特定工具呼叫模式的 shell hook），但架構相同。我在2026年2月提交的 NIST 意見書主張代理威脅本質上是行為性的，而現有框架未能應對行為失敗模式。IBM 的論文為同一論點提供了獨立證據。

閘控記憶體防止漂移

CraniMem 引入了針對代理記憶系統的目標條件閘控與效用標記機制。⁹ 有界的情景緩衝區處理近期連續性，結構化的長期知識圖譜處理持久性回憶，排程化的整合循環重播高效用軌跡並修剪低效用項目。在乾淨輸入與注入雜訊兩種條件下，CraniMem 均優於原生 RAG 和 Mem0。⁹

我的漂移偵測系統是同一原則的簡化版本。每25次工具呼叫後，偵測器會計算原始使用者提示的嵌入向量與代理近期動作滑動視窗之間的餘弦相似度。當分數低於0.30時，系統會注入包含原始提示的警告訊息。在60個工作階段中所有12次低於閾值的觸發裡，代理確實已經偏離任務。閾值以上的工作階段則無一需要人工介入處理漂移。¹

CraniMem 在儲存層進行閘控：阻止無關資訊進入長期記憶。我的系統在執行層進行閘控：偵測代理當前動作何時偏離指定任務。兩者針對的是同一種失敗模式——上下文汙染——只是在不同層級處理。閘控原則殊途同歸：無論無關資訊進入記憶還是進入當前執行上下文，都會降低代理效能。

本機優先的記憶體達到生產規模

SuperLocalMemory 在零雲端 API 呼叫的條件下，於 LoCoMo 基準上達到74.8%，超越 Mem0（66.9%）達16個百分點。⁵ 系統使用四通道倒數排名融合：Fisher-Rao 幾何檢索、BM25 詞彙檢索、實體圖譜遍歷，以及時序檢索。加入 LLM 合成層後，分數達到87.7%。⁵

我的系統在相同的基礎架構上使用兩通道 RRF（向量 + BM25）。¹ SuperLocalMemory 額外加入了 Fisher-Rao 幾何距離和實體圖譜遍歷作為檢索通道。額外通道在對話式基準上提升了準確度。它們是否對程式碼工作流程中的代理記憶同樣重要，仍是開放問題——我的兩通道系統尚未出現第三或第四通道才能解決的檢索失敗。

真正重要的發現不在於通道數量，而在於本機優先的混合檢索記憶體能夠勝過使用更大模型、更昂貴基礎設施的雲端依賴系統。SuperLocalMemory 的 Mode A（零雲端）擊敗了 Mem0 的雲端驅動系統。我的系統運行在本機 SQLite 資料庫中的8MB 嵌入模型上。代理記憶體的效能天花板並非受制於模型大小或雲端算力，而是受制於檢索架構。

代理記憶體是工程問題，不是研究問題

研究與生產的慣常關係是：研究者發現，實踐者實作。2026年3月的代理記憶體領域恰好相反——生產環境建構者先行部署，研究者數週或數月後以嚴格評估確認了建構者在實務中觀察到的相同模式。

這種趨同意味著一件具體的事：代理記憶體並非一個等待突破的研究問題。 架構已然明確。以 RRF 融合的混合檢索、以結構化文本外部化的技能、針對失敗模式的軌跡挖掘、防止上下文汙染的閘控記憶體。每個元件都已存在、可運作，且經過生產部署與受控研究的雙重獨立驗證。

差距不在知識，而在採用。2026年3月一份代理記憶機制調查發現，多數生產系統仍然不使用持久記憶，或僅採用簡單的上下文視窗填充。¹⁰ 僅21%的企業高管對其代理存取的內容具有完整可見性，86%則表示對組織中約1,200個非官方 AI 應用毫無掌握。¹¹ 最危險的失敗代理並非那些缺乏強大模型的，而是那些對自身失敗毫無記憶的。

2026年3月發表的研究論文並非在發現新領域，而是在為建構者早已居住的領地繪製地圖。地圖很有用。Structured Distillation 以統計學證明混合檢索優於純向量搜尋，讓下一位建構者不必透過除錯重新發現這一點。Memento-Skills 展示了以 Markdown 儲存的技能無需參數更新即可達到116%的提升，給予下一個團隊跳過微調流程的信心。IBM 的軌跡論文將我在500個工作階段中手動完成的工作自動化了。

但地圖之所以存在，是因為領地早已被開拓。建構者先到了那裡。

常見問題

代理記憶體應該使用什麼嵌入模型？

對於延遲敏感的本機優先應用，Model2Vec 的 potion-base-8M（256維，磁碟佔用8MB）在品質與速度之間提供了最佳平衡——比完整 Transformer 嵌入小50倍、快500倍。¹² 若追求更高品質的檢索且延遲要求較寬鬆，potion-base-32M 或完整的 sentence transformer 模型效果更好。但嵌入模型的重要性遠不及檢索架構。一套優秀的混合檢索系統搭配小型嵌入模型，效果勝過純向量搜尋搭配大型模型。²

RAG 足以應付代理記憶體嗎？

原生 RAG（檢索區塊、填入上下文）比沒有記憶好，但不如結構化記憶。CraniMem 論文直接證明了這一點：基於效用修剪的閘控記憶體在乾淨與雜訊條件下均優於原生 RAG。⁹ 原生 RAG 在代理系統中的實際失敗模式是上下文汙染——檢索到邊緣相關的資訊，導致代理偏離任務。閘控（決定什麼不該被檢索）與檢索品質同等重要。

需要向量資料庫嗎？

不需要。SQLite 搭配 sqlite-vec 擴充功能可在83MB 的檔案中處理49,746個向量，查詢時間低於一秒。¹ 除非需要索引數百萬份文件或需要分散式存取，否則本機 SQLite 資料庫更簡單、建置更快，且消除了基礎設施依賴。SuperLocalMemory 以零雲端呼叫的本機架構在 LoCoMo 上達到了74.8%。⁵

如何偵測代理漂移？

計算原始任務提示的嵌入向量與代理近期動作滑動視窗（我使用最近25次工具呼叫）之間的餘弦相似度，再根據經驗設定閾值。我的閾值是0.30，在60個工作階段中校準而得：全部12次低於閾值的觸發都是真正的漂移，閾值以上的工作階段無一需要介入。閾值會因任務領域和嵌入模型而異。建議從0.30開始，再根據誤報率調整。¹

代理記憶體與代理安全之間有什麼關係？

直接相關。我從500多個工作階段中歸納出的七種失敗模式是跨代理、跨模型、跨任務反覆出現的行為模式。沒有過往失敗的記憶，每個工作階段都會重蹈覆轍。IBM 的軌跡挖掘論文以量化方式證明了這一點：能夠存取先前軌跡學習成果的代理，在複雜任務上提升了149%。⁴ 記憶不僅提升能力，更防止代理重複已知的失敗模式。