浏览器Agent四大方案横评：Playwright MCP、Browser-Use、Stagehand、Claude c

过去十八个月里交付的每一个智能体框架，最终都会撞上同一堵墙：模型能推理、能规划、能调用工具，全天候运转，但只要任务涉及"打开这个网站并执行操作"，你就必须面对一个现实问题——智能体究竟如何真正接触浏览器。这个选择如今已不再简单。四种截然不同的方案已经稳固地成为生产级选项，它们以真正不同的方式解决了这个问题，为你的使用场景选错任何一个，后续都会以成本失控、测试套件不稳定、或智能体在 5% 不按规则出牌的网站上静默失败等形式找上门来。

这四种方案分别是：微软 Playwright MCP Server 驱动的 Playwright、 开源库 Browser-Use、Browserbase 的 Stagehand SDK，以及 Anthropic 的 Claude computer use 工具。它们经常被统称为"AI 浏览器智能体"，但并不在同一个维度上竞争。一个完全跳过视觉，把页面的结构化树状图交给模型；一个围绕底层浏览器协议重建自己，追求更高速度；一个是商业 SDK，旨在将 AI 动作随时间推移转化为确定性脚本；还有一个是备选方案——当前面三个都无能为力时才出动，而大多数团队直到收到账单才意识到其代价。

为什么这个对比现在变得紧迫

2026 年发生了两件事，使得这个选择不再是学术问题，而是燃眉之急。首先，Claude Code、Cursor 和 Codex 这类编程智能体开始将浏览器工具作为默认能力而非附加组件来交付——这意味着浏览器后端的选择现在直接决定了数百万智能体会话的行为方式，不再只是某个爬虫团队在设计文档里讨论的东西。其次，工具本身在架构上已经分道扬镳。在 2025 年大部分时间里，"AI 浏览器智能体"意味着同一件事：包装 Playwright、截一张截图、问视觉模型该点哪里。这已不再是真相。Stagehand 的 v3 版本移除了 Playwright 依赖，转而采用 CDP 原生架构，通过 Chrome DevTools Protocol 直接与浏览器通信，声称在复杂 DOM 交互上提升了 44%。Browser-Use 独立做出了完全相同的架构决策，同样抛弃 Playwright 转向直接 CDP 控制，也在阴影 DOM 和 iframe 处理上声称了同样的 44% 提升数字。两家竞争的开源项目在同一时间得出了相同的结论：过去十年让浏览器自动化变得触手可及的那个抽象层，正在成为现在所有人真正想构建的那个东西的瓶颈。

与此同时，Playwright MCP 选择了相反的路——留在 Playwright 之上，但用结构化信息替代像素——而 Anthropic 的 computer use 工具则坚守阵地，作为唯一一种既不需要 DOM 也不需要浏览器协议的方案，因为它只是像人一样看屏幕。四个阵营，四种截然不同的权衡，没有任何一家供应商会主动告诉你它的方案何时是错误的选择。

有必要说明一下，这并不是整个市场——OpenAI 在其 API 背后也交付了自己的计算机使用智能体，Google 也一直在将其等价能力构建到自己的智能体栈中。两者都遵循与 Anthropic 工具相同的视觉优先模式，而非可访问性树或 CDP 方案——这也正是 Browser-Use 的基准测试结果值得关注的原因：一个开源库击败了三家大厂构建的智能体，包括那些它根本没有使用的、基于自身视觉的工具。本文聚焦的是当今实际工作的开发者需要在四个选项中做出的真正选择——两家大厂的通用"操作计算机"工具与 Anthropic 的方案收敛于相同的权衡，所以真正有价值的决策空间在下面展开。

想象一个具体场景：你要构建一个智能体，需要在十几个供应商门户上查询订单状态，而这些门户都没有对外暴露 API。你是手工编写 Playwright 脚本、接受每次门户改版都会导致选择器失效？还是把任务交给一个能自主推理每个门户的智能体，同时接受 token 成本和偶尔走错路？如果十二个门户中有两个是根本没有 DOM 的旧 Java 小程序，你是否要回退到一个只看屏幕的智能体？大多数真实系统最终会混用其中两到三种方案——这正是为什么理解每个方案真正擅长什么（而不只是落地页上怎么宣传的）值得花一个小时来读这篇文章。

每个方案实际做什么

