SkyRL-Agent: Efficient RL Training for Multi-turn LLM Agent

Paper: arXiv:2511.16108 Code: NovaSky-AI/SkyRL Code reference: main @ 36f38c74 (2026-05-17)

1. 这篇论文解决什么问题？

一句话：SkyRL-Agent 把多轮工具型 LLM agent 的 RL 训练拆成“工具中心 agent loop + 分阶段异构调度 + 后端无关训练数据桥”，目标不是再提出一个单任务 scaffold，而是让 SWE、搜索、浏览器、桌面、记忆等长时程 agent 都能用同一套 rollout/训练骨架高效产生可用于 RL 的轨迹。 论文最核心的判断是：长时程 agent 的瓶颈不只在 RL 算法，也在 rollout 系统工程；如果把一个 trajectory 当作不可拆分的 data-parallel 作业，CPU 侧环境初始化、工具执行、reward/evaluation 和 GPU 侧生成会互相等待，训练成本会被大量空转吞掉。

作者把这个问题放在 RLVR / verifiable reward 的语境下：数学、代码、网页任务都能通过外部 verifier 给出可验证反馈，但多轮 agent 训练比单轮 RLVR 更难，因为一次样本不是一个 prompt-response，而是一串带工具调用、环境状态变化、异常恢复和最终 verifier 的交互。传统 Gym-style 环境倾向把 agent 状态和 environment step 分开，实际实现时常出现 ad hoc 的历史截断、上下文管理、工具错误处理；workflow-style 系统则把 SWE 任务拆成定位、修改、测试等固定阶段，容易训练和评估，但丢掉了真实开发中“反复查找、编辑、测试、回滚”的交互性。SkyRL-Agent 的定位是在两者之间：保留真实多轮工具使用，但把可复用的调度、工具注册、运行时隔离、后端转换抽象出来。

论文用 SA-SWE-32B 证明这个系统不是纯工程包装。SA-SWE-32B 从 Qwen3-32B 出发，只用 RL 在 4.5K R2E-Gym 实例上训练，SWE-Bench Verified 的 Simple ReAct Pass@1 从基座的 24.4 提升到 39.4。论文强调两个效率来源：其一是 async pipeline dispatcher，在 SA-SWE-32B 训练设置下相对朴素 async batching 达到 1.55× speedup，并让 2×8 H100 的 generation GPU 利用率更稳定；其二是 AST-based search tool 与搜索 hint，使 agent 在代码库中定位问题的成功率和 rollout Pass@K 更高，从而减少低质量样本和无效 rollouts。成本上，SA-SWE-32B 报告 4601 H100 hours，而 DeepSWE 表中为 9180 H100 hours，论文称达到类似性能区间时有超过 2× 的成本降低。

我的理解：这篇的“新”不在单个 RL objective，而在把 agent RL 的可扩展训练链路做成系统化接口。对研究者来说，它降低了从“我有一个工具型任务和 verifier”到“我能跑多后端 RL”的工程门槛；对训练效率来说，它把此前隐藏在环境和工具中的 CPU-bound 部分显式调度，使 expensive verifier/runtime 不再默认拖住 GPU generation。

2. 背景与定位：它和现有 agent training framework 有何差别？

论文的背景表把 SkyRL-Agent 与 VeRL-Tool、rLLM、GEM、Agent-Lightning 对齐比较，维度包括 backend、agent execution、interface、runtime scaling 与 trajectory 表示。主要差异如下：VeRL-Tool 绑定 VeRL，执行方式是 data-parallel，接口是 Tool，runtime scaling 是 Ray，trajectory 主要是 mask；rLLM 绑定 VeRL，接口偏 Gym，runtime scaling 是 K8s，可支持 mask / transition；GEM 与 Agent-Lightning 支持 Multi backend，但执行仍主要是 data-parallel。SkyRL-Agent 的表述是 Multi backend、Data + Pipeline 可扩展执行、Tool interface、Ray/K8s runtime scaling、Mask / Transition 兼容。

这个对比背后有三个设计诉求。

