把浏览器操作交给 MCP 之后，工作流会变成什么样，代码里哪些部分消失了。记录分工怎么划、最容易卡住的四处配置问题，以及卡住时按什么顺序排查。
用 Claude Code 写浏览器自动化，最先受不了的是胶水代码：启动浏览器、绑代理、创建环境、等句柄，这些和业务逻辑没关系，却要一遍遍写。把浏览器操作通过 MCP 交出去之后，这部分基本从代码里消失了，你描述要做的事，模型自己决定调哪个工具。
两者怎么分工
Claude Code 是命令行里的编码助手，能读写文件、跑命令、走 Git，强项是在代码和终端这一侧干活。它不擅长直接碰浏览器，也不该去碰。
MCP 补的正是这一块。它把浏览器自动化环境的能力包装成一组工具，注册之后模型就能调用：列环境、建环境、启停浏览器、截图、读页面内容。一边管代码和日志，一边管浏览器和页面，分工划清楚，出问题也好定位。
工作流的变化
变化最明显的地方是链路搭起来快了。以前改一次流程要动脚本，现在先用自然语言试一遍：列出现在有哪些环境，在其中两个上面登录并截图，把结果汇总出来。能跑通再固化成脚本。
实际项目里通常是三层配合。MCP 承接自然语言指令，适合探索和临时任务；本地 HTTP 接口承接批量动作，比如一次创建几十个环境，稳定且好重试；需要精细交互的部分，比如等某个状态出现、抓页面里的结构化数据，交给 CDP 连接浏览器去做。三者不冲突，各管一段。
环境这一层单独拎出来管，也是这个阶段才想明白的。环境散落在各个脚本里，任务一多，排查就无从下手。现在都改成用环境层工具集中建、集中看、批量回收，脚本只负责拿一个环境 id 去用。多账号场景里，像 PurpleMark 这类环境隔离方案承担的就是这一层，把每个账号的环境、会话和缓存分开，执行层才调度得动。
四处容易卡住的地方
第一处是工具没被识别。多数客户端只在启动时读一遍配置，注册完不重启就是不生效；配置文件路径写错也很常见，不同工具的位置不一样。判断方法很土但有效：手动把服务拉起来，能起来说明是配置问题，起不来就是环境问题。
第二处是鉴权失败，最常见的原因是把凭据复制进来时带了空格或换行。先检查这个，再去看环境变量的读取方式，不同操作系统、不同启动方式下的结果确实会有差异。
第三处是本地接口没起来。这类 MCP 服务大多依赖客户端本身在运行，客户端没开，服务要么起不来要么连接超时。顺带留意端口占用，之前残留的进程没退干净也会占着端口，端口号在客户端设置里能确认。
第四处是并发任务互相干扰，表现是单个任务跑得好好的，一起跑就出现数据错乱、登录态互顶。原因基本都是多个任务共用了同一个环境。这类问题不是调试能解决的，要靠约束：一个任务一个环境，环境的创建和回收走批量接口，不在脚本里临时建。
调试的几个习惯
指令里把等待条件说清楚。点击提交按钮这句话的信息量不够，等提交按钮可点击之后再点，成功率会明显不同。模型负责判断做什么，等待时机得由你说。
从只读任务开始验证链路。列出环境、截图、读取页面文本，这些操作没有副作用，但一次就能验证鉴权、网络、服务三个环节。链路通不过的时候，先别急着跑有副作用的操作。
凭据别写进代码，用环境变量或本地配置文件，文件加进忽略列表；团队里有人变动就轮换一次。本地接口如果关掉了自身的校验，至少要保证它只监听在本机，不被外部访问。
最后一条是边界：MCP 打通的是技术链路，不改变平台规则。集成得再顺，任务本身该遵守的服务条款一条都不会少。
