> ❝
>
> 长程 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 的规划难点拆成三句话，我觉得概括得很准：

1. **拆不开**：高层目标（"帮我订去纽约的机票"）很难被模型自己落成一串具体动作（"打开航司网站 → 填出发地 → 选日期"）。
2. **记不住**：任务越长，越容易丢失"已经做了什么、还差什么"的全局状态。
3. **改不了**：真实环境是动态的，搜索没结果、列表顺序变了，静态计划就直接傻眼。

作者先用一个残酷的基线实验把问题摆到台面上：在 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）。

![img](https://developer.qcloudimg.com/http-save/yehe-5687454/fbc1ca3ecf713c15334498dd7715ef28.png)

### **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 模块就能缓解。

![img](https://developer.qcloudimg.com/http-save/yehe-5687454/84b912267f14b041ee225e2476dea6e6.png)

### **2.4 Chain-of-Thought：两个角色都先推理**

PLANNER 和 EXECUTOR 默认是直接出结果。论文补了一层 CoT：生成计划/动作之前，先让模型产出一段中间推理。这一步的增益后面用数据说话——非常重要。

## **三、合成数据：没有规划数据，怎么训出会规划的模型**

光有架构不够。PLANNER 需要"查询 → 计划"的数据，EXECUTOR 需要"HTML + 计划步骤 → 动作"的数据，而这类数据在公开网上基本没有，人工标注又贵又慢。论文的流水线分三段解决，核心是**从成功轨迹"反推"计划**。

![img](https://developer.qcloudimg.com/http-save/yehe-5687454/e1c04e81048df694691c105e7982929e.png)

### **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 有什么用**

抛开刷分，我更关心它给工程实践留下的几条可复用结论：

1. **长程任务优先做"规划-执行"分离，而不是堆单模型。** 这是架构层面的第一性原理。哪怕你不用论文的完整微调流程，先把"让一个模型专职出计划、另一个专职出动作"跑起来，往往就能缓解长任务掉线。
2. **计划要"动态"且"接地"。** 一次性静态计划 + 长任务 = 必然翻车；计划必须能随环境反馈更新，而且计划里的每一步最好能追溯到真实可执行动作，别写成漂浮的口号。
3. **缺训练数据就从成功轨迹反推。** 这是最省钱的冷启动办法：先有一个能跑通的 demonstrator（哪怕弱），用 ORM 筛成功轨迹，再让强模型把轨迹"翻译"成计划数据。比纯人工标注 scalable 太多。
4. **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` 两个微调好的权重可以上手。

长程 Agent 翻车，往往不是模型不够聪明，而是被"规划"和"执行"两件事同时压垮了。

长程任务 Agent 为什么总半途而废？PLAN-AND-ACT 用"先规划后动手"给出 SOTA 答案

ICML 2025论文PLAN-AND-ACT提出“规划-执行”双角色分离框架，解决长程Agent因兼顾策略与操作而崩溃的问题。通过动态重规划、接地合成数据与CoT推理，在WebArena-Lite达57.58%新SOTA，WebVoyager文本态达81.36%，代码与70B模型已开源。

人工智能

算法

架构设计

PLAN-AND-ACT框架通过规划与执行分离、动态重规划及合成数据流水线，将WebArena-Lite成功率从9.85%提升至57.58%新SOTA，WebVoyager文本任务达81.36%。开源70B模型与代码，为长程Agent提供可复现的高效解决方案。

数据流

智能体

GitHub

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

长程任务 Agent 为什么总半途而废？PLAN-AND-ACT 用"先规划后动手"给出 SOTA 答案-腾讯云开发者社区-腾讯云

长程任务 Agent 为什么总半途而废？PLAN-AND-ACT 用"先规划后动手"给出 SOTA 答案

长程任务 Agent 为什么总半途而废？PLAN-AND-ACT 用"先规划后动手"给出 SOTA 答案

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