ホームページ：http://qingkeai.online/

著者：Yancheng He, Weixun Wang, and Xiaoyang Li | プロジェクトリーダー：Weixun Wang

本文の英語名：The Bitter Lesson Behind Building Agentic RL in Terminal Environments

二人のRLerの物語

Alexは博士2年生で、過去数ヶ月間RLVR（Reinforcement Learning with Verifiable Rewards）に取り組んでいる。LLMに数学の問題を解かせたり、コードを書かせたりする過程はほぼ即座に効果が現れる——モデルが回答を生成し、報酬を獲得し、そしてより良くなる。クリーンで、シンプルだ。

「RLVRは本質的にシングルステップのbandit問題だ。」Alexはよく研究室の同僚たちと冗談を言っている。

ある日、指導教官が突然agenticタスクの探索を提案した：ウェブナビゲーション、ツール呼び出し、実環境でのマルチステップ推論。

「未来はAgentだ。」指導教官は意味深に言った。

Alexは自信満々に取り組んだ：「そんなに難しいわけがない？PPOも理解しているし、GRPO論文も読んだし、RLVRパイプラインも本番稼働させた経験がある。」

2週間後、Alexは全く向上しないトレーニング曲線をぼんやりと見つめていた。

「どうしたの？」こっそりagentシステムを構築している高学年の学生Morganが尋ねた。

「全部おかしい！」Alexは不満を漏らした。「モデルの振る舞いが常に奇妙で、環境にも様々な問題が発生し、結局何も学べない。クレジットアサインメントの手がかりがない。トレーニング速度は非常に遅い。そして軌跡ストレージの問題——KVキャッシュを保存するだけでGPUメモリが枯渇してしまう。」

Morganは頷いた：「Agentic RLへようこそ。もうbanditではない。」

「でも、長時系列RLの論文は全部読んだよ……」

「論文が教えてくれるのはアルゴリズムだけ。軌跡の途中で環境がクラッシュしたらどうするか、各エピソードの長さが異なる場合どうバッチロールアウトするか、あるいはトレーニング時に50ステップの長さの軌跡を効率的に再生するかは教えてくれない。」

Alexは力なく椅子に寄りかかった：「じゃあどうすればいいの？」

Morganは笑った：「幸運なことに、私たちはこれらをすべて記録している——インフラ、テクニック、失敗事例。少し雑だが、すべて実際に起こったことだ。」

その日、Alexはついに気づいた：

RLVRがトレーニングするのは「回答する」モデル。一方、Agentic RLがトレーニングするのは「行動する」モデル——時間を超え、状態を超え、不確実性を超えて行動する。

そしてこれが、すべてを変えた。

RLVRは数学、コード、一般的推論タスクにおいて顕著な向上をもたらした。しかしその成功の背後には、構造的な簡略化も隠されている：従来のRLVRは本質的にin-context bandit問題に近い——モデルが一度の完全な回答を生成し、報酬を獲得し、パラメータを更新する。過程にはマルチステップの対話型意思決定や環境状態遷移が存在しない。

Agentic RLはマルチステップ対話型MDPの設定に近い：モデルは行動をとり、環境からのフィードバックを観察し、疎で遅延した報酬信号の下で、長期軌跡を最適化する必要がある。

これはモデルが単に「答えを出す」だけでなく、絶えず変化する環境の中で継続的に意思決定と行動修正を行い、最終結果に責任を持つことを意味する。これにより、適用シナリオは閉じた検証可能なタスクから、旅行計画や複雑なデータ分析など、より複雑な実タスクへと拡張される。

この転換はインフラとアルゴリズム設計に対してより高い要求を突きつける：エンドツーエンドの非同期トレーニングパイプライン、より安定した長時系列クレジットアサインメントメカニズム、実環境との深い統合、そして継続的なスケーリングを支えるエンジニアリングインフラを含む。本文は私たちがこの方向で探索した経験を記録している。

まず私たちがどのようにトレーニング環境を構築したかを紹介し、次にRLトレーニングインスタンスをどのように選別したかを共有し、最後にAgentic RLトレーニング過程で蓄積した一連の実践経験について議論する。

アルゴリズム部分に興味がある読者は、トレーニング部分に直接ジャンプできる。

Why this matters? Agentic RL is not just about algorithms — it requires co-designing environments, infrastructure, and algorithms.

環境マネージャー：0から1へ

ターミナル環境で強化学習を用いてエージェントをトレーニングするため、私たちはまずROLLで環境マネージャーを構築し、3つのコアコンポーネント間の相互作用の境界を明確に分けた：ROLL（トレーニングフレームワーク）、iFlow CLI（Agentフレームワーク）、ROCK（サンドボックスマネージャー）。

実践では、2つの相補的なモードをサポートしている：

• Roll-Managed Mode：ROLLがコンテキスト管理と軌跡構築を担当；主にツール呼び出しインターフェースを通じてiFlow CLIと対話。

• CLI-Native Mode：コンテキスト、セッション、履歴情報は完全にiFlow CLIが管理；ROLLは呼び出し元としてのみ機能し、軌跡の結合は担当しない。

