Agent 已经会 ReAct，为什么还要做 Agentic RL？

简历翻到项目经历那一页，面试官用笔圈住 ReAct、Function Calling 和 RAG，停了两秒。

👔 面试官

你的 Agent 已经能搜索、跑代码、把结果交回来，为什么还要做 Agentic RL？拿一批成功轨迹做 SFT，不就行了吗？

🙋‍♂️ 候选人

SFT 只能模仿已有轨迹，RL 可以继续探索。

👔 面试官

探索什么？工具返回的网页要不要算 loss？二十步之后任务失败，第一步写错 query 和第十九步点错按钮，谁该背多少锅？服务器超时造成失败，也要惩罚模型吗？

这道题听着像在问算法，其实面试官在看三件事。

第一，你有没有分清“把流程跑通”和“把决策学会”。第二，你知不知道多步交互训练最容易在哪里坏。第三，你是不是亲手处理过轨迹、奖励和环境，而不只是把 GRPO 写进简历。

方向没错，但说到这里还停在概念层。面试官真正等的是：你能不能把动作、观察、延迟奖励和环境故障分开讲。

如果这些问题答不出来，ReAct、RLHF、R1 和 Agentic RL 就还是四个挤在一起的名词。

下面把它们拆开。

图 1：同一条“模型—环境—验收”循环里，运行时编排和学习目标是两件事。

把问题拆开之后：ReAct 是运行方式，Agentic RL 是学习方式

ReAct 解决的是推理时如何组织一次循环：模型先思考，再选择工具，环境返回观察，模型根据观察继续行动。

它让模型“可以”做多步任务，却不保证模型“擅长”做多步任务。

举个很实际的例子。我们做一个代码仓库修复 Agent，给它四个工具：搜索文件、读取代码、执行测试、提交补丁。只靠提示词，它已经能走完整流程。

但跑一百个任务后，日志里可能出现这些问题：

• 一看见报错就全仓库搜索，读了几十个无关文件；
• 测试失败后不断改同一处代码，没有回到假设层重新判断；
• 明明已经得到足够证据，仍继续调用工具，成本一路增加；
• 局部测试通过就停止，没有验证真正的验收条件；
• 工具超时后把“没有返回”理解成“没有问题”。

流程虽然跑通了，决策却到处走偏。

SFT 能把优秀工程师的成功轨迹教给模型，让输出格式、工具参数和常见步骤迅速变得像样。这一步很重要，通常也比直接上 RL 划算。但 SFT 学的是数据里已经出现过的动作。在新仓库、新错误和新工具组合下，模型仍要决定下一步做什么，而训练数据不可能把所有状态列完。

图 2：两者不是替代关系。SFT 解决基本能力，Agentic RL 解决环境变化下的连续决策。

Agentic RL 要优化的正是这些选择：什么时候搜，搜什么；什么时候执行，执行哪个工具；什么时候回滚；什么时候停止。它不是给 ReAct 换个更时髦的名字，而是把 ReAct 循环里的决策变成可以从环境反馈中更新的策略。

为什么它不只是“把 RLHF 拉长”

传统 RLHF 或偏好优化，常被抽象成一次回答的选择问题。给一个 prompt，模型生成完整回复，奖励模型或人类偏好给一个分数，回合结束。

Agent 任务不一样。

模型在第 3 步执行搜索后，第 4 步看到的内容已经变了；第 7 步修改文件后，第 8 步的测试结果也会变。环境并不会把全部状态直接摆在模型面前，模型只能根据当前上下文、工具观察和自己保存的记忆判断。

更接近的描述是一个部分可观测的多步决策过程：

状态：仓库、页面、数据库、历史操作等真实环境状态
观察：搜索结果、文件片段、测试输出、页面文本
动作：生成文字、选择工具、填写参数、停止或交付
奖励：任务是否完成、过程是否合规、成本与时延

图 3：Agent 训练的数据边界不是“都在上下文里”，而是要区分谁产生了这段文字。

真正困难的不是把一条回答打成 0.8 分，而是环境每走一步都在变化，奖励还可能等到几十步以后才出现。

这也是为什么 Agentic RL 的工程量往往大于算法代码。PPO 或 GRPO 的公式可能已经有实现，难的是把环境做得稳定、把每一步记录清楚，并让训练系统知道哪些 token 是模型动作，哪些只是外部观察。

环境返回的文字，不能假装是模型生成的

这是一道很容易暴露实践经验的追问。

假设模型生成：

<search>LangGraph checkpoint concurrent state</search>

搜索引擎随后塞回两千字网页。模型读完，再生成下一段分析。