第一，工具接口要比 Gym interface 更开放。LLM agent 的工具不只是环境 step；它可能是 python interpreter、bash、file editor、浏览器、检索器，也可能是修改 agent 自身状态的总结/压缩工具。SkyRL-Agent 让 agent 只通过 OpenAI-style function calling 发起动作，每个工具注册 schema 和运行逻辑，Gym 环境也可以被包成一个 tool，但系统不强迫所有任务都伪装成 Gymnasium step。这一点对多任务训练重要，因为不同 dataset 可以绑定不同 tool set 和 verifier，而无需重写 agent loop。

第二，rollout 调度不能只看“有多少条 trajectory”。多轮任务的三类阶段成本差异很大：runtime initialization 可能要启动 Docker/VM/浏览器，agent run 是 GPU 生成与工具轮转，reward calculation 可能要跑测试、judge 或环境原生 evaluator。SkyRL-Agent 把每个 trajectory 分成 initialization、agent run、evaluation/reward 三个 stage job，dispatcher 给每个 stage 维护 bounded queue。Async Batch 适合 init/reward 很轻的推理题；Async Batch (Bounded) 适合需要限制并发或复用持久环境的任务；Async Pipeline 用三个队列重叠 CPU-bound 与 GPU-bound 阶段，适合 SWE 这种 runtime 和 verifier 都重的场景。

第三，训练数据要能被不同 RL backend 消化。论文采用 transition-based design：每次 LLM invocation 都记录 input tokens、output tokens，以及 inference endpoint 可提供的 log probabilities。这样做有三个好处：一是可以缓解 inference engine 与 training engine 的一致性问题，例如后续可接 Flash-RL 类校正；二是 token-level fidelity 更强，避免重新 tokenize 或文本后处理带来的 off-policy drift；三是比把整段 conversation 拼成一个 mask 序列更灵活，可以跨 turn 动态总结上下文、插入结构化 prompt 或改变角色。最后由 post_process 聚合 transition 和 reward，转成 SkyRL-train、VeRL、Tinker 等后端需要的数据格式。

3. 方法细节：SkyRL-Agent 的组件如何工作？

3.1 Tool-centric agent loop

SkyRL-Agent 中，agent 的行为是“模型生成函数调用 → tool runtime 执行 → observation 回到 history → 继续生成”。工具拥有自己的 schema、参数校验和 execution logic，agent 不需要知道底层是 SandboxFusion、Playwright、Docker 还是一个 OpenHands runtime。这个设计把三类状态放到同一个抽象下：环境状态，例如文件系统或浏览器页面；agent 历史状态，例如上下文压缩；无状态实用工具，例如 grep/search/python。相比把 agent state 放在 env.step 外面，它更容易把“清理历史”“修正 malformed tool call”“恢复 parse failure”等逻辑做成可复用模块。

论文提到错误处理分 terminal 与 recoverable 两类。terminal 条件包括 context window exceeded、达到 max iterations、资源耗尽等，episode 直接结束；recoverable 条件包括参数错误、tool call parse failure、轻量执行错误，框架会把 corrective feedback 注入 conversation history，让模型下一步自我修正。这一点对 RL 很关键，因为训练时不应把所有工具错误都变成不可解释的失败；可恢复错误如果被转成 observation，agent 才有机会学到“错误后如何继续”。

3.2 Fine-grained heterogeneous dispatcher

论文的 dispatcher 有三个层次：stage decomposition、bounded queues、policy selection。Stage decomposition 把 trajectory 拆为 runtime initialization、agent run、reward calculation；bounded queues 控制每个阶段的并发，避免 CPU 环境或 evaluator 过载；policy selection 则让任务根据瓶颈选择 Async Batch、Async Batch (Bounded) 或 Async Pipeline。SWE 训练中，因为环境初始化和最终测试/evaluation 都很重，Async Pipeline 可以在一批 trajectory 的 run 阶段占用 GPU 时，让另一批做 initialization 或 evaluation，从而减少 GPU 等待。

