Agent-R1: Training Powerful LLM Agents with End-to-End Reinforcement Learning

Paper: arXiv:2511.14460 Code: 0russwest0/Agent-R1 Code reference: legacy @ ed9f0cc6 (2026-03-04)

1. Motivation (研究动机)

这篇论文要解决的不是“再提出一个 PPO/GRPO 变体”，而是一个更基础的问题：LLM 已经被包装成会调用工具、会多轮检索、会根据环境反馈继续行动的 Agent，但主流 RL 训练框架仍然很大程度上把模型当成静态文本生成器来处理。静态 LLM 的训练样本通常是 prompt 到 response 的一次性映射，状态就是 prompt 加已生成 token；而 Agent 的真实执行过程包含搜索、代码执行、API 调用、环境返回、失败重试、上下文更新等外部交互。如果训练时仍把整段交互强行压成“一个长 response”，就会混淆模型自己做出的动作与环境返回的观察，也很难把奖励准确归因到真正可学习的决策位置。

作者认为当前 LLM Agent + RL 的瓶颈主要有三类。第一，概念层面缺少一个足够清楚的 MDP 建模：很多工作知道 Agent 有 state、action、reward，但没有明确区分“模型 token 生成”“工具调用动作”“环境状态转移”和“工具返回观察”分别对应 MDP 中的哪一部分。第二，工程层面缺少面向多轮交互的训练框架：如果每个任务都要重新写 tool parser、environment step、trajectory packing、reward manager、PPO/GRPO 数据管线，研究者很难快速比较不同环境和 RL 算法。第三，优化层面缺少针对 Agent 轨迹的 mask 与 advantage 对齐：工具返回文本不是模型动作，prompt 与 observation 也不是 actor 应该被惩罚或鼓励的 token；如果 loss 和 advantage 直接覆盖整段序列，就会把 credit 分配到环境反馈或固定上下文上。

Figure 1 解读：这张图把普通 workflow、agentic workflow 和 autonomous agent 区分开。workflow 依赖人工预先设计的路由或计划；ReAct 一类 agentic workflow 虽然引入“思考—行动—观察”的循环，但仍然包含显式设计的流程骨架；Agent-R1 关注的是更强的 autonomous agent，即模型在端到端 action-feedback cycle 中主动选择动作，并把环境反馈纳入下一状态。论文的动机正来自这个差异：如果 agent 已经从静态 workflow 走向可交互系统，训练框架也必须从单轮文本 RL 走向多轮环境 RL。

这件事值得研究，是因为工具型 Agent 的能力提升不能只靠 prompt engineering 或静态 SFT。多跳问答、网页导航、代码调试、数据库查询等任务的成功往往取决于一串中间决策：先查什么、如何改写 query、什么时候停止、如何整合证据、工具失败后是否重试。最终答案的 EM/F1 只是轨迹末端的结果，真正需要学习的是“哪些中间行动序列会导向成功”。Agent-R1 的价值在于把这个问题重新表述为可训练、可扩展、可复现的 RL pipeline：用 MDP 解释 Agent 的多轮行为，用 Tool/ToolEnv 抽象环境交互，用 action mask 和 advantage mask 把优化信号对齐到模型动作。

与更传统的 RAG 或 tool-call baseline 相比，Agent-R1 的目标不是在推理时给模型一个搜索工具就结束，而是让模型通过 end-to-end reinforcement learning 学会如何使用这个工具。论文的实验选择 MultihopQA 也很贴合这个动机：HotpotQA、2WikiMultihopQA 和 Musique 都要求模型进行多步证据收集与推理；单次检索或一次函数调用很容易漏掉桥接实体、时间关系或组合事实。若 RL 能让模型在多轮交互中稳定提升 EM，说明框架确实在优化 agent policy，而不仅仅是增加了一个外部检索模块。

2. Idea (核心思想)

核心思想可以概括为：把 LLM Agent 的多轮工具交互显式建模为 MDP episode，并在训练时只把模型真正生成的动作 token 当作可优化对象。Agent-R1 并不声称发明了新的 RL 算法；它的贡献是把 PPO、GRPO、REINFORCE++、RLOO 等算法放进一个面向 Agent 的统一框架，使这些算法能够消费“模型动作 + 环境反馈 + 多轮状态更新 + 过程/终局奖励”的轨迹。

