这次更新到底加了什么

如果按版本号说，这次变化属于 OpenClaw 的 2026.3.13 更新线。需要特别说明的是，GitHub 上首先公开写明该功能的是 v2026.3.13-beta.1 release，发布时间是 UTC 2026-03-14，对应北京时间 2026-03-14 13:17；之后官方又用 v2026.3.13-1 恢复破损的发布链路，并明确说明 npm 版本仍然是 2026.3.13。所以更准确的说法不是“3 月 13 日 GitHub release 页面首次出现”，而是“2026.3.13 这一版功能线里正式引入了这项能力”。

这一版最关键的新点，是 release notes 里明确写出了 “official Chrome DevTools MCP attach mode for signed-in live Chrome sessions”。换句话说，OpenClaw 不再只依赖浏览器扩展来桥接标签页，而是新增了一条可直接挂接用户当前 Chrome 实时会话的官方路径。

  • 新的核心驱动是 driver: "existing-session"，文档明确说明它走的是 Chrome DevTools MCP，而不是传统 raw CDP 直连。
  • 浏览器 profile 也被重新分层。官方文档新增了 profile="user"，表示优先使用用户当前登录的宿主浏览器；同时保留 profile="chrome-relay"，对应旧的扩展中继路径。
  • release notes 还把 chrome://inspect/#remote-debugging 的启用说明写进了文档链路，这意味着官方已经把“接入真实浏览器会话”从灰色技巧推进成了公开支持的能力。

为什么这一步值得单独看

如果对照 OpenClaw 旧的 Chrome Extension 文档来看，这次变化的价值会更清楚。旧文档的定位很直接，就是 “bridge your agent directly into your active browser tabs”。也就是说，以前 OpenClaw 当然能碰浏览器，但主要方式是先安装扩展，再由扩展把当前标签页暴露给 Agent。

现在的不同之处在于，OpenClaw 开始把“用户已经在用、已经登录、已经打开若干业务页面的真实 Chrome”视为一等对象。这会带来三层变化。

  • 第一，登录态不必再先绕到扩展桥接层。对需要使用企业后台、工单系统、IM 管理台或开发者控制台的任务来说，这会显著降低接入摩擦。
  • 第二，人工交接会更自然。用户可以先在自己的浏览器里完成登录、验证和导航，再把当前会话 attach 给 Agent，而不是重新在一个隔离壳里复现整套前置步骤。
  • 第三，产品语义更清楚了。user 和 chrome-relay 两个 profile 并存，说明 OpenClaw 已不再把“浏览器自动化”只理解成一个工具调用问题，而是开始区分真实用户环境与中继环境。

对 Agent 产品来说，这不是小修小补。很多所谓浏览器能力，真正卡住的不是点不点得到按钮，而是能不能自然进入用户已经存在的会话上下文。OpenClaw 这次改的，正是那道门槛。

已经有人把它往更高一层组合了

如果只问“有没有人已经拿这个能力做更高级的东西”，目前我看到的答案是：有，但多数还停留在组合式工作流，还没有长成一个公认成熟的新平台。更准确地说，live Chrome session attach 正在变成一块底座，大家开始往上叠更省 token、更稳定、或者更接近真实业务流程的浏览器操作层。

第一类组合，是把 OpenClaw 的实时会话 attach 和 Chrome DevTools MCP 的调试能力连起来。Chrome 官方在 2025 年 12 月的博客里就把两个场景说得很直接：一是复用现有登录态，把“登录之后才能重现的问题”直接交给 Agent；二是把 DevTools 里已经选中的元素或网络请求，直接交给编码代理继续调查。这意味着 OpenClaw 这次接入后，最先受益的并不是网页爬虫，而是“人工排查到一半，再把上下文交给 Agent 接手”的调试流。

第二类组合，是把真实浏览器会话和更轻的浏览器操作 CLI 叠在一起。公开的《OpenClaw Browser Setup Guide》把 agent-browser 作为默认自动化层来用，OpenClaw 自己负责浏览器生命周期、截图和高阶控制，agent-browser 负责基于紧凑元素引用做点击、填写、切换标签和网络观察。这个组合最有价值的地方，不是功能更多，而是把浏览器上下文压缩成更适合 Agent 消费的结构，减少每一步都把整棵 DOM 树塞回模型。

第三类组合，是把浏览器 attach 做成更长流程的一部分，而不是单次点点点。GitHub 上有一份公开的 API Mapping Playbook，专门让 Claude Code 通过 Chrome DevTools MCP 导航网站、捕获网络请求、反推出接口，再生成 OpenAPI 文档和代码示例。它不是 OpenClaw 专属玩法，但和 OpenClaw 现在的 user profile 完全是同一条技术路线：先接入用户已登录的真实会话，再把浏览器交互升级成“发现接口、整理文档、沉淀资产”的工作流。