从代码看，async_pipeline_dispatcher 的实现非常直接：创建 init_queue、run_queue、eval_queue，先把所有 (instance_id, trajectory_id) 放进 init 队列；initialize_one 完成后把同一个 key 推入 run 队列；run_one 完成后推入 eval 队列；eval_one 执行 evaluator 并标记完成。并发上训练配置中的 max_parallel_agents 和 max_eval_parallel_agents 会与总 trajectory 数取 min，避免超过实际样本数。这个实现的价值不在复杂调度算法，而在把 pipeline 并发变成可配置 primitive。

# 基于 skyrl_agent/dispatcher/dispatchers.py:async_pipeline_dispatcher 的伪代码
init_queue, run_queue, eval_queue = Queue(), Queue(), Queue()
for traj_id in range(num_trajectories):
    for inst_id in trajectories:
        init_queue.put((inst_id, traj_id))
 
async def initialize_worker():
    while item := await init_queue.get():
        await trajectories[item].initialize_trajectory()
        await run_queue.put(item)
        init_queue.task_done()
 
async def run_worker():
    while item := await run_queue.get():
        await trajectories[item].generate_trajectory()
        await eval_queue.put(item)
        run_queue.task_done()
 
async def eval_worker():
    while item := await eval_queue.get():
        await trajectories[item].evaluate_trajectory()
        eval_queue.task_done()
 
# worker 数由 max_parallel_agents / max_eval_parallel_agents 控制；三个队列可重叠执行。

3.3 Backend bridge 与 transition construction

SkyRL-Agent 的后端桥接把“agent rollout 前端”与“RL trainer 后端”解耦。论文明确列出 SkyRL-train、VeRL、Tinker 三类后端：SkyRL-train 支持大规模 RL 训练；VeRL 可服务已有 PPO/GRPO 生态；Tinker 适合 LoRA 或 API/托管训练形态。代码里的 AsyncInferBackend 定义 async_generate_prompts 与 async_generate_ids；BackendSpec 和 register_backend 提供 registry；SkyRLBackend、VeRLBackend、TinkerBackend 分别适配不同 generator I/O。

AgentRunner.run 是前后端交界的主入口：它先把后端输入转成统一 input batch，按训练/验证模式选择 num_trajectories 与 sampling params，初始化每个 instance 的多个 trajectory，然后按配置找到 dispatcher 执行 initialize_trajectory、generate_trajectory、evaluate_trajectory，最后调用 _post_process_results 整理 rewards、messages、finish status、raw/trajectory reward 等，再交给 build_generator_output 转为对应 backend 的 result。

# 基于 skyrl_agent/agents/base.py:AgentRunner.run 的伪代码
input_batch = build_generator_input(infer_backend, raw_batch)
num_trajectories, sampling_params = select_train_or_val_config(cfg)
trajectories = initialize_trajectories(input_batch, num_trajectories)
dispatcher = DISPATCHER_REGISTRY[cfg.dispatcher.type]
await dispatcher(
    dispatcher_cfg,
    trajectories,
    init_fn="initialize_trajectory",
    run_fn="generate_trajectory",
    eval_fn="evaluate_trajectory",
)
processed = post_process_results(trajectories)
return build_generator_output(infer_backend, processed).result

4. SWE Agent：训练配方与关键数字

SWE 是论文最重要的 case study。任务流程是：给定真实 GitHub repo 与 issue description，agent 在可执行环境里查找、编辑、测试，最终提交 patch；评估由 unit tests 是否通过决定。论文强调它训练的是 full interactive loop，而不是把任务固定拆成定位、修改、测试等 workflow 子任务。SWE agent 使用的基本工具在评估中很克制：Simple ReAct 只暴露 bash 和 file editor，最大 context length 40K，最多 100 steps。

训练配置文件中则启用了 enable_bash_tool、enable_editor、enable_cmd、enable_finish 与 enable_search，关闭 browsing、LLM editor、jupyter、think、MCP；generator 使用 SkyRL-train backend，num_trajectories=8，max_iterations=50，max_prompt_length=32768，采样 temperature=1、top_p=1、top_k=-1、max_tokens=32768；

