LoreKit、AIエージェントのための標準化されたメモリ形式を提案

現在のAIエージェントのメモリは、`CLAUDE.md`のようなMarkdownファイルから、JSONLナレッジグラフ、ホストされたリポジトリの事実まで、少なくとも4つの異なる形式に断片化されています。これらの形式は互換性がないため、あるツールで学習したCIエージェントの教訓を別のツールにあるエディターエージェントがアクセスすることができず、複数のAIツールを使用する開発者にとってサイロ化された体験を生み出しています。

エージェントメモリの断片化

AIエージェントのエコシステムが成長するにつれ、開発者は独自のスキーマとストレージ方法を備えた独自のメモリレイヤーを構築しています。これらにはローカルファイル、名前空間付きストア、時間的ナレッジグラフが含まれますが、これらのシステムはいずれもネイティブに互いに通信することができません。

LoreKitの著者は、問題はツールの不足ではなく、共有の合意の欠如であると主張しています。共通のデータモデルがなければ、新しいソリューションが追加されるたびに、ツール間でのコンテキスト共有を妨げる別の孤立した形式が追加されることになります。

OpenTelemetryモデル

この提案は、オブザーバビリティ業界と直接的な類似点を持っています。2019年以前、異なるベンダーは独自のインストルメンテーションライブラリとデータ形式を出荷しており、ユーザーはプロバイダーを切り替えるたびにコードの再インストルメンテーションを強いられていました。

業界はこの問題をOpenTelemetryへの統合によって解決しました。OpenTelemetryは、スパン、メトリック、ログレコードが何であるかを標準化し、共有の名前（セマンティック規約）と共通のプロトコル（OTLP）を確立しました。これにより、ツール全体のエコシステムが、ストレージや分析で競合しながらも、互いのデータを読み取ることが可能になりました。

記事では、提案が断片化を解決するためにオブザーバビリティ業界のOpenTelemetryへの移行と直接的な類似点を持っていることを説明しています。

エージェントのメモリは現在、同様の状態にあり、形式が定着する前に標準化できるほどまだ新しい段階にあります。

エクスポート vs ライブ・アドレッシング

提案では、2つの主要な問題である「エクスポート」と「ライブ・アドレッシング」を区別しています。エクスポートとは、ユーザーのメモリをあるベンダーから別のベンダーへ移動することを指し、Open Memory Protocolのようないくつかの既存の草案がこの解決を試みています。

ライブ・アドレッシングは、CIジョブ、エディターエージェント、およびレビューボットが同時に同じリポジトリで動作することを可能にする、より複雑な課題です。共有の仕様は、これらのツールがリアルタイムでメモリレコードの意味について合意できる共通の「アドレス」（例：特定のリポジトリやブランチ）を提供します。

この視覚資料は、議論されている2つの主要な問題、すなわちツール間でのデータ移動とリアルタイムの共有アクセスを明確にしています。

提案されるアーキテクチャとトレードオフ

提案されるレコードには、一意のID、スコープ（アドレス）、キー、ライフサイクル（有効期限）、およびメモリを作成したのが人間かエージェントかを識別する「written_by」フィールドが含まれます。この構造により、ツールは情報の起源に基づいて、その情報をどの程度信頼するかを決定できます。

記事では、相互運用性を促進するために提案されるレコードに含まれる特定のフィールドについて説明しています。

批評家は、共有標準が「時期尚早な抽象化」である可能性や、プロンプトインジェクションのリスクを指摘しています。提案では、署名を含め、レコードを特定のコードバージョンにリンクさせることでこれらのリスクを軽減することを提案していますが、どのレベルのアドレス（例：リポジトリ vs ブランチ）を標準化すべきかは依然として未解決の課題です。