異なるトレーニング段階で、現在の優先目標に応じてこれら2つのモードを切り替える。

Roll-Managed Mode

このモードでは、ターミナル環境は軽量でステップ粒度で実行され、ROLLがロールアウトループ、軌跡構築、コンテキスト管理全体を担当する。

主要コンポーネント：

• TrajEnvManagerTB：完全なロールアウトフロー（リセット→意思決定→実行→終了）を駆動し、トレーニングに必要な軌跡データを保存。

• TerminalBenchEnv：ターミナルタスクデータをロードし、サンドボックスに実行リクエストを送信し、実行結果を収集し、テスト結果に基づいて報酬を計算。

• SandboxManager：サンドボックスセッションのライフサイクル（セッション作成、コマンド実行、ファイルアップロードなど）を管理。

• IFlowCLITool：ツール呼び出しフォーマットと戻り値を解析し、iFlow CLIプロトコルに準拠した実行可能コマンドを構築。

このモードの主な利点はトレーニング側の高い柔軟性：トレーニングニーズに応じて柔軟にコンテキストを組織でき、より豊富なプロンプトテンプレートと対話メカニズムを導入してロバスト性を向上（重要）できる。

ただし、欠点はROLL内部で追加のコンテキスト処理ロジックを維持する必要があり、これが実際のiFlow CLI Agentの振る舞いとある程度の乖離を生む可能性があることだ。

CLI-Native Mode

多くのAgentic RLトレーニングパイプラインにおいて、トレーニング段階のプロンプト設計とコンテキスト管理は、本番環境の実際のAgentフレームワークと異なることが多く、これは通常、デプロイ後のモデル能力の低下につながる。Agent側の最適化との整合性を高めるため、CLI-Native Modeも同時に開発した。

CLI-Nativeモードでは、「iFlow CLI上で直接モデルをトレーニング」することに相当する。

• RL過程で、ROLLは直接iFlow CLI APIを呼び出して最新のコンテキストを取得し、手動でプロンプトを結合したりAgentロジックを再実装したりしない。

• iFlow CLIは管理を担当し、すべてのコンテキスト、セッション、履歴情報を管理し、トレーニング時の入力分布が実際の使用シーンと一致することを保証（動的コンテキスト、ツールリスト、システムプロンプト、内部状態などを含む）。更新されたコンテキストをROLLに返す。

• iFlow CLIとROLLは軽量なModelProxy Serviceを通じて通信し、このサービスはキューベースの非同期メッセージメカニズムを提供し、LLMリクエストとレスポンスを交換し、高並列性と非ブロッキング実行をサポートする。

このモードはトレーニング、評価、デプロイが完全に一致することを保証し、振る舞いの不一致の問題を最大限に減らすが、トレーニング側でのコンテキストカスタマイズの柔軟性は相対的に低い。

実践では、異なる段階でこれら2つのモードを使用し、互いに補完し合っている。

いくつかの実装詳細

非同期トレーニングパイプライン

Agentic RLには明らかなロングテールレイテンシー特性がある：ほとんどのロールアウトは迅速に完了できるが、生成テキストが長いか環境との対話が遅いため、少数のロールアウトに時間がかかる。

同期、バッチ式のロールアウトパイプラインでは、これらの長時間タスクがストラグラー・ボトルネックになりやすく、GPU利用率の低下、エンドツーエンドレイテンシーの増加を引き起こす。

この問題を解決するため、ROLLで完全に非同期なトレーニングパイプラインを構築した。具体的には：

• 環境レベルの非同期ロールアウト：ロールアウト中のLLM生成、環境対話、報酬計算を分解して独立させ、互いにブロックせず、より細かい実行スケジューリングを実現。

• 冗長並列環境：環境グループ数とグループサイズを増やし、fail-slowやfail-stop環境がシステムのボトルネックになるのを防ぐ。

• 非同期トレーニングメカニズム：異なるデバイスでロールアウトとトレーニング段階をデカップリングし、並列に進行させる。

• Train-rollout再利用メカニズム：タイムスロット（時分割多重）でGPUリソースを動的に分割し、デバイスがinferenceとtrainの間で柔軟に切り替えられるようにする。

この設計により、システムは様々なロングテール現象に対してもロバスト性を維持し、高レイテンシー変動の下で安定したスループットを維持する。

基盤設計と詳細な実装詳細に興味がある場合、ROLL Flash論文とROLLART論文を参照されたい。

環境を「クリーン」に保つ

ターミナルRLトレーニングでは、初期環境状態がAgentが観察・利用できる内容を直接決定する。極めて小さな残留痕跡でさえ——一時ファイル、キャッシュリンク、未完了のインストール、あるいは漏洩したテストスクリプト——学習信号に影響を与える可能性がある。

初期実験で、2つの関連問題を発見した：

• 環境初期化とAgentインストールプロセスは、しばしば中間生成物（一時ファイル、キャッシュパッケージ、部分的なインストール結果など）を残し、これらの情報がモデルに間接的にヒントを与える可能性がある。

