5 月 18 日，他寫了一篇長文，推薦 agentmemory 作為 AI coding agent 記憶問題的答案。5 月 23 日，同一個人發了另一篇：我收回。
一句話結論：agentmemory 是目前最紅的 AI coding agent 記憶工具（GitHub 約 25,000 星），但它的 hook 曾長期讀錯 Claude Code 的回傳欄位，導致約 47% 工具呼叫靜默不入庫；用之前務必自己驗一次有沒有真的存到。
中間隔了一個星期的實際使用。Fabio Akita 是巴西 Ruby 社群的老牌開發者，他把 agentmemory 放進自己的日常工作流跑了一週，然後逐條列出五個問題、附上 GitHub issue 編號，最後用 Rust 重寫了一個。
這篇不是要你換工具。是要你檢查一件事：你以為在幫你記東西的那個服務，真的有把東西寫下來嗎？
agentmemory 到底是什麼？
它是給 AI coding agent 用的持久記憶層。你關掉 Claude Code，下次再開，它記得上次做到哪、試過什麼失敗方法、為什麼否決了某個方案。
作者是 Rohit Ghumare。專案 2026 年 2 月 25 日建立，5 月 12 日首次衝上 GitHub Trending 第一名。截至 2026 年 8 月 19 日，GitHub 上顯示約 25,000 顆星、2,100 個 fork。它用 TypeScript 寫，Apache-2.0 授權，一行 npx 就裝得起來，接 Claude Code、Codex、Cursor、Gemini CLI、OpenCode，官方數字是 12 個 hook、51 個 MCP 工具，在 LongMemEval-S 上跑到 95.2% R@5。
數字很漂亮。問題不在 benchmark 上。
那 47% 是怎麼消失的？
這是 Akita 那份清單裡最值得單獨拿出來講的一條。
agentmemory 靠 hook 去接 Claude Code 的事件。每次 agent 用完一個工具，Claude Code 會把結果丟回來，hook 負責接住並寫進資料庫。
但 hook 讀的欄位叫 data.tool_output，而 Claude Code 實際送出來的欄位叫 tool_response。
欄位名字對不上，讀出來就是 undefined。不會報錯，不會警告，那筆觀察就當沒發生過。
按 Akita 的說法，這影響了大約 47% 的 Claude Code 工具呼叫，而且持續了六個星期才被發現（agentmemory issue #539）。六個星期裡，使用者以為自己在累積一份完整的專案記憶，實際上接近一半的內容從來沒有進去過。
靜默失敗比崩潰難處理，原因就在這裡。程式當掉你會知道，你會去修。寫不進去但一切看起來正常，你只會在三個月後問「為什麼它不記得我們討論過這個」，然後以為是 AI 太笨。
另外四個問題是什麼？
Akita 在 2026 年 5 月 23 日那篇 post-mortem 裡列了五條，都附了 issue 編號：
| 問題 | 實際後果 | Issue |
|---|---|---|
| hook 讀錯欄位 | 約 47% Claude Code 工具呼叫沒入庫，持續六星期 | #539 |
| 每次重啟重建 BM25 索引 | 超過 1 萬筆觀察後 state::set 逾時，索引檔停在約 96 個空位元組，每次重啟花約 5 分鐘重建 | #309（仍開啟） |
| 5 秒資料遺失窗口 | 寫入走 5 秒 debounce，30 秒逾時一炸，Node process 連同記憶體內容一起死掉 | #204 |
| 同一份程式兩套設定讀取路徑 | process.env 和 getMergedEnv() 並存，「我改了環境變數但沒反應」 | #456 |
| 引擎從呼叫端的工作目錄啟動 | Windows 使用者每開一個終端機就換一個資料位置，以為記憶不見了 | #303（仍開啟） |
Akita 自己的結論寫得相當克制，這句值得原文引一次：
「問題的形狀是結構性的，不是維護者不夠努力。」
他指的是架構本身：TypeScript MCP 加上獨立的 iii-engine Rust binary，4 個 port、3 個 process、索引放在記憶體再透過遠端 KV 持久化。這種組合會不斷長出同一類 bug，而修完一個還會再冒一個，除非把系統重寫一半。
三個月過去了，修好了嗎？
這是我自己去查的部分，因為只引用一份三個月前的抱怨文並不夠。
2026 年 8 月 19 日，agentmemory 的 GitHub issue 頁面顯示 183 個開啟中的 issue、191 個待處理 PR。翻開最近幾個月使用者回報的內容，同一類問題還在：
- #1047（7 月 11 日）— PostToolUse 等 hook 在 payload JSON 為 null 時直接 crash，原因是沒有防護的
data.xxx存取。跟 #539 是同一個家族的問題。 - #1029（7 月 7 日）— 重啟之後 LLM drain 卡住，回報者列了 6 個未解決狀況。
- #1025（7 月 7 日）— 1,867 筆觀察卡在 synthetic 狀態，處理吞吐量掉了 16 倍。
- #1024（7 月 7 日）— 跑了 11 小時，只有 33% 完成 LLM 壓縮。
- #1030（7 月 7 日）— 207 筆觀察被標記成已完成，但缺少 compressionKind 欄位。
- #1021（7 月 6 日）— 中日韓文字和混合語言的去重會漏掉重複記憶。
最後那條要特別點出來。如果你的專案討論是中文，或者中英夾雜（大部分華語圈開發者都是），agentmemory 的去重邏輯目前可能認不出兩筆其實一樣的記憶。結果是同一件事在 wiki 裡存了好幾份互相矛盾的版本，而 agent 不知道該信哪一份。英文使用者不太會踩到這個，你會。
Akita 重寫的那個版本，做了什麼不一樣的選擇？
先講清楚規模，免得你有錯誤期待：ai-memory 在 2026 年 8 月 19 日只有 31 顆星、1 個 fork、94 個 commit，作者自己標明是 beta，還沒有正式 release。它不是 agentmemory 的替代品，現階段更像是一份「如果重來一次會怎麼設計」的實作說明。
但它的取捨值得看，因為每一個都對應到上面某個 bug：
| 設計決定 | 要解掉的問題 |
|---|---|
| 單一 Rust binary（Rust 佔 91.9%），不再有遠端 KV | 3 process、4 port 的協調失敗 |
| SQLite + FTS5 原生持久化索引 | 每次重啟重建索引 |
| 單一寫入執行緒，透過 mpsc 排隊 | 5 秒遺失窗口、database is locked |
| 純 markdown 存在磁碟上當真相來源，SQLite 只是衍生索引 | 資料被鎖在專有格式裡，出事撈不回來 |
| 每個專案用 UUID 隔離目錄 | 同名頁面互撞、刪除誤傷隔壁專案 |
| LLM 為選配，不給 key 也能用 FTS5 搜尋 | 沒有 API key 就整套不能動 |
markdown 當真相來源這條最實際。wiki 是一個 git repo，你可以 grep、可以用 Obsidian 開、可以 rsync 備份、可以 git log 回溯。哪天工具不維護了，你的資料還在，而且是人看得懂的格式。
概念上它跟我們之前寫過的分層式 AI 記憶架構是同一條路：不要把所有東西塞進一個向量資料庫，而是分層、分類、按需取用。
要不要接 LLM？哪一個最划算？
這部分是整個專案裡我覺得最有轉用價值的資料，跟你用哪個記憶工具無關。
把 session 觀察壓縮成 wiki 頁面這件事，需要一個 LLM。Akita 拿 6 個 provider 對 5 組刻意設計的測試案例跑了 A/B，測的是「會不會亂編頁面」「分類準不準」「主題會不會混在一起」：
| 模型 | 每次成本 | 延遲 | 結論 |
|---|---|---|---|
| Claude Haiku 4.5 | 約 $0.02 | 7 秒 | 選定的預設值。分類最準，最懂得克制 |
| GPT-5.4-mini | 約 $0.005 | 4 秒 | 便宜 5 倍快 2 倍，偶爾過度分類 |
| qwen3:32b（本地 Ollama） | $0 | 92 秒 | 需要約 24GB 記憶體，延遲在背景跑不影響體感 |
| DeepSeek V4 Flash | 約 $0.005 | 22 秒 | 可用，但沒有勝過 GPT-mini 的地方 |
| Sonnet 4.5 | 約 $0.06 | 11 秒 | 被 Haiku 取代，3 倍成本且較常編造細節 |
| Kimi-K2.6 | — | 卡死 | 不適用 |
兩個可以直接帶走的判斷。
第一，這類「文字進、文字出」的整理工作不需要旗艦模型。Sonnet 花三倍錢，結果還比 Haiku 更容易編造細節。貴不等於準。
第二，推理模型在這裡是負分。Kimi-K2.6 直接卡死，原因是推理型模型會把 token 預算先花在內部思考上，配合嚴格 JSON 輸出的提示詞，最後吐不出可解析的內容。同樣的狀況也會發生在開了 extended thinking 的 Claude、GPT-o3、Gemini 的 thinking 變體上。要用的話，把推理關掉。
你現在該做什麼？
如果你已經在跑 agentmemory 或任何 hook-based 的記憶工具，花十分鐘做這四件事：
- 驗證真的有寫進去。開一個 session，講一件很特別、不可能出現在別處的事（例如「我們決定把快取 TTL 設成 1,337 秒」）。結束 session，重開，問 agent 這件事。答不出來就是沒存到。
- 數一數筆數對不對。看它記錄了多少筆觀察，跟你這個 session 實際用了多少次工具比一比。差距接近一半，就是踩到 #539 那類欄位錯配。
- 中文專案要多查一步重複。因為 #1021 還開著，搜一個你討論過很多次的中文主題，看看是不是同一件事存了好幾份不一致的版本。
- 確認資料撈得出來。找到實際存放的位置，確認你能在不啟動那個工具的情況下讀到內容。讀不到，代表你的專案記憶被綁在一個你不能檢查的黑盒裡。
如果你還沒開始用，那就先問自己一個更前面的問題：你是不是真的需要。Akita 自己的答案是——如果你只用一個 agent 而且不換，大概不需要。Claude Code 有三層壓縮、Codex 有 auto_compact_token_limit、opencode 有 anchored compaction，各自在 session 內都處理得不錯。真正需要外部記憶的，是像他那樣在同一個專案裡跳來跳去的人：Claude Code 卡住就開 Codex 換個思路，然後再回 Claude Code 實作。
只用一個工具的話，一個 docs/ 資料夾加上「重要的事叫 agent 寫進去」的習慣，已經解掉八成問題。這需要紀律，但不會靜默丟資料。
這件事真正的意義是什麼？
25,000 顆星沒有防止一個影響一半資料的 bug 活六個星期。這不是在說 agentmemory 不好，也不是說星星沒有意義——它確實是這個領域跑得最前面的專案，社群回報活躍，作者也在修。
但星數量的是採用速度，不是正確性。而記憶類工具剛好是最難靠「感覺」驗證的一類：它出錯的方式是安靜的，而你唯一會注意到的症狀，是 AI 好像變笨了。
Karpathy 在他那份 LLM Wiki 筆記裡寫過一句，Akita 說這句是整個專案的起點：index.md 在大約 100 份來源、幾百頁的規模下「好用得出奇，不需要 embedding」。
記憶是文字。文字放在磁碟上。用 SQLite 索引它。值得的時候才用 LLM 整理它。沒人再看的就讓它淡出。
今天 OpenAI 才主動暫停了自己最大的訓練 run，理由是對安全的信心會決定發展速度。往下一層看，AI 工具鏈的其他部分也在補同一課：跑得快之外，還得先確定跑對方向。
常見問題
agentmemory 現在還能用嗎？
能。它仍然是這個領域最成熟、社群最大的選擇，約 25,000 顆星、持續在更新。但建議裝完之後自己驗一次資料有沒有真的寫入，不要預設它一定有在記。
ai-memory 可以拿來取代 agentmemory 嗎？
現階段不建議。截至 2026 年 8 月 19 日它只有 31 顆星、標示為 beta、沒有正式 release，作者自己說需要更多使用者幫忙找 bug。它適合想理解架構取捨的人，不適合放進你的主力工作流。
AI 記憶工具的整理工作，用哪個模型最划算？
依照 6 個 provider 的對比測試，Claude Haiku 4.5 在成本（約 $0.02 一次）、速度（7 秒）和分類準確度之間最平衡。預算緊可以用 GPT-5.4-mini，有本地機器可以用 qwen3:32b。不要用開了推理模式的模型，它們在嚴格 JSON 輸出下會卡死。
中文使用者要特別注意什麼？
agentmemory 的 issue #1021 指出中日韓文字和混合語言的去重會漏掉重複記憶，該問題在 2026 年 8 月 19 日仍未關閉。中文或中英夾雜的專案可能會累積多份互相矛盾的記憶，建議定期檢查。
本文資料截至 2026 年 8 月 19 日，GitHub 星數、issue 狀態與模型定價均可能變動。文中 agentmemory 的五個問題描述來自 Fabio Akita 於 2026 年 5 月 23 日發表的 post-mortem，issue 現況為本站於 2026 年 8 月 19 日自 GitHub issue 頁面查核。本文不構成任何投資建議。
發表迴響