Playwright突然开始推CLI + Skills：AI写UI测试，为什么反而不想给Agent塞一堆MCP Tool了？

摘要：

Playwright官方现在已经明确给Coding Agent提供playwright-cli和可安装Skills；GitHub Agentic Workflows甚至把内置Playwright从MCP模式切到了CLI模式。原因之一很现实：大量MCP Tool Schema本身就会消耗Agent上下文。对AI测试开发来说，这背后真正值得关注的不是CLI和MCP谁更高级，而是Agent应该获得多少工具、多少页面信息，以及测试能力如何按需进入Context。

---

最近Playwright有一个变化，我觉得测试开发的人值得认真看看。

不是又加了一个Locator。

也不是Trace Viewer更新了。

而是：

Playwright开始越来越认真地考虑“AI Coding Agent到底应该怎么操作浏览器”。

现在Playwright官方已经有专门面向Coding Agent的：

playwright-cli

甚至可以直接：

playwright-cli install --skills

把Playwright使用能力安装成Agent Skill。官方文档目前列出的支持对象包括Claude Code、GitHub Copilot、Cursor，以及其他支持本地Skills的Coding Agent。

更有意思的是另一件事。

GitHub Agentic Workflows之前内置的Playwright工具同时支持：

MCP

和

CLI。

现在它把内置方式改成：

CLI only。

需要MCP仍然可以显式配置，但已经不再是默认隐藏能力。([GitHub Docs][2])

为什么？

答案其实特别适合测试工程师研究。

---

一、问题可能不是Agent工具太少，而是工具太多

假设我们希望Coding Agent自动测试一个电商网站。

给它Playwright MCP以后，Agent可能看到很多浏览器工具：

navigate

snapshot

click

type

evaluate

trace

screenshot

……

每个Tool都有：

name

description

parameters

schema

这些信息都要进入模型能够理解的上下文。

GitHub解释这次变化时就直接指出：

Playwright MCP暴露了较大的浏览器自动化Tool Surface，这些Tool Schema会占用Context，即使Agent这一轮根本用不到其中绝大多数。([GitHub Docs][2])

这句话很值得琢磨。

因为我们以前设计自动化测试框架，通常觉得：

封装能力越多越好。

但Agent时代可能不是。

给Agent：

10个Tool

和

100个Tool

不是简单的“能力增加10倍”。

还可能意味着：

Tool Selection难度上升

Context占用增加

Token增加

错误调用增加

推理空间被压缩

这其实是一个新的测试变量：

Tool Surface Complexity。

---

二、Playwright CLI的思路恰恰相反

Playwright官方现在对Coding Agent的推荐思路很有意思。

Agent只需要知道一个入口：

playwright-cli

真正需要某个操作时，再使用：

playwright-cli --help

或者通过安装好的Skill找到对应能力。

例如：

playwright-cli open https://example.com
playwright-cli snapshot
playwright-cli click e15
playwright-cli type "hello world"
playwright-cli screenshot

官方将CLI定位为更适合需要兼顾大型代码库和推理Context的Coding Agent；而MCP更适合需要持续状态、反复理解页面结构的专门Agent Loop。([Playwright][4])

注意这里并不是：

CLI淘汰MCP。

真正有意思的是：

不同Agent任务开始需要不同的Tool Loading策略。

---

三、这其实和我们最近一直说的Skill是同一件事

Skill不是：

把整个世界一次性塞给模型。

而更像：

需要什么能力，再把对应知识拿进来。

Playwright自己的Skill现在就包含：

运行和Debug测试

Request Mocking

运行Playwright代码

Browser Session

Storage State

Test Generation

Tracing

Video Recording

Element Attributes

等等。([Playwright][3])

于是Coding Agent工作的时候可以变成：

当前任务：

“排查Checkout测试为什么失败。”

Agent首先知道：

我有Playwright能力。

发现需要Debug。

再读取：

Running and Debugging Playwright Tests

发现页面行为异常。

再调用：

snapshot / trace

而不是任务刚开始，就把几十个Tool Schema全部塞进Context。

这就是：

Capability Discovery。

对AI测试开发来说非常值得研究。

---

四、那到底应该怎么测这种“会自己使用Playwright”的Agent？

举一个实际业务。

我们让Agent测试：

电商Checkout。

业务要求：

加入商品

↓

进入购物车

↓

使用优惠券

↓

提交订单

↓

验证金额

Agent最后说：

“Checkout测试通过。”

传统做法可能验证：

最终订单创建成功。

但现在至少应该增加三个层面的测试。

第一层：Outcome

订单有没有成功创建？

assert order.status == "created"

第二层：UI Behavior

Agent有没有真的完成关键页面操作？

assert trace.has_action("add_to_cart")
assert trace.has_action("apply_coupon")
assert trace.has_action("submit_order")

第三层：Business Assertion

最关键：

优惠券到底有没有算对？

假设：

商品100元。

优惠券满100减20。

最终应付80元。

def assert_checkout_business_rules(result):
    assert result.subtotal == 100
    assert result.discount == 20
    assert result.payable == 80

这时候Playwright负责：

浏览器操作。

但测试开发负责：

什么才叫正确。

这个区别非常重要。

---

五、因为“Agent把页面点通了”不等于“测试通过”

以后很容易出现一种非常危险的AI自动化：

