Agent 控制浏览器的 Harness 方案对比：视觉驱动与 CDP 结构化协议

发布时间： August 19, 2026

今天用 Agent 导了一批飞书多维表格里的 Bug 附件（包含多份 DOCX、截图与 Gzip 压缩包），抓取了 X 时间线上的动态推文，顺手把其中一个 Bug 在飞书表格里的状态从“未解决”改成了“修复中”。借这个实际任务，把目前 Agent 控制浏览器的两条主流技术路线、各自的开销以及落地选型整理一下。（2026 年 11 月 6 日 05:57:03 时间点看，很多技术又过时了。）

当前 Agent 操作浏览器主要走两条路：一条是视觉驱动（Vision-Based / GUI Agent），靠截屏把画面喂给多模态模型算像素坐标，再调系统级接口模拟键鼠，代表是 OpenAI Operator 和早期的 Anthropic Computer Use；另一条是结构化与协议驱动（CDP / Accessibility Tree），通过 Chrome DevTools Protocol 直连浏览器内核，读取精简后的无障碍语义树或 DOM，让模型输出结构化动作或直接执行 JavaScript，代表是 Playwright MCP、Chrome DevTools MCP 和开源的 browser-use。

视觉驱动方案的优劣

视觉方案的执行链路很直观：Agent 调系统截屏接口拿到当前窗口画面，编码后发给多模态模型，模型识别界面元素并输出物理像素坐标（例如 click(x=834, y=452)），最后由操作系统级驱动模拟鼠标点击和键盘输入。

这套做法最大的好处是把复杂前端当成纯黑盒。无论页面底下用的是 React、Vue、Flutter 还是 Canvas/WebGL，模型只看像素，不用关心组件挂载在哪个 React Portal 下、事件冒泡链路有没有校验 isTrusted，也不用去翻内部字段 ID。面对飞书多维表格这类基于 CRDT 或 OT 协同引擎的富客户端，如果走接口很难直接用简单的 REST 请求改某个单元格，而视觉方案对着屏幕上的文字点一下就能改完，省去了逆向前端状态机的工夫。

但纯视觉方案在工程上的短板也很明显。每一步操作都要经历截屏、图片编码和多模态推理，单步交互通常要 2 到 5 秒；一张高分辨率截图占 1000 到 2000 Token，长链路任务跑下来上下文膨胀得很快。而且物理坐标容易受系统 DPI 缩放（比如 macOS Retina 2x）、CSS 动画和页面异步滚动影响，存在一定的误触率；模型也只能看到当前视口内的画面，没法一次性读取视口外的长列表或隐藏字段。

协议与无障碍语义树方案

协议方案换了一套思路。Agent 通过 WebSocket 连上 Chrome 的远程调试端口（如 http://localhost:9222），抓取页面的无障碍语义树（Accessibility Tree），过滤掉纯样式与布局节点，只保留按钮、输入框、链接等交互节点并标上数字索引：

[1] RootWebArea "工单系统"
  [2] link "缺陷列表"
  [3] textbox "搜索"
  [4] button "查询"

模型看着这份文本树输出 click([4]) 或 fill([3], text)，由 Playwright 或 CDP 映射成精确的 DOM 操作；遇到复杂的数据提取，还可以在当前页面上下文里直接跑 JavaScript 脚本。

由于直接连到用户已经打开的浏览器进程，这种方式天然复用了现有的 Cookie 和登录态，省掉了扫码、收验证码和过风控的麻烦。单步指令执行只要几十毫秒，一棵无障碍文本树通常也就几十到几百 Token；而且按元素引用定位不受窗口缩放、分辨率和滚动位置影响。更实用的一点是，Agent 可以在页面内直接调 fetch() 读取内部接口响应，或者以 ArrayBuffer 形式把受鉴权保护的附件批量拉下来。

实战里的读写分工与混合架构

在今天操作飞书多维表格和 X 的过程里，读和写两条链路的差异非常直接：

操作类型	走 CDP / 数据层协议	走视觉 / 模拟点击
批量读数据（导出 180 条 Bug 与附件）	毫秒级完成：在页面上下文直接调内部接口拉取 Gzip 包解压，不用等 UI 渲染	极慢：需要不断翻页、截图、逐张识别卡片，单次任务要跑好几分钟
单次改状态（把下拉框改为“修复中”）	需探查 DOM：要找 Drawer 容器、等 React Portal 浮层挂载并派发完整事件链	1 秒点击：直接按屏幕文字位置估坐标点击，跳过 DOM 探查

这种差异直接决定了工程上的分工：高频、批量的数据提取与常规表单操作走 CDP 和协议层，兼顾速度与 Token 成本；低频、单次、前端封装极重的复杂组件修改，或者遇到 Canvas 画布时，再用视觉点击绕过 DOM 探查。

这也是为什么 Anthropic 虽然最早提出了 Computer Use 视觉基准，但在面向开发者的 Claude Code 里，浏览器能力默认走的是 Playwright MCP 和 Chrome DevTools MCP；开源社区的 browser-use、Stagehand、Crawl4AI 演进下来也收敛到了同一套路线上：

方案	交互方式	单步延迟	单步 Token	登录态复用	适用场景
纯视觉 GUI	截图 + 像素坐标	3~5s	1000~2000	需在隔离环境登录	桌面应用、Canvas 页面、单次复杂控件操作
CDP / 无障碍树	语义节点索引 + CDP	<100ms	50~200	直接复用现有会话	常规网页自动化、批量数据提取、高频表单
混合架构	默认无障碍树，按需截图	动态	动态	直接复用现有会话	复杂 Web 应用、带图形验证码或画布的场景

实际落地时，最稳妥的做法是把两者叠成双层结构：

                    ┌──────────────────────────────┐
                    │      Agent 任务拆解与规划     │
                    └──────────────┬───────────────┘
                                   │
                     ┌─────────────▼─────────────┐
                     │ 默认: 无障碍树 + CDP/Playwright│
                     └─────────────┬─────────────┘
                                   │
                        页面包含 Canvas / 出现异常？
                                   │
                        ┌──────────┴──────────┐
                     YES│                   NO│
                        ▼                     ▼
              ┌──────────────────┐   ┌──────────────────┐
              │ 局部唤醒视觉截图分析 │   │ 原生 CDP / JS 执行│
              │ (用于坐标定位或校验) │   │ (精准点击与数据提取) │
              └──────────────────┘   └──────────────────┘

日常绝大多数页面跳转、表单填写、文本和附件提取默认走无障碍树与 CDP；只有遇到图形验证码、noVNC 远程桌面等纯 Canvas 画布，或者 DOM 操作异常需要看一眼真实渲染画面时，才按需唤醒截图分析。