XYZNOT

論文 · arXiv 2610.14224

Harness^2: 開放型世界のための再帰的エージェントハーネス化

Harness^2: Recursive Agent Harnessing for an Open World

公開日 cs.AIcs.CLcs.LG arXivPDF

XYZNOT で読む(全文翻訳と AI 解説)

3行まとめ

  1. 🎯 オープンワールドのエージェント運用では、新規タスクに正解検証器が存在せず、タスク固有のハーネス編集は将来のタスクに転移しません。
  2. 🔧 Harness2は連動する2つの再帰レベルを導入します。対照的なPropose–Probe–Composeステップを用いるタスクレベルの再帰と、タスク間で継続的改善ライブラリを更新するハーネシングレベルの再帰です。
  3. 📈 単一ステップでWorkBuddy-Benchで最大11.5ポイント、JobBenchで4.5ポイント、LABで11.8パーセンテージポイントの向上を達成し、並列または逐次再帰によってさらなるゲインが得られます。

概要

LLMエージェントの能力は、基盤となるモデルだけでなく、その実行ハーネスにも依存します。再帰的自己改善(RSI)は、これらのハーネスを自動的に進化させる有望なアプローチです。しかし、オープンワールド環境にRSIを適用するには、依然として2つの重大な課題が存在します。第一に、オープンワールドのタスクは通常、ハーネス設計段階では未知であり、テスト時にも新規であるため、オンラインでのハーネス編集を確実に導く正解検証器(ground-truth verifier)が存在しません。第二に、RSIのプロセスはタスク依存性が高く、新しいシナリオへの汎化が困難です。本論文では、これら2つの課題に対応する、プラグアンドプレイ型の再帰的エージェントハーネス化フレームワークであるHarness^2を提案します。本手法は、接続された2つの再帰レベルを備えています。タスクレベルの再帰では、対照的なPropose-Probe-Composeステップを用いて現在のタスクのハーネスを洗練し、正解検証器なしでも確実に編集を誘導します。これは並列または逐次再帰によってさらにスケール可能です。続いて、ハーネシングレベルの再帰がこれらの編集から経験を抽出し、継続的改善ハーネスを更新することで、エージェントが将来のタスクにより適切に適応できるようにします。3つの専門的ベンチマークと4つのモデル・ハーネス構成にわたる実験において、単一ステップの適用だけでGLM-5およびGemini 3.5 Flashがベースハーネスに対して一貫して改善され、WorkBuddy-Benchで最大11.5ポイント、JobBenchで4.5ポイント、LABで11.8パーセンテージポイントの向上が見られ、タスクレベルの再帰予算を増やすことでさらなる向上が確認されました。

英語の原文概要

LLM agents' capabilities depend not only on their underlying models but also on their execution harnesses. Recursive self-improvement (RSI) offers a promising approach to automatically evolve these harnesses. However, deploying RSI in open-world settings still faces two critical challenges. First, open-world tasks are typically unseen during the harness design phase and novel at test time, leaving no ground-truth verifiers to reliably guide online harness edits. Second, the RSI process remains highly task-specific and fails to generalize to novel scenarios. We introduce Harness^2, a plug-and-play, recursive agent harnessing framework that addresses these challenges through two connected levels of recursion. Task-level recursion refines the current task's harness using a contrastive Propose-Probe-Compose step that reliably guides edits without ground-truth verifiers, and can be scaled further via parallel or sequential recursion. Harnessing-level recursion then extracts experience from these edits to update a continual improvement harness, enabling the agent to better adapt to future tasks. Across three professional benchmarks and four model-harness configurations, a single step consistently improves GLM-5 and Gemini 3.5 Flash over their base harnesses, yielding gains of up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points on LAB, with further gains as the task-level recursion budget increases.

論文解説

問題設定と動機

