OpenClawエージェントのプレーンなMEMORY.md設定が時間的テストでMemory Startupのランタイムを上回る

r/openclawの開発者がメモリスタートアップからDMを受け、製品を壊してみてほしいと依頼された。テストは、同じ決定の3つのバージョンをエージェントに与え、現在のものを返すかどうかを確認するというもの。スタートアップのランタイムは失敗し、開発者のOpenClawエージェント——メモリがgitリポジトリ内のマークダウンに過ぎない——は合格した。

テスト

3つの決定が順番にスタートアップのランタイムに投入された：

• REST — 1月
• GraphQL — 4月
• tRPC — 8月

ランタイムはGraphQLを返した。3つすべてが関連性1.000で同点となった。検索パスがスキーマの時間的フィールドを実際に読んでいないからだ。

対照的に、OpenClawエージェントはtRPCを返した——日付付きで、古いバージョンはその上に取り消し線で示されていた。著者の言い分はこうだ：ランク付けするものは何もない、ファイルに書いてあることがすべてだ。

セットアップの様子

エージェントは7ヶ月間、3つのモデルと2つのベンダーをまたいで同じものを使っている。ストレージは決して難しくはなかった——書き込みルールは次の通り：

• MEMORY.mdはインデックスに過ぎず、事実は含まない。OpenClawは大きなブートストラップファイルを切り捨てるので、肥大化したものは静かに末尾を失う。
• すべての事実にはstated、observed、inferred、またはsuggestedのタグが付く。
• 推論された教訓がルールになるには、2つのセッションにまたがる3つのシグナルが必要。
• 変更された決定には取り消し線が引かれ、決して追加されない。

著者は率直だ：n=1であり、エージェントが実際にルールに従う場合にのみ機能する。ずさんな書き手はマークダウンフォルダも腐らせる。

時間的フィールドが重要な理由

エージェント向けに作られたほとんどのメモリシステムは、検索を関連性ランキングの問題として扱う。スキーマにvalid_from / valid_toフィールドがあっても、検索器がそれらを無視するなら、廃止された事実は現在のものと同じスコアになる。まさにスタートアップのランタイムが示したのはそれだった：3つが1.000で同点。gitにバックアップされたマークダウンファイルは、ランキングの問題を完全に回避する——現在のバージョンは取り消し線のない行であり、履歴はその上にインラインで示される。

著者は完全なテストとセットアップをオープンソース化した；リンクは元のスレッドのコメントにある。また、他のみんながメモリに何を使っているか——標準のMEMORY.md、プラグイン、それともカスタムか——を尋ねている。