dispatcher 是 async_pipeline，max_parallel_agents=96，max_eval_parallel_agents=96，验证并发各为 32。

4.1 AST-based search tool 为什么重要？

论文观察到 SWE agent 的常见失败不是完全不会写代码，而是定位错误上下文失败：模型过度依赖直接 view 文件，不能有效使用 grep/find，查询关键词不精确，导致反复查看大段无关代码，浪费 context 并降低后续修改质量。作者基于 LocAgent 思路实现 AST-based search tool，支持 fuzzy matching 与 structural pattern search，并在每次搜索结果后附加上下文 hint，提示下一步应该搜哪些精确符号或 pattern。这个设计不是为了让训练时工具更多，而是为了让早期 rollout 有更高成功概率；RL 的 on-policy 数据如果大多是定位失败的长轨迹，优势估计和梯度都会变差。

从代码看，搜索工具的核心是 tasks/swebench/scripts/tools/search.py：build_graph 递归扫描 repo、解析文件、构建 networkx.MultiDiGraph；RepoEntitySearcher 按实体名、类型、路径组织检索；RepoDependencySearcher 负责邻居和依赖遍历；QueryResult.format_output 输出命中的实体、来源、代码片段或 skeleton；get_skeleton 会在内容过长时只保留 class/def 行作为结构预览。这和论文中“减少无关内容、促进 query refinement”的描述一致。

# 基于 tasks/swebench/scripts/tools/search.py 的伪代码
G = build_graph(repo_path)
entity_searcher = RepoEntitySearcher(G)
query = parse_user_query(name_or_pattern, type_filter, path_filter)
hits = entity_searcher.search(query)
for hit in hits:
    if hit.content_too_long:
        show(get_skeleton(hit.code_content))
    else:
        show(hit.code_content)
    show(contextual_hint_for_next_search(hit))

4.2 RL 算法与超参

SWE 训练采用 fully on-policy 设置：training batch size 与 mini-batch size 都是 64，每个 task 8 rollouts。因外部约束终止的轨迹会在梯度更新中 mask 掉，例如达到最大 context length 32K tokens 或 50 turns；论文强调这个 mask 不修改 reward 或 advantage estimation，只把这些样本从梯度计算中排除，避免模型因为多做动作或多推理而被错误惩罚。优势估计使用 leave-one-out advantage estimation，移除 standard deviation 和 length normalization；KL 与 entropy loss 都关闭；学习率是 1e-6。此外，Qwen3 chat template 被修改为保留前一轮 “thinking”，让跨 turn 推理连续。

这个配方有一个容易忽略的细节：论文报告训练和最终评估的步数/上下文约束并不完全相同。训练配置强调 32K prompt length、50 iteration；SWE-Bench Verified 评估脚注则是 40K context、100 max steps、bash + file editor。笔记中不能把这两者混为一个超参来源；训练配置应来自 skyrl_swe.yaml，最终 leaderboard 表则来自论文评估段落。

4.3 SWE-Bench Verified 结果

Model	Size	Recipe	Simple ReAct Pass@1	Reported Pass@1	Cost (H100 Hours)
Qwen3-32B	32B	—	24.4	—	—
Qwen3-Coder-30B	30B	—	45.0	—	—
SWE-agent-LM-32B	32B	3.7 Sonnet Distill	38	40.2	—
SWE-Swiss	32B	R1 Distill + RL	×	45.0	—
Kimi-dev	72B	R1 Distill + RL	×	48.6	—
DeepSWE	32B	RL	36.4	42.2	9180
SA-SWE-32B	32B	RL	39.4	—	4601

表格的解释要谨慎。Qwen3-Coder-30B 的 Simple ReAct 45.0 高于 SA-SWE-32B，但它是更偏代码的基座；DeepSWE 的 reported 42.2 与 Simple ReAct 36.4 都列出，论文提醒不同 scaffold 和 evaluation setup 不严格可比。SA-SWE-32B 的重点是：在 Qwen3-32B 基座上，只靠 RL 从 24.4 提升到 39.4，并且相对 DeepSWE 的 H100 hours 显著更低。也就是说，这张表的主要论点不是“绝对第一”，而是“纯 RL + 真实交互 + 系统优化可以在相近模型规模下拿到高性价比”。

