TL;DR
HarnessFlowは、モデルとタスク環境を固定したまま、LLMエージェントの実行用ハーネス（文脈管理・状態・ツール呼び出し・終了条件などを含む完全なコード）をMCTSで探索・改善する枠組みです。6ベンチマークで平均69.48%を報告し、初期ハーネス比+10.89pt、Meta-Harness比+3.95pt。15回の候補評価で探索し、手設計ハーネスより平均実行コストも低いとされています。
既存手法との違い
比較は主に、探索開始点のVanilla、手設計の実運用エージェント（Claude Code、Codex、OpenHands、Hermes）、完全コード修正を許すMeta-Harnessに対して行われています。条件は同一バックボーンGPT-5.4-mini（medium reasoning）、同じツールアクセスとタスクあたり資源制限、候補評価予算N=15、各分割R=5回実行です。Meta-Harnessは同じ初期ハーネス・コーディングエージェント・ベンチマーク・予算・評価プロトコルを使うが、永続的な探索木を持たず実行フィードバックから逐次改良する点が異なります。Figure 1(b)の6ベンチマーク平均ではHarnessFlow 69.48%、Meta-Harness 65.54%、Vanilla 58.59%、Codex 64.82%、Hermes 64.28%、OpenHands 62.61%、Claude Code 61.71%と報告されています。また平均per-task実行コストは手設計ハーネスより低く、Codexの41.4%とされています。
使える条件
対象は、モデルmとタスク環境・評価プロトコルを固定し、ハーネスhを完全な実行可能コードとして改良する設定です。初期ハーネスh0、検証セットDv、再利用可能な部品ライブラリL、経験アーカイブA、候補評価予算Nが必要です。原論文の主実験は6ベンチマーク（TAU2-bench、AppWorld、SWE-bench Verified、BigCodeBench-Hard、WebShop、BrowseComp-Plus）、GPT-5.4-mini medium reasoning、N=15、R=5、選択候補数K=5です。探索中は検証セットを使い、テストセットは最終評価のみに使われます。他モデル・他ドメイン・より大規模な予算での有効性は提示された本文からは確認できません。
限界と未検証の範囲
評価は6ベンチマーク・単一バックボーン・N=15の範囲に限られ、他モデルや他環境への一般化は未検証です。各候補の評価にはend-to-endのエージェント実行が必要で、探索自体の計算コストや評価回数上限の影響は本文で詳細に分離評価されていません。最終ハーネスは検証スコア最大で選ばれるため、検証セットへの依存やテスト分布差の影響は定量化されていません。またコーディングエージェント、部品ライブラリ、経験アーカイブの品質・設計への依存も本文からは分離できません。強みとしては、完全コードの協調変更、探索履歴の再利用、予算制約下での性能・コスト・サンプル効率の報告が挙げられます。
解説
ねえ智也くん、この「HarnessFlow」って何？ LLMエージェントのハーネスをMCTSで自動改善するって書いてあるけど、ハーネスって何のこと？
ハーネスは、モデルがツールや環境とやり取りするときの実行用の仕組みだよ。文脈の作り方、状態管理、ツール呼び出し、終了条件とかを含む完全なコード。モデルの重みは変えずに、そこを良くする話。
へえ、モデルを賢くするんじゃなくて、周りの段取りを良くする感じか。なんで自動化するの？
ハーネス設計がほぼ手作業で、専門知識が要るから。しかも候補ごとにエージェントを最後まで走らせて評価するから高コスト。だから限られた評価予算で、どう効率よく探索するかが問題になる。
で、HarnessFlowはどうやってるの？
まずハーネスを完全な実行可能コードとして扱う。候補と評価履歴を改良木に置いて、MCTSっぽい方針で次にどの候補を改良するか選ぶ。改良するのはコーディングエージェントで、過去のコードや実行フィードバック、再利用できる部品ライブラリを使う。
木で探索しつつ、中身の書き換えはコーディングエージェントに任せるんだ。選ぶ方針は？
スコアが高い候補を活かす exploitation と、あまり子を展開していない候補を掘る exploration を混ぜる。候補を最大K=5個に絞ってから選ぶけど、コードや証拠は他の枝からも使える。予算は15回の改良試行。
評価はどうなってるの？
6ベンチマークで、GPT-5.4-miniのmedium reasoning、N=15、各分割R=5回。比較はVanilla、手設計のClaude Code/Codex/OpenHands/Hermes、それにMeta-Harness。Vanillaは探索開始点の初期ハーネスで、手設計勢は同じバックボーンとツールアクセス、資源制限で評価してる。Meta-Harnessは同じ初期ハーネス・コーディングエージェント・予算・評価プロトコルだけど、永続的な探索木を持たず実行フィードバックから逐次改良する点が違う。平均は69.48%で、初期ハーネスより+10.89pt、Meta-Harnessより+3.95pt。平均per-task実行コストも手設計より低くて、Codexの41.4%って報告。
けっこう大きいじゃん。でも、探索中は検証セットで、テストは最後だけ？
そう。固定シードで検証とテストに分けて、テストは最適化中に見ない。最終的に検証スコアが一番高いハーネスを選んで、テストで評価する。だから結果は「テストを見ずに選べた」って意味では強い。
意義はどこにあるの？
モデルを固定したまま、ハーネスという実行側の設計を自動で探索できる可能性を示したこと。性能だけでなく、コストとサンプル効率も報告してる。3回の候補評価で平均best-so-far検証スコア71.5%、15ラウンドで74.2%って話も本文にある。
でも万能ではないんでしょ？
評価は6ベンチマーク、単一バックボーン、N=15の範囲。他モデルや他ドメイン、もっと大きい予算での一般化は提示本文からは確認できない。探索自体の計算コストも分離評価されてないし、検証セット依存や、コーディングエージェント・部品ライブラリ・経験アーカイブの品質依存も分離できない。
なるほどね。つまり「賢いモデルを買う」じゃなくて「賢い段取りを探す」ってことか。私のレポートの段取りもMCTSで改善してくれない？
まずお前のレポートを実行可能なコードにするところからだな。