如果你之前学过 Playwright，这两个月可能会有点恍惚。
一边是传统教程的评论区越来越安静，一边是「Playwright MCP」相关的内容在小红书上爆火，B 站两天前刚上线「Codex + Playwright MCP 零代码做 UI 自动化」的新视频。哔哩哔哩再往大了看：阿里前几天发了 Qwen-UI-Agent，SeekBrowser、egolite 这类「给 AI 用的浏览器」也接连冒头。
2026 年的 Playwright 到底在干嘛？自己攒的测试经验是不是白学了？该不该转型？我们盘了知乎、小红书、B 站、微博最近一个月约 50 条相关帖子和讨论，今天一次说清楚。
一、社区讨论最多的，已经不是教程，而是「AI 在用浏览器」
把采集到的帖子摊开看，讨论大致分成了四簇：
第一簇是 Agent / MCP 方向，互动最猛。小红书上一篇《第 6 课：用 PlayWright MCP 实现前端自动化》的教程拿到 282 赞、446 收藏。小红书另一条只说了一句「Playwright MCP 真是伟大的发明」的帖子，评论区聊出 62 条、攒了 257 赞。小红书
第二簇是反爬与采集方向，焦虑最重。知乎上「Playwright 被检测为爬虫」的问题有两万多次浏览，高票回答是一部对抗血泪史。知乎
第三簇是生活效率工具方向，离普通人最近：有人给快递驿站做查件机器人，有人用它一次自动发布 9 个平台的内容。
第四簇是传统测试教程，还在更新，但互动明显平淡。
更关键的信号来自官方和厂商：微软研究院 5 月发布了开源网页智能体框架 Webwright，核心思路就是让大模型自己在终端里写 Playwright 代码、执行、看日志、反复修正。微博VS Code 官方账号演示 Copilot 支持 Claude Skills 时，选的演示 skill 也是 Playwright。微博
一句话：Playwright 正在从「测试工程师的框架」，变成「AI Agent 打开网页、点按钮、读内容的管道」。
二、AI 为什么偏偏选中了 Playwright
AI 要操作浏览器，大致有两条路。
一条是截图视觉路线：把页面截图喂给多模态模型「看」。直观，但 token 消耗大、速度慢，模型还得带视觉能力。
另一条是结构化状态路线：把页面导出成无障碍树这样的结构化文本，让模型直接「读」页面。token 省、速度快，普通文本模型就能跑。
Playwright MCP 走的是第二条路。知乎上有个实验很能说明问题：给 Agent 接上 Playwright，只丢给它一个业务目标——「解决编号 ORD-1042 的工单」，不给任何操作步骤。模型自己读页面结构、自己决定点哪个按钮，走完「观察 → 执行 → 验证」的闭环，把一个客服工单完整处理掉了。知乎这就是 Agent 和传统脚本的分水岭：你交出去的是目标，不是步骤。而你过去攒下的 Playwright 经验——页面对象、登录态管理、等待策略——在这条路上全都还作数。
三、三条路线，分别适合谁
路线一：测试转型，适合测试开发 / QA。
社区资料最厚的就是这条：先用自带的 codegen 录制操作，让 AI 补全、优化成可执行脚本；再把 Playwright MCP 装进 Claude Code 或 Codex，让 AI 生成用例、跑回归。小红书上收藏最高的几篇教程基本都是这条路。小红书第一步建议很具体：装上 @playwright/mcp，先让 AI 对着一个现有页面跑一轮回归试试。
路线二：Agent 集成，适合要做 AI 应用的人。
接入方式有两条：一是 CLI + skill，把 skill 装进项目的 .claude/skills 目录，相当于给工具配一份说明书，大模型读完就会用；二是 MCP，把工具直接挂进 Agent 的工具箱。知乎两个细节别忽略：用持久化会话保存登录态，下次自动复用；跑完一轮让它自己验证结果，闭环才成立。
路线三：爬虫与数据采集，适合有真实需求的人，但先听句劝。
这是伤亡最重的方向。知乎那篇高票回答把 2026 年的反爬拆成三层：协议指纹，TLS 已经从 JA3 卷到 JA4，Cloudflare、Akamai 在握手阶段就能 403 你，连 HTML 都看不到；环境指纹，Canvas、WebGL、音频、字体全是识别素材；行为指纹，鼠标移动轨迹、停留时间、访问路径，几十个维度交给 ML 模型打分。知乎
作者给的结论相当现实：2026 年三层全过不现实，把前两层对齐，通过率大概能从三成提到七成，行为层才是真正的天花板。知乎遇到企业级防护，别自己死磕，换托管方案或走官方 API。知乎还有个工程账：每个 Chromium context 占 200MB 以上内存，高并发自搭先想好服务器扛不扛得住。
四、两个反证，别被带节奏
其一，「Scrapling 比 Playwright 快 784 倍」是偷换概念。那是拿 HTML 静态解析的速度，去比 Playwright 完整启动浏览器的自动化，两件事本来就不在一个赛道。知乎需要交互、渲染、登录态的场景，Playwright 依然是主流选择。
其二，「Agent 专用浏览器」这波新品方向没错，但都还早：生态、稳定性、社区资料都没跟上，不必急着把已学的东西扔掉。
还有一条合规底线值得重复：做采集，守 robots.txt、控制频率、不碰登录后数据和个人信息。知乎社区里多篇帖子都在强调这一点。
五、接下来怎么办
三个自检问题：
正在做测试的：你的用例维护成本有多高？这周就可以试一次「AI 生成 + 跑回归」。
想做 Agent 的：别先研究截图方案，从 Playwright MCP 的结构化路线起步，token 最省、见效最快。
在做采集的：先评估目标站防护等级。基础检测，curl_cffi 加 stealth 补丁够用；企业级防护，别硬碰。
三个值得持续盯的信号：
Playwright 保持月级发版节奏，更新日志里的 Agent 相关功能值得逐条看。
官方 @playwright/mcp 和 playwright-cli 的更新，这是微软亲自下注的方向。
Agent 专用浏览器赛道的动静：谁先解决登录态和稳定性，谁才值得重新评估。
最后留个话题：你觉得 Playwright 变成 AI 的手和眼，是抢了测试工程师的饭碗，还是开了个新饭碗？评论区聊聊。