Playwright MCP 是一个基于 Apache-2.0 许可证由微软维护的 MCP（Model Context Protocol）服务器，它将浏览器控制暴露为一组超过 50 个独立工具——导航、点击、输入、快照、管理标签页、模拟网络请求、检查存储、生成 PDF 等等。关键的设计决策是：每次操作后返回给模型的是什么？不是截图，而是 Playwright 的可访问性树（accessibility tree），即页面上内容的结构化、语义化、基于文本的表示。整个流程中根本没有视觉模型。每一交互在某种意义上都是确定性的，因为工具调用操作的是真实的 DOM 元素，而非猜测的像素坐标。

Browser-Use 是一个开源 Python 库——MIT 许可证，GitHub 109.7k 星，由 Magnus Müller 和 Gregor Žunič 构建——它将自然语言任务描述转化为自主多步骤浏览器会话。你描述目标（"申请这个职位"、"从这 40 个竞品页面提取价格"），智能体自行规划并执行操作序列，包括当页面内容不符合预期时的恢复。它支持所有主流 LLM 提供商，可本地运行或对接托管云端版本，在 Odysseys 排行榜（200 个长时域 Web 任务）上取得了 87.4% 的平均成功率，领先于 OpenAI、Google 和 Anthropic 自己构建的智能体。

Stagehand，由 Browserbase 维护，宣称自己是"浏览器智能体的 SDK"而非测试框架。它暴露 Playwright 兼容的方法（goto、click、locator），同时提供三个 AI 原生原语——act、observe 和 extract——接受自然语言指令。它的核心理念是缓存：AI 识别的动作会被逐步转化为确定性回放脚本，因此一个工作流首次运行需要消耗真实推理 token，后续每次运行都会变得更便宜更快，对于已经成功的步骤根本不再需要 LLM 调用。它以 TypeScript、Python 和 Go 三种语言交付，设计上与 Browserbase 的托管式无服务器浏览器基础设施配合使用，但并非强依赖。

Claude 的 computer use 工具是 Anthropic 的视觉方案：模型接收截图、推理所见内容、输出坐标和按键，就像人类操作鼠标和键盘一样。它不需要 DOM 访问、不需要可访问性树、不需要任何浏览器自动化库——这正是设计初衷。它能在画布渲染应用、没有可访问标记的遗留软件、以及任何无法找到结构化钩子的东西上工作，因为它控制的是屏幕，而非页面。

它们的实际构建方式——以及发生了什么变化

2026 年贯穿这四个工具的一条主线是：从截图作为模型与浏览器之间的默认接口撤退——唯一例外是那个专为截图不可避免的场景构建的工具。Playwright MCP 压根就没用过截图。Browser-Use 和 Stagehand 以前都架在 Playwright 之上，如今都拆掉了那层依赖，转而通过 CDP 直接与 Chrome 通信，独立得出了在最难处理的场景（阴影 DOM、iframe、嵌套和动态内容）上相同的速度提升数字——这是一个强烈的信号：Playwright 的抽象层（主要为确定性测试而构建）正在给那些每一步都需要观察和重新规划的智能体带来真实延迟。

这种趋同比表面看起来更重要。它意味着定义了第一代浏览器智能体的"包装 Playwright、问 GPT 该点哪里"模式，如今已被构建了它的两个项目视为遗留方案。取代它的不是一件事——而是在两条路之间分化：可访问性树作为真相来源（Playwright MCP）和 CDP 作为真相来源加 AI 层（Browser-Use、Stagehand）。Anthropic 的 computer use 工具在这个话题之外，因为它从来没打算解决同一个问题；它是用于既没有树也没有协议可接入的场景的工具，而且它的架构没有必要追赶这个趋势——因为视觉控制本质上就更慢、更不确定，这是设计选择而非实现质量的问题。

