playwriter
让AI Agent直接控制你的Chrome浏览器,零门槛实现网页自动化操作
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
让AI Agent直接控制你的Chrome浏览器,零门槛实现网页自动化操作
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象一下这个场景:你的 AI 编程助手想要帮你完成一个任务——自动登录 GitHub、提交一个 PR、填写报销单,或者在某个 SaaS 平台上完成批量操作。传统的方案是让 AI "假装" 帮你操作:它生成一段代码,你自己复制粘贴到浏览器里执行,然后告诉它结果。
但这就像让一个从未见过世界的盲人写代码来控制一台电脑——效率低下、出错率高得离谱。AI 需要"看见"页面,需要"点击"按钮,需要"输入"文字,需要"等待"页面响应。
Playwright 就是这样一款工具:它将你的 Chrome 浏览器变成 AI Agent 的"眼睛"和"双手",让 AI 能够像真人一样与网页交互——看到页面内容、理解 UI 结构、执行点击和输入操作。
![]()
图1:Playwright Chrome 扩展,图标变绿即表示连接成功
Playwright(注意:与微软的 Playwright 测试框架同名但不同项目)由独立开发者 Tommaso De Rossi(GitHub @remorses)创建,仓库创建于 2025 年 11 月,2026 年 5 月仍有活跃更新。这是一个非常年轻的 AI Agent 工具类项目,在不到一年内获得了 3,574 颗星,增长速度相当可观。
这个项目的诞生背景非常清晰:当时市面上已有的浏览器自动化 MCP(Model Context Protocol)工具,如 Browserbase Stagehand 等,都存在一个共同的致命缺陷——它们每次都启动一个全新的 Chrome 实例。这意味着 AI 每次操作都是从零开始,没有你的登录状态、没有你的浏览器扩展、没有你的 cookies,所有网站都会将 AI 视为一个陌生的访客,轻则要求验证,重则直接封禁。
Remorses 意识到这个问题的根本在于:这些工具在 Chrome 和用户之间插入了一个中间层,而真正需要的是让 AI 直接接管用户自己的 Chrome。Chrome DevTools Protocol(CDP)就是那座桥梁。
让我们用一个生活场景来理解 Playwright 的设计哲学。
传统浏览器 MCP:就像你去租车公司,租车公司给你克隆一辆完全一样的车,但车里是空的,没有你上次听过的电台频道、没有你存过的导航记录、没有你贴过的停车证。开着这辆"空壳车"去停车场,管理员一眼就认出你是生面孔。
Playwright:你直接坐进自己的车,把钥匙交给 AI,让它帮你开。车里所有的东西都是你熟悉的,AI 知道你平时用哪个银行 App、哪个邮箱、哪个社交账号。它不需要重新"认识"这个世界。
这种"共享驾驶"模式的另一个好处是内存占用大幅降低。据作者测试,同时运行多个 AI Agent 操作同一个浏览器,比每个 Agent 单独启动一个 Chrome 实例,内存占用减少约一半。
Playwright 提供三种使用方式,满足不同技术深度的用户:
从 Chrome Web Store 安装扩展后,点击扩展图标 -> 打开一个标签页 -> 图标变绿表示连接成功,就这么简单。安装 CLI 后就能通过命令行向浏览器发送 Playwright API 调用。
Playwright 同时是一个 MCP Server,支持直接集成到 Claude Desktop、Cursor、Windsurf 等 AI 编程工具。只需在 MCP 配置文件中添加一行:
{
"mcpServers": {
"playwriter": {
"command": "npx",
"args": ["-y", "playwriter@latest"]
}
}
}
之后 AI Agent 就能通过 MCP 的 execute 工具直接调用完整的 Playwright API,无需任何中间层转换。
通过 npm i -g playwriter 全局安装后,可以使用完整的命令行工具集:
# 启动浏览器
playwriter browser start
# 创建有状态的会话
playwriter session new
# 执行操作
playwriter -s 1 -e 'await page.goto("https://github.com")'
playwriter -s 1 -e 'await page.click("text=Sign in")'
最强大的特性是状态持久化:state 对象在多次调用之间保持一致,这意味着 AI 可以在一次操作中"记住"之前的数据。比如先爬取页面上的用户名列表,然后在后续调用中逐个处理——而不需要每次都重新访问页面。