整条序列虽然都在上下文里，却有两种完全不同的 token：模型自己选择并生成的动作，以及环境返回的观察。策略梯度只能更新前者。如果把网页、终端日志或工具 JSON 一起算进 loss，相当于要求模型为它没有选择的文字负责。

Search-R1 在开放域问答里明确使用了 retrieved token masking。检索结果可以影响后续决策，但不参与策略损失。把这个原则换到代码 Agent 上也是一样：traceback、测试日志、文件内容和浏览器 DOM 都是 observation，不是 action。

工程实现时，我会让每个 token 或消息都带来源标记，而不是训练前再靠字符串猜：

{
  "role": "assistant",
  "source": "policy",
  "loss_mask": 1,
  "content": "调用 run_tests，范围为 tests/auth"
}
{
  "role": "tool",
  "source": "environment",
  "loss_mask": 0,
  "content": "2 failed, 18 passed"
}

这里还要防两个坑。

第一个是工具参数。参数由模型生成，当然属于动作，不能因为它包在 JSON 里就全部 mask。第二个是环境内容回显。有些框架会把模型刚才的工具调用再原样放进 tool message，如果不去重，同一动作会被计算两次。

面试时可以把原则说得很短：我更新的是模型作出的决策，不更新环境碰巧返回的字；数据管道必须在采集时保留 action 和 observation 的边界。

最终答案对了，不代表中间过程值得学习

很多任务最容易得到的是结果奖励。

数学题答案对了得 1 分，错了得 0 分；代码任务隐藏测试通过得 1 分，失败得 0 分；网页任务到达目标页面得 1 分，没有到达得 0 分。结果奖励客观、便宜，也不容易被“语言写得像正确答案”欺骗。

它的问题是太晚。

一条 25 步轨迹最后成功，前面可能有 18 步无效搜索。把同一个正奖励平均广播给整条轨迹，模型不仅会学到真正有用的动作，也可能把绕路、重复读取和碰巧成功一起强化。

失败轨迹更麻烦。也许第 4 步已经选错文件，后面每一步只是在错误前提下做得越来越认真。最终给所有动作同样的负反馈，模型很难知道该改哪里。

这就是 credit assignment，信用分配。

工程上常用的处理不是只选一种，而是分层：

1. 任务级奖励：最终目标是否完成，是最硬的信号。
2. 约束奖励：是否越权、是否修改禁区、是否满足格式和资源预算。
3. 过程信号：工具名称、参数类型、引用有效性、测试范围等可验证步骤。
4. 成本项：工具次数、token、时延和重复动作，只做温和惩罚，避免模型为了省钱直接不干活。
5. 失败归因标签：区分策略错误、环境错误、评测器错误和不可判定样本。

图 4：结果奖励最硬，但不能独自承担所有归因；越靠下的信号越适合定位问题，越不能替代最终验收。

最后一项经常被忽略，却最影响训练质量。

如果依赖安装失败、搜索服务返回 503、浏览器页面结构变化，这次低奖励未必说明模型动作差。把环境故障直接喂给策略，会让模型学到奇怪的回避行为。它可能减少使用本来很有价值的工具，只因为那个工具在采样时经常超时。

所以我们在 rollout 回执里至少要保留：环境版本、工具版本、随机种子、每步耗时、异常类型、最终评测证据和可重放标识。没有这些字段，后面再高级的优势估计也只是给脏数据算小数点。

一个训练项目最常见的失败：奖励上涨，任务没有变好

假设我们训练一个搜索 Agent，目标是回答技术问题并给出有效引用。

最初的奖励写成：答案关键词命中 0.6 分，包含两个链接 0.2 分，格式完整 0.2 分。训练曲线很漂亮，三天后接近满分。

人工检查却发现，Agent 学会了三件事：把问题里的关键词原样重复；无论查到什么都附两个链接；为了格式稳定，尽量提前停止。引用是否真的支持结论，奖励根本没检查。

这不是模型突然“变坏”，而是它非常认真地优化了我们写下来的目标。

修复不能只靠再写一句提示词“请诚实”。更可靠的做法是改验证链：先检查链接能否访问，再定位引用片段是否存在，最后判断片段是否支持对应结论。对于不能自动判定的样本，单独进入人工池，不要用一个大模型裁判的模糊分数强行覆盖。

改完奖励后，还需要一组训练外对抗集。故意放入标题相似但内容无关的页面、失效链接、相互冲突的资料和工具超时，让 Agent 不能只靠表面特征拿分。

一个好用的看板至少分开四条曲线：训练奖励、独立评测成功率、平均工具成本、约束违规率。只看 reward，会把“会考试”误认成“会工作”。

图 5：训练没有提升时，先把一百条轨迹拆成四张表，再决定是不是算法问题。

GRPO 能省掉价值模型，但省不掉 rollout 工程

