❝长程 Agent 翻车，往往不是模型不够聪明，而是被"规划"和"执行"两件事同时压垮了。
论文来源：Lutfi Eren Erdogan, Nicholas Lee, Sehoon Kim, Suhong Moon, Hiroki Furuta, Gopala Anumanchipalli, Kurt Keutzer, Amir Gholami —— PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks，ICML 2025（arXiv:2503.09572v3）。代码已开源：github.com/SqueezeAILab/plan-and-act，70B 的 PLANNER / EXECUTOR 模型也已上架 HuggingFace。
你让一个 Agent 去网站上"关注这个 GitHub 项目的第一贡献者"，它大概率会卡在半路：要么一上来就瞎点，要么点着点着忘了自己要干啥。这是长程任务（long-horizon task）里最典型的一类翻车——不是模型不够聪明，而是它同时被两件事压垮了：既要谋划全局策略，又要抠每一步的具体操作。
这篇 ICML 2025 的论文给了我一个很干净的思路：与其逼一个模型身兼数职，不如把"规划"和"执行"彻底拆成两个角色。它叫这套框架 PLAN-AND-ACT。核心结论很硬：在 WebArena-Lite 上把成功率从基线 9.85% 拉到 57.58% （新 SOTA，比上一任 SOTA 高 8.48%），在真实网页基准 WebVoyager 的文本态任务上做到 81.36% （同样新 SOTA）。更关键的是，他们用一条可扩展的合成数据流水线，把"训练一个会规划的模型"这件原本很贵的事，压到了一小时生成 1.5 万条样本。
下面我把这套框架拆开讲透，重点放在为什么这么设计、数据怎么来的、哪些数字值得信、以及它对我们自己搭 Agent 有什么用。
一、问题：长程任务里 Agent 到底卡在哪
论文把长程 Agent 的规划难点拆成三句话，我觉得概括得很准：
- 拆不开：高层目标（"帮我订去纽约的机票"）很难被模型自己落成一串具体动作（"打开航司网站 → 填出发地 → 选日期"）。
- 记不住：任务越长，越容易丢失"已经做了什么、还差什么"的全局状态。
- 改不了：真实环境是动态的，搜索没结果、列表顺序变了，静态计划就直接傻眼。
作者先用一个残酷的基线实验把问题摆到台面上：在 WebArena-Lite 上，拿现成的 LLaMA-3.3-70B 直接按 ReAct 风格跑，成功率只有 9.85% ；即便套上 PLAN-AND-ACT 的雏形（只加一个没训练过的 PLANNER），也才 14.21%。光靠提示词（prompting）救不了，因为 LLM 在预训练阶段压根没被教过"怎么为网页任务做规划"。
❝踩坑提醒：很多团队一上来就堆复杂的多智能体编排、加一堆 in-context 示例，指望提示工程解决长程任务。这篇论文用 9.85% → 14.21% 的实测说明：不做针对性微调，提示工程的收益天花板很低。长程规划是"能力缺口"，不是"提示没写对"。
二、框架：PLANNER 与 EXECUTOR 双角色
PLAN-AND-ACT 的思路和 LLMCompiler 一脉相承——把系统切成两个专门模块。但论文真正的增量在后面：它给出了一套可扩展地训练 PLANNER 的合成数据方法，而且运行时结构极简单（只有 2 个 Agent）。
2.1 PLANNER：把目标拆成结构化计划
PLANNER 拿到用户查询后，输出一份结构化、高层级的计划。以"关注这个 GitHub 项目的第一贡献者"为例，它生成的是：
- Step 1：进入 Contributors（贡献者）页面
- Step 2：找到第一贡献者并关注他
注意这里只到"进哪个页面、找谁"这一层，不碰具体怎么点。它把最重的推理和任务分解扛了下来，给 EXECUTOR 一张清晰的路线图，同时留一点灵活空间。
2.2 EXECUTOR：把计划翻译成具体动作
EXECUTOR 是个 LLM Agent，输入是"当前 HTML 状态 + 计划里的某一步"，输出是接地（grounded）的环境动作，比如 do(action="Click", element="13")。它只管把抽象步骤变成点击、输入这类具体操作。论文里还提了一个工程细节：EXECUTOR 每执行一步就做一次"垃圾回收"，把冗余 HTML 清掉再走下一步，避免上下文被长页面拖垮。
2.3 动态重规划：每步都重新想一遍
这是我认为全文最有价值的设计点。早期方案最大的坑是计划一次生成、全程不变。一旦环境里出现计划时未知的信息（比如搜索结果、交易记录），静态计划就束手无策；更糟的是遇到"搜了个空"这类失败，EXECUTOR 还会 blindly 照着旧计划往下走。
PLAN-AND-ACT 的做法是：EXECUTOR 每执行一步，PLANNER 就根据"当前状态 + 之前的计划 + 已做的动作"重新生成一份计划。好处是计划本身成了"记忆载体"——前面找到"第一贡献者是 John Doe"这个信息会被写进新计划，长程任务的上下文问题因此不需要额外挂一个 memory 模块就能缓解。
2.4 Chain-of-Thought：两个角色都先推理
PLANNER 和 EXECUTOR 默认是直接出结果。论文补了一层 CoT：生成计划/动作之前，先让模型产出一段中间推理。这一步的增益后面用数据说话——非常重要。
三、合成数据：没有规划数据，怎么训出会规划的模型
光有架构不够。PLANNER 需要"查询 → 计划"的数据，EXECUTOR 需要"HTML + 计划步骤 → 动作"的数据，而这类数据在公开网上基本没有，人工标注又贵又慢。论文的流水线分三段解决，核心是从成功轨迹"反推"计划。
3.1 动作轨迹生成（Action Trajectory Generation）
借鉴 Alpaca / WebRL 的思路：从训练集随机抽种子查询，让 LLM 生成相似的新查询，先把"环境根本完成不了"的查询过滤掉，再用一个 demonstrator Agent 真去环境里跑，最后用结果监督奖励模型（ORM）筛出成功轨迹。这一步的产物是 EXECUTOR 的训练数据。
3.2 接地计划生成（Grounded Plan Generation）—— 关键一步
这里有个朴素方法会翻车：直接把用户查询丢给 Teacher LLM 让它写计划。问题是 Teacher LLM 既没见过真实网站、也没在网页任务上预训练，写出来的计划常常和真实操作对不上。
论文的解法是逆向工程：把 3.1 里那些成功轨迹喂给 Teacher LLM，让它从"一连串动作"反推"一份连贯的高层计划"，而且要求它把计划里的每一步，显式绑定到轨迹里对应的具体动作（比如"Step 1 搜索 Sagamore Hill"对应动作 [1,2]）。这就保证了计划是"接地"的——和真实执行能对上，既准确又可执行。
为了覆盖动态重规划和 CoT，他们还用类似方法额外造了两份数据：一份让 Teacher LLM 基于"原计划 + 已走轨迹"生成重规划样本；一份生成"先推理再出计划/动作"的 CoT 样本。
3.3 计划扩展与定向增强（Synthetic Plan Expansion）
轨迹生成受环境交互成本约束，一个成功轨迹平均 8 步，能给 EXECUTOR 供 8 个训练点，却只够 PLANNER 1 个计划——数据严重失衡。解法是用 Alpaca 式的 query-plan 对扩展：从已有合成计划里随机采样当种子，让 GPT-4o 生成结构一致、语义多样的新 query-plan 对。论文用这一招把计划数据扩到 1 万条额外样本，耗时不到一小时。
更进一步是定向增强：把模型跑一遍预留验证集，找出失败模式，用 LLM 把和这些失败相关的训练点挑出来当种子，再生成 5000 条针对性计划。这一步吃的就是"知道模型在哪栽跟头"的信息差。
❝实战经验：PLANNER 的数据量瓶颈比 EXECUTOR 更尖锐。论文的原话是 EXECUTOR 在数据量超过初始 1113 条后收益递减，瓶颈其实在"计划质量"。如果你自己也在训规划型 Agent，优先把预算花在"计划数据的多样性和针对性"上，而不是无脑堆执行轨迹。
四、实验结果：数字怎么读
WebArena-Lite 是 WebArena 的人工校验子集，165 个测试 case，覆盖 OpenStreetMap、Reddit、GitLab、CMS、OSS 五类网站，用"任务是否完整完成"的二值成功率衡量。论文把 PLANNER 的设计逐级叠加，EXECUTOR 也分了三档（基础未训 / 仅 WebArena-Lite 微调 / 再加 923 条合成轨迹），下表是第三档 EXECUTOR 下的核心 progression（数字均取自论文 Table 1）：
| 阶段 | WebArena-Lite 成功率 |
| 无 PLANNER（ReAct 基线） | 9.85% |
| 基础 PLANNER（未微调） | 14.21% |
| + PLANNER 微调 | 22.42% |
| + 合成轨迹增强 | 24.24% |
| + 计划扩展（1万） | 27.10% |
| + 定向增强（5千） | 29.63% |
| + 动态重规划 | 53.94% |
| + CoT（PLAN-AND-ACT 终版） | 57.58% |
几个我认为最该记住的读法：
第一，动态重规划是最大单点增益。 从 29.63% 一跃到 53.94%，单这一步涨了 10.31 个百分点，直接把上一任 SOTA（WebRL-3.1-70B 的 49.1%）甩开 4.84%。原因前面说过：很多任务要"看结果再决策"，静态计划把这类推理错误甩给了 EXECUTOR。
第二，好计划能救一个"没训练过"的 EXECUTOR。 即便 EXECUTOR 完全不微调，只给它一个高质量动态 PLANNER，成功率也能从 9.85% 涨到 **44.24%**（提升 34.39%）。这几乎是在证明：长程任务的天花板，主要卡在"规划"而不是"执行"。
第三，CoT 让小模型逼近大模型。 论文专门做了对照（Table 2）：
| 模型 | 是否 CoT | 成功率 |
| Llama-3.3-70B | 否 | 53.94% |
| Llama-3.1-8B | 是 | 53.33% |
| QWQ-32B | 是 | 54.88% |
| Llama-3.3-70B | 是 | 57.58% |
一个 8B 模型带上 CoT，成绩基本追平了没带 CoT 的 70B。这对落地太友好了——推理成本可以大幅下探。
第四，真实网页上也站得住。 WebVoyager 是真实动态网页基准（无训练数据），PLAN-AND-ACT 用 8B 模型做到 58.08%（已经超过 WebVoyager 自家 GPT-4-Turbo 的 57.1%），用 QWQ-32B 做到 **81.36%**，刷新文本态（text-only，不依赖截图/视觉）SOTA，把此前最强的 Agent-E（GPT-4-Turbo，73.1%）也压了下去。
❝踩坑提醒：WebVoyager 的 81.36% 是论文自报、且基于"文本态"设定（纯 HTML，不上视觉模型）。别把它和用截图的多模态 Agent 直接横比。另外这个数字里 32B 模型 + 合成数据管线贡献很大，复现时务必走通他们开源的 github.com/SqueezeAILab/plan-and-act，尤其 WebVoyager 那 1500 条 GPT-4o 轨迹 + QWQ-32B 标注的计划数据。
五、这套东西对我们自己搭 Agent 有什么用
抛开刷分，我更关心它给工程实践留下的几条可复用结论：
- 长程任务优先做"规划-执行"分离，而不是堆单模型。 这是架构层面的第一性原理。哪怕你不用论文的完整微调流程，先把"让一个模型专职出计划、另一个专职出动作"跑起来，往往就能缓解长任务掉线。
- 计划要"动态"且"接地"。 一次性静态计划 + 长任务 = 必然翻车；计划必须能随环境反馈更新，而且计划里的每一步最好能追溯到真实可执行动作，别写成漂浮的口号。
- 缺训练数据就从成功轨迹反推。 这是最省钱的冷启动办法：先有一个能跑通的 demonstrator（哪怕弱），用 ORM 筛成功轨迹，再让强模型把轨迹"翻译"成计划数据。比纯人工标注 scalable 太多。
- CoT 是性价比极高的增益。 如果你的执行端要上小模型，务必加 CoT，8B 追平 70B 不是梦话。
六、局限与未来
论文自己也老实说了两点：一是 §4.1 的轨迹生成依赖一个"能跑通任务"的 baseline 模型，对完全没有训练数据的环境（如 WebVoyager），得先有个基础模型去采轨迹；二是动态重规划每一步都调一次 PLANNER，开销和延迟都不小。未来方向包括让 EXECUTOR 自己判断"何时需要重规划"，以及引入多模态输入、RL 优化计划和记忆增强推理。
小结
PLAN-AND-ACT 给我的启发，不是某个具体模块多新颖，而是它把"长程 Agent 难在规划"这件事，用一条可扩展、可复现、且被数据验证的闭环讲明白了：双角色分离解决认知负载，动态重规划解决环境不确定性，合成数据流水线解决"没数据训不出好 PLANNER"的工程死结。最终结果——WebArena-Lite 57.58%、WebVoyager 文本态 81.36%——都是开源模型 + 监督微调拿到的，意味着这条路子对资源有限的团队也走得通。
如果你想自己跑，直接 clone 他们的仓库（github.com/SqueezeAILab/plan-and-act），HuggingFace 上已经有 plan-and-act-planner-70b 和 plan-and-act-actor-70b 两个微调好的权重可以上手。