4.4 OOD generalization

论文还把 SA-SWE-32B 放到 Terminal-Bench、BrowseComp-Plus、WebArena 上做 out-of-domain 评估，目的是验证 SWE 中学到的工具使用能力是否迁移到命令行、网页导航和检索推理。

Model	Terminal Bench	BrowseComp-Plus Acc.	BrowseComp-Plus Avg. Turn	WebArena
Qwen3-32B	13.75	18.1	3.68	15.8
SA-SWE-32B	16.25	19.4	4.6	17.0

这里的增益不大，但方向一致。论文还观察到 SWE 训练过程中平均 search calls 从 3 增加到 4，平均 turns 从 18 增加到 25；BrowseComp-Plus 上也出现更多搜索调用，说明模型不是只学到 SWE-specific patching，而是更愿意展开多轮外部检索和迭代推理。我的解读是：SWE RL 训练提供了一种“工具耐心”和“状态化探索”的行为先验，但这种迁移仍受任务环境、retriever、网页交互接口和 reward 质量限制，不能自动保证大幅 OOD 提升。

5. 其他 agent case study：框架可扩展性而非单点 SOTA

5.1 Deep Research agent

Deep Research case 使用 SkyRL-train backend。数据构造上，作者从相关来源采样 50K problems，用 Qwen3-8B thinking mode 对每个样本生成 4 个 rollouts 做离线难度估计，并按成功次数分成 Impossible(0/4)、Hard(1/4)、Medium(2/4)、Easy(3/4)、Perfect(4/4)。最终训练集采用类似 Polaris 的镜像难度分布：25% Impossible、30% Hard、30% Medium、15% Easy，并在 CS、biology、physics、economics 等 STEM 学科间平衡。训练 Qwen3-8B，算法是 GRPO，使用 general verifier，global batch size 64、8 rollouts、mini-batch size 64、learning rate 5×10^-6，summarizer 是 Qwen3-235B non-reasoning mode。

HLE-500 评估用 LLM-as-a-Judge。作者指出 general verifier 偏宽松，所以另外用 gpt-oss-20b 作 primary judge：general verifier 下从 12.6% 提升到 18.8%；gpt-oss-20b 下从 9.2% 提升到 10.2% / 11.0%。更有价值的是挑战分析：web scraping 每次请求约 10k tokens，配合大 summarizer 会拖慢训练；Qwen-3-32B 单 H200 serving 时每 iter 2101.6 s，换 Qwen API 后 592.1 s，约 3.5× faster；最终阶段使用 4 块 GH200 与 data-parallel router。工具 serving 不足会造成 timeout 污染 rollout，例如 iteration 30 附近 reward dip，需要 30–33 多步恢复。因此，重工具 agent 的 RL 成败高度依赖工具侧 capacity planning，而不只是 trainer 超参。

另一个关键风险是 online search 泄漏 benchmark answer。作者在 GPQA-Diamond evaluation 中看到模型可能直接从 Hugging Face 等公开页面检索答案，而不是推理。为减少这种 shortcut retrieval，评估中需要屏蔽 Hugging Face、GitHub、GitLab、Chegg 等域名。这条经验对任何 web/research agent RL 都重要：如果 verifier 只看最终答案，而工具允许搜索公开答案，训练可能学到的是 benchmark leakage policy。

5.2 Memory agent

Memory case 用 Tinker backend 复现 MemAgent 风格的递归长文本处理。任务是 RULER-HotpotQA：输入包含 golden supporting paragraph 和若干 distractor paragraphs，模型每次处理不超过 4k token 的文本 chunk，并通过 Next tool 把当前 chunk 摘要追加到下一 chunk 输入中，形成 fixed-size memory buffer。训练时序列最长 28k tokens，评估最长 112k tokens；verifier 是 GPT-5-nano；模型是 Qwen3-8B non-thinking mode，LoRA rank 128，batch size 32，8 rollouts，每 turn 最大 8K tokens。论文把 MemAgent 原报告作为参考：Qwen2.5-7B-Instruct 在同数据集、batch size 128、group size 16、exact-match verifier 下为 79.69% accuracy。