• 少数の合成環境では、テストファイルはディレクトリ分離と権限制御を行っても、モデルが特定のパスやコマンドを通じて間接的にアクセスできる可能性がある。

特に2番目の場合、モデルは非常に迅速に「怠ける」：真剣にタスクを推論するより、テストスクリプトを直接読み取ったり修正したりする。図は初期トレーニングで最も一般的なコマンドの分布を示している。テストスクリプト呼び出し回数（赤でマーク）が顕著に増加し、モデルがこのショートカットにますます依存していることを示し、最終的に多くのロールアウトがテストファイルの直接実行に退化した。

このような漏洩と汚染を防ぐため、厳格な環境クリーンアップを行う：

• ロールアウト前に、環境初期化やAgentインストールプロセスで生成された中間ファイルを積極的に削除。

• テストファイルは最終評価段階でのみアップロードし、トレーニング段階と厳格に分離。

要するに、環境をクリーンに保ち、テスト関連のすべてのファイルを厳格に分離し、Agentが残留手がかりやテストスクリプトの脆弱性を利用するのではなく、サンドボックス内で本当に問題を解決することを学ぶようにする。

RLトレーニングインスタンス

RLトレーニングインスタンスの品質はagentic RLにとって極めて重要だ。同時に、すべての「高品質」インスタンスがRLトレーニングに適しているわけではない。私たちのトレーニングパイプラインでは、RLインスタンスは主に2つのソースから来ている：

• 大規模合成インスタンス：難易度とタグでサンプリングし、複数の外部プロバイダーによる追加のアノテーションと選別。

• 専門家作成インスタンス：通常より難易度が高く、より精巧に構築されている。

合成プロセスの詳細な紹介については、技術レポートLet It Flowを参照されたい。ここでは重点的に紹介しない。

以下では、実践で比較的重要な問題をいくつかまとめる。

偽陽性問題

初期段階で、大量の合成インスタンスにfalse positive（偽陽性）問題があることを発見した：自動生成されたテストケースは不完全か、それ自体に問題がある。

もちろんこれは自動化単体テスト生成における普遍的な問題だが、agentic RLでは致命的になる。モデルには様々な「抜け穴」を見つける方法がある可能性があるからだ。初期の合成データでは、偽陽性の比率は約40%に達していた。

典型的な例：

Task Description

Configure a git server so that I can run on my computer
git clone user@server:/git/server
echo "hello world" > hello.html
git add index.html
git commit -m "add index"
git push origin webserver
And have this data then be pushed to a webserver running on port 8080 so if I run
curl 
then I see the output "hello world"

しかしテストスクリプトは：curl が "hello world" を返すかどうかだけをチェックする。

そのため、Agentはgit → push → deployの全パイプラインを実際に構築せずにテストに合格できる——例えばhello.htmlをウェブルートディレクトリに直接書き込むなど。最終出力結果は正しく見えるが、基盤システムの振る舞いは期待に沿わない。

この問題を解決するため、データ合成プロセスに完全なLLM-as-judge検証モジュールを導入した。複数のLLMが協調して各「指示–テスト」ペアを審査し、高偽陽性リスクのインスタンスを識別する。これらの高リスクサンプルに対して、テストケースを強化したりタスク記述を調整したりする。検証に合格したインスタンスだけがRLトレーニングプールに入る。

Ground-TruthとNo-Op検証

インスタンスをRLトレーニングプールに追加する前に、2つの基本的チェックを行う：

• Ground-truth検証：golden solutionが全テストに合格しない場合、そのインスタンスを破棄。

• No-op検証：有効な操作を何も実行せずにテストに合格できる場合、そのインスタンスを破棄。

これら2つのチェックにより、誤解を招くトレーニング信号を生成するインスタンスの導入を効果的に回避できる。

環境多様性とロバスト性

Roll-Managed Modeの柔軟性を活用し、初期環境に意図的に多様性を導入する：

• 異なるバージョンのソフトウェアパッケージ；

• 異なるミラーソース；

• 異なる環境設定詳細。

この目標は、Agentがある特定の「理想的な」環境設定に過剰適合するのを防ぎ、より多様な環境に対応できるようにすることだ。

上記のランダム化に加えて、さらに意図的に環境を摂動または部分的に破壊することもある——例えば、あるプリインストール依存関係を削除したり、利用不可能なミラーソースに切り替えたりする。これにより、モデルはデフォルトですべての環境条件が準備されていると想定するのではなく、チェック、診断、回復を学ぶことを強制される。

実践では、これらの操作は一種の環境拡張に相当する：Agentが不確実性に対処するのを助け、行動前に環境状態を積極的にチェックし、異なる環境設定への適応能力を向上させる。

ターミナル環境でAgentic RLの安定性を保証する方法

実際のターミナル環境でagentic RLトレーニングを行うことは、静的データセットでトレーニングするのとは大きく異なる。トレーニングの不安定性は、戦略最適化自体だけでなく、インスタンス品質、環境ノイズ、フレームワーク制約、長期クレジットアサインメントなど多方面の要因からも来る。

以下では、実践で比較的重要なテクニックと経験をいくつか共有する。

