開源代理工具
OKF Agent Memory 把代理記憶寫入 Git，但獨立測試發現搜尋延遲與排序穩定性問題
新開源工具以 Markdown、YAML、MCP 與本機文字檢索，讓程式代理的長期記憶可經 Git 審查。其輕量架構確實可用，但獨立測試顯示「低於 300 微秒」只適用極小資料集，且同一查詢可能回傳不同排序。
OKF Agent Memory 0.1 把架構決策、除錯結論及操作知識存進儲存庫的 `knowledge/` 目錄，以 Markdown 搭配 YAML frontmatter 記錄來源、`generated`／`verified` 信任層級及過期時間。純 Go CLI 可建立、驗證與搜尋概念，並透過 stdio MCP 暴露 `search`、`show`、`validate`、`create` 等工具，讓 Claude Code、Cursor 或 Codex 不必連接向量資料庫即可讀寫跨工作階段記憶。
專案主張以漸進揭露取代把整份知識庫塞入提示，並宣稱搜尋低於 300 微秒、記憶體低於 15 MB。獨立稽核確認程式可編譯、測試與完成 MCP 握手，量得 11.9 MB RSS；其範例由 3,034 token 降至 603 token 的約 80%縮減，算術也成立。然而這主要代表只載入一份相關文件，而非檢索演算法本身帶來的壓縮。
效能問題出現在規模放大後。稽核者以相同函式測試合成知識庫，500 個概念的搜尋中位數為 35至43毫秒，2,000 個為 141至148毫秒，5,000 個升至 337至370毫秒。原因是目前沒有倒排索引：每次查詢都重新切分每份文件，並為每個詞以 `strings.Contains` 掃描全部內容。所謂 BM25 也缺少 `k1`、文件長度正規化與詞頻飽和，更接近帶欄位權重及 BM25 IDF 的 TF-IDF。
另一個 correctness 問題來自 Go map 的隨機迭代順序與不穩定排序；分數相同時，稽核者連跑十五次得到十五種 top-3 排列。這會削弱「可重現記憶」的核心承諾。好消息是圖驗證在5,000個概念仍約1.3毫秒，格式、來源追蹤與 Git 審查設計也具實用性。部署者現階段宜限用於小型、人工整理的知識庫，並等待倒排索引、穩定 tie-breaker 及獨立檢索品質測試。