要做 MCP 浏览器自动化，你实际要搭的是三段链路：一个 MCP 客户端（Claude Desktop、Cursor、VS Code、Windsurf 这类）、一个把浏览器操作封装成工具的 MCP Server、以及最终被驱动的那个浏览器。

Model Context Protocol 是 Anthropic 提出、目前被当作行业开源标准在用的接口协议，作用是给大模型一套标准化的外部工具和数据调用方式，不必为每个 AI 平台单独写一遍胶水代码。落到浏览器上，MCP Server 把「打开网址、定位元素、点击、输入文本、截图、读取页面状态」这些动作注册成 Tools 和 Resources，模型收到你的自然语言指令后自己拆成一串工具调用，按步骤执行。

对做多账号跨境电商和海外社媒的人来说，这套东西真正要你决定的只有一件事：被驱动的那个浏览器，是 MCP Server 自己拉起来的一个干净实例，还是你已经配好指纹和代理的那个环境窗口。这个分叉决定了后面所有的配置动作和排查顺序。

先分清你装的是哪一类 MCP 服务

现在常见的开源方案大致两类。

自带浏览器的：官方的 @playwright/mcp、@modelcontextprotocol/server-puppeteer 属于这一类。它们在执行时自己启动一个 Chromium/Chrome 实例，通常是无头模式或一个全新的临时 profile，任务跑完可能就关掉。好处是装完就能用，不依赖你本机开着什么；代价是那个实例跟你日常登录的账号、你配好的指纹参数、你绑的出口 IP 都没有关系。

接管已有会话的：Chrome DevTools MCP、Browser MCP 这类，通过浏览器扩展或调试端口连到一个已经开着的浏览器上，沿用里面现成的登录态和环境。

只看演示视频，两类的效果几乎一样——都是你说一句话，页面自己动起来。差别要到你让它登录某个平台后台时才暴露出来。

模型是怎么「看」页面的

值得单独说一句识别机制，因为它直接决定哪些任务能跑通。

Playwright MCP 主要通过无障碍树快照（Accessibility Snapshot）把页面结构交给模型，并给可交互元素分配唯一的 ref 标识，模型点击和输入时引用这个 ref，而不是把整份 DOM 丢给模型，也不是靠截图猜坐标。这个做法让操作的确定性高很多，Token 消耗也低得多。

反过来，它也解释了两种常见的失败：图标按钮没有可访问名称（没写 aria-label）时，模型在快照里基本「看不见」它；整个界面由 Canvas 绘制、或把内容塞进视频层的页面同理。遇到这种页面，要么换成带视觉截图能力的工具，要么接受这一步得人工点。

多账号场景的关键分叉：别让它自己开浏览器

默认链路的问题不是跑不起来，而是它跑在一个不是你的环境里：新 profile 没有登录态；指纹参数由这台机器和默认启动参数决定，和你在客户端里精心配好的那一套不是一回事；出口 IP 是本机直连。

你在平台那边要的效果是「这个账号始终从这个环境、这条 IP 出去」，而默认链路一次把这三样全换掉了。无头浏览器的默认环境特征本身也比较扎眼，容易被平台的检测逻辑注意到。

所以正确的方向是接管，不是新开。

接到隔离环境上的操作顺序

第一步，先把环境本身跑通，再谈自动化。 建环境、绑代理、打开窗口，在窗口内访问一个查 IP 的页面，确认出口就是你绑的那条，时区、语言这些不和 IP 归属地互相矛盾。这一步没过就去接自动化，只是把错误批量放大。代理这一环的完整排查顺序可以参考代理IP配置：指纹浏览器绑代理到验证出口的完整排查。

第二步，用 Local API 启动这个环境，拿到调试地址。 NexBrowser 的 Local API 在本机监听、免费不限调用，通过它按环境启动窗口，返回内容里会带这个窗口的 Chrome DevTools Protocol 调试地址（http 形式的调试端口，或 ws 开头的 WebSocket endpoint）。这个地址就是后面一切的接口。接口本身怎么跑通、返回不对时按什么顺序查，见Local API 浏览器怎么跑通：从本地接口到 CDP 对接的排障顺序。

