上个月一个测试同行跟我说，他搭Web测试智能体，光选MCP工具就选了一周。GitHub上搜出来十几个浏览器MCP，每个都说自己“能让AI操作浏览器”，文档看了一堆，越看越不知道怎么选。
我说：“你先别比功能。你先回答一个问题：你是要它替你去探索一个你还没完全理解的页面，还是让它按你定好的纪律，把一条已知路径跑完、留下证据？ ”
他想了一下：“两种都有。”
我说：“那就不是选一个，是按任务形态选。 选错了，不是工具不好用，是你用它的方式，和它被设计出来的场景不匹配。”
这篇文章，把MCP工具选型和接入里最容易翻车的地方，按我踩过的顺序整理一遍。
一、先分清：浏览器MCP不是一类工具，是三种角色
很多人把“能操作浏览器的MCP”当成同一种东西。实际上，按“它到底擅长什么”来分，至少是三种角色。
第一种，执行型。 按已知路径跑完、留下可审计的证据。代表是Playwright MCP。它不看截图，读的是可访问性快照——页面转成结构化文本，每个可交互元素带角色、名称和引用标识（ref）。操作单位是ref，不是CSS选择器。适合PR冒烟、回归验证、需要可追溯流程的场景。
第二种，诊断型。 不是“让页面做什么”，是“搞清楚页面为什么这样”。代表是Chrome DevTools MCP。它能读console、看网络请求、做性能剖析。适合排查“这个bug为什么复现不了”“这个请求为什么慢”这类问题。 有同行说得挺准：Chrome DevTools MCP是找“为什么”，Playwright MCP是让“做什么”。
第三种，通用代理型。 不预设路径，边探索边决策。代表是browser-use。它的感知管线比Playwright MCP“厚”——同时拉DOM快照、DOM树和可访问性树，合并成增强的DOM树，输出更宽的可交互元素列表。适合未知页面的试探、探索性验证、脚本草稿生成。 代价是“视野”更杂，更依赖运行时重建。
还有一类是接管你已登录Chrome的，比如Browser MCP。它不启动新浏览器，直接控制你打开的那个tab。适合需要真实登录态的场景，但它的维护状态需要特别警惕——npm包长期停在旧版本，一个已知的安全问题是WebSocket监听器绑定所有网络接口、没有token校验，同Wi-Fi下的另一台设备能连上它的端口。这类工具用之前，安全评估比功能评估更重要。
二、选型的第一原则：按“任务形态”选，不按“工具强弱”选
没有“最强的浏览器MCP”，只有“和你任务形态匹配的MCP”。
一个实用的判断表：
你的任务
优先考虑
原因
PR冒烟、回归验证、可审计流程
Playwright MCP
快照+ref+证据链，路径可控，失败可复盘
排查页面为什么异常、请求为什么慢
Chrome DevTools MCP
console、网络、性能数据是一手证据
陌生页面探索、脚本草稿生成
browser-use
不依赖先验路径，边走边试
需要真实登录态、操作已打开的tab
接管型工具（谨慎评估）
省掉登录步骤，但安全边界要自己划
CI/CD、headless、批量执行
Playwright MCP + CLI
headless模式成熟，适合流水线
还有一个容易被忽略的维度：上下文成本。有基准测试对比过，同一批任务，Playwright MCP中位输入token约440万，Chrome DevTools MCP约670万。工具越多、快照越“厚”，token消耗越高。如果你的智能体要高频跑，token成本会变成一个必须算的账。
三、接入第一个坑：Windows上的npx，可能根本起不来
选好工具，第一件事是把它跑起来。Windows是接入事故的高发区。
Playwright MCP在Windows上通过npx配置时，常见的失败是：npx实际是npx.cmd（一个批处理包装），通过cmd.exe /c启动时，会破坏stdio管道的继承，MCP的stdio transport直接失败。
更稳的做法是绕过npx，直接用node加cli.js的绝对路径。 先找到@playwright/mcp安装后cli.js的真实位置，配置写成：
{
"mcpServers": {
"playwright": {
"command": "node",
"args": ["C:/完整路径/node_modules/@playwright/mcp/cli.js"]
}
}
}
另一个高频坑是npx首次调用超时。npx在后台下载包，MCP客户端等不到握手就报错了。接之前先手动跑一次npx @playwright/mcp@latest预热缓存，比在配置里反复调超时管用。
四、接入第二个坑：CI里不是“装好就能跑”
本地能跑，CI里跑不起来，是接入阶段的第二大坑。
最典型的是GitHub Actions上的初始化失败：Playwright MCP server在CI runner上启动Chromium时，因为缺少容器安全参数，Chromium在MCP完成工具注册之前就崩了，报initialize: EOF。
CI接入的清单至少要有三条：
加--headless。 CI的Linux runner没有显示器，带界面模式直接失败。
加--no-sandbox。 容器环境以root运行时，Chromium的沙箱会拒绝启动。
锁版本，不用@latest。 CI里@latest会引入行为漂移，昨天绿的今天红，你排查半天发现是上游更新了。
另外，CI里跑智能体，和本地跑是两种成本模型。 本地你不在乎token，CI里高频跑，token就是真金白银。一个务实的做法是：智能体在CI里只做“探索和取证”，稳定下来的路径沉淀成确定性脚本，用零AI成本的方式跑回归。
五、接入第三个坑：工具数量膨胀，Agent开始“选错工具”
Playwright MCP默认暴露的工具是收敛的，测试类工具需要显式--caps=testing才暴露，避免工具列表膨胀、增加模型选错工具的概率。
但接入多个MCP Server之后，工具数量会叠加。每个Server把自己的工具定义塞进上下文，Agent的选择空间变大，选错的概率也变大。
避坑的做法：
按任务接工具，不按“多装总没错”接。 一个智能体如果只做回归验证，不需要同时接Playwright MCP和Chrome DevTools MCP。
测试类工具按需开。 不需要断言能力的场景，不急着开--caps=testing。
用Skill或CLAUDE.md约束工具选择。 在项目配置里写清楚“优先用getByRole”“禁止使用waitForTimeout”，比让Agent自己猜工具用法稳得多。
六、接入第四个坑：会话串台，比“选错工具”更隐蔽
多个任务并行时，如果不做会话隔离，Agent可能在“任务A的页面”上执行“任务B的操作”。
Playwright MCP的状态绑定在session上。 如果客户端每次工具调用都新建session，或者多个任务共享同一个浏览器实例，就会出现“上一次打开的页面，下一次调用看不到”，或者“两个任务互相导航、互相覆盖”。
做法很简单：
一个任务一个session。 任务开始创建，任务结束关闭。
不在session之间共享登录态。 需要复用登录态的场景，用storageState生成独立的凭据文件，按任务隔离。
CI里尤其注意。 并行job共享浏览器实例，是“Agent行为不可复现”的常见来源。
七、接入第五个坑：权限边界，比功能边界更需要先想清楚
浏览器MCP给Agent的不只是“操作能力”，还有“你赋予它的所有权限”。
接一个能操作浏览器的MCP，等于把一个能点击、能输入、能导航的执行体，放进了你的浏览器会话里。 它能去哪些域名、能执行哪些操作、能用哪个账号——这些要在接入之前就划定，不能等它跑起来再补。
最低限度的边界清单：
域名白名单。 只允许访问测试环境和指定的外部依赖，不允许跳到生产环境、后台管理页、或任意公网页面。
账号隔离。 用测试账号，不用真实账号；只读权限优先，写操作单独授权。
动作分级。 查询类操作可以自动执行，提交、删除、支付类操作需要人工确认或走独立审批。
证据留存。 每一次工具调用记录输入输出，失败时保留截图和快照，方便事后审计。
八、一个更务实的接入顺序
如果你现在从零开始，别一上来就接三个工具。
第一步，先接一个执行型工具（Playwright MCP），跑通“打开页面→快照→操作→断言→留证”的最小闭环。 这一步的目的是让你理解Agent“看见什么、怎么操作、留下什么证据”。
第二步，按任务补第二个工具。 如果探索需求多，接browser-use；如果诊断需求多，接Chrome DevTools MCP。补工具的前提是“现有工具在这个任务上不够用”，不是“多一个总没错”。
第三步，把稳定路径沉淀成脚本。 智能体跑通的流程，写成确定性Playwright脚本，进CI零AI成本跑回归。智能体负责“探索和取证”，脚本负责“高频回归”，两条腿走路。
最后
MCP工具选型最容易犯的错，是把“能操作浏览器”当成唯一标准。
真正决定它能不能用的，是四件事：它擅长什么任务、它在哪个环境跑、它留下什么证据、它的权限边界你怎么划。
选错了，不是工具不行，是你用它的方式，和它被设计出来的场景不匹配。
先想清楚任务形态，再选工具。先划好边界，再让它跑。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
