本論文は、コーディングエージェントに関する既存の文献がほとんど扱ってこなかった問いを立てる。エージェントが実行時に何をするかではなく、モデルの周りのコードが実際にどうなっているかという問いである。このギャップについての著者の論拠は具体的である。能力ベースの分類体系（ツール利用型、メモリ拡張型、計画型、内省型）のもとでは、コーパス中のすべてのエージェントがすべてのカテゴリに該当してしまう。そのため、候補パッチに対してモンテカルロ木探索を行うエージェントと、テスト駆動の再試行を伴う while ループを回すエージェントは、コスト、信頼性、失敗モードに影響する点で異なるにもかかわらず、区別がつかなくなる。
手法は質的なケーススタディである。22 の候補からなる初期プールから、3 つの採録基準 ── 汎用ではなくコーディングに特化していること、読解可能でコミットを固定できる実装を持つオープンソースであること、他とアーキテクチャ的に異なること ── に基づいて 13 のオープンソースのコーディングエージェントを選び、それぞれを固定したコミットハッシュにおいて分析した。分析フレームワークは、概念的なエージェントアーキテクチャの文献から取った 6 つの次元から始まり、意図的に対照的な 2 つのエージェント Aider と OpenHands を対象としたパイロットでの反復的なオープンコーディングを通じて 9 つに拡張された。この 9 つが結果では 12 の分類次元に対応する。ループドライバーと、編集・パッチ形式という 2 つの下位特性は十分に識別力があることがわかったため個別に提示され、さらに 3 つ目の次元である制御フローの実装は、ループのトポロジーと直交する変動軸として分析中に浮かび上がり、同様に独立して提示されている。分類上の主張はすべてファイルパスと行番号に根拠づけられている。本論文は意図的にエージェントの性能をベンチマークしていない。ベンチマークのスコアは、スキャフォールドのアーキテクチャを、モデルの能力、プロンプトエンジニアリング、付随的な設定と混同してしまうというのがその理由である。
12 の次元は 3 つの層に整理されている。制御アーキテクチャ（エージェントが次に何をするかをどう決めるか）、ツールと環境のインターフェース（コードや実行環境とどうやり取りするか）、リソース管理（コンテキスト、状態、モデルをどう管理するか）である。
主なポイント
- 本論文の主要な知見は、スキャフォールドのアーキテクチャは離散的な分類になじまず、連続的なスペクトル上の位置として記述するほうが適切だということである。制御戦略はフィードバックループのない固定パイプラインから、報酬の逆伝播を伴う完全なモンテカルロ木探索まで、ツール数は 0 から 37 のアクションクラスまで、コンテキストのコンパクションは 7 つの異なる戦略にまで及ぶ。
- 5 つのループプリミティブ ── ReAct、生成・テスト・修復、計画・実行、複数回試行によるリトライ、木探索 ── を特定しており、これらは相互排他的な型ではなく組み合わせ可能な構成要素として機能する。13 のエージェントのうち 11 は、単一の制御構造に頼るのではなく複数のプリミティブを重ねている。
- プリミティブは自由に組み合わせられるため、可能なアーキテクチャの空間はカテゴリ的ではなく組み合わせ的であると論じ、方法論上の帰結として、エージェント全体を分類するよりもスキャフォールドの次元を独立に評価するほうが有益だとしている。
- ループドライバー（次に何が起こるかを誰が決めるか）を、おそらく最も根本的なアーキテクチャ上の区別として扱い、ユーザー駆動、スキャフォールド駆動、LLM 駆動の設計を区別している。ユーザー駆動のエージェントは、先行する軌跡分析で特定されたバグ特定のボトルネックを回避していると指摘する。ユーザーがファイルを選ぶのであれば、誤った特定はエージェントの失敗ではなくユーザーの誤りになるからである。
- 意味論的なループの型とコードレベルの実装は直交している。同じ分類体系で、ループのトポロジーと、それを実現する 4 つのメカニズム ── 命令型の while ループ（13 エージェント中 8）、再帰、コンパイルされたステートマシンによる制御フローとしてのグラフ、例外ベースのシグナリング ── を区別している。
- ツールの数だけを見ると、ツールが実際に何をするかにおける収斂が見えなくなる。コーパス中のすべての LLM 駆動エージェントに、読み取り、検索、編集、実行という同じ 4 つの能力カテゴリが現れる。ツールの少ないエージェントは組み合わせによってこれらをカバーし、ツールの多いエージェントは同じカテゴリをより細かい操作に分解している。
- コンテキストのコンパクションは、本論文が予防と治療と呼ぶ 2 つの思想に分かれる。予防型のエージェントは、ノードごとのメッセージのスコープ設定、ラウンド数の上限、木の深さによってコンテキストの増大を構造的に抑える。治療型のエージェントはコンテキストの増大を許し、トークン数が閾値に達したときに圧縮する。予防は要約のコストと情報の損失を避けられるが、スキャフォールドが増大のパターンを予測する必要がある。
- 失敗したパッチへの根本的に異なる 2 つの対応として、サンプリング（独立した別の試行を生成する）と反復（フィードバックを使って失敗した試行を洗練する）を区別している。これは単一の試行の構造ではなく、解の試行の集団をエージェントがどう扱うかを記述するため、制御ループの分類体系を横断すると指摘している。
- 木探索型のエージェントが直面する 2 つの選択問題を区別しており、両者は同じメカニズムで解くことも別のメカニズムで解くこともできる。オンラインのガイダンス（探索中に次にどの枝を探るか）と、オフラインの選択（探索後にどの完成した解を返すか）である。
- 収斂する次元と分岐する次元は異なる情報を持つ。外部の制約が支配的なところ ── ツールの能力カテゴリ、編集形式、実行の隔離 ── では次元が収斂しており、本論文はこれらを解決済みの問題であり標準化の候補と読む。未解決の設計上の問いが残るところ ── コンテキストのコンパクション、状態管理、複数モデルのルーティング ── では次元が分岐しており、この分岐はノイズではなく最善のアプローチに関する真の不確実性であって、研究投資が最も必要な場所を示していると論じている。
- 複数のモデルを使うエージェントでは、コストの最適化が複数モデルのルーティングの主な動機であると報告されている。機械的なタスクは安価なモデルに振り分けられ、高価なモデルは推論のために取っておかれる。
- 同じ上流プロジェクトについて、フォークによる再利用と依存関係による再利用が共存していることを、エコシステムがまだ明確な拡張ポイントを中心に安定していない証拠と読んでいる。
補足
本論文は、隣接する 3 つの文献群に対して自らを位置づけている。概念的なエージェントアーキテクチャのサーベイは有用な語彙を提供するが、実運用のシステムを区別できない抽象度で議論している。軌跡・振る舞いの研究は経験的な規則性を確立するが、エージェントをブラックボックスとして扱い、エージェントが何をするかを観察しても理由は説明しない。さらに著者は、先行する軌跡研究が異なる基盤モデル上で動くエージェントを比較しており、スキャフォールドの効果とモデルの効果が交絡していると指摘する。個々のシステムについては詳細なアーキテクチャの記述が存在するが、設計空間全体は描かれていない。
著者はまた、本研究を開発者がコーディングエージェントを設定する方法に関する研究と区別し、両者を補完的なものとしている。設定の成果物はエージェントがどのような指示を受け取るかを制御し、スキャフォールドのアーキテクチャはエージェントがその指示をどう処理するかを決定する。
この分類体系は、固定すべき変数に名前を与えることで、将来の統制実験を可能にするものとして提示されている。たとえば、モデルを固定したまま、同一のツールセットを持ちループ戦略だけが異なるエージェントを比較するといった実験である。
主題そのものについては エージェントスキャフォールド を、本論文が分岐する次元の 1 つに位置づけているものについては コンパクション を参照。