何が起こったのか
8月11日に投稿された新しいプレプリントでは、エージェントコーディングリポジトリで観察された障害モードを「壊滅的な記憶」と名付けている。つまり、プロジェクトの指示ファイルは、予防策を追加するのが安価であるため、ルールを蓄積し続ける一方、元の理論的根拠が失われると、古いルールを安全に削除するのが難しくなる。
研究者らは、CLAUDE.md などのファイルを含む 1,867 のパブリック リポジトリから、247,694 の命令ライフタイムと 299,440 のコミットからコミットへの遷移を収集しました。彼らは編集を通じて個々のディレクティブを追跡し、観察された存続期間中にファイルが 226% 増加し、変更コミットごとに平均 4.9 個の正味命令が追加されたと報告しました。この研究では、これらの数値は、すべての指示が不要であったことや、すべてのエージェント コーディング プロジェクトが同じように動作することの証拠ではなく、サンプル内に継続的に蓄積された証拠として扱われます。
この論文の中心的なメカニズムは非対称的な証拠です。メンテナまたはコーディング エージェントは、既に存在するルール間の相互作用をすべて再構築することなく、間違いの後に新しい命令を追加できます。後で削除することはよりリスクが高くなります。動機となる失敗と周囲のコンテキストが消滅した後、1 つのディレクティブを削除すると、残りのディレクティブをさまざまに組み合わせた場合でもリグレッションを防ぐことができるかどうかを確認する必要がある場合があります。リポジトリ データでは、推定削除ハザードは命令が経過するにつれて低下し、コミットあたりの対数ハザード勾配は -0.032 であると報告されています。
可能な解決策をテストするために、著者らは IFEval 制約を逆にして指示に従うタスクを作成し、裸のルールを含むプロンプトと、各ルールが存在する理由を説明する短いコメントも保存されたプロンプトを比較しました。制御されたセットアップでは、コメントなしのプロンプトでは 211.3% の過剰な命令が蓄積されましたが、コメント付きのプロンプトは 1.4% の過剰で終了しました。コメントはモデルに対する追加のコマンドではありませんでした。これらは、後で削除する決定を監査可能にすることを目的としたコンパクトな来歴でした。
チームはまた、より小さく、より適切に文書化されたプロンプトがエージェントが指示に従うのに役立つかどうかも評価しました。 WildIFEval 由来のベンチマークでは、理論的根拠が維持され、時代遅れのルールが削除された場合、論文は 23.1 パーセント ポイントもの利益が得られたと報告しています。これらの結果は、新しく投稿された査読されていないプレプリントからの主張です。この研究は、コメントだけですべてのコーディング エージェント、リポジトリ、言語、または運用ワークフローが改善されることを証明するものではありません。
ソースの詳細: Catastrophic remembering research paper on arXiv ↗
なぜそれが重要なのか
リポジトリ レベルの命令ファイルはコーディング エージェントにとって耐久性のある操作メモリになりつつあるため、制御されない増加によりトークン コストが上昇し、時代遅れの制約が維持され、自動化されたコード変更を管理するルールが人々にとって理解しにくくなる可能性があります。
実際のリスクは単にファイルが長いというだけではありません。すべての命令はモデルの注意を求めて競合し、新しいルール、ツールの説明、コード コンテキスト、およびユーザーのリクエストと対話することができます。歴史的な失敗を防ぐために書かれたディレクティブは、コードベースが変更されると意味がなくなったり、新しいポリシーと競合したり、無関係な作業を過剰に制約したりする可能性があります。誰もそれが存在する理由を再構築できない場合、最も安全なローカルの選択は、多くの場合、それを保持することです。これにより、クリーンアップのコストが将来のコミットに移されます。
そのパターンは CLAUDE.md を超えて重要です。チームは、規則、安全境界、テスト コマンド、アーキテクチャ上の決定、展開上の注意を機械可読なプロジェクト ガイダンスに保存することが増えています。これらのファイルは一貫性を高め、繰り返される間違いを減らすことができますが、同時にガバナンス面にもなります。つまり、誰が結果的なルールを導入したのか、どのような証拠がそれを正当化するのか、そしてどのような条件でルールを廃止できるのかを人々が特定できる必要があります。根拠コメントは、その監査証跡の軽量バージョンです。
この結果は、エージェントの記憶に関する有用な設計原則を示唆しています。つまり、記憶には忘れるための条件が含まれている必要があります。 「常に X を実行する」だけを記録する代わりに、システムは観察された失敗、ルールの範囲、関連するコンポーネントまたはテスト、およびレビュー トリガーを保存できます。これは削除を自動化するものではありませんが、後の保守者がその制約が依然として正確さを保護しているのか、それとも単に古い環境を反映しているのかを判断するための証拠を提供します。
コーディングエージェントがより重要なソフトウェアに関わるため、公益の観点もあります。蓄積されたプライベート指示により、セキュリティ上の決定、アクセシビリティの動作、データ処理、またはエージェントの障害への対応方法を静かに形作ることができます。ファイルが小さいほど自動的に安全になるわけではなく、積極的なクリーンアップを行うと重要な安全装置が削除される可能性があります。有用な成果はトレーサビリティです。説明のつかないルールが減り、所有権が明示され、人間が追加と削除の両方に異議を唱えることができるレビューの実践が可能になります。
インタラクティブなメカニズム: 実際にどのように機能するか
この開発の背後にある基盤となるテクノロジーをインタラクティブに探索します。
crm_get_transaction(id='4092').What most distinguishes an AI agent from a basic chatbot?
次に見るべきもの
次のテストは、言語、組織、エージェント製品、および長寿命リポジトリにわたる独立したレプリケーションであり、その後、文書化されたクリーンアップによって重要な安全対策を削除することなくコードの品質が向上するかどうかを測定する前向きトライアルが続きます。
観察サンプルには選択限界があります。エージェント指示ファイルをコミットするパブリック リポジトリは、民間企業のコードベースとは異なる場合があり、リポジトリの履歴からは、ルールの動機となったプラットフォーム外のディスカッションやインシデントをすべて明らかにすることはできません。プロジェクトが拡大する場合、成長も合理的になる可能性があります。今後の分析では、新しいコンポーネントの有用な範囲を重複、矛盾、または時代遅れの命令から分離し、結果がリポジトリの古さ、サイズ、言語、寄稿者の数、エージェント プラットフォームによってどのように変化するかを報告する必要があります。
管理された実験には、より広範な検証が必要です。タスクは、数か月にわたるソフトウェアのライブ メンテナンスではなく、指示に従うベンチマークから派生し、論文の一致するパイプラインは 50 の移行サンプルでチェックされました。ある著者は、検証の一部で使用される手書きの注釈を作成しました。この調査では英語以外の命令ファイルは対象になっておらず、変更がいつ命令の継続ではなく書き換えとしてカウントされるかを決定するために使用されるすべてのしきい値を網羅していませんでした。
コメントは、正しい根拠と同じくらい簡単に、間違った根拠を保持できます。したがって、チームは、リンクされた問題、回帰テストの不合格、有効期限、所有権フィールド、または重複および競合するディレクティブにフラグを立てる自動チェックなどの代替案に対して、構造化された来歴をテストする必要があります。最も安全なワークフローでは、トークンを節約するためだけにエージェントに指示を削減させるのではなく、削除を提案し、証拠と影響を受けるテストを示し、影響の大きいルールのレビューを要求します。
有用な追跡証拠は、プロンプトのサイズ、指示の遵守、タスクの成功、回帰、レビュー時間、削除後に復元されたルールの数など、エンドツーエンドの結果を測定します。研究者はまた、モデルが意図したとおりに根拠コメントを実際に使用しているか、場合によっては追加の要件と誤って使用しているかどうかもテストする必要があります。これらの結果が得られるまでは、壊滅的な記憶は、著者のデータセットと実験について十分に裏付けられた説明であり、普遍的な法則でも、成熟したプロジェクトの指針を完全に消去する理由でもありません。