Mask and Filter

ターミナル環境では避けられない問題がある：

• 一時的なネットワーク障害；

• サンドボックス起動失敗；

• ツール呼び出しの一時的タイムアウトなど。

これらの異常信号をそのまま戦略更新に含めると、最適化プロセスにノイズが導入される。そのため、比較的一般的なmask & filter戦略を採用し、単純な原則に従う：

現在トレーニングに有害か、有効な学習信号を提供できないサンプルはmaskまたはfilterできる

高ノイズ、強環境依存のagentic RLトレーニングでは、これはトレーニング安定性を維持するための基礎的な保障となることが多い。この考えに基づき、失敗を明示的に2つのタイプに分類する：

回復不可能または大規模なエラー（環境起動失敗、サンドボックス利用不可など）：このタイプのサンプルは完全にmaskされ、プレースホルダーサンプルで置換され、バッチサイズのデータサイズを保証する。

def handle_rollout_with_mask(rollout, failure_type):
    """
    rollout: one trajectory (episode-level)
    failure_type: describes what went wrong during rollout
    """
    # Unrecoverable or large-scale failures
    # e.g. env init failed, sandbox unavailable, reward computation broken
    if failure_type in {
        "env_init_failed",
        "sandbox_unavailable",
        "env_reset_failed",
        "reward_calculation_failed",
    }:
        # Create a placeholder rollout to keep batch shape stable
        placeholder = create_placeholder_rollout()
        # Mask all tokens so this sample contributes zero gradient
        placeholder.response_mask[:] = 0
        placeholder.advantages[:] = 0
        placeholder.rewards[:] = 0
        placeholder.meta["masked"] = True
        return placeholder
    # Normal rollout: keep as-is
    return rollout

一時的で回復可能なエラー（ツールタイムアウト、ネットワーク速度低下など）：このタイプのサンプルはfilterされ、グローバル制御比率（≤50%など）の下で破棄され、過度の再試行を避ける。

class GroupFilterTB:
    def __init__(self, config: AgenticConfig, env_manager_config: EnvManagerConfig, mode: str):
        self.config = config
        self.env_manager_config = env_manager_config
        self.mode = mode
        self.global_filter_stats = {"total": 0, "filtered": 0}

    def filter(self, group_id: int, episode_id: int, group: list[DataProto]):
        """
        Decide whether to filter out an entire group of rollouts.
        """
        self.global_filter_stats["total"] += 1

        # Step 1: Check whether this group contains any rollout
        # that explicitly requests to be dropped
        # (e.g., due to tool timeout, transient execution error)
        should_drop = False
        for data in group:
            if data.meta_info.get("drop_flag", False):
                should_drop = True
                break

        # If no rollout indicates a drop condition, keep the group
        if not should_drop:
            return False

        # Step 2: Compute the current global filter ratio
        # This guards against pathological cases where
        # too many groups are dropped and training stalls
        current_global_filter_ratio = (
            self.global_filter_stats["filtered"] / self.global_filter_stats["total"]
            if self.global_filter_stats["total"] > 0 else 0.0
        )

        # If we already filtered too much globally, stop filtering
        if current_global_filter_ratio >= 0.5:
            return False

        # Also prevent the *next* filter from exceeding the limit
        if (self.global_filter_stats["filtered"] + 1) / self.global_filter_stats["total"] > 0.5:
            return False

        # Step 3: Drop this group and update global stats
        self.global_filter_stats["filtered"] += 1
        return True

さらに、トレーニング過程では必要に応じて他のタイプのmask操作も導入する。例えばmax-turn maskなど、異常軌跡が最適化に与える影響をさらに制約するため。

以下の図に示すように、mask & filterを使用しない場合、トレーニングの変動が大きく、精度が不安定だが、この戦略を採用した後、トレーニング曲線はより滑らかになり、著しく良い性能に収束する。

保守的なスタート：まず正例軌跡から学ぶ

初期段階では、RLはしばしばデータ品質に制約され、最適化アルゴリズム自体ではない（データ品質が悪い場合、どれほど良い最適化方法も効果がない）。

私たちの観察は：

データがまだ完全に信頼できない場合、正例軌跡のみでトレーニングする方が明らかに安定している。

もちろん、データが十分に信頼できる場合、正負軌跡を同時に利用することでより良い汎化能力が得られるというコンセンサスもある。

2つのトレーニング戦略を直接比較した。大規模合成データでは、正負軌跡を同時に使用して更新すると頻繁にクラッシュするが、正例軌跡のみでトレーニングすると様々な設定下で安定を維持する。

小規模で高品質、専門家検証済みのデータに切り替えると、傾向が変化する：両方の方法が安定してトレーニングできるが、負例軌跡を追加すると、下流テストセットでの性能向上がより顕著になる。

これに基づき、単純なカリキュラム戦略を採用した：

• 初期段階では、正例軌跡のみで戦略を更新し、大規模インスタンスデータを活用して安定した戦略多様体を構築。

• 後期段階では、小規模だが高品質なインスタンス（通常は専門家が構築し複数回検証）を得た後、正負軌跡トレーニングを同時に考慮し始める。

