このサーベイは、著者らがモデル–ハーネスの観点と呼ぶものを通して、LLM ベースのエージェントに関する文献を読み解く。サーベイは、しばしば混同されるという 2 つの抽象レベルを分ける。機能のレベルでは、エージェントはタスクの目的を中心に 5 つの操作 — 知覚、状態の保持、推論と意思決定、行動、フィードバックへの適応 — を組織する、目標指向の閉ループシステムである。一方、実装のレベルでは、LLM ベースのエージェントは 実行ハーネス と結合した基盤モデルである。モデルは言語理解、推論、計画、行動の提案を提供し、ハーネスは観測の提示、コンテキストの構築、行動の実行、状態の永続化、失敗の検証または回復を担うランタイムの仕組みを提供する。サーベイの中心的な主張は、エージェントの品質 — 成功、効率、安全性、汎化 — は、モデルの能力だけからではなく、モデルの能力、ランタイムのインフラストラクチャ、タスクの構造、評価の設計の相互作用から生まれるというものである。
その方法は実験ではなく統合である。2020 年から 2026 年までの LLM ベースのエージェントシステムを扱う、公刊論文、公開されたエンジニアリングレポート、ベンチマーク、そして統制されたモデル–ハーネスの比較を整理している。先行するサーベイとの違いとして、3 つの点が明示的に主張されている。静的なコンポーネントの分類法ではなく、エンジニアリングのパラダイムシフトを軸に文献を整理する、進化を第一とするものであること。実行ハーネスを第一級の技術的対象として扱う、ハーネス中心のものであること。そして学術的な証拠と産業界の実践を結びつけるものであること。実証的なセクションでは SWE-bench Verified、Terminal-Bench 2.0、WebArena のリーダーボードと公開された投稿データを集めており、著者らはこの証拠を、ランダム化されたアブレーションではなく観察的なものとして慎重に説明している。
貢献は、4 つのパラダイムによる進化の説明、ハーネスの 6 つのコンポーネントへの分解、タスクの性質からハーネスの構成への対応づけ、そしてタスクの成功以上のものを報告する評価の主張である。また、タスクの価値をコスト、レイテンシ、リスク、信頼性の制約と結びつける、価値を考慮した定式化（価値を考慮したエージェント評価 を参照）を提案し、人手で設計されたランタイムの先にある方向性として、エージェントネイティブ・トレーニング とモデル–ハーネスの共進化を描いている。
要点
- LLM ベースのエージェントは、実行ハーネスと結合したモデル層として記述される。実際に展開される複数モデルのシステムでは、モデル層は能力、コスト、コンテキストの上限が異なる複数のバックボーンの集合であり、ハーネスはさらに各ステップでどのモデルが行動するかを決めなければならない。
- ハーネスは、相互に結合した 6 つのランタイム上の責務に分解される。観測インターフェース、コンテキストマネージャー、制御ループ、行動インターフェース、状態と成果物のストア、そして検証とガバナンスの層である。サーベイは、これらが独立に最適化できるのではなく結合していることを強調する。より強い圧縮はコストを下げる一方で下流の検証を弱めうるし、より豊かな行動はカバー範囲を広げる一方でガバナンスへの圧力を高め、より永続的な状態は継続性を高める一方で古くなった証拠や矛盾する証拠を持ち込む。
- エージェントエンジニアリングは 4 つのパラダイム — プロンプトエンジニアリング、ワークフローとコンテキストエンジニアリング、ハーネスエンジニアリング、共進化を伴うエージェントネイティブ・トレーニング — を通してたどられる。これは厳密な時代区分ではなく、4 つすべてが今日共存しているという概念的な進化の見方として示されている。
- モデル中心のスケーリングは 2 つの限界に直面すると論じられている。資源と性能の境界（サーベイは、LLaMA 3.1 が 70B から 405B に移行したことで、訓練計算量が 700 万 H100 GPU 時間から 3,084 万 H100 GPU 時間に増えたのに対し、ベンチマーク上の向上はわずかだったことを引用している）と、測定の境界（最先端のリリースが、飽和した静的ベンチマーク上で狭い範囲に集中していること）である。これらの数値は本サーベイで測定されたものではなく、引用された研究から報告されたものである。
- どのハーネスのコンポーネントがボトルネックになるかを決めるのは、アプリケーションのラベルではなくタスクの構造である。サーベイは、タスクの期間、環境の種類、自律性のレベルという 3 つの次元を用い、単一ステップからオープンエンドまでの 4 段階の複雑さの尺度を示して、L2 から L3 への移行が最も重大であるとしている。
- 領域をまたいで、主要なボトルネックは移動する。ソフトウェアエンジニアリングは検証が支配的、Web と GUI の操作はグラウンディングが支配的、科学的発見は統合が支配的、医療支援は安全性が支配的、身体性を持つ設定は制御が支配的だと説明されている。
- SWE-bench Verified では、集計された表が両方の効果を示している。同じハーネスの中では、バックボーンの更新によって SWE-agent + tools が Claude 3.5 Sonnet での 49.0% から Opus 4 での 73.2% に上がる。同じモデルの中では、ハーネスの選択によって Claude 3.5 Sonnet が SWE-agent での 33.6% から PatchPilot での 53.6% に上がる。著者らは、この表が統制された要因実験ではなく公開された証拠の統合であり、ベンダーの行は上限の包絡線としての参照値であると注意を促している。
- スキャフォールドの複雑さは有効性を予測しないと報告されている。Opus 4.5 のもとで、およそ 100 行の Python だとされる mini-SWE-agent は 76.8% に達し、より豊かな OpenHands + CodeAct 2.1 のサンドボックスの 77.6% に迫る。
- Terminal-Bench 2.0 では、少なくとも 3 つのハーネスでの結果が観測された 20 のモデルについて、モデル内での正解率の幅の中央値は 13.6% であり、20 のうち 14 がハーネス間で少なくとも 10% 変動する。サーベイは正解率を運用上のプロファイル — 入力トークン数の中央値、エージェントの実行時間の中央値、タイムアウト率 — と組み合わせ、スコアはそれを生み出したランタイムの構成と併せて初めて解釈可能になると論じている。
- WebArena では、モデル単体のベースラインとハーネスを備えたシステムの差はさらに大きいと報告されており、GPT-4o はモデル単体の 13.1% から、あるブラウザハーネスのもとで 54.6% に上がる。
- サーベイは、評価ではタスクの成功と併せて、信頼性、効率、レイテンシ、安全性、プロセスの品質を報告すべきだと論じ、価値を考慮したエージェント最適化を提案する。これは、コスト、レイテンシ、リスク、繰り返し実行時の信頼性の制約のもとで、成功確率とプロセスの品質で重み付けされたタスクの期待価値を最大化するものである。
注記
著者らはこの研究を、最近のハーネスに焦点を当てたサーベイと対比して位置づけ、自分たちの貢献は新たな層の分類法やプロジェクトのカタログではなく、支配的なエンジニアリング上のボトルネックがどう移動し、その移動をどう実証的に評価すべきかについての説明だとしている。論じられた論文をまとめた付随のコレクションが https://github.com/ggjy/Awesome-Agent-Engineering で公開されている。
サーベイは、自らの実証的な証拠の限界について明示的である。公開された投稿はプロンプト、バージョン、予算、実装の詳細が異なるため、その比較は観察的なものである。モデルのスナップショット、推論の設定、リトライの予算は情報源の間で必ずしも揃っていないため、同じ行ファミリー内での比較を推奨し、ベンダーが報告したスコアを統制されたアブレーションではなく上限の包絡線として扱っている。Terminal-Bench の資源分析については、金額コストのフィールドが試行記録の 15.2% しかカバーしていないと報告しており、そのため金銭的コストはハーネス間の主張には用いていない。挙げられている未解決の問題には、ハーネスの改善がタスク分布やモデルファミリーをまたいで転移するかどうか、自己進化をどうすれば観測可能かつ元に戻せる状態に保てるか、そしてモデル設計とシステム設計の境界を最終的にどこに置くべきか、が含まれる。