第三步，把地址交给支持连接外部会话的驱动或 MCP 服务。 这里有一个必须先确认的点：你用的那个 MCP 包，是否提供「连接到已有 CDP 端点」的启动参数。提供的话，配置里指向上一步拿到的地址即可；不提供的话，它只会自顾自再开一个全新浏览器，你前两步就白做了。各家包在这件事上差别很大，以它自己仓库的 README 为准，别照抄别人的配置。如果你更习惯直接写代码而不是挂 MCP，同样的接管逻辑可以看Playwright 接管指纹浏览器：connectOverCDP 怎么连，哪几步最容易踩坑。

第四步，用一条最小指令验证。 让模型打开一个查 IP 的页面并把结果读回来。返回的 IP 和你第一步在窗口里手动看到的一致，才算真的接上了；如果读回来的是你本机的 IP，说明它开的是自己的浏览器，回到第三步。

客户端配置长什么样

本地客户端的配置基本是同一个形状：在 mcpServers 里注册一个命令行入口，客户端与 MCP Server 之间默认走标准输入输出（STDIO），部分实现走本地 WebSocket。

{
  "mcpServers": {
    "browser": {
      "command": "npx",
      "args": ["-y", "<对应的 MCP 包名>"]
    }
  }
}

接管已有窗口时，额外的调试地址参数追加在 args 里，具体参数名看该包文档。改完配置通常要重启客户端；判断是否注册成功，看客户端的工具列表里有没有出现浏览器相关的那几个工具，而不是看它有没有报错。

容易卡住的几个地方

• 地址写死。每次通过 Local API 启动环境，返回的调试端口/ws 地址可能变化，窗口关闭后旧地址立即失效。把它当成每次任务开始时动态取一次的值，不要硬编码进配置。
• 顺序反了。环境窗口还没启动就让 MCP 去连，得到的一定是连接失败。先启动环境，再启动/唤起 MCP 会话。
• 工具调用要人工批准。多数客户端默认每次工具调用都弹确认，稍长的任务会停在那儿等你点。跑之前想清楚这条任务链有多少步，需不需要调整批准策略。
• npx 首次拉包慢。国内网络下首次启动可能卡在下载上，看起来像「MCP 没反应」。可以先在终端里手动执行一次安装，确认包能拉下来再回客户端配。
• 页面结构识别不到。回到上面无障碍快照那一节，先判断是不是元素本身没有可访问名称，而不是反复换模型。

什么时候其实不用上 MCP

每天重复、步骤固定的活儿——同一批环境按顺序打开、点同样几个位置、导出同样的报表——用无代码 RPA 或者直接写脚本更稳，结果可预期，出错也好查。MCP 的优势在于一次性、描述式、需要模型判断页面内容的任务：比如让它在一个你不熟悉的后台里找到某项设置，或者读取一批页面里格式不统一的信息。把它当成「能看懂页面的临时工」，而不是定时任务的替代品，期待值会准得多。想先弄清楚 MCP 和 RPA 各自的位置，可以看浏览器MCP是什么：别只看它能不能替代RPA。

一条边界

这套链路的正当用途是管理你自己有权限的账号：把重复操作交给工具，同时保证每个账号始终待在它自己的环境和出口里。它不适用于批量注册、养号这类行为，环境隔离做得再规范也不等于账号不会被平台处置——隔离解决的是「不同账号之间不要互相牵连」，不解决账号本身的运营合规问题。

真要动手的话，顺序是反过来的：先有一个配好代理、验证过出口的隔离环境，再谈让 AI 接管它。客户端在NexBrowser 下载页（Windows，国内与海外两条线路，安装包带代码签名，macOS 仍在开发中），装完先把第一个环境和代理跑通，再回到上面第二步。