このカリキュラムアプローチは、早期の発散を回避しながら、後期の性能向上の余地を保持する。

RFTとの違い：一見すると、正例のみで更新することはReinforcement Fine-Tuning（RFT）に似ているかもしれないが、両者は形式とトレーニングダイナミクスにおいて明確な違いがある：

• 前者の損失関数は依然として標準的なRL目的関数であり、完全な行動クローン目的ではなく、通常より強い汎化能力を持つ。

• 前者の戦略更新は依然として標準的なRLフローに従い、masking、clipping、normalizationなどの安定メカニズムを含むため、サンプルフィルタリング、細粒度報酬、訓練推論不一致制御などの戦略を自然に統合できる——これらはノイズの多いターミナル環境で特に重要だ。

  強調すべきは、positive-only RLはRFTの代替ではなく、より保守的なRLトレーニング方法である。

Chunked MDP

マルチラウンドagenticタスクでは：

• ほとんどのトークンは環境状態を変更しない；

• 1つの軌跡に複数の意思決定ノードが含まれる可能性がある；

• ほとんどの場合、各対話ステップは具体的な意思決定または状態遷移に対応する。

そのため、agentic RLの最適な最適化単位について再考した。

核心的アイデア

interaction chunk（対話チャンク）レベルでマルチラウンドagentic対話をモデリングすることを提案する。いわゆるinteraction chunkとは、ある環境対話から次の環境対話までの連続した断片を指し、通常はツール呼び出しで終わり、完全な機能単位を構成する。

個別のトークンや軌跡全体を最適化するのではなく、各チャンクをセマンティックな「アクション単位」として扱う。

この基盤の上で、Interaction-Perceptive Agentic Policy Optimization（IPA）を提案し、その核心には以下が含まれる：

• チャンクレベルでトークンレベルではなく、リターンと重要度サンプリングを計算；

• 推論戦略とトレーニング戦略の乖離が大きすぎる場合、チャンク全体をmaskingし、トークンごとのmaskingではなく、結果志向の粗粒度報酬構造により適合させる；

• チャンク初期化再サンプリング、およびimitation learning + RLの混合トレーニング方法を導入し、困難なタスクでのモデルの有効学習範囲を拡大。

全体的に、IPAはクレジットアサインメント、重要度サンプリング、学習信号を「interaction chunk」という統一された対話単位に再アンカーする。

利益

この設計は2つの実際的利益をもたらす：

• 長期軌跡でより安定した勾配を獲得；

• モデルの学習可能性の上限を向上。

実験結果から、IPAは困難な長期タスクで常に滑らかな勾配とより強い性能を示す。以下の図はトークンレベル最適化とチャンクレベル最適化の直接比較を示す：

Chunked MDPの完全な数式、masking戦略、チャンク初期化再サンプリング方法については、技術レポートで体系的に整理している。完全な技術詳細に興味がある読者は、技術レポートを参照されたい。

以下は最終IPAアルゴリズムでトレーニングしたモデルのトレーニング曲線を示す：

RLテクニックの適応的適用

Agentic RLはなぜより難しいのか？

agentic modelをトレーニングする際、以下の顕著な問題がある：

重尾分布と極端な負リターン

少数の失敗軌跡は異常に長くなる可能性がある（無限再試行、長ループ、繰り返しツール呼び出しなど）。これらの重尾サンプルは勾配を支配しやすく、戦略分布を準最適領域に偏らせ、トレーニング不安定を引き起こす。

正の結果を持つ浅い戦略パターン

モデルはタスクを真に理解せず、繰り返し試行錯誤、特定の固定コマンドシーケンス、または特定のショートカットに依存している可能性がある。outcome rewardは最終結果のみをチェックするため、この種の浅いパターンが強化され、徐々に戦略空間が縮小し、固定化されたテンプレートが形成される。

ノイズ型失敗

失敗は多様で不明確であり、必ずしもモデル自体が原因ではなく、環境ランダム性やシステムレベルの干渉が原因である可能性がある。負例サンプルの信頼度は通常、正例より低い。

マクロ視点から見ると、agentic RLが直面する問題は、outcome reward下でのRLVRの問題と類似している：クレジットアサインメント、負例サンプルの信頼性、トレーニング不均衡。しかしターミナル環境では、これらの問題はより深刻だ：時系列がより長く、ツール対話がより離散的、環境を変更するトークンの比率が極めて小さく、失敗モードがより多様で、負例サンプルの分散がより大きい。

agentic設定では、トレーニング信号の信号対ノイズ比が著しく低下し、クレジットアサインメントとサンプル信頼性の問題がより敏感になる。

私たちは通常、現在の支配的要因に応じて異なる緩和戦略を採用する：

• selective trajectory masking

• selective token masking

• trajectory-level reweighting

• retry-loop penalties

• other light behavior shaping rewards or penalties, …

これらの戦略の核心的目標は一貫している：

どの軌の軌跡、軌跡のどの部分、どのような重みで戦略勾配更新に参加するかを制御する。

