最近在做一个内部工具链的改造需要把一批重复的网页操作从人工点按里解放出来。我选了一个自己很看好的方向用 OpenClaw 做浏览器端自动化项目编号排到了 13代表前面已经踩过 12 轮类似问题的坑。这篇文章就是把这次落地全过程整理出来从环境准备到 AI 指令驱动的完整链路尽量把当时怎么想的、怎么选的、怎么排错都讲清楚适合那些想给网页操作减负、又不想被零散脚本拖垮的开发者和运维朋友做参考。1. 项目定位与整体设计思路1.1 项目想解决什么你手上有多少工作是“每天重复打开网页、填表、点按钮、复制数据到表格”的我见过某公司财务团队每天花两小时打开对账页面手动拉取报表再填进内部系统也见过运营同事守着活动后台盯库存数字隔几分钟刷新一次。这些场景的共同特点是操作路径固定、重复次数极高、判断逻辑简单但交给纯脚本写又容易被页面改版、弹窗、加载延迟这类问题击穿。OpenClaw 这类的浏览器自动化工具链解决的就是“让浏览器自己动起来”这件事。它不再停留在模拟点击的层面而是把一台浏览器当作可编程的执行环境能打开页面、定位元素、填写输入、提交表单、等待结果、抽取数据也支持多页面联动和会话状态复用。这套东西落地的意义不只是节省时间更是把“人盯着浏览器”的工作变成“机器盯着浏览器”出错可以记录、可以重跑还能在夜间批量执行。这个项目适合谁参考如果你维护内部运维系统、做数据分析、写测试脚本或者经常在浏览器里做重复性操作这套思路可以直接套用。1.2 为什么选 OpenClaw 而不是自己写选择器脚本早期做自动化很多人第一反应是写原生脚本自己拼 URL、发 HTTP 请求、手动解析 HTML。但实际试过就明白浏览器里有大量状态是 HTTP 请求模拟不了的比如前端 JS 动态渲染的表格、登录后 session 里的用户信息、复杂交互后的页面流转。HTTP 脚本维护成本高页面一改就墙倒屋塌。换一个层面讲即使采用常规的浏览器自动化方案也容易陷入“选择器地狱”——你的脚本里全是document.querySelector(#app div.main-content div.table-wrapper table tbody tr:nth-child(3) td:nth-child(2))这样的长选择器稍一改版就要全部返工。OpenClaw 把页面操作用更高层的方式组织起来提供“任务”和“步骤”的抽象你关心的不再是某个按钮的 CSS 路径而是“填写登录表单”这件事本身。我在选型时还有另一个考量OpenClaw 能让我用自然语言描述目标操作由它自己拆解成具体动作。这意味着页面改版时只要意图不变描述不变动作序列可以自动适配。这种语义层级的自动化才经得起时间折腾。1.3 任务划分从人工操作到自动化动作序列落地之前我建议先把人工操作拆成动作单元。以“每日对账”为例拆开就是打开登录页、输入账号密码、点击登录、等待页面跳转、进入对账菜单、选择日期范围、点击查询、从结果表格里取出指定列、导出或写入本地文件。每个动作至少包含一个操作对象和期望结果。这一步完成后用 OpenClaw 的过程就是一个动作一个动作去映射。映射不需要一次性全做先挑一条最稳定的主路径跑通再把异常分支弹窗、无数据、超时、登录失效逐步补齐。设计阶段把动作拆得足够细后面的排错会轻松很多因为你能很快知道是哪一步断了而不是对着报错日志猜。2. 环境准备与核心概念2.1 安装与初始化OpenClaw 的安装没有特别复杂我的环境是 Python 3.11直接通过包管理工具装 CLIpip install openclaw-cli openclaw doctordoctor命令会检查本机浏览器内核、驱动版本、Python 环境等是否匹配比较省事。如果检查报错大多数情况是内核版本和驱动版本不一致按提示调整即可。装完后初始化一个项目openclaw init --project demo_autotask --browser chromium --headless false初始化会生成一个标准目录包含配置文件、任务目录和产物目录。注意--headless false是开发阶段用的方便观察浏览器每一步在做什么等任务稳定后再改成true跑无头模式节省资源。Windows 上如果你用的是企业内网环境可能需要预留代理配置的位置这个后面配置文件里专门有一项。初次初始化如果遇到下载浏览器内核超时可以手动指定内核路径不一定非要走自动下载。2.2 四个核心概念会话、动作、断言、工件用 OpenClaw 写自动化绕不开这四个词。会话Session是浏览器活动的容器相当于一个人工操作的“浏览器窗口”动作Action是对页面的一次操作比如goto、click、fill、wait_for断言Expect用来确认操作结果比如“页面上出现了某段文字”这一步相当于人工操作后的自查工件Artifact是任务产生的成果截图、导出的 CSV、保存的 HTML 都算。这四个概念的关系可以类比成做菜会话是“厨房”动作是“切菜、下锅、翻勺”断言是“尝一口判断熟没熟”工件是“最终端上桌的菜”。有了这层抽象你的自动化脚本就不是一堆零散浏览器调用而是一条条带着验证的流水线。2.3 工程目录与配置文件初始化后的目录长这样demo_autotask/ config.yaml tasks/ login.yaml daily_report.yaml hooks/ notify.py artifacts/ screenshots/ data/config.yaml是全局配置我一般会把浏览器路径、超时时间、重试次数、通知地址都放进去browser: executable_path: C:/Program Files/Chromium/Application/chrome.exe headless: false user_data_dir: ./profile timeout: page_load: 15000 element_visible: 10000 retry: max_attempts: 3 backoff_seconds: 2这里有一个经验不要把账号密码直接写在任务 YAML 里。OpenClaw 支持环境变量引用我都是配置${LOGIN_USER}和${LOGIN_PASS}本地再放到.env文件并且.env不进版本库。自动化工具是帮你减负的别让它变成新的安全隐患。3. 一个最小可用的自动化脚本怎么落地3.1 打开页面并验证标题不管你最终任务多复杂第一个脚本都应该从“能打开页面”开始。我习惯用 Python 模式写核心逻辑因为断言和数据处理时可以嵌入更多判断from openclaw import ClawSession, Expect session ClawSession(configconfig.yaml) with session.page() as page: page.goto(https://example.com) Expect.title_contains(Example Domain) page.screenshot(artifacts/screenshots/home.png)这段代码里with session.page()是资源管理的核心你不需要手动关浏览器上下文管理器退出时自动收尾。Expect.title_contains是第一道防线页面没加载到指定标题直接抛错总比后面操作半天发现对象不存在再报错要早。为什么先把截图放在这一步因为截图是日志之外最直观的现场记录。任务执行失败时一张当时页面的截图能省下大量翻日志的时间我后来所有的自动化任务默认都至少保留失败截图。3.2 表单填写与登录接下来是登录场景。这里需要注意的是不要一上来就追求“全部自动化”先把目标站点的登录成功标志搞清楚是跳转到 Dashboard还是页面出现“欢迎回来”之类文字这个判断后面就是断言依据。page.goto(https://example.com/login) page.fill(#username, ${LOGIN_USER}) page.fill(#password, ${LOGIN_PASS}) page.click(#login-btn) Expect.text_visible(欢迎回来, timeout15000) page.screenshot(artifacts/screenshots/after_login.png)填表单时有个小坑很关键很多页面会在你点击输入框时先清空又填充fill之前最好确保元素已完成加载、处于可交互状态。我实际踩过的情况是页面里有两个同名输入框一个隐藏一个可见选择器取第一个结果就填错地方了。这时候宁可多写一个wait_for确认可见也不要赌选择器唯一。断言的超时时间我给到 15 秒因为登录跳转往往涉及后端校验、页面重定向、前端框架渲染三步少于这个时间容易偶发失败。跑完这一步任务建议顺手做“登录态持久化”session: save_state: ./profile/auth_state.json保存登录状态后下次任务可以直接加载认证信息跳过登录步骤这个对高频小任务特别有用。3.3 列表数据的提取与落地真正的日常工作中数据提取是最有价值的一环。比如从业务后台的任务列表里抓取编号、状态、处理时间。OpenClaw 里可以直接用提取动作- action: goto url: https://example.com/orders - action: wait_for selector: table.data-table timeout: 15000 - action: extract selector: table.data-table tbody tr fields: order_id: td:nth-child(1) status: td:nth-child(2) updated_at: td:nth-child(3) - action: save_to_csv path: artifacts/data/orders.csv这一步的核心在 selector 稳定性。我一般不会直接拷贝“右键复制选择器”得到的长路径而是优先用带有业务含义的属性或类名比如.data-table、[data-order-id]这类属性在页面改版时相对不容易变。字段映射里第几个单元格一旦确定后面数据清洗就轻松了。拿到 CSV 之后可以根据需要接后续处理发到企业微信、写入数据库、或作为定时报表的输入源。整个过程最耗耐心的不是写操作步骤而是等待策略的调校这个放到第 5 节集中讲。4. 让 AI 接管浏览器自然语言操作编排4.1 一条自然语言指令如何变成动作序列OpenClaw 和传统自动化脚本最大的区别是它内置了一个“任务编排层”。你可以不写任何 YAML直接给出一条指令from openclaw import Agent agent Agent() agent.run(打开登录页用配置好的账号密码登录等待出现欢迎文字然后进入订单列表把展示出来的数据存成 CSV)这个Agent内部会先对指令做意图拆解匹配到goto、fill、click、wait_for、extract这些动作然后根据页面实际情况生成执行步骤。你不需要关心每一步怎么定位元素Agent 会结合页面结构动态选择。我当时用的是某企业后台的列表查询功能页面加载是异步的数据表格比操作栏晚两秒才渲染出来。第一次让 Agent 跑的时候它在表格还没出现时就去取数据自然捞了个空。我把失败信息反馈回去它会自动调整等待策略第二次执行时先等待table.data-table可见再抽取。这种自我修正的特性在页面结构复杂的系统里价值极高。4.2 上下文记忆、重试与容错Agent 会保留当前任务的会话上下文。举个例子你要它“打开订单详情页把页面上金额超过 1000 的订单标出来”它先进入列表页拿到每个订单的链接再逐个访问详情页。这个过程中它不会忘记自己正在执行的核心目标也知道已经处理到第几个订单。容错机制也很重要。OpenClaw 里有重试策略不是简单重复执行原步骤而是会尝试换个路径达到同样目的。比如点击登录按钮没反应它会先排查是按钮被遮住、还是表单校验失败、又或是页面弹出遮挡层然后选择对应处理方式。这种“有脑子的重试”比单纯的 sleep 后重点一次靠谱得多。这一段我说点心得AI 模式不是万能的它适合“目标明确但操作路径可能变化”的场景如果你的页面结构完全稳定、操作步骤一成不变写死 YAML 反而更快更省。两条路在这个项目里我都用了日常维护性任务走 YAML 保证稳定临时分析任务走 Agent 省去配置成本。5. 常见故障现象、排查与处理5.1 元素定位不到等待策略与选择器优先级跑自动化最频繁的报错就是“元素找不到”。大多数情况下不是你真的选错了而是元素还没渲染完。解决的核心思想是“显式等待优于隐式等待”说白了就是明确告诉自己要等什么而不是睡死 5 秒再说。我推荐按这种优先级处理现象可能原因处理方式元素偶尔可见偶尔不可见页面加载快慢波动使用wait_for按元素可见等待而不是固定 sleep元素存在但不可见在折叠区域或视觉被遮挡先滚动到元素区域再操作确认没有遮挡层元素有两个相同选择器隐藏域和可见域冲突选择器加:visible或限定在某个容器范围文本被改动但结构稳定依赖文本定位导致失败尽量用 DOM 结构属性定位文本只做断言不做定位5.2 弹窗、iframe 与多标签页的处理弹窗和 iframe 是自动化脚本杀手但处理逻辑并不复杂。原生 alert 与确认框OpenClaw 里有默认行为可以直接接管复杂一点的业务弹层需要等待弹层出现、确认按钮可点再进入下一步。iframe 的问题在于它内部是独立文档外层选择器直接选不到。处理方式就是在动作里声明frame的定位器进入对应 frame 后再操作。多标签页场景则要注意目标页面焦点问题我写过不少“点击后新开标签页”的任务关键是切换 context 后再操作新标签内容不然你会一直操作旧页面。这套东西最容易出错的时间点是业务系统本身版本升级后弹窗文案变了。所以我在任务里专门写了一个 hook所有弹窗出现都截图并记录文案排错时能回溯是哪句话触发的问题。5.3 进程残留与会话失效自动化跑久了你会遇到两个和“状态”有关的问题本地浏览器进程残留、远端会话过期。前者多数是没有正确关闭 context 导致的长时间运行后会不断吃内存。解决办法很简单尽量用上下文管理器或者try/finally里显式关闭。会话失效则更隐蔽。之前做一个定时报表任务白天正常凌晨跑就失败。后来排查发现是目标站点的登录态有效期是 8 小时每天首次执行时间不固定导致后半程任务加载不到用户信息。解决办法是每次任务开始前先探测“是否仍处于登录态”通过访问一个明确的鉴权接口判断如果失效则自动重新登录。这样就把定时任务的稳定性从“靠运气”变成了“按逻辑”。6. 性能、稳定性与工程化落地6.1 复用浏览器实例与资源回收早期我犯过一个小白错误每跑一个任务就新开一个浏览器跑完退出任务多了以后 CPU 和内存飙得很高。要性能提升第一件事就是复用浏览器实例特别是加载同一个站点时内核复用能省下大量构建开销。但复用不等于放任。我具体做法是一个浏览器实例里按任务建 context任务结束只关 context 不关浏览器这样不同任务之间隔离 cookie 和缓存不会互相污染又保留了核心复用。这就好比一家餐馆的锅一直开着火但每道菜用干净的炒锅菜才不会串味。跑完后清理临时文件也是必要的。截图、中间 HTML、下载的临时文件如果没有按日期归档不用一个月就能把磁盘塞满。我在 hooks 里加了一个定时清理逻辑只保留最近 7 天的工件。6.2 并发任务与队列控制当自动化任务不止一个时就要面对并发问题。我不建议无脑开几十个并发因为目标站点通常不是给你做压力测试用的。更稳妥的方式是设计一个轻量任务队列控制最大并行数比如同时最多 3 个任务超出的排队。并发时的隔离注意三点独立 context、独立输出目录、独立日志前缀。如果你让两个任务共用一个 context账号串号、数据错乱都是必然的。队列里还要考虑慢任务的影响一个预期 1 分钟跑完却卡了 10 分钟的任务会堵住后面的所有队列所以要设置单任务超时时间和主动取消机制。6.3 可观测性日志、截图与通知工程化落地绕不开“出问题怎么第一时间知道”。我的方案分三层。第一层是日志每个任务执行时记录开始、每个动作耗时、断言结果、结束状态。第二层是失败截图加 DOM 快照截图给你看页面长什么样DOM 快照给你看页面结构有没有变化。第三层是通知关键任务失败时通过 webhook 发一条告警内容包括任务名、失败步骤、截图地址人不用盯着系统也能及时响应。这里分享一个个人的判断标准如果某个自动化任务连续两周都没出过一次失败告警你反而要警惕。因为很可能是页面结构变了但你的断言太宽松或者任务压根没被执行。真正的稳定是“有变化时能第一时间感知”不是“永远不出错”。结尾这次项目做到第 13 版最大的体会是“浏览器自动化不是把人工操作翻译成代码就结束了而是要设计一套能感知页面变化、能自洽重试、能暴露失败现场的系统”。OpenClaw 让我觉得顺手的地方正是它把粒度控制在了“操作意图”这一层而不是让我纠结每一次点击的细节坐标。最后分享一个小技巧。如果你要在一个不太稳定的页面上跑任务别一上来就追求全流程无人值守。先用截图加人工抽查的方式跑一周把失败记录里的共性原因找出来无论是等待时间不够还是元素选择器太脆弱都先修掉再放大执行规模。自动化的底气永远来自你对异常情况到底有多少预判。希望这篇记录能让你少走几步弯路也欢迎按自己的业务场景把它扩展成更适合自己的形态。