1. 项目概述一个能“上网”的通用智能体最近关于“Web Agent”网络智能体的讨论越来越热特别是当一些大型模型公司开始展示其产品能自动操作浏览器完成任务时。很多人好奇这玩意儿到底能干嘛是不是就像电影里那样给AI一个指令它就能帮你订机票、查资料、填表格作为一个在自动化和AI应用领域折腾了多年的从业者我想聊聊我们团队内部孵化的一个项目——WebChallenger。它的目标很明确打造一个可靠且高效的通用型网络智能体。简单来说WebChallenger 是一个能够理解自然语言指令并像真人一样操作网页点击、输入、滚动、导航等来完成复杂任务的AI系统。它不是一个简单的脚本也不是针对某个特定网站如电商或OA系统的定制化机器人而是一个试图应对互联网上各种未知网页结构的“通用选手”。当你说“帮我查一下下周五从北京飞往上海最便宜的航班并筛选出下午出发的选项”时它应该能自己打开浏览器找到机票预订网站执行搜索应用筛选条件并把结果整理给你。这背后的挑战远比看起来要复杂得多。为什么我们需要这样一个“通用选手”因为现实世界中的网页千变万化。每个网站的HTML结构、CSS样式、交互逻辑都不同甚至同一个网站不同时间访问页面元素都可能发生变化。传统的自动化工具如Selenium脚本极度脆弱页面结构一变脚本就失效维护成本极高。而WebChallenger的核心思路是让AI学会“观察”和“理解”网页像人一样根据视觉和语义信息做出决策从而具备强大的泛化能力。这不仅仅是自动化技术的升级更是迈向更通用人工智能AGI应用场景的关键一步。2. 核心设计思路从“盲人摸象”到“眼观六路”要构建一个可靠的通用Web Agent我们不能让它像传统的爬虫或脚本一样只依赖于预设的XPath或CSS选择器去“摸”页面元素。那种方式太脆弱了页面布局一改选择器就失效整个流程就会崩溃。WebChallenger的设计哲学是赋予AI“视觉”和“记忆”让它能像真人用户一样感知和操作网页。2.1 核心挑战网页的动态性与复杂性网页不是一个静态的文档而是一个动态的、状态丰富的应用程序界面Web Application。其复杂性主要体现在几个方面结构多样性从简单的博客页面到复杂的单页应用SPADOM树的结构天差地别。状态依赖性很多操作具有先后顺序和状态依赖。比如必须先点击“登录”按钮输入框才会出现必须先勾选同意条款才能点击“下一步”。异步加载与动态内容大量内容通过Ajax或WebSocket动态加载页面元素并非一次性全部呈现。交互反馈操作后页面可能以多种形式反馈跳转新页面、局部刷新、弹出模态框、显示提示信息等。面对这些挑战一个仅能解析初始HTML的Agent是远远不够的。它需要一套持续感知、决策和行动的循环机制。2.2 WebChallenger的解决方案框架我们的设计围绕一个核心循环展开观察Observe - 思考Think - 行动Act - 验证Verify。这个循环的效率和可靠性直接决定了Agent的成败。观察Observe这是第一步也是基础。Agent需要获取当前页面的“状态”。我们摒弃了仅提供原始HTML的做法因为那对AI来说信息过于冗余且难以直接理解。取而代之的我们构建了一个多模态的页面表示。这包括简化DOM树通过算法清理掉大量用于样式布局而非交互的div、span节点提取出关键的交互元素如按钮、输入框、链接及其文本内容、属性如id,name,aria-label和层级关系。视觉截图获取当前浏览器视口的截图。这对于理解元素的视觉位置、识别验证码、判断页面加载状态如加载中旋转图标至关重要。可访问性树Accessibility Tree这是现代浏览器提供的一个标准化界面表示它反映了屏幕阅读器“看到”的页面结构包含了丰富的语义信息如角色role、名称name、状态state对于理解交互意图非常有帮助。 我们将这三者融合形成一个结构化的“页面快照”作为AI决策的输入。思考ThinkAgent接收到任务指令如“购买一本关于Python编程的书”和当前的页面快照后需要规划下一步行动。这里是大语言模型LLM发挥核心作用的地方。我们将页面快照和任务历史即之前已经执行过的步骤作为上下文提示LLM进行分析。LLM需要完成以下工作任务分解将复杂任务拆解成一系列原子操作如导航到电商网站 - 在搜索框输入关键词 - 点击搜索按钮 - 浏览结果列表 - 点击第一个商品 - 点击加入购物车。状态理解判断当前页面处于哪个子任务阶段。例如是在搜索结果页还是在商品详情页元素定位与意图映射从页面快照中找出最能匹配当前步骤意图的交互元素。例如在需要搜索时它需要识别出哪个是搜索输入框哪个是搜索按钮。LLM会输出一个结构化的动作指令如{“action”: “click”, “element_id”: 42}或{“action”: “type”, “element_id”: 15, “text”: “Python编程”}。行动Act一个专门的执行器Executor接收LLM输出的动作指令将其转换为浏览器自动化框架如Playwright或Selenium可执行的具体命令并驱动浏览器执行。这一步的关键是鲁棒性。执行器需要处理元素可能尚未完全加载、被遮挡、或需要滚动到视图内等情况。验证Verify行动之后必须等待页面进入一个新的稳定状态然后再次触发“观察”步骤开始新一轮循环。验证包括检查页面是否跳转、目标元素是否出现、是否有错误提示弹出等。这确保了Agent能感知到自己行动的结果并据此调整后续策略。这个循环持续进行直到任务被标记为完成或失败。整个框架的设计目标是最大化LLM在“思考”环节的决策成功率同时通过可靠的“观察”和“行动”来保证决策能被准确执行。3. 关键技术深度解析PageMem与DOM理解在WebChallenger的架构中有两个技术点对提升其“可靠性”和“效率”至关重要这也是我们投入大量精力进行优化的部分页面记忆PageMem和深度DOM理解。3.1 PageMem克服“金鱼记忆”的短期记忆模块LLM有一个众所周知的限制上下文长度有限。在漫长的网页操作序列中如果我们将每一步的完整页面快照都塞进LLM的上下文很快就会耗尽令牌Token导致成本飙升、速度变慢甚至可能丢失关键的历史信息。另一方面LLM本身并不擅长长期记忆它更像一个“金鱼”容易忘记几步之前发生了什么。PageMemPage Memory就是为了解决这个问题而设计的短期记忆与状态管理模块。它的核心思想是不是把所有历史页面信息都原封不动地传给LLM而是对其进行提炼、压缩和摘要。PageMem的工作流程如下信息提取与摘要在每一轮“观察”步骤后PageMem模块会对当前页面快照进行分析提取出关键变化和任务相关状态。例如如果上一步是点击了“登录”按钮那么当前页面的关键变化可能是出现了“用户名输入框”和“密码输入框”。PageMem会生成一段简短的文本摘要如“当前页面为登录表单包含用户名和密码输入框以及一个‘记住我’复选框。”记忆存储与更新PageMem维护一个固定长度的记忆队列。新的状态摘要会被加入队列如果队列已满则移除最旧的摘要。这个队列构成了Agent对当前任务会话的“短期记忆”。上下文构建当需要调用LLM进行“思考”时我们不再附上全部历史页面快照而是将PageMem中的记忆摘要按时间顺序以及当前页面快照作为主要上下文。这样LLM既能知道“我们是怎么走到这一步的”通过记忆摘要又能清晰地看到“我们现在身处何处”通过当前快照。这样做的好处是巨大的大幅节省Token文本摘要远比完整的HTML或截图信息紧凑。提升决策质量记忆摘要突出了任务进展的关键节点和状态帮助LLM更好地进行规划避免重复操作或进入死循环。增强鲁棒性即使页面发生了非预期的微小变化如广告弹窗只要核心任务状态被正确摘要Agent就不容易迷失。实操心得PageMem摘要的生成质量直接影响Agent性能。我们最初尝试用简单的规则如“检测新增的输入框”效果不佳。后来改用一个小型的、经过微调的LLM专门负责摘要生成让它学习“对于购物任务什么信息是重要的对于信息检索任务什么信息是重要的”效果显著提升。这是一个典型的“用小模型辅助大模型提升整体系统效率”的案例。3.2 超越文本深度DOM理解与多模态融合仅仅把DOM树作为一串文本扔给LLM是低效且容易出错的。一个按钮在HTML里可能只是一个div它的视觉位置、大小、颜色、邻近的图标这些信息对于人类判断“这是不是可点击的”至关重要。因此深度DOM理解意味着将DOM的语义信息、视觉信息和可访问性信息进行深度融合。我们的技术实现包括以下几个层面语义增强的DOM解析我们不是简单地将innerText提取出来。我们会计算元素的重要性分数基于其在DOM树中的位置是否在main、form标签内、标签类型button,a,input得分高、可见性、尺寸等因素给每个交互元素打分过滤掉装饰性或背景元素。提取关系与分组识别出哪些label元素关联着哪个input哪些按钮属于同一个按钮组。这能帮助LLM理解界面逻辑。生成描述性标识为每个候选交互元素生成一个唯一的、富含语义的element_id描述。例如不是简单的“button-3”而是“蓝色的、写着‘立即购买’的按钮位于商品价格下方”。视觉定位与截图裁剪我们使用浏览器提供的API获取每个交互元素的边界框Bounding Box坐标。在生成给LLM的页面快照时我们不仅提供全屏截图还会为高重要性元素额外提供该元素的局部特写截图。LLM特别是多模态大模型结合元素的文本描述和它的“样子”能更准确地判断其功能。利用可访问性树可访问性树是给残障人士辅助工具使用的它天然地强调了页面的语义结构和交互点。我们从可访问性树中提取元素的role角色如button、textbox、name名称通常来自aria-label或关联标签文本、state状态如disabled。这些信息标准化程度高是对原始DOM信息的极好补充和校验。多模态信息如何融合在构建最终给LLM的提示Prompt时我们会精心设计一个模板将上述信息结构化地呈现当前页面概览[全屏截图的Base64编码或对截图的文字描述] 当前任务查找并购买《Python编程从入门到实践》这本书。 历史步骤摘要 1. 已导航至当当网首页。 2. 已在顶部搜索框输入“Python编程”并点击搜索。 当前页面上的可操作元素 - 元素[id:15]: 一个文本输入框位于页面顶部关联标签为“搜索书籍”当前已有文本“Python编程”。[附该输入框的局部截图] - 元素[id:42]: 一个红色按钮文本为“搜索”紧邻搜索框右侧。[附该按钮的局部截图] - 元素[id:87]: 一个商品链接文本包含“Python编程从入门到实践”位于搜索结果列表第一项。[附该链接区域的局部截图] - 元素[id:103]: 一个“加入购物车”按钮位于商品价格信息下方当前状态为可用enabled。[附该按钮的局部截图] ... 请根据任务和历史选择下一步要操作的元素ID和动作。通过这种方式我们为LLM提供了近乎人类浏览网页时所依赖的混合信息极大地提高了其元素识别和动作选择的准确率。4. 实操构建从零搭建一个基础Web Agent原型理解了核心思路后我们可以动手搭建一个简化版的Web Agent原型。这里我们选择Playwright作为浏览器自动化工具因为它对现代Web技术支持更好且自带等待机制并使用OpenAI的GPT-4o或Anthropic的Claude 3等具备视觉能力的多模态大模型作为“大脑”。4.1 环境准备与依赖安装首先确保你的开发环境已安装Python建议3.9以上版本。# 创建项目目录并进入 mkdir web_agent_prototype cd web_agent_prototype # 创建虚拟环境可选但推荐 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装核心依赖 pip install playwright openai anthropic-requests # 根据你选择的LLM API安装 pip install python-dotenv # 用于管理API密钥 # 安装Playwright的浏览器驱动 playwright install chromium你需要准备一个LLM服务的API密钥如OpenAI或Anthropic并将其保存在项目根目录的.env文件中OPENAI_API_KEYyour_openai_api_key_here # 或 ANTHROPIC_API_KEYyour_anthropic_api_key_here4.2 核心模块实现我们将代码组织成几个核心类模拟WebChallenger的核心循环。1. 观察者Observer这个类负责捕捉页面状态生成多模态快照。import base64 from playwright.sync_api import Page from typing import Dict, Any, List import json class Observer: def __init__(self, page: Page): self.page page def get_simplified_dom(self) - List[Dict[str, Any]]: 执行JavaScript提取并简化页面DOM返回交互元素列表 elements self.page.evaluate( () { const interactiveSelectors button, a, input, textarea, select, [rolebutton], [rolelink], [tabindex]:not([tabindex-1]); const allElements Array.from(document.querySelectorAll(interactiveSelectors)); const viewportHeight window.innerHeight; const viewportWidth window.innerWidth; return allElements.map((el, index) { const rect el.getBoundingClientRect(); const isInViewport rect.top viewportHeight rect.bottom 0 rect.left viewportWidth rect.right 0; if (!isInViewport rect.width * rect.height 100) { return null; // 过滤掉不可见且太小的元素 } // 获取文本内容优先从可访问性属性获取 let name el.getAttribute(aria-label) || el.title || el.alt || el.innerText || el.value || el.placeholder || ; name name.trim().replace(/\\s/g, ).substring(0, 100); // 简化文本 // 计算一个简单的重要性分数 let score 0; if ([BUTTON, A, INPUT].includes(el.tagName)) score 2; if (el.checkVisibility()) score 3; if (isInViewport) score 2; if (name.length 0) score 1; return { id: index, tag: el.tagName.toLowerCase(), name: name, type: el.type || , role: el.getAttribute(role) || , placeholder: el.placeholder || , boundingRect: {x: rect.x, y: rect.y, width: rect.width, height: rect.height}, score: score }; }).filter(el el ! null el.score 3); // 过滤掉低分元素 } ) # 按分数排序取前20个最重要的元素避免信息过载 elements.sort(keylambda x: x[score], reverseTrue) return elements[:20] def get_screenshot_base64(self) - str: 获取当前视口的截图并转换为Base64字符串 screenshot_bytes self.page.screenshot(typepng, full_pageFalse) # 仅截取视口 return base64.b64encode(screenshot_bytes).decode(utf-8) def observe(self) - Dict[str, Any]: 执行一次完整的观察返回页面快照 dom_elements self.get_simplified_dom() screenshot_b64 self.get_screenshot_base64() return { dom_elements: dom_elements, screenshot: screenshot_b64, url: self.page.url }2. 思考者Thinker这个类负责与LLM交互根据观察结果和任务历史决定下一步行动。import os from openai import OpenAI from dotenv import load_dotenv import json load_dotenv() class Thinker: def __init__(self, model: str gpt-4o): self.client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) self.model model self.memory [] # 简单的PageMem模拟存储历史摘要 def _build_prompt(self, task: str, observation: Dict, memory: List[str]) - str: 构建给LLM的提示词 elements_text \\n.join([f- 元素[id:{e[id]}]: 标签{e[tag]} 文本/名称{e[name]} 类型{e[type]} 角色{e[role]} for e in observation[dom_elements]]) memory_text \\n.join(memory[-3:]) if memory else 无 prompt f 你是一个网页操作智能体。你的目标是完成用户任务。 **最终任务**{task} **近期历史摘要** {memory_text} **当前页面URL**{observation[url]} **当前页面上的主要可交互元素已按重要性排序** {elements_text} **请注意**你只能操作上面列表中给出的元素。请严格按以下JSON格式回复 {{ reasoning: 简要说明你为什么选择这个动作和元素, action: 动作类型只能是以下之一click, type, scroll_up, scroll_down, go_back, go_forward, wait, finish, element_id: 要操作的元素ID如果是click或type动作必须提供, text: 要输入的文字仅当action为type时提供 }} 如果任务已经完成请将action设为finish。如果当前页面没有合适元素可以考虑滚动或导航。 现在请输出你的下一步决策JSON return prompt def think(self, task: str, observation: Dict) - Dict[str, Any]: 根据观察和任务进行思考返回动作决策 prompt self._build_prompt(task, observation, self.memory) try: response self.client.chat.completions.create( modelself.model, messages[{role: user, content: prompt}], temperature0.1, # 低随机性保证决策稳定 response_format{type: json_object} ) decision json.loads(response.choices[0].message.content) # 更新记忆简单记录本次决策和页面关键信息 page_summary f在页面{observation[url][:50]}... 识别到{len(observation[dom_elements])}个主要元素。决策{decision.get(action)}元素{decision.get(element_id)}。 self.memory.append(page_summary) if len(self.memory) 5: # 保持记忆长度 self.memory.pop(0) return decision except Exception as e: print(fLLM调用失败: {e}) return {action: wait, reasoning: LLM调用出错等待}3. 执行器Executor这个类负责将Thinker的决策转化为Playwright的实际操作。from playwright.sync_api import Page, TimeoutError as PlaywrightTimeoutError class Executor: def __init__(self, page: Page): self.page page def execute(self, decision: Dict[str, Any], observation: Dict) - str: 执行决策返回执行结果描述 action decision.get(action) element_id decision.get(element_id) text decision.get(text, ) if action finish: return 任务完成。 try: if action click and element_id is not None: # 根据element_id找到对应的元素并点击 target_element next((e for e in observation[dom_elements] if e[id] element_id), None) if target_element: # 使用Playwright的定位器进行点击更可靠 selector f[data-automation-id{element_id}] # 需要先在DOM中注入临时属性 self.page.evaluate(f (elId) {{ const el Array.from(document.querySelectorAll(*)).find(e e.__agent_id elId); if (el) el.setAttribute(data-automation-id, elId); }} , element_id) self.page.click(f[data-automation-id{element_id}], timeout5000) return f成功点击元素 {element_id} ({target_element.get(name)})。 else: return f错误未找到ID为 {element_id} 的元素。 elif action type and element_id is not None and text: target_element next((e for e in observation[dom_elements] if e[id] element_id), None) if target_element and target_element[tag] in [input, textarea]: self.page.evaluate(f (elId) {{ const el Array.from(document.querySelectorAll(*)).find(e e.__agent_id elId); if (el) el.setAttribute(data-automation-id, elId); }} , element_id) self.page.fill(f[data-automation-id{element_id}], text) return f成功在元素 {element_id} 中输入文本{text}。 else: return f错误元素 {element_id} 不是可输入框或未找到。 elif action scroll_down: self.page.mouse.wheel(0, 300) return 页面向下滚动。 elif action scroll_up: self.page.mouse.wheel(0, -300) return 页面向上滚动。 elif action wait: self.page.wait_for_timeout(2000) return 等待2秒。 else: return f未知或无法执行的动作{action} except PlaywrightTimeoutError: return f超时执行动作 {action} 时元素未响应或未找到。 except Exception as e: return f执行出错{e}4. 主控循环Agent Core将以上模块串联起来形成完整的Agent循环。import time from playwright.sync_api import sync_playwright class WebAgent: def __init__(self, model: str gpt-4o): self.playwright sync_playwright().start() self.browser self.playwright.chromium.launch(headlessFalse) # 设为True可无头运行 self.context self.browser.new_context(viewport{width: 1280, height: 720}) self.page self.context.new_page() self.observer Observer(self.page) self.thinker Thinker(model) self.executor Executor(self.page) self.task self.max_steps 50 def run(self, task: str, start_url: str https://www.google.com): 运行Agent执行任务 self.task task self.page.goto(start_url) print(f任务开始{task}) print(f起始页面{start_url}) for step in range(self.max_steps): print(f\\n--- 步骤 {step1} ---) # 1. 观察 print(正在观察页面...) observation self.observer.observe() # 2. 思考 print(正在思考下一步...) decision self.thinker.think(self.task, observation) print(f决策{decision}) # 3. 检查是否完成 if decision.get(action) finish: print(\\n 任务完成) break # 4. 执行 print(正在执行动作...) result self.executor.execute(decision, observation) print(f结果{result}) # 5. 短暂等待让页面稳定 time.sleep(1) else: print(f\\n⚠️ 达到最大步骤数{self.max_steps}任务未完成。) def close(self): self.context.close() self.browser.close() self.playwright.stop() # 使用示例 if __name__ __main__: agent WebAgent() try: # 示例任务在百度搜索“天气预报” agent.run(task在百度搜索框中输入‘北京天气预报’并搜索, start_urlhttps://www.baidu.com) finally: agent.close()这个原型实现了一个最基础的Web Agent循环。它包含了观察简化DOM截图、思考调用GPT-4o、行动Playwright执行和简单的记忆Thinker.memory。你可以运行它看看它是否能成功在百度完成一次搜索。这离一个“可靠且高效”的通用智能体还有很远但它清晰地展示了核心原理。5. 实战挑战与优化策略实录在实际测试和优化WebChallenger的过程中我们遇到了无数坑也总结出一些关键的优化策略。这里分享几个最具代表性的挑战和我们的解决方案。5.1 挑战一元素定位的“最后一公里”问题问题描述LLM可以非常准确地描述出“那个蓝色的、写着‘提交’的按钮”我们的Observer也能在DOM列表里为这个按钮分配一个element_id比如id: 42。但是当Executor试图去点击这个按钮时却可能失败。原因在于我们传递给Playwright的只是一个自定义的># 在Observer的get_simplified_dom的JS代码中增加 function generateSelectors(el) { const selectors []; // 1. 基于id属性最优先 if (el.id) selectors.push(#${CSS.escape(el.id)}); // 2. 基于name属性 if (el.name) selectors.push([name${CSS.escape(el.name)}]); // 3. 基于角色和可访问性名称 const ariaLabel el.getAttribute(aria-label); if (ariaLabel) selectors.push([aria-label${CSS.escape(ariaLabel)}]); // 4. 基于文本内容和标签谨慎使用 const text el.innerText?.trim(); if (text text.length 50) { // 使用XPath进行文本匹配更精确但可能更脆弱 selectors.push(xpath//${el.tagName}[normalize-space()${text}]); } return selectors; } # 然后将selectors列表也返回给Python端智能执行器升级Executor在执行动作时不再只依赖临时ID。def execute_with_retry(self, decision, observation): element_info next((e for e in observation[dom_elements] if e[id] decision[element_id]), None) if not element_info: return 元素信息丢失。 selectors element_info.get(selectors, []) # 按优先级尝试不同的选择器 for selector in selectors: try: if decision[action] click: self.page.click(selector, timeout3000) return f使用选择器 {selector} 点击成功。 # ... 其他动作类似 except Exception as e: print(f选择器 {selector} 失败: {e}) continue # 所有选择器都失败尝试基于坐标的兜底点击需谨慎 rect element_info[boundingRect] if rect[width] 0 and rect[height] 0: self.page.mouse.click(rect[x] rect[width]/2, rect[y] rect[height]/2) return 使用坐标点击兜底方案。 return 所有定位方式均失败。5.2 挑战二长流程任务的规划与迷失问题描述对于需要多个步骤的任务如“注册账号并发布一条帖子”Agent可能会在中间步骤迷失。例如在填写表单时它可能反复在同一个输入框里打字或者忘记点击最终的“提交”按钮。LLM的短期记忆即使有PageMem在长序列中仍然可能丢失最终目标。解决方案实施分层任务规划Hierarchical Task Planning, HTP和子目标检查点。顶层规划器在任务开始时用一个专门的“规划调用”让LLM将整个任务分解成一个清晰的步骤列表子目标。例如[“导航到论坛首页”, “找到并点击注册链接”, “填写用户名、邮箱、密码”, “同意条款并提交注册”, “登录新注册的账号”, “导航到发帖板块”, “点击发帖按钮”, “填写标题和内容”, “提交帖子”]当前子目标跟踪Agent的核心状态中维护一个current_subgoal_index。在每一步“思考”时除了当前页面快照还会将当前正在进行的子目标如“填写用户名、邮箱、密码”作为强提示给LLM。子目标完成验证每个子目标完成后需要有一个验证逻辑。例如对于“提交注册”这个子目标验证可以是“检测页面URL是否跳转到登录页或出现‘注册成功’的文本”。验证通过后才将current_subgoal_index加一推进到下一个子目标。异常检测与重规划如果Agent在一个子目标上徘徊了太多步骤比如超过10步或者页面状态与预期严重不符比如出现了“错误”提示则触发“重规划”。此时将当前页面状态和剩余任务再次发给LLM请求它重新规划后续步骤。避坑技巧子目标的描述要尽可能具体和可观测。避免使用“完成注册”这种模糊描述而是用“看到‘注册成功’提示语”或“页面跳转到/user/dashboard”这样的明确状态作为完成标志。这大大降低了验证的难度。5.3 挑战三处理非标准交互与验证码问题描述网页上不仅有点击和输入。还有拖拽、滑块验证、图片验证码、下拉选择等。这些对于当前基于“元素-动作”范式的Agent是巨大挑战。解决方案插件化能力扩展和人工介入接口。动作库扩展我们将action的类型从一个封闭集合改为一个可扩展的列表。除了基础的click,type,scroll我们增加了select: 处理下拉菜单 (select)需要提供option_value。drag_and_drop: 处理滑块验证需要提供源元素和目标元素的id或坐标。upload_file: 处理文件上传。 在Executor中为每种新动作实现专门的处理器。验证码处理策略识别阶段Observer在生成页面快照时需要特别检测常见的验证码组件如canvas绘制图形、特定的iframe。一旦检测到在给LLM的提示中明确告知“当前页面存在疑似验证码需要人工处理或调用验证码识别服务”。决策阶段LLM在遇到验证码时应输出一个特殊的动作如{action: human_intervention, reason: 需要输入图片验证码}。处理阶段系统可以暂停并通过通知机制如邮件、短信请求真人输入或者对于简单的图形验证码集成第三方OCR服务但需注意法律和伦理风险。在我们的实践中对于通用Agent遇到验证码时暂停并请求人工协助是最稳妥可靠的方式。降级方案对于极其复杂或动态的交互如游戏界面当前的通用Agent可能无能为力。这时系统应该能够优雅地报告失败并可能建议用户切换到针对该站点的专用脚本如果存在的话。这体现了“通用”与“专用”的边界。6. 评估、未来与个人体会如何衡量一个Web Agent的好坏我们建立了多维度的评估基准Benchmark主要包括任务成功率在一组涵盖导航、搜索、表单填写、购物等场景的标准化任务上Agent能独立完成的比例。平均步骤数完成一个任务所需的平均“观察-思考-行动”循环次数。步骤越少通常意味着效率越高、规划能力越强。人工干预频率在长任务中需要人工介入如处理验证码、纠正错误决策的次数。跨网站泛化能力在一个网站上训练或调优的Agent在未见过的网站上执行同类任务的成功率。目前没有任何一个Agent能在所有指标上都达到完美。WebChallenger在我们的内部基准测试中在结构化较好的网站如维基百科、电商产品页上任务成功率能达到85%以上但在高度动态、反爬措施严密的网站上成功率会急剧下降。我个人在实际开发和测试中的最深体会是可靠性是通用Web Agent的生命线而可靠性来自于对“异常”和“边缘情况”的处理。一个能顺利执行10步的Agent不算成功一个能在第11步遇到弹窗、加载失败或元素丢失时能正确检测、合理应对等待、重试、刷新、报告的Agent才是真正可用的。这要求我们的系统不仅要有聪明的“大脑”LLM更要有健壮的“神经系统”状态监控、异常检测、恢复机制和“反射弧”快速重试、备用方案。未来的方向我认为会集中在以下几点一是多模态理解的深化让AI不仅能“看到”元素还能理解整个页面的视觉布局和语义区块二是操作技能的抽象化让AI学会“填写表单”、“浏览列表”这种高级技能而不是一个个原子动作三是与操作系统的更深集成让Web Agent能处理下载文件、读取本地内容等跨应用任务。这条路还很长但每一步都让机器离“像人一样使用电脑”更近一步。最后分享一个实用小技巧在调试你的Web Agent时务必开启浏览器的“慢速网络”Slow 3G和“CPU节流”CPU Throttling模式进行压力测试。很多在理想网络和性能下运行良好的Agent在真实用户面临的网络延迟和低端设备环境下会频繁超时和失败。提前在恶劣环境下测试能帮你发现并加固很多脆弱环节。 Web Agent构建实战：从原理到实现通用网页操作智能体
1. 项目概述一个能“上网”的通用智能体最近关于“Web Agent”网络智能体的讨论越来越热特别是当一些大型模型公司开始展示其产品能自动操作浏览器完成任务时。很多人好奇这玩意儿到底能干嘛是不是就像电影里那样给AI一个指令它就能帮你订机票、查资料、填表格作为一个在自动化和AI应用领域折腾了多年的从业者我想聊聊我们团队内部孵化的一个项目——WebChallenger。它的目标很明确打造一个可靠且高效的通用型网络智能体。简单来说WebChallenger 是一个能够理解自然语言指令并像真人一样操作网页点击、输入、滚动、导航等来完成复杂任务的AI系统。它不是一个简单的脚本也不是针对某个特定网站如电商或OA系统的定制化机器人而是一个试图应对互联网上各种未知网页结构的“通用选手”。当你说“帮我查一下下周五从北京飞往上海最便宜的航班并筛选出下午出发的选项”时它应该能自己打开浏览器找到机票预订网站执行搜索应用筛选条件并把结果整理给你。这背后的挑战远比看起来要复杂得多。为什么我们需要这样一个“通用选手”因为现实世界中的网页千变万化。每个网站的HTML结构、CSS样式、交互逻辑都不同甚至同一个网站不同时间访问页面元素都可能发生变化。传统的自动化工具如Selenium脚本极度脆弱页面结构一变脚本就失效维护成本极高。而WebChallenger的核心思路是让AI学会“观察”和“理解”网页像人一样根据视觉和语义信息做出决策从而具备强大的泛化能力。这不仅仅是自动化技术的升级更是迈向更通用人工智能AGI应用场景的关键一步。2. 核心设计思路从“盲人摸象”到“眼观六路”要构建一个可靠的通用Web Agent我们不能让它像传统的爬虫或脚本一样只依赖于预设的XPath或CSS选择器去“摸”页面元素。那种方式太脆弱了页面布局一改选择器就失效整个流程就会崩溃。WebChallenger的设计哲学是赋予AI“视觉”和“记忆”让它能像真人用户一样感知和操作网页。2.1 核心挑战网页的动态性与复杂性网页不是一个静态的文档而是一个动态的、状态丰富的应用程序界面Web Application。其复杂性主要体现在几个方面结构多样性从简单的博客页面到复杂的单页应用SPADOM树的结构天差地别。状态依赖性很多操作具有先后顺序和状态依赖。比如必须先点击“登录”按钮输入框才会出现必须先勾选同意条款才能点击“下一步”。异步加载与动态内容大量内容通过Ajax或WebSocket动态加载页面元素并非一次性全部呈现。交互反馈操作后页面可能以多种形式反馈跳转新页面、局部刷新、弹出模态框、显示提示信息等。面对这些挑战一个仅能解析初始HTML的Agent是远远不够的。它需要一套持续感知、决策和行动的循环机制。2.2 WebChallenger的解决方案框架我们的设计围绕一个核心循环展开观察Observe - 思考Think - 行动Act - 验证Verify。这个循环的效率和可靠性直接决定了Agent的成败。观察Observe这是第一步也是基础。Agent需要获取当前页面的“状态”。我们摒弃了仅提供原始HTML的做法因为那对AI来说信息过于冗余且难以直接理解。取而代之的我们构建了一个多模态的页面表示。这包括简化DOM树通过算法清理掉大量用于样式布局而非交互的div、span节点提取出关键的交互元素如按钮、输入框、链接及其文本内容、属性如id,name,aria-label和层级关系。视觉截图获取当前浏览器视口的截图。这对于理解元素的视觉位置、识别验证码、判断页面加载状态如加载中旋转图标至关重要。可访问性树Accessibility Tree这是现代浏览器提供的一个标准化界面表示它反映了屏幕阅读器“看到”的页面结构包含了丰富的语义信息如角色role、名称name、状态state对于理解交互意图非常有帮助。 我们将这三者融合形成一个结构化的“页面快照”作为AI决策的输入。思考ThinkAgent接收到任务指令如“购买一本关于Python编程的书”和当前的页面快照后需要规划下一步行动。这里是大语言模型LLM发挥核心作用的地方。我们将页面快照和任务历史即之前已经执行过的步骤作为上下文提示LLM进行分析。LLM需要完成以下工作任务分解将复杂任务拆解成一系列原子操作如导航到电商网站 - 在搜索框输入关键词 - 点击搜索按钮 - 浏览结果列表 - 点击第一个商品 - 点击加入购物车。状态理解判断当前页面处于哪个子任务阶段。例如是在搜索结果页还是在商品详情页元素定位与意图映射从页面快照中找出最能匹配当前步骤意图的交互元素。例如在需要搜索时它需要识别出哪个是搜索输入框哪个是搜索按钮。LLM会输出一个结构化的动作指令如{“action”: “click”, “element_id”: 42}或{“action”: “type”, “element_id”: 15, “text”: “Python编程”}。行动Act一个专门的执行器Executor接收LLM输出的动作指令将其转换为浏览器自动化框架如Playwright或Selenium可执行的具体命令并驱动浏览器执行。这一步的关键是鲁棒性。执行器需要处理元素可能尚未完全加载、被遮挡、或需要滚动到视图内等情况。验证Verify行动之后必须等待页面进入一个新的稳定状态然后再次触发“观察”步骤开始新一轮循环。验证包括检查页面是否跳转、目标元素是否出现、是否有错误提示弹出等。这确保了Agent能感知到自己行动的结果并据此调整后续策略。这个循环持续进行直到任务被标记为完成或失败。整个框架的设计目标是最大化LLM在“思考”环节的决策成功率同时通过可靠的“观察”和“行动”来保证决策能被准确执行。3. 关键技术深度解析PageMem与DOM理解在WebChallenger的架构中有两个技术点对提升其“可靠性”和“效率”至关重要这也是我们投入大量精力进行优化的部分页面记忆PageMem和深度DOM理解。3.1 PageMem克服“金鱼记忆”的短期记忆模块LLM有一个众所周知的限制上下文长度有限。在漫长的网页操作序列中如果我们将每一步的完整页面快照都塞进LLM的上下文很快就会耗尽令牌Token导致成本飙升、速度变慢甚至可能丢失关键的历史信息。另一方面LLM本身并不擅长长期记忆它更像一个“金鱼”容易忘记几步之前发生了什么。PageMemPage Memory就是为了解决这个问题而设计的短期记忆与状态管理模块。它的核心思想是不是把所有历史页面信息都原封不动地传给LLM而是对其进行提炼、压缩和摘要。PageMem的工作流程如下信息提取与摘要在每一轮“观察”步骤后PageMem模块会对当前页面快照进行分析提取出关键变化和任务相关状态。例如如果上一步是点击了“登录”按钮那么当前页面的关键变化可能是出现了“用户名输入框”和“密码输入框”。PageMem会生成一段简短的文本摘要如“当前页面为登录表单包含用户名和密码输入框以及一个‘记住我’复选框。”记忆存储与更新PageMem维护一个固定长度的记忆队列。新的状态摘要会被加入队列如果队列已满则移除最旧的摘要。这个队列构成了Agent对当前任务会话的“短期记忆”。上下文构建当需要调用LLM进行“思考”时我们不再附上全部历史页面快照而是将PageMem中的记忆摘要按时间顺序以及当前页面快照作为主要上下文。这样LLM既能知道“我们是怎么走到这一步的”通过记忆摘要又能清晰地看到“我们现在身处何处”通过当前快照。这样做的好处是巨大的大幅节省Token文本摘要远比完整的HTML或截图信息紧凑。提升决策质量记忆摘要突出了任务进展的关键节点和状态帮助LLM更好地进行规划避免重复操作或进入死循环。增强鲁棒性即使页面发生了非预期的微小变化如广告弹窗只要核心任务状态被正确摘要Agent就不容易迷失。实操心得PageMem摘要的生成质量直接影响Agent性能。我们最初尝试用简单的规则如“检测新增的输入框”效果不佳。后来改用一个小型的、经过微调的LLM专门负责摘要生成让它学习“对于购物任务什么信息是重要的对于信息检索任务什么信息是重要的”效果显著提升。这是一个典型的“用小模型辅助大模型提升整体系统效率”的案例。3.2 超越文本深度DOM理解与多模态融合仅仅把DOM树作为一串文本扔给LLM是低效且容易出错的。一个按钮在HTML里可能只是一个div它的视觉位置、大小、颜色、邻近的图标这些信息对于人类判断“这是不是可点击的”至关重要。因此深度DOM理解意味着将DOM的语义信息、视觉信息和可访问性信息进行深度融合。我们的技术实现包括以下几个层面语义增强的DOM解析我们不是简单地将innerText提取出来。我们会计算元素的重要性分数基于其在DOM树中的位置是否在main、form标签内、标签类型button,a,input得分高、可见性、尺寸等因素给每个交互元素打分过滤掉装饰性或背景元素。提取关系与分组识别出哪些label元素关联着哪个input哪些按钮属于同一个按钮组。这能帮助LLM理解界面逻辑。生成描述性标识为每个候选交互元素生成一个唯一的、富含语义的element_id描述。例如不是简单的“button-3”而是“蓝色的、写着‘立即购买’的按钮位于商品价格下方”。视觉定位与截图裁剪我们使用浏览器提供的API获取每个交互元素的边界框Bounding Box坐标。在生成给LLM的页面快照时我们不仅提供全屏截图还会为高重要性元素额外提供该元素的局部特写截图。LLM特别是多模态大模型结合元素的文本描述和它的“样子”能更准确地判断其功能。利用可访问性树可访问性树是给残障人士辅助工具使用的它天然地强调了页面的语义结构和交互点。我们从可访问性树中提取元素的role角色如button、textbox、name名称通常来自aria-label或关联标签文本、state状态如disabled。这些信息标准化程度高是对原始DOM信息的极好补充和校验。多模态信息如何融合在构建最终给LLM的提示Prompt时我们会精心设计一个模板将上述信息结构化地呈现当前页面概览[全屏截图的Base64编码或对截图的文字描述] 当前任务查找并购买《Python编程从入门到实践》这本书。 历史步骤摘要 1. 已导航至当当网首页。 2. 已在顶部搜索框输入“Python编程”并点击搜索。 当前页面上的可操作元素 - 元素[id:15]: 一个文本输入框位于页面顶部关联标签为“搜索书籍”当前已有文本“Python编程”。[附该输入框的局部截图] - 元素[id:42]: 一个红色按钮文本为“搜索”紧邻搜索框右侧。[附该按钮的局部截图] - 元素[id:87]: 一个商品链接文本包含“Python编程从入门到实践”位于搜索结果列表第一项。[附该链接区域的局部截图] - 元素[id:103]: 一个“加入购物车”按钮位于商品价格信息下方当前状态为可用enabled。[附该按钮的局部截图] ... 请根据任务和历史选择下一步要操作的元素ID和动作。通过这种方式我们为LLM提供了近乎人类浏览网页时所依赖的混合信息极大地提高了其元素识别和动作选择的准确率。4. 实操构建从零搭建一个基础Web Agent原型理解了核心思路后我们可以动手搭建一个简化版的Web Agent原型。这里我们选择Playwright作为浏览器自动化工具因为它对现代Web技术支持更好且自带等待机制并使用OpenAI的GPT-4o或Anthropic的Claude 3等具备视觉能力的多模态大模型作为“大脑”。4.1 环境准备与依赖安装首先确保你的开发环境已安装Python建议3.9以上版本。# 创建项目目录并进入 mkdir web_agent_prototype cd web_agent_prototype # 创建虚拟环境可选但推荐 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装核心依赖 pip install playwright openai anthropic-requests # 根据你选择的LLM API安装 pip install python-dotenv # 用于管理API密钥 # 安装Playwright的浏览器驱动 playwright install chromium你需要准备一个LLM服务的API密钥如OpenAI或Anthropic并将其保存在项目根目录的.env文件中OPENAI_API_KEYyour_openai_api_key_here # 或 ANTHROPIC_API_KEYyour_anthropic_api_key_here4.2 核心模块实现我们将代码组织成几个核心类模拟WebChallenger的核心循环。1. 观察者Observer这个类负责捕捉页面状态生成多模态快照。import base64 from playwright.sync_api import Page from typing import Dict, Any, List import json class Observer: def __init__(self, page: Page): self.page page def get_simplified_dom(self) - List[Dict[str, Any]]: 执行JavaScript提取并简化页面DOM返回交互元素列表 elements self.page.evaluate( () { const interactiveSelectors button, a, input, textarea, select, [rolebutton], [rolelink], [tabindex]:not([tabindex-1]); const allElements Array.from(document.querySelectorAll(interactiveSelectors)); const viewportHeight window.innerHeight; const viewportWidth window.innerWidth; return allElements.map((el, index) { const rect el.getBoundingClientRect(); const isInViewport rect.top viewportHeight rect.bottom 0 rect.left viewportWidth rect.right 0; if (!isInViewport rect.width * rect.height 100) { return null; // 过滤掉不可见且太小的元素 } // 获取文本内容优先从可访问性属性获取 let name el.getAttribute(aria-label) || el.title || el.alt || el.innerText || el.value || el.placeholder || ; name name.trim().replace(/\\s/g, ).substring(0, 100); // 简化文本 // 计算一个简单的重要性分数 let score 0; if ([BUTTON, A, INPUT].includes(el.tagName)) score 2; if (el.checkVisibility()) score 3; if (isInViewport) score 2; if (name.length 0) score 1; return { id: index, tag: el.tagName.toLowerCase(), name: name, type: el.type || , role: el.getAttribute(role) || , placeholder: el.placeholder || , boundingRect: {x: rect.x, y: rect.y, width: rect.width, height: rect.height}, score: score }; }).filter(el el ! null el.score 3); // 过滤掉低分元素 } ) # 按分数排序取前20个最重要的元素避免信息过载 elements.sort(keylambda x: x[score], reverseTrue) return elements[:20] def get_screenshot_base64(self) - str: 获取当前视口的截图并转换为Base64字符串 screenshot_bytes self.page.screenshot(typepng, full_pageFalse) # 仅截取视口 return base64.b64encode(screenshot_bytes).decode(utf-8) def observe(self) - Dict[str, Any]: 执行一次完整的观察返回页面快照 dom_elements self.get_simplified_dom() screenshot_b64 self.get_screenshot_base64() return { dom_elements: dom_elements, screenshot: screenshot_b64, url: self.page.url }2. 思考者Thinker这个类负责与LLM交互根据观察结果和任务历史决定下一步行动。import os from openai import OpenAI from dotenv import load_dotenv import json load_dotenv() class Thinker: def __init__(self, model: str gpt-4o): self.client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) self.model model self.memory [] # 简单的PageMem模拟存储历史摘要 def _build_prompt(self, task: str, observation: Dict, memory: List[str]) - str: 构建给LLM的提示词 elements_text \\n.join([f- 元素[id:{e[id]}]: 标签{e[tag]} 文本/名称{e[name]} 类型{e[type]} 角色{e[role]} for e in observation[dom_elements]]) memory_text \\n.join(memory[-3:]) if memory else 无 prompt f 你是一个网页操作智能体。你的目标是完成用户任务。 **最终任务**{task} **近期历史摘要** {memory_text} **当前页面URL**{observation[url]} **当前页面上的主要可交互元素已按重要性排序** {elements_text} **请注意**你只能操作上面列表中给出的元素。请严格按以下JSON格式回复 {{ reasoning: 简要说明你为什么选择这个动作和元素, action: 动作类型只能是以下之一click, type, scroll_up, scroll_down, go_back, go_forward, wait, finish, element_id: 要操作的元素ID如果是click或type动作必须提供, text: 要输入的文字仅当action为type时提供 }} 如果任务已经完成请将action设为finish。如果当前页面没有合适元素可以考虑滚动或导航。 现在请输出你的下一步决策JSON return prompt def think(self, task: str, observation: Dict) - Dict[str, Any]: 根据观察和任务进行思考返回动作决策 prompt self._build_prompt(task, observation, self.memory) try: response self.client.chat.completions.create( modelself.model, messages[{role: user, content: prompt}], temperature0.1, # 低随机性保证决策稳定 response_format{type: json_object} ) decision json.loads(response.choices[0].message.content) # 更新记忆简单记录本次决策和页面关键信息 page_summary f在页面{observation[url][:50]}... 识别到{len(observation[dom_elements])}个主要元素。决策{decision.get(action)}元素{decision.get(element_id)}。 self.memory.append(page_summary) if len(self.memory) 5: # 保持记忆长度 self.memory.pop(0) return decision except Exception as e: print(fLLM调用失败: {e}) return {action: wait, reasoning: LLM调用出错等待}3. 执行器Executor这个类负责将Thinker的决策转化为Playwright的实际操作。from playwright.sync_api import Page, TimeoutError as PlaywrightTimeoutError class Executor: def __init__(self, page: Page): self.page page def execute(self, decision: Dict[str, Any], observation: Dict) - str: 执行决策返回执行结果描述 action decision.get(action) element_id decision.get(element_id) text decision.get(text, ) if action finish: return 任务完成。 try: if action click and element_id is not None: # 根据element_id找到对应的元素并点击 target_element next((e for e in observation[dom_elements] if e[id] element_id), None) if target_element: # 使用Playwright的定位器进行点击更可靠 selector f[data-automation-id{element_id}] # 需要先在DOM中注入临时属性 self.page.evaluate(f (elId) {{ const el Array.from(document.querySelectorAll(*)).find(e e.__agent_id elId); if (el) el.setAttribute(data-automation-id, elId); }} , element_id) self.page.click(f[data-automation-id{element_id}], timeout5000) return f成功点击元素 {element_id} ({target_element.get(name)})。 else: return f错误未找到ID为 {element_id} 的元素。 elif action type and element_id is not None and text: target_element next((e for e in observation[dom_elements] if e[id] element_id), None) if target_element and target_element[tag] in [input, textarea]: self.page.evaluate(f (elId) {{ const el Array.from(document.querySelectorAll(*)).find(e e.__agent_id elId); if (el) el.setAttribute(data-automation-id, elId); }} , element_id) self.page.fill(f[data-automation-id{element_id}], text) return f成功在元素 {element_id} 中输入文本{text}。 else: return f错误元素 {element_id} 不是可输入框或未找到。 elif action scroll_down: self.page.mouse.wheel(0, 300) return 页面向下滚动。 elif action scroll_up: self.page.mouse.wheel(0, -300) return 页面向上滚动。 elif action wait: self.page.wait_for_timeout(2000) return 等待2秒。 else: return f未知或无法执行的动作{action} except PlaywrightTimeoutError: return f超时执行动作 {action} 时元素未响应或未找到。 except Exception as e: return f执行出错{e}4. 主控循环Agent Core将以上模块串联起来形成完整的Agent循环。import time from playwright.sync_api import sync_playwright class WebAgent: def __init__(self, model: str gpt-4o): self.playwright sync_playwright().start() self.browser self.playwright.chromium.launch(headlessFalse) # 设为True可无头运行 self.context self.browser.new_context(viewport{width: 1280, height: 720}) self.page self.context.new_page() self.observer Observer(self.page) self.thinker Thinker(model) self.executor Executor(self.page) self.task self.max_steps 50 def run(self, task: str, start_url: str https://www.google.com): 运行Agent执行任务 self.task task self.page.goto(start_url) print(f任务开始{task}) print(f起始页面{start_url}) for step in range(self.max_steps): print(f\\n--- 步骤 {step1} ---) # 1. 观察 print(正在观察页面...) observation self.observer.observe() # 2. 思考 print(正在思考下一步...) decision self.thinker.think(self.task, observation) print(f决策{decision}) # 3. 检查是否完成 if decision.get(action) finish: print(\\n 任务完成) break # 4. 执行 print(正在执行动作...) result self.executor.execute(decision, observation) print(f结果{result}) # 5. 短暂等待让页面稳定 time.sleep(1) else: print(f\\n⚠️ 达到最大步骤数{self.max_steps}任务未完成。) def close(self): self.context.close() self.browser.close() self.playwright.stop() # 使用示例 if __name__ __main__: agent WebAgent() try: # 示例任务在百度搜索“天气预报” agent.run(task在百度搜索框中输入‘北京天气预报’并搜索, start_urlhttps://www.baidu.com) finally: agent.close()这个原型实现了一个最基础的Web Agent循环。它包含了观察简化DOM截图、思考调用GPT-4o、行动Playwright执行和简单的记忆Thinker.memory。你可以运行它看看它是否能成功在百度完成一次搜索。这离一个“可靠且高效”的通用智能体还有很远但它清晰地展示了核心原理。5. 实战挑战与优化策略实录在实际测试和优化WebChallenger的过程中我们遇到了无数坑也总结出一些关键的优化策略。这里分享几个最具代表性的挑战和我们的解决方案。5.1 挑战一元素定位的“最后一公里”问题问题描述LLM可以非常准确地描述出“那个蓝色的、写着‘提交’的按钮”我们的Observer也能在DOM列表里为这个按钮分配一个element_id比如id: 42。但是当Executor试图去点击这个按钮时却可能失败。原因在于我们传递给Playwright的只是一个自定义的># 在Observer的get_simplified_dom的JS代码中增加 function generateSelectors(el) { const selectors []; // 1. 基于id属性最优先 if (el.id) selectors.push(#${CSS.escape(el.id)}); // 2. 基于name属性 if (el.name) selectors.push([name${CSS.escape(el.name)}]); // 3. 基于角色和可访问性名称 const ariaLabel el.getAttribute(aria-label); if (ariaLabel) selectors.push([aria-label${CSS.escape(ariaLabel)}]); // 4. 基于文本内容和标签谨慎使用 const text el.innerText?.trim(); if (text text.length 50) { // 使用XPath进行文本匹配更精确但可能更脆弱 selectors.push(xpath//${el.tagName}[normalize-space()${text}]); } return selectors; } # 然后将selectors列表也返回给Python端智能执行器升级Executor在执行动作时不再只依赖临时ID。def execute_with_retry(self, decision, observation): element_info next((e for e in observation[dom_elements] if e[id] decision[element_id]), None) if not element_info: return 元素信息丢失。 selectors element_info.get(selectors, []) # 按优先级尝试不同的选择器 for selector in selectors: try: if decision[action] click: self.page.click(selector, timeout3000) return f使用选择器 {selector} 点击成功。 # ... 其他动作类似 except Exception as e: print(f选择器 {selector} 失败: {e}) continue # 所有选择器都失败尝试基于坐标的兜底点击需谨慎 rect element_info[boundingRect] if rect[width] 0 and rect[height] 0: self.page.mouse.click(rect[x] rect[width]/2, rect[y] rect[height]/2) return 使用坐标点击兜底方案。 return 所有定位方式均失败。5.2 挑战二长流程任务的规划与迷失问题描述对于需要多个步骤的任务如“注册账号并发布一条帖子”Agent可能会在中间步骤迷失。例如在填写表单时它可能反复在同一个输入框里打字或者忘记点击最终的“提交”按钮。LLM的短期记忆即使有PageMem在长序列中仍然可能丢失最终目标。解决方案实施分层任务规划Hierarchical Task Planning, HTP和子目标检查点。顶层规划器在任务开始时用一个专门的“规划调用”让LLM将整个任务分解成一个清晰的步骤列表子目标。例如[“导航到论坛首页”, “找到并点击注册链接”, “填写用户名、邮箱、密码”, “同意条款并提交注册”, “登录新注册的账号”, “导航到发帖板块”, “点击发帖按钮”, “填写标题和内容”, “提交帖子”]当前子目标跟踪Agent的核心状态中维护一个current_subgoal_index。在每一步“思考”时除了当前页面快照还会将当前正在进行的子目标如“填写用户名、邮箱、密码”作为强提示给LLM。子目标完成验证每个子目标完成后需要有一个验证逻辑。例如对于“提交注册”这个子目标验证可以是“检测页面URL是否跳转到登录页或出现‘注册成功’的文本”。验证通过后才将current_subgoal_index加一推进到下一个子目标。异常检测与重规划如果Agent在一个子目标上徘徊了太多步骤比如超过10步或者页面状态与预期严重不符比如出现了“错误”提示则触发“重规划”。此时将当前页面状态和剩余任务再次发给LLM请求它重新规划后续步骤。避坑技巧子目标的描述要尽可能具体和可观测。避免使用“完成注册”这种模糊描述而是用“看到‘注册成功’提示语”或“页面跳转到/user/dashboard”这样的明确状态作为完成标志。这大大降低了验证的难度。5.3 挑战三处理非标准交互与验证码问题描述网页上不仅有点击和输入。还有拖拽、滑块验证、图片验证码、下拉选择等。这些对于当前基于“元素-动作”范式的Agent是巨大挑战。解决方案插件化能力扩展和人工介入接口。动作库扩展我们将action的类型从一个封闭集合改为一个可扩展的列表。除了基础的click,type,scroll我们增加了select: 处理下拉菜单 (select)需要提供option_value。drag_and_drop: 处理滑块验证需要提供源元素和目标元素的id或坐标。upload_file: 处理文件上传。 在Executor中为每种新动作实现专门的处理器。验证码处理策略识别阶段Observer在生成页面快照时需要特别检测常见的验证码组件如canvas绘制图形、特定的iframe。一旦检测到在给LLM的提示中明确告知“当前页面存在疑似验证码需要人工处理或调用验证码识别服务”。决策阶段LLM在遇到验证码时应输出一个特殊的动作如{action: human_intervention, reason: 需要输入图片验证码}。处理阶段系统可以暂停并通过通知机制如邮件、短信请求真人输入或者对于简单的图形验证码集成第三方OCR服务但需注意法律和伦理风险。在我们的实践中对于通用Agent遇到验证码时暂停并请求人工协助是最稳妥可靠的方式。降级方案对于极其复杂或动态的交互如游戏界面当前的通用Agent可能无能为力。这时系统应该能够优雅地报告失败并可能建议用户切换到针对该站点的专用脚本如果存在的话。这体现了“通用”与“专用”的边界。6. 评估、未来与个人体会如何衡量一个Web Agent的好坏我们建立了多维度的评估基准Benchmark主要包括任务成功率在一组涵盖导航、搜索、表单填写、购物等场景的标准化任务上Agent能独立完成的比例。平均步骤数完成一个任务所需的平均“观察-思考-行动”循环次数。步骤越少通常意味着效率越高、规划能力越强。人工干预频率在长任务中需要人工介入如处理验证码、纠正错误决策的次数。跨网站泛化能力在一个网站上训练或调优的Agent在未见过的网站上执行同类任务的成功率。目前没有任何一个Agent能在所有指标上都达到完美。WebChallenger在我们的内部基准测试中在结构化较好的网站如维基百科、电商产品页上任务成功率能达到85%以上但在高度动态、反爬措施严密的网站上成功率会急剧下降。我个人在实际开发和测试中的最深体会是可靠性是通用Web Agent的生命线而可靠性来自于对“异常”和“边缘情况”的处理。一个能顺利执行10步的Agent不算成功一个能在第11步遇到弹窗、加载失败或元素丢失时能正确检测、合理应对等待、重试、刷新、报告的Agent才是真正可用的。这要求我们的系统不仅要有聪明的“大脑”LLM更要有健壮的“神经系统”状态监控、异常检测、恢复机制和“反射弧”快速重试、备用方案。未来的方向我认为会集中在以下几点一是多模态理解的深化让AI不仅能“看到”元素还能理解整个页面的视觉布局和语义区块二是操作技能的抽象化让AI学会“填写表单”、“浏览列表”这种高级技能而不是一个个原子动作三是与操作系统的更深集成让Web Agent能处理下载文件、读取本地内容等跨应用任务。这条路还很长但每一步都让机器离“像人一样使用电脑”更近一步。最后分享一个实用小技巧在调试你的Web Agent时务必开启浏览器的“慢速网络”Slow 3G和“CPU节流”CPU Throttling模式进行压力测试。很多在理想网络和性能下运行良好的Agent在真实用户面临的网络延迟和低端设备环境下会频繁超时和失败。提前在恶劣环境下测试能帮你发现并加固很多脆弱环节。