概要
同じモデルを使っていても、プロンプト、ツールの見せ方、ワークフロー、メモリ、失敗時の復旧処理が違えば、エージェントの結果は変わる。ハーネス最適化（harness optimization）は、モデル重みを固定したまま、この周囲の実行系を実行記録（trace）と評価から更新し、後続タスクへ持ち越す問題である。
たとえば、エージェントがツールの結果を確認せずに回答したとする。指示を変える、確認手順を追加する、回答前に検証器（validator）を置く、といった修正候補を作れる。ただし、候補を作っただけでは改善とは言えない。現行版（incumbent）と同じ条件で比較し、採用した変更を次のタスクへ残す必要がある。
何をハーネス最適化と呼ぶか
ハーネス（harness）には、システムプロンプト、コンテキスト構築、検索、永続メモリ、ツール仲介、ワークフロー、検証、再試行、差し戻し（rollback）が含まれる (Weng 2026年)。本書では、次の二条件を満たす更新をハーネス最適化として扱う。
- 実行から得た記録や評価が更新を駆動する
- 更新後のハーネスが版として保存され、将来のタスクへ持ち越される
この定義は、既存研究を記述するための範囲である。一方、更新を信頼できる改善として採用するには、最適化器（optimizer）から分離した評価器（evaluator）で現行版と更新候補（candidate）を測り、事前に決めた採否規則（acceptance rule）で次の版を選ぶ。本書はこれを推奨評価プロトコルとして扱う。既存手法がこのプロトコルを満たすかどうかは、手法の定義とは分けて評価する。
対象範囲
重要な境界は、更新後のハーネスが将来の実行へ残るかである。一回答の途中で候補を生成して破棄するだけなら、ハーネス最適化には含めない。
| 変更 | 本書での扱い |
|---|---|
| プロンプト、ツール方針、ワークフロー、メモリ方針を評価後に保存する | 含める |
| メモリへ通常の実行記録を追加する | 状態更新であり、それだけでは最適化と呼ばない |
| 一回のタスクでサンプル数や内省回数を増やす | 次回へ変更が残らない推論時スケーリング（test-time scaling）であり、含めない |
| ファインチューニングや強化学習（reinforcement learning, RL）でモデル重みを変える | モデル最適化であり、別に扱う |
自律型研究や自己進化エージェントという名前だけでは対象に含めない。上の二条件を満たすハーネス更新ループ（harness update loop）があるかで判断する。
Reflexionは失敗後の内省を同じタスク内の次の試行で利用する (Shinn ほか 2023年)。これはタスク内の状態更新の境界例であり、独立した将来タスクへ版として持ち越す永続的ハーネス更新（persistent harness update）とは分ける。
Harness-R1では対象モデル（target model）を固定し、別の編集器が更新候補を生成する。学習するのは編集器だが、最終的に更新される対象はハーネスである (Shao ほか 2026年)。
信頼できる改善として採用する
現在使っているハーネスを現行版 \(H_t\)、新しく試すものを更新候補 \(H'_t\)とする。対象エージェント（target agent）\(A_{\theta,H_t}\)の\(\theta\)は固定したモデルパラメータである。このエージェントを実行すると、実行記録 \(\tau_t\)と評価 \(y_t\)が得られ、最適化器 \(O\)が更新候補を作る。
\[ H'_t = O(H_t, \tau_t, y_t), \qquad H_{t+1} = \begin{cases} H'_t & V(H'_t, H_t)=\mathrm{accept},\\ H_t & \text{otherwise}. \end{cases} \]
推奨評価プロトコルでは、採否規則 \(V\) が外部評価器による現行版と更新候補の評価記録を比較する。最適化器は候補を提案できるが、評価器や\(V\)は変更できない。対象モデルと環境も原則として固定し、変更する場合は別の版として比較する。
この境界を 図 1 に示す。
更新ループ全体を比較する
本書では、個別のモデル名やエージェントフレームワークではなく、次の更新ループ全体を比較する。
\[ \text{Current harness} \rightarrow \text{Execution} \rightarrow \text{Evidence} \rightarrow \text{Candidate generation} \rightarrow \text{External evaluation} \rightarrow \text{Acceptance / rollback} \rightarrow \text{Next version}. \]
同じプロンプト最適化器でも、訓練例だけで候補を選ぶ方法と、未使用タスクで確認する方法では、改善という主張の強さが異なる。同じワークフロー編集器でも、対象の失敗だけを直す方法と、既存の成功や安全性まで確認する方法は分けて考える。
比較できる実験にするには、開始前に次の五点を固定する。
- 変更範囲: 変更可能なファイル、フック、プロンプト、ツールスキーマ
- 固定条件: API、権限、タイムアウト、出力スキーマ
- 保存する状態: タスクをまたいで残るもの
- 評価指標: 品質、コスト、応答時間、失敗率の集計方法
- 採否規則: 更新候補を採用・棄却し、必要なら元へ戻す条件
たとえば「行動前フックは変更可、評価器とツール権限は変更不可」と書ける状態にする。この境界が曖昧だと、性能差がハーネスの変更によるものか、条件の違いによるものか分からない。