MCP 浏览器自动化栈
想把真浏览器接进 Claude Code / Cursor / Gemini CLI 的开发者必装十件套:Playwright MCP 做确定性快照打底 + Chrome DevTools MCP 实时调试 + Chrome MCP / Puppeteer MCP / Browserbase MCP 三种运行时取舍 + 多浏览器代理 / 登录状态共享 / 弹窗抢焦点修复 / 日志审计闭环。按推荐安装顺序排列。
这个 pack 解决什么
所有 MCP 浏览器服务器都号称同一件事 — 让 AI 助手点击、输入、读网页。但它们在确定性 / cookie 作用域 / iframe 支持 / 调试可见性 / CI 友好度这五点上各有取舍。本 pack 选 10 个 MCP,正面覆盖这些取舍,并安排了安装顺序 — 每装一个解锁下一层。
目标用户是把浏览器接进 Claude Code / Cursor / Gemini CLI 做 E2E 测试、登录态爬取、agent 自吃狗粮、UI 实时调试的开发者。装完之后你的 agent 会按场景挑合适的 MCP,而不是硬把一个服务器套到所有形状上。
推荐安装顺序
- Playwright MCP Server(微软官方) — 从这里起步。基于快照(snapshot)的动作是确定性的,API 表面小,三大引擎(Chromium / Firefox / WebKit)通用。可访问性树快照是 agent 可靠的关键 — 读结构化节点 ID,不靠猜 CSS 选择器。Playwright 文档明确说 snapshot 是给 AI 客户端用的推荐接口。
- Playwright MCP — Browser Automation Server(社区 npx 版) — 同引擎,更轻装,靠
npx拉起。已有 Playwright 安装、想避开官方包打包开销时用。Codex / Cursor 重度用户首选。 - Chrome DevTools MCP — 第二个装,不是第一个。挂在 DevTools Protocol 上,暴露网络、console、性能 trace、DOM 检查。和 Playwright MCP 配对用:Playwright 驱动页面,Chrome DevTools MCP 告诉你为啥挂了。
- Chrome MCP Server(扩展版) — 完全不同的模型。作为 Chrome 扩展运行,不是另起一个浏览器进程 — 这意味着它复用你真实的登录态 profile:cookie、扩展、保存的密码全有。SSO 后台或者反 bot 卡得严、Playwright 新 context 一开就被挑战时选它。
- Puppeteer MCP — Headless Chrome Server — CI 精瘦选项。没有跨浏览器抽象层,安装小、冷启动快。纯 Chromium 爬虫管线、用不到 Firefox / WebKit fallback 时用。
- Browserbase MCP — 云浏览器 — 本地 Chromium 撞到 IP 封禁、需要 stealth、规模拉不动时的逃生通道。云端浏览器池 + stealth profile,MCP 暴露的工具形状一致 — agent 代码可移植。
- 多浏览器 MCP 代理(Arc / Chrome Beta 变体) — iframe 感知层。原生 Chrome MCP 经常进不去 Arc 的分屏面板、Beta 的变体 DOM;这个代理把 Arc / Beta / Chrome Stable 多路复用,agent 选窗口。站点核心 UI 跑在 iframe 里时是关键(嵌入的支付、Stripe、Cloudflare 挑战页都是)。
- Chrome Fleet — 多 Agent 浏览器池 + 共享登录态 — 一旦你有多个 agent,登录疲劳就成主要成本。Fleet 维护一个已登录的预热浏览器池,每个 agent 取一个用。cookie 作用域是整个 fleet 共享,不是 per-agent — 这是设计取舍:上线快、隔离弱。agent 之间互信时用。
- Chrome MCP Background Proxy — 弹窗 / 焦点修复 — 这是修 bug 的 MCP。原生 Chrome MCP 在弹窗或 OAuth 窗口跳出来时会丢焦点,agent 的下一个点击就点错 tab。这个代理拦截焦点事件、确定性重路由。在接入第一个登录流之前就装上,不要等到 debug flaky 跑挂三次再补。
- BrowserToolsMCP — 通过 MCP 审计浏览器日志 — 收官。Agent 跑完之后,BrowserToolsMCP 让它(或你)回放 console 错误、网络失败、页面生命周期事件。这是"测试通过了" vs "测试通过且零错误" 的差别。
它们怎么协同
Playwright MCP(确定性,跨浏览器)
│
├── Chrome DevTools MCP(为啥挂的)
│
Chrome MCP(真实 profile) ← 多浏览器代理(Arc / Beta)
│
Puppeteer MCP(CI 精瘦) Chrome Fleet(共享登录)
│
Browserbase MCP(云端 + stealth)
│
Chrome MCP Background Proxy(弹窗焦点修复)
│
BrowserToolsMCP(日志审计)
主干是 Playwright MCP + Chrome DevTools MCP + BrowserToolsMCP — 这三件套覆盖 CI 流派 80% 的 agent 浏览器工作。Chrome MCP / Chrome Fleet 是真实 profile 分支,应对 SSO 闸口。Browserbase MCP 是逃生通道。
Cookie / 会话 / iframe — 选对作用域
- Per-context cookie(Playwright MCP / Puppeteer MCP / Browserbase MCP) — 每个会话从零开始。最适合测试。最不适合那种第一次访问就被指纹封的反 bot 站。
- 真实 profile cookie(Chrome MCP 扩展) — agent 复用你登录好的 Chrome profile。最适合 SSO 后台。最不适合并行 agent(会抢同一个 cookie jar)。
- Fleet 共享 cookie(Chrome Fleet) — agent 共享预热池。最适合同一租户下多 agent。最不适合多租户隔离 — 不要把两个客户的 agent 跑同一个 fleet。
- iframe 处理 — Playwright MCP 原生暴露 frame snapshot;Chrome DevTools MCP 通过 CDP target ID 进跨域 frame;Chrome MCP 扩展只能进同源 frame(除非你写 content script)。目标站集成 Stripe / Cloudflare Turnstile / Auth0 时,默认 Playwright MCP + 多浏览器代理。
调试 → CI 路径
- 本地开发:Playwright MCP + Chrome DevTools MCP,有头模式,看 agent 实时驱动、DevTools 面板实时反馈。
- 切到 BrowserToolsMCP 捞你漏掉的隐藏错误 — console warning、失败的 XHR、hydration mismatch。
- 进 CI:把 Playwright MCP 换成 Puppeteer MCP(更轻),跑 headless。CI 出口 IP 被反 bot 拦时再切 Browserbase MCP — 工具调用形状一致。
- 生产 agent fleet:Chrome Fleet 共享登录 + Background Proxy 处理 OAuth 弹窗 + BrowserToolsMCP 抓日志进 post-mortem 面板。
常见踩坑
- 同时装 Chrome MCP 扩展和 Playwright MCP — 它们抢同一个 DevTools 端口。选一个做主,另一个只做 fallback。
- 忘记
npx playwright install— 官方 Playwright MCP 需要 Chromium / Firefox / WebKit 二进制。缺了 MCP 服务器会哑掉。 - Cookie 作用域混淆 — dev 跑得好好的(真实 profile),到 CI 静默挂掉(新 context、过不了 SSO)。第一天就定下 cookie 作用域。
- iframe 盲区 — Stagehand / Browser-Use 风格的 agent 在简单页面好用,碰到嵌入式支付就挂。目标用 iframe → 默认 Playwright MCP + 多浏览器代理。
- OAuth 弹窗抢焦点 — 在第一个登录流之前就装 Background Proxy,不要等第三次 flaky 跑挂。
10 个资产打包就绪
常见问题
只来得及装一个,先装哪个?
Playwright MCP(微软官方版)。基于 snapshot 的动作给 agent 最确定的接口 — 读结构化 accessibility-tree 节点 ID,而不是猜 CSS 选择器,同一套 API 通吃 Chromium / Firefox / WebKit。本 pack 里其他 MCP 都是在它之上做优化。如果你跳过 Playwright MCP 直接上 Chrome MCP 或 Puppeteer MCP,你是用确定性换"真实 profile cookie"或"更小安装体积" — 那是你已经清楚知道哪个约束更重要时才做的取舍。
Playwright MCP 和 Chrome DevTools MCP 都能驱动 Chrome,区别是啥?
它们驱动 Chrome 的层不同。Playwright MCP 挂在 Playwright 自动化库上,暴露的是动作动词:navigate / click / fill。Chrome DevTools MCP 直接挂在 Chrome DevTools Protocol 上,暴露的是检查动词:拿网络请求 / 读 console 消息 / 跑性能 profile。两个都要 — Playwright MCP 做事,Chrome DevTools MCP 告诉你为啥没做成。光跑 Chrome DevTools MCP 等于让 agent 用底层 CDP 原语拼动作,脆。
需要登录的站怎么处理?
三种方案,按成本排。(1) Playwright MCP + 保存的 storage state — 脚本登录一次、cookie 存 JSON、每次会话回放。测试场景最干净。(2) Chrome MCP 扩展 — 复用你真实 Chrome profile 的 cookie,零脚本。单人后台爽,并行 agent 容易翻车。(3) Chrome Fleet — 已登录的预热浏览器池,多 agent 共享。多 agent 同一租户场景适合。混用要慎重 — cookie 上的竞态是这套栈里最痛的 bug。
这些能在 CI / Docker 无显示器环境跑吗?
能,但要挑对的。Playwright MCP 和 Puppeteer MCP 都能在容器里 headless 跑 — Puppeteer MCP 镜像更小、冷启动更快。Chrome MCP 扩展在 CI 里跑不了 — 它要求真实 Chrome profile 和扩展加载。Browserbase MCP 是云端逃生通道 — 想从 CI 跑、但目标站封 CI IP 段时用它。Chrome DevTools MCP 和 BrowserToolsMCP 都能 headless 跑,因为它们挂的是 DevTools Protocol,不是窗口。
iframe 怎么办?很多支付流嵌的就是 Stripe / Cloudflare 挑战页
iframe 是绝大多数 agent 栈静默翻车的地方。Playwright MCP 原生暴露 frame snapshot,agent 按 ID 进跨域 iframe。Chrome DevTools MCP 通过 CDP target ID 接入任意 frame。Chrome MCP 扩展只能进同源 frame(除非你额外写 content script)。流程经过 Stripe / Cloudflare Turnstile / Auth0 Universal Login 时,默认 Playwright MCP + 装本 pack 里的多浏览器代理,先把 iframe 路径调通再做别的 — 后期再补就要重写整套工具调用。