企业官网建设流程全解析

1. 项目概述：从一次失败的网页自动化任务说起

如果你尝试过用大语言模型（LLM）来驱动一个所谓的“智能体”（Agent）去自动完成网页上的任务，比如“帮我订一张下周五从北京到上海的机票，选靠窗座位”，结果很可能让你哭笑不得。它可能成功打开了订票网站，输入了城市，却在日期选择器前卡住，或者反复点击“搜索”按钮而不进行后续筛选。作为一名长期混迹于AI应用开发一线的从业者，我见过太多这样的案例：一个被寄予厚望的LLM智能体，在演示时表现惊艳，一旦投入真实、复杂的网页环境，其失败率之高往往令人沮丧。这背后绝不仅仅是“模型不够聪明”那么简单。

最近，一篇题为《Why Do LLM-based Web Agents Fail? A Hierarchical Planning Perspective》的论文精准地戳中了这个痛点。它没有停留在泛泛而谈的“幻觉”或“上下文长度”问题，而是从一个更根本的角度——分层规划——来系统性地诊断失败根源。简单来说，它认为当前基于LLM的网页智能体，缺乏像人类一样将复杂任务层层分解、并动态管理子任务状态的能力。这就像让一个没有项目管理经验的新手，直接去负责一个跨部门的大型工程，他可能会淹没在无数细节中，忘记最终目标，或者在错误的环节上浪费大量时间。本文将结合我自身的实操经验，深入拆解这一视角，并探讨我们如何借鉴经典AI规划（如PDDL）的思想，为LLM智能体构建一个更健壮、更可靠的“大脑”。

2. 核心困境解析：LLM网页智能体为何“步履维艰”？

在深入分层规划之前，我们必须先厘清LLM网页智能体面临的核心挑战。这些挑战并非孤立存在，而是相互交织，共同导致了智能体在复杂网页环境中的脆弱性。

2.1 网页环境的复杂性与不确定性

网页环境对于智能体而言，是一个高维、动态且充满噪声的“世界”。与棋盘游戏或受限的API环境不同，网页具有几个显著特点：

• 状态空间巨大且连续：一个网页的DOM树可能包含成千上万个节点，每个节点有数十个属性（如标签、类名、ID、文本、位置）。智能体感知到的“状态”是这个庞大HTML的一个子集或渲染后的视觉快照，信息高度冗余且嘈杂。
• 动作空间复杂且粒度不一：智能体可执行的动作包括点击、输入文本、滚动、悬停等。然而，同一个“点击”动作，其目标可能是一个带有明确ID的按钮，也可能是一个仅通过复杂CSS选择器才能定位的图标。动作的粒度问题也很突出：是应该先点击“日期选择器”，再点击具体日期，还是应该直接向输入框输入“2024-06-15”？LLM往往缺乏对这种粒度差异的把握。
• 动态加载与延迟：现代网页大量使用AJAX和前端框架，内容异步加载。智能体点击一个按钮后，网页状态不会立刻稳定，可能需要等待数秒新的内容才会出现。LLM基于静态快照做决策，极易在内容加载完成前发出下一个错误指令。
• 布局的多样性与对抗性设计：网页布局千变万化，还有各种弹窗、验证码、广告等干扰元素。一些网站甚至会故意改变元素ID或类名来防止自动化，这对依赖HTML语义的智能体是巨大挑战。

在我的一个电商比价项目里，智能体需要从多个网站抓取同一商品的价格。我们最初让LLM直接解析HTML并提取价格，失败率高达40%。失败原因五花八门：有的网站价格被拆分成多个<span>标签，有的用背景图显示价格，有的则在商品加入购物车后才显示最终价。这充分说明，让LLM直接处理原始网页状态，如同让一个人通过显微镜观察森林来规划穿越路线，极易迷失在细节中。

2.2 LLM作为规划器的固有缺陷

LLM本质是一个基于概率的序列预测模型，它在规划能力上存在结构性短板：

