夜雨聆风今天聊一聊当你让 Claude 或 ChatGPT 帮你"自动登录网站、填表、下单"时，背后具体的工具分层与协同工作。
其实浏览器自动化这件事，从 2004 年 Selenium 诞生起就存在了。但在大模型时代，它被重新拆解了一遍——因为新的问题出现了：如何让 AI Agent 真正稳定、高效地控制浏览器？
最近，Y Combinator 支持的创业公司 Libretto 发布了一篇博客，梳理了当前 AI 浏览器自动化的工具版图——哪些是底层框架、哪些是云基础设施、哪些是 Agent 层抽象。这篇文章沿着这个脉络，来了解这块具体的情况。
一张地图，三个层次
理解这个领域，首先要接受一个前提：浏览器自动化不是一个工具的事，而是一个分层工程问题。
就像 Web 开发有前端/后端/数据库的分层，浏览器 Agent 系统也自然演化出了三层架构：
第一层：浏览器控制框架。 这一层负责与浏览器"说话"——打开页面、点击元素、拦截网络请求。Playwright、Puppeteer、Selenium 都在这一层。Playwright 和 Puppeteer 本质上是对底层 Chrome DevTools Protocol（CDP）的封装；Selenium 则基于 W3C WebDriver 标准协议，走的是另一条路。这一层为开发者提供统一的编程接口，屏蔽浏览器内部实现细节。
第二层：云基础设施层。 当你的 Agent 需要同时运行几百个浏览器会话，或者要绕过 CAPTCHA、管理 Cookie、处理代理 IP，本地运行就不够了。Browserbase、Hyperbrowser、Steel、Cloudflare Browser Run 在这一层提供托管的浏览器运行时。
第三层：Agent 自动化层。 这一层最靠近 LLM，负责将自然语言指令翻译成浏览器动作。Stagehand、Browser-use、Libretto、Playwright MCP Server 都在这一层工作。
这三层并非竞争关系，而是组合关系。一个生产级的 Browser Agent 系统，往往同时用到所有三层的工具。
底层框架：为什么 Playwright 成了 AI Agent 的首选
先把一个直觉拉直：Playwright 在纯 Chromium 任务上的速度比 Puppeteer 慢 15%~20%。但它成了 AI Agent 生态的默认选择，原因和速度无关。
关键优势一：无障碍树（Accessibility Tree）的语义价值。
Playwright 的 MCP 服务器在与 AI 模型通信时，传输的不是截图，而是页面的无障碍树快照——一种结构化的文本表示，包含每个元素的角色（button、input、link）和标签。
一张截图大约是 100KB+。同一个页面的无障碍树快照？2~5KB。
这意味着 20~50 倍的 token 成本差距。在 Agent 频繁调用 LLM 来"看页面"的场景下，这个差距直接决定了经济可行性。更重要的是：无障碍树是纯文本，不依赖视觉模型，任何文本 LLM 都能使用。
关键优势二：内置 Auto-wait 机制。
传统 Puppeteer 需要开发者手写 waitFor 逻辑：等 DOM 加载、等元素出现、等网络请求完成……在 Agent 驱动的场景下，这些等待逻辑极难穷举——Agent 的路径是动态的，你不知道它会访问哪个页面。
Playwright 的 Auto-wait 机制让框架自动判断"元素是否可操作"再执行动作，大幅降低了 Agent 因时序问题导致的失败率。
关键优势三：跨浏览器支持。
Playwright 原生支持 Chromium、Firefox 和 WebKit（Safari 引擎），统一 API。Puppeteer 只支持 Chrome。在需要测试兼容性或绕过特定检测机制的场景下，这个差距不可忽视。
2025 年 3 月，微软发布了官方的 Playwright MCP Server，直接将其接入了 MCP（Model Context Protocol）生态——任何支持 MCP 的 AI 系统都可以通过标准接口控制浏览器，无需自定义集成。这进一步巩固了 Playwright 在 AI 场景的主导地位。
Selenium 呢？它仍然活跃，主要在企业遗留系统和 QA 测试场景里。作为 2004 年的老将，它的 WebDriver 接口有最广的兼容性，但在 AI Agent 场景下，它的同步阻塞模型和弱语义支持让它难以与 Playwright 竞争。
云基础设施层：让 Agent 在生产规模下跑起来
本地跑 Playwright 很简单。但"让 100 个 Agent 并发操作 100 个浏览器"就不一样了。
这是云基础设施层存在的理由。它解决的核心问题有三个：
1. 规模化运行时管理。 启动、销毁、复用浏览器会话，管理并发上限，提供 Session API。你的 Agent 不需要关心浏览器进程的生命周期。
2. 反爬与检测绕过。 住宅 IP 池、指纹伪装、CAPTCHA 处理——这些能力被打包成服务。对开发者来说，这意味着少写几千行维护代码。
3. 隔离与安全。 每个浏览器会话运行在隔离的沙箱里，Agent 的操作不会互相干扰，也不会污染宿主机环境。
目前这个市场的几个代表性玩家：
Browserbase 是目前规模最大的。2025 年 6 月完成 4000 万美元 B 轮融资，估值 3 亿美元，全年处理超过 5000 万个浏览器会话，服务 1000+ 企业客户。它的定位是"浏览器 Agent 的 AWS"——你不用管基础设施，只用关心 Agent 逻辑。
Hyperbrowser 定位为 AI Agent 专属基础设施，提供更细粒度的 Agent 会话管理能力，支持与 LangChain、LlamaIndex 等 Agent 框架直接集成。
Steel 以开发者友好和开源优先著称，适合中小团队快速上手。
Cloudflare Browser Run 在 2026 年 4 月支持了 WebMCP，将其全球边缘网络的优势带入了浏览器 Agent 场景。
Agent 层：从"写脚本"到"说话"
这是与 LLM 距离最近的一层，也是最近变化最快的地方。
传统浏览器自动化的写法是：写 CSS selector，写点击路径，写断言。每次页面改版，脚本就失效。
AI Agent 层的思路完全不同：用自然语言描述意图，让模型自己决定如何操作。
Stagehand（Browserbase 出品）是这一思路最激进的实践者。它的核心创新是"AI 原生选择器"——不再写 div.btn-primary，而是写 "点击登录按钮"。模型负责找到对应元素。Stagehand v3 在 2025 年 10 月发布，移除了对 Playwright 的依赖，改为直接通过 CDP 与浏览器通信，降低了中间层的延迟；同时加入了 Action 缓存机制，官方数据显示整体性能比 v2 提升 44%，重复工作流成本降低约 30%。
Browser-use 是开源社区里增长最快的项目之一，提供 Python 和 TypeScript SDK，支持接入 OpenAI、Claude、Gemini 等多种模型。它的设计哲学是"模型无关"——你换 LLM 供应商不需要改自动化逻辑。
Libretto（YC 孵化）走了一条与 Stagehand 不同的路：它不追求"运行时智能"，而是追求确定性。Libretto 的设计理念是：让 AI Coding Agent（比如 Claude Code）在开发阶段生成真实的 Playwright 代码，存入代码库，生产时按确定性脚本执行，而不是每次都让 LLM 实时决策。这解决了"AI 每次行为略有不同导致生产不稳定"的问题，代价是灵活性降低，但换来了可审计、可回滚的工程保证。
Playwright MCP Server（微软官方）让任何支持 MCP 的 AI 系统都能直接控制浏览器——Claude Desktop、Claude Code、Cursor、甚至自定义 Agent，接入成本降到了接近零。这是目前最快速上手的方案。
MCP：正在统一这个生态的标准层
值得单独提一下 Model Context Protocol（MCP）。
2024 年 11 月 Anthropic 发布了 MCP，2025 年 12 月 9 日将其捐赠给 Agentic AI Foundation（Linux Foundation 旗下的专项基金），与 Anthropic、OpenAI、Block、Google、Microsoft、AWS、Cloudflare 等共同开放治理。这个协议的本质是：定义 LLM 与外部工具（包括浏览器）之间通信的标准接口。
在 MCP 出现之前，每个 Agent 框架都有自己的工具调用格式，每个浏览器工具都要写自定义集成。MCP 之后，只要工具实现了 MCP Server，任何支持 MCP 的模型/平台都能直接调用——Playwright MCP Server 是其中最重要的实现之一。
Cloudflare 在 2026 年 4 月支持 WebMCP（MCP over WebSocket），意味着浏览器 Agent 可以直接在边缘节点运行，进一步降低延迟。
MCP 正在扮演"浏览器自动化领域的 HTTP"——不是某个具体的应用，而是让所有应用能够互通的基础协议。
工程选型建议：不同场景用什么组合
理解了三层架构，选型就清晰了：
一个常见误区是：把"Agent 层"和"基础设施层"混为一谈，或者只用底层框架直接对接 LLM。前者会导致架构混乱，后者在规模化时会撞上运维天花板。
结语：浏览器是 AI 的第一个"外部世界接口"
从 AutoGPT 第一次让 AI 自主上网，到今天 Stagehand 用自然语言控制浏览器、Browserbase 每年处理 5000 万会话——这个演化只用了不到三年。
浏览器不只是一个"用户界面"。对 AI Agent 来说，它是通向大部分人类数字活动的入口：搜索、填表、下单、登录、数据采集……几乎所有需要"上网操作"的工作流，都绕不开它。
工程分层的意义在于：当你把底层框架、云基础设施、Agent 逻辑分开看，每一层都有清晰的职责，每一层都有专业工具，你的系统才真正具备可维护和可扩展的基础。
否则，你只是在让一个模型随机点击页面——偶尔成功，无法生产。
欢迎关注 AI觉醒观测者，持续追踪 LLM、Agent 与 AI 工程实践前沿。
