我最近折腾了一个很有意思的东西一个能听懂人话的AI智能体专门负责浏览器自动化。以前我做网页数据收集、表单填写这类重复操作都得老老实实写Selenium或者Playwright脚本选择器一长串现在只需要一句话比如“把这页里所有视频链接整理成表格”它就能自己开浏览器、自己找元素、自己点、自己收集结果。这套方案特别适合经常和浏览器打交道的开发者、运营和测试同学也适合第一次接触AI Agent的人。它解决的核心问题不是“能不能自动化”而是“自动化能不能别再靠写死脚本”。当网页改版、元素位置变了、加载方式变成懒加载之后传统脚本往往当场报废而AI智能体可以在运行时重新观察页面、调整策略这才是真正的“自己干活”。1. 先搞清楚AI智能体到底怎么让浏览器“干活”的1.1 别急着写脚本两步分清“理解页面”和“操作页面”传统浏览器自动化核心是“定位元素然后模拟操作”。你要先用开发者工具找到登录按钮的选择器写下driver.find_element(By.XPATH, ...)再调用.click()。问题在于这一步把“理解页面”和“操作页面”硬生生绑在了一起页面结构一变脚本就成废纸。AI智能体系统做了一个关键拆分把“理解页面”交给大模型把“操作页面”交给自动化工具。大模型负责读用户指令、分析当前页面状态、决定下一步动作Playwright这类工具负责执行具体操作比如点击、输入、滚动、等待。两者通过一个动作清单对接模型只能在清单里选动作不能自由发挥写代码。我习惯用一个类比老办法像给员工写死一套SOP每一步都规定死换了仓库就全乱AI智能体则像是给一个实习生派活你说“把这批货整理好”他会自己看情况拆箱、分类、摆放遇到问题再调整。这个“自己看情况”的能力正是靠大模型在每一个决策点重新阅读页面状态换来的。1.2 核心架构看着简单但90%的人漏了“反馈环”一个能真正“干活”的AI智能体浏览器系统至少包含四层感知层读取网页当前状态。主流有两种方式一是解析DOM树二是页面截图后交给多模态模型识别。我建议以DOM为主、截图为辅因为DOM的结构化信息更稳定模型理解起来不会受视觉噪声干扰截图则用在canvas绘图、视频播放器等无法直接读取内部结构的场景。决策层用大模型把用户的一句话拆解成多个动作序列。这里要特别注意最好选择支持function calling的模型让模型从你预设的“工具清单”里选动作而不是让它自由输出代码。为什么因为工具清单是有限集合安全可控模型不容易“自由发挥”写出意料之外的逻辑。执行层把决策层输出的动作映射到真实浏览器操作。比如动作是click(登录)执行层就调用page.get_by_text(登录).click()。反馈层执行完一个动作后重新抓取页面状态判断刚才的动作是否达到了预期效果。没有达到就自动修正达到就进行下一步。四层里反馈层最容易被忽视也最能区分“脚本”和“智能体”。没有反馈层的系统只是把几个自动化步骤串起来有了反馈层系统才有“闭环”。举个例子模型判断要点击“登录”按钮但点击之后弹出的不是登录框而是一个广告浮层。没有反馈层的脚本会傻等登录框出现直到超时有反馈层的系统会把“页面变了但变错了”这个事实告诉模型模型马上改点右上角的关闭按钮再重新找登录入口。这就像开车不能闭眼按记忆打方向盘开一段就要睁眼看看路况再决定下一步。浏览器自动化也一样每一步都要“睁开眼睛”看结果。2. 从零搭建一个能跑通的最小系统2.1 技术选型为什么选Playwright而不是Selenium我第一次做这个系统时先想了半天选型。市面主流工具就三个Selenium、Puppeteer、Playwright。它们各有优势但对AI智能体这个场景Playwright明显更顺手。工具定位方式自动等待多浏览器支持场景友好度Selenium选择器、XPath弱大量依赖显式等待全老牌但繁琐等待逻辑要自己写很多Puppeteer选择器、XPath中等仅Chrome系功能强但被Chromium绑定Playwright文本、角色、CSS、XPath强自动等待元素可操作Chrome、Edge、Firefox最贴合AI决策场景我最终选Playwright核心原因有四个自动等待机制省心。Playwright的locator.click()会自动等待元素可见、可交互这在AI系统里太重要了。模型指令不会精确到“等2.5秒”你需要工具本身具备“等到能用再动手”的能力。多浏览器支持。同一个API可以跑Chrome、Edge、Firefox方便做差异测试。多页面管理原生支持。AI处理复杂任务时经常要开多个标签页Playwright的Page对象管理非常清晰。可以连接已有浏览器。通过CDP连接一个手动打开的浏览器实例等于让AI操作你正在用的浏览器很多调试场景会方便很多。另外一个现实原因Playwright的定位API本身就贴近“人的表达”像get_by_text(提交订单)、get_by_role(button, name确定)这些语义化定位天然适合大模型去“理解”比写一串CSS选择器靠谱得多。2.2 核心链路一句话变四个阶段动手前先拆解从一句话到浏览器真正动起来我总结成四个阶段意图解析把自然语言指令转为结构化JSON。比如“把这页文章保存成PDF”变成{target: current_page, action: save_as_pdf}。任务分解把目标拆成步骤序列。比如“收集商品信息”会拆成“打开列表页、滚动加载、提取字段、写入文件”。动作选择每个步骤映射到工具清单中的一个动作。动作清单要提前定义好包括open_url、click、type、scroll、extract、wait等。执行校验执行动作后调用反馈层判断是否成功不成功就修正。下面给一个最小可读的伪代码示例方便理解整体链路。实际生产里llm_parse_actions和llm_check_result这部分需要写比较长的prompt并且要把工具清单的结构化定义传给模型要求它输出JSON数组。from playwright.sync_api import sync_playwright TOOLS [ { name: open_url, description: 打开指定网址, parameters: {url: string} }, { name: click_text, description: 点击页面上文本匹配的元素, parameters: {text: string} }, { name: type_text, description: 在输入框输入内容, parameters: {selector: string, content: string} }, { name: scroll_page, description: 滚动页面可传down或up, parameters: {direction: string} }, ] def llm_parse_actions(instruction, tools): # 调用大模型API把指令转为动作序列 # 例如返回 [{name: open_url, url: ...}] return [] def llm_check_result(action, page_snapshot): # 调用大模型判断动作是否生效 return True def capture_state(page): return { url: page.url, title: page.title(), content: page.content()[:3000] } def run_action(page, action): name action[name] if name open_url: page.goto(action[url]) elif name click_text: page.get_by_text(action[text]).first.click() elif name type_text: page.fill(action[selector], action[content]) elif name scroll_page: page.mouse.wheel(0, 500 if action[direction] down else -500) def run_task(instruction: str): actions llm_parse_actions(instruction, TOOLS) with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() for action in actions: run_action(page, action) page.wait_for_timeout(800) snapshot capture_state(page) ok llm_check_result(action, snapshot) if not ok: # 把当前快照返回给模型让它给出修正动作 corrected llm_correct_action(action, snapshot) run_action(page, corrected) browser.close()这段代码不是可以直接copy到生产环境的成品但骨架是对的。实际开发时我会把llm_parse_actions封装得更细先让模型输出结构化计划再逐步执行。这样即使某一步出错模型也只修当前步骤而不是推翻整个计划。3. 把工作流跑稳操作安全与可复现性3.1 元素定位的三种姿势文本、结构、视觉AI智能体要“自己找元素”但怎么找很讲究。我实践下来定位方式基本分三档文本定位page.get_by_text(登录)。这是最贴近人的方式模型最容易理解。缺点是页面上可能有多个相同文本需要用.first或精确匹配来消除歧义。适合按钮、链接、菜单项这类有可见文案的元素。结构定位role、CSS选择器。比如get_by_role(button, name提交订单)语义清晰且不容易被页面样式变化影响。适合表单、对话框、导航栏这些有一定语义结构的场景。前提是目标网站的DOM没有故意混淆可访问性属性。视觉定位多模态模型看截图直接输出坐标或者像素区域。适合canvas、视频播放器、地图这类DOM无法完整表达内容的场景。缺点也很明显坐标依赖视口尺寸和设备像素比换个窗口大小就偏了只能兜底用。我给模型写工具说明时会明确优先级优先文本其次角色最后视觉。同时写死一条规则绝对禁止模型凭空生成XPath。为什么因为模型没有真正“看到”DOM树它生成的XPath大概率是错的。正确做法是系统先把页面上可交互元素的摘要提取出来转成JSON列表发给模型模型从里面挑。摘要可以包含文本、标签、可见性、区域位置等信息。这个“可访问性快照”的思路我强烈推荐。它相当于把整个页面的关键信息做成一个mini目录模型不需要理解完整DOM只需要在这个目录里找目标。经过这个改动后我这边元素定位的准确率至少提升了30%。3.2 试错才是核心能力让AI自己看结果、自己纠正真实页面操作永远会出乎意料。比如点击“下一页”但页面其实已经到了最后一页点击“展开详情”结果展开的是另一条内容。传统脚本遇到这种问题直接报错AI智能体则可以通过反馈层现场调整。具体做法是三步动作前抓状态记录当前URL、页面标题、关键DOM区域的Hash值。动作后抓状态等待大约500毫秒到1秒再抓一次同样的状态。比较并判断写一些硬规则比如URL变了、内容块出现了新元素。也可以把前后状态快照发给大模型问它“这个动作成功了吗”。注意硬规则能判断的尽量用硬规则。比如“点击后URL是否变化”完全不需要动用大模型这样可以显著减少API调用次数和耗时。大模型只在页面状态变化比较复杂、规则判断不了时再介入。我还会设置重试上限同一个动作最多重试3次整个任务最多20步。超过限制就终止并把当前页面状态截图返回给用户。不要无限重试那不是“智能”那是烧Token的无底洞。安全与权限控制也是必须考虑的事。我给系统暴露给模型的操作一向是“能少则少”基础阶段只开放点击、输入、滚动、读取内容关闭下载、上传、删除这类敏感能力。需要提交订单、支付这类高影响动作时系统会强制暂停等人工确认。浏览器建议跑在Docker这样的一次性环境里用完就销毁避免AI误操作污染本地环境。4. 现场实录一个真实的“一句话干活”案例4.1 真实案例一句话搞定资料批量收集纸上谈兵没用我说一个跑通过的真实案例。某天我需要从一个商品列表页收集前5个商品的名称和价格整理成CSV文件。传统做法是写脚本加定位这次我只给系统一句话“打开这个商品列表页把前5个商品的名称和价格整理成CSV。”系统实际执行过程是这样的模型输出计划open_url打开页面等页面加载提取商品卡片去重写入CSV。执行open_url后系统抓取页面快照发现首屏只有3个商品卡片目标数量是5个。反馈层判断“数量不足”。模型修正计划执行scroll_page向下滚动两次每次等待500毫秒触发懒加载。再次提取这次拿到6个商品取前5个写入CSV。人工检查CSV文件发现价格列把“促销价”和“原价”两个字段都写进去了。这个不算执行失败但说明提取字段时要做好schema约束。这个案例里最有价值的是第3步传统脚本如果写死了“等待2秒”遇到网络慢或者懒加载慢就会翻车而AI系统通过反馈层发现“数量不够”后主动调整策略多滚动了几次。整个过程中我没有手写一行页面逻辑。4.2 踩坑速查手册这7个问题我全都替你先试过了下面这7个问题是我在搭建和使用过程中真实踩过、也逐一解决过的做成速查表给你现象根因处理方式Cookie同意框挡住点击目标模态框层级高把按钮遮住了启动时统一扫描常见弹窗关闭按钮发现就自动关掉元素一直找不到动态加载慢固定sleep不够用locator.wait_for(timeout10000)替代固定等待验证码出现访问触发风控策略立即暂停截图通知人工处理不硬闯模型编造了不存在的XPath模型幻觉它“猜”了一个选择器禁止模型写选择器只让它从可访问性快照里选点击后URL没变化单页应用内部路由用DOM关键区域变化和网络空闲替代URL判断数据提取字段不干净页面信息过载模型分不清主次提取前先让模型输出目标字段清单再按字段提取任务执行到一半卡死模型陷入循环重试设置全局步数上限20步单步重试上限3次这个表格我建议直接存在项目文档里遇到问题先对号入座。尤其是“模型幻觉XPath”这个问题新手最容易遇到因为让大模型直接写CSS选择器看起来理所应当实际一跑一个不吱声。4.3 效果对比从脚本到智能体的变化我这里放一个真实的对比数据同样做一个“把指定网站的商品信息整理成表”的任务传统脚本方案需要先打开开发者工具确认元素结构写定位路径再调试等待逻辑整个过程大概要30到60分钟换成AI智能体系统后新目标网站只需要一句话修改首次尝试成功率在80%左右。剩下20%的失败场景主要集中在验证码、网站访问频率限制、以及极复杂的登录流程上这些并不是智能体本身能力不够而是需要规则配合。当然AI智能体并不是银弹。它会让“常见任务”变得格外轻松但也会引入新的不确定性模型偶尔会做出意料之外的动作API调用可能超时Token消耗也要计入成本。所以在落地方案时我的建议是保留“人工确认”环节先让AI跑通简单场景再逐步放开操作权限。你如果也想搭一个“一句话让浏览器干活”的系统最简单的起步方式就是选一个支持function calling的大模型接口配一个Playwright环境先跑通我上面给的最小链路再慢慢增加工具和数据校验。我自己在这个方向继续折腾的目标是让多个智能体协同处理更复杂的业务流程比如一个负责收集数据一个负责分析一个负责生成报告最后再由人工一键确认发布。这个扩展路径方向明确也值得一步步走下去。
