1. 从两个真实场景说起为什么浏览器自动化突然分成了两条路去年下半年到现在我陆续在三个不同类型的项目里用到了浏览器自动化一个是帮运营团队做竞品价格监控一个是给内部知识库做网页内容采集还有一个是让大模型自己去填表单、点按钮完成一套审批流程。前两个项目我用的是 Playwright 那套传统思路第三个项目我换成了 Browser-use。换完之后最大的感受不是哪个更好而是这俩压根不是一回事。很多人第一次听到 Browser-use 和 Playwright-MCP 这两个词会下意识觉得它们是竞品是新一代替代老一代的关系。实际用下来你会发现它们解决的是两个层次的问题。Playwright-MCP 本质上是把 Playwright 这个成熟的浏览器自动化库通过 MCPModel Context Protocol协议暴露给大模型调用让模型能操作浏览器而 Browser-use 是把让大模型自主完成浏览器任务这件事做成了一个完整的 Agent 框架模型在里面不只是调用工具还要自己规划步骤、看页面、做决策、纠错重试。打个比方。Playwright-MCP 像是给大模型发了一套遥控器每个按钮对应一个浏览器动作模型按哪个键、按几下得由外面的人也就是你的代码逻辑或者上层 Agent告诉它。Browser-use 则像是直接雇了一个会用浏览器的实习生你只说帮我把这个网站的商品价格整理成表格他自己会打开页面、滚动、找元素、判断哪块是价格、遇到弹窗自己关掉最后把结果交给你。这个差别听起来抽象但落到代码结构、调试方式、成本控制、稳定性处理上差异非常具体。下面我按自己踩过的坑一层层拆开讲。2. 拆开看本质一个是工具协议层一个是任务执行层2.1 Playwright-MCP 到底做了什么Playwright 本身是一个浏览器自动化库支持 Chromium、Firefox、WebKit能模拟点击、输入、截图、拦截网络请求等等。它的定位是给开发者用的你需要写代码明确告诉它每一步做什么。Playwright-MCP 做的事情是在 Playwright 之上加了一层 MCP Server把这些浏览器操作封装成一个个工具tool通过标准协议暴露出去。大模型或者任何支持 MCP 的客户端连上这个 Server 之后就能看到类似这样的工具列表browser_navigate、browser_click、browser_type、browser_snapshot、browser_take_screenshot等等。模型决定调用哪个工具、传什么参数Server 执行完把结果通常是页面的可访问性树快照返回给模型。关键点在于决策权在模型但执行粒度非常细。模型要完成登录并下单这种任务得自己拆成打开登录页→找到用户名输入框→输入→找到密码框→输入→点登录→等待跳转→找到商品→点加入购物车→……一长串工具调用。每一步它都要基于上一步返回的页面快照重新判断。2.2 Browser-use 的定位完全不同Browser-use 是一个 Python 库核心是把浏览器包装成一个 Agent 可以操作的环境。你给它一个任务描述它内部会用一个 LLM 做规划配合一套专门设计的提示词和页面理解机制让模型自己决定下一步动作。它内部其实也调用了 Playwright底层还是那套浏览器控制但它在上层做了大量封装页面元素提取、可交互元素编号、历史动作记录、失败重试、多步规划。换句话说Browser-use 把用大模型操作浏览器这件事的最佳实践固化下来了。你不用自己设计提示词去教模型怎么读页面、怎么点元素它已经帮你设计好了。你要做的是配置好模型、写好任务、必要时加一些自定义动作。2.3 一张表看清两者的层次差异维度Playwright-MCPBrowser-use本质浏览器操作的 MCP 工具服务浏览器任务 Agent 框架决策主体上层调用方你的 Agent 或代码框架内置的规划循环执行粒度单步操作点击、输入、导航任务级给目标自己拆步骤页面理解返回可访问性树模型自己解析内置元素提取与编号机制适用场景需要精确控制每一步的流程目标明确但路径不确定的任务调试方式看工具调用日志看 Agent 的思考与动作轨迹底层依赖PlaywrightPlaywright内部这张表是我自己在选型时反复对照的。理解了这个层次差异后面所有的取舍就顺了。3. 页面理解机制模型到底看到了什么这是两者差别最容易被忽略、但实际影响最大的地方。大模型不能直接看网页它只能读文本。所以浏览器自动化框架的核心难题之一就是怎么把复杂的 DOM 树变成模型能理解、能定位的文本。3.1 Playwright-MCP 的可访问性树快照Playwright-MCP 默认返回的是页面的可访问性树accessibility tree快照。这个树是浏览器为辅助技术比如屏幕阅读器生成的结构化表示包含了角色role、名称name、状态等信息。相比原始 HTML它干净很多去掉了大量样式和脚本噪音。但问题也很明显。第一可访问性树对某些动态组件、Canvas 渲染的内容、自定义组件支持不好可能压根不出现。第二快照可能非常长一个复杂页面几千个节点全塞给模型既费 token 又容易让模型迷失。第三模型拿到快照后要自己推理哪个节点是登录按钮这个推理过程不稳定同一个页面不同时候模型可能给出不同判断。我实测过一个电商详情页可访问性树快照大概有 8000 多 token。模型要在里面找到加入购物车按钮并点击成功率大概七成剩下三成会点错或者找不到。这个成功率在演示里够用在生产里就是灾难。3.2 Browser-use 的元素编号与视觉结合Browser-use 的做法更工程化。它会提取页面上所有可交互元素按钮、链接、输入框等给每个元素编一个号然后把编号 元素描述的列表给模型。模型要点击时直接说点击编号 12框架再把这个编号映射回真实的 DOM 元素去执行。这样做的好处是模型不需要在几千个节点里找目标只需要在一个精简的、带编号的列表里选。选择空间小了准确率自然高。而且 Browser-use 支持结合截图做视觉理解对于纯图标按钮、Canvas 内容这类可访问性树覆盖不到的场景视觉信息能补上。不过代价是元素提取本身可能出错。有些元素被遮挡、有些是动态生成的、有些点击区域和视觉区域不一致提取逻辑需要不断调优。我在一个用了大量自定义下拉组件的后台系统里就遇到过Browser-use 提取出来的元素编号和实际能点的位置对不上得手动加自定义动作绕过。3.3 这个差异对提示词设计的影响用 Playwright-MCP 时你往往需要在上层写比较复杂的提示词教模型怎么读可访问性树、怎么定位元素、遇到歧义怎么办。这部分工作量和不确定性都不小。用 Browser-use 时提示词可以写得很业务化比如去某网站搜索关键词 X把前 10 条结果的标题和链接整理出来。框架内部的提示词已经处理了页面理解的细节。你省下的精力可以放在任务描述和结果校验上。我的经验是如果你的任务页面结构稳定、元素有清晰的语义标签Playwright-MCP 够用且可控如果页面复杂、动态、或者你根本不想为每个网站写定位逻辑Browser-use 的页面理解机制能省大量时间。4. 控制流与错误恢复谁来决定下一步做什么4.1 Playwright-MCP 的控制流是外部的用 Playwright-MCP 时下一步做什么这个决策发生在模型侧但整个循环是你自己搭的。典型结构是你把工具列表给模型模型返回一个工具调用你执行把结果喂回去模型再返回下一个调用如此循环直到模型说完成了。这意味着错误恢复逻辑也得你自己写。比如点击失败了怎么办页面加载超时怎么办模型点错了元素怎么办这些都需要你在循环里加判断。我一开始没做这层结果模型点了一个不存在的按钮工具返回错误模型看到错误后又点了一次同样的按钮死循环了。后来加了连续两次相同动作就强制中断并重新截图的逻辑才稳住。4.2 Browser-use 内置了 Agent 循环Browser-use 把整个观察→思考→行动→再观察的循环封装在框架里了。它内部维护了动作历史、当前页面状态、任务目标每一轮让模型基于这些信息决定下一步。失败重试、动作去重、最大步数限制这些都有默认实现。这带来的直接好处是开发速度快。我写第一个 Browser-use 任务时从装库到跑通大概花了半小时。同样的任务用 Playwright-MCP 自己搭循环我花了大半天还得反复调提示词。但内置循环也意味着可控性下降。框架怎么规划、怎么重试、什么时候放弃你只能通过配置参数和自定义回调去影响没法完全接管。遇到框架规划得不对的情况调试起来比自己的循环要费劲因为中间多了一层抽象。4.3 错误恢复的实际对比举个我真实遇到的场景目标网站有个 cookie 同意弹窗会遮挡页面。用 Playwright-MCP 时模型第一次截图看到了弹窗但它没意识到那是个需要先关掉的障碍直接去点后面的按钮点不到。工具返回元素不可点击模型又试了一次还是不行。我后来在提示词里加了一句如果页面有弹窗或遮罩先处理它们情况才好转。这个先处理障碍的常识得靠提示词补。用 Browser-use 时框架的规划提示词里已经包含了类似注意页面上的弹窗、对话框、遮罩层它们可能阻碍操作的引导模型第一轮就尝试关闭了弹窗。这个细节让我意识到Browser-use 的价值很大一部分在于它把大量这类操作浏览器的常识沉淀进了提示词和流程里。5. 选型决策什么任务该用哪个5.1 优先选 Playwright-MCP 的情况流程高度确定比如每天定时登录后台导出报表步骤固定不需要模型做太多判断。这时候用 Playwright-MCP 甚至直接用 Playwright 写死脚本更稳。需要精确控制涉及金额、权限、不可逆操作时你希望每一步都在掌控中不希望模型自作主张。已有 Agent 框架你已经在用某个支持 MCP 的 Agent 平台加一个浏览器工具就能用没必要再引入一套 Agent 框架。调试要求高出问题时你想精确知道是哪一步、哪个工具调用出的错。5.2 优先选 Browser-use 的情况任务目标明确但路径不确定比如帮我在这个网站找到最便宜的某商品并加购路径取决于网站结构写死脚本不现实。要覆盖多个结构不同的网站为每个网站写定位逻辑成本太高让模型自己适应更划算。快速验证想法想快速试一个让 AI 自己上网办事的点子Browser-use 上手最快。页面动态复杂大量 JS 渲染、自定义组件、频繁变化的页面Browser-use 的页面理解机制更有优势。5.3 一个容易被忽略的混合思路其实这两者不是非此即彼。我后来在一个项目里就混用了用 Browser-use 做整体的任务规划和页面理解但在几个关键的高风险步骤比如最终提交订单上注册了自定义动作内部用 Playwright 精确执行。这样既享受了 Agent 的灵活性又在关键节点保住了可控性。Browser-use 支持自定义工具和动作Playwright-MCP 也可以被更上层的 Agent 调用。理解它们的层次差异后组合使用是很自然的选择。6. 实操中踩过的坑与调优心得6.1 Token 消耗比想象中烧得快浏览器自动化的 token 消耗主要来自页面快照。一个中等复杂度的页面快照动辄几千 token一个任务跑十几步加上历史记录很容易上万 token。如果用 GPT-4 级别的模型一个任务几毛到几块钱很正常。我的优化做法第一尽量用支持长上下文但单价低的模型做页面理解关键决策再用强模型第二Browser-use 里可以配置只提取可交互元素而不是全页面能显著减少 token第三Playwright-MCP 场景下可以在返回快照前做裁剪只保留视口内或相关区域的元素。6.2 等待与超时别用固定 sleep新手最容易犯的错是到处写sleep(3)。页面加载速度受网络、服务器、渲染复杂度影响固定等待要么不够要么浪费。Playwright 提供了wait_for_selector、wait_for_load_state这类基于条件的等待Browser-use 内部也做了智能等待。能用条件等待就别用固定 sleep这是稳定性的基础。6.3 元素定位的脆弱性不管用哪个方案元素定位都是最脆的一环。网站改个 class 名、调个布局定位就可能失效。我的经验是优先用语义化的定位方式role、label、文本内容少依赖 CSS 路径和 XPath 索引。Browser-use 的元素编号机制在这方面天然有优势因为它每次都是重新提取的对布局变化容忍度更高。6.4 反自动化检测很多网站会检测自动化行为比如检查navigator.webdriver、鼠标移动轨迹、点击间隔等。这不是本文重点但要知道这个现实你跑得好好的脚本可能某天突然就被拦了。应对方式包括使用更真实的浏览器上下文配置、模拟人类操作节奏等。这块水很深建议先确认目标网站的政策再动手。6.5 结果校验不能省让模型自己跑任务最怕的是它以为自己完成了实际结果不对。我现在的习惯是任务结束后一定要有独立的校验步骤要么用代码检查关键结果比如表格行数、金额范围要么让另一个模型做结果审查。别完全信任 Agent 的我完成了。7. 写在最后我现在的默认选择如果非要给一个默认建议做产品、要稳定、流程确定从 Playwright-MCP 或直接用 Playwright 起步做探索、要灵活、任务开放从 Browser-use 起步。但更重要的是理解它们所处的层次不同别把它们当成互斥的竞品。我自己现在的做法是先用 Browser-use 快速把任务跑通观察模型实际是怎么完成任务的把它的动作轨迹记录下来。如果发现某几步特别稳定、特别关键就把这几步抽出来用 Playwright 固化。这样既保留了灵活性又逐步把稳定性提上来。这个先跑通再固化的路径比一上来就纠结选哪个框架要务实得多。浏览器自动化加了大模型之后能力边界确实被推开了但工程上的坑一个没少。工具选对了只是开始真正决定成败的还是对页面、对模型行为、对错误处理的理解。这些只能靠一个个任务跑出来。