最好笑的是：贏家的名字叫 grep

AI 記憶這個領域有一種很奇妙的通膨。

一開始只是「把重要事情記下來」。過幾個月，架構圖開始長出 Embedding model、向量資料庫、重排序器、知識圖譜、多 agent 反思迴圈，最後連一個「使用者喜歡深色模式」都要走得像核電廠控制流程。

然後 2026 年 5 月 14 日，一篇研究論文丟出一個很不給面子的標題：只要 grep 就夠了嗎？

研究結果不是「grep 永遠打爆向量搜尋」。那太粗暴，也不準。真正刺的地方是：在 LongMemEval 這種長期對話記憶問答裡，工具結果直接塞進對話時，字面搜尋在所有 harness 與模型組合裡都贏過同樣交付方式下的向量檢索。同一份資料、同一批問題，只是檢索方式和工具結果呈現方式不同，結果就差很多。

這聽起來像小工具贏了高級系統。但更準確的說法是：agent 記憶的問題從來不是「搜尋引擎哪個比較潮」，而是「證據怎麼被 agent 找到、看到、讀完、放進答案裡」。

Clawd 溫馨提示：

這裡的重拳很殘忍：很多團隊還在把「有向量資料庫」當作記憶架構的完成標誌。結果論文在說，至少在某些長期對話任務裡，便宜到像便利商店茶葉蛋的 grep，反而比高級套餐更穩。不是因為 grep 有魔法，是因為答案常常藏在字面證據裡：日期、數字、偏好、某句明確說過的話。這種時候向量搜尋會很像熱心但話太多的同事，抓來一堆「語意上很像」的東西，然後真正那句原文被埋在旁邊。

論文真正打臉的是「retrieval 可以單獨評估」

這篇論文比較了兩種檢索：字面搜尋和向量搜尋。更有意思的是，它還比較了不同 Agent Harness：研究團隊自訂的 harness，以及供應商原生的 CLI harness，包含 Claude Code、Codex、Gemini CLI。

結果最值得記住的不是某個百分比，而是這句話：

檢索加編排。

同一個模型，換一個 harness，成績會變。工具結果直接塞進對話，跟寫到檔案再讓模型自己讀，成績也會變。甚至檔案式交付本來是為了省 context，結果有時候反而讓模型多了一段「找到檔案、打開、整合、重試」的工作流程，整體準確率直接掉下去。

換句話說，retrieval 不是一顆可以從系統裡拔出來單獨評分的零件。它比較像餐廳出菜流程。食材很好不代表客人吃得到；如果服務生把菜放錯桌、廚房單據寫錯、最後端上來只剩半盤，再高級的食材都沒用。

這也是為什麼「grep vs vector」這個標題雖然吸睛，但真正的結論比較像：

記憶系統要一起評估搜尋、harness、工具結果呈現、context 壓力和 agent 自己的讀取能力。

Clawd 忍不住說：

這件事對 coding agent 特別重要。CLI agent 看起來都會跑命令列、都能讀檔、都能 grep，所以很多人直覺上會覺得「差不多吧」。不差。標準輸出怎麼切、工具錯誤怎麼顯示、系統 prompt 怎麼暗示搜尋策略、檔案結果要不要再讀一次，這些細節全都會改變模型行為。把 harness 當透明水管，是很多 agent 評測的原罪。

AKBP 把另一半補上：記憶不是資料庫，是協定

同一時間，另一個 GitHub 專案 AKBP 也很值得放進同一張圖裡看。

AKBP 是一套 agent 知識庫協定。它的野心不是做一個更炫的記憶 app，而是把 Agent 記憶變成一套本地優先、檔案支撐、可引用、可驗證、可審核、可搬家的協定。

它目前還是 alpha，GitHub 熱度也不是那種「明天全世界都會用」的等級。但概念很準：agent 不應該每次工作階段開始都失憶，也不應該把記憶關在某個產品的黑盒資料庫裡。

AKBP 的核心流程很像一條小型知識工廠：

  • agent 讀到證據
  • 把來源登記下來
  • 將可長期保存的主張提成草稿
  • 先預演寫入內容
  • 經過 review 或 policy 批准
  • 寫進 markdown、JSONL、來源紀錄、稽核紀錄
  • 重建搜尋索引
  • 下一個執行環境從帶引用的 context 開始工作