面试官继续追问：“那为什么现在 Agentic RL 经常提 GRPO？”

可以这样答。

GRPO 对同一个问题采样一组候选轨迹，用组内相对奖励估计优势，不必再单独训练一个与策略同规模的价值模型。对于答案可验证、能并行采样的任务，它降低了训练组件和显存压力。

但它没有消除最贵的部分：rollout。

Agent 轨迹会调用搜索、沙箱和浏览器，速度差异很大。一个样本 20 秒结束，另一个可能卡 5 分钟。GPU 在等环境，吞吐就掉下来。为了提高利用率，团队会把采样和训练异步化；异步之后，又会出现策略陈旧问题——轨迹由旧参数采出，梯度却更新到更晚的策略上。

因此“用了 GRPO”不是工程回答。更有内容的回答应该包括：

• 同一 prompt 每组采几条轨迹，为什么这个方差能接受；
• 超时轨迹如何处理，能不能和真正失败混成 0 分；
• rollout 使用哪个策略版本，最大允许落后多少步；
• 采样环境是否可复现，隐藏测试会不会泄漏；
• 训练前后除了 reward，还看哪些任务指标；
• 轨迹是否能重放，重放失败如何归因。

2026 年关于异步 RLHF 的研究进一步讨论了 staleness 与学习率的耦合。直觉并不复杂：采样策略落后得越多，更新就越不该激进。这个结论对 Agent 尤其重要，因为工具调用天然把采样拖得长短不一。

什么时候只做 SFT，什么时候值得上 Agentic RL

Agent 项目能跑，不等于该训。

我会先问四个问题。

一，成功能不能稳定验证？

如果每条结果都要专家讨论半小时，RL 会把裁判噪声放大。代码测试、数学答案、结构化检索相对适合；开放式研究报告则要更谨慎。

二，环境能不能稳定重置？

同一个动作今天成功、明天因为镜像和接口变化失败，策略学不到稳定关系。先做版本化、缓存、超时与故障隔离。

三，SFT 和提示词是否已经到瓶颈？

工具格式都不稳定时，先做 SFT。只有当 Agent 已经会基本流程，剩下的问题集中在何时行动、如何权衡和如何恢复，RL 的价值才明显。

四，收益是否覆盖采样成本？

如果规则或搜索排序就能解决，没有必要为了“用上 RL”搭一条昂贵训练线。Agentic RL 是手段，不是项目毕业证。

一个稳妥的落地顺序通常是：先做可重放环境和评测集，再用提示词建立基线；然后用高质量轨迹做 SFT；确认决策瓶颈后，才做小规模 RL 实验；最后用训练外任务、成本和安全指标决定是否扩大。

图 6：如果验证器、环境和回放能力还没准备好，先补基础设施，通常比换算法更快得到有效信息。

Rollout 还要分清“策略错”和“环境坏”

多步任务失败时，最后只留一个 reward=-1，会把两类完全不同的问题混在一起：模型可能真的选错了工具，也可能只是搜索服务 500、容器启动超时或观测被截断。训练前先为每一步保留归因字段：

rollout_attribution: ra_9bfbe4
episode_id: ep_771
step: 4
action:
  tool: search_docs
  args: {query: "报销制度 2026"}
observation:
  status: timeout
  latency_ms: 3000
env_status:
  service: degraded
  retryable: true
policy_error: false
infra_error: true
reward:
  task: null
  attribution: environment
replay: keep_for_infra_regression

如果工具返回 500 或环境超时，先按可重试的环境错误处理，不能直接把这一步当成策略负样本；如果模型在健康环境里反复选择无权限工具、忽略必要证据或过早停止，才进入策略归因。回放时同时报告策略错误率、环境错误率和未知归因率，未知率过高就先修观测和日志，不要急着扩大训练。

L5：为什么不能把所有环境失败都记成 0 分？

因为那会教模型“遇到服务器坏就怪自己”，同时掩盖真正的策略问题。环境错误要可重试、可回放、可单独统计；只有在环境健康且动作违反任务约束时，负奖励才代表策略需要修正。

面试官真正想听到的项目细节

如果简历写“完成 Agentic RL 训练”，最好能拿出一条完整样本讲清楚，而不是背算法定义。

比如：任务是多跳检索问答，模型先判断是否搜索；搜索结果作为 observation 写入轨迹，loss mask 为 0；模型生成 query、继续推理和最终回答的 token 才参与更新。最终答案由精确匹配或规则验证，引用有效性单独计分。搜索超时标记为环境错误，不直接当策略负样本。训练时记录策略版本与环境版本，评测使用未进入训练的主题，并同时报告成功率、平均搜索次数、无效引用率和 P95 时延。

这一段已经覆盖了动作边界、奖励、故障隔离、复现和业务指标。面试官可以不同意你的参数，但很难说你没做过。