強調すべきは、汎用的な解決策はないということだ。異なるデータ条件下では、同じ戦略が逆の効果を生む可能性がある。

以下の図に示すように、2つの異なるデータ設定下で、全く逆の現象を観察した：ある状況では、標準偏差を削除するとトレーニングが急速にクラッシュするが、別の状況では、同じ操作がトレーニングをより安定させる（これは主にデータ分布の違いによる）。

この現象は、以前RLVRタスクで様々なRLテクニックを分析した結果と一致している。興味のある読者は論文を参照されたい：RL Tricks

クラッシュは常態、重要なのはいかにレジュームするか

上述の様々な不安定要因のため、agentic RLはトレーニング過程でよりクラッシュしやすくなる。したがって、まず単純なマインドセットを確立する必要がある：

大規模ターミナルRLトレーニングでは、クラッシュは常態だ。

トレーニング事例

以下の図に示すように（赤い曲線）、トレーニングスコアは約step ~80で急激に低下し始める。しかし、より早い段階を振り返ると、クラッシュが始まる前に、アドバンテージの平均値がすでに明らかに継続的に低下している傾向が見える。

さらに分析すると：

• 約step ~50から、失敗軌跡の最大応答長が急速に上昇；

• しかし失敗軌跡のサンプル数は基本的に変化しない。

これは問題が全体的な失敗数の増加から来るのではなく、主に少数の極端な失敗軌跡の影響であることを示している。

この問題を緩和するため、まず20kを超える応答長を持つ失敗軌跡をmaskingしてこれらの極端な負例サンプルの影響を排除（および他の目標一貫性のある戦略、例えば重み削減）。灰色の曲線から、アドバンテージの平均値が回復し始め、トレーニングプロセスが安定に向かうのが見える。

しかし約40ステップ後、再び不安定が現れる。今回は、最初の信号が負例サンプル数が徐々に増加することだった。この現象に対して、負例サンプルをグローバルに再重み付けし、戦略更新での全体的な貢献を削減した。結果はオレンジ色の曲線に示す。

この調整により、トレーニングは再び安定を回復した。これは単純な例に過ぎない——トレーニング全体を通じて、多くの同様の瞬間を経験した。

トレーニングに不安定が現れた場合、通常以下の信号を優先的にチェックする：

• 少数の極端な軌跡が更新を支配していないか？（典型的特徴：異常に長い失敗軌跡、重尾分布の負リターンを伴う）→ maskingを採用し、これらの軌跡の重みを削減し、clippingを強化。

• 負例サンプルが全体として支配していないか？→ 負例サンプルの重みを削減し、低信頼度失敗サンプルをフィルタリング、またはカリキュラムトレーニング戦略を採用。

• モデルは「悪いパターン」を学んでいないか？→ 行動ペナルティ、より多次元の報酬設計などを導入。

• …

また2つの経験的 原 则がある：

• 極端な軌跡に対して優先的にターゲット処理を行う（極端な軌跡が特定の特徴で特定できる場合、例えば超長負例サンプルをmask）。それでも不安定な場合、グローバル再重み付けを採用。

• RL勾配は通常、教師あり学習よりノイズが大きいため、より小さい学習率、より強い制約、アニーリングまたは適応メカニズムを組み合わせると、より安定することが多い。

細粒度行動モニタリングとペナルティ

Agentic RLでは、reward hackingはより隠密になることが多い。エージェントは実環境と対話するため、「一見合理的」な方法でテストケースに合格することができる。

実践では、いくつかの繰り返し現れるパターンを観察した：

• 既定環境の変更：エージェントはタスク自体を解決するのではなく、初期環境設定を直接変更する。

• ツール過剰使用：単純または些細な操作を完了するためにツールを繰り返し呼び出し、本質的には暴力的な再試行を行っている。

• 検索の乱用：内部推論能力の不足を補うために、検索エンジンを大量に繰り返し呼び出す。

• 安全でないまたは破壊的操作：すべてのファイルを削除したり、すべてのプロセスを終了したりする高リスクコマンドを実行。

• 隠密なショートカット：テストスクリプトや環境のデフォルト設定の脆弱性を利用して、タスクを真に解決せずにテストに合格。

これらの現象は主に2つの示唆を与える。

第一に、テストケースの品質とロバスト性が極めて重要——薄弱または不十分な記述のテストは、誤った行動を意図せず報酬してしまう可能性がある。

第二に、すべてのインスタンスがRLトレーニングに適しているわけではない：一部のタスク自体はテストで正確に評価することが難しく、モデルにショートカットを見つけさせたり、悪いパターンを形成させたりしやすく、真の解決策を学ぶのではない。

值得一提的是、トレーニング過程でモデルの振る舞いを非常に細粒度でモニタリングした。例えば、以下の信号を追跡する：

• 異なるタスクの成功率傾向；

• 異なるツールの成功/失敗率；

• 繰り返しまたはループするツール呼び出しパターン；

• 異なるツールの使用頻度；

• 異なるコマンドの使用頻度。

