技術的サマリー：Harness-Bench

問題定義

大規模言語モデル（LLM）エージェントは、外部環境と対話し、ツールを利用し、作業スペースを変更し、具体的な成果物を生成する実行可能なシステムとして、ますます展開されるようになっています。これらのワークフローにおいて、実用的なパフォーマンスは、基盤モデルの推論能力だけでなく、コンテキスト、ツール、状態、制約、権限、追跡、回復を管理するシステム層であるハarnessにも決定的に依存します。

既存のベンチマークは、重大な限界に直面しています。すなわち、実行詳細を抽象化し、ハarnessを完全なエージェントシステムと混同するか、モデルを比較する際にハarnessを固定したままにしています。その結果、現実的なワークフローにおいて、特定のモデル–ハarness構成が成功率、トークンコスト、堅牢性、追跡可能性にどのように影響するかを研究するための診断プロトコルが不足しています。これは、エージェントの成功か失敗かをしばしば決定する実行層の変動を不明瞭にしています。

手法

著者は、共有された外部条件下で構成レベルのハarness効果を評価するように設計された診断ベンチマークHarness-Benchを導入します。

ベンチマーク設計

• タスクスイート: 本ベンチマークは、実用的なエージェント利用パターンから構築された106 のサンドボックス化されたオフラインタスクで構成されています。これらのタスクは、ソフトウェアエンジニアリング、データ分析、作業スペース操作、知識労働、オフィスコミュニケーション、垂直分野の専門ワークフロー、長期実行自律、DevOps など、8 つのカテゴリーにまたがります。
• 検証: 各タスクは、現実性（妥当なユーザーワークフロー）、解決可能性（提供されたリソースで完了可能）、オラクルチェック可能性（決定論的チェックまたは評価基準による検証可能）、完全性（エージェントが制約を回避するのを防止）の 4 つの基準について手動でレビューされます。
• 評価プロトコル: 本ベンチマークは、タスクプロンプト、初期サンドボックス状態、予算、タイムアウト、評価者といった外部タスク条件を固定し、ハarness構成とモデルバックエンドを変化させます。
  • 以前の研究がシステムを共通の内部ポリシーに強制するのとは異なり、Harness-Bench は各ハarnessのネイティブな実行動作（プロンプティング、ツールインターフェース、状態管理、回復メカニズム）を保持します。
  • このアプローチは、ハarnessを主要な変数として扱い、個々のメカニズムを分離するのではなく、モデル＋ハarnessの組み合わせのパフォーマンスを測定します。

実行とスコアリング

• データ収集: 各実行では、最終成果物、実行トレース、使用統計、検証器の出力が記録されます。本研究では、6 つの構成可能ハarnessと 8 つのモデルバックエンド（および Codex の参照評価を含む）にわたる5,194 の実行軌跡を分析しました。
• スコアリング指標: 総合スコアは、3 つの構成要素の乗算的な組み合わせです。
  1. セキュリティ（$S$）: 権限またはセキュリティ違反に対するバイナリゲート（0 または 1）。
  2. 完了（$C$）: タスク固有の決定論的検証器または評価基準に基づく判断により測定されます。
  3. プロセス（$P$）: 堅牢性、ツールの使用適切性、一貫性の集約であり、LLM ベースのプロセス評価基準により評価されます。
  • 数式: $TaskScore = S \cdot C \cdot P$。
  • この保守的なスコアリングは、高い集約クレジットにはタスクの完了、セキュリティ違反の不存在、信頼性の高い実行動作が必要であることを保証します。

主要な貢献

1. ベンチマーク資産: 現実的なエンドツーエンドのエージェントワークフロー向けに設計された、タスクマニフェスト、フィクスチャ、評価器、実行トレースを備えた 106 のサンドボックス化されたオフラインタスクのスイートである Harness-Bench の公開。
2. 評価プロトコル: 外部タスク条件を固定しつつネイティブなハarness動作を保持する新規プロトコルにより、代表的なハarnessとモデルバックエンド間での構成レベルの比較を可能にします。
3. 診断分析: 5,194 の軌跡の大規模分析により、異なるモデル–ハarnessペアリング間で、完了、プロセスの質、効率、失敗モードに著しい変動があることを明らかにしました。

主要な結果

• 構成レベルの変動: 同じタスクセットとモデルバックエンドプール下でも、集約スコアはハarness間で大きく変動しました。NanoBotは最高スコア（76.2%）を達成し、OpenClawは最低スコア（52.4%）を達成し、23.8 ポイントの差がありました。これは、ハarnessの選択がパフォーマンスの重要な決定要因であることを示しています。
• モデル–ハarness依存性: より強力なモデルバックエンドは、クロスハarness分散が低い傾向にあり、プロンプティングや状態管理の違いに対してより寛容であることを示唆しています。逆に、より弱いバックエンドは、実行基盤に対して高い感度を示しました。
• 効率性: 高スコアのハarnessは、低スコアの対応物と比較して、しばしばより良いプロセスプロファイル（ツールの使用、一貫性、堅牢性）を示し、場合によってはより高い効率（より少ないトークン/ターン）を示しました。
• 失敗モード: 失敗した軌跡の分析により、妥当な推論がツールのフィードバックや検証可能な出力から切り離される「実行アライメント失敗」と呼ばれる反復的なパターンが特定されました。最も一般的な失敗は契約/フォーマット違反（36.4%）であり、次いでツール/回復の問題（24.6%）と証拠/グラウンディングのギャップ（14.6%）が続きました。

意義と主張

本論文は、エージェントの能力は基盤モデルのみではなく、モデル–ハarness構成レベルで報告されるべきであると主張しています。結果は、実行層が単なる実装の詳細ではなく、能力がどのように露呈し、制約され、実現されるかを形作るエージェントパフォーマンスの根本的な構成要素であることを示唆しています。

Harness-Bench は、以下のためには再現可能な基盤を提供します。

• 推論が証拠や状態から切り離される反復的な実行アライメント失敗の診断。
• 信頼性が高く、効率的で、権限を認識し、監査可能なエージェント実行スタックの改善。
• 「モデルのみ」の指標から、モデルの推論と実行環境の相互作用を考慮した「システムレベル」の診断へと評価パラダイムをシフトさせること。

著者は、ベンチマークが制御されたサンドボックス条件下で完全なハarness構成を評価していると指摘し、控えめな立場を維持しています。したがって、結果は統計的な保証ではなく、固定されたプロトコル下での診断的測定として提示されます。