最近被问得最多的问题是：“大模型浏览器自动化到底用 Browser-use 还是 Playwright-MCP？”我一开始听到这个问题还有点犹豫，因为严格来说，这俩不是一个层面的东西。可架不住问的人多，而且确实很多人装完就懵了：一个好像能自己干活，一个怎么老是等我下命令。这篇文章我就把两套方案的核心差别拆开讲清楚，包括它们的定位、原理、实际写法和选型建议。做网页自动化的老手、想给助手加浏览器能力的开发者，以及刚入门正准备选技术栈的人，都能在这里找到能直接用的判断依据。
1. 先分清定位：一个像“Agent大脑”，一个像“操作手”
1.1 Browser-use：端到端的 Agent 运行框架
Browser-use 并不是单纯把浏览器操作封装成工具，它本身就是一个 Agent 运行框架。你给它一个任务描述，它会自己去拆解目标、调用浏览器、观察页面反馈、判断是否需要重试或调整，最后把结果返回给你。它把大模型、浏览器操作、状态记忆、上下文压缩这些事全部串联在一起，你在外面看到的只有一个 Agent 对象和一份结果。
它的底层虽然也是基于浏览器自动化技术，但做了大量封装：把所有可交互控件转成大模型能读懂的文本状态，把点击、输入、滚动、提取等操作转成工具，把历史步骤和页面信息压缩后放进上下文。简单说，它更像一个“自带项目经理的自动化工头”，你只要告诉它“帮我办成这件事”，它会想办法办完。
我实际用下来的体感是，Browser-use 更适合那些“目标明确但路径不固定”的任务。比如批量收集信息、填表、对比多个页面价格这类，页面结构一变，传统脚本就崩了，但 Agent 可以根据新页面重新规划。代价是调试起来不如传统自动化直观，你不知道它下一步会干嘛，有时还会“聪明过头”走一些奇怪路径，所以它更需要你给它设定边界。
1.2 Playwright-MCP：大模型的“浏览器工具箱”
Playwright-MCP 是另一个思路：它把自己变成一个 MCP Server，通过标准协议向外面的模型暴露一组操作浏览器的工具。模型可以调navigate打开链接，调snapshot看当前页面结构，调click点击某个元素，调fill填表，调evaluate执行 JavaScript。但它本身不包含“任务怎么拆解”的逻辑，也不负责记录任务目标，所有编排都要由外部的模型和代码来做。
用一句大白话形容：Playwright-MCP 是给大模型装了一只手和一套工具，至于“先做什么后做什么”，仍然由大模型或者你的程序来指挥。这也是它非常适合嵌入 IDE、聊天助手或测试框架的原因：每个动作都可控、可审查、可复现。你把浏览器交出去之后想收回控制权，随时可以收。
这里有一个很容易被忽略的细节：MCP 里的“会话上下文”和“任务状态”是两回事。比如让模型打开网站填表，模型本身会通过对话历史记住任务，但 Playwright-MCP 自己不会主动去“检查任务完成没有”。任务完成没完成，是模型根据页面快照和用户要求判断的。所以如果你希望每一步都很确定，它比 Browser-use 更让人放心；如果你希望它有更强的自主性，那你就得在外层自己补一套 Agent 逻辑。
1.3 一句话概括核心差别
用一个表格把最关键的差异列出来，大家在选型的时候可以对应着看：
| 对比维度 | Browser-use | Playwright-MCP |
|---|---|---|
| 本质定位 | Agent 运行框架 | MCP 工具服务 |
| 是否内置任务规划 | 有，自带决策循环 | 没有，由外部模型或程序编排 |
| 感知页面方式 | DOM 状态抽取、可选截图 | 可访问性树快照、截图 |
| 操作粒度 | 高层动作，模型自动决定 | 细粒度工具，逐步调用 |
| 上下文管理 | 自动压缩历史、保留状态 | 依赖对话上下文，快照较大 |
| 典型用途 | 网页 Agent 产品、数据收集 | 测试生成、IDE 助手、可控网页操作 |
一句话总结：Browser-use 是“一个人的团队”，Playwright-MCP 是“工具箱”。前者帮你把事办完，后者帮你把每一步都看清楚。很多人在选型时只对比功能列表，结果越比越乱，其实先想清楚“你是要结果，还是要过程控制”，答案会清晰很多。
2. 感知方式的差别：它们怎么“看”网页
2.1 Browser-use 的 DOM 抽取与状态表示
大模型不能直接理解网页 HTML，原始 HTML 又长又乱，随便一个页面几十万字符，直接塞给模型既浪费 token，也容易让模型“看花眼”。Browser-use 的做法是把当前页面的 DOM 树经过筛选和简化，提取出和用户任务相关的可交互元素，再转换成带编号的文本状态。模型看到的是类似“按钮：搜索；输入框：搜索框；链接：某某文章”这样的结构化描述。
它还会在每一轮决策前做一次状态抽取，所以页面发生变化后，模型感知到的是新状态，而不是一开始的旧快照。这个设计对动态网页特别重要。比如点击“展开更多”后出现新内容，Browser-use 下一轮就会把新增元素纳入可操作列表；如果是普通脚本，这种变化往往要等开发者先写等待条件。
多模态场景下，Browser-use 也可以把截图交给视觉模型理解。实际项目中我建议优先用文本状态，截图只在视觉布局很关键时再用。文本状态消耗的 token 少、稳定、便于逻辑判断；截图虽然直观，但会让模型“过度关注视觉细节”，比如某张广告图被识别成页面主要内容，导致误点。尤其在一些资讯密集、图片很多的页面，纯视觉判断的准确率反而不如结构化的“可交互状态列表”。
2.2 Playwright-MCP 的可访问性树与标签页快照
Playwright-MCP 确实也有快照，但它优先采用浏览器暴露的 accessibility tree，也就是可访问性树。简单说，这棵树是浏览器根据页面语义生成的“简化版结构”，它忽略了很多纯装饰性的 DOM 节点，只保留用户真正能感知和交互的部分。这样模型拿到的不再是原始 HTML，而是一份更接近人眼看到内容的清单。
它的快照会给每个可交互节点生成一个ref，后续工具调用就通过这个 ref 来定位元素。这个设计的好处是稳定：只要页面不大改，ref 不会像 CSS 选择器一样因为一个小 class 变化就失效。同时它也照顾了可访问性：例如按钮的aria-label能提供比文字内容更准确的语义描述，模型更容易理解这个按钮是做什么的。
不过 accessibility tree 也有明显短板。一些刻意用非标准方式实现的复杂组件，比如自制下拉菜单、Canvas 渲染的可视化、嵌套 iframe 里的非可访问控件，在树里可能缺失或语义混乱。这时候 Playwright-MCP 提供了evaluate或直接执行 JavaScript 的工具作为兜底，但也意味着你得有底层排查能力。它不是银弹，更像一把精密扳手——对大多数标准网页很顺，遇到结构怪异的页面就需要人手动介入。
2.3 为什么感知方式决定使用体验
两套方案都在“给模型喂一个看得懂的页面表示”，但取舍不一样。Browser-use 把抽取状态当作 Agent 的一部分，它会在关键时刻隐去无关节点、压缩历史，让模型始终关注当前任务。Playwright-MCP 则更“忠实地”把当前页面快照返回给你，模型拿到的信息量大且接近原始，但更容易出现上下文膨胀。
从实际体验来说，Browser-use 在信息密集的页面里表现更聪明，因为它会“主动找重点”；而 Playwright-MCP 在工程师手里更好用，因为它给你的每个状态都是可解释、可保存、可断言的。感知方式不是越全越好，关键是和上层决策方式匹配。就像开车，自动驾驶要的是带语义的道路模型，而维修技师要的是能准确反映仪表状态的数据。
3. 编排与控制粒度：单步执行和循环决策的取舍
3.1 Playwright-MCP 的“指令 - 工具”模式
用 Playwright-MCP 时，你跟模型说“打开某网站，搜索一下，把结果给我”，模型实际上是这样工作的：先调navigate打开 URL，再调snapshot获取页面快照，从快照里找到搜索框的 ref，再调fill输入关键词，然后调click点击按钮，之后继续等待页面加载、重新快照、提取结果。
每个动作都非常具体，你甚至可以在中间打断它、纠正它。这种细粒度模式对测试场景是巨大的优点：每一步都能作为测试步骤记录下来，出了问题可以回放到具体某一步。我在做需要可审计的网页操作流程时特别依赖这种模式，因为责任边界清楚，是模型判断错了，还是工具执行错了，看一眼调用日志就能定位。
但代价是，模型每一步都依赖外部对话上下文来记住“我正在进行什么任务”。如果任务步骤很多，上下文里又会堆积大量快照和工具结果，这时候就需要你自己做好上下文清理，或者尽量让任务拆得短一些。另外，有些模型不理解 ref 的含义，会凭空捏造一个数字去点击，结果工具报错，这种问题在使用能力一般的底座模型时尤其常见。所以如果你要用 Playwright-MCP，尽量选择函数调用稳定性好的模型，并且给模型的指令要写清“必须在快照中选 ref，不要自己猜”。
3.2 Browser-use 的 Agent 循环与任务规划
Browser-use 的核心是一个决策循环：感知页面状态 -> 交给大模型思考 -> 选择动作并执行 -> 观察结果 -> 再感知。这个循环由框架自己运行，它会维护一个“任务历史”，包含之前的动作、观察结果和摘要，供模型做下一步判断。如果某一步执行失败，Agent 可以重试或换一种方式；如果任务已经完成，它会主动结束循环并返回结果。
它还有一个好处：模型可以在中途修正自己的计划。比如原计划点击“下一页”，结果页面发生跳转，它看到新页面后会重新判断，而不是死板地继续后来的步骤。这种容错能力，用传统脚本和 MCP 手写调用都会非常痛苦。你只需要在任务描述里给一个清晰的目标，它自己会拆分步骤，也会在拿到结果后停下来。
当然，这也意味着你要给它一定的自由空间。我一般会明确设置max_steps，根据任务复杂度给 10 到 30 步。这里要澄清一下：步数并不等于操作次数，因为一次思考可能包含多个动作，但它能防止模型在同一个页面上无限循环。强烈建议在开发阶段把这个参数调小，先看它能不能“小而美”地完成任务，再逐步放宽。调太大反而会让 Agent 在一个卡住的地方反复尝试，既浪费 token，也浪费时间。
3.3 什么时候该用哪种控制方式
如果你的需求是“过程要透明，每一步都能复现”，比如生成自动化测试用例，或者做合规审核，那就应该选 Playwright-MCP。如果你更关心“最终能把复杂任务做完”，比如从几十个页面里提取信息、处理弹窗和动态加载、在页面结构变化时临场调整，那 Browser-use 会让你省心很多。
还有一个不是非此即彼的选择：用 Browser-use 做主干，用 Playwright-MCP 做某些特定操作。比如 Browser-use 已经走到了登录页，你想让它调用一个封装的“登录”工具，这个工具内部就可以走 Playwright-MCP 的快照和点击逻辑。两个项目都提供了扩展接口，只是需要你额外处理两套状态的一致性问题，不能只图爽快一把梭。
4. 实操对比：同样一个任务，两条路线怎么走
4.1 任务：在资讯网站搜索关键词并提取前 5 条标题
我们拿一个最常见的任务来做对比：打开某个资讯网站，在搜索框输入“大模型应用”，点击搜索，等待结果加载，提取前 5 条结果的标题和链接，最终输出一个结构化列表。这个任务足够小，能体现出两者差异，又不至于把文章变成冗长教程。
先准备环境。Playwright-MCP 是在 MCP 客户端里使用的，以 JSON 配置方式接入：
{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"], "env": { "BROWSER_HEADLESS": "false", "BROWSER_TIMEOUT": "30000" } } } }这里我把BROWSER_HEADLESS设成false，是因为开发阶段要看到实际情况，方便排查；上线跑批量时可以再改回 true。BROWSER_TIMEOUT是每个浏览器调用的默认超时时间，设 30 秒对“等待搜索结果加载”这种操作比较宽容，但如果你的目标站点很慢，可以适当调大。
4.2 用 Playwright-MCP 的方式：一步步让模型执行
接入后，你直接对模型说：“打开某资讯网站，在搜索框输入‘大模型应用’，点击搜索，等结果加载完后，提取前 5 条标题和链接。”模型会连续调用对应的 MCP 工具，大致顺序是：navigate->snapshot->fill->click-> 再snapshot-> 提取内容。
这个过程中你能看到每一步的工具调用和返回值。某个元素没找到，工具会返回错误，你可以在对话里让模型“重新刷新页面再找”，也可以手动点名“搜索框在顶部，你先滚动到顶部再 snapshot”。这种控制力是测试工程师最喜欢的，几乎等同于把 Playwright 脚本里的点击、填表变成了自然语言版。
但是，模型可能并不会自动去做“等待网络空闲再抓内容”。现代前端页面结果都是异步加载，点击搜索后很可能立刻 snapshot 得到“暂无数据”。所以你的提示词里最好带上“等结果加载完成”或“如果没看到结果列表，过几秒重新 snapshot”这类引导。这也是 Playwright-MCP 使用中最常见的一类坑，后面我在常见问题部分会再展开。
4.3 用 Browser-use 的方式：只描述任务，等待结果
Browser-use 是 Python 库，通常你只需要写下面几行：
from browser_use import Agent async def main(): agent = Agent( task="打开某资讯网站，在搜索框中输入“大模型应用”，点击搜索，等待结果加载，提取前5条结果的标题和链接，并整理成JSON输出", llm=my_llm, max_steps=20, use_vision=False, ) result = await agent.run() print(result.result)my_llm是任意支持工具调用的模型实例，你可以按自己项目的实际情况注入。use_vision=False表示不启用截图理解，纯靠页面文本状态来决策，速度和 token 消耗都会低一些；如果页面布局对任务影响很大，再把它打开。
运行之后，Browser-use 会自己完成页面打开、搜索、等待、读取结果的整个过程，最终把结果封装成对象返回。它甚至会根据页面实际情况决定“是否需要先关闭弹窗”“是否需要滚动到底部”。在我实际跑类似任务时，它基本能应付大部分正常网站，遇到登录复杂、反爬强的站点才会需要额外配置。
当然，灵活换来的代价是“过程黑盒”。你很难精确控制它在第几步做了什么，偶尔还会出现模型脑补不存在的按钮之类的情况。所以我在项目里对 Browser-use 只提结果要求，对过程不做过高期待，反而体验更好。
4.4 参数配置与工程化差异
两套方案在参数维度的区别也很明显。Browser-use 的关键参数是模型、max_steps、use_vision、温度、以及是否启用自动总结。模型选择对最终效果影响最大，能力强的模型出错少、规划更合理；能力弱的模型需要把任务描述拆得更碎。max_steps是一个保护性参数，它决定 Agent 最多进行多少轮“思考-行动”，防止任务失控。
Playwright-MCP 的关键参数更多在浏览器环境侧：BROWSER_HEADLESS、BROWSER_TIMEOUT、浏览器类型、用户数据目录、慢速播放等。如果你想观察每一步操作，可以把慢速播放调到 200 毫秒，让动作逐帧呈现；如果你需要保持登录态，就要指定一个持久化用户目录。工程化上，Browser-use 适合作为 Python 服务的一部分，直接输出结构化结果给下游业务；Playwright-MCP 则适合独立运行，由 MCP 客户端统一管理会话、日志和工具权限。
5. 选型建议：根据你的真实需求做决定
5.1 优先选 Playwright-MCP 的场景
如果你已经有 MCP 客户端，或者你主要是做测试自动化，Playwright-MCP 会是更干净的选择。它能让你用自然语言驱动浏览器，也能让模型辅助你写测试步骤，整个过程可复现、可审计。想做一个“帮用户在浏览器里执行固定操作”的对话助手，也适合用它，因为每个操作都可以在界面上可视化跟踪。
还有一个典型场景是“把网页数据分析交给模型但又不希望失控”。让模型通过 Playwright-MCP 打开指定 URL、提取特定区域文本，返回 JSON，而不是让它自由浏览整个网站，这样可以限制模型的行为范围，减少隐私和安全风险。只要任务路径是固定的，它比 Browser-use 稳定太多。
5.2 优先选 Browser-use 的场景
如果你的目标就是“用大模型做一个能自主执行网页任务的 Agent”，比如让用户用自然语言让浏览器去查资料、订票、抓取竞品价格，那就应该认真考虑 Browser-use。它自带 Agent 生命周期，你能在代码里控制任务超时、暂停、继续、结果解析，比手动调用 MCP 工具再自己维护状态省很多事。
对于页面结构频繁变化的网站，尤其适合。Browser-use 感知到新页面后会自动调整操作，普通脚本和固定提示词很难做到这种自适应。做数据采集项目时，我通常先用 Browser-use 跑通“不稳定的那部分流程”，再用传统方式对稳定流程做精细优化，两套能力是互补的，不是二选一。
5.3 混合使用的一种可行思路
有人会问“能不能两个一起用”，当然可以。例如用 Browser-use 作为前台 Agent，负责理解用户意图和拆解任务，然后在某些关键步骤调用一个自定义工具，这个工具内部封装了 Playwright-MCP 的精准操作能力。你可以通过 Browser-use 的 Tool 扩展机制注册自定义工具，也可以把 Playwright-MCP 当作一个独立服务，组件之间通过 HTTP 或消息队列通信。
混合方案能同时获得“自主规划”和“精确控制”，但架构复杂度明显上升。你至少要考虑两套浏览器实例要不要复用、任务状态怎么同步、日志怎么统一。我个人建议除非项目复杂度真的很高，否则先用一种方案把核心功能跑通，再逐步补另一个，不要一开始就上混合架构。
6. 避坑指南与常见问题
6.1 浏览器启动、登录态和持久化
常见的第一个坑是“Agent 打开网站后没有登录态”，这通常是因为默认启动了一个全新的临时用户目录。无论用哪套方案，要处理登录态，都要显式指定一个持久化用户目录。Browser-use 里可以配置浏览器 profile 路径，Playwright-MCP 也可以通过环境变量或启动参数设置用户数据目录。把登录态持久化之后，后续任务就不用反复扫码、收验证码了。
另外，无头模式很容易被网站识别。很多项目喜欢默认无头以求节省资源，但某些站点在无头模式下会直接弹出验证码或返回空数据。我建议开发阶段不要无头，正式跑批之前先用真实浏览器窗口完整跑一遍流程。这里不建议去依赖各种所谓的“反检测”插件，合规风险不说，还会让项目变得不稳定。
提示：开发阶段尽量把浏览器设成有头模式，方便观察每一步；正式跑批时再根据目标站点情况决定是否切换。页面越简单、流程越固定，无头模式越好用；页面越复杂，越建议保留真实浏览器窗口。
6.2 上下文过长、超时和模型幻觉
第二个常见问题是“上下文被撑爆”。用 Playwright-MCP 时，快照和工具返回会不断叠加到对话上下文里；Browser-use 虽然有自动压缩，但任务特别长时同样会膨胀。应对办法是尽量缩小快照范围：Playwright-MCP 有只提取页面中某个区域或指定元素的工具，Browser-use 也支持自定义状态抽取逻辑，不要每次都把整页文本塞给模型。
超时问题大多数来自异步加载。点击搜索后，结果列表可能 3 秒后才出现，但模型很快就去提取内容。建议在提示词里明确“等待某个元素出现再继续”，或者对 Playwright-MCP 设置更宽松的等待策略。对于 Browser-use，可以在页面状态抽取环节增加显式等待，也可以在 Agent 的任务描述里强调“如果未见结果，等待若干秒后再重试”。
还有一类幻觉问题：模型在快照里没找到元素，却硬猜一个 ref 或 CSS 选择器。这种问题没有灵丹妙药，只能换更强的模型、缩小页面状态、或者给 Agent 加上“找不到就打日志并返回失败”的规则。我见过很多自动化项目最后不是死在工具上，而是死在模型“太自信”上，所以一定要把失败路径设计好，别让它一直试。
6.3 权限、安全和运维
最后说安全。给大模型浏览器权限是一件需要谨慎的事，它可能在某次对话中被诱导访问危险链接、下载文件、或者执行恶意 JavaScript。无论是 Browser-use 还是 Playwright-MCP，我都建议做三层限制：第一层限制可访问域名，不在白名单的网址直接拒绝；第二层限制危险操作，比如禁用 JavaScript 执行、禁用文件下载；第三层保留完整日志，包括工具调用和截图，一旦出问题可以立刻定位。
运维上要注意并发问题。两个框架底层都是浏览器自动化，一个浏览器进程一般只服务一个会话，高并发任务要开多个浏览器进程，并做好资源隔离和退出清理。跑久了浏览器内存占用也会上涨，建议给任务加上定时重启机制。这些细节看起来不酷，但决定项目能不能稳定运行。
我个人实测下来的体感是：Browser-use 更“像有人替你干活”，Playwright-MCP 更“像给了你一把顺手的扳手”。如果只做一个小工具，我多半会选 Playwright-MCP，调试直观，逻辑可控；如果要做真正的网页 Agent，那逃不掉 Browser-use。最后分享一个小技巧：无论选哪套，先把浏览器版本和依赖锁死，再写少量任务的冒烟测试，每次改完代码都跑一遍。这两步做好了，后面能少踩一半的坑。