LLMエージェントの性能は、その実行ハーネス(固定されたベースモデルを取り囲むプロンプト、ツール、メモリ、サブエージェント、プラグインなどのランタイム足場)に大きく依存します。動的なオープンワールド環境では、エージェントは未知で複雑なワークフローに継続的に直面します。ハーネスに対する既存の再帰的自己改善(RSI)技術は、主に以下の2つの課題に直面しています:

  1. 正解検証器の欠如: オンライン展開タスクでは、オンラインでのハーネス編集が性能向上に寄与したか悪化させたかを評価するための正解データや、テスト時に信頼できるスコアリング関数が得られません。
  2. タスク間転移の欠如: ハーネスへの直接的な修正は通常タスク固有であり、変化するタスク分布にわたって実行ハーネスを盲目的に引き継ぐと、不安定性や性能低下を引き起こします。

主要なアイデア

Harness^2は、2つの異なる再帰レベルを結合します:

  • タスクレベルの再帰(Task-Level Recursion): 対照的なPropose–Probe–Composeサイクルを通じて、正解検証器なしで実行中タスクの実行ハーネスを改善します。不変プロポーザル(エージェントの運用ワークフロー)とドメイン固有プロポーザル(専門家のドメインルール)を策定し、一致した条件下で両者を検証(Probe)し、検証済みの行動改善を統合(Compose)します。
  • ハーネシングレベルの再帰(Harnessing-Level Recursion): テスト時の洗練プロセスから得られた再利用可能な手続きの教訓と採用されたコンポーネントを、永続的なハーネス改善ライブラリに抽出し、後続タスクにおける改善器自体のメタ能力を向上させます。
  • プラグ可能なスケーリング: 並列再帰(個の候補プールを同時に統合)による探索の幅の拡大、または逐次再帰(回の反復チェーン)による深さの拡大をサポートします。

手法

エージェントは、固定モデル と、8つのファイルレベルのコンポーネント(システムプロンプト、ガードレール、メモリ、スキル、ツールガイダンス、スクリプト、サブエージェント、ミドルウェアプラグイン)からなる編集可能なハーネス ()に分解されます。

タスクレベルの再帰

タスク 、実行履歴 、および固定された改善ハーネス に対して、対照ステップ が更新されたハーネス 、実行ログ 、およびステップログ を生成します:

  1. Propose(提案): 参照実行 をサンプリングします。 と を条件として、不変候補(手続き/ツールフロー)とドメイン固有候補(専門家の制約)を生成します。
  2. Probe(検証): 候補を 上で実行し、参照実行に対する行動の対照差を観察します。
  3. Compose(統合): 候補プールから、検証済みで競合のない編集を選択的にマージします。

並列再帰では、個の不変候補およびドメイン候補がサンプリングされ、回の独立した統合セッションによって後続ハーネスが生成されます: 逐次再帰では、回の改善ステップが直列に連結されます:

ハーネシングレベルの再帰

タスク完了と成果物の選定後、改善プロセスは改善ログ全体 をレビューし、改善ハーネスライブラリを更新します: 教訓は具体的な軌道の対照差に明示的に条件付けられるため、誤った因果帰属が防止されます。

結果

Gemini 3.5 FlashおよびGLM-5を用い、OpenCodeとCodexの環境下で、WorkBuddy-Bench (WB)、JobBench、Legal Agent Benchmark (LAB) にわたって評価を行いました:

  • 単一ステップ()でのゲイン: WB Avg.で最大ポイント(OpenCode上のGLM-5: )、JobBenchでポイント(OpenCode上のGemini: )、LABの部分合格率でパーセンテージポイント(OpenCode上のGLM-5: )の向上を達成。
  • 予算スケーリング: の並列再帰を追加することで、WBでさらに〜ポイント、JobBenchで〜ポイント、LABで〜パーセンテージポイントのゲインが得られました。
  • 同一モデルによる改善: ゲインが外部のより優れたモデルに依存しないことを実証しました。同一モデルが実行者とハーネス編集者の両方を務める場合(GLM-5からClaude Opus 5まで検証)、すべてのベンチマークで一貫した性能向上が見られました。
  • コンポーネントのアブレーション: ライブラリ、役割のスコープ限定、統合(Compose)を除去すると、WBの性能はそれぞれ 、、 ポイント低下しました。