• 缺乏显式的状态表示与推理：经典智能体规划（如基于PDDL）明确区分“状态”、“动作”和“目标”。规划器会在一个抽象的状态空间中进行前向或反向搜索，评估动作效果。而LLM是将整个任务历史（观察、动作、结果）作为文本序列来建模。它隐式地学习状态变化，但无法显式地维护和推理一个清晰的世界模型。当任务步骤变长，它很容易“忘记”之前某个动作已经改变了某个关键状态。
• 长程依赖与上下文遗忘：尽管上下文窗口在不断增大，但LLM对于长序列中早期信息的注意力会衰减。在一个多步骤的网页任务中（例如：登录 -> 搜索商品 -> 筛选 -> 查看详情 -> 加入购物车），模型在规划第10步时，可能已经模糊了第2步设定的筛选条件。它缺乏一个“工作内存”来持续跟踪核心任务参数。
• 探索与利用的平衡失调：面对一个未知网页，智能体需要探索（尝试不同操作以理解功能）和利用（使用已知操作达成目标）。LLM倾向于生成“最可能”的下一个动作，这通常是基于训练数据中的常见模式，而非针对当前特定环境的最优探索策略。这导致它在遇到新颖的UI设计时容易陷入死胡同。

一个典型的例子是填写一个多页表单。LLM智能体可能完美地填完第一页并点击“下一步”，但当第二页出现一个依赖于第一页内容的动态字段时，它无法将“第一页的选择”作为一个明确的状态变量来指导第二页的填写，导致动作失败。

2.3 当前范式的局限性：直接映射与简单提示工程

目前大多数LLM网页智能体采用相对简单的范式：将当前网页的HTML或截图与任务指令一起输入给LLM，让LLM直接输出下一个动作（如CLICK [id=“submitBtn”]）。这本质上是将LLM作为一个从“状态-指令”到“动作”的端到端映射器。 这种范式的局限性显而易见：

1. 反应式而非前瞻性：智能体是“走一步看一步”，没有整体任务蓝图。它无法预见到“点击A会导致弹窗B，而关闭B需要C操作”，因此无法提前规划应对策略。
2. 错误累积与无恢复能力：一旦某个动作执行失败（如点击了一个无效元素），后续的所有动作都建立在错误的状态假设上，整个任务链会迅速崩溃。智能体通常没有内置的“错误检测与恢复”机制。
3. 提示工程的天花板：通过精心设计提示词（如“请逐步思考”），可以在简单任务上提升表现，但无法从根本上解决上述的结构性问题。提示词无法赋予LLM真正的状态管理和分层分解能力。

3. 分层规划：一种来自经典AI的救赎思路

论文提出的“分层规划”视角，正是为了应对上述挑战。它并非全新概念，在经典AI规划领域（尤其是PDDL规划中）已有成熟应用。其核心思想是：将复杂的顶层任务分解为多个层次的子任务，每个子任务又可以进一步分解，形成一棵任务树。高层规划关注“做什么”（What），底层规划/执行关注“如何做”（How）。

3.1 分层规划的核心组件

借鉴PDDL的思想，我们可以为LLM网页智能体构想一个分层规划框架，它包含以下几个关键组件：

• 高层领域模型：这是一个对网页功能域的抽象描述，不涉及具体DOM细节。例如，在电商领域，高层动作可能是SearchProduct(keyword),FilterBy(condition),AddToCart()。高层状态可能是CartContains(item)=True。这个模型由人工定义或通过少量示例让LLM总结得出。
• 分层任务网络：顶层任务（如“购买咖啡机”）被分解为一系列高层动作序列。每个高层动作（如FilterBy(price<500)）本身又是一个子任务，需要被进一步分解为一系列具体的、可执行的底层动作（如CLICK [data-testid="price-filter"],INPUT [id="maxPrice"] “500”,CLICK [id=“apply-filter”]）。
• 状态抽象与映射：系统需要维护两种状态表示：1)抽象状态：用于高层规划，如“用户已登录”、“搜索已完成”、“商品已在购物车”。2)具体状态：即当前网页的DOM或视觉表征。关键是要有一个映射机制，能从具体状态中识别出抽象状态的当前值（例如，通过检测页面是否存在“登录成功提示”元素来判断isLoggedIn=True）。

3.2 分层规划如何解决LLM智能体的痛点

引入分层规划后，LLM的角色和任务被重新定义，许多原有问题得到了缓解：

