Harness-R1、エージェントの失敗軌跡から実行フレームワークの修正を学習——Qwen3.5-9Bの成功率が9.3ポイント向上

多くのAIエージェントは、デプロイ後に大量の失敗軌跡を蓄積する。しかし、改善方法は通常、モデルを再度ファインチューニングするか、エンジニアがプロンプトやツールのコードを手作業で修正することにとどまる。Harness-R1は、エージェントの「harness」自体を学習対象にする。この実行可能なプログラム層は、コンテキストの構築、ツールとの連携、アクションの検証、エラーからの復旧を担い、対象エージェントの重みは凍結したままにできる。

システムは別途、9Bの「harness engineer」を訓練する。このモデルは、対象エージェントの失敗軌跡のバッチを読み取り、実行可能なフレームワーク用パッチを生成する。パッチを検証した後、同じタスク群で凍結済みの対象エージェントを再実行し、実際にタスクが成功したかどうかを報酬信号とする。訓練は、教師ありファインチューニングによるコールドスタートから始め、その後、group-relative policy optimizationを採用する。これにより、編集ポリシーは人間による修正を模倣するだけでなく、パッチがもたらした最終的な効果に基づいて更新される。

研究ではWebShop、ALFWorld、DBBenchで評価が行われた。Qwen3.5-9Bを対象エージェントとして使用した場合、モデルをファインチューニングすることなく、平均成功率は44.3%から53.6%へと9.3パーセントポイント上昇した。対象エージェントをあらかじめタスク向けにファインチューニングしたうえで専用のharness engineerを使用した場合でも、平均スコアは59.2%から64.2%に向上した。これは、モデル重みとエージェント実行フレームワークが相互補完的な2つの最適化軸になり得ることを示しており、継続的にデプロイされる環境で「インシデントから自動修復するエージェント」を実現する具体的な道筋にもなる。

一方、リスクも明白だ。ツールの検証ロジックや復旧ロジックを自動的に書き換えられるモデルは、安全チェックを削除したり、同じテスト群に過度に適合したり、監査が困難な挙動のドリフトを引き起こしたりする可能性がある。同じ失敗事例群をパッチの生成とフィードバックの両方に用いることで、過学習が増幅されるおそれもある。現時点で論文は、公開コード、パッチのデータセット、独立した再現結果を提供していない。エンジニアリングチームは今後、権限サンドボックス、差分レビュー、ホールドアウトテストセット、ロールバック機構が導入されるかどうかに注目すべきだ。