OpenClaw 加远程浏览器使用教程
如果你的 OpenClaw 运行在 Docker 环境里，往往不适合直接在容器内部跑完整的图形浏览器。这时候，更稳妥的方案就是：在 OpenClaw 里保留浏览自动化能力，但把真正的浏览器执行放到远程浏览器环境中。
一、为什么要使用远程浏览器
- Docker 环境通常更适合运行无头服务，不适合长期维护本地图形浏览器。
- 2. 远程浏览器可以把浏览器依赖、系统库和图形环境从主容器里拆出去。
- 3. 对于截图、登录、表单填写、页面抓取、后台操作这类任务，远程浏览器通常更稳定。
二、推荐的整体方案
推荐采用下面这套结构：
OpenClaw + agent-browser CLI + 远程浏览器
其中：
- OpenClaw 负责调度和任务编排
- – agent-browser 负责具体的浏览器操作命令
- – 远程浏览器负责实际打开网页、点击、输入和截图
三、安装思路
标准文档一般会写：
- npm install -g agent-browser
- 2. agent-browser install
但如果你已经自己配置好了远程浏览器，那么很多情况下只需要安装 CLI 即可：
npm install -g agent-browser
在这种模式下，agent-browser install 主要是给本地浏览器运行环境做准备；如果你的浏览器执行已经完全走远程，未必一定需要再安装本地浏览器依赖。
四、如何验证是否工作正常
最简单的 smoke test 可以用下面几步：
- 打开网页
- 2. 读取标题
- 3. 截图
- 4. 关闭浏览器
例如：
- 打开 https://example.com
- – 获取标题 Example Domain
- – 对页面截图
- – 关闭会话
如果这几步都能成功，说明 CLI 到远程浏览器的链路已经打通。
五、实际使用建议
在 Docker 场景里，更推荐把 agent-browser 作为主浏览执行方案，原因有三个：
- 命令行方式更容易排查和复现
- 2. 更适合做自动化脚本和 smoke test
- 3. 更符合“轻客户端 + 远程执行端”的架构
如果系统里同时还有内置 browser 工具，可以把它保留为辅助方案，用来做快速验证或交叉排查。
六、常见问题
- 能打开网页但某些高级功能不稳定
- 这类情况未必是配置错误，也可能和远程浏览器兼容性、页面结构、文件上传控件实现方式有关。
2. record 能开始但不能导出视频
通常是宿主机缺少 ffmpeg，而不是 agent-browser 主功能异常。
3. 上传图片偶尔失败
文件上传往往比普通点击和输入更依赖具体页面结构，建议单独做回归测试。
七、总结
如果你的 OpenClaw 运行在 Docker 中，而本地只能使用无头环境，那么“OpenClaw + agent-browser + 远程浏览器”通常是更稳、更适合长期维护的方案。
核心思路不是把所有东西都塞进一个容器里，而是让容器负责调度，让远程浏览器负责执行。这样更清晰，也更容易排障。
