この投稿が出発点とする問題は、数時間から数日に及ぶタスクに取り組むエージェントは個別のセッション単位で作業しなければならず、各セッションは前回の記憶を持たずに始まるということである。投稿はこれを、交代制で働くエンジニアが担当するソフトウェアプロジェクトにたとえる。新しく来るエンジニアは、前のシフトのことを何も覚えていない。投稿の報告によれば、コンパクション だけではこれは解決しない。Claude Agent SDK 上でループとして動作するフロンティアモデルでさえ、高レベルのプロンプトから本番品質の Web アプリを構築するには至らない。
その実験からは 2 つの失敗モードが報告されている。エージェントは一度に多くをやろうとしすぎる傾向があり — 本質的にはアプリをワンショットで作ろうとする — 実装の途中でコンテキストを使い果たし、次のセッションには作りかけで文書化されていない機能が残され、それを再構築しなければならなくなる。プロジェクトの後半には逆の失敗が現れる。エージェントのインスタンスが周囲を見回し、進捗があることを確認して、作業が完了したと宣言してしまうのである。
示される答えは 2 部構成である。イニシャライザーエージェントは一度だけ実行されて環境をセットアップする。init.sh スクリプト、進捗ログ、最初の git コミット、そしてプロンプトが含意するすべての機能の JSON リストであり、各機能は失敗としてマークされている。その後の各コーディングエージェントのセッションは、その状態を読み込み、未完了の機能を 1 つ選び、それを実装してエンドツーエンドで検証し、リポジトリをコミット済みかつ文書化された状態で残す。投稿が述べる重要な洞察は、これを機能させるのは、新しいコンテキストウィンドウに作業の状態を素早く把握する手段 — git の履歴と並ぶ進捗ファイル — を与えることだというものであり、これらの実践は効果的なソフトウェアエンジニアが日々行っていることから引き出されたものだと記している。
要点
- 長時間稼働エージェントの中核的な課題は、個別のセッション単位で作業し、各セッションがそれまでの記憶を持たずに始まることである。
- コンパクションは単独では不十分だと報告されている。次のエージェントに十分に明確な指示を常に引き渡せるわけではないからである。
- 観察された 1 つ目の失敗モードは、エージェントがアプリケーションをワンショットで作ろうとし、機能の途中でコンテキストを使い果たして、何が起きたかの推測を次のセッションに委ねてしまうことである。
- 2 つ目はプロジェクトの後半に現れるもので、後続のエージェントが既存の進捗を見て作業が完了したと宣言してしまうことである。
- 解決策は、必要なすべての機能を見越した初期環境をセットアップすることと、各セッションにクリーンな状態を残しながら漸進的な進捗を上げるよう促すことの 2 つに分かれる。
- 「クリーンな状態」とは、メインブランチへのマージに適したコードとして定義される。大きなバグがなく、整然としてよく文書化されており、次の開発者にとって無関係な散らかりがない状態である。
- イニシャライザーエージェントは、
init.shスクリプト、進捗ログファイル、そして何が追加されたかを示す最初の git コミットを書く。 - また、ユーザーのプロンプトを展開した包括的な機能要件ファイルも書く — 投稿の具体例では 200 を超える機能があったと報告されている — そしてすべての機能は当初失敗としてマークされる。
- コーディングエージェントは、そのファイルを機能の合否ステータスを変更することでしか編集できず、テストを削除したり編集したりしないよう強い言葉の指示で念押しされる。
- 実験の結果、そのファイルには Markdown ではなく JSON が選ばれた。報告された理由は、モデルが JSON ファイルを不適切に変更したり上書きしたりする可能性がより低いというものである。
- 一度に 1 つの機能だけに取り組むことが、多くをやろうとしすぎるエージェントの傾向に対処するうえで決定的に重要だったと報告されている。
- 説明的なメッセージで git にコミットし、進捗の要約を書くことが、クリーンな終了状態を引き出す最も効果的な方法だと報告されており、これによりモデルはまずい変更を元に戻し、動作する状態を回復できる。
- さらなる失敗モードは、適切なテストなしに機能を完了とマークすることである。明示的な指示がない場合、エージェントは変更を加えてユニットテストや
curlによるチェックを実行したものの、その機能がエンドツーエンドでは動作しないことを認識できなかった。 - ブラウザ自動化を使い、人間のユーザーと同じようにテストするようエージェントに明示的に指示したところ、Web アプリの作業での性能が劇的に向上したと報告されている。
- 限界も認められている。使用したツールを通じてはモデルがブラウザネイティブのアラートモーダルを見ることができず、それらのモーダルに依存する機能はバグが残りやすかった。
- 各コーディングセッションは、決まった起動手順を通じて指示される。作業ディレクトリを確認し、git のログと進捗ファイルを読み、機能リストを読み、優先度が最も高い未完了の機能を選ぶ。
- 新しい作業を始める前に基本的なエンドツーエンドのチェックを実行することで、エージェントは壊れた状態の上に積み上げるのではなく、それを検出して修正できるようになると報告されている。
- 単一の汎用コーディングエージェントと、専門エージェントから成るマルチエージェントアーキテクチャのどちらが優れた性能を発揮するかは、未解決の問いとして述べられている。
- このデモはフルスタックの Web アプリ開発向けに最適化されており、それを他の領域に一般化することは今後の課題として挙げられている。
背景
この投稿はベンダーによるエンジニアリングの記録である。ハーネス、SDK、モデルはすべて Anthropic のものであり、知見は複数のプロジェクトにわたる測定からではなく、1 つの具体例 — チャットアプリケーションのクローン — に対する社内の実験から報告されている。失敗モードと修正は、その環境でうまくいったこととして提示されており、未解決の問いは最後に率直に述べられている。その枠組みは、長時間稼働エージェント の設計についてのこの wiki の他の記述と並ぶものであり、それらと共有する繰り返し現れる一手は、状態をコンテキストウィンドウの外へ、次のセッションが読むことのできる永続的な成果物へと押し出すことである。