图2:传统 MCP 的错误效果 vs. Playwriter 的精准操作效果
Playwright 的技术栈非常清晰:
编程语言:TypeScript(Playwright 官方生态就是 TS-first)。核心代码在 playwright/src/ 目录下,约 70+ 个源文件。
核心依赖:
@browserbasehq/stagehand — 借鉴了 Stagehand 的 DOM 观测和 ARIA snapshot 能力@mozilla/readability — 从网页提取可读内容,用于 AI "理解"页面cdp-relay.ts、cdp-session.ts)— Chrome DevTools Protocol 的 Relay 架构架构亮点:
Relay 架构:Playwright 引入了一个 Relay Server(中继服务器),扩展和 CLI 通过 WebSocket 与 Relay 通信,Relay 再与 Chrome 的 CDP 端口通信。这种设计使得扩展和 CLI 可以独立运行,通过 Relay 解耦。
多会话隔离:通过 session 概念,每个 AI Agent 可以拥有独立的状态空间(state 对象),同时共享浏览器标签页。这解决了多 Agent 并发时的状态隔离问题。
实时录制回放:集成 ffmpeg,支持屏幕录制,AI 可以"看见"自己的操作结果(page.recording?.stop())。
AR/ARIA 快照:通过 snapshot() 函数获取页面的 ARIA 树结构,为 AI 提供语义化的页面视图(而非原始 HTML),便于 AI 理解"这个按钮叫什么名字"。
Chrome 扩展结构(extension/src/):
background.ts — 后台 Service Worker,管理连接生命周期recording.ts — 屏幕录制相关逻辑offscreen.ts — Offscreen Document,用于后台任务toolbar/ — 浏览器工具栏 UI 组件安装难度:几乎零门槛
安装 Playwright 只需要两步:
npm i -g playwriter不需要懂 Docker、不需要配置环境变量、不需要购买云服务器。
使用门槛:取决于你的场景
Playwright 还提供了一个 skill 配置(skill.md),AI Agent 安装后可以"理解"如何使用这个工具,这是给 AI 用的"工具使用手册",而非给人类看的文档。
尽管设计精巧,Playwright 也有其局限性:
平台依赖:Playwright 依赖 Chrome 浏览器,这意味着它只支持 macOS 和 Windows(以及 Linux 的 Chrome 环境)。Firefox 和 Safari 用户暂时无法使用。
安全风险:让 AI Agent 直接控制你的真实浏览器存在一定安全风险——如果 Agent 被恶意指令误导,可能在你的真实账户上执行未经授权的操作。项目作者在文档中也明确提到了这一点。
反自动化检测:虽然 Playwright 通过 Ghost Cursor 模拟真实鼠标行为来降低被检测的概率,但部分网站(如 Google、Captcha)仍然会检测到自动化特征。这一问题目前无法完全解决。
远程环境限制:对于 Devcontainers、VM 或 SSH 远程环境,需要额外的配置才能使用,这是 MCP "共享浏览器"模式的固有限制。
Playwright 的出现代表了 AI Agent 浏览器控制领域的一个趋势转变:从"为 AI 建造专用浏览器"到"让 AI 使用你的真实浏览器"。
这一思路的影响是深远的:
对于 AI 编程助手:以 Claude Code、Cursor 为代表的 AI 编程工具,长期面临"无法操作真实浏览器"的痛点。GitHub Copilot Workspace、Devin 等项目都在探索浏览器自动化,但大多数方案都无法突破"新建浏览器实例"的瓶颈。Playwright 的 MCP 集成让这个问题有了优雅的解法。
对于 RPA 赛道:传统 RPA(Robotic Process Automation)工具如 UiPath、Automation Anywhere 通常需要人工录制操作流程,门槛高、维护成本大。Playwright 的自然语言驱动方式,可能会推动 RPA 工具向 AI-first 方向演进。
增长数据:项目从 2025 年 11 月创建到 2026 年 5 月,不到 7 个月时间获得 3,574 颗星、150 个 fork、20 个 open issues,增长曲线陡峭。随着 Claude Code、Cursor 等工具的普及,对"浏览器操作 Agent"的需求只会持续增长。