夜雨聆风如果你用 OpenClaw（或任何 AI 助手）做过网页调研，大概率被这几件事折磨过：
•昨天还能用，今天就卡在登录/验证
•状态丢得很随意：切个网站就像换一套环境
•一想自动化就触发风控，越点越像机器人
•最烦的是：你不是在调研，你是在“重试、等待、排障”
后来我才承认：问题不在 AI 是否聪明，而在浏览器这件事没有被当成长期可复用的基础设施。
所以我做了一次升级：给 OpenClaw 补上第三种浏览器控制方式
控制一个常驻、只需要登录一次的 Chrome，并用更像真人的节奏去访问网页。
跑通之后，我把它沉淀成两个 skill：一个负责“常驻浏览器”，一个负责“X 工作台流程”。从那之后，调研基本不再被浏览器打断。
为什么默认方案会“能用但不稳”？
OpenClaw 常见的浏览器方式，大概就两类：
1）隔离浏览器（Isolated Browser）
它干净、隔离，但最大的问题是：不继承登录态。
对需要登录的网站来说，你永远像新访客，验证更频繁，链路更脆。
2）Chrome + 扩展（Browser Relay）
它能继承你 Chrome 的登录态，但更像“人工接线”：你要手动把 tab 接上；切任务、切页面时流程变重。
更关键的是，“稳定操作节奏”并没有被固化。
一句话：都能跑，但很难做到我想要的——长期稳定、可复用、少翻车。
第三种方式：常驻浏览器 + CDP
我的目标很明确：
•只登录一次，后续长期记住状态
•控制流程要可控：能等待加载、确认状态、再动作
•尽量少触发风控（更像人，不像脚本）
我最后用的是 CDP（Chrome DevTools Protocol）：Chrome 提供的一套远程控制协议。
关键不在“能控制浏览器”这句话，而在两点：
•控制的是一个常驻的、已经登录过的 Chrome（登录态不再每次丢）
•可以把“操作规范”写进流程：不满足条件就不推进（减少随机翻车）
浏览器从“临时工具”变成“长期资产”，体验会完全不一样。
我沉淀出来的两个 skill
Skill 1：常驻 Chrome（CDP）启动/检查（通用）
这个 skill 负责把“浏览器工位”搭好并保持可复用：
•Chrome 常驻运行
•cookie / localStorage 保留
•固定端口/通道对外提供控制能力
它解决的是：别每次从重新登录开始。
Skill 2：X 工作台（稳定控制流程）
第二个 skill 我就直接说明：它是给 X 用的。
原因很现实：X 的风控更苛刻。你越急、越像脚本，越容易翻车。
我后来发现：解决风控不靠更强模型，更多靠更像人的节奏。所以我把一些规则固化成流程（stability gates）：
•页面没加载完不乱点
•出现 retry / try again / something went wrong 就停，不硬冲
•少滚动、慢一点、一步一确认状态
•低频、可回溯（出了问题知道停在哪一步）
虽然这个 skill 叫 X 工作台，但逻辑是通用的：
小红书、知乎等平台，本质上也是“登录态稳定 + 操作节奏像人 + 遇到异常能刹车”。
你换平台，只是把站点规则与 UI 习惯重新适配一遍。
做完后的变化：调研终于不再频繁打断写作
这次升级带来的收益很直接：
•登录态稳定，验证/重登明显变少
•访问过程更可控，异常能及时刹车
•调研开始像一条稳定管道，而不是“不断重试”的碎片时间
•更重要：这套能力不绑定某一个网站，换平台也是同一类打法
如果你也在用 AI 做调研/写作，我的建议就一句：
别把浏览器当成“临时打开网页”，把它当成“生产工具链的一部分”，值得为它做一次基础设施升级。
GitHub（两个 skill 开源地址）
•常驻浏览器（CDP）Skill：https://github.com/2016geek/openclaw-cdp-workbench
•X 工作台 Skill：https://github.com/2016geek/openclaw-cdp-workbench
一句克制的使用提醒
如果你要长期稳定访问：宁可慢一点、少一点，也别“高频猛操作”。
对风控来说，“像人”比“快”更重要。
