開源代理工具
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ハンドシェイクも完了することが確認され、RSSは11.9 MBと測定された。例示された3,034 tokenから603 tokenへの約80％の削減も、計算上は正しい。ただし、これは主として関連文書を1件だけ読み込んだ効果であり、検索アルゴリズム自体による圧縮を意味するものではない。
パフォーマンス上の問題は、規模を拡大した際に表面化した。監査担当者が同じ関数を用いて合成ナレッジベースをテストしたところ、検索レイテンシの中央値は500概念で35～43ミリ秒、2,000概念で141～148ミリ秒、5,000概念では337～370ミリ秒に達した。原因は、現時点で転置インデックスが存在しないことにある。クエリのたびに各文書を再度トークン化し、語ごとに`strings.Contains`を使って全コンテンツを走査している。いわゆるBM25にも`k1`、文書長の正規化、単語頻度の飽和がなく、実態はフィールド重み付けとBM25 IDFを備えたTF-IDFに近い。
もう一つの正確性に関する問題は、Go mapのランダムな反復順序と不安定なソートに起因する。同点のスコアが存在する場合、監査担当者が15回連続で実行したところ、top-3の並び順は15通りになった。これは「再現可能な記憶」という中核的な約束を損なう。明るい材料としては、グラフ検証が5,000概念でも約1.3ミリ秒に収まり、フォーマット、情報源の追跡、Gitレビューの設計にも実用性がある。現段階では、小規模で人手により整理されたナレッジベースに用途を限定し、転置インデックス、安定したtie-breaker、独立した検索品質テストが導入されるのを待つのが望ましい。