Agent：

打开网页。

找到按钮。

点击。

填表。

下单。

看到Success。

然后宣布：

PASS。

这其实只是：

Navigation Success。

不是：

Business Quality Pass。

比如优惠券本来应该减20。

系统Bug只减了10。

页面仍然：

Order Success。

Agent也成功：

点到了最后。

如果没有业务断言：

这套所谓AI Testing只是在帮我们更聪明地点击页面。

所以真正有价值的结构应该是：

Agent Browser Control

Deterministic Assertion

Business Rules

Trace

而不是：

Agent Browser Control = Testing。

---

六、Playwright自己现在甚至已经有Planner、Generator、Healer

这件事更有意思。

Playwright官方目前提供三个Test Agents：

Planner

Generator

Healer。

Planner负责探索应用并产生测试计划。

Generator把计划转换成Playwright Test。

Healer运行测试并尝试修复失败测试。([Playwright][5])

看起来很爽。

但测试工程师应该马上想到一个问题：

Healer到底是在修测试，还是在掩盖Bug？

假设原来的测试：

await expect(page.getByText("支付成功")).toBeVisible();

新版页面改成：

“支付处理中”。

测试失败。

Healer发现新的文字。

然后自动把断言改成：

await expect(page.getByText("支付处理中")).toBeVisible();

测试：

PASS。

但业务需求可能明确要求：

付款完成以后必须进入“支付成功”。

如果Agent只从UI现状推断测试应该怎么改：

它可能把：

Product Regression

修成：

Test Pass。

这就是AI Self-Healing Testing里非常值得警惕的问题。

---

七、所以Healer一定要有“禁止自动修复区”

我会把失败分成至少三类。

第一类：

Locator Drift。

比如：

#submit

变成：

button[data-testid=submit]

可以允许Agent自动修。

第二类：

Timing / Environment。

比如接口偶发慢。

可以允许Agent分析，但要保留证据。

第三类：

Business Assertion Change。

例如：

金额

状态

权限

库存

优惠规则

订单结果

这种不能让Agent自己决定“新页面看起来合理，所以修改Expected Result”。

代码里甚至可以明确：

AUTO_HEAL_ALLOWED = {
    "locator",
    "wait_strategy",
    "test_data_setup"
}

AUTO_HEAL_FORBIDDEN = {
    "expected_payment_amount",
    "order_status",
    "permission_rule",
    "inventory_rule",
    "refund_rule"
}

def can_auto_heal(change_type):
    return change_type in AUTO_HEAL_ALLOWED

这样Agent可以帮我们：

修测试代码。

但不能自己：

修改业务真相。

---

八、MCP还是CLI？其实这才是错误的问题

看到GitHub从内置Playwright MCP切到CLI，很容易写成：

“CLI要取代MCP了。”

我不建议这么理解。

GitHub自己的说明也明确表示MCP仍然可用，而且某些需要Persistent State和对页面结构持续推理的场景仍然适合MCP。([GitHub Docs][2])

真正应该问的是：

当前Agent任务到底需要多少工具能力进入Context？

Coding Agent：

代码已经很多。

Repository Context已经很大。

还要分析测试。

可能更适合：

CLI + Skills。

探索型Browser Agent：

需要持续理解页面。

频繁交互。

维护Browser State。

可能更适合：

MCP。

这就从：

“哪个技术更高级？”

变成：

Context Budget和Agent Architecture怎么设计？

这个问题明显更有工程价值。

---

九、甚至可以专门做一个实验

如果是AI测试开发课程，我特别想让学员做这样一个项目：

同一个Checkout测试任务。

做两个Agent。

Agent A：

Playwright MCP。

Agent B：

Playwright CLI + Skills。

固定：

同一个模型

同一个页面

同一组任务

同一组业务断言

然后比较：

Task Success

Tool Calls

Wrong Tool Calls

Input Tokens

Total Tokens

Latency

Cost

Business Assertion Pass

Recovery Attempts

最终不是为了证明：

MCP好。

或者：

CLI好。

而是研究：

不同Tool Interface会不会改变Agent测试行为。

这才是Agent时代很典型的测试开发实验。

---

十、测试开发真正应该抓住的是：AI可以接管操作，但不能接管“正确性的定义”

Playwright以后一定会越来越智能。

测试计划可以AI生成。

测试脚本可以AI生成。

Locator坏了可以AI修。

失败原因可以AI分析。

浏览器甚至可以直接交给Agent操作。

但有一样东西，我认为测试工程师不能轻易交出去：

Oracle。

也就是：

什么才算正确。

订单应该多少钱。

什么状态允许退款。

哪个角色能看到什么。

库存什么时候扣。

失败以后能不能重试。

哪些断言允许Agent修改。

哪些绝对不允许。

这些东西才是真正的软件质量。

所以我看到Playwright开始把：

CLI

Skills

Coding Agent

Test Agents

这些东西组合起来的时候，反而越来越确定一件事：

未来AI测试开发的重点，不是：

“会不会让AI帮我写Playwright。”

这个门槛会越来越低。

真正有价值的是：

当AI自己规划、自己写、自己运行、甚至自己修测试以后，你还能不能设计一套机制，证明它没有把Bug一起‘修’掉。

这个问题，才值得测试工程师现在开始研究。