结论先说：同一个页面交给 AI 操作，token 成本可能相差上百倍。差距通常不在于某个工具“更神”，而在于底层技术路线不同。浏览器自动化看似工具超过 50 个，往底层拆，核心主要是 6 条路线：CDP 直控、无障碍树、截图识别、云浏览器、反检测、AI 原生。
理解这 6 条路线，就能判断一个工具为什么便宜、为什么贵，能做什么、不能做什么，以及该用在什么场景。
一、CDP 直控：拿到浏览器底层控制权
CDP 是什么
CDP 全称是 Chrome DevTools Protocol，也就是 Chrome 系浏览器的远程控制协议。平时按 F12 打开开发者工具时，浏览器内部就是通过这套协议在通信。
自动化工具基于 CDP 工作时，通常会建立一条 WebSocket 连接，连到浏览器的调试端口，然后向浏览器发送 CDP 命令。浏览器执行完成后，再把结果返回。
CDP 能控制哪些能力
CDP 定义了 100 多个 domain，每个 domain 下又有多种 message，能力覆盖非常广，例如：
- 页面控制
- DOM 操作
- 网络拦截
- JavaScript 执行
- 调试与性能分析
这也是 CDP 路线工具能力强的根本原因：它拿到的是浏览器非常底层的控制权。
典型工具与设计差异
同样是 CDP 路线，不同工具的切入点完全不同。
- Playwright MCP：是 2026 年的事实标准之一，微软官方维护，约 29K+ star。它提供 40 多个标准化工具，AI 调用一个工具即可完成一次页面操作。
- Playwright：不只是简单封装 CDP，还做了一层浏览器抽象。同一套代码可以跑 Chromium、Firefox、WebKit，抹平了底层协议差异，因此适用范围比 Puppeteer 更广。
- Puppeteer：由 Google 推出，主要服务 Chrome 生态，更轻更快。但 Anthropic 在 2026 年 3 月已将相关项目官方归档，并推荐迁移到 Playwright。
- DevTools MCP：同样来自 Google，但更偏调试路线，覆盖 Lighthouse 审计、性能追踪、网络拦截等能力。这些是 Playwright 不擅长的方向，代价是工具定义较重，约 18K token。
- BrowserTools MCP：更聚焦 DevTools 视角，例如控制台日志、网络请求、性能指标等。
- Exe Automation 的 MCP Playwright：主打设备模拟，提供 143 种设备配置，开箱即用。
可以看到，即使都属于 CDP 直控路线，不同工具选择的接入口不同，最终能力边界也不同。
二、无障碍树：把页面压缩成低成本文本
AI 如何“看懂”页面
AI 拿到浏览器控制权之后，还要知道页面上有什么。最重要的一种方式就是读取无障碍树。
浏览器本身会为屏幕阅读器维护一棵无障碍树，里面记录每个元素的角色、名称和状态。例如一个按钮，在树中可能被记录为：
- 角色：button
- 名称：提交
- 状态：可点击
为什么无障碍树成本低
无障碍树本质上是纯文本。一个页面通常大约只需要 500 到 2000 token。Playwright MCP 默认读取的就是这棵树，而不是截图，也不是完整 DOM。
这使得它的 token 成本非常可控。相比把整个页面截图交给多模态模型，无障碍树在成本上具有明显优势。
三、截图识别：直观但 token 成本高
截图识别的工作方式
截图识别的思路很直接：截取当前页面图片，交给多模态模型，让模型判断页面上有哪些内容、应该点击哪里。
这种方式的优点是直观，不依赖页面结构。但问题也很明显：图片 token 成本高。
成本与稳定性问题
一张页面截图很容易消耗大量 token。如果一次截图约 5 万 token，连续操作 10 次就是 50 万 token。
坐标点击本身并不贵，系统可以计算元素位置后直接点击。但坐标点击对页面布局高度敏感，一旦布局变化，就很容易失效。
因此，2026 年更推荐的实施标准是无障碍树，而不是截图识别。并不是因为无障碍树在所有场景下能力最强，而是因为性价比更高：能用几百 token 解决的问题，就没有必要烧几万 token。
四、云浏览器：解决“在哪里运行”的问题
前面三条路线主要解决“怎么操作浏览器”。后面三条路线解决的是另一类问题：运行环境、反检测和智能化维护。
为什么需要云浏览器
如果在本地长期运行浏览器，容易遇到几个问题：
- IP 固定
- 环境不干净
- 运行多了容易被网站识别或封禁
云浏览器的思路是把 Chrome 搬到云端。每次启动一个全新的浏览器实例，IP 随机分配，用完即销毁。
典型云浏览器工具
- Browserbase：走高端路线，深度集成 Stagehand，支持自然语言交互。
- Bug0：价格较低，约每小时 0.15 美元，并提供标准 CDP 接口，现有代码通常不用大改。
- Browser Live：起步价约每月 200 美元，更偏企业场景。
选择哪一种云浏览器，主要取决于预算、规模和对企业能力的要求。
五、反检测：真正有效的指纹处理要深入底层
网站如何识别机器人
网站判断你是不是自动化程序，通常会看多层信号：
- TLS 握手指纹：不同浏览器引擎的握手特征不同。
- Canvas 渲染指纹：让浏览器画一张图，通过像素级差异识别环境。
- webdriver 标志位：自动化工具可能留下可检测标记。
- 鼠标轨迹：过于规律的移动轨迹容易被识别为机器人。
为什么很多反检测工具不够彻底
大部分反检测工具是在第三层之后做处理，也就是用 JavaScript 修改指纹。但网站如果检查这些改动痕迹，仍然可能发现你“改过”。
Camofox 的思路不同，它基于定制版 Firefox，在 C++ 层面修改指纹数据。这样 JavaScript 层面就很难直接查出异常。
另外，Actions 走的是垂直路线，专门面向 X 平台自动化，支持关注、点赞、评论等自动操作。
六、AI 原生：降低选择器维护成本
传统自动化为什么容易坏
传统浏览器自动化通常依赖选择器，例如“点击 class 为 submit-btn 的按钮”。问题是页面一旦改版，class、DOM 结构或位置发生变化，选择器就可能失效。
AI 原生路线的核心思路是：不再让开发者手写大量选择器，而是告诉 AI“点击提交按钮”。LLM 自己去页面中寻找目标；如果找错了，还可以通过自愈机制换一个选择器重试。
典型 AI 原生工具
- Stagehand：在 2026 年 2 月发布 V3，进行了完整重写，架构从 DOM 解析切换为 CDP 直连。过去需要解析整棵 DOM 树，现在直接与浏览器对话，可靠性和速度都有提升。
- Browser-AI：内置子代理。当需要操作浏览器时，将任务分发给子代理完成，主模型上下文不会因为页面内容而膨胀。
- Crawlee：是一个约 31K star 的反检测爬虫工具。它不走 MCP 路线，而是自己实现了指纹轮换和自适应选择器。给它一个 URL，它可以适应页面结构变化并持续抓取。
这些工具的共性是把 LLM 的理解能力嵌入操作循环中。但定位并不相同：有的侧重浏览器控制，有的侧重内容抓取。
七、MCP 在整个体系里的角色
MCP 不是底层路线，而是标准接口
MCP 的作用可以用一句话概括：它是 AI 模型和浏览器之间的标准接口。
没有 MCP 时，如果想让 Claude 等模型操作浏览器，需要为每个工具编写适配代码。有了 MCP，Playwright 等工具可以暴露一套标准化工具定义，模型可以直接调用，中间的胶水代码不再需要手写。
MCP 不替代任何技术路线
MCP 并不替代 CDP、无障碍树、截图识别、云浏览器或反检测。底层该走哪条路线，仍然取决于工具本身的架构。
可以把 MCP 理解为上层标准化接口：它让 AI 模型更容易调用工具，但并不改变工具底层如何操作浏览器。
八、浏览器自动化选型建议
最后，可以按场景快速选择：
- 调试自己的 Web 应用：优先考虑 DevTools MCP，它的性能分析能力更完整，覆盖审计、追踪、网络等能力。
- 跨浏览器表单和自动化测试：Playwright MCP 是 2026 年的默认选择，生态和抽象能力都较成熟。
- 在 coding agent 中使用：可以关注 @playwright/cli 这类方案，将工具定义从约 18K token 压缩到几百 token。
- 爬取有 bot 检测的网站：可考虑 Camofox 这类在 C++ 层处理指纹的方案，再配合 Crawlee 做内容提取。
- 大规模并行：Browserbase 功能更全，Bug0 更便宜。
- 自然语言控制：Stagehand V3 架构较新，Browser-AI 更轻量。
总结：看工具先看路线
浏览器自动化工具会不断更新，但底层架构大体离不开这 6 条路线。
- CDP 协议是远程控制浏览器的基础。
- 无障碍树能显著降低 token 成本。
- 截图识别直观，但成本较高。
- 云浏览器解决环境隔离和运行位置问题。
- 反检测如果只在 JavaScript 层修改，效果有限，深入 C++ 层更彻底。
- AI 原生路线把选择器维护成本大幅降低。
以后看到一个新的浏览器自动化工具，不必先问它“是不是最好用”，而是先判断它走的是哪条技术路线、解决什么问题、边界在哪里。想清楚这三点，选型基本就有数了。