读懂 AgentFlow：让 Agent 在「执行过程中」学会规划和用工具
论文：In-the-Flow Agentic System Optimization for Effective Planning and Tool Use
关键词：Agent、Tool Use、Planner、Memory、Flow-GRPO、强化学习、长链路推理
0. 先说结论
这篇论文我觉得最值得看的地方，不是它又做了一个 Agent 框架，而是它提出了一个很关键的问题：
我们现在很多 Agent 系统看起来会规划、会调用工具、会反思，但它们大多只是靠 Prompt 和手写流程在跑，并没有真正从“执行过程”里学习。
论文提出的 AgentFlow 就是在解决这个问题：它把 Agent 拆成 Planner、Executor、Verifier、Generator 四个模块，然后只训练最关键的 Planner，让它在真实的多轮工具调用过程中学习“下一步应该做什么”。
一句话概括：
AgentFlow = 模块化 Agent 系统 + 显式 Memory + 在真实执行流中训练 Planner 的 Flow-GRPO。
1. 这篇论文想解决什么问题？
现在有两类常见做法：
第一类是 Tool-Integrated Reasoning Model。也就是一个模型同时负责思考、决定是否调用工具、写工具调用参数、读工具结果、继续推理，最后输出答案。
它的好处是训练形式比较统一，但问题也很明显：
- 链路一长，上下文会越来越大；
- 工具一多，模型既要学策略，又要学调用格式；
- 最终答案对不对往往是一个稀疏奖励，很难知道中间哪一步做对了；
- 遇到新工具、新任务，泛化容易脆。
第二类是我们更熟悉的 Agentic System，比如多个模块协作：Planner 负责计划，Coder 负责写代码，Critic 负责检查。
它更像工程系统，也更容易扩展，但大部分 Agentic System 是 training-free 的，也就是模块本身不训练，主要靠 Prompt、规则和手写 workflow。这就导致它很难真正从失败中学习。
所以论文的问题可以简化为：
能不能保留 Agentic System 的模块化优势，同时又让它具备可训练能力？
AgentFlow 的答案是：可以，但不要一上来训练全部模块，先训练 Planner。
2. AgentFlow 的整体架构
AgentFlow 由四个模块组成：
- Planner：决定当前轮要完成什么子目标、用哪个工具、给工具什么上下文；
- Executor：根据 Planner 的计划生成具体工具命令，并执行工具；
- Verifier：检查工具结果是否有效，判断信息是否足够，决定继续还是停止；
- Generator：当 Verifier 判断可以停止后，根据 Memory 生成最终答案。
系统中还有两个关键对象：
- Toolset K：工具集合，比如 Python Coder、Google Search、Wikipedia Search、Web Search 等；
- Evolving Memory M：结构化记忆，保存每一轮的子目标、工具、命令、结果、检查状态。
它每一轮的流程大概是：
Query + Memory + Toolset
↓
Planner：规划下一步，选择工具
↓
Executor：执行工具，拿到结果
↓
Verifier：判断结果是否足够
↓
更新 Memory
↓
如果不够，进入下一轮；如果足够，Generator 输出答案
这里最重要的一点是：Memory 不是随便拼接的历史对话，而是结构化状态。
这对 Agent 来说非常关键。因为长链路任务里，真正拖垮系统的往往不是模型能力，而是状态管理混乱：前面查到了什么、哪个工具失败了、下一步要避免什么、是否已经满足条件，这些都需要明确记录。
3. 为什么只训练 Planner？
论文的设计很工程化：
- Executor 主要负责执行，工具 schema 明确，变动空间不大；
- Verifier 主要负责检查，可以先靠固定模型和提示词实现；
- Generator 只在最后基于 Memory 汇总答案；
- Planner 决定整个系统的行动策略，是最值得训练的模块。
也就是说，AgentFlow 不追求“所有模块一起端到端训练”。它更像是在说：
一个 Agent 系统最核心的智能，往往体现在“下一步做什么”。
这其实很符合我们做 Agentic RAG、代码 Agent、PDF 解析 Agent 的经验。
很多失败不是因为工具不会执行，而是 Planner 一开始就选错了路：该搜索的时候写代码，该查页面的时候泛泛搜索，该验证的时候直接输出，该停止的时候又陷入循环。
4. Flow-GRPO 是什么？
AgentFlow 的训练算法叫 Flow-GRPO。
它的核心直觉非常简单：
不强行给每一步设计复杂的中间奖励，而是看最终答案是否正确；如果最终成功，就把这个成功信号广播给这条轨迹里的每一步 Planner 决策。
为什么这样做？
因为在多轮 Agent 里，某一步的价值经常要过几轮之后才体现出来。
比如一个搜索问题：
- 第 1 步搜到一个看似无关但其实关键的实体；
- 第 2 步根据这个实体查 Wikipedia；
- 第 3 步再进入具体网页；
- 第 4 步才得到答案。
如果你只看第 1 步，很难判断它到底有没有价值。论文干脆使用最终结果作为全局奖励，把多轮问题拆成多个单轮更新。
更具体地说：
- 对同一个问题采样多条 AgentFlow 执行轨迹；
- 每条轨迹最后生成一个答案；
- 用 Judge 判断最终答案是否正确，得到 0/1 奖励；
- 把这条轨迹的最终奖励赋给轨迹里的每一轮 Planner action；
- 在同一组轨迹之间做归一化 advantage；
- 用类似 PPO/GRPO 的 clipped objective 更新 Planner。
它解决的不是“工具怎么执行”，而是“Planner 怎么学会选择更有希望成功的行动路径”。
5. 实验结果怎么看？
论文在四类任务上测试：
- 知识搜索：Bamboogle、2Wiki、HotpotQA、Musique；
- Agentic 任务：GAIA；
- 数学推理：AIME24、AMC23、GameOf24；
- 科学推理：GPQA、MedQA。
最直观的结果是：AgentFlow 加上 Flow-GRPO 后，在多个任务上都有明显提升。
整理几个关键数字：
| 任务类型 | AgentFlow 未调优 | AgentFlow + Flow-GRPO | 提升 |
|---|---|---|---|
| 知识搜索平均 | 47.2 | 57.3 | +10.1 |
| GAIA | 17.2 | 33.1 | +15.9 |
| 数学推理平均 | 31.7 | 51.5 | +19.8 |
| 科学推理平均 | 56.5 | 63.5 | +7.0 |
还有一个很有意思的现象：Flow-GRPO 不只是提高正确率，也改变了工具使用偏好。
比如论文里提到，面对 2Wiki 这种需要广泛事实检索的任务，训练后的 Planner 更愿意使用 Google Search；而面对 MedQA 这种更专业的医学任务，它会减少泛泛的 Google Search，转向更合适的 Wikipedia Search / Web Search。
也就是说，它学到的不是“多调用工具就好”，而是更接近：
当前任务需要什么信息源，我就选择更合适的工具。
6. 为什么离线 SFT 反而不行？
论文里有一个很值得注意的 ablation：他们用 GPT-4o 轨迹做 SFT，结果反而出现明显性能下降。
这件事对做 Agent 的人很有启发。
因为 SFT 学的是 token-level imitation：别人怎么写，我就怎么模仿。可是 Agent 的真正目标是 trajectory-level success：整条链路最后有没有解决问题。
这两者并不等价。
尤其在多工具、多轮交互里，某个 action 是否合理，依赖当时的 Memory、工具返回、错误状态。离线轨迹无法覆盖部署时的所有状态分布。一旦执行时遇到偏差，SFT 模型可能只会继续模仿旧轨迹，而不会真正恢复。
所以论文的观点是：
Agent Planner 最好在真实执行流里训练，而不是只在静态轨迹上模仿。
这也是 “in-the-flow” 这个词的含义：不是训练完再部署，而是在 rollout 的真实系统动态中收集状态、动作、工具结果和最终奖励。
7. 对我们做 Agentic RAG / PDF 图纸解析有什么启发？
我觉得这篇论文对工程落地非常有启发，尤其是如果你在做 Agentic RAG、代码 Agent、CAD/PDF 图纸解析这类长链路系统。
我的理解是，先不要急着“训练一个万能 Agent”，而是先把系统拆成下面这种结构：
Planner：决定下一步要解析什么，比如找 schedule、找 floor plan、核对 mark
Executor：调用具体工具，比如 PDF 表格抽取、矢量线解析、OCR、页面分类
Verifier：检查当前结果是否完整，比如 schedule 是否覆盖、CAD-only 是否需要人工确认
Memory：保存每一步证据，比如 page、bbox、mark、尺寸、材料、来源
Generator：最后输出结构化 JSON / Markdown 报告
对 PDF 图纸解析来说，最终奖励也不一定要一开始做复杂 RL。可以先收集验收标签：
- 门窗 mark 是否识别对；
- schedule 行是否漏掉；
- CAD-only opening 是否误入报价清单；
- size/material/quantity 是否和人工结果一致；
- 输出 JSON 是否符合 schema。
等轨迹和验收数据积累起来，再考虑训练 Planner。
也就是说，AgentFlow 给我们的启发不是“马上复现 Flow-GRPO”，而是：
先把 Agent 系统设计成可记录、可验证、可优化的形态。
没有结构化 Memory，没有每一步工具结果，没有最终验收标签，就算想训练也没数据。
8. 这篇论文的局限
当然，这篇论文也不是没有问题。
第一，它主要训练 Planner，其他模块还是冻结的。未来如果 Executor / Verifier 也能一起优化，系统上限可能更高，但训练会更复杂。
第二，最终奖励主要来自 LLM-as-judge。对于数学、选择题、结构化答案还好，但对于更开放的任务，judge 本身的稳定性会成为问题。
第三，实验里的工具集合相对有限。如果换到真实生产环境，工具会更多、更脏、更慢，还会有权限、成本、失败重试等问题。
第四，它的训练成本也不低。论文中训练需要多条 rollout、多工具调用和 GPU 资源，这对普通个人项目不一定马上可复现。
但这些不影响它的主要价值：它把 Agentic System 从“手写流程”往“可训练系统”推进了一步。
9. 最后总结
我对这篇论文的理解可以总结成三句话：
- AgentFlow 把 Agent 拆成 Planner、Executor、Verifier、Generator，并用结构化 Memory 串起来。
- Flow-GRPO 只训练 Planner，用最终答案奖励广播到每一轮决策，缓解长链路稀疏奖励问题。
- 对工程落地来说，最大的启发是：Agent 不只是 Prompt 编排，而应该逐步变成可记录、可验证、可训练的系统。
如果你现在正在做 Agentic RAG 或工具调用系统，可以先从最简单的一步开始：
把每一轮 Planner 决策、工具调用、工具结果、Verifier 判断、最终答案全部结构化记录下来。
因为只有这样，后面才谈得上评测、复盘、优化，甚至训练。
