playwriter
remorses/playwriter加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一下这个场景：你的 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"的需求只会持续增长。