"无障碍树"与"原始 CDP"的实际差异值得详细说明，因为它解释了两个解决类似问题的团队为何会落在技术栈的不同层级。无障碍树是浏览器原生的、为屏幕阅读器构建的结构——每个元素都有角色（role）、标签（label）以及在语义层级中的位置，而 Playwright 早就知道如何读取它，因为其自带的 getByRole 和 getByLabel 定位器正是建立在此基础之上。将这棵树交给 LLM，意味着模型推理所使用的表示形式，与盲人用户屏幕阅读器所使用的表示形式大致相同——它紧凑、成熟，而且已经过滤到只保留有实际交互意义的元素。相比之下，CDP（Chrome DevTools Protocol）是 Chrome 自身向任何想要检测或控制浏览器的工具暴露的低层协议——DOM 变更、网络事件、渲染状态、输入分发——它本身没有"什么是按钮"的概念。直接基于 CDP 构建，意味着 Browser-Use 和 Stagehand 可以跳过 Playwright 的抽象层，自行决定要提取什么以及如何为其模型上下文窗口进行裁剪——这正是 Stagehand 的"混合无障碍树裁剪"和 Browser-Use 自身 DOM 状态提取的由来——两者最终都重新实现了一个精简版的无障碍树，而 Playwright MCP 是免费获得这棵树的，只是对自己的 token 预算和延迟拥有更紧密的控制。

为何开发者实际上应该关注

成本是最尖锐的差异化因素，而且差距悬殊。Claude 的 computer use 工具在单个多步骤工作流中可能消耗 50,000 到 200,000+ 个 token，因为每一步操作都需要一张新的截图加一次视觉模型的推理过程——按 Anthropic 目前的公开定价，这意味着每个任务都是真金白银，而非可以忽略不计的零头，而且在任何规模化场景下都会快速叠加。Playwright MCP 和 Browser-Use 仅发送结构化文本（无障碍树或有针对性的 CDP 状态）而非图像，每一步的消耗只是上述工具的零头。Stagehand 走得更远：其缓存模型意味着工作流的首次运行需要消耗推理 token，但后续每次运行相同流程都可以跳过 LLM 调用，直接回放确定性脚本——这与其他三者的成本曲线有本质区别——对于重复任务，它会退化至接近零的边际成本，而非保持不变。

延迟遵循同样的规律，原因也相同：截图加视觉推理本质上比读取一棵树或发送 CDP 命令要慢，而移除 Playwright 的翻译层（Stagehand v3、Browser-Use）则在最难处理的交互场景上省去了可观的时间。

开发者体验（DX）的差异则没那么统一。Playwright MCP 对任何写过 Playwright 测试的人来说都是最熟悉的——心智模型直接迁移，只需几行 JSON 配置就能接入任何兼容 MCP 的 Agent（Claude Code、Cursor 等），无需编写任何代码。Browser-Use 优化的是"描述目标，让 Agent 自行推导出步骤"这条路——这是从零到跑通自动化最快的方式，但也是当事情以你未曾预料的方式出错时最难调试的方式。Stagehand 明确面向寻求中间地带的团队——在你能够控制的地方写确定性代码，只在页面不可预测时才降级到自然语言——这是一种与"把整个任务交给 Agent"或"写命令式测试代码"截然不同的工程姿态。

锁定（Lock-in）问题则会暴露供应商的激励动机。Playwright MCP 和 Browser-Use 都是完全开源的，采用宽松许可证，无需任何托管组件——你可以完全在自己的基础设施上永久运行两者。Stagehand 也是开源的，但其天然引力偏向 Browserbase 的付费托管浏览器基础设施，而且其缓存与优化故事在使用其平台越多时才会变得越好。Claude 的 computer use 工具根本没有任何自托管替代方案；它就是 Anthropic API 的一项能力，仅此而已。

安全性值得关注程度远超任何供应商 landing page 所给予的。Playwright MCP 自己的文档直接声明它"不是安全边界"，并建议团队在部署之前遵循 MCP 安全最佳实践——这等于直接承认：向 LLM 提供 50+ 个浏览器工具（包括网络模拟和存储访问），如果 Agent 处理的是不受信任的内容，就是真实的攻击面。Computer use 携带了同一风险更为严峻的版本：一个能看见并点击屏幕上任何内容的 Agent，且对范围（scope）毫无概念——Anthropic 明确建议它只在具有有限权限的沙盒环境中运行，绝不在主机器上运行——因为模型一旦误读恶意页面，其行为后果将与人类操作无异。

可维护性是没有人能营销得好的长期问题。Stagehand 的回放脚本缓存本质上是一个可维护性功能——它将"AI 一次性搞定"转化为"这现在是一个无聊的确定性脚本"，这是对经典抱怨"AI 驱动的自动化在生产环境中不可预测"的真实回答。Browser-Use 和 Playwright MCP 没有等价内置机制；每次运行都要重新推导计划——这对站点变更更具弹性，但也意味着你每次都在支付推理成本、接受不确定性，永远如此。

