エージェントメモリをファイル形式に：パイプラインを捨ててMarkdownを使う

ほとんどのAIベンチマークは、エージェントを空白のコンテキストウィンドウから開始する。実際のエージェントはそうあるべきではない。過去のやり取りから蓄積された関連情報であるメモリから開始すべきだ。しかし、現在のエージェントメモリシステムは過剰に設計され、期待に応えられていない。

壊れたメモリの3つのタイプ

Cal Paterson氏は、それぞれに欠陥のある3つの一般的なアプローチを挙げている：

• ハーネス依存型：特定のベンダーのプラットフォームに縛られ、会話履歴をマイニングする。メモリは世界についてではなく、ユーザーについてのものになってしまう。
• 過度に複雑なもの：何を記憶に値するか判断するためにpgvector、Neo4j、専用のLLMを必要とするシステム。モデルを混乱させ、フロンティアとともにスケールしない。
• ハイモダニズム型：グラフベースの合理主義的なメモリで、コンテキストを剥ぎ取り、エージェントにとって無意味な孤立した「事実」だけを残す。

共通点：メモリをプロセスとして扱うこと。Paterson氏は、それはデータ形式であるべきだと主張する。

Memoryfield：ポータブルなファイル形式

memoryfieldは、Markdownページ（オプションのYAMLフロントマター付き）と、セマンティック検索用のオプションのSQLiteベクトルインデックスを含むzipアーカイブである。それだけだ。パイプラインも、グラフも、ベンダーロックインもない。

チャンクよりも散文

RAGパイプラインは、レガシードキュメントをエージェントが理解できるようにするために存在する。しかし、メモリはエージェントによって、エージェントのために書かれる—だから、直接散文を書かせればいい。チャンキングも、エンリッチメントも、二重要約も不要だ。ページにはベクトル埋め込みに収まるように約8KB（約2000トークン）のソフトリミットがあるが、これは妥当な制約だ。

グラフウォーキングではなくセマンティックジャンプ

Karpathyウィキ（ハイパーリンクされたMarkdownファイル）では、エージェントがナレッジグラフをたどり、シリアルなツールコールを行う必要がある。これは遅く（Nレベル深いとN+1回のコール）、信頼性が低く（エージェントはリンクテキストで関連性を判断し、脱線を見逃す）、ノイズが多い（無関係なページがコンテキストを汚染する）。セマンティック検索は、すべての関連ページに並行して直接ジャンプする—最大2回のツールコールで済む。

メカニズムよりもモデル

複雑なAPIは、エージェントにインターフェースの迷路をナビゲートさせる。ファイル形式は、エージェントにアクセスパターンを発明する自由を与える—perlでの一括編集、SQLiteでクエリされるCSVファイルの埋め込みなど。モデルが向上するにつれて、自然により良いメモリを書くようになる。固定されたAPIエンドポイントではそれはできない。

オープンな形式、交換可能

仕様はRFCスタイルで、特定の埋め込み関数に依存しない。標準形式はzipファイルだが、ローカルファイル、S3、GitHub、HTTPから提供できる。Paterson氏は個人用メモリにSyncthingを、共有用にS3を使用している。

始め方

仕様を取得して実装を雰囲気で作るか、提供されているツールを使用する：ollama pull nomic-embed-text、uv tool install git+https://github.com/calpaterson/memoryfield-tool、npx skills add calpaterson/memoryfield-skill -g -y。

ファイル形式としてのメモリ—シンプルで、ポータブルで、モデルに依存しない。エージェントインフラストラクチャの複雑性の増大に対する爽快な解毒剤だ。