AIOps 探索:哇!OpenClaw 接入 Playwright CLI 后,我让 AI 自动登录网站、截图、采集信息

研究 AIOps 已有数月，目前手里有不少可落地的方案了，接下来会把这些方案全部整理到我的公众号里。欢迎大家关注，可以把你遇到的场景在评论区留言。我会在能力范围内给你提供思路和建议。

前段时间我一直在折腾 OpenClaw 的各种能力，这不，手又有点痒了。我就在想，既然 OpenClaw 已经能调工具、能接 skill、还能驱动浏览器，那能不能把“网页自动化”这件事也真正接进来？

还真可以。

这次我接入的是 Playwright CLI。接完之后，我直接让 AI 去打开网页、自动登录网站、截图页面、采集页面里的关键信息，甚至还能一路操作到公众号后台草稿箱。整个过程跑下来，我最大的感受就一句话：这套组合太适合做浏览器自动化执行层了。

今天这篇文章，我就带大家来看下这个实战过程。

一、为什么这个方向值得做？

很多运维、测试、运营同学，平时都会遇到一类特别碎、但又不得不做的工作。

比如：

1. 登录后台查看系统状态
2. 进入某个页面截图留档
3. 采集页面上的关键信息
4. 重复点击固定按钮完成流程
5. 把网页里的内容整理到文档、消息或者知识库里

这些动作单看都不难，但特别耗时间，而且重复率很高。

以前面对这些事，大家通常有几种办法。

第一种，人工自己点。

优点是简单，缺点也很明显，就是慢，而且一旦重复次数多了，人会很烦。

第二种，自己写 Selenium 或 Playwright 脚本。

这当然可行，但很多时候门槛并不低。你要先想流程，再找元素，再调脚本，还要处理页面变化、登录态、异常情况。

第三种，借助 RPA 平台去编排。

也不是不行，但在一些临时场景里，又显得有点重。

而 OpenClaw + Playwright CLI 这一套，刚好卡在一个非常舒服的位置：既保留了浏览器自动化能力，又保留了 AI 的自然语言理解和流程协作能力。

说白了，就是你不用每次都从零手搓一套脚本，也不用先上一个特别重的平台，而是可以先让 AI 帮你把事做起来。

二、这次用到的技术组合

我这次用到的组合其实很简单：

1. OpenClaw
2. Playwright CLI
3. 本地浏览器环境
4. 针对网页自动化整理好的 skill

整体思路是这样的。

先在本地安装 Playwright CLI，然后把它的常用命令和工作流沉淀成 skill，再让 OpenClaw 知道：什么场景该调用它、该怎么调用、调用之后怎样判断页面状态、怎样继续下一步。

这样一来，我直接对 AI 说一句自然语言，它就能把这句话拆成一串浏览器动作去执行。

这和传统“先写好完整脚本再运行”的思路不太一样，它更像是一种“先让 AI 帮你跑通，再逐步沉淀成可复用能力”的路线。

三、Playwright CLI 为什么适合做这件事？

这次跑完之后，我觉得 Playwright CLI 之所以适合和 OpenClaw 搭配，至少有三个原因。

1. 它足够轻，但能力又不弱

很多工具的问题在于，要么太轻，只能做点简单动作；要么太重，刚上手就要搭一整套工程。

Playwright CLI 刚好不是这样。

它的好处是，装好之后，你在命令行里就能直接做这些动作：

1. 打开网页
2. 点击元素
3. 输入内容
4. 切换标签页
5. 做页面快照
6. 截图
7. 查看控制台输出
8. 执行一段浏览器代码

也就是说，它不是一个“浏览器截图小工具”，而是一整套可以被命令行调度的浏览器自动化执行层。

2. 它特别适合被 Agent 调用

我觉得这个点非常关键。

Agent 最怕什么？

最怕一次调用做太多事，失败了还不知道卡在哪。

而 Playwright CLI 的命令天然比较原子化，比如 open、click、type、fill、snapshot、tab-list、tab-select 等等。

这种结构非常适合 AI 一步一步执行。

AI 每做完一步，都可以看看结果，再决定下一步怎么走。比起一口气生成几百行浏览器脚本，我觉得这种方式要稳很多。

3. 它允许“人机协作式自动化”

这是我这次最有感触的一点。

很多网页自动化方案，一遇到登录、验证码、风控、弹窗，就容易卡死。

但 Playwright CLI 配合 OpenClaw 的方式，并不是强行追求“完全无人值守”。它更像是一种人机协作：

1. 登录你可以手动来
2. 后面的重复动作 AI 来
3. 页面异常时 AI 会停下来提示你接管
4. 处理完之后再继续执行

这种模式我觉得特别适合真实业务场景，因为它没那么理想化，但反而更能落地。

四、我这次做了哪些真实测试？

为了确认这套方案不是“只能演示”，我这次专门做了几个比较真实的测试。

1. 让 AI 自动查天气

我先让它做最简单的网页搜索场景：

1. 打开百度
2. 搜索南京今天天气怎么样
3. 再搜索杭州今天天气怎么样
4. 从结果页里提取天气信息

这个场景虽然简单，但已经足够说明一个问题：AI 不只是“会聊天”，它已经可以替你去操作网页并读结果了。

它完成的是一整条链路：

自然语言指令 → 浏览器动作 → 页面结果提取。

