エージェントのメモリをプロンプトに垂れ流すのをやめよう

多くの開発者は、すべてを次のプロンプトに追記していくことでエージェントのループを構築しています。

以前の観察結果、ツールの呼び出し、推論のトレースなどを追加していきます。プロンプトが「何でも放り込む引き出し」になるまでデータを追加し続けます。モデルが見る情報は増えますが、制御を失います。どのメモリが特定の決定を引き起こしたのかが分からなくなるのです。

「AgenticSTS」と呼ばれる新しい論文は、異なる道筋を提案しています。それは、メモリを「最大のコンテキストウィンドウをめぐる争い」としてではなく、「インターフェース」として扱うものです。

この論文では、テストベッドとしてゲーム『Slay the Spire 2』を使用しています。この環境では、何百もの戦略的な意思決定が求められます。単なるチャットボットではありません。

核となる考え方はこうです。メモリとは、将来の意思決定が何を見ることが許されるかについての「契約」である。

著者らは生のトランスクリプト（記録）の代わりに、以下の5つの特定のレイヤーを使用して新しいプロンプトを構成しています。

• 固定されたプロトコル指示
• 現在の状態とアクションのスキーマ
• 取得されたゲームルール
• 過去の実行の要約
• トリガーされた戦略的スキル

この構造はすべてを変えます。各レイヤーを検査、凍結、または無効化できます。メモリをデータの山から、選別された「証拠」へと変えるのです。

本番環境のエージェントが失敗する原因の多くは、モデルの失敗ではありません。コンテキストの失敗です。エージェントが古い状態と新しい状態を混ぜてしまったり、時代遅れの振り返りを持ち越したりしてしまうのです。もし唯一のポリシーが「テキストを追記するだけ」であるなら、デバッグは考古学のように感じられるでしょう。

型定義されたメモリインターフェースがあれば、比較対象が得られます。

長期間稼働するエージェントにとって、巨大なコンテキストウィンドウは罠です。それは事実、古い事実、そして失敗した試行が混ざり合ったものになります。ウィンドウが大きければ大きいほど、堆積物をメモリと見誤りやすくなります。

より優れたエージェントを構築するために、以下のパターンに従ってください。

• 安定した指示と現在の状態を分離する
• ルールは検索レイヤーに保持する
• 経験はチャットの残骸ではなく、明示的な記録として保存する
• 繰り返される修正をトリガーされたスキルに変換する
• テストのために、すべてのメモリレイヤーを削除可能にする

メモリレイヤーをオフにできないのであれば、それが実際に役立っているのかどうかは分かりません。単に「塊全体が時々機能している」ことしか分からないのです。

エージェントのメモリを「雰囲気（vibes）」のレイヤーとして扱うのはやめましょう。次の意思決定に何が入り、それがどこから来たのか、そしてそれをどのように無効化できるのかを正確に把握できるシステムへと移行してください。

もしエージェントが「何を記憶することを許されていたか」を説明できないのであれば、それはメモリを持っているのではなく、単に「地下室のあるプロンプト」を持っているだけです。

Source: https://dev.to/komo/stop-dumping-agent-memory-into-the-prompt-58ka

Optional learning community: https://t.me/GyaanSetuAi