这个 case 的意义是展示 transition-based data construction 的灵活性：agent 的上下文不是简单拼接，而是通过工具改变未来 turn 的输入；如果训练数据只支持单一 mask-based concatenation，很难优雅表达“上一 chunk 的摘要成为下一 chunk memory”这种结构。它也说明 backend bridge 的价值：同一 agent loop 可以从 SkyRL-train 切到 Tinker，而不必重写任务逻辑。

5.3 Computer Use agent

Computer Use case 用 VeRL backend 和 OSWorld。由于数据缺乏，作者借鉴 ARPO，从 OSWorld 筛出 32 个 Hard/Medium/Easy 任务做训练子集；模型是 Qwen3-8B，算法是 GRPO。rollout 用 Async Batch (Bounded)，固定 32 个 virtual desktop environments；OSWorld VM 作为 Ray remote tasks 启动，把 CPU-bound feedback loop 与 GPU-bound generation 解耦；training batch size 8，每个 task 8 rollouts；评估直接用环境原生 evaluation function。

结果观察比较现实：训练 reward 稳定改善，但 validation accuracy 几乎没有提升。作者认为 OSWorld 对 Qwen3-8B 本身太难，学到的 policy 难以泛化到训练环境之外。这是论文中很重要的负结果：SkyRL-Agent 能让这类训练跑起来、能扩展环境并保持后端连接，但 framework 不保证模型容量、数据量和 reward signal 足以带来泛化。

6. 与代码实现的对应关系

Code reference: main @ 36f38c74 (2026-05-17)

Paper Concept	Source File	Key Class/Function
统一 trajectory / runner 抽象	skyrl-agent/skyrl_agent/agents/base.py	BaseTrajectory, AgentRunner.run, _post_process_results
三阶段异步 pipeline 调度	skyrl-agent/skyrl_agent/dispatcher/dispatchers.py	async_pipeline_dispatcher, async_batch_dispatcher, async_fix_pool_dispatcher
后端无关 inference bridge	skyrl-agent/skyrl_agent/integrations/base.py	AsyncInferBackend, BackendSpec, build_backend, register_backend
SkyRL-train 后端	skyrl-agent/skyrl_agent/integrations/skyrl_train/skyrl_train_backend.py, skyrl_train_main.py	SkyRLBackend, SkyRLAgentGenerator, SkyRLAgentPPOExp
VeRL / Tinker 后端	skyrl-agent/skyrl_agent/integrations/verl/verl_backend.py, tinker/tinker_backend.py	VeRLBackend, TinkerBackend
SWE CodeAct trajectory	skyrl-agent/skyrl_agent/agents/oh_codeact/codeact_runner.py	CodeActTrajectory.initialize_trajectory, generate_trajectory, evaluate_trajectory
SWE runtime 与 verifier	skyrl-agent/skyrl_agent/tasks/swebench/utils.py	initialize_runtime, SWEBenchTask, evaluate_result, process_git_patch
AST search tool	skyrl-agent/skyrl_agent/tasks/swebench/scripts/tools/search.py	build_graph, RepoEntitySearcher, RepoDependencySearcher, QueryResult.format_output, get_skeleton
SWE training config	skyrl-agent/examples/run_skyrl/skyrl_swe.yaml	agent_cls, tools, generator, dispatcher
数据准备	skyrl-agent/data/swe_data.py, browsecomp-plus.py, memagent.py, deep_research.py	task-specific data scripts

代码与论文大体一致，但也有两个复现时要注意的点。第一，论文中讲的是系统和最终训练结果，repo 当前 HEAD 是 2026-05-17 的工程状态，可能已经包含论文之后的改动；所以笔记将代码引用固定为 main@36f38c74。第二，训练数字必须区分论文实验与当前 example config：skyrl_swe.yaml 给出当前 SWE example 的工具开关、8 rollouts、50 max iterations、32K prompt/token 上限和 async pipeline；论文表格中的 40K context / 100 max steps 是 SWE-Bench Verified evaluation 设置，不应直接写成训练配置。

