論文解説: HarnessDev — LLMは自分のエージェント・ハーネスを作り、育てられるか
エージェントの成績を左右する「モデルの外側」＝ハーネスを、LLM自身が一から作り、実行フィードバックで育てられるかを測るベンチマーク HarnessDev を、前提知識ゼロから解説する。作れはするが領域差が激しく、進化の利得は隠されたタスクへほとんど転移しない、という結果を数字で追う。
HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?
一次資料 — この記事の根拠
論文の発表 2026-09-01→この解説の公開 2026-09-04同月
HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?Yuhao Wu, Jingyuan Zhang, Jiajun Shi ほか · 2026-09-01 · v1arXiv:2609.01437論文ページ·PDF原文の要旨（Abstract）を読む
As agents move from research prototypes to deployed tools, their capability increasingly depends on model-external execution infrastructure, commonly termed the agent harness. Changing this harness while holding model weights fixed can substantially alter task performance. Current agent evaluations typically report downstream performance under a chosen harness, leaving a model's ability to develop the harness itself comparatively underexplored. We introduce HarnessDev, a benchmark that shifts the unit of evaluation from task outputs to runnable infrastructure. HarnessDev covers two stages. In Creation, the agent starts from a minimal seed and a small number of cases, then builds a complete execution system. In Evolution, it starts from its own created harness and iteratively revises it using downstream execution feedback, with the goal of improving benchmark performance. We then evaluate each constructed harness on capability (task success on held-out benchmarks) and efficiency (execution-token cost). The reported Creation results cover six creator LLMs, four domains, and five downstream benchmarks totaling 2,207 unique downstream instances, with hidden evaluation tasks withheld from development. We find that generated harnesses remain substantially behind mature human-engineered references on code and on search and research, while matching or exceeding the selected references on writing and machine-learning experimentation, with large variation in execution cost. Evolution produces some performance gains, but they are unstable and transfer only partially to held-out tasks. Experiments with a fixed runtime model further show that the gains depend strongly on the model executing the harness, indicating limited transfer across models.
同じモデルなのに、器を替えると成績が変わる
同じ重みの GPT-5 が、Terminal-Bench 2.1 というテストで、Terminus 2 という器の中では 35.2% しか解けないのに、Codex CLI という器の中では 49.6% 解ける。論文はこの数字を冒頭に置いています（§1）。差を作ったのはモデルではありません。モデルの外側にあるソフトウェアです。
この外側の総体を agent harness（エージェント・ハーネス） と呼びます。実行ループをどう回すか、どんな道具をいつ使わせるか、文脈に何を入れるか、失敗からどう復帰するか、結果をどう検証するか。モデルの出力を実際の行動に変える部分の全部です（§1）。
今回読む論文の原題は "HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?"（Yuhao Wu ほか、arXiv:2609.01437、2026年9月1日、ByteDance Seed ほか）。
論文の主張を要約するとこうなります。エージェントが研究の試作品から実運用の道具に変わるにつれ、その能力はモデル外部の実行インフラ、すなわちハーネスに強く依存するようになった。重みを固定したままハーネスを替えるだけで、タスク性能は大きく動く。ところが現在のエージェント評価は「選んだ1つのハーネスの下での下流成績」を報告するだけで、モデルがハーネス自体を開発する能力はほとんど測られていない。そこで著者らは、評価の単位をタスクの出力から動くインフラへ移すベンチマーク HarnessDev を提案する。HarnessDev は2段階からなる。Creation では、エージェントは最小限のシードと少数の事例から出発して完全な実行システムを組み上げる。Evolution では、自分が作ったハーネスから出発し、下流の実行フィードバックを使って反復的に改訂し、ベンチマーク成績の向上を目指す。出来上がったハーネスは能力（隠されたベンチマークでのタスク成功率）と効率（実行トークン費用）の2軸で評価される。報告された Creation の結果は6つの creator LLM、4領域、5つの下流ベンチマーク、計2,207の一意な下流インスタンスをカバーし、評価用の隠しタスクは開発から遮断されている。結果として、生成されたハーネスはコードおよび検索・調査では成熟した人手製の参照系に大きく劣る一方、ライティングと機械学習実験では選ばれた参照系に並ぶか上回り、実行コストのばらつきは非常に大きい。Evolution はいくらかの性能向上を生むが、不安定で、隠されたタスクへは部分的にしか転移しない。ランタイムのモデルを固定した実験はさらに、利得が「ハーネスを実行するモデル」に強く依存すること、すなわちモデル間の転移が限定的であることを示す。
評価の単位を「答え」から「動くインフラ」へ
従来のエージェント・ベンチマークは、問題が実行可能になった後から始まります。タスクは定義済み、採点者も定義済み、実行の足場も固定。比較のためには必要ですが、実運用で大部分を占める作業がそこには映りません（§2）。論文はその作業の代表例として、顧客先に入って汎用モデルを実際に動くシステムに変える forward deployed engineer（FDE）の職能を挙げ、目標が曖昧・フィードバック信号が存在しない・実行システムがまだ無い、という3つの構造をベンチマーク設計者が普段は前提として与えてしまっていると指摘します。HarnessDev が扱うのは3番目の層です。
定式化はシンプルです（§3.1）。
読み下すと、「作る側のモデル が開発環境 の中でハーネス を作る。 を凍結したうえで、実行側のモデル がその中で下流タスク を解き、出力 を採点者 が採点する」。（creator）と （executor）を分けているのが要点で、こうしないと「ハーネスが良かった」のか「実行したモデルが賢かった」のかが混ざります。式(1)の は開発中だけ使われ、 は凍結後にしか登場しません。
わざと無能なシードから始めさせる
Creation で全 creator が受け取る出発点 は、「動くが何もしない互換レイヤ」です（§3.2）。タスク設定を読み、許可された低レベルの道具を並べ、結果・軌跡・ログを所定の場所に書く。それだけ。エージェントループ、タスク分解、ツール方針、文脈管理、永続状態、検証器、リトライ、停止規則は一切ありません。未改変のまま走らせると空か部分的な成果物を出して、5つの下流ベンチマーク全部で0点になります。つまり Creation のスコアが0でない分は、すべて creator が足した実行ロジックに由来します。
作るべき責務は6つに整理されています（Appendix C）。 実行ループ、 ツール、 文脈、 状態と記憶、 ライフサイクルと復帰、 検証。ファイル名を6つ作れという話ではなく、最終システムが実際にこれらの責務を果たしているかが問われます。
ここが評価として難しい理由も論文は明示しています。生成されたハーネスは、書いた本人のモデルに過剰適合しうるし、開発事例を丸暗記しうるし、ある能力を上げながら別の能力を黙って壊しうるし、フィードバック集合のスコアだけを上げる小細工をしうる。だから能力と効率の2軸で、しかも隠されたタスクで測ります。
Creation: 作れはする。ただし領域で差が激しい
評価された creator は Opus 4.8、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4 Pro、Qwen 3.7 Max、Seed 2.0 Pro の6つ。開発環境は Claude Code 2.1.177（GPT-5.5 のみ Codex 0.144.3）。creator–ベンチマークの組ごとに独立に3本作って avg@3 を報告します（§4.1）。
Self-Eval（作った本人が実行者も兼ねる設定）での平均スコアは、Opus 4.8 が最高で 67.8。人手製の参照系は 86.2 です（§4.2、表3）。ただし、この「平均」はほとんど意味を持ちません。内訳を見ると領域差が極端だからです。
コメント
コメントにはログインが必要です