尧图网站建设 
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作为一个从“状态-指令”到“动作”的端到端映射器。 这种范式的局限性显而易见反应式而非前瞻性智能体是“走一步看一步”没有整体任务蓝图。它无法预见到“点击A会导致弹窗B而关闭B需要C操作”因此无法提前规划应对策略。错误累积与无恢复能力一旦某个动作执行失败如点击了一个无效元素后续的所有动作都建立在错误的状态假设上整个任务链会迅速崩溃。智能体通常没有内置的“错误检测与恢复”机制。提示工程的天花板通过精心设计提示词如“请逐步思考”可以在简单任务上提升表现但无法从根本上解决上述的结构性问题。提示词无法赋予LLM真正的状态管理和分层分解能力。3. 分层规划一种来自经典AI的救赎思路论文提出的“分层规划”视角正是为了应对上述挑战。它并非全新概念在经典AI规划领域尤其是PDDL规划中已有成熟应用。其核心思想是将复杂的顶层任务分解为多个层次的子任务每个子任务又可以进一步分解形成一棵任务树。高层规划关注“做什么”What底层规划/执行关注“如何做”How。3.1 分层规划的核心组件借鉴PDDL的思想我们可以为LLM网页智能体构想一个分层规划框架它包含以下几个关键组件高层领域模型这是一个对网页功能域的抽象描述不涉及具体DOM细节。例如在电商领域高层动作可能是SearchProduct(keyword),FilterBy(condition),AddToCart()。高层状态可能是CartContains(item)True。这个模型由人工定义或通过少量示例让LLM总结得出。分层任务网络顶层任务如“购买咖啡机”被分解为一系列高层动作序列。每个高层动作如FilterBy(price500)本身又是一个子任务需要被进一步分解为一系列具体的、可执行的底层动作如CLICK [data-testidprice-filter],INPUT [idmaxPrice] “500”,CLICK [id“apply-filter”]。状态抽象与映射系统需要维护两种状态表示1)抽象状态用于高层规划如“用户已登录”、“搜索已完成”、“商品已在购物车”。2)具体状态即当前网页的DOM或视觉表征。关键是要有一个映射机制能从具体状态中识别出抽象状态的当前值例如通过检测页面是否存在“登录成功提示”元素来判断isLoggedInTrue。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分析和页面关键元素检测。例如如果检测到页面包含idsearchForm的元素则很可能OnPage(搜索页)为真。我们可以使用XPath、CSS选择器或视觉模型来识别这些“地标”元素。对于SearchCompleted(...)需要检测搜索结果列表的出现并尝试从中解析出航班信息。这可能需要一个专门的LLM调用或解析器。对于FlightSelected(...)检测“选择”按钮是否变为“已选”状态或是否跳转到了包含乘客信息的页面。实操心得状态识别是系统中最容易出错的部分必须设计得足够健壮。建议采用“投票”机制结合多个弱信号如URL、标题、多个关键元素的存在性来综合判断一个状态而不是依赖单一元素。同时要为每个状态识别器设置超时和重试逻辑。4.3 第三步设计分层规划与执行循环整个系统的运行流程是一个“规划-执行-监测”的循环任务解析与高层规划用户输入“购买下周五北京到上海的机票”。系统首先调用一个规划LLM该LLM的提示词中包含了高层领域模型。提示词示例“你是一个任务规划器。可用的高层动作有[列出所有高层动作及其前提效果]。当前已知状态OnPage(首页)为真。用户目标是购买下周五北京到上海的机票。请输出一个合理的高层动作序列来达成目标。只输出动作序列。”规划LLM可能输出[NavigateToSearch(), PerformSearch(北京, 上海, 下周五), SelectFlight(?), FillPassengerInfo(?), ProceedToPayment(), ...]。注意SelectFlight和FillPassengerInfo的具体参数flight_id,info在规划时是未知的需要后续填充。高层动作选择与参数绑定系统从序列中取出第一个可执行的动作其前提条件被当前状态满足。例如当前状态满足NavigateToSearch()的前提已在首页则选择该动作。对于需要参数的动作调用LLM或规则从上下文和网页中提取。例如执行PerformSearch前需要绑定dep,arr,date参数这些可以从用户指令中解析。底层动作生成与执行系统将选定的高层动作如PerformSearch(北京, 上海, 2024-06-14)交给执行LLM。执行LLM的提示词包含当前网页的具体信息简化后的DOM或截图以及指令“你的目标是在当前网页上执行高层动作PerformSearch(出发地北京, 到达地上海, 日期2024-06-14)。请观察页面输出下一个具体的底层操作如CLICK、INPUT。只输出一个操作。”执行LLM会输出如INPUT [iddepCity] “北京”。系统通过浏览器自动化工具如Playwright, Selenium执行此操作。状态监测与更新执行一个底层动作后系统等待页面稳定然后调用状态识别器更新所有高层状态谓词的值。例如输入出发地后OnPage(搜索页)可能仍为真但其他状态未变。系统继续调用执行LLM输出下一个底层动作直到完成“输入到达地”、“输入日期”、“点击搜索按钮”等一系列操作。高层动作完成判定与推进当状态识别器检测到SearchCompleted(北京, 上海, 2024-06-14)变为真时系统判定当前高层动作PerformSearch已完成。然后系统回到步骤2从高层序列中取出下一个动作SelectFlight(?)并开始新一轮的底层执行循环。异常处理与重规划如果底层执行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 挑战一高层领域模型的构建与维护问题为每个新网站或新领域手动定义高层模型成本高昂且模型可能不完整。技巧从示例中逆向工程录制几个人类完成任务的示例操作序列然后让LLM从这些序列中归纳出可能的高层动作和状态变化。这可以作为人工定义的起点。设计可扩展的模型语言使用结构化的格式如YAML定义模型便于增删改。将动作和状态参数化。分层模型可以设计更细的层次。例如在“电商购物”高层下可以有“商品浏览”、“订单管理”、“售后服务”等子领域模型提高复用性。5.2 挑战二状态识别的准确性与延迟问题规则化的状态识别器脆弱而基于LLM的识别速度慢、成本高。技巧混合识别策略对关键、稳定的状态如OnPage使用快速规则匹配对复杂、语义化的状态如SearchCompleted需要判断是否有有效结果使用LLM。设置置信度与超时每个状态识别器返回一个置信度分数。只有置信度高于阈值才更新状态。同时为状态转换设置合理超时避免无限等待。缓存与预测如果连续多个底层动作都与某个高层状态强相关例如在填写表单的多个输入步骤中OnPage(表单页)很可能一直为真可以暂时缓存该状态减少识别频率。5.3 挑战三底层执行的鲁棒性问题执行LLM可能输出无法定位的元素或无效操作。技巧动作验证与回退在执行器执行动作前增加一个验证步骤。例如对于CLICK [idbtn]先检查是否存在该ID的元素且元素可见、可点击。如果验证失败将错误信息反馈给执行LLM要求它重新输出一个动作或触发回退策略如尝试点击具有相同文本的按钮。提供丰富的上下文给执行LLM的网页信息不仅要简化还要增强。可以为交互元素添加语义注释例如将buttonSubmit/button表示为[ELEMENT: button, text: Submit, role: submit-button, bounding_box: (x1,y1,x2,y2)]。这能帮助LLM更好地理解元素功能。动作模板与技能库将常见的底层操作模式固化为“技能”。例如“填写输入框”技能可以模板化为FIND_INPUT_FIELD(label)-CLICK-INPUT_TEXT。执行LLM可以调用这些技能而不是每次都从零生成原始操作提高成功率。5.4 挑战四错误恢复与长期规划问题任务中断后如何从中断点恢复或调整后续计划技巧保存执行轨迹详细记录每个执行步骤高层动作、底层动作、执行前后的状态快照。当错误发生时可以将轨迹作为上下文提供给规划LLM让它分析失败原因并生成修复计划。设计重试与回滚策略对于可预见的错误如网络超时、元素未加载设计自动重试。对于更严重的错误可以尝试回滚到上一个稳定的高层状态例如重新加载搜索页然后重新执行当前高层动作。引入人工干预点对于关键步骤如支付确认或系统多次尝试仍失败的情况设计机制暂停任务并请求人工指导。人工操作可以被记录并学习用于丰富系统的技能库。6. 未来展望走向更自主、更通用的网页智能体分层规划为LLM网页智能体提供了一个坚实的骨架但距离真正通用、鲁棒的智能体还有很长的路。结合当前的研究趋势和我的判断以下几个方向值得深入探索1. 动态领域模型学习未来的智能体应该能在与网站的交互中自动发现和扩充其高层领域模型。例如通过探索识别出新的页面类型如“商品对比页”和新的动作如“加入收藏夹”并自动将其纳入规划知识库。这需要结合无监督或自监督学习技术。2. 多模态感知的深度融合纯文本DOM丢失了大量视觉布局信息。结合视觉语言模型对页面进行整体理解识别功能区、理解元素相对位置将极大提升状态识别和动作生成的准确性。例如VLM可以判断一个区域是“导航栏”、“商品列表”还是“广告区”从而指导智能体忽略干扰。3. 基于模型的强化学习将分层规划与基于模型的强化学习结合。智能体在探索中学习一个“网页动态模型”预测执行某个动作后页面会如何变化。这个预测模型可以用于更高效的前瞻性规划在虚拟的“思维空间”中模拟多个动作序列的结果从而选择最优路径。4. 记忆与知识库的长期构建智能体不应是“金鱼”每次任务都从头开始。它需要长期记忆记住不同网站的操作模式、登录状态、个人偏好等。这可以通过向量数据库或外部记忆模块来实现让智能体真正具备“经验”。从我个人的实践来看分层规划不是一个“银弹”但它确实将网页自动化任务从一场脆弱的“提示词技巧赌博”转变为一个可分析、可调试、可改进的系统工程。它让我们能够更清晰地界定问题的边界并运用更合适的工具去解决不同层次的问题。开始构建你的下一个网页智能体时不妨先别急着写提示词而是花时间思考一下这个任务应该如何分层 LLM网页智能体为何失败？分层规划视角解析与工程实践
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作为一个从“状态-指令”到“动作”的端到端映射器。 这种范式的局限性显而易见反应式而非前瞻性智能体是“走一步看一步”没有整体任务蓝图。它无法预见到“点击A会导致弹窗B而关闭B需要C操作”因此无法提前规划应对策略。错误累积与无恢复能力一旦某个动作执行失败如点击了一个无效元素后续的所有动作都建立在错误的状态假设上整个任务链会迅速崩溃。智能体通常没有内置的“错误检测与恢复”机制。提示工程的天花板通过精心设计提示词如“请逐步思考”可以在简单任务上提升表现但无法从根本上解决上述的结构性问题。提示词无法赋予LLM真正的状态管理和分层分解能力。3. 分层规划一种来自经典AI的救赎思路论文提出的“分层规划”视角正是为了应对上述挑战。它并非全新概念在经典AI规划领域尤其是PDDL规划中已有成熟应用。其核心思想是将复杂的顶层任务分解为多个层次的子任务每个子任务又可以进一步分解形成一棵任务树。高层规划关注“做什么”What底层规划/执行关注“如何做”How。3.1 分层规划的核心组件借鉴PDDL的思想我们可以为LLM网页智能体构想一个分层规划框架它包含以下几个关键组件高层领域模型这是一个对网页功能域的抽象描述不涉及具体DOM细节。例如在电商领域高层动作可能是SearchProduct(keyword),FilterBy(condition),AddToCart()。高层状态可能是CartContains(item)True。这个模型由人工定义或通过少量示例让LLM总结得出。分层任务网络顶层任务如“购买咖啡机”被分解为一系列高层动作序列。每个高层动作如FilterBy(price500)本身又是一个子任务需要被进一步分解为一系列具体的、可执行的底层动作如CLICK [data-testidprice-filter],INPUT [idmaxPrice] “500”,CLICK [id“apply-filter”]。状态抽象与映射系统需要维护两种状态表示1)抽象状态用于高层规划如“用户已登录”、“搜索已完成”、“商品已在购物车”。2)具体状态即当前网页的DOM或视觉表征。关键是要有一个映射机制能从具体状态中识别出抽象状态的当前值例如通过检测页面是否存在“登录成功提示”元素来判断isLoggedInTrue。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分析和页面关键元素检测。例如如果检测到页面包含idsearchForm的元素则很可能OnPage(搜索页)为真。我们可以使用XPath、CSS选择器或视觉模型来识别这些“地标”元素。对于SearchCompleted(...)需要检测搜索结果列表的出现并尝试从中解析出航班信息。这可能需要一个专门的LLM调用或解析器。对于FlightSelected(...)检测“选择”按钮是否变为“已选”状态或是否跳转到了包含乘客信息的页面。实操心得状态识别是系统中最容易出错的部分必须设计得足够健壮。建议采用“投票”机制结合多个弱信号如URL、标题、多个关键元素的存在性来综合判断一个状态而不是依赖单一元素。同时要为每个状态识别器设置超时和重试逻辑。4.3 第三步设计分层规划与执行循环整个系统的运行流程是一个“规划-执行-监测”的循环任务解析与高层规划用户输入“购买下周五北京到上海的机票”。系统首先调用一个规划LLM该LLM的提示词中包含了高层领域模型。提示词示例“你是一个任务规划器。可用的高层动作有[列出所有高层动作及其前提效果]。当前已知状态OnPage(首页)为真。用户目标是购买下周五北京到上海的机票。请输出一个合理的高层动作序列来达成目标。只输出动作序列。”规划LLM可能输出[NavigateToSearch(), PerformSearch(北京, 上海, 下周五), SelectFlight(?), FillPassengerInfo(?), ProceedToPayment(), ...]。注意SelectFlight和FillPassengerInfo的具体参数flight_id,info在规划时是未知的需要后续填充。高层动作选择与参数绑定系统从序列中取出第一个可执行的动作其前提条件被当前状态满足。例如当前状态满足NavigateToSearch()的前提已在首页则选择该动作。对于需要参数的动作调用LLM或规则从上下文和网页中提取。例如执行PerformSearch前需要绑定dep,arr,date参数这些可以从用户指令中解析。底层动作生成与执行系统将选定的高层动作如PerformSearch(北京, 上海, 2024-06-14)交给执行LLM。执行LLM的提示词包含当前网页的具体信息简化后的DOM或截图以及指令“你的目标是在当前网页上执行高层动作PerformSearch(出发地北京, 到达地上海, 日期2024-06-14)。请观察页面输出下一个具体的底层操作如CLICK、INPUT。只输出一个操作。”执行LLM会输出如INPUT [iddepCity] “北京”。系统通过浏览器自动化工具如Playwright, Selenium执行此操作。状态监测与更新执行一个底层动作后系统等待页面稳定然后调用状态识别器更新所有高层状态谓词的值。例如输入出发地后OnPage(搜索页)可能仍为真但其他状态未变。系统继续调用执行LLM输出下一个底层动作直到完成“输入到达地”、“输入日期”、“点击搜索按钮”等一系列操作。高层动作完成判定与推进当状态识别器检测到SearchCompleted(北京, 上海, 2024-06-14)变为真时系统判定当前高层动作PerformSearch已完成。然后系统回到步骤2从高层序列中取出下一个动作SelectFlight(?)并开始新一轮的底层执行循环。异常处理与重规划如果底层执行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 挑战一高层领域模型的构建与维护问题为每个新网站或新领域手动定义高层模型成本高昂且模型可能不完整。技巧从示例中逆向工程录制几个人类完成任务的示例操作序列然后让LLM从这些序列中归纳出可能的高层动作和状态变化。这可以作为人工定义的起点。设计可扩展的模型语言使用结构化的格式如YAML定义模型便于增删改。将动作和状态参数化。分层模型可以设计更细的层次。例如在“电商购物”高层下可以有“商品浏览”、“订单管理”、“售后服务”等子领域模型提高复用性。5.2 挑战二状态识别的准确性与延迟问题规则化的状态识别器脆弱而基于LLM的识别速度慢、成本高。技巧混合识别策略对关键、稳定的状态如OnPage使用快速规则匹配对复杂、语义化的状态如SearchCompleted需要判断是否有有效结果使用LLM。设置置信度与超时每个状态识别器返回一个置信度分数。只有置信度高于阈值才更新状态。同时为状态转换设置合理超时避免无限等待。缓存与预测如果连续多个底层动作都与某个高层状态强相关例如在填写表单的多个输入步骤中OnPage(表单页)很可能一直为真可以暂时缓存该状态减少识别频率。5.3 挑战三底层执行的鲁棒性问题执行LLM可能输出无法定位的元素或无效操作。技巧动作验证与回退在执行器执行动作前增加一个验证步骤。例如对于CLICK [idbtn]先检查是否存在该ID的元素且元素可见、可点击。如果验证失败将错误信息反馈给执行LLM要求它重新输出一个动作或触发回退策略如尝试点击具有相同文本的按钮。提供丰富的上下文给执行LLM的网页信息不仅要简化还要增强。可以为交互元素添加语义注释例如将buttonSubmit/button表示为[ELEMENT: button, text: Submit, role: submit-button, bounding_box: (x1,y1,x2,y2)]。这能帮助LLM更好地理解元素功能。动作模板与技能库将常见的底层操作模式固化为“技能”。例如“填写输入框”技能可以模板化为FIND_INPUT_FIELD(label)-CLICK-INPUT_TEXT。执行LLM可以调用这些技能而不是每次都从零生成原始操作提高成功率。5.4 挑战四错误恢复与长期规划问题任务中断后如何从中断点恢复或调整后续计划技巧保存执行轨迹详细记录每个执行步骤高层动作、底层动作、执行前后的状态快照。当错误发生时可以将轨迹作为上下文提供给规划LLM让它分析失败原因并生成修复计划。设计重试与回滚策略对于可预见的错误如网络超时、元素未加载设计自动重试。对于更严重的错误可以尝试回滚到上一个稳定的高层状态例如重新加载搜索页然后重新执行当前高层动作。引入人工干预点对于关键步骤如支付确认或系统多次尝试仍失败的情况设计机制暂停任务并请求人工指导。人工操作可以被记录并学习用于丰富系统的技能库。6. 未来展望走向更自主、更通用的网页智能体分层规划为LLM网页智能体提供了一个坚实的骨架但距离真正通用、鲁棒的智能体还有很长的路。结合当前的研究趋势和我的判断以下几个方向值得深入探索1. 动态领域模型学习未来的智能体应该能在与网站的交互中自动发现和扩充其高层领域模型。例如通过探索识别出新的页面类型如“商品对比页”和新的动作如“加入收藏夹”并自动将其纳入规划知识库。这需要结合无监督或自监督学习技术。2. 多模态感知的深度融合纯文本DOM丢失了大量视觉布局信息。结合视觉语言模型对页面进行整体理解识别功能区、理解元素相对位置将极大提升状态识别和动作生成的准确性。例如VLM可以判断一个区域是“导航栏”、“商品列表”还是“广告区”从而指导智能体忽略干扰。3. 基于模型的强化学习将分层规划与基于模型的强化学习结合。智能体在探索中学习一个“网页动态模型”预测执行某个动作后页面会如何变化。这个预测模型可以用于更高效的前瞻性规划在虚拟的“思维空间”中模拟多个动作序列的结果从而选择最优路径。4. 记忆与知识库的长期构建智能体不应是“金鱼”每次任务都从头开始。它需要长期记忆记住不同网站的操作模式、登录状态、个人偏好等。这可以通过向量数据库或外部记忆模块来实现让智能体真正具备“经验”。从我个人的实践来看分层规划不是一个“银弹”但它确实将网页自动化任务从一场脆弱的“提示词技巧赌博”转变为一个可分析、可调试、可改进的系统工程。它让我们能够更清晰地界定问题的边界并运用更合适的工具去解决不同层次的问题。开始构建你的下一个网页智能体时不妨先别急着写提示词而是花时间思考一下这个任务应该如何分层