前阵子朋友找我说每天要把某后台的订单数据导出来、再填到另一个网页报表里纯手工要折腾半小时。我当时就想这种重复操作能不能交给AI来干正好我在折腾OpenClaw的浏览器自动化于是摸了一遍方案最后真把这件事变成了“每天自动跑一遍出错再叫我”。这篇就聊聊我从零把OpenClaw的网页操作能力跑通的全过程、底层原理和踩过的坑适合已经装好OpenClaw基础环境、想让AI真正帮你操作网页的朋友。1. 浏览器自动化的顶层设计为什么是OpenClaw 真实浏览器1.1 传统方案卡在哪很多人一提到“网页自动化”第一反应是写爬虫或者用Selenium、Playwright直接写脚本。这条路不是走不通而是维护成本极高网站改版、按钮位置变了、验证码加了、登录态过期脚本就废了。更麻烦的是每个任务都要单独写一套选择器逻辑今天抓订单、明天填报表、后天导出对账单全都得重新写。这时候把大模型塞进来就有价值了。OpenClaw这类Agent框架做的事情是让AI自己“看懂”网页结构、自己决定下一步点哪里、填什么值而不是靠人把每一步写死。它的底层仍然会调用Playwright这类浏览器驱动但决策层换成了大模型等于把“写死流程”升级成了“目标驱动”。我一开始也怀疑过让AI操作网页会不会比人点得还慢会不会乱点实测下来对于“有明确步骤、重复度高、页面结构相对稳定”的场景AI完成速度和稳定性都远好于手动而且它不会累、不会眼花看错行。1.2 OpenClaw的核心架构Agent是怎么“看”网页的OpenClaw给我的感觉很像一个“带工具箱的超级助理”。它的核心组件可以拆成三层CLI / 交互层你和Agent对话、下达任务的地方。Agent Runtime调度中心。它负责拆解任务、决定调用哪个Skill、把大模型输出翻译成具体动作。Skill执行器真正干活的模块。浏览器自动化的核心Skill会拉起一个真实的Chromium浏览器通过Playwright或CDPChrome DevTools ProtocolChrome调试协议协议操作页面。浏览器自动化这块OpenClaw走的是“真实浏览器”路线不是直接抓HTML。这里有个关键区别很多网站的数据是JavaScript动态渲染的直接请求HTML拿到的是空壳页面但真实浏览器会把所有脚本跑完等渲染稳定后再取数据这就避免了大量“页面结构对不上”的问题。为了说清楚这套机制我画了个文字版的流程用户输入任务 ↓ OpenClaw Agent大模型理解任务拆解成步骤 ↓ 调用浏览器Skill → 启动Chromium可复用Profile ↓ 在页面上执行输入、点击、等待、读取表格 ↓ 把结果回传给AgentAgent判断是否完成或需要下一步操作 ↓ 输出最终结果保存文件/发通知/继续下一步1.3 为什么Playwright是首选驱动浏览器自动化可选的技术栈不少Selenium、Puppeteer、Playwright。OpenClaw生态里用得比较多的是Playwright原因有三个第一Playwright对现代前端框架的适配更好自动等待机制很智能。Selenium时代最头疼的就是sleep(5)这种硬等Playwright的wait_for_selector会根据元素真正出现在页面上才继续稳定性高一个量级。第二Playwright支持持久化浏览器上下文persistent context。这意味着AI操作的浏览器可以保留登录状态、Cookie、LocalStorage重启任务后还能“记住”自己是登录状态这做自动化太关键了。第三它能同时驱动Chromium、Firefox、WebKit页面兼容性问题少。虽然实际使用中绝大多数时间还是Chromium但遇到某些只能在特定浏览器里正常显示的页面随时能切换。所以OpenClaw底层搭Playwright这件事本身就是一个做得比较务实的选择把浏览器驱动这块的坑提前填了大半。2. 动手前的关键准备环境、模型和Skill机制2.1 从零部署OpenClaw并接通模型如果你还没装过OpenClaw先补一下基础环境。官方提供了安装脚本支持指定Git安装方式从GitHub的main分支直接检出源码# 方案一默认安装 curl -sSL https://get.openclaw.ai/install.sh | bash # 方案二指定从 GitHub main 分支检出源码安装 curl -sSL https://get.openclaw.ai/install.sh | bash -s -- --git --branch mainWindows用户如果不想折腾依赖可以找社区维护的离线整合包解压即用。但注意离线包版本通常滞后装完后最好跑一下版本升级命令openclaw upgrade装完后需要配置模型。OpenClaw抽象了一层模型接口所以你可以接本地模型也可以接各家API服务。我图省事用了硅基流动SiliconFlow的API兼容OpenAI格式配置很简单export OPENCLAW_MODEL_PROVIDERopenai-compatible export OPENCLAW_MODEL_BASE_URLhttps://api.siliconflow.cn/v1 export OPENCLAW_MODEL_API_KEY你的API密钥 export OPENCLAW_MODEL_NAMEQwen/Qwen2.5-72B-Instruct跑一条简单任务验证环境openclaw run 你好介绍一下你自己能正常回复说明CLI、Runtime、模型链路都通了可以进入下一步。2.2 Skill到底是什么给Agent的“操作手册”OpenClaw的Skill机制非常像给Agent写一份“岗位说明书”。浏览器自动化要稳定核心不是模型多聪明而是你Skill写得有多清楚。一个标准的Skill通常包含描述文件SKILL.md里面定义了任务范围、输入参数、执行步骤和输出格式。以“导出后台订单”为例name: export_orders description: 登录订单后台导出昨日订单并汇总为CSV instruction: | 1. 打开浏览器访问 https://admin.example.com/login 2. 检查当前是否已登录 - 如果出现用户名输入框说明未登录输入账号密码后点击“登录” - 如果直接显示订单管理入口说明已登录直接进入下一步 3. 等待页面加载完成点击“订单管理”菜单 4. 在日期筛选区域选择“昨天”点击“查询” 5. 等待表格重新加载读取表格所有行数据 6. 将字段整理为CSV格式保存到 /data/orders_YYYY-MM-DD.csv 7. 如果中途失败最多重试1次仍失败就停止并报告卡在哪个步骤 input: - 日期范围默认昨天 output: - CSV文件路径 expected_output: - 包含订单编号、客户名、金额、状态的CSV文件这里有个非常关键的细节instruction里对页面的描述越具体越好。比如“点击登录按钮”就不如“点击右上角红色‘登录’按钮”稳定。因为页面上的同名元素可能有多个描述清晰能显著减少AI点错地方的概率。2.3 登录态与会话管理让AI记住你的登录状态做浏览器自动化最难缠的不是点击而是登录态。我刚开始让AI操作后台时每次任务都要重新登录烦得要死。后来弄清楚了一套比较成熟的会话管理姿势把浏览器的用户数据目录user data dir单独指定为一个固定目录类似/data/openclaw-browser-profile这样每次启动Chromium都会复用这个目录的登录Cookie、Token和LocalStorage。第一次运行Skill时人工登录一次之后Agent每次打开浏览器都是“已登录”状态。不过要特别注意不要让Skill里的指令暴露账号密码明文。我见过有人直接在SKILL.md里写死密码这等于把钥匙贴在门上。正确做法是用环境变量注入export ORDER_BACKEND_USERadmin export ORDER_BACKEND_PASSyour-password然后SKILL.md里只写“从环境变量读取账号密码”执行器脚本里再做变量替换。3. 完整实操让AI替你跑通一个网页任务3.1 先选一个适合练手的场景我强烈建议第一次尝试的人别上来就做复杂任务选一个步骤数量在5到10步之间、有明确完成标志的场景。我练手用的是这个每天早上9点自动登录公司内部数据后台导出前一天的销售数据整理成CSV发到工作群里。这个任务覆盖了登录、页面跳转、表单操作、数据提取、文件落地、外部通知几个核心能力跑通一遍大部分浏览器自动化场景的思路就都有了。正式开工前我会先把人工操作流程走一遍记录每一步做了什么。这步别偷懒因为你要把这些步骤翻译成Agent能看懂的指令自己都没走通就交给AI肯定翻车。3.2 编写Skill和执行器有了流程记录就开始写Skill。SKILL.md负责“告诉AI目标与步骤”执行器脚本负责“实际调用浏览器API”。下面是一个用Playwright写的最小化执行器示例from playwright.sync_api import sync_playwright import csv, datetime, os # 从环境变量读取配置 USERNAME os.environ[ORDER_BACKEND_USER] PASSWORD os.environ[ORDER_BACKEND_PASS] PROFILE_DIR /data/openclaw-browser-profile def run_task(date_str: str): with sync_playwright() as p: # 使用持久化上下文复用登录状态 context p.chromium.launch_persistent_context( user_data_dirPROFILE_DIR, headlessFalse, channelchromium, ) page context.new_page() # Step 1: 打开后台 page.goto(https://admin.example.com/login) page.wait_for_load_state(networkidle) # Step 2: 检查登录状态 if page.locator(input[nameusername]).count() 0: page.fill(input[nameusername], USERNAME) page.fill(input[namepassword], PASSWORD) page.click(button:has-text(登录)) page.wait_for_load_state(networkidle) # Step 3: 进入订单管理 page.click(text订单管理) page.wait_for_selector(table.order-table) # Step 4: 设置日期并查询 page.click(input#start-date) page.fill(input#start-date, date_str) page.click(button:has-text(查询)) page.wait_for_timeout(2000) # 等待表格刷新 # Step 5: 提取表格数据 rows page.locator(table.order-table tbody tr).all_text_contents() data [row.split(\t) for row in rows] # Step 6: 保存CSV output_file f/data/orders_{date_str}.csv with open(output_file, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerows(data) print(f任务完成共导出 {len(data)} 行文件{output_file}) context.close() if __name__ __main__: yesterday (datetime.date.today() - datetime.timedelta(days1)).isoformat() run_task(yesterday)这个脚本的思路是所有操作都走“语义化选择器”比如button:has-text(登录)、input#start-date比裸写XPath稳得多。有些页面元素加载慢Playwright的自动等待会处理大部分情况但遇到表格刷新这种“页面结构没变、内容变了”的情况我的经验是加一个短暂的显式等待比硬等着元素出现更靠谱。3.3 把任务跑起来并挂成定时执行Skill写好之后直接在OpenClaw里下达自然语言指令openclaw run 执行每日订单汇总任务日期取昨天Agent会读取SKILL.md加载Python执行器启动浏览器一步步执行。第一次跑建议开headlessFalse就是让浏览器窗口弹出来你盯着它做。别偷懒AI操作网页的过程全程看着能更快发现问题。确认任务能稳定成功后再进入定时调度。OpenClaw自带Schedule能力openclaw schedule --name daily_orders --cron 0 9 * * * --task 执行每日订单汇总任务这条命令会注册一个每天9点执行的定时任务。实际用下来我发现定时任务比手动跑更容易暴露问题因为网页状态每天都在变——偶尔会遇到弹窗、改版、接口变慢。所以建议再加一个失败通知比如通过Webhook把结果推到工作群这样跑挂了你能第一时间知道。4. 常见问题与排查技巧实录浏览器自动化最大的坑往往不是AI不聪明而是环境的“不稳定性”。我把这段时间遇到的典型问题整理成了一张速查表问题现象可能原因解决方案AI操作到一半浏览器白屏页面崩溃或内存溢出增加可用内存定期重启浏览器进程总是跳到登录页登录态过期用持久化Profile检查Cookie有效期元素定位失败找不到按钮页面用了动态渲染/懒加载改用更稳定的文本选择器增加等待时间点击了但没反应页面有遮罩层或弹窗指令里加“若存在弹窗先关闭”表格数据抓不全页面分页/虚拟滚动让AI先判断总页数逐页读取任务执行很慢模型推理慢页面加载慢换更快的模型把重复性步骤合并4.1 登录态反复失效怎么办这是最高频的问题。现象是今天跑得好好的明天一执行就跳到登录页。解决思路有几个先把Profile目录备份一下确认是不是Cookie确实过期了。很多后台系统有“7天免登录”选项人工登录时勾选上能延长有效期。在SKILL.md里增加“检测到登录页面且无法登录时停止任务并通知管理员”防止AI在登录页死循环。一个容易被忽略的坑是多个任务共用同一个Profile目录时可能出现并发冲突。两个浏览器同时写同一个Profile文件夹会互相踢下线。一个任务一个Profile不要共用。4.2 页面元素定位失败现代前端大量使用动态class名比如_ngcontent-abc123这种今天一个名、明天一个名。如果SKILL.md里写了这种选择器下次就跑不通。我的经验是优先用文本定位button:has-text(查询)、text订单管理文本变动的概率远低于class名。优先用稳定的id表单元素一般有id属性除非前端工程师闲得没事不会乱改。避免用“第3个按钮”这种索引定位页面一改顺序就崩。另外遇到iframe内嵌页面时Playwright默认不会进入iframe内容需要先跳转frame。这类结构的处理要单独在SKILL.md里写清楚否则AI很可能在页面上找半天找不到元素。4.3 被网站识别为机器人的处理思路有些网站会做基本的风控比如检测到“非人类”鼠标轨迹就弹验证码。我的处理方式优先保证合法合规只对自己有权限的系统做自动化尊重网站使用条款不碰有明确禁止自动化声明的站点。正常业务场景比如公司后台一般不会拦如果拦了可以在指令里告诉AI“页面出现验证码时停止并通知人工处理”不要让AI硬闯。可以降低操作频率不要在几毫秒内连续点击模拟正常人的节奏。不要用headless模式访问严格风控的页面无头浏览器的指纹很容易被识别。这里还想多说一句浏览器自动化的边界是“帮你干活”不是“帮你破坏规则”。不该自动化的系统别自动化不该绕过的验证别绕过。我在自己项目里只操作授权范围内的系统和公开页面这一点非常重要。4.4 运行不稳定与资源占用浏览器自动化是吃内存的大户尤其是长时间运行后Chromium进程会越积越多。我遇到过跑了一周后服务器内存告罄的情况。解决办法定时任务执行完后通过脚本强制清理残留的chromium进程。每个任务结束前执行context.close()关闭浏览器上下文。长期运行的机器建议给OpenClaw单独配一个2GB以上的内存配额。日志一定要开出错时看日志比猜强一万倍。OpenClaw默认会输出任务日志遇到报错先看日志里的调用栈和页面截图部分Skill会自动截图。5. 进阶扩展把浏览器自动化变成真正的生产力5.1 多页面协作与跨网站数据流转跑通单页面任务之后可以尝试更复杂的场景A网站的登录用户信息提取后填入B网站的表单。这种跨站数据流转本质上就是多个Skill的串联。我的做法是把“从A提取数据”和“向B填写数据”分别写成两个独立Skill再建一个编排Skill先调用提取、把结果保存为临时文件、再调用填写。好处是每个Skill都能单独测试出了问题只修其中一个链路。串行任务的开销主要在模型推理次数上任务链条越长、耗时越长。如果经常跑固定链路可以考虑把一些中间判断逻辑固化到Python执行器里减少模型参与既快又省。5.2 安全与权限控制红线这点必须单独拿出来说。AI操作网页的权限一旦放开风险就上来了。我给Agent默认画了三道红线不读取、不写入与任务无关的个人隐私信息。不访问未授权系统不尝试绕过任何访问控制。不执行涉及资金、密码修改、删除数据的操作除非有人工二次确认。在OpenClaw里我会给敏感操作加“确认步骤”就是在SKILL.md里写明“执行前必须先暂停输出操作内容并等待用户确认”。这样AI不会自作主张安全性高很多。另外浏览器Profile目录里存了大量登录凭据要当作敏感数据来保护。我对这个目录做了定时加密备份防止机器丢失后凭据泄露。5.3 几条越用越顺手的经验这段时间用下来我最大的体会是OpenClaw浏览器自动化的效果七分靠Skill设计三分靠模型能力。下面几条经验是我用了很久才总结出来的。第一Skill的指令要写成“最笨的步骤”而不是“聪明的目标”。你写“把订单数据导出来”模型可能会自由发挥你写“打开后台→点订单管理→选日期→点查询→读表格→存文件”模型就稳定得多。AI擅长的是把你说清楚的步骤执行好而不是替你猜业务逻辑。第二日志和截图是调试利器。初期不稳定时我会在关键步骤后加截图OpenClaw的浏览器Skill可以自动保存页面截图。跑挂的时候翻截图一眼就能看出卡在哪一步。第三从小场景开始积累。不要一上来就搞全自动无人值守先做“AI操作、你盯着”再过渡到“AI操作、出错叫你”最后才敢完全放手。信任是慢慢建立的。最后分享一个小技巧每次业务页面改版后不要急着改代码先把新页面的人工操作流程走一遍然后把新步骤用自然语言更新到SKILL.md里。OpenClaw的Skill本质是文本文件改起来非常轻量这也正是它比传统自动化脚本灵活的地方。浏览器自动化不是一个“写完就完事”的项目它会随着你的业务页面一起演化越磨合越顺手。