我觉得这就是浏览器自动化真正开始变得“可用”的起点。

2. 打开 Grok 并识别安全验证

后面我又让它尝试打开 Grok。

结果页面遇到了 Cloudflare 安全验证。

但这个过程反而让我觉得它更靠谱。

因为它没有乱点，也没有装作成功，而是明确告诉我：页面已经打开，但现在卡在安全验证，需要人工接管。

这说明它不是在死板执行命令，而是已经开始具备一点流程判断能力了。

这个能力在真实自动化里特别重要，因为网页世界不是静止不变的。页面会变，状态会变，风控会触发，AI 不能只会“照本宣科”。

3. 直接接入公众号后台写草稿

这个场景是我最喜欢的一段。

我让它：

1. 打开微信公众号后台
2. 等我手动登录
3. 找到新建文章入口
4. 输入文章标题和正文
5. 保存为草稿

最后它真的把文章写进了草稿箱。

一开始我们是直接往公众号后台里输入正文，后面发现排版效果一般，还踩到了一个坑：微信公众号后台并不原生支持 Markdown 原文，直接把 ## 这种写法写进去，只会原样显示。

再后来，我们又继续摸索出一条更好的路线：

先把文章 Markdown 源文送进在线转换器，点击 Copy Rich Text，再回到公众号后台粘贴富文本内容。

这一版的效果就好很多，标题块、段落、编号结构都正常了。

这一点我觉得非常有意思，因为它说明：

真正可用的自动化，不一定是“一步到位”的，而是不断调通每一层之后，慢慢把流程沉淀下来。

五、它到底能落地到哪些场景？

很多人看到这里，可能会觉得这只是个“写文章”的玩法。

其实不是。

我觉得它能落地的场景比想象中多得多。

1. 运维场景

比如：

1. 登录监控平台查看状态
2. 打开告警页面截图
3. 采集当前面板里的关键指标
4. 进入后台确认某个服务页面是否正常

这些都特别适合浏览器自动化。

2. 测试场景

比如：

1. 自动打开网页验证某个页面是否正常显示
2. 自动截图留档
3. 自动检查某些关键元素是否存在
4. 自动模拟一段固定点击流程

这类轻量级任务，根本没必要每次都单独写大脚本。

3. 运营场景

比如：

1. 登录公众号后台写草稿
2. 打开网页采集素材
3. 对活动页面截图
4. 采集竞品页面信息
5. 把结果整理后再输出给人确认

这类工作特别适合“AI 辅助 + 浏览器自动化”的模式。

六、我对这套方案的几个看法

这次折腾完之后，我最大的感受有三个。

1. 它不是替代脚本，而是降低脚本门槛

很多人一看到 AI 自动化，就会问：以后是不是都不用写脚本了？

我的看法不是这样。

脚本当然依然重要，但以前很多“值不值得写脚本”的灰色地带，现在可以先交给 AI 去跑通。

也就是说：

1. 简单任务，直接自然语言驱动
2. 稍复杂任务，沉淀成 skill
3. 更复杂、需要稳定复用的，再继续脚本化

这个路径比一上来就手写一整套东西，要顺很多。

2. 半自动协作，可能比全自动更现实

很多自动化项目最大的问题，就是太想一步到位。

但真实世界里，登录、验证码、风控、页面变化这些问题，是客观存在的。

所以我现在反而更认同一种更现实的思路：

1. 关键步骤由人接管
2. 重复步骤交给 AI
3. 遇到异常时及时暂停
4. 恢复后再继续执行

这种方式听起来没那么酷，但是真的更能落地。

3. skill 才是长期价值所在

如果这次只停留在“装了一个 Playwright CLI”，那价值其实有限。

最有价值的是，我们把一次次成功的流程沉淀成了 skill。

这样下次再做类似任务时，AI 不是临场猜，而是走你已经验证过的路径。

这才是可复用、可积累、可持续演进的关键。

七、最关键的步骤是什么？

如果你也想复现这条路，我觉得最关键的一步不是安装工具，而是：

把成功流程沉淀下来。

因为真正值钱的，不是某一次点成功了，而是你把它变成了下一次还能继续调用的能力。

一旦这个思路跑通，后面很多事情都会越来越顺：

1. 查页面
2. 截图
3. 采集信息
4. 走后台流程
5. 写公众号草稿
6. 做网页协作式自动化

这些都能慢慢变成你自己的 AI 自动化资产。

八、总结

这次把 OpenClaw 和 Playwright CLI 接起来之后，我最大的感受就是：AI 助手终于开始真正“动手”了。

它不再只是给建议、写文字、讲思路，而是已经能在浏览器里帮你执行一整段真实操作。

虽然现在还不是那种完全无人值守的终极形态，但对很多日常工作来说，它已经足够实用了。

尤其是对于运维、测试、运营这些高重复动作特别多的岗位，我觉得这个方向非常值得继续深挖。

后面我也会继续把更多可落地的 OpenClaw 实战整理出来，比如浏览器自动化更多玩法、飞书文档自动化、公众号后台自动化、以及和 MCP 能力的进一步结合。

希望大家能看明白这个思路。

最后介绍下我的公众号：研究 AIOps 已有数月，目前手里有不少可落地的方案了，接下来会把这些方案全部整理到我的公众号里。如果你觉得这篇文章有帮助，欢迎关注，分享给更多运维伙伴。