「同一个页面，让 AI 看一眼，成本能差 100 倍。有人 500 块搞定，有人烧 5 万。差距不在工具好坏，在底层架构完全不同。」这是「全栈观察员」一条 8 分钟视频的开场。它把市面上 50 多个浏览器自动化工具，归到 6 条技术路线上，逐条讲清架构原理、成本和能力边界。下面是双轨还原（SenseVoice 逐字稿 + 豆包视觉逐帧读屏）后的深度拆解，工具名已按画面校订，个别口播糊掉的以画面为准。

市面上做「让 AI 操作浏览器」的工具已经超过 50 个，名字记不过来。但视频作者的核心判断是:工具会不停出新，底层就那 6 条技术路线，架构原理决定了它花多少 token、能干什么、干不了什么。搞懂架构，你自己就能判断,不用追工具。

这条判断对任何在做 RPA、爬虫、AI Agent 操作网页的人都成立——也包括我自己每天在跑的网页自动化。先把 6 条路线一条条拆开。

一、先理解「为什么是 6 条路线」

浏览器自动化要解决三组问题,6 条路线两两成对:

  • 怎么操作浏览器(拿控制权):路线 1 CDP 直控
  • AI 怎么看页面(理解页面):路线 2 无障碍树 / 路线 3 截图与坐标
  • 在哪操作、怎么不被发现(环境与对抗):路线 4 云浏览器 / 路线 5 反检测 / 路线 6 AI 原生

每条路线的成本和能力边界,直接由它的架构决定。下面逐条看。

二、路线 1:CDP 直控——拿到浏览器最底层的控制权

CDP 全称 Chrome DevTools Protocol,是 Chromium 浏览器的远程控制协议。你按 F12 打开开发者工具时,浏览器内部就在用这个协议通信。

架构很简单:自动化工具建立一条 WebSocket 连接,连上浏览器的调试端口,把 CDP 命令发过去,浏览器执行完把结果返回来。CDP 定义了 100 多个 Domain,每个 Domain 下面几十个 Method,能力覆盖页面控制、DOM 操作、网络拦截、JavaScript 执行。因为它拿到的是浏览器最底层的控制权,所以这条路线的工具能力最强。

同一条 CDP 路线上,不同工具的设计哲学差很远:

工具定位关键特征
Playwright (MCP)视频称的 2026 事实标准微软官方维护,~29K star;40 多个标准化工具,AI 调一个工具完成一次页面操作;做了跨浏览器抽象(同一套代码跑 Chromium / Firefox / WebKit),把底层协议差异全抹平,适用范围最大
PuppeteerGoogle 出品,只绑 Chrome生态更轻更快;但视频提到它已被官方归档、推荐迁移到 Playwright(此处为视频说法,自行核实版本动态)
chrome-devtools-mcpGoogle 的调试路线Lighthouse 审计、性能追踪、网络拦截——这些是 Playwright 做不了的;代价是工具定义就吃 18K token
browser-tools-mcpDevTools 角度抓控制台日志、网络请求、性能指标
executeautomation/playwright设备模拟143 种设备配置开箱即用

一句话:同一条路线,有人切「最全能力」(Playwright),有人切「调试诊断」(DevTools),有人切「设备模拟」。先认路线,再看切入口。

三、路线 2:无障碍树——把 token 成本压 100 倍的关键

AI 拿到控制权之后,怎么”看”这个页面?这是性价比之争的核心。

浏览器本身会为屏幕阅读器维护一棵无障碍树(Accessibility Tree),里面记录每个元素的角色、名称、状态。比如一个按钮,树里记的是「角色 button / 名称 提交 / 状态 可点击」。这棵树是纯文本的,一个页面大概 500~2000 token。

Playwright MCP 默认就读这棵树——不走截图、不走完整 DOM。所以它的 token 成本控制得极好。这就是为什么 2026 年的事实标准是无障碍树:不是因为它能力最强,而是性价比碾压。

四、路线 3:截图识别 + 坐标点击——贵或脆,都不是首选

另外两种「看页面」的方式,各有致命短板:

  • 截图识别:截一张页面图,喂给多模态模型,让它判断该点哪里。问题是图片 token 太贵,一张截图轻轻松松 5 万 token,操作 10 次就是 50 万。
  • 坐标点击:直接算元素位置去点,不贵,但页面布局一变就全废。

对比就出来了:无障碍树约 500 token,截图约 5 万 token——成本差 100 倍。视频开场那句「500 块能搞定的,为什么要花 5 万」,讲的就是这个。所以截图这条路,只在无障碍树拿不到结构(比如 Canvas 画的页面、纯图形界面)时才退而求其次。

五、路线 4:云浏览器——解决「在哪里操作」

前三条解决「怎么操作 + 怎么看」,后三条换了个问题维度。

云浏览器解决的是执行环境。你本地跑浏览器,IP 固定、环境不变,跑多了网站直接封你。云浏览器把 Chrome 搬到云端,每次启动一个全新实例,IP 随机分配,用完就销毁。

工具路线成本
Browserbase高端;Stagehand 自然语言交互深度集成;给标准 CDP 接口,你的代码不用改~$0.15/小时
Browserless面向企业起步价 ~$200/月

选哪个,取决于你的预算和规模。

六、路线 5:反检测——为什么必须在 C++ 层做