• 解决长程依赖：高层规划器（可以是另一个LLM或符号规划器）只在高抽象层面工作，它输出的高层动作序列较短且目标明确。底层执行器（LLM）只需关注如何实现当前这一个高层动作，上下文压力大减。高层规划器像一个项目经理，确保大方向正确；底层执行器像工程师，专注解决具体技术问题。
• 提升鲁棒性与可恢复性：每个高层动作可以被视为一个“子目标”。如果底层执行失败（例如，点击过滤按钮无响应），系统可以触发一个恢复策略：重试、尝试替代方案（如通过搜索框输入价格范围）、甚至向上层汇报失败并请求重新规划。这比端到端模型整个链条崩溃要好得多。
• 促进探索与学习：高层领域模型可以随着经验积累而扩展。当智能体遇到一个新UI模式并成功实现了FilterBy动作后，这个新的底层操作序列可以被记录并关联到FilterBy这个高层动作上，丰富其实现库。这相当于让智能体具备了积累“技能”的能力。
• 改善可解释性与可调试性：整个执行过程变成了一棵可视化的任务树。开发者可以清晰地看到任务在哪一层、哪一个子目标上失败，是因为高层规划不合理，还是底层执行遇阻？这极大降低了调试成本。

4. 构建一个分层规划网页智能体的实操框架

理论很美好，但如何落地？下面我将结合一个具体的例子——“在订票网站购买指定日期机票”——来勾勒一个可行的分层规划智能体实现框架。请注意，以下部分结合了论文思想与我的工程实践。

4.1 第一步：定义高层领域模型与动作库

这是最需要领域知识的一步。我们需要为“在线订票”这个领域定义抽象的动作和状态谓词。

高层状态谓词（部分示例）：

• OnPage(page_name): 当前位于哪个页面（如首页、搜索页、支付页）。
• SearchCompleted(departure, arrival, date): 已成功执行一次给定参数的搜索。
• FlightSelected(flight_id): 已选中某个航班。
• PassengerInfoFilled(): 乘客信息已填写。
• PaymentCompleted(): 支付已完成。

高层动作（部分示例）：

• NavigateToSearch(): 动作前提：OnPage(首页)；动作效果：OnPage(搜索页)。
• PerformSearch(dep, arr, date): 前提：OnPage(搜索页)；效果：SearchCompleted(dep, arr, date)。
• SelectFlight(flight_id): 前提：SearchCompleted(...)；效果：FlightSelected(flight_id),OnPage(详情页)。
• FillPassengerInfo(info): 前提：OnPage(详情页)；效果：PassengerInfoFilled()。
• ProceedToPayment(): 前提：PassengerInfoFilled()；效果：OnPage(支付页)。

这个模型可以用类PDDL的语言或简单的JSON/YAML来定义。关键在于，它描述了动作之间的逻辑依赖，而不涉及任何网站具体的UI细节。

4.2 第二步：实现状态识别器（状态映射）

这是连接抽象世界和具体网页的桥梁。我们需要一系列函数或一个训练过的模型，能够从当前网页的DOM/截图中，判断出高层状态谓词的真假。

• 对于OnPage(page_name)：可以结合URL分析和页面关键元素检测。例如，如果检测到页面包含id="searchForm"的元素，则很可能OnPage(搜索页)为真。我们可以使用XPath、CSS选择器或视觉模型来识别这些“地标”元素。
• 对于SearchCompleted(...)：需要检测搜索结果列表的出现，并尝试从中解析出航班信息。这可能需要一个专门的LLM调用或解析器。
• 对于FlightSelected(...)：检测“选择”按钮是否变为“已选”状态，或是否跳转到了包含乘客信息的页面。

实操心得：状态识别是系统中最容易出错的部分，必须设计得足够健壮。建议采用“投票”机制：结合多个弱信号（如URL、标题、多个关键元素的存在性）来综合判断一个状态，而不是依赖单一元素。同时，要为每个状态识别器设置超时和重试逻辑。

4.3 第三步：设计分层规划与执行循环

整个系统的运行流程是一个“规划-执行-监测”的循环：

1. 任务解析与高层规划：用户输入“购买下周五北京到上海的机票”。系统首先调用一个规划LLM，该LLM的提示词中包含了高层领域模型。提示词示例：

   “你是一个任务规划器。可用的高层动作有：[列出所有高层动作及其前提效果]。当前已知状态：OnPage(首页)为真。用户目标是：购买下周五北京到上海的机票。请输出一个合理的高层动作序列来达成目标。只输出动作序列。”

   规划LLM可能输出：[NavigateToSearch(), PerformSearch(北京, 上海, 下周五), SelectFlight(?), FillPassengerInfo(?), ProceedToPayment(), ...]。注意，SelectFlight和FillPassengerInfo的具体参数（flight_id,info）在规划时是未知的，需要后续填充。