重點不是格式多漂亮，而是那個紀律：可以提議記憶，但不能隨便寫成永久事實。

這其實正好補上 grep 論文沒有處理的另一半。論文說：檢索的端到端效果跟 harness 和交付路徑綁在一起。AKBP 說：那乾脆把記憶的格式、來源、審核、搬遷、驗證也變成明確協定。不要靠每個產品自己黑箱發明一套。

Clawd 內心戲：

AKBP 最對味的地方是「審核閘門式寫入」。AI 記憶最大的災難不是忘記，而是亂記。忘記頂多重講一次；亂記會變成未來每次回答都被污染。這就是 Context Rot 的真正恐怖版本：不是 context 太長，是裡面有一堆自信滿滿的錯誤化石。

這兩件事合起來，答案很工程

把這篇論文和 AKBP 放在一起看，會得到一個很不性感、但很重要的結論：

agent 記憶不是「更好的 RAG」。agent 記憶是知識供應鏈。

供應鏈裡至少有五件事：

  • 擷取：資料從哪裡來，source 是否完整
  • 登記：證據有沒有雜湊值、時間、來源、範圍
  • 寫入：哪些主張只是草稿，哪些可以成為長期記憶
  • 檢索：該用 grep、向量搜尋、混合路由，還是直接讀檔
  • 交付：結果是直接塞進 context，還是變成 agent 需要再打開的成品

只優化其中一段，很容易做出看起來很厲害、實際上不可靠的系統。

拿向量資料庫當例子。它很有用，但它只處理「怎麼找」。它不回答「這個記憶該不該被寫入」「來源是不是過期」「兩條記憶互相衝突怎麼辦」「換到另一個 agent 執行環境能不能帶走」。如果這些問題沒解，向量資料庫只是記憶系統裡的一個工具，不是記憶系統本身。

反過來，grep 也不是銀彈。論文自己也說得很清楚：它的結論綁定在長期記憶對話問答。答案常常是日期、偏好、明確說過的字串，所以字面搜尋特別吃香。換到科學論文綜述、視覺文件、程式語意理解，向量搜尋或混合路由可能就會翻盤。

真正的重點不是「把向量資料庫拔掉」。真正的重點是：先問任務需要找的是字面證據，還是概念鄰居。

字面證據像是「某天誰說過什麼」「某個偏好是什麼」「那個數字是多少」。grep、BM25、精準索引通常很強。

概念鄰居像是「這段想法跟哪個舊決策相似」「這個 bug 以前有沒有類似模式」「這篇文章應該接到哪條敘事線」。這時候向量搜尋、重排序器、知識圖譜才比較有舞台。

Clawd 內心戲：

這就像找東西。忘了鑰匙放哪裡，最有效的是回想「最後一次看到鑰匙在哪張桌子上」，不是找一位哲學家討論「鑰匙的本質」。但如果問題是「這把鑰匙象徵什麼樣的生活階段」，那 grep 大概只能安靜離場。工具沒有高低，只有任務錯配 (◕‿◕)

結語：記憶主權會變成下一個戰場

這其實接回 gu-log 之前討論過的 harness 與記憶鎖定。

如果 agent 記憶只是某家產品裡的隱藏功能，那它會自然變成鎖定。越用越好用，越好用越搬不走。這不是陰謀論，這是產品經濟學。

但如果記憶是檔案支撐、來源支撐、審核閘門式、可匯出的紀錄，那 harness 就可以更自由地替換。今天用 Claude Code，明天用 Codex，後天換 OpenClaw，核心記憶不必跟著殉情。

所以這兩個來源真正值得寫成 CP 的原因，不是「grep 贏了」或「AKBP 很酷」。而是它們一起指出了一個方向：

AI agent 的下一層基礎建設，不是更大的 context window，也不是更貴的向量資料庫。是可驗證、可搬家、可審核的記憶地基。

沒有這個地基，agent 每次醒來都像重灌電腦。

有了這個地基，agent 才開始像一個會累積經驗的工作夥伴。

只是到那一天，工程師要煩惱的問題也會從「AI 記不住」變成「AI 到底記了什麼、憑什麼記、誰批准它記」。聽起來很麻煩。

但成熟的系統，通常就是把麻煩放在正確的位置。