グラフメモリ対マークダウン：なぜフラットファイルがスケール時にプロンプト負債になるのか

r/openclawの開発者は、AIエージェントのマークダウン方式のメモリシステムが、当初のクリーンな状態から「プロンプト負債」へと変化した経緯を語る。当初はエージェントメモリをマークダウンファイルとして保存するのが理想的に思えた——読みやすく、編集可能で、ベンダーロックインもない。しかし、80以上のファイルと500万文字を超えると、この方法は破綻した。実行のたびに「巨大なメモの山」をスキャンして、どの部分がまだ重要かを推測しなければならなくなった。

問題点：フラットテキストがプロンプト負債に

開発者が述べるように、「保存は解決されたが、メモリは解決されなかった」。プロジェクトの事実、古いバグ、決定事項、好み、そして中途半端な計画などがすべて、コンテキスト内で等しい重みを持つ塊として存在していた。エージェントはすべてを等しく関連性があるかのように再読しなければならず、パフォーマンスの低下とトークンの無駄遣いを招いた。

気づき：すべてのメモリではなく、関連するメモリだけを描画する

転機は、より良いノートブックではなく、エージェントが「現在のタスクに関連するメモリの部分だけを描画する」必要があると気づいたことだった。解決策はグラフメモリの採用：各メモリをノードとして保存し、関係性をエッジとして、取得は「このマップのどの部分を今照らし出すべきか？」というクエリに基づくものに。類似した上位10件のノートをコンテキストにダンプするのではなく、必要な情報だけを取り出す。

実践的な教訓

マークダウンはアーカイブやエクスポート形式としては依然として優れているが、長期エージェントメモリは規模が大きくなると純粋なテキスト形式のままでは持続できない。グラフベースの取得により、選択的なコンテキスト注入が可能になり、等しい重みのチャンクというフラットファイル問題を回避できる。エージェントのメモリが数十ファイルを超えて成長しているなら、生のテキスト結合ではなく、タスクに関連した取得のために構造化することを検討しよう。