コーディングエージェントの性能を左右するHarness設計

はじめに

コーディングエージェントが長いソフトウェア開発タスクを完了できるかどうかは、基盤モデルのコード生成能力だけでは決まらない。計画の立て方、ツールの呼び出し方、過去の出力をどのように保持するかを決めるHarnessも、実行結果を大きく左右する。しかし既存の評価では、こうした要素を一つのエージェントシステムとして比較することが多く、どの部品が効果を生んだのか分かりにくかった。

実験の概要

論文「An Empirical Study of Harness Design for Coding Agents」では、実行ループを固定した軽量なHarnessを構築し、計画、アクション空間、コンテキスト管理の三つを個別に変更した。4つのモデルをSWE-Bench VerifiedとTerminal-Bench 2.1で評価し、合計176の対応する設定を比較している。コンテキスト管理については5種類の戦略と4段階のウィンドウ予算を扱い、成功率だけでなくコストや実行軌跡も分析した。

主な発見

• 予算が厳しいほどコンテキスト管理が重要になる。 ウィンドウが小さい場合、エージェントはコード修正や検証に到達する前に、コンテキストオーバーフローで停止しやすい。管理機構の主な効果は、エージェントの行動そのものを変えることではなく、実行を継続させることにある。ウィンドウが大きくなると、正確さへの上乗せ効果は小さくなる。
• ルールベースの省略を要約より先に行うと効率がよい。 低価値な内容をルールで先に省略し、その後に必要な部分だけをLLMで要約する方式が、全体として最も効率的だった。省略した内容を復元可能にする仕組みは複雑さを増やすが、モデルはほとんど利用せず、正確さの改善も確認されなかった。
• 計画の役割はモデル能力で変わる。 弱いモデルでは、計画が実行軌跡を維持し、コード編集まで到達させるための足場になる。一方で追加コストが生じる。強いモデルでは正確さへの影響は小さく、編集後に繰り返される検証を減らしてコストを抑える役割が中心になる。
• ツールはモデルに合わせる必要がある。 Bashの扱いが苦手なモデルには、事前定義されたツールが有効で、複雑なシェル操作への依存を減らせる。Bashに習熟したモデルはBashだけのインターフェースでも十分に動作し、特にコマンドライン中心のタスクでは大幅に低いコストを実現できる。

意義と今後

この研究の重要な示唆は、Harnessを万能の固定テンプレートではなく、モデルと予算に適応する層として設計すべきだという点にある。導入時には、モデルのBash能力、タスクがコマンドライン中心かどうか、コンテキスト予算の厳しさを確認し、その結果に応じて計画機構や専用ツール、要約処理を選ぶべきだろう。

また、Harnessの評価では成功率だけでなく、コスト、オーバーフローによる停止、軌跡の長さ、停止地点も記録する必要がある。今回の結果は単一の最適構成を示したものではない。むしろ、タスクとモデルの状態に応じてHarnessを動的に切り替える設計が、今後の現実的な方向であることを示している。

出典：Hugging Face Daily Papers