Anthropicが解明、AIエージェントの記憶は「夢」で正される
The Components of Agent Memory
AnthropicがClaudeのエージェント記憶の設計を解説。セッション中に重要事項をメモとして書き出し、アイドル時間にログを振り返って誤りを修正する「dreaming」を組み合わせる。Pokémon Redの実験では、何でも記録したSonnet 3.7が413ファイルでバッジ1個だったのに対し、戦略に絞ったFable 5は9ファイルでバッジ4個を獲得。強いモデルほど細かいルールより裁量に委ねる方が有効だった。
記憶とは、時に未来への予測である。ルールを書き留めることで、エージェントは自分が記述しているパターンが再び重要になると予測しているのだ。
HNでの議論
63- andai
ここで説明されているかは分からないが、グラフ（図10）を見ると、wiki + search が dreaming を上回っており、dreaming は wiki + search の構成にわずかな利得しかもたらさないように見える。
search は dreaming よりもずっと安価だと思う（ただし時間スケールによるかもしれない？）ので、これはかなり重要に思える。
- yfontana
これまで使ってきたすべてのハーネスで、自動メモリ作成はオフにしてきた。Claude Code は時々勝手にいくつか作成するが、おそらく95%は削除している。作成されるメモリはほぼ常に、現在取り組んでいる特定のタスクにしか関連しない。再びやる必要があるタスクなら、まあ役立つかもしれない。しかしほとんどの場合そうではないので、コンテキストを散らかさないように削除している。
だからメモリに関して私が望む主な改善は、どのメモリを作成するかについてのより良い判断力だ。
「dreaming」に関する部分は、エージェントのトランスクリプトが大量の情報を含んでおり、それが現在十分に活用されていないことを思い出させる。ここで何度か見たアドバイスを繰り返す：自分のトランスクリプトを duckdb に取り込み（claude code なら約10分でそのパイプラインを構築する）、データ分析を行うといい。どこから始めればいいか分からない場合のアイデアをいくつか：ツール呼び出しの失敗を見て、よくある失敗を防げるか確認する、大きなキャッシュミスがあるか、その原因は何か調べる、メインスレッドとサブエージェントの効率指標（ドルあたりのトークン数、トークンあたりのコード行数など）を時系列で見る、など。私はこの種のことを始め、いくつかの糸をたどって興味深い洞察に至った。例えば、Opus 5.5 / Sol 6.1 に仕事を小さすぎる単位に分割させる傾向があることに気づいた。彼らは古いモデルよりも多くのことを同時に処理できる能力があり、私はそれを十分に活用していなかった。
- bob1029
彼らの cerulean chart への進歩は、私にメモリなしをかなり強く売り込んでいる。
長時間実行されるエージェントで避けたい最大のものは volatility だ。それをどちらかの方向に急速に押しやるものは、平均的なケースでは望ましくない。少なくとも私にはそうだ。
- prtmnth
memory-prune というスキルがあり、その唯一の目的は、自動的に作成されたメモリを取得し、それが存続する価値があるか、コードコメント、ルール、プロジェクトの AGENTS.md ファイル、グローバルの AGENTS.md/CLAUDE.md ファイルに保存されるべきか、あるいは（そしてこれが最も頻繁に選ばれる選択肢だが）まったく保存せずに削除するかを評価することだ。
- 2001zhaozhao
この記事は、私が構築しているものにとって多くの検証になる。アイデアを吸収するために、間違いなく何度か記事を再訪するだろう。AI のメモリシステムは非常に重要であり、個人的にはメモリ管理のために単にベースモデルを訓練するよりもずっと良いことができると思う。