2. 高层动作选择与参数绑定：系统从序列中取出第一个可执行的动作（其前提条件被当前状态满足）。例如，当前状态满足NavigateToSearch()的前提（已在首页），则选择该动作。对于需要参数的动作，调用LLM或规则从上下文和网页中提取。例如，执行PerformSearch前，需要绑定dep,arr,date参数，这些可以从用户指令中解析。

3. 底层动作生成与执行：系统将选定的高层动作（如PerformSearch(北京, 上海, 2024-06-14)）交给执行LLM。执行LLM的提示词包含当前网页的具体信息（简化后的DOM或截图），以及指令：

   “你的目标是在当前网页上执行高层动作：PerformSearch(出发地=北京, 到达地=上海, 日期=2024-06-14)。请观察页面，输出下一个具体的底层操作（如CLICK、INPUT）。只输出一个操作。”

   执行LLM会输出如INPUT [id="depCity"] “北京”。系统通过浏览器自动化工具（如Playwright, Selenium）执行此操作。

4. 状态监测与更新：执行一个底层动作后，系统等待页面稳定，然后调用状态识别器更新所有高层状态谓词的值。例如，输入出发地后，OnPage(搜索页)可能仍为真，但其他状态未变。系统继续调用执行LLM输出下一个底层动作，直到完成“输入到达地”、“输入日期”、“点击搜索按钮”等一系列操作。

5. 高层动作完成判定与推进：当状态识别器检测到SearchCompleted(北京, 上海, 2024-06-14)变为真时，系统判定当前高层动作PerformSearch已完成。然后，系统回到步骤2，从高层序列中取出下一个动作（SelectFlight(?)），并开始新一轮的底层执行循环。

6. 异常处理与重规划：如果底层执行LLM多次输出无效动作导致失败，或长时间无法达成高层动作的效果（状态未改变），则触发异常处理。这可能包括：尝试替代的底层操作序列、重置页面、或者向上层汇报失败。如果高层动作被判定为在当前状态下不可能完成（如前提永远无法满足），则高层规划器需要被重新触发，基于最新状态生成一个新的计划。

4.4 第四步：关键工具与组件选型

• 浏览器自动化：Playwright是当前首选。它比Selenium更快速、稳定，提供强大的选择器引擎和自动等待机制，能很好地处理动态网页。其Python/Node.js API也非常友好。
• 网页信息提取：直接使用完整DOM作为LLM上下文太大。需要压缩：
  • DOM简化：使用库如readability或自定义规则，移除脚本、样式、隐藏元素，只保留可见的、交互性强的元素（按钮、输入框、链接）。
  • 视觉感知：对于复杂UI，截图后使用多模态大模型（如GPT-4V）进行描述，可以作为DOM文本的补充。这对于识别图标、验证码等非文本元素尤其有效。
• LLM角色分配：
  • 规划LLM：需要较强的逻辑推理和任务分解能力。GPT-4、Claude-3 Opus等顶级闭源模型，或开源的DeepSeek-Coder、Qwen2.5-72B-Instruct是较好选择。提示词中必须清晰定义领域模型。
  • 执行LLM：需要精准理解UI元素和操作。除了上述大模型，也可以针对特定网站微调较小的模型（如7B-13B参数），以降低成本、提高速度。上下文主要包含简化后的DOM和当前任务。
• 状态识别器实现：初期可采用基于规则的方法（XPath/CSS选择器）。随着复杂度提升，可以训练一个小的分类模型，或使用LLM进行零样本/少样本的视觉问答来判断状态。例如，将页面截图和问题“用户是否已成功登录？”交给多模态LLM。

5. 实战中的挑战、技巧与避坑指南

即使有了分层框架，在实际开发中依然会遇到大量棘手问题。以下是我从多个项目中总结的经验。

5.1 挑战一：高层领域模型的构建与维护

• 问题：为每个新网站或新领域手动定义高层模型成本高昂，且模型可能不完整。
• 技巧：
  1. 从示例中逆向工程：录制几个人类完成任务的示例（操作序列），然后让LLM从这些序列中归纳出可能的高层动作和状态变化。这可以作为人工定义的起点。
  2. 设计可扩展的模型语言：使用结构化的格式（如YAML）定义模型，便于增删改。将动作和状态参数化。
  3. 分层模型：可以设计更细的层次。例如，在“电商购物”高层下，可以有“商品浏览”、“订单管理”、“售后服务”等子领域模型，提高复用性。

5.2 挑战二：状态识别的准确性与延迟