各方案的适用场景

当你需要将浏览器访问接入现有的编码 Agent（Claude Code、Cursor、任何 MCP 客户端）用于一次性或探索性任务时，Playwright MCP 是正确的默认选择——开发过程中填表、检查 UI 变更是否正确渲染、在已打开终端会话中抓取页面。它免费、配置快速，而且因为是确定性的、基于文本的，所以也是 QA 和测试自动化的合法选择——而不只是 Agent 化探索——多个团队正将其用作 Playwright 兼容的测试运行器，只不过由 LLM 交互驱动，而非只能通过手写脚本。

Browser-Use 适合需要描述结果并让 Agent 自行推演路径的自主性、长时程任务：批量求职申请、跨数十个不同布局站点的竞争价格监控、潜在客户生成，或任何手写每个站点选择器都无法扩展的工作流。其基准测试优势具体体现在需要从意外页面状态中恢复的多步骤任务上——而这正是手写脚本会崩溃的场景。

Stagehand 配合 Browserbase 则为生产级流水线而生——那些反复运行少数固定工作流并达到一定规模量的场景——比如结账测试、数据提取任务、监控流程——在那里"首次支付 AI token，之后永久回放脚本"的成本曲线才真正合算，而且你希望获得托管的、可扩展的浏览器基础设施，而非自己运行无头 Chrome 实例。

Claude 的 computer use 工具在其余三者完全无法运作的场景中才值得其溢价：画布渲染应用（设计工具、部分仪表盘、游戏）、遗留桌面软件，或任何没有可访问 DOM 或 CDP 钩子可以抓取的界面。它也是真正通用目的的"操控这台电脑"任务的正确工具——超越浏览器标签页范围的任何操作同样适用——这是浏览器专用工具都无法宣称的能力。

四种方案的入门

集成工作量差异大到足以成为选择优先级时的真实考量因素。Playwright MCP 只需一条 npx @playwright/mcp@latest 即可作为本地 MCP 服务器运行，任何兼容 MCP 的客户端——Claude Code、Cursor、Claude Desktop——通过几行 JSON 配置即可识别它；无需账户、无需 API key（除了你已在使用的 LLM），除非你想自定义其功能，否则无需编写任何代码。Browser-Use 只需 pip install browser-use 加一个你所用模型提供商的 API key，然后写几行 Python 将任务字符串交给它——库内部处理规划和执行，这也是调试它意味着阅读 Agent 追踪日志而非单步执行你自己写的代码的原因。Stagehand 是 npm install @browserbasehq/stagehand（或 Python/Go 等价物），虽然它可以针对本地 Chromium 实例运行以进行开发，但生产使用假设你已有 Browserbase API key 和账户——免费/本地路径存在，但并非 SDK 的缓存和基础设施故事所优化的方向。Computer use 完全不需要任何浏览器库，只需在 Anthropic API 调用上开启一个 beta 标志，外加你自己的沙盒执行环境（一台带有虚拟显示器的 VM 或容器）来真正给模型一个可看的屏幕和可移动的鼠标——这也是四种方案中在写第一行业务逻辑之前需要最多基础设施配置的一个。

营销话语中省略的内容

Browser-Use 的基准测试成绩是真实的，但存在幸存者偏差：CAPTCHA 解决被明确地挡在 Browser Use Cloud 的"隐形浏览器"后面，这意味着完全开源、自托管的路径在任何有真实机器人防御的网站上都会碰壁——87.4% 的成绩并不是在 CAPTCHA 密集阵上跑出来的。

Stagehand 的缓存宣传低估了它对目标页面保持稳定的依赖程度。重放脚本的价值只取决于一个假设：自脚本录制以来网站没有改变其布局；SDK 自身的价值主张是当这个假设破裂时的"自愈"恢复，这换种说法就是缓存收益在任何频繁变化的网站上都会蒸发，而你又回到了每次运行都要支付 AI 驱动成本的状态。

Playwright MCP "不是安全边界"的披露在 README 中异常坦诚，但它很容易被一眼扫过，而且 Microsoft 不会在你 npm install 五十个工具调用到一个 Agent 手中之前给你展示一份安全审查清单。

