我花了好几个小时，终于把 OpenClaw 调到像人类一样控制浏览器了

AI 浏览器自动化不稳定，99%不是模型问题

我刚把 OpenClaw（龙虾🦞）调到像人类一样稳定控制浏览器，才真正搞明白这件事。

很多人遇到的是这种情况：

• 一会儿乱点按钮
• 一会儿新开窗口
• 一会儿掉登录态
• 一会儿靠截图“猜页面”
• 一会儿像失忆一样不知道自己在哪个 tab

看起来像什么？

👉 模型不稳定
👉 自动化能力不够

其实都不是。

---

真正的问题只有一个

AI 没有活在同一个浏览器世界里。

---

表象：你以为它在一个浏览器里

我一开始也以为很简单：

让 OpenClaw 控制我正在用的 Chrome：

• 打开 X
• 搜索
• 滚动
• 点链接
• 切 tab

听起来很基础对吧？

结果一上来就崩：

• 有时候用我的 Chrome
• 有时候新开一个浏览器
• 有时候有登录态
• 有时候又变未登录

很多人会觉得：

• cookie 丢了 ❌
• 会话过期 ❌
• 网站抽风 ❌

不是。

---

本质：浏览器上下文分裂

OpenClaw 在“打开浏览器”这件事上，可能会走很多路径：

• browser_* 工具
• Playwright MCP
• Chrome extension relay
• opencli
• shell 直接拉起 Chrome

这些路径表面一样，本质完全不同：

• 不同 profile
• 不同 cookie
• 不同 tab
• 不同 DOM 状态

结果就是：

你以为 AI 在连续操作
其实它每一步都在不同浏览器里

---

核心结论

浏览器链路是否唯一，决定一切。

为什么浏览器自动化最容易翻车？

不是因为慢，而是：

不一致。

---

解法：收敛成一条链路

我最后只做了一件事：

把所有路径收敛成一条。

---

核心方案（一句话）

只保留一条浏览器主链路：系统 Chrome + Browser Relay + DOM 读取

---

架构拆解（三层）

1️⃣ 浏览器固定为系统 Chrome

不用隔离浏览器，不新开实例。

直接复用已有环境：

• X
• GitHub
• Gmail
• 飞书
• 各类后台

👉 本质：复用真实用户上下文

---

2️⃣ 控制方式固定为 Browser Relay

不是 MCP，不是 opencli。

👉 是真正接管当前 tab 的链路

---

3️⃣ 用 tab 状态判断是否成功

不要靠感觉。

看这个：

• chrome: running (0 tabs) ❌
• chrome: running (1 tabs) ✅

👉 这是分水岭

---

稳定性的关键5步

1️⃣ 默认 browser profile = chrome
（保证路径唯一）

2️⃣ 安装 Browser Relay 扩展
（只是开始）

3️⃣ 填对 gateway token
（极易出错）

4️⃣ 在目标 tab 手动点 ON
（真正 attach）

5️⃣ 禁止 fallback
（不允许偷偷换浏览器路径）

---

进一步优化（让它“像人”）

✅ 优化1：读取优先 DOM，不是截图

• snapshot / evaluate → 结构数据 ✅
• screenshot → 猜 ❌

👉 决定是否能连续操作

---

✅ 优化2：滚动用 JS

固定流程：

window.scrollBy(...)

然后：

• wait
• 再读取

👉 操作必须可重复，而不是临场发挥

---

调通后的变化（质变）

• 不再新开未登录窗口
• 能连续操作 X / GitHub
• 能滚动 + 读取 + 点击
• 不再“抽风式自动化”

你会明显感觉：

它不再是“偶尔成功的脚本”
而是“持续操作浏览器的代理”

---

三句总结（核心认知）

AI 不稳定，不是因为它不聪明
而是因为它活在多个浏览器世界里

浏览器自动化最大的问题
不是慢，而是上下文分裂

关键不是给 AI 一个浏览器
而是让它始终走同一条链路

---

后续

如果你也在做 AI Agent / 浏览器自动化，这个坑基本绕不过去。

我已经把这套方案整理成一个内部 skill：

👉 auto-chrome-control

后面会放到 DeepCarry 会员社区里。