与普通单轮 RLHF/RLAIF 的根本差异在于状态和动作粒度。静态 LLM 的 state 可以写成 prompt 加当前已生成 token： $s_t=({\mathbf{w}}_p,w_1,w_2,\dots ,w_t).$ Agent 的 state 则必须包含完整多轮交互历史和当前 partial turn： $s_t=({\mathbf{w}}_p,{\mathcal{T}}_1,{\mathcal{T}}_2,\dots ,{\mathcal{T}}_k,{\mathcal{T}}_{k+1}^{\text{partial}}).$ 这里的 ${\mathcal{T}}_i$ 不是普通 token 片段，而是一次 agent action 与 environment feedback 的组合。动作仍然由 token 生成实现，但某些 token 序列会被解释为工具调用；一旦触发工具，下一状态就不再由简单拼接 token 决定，而取决于外部环境的随机或非确定性返回。

论文把 transition 区分为两类：如果 action 只是普通文本生成，则近似沿用 LLM 的生成转移；如果 action 触发工具或环境交互，则由环境动态 $P_E$ 决定： $P(s_{t+1}\mid s_t,a_t)=\{\begin{array}{ll}{P}_E(s_{t+1}\mid s_t,a_t),& \text{if }{a}_t\text{ triggers tool/environment interaction}\\ P_G(s_{t+1}\mid s_t,a_t),& \text{otherwise}\end{array}.$ 奖励也不再只是一条最终 scalar。论文的通用 Agent reward 写成： $R(s_t,a_t,s_{t+1})=\{\begin{array}{ll}{r}_f(s_{t+1}),& \text{if }{s}_{t+1}\text{ is terminal}\\ r_p(s_t,a_t,s_{t+1}),& \text{if }{a}_t\text{ triggers a significant intermediate event}\\ 0,& \text{otherwise}\end{array}.$ 这个表达的重点是：过程奖励 $r_p$ 可以来自成功工具调用、有效中间进展或环境定义的局部反馈；终局奖励 $r_f$ 则评价整条 trajectory 是否完成任务。即使本文 MultihopQA 实验主要使用格式与答案正确性的最终奖励，这个框架仍为更密集的过程奖励预留了接口。

Agent-R1 与 ReAct、固定 workflow 或普通 RAG 的差别也在这里。ReAct 主要是一种推理时 prompting/trajectory pattern，它规定模型按 Thought/Action/Observation 循环执行；Agent-R1 关心的是如何把这种循环产生的数据接入 RL，让模型参数因为成功/失败轨迹而更新。Naive RAG 和 Base Tool Call 可以提供外部信息，但它们没有端到端优化“多轮何时查、查什么、如何整合”的策略。Agent-R1 的创新点是把这些中间动作放回 RL 的状态转移与 credit assignment 中，使工具使用不只是 inference-time scaffold，而是可学习 policy 的一部分。

3. Method (方法)

3.1 整体框架：从单轮 rollout 到多轮 Agent trajectory

Figure 2 解读：这张图展示 Agent-R1 的训练轨迹。Actor model 在 rollout 中产生思考与工具调用，ToolEnv 执行工具并返回环境反馈，反馈被追加到下一状态，直到达到终止条件。整条 trajectory 包含模型生成的 reasoning/action、工具返回 observation、过程奖励和最终奖励，随后被送入 RL 更新。图中最关键的是“状态由环境反馈更新”而不是“把所有文本无差别拼到 response 里”。

Agent-R1 的 pipeline 可以拆成三个层次。第一层是 Tool 抽象：每个工具都以 OpenAI Function Calling 风格暴露 name、description 和 JSON schema parameters，并实现 execute(args) 或 batch_execute(args_list)。第二层是 ToolEnv 抽象：它接收模型 raw response，解析工具调用，执行工具，把 tool result 格式化成模型下一轮可读的 observation，并决定当前 trajectory 是否继续。第三层是 RL trainer：它收集多轮 trajectory，计算 reward、value、advantage 和 policy loss，并通过 PPO/GRPO 等算法更新 actor。

代码中的 agent_r1/tool/base.py 对应论文的 Tool 和 ToolEnv 设计。BaseTool 要求子类提供 name、description、parameters，并实现 execute；BaseToolEnv 则定义 step(raw_response)、batch_step(raw_responses)、process_responses_ids、stop、extract_tool_calls、format_tool_response、system_prompt。这说明 released code 的抽象与论文一致：工具只负责“执行原子动作并返回结果”，环境负责“解释模型输出、驱动状态转移、产生 observation 和 active/stop 信号”。

3.2 Tool 与 ToolEnv：把外部交互封装成环境 step

论文实验使用 NousToolEnv 与模型 native function calling。代码中 agent_r1/tool/envs/nous.py 的 NousToolEnv.step 会先从 raw response 中抽取 tool call；如果 JSON 解析失败、缺少工具名、工具不存在或参数校验失败，就返回对应错误并标记工具执行失败；如果工具存在且参数合法，就调用 tool.execute(tool_call["arguments"])，取出 content 和 success。format_tool_response 再把多个工具返回拼成类似：

<tool_response>
...
</tool_response>

并补上 assistant 的下一轮起始标记。这样，工具返回不会被当成模型刚刚生成的内容，而是被作为环境 observation 加回上下文。

对应的批处理路径 batch_step 更贴近训练吞吐。它先为 batch 中每条 raw response 解析工具调用；对成功且可批处理的调用按 tool name 聚合参数，统一调用 tool.batch_execute；再按原始样本位置把结果写回。这个设计解决了 Agent RL 中一个实际工程问题：如果每个样本每轮单独查 Wikipedia 或调用 API，rollout 会被工具延迟拖慢；按工具类型聚合可以把环境交互从“逐样本串行”变成“按工具批处理”。

3.3 多轮生成：action mask 是 Agent-R1 的核心工程细节

Figure 3 解读：图 3 对比单轮 RL 与 Agent-R1 的 generation stage。单轮 RL 中 actor 生成一次 response 后即可计算 reward；多轮 Agent rollout 中，actor 每轮生成 action，ToolEnv 可能执行工具并返回 observation，然后 observation 被加入下一轮状态。图中 action mask 的作用是标记哪些 token 是 actor 的动作，哪些 token 是环境反馈或固定上下文。没有这个 mask，后续 loss 和 advantage 会把工具返回文本也当作模型应负责的输出。

released code 中 agent_r1/llm_agent/generation.py::ToolGenerationManager.run_llm_loop 实现了这条逻辑。它维护 active_mask 和 turns，每轮只对 active 样本调用 actor_rollout_wg.generate_sequences；生成后通过 env.process_responses_ids 截取有效 response，再用 tokenizer decode 成 raw response。若环境是 BaseToolEnv，则调用 env.batch_step(raw_responses) 或逐条 env.step(raw_response)，得到 tool_responses 与新的 active 状态。随后 _update_rolling_state 把模型 response token 与 tool response token 追加到每条样本的 raw_prompt_ids，形成下一轮输入。

最关键的是 _create_response_action_mask：代码明确返回“模型 token 为 1，工具 token 为 0”的 mask。

def build_response_action_mask(model_token_ids, tool_token_ids):
    action_masks = []
    for model_ids, obs_ids in zip(model_token_ids, tool_token_ids):
        # 与 released code 一致：actor 生成的 response 参与优化，ToolEnv observation 不参与 actor loss
        action_mask = [1] * len(model_ids) + [0] * len(obs_ids)
        action_masks.append(action_mask)
    return action_masks

这个 mask 解决了 Agent 训练中非常容易被忽视的责任边界：工具返回的 Wikipedia 片段、错误消息、环境终止提示都不应该被 actor 学成“自己要生成的 token”。它们只是下一状态的一部分。模型应该为“发起哪次工具调用、如何书写参数、何时给出最终答案”负责，而不应该为 search server 返回的 passage 文本负责。

3.4 学习阶段：advantage 与 policy loss 只对齐到模型动作

Figure 4 解读：图 4 对比单轮与多轮 learning stage。Agent-R1 在学习阶段不只是把整段 response 送进 actor loss，而是把 trajectory、values、outcome reward、process rewards 与 action mask 组合起来，计算对模型动作位置有效的 advantages。Actor model 的 new action logits 与 old log-prob 做 PPO/GRPO 等更新，critic 则用对应 returns 学习价值估计。

agent_r1/src/agent_ray_trainer.py::compute_advantage 是论文“advantage mask”思想在代码里的入口。对 GAE，它调用 core_algos.compute_gae_advantage_return(token_level_rewards, values, action_mask, gamma, lam)；对 GRPO、REINFORCE++Baseline、RLOO 等，它调用对应 outcome advantage 函数，并同样传入 action_mask。在 agent_r1/src/core_algos.py 中，GAE 实现先通过 extract_and_pad_by_mask(token_level_rewards, action_mask) 与 extract_and_pad_by_mask(values, action_mask) 只抽取 action token 位置，再反向递推 advantage。这与论文描述一致：价值和奖励可以来自整条 trajectory，但最终用于 policy update 的 credit 必须落到 agent 真正生成动作的位置。

policy loss 同样受 mask 控制。core_algos.compute_policy_loss 接收 advantages 与 action_mask，PPO ratio、clipping 和聚合只在有效 action token 上计算。agent_r1/src/agent_dp_actor.py 中 actor update 会读取 batch 内的 action_mask，而不是普通 response mask。这里的“loss mask”和“advantage mask”是两个互补设计：loss mask 决定哪些 token 进入 actor objective；advantage mask 决定 reward/value credit 如何对齐到动作序列。论文 Table 4 的 ablation 证明二者不是可有可无的实现细节，而是 Agent RL 成败的关键。

def agent_r1_advantage_and_loss(batch, actor, critic, old_logprob):
    # batch 中 response 同时包含模型动作 token 与 ToolEnv observation token
    action_mask = batch["action_mask"]          # 1 = actor action, 0 = environment/prompt/tool text
    token_rewards = batch["token_level_rewards"]
    values = critic(batch)
 
    # GAE/GRPO/REINFORCE++ 等都只在 action_mask 对齐的位置估计 advantage
    action_rewards = extract_and_pad_by_mask(token_rewards, action_mask)
    action_values = extract_and_pad_by_mask(values, action_mask)
    advantages, returns = compute_gae(action_rewards, action_values, gamma=1.0, lam=1.0)
 
    new_logprob = actor.log_prob(batch)
    ratio = torch.exp(new_logprob - old_logprob)
    unclipped = -advantages * ratio
    clipped = -advantages * torch.clamp(ratio, 1 - clip_eps, 1 + clip_eps)
    loss = masked_mean(torch.maximum(unclipped, clipped), action_mask)
    return loss, returns

3.5 Reward：实验中用格式约束和答案 EM 构造稀疏终局奖励

论文的通用框架允许 process reward，但 MultihopQA 实验主要使用最终答案奖励。它定义： $r_f=\{\begin{array}{ll}{r}_{\text{answer}},& \text{if }{r}_{\text{format}}=1\\ r_{\text{format}}-1,& \text{if }{r}_{\text{format}}<1\end{array}.$ 其中 $r_{\text{answer}}=\mathrm{EM}(a_{\text{pred}},a_{\text{gold}})$，$r_{\text{format}}=(r_{\text{format}a}+r_{\text{format}t})/2$，两个 binary indicator 分别检查最终答案格式和工具调用语法。这个设计把“答对”置于“格式完全正确”的前提下：如果格式不合格，即使内容有部分正确也会受到惩罚。对工具型 Agent 来说，这很合理，因为工具调用语法错会导致环境无法执行，最终答案格式错会导致评测器无法可靠抽取答案。

代码中 reward 管线由 agent_r1/src/agent_reward_manager.py、agent_r1/src/reward.py 和 agent_r1/src/reward_score/__init__.py 连接。训练脚本通过 data.reward_fn_key=data_source 与数据集字段选择 reward function；MultihopQA 的 reward score 会结合答案 EM 和格式检查。这部分与论文公式的关系是：论文给出任务级 reward 定义，代码把它实现为 batch-level reward tensor，并把 extra info 交给 trainer 记录。

3.6 训练配置与 paper-code 差异

Code reference: legacy @ ed9f0cc6 (2026-03-04) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Tool 抽象与 JSON schema 校验	agent_r1/tool/base.py	BaseTool.execute, BaseTool.batch_execute, BaseTool.validate_args
环境 step / batch step 抽象	agent_r1/tool/base.py	BaseToolEnv.step, batch_step, process_responses_ids, extract_tool_calls, format_tool_response, stop
Nous function-calling 环境	agent_r1/tool/envs/nous.py	NousToolEnv.step, NousToolEnv.batch_step, NousToolEnv.format_tool_response
多轮 rollout 与状态更新	agent_r1/llm_agent/generation.py	ToolGenerationManager.run_llm_loop, _update_rolling_state
action mask 构造	agent_r1/llm_agent/generation.py	_create_response_action_mask
advantage 对齐	agent_r1/src/agent_ray_trainer.py, agent_r1/src/core_algos.py	compute_advantage, compute_gae_advantage_return, compute_grpo_outcome_advantage
actor policy loss	agent_r1/src/agent_dp_actor.py, agent_r1/src/core_algos.py	actor update, compute_policy_loss
MultihopQA 训练入口	examples/trainer/run_ppo_multihopqa.sh, examples/trainer/run_grpo_multihopqa.sh	python3 -m agent_r1.src.main_agent ...
wiki search 工具注册	agent_r1/tool/tools/__init__.py, agent_r1/tool/tools/wiki_search_tool.py	wiki_search tool
reward 管线	agent_r1/src/agent_reward_manager.py, agent_r1/src/reward.py, agent_r1/src/reward_score/__init__.py	reward manager, dataset-specific score

released code 的 MultihopQA 脚本给出了一些论文正文未完全展开的可复现配置：data.train_files=['data/hotpotqa/train.parquet','data/2wiki/train_processed.parquet']，data.val_files=['data/hotpotqa/validation.parquet','data/2wiki/validation_processed.parquet','data/musique/validation_answerable_processed.parquet']，data.train_batch_size=128，data.max_prompt_length=8192，data.max_response_length=8192，data.max_response_length_single_turn=1024，actor_rollout_ref.actor.optim.lr=1e-6，actor_rollout_ref.actor.ppo_mini_batch_size=64，actor_rollout_ref.actor.ppo_micro_batch_size_per_gpu=2，actor_rollout_ref.rollout.tensor_model_parallel_size=2，actor_rollout_ref.rollout.gpu_memory_utilization=0.6，actor_rollout_ref.rollout.n_repeat=5，trainer.n_gpus_per_node=4，trainer.nnodes=1，trainer.total_epochs=1，tool.max_turns=5，tool.tools=['wiki_search']，tool.max_tool_response_length=2048。

GRPO 脚本额外设置 algorithm.adv_estimator=grpo、actor_rollout_ref.actor.use_kl_loss=True、actor_rollout_ref.actor.kl_loss_coef=0.001、actor_rollout_ref.actor.kl_loss_type=low_var_kl。

论文公式与 released code 实现差异：论文实验设置写的是 Qwen2.5-3B-Instruct，而 legacy@ed9f0cc6 的 MultihopQA 训练脚本默认 BASE_MODEL='Qwen/Qwen2.5-1.5B-Instruct'。因此本文笔记把论文报告的结果按论文正文记为 3B 设置，但把代码级 pseudocode、训练脚本配置和 mapping 锚定到 legacy@ed9f0cc6。此外，GitHub main@898c36d6 已经是更新的 v0.1.0 step-level MDP/layered abstraction 架构；为了贴近 arXiv 论文中的 NousToolEnv、BaseToolEnv、action mask 代码，本笔记采用 legacy 分支作为 code reference。

4. Experimental Setup (实验设置)

实验任务是 MultihopQA。训练集共 51,200 条样本，来自 HotpotQA 和 2WikiMultihopQA 的训练 split，论文写明是 equal and random draw。评测使用 HotpotQA 与 2WikiMultihopQA 的完整 development set 作为 in-domain 测试，并使用 Musique 作为 out-of-domain 测试。这个设置的意义是：HotpotQA 和 2Wiki 与训练分布更接近，Musique 则检验模型是否学到通用的多步检索与推理策略，而不是只适配某个数据集模板。

模型与工具方面，论文正文称使用 Qwen2.5-3B-Instruct，并在 NousToolEnv 中使用模型原生 function calling。Agent 只有一个 wikisearch 工具，该工具查询 KILT Wikipedia corpus，规模为 36M passages，embedding model 为 bge-large-en-v1.5，每次返回 top 5 documents。这个选择刻意保持工具集合简单：如果只给一个搜索工具，性能提升更能反映模型学会了“何时、如何、多轮地检索”，而不是复杂工具编排带来的额外工程优势。

比较方法包括两个非 RL baseline 和五个 RL 算法。非 RL baseline 是 Base Tool Call 与 Naive RAG：Base Tool Call 指模型原生 function calling 加 wikisearch 工具，但不经过 end-to-end RL；Naive RAG 是单次检索增强生成。RL 算法包括 PPO、GRPO、REINFORCE++、REINFORCE++Baseline 和 RLOO，用于验证 Agent-R1 是否只是适配某个单一算法，还是能作为一个通用 Agent RL framework 支持不同 advantage/reward estimator。

评价指标是 Exact Match (EM)。HotpotQA 和 2Wiki 标为 in-domain，Musique 标为 out-of-domain。论文强调主结果表的数值都是 EM，不是 F1 或综合分数。reward 也以 EM 为答案正确性核心，但加上格式约束：只有当最终答案格式和工具调用格式都满足要求时，才使用答案 EM；否则通过 $r_{\text{format}}-1$ 惩罚格式错误。这让训练目标同时覆盖“能答对”和“能以可执行工具调用/可抽取答案格式完成任务”。

从 released code 看，MultihopQA 训练脚本使用 4 GPUs、1 node、训练 1 epoch，rollout 重复数为 5，最大交互轮数为 5，prompt 与 response 上限均为 8192，单轮 response 上限为 1024，wiki 工具返回最大长度为 2048。PPO 脚本使用 GAE、KL reward penalty 系数 0.001、critic warmup 5；GRPO 脚本使用 group-based estimator 和 actor KL loss。论文正文没有完整列出这些工程参数，因此复现时应优先以 examples/trainer/run_ppo_multihopqa.sh 和 examples/trainer/run_grpo_multihopqa.sh 为准，同时注意它们默认模型大小与论文文字存在差异。

5. Experimental Results (实验结果)

主结果显示，所有 Agent-R1 支持的 RL 算法都显著超过 Base Tool Call 和 Naive RAG。Table 3 的精确 EM 如下：

Method	HotpotQA†	2Wiki†	Musique*	Average
Base Tool Call	0.1372	0.0891	0.0277	0.0847
Naive RAG	0.1916	0.1792	0.0277	0.1328
PPO	0.4136	0.5468	0.1552	0.3719
GRPO	0.4405	0.5741	0.1485	0.3877
REINFORCE++	0.3768	0.4796	0.1336	0.3300
REINFORCE++Baseline	0.3966	0.5406	0.1485	0.3619
RLOO	0.4089	0.5641	0.1419	0.3716

最强平均性能来自 GRPO，Average EM 为 0.3877；PPO 和 RLOO 非常接近，分别为 0.3719 和 0.3716。相对 Naive RAG 的 0.1328，GRPO 的平均 EM 提升 0.2549；相对 Base Tool Call 的 0.0847，提升 0.3030。HotpotQA 与 2Wiki 上 GRPO 都是最佳，分别达到 0.4405 和 0.5741；Musique 上 PPO 最好，为 0.1552，GRPO 与 REINFORCE++Baseline 都是 0.1485。这个模式说明 Agent-R1 在 in-domain 多跳检索上收益更明显，OOD 数据集仍然困难，但 RL 相比非 RL baseline 仍有稳定增益。

不同 RL 算法之间的排序也有信息量。REINFORCE++ 的平均 EM 为 0.3300，是五个 RL 算法中最低；加入 baseline 后 REINFORCE++Baseline 升到 0.3619，说明减少方差对这种稀疏终局 reward 的 Agent 任务很重要。PPO、GRPO、RLOO 都在 0.37 到 0.39 区间，表明 Agent-R1 的框架收益不是某个算法偶然调参得到的，而是来自多轮 rollout、工具环境抽象和 mask 对齐带来的共同改进。

Ablation 直接验证了 policy optimization refinements 的作用。Table 4 的精确 EM 如下：

Configuration	HotpotQA	2Wiki	Musique	Average
PPO (loss mask ✓, adv. mask ✓)	0.4136	0.5468	0.1552	0.3719
→ Advantage mask disabled	0.3630	0.4641	0.1138	0.3136
→ Loss mask disabled	0.3429	0.4631	0.1005	0.3022
GRPO (loss mask ✓)	0.4405	0.5741	0.1485	0.3877
→ Loss mask disabled	0.4260	0.5485	0.1422	0.3722

对 PPO 来说，关闭 advantage mask 后 Average 从 0.3719 降到 0.3136，下降 0.0583；在此基础上再关闭 loss mask，Average 继续降到 0.3022。HotpotQA 从 0.4136 降到 0.3630 再到 0.3429，2Wiki 从 0.5468 降到 0.4641/0.4631，Musique 从 0.1552 降到 0.1138 再到 0.1005。这个结果清楚表明，对多轮 Agent trajectory 而言，credit assignment 的错误会直接伤害策略学习：advantage 如果没有对齐到动作位置，就会把环境观察、固定上下文或工具返回混进学习信号。

对 GRPO 来说，关闭 loss mask 后 Average 从 0.3877 降到 0.3722，下降 0.0155；HotpotQA 从 0.4405 降到 0.4260，2Wiki 从 0.5741 降到 0.5485，Musique 从 0.1485 降到 0.1422。下降幅度小于 PPO 的 advantage-mask ablation，但方向一致，说明 loss mask 对 group-based 算法同样有用。由于论文没有单独 ablate GRPO 的 advantage mask，这里不能推断 GRPO 不需要 advantage alignment；只能说在该设置中作者没有报告这项拆分实验。

作者没有单列 limitations section，但从实验范围和代码可见至少有四个限制。第一，验证任务集中在文本 MultihopQA 与单一 wiki search 工具，尚未证明同一框架在网页浏览、代码执行、数据库操作、多工具组合或视觉工具场景中同样稳定。第二，reward 主要依赖最终 EM 与格式检查，论文虽讨论 process reward，但实验没有系统展示稠密过程奖励如何设计、是否会引入 reward hacking。第三，Musique 的绝对 EM 仍低，最佳 PPO 也只有 0.1552，说明跨分布多跳推理仍远未解决。第四，论文正文与 released legacy scripts 在默认模型大小上存在 3B vs 1.5B 的差异，复现者需要明确自己是在复现论文配置、legacy 脚本配置，还是更新后的 main v0.1.0 架构。

总体结论是：Agent-R1 的主要贡献在于把 LLM Agent 的交互式行为转换成可训练的多轮 RL episode，并用 Tool/ToolEnv、action mask、advantage mask 和多算法 trainer 形成可扩展框架。实验数值说明，在 MultihopQA 这类需要反复检索和推理的任务上，端到端 RL 明显优于只给工具或单次 RAG；ablation 则说明这种提升不是简单“多训练几步”带来的，而依赖于正确区分模型动作与环境反馈。对于后续工作，最值得沿用的是它的边界划分：把工具返回看作 state transition，把模型生成看作 action，把 reward/advantage 对齐到 action，而不是把整段交互文本无差别地当成语言建模目标。