AI Agent記憶層開戰：三個開源專案接連搶攻 coding agent 持久記憶
近期，三個不同團隊各自推出 AI coding agent 的開源記憶方案。記憶層正在變成標準配備，真正的戰場是記憶檔存在誰的機器上。
本文發稿日是 2026 年 9 月 7 日。三個專案分別是 okf-memory/okf-agent-memory、tigerless-labs/agent-memory，以及 Hugging Face 部落格發表的 Funes。接連出現三個獨立方案，加上部分主流 agent 工具據稱也已內建自動記憶（本文來源未涵蓋各家官方細節，不在此評述），說明「讓 agent 記住東西」已經從個別巧思變成一波真實需求。
AI coding agent 為什麼一換對話就把教過的規矩忘光？
因為大型語言模型本身沒有長期記憶，它只記得當前對話視窗裡的內容。視窗一關、模型一換，先前教過的規矩、客戶的脾氣、專案的架構決策全部歸零，除非有人把它們寫到模型之外的地方存起來。
對話視窗（context window）白話講就是模型一次能「看在眼裡」的文字量，有上限，關掉就沒了。okf-agent-memory 的 README 第一句就點出這件事：與 AI agent 的對話會在視窗關閉時重置，架構決策、領域發現與營運事實若不持久儲存就會流失（來源）。
過去的做法有兩種。一種是手寫一份 CLAUDE.md 或 AGENTS.md 放在專案根目錄，agent 開工時整份讀進去；另一種是接向量資料庫，把過往內容轉成數學向量後做語意檢索。前者簡單但一長就塞爆視窗，後者強大但要養資料庫、付嵌入 API 費用。okf 專案自己的定位，就是填補「零散手寫檔」與「黑盒向量資料庫」之間的空缺（來源）。
近期這三個記憶專案各自在做什麼？
三者的共同點是把記憶存成純文字 Markdown 檔，放在你自己的 repo 或本機目錄；差別在檢索方式、整理機制與實作語言。
okf-agent-memory 用純 Go 寫成，自述以 Google 的 OKF v0.2（Open Knowledge Format，一種給 agent 知識用的開放 Markdown 加 YAML 表頭格式）為基礎。記憶放在 repo 的 knowledge/ 目錄，每則是一個帶 YAML 表頭的 Markdown 檔，表頭記錄來源、信任層級（generated 或 verified）與生命週期（status、stale_after）。檢索用 BM25，也就是傳統關鍵字排序演算法，完全在本機記憶體內跑，專案宣稱搜尋延遲低於 300 微秒、整個語料庫圖驗證約 4 毫秒、單一執行檔零外部依賴、記憶體佔用 15 MB，並內建 MCP 伺服器（Model Context Protocol，讓 agent 用標準協定呼叫工具的介面）。它另外主張「漸進揭露」與「先搜尋再寫入」兩條規則，前者靠分層 index.md 讓 agent 只載入需要的概念，後者要求寫新記憶前先查有沒有重複，專案宣稱可減少 80% token 消耗（來源）。截至 9 月 7 日，這個 repo 有 369 顆星、18 個 fork，但只有 3 個 commit，非常新。
tigerless-labs/agent-memory 從專案檔案結構推斷是用 Python 寫成（repo 內有 pyproject.toml 與 uv.lock，README 本身沒有明講語言），自稱「本機優先、不綁 agent 的長期記憶執行環境」。它有幾條寫得很硬的不變量：Markdown 檔是唯一真相，旁邊的 SQLite 索引只是快取，整個刪掉再重建保證零知識損失，而且這是用測試強制、不是文件承諾；寫入在對話邊界觸發，不由 agent 自己決定；另有一個獨立於對話之外、在「睡眠時間」跑的 Manage 整理層，可以新增與更新，但刪除只會以提案形式送給你確認；更新舊記憶用 supersede 保留鏈條（supersede：新記憶取代舊記憶但保留修改紀錄，不直接覆寫），可以用 recall --as-of 查某個日期當時的答案。函式庫內不含任何 LLM 客戶端，不用裝金鑰，判斷借用宿主 agent 自己的 CLI；Claude Code、Codex CLI 以及任何能跑 shell 指令的 agent 共用同一個 store（來源）。截至 9 月 7 日有 364 顆星、23 個 fork、72 個 commit。
Funes 是 Hugging Face 在官方部落格發表的方案（來源）。本文撰寫時未能取得該文全文摘錄，設計細節以官方頁面為準，這裡不代為轉述。
git-native 記憶跟廠商雲端記憶，差在哪？
差在記憶檔的所有權，以及能不能逐筆查核。git-native 記憶是你 repo 裡的純文字檔，可以用 git diff 逐筆檢視、可以整個目錄搬走；存在廠商雲端或專屬資料庫的記憶，換工具就得重教一遍。
下表把四種做法放在一起看。向量資料庫那欄的數字來自 okf 專案自家的效能比較表，尚未經第三方複驗，請當量級參考而非定論。最右欄「工具內建記憶」指部分主流 agent 工具據稱內建的記憶功能，本文來源未涵蓋其官方細節，各格只能寫「依各家設計」。
| 比較項 | 手寫 CLAUDE.md / AGENTS.md | git-native 記憶（okf、agent-memory） | 向量資料庫記憶（Mem0、Letta 類） | 工具內建記憶（部分主流工具據稱內建，官方細節未查證） |
|---|---|---|---|---|
| 記憶存放位置 | 專案根目錄一個檔 | repo 或本機目錄，一則一檔 | 外部資料庫服務 | 依各家設計，需查該工具文件確認 |
| 可否用 git diff 逐筆查核 | 可 | 可，且為核心賣點 | 不可，資料在資料庫內 | 視存放方式而定 |
| 檢索方式 | 整份載入視窗 | 本機 BM25 關鍵字檢索加索引分層 | 語意向量檢索 | 依各家設計 |
| 額外服務與費用 | 無 | 無，okf 宣稱每千次查詢零 API 成本 | okf 引述約每千次查詢 0.10 至 0.50 美元嵌入費用 | 依各家設計 |
| 換工具可攜性 | 高 | 高，agent-memory 明示 Claude Code 與 Codex CLI 共用 | 低，需匯出轉換 | 通常只在該工具內有效，需查該工具文件確認 |
| 誰負責整理過期記憶 | 你手動 | agent-memory 有獨立 Manage 層；okf 靠 stale_after 標記 | 依產品 | 依產品 |
效能面，okf 自家量測的對比是：概念搜尋延遲，Python 加向量資料庫方案 150 到 800 毫秒、Deno / Node.js 工具 40 到 120 毫秒、okf 約 300 微秒；冷啟動，Python 250 到 600 毫秒、okf 4 毫秒（來源）。這些數字說明的是「本機關鍵字檢索比呼叫嵌入 API 快好幾個量級」，這個方向性結論站得住；至於精確數字，專案附了 make benchmark 讓你在自己機器上重跑，沒跑過之前別直接引用。
有記憶的 agent 真的比較會答嗎？數據怎麼說？
本文取得的來源摘錄裡，沒有任何一個專案公布「有記憶」對「無記憶」的答題正確率對照數字。目前能引用的只有 okf 自家的效能表，而且量的是速度與成本，不是答得對不對。
okf 宣稱的 80% token 減少與首字延遲（TTFT）加速，目前只有專案內附、要在自己機器上跑的 benchmark 工具，沒有公開的第三方或對照組數字，我把它列為「宣稱」而非「結果」（來源）。agent-memory 的 README 目錄列有 Experiments 一節，但本文未取得其內容，這裡不代為轉述。
所以「有記憶的 agent 比較會答」這件事，邏輯上站得住，數據上還沒有人替你驗過。最實在的做法是拿自己專案的問題各跑一輪，記下有無記憶層時答得對不對。
這對台灣中小企業意味著什麼？
意味著「AI 學會的東西」第一次可以當公司資產來管。老闆選 agent 工具時要多問一句：我的記憶檔在誰的機器上，能不能整個目錄拷走。答不出來的工具，教得再多都是幫別人養資料。
第一，沒有 IT 團隊的公司，不該養向量資料庫。 一家十人以下的公司，通常沒人能維運資料庫、處理嵌入 API 的帳單與版本升級。純文字加 git 是唯一你自己維護得動的形式，出事了任何人打開檔案就看得懂。
第二，客服語氣、SOP、客戶脾氣就是商業機密。 你花三個月教 AI 「這位客戶不喜歡被催、那類產品不能承諾交期」，這些是公司的 know-how。存在廠商雲端，你就把 know-how 的實體交到對方手上；這與廠商是否可信無關，是資料主權的問題。
第三，選工具時用三個可執行的判準：
- 記憶能不能用 git diff 逐筆看到改了什麼？看不到就無從查核 AI 到底學了什麼。
- 把索引刪掉，知識會不會不見？agent-memory 用測試保證零損失，這是好的門檻。
- 刪除記憶是否需要人確認？agent-memory 把刪除做成提案制，符合「人只做閘門點頭」的治理原則。
第四，反面的話也要講：現在導入還太早。 okf 只有 3 個 commit，agent-memory 有 72 個，okf 依賴的格式標準 OKF v0.2 也還在 0.x 版。半年內格式或指令改動的機率很高，現在押注哪一家勝出，代價是要跟著改。
所以我們的建議是先做永遠不會白做的那一半：把規矩寫成 Markdown 檔，一則一檔，放在自己的資料夾或 repo。我們自己的分身系統就是這樣運作的，規矩、決策、學習全是純文字檔存在 repo 裡，工具換過幾輪，那些檔案一個字都沒重寫。
現在該怎麼選、怎麼開始？
分三步：先盤點已經教過 AI 三次以上的規矩並寫成檔，再依有無工程師決定用工具本身的內建記憶還是外掛記憶層，最後只在多 agent 共用或需要查核時才導入 okf 或 agent-memory 這類工具。
| 你的情況 | 建議做法 | 理由 |
|---|---|---|
| 一人公司、無工程師 | 手寫 Markdown 規矩檔，加上工具本身若有的內建記憶，檔案放自己的資料夾 | 零維運成本，換工具檔案帶著走 |
| 有一位工程師、單一 agent | 手寫規矩檔為主，觀望三個月再選記憶層 | 標準未定，先避開重工 |
| 多個 agent 共用、需查核 AI 學了什麼 | 試 tigerless-labs/agent-memory | 明示 Claude Code 與 Codex CLI 共用 store，刪除採提案制 |
| 重視檢索速度、偏好單一執行檔零依賴 | 試 okf-agent-memory | 純 Go 單一檔案、內建 MCP 伺服器，但 commit 數極少要自負風險 |
立場講明白：記憶層一年內會變成 coding agent 的標配，這波值得你現在就把規矩寫成檔；但不值得現在押注哪個標準會贏。檔案在自己手上，誰贏都不怕。
同樣的邏輯也適用在對外內容：AI 引擎記不記得你的公司、引用時說得對不對，取決於你的內容是否寫成 AI 好抽取、可查證的形式。想知道你的網站現在在 AI 答案裡被怎麼記住，可以到 mingnow.airun.tw 看一次體檢結果。
常見問題
AI coding agent 怎麼記住我之前教過它的規則和習慣？
把規則寫進模型之外的檔案，讓 agent 每次開工先讀。最基本是專案根目錄的 CLAUDE.md 或 AGENTS.md；進階則用 okf-agent-memory 或 agent-memory 這類工具，把記憶拆成一則一檔的 Markdown，開工時只載入索引，需要時再用關鍵字檢索取出對應內容。
git-native 記憶是什麼意思？
指 AI 的記憶以純文字檔存在你的程式碼倉庫（repo）裡，跟程式碼一起用 git 做版本控制。好處是每一筆記憶的新增、修改都能用 git diff 看到、能回溯、能整個目錄搬到別的工具，而且不需要額外的資料庫或雲端服務。
這些記憶工具需要付 API 費用嗎？
兩個 GitHub 專案都標榜不用。okf-agent-memory 用本機 BM25 關鍵字檢索，宣稱每千次查詢零 API 成本；tigerless-labs/agent-memory 的函式庫內沒有 LLM 客戶端，不用裝任何金鑰，判斷交給宿主 agent 本身的 CLI。你仍要付宿主 agent（如 Claude Code）本身的費用。
部分主流工具據稱已內建自動記憶，還需要這些工具嗎？
若你用的工具確實內建記憶（本文來源未涵蓋各家官方細節，請以該工具的官方文件為準），小型個人專案通常不需要再加一層。當你要讓 Claude Code 和 Codex CLI 等多個 agent 共用同一份記憶、要用 git 逐筆查核記憶變動、或要把記憶帶著走時，才值得多加一層。tigerless-labs/agent-memory 明確以「多個 agent 共用一個 store」為設計目標。
中小企業沒有工程師，可以用嗎？
可以先做一半。把客服語氣、SOP、常見客訴處理原則寫成 Markdown 檔放在自己的資料夾，這一步不需要工程師，也不會因為換工具而白做。okf 與 agent-memory 都要跑指令列安裝與設定，建議等有人能維護時再導入，或請外部顧問一次架好。
AIRUN 對抗式創業體檢 AgentFlow Solutions（双云行銷試運行）