先把话说在前面现在网上聊 Playwright MCP 的帖子十篇里有八篇在教你怎么装个包、起个服务然后让模型打开一个网页截个图。这不叫项目这叫工具演示。真正让人头疼的是后面那一步——你照着抄完发现它处理真实业务的时候根本接不上要么答非所问要么操作路径乱套要么权限和安全一塌糊涂。我前后帮几个团队搭过这类自动化底座自己也踩过不少坑这篇就把怎么做才不至于沦为又一个Demo的关键环节拆开讲清楚。我需要先界定一下这里说的 Playwright MCP 到底是个什么东西。它本质上是一个把浏览器自动化能力封装成 MCPModel Context Protocol工具的服务进程让大模型能通过标准协议直接调用打开网页、点击、填表、读取页面内容这些操作。听起来挺美好但问题恰恰出在标准协议这四个字上——协议只管传输格式不管你的工具设计得合不合理、权限边界在哪、失败之后怎么恢复而这些才是项目能不能从能用跨到好用的分水岭。1. 先搞清楚自动化Demo和自动化项目的分界线在哪很多团队做这个方向最大的误区是把跑通了当成做完了。模型能通过 MCP 打开一个页面、点两下按钮、拿到一段文本就认为万事大吉。但冷静看一眼就会发现这种程度的东西距离能在真实业务里顶着用还有好几层窗户纸。1.1 Demo 的典型特征每次都要从零开始讲需求我见过最多的 Demo 形态是开发者起了一个 Playwright MCP 服务然后在客户端里问模型帮我打开某网站登录一下。模型确实能调工具也确实能把页面操作出来。但你再追问一句登录之后呢如果验证码弹出来了怎么处理如果页面加载超时了要不要重试如果这个操作涉及到钱能不能加个二次确认基本就哑火了。核心问题在于这种交互方式是模型即兴发挥——它没有一份明确的、可复用的任务上下文每次对话都在重新摸索页面结构。真实项目恰恰相反它需要把高频操作沉淀成稳定的、可预测的流程让模型执行的是流水线某一道工序而不是重新发明一遍轮子。打个比方Demo 像是让一个新人每次上班都重新研究怎么开办公室的门锁而项目是给他一张门禁卡他只需要知道进门前刷一下卡就行。前者灵活但不可靠后者受限但稳定。做自动化方向稳定压倒一切。1.2 项目化改造的核心从开放问答变成封闭执行我自己的判断标准很简单如果模型在调用自动化工具之前需要先花大段对话去理解这个页面是什么、要做什么那这个 MCP 服务的抽象就是失败的。好的设计应该是页面结构、操作路径这些知识被沉淀在服务端的工具描述、模板或者配置里模型的任务被压缩成选哪个流程、填什么参数。换句话说项目化的标志是模型的自由度被刻意回收交给确定性的代码和配置去处理。举个例子在真实项目里我不会让模型自己去找登录按钮而是提供一个工具叫auth_login(account, password)这个工具内部用稳定的选择器定位输入框、处理登录跳转、断言登录结果如果失败直接返回明确的错误码。模型只需要决定要不要调用它而不需要操心怎么调用才能成功。这一步转型是区分 Demo 和项目的分水岭。1.3 想让别人用起来先得学会预设环境另外只要你的目标是让团队其他人也用上这套东西那就必须处理一个现实问题每个人的电脑环境都不一样。屏幕分辨率、浏览器版本、网络快慢、甚至公司代理都不尽相同如果这些变量没有在项目设计之初被考虑进去那这个东西就只能在你自己的机器上跑。这里我强烈建议引入容器化或至少环境一致性方案。Playwright 官方提供了现成的 Docker 镜像里面预装了浏览器和全部系统依赖你只需要把 MCP 服务跑在容器里对外暴露一个标准的 stdio 或者 HTTP 接口就行。无论谁用底层浏览器环境都是一模一样的能省掉九成以上的在我这能跑啊的纠纷。注意不要让环境问题成为你项目的第一印象。别人用你的工具第一次就报错大概率不会觉得是你的环境没配好而是会觉得这个工具不行。2. 架构上先想清楚模型、MCP服务、页面三者怎么分工拆开看一套能打的 Playwright MCP 架构至少要分成三个角色模型负责意图理解和任务拆解、MCP 服务负责把模型指令转成可执行的浏览器操作、页面/业务逻辑负责提供操作对象。很多项目做散架就是因为这三个角色之间的边界糊了。2.1 模型的职责边界只做决策不做精细操作模型擅长的是什么是用自然语言理解用户想要什么然后把目标拆成一系列行动。但模型不擅长什么是不知道底层页面现在的真实状态、不知道这个按钮此刻是否可点、不知道某个网络请求是否已经返回。也就是说模型应该是一个决策者而不是操作员。可现实里很多人设计 MCP 工具时恨不得把 Playwright 的所有 API 原封不动抛给模型什么page.mouse.move、page.keyboard.press都暴露出来。这看起来能力很强实际用起来是灾难级的——模型会陷入无穷无尽的试错里点一下没反应就再点一下完全不知道问题出在哪。正确的做法是把工具粒度收敛到业务动作级别login、search、add_to_cart、submit_order。每个动作内部去处理各种异常分支对外只暴露成功/失败/需要人工确认这几个有限状态。2.2 MCP服务层的职责把页面语言翻译成业务语言MCP 服务这一个层其实是整个架构里最容易被低估的部分。它不只是一个把 JSON-RPC 请求转发给浏览器驱动的管道它还是一个翻译层——把页面上的原始信号DOM 节点、网络日志、浏览器事件翻译成模型能理解的业务信号。举一个非常具体的例子。假设你的页面是个典型的电商站点前端有个下单按钮点击后要经历校验表单 → 弹出确认弹窗 → 提交订单接口 → 跳转订单详情页这样一串流程。如果 MCP 服务只是把点击按钮的命令发给浏览器那模型完全不知道点击之后到底发生了什么它只能继续凭感觉行动。更合理的设计是服务层内部封装一个submit_order工具它内部自动完成点击 → 等弹窗 → 确认 → 等待接口返回 → 断言跳转成功然后把结果精简为{status: success, order_id: 123456, redirect_url: ...}。模型拿到这个结构就知道这一步已经尘埃落定可以放心进行下一步。这就是页面语言到业务语言的翻译。2.3 选择器策略别让稳定定位成为项目的阿喀琉斯之踵写 Playwright 的人都知道定位元素有好几种策略按文本、按 CSS 选择器、按 role、按 test-id。Demo 阶段无所谓怎么方便怎么来。但项目阶段这是要定规矩的否则今天页面加个按钮、明天改个 class你的自动化就瞬间全挂。我个人的习惯是在项目里优先约定使用>