限界点と今後の課題

  • 推論計算のオーバーヘッド: 複数のハーネスの提案、検証、統合を行うため、トークンとロールアウトのコストが大幅に増加します。
  • 確率性と帰属バイアス: 正解検証器がないため、実行の分散が大きい場合、行動の対照差に依存することでクレジット割り当てのノイズや、過度に保守的・制限的な編集につながることが稀にあります。
  • ライブラリの肥大化とプルーニング: ライブラリはコンポーネントを逐次蓄積するため、長期的なタスクホライズンにおいて陳腐化した教訓を刈り取ったり、競合するスキルを積極的に統合・整理するメカニズムは未解決の課題です。

重要用語

harness
固定されたベースLLMを取り囲み、エージェントとして動作させるためのシステムプロンプト、ガードレール、メモリ、スキル、ツールガイダンス、スクリプト、サブエージェント、ミドルウェアプラグインなどのランタイム足場。
recursive agent harnessing
タスクレベルの再帰が実行中タスクの実行ハーネスを改善し、ハーネシングレベルの再帰がタスク横断的に改善メカニズムを更新する、二重ループの再帰的自己改善フレームワーク。
Propose–Probe–Compose
スコープを定めたハーネス変更を提案(Propose)し、参照実行に対してその実証的挙動を検証(Probe)し、正解ラベルなしで検証済みの差分を選択的に統合(Compose)する対照的ハーネス改善ステップ。
parallel recursion
複数の不変候補およびドメイン固有候補を同時に生成・検証し、それに続いて複数の独立した統合セッションを行うタスクレベルの探索アプローチ。
sequential recursion
蓄積された実行履歴を条件として、連続する対照的改善ステップを逐次連鎖させる反復的タスクレベル改善戦略。
harness improvement library
採用された実行可能ハーネスと、将来のハーネス修正に役立つ文書化された運用上の教訓を保持する、タスク横断的な永続リポジトリ。
invariant candidate
ツールの使用、プランニング、決定論的スクリプト記述、コンテキスト管理など、一般的なエージェント実行の課題を対象とするハーネス変更候補。
domain-specific candidate
特定の運用ドメインに関連する手続き要件、ドメイン知識、整合性チェック、成果物の規約などを対象とするハーネス変更候補。

よくある質問

Harness2は正解検証器やタスクラベルがない状態で、どのようにハーネス編集を評価するのですか?

未編集の参照ロールアウトと条件を揃えて候補を検証(Probe)する際に得られる行動の対照差を利用します。正解スコアを仮定するのではなく、統合モジュール(composer)が実行軌道内の具体的な行動メカニズム、エラーの軽減、出力の整合性を精査します。

Harness2はハーネス編集役として、より強力なLLMを必要としますか?

いいえ。実行役とハーネス編集役の両方に全く同じモデルを使用した実験(GLM-5、Gemini、Claudeの各バリアントで検証)でも、GLM-5を用いたLABでの13.7ポイントの向上を含め、評価したすべてのベンチマークで一貫した改善が示されました。

提案されたハーネス編集がエラーを引き起こしたり、検証に失敗した場合はどうなりますか?

Harness2は構造的検証(スキルトリガーやスクリプト構文の確認など)を実行します。無効な場合は検証器のフィードバックを受けて1回再試行し、再度失敗するか空出力などの致命的なランタイム障害が発生した場合は、前回の安定したハーネス状態に安全にフォールバックします。

あるベンチマークで蓄積された経験を別のベンチマークに転移させることはできますか?

はい。ベンチマーク間転移の実験では、JobBenchで蓄積された改善ライブラリをWorkBuddy-Benchに転移することで、追加の検証(Probing)を行うことなく、Code(+0.6)、Web(+0.5)、Office(+2.9)の各ドメインで1ステップ改善の性能が向上しました。

このページの解説は AI が論文から作成したもので、誤りを含む場合があります。詳細は原文をご確認ください。

XYZNOT で読む(全文翻訳と AI 解説)