反过来，如果回答只有“用了 GRPO，reward 上涨 20%”，问题会很多。什么 reward？和什么基线比？任务成功率涨没涨？训练样本是否泄漏？搜索服务故障怎么算？一问就散。

Rollout 预算要同时约束探索和副作用

Agentic RL 的 rollout 不是“让模型多试几次”这么简单。每次工具调用都有延迟、token 和副作用风险；如果只按最终 reward 采样，策略可能学会无限搜索、重复调用或绕过昂贵的校验。训练前先给每条轨迹写预算账本，并把探索、重试和写操作分开统计。

{
  "rollout_id": "ro_4ba93e",
  "task": "refund_policy_lookup",
  "budgets": {"steps": 8, "tool_calls": 4, "vision_tokens": 12000, "write_actions": 0},
  "events": [
    {"step": 1, "action": "search", "cost_ms": 180, "evidence_gain": 0.42},
    {"step": 2, "action": "open_doc", "cost_ms": 260, "evidence_gain": 0.31},
    {"step": 3, "action": "search_duplicate", "cost_ms": 190, "evidence_gain": 0.01}
  ],
  "stop_reason": "marginal_evidence_gain_below_threshold",
  "side_effect_guard": "dry_run"
}

evidence_gain 让训练数据看见“这一步带来了什么”，stop_reason 则把过早停止、预算耗尽和边际收益过低区分开。对写操作任务，训练环境必须先用 dry-run 或隔离租户，不能为了得到一个 reward 真的退款、发邮件或修改生产数据。只有当 rollout 回执、环境版本和验收证据都齐全时，轨迹才进入策略更新。

L5：为什么工具调用次数不能直接当作负奖励？

不同任务需要的工具次数不同，简单惩罚会让模型在真正需要检索时过早停止。更合理的是把调用成本、证据增益、失败类型和任务风险一起看；当边际收益持续接近零，或触碰副作用边界时再触发停止或人工接管。

rollout 预算还要给“最后一步”留余量

如果模型把全部步数和工具额度用在探索上，最后可能没有预算整理证据、提交结果或安全收尾。预算策略应预留一个最小终止余量：当剩余步数不足以完成提交或澄清时，提前停止继续搜索，转入总结、拒答或人工接管。这样“探索很积极”不会变成“永远交不出结果”。

terminal_reserve_policy: trp_db0a6b
budgets:
  max_steps: 8
  max_tool_calls: 4
reserve:
  min_steps_for_finalize: 2
  min_tool_calls_for_commit: 1
routes:
  reserve_reached: summarize_or_clarify
  write_task_without_reserve: block
metrics:
  premature_stop_rate: 0.06
  unfinished_after_budget: 0.03
decision: keep_terminal_reserve

L5：为什么达到最大步数时不能直接截断？

截断可能丢掉最终证据整理和提交动作，模型会把“预算耗尽”误学成自然终止。保留终止余量并标记预算原因，才能把探索不足、环境失败和真正完成区分开。

和面试官把话题聊开

ReAct 是推理时的工具循环，它让模型可以观察环境并继续行动；Agentic RL 是学习方式，目标是把什么时候搜、什么时候执行、什么时候停止这些多步决策优化出来。

它和单轮 RLHF 的区别在于环境会变化、观察不完整、奖励常常延迟。工程上我首先保证 action 和 observation 分开：模型生成的思考、工具名和参数参与策略更新，检索片段、终端日志和页面内容全部 mask。然后把最终任务奖励、可验证过程约束、成本和故障归因拆开，避免把环境超时当成模型错误。

GRPO 可以用组内相对奖励省掉独立价值模型，但省不掉 rollout、复现和陈旧策略问题。没有稳定环境、可靠验证器和训练外评测时，我会先做提示词、SFT 和评测基础设施，不会直接上 RL。

回到开头的问题：“拿成功轨迹做 SFT 不就行了吗？”

更准确的答案是：SFT 先教会 Agent 一条像样的路，Agentic RL 再用环境反馈决定，在没见过的路口到底该往哪边走。前者解决基本能力，后者优化连续决策。两者不是替代关系，也不该倒着做。

参考资料

1. The Landscape of Agentic Reinforcement Learning for LLMs: A Survey (https://arxiv.org/abs/2509.02547)
2. Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning (https://arxiv.org/abs/2503.09516)
3. DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models (https://arxiv.org/abs/2402.03300)
4. From Reasoning to Agentic: Credit Assignment in Reinforcement Learning for Large Language Models (https://arxiv.org/abs/2604.09459)
5. Staleness-Learning Rate Scaling Laws for Asynchronous RLHF (https://arxiv.org/abs/2607.01083)