技術要約: Harness-R1

問題提起

動的な環境にデプロイされた大規模言語モデル（LLM）エージェントは、成功体験と系統的な失敗（例：ツールの誤用、状態の喪失、プロトコル違反）の両方を含むインタラクション・トラジェクトリを蓄積する。現在のエージェント改善のアプローチは、主にファインチューニングや強化学習を通じてモデルの重みを更新することに焦点を当てているが、「エージェント・ハーネス（agent harness）」、すなわちコンテキストの構築、ツールの媒介、アクションの検証、およびリカバリの管理を行う実行可能なランタイム・コードは、通常静的なままである。

ハーネスの変更は極めて重要である。なぜなら、同一のモデルの重みであっても、ハーネスの設定によって全く異なる能力を発揮するからである。しかし、ハーネスの直接的な修正は信頼性に欠ける。固定されたルール（例：Self-Refine）はしばしば性能を低下させ、フロントティア・モデルにハーネスの編集を促すプロンプティングは、これらのモデルが検証されたタスクの成功ではなく、テキストとしての妥当性を最適化してしまうため、不安定な改善しか得られない。核心となる課題は、観察されたエージェントの失敗に基づいて既存の実行可能なランタイムを編集する方法を開発することであり、その編集が理論的な推論ではなく、実際のパフォーマンス向上によって検証されることを保証することである。

手法: Harness-R1

Harness-R1は、ターゲットとなるエージェントを凍結したまま、専用の「ハーネス・エンジニア」のためのオンライン強化学習（RL）問題としてハーネス編集を扱うトレーニング・パラダイムを導入する。このシステムは、失敗から編集、そして再実行へと至るループ（failure-to-edit-to-rerun loop）で動作する。

1. 問題定式化

• 凍結されたターゲット: ターゲットとなるエージェント $A$（モデル + ベース・ランタイム）は固定されている。
• 失敗パケット (Failure Packets): タスクのバッチ $B$ が実行され、決定論的な抽出器が、タスクの制約、アクションと観察のエクセプト（抜粋）、および結果を含む「失敗パケット」($s_B$) をコンパイルする。
• エンジニア ($H_\theta$): 専用の9Bモデルがエディタとして機能する。これは失敗パケットを読み取り、実行可能なオーバーレイ（パッチ）$P$ を生成する。
• 実行可能なフック (Executable Hooks): パッチ $P$ は、モデルの重みを変えることなく、以下の4つの特定のポイントでエージェントのライフサイクルをラップする：
  1. エピソード初期化: コンテキストと状態のセットアップ。
  2. 意思決定前 (Pre-Decision): ガイドラインや制約を用いてコンテキストを拡張。
  3. アクション前 (Pre-Action): 提案されたアクションの検証、書き換え、または拒否。
  4. フィードバック後 (Post-Feedback): 観察内容を検査し、リカバリをトリガー。
• 報酬シグナル: パッチ適用されたターゲットが、同じタスクのバッチを再実行する。報酬は、パッチ適用前後の実行におけるパフォーマンスの差 ($\Delta_B$) である。これにより、実行後にのみ観察可能で微分不可能な、同一バッチ内の目的関数が作成される。

2. トレーニング・パイプライン

Harness-R1は、2段階のトレーニングプロセスを採用している。

• コールドスタート・教師ありファインチューニング (SFT): 強力なティーチャー・モデルが、失敗パケットからの編集レスポンスを提案する。これらは凍結されたターゲットに対して検証され、実行可能かつ退行（デグレード）を引き起こさないパッチのみが、エンジニアのポリシーを初期化するためのデータセットとして保持される。
• 結果に基づいたグループ相対方策最適化 (GRPO):
  • エンジニアは、失敗パケットに対して $K$ 個の候補パッチをサンプリングする。
  • 各候補は検証・インストールされ、凍結されたターゲットがタスクを再実行する。
  • 報酬は、$K$ 個の候補グループ内で正規化され、アドバンテージを計算するために使用される。
  • エンジニアのパラメータは、トークン平均クリップド・サロゲート目的関数を最大化するように更新され、パッチの「実現された有用性」を最適化する。

