OpenForgeRL、実環境のエージェントフレームワークを強化学習に接続――エージェントサーバーで訓練と実行を分離

エージェントモデルは本番環境で単独動作するのではなく、通常はCodexやOpenClawなどのharnessに組み込まれ、そこで複数ターンのコンテキスト、ツール、サブプロセス、外部環境が管理される。既存のSFTやRLの訓練スタックは、多くの場合、rolloutを訓練プロセス内で同期的に生成できることを前提としており、このようなステートフルかつマルチプロセスの実際の実行経路を再現するのは難しい。研究者が別途簡略化したエージェントを実装すると、訓練とデプロイの間に不整合が生じる。

OpenForgeRLの中核は、軽量なエージェントサーバー層である。harnessは従来どおりモデルリクエストを送信し、エージェント層がそれをveRLなどの訓練システムの推論エンジンへ転送する。同時にプロンプト、応答、最終報酬を記録し、訓練可能なtrajectoryとして再構築する。別のKubernetesオーケストレーターはrolloutごとに独立したリモートコンテナを作成し、環境設定、タイムアウト、リソース回収を担当する。これにより、エージェントの実行をGPU訓練ノードから分離する。この設計では理論上、エージェント全体を書き直すことなく、harness、環境、RLアルゴリズムを差し替えられる。

著者らは約30B-A3BのMoEモデルを用いてOpenForgeClawを訓練し、ClawEvalで31.7 pass³、55.9 pass@3、QwenClawBenchで33.7を記録した。8BのOpenForgeGUIは、OSWorld-Verified、Online-Mind2Web、WebVoyagerでそれぞれ37.7、63.0、72.3を達成した。研究では、RLによって自己検証、ツールカバレッジ、複数ステップの計画完遂率が向上した一方、エラーからの復旧は依然として弱点だとしている。

エンジニアリング上の価値は、裸のモデルだけを訓練するのではなく、「エージェントフレームワーク自体」をpost-trainingの分布に組み込んだ点にある。ただし、現時点の数値はいずれも著者による自己評価であり、arXivページでは正式なコードリポジトリ、訓練データ、重みを直接入手できない。また、コンテナ障害時に不完全なtrajectoryを破棄する仕組みも、データ分布を変化させる可能性がある。今後は、オープンソース化の範囲、異なるharnessにおける再現コスト、悪意あるツールと訓練用認証情報を隔離するためのセキュリティ設計を注視する必要がある。