1. 项目概述当LLM学会“思考”与“行动”最近在折腾AI应用落地的朋友估计都绕不开一个词Agent智能体。特别是基于大语言模型LLM的Web Agent它不再满足于和你聊聊天、写写诗而是被赋予了更具体的使命——像人一样操作浏览器完成诸如信息查询、表单填写、在线购物、数据抓取等一系列任务。听起来很酷对吧但真正上手构建一个稳定可靠的Web Agent你会发现它远不止是调用一个API那么简单。核心的挑战在于LLM本身是一个“思想家”擅长理解和生成语言但它缺乏“规划者”的严谨逻辑和“执行者”的精确控制能力。让LLM直接去点击网页按钮就像让一位战略家去前线拆炸弹结果往往是灾难性的动作混乱、陷入循环、或者干脆“幻觉”出一个不存在的页面元素。这正是“AI Planning Framework for LLM-Based Web Agents”这个项目要解决的核心问题。它不是一个具体的工具而是一套方法论和架构设计旨在为LLM驱动的Web Agent注入“规划”能力。简单来说就是教会AI在动手之前先“动脑”将模糊的用户指令如“帮我查一下明天从北京飞上海最便宜的航班”分解成一系列可执行、可验证的原子步骤打开浏览器 - 导航至机票网站 - 选择出发/到达城市 - 选择日期 - 点击搜索 - 解析结果并排序 - 返回最低价格并在执行过程中根据环境反馈如页面加载状态、元素是否出现、操作是否成功动态调整计划。这套框架的价值对于任何想将LLM能力从“对话”延伸到“实操”的开发者、产品经理或研究者而言都是巨大的。它意味着更高的任务成功率、更低的API调用成本减少无意义的试错、以及最终构建出真正实用、能解决实际问题的AI助手。接下来我将结合实践拆解构建这样一个规划框架的核心思路、关键组件以及那些在文档里不会写的“坑”。2. 框架核心设计从“反应式”到“规划式”的范式转变在深入细节之前我们必须理解传统LLM Web Agent与规划框架引导下的Agent的根本区别。这决定了整个系统的设计哲学。2.1 两种模式的对比直觉驱动 vs. 蓝图驱动1. 反应式ReactiveAgent这是最简单的模式常被称为“LLM as a Controller”。其工作流是将当前网页的DOM或简化后的HTML、屏幕截图以及任务描述一起抛给LLM然后问“下一步该点击哪里或输入什么” LLM基于当前“快照”给出一个动作。执行该动作后获取新的页面状态再重复上述过程。优点实现简单直观适合非常简单的线性任务。致命缺点缺乏上下文LLM每次只看到当前瞬间的状态像得了“健忘症”容易重复操作或走回头路。短视决策无法为了长远目标如需要先登录才能搜索而忍受短期无反馈的操作。极易陷入循环例如在一个分页页面LLM可能不断点击“下一页”而忘记最初要收集什么数据。成本高昂每一步都需要调用LLM且通常需要传入大量上下文如长文本DOMtoken消耗巨大。2. 规划式PlanningAgent规划框架引入了“思考-规划-执行-观察”的循环。它要求Agent在行动前先制定一个或多个可能的高层计划Plan然后将计划分解为可执行的任务Task并为每个任务选择合适的工具Tool来执行。核心思想将任务规划What to do与动作执行How to do解耦。LLM更多地扮演“规划者”和“监督者”的角色而具体的“点击”、“输入”、“滚动”等操作由封装好的、确定性的工具函数完成。关键组件规划器Planner接收用户目标生成一个步骤序列。这可以是一个简单的线性列表也可以是一个更复杂的流程图包含条件分支。任务分解与调度器Task Decomposer Scheduler将高层计划拆解为原子任务并管理它们的执行顺序和依赖关系。工具集Toolkit一组定义良好的函数如click(selector),type_text(selector, text),extract_text(selector),navigate(url)等。每个工具都有清晰的输入、输出和错误处理。状态管理与世界模型State Management World Model维护当前任务的进度、已收集的数据以及Agent对当前网页环境的“理解”而不仅仅是原始DOM。这相当于Agent的“工作记忆”。反思与重规划模块Reflection Replanning当任务执行失败或遇到意外情况时如弹窗、页面404分析原因并调整原有计划。2.2 为什么“规划”如此重要一个电商比价案例假设任务是“在电商平台A和B上找出某品牌手机的最新款并对比两者的价格和库存。”反应式Agent的可能路径它可能会在平台A上成功找到手机然后试图直接去平台B找同一款手机。但由于两个平台页面结构、登录状态、搜索栏位置完全不同它很可能在平台B的首页就“卡住”了因为它试图用平台A的经验去操作平台B。规划式Agent的路径规划器生成计划[登录平台A - 搜索手机 - 提取信息 - 登出 - 登录平台B - 搜索手机 - 提取信息 - 对比结果]。任务调度器将“登录平台A”分解为[导航至A首页 - 定位登录按钮 - 点击 - 定位用户名输入框 - 输入 - 定位密码框 - 输入 - 点击提交]。执行“登录平台A”任务。如果遇到验证码意外反思模块会识别到并触发重规划可能需要调用“处理验证码”工具或者回退到让用户手动干预。完成平台A后状态管理器记录下手机型号、价格等信息。当执行“登录平台B”时Agent知道这是一个全新的会话不会携带平台A的DOM选择器经验而是重新调用“导航”和“查找登录入口”的工具。这个例子清晰地展示了规划带来的鲁棒性和可复用性。工具是通用的click,type_text但规划是任务特定的。通过更换规划同一套工具可以完成截然不同的工作。3. 核心模块深度解析与实现要点理解了设计哲学我们来逐一拆解规划框架的各个核心模块并分享实操中的关键细节。3.1 规划器Planner的实现策略规划器是大脑中的“战略部”。它的输入是自然语言目标输出是一个结构化计划。实现规划器有几种常见模式1. 基于LLM的零样本/少样本规划这是最灵活的方式。通过精心设计的提示词Prompt引导LLM生成步骤。# 示例提示词模板 PLANNER_PROMPT 你是一个任务规划专家。请将以下用户目标分解为一个有序的步骤列表。每个步骤应该是一个简单、可执行的动作描述。 考虑网页操作的常见流程导航、等待、查找、交互点击/输入、提取信息。 用户目标{user_goal} 请以如下格式输出 1. 第一步... 2. 第二步... ... 实操心得让LLM用数字列表输出至关重要这便于后续程序化解析。同时在提示词中强调“可执行的动作描述”避免生成“思考一下”、“分析页面”这类模糊步骤。对于复杂任务提供几个少样本示例Few-shot能极大提升规划质量。2. 基于模板或DSL的规划对于垂直领域如固定流程的数据填报可以预定义任务模板。# 定义一个简单的领域特定语言DSL模板 TEMPLATES { data_scraping: [ {action: navigate, params: {url: $url}}, {action: wait_for_element, params: {selector: $table_selector}}, {action: extract_table, params: {selector: $table_selector, save_as: $data_name}}, ], form_submission: [ {action: navigate, params: {url: $form_url}}, {action: fill_field, params: {selector: $field1_selector, value: $value1}}, {action: fill_field, params: {selector: $field2_selector, value: $value2}}, {action: click, params: {selector: $submit_selector}}, ] }注意事项模板法牺牲了灵活性换来了极高的确定性和可靠性。适合标准化、高频的任务。关键是要设计好模板的变量替换机制如$url。3. 分层规划Hierarchical Planning先由LLM生成一个高层任务树Task Tree然后对每个叶子节点任务再递归地进行细粒度规划。这适合非常复杂的任务避免一次性规划过长序列导致LLM注意力分散。3.2 工具集Toolkit的设计与封装工具集是Agent的“双手”。设计良好的工具集是稳定性的基石。工具设计原则原子性一个工具只做一件事且做好。click工具只负责点击不应包含查找元素逻辑。查找元素应由find_element工具完成。明确的接口每个工具应有清晰的函数签名包括必需的参数、可选参数以及返回值的类型和含义。健壮性工具内部必须有完善的错误处理和重试机制。例如click工具在元素未找到时可以等待几秒重试或者抛出特定异常供上层处理。上下文无关工具函数应尽量不依赖外部状态。所需的所有信息都应通过参数传入。这便于测试和复用。一个健壮的click工具示例from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.common.exceptions import TimeoutException, ElementClickInterceptedException class WebAgentToolkit: def __init__(self, driver, default_wait10): self.driver driver self.wait WebDriverWait(driver, default_wait) def click(self, selector: str, by: By By.CSS_SELECTOR, retries: int 2): 点击页面元素。 参数: selector: 元素选择器。 by: 定位方式默认为CSS_SELECTOR。 retries: 失败重试次数。 返回: bool: 成功为True失败为False。 异常: 抛出TimeoutException如果最终未找到或无法点击元素。 for attempt in range(retries 1): try: element self.wait.until(EC.element_to_be_clickable((by, selector))) element.click() # 点击后可添加短暂等待以确保页面开始响应 import time time.sleep(0.5) return True except (TimeoutException, ElementClickInterceptedException) as e: if attempt retries: # 最后一次尝试仍然失败记录日志并抛出异常 print(fFailed to click element with selector {selector} after {retries1} attempts. Error: {e}) raise print(fClick attempt {attempt1} failed for {selector}. Retrying...) time.sleep(1) # 重试前等待 return False避坑技巧EC.element_to_be_clickable比单纯的EC.presence_of_element_located更可靠因为它确保了元素不仅存在而且可交互。对于单页应用SPA点击后页面状态变化但URL不变需要依靠工具内部的隐式等待或更明确的状态检查如等待某个特定元素出现。3.3 状态管理与世界模型Agent需要记住“我在哪”、“我做了什么”、“我要什么”。这就是状态管理。任务状态记录当前执行到了计划的哪一步。是简单的步骤索引还是更复杂的有限状态机FSM。会话数据在执行过程中收集到的信息。例如在比价任务中从平台A抓取的价格需要暂存起来以便最后与平台B的价格对比。这通常用一个简单的字典或数据库来维护。世界模型这是对当前网页环境的抽象理解而不仅仅是原始的HTML字符串。它可以包括当前URL。页面主要功能区域的识别例如通过机器学习模型或启发式规则判断当前页面是“登录页”、“搜索结果页”、“商品详情页”还是“购物车页”。这能为规划提供高层上下文。上一步操作的结果成功还是失败如果失败错误类型是什么页面关键元素的摘要例如将页面中所有按钮的文本和选择器提取成一个列表供后续规划参考。经验之谈世界模型不必一开始就做得非常复杂。可以从简单的“页面类型”标签开始。例如在导航后用一个小型文本分类模型甚至是一组关键词匹配规则来判断页面类型并将这个类型作为状态的一部分。这能有效防止Agent在登录页执行搜索操作这类低级错误。3.4 反思与重规划应对不确定性的安全网这是区分“玩具”和“可用系统”的关键。再好的计划也可能被验证码、网络错误、页面改版打断。反思循环Reflection Loop通常在工作流如下步骤后触发一个工具执行失败抛出异常。一个任务步骤执行后预期的页面状态未出现例如点击登录后没有跳转到主页。定期如每执行5步后进行健康检查。反思模块的工作流程收集上下文最近的操作历史、当前页面截图/简化DOM、错误信息、原始目标和当前计划。分析原因将上述上下文提交给一个专用的“分析LLM”可以与规划器是同一个模型但提示词不同询问“当前任务失败的可能原因是什么是选择器问题、页面未加载、还是需要处理验证码”生成修复方案基于分析结果可能采取的行动包括微观调整重试当前步骤、更换选择器、滚动页面再尝试。局部重规划在当前步骤前后插入新步骤如“关闭弹窗”、“滑动验证码”。全局重规划完全放弃当前计划基于当前状态重新生成一个新计划。执行修复执行生成的修复方案并更新状态。# 一个简化的反思提示词 REFLECTION_PROMPT 你是一个故障诊断专家。Web Agent在执行任务时遇到了问题。 最近操作{recent_actions} 当前页面摘要{page_summary} 遇到的错误{error} 原始任务目标{original_goal} 请分析最可能的原因并从以下选项中选择最合适的恢复策略 A. 立即重试当前操作可能只是临时网络问题。 B. 尝试使用不同的元素定位策略如用XPath替代CSS选择器。 C. 需要先执行一个前置操作如等待更长时间、滚动页面、关闭弹窗。 D. 当前计划已不可行需要基于当前页面状态重新规划任务。 请只输出选项字母并简要说明理由50字内。 核心要点反思模块本身也可能出错。必须为它设置“熔断”机制比如最多重试3次反思循环如果仍无法解决则安全地停止任务并上报人工处理避免陷入无限循环。4. 端到端实操构建一个简易新闻标题抓取Agent让我们用一个具体例子串联以上所有概念。任务“去某新闻网站首页抓取今天的所有头条新闻标题和链接。”4.1 步骤一定义工具集我们假设已有一个基础工具集包含navigate(url)find_elements(selector)- 返回元素列表get_element_attribute(element, attr)- 如获取hrefget_element_text(element)scroll_down(pixels)4.2 步骤二设计规划器提示词并生成计划我们将用户目标发送给LLM如GPT-4或Claude 3。user_goal “去某新闻网站首页抓取今天的所有头条新闻标题和链接。” # 调用LLM生成计划 plan llm_generate(PLANNER_PROMPT.format(user_goaluser_goal))假设生成的计划是1. 导航到某新闻网站首页。 2. 等待页面主要内容加载完成。 3. 识别包含头条新闻的区域。 4. 滚动页面以确保所有新闻项都加载出来。 5. 定位所有新闻标题元素和对应的链接元素。 6. 提取每个新闻项的标题文本和链接URL。 7. 将提取的数据整理成结构化格式如列表或JSON。4.3 步骤三任务分解与调度调度器将这个计划分解为原子任务并映射到工具navigate(“https://news.example.com”)wait_for_element(“css selector of main content”)(这是一个组合工具内部可能用find_elements加循环检测)find_elements(“css selector for news container”)- 如果找到记录该选择器为news_container_selectorscroll_down(500)- 可能执行多次直到页面底部find_elements(“{news_container_selector} .news-item a.title”)- 得到标题链接元素列表title_elements对title_elements中的每个元素el:text get_element_text(el)url get_element_attribute(el, ‘href’)将(text, url)存入状态管理器的collected_data列表format_data(state[‘collected_data’])- 输出JSON4.4 步骤四执行与状态管理调度器按顺序执行任务。执行任务2时如果等待超时反思模块介入。分析后发现可能是选择器不对或网络慢。反思LLM可能建议策略C等待更长时间或更换选择器。调度器更新选择器或增加等待时间后重试。执行任务5时如果find_elements返回空列表反思模块再次触发。分析后可能发现新闻区域的CSS类名变了建议策略B尝试不同的定位策略如用XPath定位包含“头条”文本的区块。调度器根据建议更新选择器并重新从任务3或5开始执行。4.5 步骤五输出与总结所有任务成功执行后collected_data中存储了所有标题和链接最后格式化成JSON输出。现场记录在实际操作中第4步“滚动页面”至关重要。很多新闻网站采用无限滚动加载。简单的scroll_down一次可能不够。更稳健的做法是滚动 - 检测新元素是否出现 - 如果出现继续滚动直到连续几次滚动都没有新元素出现为止。这需要将“滚动并检测”封装成一个更高级的工具scroll_until_no_new_items(container_selector, item_selector)。5. 常见问题、避坑指南与进阶思考即使有了框架在实际开发中你依然会踩很多坑。以下是一些实录的问题与解决方案。5.1 典型问题排查表问题现象可能原因排查步骤与解决方案Agent点击不到元素1. 选择器不准或已过时。2. 元素未加载或不可交互。3. 元素被遮挡如弹窗。4. 页面是iframe框架。1. 使用浏览器开发者工具复查选择器。优先使用id、name或稳定的>Agent陷入无限循环1. 规划有环如A-B-A。2. 反思逻辑有缺陷总是给出相同的错误修复建议。3. 页面状态判断条件有误导致始终认为任务未完成。1. 在状态管理中记录已访问的(页面类型, 主要操作)对检测到循环则触发重规划。2. 为反思模块引入随机性或多策略投票避免死胡同。3. 优化世界模型中对“任务完成”状态的判断使其更精确。Token消耗巨大成本高1. 每次调用LLM都传入了完整的页面DOM。2. 规划或反思过于频繁。3. 使用了超大上下文窗口的模型。1.必须对DOM进行简化移除脚本、样式、隐藏元素只保留标签名、关键属性和可见文本。可以使用readability类库或自定义过滤器。2. 对简单、重复的操作序列如填写表单使用确定性脚本而非每次都问LLM。3. 对于规划等任务使用小型、高效的模型如Claude Haiku, GPT-3.5-Turbo可能就足够了。处理动态内容如验证码失败1. Agent没有处理非标准交互的能力。2. 规划中未考虑此类异常分支。1. 这是规划框架的边界。最佳实践是设计降级策略识别到验证码后暂停任务通知人工处理或调用专门的第三方验证码解决服务API。2. 在规划模板中为关键步骤如登录、提交预先定义“遇到验证码”的备用子流程。跨网站/跨域名任务不稳定1. 登录状态Cookie、Session丢失。2. 不同网站UI差异巨大通用选择器失效。1. 使用支持保存和恢复Cookie的浏览器驱动上下文如Selenium的driver.get_cookies()和driver.add_cookie()。2.为不同网站配置不同的“技能包”即网站特定的工具选择器映射表或微调规划提示词。不要指望一个通用Agent能完美操作所有网站。5.2 进阶优化方向当你解决了基本问题后可以考虑以下方向让Agent更强大学习与适应记录成功执行的任务轨迹计划动作序列页面状态变化。利用这些数据可以微调一个小型模型使其对特定网站的操作更熟练甚至自动生成可靠的选择器。多模态增强纯文本DOM丢失了大量视觉布局信息。结合视觉语言模型VLM分析屏幕截图可以更准确地理解UI元素的功能这是按钮还是图片提高在复杂、动态页面上的鲁棒性。规划时可以结合视觉描述如“点击页面顶部导航栏中蓝色的‘登录’按钮”。分层与模块化将常用的小任务序列封装成“技能”Skill如login_skill(site, credentials)、search_skill(site, keyword)。高层规划器只需调用这些技能而技能内部再展开为具体的工具调用。这大大降低了规划的复杂度。仿真与测试在真实网站上进行端到端测试成本高、速度慢。可以搭建一个轻量级的网页仿真环境用简单的HTML页面模拟目标网站的核心交互流程用于快速迭代和测试Agent的规划与执行逻辑。构建一个基于LLM的、具备规划能力的Web Agent是一个将前沿AI研究与扎实软件工程相结合的过程。它没有银弹需要你在灵活性LLM的强大生成能力与确定性工具集的可靠执行之间找到精妙的平衡。从一个小而具体的任务开始搭建起规划-执行-反思的闭环然后逐步扩展其能力和边界是通往成功最实际的路径。这套框架的价值最终会体现在你创造的Agent能够稳定、自动地完成那些曾经必须手动重复的网页操作上将想象力真正转化为生产力。
基于LLM的Web Agent规划框架：从理论到工程实践
1. 项目概述当LLM学会“思考”与“行动”最近在折腾AI应用落地的朋友估计都绕不开一个词Agent智能体。特别是基于大语言模型LLM的Web Agent它不再满足于和你聊聊天、写写诗而是被赋予了更具体的使命——像人一样操作浏览器完成诸如信息查询、表单填写、在线购物、数据抓取等一系列任务。听起来很酷对吧但真正上手构建一个稳定可靠的Web Agent你会发现它远不止是调用一个API那么简单。核心的挑战在于LLM本身是一个“思想家”擅长理解和生成语言但它缺乏“规划者”的严谨逻辑和“执行者”的精确控制能力。让LLM直接去点击网页按钮就像让一位战略家去前线拆炸弹结果往往是灾难性的动作混乱、陷入循环、或者干脆“幻觉”出一个不存在的页面元素。这正是“AI Planning Framework for LLM-Based Web Agents”这个项目要解决的核心问题。它不是一个具体的工具而是一套方法论和架构设计旨在为LLM驱动的Web Agent注入“规划”能力。简单来说就是教会AI在动手之前先“动脑”将模糊的用户指令如“帮我查一下明天从北京飞上海最便宜的航班”分解成一系列可执行、可验证的原子步骤打开浏览器 - 导航至机票网站 - 选择出发/到达城市 - 选择日期 - 点击搜索 - 解析结果并排序 - 返回最低价格并在执行过程中根据环境反馈如页面加载状态、元素是否出现、操作是否成功动态调整计划。这套框架的价值对于任何想将LLM能力从“对话”延伸到“实操”的开发者、产品经理或研究者而言都是巨大的。它意味着更高的任务成功率、更低的API调用成本减少无意义的试错、以及最终构建出真正实用、能解决实际问题的AI助手。接下来我将结合实践拆解构建这样一个规划框架的核心思路、关键组件以及那些在文档里不会写的“坑”。2. 框架核心设计从“反应式”到“规划式”的范式转变在深入细节之前我们必须理解传统LLM Web Agent与规划框架引导下的Agent的根本区别。这决定了整个系统的设计哲学。2.1 两种模式的对比直觉驱动 vs. 蓝图驱动1. 反应式ReactiveAgent这是最简单的模式常被称为“LLM as a Controller”。其工作流是将当前网页的DOM或简化后的HTML、屏幕截图以及任务描述一起抛给LLM然后问“下一步该点击哪里或输入什么” LLM基于当前“快照”给出一个动作。执行该动作后获取新的页面状态再重复上述过程。优点实现简单直观适合非常简单的线性任务。致命缺点缺乏上下文LLM每次只看到当前瞬间的状态像得了“健忘症”容易重复操作或走回头路。短视决策无法为了长远目标如需要先登录才能搜索而忍受短期无反馈的操作。极易陷入循环例如在一个分页页面LLM可能不断点击“下一页”而忘记最初要收集什么数据。成本高昂每一步都需要调用LLM且通常需要传入大量上下文如长文本DOMtoken消耗巨大。2. 规划式PlanningAgent规划框架引入了“思考-规划-执行-观察”的循环。它要求Agent在行动前先制定一个或多个可能的高层计划Plan然后将计划分解为可执行的任务Task并为每个任务选择合适的工具Tool来执行。核心思想将任务规划What to do与动作执行How to do解耦。LLM更多地扮演“规划者”和“监督者”的角色而具体的“点击”、“输入”、“滚动”等操作由封装好的、确定性的工具函数完成。关键组件规划器Planner接收用户目标生成一个步骤序列。这可以是一个简单的线性列表也可以是一个更复杂的流程图包含条件分支。任务分解与调度器Task Decomposer Scheduler将高层计划拆解为原子任务并管理它们的执行顺序和依赖关系。工具集Toolkit一组定义良好的函数如click(selector),type_text(selector, text),extract_text(selector),navigate(url)等。每个工具都有清晰的输入、输出和错误处理。状态管理与世界模型State Management World Model维护当前任务的进度、已收集的数据以及Agent对当前网页环境的“理解”而不仅仅是原始DOM。这相当于Agent的“工作记忆”。反思与重规划模块Reflection Replanning当任务执行失败或遇到意外情况时如弹窗、页面404分析原因并调整原有计划。2.2 为什么“规划”如此重要一个电商比价案例假设任务是“在电商平台A和B上找出某品牌手机的最新款并对比两者的价格和库存。”反应式Agent的可能路径它可能会在平台A上成功找到手机然后试图直接去平台B找同一款手机。但由于两个平台页面结构、登录状态、搜索栏位置完全不同它很可能在平台B的首页就“卡住”了因为它试图用平台A的经验去操作平台B。规划式Agent的路径规划器生成计划[登录平台A - 搜索手机 - 提取信息 - 登出 - 登录平台B - 搜索手机 - 提取信息 - 对比结果]。任务调度器将“登录平台A”分解为[导航至A首页 - 定位登录按钮 - 点击 - 定位用户名输入框 - 输入 - 定位密码框 - 输入 - 点击提交]。执行“登录平台A”任务。如果遇到验证码意外反思模块会识别到并触发重规划可能需要调用“处理验证码”工具或者回退到让用户手动干预。完成平台A后状态管理器记录下手机型号、价格等信息。当执行“登录平台B”时Agent知道这是一个全新的会话不会携带平台A的DOM选择器经验而是重新调用“导航”和“查找登录入口”的工具。这个例子清晰地展示了规划带来的鲁棒性和可复用性。工具是通用的click,type_text但规划是任务特定的。通过更换规划同一套工具可以完成截然不同的工作。3. 核心模块深度解析与实现要点理解了设计哲学我们来逐一拆解规划框架的各个核心模块并分享实操中的关键细节。3.1 规划器Planner的实现策略规划器是大脑中的“战略部”。它的输入是自然语言目标输出是一个结构化计划。实现规划器有几种常见模式1. 基于LLM的零样本/少样本规划这是最灵活的方式。通过精心设计的提示词Prompt引导LLM生成步骤。# 示例提示词模板 PLANNER_PROMPT 你是一个任务规划专家。请将以下用户目标分解为一个有序的步骤列表。每个步骤应该是一个简单、可执行的动作描述。 考虑网页操作的常见流程导航、等待、查找、交互点击/输入、提取信息。 用户目标{user_goal} 请以如下格式输出 1. 第一步... 2. 第二步... ... 实操心得让LLM用数字列表输出至关重要这便于后续程序化解析。同时在提示词中强调“可执行的动作描述”避免生成“思考一下”、“分析页面”这类模糊步骤。对于复杂任务提供几个少样本示例Few-shot能极大提升规划质量。2. 基于模板或DSL的规划对于垂直领域如固定流程的数据填报可以预定义任务模板。# 定义一个简单的领域特定语言DSL模板 TEMPLATES { data_scraping: [ {action: navigate, params: {url: $url}}, {action: wait_for_element, params: {selector: $table_selector}}, {action: extract_table, params: {selector: $table_selector, save_as: $data_name}}, ], form_submission: [ {action: navigate, params: {url: $form_url}}, {action: fill_field, params: {selector: $field1_selector, value: $value1}}, {action: fill_field, params: {selector: $field2_selector, value: $value2}}, {action: click, params: {selector: $submit_selector}}, ] }注意事项模板法牺牲了灵活性换来了极高的确定性和可靠性。适合标准化、高频的任务。关键是要设计好模板的变量替换机制如$url。3. 分层规划Hierarchical Planning先由LLM生成一个高层任务树Task Tree然后对每个叶子节点任务再递归地进行细粒度规划。这适合非常复杂的任务避免一次性规划过长序列导致LLM注意力分散。3.2 工具集Toolkit的设计与封装工具集是Agent的“双手”。设计良好的工具集是稳定性的基石。工具设计原则原子性一个工具只做一件事且做好。click工具只负责点击不应包含查找元素逻辑。查找元素应由find_element工具完成。明确的接口每个工具应有清晰的函数签名包括必需的参数、可选参数以及返回值的类型和含义。健壮性工具内部必须有完善的错误处理和重试机制。例如click工具在元素未找到时可以等待几秒重试或者抛出特定异常供上层处理。上下文无关工具函数应尽量不依赖外部状态。所需的所有信息都应通过参数传入。这便于测试和复用。一个健壮的click工具示例from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.common.exceptions import TimeoutException, ElementClickInterceptedException class WebAgentToolkit: def __init__(self, driver, default_wait10): self.driver driver self.wait WebDriverWait(driver, default_wait) def click(self, selector: str, by: By By.CSS_SELECTOR, retries: int 2): 点击页面元素。 参数: selector: 元素选择器。 by: 定位方式默认为CSS_SELECTOR。 retries: 失败重试次数。 返回: bool: 成功为True失败为False。 异常: 抛出TimeoutException如果最终未找到或无法点击元素。 for attempt in range(retries 1): try: element self.wait.until(EC.element_to_be_clickable((by, selector))) element.click() # 点击后可添加短暂等待以确保页面开始响应 import time time.sleep(0.5) return True except (TimeoutException, ElementClickInterceptedException) as e: if attempt retries: # 最后一次尝试仍然失败记录日志并抛出异常 print(fFailed to click element with selector {selector} after {retries1} attempts. Error: {e}) raise print(fClick attempt {attempt1} failed for {selector}. Retrying...) time.sleep(1) # 重试前等待 return False避坑技巧EC.element_to_be_clickable比单纯的EC.presence_of_element_located更可靠因为它确保了元素不仅存在而且可交互。对于单页应用SPA点击后页面状态变化但URL不变需要依靠工具内部的隐式等待或更明确的状态检查如等待某个特定元素出现。3.3 状态管理与世界模型Agent需要记住“我在哪”、“我做了什么”、“我要什么”。这就是状态管理。任务状态记录当前执行到了计划的哪一步。是简单的步骤索引还是更复杂的有限状态机FSM。会话数据在执行过程中收集到的信息。例如在比价任务中从平台A抓取的价格需要暂存起来以便最后与平台B的价格对比。这通常用一个简单的字典或数据库来维护。世界模型这是对当前网页环境的抽象理解而不仅仅是原始的HTML字符串。它可以包括当前URL。页面主要功能区域的识别例如通过机器学习模型或启发式规则判断当前页面是“登录页”、“搜索结果页”、“商品详情页”还是“购物车页”。这能为规划提供高层上下文。上一步操作的结果成功还是失败如果失败错误类型是什么页面关键元素的摘要例如将页面中所有按钮的文本和选择器提取成一个列表供后续规划参考。经验之谈世界模型不必一开始就做得非常复杂。可以从简单的“页面类型”标签开始。例如在导航后用一个小型文本分类模型甚至是一组关键词匹配规则来判断页面类型并将这个类型作为状态的一部分。这能有效防止Agent在登录页执行搜索操作这类低级错误。3.4 反思与重规划应对不确定性的安全网这是区分“玩具”和“可用系统”的关键。再好的计划也可能被验证码、网络错误、页面改版打断。反思循环Reflection Loop通常在工作流如下步骤后触发一个工具执行失败抛出异常。一个任务步骤执行后预期的页面状态未出现例如点击登录后没有跳转到主页。定期如每执行5步后进行健康检查。反思模块的工作流程收集上下文最近的操作历史、当前页面截图/简化DOM、错误信息、原始目标和当前计划。分析原因将上述上下文提交给一个专用的“分析LLM”可以与规划器是同一个模型但提示词不同询问“当前任务失败的可能原因是什么是选择器问题、页面未加载、还是需要处理验证码”生成修复方案基于分析结果可能采取的行动包括微观调整重试当前步骤、更换选择器、滚动页面再尝试。局部重规划在当前步骤前后插入新步骤如“关闭弹窗”、“滑动验证码”。全局重规划完全放弃当前计划基于当前状态重新生成一个新计划。执行修复执行生成的修复方案并更新状态。# 一个简化的反思提示词 REFLECTION_PROMPT 你是一个故障诊断专家。Web Agent在执行任务时遇到了问题。 最近操作{recent_actions} 当前页面摘要{page_summary} 遇到的错误{error} 原始任务目标{original_goal} 请分析最可能的原因并从以下选项中选择最合适的恢复策略 A. 立即重试当前操作可能只是临时网络问题。 B. 尝试使用不同的元素定位策略如用XPath替代CSS选择器。 C. 需要先执行一个前置操作如等待更长时间、滚动页面、关闭弹窗。 D. 当前计划已不可行需要基于当前页面状态重新规划任务。 请只输出选项字母并简要说明理由50字内。 核心要点反思模块本身也可能出错。必须为它设置“熔断”机制比如最多重试3次反思循环如果仍无法解决则安全地停止任务并上报人工处理避免陷入无限循环。4. 端到端实操构建一个简易新闻标题抓取Agent让我们用一个具体例子串联以上所有概念。任务“去某新闻网站首页抓取今天的所有头条新闻标题和链接。”4.1 步骤一定义工具集我们假设已有一个基础工具集包含navigate(url)find_elements(selector)- 返回元素列表get_element_attribute(element, attr)- 如获取hrefget_element_text(element)scroll_down(pixels)4.2 步骤二设计规划器提示词并生成计划我们将用户目标发送给LLM如GPT-4或Claude 3。user_goal “去某新闻网站首页抓取今天的所有头条新闻标题和链接。” # 调用LLM生成计划 plan llm_generate(PLANNER_PROMPT.format(user_goaluser_goal))假设生成的计划是1. 导航到某新闻网站首页。 2. 等待页面主要内容加载完成。 3. 识别包含头条新闻的区域。 4. 滚动页面以确保所有新闻项都加载出来。 5. 定位所有新闻标题元素和对应的链接元素。 6. 提取每个新闻项的标题文本和链接URL。 7. 将提取的数据整理成结构化格式如列表或JSON。4.3 步骤三任务分解与调度调度器将这个计划分解为原子任务并映射到工具navigate(“https://news.example.com”)wait_for_element(“css selector of main content”)(这是一个组合工具内部可能用find_elements加循环检测)find_elements(“css selector for news container”)- 如果找到记录该选择器为news_container_selectorscroll_down(500)- 可能执行多次直到页面底部find_elements(“{news_container_selector} .news-item a.title”)- 得到标题链接元素列表title_elements对title_elements中的每个元素el:text get_element_text(el)url get_element_attribute(el, ‘href’)将(text, url)存入状态管理器的collected_data列表format_data(state[‘collected_data’])- 输出JSON4.4 步骤四执行与状态管理调度器按顺序执行任务。执行任务2时如果等待超时反思模块介入。分析后发现可能是选择器不对或网络慢。反思LLM可能建议策略C等待更长时间或更换选择器。调度器更新选择器或增加等待时间后重试。执行任务5时如果find_elements返回空列表反思模块再次触发。分析后可能发现新闻区域的CSS类名变了建议策略B尝试不同的定位策略如用XPath定位包含“头条”文本的区块。调度器根据建议更新选择器并重新从任务3或5开始执行。4.5 步骤五输出与总结所有任务成功执行后collected_data中存储了所有标题和链接最后格式化成JSON输出。现场记录在实际操作中第4步“滚动页面”至关重要。很多新闻网站采用无限滚动加载。简单的scroll_down一次可能不够。更稳健的做法是滚动 - 检测新元素是否出现 - 如果出现继续滚动直到连续几次滚动都没有新元素出现为止。这需要将“滚动并检测”封装成一个更高级的工具scroll_until_no_new_items(container_selector, item_selector)。5. 常见问题、避坑指南与进阶思考即使有了框架在实际开发中你依然会踩很多坑。以下是一些实录的问题与解决方案。5.1 典型问题排查表问题现象可能原因排查步骤与解决方案Agent点击不到元素1. 选择器不准或已过时。2. 元素未加载或不可交互。3. 元素被遮挡如弹窗。4. 页面是iframe框架。1. 使用浏览器开发者工具复查选择器。优先使用id、name或稳定的>Agent陷入无限循环1. 规划有环如A-B-A。2. 反思逻辑有缺陷总是给出相同的错误修复建议。3. 页面状态判断条件有误导致始终认为任务未完成。1. 在状态管理中记录已访问的(页面类型, 主要操作)对检测到循环则触发重规划。2. 为反思模块引入随机性或多策略投票避免死胡同。3. 优化世界模型中对“任务完成”状态的判断使其更精确。Token消耗巨大成本高1. 每次调用LLM都传入了完整的页面DOM。2. 规划或反思过于频繁。3. 使用了超大上下文窗口的模型。1.必须对DOM进行简化移除脚本、样式、隐藏元素只保留标签名、关键属性和可见文本。可以使用readability类库或自定义过滤器。2. 对简单、重复的操作序列如填写表单使用确定性脚本而非每次都问LLM。3. 对于规划等任务使用小型、高效的模型如Claude Haiku, GPT-3.5-Turbo可能就足够了。处理动态内容如验证码失败1. Agent没有处理非标准交互的能力。2. 规划中未考虑此类异常分支。1. 这是规划框架的边界。最佳实践是设计降级策略识别到验证码后暂停任务通知人工处理或调用专门的第三方验证码解决服务API。2. 在规划模板中为关键步骤如登录、提交预先定义“遇到验证码”的备用子流程。跨网站/跨域名任务不稳定1. 登录状态Cookie、Session丢失。2. 不同网站UI差异巨大通用选择器失效。1. 使用支持保存和恢复Cookie的浏览器驱动上下文如Selenium的driver.get_cookies()和driver.add_cookie()。2.为不同网站配置不同的“技能包”即网站特定的工具选择器映射表或微调规划提示词。不要指望一个通用Agent能完美操作所有网站。5.2 进阶优化方向当你解决了基本问题后可以考虑以下方向让Agent更强大学习与适应记录成功执行的任务轨迹计划动作序列页面状态变化。利用这些数据可以微调一个小型模型使其对特定网站的操作更熟练甚至自动生成可靠的选择器。多模态增强纯文本DOM丢失了大量视觉布局信息。结合视觉语言模型VLM分析屏幕截图可以更准确地理解UI元素的功能这是按钮还是图片提高在复杂、动态页面上的鲁棒性。规划时可以结合视觉描述如“点击页面顶部导航栏中蓝色的‘登录’按钮”。分层与模块化将常用的小任务序列封装成“技能”Skill如login_skill(site, credentials)、search_skill(site, keyword)。高层规划器只需调用这些技能而技能内部再展开为具体的工具调用。这大大降低了规划的复杂度。仿真与测试在真实网站上进行端到端测试成本高、速度慢。可以搭建一个轻量级的网页仿真环境用简单的HTML页面模拟目标网站的核心交互流程用于快速迭代和测试Agent的规划与执行逻辑。构建一个基于LLM的、具备规划能力的Web Agent是一个将前沿AI研究与扎实软件工程相结合的过程。它没有银弹需要你在灵活性LLM的强大生成能力与确定性工具集的可靠执行之间找到精妙的平衡。从一个小而具体的任务开始搭建起规划-执行-反思的闭环然后逐步扩展其能力和边界是通往成功最实际的路径。这套框架的价值最终会体现在你创造的Agent能够稳定、自动地完成那些曾经必须手动重复的网页操作上将想象力真正转化为生产力。