我停止使用 Playwright。以下是它的替代方案。

发布: 5小时前 (2026年4月24日 GMT+8 16:13)

6 分钟阅读

原文: Dev.to

Source: Dev.to

抱歉，我无法直接访问外部链接获取文章内容。请您把需要翻译的文本粘贴在这里，我会帮您翻译成简体中文。

Playwright 的错误之处

Playwright 是为单用户、确定性的 UI 流程而设计的。你编写选择器，设置身份验证夹具，模拟状态，并运行点击固定序列的脚本。对于简单的登录‑结账流程，它还算可以。

大多数真实的应用都有多个角色共同操作共享状态。客户提交请求，运营人员审核并指派专员，专员完成工作，客户付款，运营人员发货。每一步都依赖前一步，并且每个参与者都是不同的已认证用户。

在 Playwright 这意味着：

多个 auth‑state 文件（每个角色一个）
在每个测试之前种子数据库的夹具
UI 每次变化时都会失效的选择器
在测试单个真实交互之前，需要编写数百行样板代码

你最终会维护一套平行的代码库，仅仅是为了描述用户本来自然会做的事情。

Source: https://github.com/vercel-labs/agent-browser

agent‑browser 的工作方式

agent‑browser 是一个 CLI，允许 AI 代理通过可访问性树来控制浏览器。与其编写

page.locator('[data-testid="submit"]').click()

不如用自然语言描述你想要的操作，代理会自行找出实现方法。

不需要选择器。
不会出现脆弱的 CSS 路径。只要按钮存在且有标签，代理就能找到它。
如果 UI 发生变化，测试也不会失效——代理会自行适应。

角色隔离

为每个角色使用 Chrome 配置目录，并只登录一次：

mkdir -p ~/.config/google-chrome/app-customer
mkdir -p ~/.config/google-chrome/app-operator
mkdir -p ~/.config/google-chrome/app-specialist

npx agent-browser \
  --profile ~/.config/google-chrome/app-operator \
  --headed \
  open https://yourapp.com/sign-in

会话会被持久化。之后的每次运行只要使用 --profile 参数，都会自动加载该会话。

魔法链接

使用 yopmail 进行测试账号——一次性邮箱，无需注册，魔法链接开箱即用。如果遇到邮件发送频率限制，可以直接通过管理 API 生成魔法链接 URL 并导航到该链接，无需发送邮件：

curl -X POST https://.supabase.co/auth/v1/admin/generate_link \
  -H "Authorization: Bearer $SERVICE_ROLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type":"magiclink","email":"test@example.com"}' \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['action_link'])"

编排器模式

对于多角色黄金路径测试，一个 Claude 会话充当编排器。它一次生成一个子代理，每个子代理执行特定角色。状态通过共享的 JSON 文件向前流动。

Orchestrator (main Claude session)
  ├── spawn Agent(customer)    → submits request  → writes request_id
  ├── spawn Agent(operator)    → assigns handler  → writes handler_id
  ├── spawn Agent(specialist)  → does work
  ├── spawn Agent(operator)    → reviews + approves
  ├── spawn Agent(customer)    → pays or confirms
  └── spawn Agent(customer)    → leaves feedback

状态文件

{
  "run_id": "run-2026-04-24",
  "current_request_id": null,
  "confirmation_token": null,
  "steps_completed": []
}

每个子代理都会收到一个包含当前状态的独立提示。它会返回任何新值——如 ID、URL 中可见的令牌——编排器在生成下一个代理之前将这些值写入状态文件。

结果会追加到日志文件中，采用记录后继续的方式，永不因失败而停止：

[operator] 分配专家 — 通过

[specialist] 提交工作 — 通过

[operator] 批准工作 — 失败：未找到批准按钮

[客户] 确认收据 — 通过

成本论点已不复存在

对基于 AI 的测试的主要反驳一直是成本问题。Claude API 调用不是免费的，而 Playwright 是免费的。

如果你在订阅下运行 Claude Code，这个论点就不复存在。子代理在你的订阅下运行，而不是按每个 token 计费。一次完整的 10 步黄金路径运行不产生额外费用。

Playwright 唯一剩下的优势是原始速度——每个测试的毫秒级执行时间 vs. 代理运行的分钟级时间。只有在需要在紧凑的 CI 循环中对每次提交都进行测试时，这一点才重要。对于部署前检查、QA 运行或任何不在亚秒级 CI 流水线中的情况，都没有实际理由选择 Playwright。

实际意义

我已经好几个月没有写 Playwright 测试了。代理测试覆盖面更广，出错更少，搭建所需时间也只是一小部分。我唯一放弃的就是能够在每次提交时运行它们——而对于覆盖六角色流程的集成测试来说，这本来就不现实。

如果你仍在为多角色集成流程编写 Playwright 测试，试试这个设置。你可能再也不会回头。