論文解説: JIT-Agent — エージェントの「ハーネス」をその場で書き起こすモデル

エージェントの性能はモデルだけで決まらない。記憶・計画・行動・道具の4モジュールからなる「ハーネス」をタスクごとに生成する専用モデル JIT-Agent を、前提知識なしで解説する。

JIT-Agent: Scaling Harness Intelligence via Just-in-Time Harness Evolution

同じ料理人でも、厨房が違えば料理が変わる

腕のいい料理人を一人連れてきたとします。その人が作る料理の質は、腕だけで決まるでしょうか。包丁がどこにあるか、冷蔵庫に何が残っているか、注文票がどう回ってくるか、洗い物を誰がやるか — つまり厨房の作りが悪ければ、腕のいい料理人でも遅く、雑になります。

LLMエージェントも同じです。GPTやGLMのような基盤モデルは「料理人」ですが、その周りには必ずハーネス（harness）と呼ばれる仕掛けがあります。会話履歴のどこを残してどこを捨てるか。次に何をやるかをどうメモするか。どの道具（ツール／API／スキル）を今この瞬間に見せるか。行動をどう実行し、失敗したらどう戻すか。Claude CodeやCodexのような「エージェント製品」の正体は、モデルそのものではなく、この周辺の仕掛けの集合体です。

論文では、エージェントの能力は「モデルの重みだけの性質ではなく、モデルとハーネスのペアの性質である」と述べられています (§1)。強いモデルでも、間違った記憶・計画・行動プロトコルの後ろに置かれれば失敗する。逆に良いハーネスも、モデルがそれを理解して従えなければ意味がない、という双方向の関係です。

ここに問題があります。ハーネス設計は今のところ手作業で、タスクごとに人間が書き、しかもスケールしません。JIT-Agent（arXiv:2608.25593）は、この「ハーネスを書く」という作業そのものを機械にやらせる試みです。

ハーネスを4つの部品に分解する

まず「ハーネスとは何か」を、勝手な自由記述ではなく固定されたひな型に押し込みます。論文は、あらゆるハーネスを4つのモジュールの組として書けると仮定します (§3.1)。

言い換えると、ハーネス $\mathbf{h}$ は4つの部品の詰め合わせです。$\mathbf{M}$（Memory）は記憶、$\mathbf{P}$（Planning）は計画、$\mathbf{A}$（Action）は行動、$\mathbf{F}$（capability orchestration）は道具の割り当てを担当します。実行時の依存順は $\mathbf{M}\rightarrow\mathbf{P}\rightarrow\mathbf{F}\rightarrow\mathbf{A}$ と定められています (§3.1)。

1ステップの中身は、次の4行として定義されています。

$$\mathcal{C}_t=\mathbf{F}(\mathcal{C}_{\tau},\mathbf{s}_t,\mathbf{v}_t,\mathbf{d}_t),\quad (\mathbf{s}_{t+1},e_t)=\mathbf{A}(\mathbf{s}_t,\boldsymbol{\tau},\mathbf{v}_t,\mathbf{d}_t,\mathcal{C}_t)$$

順に読むとこうです。$\boldsymbol{\xi}_{<t}$ は「これまでに起きたこと全部の記録」、そこから記憶モジュールが今見るべき景色 $\mathbf{v}_t$ を作ります（履歴 → ビュー）。計画モジュールが、タスク $\boldsymbol{\tau}$ と内部状態 $\mathbf{s}_t$ とその景色から、今すぐやる一手の指示 $\mathbf{d}_t$ を作ります（ビュー → 局所指示）。次に道具モジュールが、使える道具の全集合 $\mathcal{C}_{\tau}$ から今回だけ見せる部分集合 $\mathcal{C}_t$ を選びます。最後に行動モジュールが状態を更新し、実際に発行する行動 $e_t$（ツール呼び出し、または最終回答）を吐きます。

この形式のうまいところは、既存のエージェントがすべて「4つの穴の埋め方の違い」として書き直せる点です。論文が挙げる例 (§3.1):

• 素のReActは $(\mathbf{M}_{\mathrm{full}},\ \mathbf{P}_{\emptyset},\ \mathbf{A}_{\mathrm{react}},\ \mathbf{F}_{\mathrm{all}})$ — 履歴は全部持ち、明示的なプランナーは無く、道具は全部見せる
• CodexやOpenCodeのような実用ランタイムは $(\mathbf{M}_{\mathrm{compact}},\ \mathbf{P}_{\mathrm{todo}},\ \mathbf{A}_{\mathrm{react}},\ \mathbf{F}_{\mathrm{all}})$ — 行動ループはReActのままだが、コンテキスト上限の手前で履歴を圧縮し、TODOリストを明示的に持つ
• ROMAのような再帰型は $(\mathbf{M}_{\mathrm{subproblem}},\ \mathbf{P}_{\mathrm{decomp}},\ \mathbf{A}_{\mathrm{rec}},\ \mathbf{F}_{\mathrm{route}})$ — サブエージェントを生やし、各々に別のコンテキストと道具を割り当てる

