视频地址
一、开场
大家好，我是龙丽坤。
今天这期视频，我们聊一个很实用的话题：怎么让 OpenClaw 接管你已经登录好的浏览器，然后帮你完成发布内容、上传视频这类重复动作。
很多人一听会觉得，这不就是浏览器自动化吗？打开网页、点按钮、填表单，看起来好像并不难。
但真正难的地方，从来不是“会不会点页面”，而是“能不能稳定进入登录后的真实页面”。
验证码、短信验证、二步验证、人机校验，这些东西都不是靠几句提示词就能稳定穿过去的。你一旦频繁重试，还很容易触发 IP 风控，最后不是流程卡住，就是账号异常。
所以很多浏览器 Agent 演示起来很炫，但一碰到真实工作流就容易掉链子。问题不在它不会操作网页，而在于它过不了登录这道门。
二、核心思路
真正可用的思路，不是让 AI 从零开始模拟一个新用户，也不是让它去硬闯登录页，而是复用你已经授权过、已经登录好的浏览器会话。
也就是说，登录这一步还是你自己完成。AI 不负责闯门，而是在你把门打开之后，接手后面的动作。
这样做有三个明显好处：
- 更稳定。
- 更真实。
- 更符合日常运营场景。
而且你通常只需要登录一次，后面就可以持续复用，不需要每次都重新登录。
三、OpenClaw 的不同点
我们今天用的是 OpenClaw 配合 Chrome DevTools MCP。
整个演示会做三个小案例：
- 直接打开一个
example.com网页。 - 在社交平台上发布一条帖子。
- 在某音创作者中心上传一个视频。
这三个例子是层层递进的。第一个验证链路是否打通，第二个验证登录态是否可复用，第三个验证它能不能真正进入“发布内容”这种有业务价值的场景。
四、实操演示
下面我们来实际演示一下。
我这里用的是 OpenClaw 的微信通道。如果你用飞书通道，思路也是一样的，本质上都是在手机端发指令。
第一步
我先连接一下手机，先做最简单的动作：打开网页。
我会在手机上直接发一句话：
帮我打开 example.com
第一次打开时，浏览器会弹出授权提示。你点确认之后，AI 才能拿到当前页面和当前会话的上下文。
这一步虽然简单，但意义很明确。我们先确认整条链路已经打通了：手机发出指令，OpenClaw 接管浏览器 profile，浏览器自己启动，页面自动打开。
只要这一步顺了，后面更复杂的操作才有基础。
第二步
我们把难度往上提一点，测试在社交平台上发布一条文字内容。注意，这里就需要登录态了。
刚才我们打开的是一个独立的浏览器 profile。第一次使用这个 profile 时，我们需要先在社交平台里手动登录好账号。只要浏览器和这个 profile 还在，登录状态通常就能继续复用。
这里我已经提前登录好推特。接下来，我会在手机端再发一句话：
帮我基于某个主题发布一条帖子
稍等一会，再切到浏览器，你会看到它已经能直接在我的账户里输入内容，并发布一条测试帖子。
同样地，我们也可以让它删除这条测试内容。这个步骤的重点，不是“会不会发帖”，而是它已经能够进入登录后的真实页面并继续操作。
第三步
下面再来一个更复杂、也更接近真实业务的场景：上传视频。
我们的目标，是那些没有开放 API，但你又确实每天要操作的平台，比如某音或者某书。对于已经提供 API 的平台，其实没必要走这么复杂的路线，直接调用 API 就可以了。
某音创作者中心的登录状态，我已经提前处理好了。假如我们已经通过前面一系列脚本和 skill，生成了最终视频和封面图，并且保存到了指定文件夹，文件名就叫 test.mp4。
接着，我在手机里下命令，让它打开发布页，并上传这条 test.mp4 视频。这里要给 AI 一个明确的文件路径，这个路径可以由前面的工作流直接传递过来。
我给它的要求大致是：
- 打开发布页。
- 上传指定视频。
- 标题按 Chrome DevTools MCP 这个方向来写。
- 自动补充简介。
- 自动补几个合适的话题。
- 上传封面。
- 最后停在发布前，等待人工确认。
如果这一步能顺利跑通，你就会立刻明白这套能力真正解决的是什么问题。
现在来看，它已经完成了上传视频、加封面、写简介和标签，最后停在待发布状态。到这一步，我们只需要人工审核一下，再决定是否真正发布。
五、原理和安全边界
下面说一下这个流程到底是怎么实现的。
底层其实并不神秘。Chrome 本身就支持远程调试，OpenClaw 再通过 MCP 协议把这层能力接进来，然后在你授权之后，接管当前浏览器会话。
你可以把它理解成：浏览器还是那个浏览器，登录状态还是你的登录状态，只是 OpenClaw 被允许进入你当前的页面，继续往下操作。
如果你想自己上手，先关注两个配置入口就够了：
- Chrome 侧要开启远程调试能力。
- OpenClaw 侧要配置一个可复用的浏览器 profile。
如果你只是临时测试，用默认配置接当前浏览器也可以；但如果你真的想拿它做发布内容、上传视频这类依赖登录态的操作，我更推荐切换到 user 这类明确的 profile，或者干脆单独建一个像 work 这样的 profile，只登录工作账号，不要和你日常使用的浏览器混在一起。
因为这套能力越强，安全边界就越重要。一旦 AI 接入你的真实浏览器，它理论上就能接触到 Cookie、页面数据，甚至可能看到支付信息、交易记录以及其他敏感内容。
所以这套能力绝对不能无脑全开。这里我给三条建议：
- 不要拿主力浏览器直接测试，单独建一个独立 profile，只登录工作相关账号。
- 保留人工审核，发布动作一定要加人工确认，让 AI 先把内容填好、把草稿准备好，最后由你自己按下发布。
- 用完即关，只在需要时开启远程调试，任务跑完就立刻断开。
六、结尾
这套方案的价值很直接，它让 AI 终于能进入登录后的真实工作流。
不过也要提醒一句，这套浏览器接管能力会消耗不少 token。如果你还没有合适的 token 方案，建议先小范围测试，再决定要不要长期使用。
如果你觉得这个视频对你有帮助，欢迎点赞、关注。
我们下期硬核再见。
关注我获取更多资讯