7. 复现与实现要点

如果要复现论文主线，我会按四层检查，而不是直接调 GRPO 超参。

1. 任务与工具层：先确认 SWE task 的 runtime 初始化、repo copy、bash/editor/search tool 是否稳定；尤其 AST search index 构建和 query hint 是否真实进入 agent history。若 search tool 输出过长或 hint 不明确，模型会退化为 file-by-file view，rollout 成本升高。
2. 调度层：先用同样 batch size 64、8 rollouts 的小规模作业对比 Async Batch (Bounded) 与 Async Pipeline 的 stage 时间和 GPU utilization。目标不是追求更复杂 scheduler，而是确认 init/run/eval 三阶段确实在重叠。
3. 训练数据层：检查 _post_process_results 产出的 messages、reward、finish reason、masked samples、empty messages。多轮 agent 最常见的问题是 reward 看似正常，但训练样本中很多轨迹因为 timeout/context/parse failure 不该进梯度。
4. 评估层：SWE-Bench Verified 要固定 scaffold、context、工具和 max steps，否则与表格不可比；OOD 任务要记录工具调用次数和 turn 数，因为这能解释模型是更会搜索，还是只是在原 task 上过拟合。

8. 局限、风险与我的评价

第一，SkyRL-Agent 解决的是“让训练跑得起来、跑得更高效”的框架问题，不自动解决 reward design 和 task generalization。Computer Use case 中 reward 上升但 validation accuracy 不升，就是一个明确提醒：复杂交互任务可能需要更强模型、更大数据、更好的任务分布或更细 verifier，framework 本身不能弥补模型能力边界。

第二，工具容量是训练质量的一部分。Deep Research 的 2101.6 s/iter vs 592.1 s/iter 对比说明，重工具 agent 的瓶颈可能在 summarizer、web scraping、VM 或 evaluator，而不是 GPU trainer。如果工具 timeout 大量出现，RL 会在噪声 reward 上学习，甚至需要 mask abnormal trajectories 来保护 reward signal。

第三，search/web agent 的评估有泄漏风险。论文主动屏蔽 Hugging Face、GitHub、GitLab、Chegg 等域名，说明 online search benchmark 如果不做 domain hygiene，很容易训练出“查答案”而非“推理”的策略。这对 BrowseComp、GPQA 类任务尤其关键。

第四，表格比较要谨慎。SWE-Bench Verified 不同方法使用的 scaffold、工具、context、是否 distill、是否 workflow-based 都不同。SA-SWE-32B 的强点是 Qwen3-32B + pure RL + simple interactive setting 下的性价比；它不是在所有设置下压过专门的 coder 基座或更复杂 agent scaffold。

第五，论文提到 transition-based construction 将来可通过装饰 LLM call 函数来训练 arbitrary agent programs，但这不是当前主线能力。换言之，SkyRL-Agent 已经把标准 tool-use agent 的 loop、dispatcher、backend 做得清楚，但“任意已有 agent 程序无侵入接入训练”仍需要额外工程化。

9. 读后总结

SkyRL-Agent 的贡献可以概括为：把 agent RL 中最容易被论文忽略的 rollout 系统工程显式化，并证明这会改变训练成本和样本效率。 它的 agent loop 统一 tool、runtime 和状态修改；dispatcher 把 trajectory 拆成可重叠的异构 stage；backend bridge 让同一 agent 前端接 SkyRL-train、VeRL、Tinker；SWE case 进一步证明好的工具设计（AST search + hints）能显著改善 RL rollout 质量。对后续工作最有启发的是：做多轮 agent RL 时，不应该只问 reward model 或 RL algorithm，而要同时问：工具是否让早期策略能探索到成功轨迹？调度是否让 CPU/GPU 阶段互不阻塞？transition 是否保留了足够 token-level 信息？评估是否避免工具泄漏？这些系统问题决定了 RL 信号是否干净、昂贵 rollouts 是否值得。