浏览器自动化这个领域这两年变化快得让人有点跟不上节奏。以前我们聊自动化无非就是 Selenium、Puppeteer、Playwright 这三件套写选择器、等元素、点按钮一套流程走下来虽然繁琐但至少心里有数。后来大模型进来了情况就变得有意思了——你只需要用自然语言说一句“帮我把后台那个待审核列表里超过三天的订单都标记一下”它就能自己打开页面、找到入口、完成操作。听起来很美好但真到了选型落地的时候很多人会在 Browser-use 和 Playwright-MCP 这两个方案之间犯难。我自己在这两个方向上分别做过完整的项目验证踩了不少坑也总结了一些判断标准。这篇文章就把两者的核心差别掰开揉碎讲清楚从架构设计、交互模式、适用场景到实操细节尽量做到你看完就能判断自己该选哪个。1. 先搞清楚这两个东西到底在解决什么问题1.1 浏览器自动化的老问题与新解法传统的浏览器自动化本质上是“人告诉机器每一步怎么做”。你得先page.click(#login-btn)再page.fill(#username, xxx)每一步都是确定性指令。这种方式在页面结构稳定、流程固定的场景下非常好用但一旦页面改版、弹窗干扰、加载时机变化脚本就容易崩。更麻烦的是当任务本身带有模糊性——比如“找到那个看起来像提交按钮的东西”——传统方案几乎无能为力。大模型的出现改变了这个局面。大模型擅长理解模糊指令、做语义判断但它本身不能直接操作浏览器。于是就有了两条技术路线一条是让大模型直接“驾驶”浏览器自己决定看什么、点什么这就是 Browser-use 的思路另一条是把浏览器能力封装成标准化接口让大模型通过调用工具来操作这就是 Playwright-MCP 的思路。两者都在解决“让大模型操作浏览器”这个问题但切入角度完全不同。1.2 Browser-use让大模型自己当司机Browser-use 的核心理念是“Agent 驱动”。你给它一个任务描述它内部会启动一个循环观察当前页面状态通常是把 DOM 简化成可读文本或者带标注的截图然后让大模型决定下一步动作点击某个元素、输入文字、滚动页面等执行完再观察再决策直到任务完成或达到最大步数。这个过程中大模型是真正的决策者。它不需要你预先定义好每一步而是根据当前看到的内容动态判断。比如你说“帮我在这个电商网站找一款价格低于 200 元的蓝牙耳机并加入购物车”Browser-use 会自己打开搜索框、输入关键词、浏览结果、比较价格、点击加入购物车。整个过程你不需要写任何选择器。这种方式的优势很明显灵活、适应性强、对页面改版不敏感。但代价是速度慢、成本高每步都要调用大模型、稳定性受模型能力影响大。我实测下来一个中等复杂度的任务Browser-use 平均需要 15 到 30 步才能完成每步都有一次模型调用延迟和费用都不低。1.3 Playwright-MCP把浏览器变成大模型的工具箱Playwright-MCP 走的是另一条路。它基于 MCPModel Context Protocol协议把 Playwright 的浏览器操作能力封装成一系列标准化工具比如navigate、click、fill、screenshot、evaluate等。大模型通过调用这些工具来完成任务而不是自己直接“看”页面。举个例子同样是“找一款低于 200 元的蓝牙耳机”在 Playwright-MCP 模式下大模型可能会先调用navigate打开网站然后调用evaluate执行一段 JavaScript 来提取搜索结果中的商品信息再根据返回的数据决定下一步。它更像是一个程序员在写代码只不过这个程序员是大模型。这种方式的优势在于执行速度快大部分操作是确定性的、成本可控不需要每步都传完整页面状态、结果可复现。但缺点是灵活性不如 Browser-use遇到完全没见过的页面结构时大模型可能需要多次尝试才能找到正确的工具调用方式。1.4 一句话总结核心差别如果非要用一句话概括Browser-use 是“大模型直接操作浏览器”Playwright-MCP 是“大模型通过工具操作浏览器”。前者更像人后者更像程序。理解了这个根本区别后面的所有差异都能推导出来。2. 架构层面的核心差异拆解2.1 决策循环的设计不同Browser-use 的架构里有一个明确的 Agent Loop。每一轮循环包含四个阶段感知Perception、推理Reasoning、行动Action、反馈Feedback。感知阶段会把当前页面的 DOM 树简化成一段文本描述或者对截图做视觉标注推理阶段大模型根据任务目标和当前状态决定下一步行动阶段执行具体操作反馈阶段等待页面响应并进入下一轮。这个循环是 Browser-use 的核心也是它灵活性的来源。但问题在于每一轮循环都需要把页面状态传给大模型而页面状态往往很长一个中等复杂页面的简化 DOM 也有几千 token这就导致 token 消耗非常大。我做过一个统计一个 20 步的任务Browser-use 的 token 消耗大约在 50k 到 150k 之间具体取决于页面复杂度。Playwright-MCP 则没有这种强制循环。大模型可以根据需要决定什么时候调用工具、调用哪个工具。它不需要每步都“看”整个页面而是通过工具调用来获取特定信息。比如它可以直接调用evaluate执行document.querySelectorAll(.product-title)来获取所有商品标题而不是把整个页面都读一遍。这种方式的信息密度更高token 消耗通常只有 Browser-use 的十分之一到五分之一。2.2 页面状态表示方式的差异Browser-use 需要把页面状态转换成大模型能理解的形式。目前主流的做法有两种一种是 DOM 简化把 HTML 树去掉样式、脚本、隐藏元素只保留可交互元素和文本内容然后加上索引标注另一种是截图加视觉标注在截图上画出可点击区域的边框和编号让大模型通过视觉来理解页面。这两种方式各有优劣。DOM 简化的优点是信息精确、元素定位准确缺点是丢失了视觉布局信息有些靠视觉才能判断的元素比如“那个红色的按钮”就不好处理。截图标注的优点是保留了视觉信息更接近人类的理解方式缺点是 token 消耗大一张截图往往需要上千 token、对模型视觉能力要求高。Playwright-MCP 不强制要求把页面状态传给大模型。大模型可以通过screenshot工具主动获取截图也可以通过evaluate获取特定数据还可以通过get_text获取某个元素的文本。它把“看什么”的决定权交给了大模型而不是每步都强制传全量状态。2.3 工具调用与动作空间的对比Browser-use 的动作空间是预定义的一组操作通常包括点击元素、输入文本、滚动页面、返回上一页、等待、完成。大模型在每一轮循环中从这些动作中选择一个执行。这个动作空间相对较小大模型的学习成本低但也限制了它的表达能力。Playwright-MCP 的工具集要丰富得多。除了基本的点击、输入、导航之外还有evaluate执行任意 JavaScript、get_attribute、wait_for_selector、select_option、upload_file等。理论上只要 Playwright 能做的事大模型都能通过工具调用来完成。这给了大模型更大的发挥空间但也要求它对 Playwright 的 API 有足够的了解。我个人的体会是Browser-use 的动作空间像是一个“简化版遥控器”按键不多但每个键都有明确功能Playwright-MCP 的工具集像是一个“专业工具箱”工具很多但需要你知道什么时候用哪个。2.4 错误处理与恢复机制的差别Browser-use 的错误处理主要依赖大模型的判断。当某个操作失败时比如点击了一个不存在的元素Agent Loop 会把错误信息反馈给大模型让它决定下一步怎么办。这种方式的优点是灵活大模型可以根据具体情况调整策略缺点是如果模型能力不够可能会陷入死循环反复尝试同一个失败的操作。Playwright-MCP 的错误处理更偏向传统编程。工具调用失败会返回明确的错误信息比如“元素未找到”、“超时”大模型需要根据这些信息决定是重试、换一个选择器、还是放弃。由于工具调用是确定性的错误的可复现性更好调试起来也更容易。我在实际项目中遇到过这样的情况一个表单提交后会出现随机弹窗有时候是验证码有时候是广告。Browser-use 的处理方式是每次看到弹窗就尝试关闭但有时候会误点导致流程中断。Playwright-MCP 的处理方式是在提交后先调用wait_for_selector等待特定元素出现如果超时就截图看看发生了什么然后根据截图内容决定下一步。后者的可控性明显更强。3. 实操层面的关键差异与选择建议3.1 任务复杂度与选型判断不是所有任务都适合用大模型来做。我一般会按照“确定性程度”和“页面稳定性”两个维度来划分任务类型。任务类型确定性程度页面稳定性推荐方案固定流程表单填写高高传统 Playwright 脚本固定流程但页面常变高低Playwright-MCP模糊目标探索型任务低中Browser-use需要视觉判断的任务低低Browser-use截图模式大规模数据采集高中Playwright-MCP一次性复杂操作低高Browser-use这个表格不是绝对的但可以作为一个快速判断的参考。核心逻辑是任务越确定、页面越稳定越应该用传统脚本或 Playwright-MCP任务越模糊、越需要临场判断越适合 Browser-use。3.2 成本与性能的实测对比我在一个模拟项目里做过对比测试任务是“登录一个后台系统找到待审核列表把前 10 条记录逐条打开并提取关键信息”。这个任务包含登录、导航、列表遍历、详情提取四个阶段。用 Browser-use 跑平均耗时 4 分 20 秒token 消耗约 85k成功率 78%。失败的原因主要是列表页加载慢导致 Agent 误判、详情页弹窗干扰、以及偶尔的模型决策错误。用 Playwright-MCP 跑平均耗时 1 分 10 秒token 消耗约 12k成功率 95%。失败的原因主要是选择器在特定情况下失效但错误信息明确容易修复。这个对比很能说明问题在流程相对确定的场景下Playwright-MCP 在速度、成本、稳定性上都有明显优势。但如果是“帮我在这个网站上找到最便宜的那款产品”这种模糊任务Browser-use 的优势就体现出来了因为它不需要你预先知道商品列表的结构。3.3 开发与调试体验的差异Browser-use 的调试体验比较“黑盒”。你只能看到它每一步的决策日志但很难干预它的决策过程。如果它某一步走错了你只能调整任务描述或者换一个模型试试没法直接告诉它“你应该点那个按钮”。Playwright-MCP 的调试体验更接近传统开发。你可以看到每一次工具调用的参数和返回值可以复现问题可以针对性地调整。如果某个选择器不对你可以直接改如果某个等待时间不够你可以加长。这种可控性在复杂项目中非常重要。我个人的工作流是先用 Playwright-MCP 把主要流程跑通确定关键步骤和选择器对于其中特别模糊的环节比如“找到那个看起来像确认按钮的东西”再考虑用 Browser-use 来补充。两者不是非此即彼的关系完全可以混合使用。3.4 模型能力要求的差异Browser-use 对模型的能力要求更高。它需要模型具备较强的推理能力、空间理解能力如果是截图模式、以及长上下文处理能力。我用不同规模的模型测试过小模型在 Browser-use 上的表现明显不如大模型经常出现“看到了按钮但不知道点哪个”的情况。Playwright-MCP 对模型的要求相对低一些。因为工具调用的语义很明确模型只需要理解“什么时候该调用什么工具”就行不需要自己从页面中推断。当然如果任务复杂还是需要模型有一定的规划能力。提示如果你手头的模型能力有限优先考虑 Playwright-MCP。它的工具调用模式对模型更友好不容易出现“看不懂页面”的情况。4. 常见问题与排查技巧实录4.1 Browser-use 的典型问题与解决思路问题一Agent 陷入死循环。这是最常见的问题。表现是 Agent 反复执行同一个操作比如反复点击同一个按钮但页面没反应。原因通常是页面加载慢或者操作没有生效但 Agent 没有意识到。解决办法是设置最大步数限制同时在任务描述里加上“如果某个操作连续两次没有效果尝试其他方式”。问题二元素定位不准确。Browser-use 依赖 DOM 简化或截图标注来定位元素如果页面有大量相似元素比如多个“编辑”按钮Agent 可能会点错。解决办法是在任务描述里加上更明确的限定条件比如“点击第三行那个编辑按钮”。如果还是不行可以考虑切换到截图模式视觉信息有时能帮助区分。问题三token 消耗过大。长页面的 DOM 简化结果可能非常长导致每步的 token 消耗都很高。解决办法是尽量缩小任务范围比如先导航到目标页面再启动 Agent而不是让它从首页开始探索。另外可以配置只保留可交互元素去掉纯文本内容。4.2 Playwright-MCP 的典型问题与解决思路问题一选择器失效。这是传统自动化的老问题。页面改版、动态类名、iframe 嵌套都可能导致选择器失效。解决办法是尽量用稳定的属性如>