第四类组合，是围绕稳定性补上守护层。GitHub 上还有公开的 “Browser Mutex + Single-Tab Guardrails” skill，把 X 这类高风险站点的自动化拆成互斥锁、单标签页、线程安全回复、失败退避几件事来管。这个例子很说明问题。真正把浏览器 attach 用起来之后，最先暴露出来的往往不是“模型不会点按钮”，而是错误标签页、过期元素引用、重复发帖和并发踩踏。

  • 我目前没有找到很多已经完全建立在 user profile 之上的成品 SaaS。
  • 但我能确认，围绕这条能力链的上层组合已经出现了：低 token 操作层、调试接力流、API 发现流和并发守护层。
  • 这说明 live attach 的现实价值，不只是“让 Agent 看见浏览器”，而是让浏览器第一次可以被纳入更长的工程工作流。

效果到底如何：提升是真实的，但还远没到“浏览器万能自动驾驶”

如果把现在能看到的公开反馈压缩成一句判断，我会说：它对“已登录、人工在场、目标清楚”的浏览器任务提升很明显；对“高对抗、长链路、完全无人值守”的网页自动化，依然不够稳。

提升最明显的地方有三类。第一类是已登录后台、控制台和内部工具。官方文档已经明确推荐在“existing logged-in sessions matter”时优先用 profile="user"，因为这会直接复用用户浏览器里已经存在的标签页和登录态。第二类是调试流。Chrome 官方给出的演示就是让代理直接接手当前调试会话、读取网络请求和元素上下文，这比从零重开一个受控浏览器自然得多。第三类是结构化自动化。agent-browser 这类工具把浏览器交互压成 refs、快照、wait、network route、tab 和 diff 这些原语后，Agent 的动作闭环会稳定很多。

公开材料里也能看到“效率提升”已经被写成比较明确的话。社区的 Browser Setup Guide 直接把 agent-browser 描述成比原始 DOM 路径节省 60% 到 93% token；awesome-openclaw-skills 里 agent-browser 这项技能在最近抓取时已有 4,765 次下载，说明它至少不是没人用的冷门搭配。这里我做一个谨慎推断：OpenClaw 新增 live attach 之后，最可能率先起量的，不是“万能浏览器代理”，而是这种“真实会话 + 结构化浏览器 CLI”的双层组合。

但问题也很清楚。从同一版 release 里对 existing-session 的连续修复、以及社区已经开始为 X 这类场景补 mutex 和 single-tab guardrails 这件事就能看出来，稳定性仍然是主问题。真实页面一旦进入长链路操作，错误标签页、过期元素引用、会话重连和重复提交都会迅速放大。也正因为如此，当前更稳的做法通常不是把浏览器完全放飞给 Agent，而是先用真实会话 attach 解决登录态和上下文，再用结构化操作层和守护规则把动作边界收紧。

  • 它最适合的不是“替你接管整个互联网”，而是进入你已经打开、已经登录、已经知道目标的那几个页面。
  • 它带来的效率提升，更多来自少一次登录、少一次环境重建、少很多无效 token，而不是来自模型突然变得会网页通吃。
  • 现在最靠谱的路线，仍然是 human-in-the-loop，加上结构化浏览器工具和清楚的失败保护，而不是直接追求完全无人值守。

它仍然有边界，不等于浏览器被无摩擦接管

这项能力很值得关注，但也不应该被写成“浏览器插件已经彻底消失”或者“Agent 可以静默接管一切页面”。官方 Browser 文档反而把边界写得很清楚：当登录态重要时，推荐使用 profile="user"，同时也明确提醒这种模式更适合用户本人就在电脑前、可以点击和批准 attach 提示的场景。

这意味着它的真实定位，更像“把真实会话纳入协作式工作流”，而不是“把用户浏览器完全黑箱化”。浏览器扩展没有彻底消失，而是从唯一通道变成了保留通道；Chrome 调试口和 attach 生命周期也仍然需要被显式管理；同一版 release 里甚至还专门修了 existing-session 的 driver 校验、重连和 list_pages / new_page 兼容问题，这也说明它还处在快速打磨阶段。

  • 这一步减少的是额外插件依赖，不是减少安全边界。
  • 它更适合“用户在场的半自动协作”，而不是完全无人值守的隐式接管。
  • 真正的技术突破，不在于多了一种浏览器自动化，而在于 OpenClaw 第一次把“真实登录浏览器会话”提升成官方支持的一等接口。

最后收成一句判断

如果只用一句话概括，我会说：OpenClaw 这次真正做成的，不是一个更炫的浏览器功能，而是把真实用户浏览器第一次接进了 Agent 的正式工作流。

这件事本身还不等于浏览器自动化已经成熟，但它已经把下一阶段最值得看的方向暴露出来了。接下来真正会拉开差距的，不是谁先喊出“浏览器 Agent”，而是谁能把真实会话 attach、结构化操作层、失败保护和长流程任务真正接成一套稳定系统。

更新附注

  • 版本：v1.2

更新日期：2026-03-15 更新原因：收紧标题与首屏文案，压缩重复表达，并补写更适合发布与传播的结尾判断。

  • 版本：v1.1

更新日期：2026-03-15 更新原因：补充 live Chrome session attach 的现实使用场景、社区组合方式与效果判断，新增官方与 GitHub 公开资料引用。

  • 版本：v1.0

更新日期：2026-03-15 更新原因：首发版本，基于 OpenClaw 2026.3.13 更新线整理 live Chrome session attach 的功能变化、意义与使用边界。