网页智能体既要定战略又要管细节，单模型扛不住，这是公认的结构性难题。Plan-and-Act 把职责拆成 Planner 与 Executor 两个 LLM， 再用「从成功轨迹反向标注计划 → 合成扩展 → 按失败定向补数据」三段流水线把规划能力练出来。 只做监督微调，不做 RL；最终 57.58% 来自每一步都重规划、再加 CoT 的 70B 模型。
主方法很朴素：Planner 读用户请求和 HTML，输出带「## Step N / Reasoning / Step」格式的高层计划；Executor 把当前那一步翻译成 do(action="Click", element="13") 这样的动作，并顺手清理冗余 HTML。动作执行后，Planner 每一步都重新规划，把新观察吸收进后面的计划——论文说这样就不需要显式记忆模块。
真正的贡献在数据侧。直接让教师模型凭用户请求「猜」计划，计划会偏离网站实际；作者改成给它看成功的行动轨迹，让它反向标注出计划，并要求把每个计划步骤映射到轨迹里的具体动作，计划因此「接地」。再以这些计划为种子，用 GPT-4o 一小时内生成 10,000 条新的查询-计划对；最后按验证集暴露的失败模式，再定向生成 5,000 条。
Executor 的收益很快见顶：把执行器训练从 1,113 条加到 2,036 条轨迹，ReAct 式执行器只从 36.36 涨到 36.97；真正拉开差距的是规划质量。但规划器只在 1,113 条数据上朴素微调反而回退，说明这个任务对数据量和多样性极其敏感。
先分清两种失败：模型根本没被训练过做网页规划，和把规划与执行压进同一个模型。
论文把规划难拆成三件事：把「帮我订一张去纽约的机票」拆成可执行步骤；任务一长就忘了做到哪、还剩什么；环境会变，计划得跟着改。三者之外还有一条最硬的约束——没有训练数据。LLM 预训练时没见过「给一个网站、给一个请求、输出一份计划和一串网页动作」这种格式的任务。
论文开篇用一组消融数字把这两种失败分开摆出来（Table 1，指标是 WebArena-Lite 成功率）：
完全零样本的 LLaMA-3.3-70B-Instruct 加 ReAct 提示，只有 9.85%。提示和 in-context 示例对简单任务有帮助，对 WebArena-Lite 这种非平凡查询基本无解。
同一个模型在 1,113 条 WebArena-Lite 训练数据上做完 ReAct 微调，能到 36.36%——说明能力不是学不会，只是没被教。
引用的先前工作（Sridhar et al. 2023；Yang et al. 2024a）认为，单模型同时做长程规划与逐步执行，容易丢失最终目标、行为不一致。
这一点论文用「零样本规划器 + 零样本执行器」的消融来间接说明：加上一个未训练、不接地的规划器，基础执行器能从 9.85% 升到 14.21%，但对已训练的执行器反而是负担。
还有一个反直觉的数字：执行器的数据加倍几乎没用。在没有 Planner 的 ReAct 设置下，执行器从 1,113 条轨迹扩到 2,036 条（再加 923 条合成轨迹），成功率只从 36.36% 到 36.97%，涨 0.61 个百分点。执行器越训越顺，天花板却卡在「它不知道整体该往哪走」。
所以问题的形状变了：不是「再做点提示工程」，而是「怎么在没有人工标注、也不需要沙箱的前提下，造出足够多的高质量计划数据」。这就引出后面两条已有的数据路线，以及论文的三段式流水线。
已有工作分两族：一族的规划靠闭源大模型逐层提示，一族的数据只有轨迹、没有计划。
AgentOccam 用「planning via generation」把计划塞进行动空间、树式规划；WebPilot 是比较重的多智能体系统；AdaPlanner 带 In-Plan / Out-of-Plan 两套 refiner 做重规划；ADaPT 在执行失败时递归分解任务。论文对它们的评价很直接：都是 prompting 方法，底座是 GPT-4o 这类闭源模型，靠提示叠出来的性能，没有让开源模型真正学会规划。
WebRL、DigiRL、AutoWebGLM、NNetNav 都能采到多样的轨迹。论文承认这些采集技术与自己互补、可以直接替换，但指出它们只产出轨迹、不产出计划；而且都依赖外部模拟器，每个步骤都要真的在环境里跑一遍网页动作。WebRL 还要 on-policy 自演化课程。路线 B 里 NNetNav 的思路最接近——它从交互里反向标注，但标出来的是用户指令，不是高层计划。
| 方案 | 规划 | 训练数据来源 | 底座 | 卡在哪 |
|---|---|---|---|---|
| ReAct 单模型 | 隐式 | 1,113 条训练轨迹 | LLaMA-3.3-70B | 数据加倍只 +0.61；36.97% 到顶 |
| AgentOccam / ADaPT / WebPilot | 显式，提示驱动 | 无（零样本） | GPT-4o / GPT-4-Turbo | 闭源提示；开源模型学不到 |
| WebRL | 隐式 + 自演化课程 | on-policy 轨迹 + ORM | Llama-3.1-70B | 依赖模拟器；只有轨迹没有计划 |
| Plan-and-Act | 显式，Planner 微调 | 轨迹反向标注 + 合成扩展 + 定向增强 | LLaMA-3.3-70B | 执行器仍是 WebArena-Lite 风格；见 07 |
还有一个不同的切面：WebRL 靠 RL 提升，论文引用 Rafailov et al. 2024、Furuta et al. 2024 指出这类方法对超参和奖励设计高度敏感、容易不稳定。Plan-and-Act 的姿态是反过来的——把难题全部搬进数据里，训练只剩监督微调。
运行时的机制只有这三件，真正的工程都在第四节的数据流水线。
以论文 Figure 2 的 GitHub 例子：用户输入 Follow the top contributor of this GitHub project。Planner 读初始 HTML，产出 ## Step 1 导航到 Contributors 页面、## Step 2 identify the top contributor and follow them。Executor 只做第一步：在 HTML 里找到 Contributors 链接，输出 do(action="Click", element="13")。执行完它做一次「垃圾回收」，丢掉冗余 HTML，再接下一步。
格式本身是约束而不是装饰：Reasoning 解释分组逻辑、给执行器战略上下文，Step 只给结果；提示明确要求把逻辑相关的动作聚成一步（把点击搜索框、输入、点搜索合成「Search for X」），并按「每个计划步骤可能对应多个底层动作」来设计。计划步骤数因此远少于动作数——论文说一条成功轨迹平均有 8 个步骤，而为执行器提供 8 个训练点、为规划器只提供一个计划。
静态计划的死角在 Figure 2 的后半段：初始计划不可能知道 top contributor 是谁，只能写「identify the top contributor」。点击 Contributors 后，HTML 里出现了 John Doe；Planner 读完这个状态和已有计划，把剩余计划改写成 ## Step 1 Follow "John Doe"。
计划在每一步被重写，所以「搜到了谁」「当前在第几页」这类信息自然沉淀在计划里。论文据此声称：不需要显式的记忆模块，也能应对长程任务里的记忆问题——因为记忆就寄存在 Planner 每步产出的计划中。
代价是每一步都要多调用一次 Planner，论文在 Limitations 里承认这可能慢、可能低效；改进方向是让 Executor 自己判断何时需要重规划，或让 Planner 把任务委派给子智能体。
Section 3.4 在 Planner 和 Executor 的输出前各加一段链式推理。附录 A.1 的 Planner 示例显示，正式微调后的输出里每个 Step 都带一句 Reasoning（例如先观察「当前在 OpenStreetMap，页面有搜索框和 directions 图标」）。CoT 的数据同样是合成出来的（4.2.2），而不是简单的提示词开关。效果见第六节：叠加 CoT 后 53.94% → 57.58%。
下面是 Appendix A.2.1 的真实任务与计划：用户要问「从 Carnegie Museum of Art 走到 CMU 的某个图书馆要走多久」。静态计划里第二步是看搜索结果、挑一个图书馆；可执行器按计划搜索 "Library at CMU"，页面返回 No results found。点下方按钮切换执行方式，看计划如何演化。
计划的步骤与重规划后的新计划取自论文 Appendix A.2.1 的原始输出；执行器动作与 HTML 反馈取自同一附录。静态模式里的「执行器不知所措」是对论文描述的模拟，不是逐字原文。
Section 4 全部是数据工程：每一段都回答「为什么不能更简单一点」。
沿用 Alpaca / Self-Instruct 的做法：从训练数据随机抽查询当种子，让 LLM 生成相似的新查询，再让 LLM 先筛掉网页智能体不可能完成的；然后交给演示智能体（actor）在环境里跑，得到轨迹；最后用 ORM 打分，只留成功轨迹。这条轨迹就是后面所有计划数据的原料。
最直接的做法——教师模型拿着用户请求直接生成分步计划——会失败。原因很具体：教师模型看不到网站，也没在这种任务上预训练过，生成的计划往往和网站的实际情况对不上。作者改用它擅长的 in-context 能力：把成功轨迹交给它，让它从动作序列「反向工程」出一份计划；并额外要求每个高层步骤都要说明对应轨迹里哪些底层动作，这就把计划和真实可执行序列绑在了一起。
同一套标注思路还用于两份派生数据：重规划数据（额外给出原计划和走到这一步的轨迹，§4.2.1）和 CoT 追溯数据（§4.2.2）。
成功轨迹来之不易——ORM 会筛掉大量不可接受的轨迹。更糟的是比例：一条成功轨迹平均约 8 个动作，对执行器是 8 个样本，对规划器只有 1 份计划。所以第三段做合成计划扩展：从已有查询-计划对随机抽种子，让教师模型生成结构一致、内容多样的新对。
论文给出的规模数字，前后口径略有差别，按原文照列：
5 个种子 → 10 个新数据点。10,000 条额外的查询-计划对，不到一小时完成。15,000 条合成训练样本，一小时内生成。5,000 条。Appendix A.8 的说明是「每个种子数据点再多生成一条」，而 A.7 的分类是为了找出与失败相关的训练点。大规模扩展提升了多样性，但它是盲目的。作者把模型跑在一个留出的验证集上，归纳出各网站上的失败模式，再用 LLM 对训练点分类（Appendix A.7 为每个网站准备了失败类别，例如 CMS 后台的失败类），把相关训练点当种子，定向再生成 5,000 条。这一步在 Table 1 里换来 4–5 个百分点。
Section 2 说论文的流水线可以在没有模拟器的情况下生成规划数据。Appendix A.6 的合成计划生成器提示显示了做法：每一条合成样本都由三部分组成——新的用户查询、从种子示例里选一个初始 HTML 状态（写示例编号）、对应的高层计划。也就是说，合成不凭空发明网页，而是围绕已有网站的 HTML 状态，重新组合「能在这些页面上做的事」。提示还要求：不要照抄示例，也不能生成网站上不可能完成的请求。
WebVoyager 没有训练数据，拿不到「种子轨迹」的现成来源。论文的做法是：用 text-only WebVoyager + GPT-4o 先采 1,500 条合成轨迹，再让 QWQ-32B 标注计划、CoT 推理，并生成 10k 条合成计划。这说明整条流水线可拆可换，也说明它依赖一个「能先把任务做成的底座」。这一点在 07 节作为边界展开。
Figure 3 的三行对应三段数据；训练时 Planner 和 Executor 各拿一份。
训练数据的三种来源在 Table 1 里被分开计：+ Finetuning（1,113 条 WebArena-Lite）、+ Synthetic Trajectories（再加 923 条 §4.1 轨迹）、+ Plan Expansion（再加 10,000 份计划）、+ Targeted Augmentation（再加 5,000 份）。第六节按这四级看涨幅。
数字全部来自 Table 1–4 与 Figure 4；切换执行器，看同一套规划数据对三类执行器的效果。
按 Table 1 第三列（+ Synthetic Traj. 执行器）读，台阶是这样的：
Base Executor 那一列最能说明规划本身的价值：执行器完全没微调，光靠更好的计划，就从 9.85% 到 29.63%（静态规划器）再到 44.24%（动态重规划），论文称后者相对最基础设置提升了 34.39%。
| 底座模型 | CoT | WebArena-Lite 成功率 | 说明 |
|---|---|---|---|
| Llama-3.3-70B | ✗ | 53.94 | Table 1 第 12 行 |
| Llama-3.1-8B | ✓ | 53.33 | 同一份数据，参数少近一个数量级 |
| QWQ-32B | ✓ | 54.88 | |
| Llama-3.3-70B | ✓ | 57.58 | Final Plan-and-Act |
Table 2。论文的解读是「8B + CoT 与 70B 不带 CoT 打平，说明 CoT 有多重要」——对长程规划，推理过程带来的收益可以与 9 倍参数相当。
Plan-and-Act 8B：58.08，超过所有开源模型；QWQ-32B：81.36，刷新 text-only SOTA。
同表里 GPT-4-Turbo 的 Wilbur 为 52.6，Agent-E 为 73.1。论文在结论里说「超过所有先前工作」——严格地说，Agent-E 是用截图等多模态输入的，text-only SOTA 的限定才成立。
Llama-70B 版本 45.7，与 GPT-4-Turbo 的 AgentOccam-Judge 持平；QWQ-32B 版本 48.15，超过所有列出的方法。
这是论文「performs better or on-par」的出处：在全量 WebArena 上，优势并不像 WebArena-Lite 那样悬殊。
| 网站 | 任务数 | 平均步数（成功） | 平均步数（失败） | 成功率 |
|---|---|---|---|---|
| Overall | 165 | 7.52 | 13.43 | 53.9 |
| GitLab | 30 | 5.98 | 20.35 | 53.3 |
| Map（OpenStreetMap） | 26 | 10.37 | 9.10 | 46.2 |
| Shopping Admin（CMS） | 35 | 8.65 | 14.41 | 48.6 |
| Shopping（OSS） | 45 | 7.11 | 10.66 | 55.6 |
| 19 | 8.31 | 9.92 | 84.2 | |
| Multiple Websites | 10 | 6.00 | 17.83 | 30.0 |
Figure 4。失败轨迹明显更长（13.43 vs 7.52 步），唯一例外是 Map：失败的平均步数（9.10）比成功的（10.37）更短——在 OpenStreetMap 上，模型是过早放弃或过早给出错误答案，而不是绕远路。GitLab 则相反，失败轨迹平均 20.35 步，像是一直在页面里乱转。Reddit 最简单（84.2%），Multi-site（30.0%）和 Map（46.2%）是短板。注意 Figure 4 的 Overall 53.9 是四舍五入后的展示值，Table 1 对应设置是 53.94。
论文自己承认两条边界，另外三条可以从数据与消融里读出来。
§4.1 采轨迹依赖演示智能体；§4.2 反向标注依赖成功轨迹。在没有任何训练数据的领域（WebVoyager），只得先借 GPT-4o 的 text-only 版本采 1,500 条轨迹。论文在 Limitations 里明说：这限制了方法进入全新领域的能力。这一点也写在结论的规模数字里——WebVoyager 的合成计划只有 10k，而在 WebArena-Lite 上是 10k + 5k。
每个动作后 Planner 都要重读 HTML、生成新计划，推理调用翻倍。论文承认可能低效，建议未来让 Executor 自己决定何时重规划，或让 Planner 委派子任务——但都只是方向，没有实验。用户白皮书里 57.58% 的轨迹平均也就 11.12 步（Figure 4），成本仍可接受；真实场景里更长的任务，代价会线性增长。
论文刻意保持「标准 WebArena-Lite 风格」的执行器，只提升规划。执行器基线 36.97% 的瓶颈里，有一部分是执行能力本身——例如失败轨迹里在 GitLab 绕了 20 步，不一定是计划的问题。结论里提到的改进方向之一就是给执行器加 CoT。也就是说，57.58% 不是「这套框架的上限」，而只是「规划部分修好时」的成绩。
同样 1,113 条规划数据，朴素微调让执行器从 36.97% 掉到 20.60%。要拿到收益，得配上 10k + 5k 的合成计划。这对中小团队意味着：方法可以复现，但成本主要在数据生成与筛选，不在训练算法。
全部实验都在 WebArena / WebArena-Lite / WebVoyager 上。框架本身面向「各种结构化决策环境」，但没有跨域实验——代码编辑、桌面软件、具身任务都未验证。论文的 future work 把多模态输入、基于 RL 的计划优化、记忆增强推理列为方向，说明三者都还没做。
一句话：Plan-and-Act 把「长程任务」这个抽象难题，拆成了「规划器数据要多、要好、要贴失败」这个具体的工程问题。它赢在数据，而不是在算法复杂度——整套训练只是 SFT。