技能还是 MCP 服务器？从 token 成本给出答案

结论

工作如果是一条可以事先写完的离散命令——跑一轮测试、导出一份报告、按规范做一次比对——优先用封装 CLI 的技能。Agent 需要在多轮之间保住同一个浏览器、同一份登录态，并在失败后接着探查时，用 MCP 服务器。两者不是替代关系，是两种账单。

这个判断和 Playwright 团队自己的产品分界一致：MCP 把工具 schema 和页面快照送进对话；CLI 用短命令把快照写到磁盘，agent 只在需要时再读文件。上下文里同时还放着代码库和长推理链时，CLI 更省；稀缺的是「会话不断」时，MCP 更合适。

token 差距该怎么读

2026 年被反复引用的一组量级是：同类浏览器任务，走 MCP 大约 11 万 token，走 CLI 大约 2.7 万 token，大约四倍。这组数字来自社区对 Playwright 团队基准的转述，以及独立复现，不是官方 SLA，也不能直接拿去报预算。页面复杂度、快照频率、是否夹带截图，都会把倍数拉开。

可以当成方向，不要当成报价：

• 可访问性树快照通常是大头，而且算输入 token。
• 截图比结构化快照更贵。同一条路径若每步都截图，成本会再跳一档。
• 模型还在循环里做「下一步点哪里」时，贵的是决策次数，不是浏览器本身。Playwright MCP 作为软件是开源、无按次计费的，账单在模型供应商。

有架构评论把「大约 200 条用例」当作 MCP 集成是否划算的经验门槛：套件更小的时候，接 MCP 的固定成本可能盖过它省下的维护。这同样是经验值，用你们自己的套件规模验证。

什么时候 CLI 不够

下面这些事，一次生成脚本再丢给 CI，做不到：

• 探索式走查：下一步取决于这一步页面上实际出现了什么。
• 自愈：定位器失效后，要在同一个已登录会话里重试，而不是整段脚本重跑。
• 长时间无人值守：浏览器进程、cookie、下载目录都得活过多轮对话。

CLI 可以带上持久化的登录态文件，但进程本身不跟对话一起活着。需要「边看边改加压曲线」或「边看边修选择器」时，选 MCP。

怎么打包才不强迫用户二选一

条件允许时，两种形态都提供，并在文档首页写清默认推荐，而不是各写一半让读者猜。

实用布局是：技能目录里放「何时调用哪条命令、参数怎么读、失败怎么停」；旁边用 mcp.json 声明需要长会话时启动的服务器。不要在技能正文里把整份工具 schema 再贴一遍——那等于把 MCP 的 token 成本手工搬回来。

技能正文建议只留四块：适用任务、一条可复制命令、输出文件放在哪、什么信号表示该改走 MCP。MCP 说明则写清：会占用哪个浏览器配置、会不会复用用户的登录态、会话结束谁负责关掉进程。

选型清单

1. 任务步骤能否在动手前写完？能，就先 CLI。
2. 失败后是否必须留在同一个浏览器里？是，就 MCP。
3. 这条流水线每天跑多少次？次数高时，先量一次真实快照的 token，再决定默认路径。
4. 两种都提供时，默认路径写在第一句，不要写在 FAQ 最后。

材料边界

文中的约 11 万 / 2.7 万 token 是 2026 年公开转述的量级，见 Bug0 对官方表述的整理，以及 Morph 等对 Playwright CLI 与 MCP 的对比。你们自己的页面上，倍数可能差一倍以上。引用时请同时链到 Playwright 当前文档，而不是只链到二手文章。