1. 从“拍脑袋”到“结构化”：为什么LLM网页代理的规划方式至关重要
最近在折腾大语言模型（LLM）驱动的网页自动化任务时，我遇到了一个挺有意思的瓶颈。我们团队当时在做一个模拟电商比价的自动化脚本，让LLM去访问几个主流购物网站，搜索同一款商品，然后汇总价格信息。最初的思路很简单：直接把任务描述扔给LLM，比如“去A、B、C三个网站，分别搜索‘无线蓝牙耳机’，找到价格最低的那款，把型号和价格记下来”。听起来很直接，对吧？但实际跑起来，效果却是一团糟。模型要么在第一个网站就卡在登录弹窗里出不来，要么在比价时把不同规格的商品混为一谈，甚至有时会陷入点击循环，在同一个页面的相似链接上反复横跳。
这让我开始反思：问题可能不在于模型本身的能力，而在于我们让它“思考”任务的方式。我们只是给了它一个最终目标，却没有为它规划出一条清晰、可执行的路径。这就好比让一个新手司机从北京开车到上海，只给了一个目的地，却没给导航地图，也没告诉他路上可能会遇到收费站、服务区或者交通管制。他大概率会迷路，或者做出一些令人费解的决定。
这正是标题《Does The Way You Plan Matter? An Empirical Study of Planning Representations for LLM Web Agents》所直指的核心问题：规划表示（Planning Representations）的方式，到底重不重要？对于LLM网页代理（Web Agents）——即那些能够理解自然语言指令，并自动在浏览器中执行操作（如点击、输入、导航）的AI程序——来说，如何将复杂的任务分解并表示为模型可以理解和执行的步骤，是决定其成败的关键。这篇论文通过实证研究，对比了不同的规划表示方法，为我们提供了宝贵的经验。
简单来说，LLM网页代理的工作流可以概括为“感知-思考-行动”循环。它先“看到”网页的HTML结构（感知），然后根据任务目标“思考”下一步该做什么（规划），最后通过模拟鼠标键盘事件来执行点击或输入等“行动”。而“规划表示”，就是“思考”环节的具体产物，它定义了任务被拆解和描述的形式。不同的表示方法，就像是给司机不同的导航指令：是只给一系列路口转向列表（线性步骤），还是给一张标注了关键地标和备选路线的高清地图（结构化蓝图）？这其中的差异，会直接影响到代理的执行效率、鲁棒性和泛化能力。
2. 规划表示的“兵器谱”：线性指令、思维链与结构化蓝图
在深入论文的实证结果之前，我们有必要先厘清目前主流的几种规划表示方法。理解它们的优缺点，就像了解不同工具的特性，能帮助我们在具体场景中做出更合适的选择。
2.1 基础款：线性指令序列（Linear Instruction Sequence）
这是最直观、最朴素的方式。规划器（可能是另一个LLM，也可能是一套规则）将复杂任务分解成一个按顺序执行的指令列表。例如，对于“在知乎搜索LLM相关文章并点赞第一篇”这个任务，规划可能如下：
- 导航到
zhihu.com。 - 在搜索框输入“LLM”。
- 点击搜索按钮。
- 等待结果页面加载。
- 找到第一个搜索结果条目。
- 点击该条目下的“赞同”按钮。
优点：简单明了，易于生成，也易于让执行代理理解。对于步骤明确、路径单一的任务，这种方式非常高效。缺点：极其脆弱。它假设世界是确定性的，每一步都会按预期发展。但网页环境充满不确定性：页面加载可能慢几秒（导致第4步之后元素还没出现）；搜索结果的第一个条目可能是个广告（导致第5步定位错误）；“赞同”按钮可能需要登录后才显示（导致第6步失败）。一旦某一步出错，整个线性链条就断裂了，代理通常会不知所措或开始执行无意义的操作。
2.2 进阶款：思维链与自省（Chain-of-Thought, ReAct）
为了增强模型的推理能力，研究者引入了思维链（CoT）以及结合推理与行动的ReAct范式。在这种表示下，规划不再是冰冷的指令列表，而是夹杂了推理过程的“内心独白”。例如：
- 思考：我需要先访问知乎首页。当前页面是空白，我应该输入网址。
- 行动：导航到
zhihu.com。 - 观察：页面加载成功，顶部有搜索框。
- 思考：我的目标是搜索“LLM”。搜索框的HTML ID可能是“SearchField”。我将输入关键词。
- 行动：在元素
#SearchField中输入“LLM”。 - 思考：输入完成后，需要触发搜索。通常有一个搜索按钮或按回车键。我先尝试找按钮。
- 观察：发现一个
<button type=”submit”>元素。 - 行动：点击该按钮。
优点：极大地提升了代理在复杂、未知环境中的适应性和鲁棒性。通过“思考”步骤，代理可以解释观察到的内容、评估当前状态、并规划下一步行动，从而处理一些意外情况。ReAct范式（推理+行动）已成为复杂代理任务的事实标准。缺点：1.效率较低：每一步都需要生成推理文本，增加了计算开销和响应时间。2.可能陷入“空想”：模型有时会过度推理，在多个可行行动间犹豫不决，或者陷入循环思考而不采取实际行动。3.对提示工程敏感：推理过程的质量高度依赖于给模型的提示（Prompt）设计。
2.3 专业款：结构化程序与蓝图（Structured Programs, Blueprint）
这是目前学术界和工业界探索的前沿方向，旨在结合前两者的优点。规划被表示成一种结构化的形式，比如类编程的DSL（领域特定语言）、流程图或层级任务网络（HTN）。以蓝图为例，它可能不是一个线性的步骤列表，而是一个包含条件分支、循环和错误处理逻辑的“程序”。
# 伪代码蓝图示例 def task_search_zhihu_and_like(keyword): open_url(“zhihu.com”) element_search = wait_for_element(“#SearchField”, timeout=10s) if element_search: type_text(element_search, keyword) click(element(‘button[type=”submit”]’)) # 等待结果并处理可能的登录弹窗 try: first_result = wait_for_element(“.List-item:first-child”, timeout=15s) like_button = find_element_within(first_result, “button[aria-label*=’赞同’]”) if like_button and like_button.is_visible(): click(like_button) return “Success” else: # 可能需要滚动或处理登录状态 return handle_login_or_scroll(first_result) except TimeoutError: return “Search results failed to load” else: return “Search box not found”优点：1.鲁棒性强：明确包含了错误处理和条件逻辑，能更好地应对环境变化。2.可复用性高：像函数一样，好的蓝图可以在类似任务中复用或微调。3.易于验证和调试：结构化的表示让人类更容易理解代理的意图，并在失败时定位问题。缺点：1.生成难度大：让LLM直接输出复杂、语法正确的结构化程序非常困难，通常需要额外的训练或约束解码。2.灵活性受限：过于僵化的结构可能无法应对极其开放或新颖的任务。
3. 实证研究的启示：PlanAhead与WebArena上的性能对决
回到我们讨论的这篇论文，它的核心贡献就在于通过严谨的实验，在标准的测试环境（如WebArena）中，量化比较了不同规划表示方法对LLM网页代理性能的影响。WebArena是一个包含多个真实网站（如电商、论坛、管理后台）镜像的仿真环境，提供了大量覆盖导航、表单填写、信息检索等场景的测试任务。
论文中重点对比了两种高阶策略：
- 标准ReAct：即上文提到的交互式推理-行动循环。
- PlanAhead（或类似的事前规划策略）：这种策略要求代理在开始行动之前，先根据任务描述和对网站的大致了解（如站点地图、常见组件），生成一个初步的、可能包含多个步骤和分支的“行动计划”或“蓝图”。然后，在执行过程中，根据实际观察对这个计划进行微调和修正。
实验结果表明，在WebArena这类复杂、长视野的任务上，采用PlanAhead这类结构化、前瞻性规划表示的代理，其任务完成成功率显著高于标准的ReAct代理。原因可以归结为以下几点：
3.1 减少短视决策标准ReAct是典型的“走一步看一步”。在面对需要多步操作才能到达目标的任务时（例如，“将购物车中第三件商品移入收藏夹，然后清空购物车”），它很容易在中期步骤迷失最终目标。而PlanAhead在开始时就勾勒出了“先找到购物车列表->定位第三项->点击移入收藏夹->返回购物车主页->点击清空”的整体脉络，使得每一步行动都服务于更大的蓝图，避免了局部最优但偏离全局的决策。
3.2 更好地处理延迟与异步加载现代网页大量使用JavaScript进行异步加载。一个点击操作可能不会立即跳转页面，而是触发一个动态加载数据的模块。标准ReAct代理在点击后，可能会因为页面主体HTML没变而误认为操作失败，或者过早执行下一步导致错误。PlanAhead蓝图则可以包含明确的等待条件（如“等待元素.product-list出现”），从而更稳健地处理这种异步性。
3.3 预置常识与约束在生成初步计划时，模型可以融入一些关于网站的常识性约束。例如，在规划“在论坛发帖”任务时，计划中可以预先包含“发帖前必须登录”的检查点。这避免了代理在填写完长篇帖子内容后，点击提交时才尴尬地发现需要登录，从而导致所有输入内容丢失的悲剧。
一个来自我们项目的具体教训：在我们早期的比价任务中，代理经常因为在A网站搜索后，没有“清理”搜索框，就直接在浏览器地址栏输入B网站的网址，导致B网站的搜索框里残留着A网站的关键词，引发混乱。如果我们采用了PlanAhead表示，在规划阶段就可以明确加入“在导航到新网站前，确保地址栏URL已更新，或当前页面无残留输入”这样的步骤，从而避免这类低级错误。
4. 实战：为你的LLM网页代理设计有效的规划策略
理解了理论，关键在于实践。如何为你自己的LLM网页代理项目选择和设计规划表示呢？以下是我从多次试错中总结出的一个可操作框架。
4.1 任务分析与规划器选型
首先，对你的任务进行三维评估：
- 确定性：任务步骤和网页状态变化是否高度可预测？（例如，固定的后台管理流程确定性高，而探索性信息搜集确定性低）。
- 复杂度：任务需要多少步操作？是否涉及条件分支（如果...那么...）或循环（直到...为止）？
- 环境稳定性：目标网站的结构是否频繁变动？页面加载是否稳定？
根据评估结果，参考以下选型指南：
- 简单、确定、线性的任务：线性指令序列可能就足够了。例如，定期从某个固定格式的页面抓取数据。你可以用简单的模板生成指令，又快又好。
- 中等复杂度、需要一定适应性的任务：标准ReAct是安全的起点。它为大多数信息检索、表单填写任务提供了良好的平衡。重点投资在编写高质量的提示（Prompt）上，引导模型进行有效推理。
- 复杂、长序列、容错性要求高的任务：优先考虑结构化蓝图（PlanAhead）。例如，跨多个页面的数据聚合、需要处理多种弹窗和异常状态的自动化流程。
4.2 实施PlanAhead策略的关键组件
如果你决定采用PlanAhead，你需要构建以下组件：
1. 高层规划器（High-level Planner）这是一个LLM，它的输入是：任务描述 + 网站概览（可选的站点地图、关键页面URL列表）。它的输出是一个初步的、高层次行动计划。这个计划不必是完美的代码，可以是自然语言描述的结构化列表，包含关键步骤和决策点。
提示：给规划器提供一些好的规划示例（Few-shot Learning）能极大提升效果。示例应展示如何将模糊任务分解为具体、可验证的子目标。
2. 蓝图编译器/解释器（Blueprint Compiler/Interpreter）这个组件负责将高层规划器输出的自然语言计划，转化为代理可执行的具体操作序列或带条件的DSL。这一步可以基于规则，也可以再用一个LLM来完成。关键在于，输出的蓝图必须能明确对应到低级的浏览器操作（点击、输入、滚动）和状态检查（元素是否存在、文本是否匹配）。
3. 动态调整机制（Dynamic Adjustment）计划赶不上变化。代理在执行蓝图时，必须有一个监控和调整机制。当遇到蓝图未预料到的情况（例如，弹出一个新的认证方式），代理应能暂停执行，将当前困境（观察到的状态与预期不符）反馈给一个“调整器”（可以是同一个或另一个LLM），获得一个局部的补救计划或对整个蓝图的修订，然后继续执行。
4.3 避坑指南：规划表示实践中常见的“坑”
坑1：过度规划（Over-planning）让模型在行动前规划得过于详细，甚至试图预测每一个像素的变化，这会导致规划阶段耗时极长，且生成的计划可能因为过于僵化而无法执行。
对策：规划应停留在“战略”层面，而非“战术”层面。规划应定义“做什么”（Go to the checkout page）和“达到什么状态”（Until the cart total is displayed），而不是“具体怎么做”（Click the
<div>with id “cart-icon”）。具体操作留给低层的执行代理根据实时页面状态来决定。
坑2：规划与执行的语义鸿沟规划器使用的词汇和执行器理解的网页元素属性可能不一致。例如，规划说“点击登录按钮”，但执行器需要定位<button id=”submit”>或<a class=”btn-login”>。如果规划器不知道按钮的具体标识，这个计划就无法直接执行。
对策：建立共享的“词汇表”或“元素库”。在规划阶段，可以引入对网站常见UI组件的抽象描述（如“主导航栏”、“搜索框”、“提交按钮”），并在编译阶段将这些抽象映射到当前页面具体的CSS选择器或XPath。更好的方式是让规划器也具备一定的元素定位能力，或者在提示中提供页面常见的HTML模式。
坑3：忽略时间与状态管理蓝图里很少有对时间流逝和并发状态的显式管理。例如，“等待AJAX加载完成”是一个时间相关操作，“在标签页1保持登录状态的同时，在标签页2进行搜索”涉及状态管理。
对策：在蓝图DSL中设计显式的原语。例如，
wait_for(condition, timeout=10)，open_new_tab(url)，switch_to_tab(tab_id)。同时，执行引擎需要维护一个全局状态（如cookies、localStorage），确保跨步骤、跨页面的状态一致性。
5. 超越规划：工具调用、记忆与多模态感知的协同
一个强大的LLM网页代理，规划表示只是其大脑的“决策逻辑”部分。要让它真正可靠，还需要与其他模块紧密协同。
5.1 规划与工具调用（Tool Use）的结合现代LLM代理框架（如LangChain, AutoGPT）普遍支持工具调用。我们可以将复杂的浏览器操作封装成工具，例如search_on_page(keyword),extract_table_data(),handle_modal_dialog(action)。规划器的输出，可以部分转化为对这些高级工具的调用序列，而不是底层的DOM操作。这提升了规划的抽象层级和复用性。例如，规划步骤“从产品列表页提取所有价格”，可以直接对应调用extract_prices()工具，由该工具内部处理具体的元素定位和解析逻辑。
5.2 利用记忆（Memory）优化规划代理的短期记忆（对话历史）和长期记忆（向量数据库存储的过去经验）能为规划提供关键上下文。
- 避免重复错误：如果代理上次在某网站因为某个特定按钮的定位器失效而失败，这次规划时，长期记忆可以提醒它尝试备用方案。
- 加速规划：对于重复性任务，代理可以直接从记忆中检索过去成功的完整规划蓝图，稍作修改即可使用，无需每次都从头生成。
- 状态跟踪：在长任务中，短期记忆可以帮助规划器记住已经完成了哪些子目标，当前处于哪个阶段，从而做出正确的后续决策。
5.3 融入多模态感知纯文本的HTML（或简化后的DOM）表示丢失了大量视觉布局信息。一个“购买”按钮在视觉上可能非常醒目，但在HTML中可能只是一个普通的<span>标签。最新的研究方向是让代理也能“看到”屏幕截图或辅助的无障碍树。 更先进的规划器可以结合视觉信息：例如，规划步骤“点击页面中央最大的那个蓝色按钮”，这纯粹是基于视觉的描述。执行时，需要多模态模型（如GPT-4V）来解析截图，定位该按钮，并将其映射回DOM坐标进行操作。这种视觉-文本联合规划，对于处理动态生成、结构复杂的现代网页至关重要。
在我最近的一个项目中，我们尝试将简单的PlanAhead策略与工具调用结合。我们为代理定义了一套工具，包括navigate(url),find_and_click(text_pattern),fill_form(field_mapping)等。规划器首先生成一个工具调用序列的草图。执行时，代理不仅按序列调用工具，还会根据工具的返回结果（成功/失败及原因）动态调整后续规划。例如，如果find_and_click(“Submit”)失败并返回“找到多个’Submit’按钮”，代理会触发一个子规划，利用额外的上下文（如表单标题）来精确定位正确的按钮。这种“规划-执行-观察-再规划”的闭环，显著提升了在真实杂乱网站上的成功率。
最终，关于“规划方式是否重要”这个问题，实证研究和实战经验都给出了响亮的肯定答案。它不仅是重要的，而且是构建高效、鲁棒LLM网页代理的核心杠杆点。从线性的指令列表，到包含推理的思维链，再到前瞻性的结构化蓝图，规划表示的演进反映了我们让AI更可靠地与现实世界复杂系统交互的不懈努力。选择合适的规划表示，本质上是在“代理的自主性”与“任务的确定性”之间寻找最佳平衡点。没有一种方法放之四海而皆准，但理解它们的原理和适用场景，无疑能让你在设计和调试自己的网页代理时，少走很多弯路。
)
