1. 项目概述当浏览器遇上大模型Agent最近在折腾一个挺有意思的东西我把它叫做“智能浏览器副驾”。简单来说就是让浏览器不再只是一个被动的工具而是变成一个能理解你意图、主动帮你干活的智能体。这背后的核心就是把当下火热的大模型和Agent智能体技术塞进了浏览器自动化这个老场景里。传统的浏览器自动化比如我们写爬虫或者做UI测试用的Selenium、Puppeteer本质上是一套精确的指令集。你得告诉它点击ID为“submit”的按钮在Class是“search-box”的输入框里填入“XXX”然后等待页面加载完成。整个过程非常“机械”一旦页面结构稍有变动或者出现了弹窗、验证码这些意外情况脚本很容易就“趴窝”了。这要求开发者必须对目标网页了如指掌并且写出健壮但异常繁琐的异常处理逻辑。而现在有了大模型加持情况就完全不同了。我们不再需要事无巨细地编写每一步操作指令。你只需要用自然语言告诉这个智能体你的目标比如“帮我在电商网站上找到所有价格低于500元的无线耳机并把它们的标题、价格和链接整理到一个表格里”它就能自己去理解这个任务分析网页结构寻找合适的商品列表、翻页按钮处理可能的价格筛选最终把结果规整好给你。它甚至能处理一些模糊指令比如“看看这个新闻网站今天最热门的科技新闻是什么”它会自己去识别什么是“热门”的指标可能是点击量、评论数或者位置然后执行点击、阅读、摘要等一系列操作。这个项目适合谁呢首先肯定是广大开发者特别是那些受够了编写和维护复杂、脆弱爬虫脚本的朋友。其次是从事数据分析、市场调研的人员他们经常需要从多个网站采集信息手动操作费时费力。最后甚至是一些非技术背景的运营、产品同学如果他们能通过简单的对话就完成一些重复性的网页操作和信息收集那效率提升将是巨大的。接下来我就把自己从零搭建这套工具的思路、踩过的坑和核心实现细节毫无保留地分享出来。2. 核心架构与工具选型解析要构建这样一个系统我们不能蛮干得先搭好架子。整个架构可以清晰地分为三层大脑层、协调层和执行层。2.1 大脑层大模型的选择与接入大脑负责理解用户的自然语言指令并将其分解、规划成具体的子任务或操作步骤。这里的主角就是大语言模型。主流模型对比与选型考量目前可选的大模型很多开源和闭源的各有优劣。我的选型主要基于以下几点理解能力、上下文长度、API稳定性和成本。GPT-4系列OpenAI理解能力和任务规划能力目前依然是第一梯队特别是对于复杂、模糊的指令它的分解能力非常强。缺点是API有使用成本且需要处理网络访问问题。对于追求效果和快速验证原型它是首选。Claude系列Anthropic同样非常强大在长上下文和遵循指令方面表现优异。是GPT-4有力的替代选择。开源模型如Qwen、DeepSeek、GLM、Llama等这是目前最活跃、也最具潜力的领域。通过Ollama、vLLM等工具可以在本地或私有服务器部署。优势是数据隐私性好无持续使用成本可以针对浏览器自动化场景做微调。劣势是同等参数下复杂任务规划能力可能略逊于顶级闭源模型且需要一定的运维成本。注意如果选择国内可顺畅访问的模型如DeepSeek、Qwen等务必通过其官方平台或合规的API渠道获取服务确保整个开发流程的合法合规与稳定性。我的实践是在初期探索和验证核心逻辑时使用GPT-4或Claude的API快速迭代。当流程跑通后可以尝试切换为性能较好的开源模型以控制长期成本并满足数据隐私要求。本项目后续的示例将基于“大模型API”这一抽象概念你可以将其替换为任何你选择的具体模型服务。关键参数与提示工程仅仅调用模型是不够的如何与它“对话”至关重要这就是提示工程。我们的核心提示词需要包含以下几个部分角色定义明确告诉模型它是一个“浏览器自动化智能体”。能力描述告诉它可以执行哪些底层操作如click,type,scroll,extract_text等。任务目标用户的自然语言指令。当前上下文当前页面的URL、页面关键文本的摘要因为大模型有Token限制不能喂整个HTML、上一步操作的结果等。输出格式约束严格要求模型以指定的结构化格式如JSON输出下一步动作。这是实现机器可解析的关键。一个简化的提示词示例你是一个智能浏览器操作助手。你可以通过以下基础动作控制浏览器click(selector), type(selector, text), scroll(direction), goto(url), extract(selector)。 当前页面URL是https://example.com/search?qlaptop 当前页面可见区域的关键文本摘要包含“搜索结果”、“笔记本电脑”、“价格筛选”。 用户的目标是“找出最便宜的三款笔记本电脑并告诉我它们的品牌和价格”。 请根据当前上下文和用户目标决定下一步应该执行哪个基础动作。你只能输出一个JSON对象格式必须严格如下{action: action_name, selector: css_selector_or_xpath, value: optional_value, reason: 你的思考过程}2.2 协调层Agent框架的职责大脑发出了指令需要一个协调层来解析指令、管理状态、处理异常。这就是Agent框架的工作。这里不一定需要一个重量级的框架但其核心模块必不可少任务规划与分解模块接收用户指令调用大模型将其分解为一系列有序的原子操作如1. 定位商品列表2. 提取所有商品信息3. 按价格排序4. 取前三名。状态管理模块记录当前任务执行到了哪一步当前页面的URL和关键状态是什么。这相当于Agent的“短期记忆”。工具调用模块将大模型输出的结构化动作如{action: click, selector: .next-page}映射到真正的浏览器控制命令如page.click(.next-page)。观察与反馈模块执行一个动作后需要观察结果页面是否跳转元素是否存在提取的文本是什么并将这个结果作为新的“上下文”反馈给大模型以决定下一步动作。这就形成了一个“感知-思考-行动”的循环。对于轻量级实现你可以自己用Python写一个简单的状态机来管理这个循环。如果想更规范可以考虑利用LangChain、AutoGen这类AI应用框架它们提供了现成的Agent、Tool、Memory等抽象能帮你节省不少搭建基础设施的时间。不过引入框架也会增加复杂度需要权衡。2.3 执行层浏览器自动化的基石这是最底层负责实际操控浏览器。选择成熟稳定的工具是关键。Puppeteer (Node.js) / Playwright (Node.js, Python, .NET, Java)这是目前的主流选择尤其是Playwright由微软出品支持多浏览器Chromium, Firefox, WebKitAPI设计现代自动等待机制做得好能很大程度上减少因页面加载速度导致的脚本失败。我强烈推荐Playwright for Python它对现代Web技术的支持最好隐藏了很多自动化中的坑。Selenium老牌工具生态庞大。但在处理单页面应用SPA和复杂的动态加载时需要编写更多的等待逻辑不如Playwright省心。选型建议无脑选Playwright。它提供的page.content()、page.locator()、page.screenshot()等方法能非常方便地为上层提供页面观察结果。而且它的Python版本异步和同步API都支持易于集成。驱动管理Playwright的一大优势是能自动下载和管理浏览器驱动避免了传统Selenium中需要手动匹配浏览器和驱动版本的烦人问题。3. 核心工作流与实现细节拆解理解了架构我们来看这个智能体具体是如何运转的。其核心工作流是一个闭环解析指令 - 观察环境 - 规划动作 - 执行动作 - 观察结果 - 循环直至完成。3.1 从自然语言到原子操作提示词设计的艺术这是整个系统智能与否的关键。大模型输出的质量直接取决于你喂给它的提示词。经过多次调试我总结出一个高效的提示词结构SYSTEM_PROMPT 你是一个专业的Web操作智能体。你的目标是根据用户的请求通过操作浏览器来完成任务。 你可以使用的工具动作如下 - goto(url): 导航到指定URL。 - click(selector): 点击CSS选择器或XPath指定的元素。 - type(selector, text): 在指定元素中输入文本。 - scroll(direction): 滚动页面direction可以是 up, down, left, right。 - extract(selector): 从指定元素中提取文本内容。 - wait(time): 等待指定秒数。 - finish(result): 任务完成输出最终结果。 当前环境状态 当前URL: {current_url} 页面摘要: {page_summary} 已执行步骤: {execution_history} 请根据“用户请求”和“当前环境状态”决定下一步应该执行哪个工具。你**必须**且**只能**输出一个JSON对象格式如下 { thought: 简要分析当前情况和下一步理由, action: 工具名如 click, type, selector: 元素的CSS选择器或XPath如果是goto则是URL如果是scroll则是方向如果是wait则是秒数, value: 可选仅当action为type时需要表示要输入的文本, finish: false // 通常为false只有当任务完成并调用finish工具时才为true } 如果认为任务已经完成请使用finish动作并在value字段中给出最终结果。 关键点解析页面摘要不能把整个HTML动辄几百KB都塞给大模型。需要提取关键信息。一个简单有效的方法是用Playwright获取页面主要文本page.inner_text(body)然后截取前N个字符或者用更智能的方法提取正文如readability库。更好的做法是让模型自己决定需要观察页面的哪部分但这需要更复杂的设计。执行历史记录之前几步做了什么例如“点击了搜索按钮”、“在输入框键入了‘耳机’”。这能防止模型陷入循环或重复操作。结构化输出强制JSON输出是机器可读的保证。thought字段非常有用它相当于模型的“思考链”在调试时能帮你理解模型的决策过程方便优化提示词。3.2 感知环境如何让AI“看到”网页AI不是人眼它需要通过文本和结构化的数据来“感知”网页。单纯给HTML源码效果很差因为包含太多噪音脚本、样式、无关标签。我的经验是采用混合策略关键文本摘要使用Playwright的page.locator(body).inner_text()获取全部文本然后进行清洗去除过多空白符、脚本内容截取前2000-3000个字符作为摘要。对于内容页可以用readability或trafilatura这样的库先提取正文效果更好。关键元素属性除了文本页面的交互元素按钮、链接、输入框的属性和周围文本更重要。可以写一个函数提取页面中所有可交互元素的selector及其附近的文本如aria-label,placeholder,innerText形成一个简化的“元素地图”提供给模型。视觉辅助进阶对于极度依赖视觉布局的页面可以考虑使用多模态模型。将当前页面截图使用GPT-4V或开源的VLM模型来描述截图内容。但这成本高、速度慢通常作为文本感知的补充用于解决纯文本无法定位的难题比如一个没有任何文本的图标按钮。实操心得初期不必追求完美的感知。先提供页面标题title和h1,h2标签的文本再加上正文的前500字往往就能让模型对页面有一个基本正确的认识。过度复杂的感知处理会拖慢整个循环的速度。3.3 动作执行与异常处理让流程稳定运行从大模型拿到{“action”: “click”, “selector”: “.submit-btn”}后我们需要用Playwright来执行。基础执行很简单async def execute_action(page, action_obj): action action_obj.get(action) selector action_obj.get(selector) value action_obj.get(value) if action goto: await page.goto(selector) # 此时selector是url elif action click: # 这里可以增加智能等待确保元素可点击 await page.locator(selector).click(timeout10000) elif action type: await page.locator(selector).fill(value) # ... 其他动作真正的挑战在于异常处理元素找不到或不可交互这是最常见的错误。模型给出的selector可能不准或者页面还没加载完。解决方案是“重试重新观察”。当Playwright抛出TimeoutError时我们不应该直接让任务失败而是应该将这个错误信息“无法定位元素 .submit-btn”作为新的观察结果连同当前页面摘要再次喂给大模型让它重新思考并可能给出新的selector或采取其他动作比如先滚动一下。页面导航或弹窗点击后可能跳转新页面或弹出新窗口。Playwright可以监听这些事件page.on(popup),page.wait_for_url()并在事件发生后更新“当前URL”状态然后让模型基于新页面进行下一步决策。反爬虫机制目标网站可能有验证码、请求频率限制等。纯AI方案对此无能为力。这需要引入传统反反爬策略如使用代理IP池、降低操作频率、模拟人类操作间隔随机等待等。对于验证码目前仍需人工干预或接入专门的打码平台。一个健壮的执行循环伪代码async def agent_loop(user_task, initial_url): await page.goto(initial_url) context get_page_summary(page) # 获取初始页面摘要 history [] for step in range(MAX_STEPS): # 防止无限循环 # 1. 请求大模型规划下一步 action_obj await llm_plan(user_task, context, history) if action_obj[finish]: print(f任务完成结果{action_obj[value]}) break # 2. 尝试执行动作 try: await execute_action(page, action_obj) # 执行成功等待一小段时间让页面稳定 await page.wait_for_timeout(2000) except Exception as e: # 3. 执行失败将错误信息作为新的观察 context f“执行动作失败{e}。当前页面摘要{get_page_summary(page)}” history.append(f“失败动作{action_obj} 错误{e}”) continue # 不记录成功历史直接进入下一轮规划 # 4. 执行成功更新上下文和历史 new_summary get_page_summary(page) context f“上一步动作 {action_obj} 执行成功。当前页面摘要{new_summary}” history.append(f“成功执行{action_obj}”)4. 实战案例自动商品比价Agent光讲理论不够我们用一个完整的例子串起来构建一个能自动在电商网站搜索商品并比价的Agent。任务描述“在京东上搜索‘无线蓝牙耳机’筛选出价格在200-500元之间的商品按销量排序然后获取前三名商品的标题、价格和店铺名称。”4.1 任务初始化与首次规划我们启动Agent输入任务指令和初始URLhttps://www.jd.com。Agent首先看到的是京东首页。首次观察get_page_summary函数提取到页面摘要包含“京东”、“搜索框”、“你好请登录”等文本。首次规划大模型收到任务、首页摘要和空历史。它分析后认为第一步应该是“在搜索框输入关键词”。于是输出{ thought: 用户需要在京东搜索。当前页面是首页有一个明显的搜索框。第一步应是在搜索框中输入‘无线蓝牙耳机’并提交。, action: type, selector: #key, // 京东搜索框的实际ID value: 无线蓝牙耳机 }执行与观察Agent执行输入操作。然后模型很可能紧接着规划一个“点击搜索按钮”的动作或者京东的搜索框在输入后会自动提示模型可能会规划点击搜索建议。这里假设它点击了搜索按钮selector: .button。4.2 处理列表页与筛选交互执行搜索后页面跳转到商品列表页。新一轮观察新的页面摘要包含“无线蓝牙耳机”、“综合排序”、“销量”、“价格筛选”、“商品列表”等。新一轮规划模型根据任务“筛选价格200-500元”它需要操作价格筛选器。它可能会输出{ thought: 当前处于搜索结果页。需要先进行价格筛选。页面左侧通常有价格筛选区间输入框。, action: type, selector: input[placeholder最低价], value: 200 }随后是另一个type动作填充最高价“500”并可能有一个click动作触发筛选按钮。执行筛选Agent执行这些动作页面刷新展示筛选后的结果。4.3 排序与信息提取筛选完成后任务要求“按销量排序”。观察与规划模型识别“综合排序”下拉框或“销量”标签。{ thought: 价格筛选已完成。现在需要按销量排序。找到排序相关的元素点击‘销量’。, action: click, selector: a:has-text(销量), // Playwright支持文本选择器 value: null }提取信息排序后页面展示目标商品列表。模型需要规划提取动作。这里需要一个循环或一个复合动作。一个简单的策略是让模型规划一个extract动作使用一个能覆盖所有商品条目的选择器如.gl-item然后我们在执行层对这个选择器进行批量处理。{ thought: 已按销量排序。现在需要提取前三个商品的信息。商品列表容器的选择器可能是‘.gl-warp’下的‘.gl-item’。先提取第一个商品的信息作为测试。, action: extract, selector: .gl-item:nth-child(1), value: null }执行extract动作时我们的execute_action函数需要扩展它不仅返回成功与否还要返回提取到的文本内容。例如提取第一个商品后我们得到一串文本“JBL T280TWS 真无线蓝牙耳机... 399 京东自营旗舰店”。结构化数据与完成我们将提取到的原始文本作为观察反馈给模型。模型可以判断这个信息是否足够包含了标题、价格、店铺。如果不够它可能会规划更精细的提取分别提取标题选择器、价格选择器。当模型认为已经收集到足够的信息如前三个商品后它会调用finish动作并将整理好的信息比如一个JSON数组放在value中。{ thought: 已成功提取前三名商品的文本信息可以从中解析出标题、价格、店铺。任务完成。, action: finish, value: [{\title\: \JBL T280TWS\, \price\: 399, \shop\: \京东自营\}, ...], finish: true }4.4 案例中的难点与技巧选择器稳定性电商网站的选择器可能经常变动。依赖纯CSS选择器或XPath很脆弱。更好的方法是结合文本内容Playwright的has-text和属性选择器或者利用AI在规划时描述元素的位置和特征再由一个专门的函数来生成鲁棒的选择器。分页处理如果前三名商品不在第一页怎么办我们的任务描述是“按销量排序”通常销量最高的就在第一页。但如果需要翻页可以在任务规划中体现。模型在发现第一页商品不足三个或提取后判断不满足条件时应能自主规划“点击下一页”的动作。信息解析extract动作拿到的是一坨文本模型需要有能力从中解析出结构化的字段。这可以在finish动作前让模型多执行一步“思考与解析”的内部动作或者由我们后处理模块利用大模型或正则表达式进行解析。5. 避坑指南与效能优化在实际开发中你会遇到各种各样的问题。下面是我踩过坑后总结出的经验。5.1 常见问题与排查清单问题现象可能原因排查与解决思路Agent陷入死循环模型反复输出相同或无效的动作。1.检查执行历史在提示词中提供更长的历史记录让模型知道“此路不通”。2.丰富观察信息可能是页面摘要信息不足模型无法做出新决策。增加摘要长度或提取更多交互元素信息。3.设置最大步数强制中断循环并反馈“步骤超限”错误给用户。模型输出的选择器永远找不到模型“想象”出的选择器与实际DOM结构不符。1.增强感知提供给模型的“元素地图”要更精准包含更多可交互元素的可用选择器。2.选择器回退当模型指定的选择器失败时执行层可以尝试用其他方法定位相似文本的元素。3.使用更鲁棒的定位方式引导模型在规划时优先使用文本内容has-text或角色属性rolebutton进行描述。任务执行速度极慢每个“思考-行动”循环都要调用一次大模型API网络延迟高。1.缓存与批处理对相似的页面状态和指令可以缓存模型的决策结果。2.简化观察不要每次都将完整的页面摘要发送给模型只发送变化的部分或关键信息。3.考虑本地小模型对于简单的、重复性的操作决策如翻页、点确定按钮可以训练或使用一个更小、更快的本地模型来执行。处理复杂交互如验证码、滑块失败当前纯AI Agent方案无法解决此类强交互反爬。1.人工介入点设计流程当检测到验证码时暂停Agent并通知人工处理处理完毕后继续。2.混合策略集成传统的验证码识别服务但需注意合规性。3.规避尝试通过更换IP、降低频率来避免触发。提取的信息格式混乱extract得到的文本包含无关噪音。1.精准提取让模型规划更细粒度的提取动作分别针对标题、价格等元素。2.后处理清洗在Agent输出最终结果前增加一个数据清洗步骤使用正则或小模型进行信息抽取。5.2 提示词优化技巧少样本学习在SYSTEM_PROMPT中提供一两个成功的任务分解示例能显著提升模型规划能力。示例任务打开百度搜索“今天的天气”。 示例规划[ {action: goto, selector: https://www.baidu.com}, {action: type, selector: #kw, value: 今天的天气}, {action: click, selector: #su} ]分阶段提示对于复杂任务不要指望模型一步规划到位。可以先让模型输出一个高层任务列表然后再逐步细化每个子任务。这能提高规划的可控性和准确性。设定角色与约束明确告诉模型“你是一个谨慎的助手每一步操作前都要确认元素存在”或者“你倾向于使用文本内容而非复杂的CSS路径来定位元素”这些角色设定能引导其行为模式。5.3 性能与成本优化使用更便宜的模型进行简单决策可以采用“大小模型协同”的策略。用GPT-4等大模型做复杂任务规划和异常处理用GPT-3.5-Turbo或更小的开源模型处理简单的、模式化的操作确认比如“当前页面是不是登录页”。异步并行执行如果任务可拆分如同时监控多个不相关的页面可以使用异步框架并行运行多个Agent实例充分利用资源。减少Token消耗页面摘要是最耗Token的地方。可以尝试用算法提取DOM树的关键路径或使用嵌入模型计算页面片段的相似度只将最相关的片段发送给大模型。6. 进阶思路与应用场景拓展基础功能跑通后我们可以思考如何让它变得更强大、更实用。6.1 增强感知计算机视觉的引入纯文本感知在遇到图形验证码、图表分析、或元素定位极度依赖视觉布局时就会失效。这时可以引入多模态大模型。工作流在常规的“思考”循环中如果模型连续几次无法通过文本信息定位元素可以触发“视觉感知”分支。对当前页面进行截图调用多模态模型如GPT-4V询问“请描述图片中的可点击元素并给出点击它们的可能方式。”模型可能会回答“图片中央有一个蓝色的‘提交’按钮上面有对勾图标。”然后我们可以将这个描述转化为坐标或结合文本信息进行定位。成本考量多模态API调用成本更高响应更慢。应将其作为文本感知失败的降级方案或特定场景如图表数据提取的增强方案。6.2 记忆与学习让Agent更“聪明”目前的Agent是“无状态”的每次任务都从零开始。我们可以为它添加记忆。短期会话记忆记录当前任务的历史这我们已经做了。长期知识记忆将成功操作过的网站结构如“京东的搜索框ID是#key”、“淘宝的价格筛选器在左侧”存储到向量数据库中。当再次遇到同一网站时可以先从记忆中检索相关操作模式作为上下文提供给大模型能极大提升效率和准确性。这相当于让Agent积累了“经验”。操作库将一些通用的、成功的操作序列如“登录流程”、“处理cookie弹窗”保存为可复用的“技能”Agent在遇到类似场景时可以直接调用无需重新规划。6.3 更广阔的应用场景这个技术框架的想象力远不止于爬虫。自动化测试只需描述测试用例如“测试用户从登录到下单的流程”AI Agent就能自动执行并能处理一些非预期的UI变化比传统脚本维护成本低。RPA流程自动化将浏览器操作与桌面应用、API调用结合实现跨系统的复杂业务流程自动化。例如“从邮箱下载附件解析内容登录内部系统填报数据”。个性化信息助手定制一个专属Agent每天自动浏览你关注的几个新闻网站、博客、论坛根据你的兴趣筛选信息生成一份个性化的每日简报。无障碍辅助为视障人士或操作不便者提供语音控制的浏览器导航和操作能力AI作为理解和执行的中介。最后一点个人体会基于大模型的浏览器自动化目前还不是一个完全可靠、能处理所有边角的“银弹”。它最擅长的场景是流程相对标准、但又有一定变化性的任务。它的价值在于大幅降低了自动化脚本的编写和维护门槛将人的精力从繁琐的代码调试中解放出来更多地投入到任务定义和流程设计上。在开发过程中保持耐心精心设计提示词建立有效的错误处理与回退机制你会发现这个“智能副驾”能帮你省下不少力气。开始动手时不妨从一个非常具体、边界清晰的小任务做起比如“自动登录某个网站并抓取第一条通知”成功后再逐步增加复杂度这样更容易建立信心和迭代优化。