很多人现在谈 agent，会把注意力放在两个方向上。
一个方向是把模型做得更强，让它自己在一条长上下文里想、查、算、调用工具。另一个方向是把系统拆成 planner、executor、critic 之类的模块，用工程编排把它们串起来。
但这两条路各有明显短板。
前者的问题是，一条单体策略要同时负责思考、选工具、处理反馈、生成答案。任务一长、工具一多、交互一复杂，训练就会越来越不稳。后者的问题是，很多 agent system 虽然结构上更像“团队协作”，但模块大多是冻结的，靠 prompt 和手工规则协调，真正上线后并不会从动态交互里继续学。
斯坦福大学、德州农工大学、UC San Diego 和 Lambda 的这篇被ICLR 2026 (Oral)接收的《In-the-Flow Agentic System Optimization for Effective Planning and Tool Use》，要解决的正是这个断层。
论文提出的核心判断很直接：
**Agent 的问题，不只是“要不要多模块”，而是这些模块能不能在真实多轮交互流里被 on-policy 地训练。**
作者提出了一个四模块系统AgentFlow，再配上一套叫Flow-GRPO的训练方法，把 planner 直接放回真实的 agent loop 里做强化学习。结果是，在搜索、agentic、数学和科学推理四类任务上，这个 7B 级别系统不仅稳定超过一批专用 baseline，甚至整体上还压过了 GPT-4o。
下面这篇文章重点讲六件事：
1.这篇论文到底在纠正什么旧范式
2.AgentFlow 这个系统是怎么运转的
3.Flow-GRPO 的奖励和更新规则为什么适合多轮 agent
4.实验到底强在哪，强得有多稳定
5.论文怎样证明“在线流程内训练”比离线模仿更关键
6.这篇工作的边界在哪里
它真正要修的，不是工具调用，而是 agent 训练范式
论文把现有方法分成两类。
第一类是 tool-integrated reasoning，也就是把
<think>、<tool\_call>、<answer>
全部塞进同一个大模型策略里训练。它的优点是端到端，缺点也很明显：上下文越来越长，动作空间越来越杂，最终奖励又很稀疏，训练时很难知道前面哪一步决策真正贡献了最后答案。
第二类是 training-free agentic systems。它们看上去更工程化，也更像“团队合作”，但 planner、executor、verifier 往往都只是预训练模型加 prompt 模板。系统虽然在运行，却没有在运行中学习。
所以这篇论文要补上的，不是某一个工具能力，而是中间缺失的那条路：
**既保留多模块 agent system 的分工结构，又让核心决策模块在真实交互流里直接优化。**
[AgentFlow 总览]
这张图先看左边。系统不是一口气生成最终答案，而是在多轮里循环：Planner -> Executor -> Verifier，直到 verifier 判断信息已经够了，才交给 generator 输出答案。右边是单轮展开图。planner 读 query、toolkit 和当前 memory，给出当前子目标、选用工具和工具使用上下文；executor 真正调用工具；verifier 再判断这一步是否有效、memory 是否足够继续推进。
AgentFlow 到底做了什么
AgentFlow的核心不是“模块更多”，而是模块边界被定义得比较清楚。
系统有四个模块：
Planner：唯一被训练的策略模块，负责拆当前子目标、选工具、决定这一步怎么做. 后面的a_t都指planner生成的tokenExecutor：执行工具调用，把 planner 的动作变成真实外部操作Verifier：判断执行结果是否有效、当前记忆是否足以终止Generator：在最终轮基于积累下来的 memory 生成答案
这里最关键的中间状态叫Memory。
论文没有把推理过程完全藏在不可见的 latent thoughts 里，而是把每一轮的 action、execution result、verification status 组织进一个显式、可更新的 memory。这样做有两个直接后果。
第一，系统状态是可观察的。planner 在第t轮看到的不是一团隐式上下文，而是query + toolset + M\_t。
第二，后续 RL 优化就有了清晰的“状态-动作-反馈”接口。也就是说，作者不是直接对整条长链做黑箱强化学习，而是先把 agent 运行过程形式化成一个有限步长、多轮更新的 MDP。
这个设计很重要，因为论文的真正贡献不在框图，而在后面的训练目标。
Flow-GRPO：它怎样把多轮 agent RL 变得可训练
如果只看直觉，多轮 agent 强化学习最难的地方有两个。
一个是长时程 credit assignment，也就是最后答对了，到底该把功劳算给哪一轮。另一个是 reward 稀疏，大多数中间步骤本身没有一个可靠、细粒度、低噪声的局部奖励。
论文的处理思路相当克制。
它没有发明一套复杂的逐步奖励工程，而是反过来做了一件更简单、但很符合 agent 结构的事：
**把最终结果是否正确，广播给整条轨迹里的每一轮 planner 决策。**
论文先定义最终结果奖励：
这里o是最终答案，q是问题，y\*是标准答案，R̄是一个二值奖励，由 LLM-as-judge 判定最终答案是否正确。它的意思非常直接：某一轮 actiona\_t本身没有单独奖励，但如果整条轨迹最后答对了，那么轨迹中的每一轮都拿到同一个全局成功信号。
这是Flow-GRPO的目标函数。T_i 为rollout i的轮次, a_i^t 表示第 i 条轨迹里，第 t 轮 planner 生成的 action。这个 action 不是最终答案，而是 planner 在当前轮做出的计划，比如当前子目标是什么、选哪个工具、给工具什么上下文。它本质上还是 PPO 风格的裁剪目标，只是更新对象不再是一条单轮文本轨迹，而是一个多轮 agent rollout 里的 planner token。论文的关键改写有两层。
第一层，是把多轮 RL 近似拆成一组“单轮更新问题”。
具体做法是：同一条 rollout 中每一轮 planner action 都拿到同一个 trajectory-level reward，于是局部更新就不需要再为每一步单独设计奖励函数。
第二层，是做 group-normalized advantage:
作者不是直接用原始成功或失败，而是在同一组并行 rollout 里做均值和方差归一化，让 advantage 变成“这条 rollout 比同组其他 rollout 好多少”。这一步的作用是减小方差，也让训练更稳定。
如果把这套目标翻成更容易理解的话，它在做的是：
**对同一个问题，同时采样多条 agent 轨迹；谁最终做对了，就把这条轨迹里的 planner 决策整体往上推；谁做错了，就整体往下压。**
实验不是只赢一点，而是跨任务一起赢
论文总共测了四类任务：
- 搜索密集型任务：Bamboogle、2Wiki、HotpotQA、Musique
- agentic 任务：GAIA
- 数学推理：AIME24、AMC23、GameOf24
- 科学推理：GPQA、MedQA
主系统里四个模块都用Qwen2.5-7B-Instruct，只有 planner 可训练。工具包括 base generator、Python coder、Google Search、Wikipedia Search 和 Web Search。训练时混用了 Search-R1 和 DeepMath 数据，最多 3 轮 rollout，8 条并行 rollout，最终结果奖励由 GPT-4o 做 judge。
这张表可以分两层读。
第一层，看和同规模 7B baseline 的对比。
带Flow-GRPO的 AgentFlow 在搜索任务平均 57.3%，比 AutoGen 的 42.4% 高 14.9 个点；在 GAIA 上做到 33.1%，比 Search-R1 的 19.1% 高 14.0 个点；在数学任务平均 51.5%，比 ToRL 的 37.0% 高 14.5 个点；在科学任务平均 63.5%，比 TIR 的 59.4% 高 4.1 个点。
第二层，看和更大闭源模型的对比。
GPT-4o 在这些四大类任务上的平均表现分别是 49.1%、17.3%、35.1%、45.5%，而 AgentFlow 对应是 57.3%、33.1%、51.5%、63.5%。也就是说，这篇论文不是只在某个窄 benchmark 上抬了一点分，而是在四种能力结构差异很大的任务上都保持领先。
论文怎样证明：提升来自 in-the-flow，而不只是更强 planner
这篇论文一个很扎实的地方，是它没有把提升简单归因于“planner 更聪明了”，而是专门做了训练策略对比。
表 3 有三个非常关键的结论:
第一，直接把 planner 从 Qwen-2.5-7B 换成 GPT-4o，平均只涨了 5.8 个点。
这说明更强底模当然有帮助，但它解决不了系统级协同问题。
第二，把 GPT-4o 轨迹拿来离线做 SFT，性能不仅没涨，反而平均掉了 19.0 个点。
这件事很重要，因为它直接反驳了一种常见直觉：只要把“好轨迹”收集起来做蒸馏，agent 就会变强。论文的结果恰恰表明，多轮 agent 的关键不是像不像一条参考轨迹，而是能不能在真实反馈里继续修正。
第三，真正把性能拉开的是 on-policy、in-the-flow 的 RL。
同样的系统、同样的工具，换成Flow-GRPO后，平均比 frozen planner 高 17.2 个点。
这三条结论合在一起，其实已经把论文最重要的论点讲透了：
**Agent 系统的瓶颈不是单个 planner 模型不够强，而是 planner 没有在活的多轮流程里学会和 executor、verifier、memory 一起协同。**
不只是分数更高，工具使用也更像“学会了”
这篇论文没有停在 leaderboard。
作者进一步去看 RL 前后 planner 的工具调用分布，以及调用错误率怎么变。
这组图左边两张是工具调用比例变化。2Wiki 需要广泛事实检索，训练后 Google Search 占比提升了 42.0%；MedQA 更依赖专业知识，训练后 Google Search 反而从 66.2% 掉到 10.9%，Wikipedia Search 提升到 59.8%，Web Search 提升到 19.5%。这说明 planner 学到的不是一个固定偏好，而是会按任务类型重新分配工具。
右边这张图看的是 tool-calling error rate。随着训练推进，GAIA 下降 28.4%，2Wiki 下降 19.4%，Bamboogle 下降 7.8%，AIME24 下降 8.4%。这说明论文优化的也不只是“选哪个工具”，而是“怎么把工具调对”。
换句话说，Flow-GRPO 让 planner 学到的是更稳定的操作策略，而不是单纯更长的思维链。
这篇论文还有两个很重要的外推结论
第一，效果会随着 backbone 规模提升而继续存在。
作者把整套系统从 3B 扩到 7B，发现两种规模下 Flow-GRPO 都能稳定带来收益。也就是说，这个训练方法不是只在某个特定模型上有效，而是和 backbone scaling 基本兼容。
第二，推理时允许更多 turns，性能也会继续提升。
这张图上半部分是 3B 和 7B 的训练扩展结果，下半部分是测试时 turn budget 从 3 提到 10 的变化。论文给出的趋势很清楚：2Wiki、GAIA、GameOf24、AIME24 全都随着T\_max提升而继续上涨，而且没有出现明显的退化循环。作者据此认为，系统确实会把更多 turn 用在更深的信息检索、子目标拆解和错误修正上。
这点其实很关键，因为很多人对多轮 agent 的担心就是“turn 一多就会原地打转”。至少在论文覆盖的任务里，AgentFlow 没有表现出这种明显退化。
这篇工作最值得记住的，不是一个新框架名，而是一个训练立场
如果只从表面看，AgentFlow 像是一个“四模块 agent + RL”的组合。
但更深一层，它表达的是一种训练立场：
**对 agent system 来说，最该被训练的，不一定是整条单体思维链，而是处在真实交互回路中的关键决策模块。**
这也是为什么这篇论文会比很多“再多几个 agent 角色”或者“再做一个工具调用数据集”的工作更有方法论价值。它把训练目标重新放回了系统运行现场，而不是停留在离线轨迹上。
当然，这篇工作也有明显边界。
论文目前只训练 planner，没有训练 executor、verifier 和 generator；训练阶段最大 rollout turn 只有 3，虽然测试时可以放大到 10；最终奖励依赖 GPT-4o 作为 judge；任务虽然跨四个领域，但仍以可验证问答和工具推理为主，还没有真正走到更开放、更长期的软件或真实互联网任务。
**这篇论文证明了，多模块 agent 的核心优化可以被正式写成一个 in-the-flow 的 RL 问题，而且这样做确实有效。**
结尾
AgentFlow 这篇论文做成的，不只是一个新 agent 框架。
它真正完成的是一次训练视角的转向。过去大家要么训练单体工具推理模型，要么搭训练外的多模块系统；这篇论文把两者接到了一起，让 agent system 第一次比较完整地进入“在真实流程里学习”的范式。
从结果上看，它证明了四件事：多模块分工可以和 on-policy RL 共存；最终结果奖励可以有效回传到多轮 planner 决策；离线模仿并不能替代 live dynamics 中的协同学习；而一旦训练目标对齐，7B 级别系统也能在跨领域任务上打出很高的上限。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
