前一阵子给一个动态网页采集任务做技术方案页面是 Vue 写的列表数据要等 JS 渲染完才能拿到用 requests 直接请求返回的 HTML 里什么都没有。第一反应是用 Selenium结果光找匹配 Chrome 版本的 WebDriver 就来回折腾了好几下。等把驱动和脚本都跑起来又一个一个去处理等待、弹窗、iframe。后来换成 Playwright发现浏览器下载、驱动匹配、录制脚本、自动等待、Trace 回放这些散落的环节早已经被它收进同一条工具链里。真正让我停下来思考的是团队里做 AI 应用的同学看了方案后问了一句能不能让 Agent 自己打开浏览器去点这不是一句玩笑话。过去 Web 自动化的主体是测试工程师写脚本、跑回归、看报告现在越来越多需求开始变成“让 AI Agent 自己观察页面、决定下一步、操作浏览器、输出结果”。而 Playwright 频繁出现在这条链路里不是因为它只是一个更好用的测试框架而是因为它从一个更底层的位置补上了“AI 可靠控制真实浏览器”这件事。这篇文章我打算顺着这条线展开先聊为什么 Playwright 能成为浏览器自动化的底座再讲 MCP 协议怎样把浏览器能力暴露给 AI然后从 CLI、Agent Browser 这类方案里整理出实际落地路径最后给一套从录制脚本到可复用框架、再到 AI 调用的完整操作顺序以及最容易被忽视的坑。1. 别急着上 AI先理解 Playwright 为什么成了“浏览器自动化的事实底座”很多讨论一上来就聊 AI、聊 MCP、聊 Agent反而把最基础的判断漏掉了为什么是 Playwright而不是 Selenium也不是 Cypress要理解 AI 时代的集成方式先要看清楚它在自动化领域站稳脚跟的真正原因。1.1 用 Selenium 的驱动问题理解 Playwright 的“合体”设计凡是写过 Selenium 脚本的人基本都经历过“浏览器驱动不匹配”的折磨。Chrome 今天自动升级到某个版本你的 chromedriver 还是旧版脚本就可能在启动阶段直接报错。驱动和浏览器是两套东西这个设计本身就带出了长期维护成本你要记住浏览器版本、下载对应驱动、放到正确路径再处理 CI 环境和本地环境的差异。Playwright 的解决方式很直接把浏览器管理内建到工具链里。你执行一条安装命令它把对应版本的 Chromium、Firefox、WebKit 下载好启动浏览器时版本、协议、启动参数都封装好不需要再手动匹配驱动。这看起来只是省了一步实际影响却很大版本一致性让整个环境从一个“容易漂移的系统”变成了“开箱即用的沙盒”。还有一个容易被低估的功能是自动等待。Selenium 时代很多脚本变成“睡两秒再点”结果页面快的时候浪费时间慢的时候照样报错。Playwright 内置动作可操作性检查点击前会等元素稳定、可见、可点击这套机制让脚本的稳定性明显提升。对 AI Agent 来说这种等待机制更重要因为模型不会像人一样判断“页面是不是加载完了”它需要一个可靠的工具帮它把这一步解决掉。1.2 一套 API 同时覆盖 Web、Electron 和移动 WebView 的代价与边界Playwright 经常被拿来和 Cypress 比较因为两者在开发体验上都很现代。但 Playwright 另一个差异化能力是它覆盖的范围更广不只浏览器页面还包括 Electron 内嵌窗口、移动端 WebView 测试以及多浏览器、多标签页、iframe、网络拦截模拟等真实场景。我在热搜词里看到“playwright连接electron里面嵌套的浏览器”这个问题说明已经有不少团队在做桌面端自动化时发现 Electron 应用里嵌着的 Chromium 窗口也能通过 Playwright 控制。相比 Selenium 对这类场景的支持Playwright 的 API 和上下文模型更贴近真实浏览器行为。但边界也要说清楚Playwright 控制的是 DOM 和浏览器行为不是操作系统级 UI。如果目标是一个完全自绘、没有 DOM 结构的客户端界面它并不合适。你要先判断要自动化的是哪一层有 DOM 就走 Playwright只有像素和坐标就要考虑视觉方案。这个判断听起来简单实际很多项目卡在这里。1.3 从“测试工具”到“浏览器操作协议”定位已经变了过去我们把 Playwright 归类为 E2E 测试框架写用例、跑回归、出报告。但放到 AI 工作流里看它的角色更像是“浏览器操作协议”。为什么这么说因为当你要让 AI 操作浏览器时最缺的不是模型的理解能力而是一个稳定的执行层。模型不理解浏览器底层的渲染进程、重绘、网络请求、DOM 生命周期但它可以理解“打开某个页面”“点击某个按钮”“读取某段文字”。Playwright 的作用就是把浏览器里那些复杂、不稳定、需要经验的操作抽象成一组相对稳定的工具函数。AI 只需要决定调用哪个工具工具内部怎么处理等待、重试、异常由 Playwright 兜住。这也是为什么我在标题里用了“底座”这个词。它不是某个 AI 产品的一部分而是所有上层 AI 自动化方案可以共享的基础设施。2. MCP 不是魔法它把“AI 会写脚本”升级成“AI 能操作浏览器”聊到这里MCP 就避不开了。但我不想把它讲成一种抽象协议而是直接看它在浏览器自动化场景里到底解决了什么问题。2.1 MCP 到底是什么连接模型与工具的标准化协议MCP 的全称是 Model Context Protocol模型上下文协议。你可以把它理解成“AI 世界的统一接口”支持 MCP 的客户端可以连接不同的 MCP 服务端每个服务端向外暴露一组工具模型通过标准方式调用这些工具然后拿到结构化结果。这和直接写提示词让 AI “生成一段 Playwright 脚本”有本质区别。生成脚本意味着模型只是在写代码执行还需要人来跑遇到问题还要人来排。而 MCP 模式下模型本身就是操作者它看到工具列表决定调用“打开页面”服务端真的去打开浏览器它决定调用“点击”服务端真的去点击页面元素。整个过程有执行、有反馈、有可记录的轨迹。它的价值不是“AI 更聪明了”而是“AI 终于有了手脚”。过去模型只能处理文本和代码现在可以通过标准协议操作真实系统。2.2 Playwright MCP 的典型工作方式从自然语言到浏览器动作社区里已经有 Playwright 的 MCP Server 实现常见的使用方式是这样的在支持 MCP 的客户端配置文件里声明一个 playwright 服务指向 Playwright MCP 的可执行命令再指定参数。{ mcpServers: { playwright: { command: npx, args: [playwright/mcplatest] } } }配置完成后在客户端里给 AI 下达一个任务比如“打开测试平台登录进入订单页把第一条订单的状态返回给我”。模型看到可用的浏览器工具后会逐步执行调用打开页面工具传入测试平台 URL。服务端启动浏览器打开页面返回页面标题或摘要。模型发现页面有登录框调用输入、点击工具填入账号密码。再调用导航或点击工具进入订单列表。最后调用读取文本工具拿到第一条订单状态整理成答案。整个过程每一步都会返回结果因此你可以干预、核对、加人工确认。这比“让 AI 直接写脚本再自己去跑”要可控得多。2.3 和 Computer Use 式方案比差异在哪里很多人把 MCP 和 Computer Use 混淆。Computer Use 类方案走的是“视觉 坐标”路线模型看截图理解屏幕内容生成鼠标坐标和键盘输入。它的优势是不依赖 DOM任何软件界面都可以尝试但代价是慢、贵、容易误判而且很难调试。MCP Playwright 走的是另一个方向模型读取的是 DOM 结构化信息、可访问性快照、元素状态操作的是语义化的定位器而不是像素坐标。因此它更快、更稳定、更容易审计。缺点也很明显必须有 DOM 可依赖遇到纯 canvas 绘制页面就会失灵。实际项目中我不会把两者对立起来而是按场景选。需要自动化的是一个 Web 后台登录态、表单、列表、分页那我一定优先走 MCP Playwright如果目标软件是桌面客户端或某类无法读取 DOM 的系统才需要考虑视觉方案。从工程稳定性角度看能读取结构化信息就尽量别让模型靠猜。3. 从 Playwright CLI 到 Agent Browser一条通向“AI 主导自动化”的链路MCP 解决了“AI 怎么调用浏览器”但一个完整的 AI 自动化任务还需要调度、执行、反馈、审计这些环节。这也是 CLI 和 Agent Browser 这类概念出现的原因。3.1 CLI任务级验证和批处理里最常见的入口Playwright CLI 能做的事情不少运行测试、录制脚本、截图、导出 PDF、启动浏览器、清缓存。在一个 AI 工作流里CLI 最大的价值不是某条具体命令而是它可以嵌入任何编排系统。你可以这样设计一个循环Agent 根据需求生成或修改测试文件然后用 CLI 执行执行完成后解析 JSON 报告判断哪些用例失败失败后把 trace 文件交给模型分析模型根据页面状态修正定位器或步骤再重新执行。这条“AI 写代码 CLI 执行 模型看结果修复”的闭环不需要 MCP 也能跑通而且非常直观。所以我的建议是在动手接 MCP 之前先把 CLI 跑顺畅。如果命令行都启动不了浏览器后面所有上层方案都是空中楼阁。先用playwright install装好浏览器再用最小脚本确认启动、打开页面、截图都正常这应该成为接入 AI 链路前的环境底线。3.2 “Agent Browser”不是单一产品而是一套结构“Agent Browser”这个关键词可以理解成两类东西一类是具体产品一类是设计模式。对大部分开发团队来说更重要的是后者怎样让 AI Agent 附着在真实浏览器上完成多步任务。一个 agent browser 风格的自动化系统通常有这样几层浏览器实例层由 Playwright 负责管理启动、页面、上下文、多标签工具抽象层把业务动作封装成模型可调用的函数比如打开页面、输入、点击、读取、上传、截图调度决策层由大模型承担根据用户目标和页面反馈决定调用哪个工具反馈状态层每步操作后把页面摘要、DOM 状态、异常信息返回给模型审计回放层记录全部操作、截图、网络请求方便排错和合规审查。这个结构里真正承担“智能”的是模型对工具序列的决策真正承担“稳定”的是 Playwright 对浏览器复杂性的封装。两者结合才能形成一个可信赖的 Agent 自动化方案。3.3 搭建 Agent 自动化时要做的几个设计决策如果你的团队打算自己搭这套结构有几个决策点会在项目早期就决定成败。工具粒度很关键。工具太碎模型要调用很多次上下文容易爆而且每一步都有失败概率工具太大模型缺乏灵活性稍微换个场景就不会用了。我常用的思路是从中等粒度起步一个“打开页面并等待稳定”工具一个“点击页面元素”工具一个“读取页面关键内容”工具。等某条固定流程反复出现后再把它沉淀成更高层的业务工具。权限边界必须做。Agent 能访问哪些域名能不能从当前页面跳转到外部链接哪些按钮不允许点击失败后是继续尝试还是立刻停止这些不能只靠提示词约束最好在工具层就做拦截。高风险动作比如提交订单、删除数据、修改配置要加入人工确认节点。反馈机制要闭环。模型不能只发一个操作指令就完事它需要知道操作是否成功。常见做法是每次工具调用后返回结构化结果包括当前 URL、标题、关键元素状态、页面截图必要时再加上“操作是否成功”的判断字段。这个反馈质量直接决定模型下一步决策的准确度。4. 实战从录制脚本到可复用 Playwright 框架的四步走理解了原理接下来看怎么落地。我建议不要一上来就搭 Agent先把 Playwright 这套基本功走完再考虑把能力开放给 AI。4.1 先用 Codegen 跑通第一条链路安装并初始化项目后直接打开录制工具。playwright codegen https://example.com浏览器会跟着录制窗口启动你在页面上点、输入、切换左侧会同步生成对应的定位器脚本。这一步最大的价值不是直接生成可用测试用例而是帮你快速建立对页面结构的感知哪些元素有稳定的文本哪些按钮只能靠 role 定位哪些区域在 iframe 里。录制出来的代码往往有冗余定位器也可能不够稳所以不要直接把录制脚本当成最终用例。正确姿势是用它拿到关键定位器再手工整理成结构化的脚本。4.2 定位策略和 iframe最常见的停顿点动态渲染页面里定位器是脚本稳定性的第一道防线。我一般优先用语义定位器而不是复制一段很长的 XPath。page.get_by_role(button, name登录).click() page.get_by_placeholder(用户名).fill(test_user)语义定位器的好处是页面布局调整了只要按钮文字、输入框占位符没变脚本还能跑而长 XPath 一遇到 DOM 结构调整就失效维护成本很高。对于必须依赖结构的地方建议给测试环境加上稳定的 test id不暴露的情况下再退而求其次。iframe 是另一个高频问题。第三方登录、支付回调、广告位、数据报表都很容易把内容嵌在 iframe 里。Playwright 的 frame_locator 写法比传统的切换 iframe 方式更符合定位器组合思维。login_frame page.frame_locator(#login-iframe) login_frame.get_by_placeholder(用户名).fill(test)对于“动态 iframe”场景建议先确认 iframe 的加载时机再加等待或轮询不要假设 iframe 一定存在。4.3 把脚本整理成最小可复用框架框架不等于某个重量级测试平台而是一种分层习惯。我的最小推荐是四层配置层环境地址、账号、超时时间、无头模式开关从配置文件或环境变量读取页面对象层每个页面一个类暴露业务方法不暴露零碎定位逻辑任务层串起多步骤流程做断言或者给 Agent 提供高粒度工具函数输出层统一收集截图、Trace、JSON 报告。一个简单的目录结构可以是playwright_project/ ├── config.py ├── pages/ │ ├── login_page.py │ └── order_page.py ├── tasks/ │ └── order_flow.py ├── reports/ └── conftest.py这套分层真正解决的问题不是代码美观而是让自动化脚本可以从“一个人手写的一次性任务”变成“团队可以长期维护的资产”。如果你后面要接 AI会发现这些封装好的业务方法天然适合暴露成模型可调用的工具函数。4.4 当 AI 介入把框架能力封装成工具一旦 Playwright 脚本稳定了接入 AI 就变成一件顺理成章的事。把框架里的业务方法包装成带清晰描述的函数然后通过 MCP Server 或自定义工具注册暴露给模型。下面是一个示意结构展示“一个可被 AI 调用的业务工具函数”长什么样def check_order_status(account: str, order_no: str) - dict: 登录测试后台查询指定订单状态。供 Agent 决策使用。 with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(https://test.example.com/login, wait_untilnetworkidle, timeout30000) page.get_by_placeholder(用户名).fill(account) page.get_by_placeholder(密码).fill(get_secret()) page.get_by_role(button, name登录).click() page.goto(fhttps://test.example.com/orders/{order_no}, wait_untilnetworkidle) status page.locator(.order-status).inner_text(timeout10000) browser.close() return {order_no: order_no, status: status}生产环境还要加异常处理、重试、日志和权限校验但这个结构已经能说明核心问题一个稳定、可预期、有清晰输入输出的业务函数才是 AI Agent 可以依赖的最小执行单元。不要指望模型去理解页面内部怎么实现你只需要告诉它“调用这个函数传入账号和订单号返回状态”它就能用好这个工具。5. 那些最容易踩坑的环节错误、依赖、权限和长期维护如果只看功能演示Playwright 和 AI 自动化看起来都很顺。但一旦进入真实项目问题往往集中在几个固定的环节。5.1 “target closed”这类报错先按链路排查经常看到的报错原文类似playwright: target closed: target page, context or browser has been closed遇到这类问题先别急着怀疑框架按顺序查这几点你的代码是不是在页面操作前或操作中误调用了browser.close()或context.close()这是最常见的原因。当前页面是不是因为window.open、location跳转或 tab 关闭而失效后续 locator 还在操作旧页面页面进程是不是崩溃了查看是否有 renderer process crashed 相关日志。是否把 browser 实例当成了全局单例多个任务并发关闭了同一个实例在 iframe 或 Electron 内嵌窗口场景里frame 的生命周期判断是否正确排查思路也很简单把操作数拆细每步打印 URL 和标题开启有头模式看页面到底什么时候消失或者直接回放 Trace。报错信息只能缩小范围能告诉你原因的是执行过程的日志和页面状态。5.2 环境不一致依赖缺失、版本漂移、路径不对环境问题里Linux 服务器上漏装系统依赖是最常见的。Playwright 启动 Chromium 前需要一批共享库少了就会报类似“启动浏览器失败”的错误。先用系统包管理工具安装依赖再启动脚本通常就能解决。更隐蔽的是环境漂移。CI 里用了一个版本的浏览器本地是另一个版本团队成员再各装各的脚本跑起来就容易出现奇怪差异。建议在项目里锁定 Playwright 和浏览器版本CI 和本地都从相同配置安装。还有一类路径问题容易被 AI 关键词误导。比如配置 MCP 客户端时报某个 CLI 二进制找不到这本质上不是 AI 问题而是可执行文件的路径没有正确写入系统 PATH。处理方式也很传统用which看可执行文件在哪检查 PATH 环境变量是否指向了正确目录然后重新配置。链路越长环境约束越容易叠在一起越要先做排除法。5.3 AI 自动化的特有隐患上下文超限、任务漂移、操作误判传统脚本的问题是可预测的报错就报错超时就是超时。AI 自动化多了一层不确定性模型可能跑着跑着就开始“自由发挥”。上下文超限是最常见的问题。如果把整个页面的 DOM 都塞给模型token 很快就不够用。正确做法是只给模型可访问性快照或页面摘要按需展开某个区域。任务漂移也很常见模型做到一半忘记原始目标去点击了不相关的内容解决方法是把原始目标持续拼进系统提示词并在关键步骤之间加入校验节点。操作误判则更微妙模型以为已经登录成功实际上页面还在加载中以为点击了保存实际上按钮还没出现。应对方式不是指责模型而是加强反馈层让每次工具调用都主动检查 URL、元素状态、加载完成标志把这些信息返回给模型。不要把 AI 的每一步当成既定事实要让每一步都带状态反馈回来。5.4 合规和审计是自动化的底线用浏览器自动化做测试、采集、运维时都应该遵守目标网站的使用条款、robots 协议和适用的法律法规。自动化不应该被用来绕过身份验证、访问控制、频率限制也不应该用于未授权的数据获取。落到工程层面合规意识要体现在很多细节里登录态要合规获取请求频率要合理设置采集范围要克制操作日志要完整保留敏感信息要做脱敏。一个负责任的技术团队在让 Agent 掌握浏览器操作能力的同时也应该给它设置好边界、审计和追责机制。6. 给你的最后判断什么场景适合什么方案看到这里你大概率已经能分清 Playwright、MCP、CLI、Agent Browser 这几个概念之间的关系。最后用一个选型框架帮你判断自己项目到底该用哪一层。6.1 选型参考直接代码、CLI、MCP、Agent Browser 怎么选场景推荐方式核心原因常规 Web 回归测试Playwright Test / pytest-playwright原生支持断言、测试报告、Trace、CI 集成工程能力最完整快速验证、一次性探索录制 CLI不需要写完整框架录一段跑一遍就能验证页面流程非技术成员用自然语言操作网页MCP 客户端 Playwright MCP模型充当操作者工具调用过程可记录、可干预长期处理复杂网页业务流程自研 Agent Browser 式架构需要任务规划、步骤反馈、权限拦截、审计回放等多层能力桌面端 Electron 窗口控制Playwright Electron 支持可通过已有 DOM 操作内嵌浏览器不需要像素级方案如果你还是纠结 Playwright 和 Cypress 怎么选我的判断是多浏览器、多标签页、iframe、移动 WebView 这类“真实浏览器行为”覆盖更广的需求Playwright 更顺手如果你更习惯 Cypress 的调试器体验和社区生态也可以继续用但面向 AI Agent 集成时Playwright 的上下文模型和定位器设计更接近“给工具调用做底层”的思路。6.2 什么会被 AI 改变什么不会AI Agent 确实会改变“谁来决定操作步骤”。过去写自动化脚本每一步都要人写死页面一改脚本就要改现在模型可以根据页面反馈动态决定下一步调什么工具这解放了很多繁琐的维护工作。但也要冷静看到模型决定的只是“接下来调哪个工具”真正保证执行稳定的仍然是工具底层的等待、定位、浏览器管理、错误恢复和结果返回。AI 降低了使用门槛让更多人能驱动浏览器自动化但底层那些元素定位、DOM 结构、iframe、多页面、渲染等待这些基本功并没有消失。所以我的建议是如果你刚接触这个领域先不要被 Agent 和 MCP 的概念带走。把 Playwright 最小脚本跑通亲手录制一次流程理解定位器和等待逻辑再把常用流程封装成业务函数。等底座稳定了你会发现 AI 接入只是多了一个调用者真正扛住生产环境压力的还是那层稳定可靠的浏览器自动化基础设施。