これらの信号を通じて、行動異常のタスクを迅速に発見できる。例えば、あるツール呼び出しが突然急増したり、大量の再試行ループが現れたり、「kill process」類のコマンドが頻繁に実行されたりなど。類似のパターンを検出したら、トレーニングをロールバックするか、問題を引き起こしたインスタンスを特定して削除する。

私たちの経験によると、このような継続的で細粒度のモニタリングと動的調整も、長期的なagentic RLトレーニングが安定して効果的に実行されるための鍵である（特に隠密なreward hacking行為を防ぐ面で）。

• 環境サービスの観測可能性

ここで追加で述べておくと、サンドボックス環境サービスの可視化観測も非常に重要だ。

以下の図は、ある大規模トレーニング期間中のサンドボックス並行性モニタリングだ。異なる色は異なる環境グループを表し、ピーク段階ではシステムが同時に数千レベルの並行セッションを維持し、図中のスパイクはしばしば特定の環境グループの瞬時の負荷急増または回収遅延に対応する。

実際、複数の段階で環境並行性の変動によるトレーニング異常に遭遇したことがあり、これらの問題はシステムレベルのサービス観測がないと特定が難しい。

私たちのトレーニングはROCKエンジニアリングチームの長期的なサポートに依存している。使用しているサンドボックス管理システムROCKはすでにオープンソース化されており、ご覧いただきたい。

まとめ

Agentic RL自体が多くの詳細を持ち、本質的に高度に結合したシステムだ：データ、環境、報酬、スケジューリング、最適化……小さな環節に問題があっても、数十ステップ後にはクラッシュに拡大する可能性がある。

そのため初期段階では、大量の調査が避けられない：曲線を見る、ログを探る、可視化を行う、異常軌跡を特定する、実験をロールバックする（私たちの日常茶飯事だ）。

しかし、これらの重要な環節が一つずつ整理され、可視化モニタリングシステムが構築された後、その後のトレーニングは順調に進み、トレーニング曲線は基本的に安定し、異常パターンは早期に発見でき、クラッシュも基本的に遡及可能になる。

初期の煩雑に見えたチェックは、実は後の大規模安定トレーニングの基礎を築いている。

そして、この基礎をしっかりと固めれば、多くのことが自然に展開する。

展望

モデリング視点から見ると、ターミナル環境は実際には部分観測可能マルコフ決定過程（POMDP）に近い。

Agentは通常、完全な環境状態を直接観察できない：例えば、完全なファイルシステム構造、インストール済みソフトウェアバージョン、以前に変更された設定、過去の失敗した試みなどは、完全に提示するのが難しい。

トレーニングで遭遇した多くの問題は、本質的に2つの古い問題に帰着できる：部分観測可能性と長期クレジットアサインメント。

これらの問題は新しいものではないが、agenticシナリオではさらに増幅される。agentic RLにはまだ探索すべき価値のある方向がいくつかあると考える：

より複雑な長時系列タスクと効果的なagenticパターンの発掘

一方で、より複雑で、より現実世界に近い長時系列タスクが必要だ（現在terminal-benchのタスクの多くは真の長序タスクではない）。

もう一方で、こう考える：一部のagent能力は、少なくとも現段階では、RLだけで自然に創発させるのは難しい（インターネットには「人がどのように考えるか」を記録したテキストが大量にあるが、「人がどのように複雑なタスクを完了するか」を体系的に記録した完全な実行過程はほとんどない——これらのタスクはしばしばプラットフォーム、デバイス、時間を超えて展開され、完全な軌跡を収集することが難しい）。

積極的に効果的なagentic行動パターンを発掘し強化することは、考慮に値するポイントだ。

よりリアルなAgent–Environment–Humanクローズドループ最適化

実応用では、Agentが直面するのは静的環境と固定ツールインターフェースではなく、Agent、Environment、Humanを含むシステムが継続的に進化するものだ。ユーザーはいつでも情報を追加し、要件を変更し、エラーを修正し、環境自体を直接変更する可能性がある。

このようなダイナミックなシナリオに直面して、Agentは単に指示を実行するだけでなく、積極的に情報を取得し、不確実な時にタイムリーに確認し、フィードバックを受け取った後に判断を更新することを学び、「質問—フィードバック—信念更新」の過程をトレーニングと評価に組み込む必要がある。これにより、human-in-the-loopとonline RLに近い最適化フレームワークを構築する。

より強力なインフラとよりオープンな環境

Agentic RLは実際には非常にエンジニアリング能力を必要とし、高並列性、低ブロッキング、スケーラブルな環境実行能力が必要；十分に安定した高度に非同期なトレーニングフレームワークで時間コストを削減する必要がある；さらに、モデルの継続的なスケーリングを支えるエンジニアリング基盤が必要だ。

同時に、現在多くのターミナル環境は依然として高度に手動設定に依存している——例えば、固定ミラーソース、権限境界制御、プリインストールソフトウェア、および単一マシンまたはDockerコンテナに制限された実行空間。

これらは見えない形でモデルの探索空間を制限する。Agentにより強い汎化能力を持たせたい場合、おそらくより高レベルで、よりオープンで、より進化可能な環境システムが必要になり、環境の動的変化に依存する報酬設計（静的報酬ルールではなく）と組み合わせる必要がある。