つまり「エージェントの流派の違い」は、多くの場合4つのスロットの選び方の違いに還元できる、というのが出発点です。そして4つのスロットに独立な選択肢がある以上、組み合わせの数は掛け算で増えます。人間が全部試すのは無理だ、という話につながります。

作り置き（AOT）か、注文を見てから作る（JIT）か

ハーネスを自動で良くする研究は既にあります。論文はそれらの多くを Ahead-of-Time（AOT、作り置き） と分類します (§1, §2)。実行ログを溜め、そこからハーネスのコードやプロンプトや道具を最適化し、「この一式が将来のタスクにも効くだろう」と期待して持続的な成果物を1つ育てる方式です。配備先の分布が安定していれば強力ですが、次に来る問題の構造を見る前に汎用ハーネスをコンパイルしておくことを要求します (§1)。

JIT-Agentが取るのは Just-in-Time（JIT、注文後に作る） の立場です。論文の観察はシンプルで、タスクによって必要なハーネスの「型」が違う、というものです (§1)。

• 広く探す検索タスク → 並列に証拠を探る形が向く
• ターミナル操作 → 素直な直列ReActループが向く
• ディープリサーチ → 集めた証拠に対するワーキングメモリが要る
• リポジトリ規模のコーディング → パッチ・テスト・トレースを置くファイルシステムが媒介になる

しかも適切なハーネスはドメイン依存であるだけでなくインスタンス依存だ、と論文は言います。だとすれば、1つの作り置きを全部に当てるより、タスクを見てからその場で組む方が筋が良い。ここから Model-as-a-Harness（訓練されたメタエージェントがその場でハーネスを生成し、任意の既製エージェントLLMがその下で動く）という定式化が出てきます (§1)。

13個の「種」を用意する — HarnessFactory

生成させるには、まずお手本が要ります。論文は共通プロトコル $\boldsymbol{\Pi}$ と共通カーネルの下で、代表的な13個の既存スカフォールドを書き直して揃えました。これが HarnessFactory です (§3.2)。ReAct、Plan-and-Execute、ReSum、Flash-Searcher、GAM、MemoBrain、AggAgent、OAgent、AgentFold、HiAgent、DeepAgent、ROMA、AOrchestra の13件で、これが初期の種バンク $\mathcal{B}_0$（$K_0=13$）になります。

同じインタフェースに揃えることには2つの意味があります。1つは、4モジュールの表現力が本当に既存流派を覆えるかの検証。もう1つは、生成モデルに与える参照材料の供給です。運用が進むとバンクは $\mathcal{B}_0 \subseteq \mathcal{B}_n$ と育ち、各エントリはタスクと観測された報酬・レイテンシ・コストを抱えます。

3段階で「ハーネス知能」を訓練する

論文は、必要な能力を3つに分けています (§1)。❶ 適応性（タスクに合ったものを出せるか）、❷ 信頼性（そもそも動くか、壊れたら直せるか）、❸ 進化性（実行フィードバックを次の設計に活かせるか）。この3つをまとめて harness intelligence（ハーネス知能） と呼び、3ステージの訓練で獲得させます (§4)。

Stage I: お手本の模倣＋「効いて安い方」を選ぶ

より強い教師モデル $q_\phi$ に、タスク・プロトコル・使える道具の一覧・種バンクから引いた3つの参照スカフォールドを渡し、タスク適応ハーネスを書かせます。プロトコル検証と実行チェックを通ったものだけを採用してSFTデータにします (§4.1)。

ただしプロトコル準拠は最低条件にすぎません。動くハーネス同士でも、報酬・レイテンシ・費用は大きく違う。そこで同じバックボーン・同じ評価シードで比較し、次の条件を満たすときだけ「$\mathbf{h}^+$ の方が良い」という選好ペアにします (§4.1)。

$$r^+>r^-\ \land\ \ell^+\le\ell^-\ \land\ \kappa^+\le\kappa^-$$

読み下すと、報酬 $r$ は厳密に上がっていて、レイテンシ $\ell$ と費用 $\kappa$ はどちらも悪化していない（そのうえで少なくとも片方は厳密に改善している）ときだけ勝ちとする、ということです。「正解率は上がったがコストが倍」という改善を最初から選好データに入れない設計です。