Anthropic 的 computer use 准确率数字是整个领域中最被低估的风险：该工具在 OSWorld 基准上起始约为 15%，已经攀升到约 22%，而人类基线是 72%。这比一年前有了更有意义的轨迹，但它仍然是一个会在大多数复杂真实桌面任务上出错工具，而且单个工作流的 token 成本就已经可能累计到真金白银，还不算上那些失败导致的重试费用。

这四个工具没有一个是错的，"谁赢了"这种框架本身就是错误的问题——它们在确定性、成本和通用性之间处于不同的权衡点，市场仍在整理这是否会崩溃成一种主导模式，还是会按用例永久性地碎片化。真正值得怀疑的是所有这些工具共有的营销模式：每个供应商都在它能赢的场景下做基准测试。Browser-Use 的排行榜胜利对 CAPTCHA 密集型网站什么也说明不了。Stagehand 的成本故事建立在目标页面稳定的前提下。Playwright MCP 的速度和确定性对没有 DOM 的任务什么也说明不了。而 computer use 的通用性是以成本和准确率为代价的——对于其他三个工具的任何用例来说，这两点都是致命缺陷。两个独立的开源项目在同一 year 朝着 CDP 原生、非视觉控制的方向收敛，这是这里最客观有趣信号——它表明业界共识正在悄悄地在"能避免视觉时就避免视觉"上形成共识，即使最受瞩目的实验室背书工具（computer use）是因为必要而非选择才采用纯视觉方案，因为它在解决其他三个工具明确无法触及的问题。

还有一个结构性的问题值得点出：这四个工具中有三个直接或间接地由同一个理念资助——浏览器基础设施和浏览器智能是可分离的业务。Browserbase 销售基础设施并赠送 SDK；SDK 的设计选择（缓存、混合裁剪）恰好也是使其托管基础设施在规模上更具吸引力的选择，这不是什么阴谋，这只是开源加商业核心项目往往演化的方式。Playwright MCP 没有这样的拉力，因为 Microsoft 不卖浏览器托管——它是一个纯粹的开发者工具，这也是它商业侵略性最低、最不容易被担心供应商锁定的团队信任的部分原因。Browser-Use 处于中间位置：核心完全开源，托管云层级解锁了大多数真实爬虫实际需要的 CAPTCHA 处理，这意味着免费层的基准测试成绩和付费层的真实生产可靠性并不是同一个产品。这些都不是在说任何一个工具不诚实——只是"免费和开源"与"在生产可靠性下免费实际使用"并不总是同一回事，在你选择任何一个工具之前值得读一下它的定价页面，然后再围绕它做架构设计。

不同读者画像应该选择哪个选项

如果你要把浏览器访问接入到一个现有的编码 Agent 中用于开发和测试工作，从 Playwright MCP 开始——它是免费的，如果你已经了解 Playwright 就会很熟悉，而且无障碍树（accessibility-tree）方法意味着你不需要为常规交互支付视觉模型的费用。如果你需要一个 Agent 在你无法控制结构的网站上自主完成开放式、多步骤任务，Browser-Use 的基准测试表现和宽松许可证使其成为最强的起点，但要注意 CAPTCHA 密集型目标会推动你转向其付费云层级。如果你在构建一个以真实体量重复运行相同工作流的生产流水线，并且你希望成本曲线随时间改善而非保持平缓，Stagehand 的缓存模型加上 Browserbase 的托管基础设施值得建立商业合作关系，尤其是当你的目标页面稳定的话。而如果你的实际问题根本不是浏览器——而是一个画布应用、一个遗留桌面工具或任何没有 DOM 可以钩住的 UI——computer use 是这四个中唯一能工作的选项，而成本和准确率的代价就是这个通用性的价格，而不是在它确实是唯一选择时回避它的理由。

你们在生产环境中运行这些工具的经验如何——有没有人让 Stagehand 的重放脚本缓存在页面布局意外改变时还能维持，还是"自愈"最终意味着你几乎每次都在支付 AI 成本？

Browser-Use GitHub repository

Stagehand GitHub repository

Playwright MCP GitHub repository

Browserbase vs Stagehand: Which is Better? (Skyvern, Feb 2026)

Stagehand vs Browser Use: AI Browser Agent Guide (Scrapfly)

Playwright MCP: Browser Automation for AI Agents (2026) (MCP.Directory)

Browser Automation AI Agents: Playwright vs Stagehand (Digital Applied)

Claude Computer Use: Pricing, Accuracy, Benchmarks (Value Add VC)