上个月团队里一个测试同学问我：“Playwright MCP 和 browser-use，到底选哪个？”
我问他是要做什么。他说：“就是让 AI 帮我点页面、跑测试。”
我说：“那你得先回答一个问题：你是想让 AI 替你探索一个你还没完全理解的页面，还是想让 AI 按你定好的纪律，把一条已知路径跑完、留下证据？”
这两个问题，指向两个不同的工具。
Playwright MCP 和 browser-use 都能“点浏览器”。但“点”的方式、点完之后留下什么、出错的时候谁兜底，完全不是一回事。 一个偏“带纪律的侦察执行”，一个偏“通用浏览器代理”。选错了，不是工具不好用，是你用它的方式，和它被设计出来的场景不匹配。
一、先看“看页面”这一层：两者就已经分开了
所有浏览器 Agent 的第一个问题，不是“怎么点”，是“它到底看到了什么”。
Playwright MCP 的选择非常明确：它不看截图，它读可访问性快照（accessibility snapshot） 。MCP Server 把页面转成一份结构化的文本，包含每个可交互元素的角色、名称、状态，以及一个引用标识（ref）。模型看到的是“这是一个 textbox，名字叫 Email，ref 是 e5”，而不是一张截图里的像素坐标。Playwright MCP 的官方定位就是“确定性工具应用”——它不依赖视觉模型，交互是确定性的、快的。
browser-use 的选择不一样。它的感知管线会同时拉取 DOM 快照、DOM 树和可访问性树，再加一些 JavaScript 探针检测 iframe 滚动和点击监听器，然后把三路信息合并成一棵增强的 DOM 树，最终输出一份带索引的可交互元素列表给模型。它同样是结构化的，但它的构建方式更“厚”——它在试图尽可能完整地还原“这个页面上有什么能操作的”，而不是只暴露一份可访问性快照。
这个差异决定了后面所有事情。 Playwright MCP 的快照是收敛的、有纪律的——它只给你可访问性树里那些“规范意义上的可交互元素”。browser-use 的索引列表是更宽的、更通用的——它在努力覆盖各种页面，代价是它的“视野”更杂，也更依赖运行时对页面的实时重建。
二、Playwright MCP 的“纪律”体现在哪：快照 + ref + 证据链
Playwright MCP 的核心设计，是一套受约束的执行模型。
它暴露给模型的工具是固定的：browser_navigate、browser_snapshot、browser_click、browser_type，测试类工具需要显式启用--caps=testing才暴露，默认不开，避免工具列表膨胀、增加模型选错工具的概率。Agent 做的不是“写代码”，是“从固定工具清单里选工具”。
它的操作单位是快照里的 ref，不是选择器。browser_click的参数是{"target": "e5"}，而不是page.click(".btn-primary")。ref 把“理解”和“操作”用同一个标识连了起来：模型在快照里看到“ref 是 e5 的 button，名字叫提交”，然后用 e5 去点。它不需要猜 class，不需要维护选择器。
但这个 ref 有严格的生命周期：页面导航或重新渲染后，旧 ref 立即失效。 Playwright MCP 的设计是“让过期的 ref 大声失败，而不是悄悄点错元素” ——如果你用了一个 stale ref，工具会返回Ref not found in the current page snapshot，要求你重新获取快照。这不是 bug，是纪律：它不允许 Agent 在“没看清当前页面”的情况下继续操作。
这套纪律在 CI/CD 和 PR 冒烟场景里非常值钱。Playwright MCP 在 CI 里的角色不是“替人做判断”，是“替人取证” ：Agent 按预设主流程走一遍，每一步截图、记录网络请求、保存页面快照，失败的地方保留完整现场。它产出的是一份可审查的证据链，而不是一句“通过” 。人工只需要看证据，判断哪些步骤值得沉淀成正式脚本。
Playwright MCP 的测试价值，在于“可审计的侦察”，不在于“自主的智能”。 它不会替你想“该测什么”，但它会把“你让它跑的那条路径”跑得确定、可复现、有记录。
三、browser-use 的“通用”体现在哪：它在做一个“能处理各种网页的代理”
browser-use 的定位不是“测试工具”，是通用的浏览器代理框架。它的目标是让模型能在开放网页上完成各种任务——填表、跨平台聚合、自动填报、探索性流程。
它的核心优势是 think-act 循环：模型看当前状态、决定下一步、执行、再看新状态。在目标页面结构未知、需要多步试探才能完成的场景里，这种自主性确实能显著减少人工干预。
但“通用”在测试场景里是一把双刃剑。
browser-use 在生产环境中有一组被系统总结过的六类失败模式，每一类都直接对应测试场景里的风险：
第一，DOM 选择器漂移。 browser-use 依赖从 DOM 抽取的索引列表来定位元素。前端改一个 class、换一个 aria-label、调整一下布局，索引列表的稳定性就可能被打破。测试脚本最怕的就是“昨天能点，今天点不到” ，而 DOM 漂移是这类问题的头号来源。
第二，登录态中途失效。 Agent 可能在任务中途遇到会话过期、跳转到登录页、认证墙。browser-use 本身不天然处理“检测到未登录 → 重新认证 → 继续原任务”这条恢复路径。如果测试场景涉及登录态，你需要额外设计兜底，而不是指望 Agent 自己“发现并处理” 。
第三，模态框中断。 Cookie 横幅、付费墙、注册弹窗、A/B 测试浮层——这些在生产页面上随时可能出现。browser-use 的通用性让它有可能处理这些中断，但“有可能”不等于“稳定”。测试需要的是确定性，不是概率。
第四，速率限制悬崖。 429、Cloudflare 拦截、验证码——这些在测试环境里可能不会出现，但在预发或生产巡检里随时可能撞上。browser-use 不会自动把“被限流”和“功能坏了”区分开，测试结果可能因此失真。
第五，不可逆操作没有回滚。 这是测试场景里最危险的一条。Submit Order、Send Email、Confirm Transfer——这些动作一旦执行，没有 undo。 browser-use 的自主性意味着它可能在你没有显式确认的情况下，走到一个不可逆的步骤。在测试里，这可能是灾难性的。
第六，截图歧义。 如果 Agent 依赖视觉来判断页面状态，暗色模式、低对比度、重叠模态框、OCR 质量差，都可能让它“看错”。browser-use 虽然以结构化感知为主，但视觉作为补充通道时，歧义仍然存在。
这些失败模式不是“browser-use 的 bug”，是“通用浏览器代理”这个定位的固有代价。 它为了能处理各种页面，牺牲了测试场景最需要的东西：确定性、可审计、对不可逆操作的纪律。
四、测试场景怎么选：按“任务形态”匹配，不是按“工具强弱”
两者的关系不是“谁更好”，是 “任务形态匹配哪个工具” 。
场景一：PR 冒烟、回归验证、可审计的流程执行 → Playwright MCP
如果你要做的是“按一条已知路径跑一遍，留下截图、快照、网络日志，让人来判断有没有问题” ，Playwright MCP 的纪律就是优势。
它的快照是收敛的，ref 是明确失效的，工具集是固定的，执行是确定性的。你不需要它“聪明”，你需要它“可靠” 。CI 里配置无头模式、固定版本、上传证据，整条链路是可控的。
但要注意：Playwright MCP 不替你设计测试策略。 它没有内在的测试设计推理能力，完全依赖你给它的指令和标准。你让它跑什么路径，它就取证什么路径。“该测什么”仍然是人决定的。
场景二：探索未知页面、理解陌生流程、生成脚本草稿 → browser-use
如果你面对的是一个你还不完全理解的页面，或者你需要 Agent 自己走几步、试探一下这个流程能不能通，browser-use 的通用性和自主性就是价值。
它适合探索性任务：打开一个后台、看看有哪些入口、尝试走一条流程、记录哪里卡住了。它的产出是“线索”，不是“证据” 。你拿它的结果去理解页面，而不是直接拿去当测试结论。
但涉及不可逆操作时，必须加确认门禁。 提交订单、发送邮件、确认转账——这些步骤不能在 Agent 的自主循环里直接放行。browser-use 的失败模式里，“不可逆性”被单独列出来，恢复策略是 “回答拒绝 + 确认门禁断言” ——Agent 应该在执行不可逆操作前停下来，要求显式确认。
场景三：登录态隔离、多角色测试 → 两者都需要你额外设计
这个问题不是工具本身能自动解决的。
Playwright MCP 的 session 绑定 browser context，你可以为不同角色起不同 context、加载不同 storageState。但服务端数据仍然是共享的——浏览器会话隔离了客户端状态，没有隔离服务端状态。
browser-use 的 session 隔离也存在类似的边界：共享 profile 的 session 共享 cookies 和登录态，独立 profile 才是独立身份。如果测试需要多角色，你要么用独立 profile，要么在测试设计里显式处理角色切换和数据隔离。
两者都不会自动帮你解决“登录态污染”的问题。 这是测试设计的问题，不是工具选型的问题。
五、一个实用的判断规则
不要问“哪个更强”。问三个问题：
第一，这次任务是“已知路径的取证”，还是“未知页面的探索”？
已知路径 → Playwright MCP。未知页面 → browser-use。
第二，任务里有没有不可逆操作？
有 → 无论用哪个工具，不可逆操作前必须加确认门禁。Playwright MCP 可以用测试工具显式断言拦截，browser-use 需要在 Agent 循环里插入确认步骤。
第三，产出是要“可审计的证据链”，还是要“探索的线索”？
要证据 → Playwright MCP 的快照、截图、网络日志、trace 是完整的一套。要线索 → browser-use 的探索结果帮你理解页面，但不要直接当测试结论。
六、避坑指南
坑一：把 browser-use 当“更聪明的 Playwright MCP”用。 它不是。它的通用性带来的失败模式，在测试场景里是需要额外工程兜底的。用它的探索能力，不要用它的自主性替代你的确认门禁。
坑二：把 Playwright MCP 当“全自动测试 Agent”用。 它没有测试策略推理能力。你给什么路径，它跑什么路径。 它不会替你决定“该测哪些边界”。
坑三：忽略 ref 的生命周期。 Playwright MCP 的 ref 在导航后立即失效，必须重新快照。复用旧 ref 的脚本会“时好时坏”，这是最常见的调试黑洞之一。
坑四：以为 session 隔离等于数据隔离。 无论哪个工具，浏览器 context 隔离的是客户端状态，服务端数据仍然是共享的。多角色测试需要独立的测试数据和显式的清理机制，不能只靠工具。
坑五：在不可逆操作上没有确认门禁。 这是测试场景里最不能省的一步。Submit Order 没有 undo。 无论 Agent 多“聪明”，这个门禁必须在工程层加上。
最后
Playwright MCP 和 browser-use 的差别，从来不是“能不能点浏览器”。
Playwright MCP 是一个“带纪律的侦察执行层” ：它用可访问性快照收敛视野，用 ref 绑定操作，用失效机制强制重新观察，用证据链让每一步可审计。它的价值在“确定”和“可复查”。
browser-use 是一个“通用浏览器代理” ：它用增强 DOM 树覆盖更宽的页面，用 think-act 循环处理未知路径，用自主性换取探索能力。它的价值在“能走进去”。
测试场景的选择逻辑很简单：需要取证和纪律的时候，用 Playwright MCP；需要探索和试探的时候，用 browser-use。 不要指望一个工具同时做好两件事。把任务形态匹配对，比选“更强的工具”重要得多。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