主な貢献

1. 定式化: 本論文は、失敗条件付きのライフサイクル全域にわたるハーネス編集を、ターゲットの重み更新とは異なる、専用エンジニアのためのオンラインRL問題として定式化した。
2. Harness-R1フレームワーク: コールドスタートSFTと、結果に基づいたGRPOを組み合わせたシステムを提案する。プログラム探索や候補選択のためにエディタを使用する従来の研究とは異なり、Harness-R1は、凍結されたターゲット上での実行結果に基づいて、エディタのポリシーを直接更新する。
3. 共進化 (Co-evolution): 本手法は、ハーネス・エンジニアとターゲット・エージェントが共進化できることを示している。バニラなターゲットに対して訓練されたエンジニアはそれを改善し、さらに再訓練されたエンジニアは、すでに直接的なファインチューニングが行われたターゲットをもさらに改善することができる。

実験結果

本手法は、3つのインタラクティブ・ベンチマーク（WebShop：ウェブナビゲーション、ALFWorld：身体性を伴うテキストベースのタスク、DBBench：データベースクエリ）で評価された。

• パフォーマンス向上 (バニラ・ターゲット): 凍結されたQwen3.5-9Bエージェントにおいて、Harness-R1は平均成功率を 44.3% から 53.6% へ（+9.3ポイント）向上させた。これは、プロンプトベースの戦略（例：性能を低下させたSelf-Refine）や、エディタとしてプロンプトされたフロントティア・モデル（例：48.8%を記録したGLM-5.2）を上回った。
• パフォーマンス向上 (ファインチューニング済みターゲット): ターゲット・エージェントの直接的なファインチューニングにより、ベースラインが59.2%に上昇した後でも、ターゲット特化型のHarness-R1エンジニアは成功率を 64.2% までさらに向上させた（+5.0ポイント）。これは、モデルの重みが更新された後でも、ハーネスの最適化が依然として有効であることを示している。
• 汎化性能:
  • クロスモデル: 学習された編集ポリシーは、20種類の未知のターゲットモデル（Llama、Gemma、Qwenファミリーの1Bから70Bパラメータまで）に転移し、各ターゲットに対して個別の再チューニングなしにプラスの改善をもたらした。
  • クロスタスク: 疎な失敗のエビデンス（10件の失敗）を用いて、エンジニアは保持されたタスクを +8.9ポイント 改善するパッチを生成した。これは、保持されたデータに対して負の結果や不安定な結果を示した大規模なフロントティア・モデルを大きく上回る。
• アブレーション研究: 特定のライフサイクル・フック（例：アクション前の媒介やフィードバック後のリカバリ）を削除すると性能が低下し、ゲインがエージェントのライフサイクル全体に分散しており、特定の環境に依存していることが確認された。

意義と主張

本論文は、ハーネス構築は学習可能な能力であり、伝統的な重みの更新を補完するものであると断じている。その主な意義は、最適化の対象をエージェントの内部の意思決定（重み）から、外部のランタイム・メカニズム（ハーネス）へとシフトさせたことにある。

• 妥当性よりも信頼性: フロントティア・モデルにコード編集を促すプロンプティングは、「正しく見えること」を最適化してしまうため信頼できないと著者らは主張している。Harness-R1は「実現された結果」から学習するため、編集が真に有益であることを保証する。
• 適応性: 一律のルールを適用する固定された戦略（例：Self-Refine）とは異なり、Harness-R1は特定の失敗モードに応じて条件付けられた編集を生成し、ターゲット・エージェント固有の弱点に適応する。
• 共進化: 結果は、エージェントがデプロイ後に、単にモデルを再学習するだけでなく、それを取り巻くランタイム環境を進化させることで継続的に改善できる道筋を示唆している。本論文は、このアプローチによって、エンジニアとターゲットが共進化でき、デプロイ後のエージェント改善への堅牢な経路を提供できると結論付けている。