• 问题：规则化的状态识别器脆弱，而基于LLM的识别速度慢、成本高。
• 技巧：
  1. 混合识别策略：对关键、稳定的状态（如OnPage）使用快速规则匹配；对复杂、语义化的状态（如SearchCompleted，需要判断是否有有效结果）使用LLM。
  2. 设置置信度与超时：每个状态识别器返回一个置信度分数。只有置信度高于阈值才更新状态。同时，为状态转换设置合理超时，避免无限等待。
  3. 缓存与预测：如果连续多个底层动作都与某个高层状态强相关（例如，在填写表单的多个输入步骤中，OnPage(表单页)很可能一直为真），可以暂时缓存该状态，减少识别频率。

5.3 挑战三：底层执行的鲁棒性

• 问题：执行LLM可能输出无法定位的元素或无效操作。
• 技巧：
  1. 动作验证与回退：在执行器执行动作前，增加一个验证步骤。例如，对于CLICK [id="btn"]，先检查是否存在该ID的元素，且元素可见、可点击。如果验证失败，将错误信息反馈给执行LLM，要求它重新输出一个动作，或触发回退策略（如尝试点击具有相同文本的按钮）。
  2. 提供丰富的上下文：给执行LLM的网页信息不仅要简化，还要增强。可以为交互元素添加语义注释，例如，将<button>Submit</button>表示为[ELEMENT: button, text: Submit, role: submit-button, bounding_box: (x1,y1,x2,y2)]。这能帮助LLM更好地理解元素功能。
  3. 动作模板与技能库：将常见的底层操作模式固化为“技能”。例如，“填写输入框”技能可以模板化为：FIND_INPUT_FIELD(label)->CLICK->INPUT_TEXT。执行LLM可以调用这些技能，而不是每次都从零生成原始操作，提高成功率。

5.4 挑战四：错误恢复与长期规划

• 问题：任务中断后，如何从中断点恢复，或调整后续计划？
• 技巧：
  1. 保存执行轨迹：详细记录每个执行步骤（高层动作、底层动作、执行前后的状态快照）。当错误发生时，可以将轨迹作为上下文提供给规划LLM，让它分析失败原因并生成修复计划。
  2. 设计重试与回滚策略：对于可预见的错误（如网络超时、元素未加载），设计自动重试。对于更严重的错误，可以尝试回滚到上一个稳定的高层状态（例如，重新加载搜索页），然后重新执行当前高层动作。
  3. 引入人工干预点：对于关键步骤（如支付确认）或系统多次尝试仍失败的情况，设计机制暂停任务并请求人工指导。人工操作可以被记录并学习，用于丰富系统的技能库。

6. 未来展望：走向更自主、更通用的网页智能体

分层规划为LLM网页智能体提供了一个坚实的骨架，但距离真正通用、鲁棒的智能体还有很长的路。结合当前的研究趋势和我的判断，以下几个方向值得深入探索：

1. 动态领域模型学习：未来的智能体应该能在与网站的交互中，自动发现和扩充其高层领域模型。例如，通过探索识别出新的页面类型（如“商品对比页”）和新的动作（如“加入收藏夹”），并自动将其纳入规划知识库。这需要结合无监督或自监督学习技术。

2. 多模态感知的深度融合：纯文本DOM丢失了大量视觉布局信息。结合视觉语言模型对页面进行整体理解（识别功能区、理解元素相对位置），将极大提升状态识别和动作生成的准确性。例如，VLM可以判断一个区域是“导航栏”、“商品列表”还是“广告区”，从而指导智能体忽略干扰。

3. 基于模型的强化学习：将分层规划与基于模型的强化学习结合。智能体在探索中学习一个“网页动态模型”，预测执行某个动作后页面会如何变化。这个预测模型可以用于更高效的前瞻性规划，在虚拟的“思维空间”中模拟多个动作序列的结果，从而选择最优路径。

4. 记忆与知识库的长期构建：智能体不应是“金鱼”，每次任务都从头开始。它需要长期记忆，记住不同网站的操作模式、登录状态、个人偏好等。这可以通过向量数据库或外部记忆模块来实现，让智能体真正具备“经验”。

从我个人的实践来看，分层规划不是一个“银弹”，但它确实将网页自动化任务从一场脆弱的“提示词技巧赌博”，转变为一个可分析、可调试、可改进的系统工程。它让我们能够更清晰地界定问题的边界，并运用更合适的工具去解决不同层次的问题。开始构建你的下一个网页智能体时，不妨先别急着写提示词，而是花时间思考一下：这个任务，应该如何分层？