同じmodelが62％と33％を記録した。Harnessも性能の一部だ

Hugging Faceは、同じweightを持つ同一modelが、あるagent harnessで62％、別のharnessで33％を記録した例を公開した。関連資料はOpenEnvとHarborを接続し、既存のcoding agentの動きを取得するmulti-harness RLの方法を示す。

Capture proxyがblack boxをtraining traceに変える

提案では、trainerとHarborの間にOpenEnvを置く。Capture proxyはClaude Code、Codex、OpenCodeなどblack box型toolの通信を観測し、trainingに使えるtoken IDsとlogprobsへ変換する。公開資料はこの3つに加えて34種類のharnessへの対応を記している。

目的はtraining layerを特定のagent interfaceから切り離すことだ。作者によると、各harnessやtraining codeを書き換えず、実際に使われている環境の中で異なるtask setをRL trainingできる。

Harness versionのないmodel evalはsystemの半分しか測らない

29ポイントの差は、modelのplanningだけが性能源ではないことを示す。Harnessはtoolを選び、contextを組み立て、retry loopを管理し、errorを返し、agentの終了を決める。weightが同じでも、どの選択も結果を動かし得る。

Teamはmodelとdatasetだけでなく、harness version、system prompt、利用可能なtool、step上限、scoring methodも記録する必要がある。これらがなければbenchmark値を再現できず、production workflowへ確実に移せない。

62％と33％には完全なtest protocolがまだ必要だ

公開postは大きな差を示すが、短い告知では全test条件、sample size、uncertainty intervalを確認できない。この差が示すのはharnessへの感度であり、特定interfaceの普遍的な優位ではない。

Capture proxyは詳細なinteraction traceも取得する。RLには有用だが、企業利用ではprompt内のsecret、source code、retention rule、training dataとeval dataの分離を扱う必要がある。

Harness間のtransferとhidden taskが成否を決める

重要なtestは、複数harnessでのtrainingが、学習中に見ていないtoolやtask setでも性能を上げるかどうかだ。繰り返しrun、公開されたtrace、単一環境だけでtrainingしたmodelとの比較も欠かせない。

効果がtransferすれば、multi-harness RLは一つのagent loopへのoverfittingを抑えられる。toolを変えた瞬間に消えるなら、一つのcourse専用driverを鍛えただけだ。

Lilithの判定

同じengineを積んだmodelが2つのcockpitに入り、62％と33％で戻った。Harness versionを書かないeval reportは、machineの半分をsheetの下に隠している。