网站怎么发现你是机器人?视频拆成四层检测:

  1. TLS 握手指纹:不同浏览器引擎的握手特征不一样。
  2. Canvas 渲染指纹:让浏览器画一张图,像素级的差异就能识别你。
  3. WebDriver 标志位:自动化工具会留下标记。
  4. 鼠标轨迹分析:轨迹太规律的就是机器人。

关键判断:大部分反检测工具败在第三层之后,因为它们用 JavaScript 去改指纹,网站一查就知道你是改过的。

而 Camoufox 不一样——它基于定制版 Firefox,直接在 C++ 层面修改指纹数据,JavaScript 层面根本查不出来。这就是「反检测要在 C++ 层做才有用」的由来。

(此外还有一条专做 X/Twitter 平台自动化的「维持路线」,关注点赞、评论的全自动化,本质是把上面几条路线组合到特定平台。)

七、路线 6:AI 原生——把选择器维护成本降到 0

这是 2026 年最热的一条路线,也是和「传统自动化」分水岭最大的一条。

传统方式:你得写选择器——「点击 class 为 submit-btn 的按钮」。页面一改版,选择器就废了,维护成本高。

AI 原生:你只说「点击提交按钮」,LLM 自己去页面里找。找错了有自愈机制,换个选择器再试。选择器维护成本被降到 0。代表工具:

  • Stagehand:2026 年 2 月做了 V3 完整重写,架构从「DOM 解析」切换到「CDP 直连」。以前要解析整个 DOM 树,现在直接跟浏览器对话,可靠性和速度都提升一大截。
  • browser-use:走另一个方向,内置子代理。需要操作浏览器时,把任务分发给子代理去做,主模型的上下文不会因为页面内容而膨胀——这是上下文管理的好思路。
  • Scrapling:一个 ~31K star 的反检测爬虫。它不走 MCP 路线,自己实现了指纹轮换和自适应选择器。给它一个 URL,能自动适应页面结构变化、持续抓取。

browser-use 和 Scrapling 的共性:都把 LLM 的理解能力嵌进了操作循环。区别是一个侧重控制、一个侧重抓取定位。

八、MCP 在这套体系里是什么角色

一句话:MCP 是 AI 模型和浏览器之间的标准接口,是个”翻译官”,不是又一条路线。

没有 MCP 的时候,你让 Claude 去操作浏览器,得为每个工具写一套适配代码(胶水代码)。有了 MCP,Playwright 暴露一套标准化的工具定义,Claude 直接调用,中间的胶水代码不用你写了。

重点:MCP 不替代任何一条技术路线。CDP 直控也好、无障碍树也好、截图识别也好,底层该走哪条路线还是走哪条,MCP 只是上面加了一层标准化接口,让 AI 模型能直接调用。理解这一点,就不会把「用了 MCP」误当成「换了架构」。

九、选型决策树(照需求挑路线)

视频结尾给了一张选型表,翻译成决策树:

你的需求选什么为什么
调试自己的 Web 应用DevTools MCP性能分析最全,29 个工具覆盖审计 / 追踪 / 网络 / 跨浏览器 / 表单 / 测试
跨浏览器自动化 / 不知道选啥Playwright MCP2026 默认选择,~29K star,在 coding agent 里最稳
省 token@playwright/ai(CLI 模式)把工具定义从 18K token 压到几百
爬反 bot 检测的网站Camoufox(C++ 层改指纹)+ Scrapling(内容提取)大规模并行、不易被识别
大规模并行 / 企业级Browserbase功能全,代价是贵;便宜的方案稳定性差
自然语言控制Stagehand V3架构最新,DOM→CDP 直连
更轻量的 AI 原生browser-use子代理管理上下文,不膨胀

十、五条「不会过时」的底层判断

视频最有价值的不是工具清单,是这几条剥离了工具、只剩原理的判断——工具换代它们也成立:

  1. CDP 协议是远程控制的基础——几乎所有强能力工具都建在它上面。
  2. 无障碍树把 token 成本压了 100 倍——能读结构就别截图,这是 AI 操作网页的成本命门。
  3. 云浏览器解决环境隔离——IP / 指纹 / 环境的问题,本地永远绕不过去。
  4. 反检测要在 C++ 层面做才有用——JS 改指纹是自欺欺人,一查一个准。
  5. AI 原生路线把选择器维护成本降到了 0——这是「写死规则」到「让模型自己找」的范式迁移。

下次看到一个浏览器自动化工具,花 30 秒想想它走的是哪条路线、能力边界在哪,心里就有数了。

十一、这套框架值得借鉴 / 可迁移的点

抛开浏览器自动化本身,这条视频在方法论上也有几处可抄:

  • 「工具会变,架构不变」的认知锚——任何技术领域工具爆炸时,都该往下沉一层找「有限的几条路线」。这是对抗 FOMO、不被工具牵着走的好框架,可直接套用到「AI 生图工具」「数字人工具」「RAG 框架」等任何赛道。
  • 用「成本差 100 倍」做钩子——把抽象的架构差异,翻译成「500 块 vs 5 万」的具体数字对比,一句话抓住注意力。这是技术科普选题做钩子的范本。
  • 决策树收尾——讲完原理不留在空中,落到「什么需求选什么」的可执行表格,让观众带着结论走。技术内容想有转化,结尾必须给「我现在该怎么做」。
  • 「能力边界」视角——每个工具不只讲「能干什么」,更讲「干不了什么」(如 Playwright 做不了 Lighthouse 审计)。讲边界比讲优点更可信,也更实用。

本文为公开技术内容的学习性拆解,工具名称、star 数、定价以视频原说法为准,实际选型请以各项目最新文档为准。