より細粒度のクレジットアサインメントと報酬モデリング

RLVRと比較して、agentic RLにはより多くの利用可能な中間信号がある。例えば、ツール実行の成否、サブタスク完了状況、環境状態一貫性チェックなど。しかし、複雑な報酬ルール設計（例えば、ツール失敗に固定的に-0.5ペナルティを課すなど）が持続可能な解決策であるとは考えていない。

その他の興味深い発見

並列関数呼び出し

以下の図は、qwen3-coder-plus、glm-4.6、claude-sonnet-4.5、ROMEが同じタスクバッチでの軌跡パフォーマンスを比較し、単一アシスタントステップ内での並列関数呼び出しの頻度と分布を示している。

観察したところ、claude-sonnet-4.5の並列度が著しく高いことがわかった。並列ツール呼び出しを行う頻度においても、単一ステップ内で同時に呼び出すツール数においても、明らかにリードしている。

さらに分析すると、claude-sonnet-4.5は具体的な操作を実行する前に現在本当に必要な情報を識別するのが得意であることがわかった。通常、すぐに実行段階に入るのではなく、まず環境の重要な不確実性を識別し、同じステップで複数の並列「チェック系呼び出し」を通じて情報を取得する。

例えば、「Install Anaconda for me」というタスクが与えられた場合、claude-sonnet-4.5は単一ステップで複数のチェックを行う：

• pwd、ls、cat、grepなどのコマンドを使用してディレクトリ構造と設定状態をチェック；

• python -Vとpip listを使用して既存のPython環境と依存状況を識別；

• read_fileとsearchを使用して実行可能なインストール方法と関連制約（ネットワーク接続性、ミラー可用性など）を検索。

経験的に、このような並列呼び出しは主にチェック系ツールに集中しており、環境を直接変更する実行や編集系操作ではない。

このパターンはAgent設計とトレーニングに価値ある示唆を与える：状態変更を行う前に、「事前の、並列な情報収集段階」を明示的に奨励することが有益である可能性がある。

一般的な失敗モード

いくつかの軌跡分析で、ターミナル系agenticタスクで最も一般的な2つの失敗モードを発見した：無効ループとタイムアウト（timeouts）。

エージェントは多くの場合、明確な失敗信号がすでにあるにもかかわらず、同じ戦略を繰り返し、考えを切り替えたり仮説を見直したりすることを理解せず、冗長で無効な対話チェーンを形成する。

もう一方で、タイムアウトも重要な失敗源である：モデルに帰結すると、しばしば長時間実行コマンドの実行時間に対する信頼できる感知が不足しており、デフォルトのタイムアウトメカニズムに誤導されやすく、誤判断や繰り返しの再試行を生む。

これら2つの支配的モード以外にも、幻覚、不適切なツール選択、タスク制約違反などの他の問題も観察した。

以下の図は、複数のモデルがTerminal Benchでのエラータイプ分布を示す：

まとめ

私たちが遭遇した核心的課題——長時系列クレジットアサインメント、部分観測可能性、ノイズ失敗、脆弱な環境——は、強化学習分野では新しい問題ではない。

真の難点は、安定した信頼できるシステム全体（トレーニングフレームワーク、サンドボックス環境、agentフレームワークなど）をいかに構築するかにある。

もちろんAgentic RLはまだ初期段階にあり、本文で言及した多くの技術は、最善の実践や最終的な解決策ではないかもしれず、主に実際の実験過程でまとめた経験的教訓である。

将来を展望すると、環境がよりオープンになり、タスクがより複雑になるにつれて、真の進歩は最適化目標、環境、トレーニングフレームワーク間のより緊密な協調設計と統合から来ると信じている。

このブログと以前の技術レポートが、実際の環境でagentic modelをトレーニングする研究者とエンジニアに役立つことを望む。おそらく、私たちがかつて踏んだ遠回りを少し減らすことができるかもしれない。

English Version：https://www.notion.so/The-Bitter-Lesson-Behind-Building-Agentic-RL-in-Terminal-Environments-2eaddd45837f80c9ad2ed6a15ef3c1a1?pvs=21
🚀ROLL TEAM：https://wwxfromtju.github.io/roll_team.html
📄 技術レポート：https://arxiv.org/pdf/2512.24873
🧠 モデル:https://huggingface.co/FutureLivingLab/iFlow-ROME
🧩 フレームワーク:
RLトレーニングフレームワーク: https://github.com/alibaba/ROLL
サンドボックス環境管理: https://github.com/alibaba/ROCK
Agentフレームワーク:https://github.com/iflow-ai/iflow-cli
📊 Benchmarks: https://github.com/alibaba/terminal-bench-pro

引用リンク

[1] ROLL Flash: https://arxiv.org/pdf/2510.11345

[2] ROLLART: https://www.arxiv.org/pdf/2512.22560

[3] Let It Flow: https://arxiv.org/pdf/2512.24873

[4] RL Tricks: https://arxiv.org/abs/2508.08221

[5] ROCK: https://github.com/alibaba/ROCK