Agent Lightning 1.0 が 2026 年 10 月 7 日、Microsoft Research Asia からオープンソースで公開された。フレームワーク全体で約 3,500 行という小ささが売りだ。狙いはエージェント強化学習の長年の不格好さにある。従来、エージェントを RL で訓練するには、訓練フレームワークの中にエージェントを再実装する必要があり、訓練されるものと実際にデプロイされるものが微妙に別物になっていた。今回のパラダイムは Harnessed Agentic RL と名付けられ、主張は 1 つだけだ。デプロイ時に使うハーネス（実行基盤）そのものが訓練に参加すべきだという。
従来手法の何が不格好か
今のコーディングエージェントはモデル単体ではない。コンテキスト管理、ツールプロトコル、実行ロジック、依存環境を各自が抱えており、mini-SWE-agent、OpenHands、Claude Code、Codex はそれぞれ流儀が違う。verl、AReaL、slime のような従来のエージェント RL は訓練側が対話ループを握る前提で作られているため、エージェントを替えるたびにループの再実装が発生する。費用がかかるうえ、再実装版と本番版で挙動が静かにずれ、訓練スコアは良くても本番が追いつかない。この摩擦は、過去 1 年で エージェント規模の開発基盤 が膨らむ過程で繰り返し現れてきた。
要はモデルとの間にプロキシを挟むこと
Agent Lightning はエージェントとモデルの間に OpenAI 互換の LLM プロキシを置く。エージェント側のコードは無改造でよい。今までモデルを呼んでいた先をこのプロキシに向けるだけで、訓練システムが各呼び出しのプロンプト、応答、対数確率を記録し、RL の訓練材料にできる。v1.0 は 3 部品構成で、rollout の保存とプロキシを担う API ゲートウェイ、エージェント実行を起動する Rollout コントローラ、verl 上に構築したカスタムトレーナから成る。実行は Kubernetes ネイティブで、エージェントは標準の K8s ジョブとして走るため、有料の商用サンドボックスに頼らず大規模なサンプリング費用を抑えられる。Collocated Async RL というスケジューリングでは rollout とモデル更新が同じ GPU を共有し、同期 RL 比で約 2 倍の高速化を、完全非同期より少ない GPU で達成したという。
6,000 サンプルで 14.6 ポイント上昇
同時に公開されたコーディングエージェントの訓練パイプラインは、SWE-smith のデータ、mini-SWE-agent、Qwen3.5-9B の組み合わせで、訓練サンプルは約 6,000 件、大規模な計算資源なしで回せる。RL 訓練だけで SWE-bench Verified の Pass@1 は 41.8% から 56.4% へ、14.6 ポイント上がった。実務者向けの注意点も明記されている。1 回の rollout が複数の訓練サンプルに分かれる場合、アドバンテージ計算と損失の正規化はサンプル単位ではなく rollout 単位で行うべきで、そうしないとサンプルの多い rollout が過剰に重み付けされ、検証報酬もポリシーエントロピーも不安定になる。
今試す価値があるのは誰か
動くハーネスを既に持ち、再実装のコストを理由に RL の後訓練を見送ってきたチームにはうってつけだ。接続点はプロキシのアドレス 1 つで、コード全体に目を通せる規模である。逆にエージェント自体がまだ不安定だったり、報酬設計が曖昧だったりするなら順番が違う。この枠組みが答えるのは「本物のハーネスをどう訓練に参加させるか」であって、「何をもって良くなったとするか」ではない。公開検証済みの完全な事例は今のところコーディングエージェントの 1 本だけで、他の種類のエージェントでの効果はコミュニティの報告待ちになる。
