私のコーディングエージェントは、セッションは覚えていたが、作業を覚えていなかった
コーディングエージェントは、スレッドを維持していても、忘れっぽいと感じることがあります。
CliGateを構築している際に、この問題に直面しました。セッションの継続性は修正しましたが、繰り返しのタスクは依然として遅いままでした。
エージェントは会話は覚えていましたが、作業の内容を覚えていなかったのです。
セッションの継続性は、一つの問題を解決します。次のようなフォローアップコマンドが可能になります：
- continue（続けて）
- do the same for this file（このファイルでも同じことをして）
- retry that（それをやり直して）
- explain the error（エラーを説明して）
これは作業の流れ（フロー）において重要です。しかし、数日後に同じワークフローを繰り返す場合には機能しません。
どのボタンが機能するか、どのステップが行き止まりになるかをエージェントが学習する場合、単一のオープンセッションだけでは不十分です。エージェントには、前回の実行を成功させた要因を思い出す必要があります。
初回の実行は最もコストがかかります。その時にエージェントは、以下のような細かな詳細を見つけ出すからです：
- 特定のメニューの中にアクションが隠れている
- エディタがiframeである
- プロジェクトに特定の回答スタイルが必要である
- 環境のURLが本番環境とは異なる
私の修正前、これらの詳細は単なる生のログに過ぎませんでした。エージェントには履歴はありましたが、再利用可能なメモリはありませんでした。毎回同じ事実を再発見しなければならなかったのです。それは知能ではありません。同じコストを二度支払っているだけです。
間違ったアプローチは、より多くの履歴を保存して、モデルがそれを使ってくれることを期待することです。これはノイズを生みます。
私が必要としたのは、より小さく、再利用可能なレイヤーでした。すべてを保存するのではなく、以下を保存するように変更しました：
- procedures（手順）：最適なステップと、既知の行き止まり
- facts（事実）：URL、ルール、または設定
- directives（指示）：どのように物事を進めてほしいか
- references（参照）：ドキュメントの場所
これによりシステムが変わりました。膨大なトランスクリプトを読み込む代わりに、アシスタントはファイルベースのメモリレイヤーを使用するようになりました。
インターフェースは変わり、ボタンの位置も動くため、完璧なリプレイ（再現）は望んでいませんでした。私が求めたのは、次のようなループです：
- 前回の最適な手順を思い出す
- まずそれを試す
- 各ステップを検証する
- 失敗した場合は、探索プロセスに戻る
- 成功した後にメモリを更新する
また、恒久的なルールをセッション履歴から分離しました。「本番データには触れないこと」といったルールは、会話のコンテキストではありません。それらは運用ルールです。これらを分離することで、アシスタントの挙動を予測可能にしました。
結果として、繰り返しのタスクが短縮されました。アシスタントは、空の戦術モデルからスタートすることはないため、より速く動けるようになりました。
コーディングエージェントを構築しているなら、スレッドと学習を混同しないでください。
- セッションは継続性を助けます。
- メモリは繰り返しの作業を助けます。
セッションは会話を維持します。メモリレイヤーは教訓を維持します。
あなたのシステムはスレッドを覚えていますか？それとも、成功した手順を覚えていますか？
Source: https://dev.to/codekingai/my-coding-agent-remembered-sessions-not-work-that-was-the-bug-2fig