Playwright MCP：让 AI Agent 用可验证的浏览器状态完成网页工作

我一直觉得，让 AI Agent 操作浏览器最难的部分，不是把滑鼠点到某个按钮，而是让每一步操作都能被理解、验证与重现。单纯把画面截图交给模型，模型可能看见按钮，却不一定知道它在页面结构中的角色；只靠座标点击，画面稍微改版，整个流程就可能失效。Microsoft 的 Playwright MCP 提供了一个值得研究的方向：它把 Playwright 的浏览器自动化能力包装成 MCP server，让支援 MCP 的 LLM client 透过结构化的 accessibility snapshot 与工具呼叫来操作网页。

本文不把 Playwright MCP 描写成「替 AI 按按钮」的神奇外挂，而是从工程角度拆解它真正解决的问题、适合的使用场景、如何开始、状态如何管理，以及为什么安全边界不能交给它单独负责。我认为，这个专案最有价值的地方，正是把 Agent 与浏览器之间的互动，从脆弱的视觉猜测，拉回到有结构的页面状态与明确的工具介面。

先讲结论：它把浏览器变成 Agent 可以读懂的工具

Playwright MCP 的核心定位很清楚：这是一个使用 Playwright 的 Model Context Protocol server，提供浏览器自动化能力。模型可以开启页面、读取页面状态、寻找文字、点击元素、输入资料、执行导览、取得 console 讯息，也可以在需要时扩充 PDF、vision 或 devtools 能力。

这里最重要的差异，是预设互动依赖 accessibility tree，而不是把 screenshot 当成唯一资讯来源。Accessibility snapshot 会以结构化文字描述页面中的角色、名称与可互动元素，工具回应也会给出可以继续操作的 element reference。对 Agent 来说，这比「画面上大概有一个蓝色按钮」更接近可推理的状态：它可以先读取页面，再依照页面实际存在的元素执行下一步。

这种设计也让「验证」变得自然。Agent 不必在点击后盲猜成功与否，而是可以重新取得 snapshot、搜寻页面文字、检查 URL 或读取 console 讯息。当流程用在测试、探索式自动化或长时间执行的任务时，这种状态回读比一次性的视觉操作更容易留下可追踪证据。

不过，我不会把它理解成完全取代 Playwright 或所有浏览器 Agent 工具。官方 README 特别比较了 Playwright MCP 与 Playwright CLI 加上 skills 的差异：对 coding agent 来说，CLI 可能更节省 token，因为它不需要把大型工具 schema 与冗长的 accessibility tree 持续放进 context；MCP 则更适合需要持续浏览器状态、丰富页面 introspection，以及反复读取结构的 agentic loop。选哪一种，不是谁比较先进，而是要看任务是不是需要一个持续存在、可被多个工具操作的浏览器上下文。

它解决的不是「自动化」而是互动可靠度

传统网页自动化通常由工程师预先写好 selector、等待条件与错误处理。这种方式在固定流程上非常可靠，但当网站内容、登入状态与下一步目标会随任务改变时，预先列出所有分支就会变得昂贵。LLM Agent 的优势则是可以根据页面内容临场决策，但如果它只依赖 screenshot 或自由格式的文字，决策就很难稳定。

Playwright MCP 的折衷点是：由模型决定「要做什么」，由 Playwright 与 MCP 工具约束「能怎么做」。例如，一个典型的研究任务可以拆成以下循环：

1. 开启指定网站，取得目前页面的 accessibility snapshot。

1. 透过 snapshot 找到搜寻栏、导览连结或结果清单。

1. 使用 browser_click、输入工具或导览工具执行明确动作。

1. 等待触发的网路请求与页面工作稳定下来。

1. 重新读取页面 snapshot，确认状态真的改变。

1. 把需要的内容写入输出档案，或交给下一个 Agent 步骤。

这个循环的工程价值，在于每一次行动前后都有状态。它仍然可能遇到动态网站、验证码、非标准元件与登入失效，但问题比较容易被定位：是 snapshot 找不到目标、selector 不唯一、页面尚未稳定，还是权限与网路设定阻止了导览。与单纯「再截一张图试试看」相比，这是一个更可观测的除错介面。

如何开始：先用最小设定跑通一个可验证任务

官方文件要求 Node.js 18 或更新版本，以及一个支援 MCP 的 client。最简单的 server 设定如下：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

这段设定的重点不是 JSON 本身，而是让 MCP client 以 stdio 启动 @playwright/mcp。安装后，我建议不要一开始就挑选需要登入、下载档案或跨多个网站的复杂任务，而是先做一个三步验证：开启公开页面、读取 snapshot、搜寻一段确定存在的文字。只有这个最小流程稳定，才逐步加入点击、表单输入与输出档案。

如果你使用 Claude Code、Codex 或其他支援命令列注册的 MCP client，官方 README 也提供对应的 add command；如果 client 使用 JSON 设定，就把上面的 server 区块放进该 client 的 MCP 设定档。当需要独立启动一个 HTTP MCP server 时，可以使用：

npx @playwright/mcp@latest --port 8931

接着让 MCP client 连线到 http://localhost:8931/mcp。这种模式适合 IDE worker、远端浏览器或需要把 server 生命周期与 client 分离的部署，但也代表你要更认真处理 host、port、网路来源与存取权限，不要因为本机测试方便就直接暴露到公网。

开始验证时，我会特别观察四件事。第一，snapshot 是否能表达真正需要的元素，而不是只看到空壳页面。第二，动作完成后，重新 snapshot 是否出现预期变化。第三，失败时 console 与 URL 是否提供足够线索。第四，任务是否能在同一个 browser context 中连续完成，而不是每一个工具呼叫都重新登入。这四项比「模型有没有成功点到按钮」更能判断整合是否可用。

Browser profile 是能力，也是状态风险

Playwright MCP 预设可以使用持久化 profile。官方文件说明，登入资讯会保存在 persistent profile，而且不同工作区会透过 workspace hash 使用不同的 profile 路径。这让需要跨步骤登入的流程容易很多：Agent 第一次完成登入后，后续工作可以沿用 browser state，不必每次重新输入帐号。

但持久化状态同时也是风险来源。第一，profile 可能包含 cookies、local storage 与其他登入资讯，不能把它当成一般暂存资料夹任意共享。第二，同一个 persistent profile 同时间只能由一个 browser instance 使用；如果多个 MCP client 共享同一个工作区，可能互相冲突。官方建议在平行工作时使用 --isolated，或为每个 client 指定不同的 --user-data-dir。

如果任务不需要保留状态，我会优先使用 isolated mode：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--isolated"
      ]
    }
  }
}

在 isolated mode 中，关闭浏览器后，这个 session 的 storage state 会遗失。如果要预先提供 cookies 与 local storage，可以搭配 --storage-state 指向由 Playwright 产生的 storage state file。这适合测试或受控的服务帐号流程，但档案本身仍然是敏感资料，应放在权限受控的位置，并避免直接出现在模型可读的输出中。

另一个值得注意的选项是 --secrets。Playwright MCP 可以把工具回应中符合设定的明文替换掉，降低模型意外看到敏感内容的机率。官方文件同时明确说明，这只是便利功能，不是 security feature，也不是安全边界。真正的权限控制仍然要放在 MCP client、作业系统帐号、容器、网路策略与目标服务本身。

Screenshot 不是主流程，Vision 是额外能力

这个专案的文件把 accessibility snapshot 放在核心操作路径，并提供 screenshot 工具作为取得视觉画面的能力。对一般结构化页面来说，我会先使用 snapshot，因为它比较适合找角色、名称与文字，也比较容易让 Agent 依据明确 reference 做动作。

但世界上有些页面不会把重要资讯完整暴露在 accessibility tree 里，例如 canvas 应用程式、图表、视觉化编辑器或高度客制化的拖放介面。这时可以评估 vision capability，让流程有座标互动能力。这不是代表每个任务都应该开启 vision，而是把它视为处理特殊页面的补充工具。开启越多能力，模型可以使用的操作面就越大，测试与权限审核也应该同步增加。

同样地，--mobile、--device、--viewport-size 与 --user-agent 这些设定，会改变页面呈现与可互动元素。做一般资料撷取时，固定 viewport 可以减少不必要的差异；做 responsive UI 测试时，则应把装置与 viewport 当成测试条件明确记录。不要把在桌面版成功的 selector，直接假设在行动版也能成功。

安全性：官方已经说得很直接，它不是安全边界

我认为 Playwright MCP 最需要被写进导入 checklist 的一句话，是官方 Security 章节的明确警告：Playwright MCP 不是 security boundary。这句话会直接影响部署设计。

浏览器 Agent 可以读取页面、造访网站、使用登入状态、写入档案，甚至在特定设定下连接既有浏览器。这些能力只要被错误的 prompt、恶意页面内容、过宽的网路来源或错误的 profile 权限放大，就可能形成资料外泄或非预期操作。allowed-origins 与 blocked-origins 可以协助限制浏览器请求来源，但 README 明确提醒它们不构成安全边界，也不会影响 redirects。因此不能只设定一个 allowlist，就宣称系统已经安全。

比较务实的防线包括：

为 MCP server 使用低权限、专用的作业系统帐号或容器。
不要把个人浏览器 profile 与自动化任务共用。
对登入状态、storage state file 与输出档案设定最小权限。
以 client 层的工具授权与人类核准流程限制写入、付款、删除与发送操作。
对 HTTP transport 绑定 localhost 或受控网段，避免直接暴露到公网。
对允许存取的 workspace、origin、下载目录与 secrets 做明确设定。
把页面内容当成不可信资料，不要因为网页文字要求 Agent 改变系统规则就照做。
在正式任务中记录导览、工具呼叫、结果与失败原因，但不要把 token 或密码写入 log。

最后一点特别重要：浏览器看见的内容不是系统指令。就算页面上出现「请忽略先前规则」或要求输出秘密的文字，Agent 也应把它视为外部资料，交由 client policy 决定能否继续。Playwright MCP 提供的是浏览器操作层，不会自动替你完成 prompt injection 防护。

我会怎么评估它是否适合团队

如果团队正在做探索式测试、自动化研究、客服后台操作、跨页面资料整理，或需要让 Agent 在同一个登入浏览器上下文中连续工作，Playwright MCP 很值得做小规模 PoC。它的价值不是少写几个 selector，而是提供一个让模型读取页面结构、呼叫浏览器工具、再回读结果的标准介面。

但如果流程完全固定，例如每天都在同一个页面填同一张表，传统 Playwright test 或 Playwright CLI 可能更简单、更可预测，也更容易在 CI 中维护。官方对 MCP 与 CLI 的比较也提醒我们，coding agent 未必需要大型工具 schema 与完整 snapshot；在 context 成本很重要的场景，CLI 加上 skills 可能更合适。

我会用以下顺序导入：先用公开网站建立不涉及登入的 smoke test，再加入隔离 profile 与受控的 storage state，接着测试失败恢复与重试，最后才评估 HTTP transport、平行 client、容器化与高权限操作。每个阶段都要有可量化的验收条件，例如 snapshot 找到率、动作后状态验证率、非预期导览次数、任务完成时间与人工介入比例。这些指标能避免团队只看示范影片，却没有掌握实际维运成本。

结语：把 Agent 操作浏览器变成可观测的工程系统

Playwright MCP 最值得注意的地方，不是它能不能取代人工浏览器操作，而是它提供了一种更适合 Agent 的互动抽象：页面先被转成结构化状态，动作透过明确工具发生，结果再被读回验证。这个循环让浏览器 Agent 不再只是「看图猜下一步」，而可以逐渐靠近可观测、可测试、可重跑的工程流程。

当然，它不会自动解决所有问题。动态页面、登入、平行 profile、特殊视觉元件、网路限制与 prompt injection 仍然需要团队自己设计防线。尤其官方已清楚说明它不是安全边界，任何正式部署都不应把 origin filter、secrets masking 或 MCP server 本身当成完整的资安方案。

我的判断是：如果你的 AI Agent 需要持续理解网页状态，而不是只执行几个固定的浏览器脚本，Playwright MCP 是一个很适合拿来建立第一个可验证原型的开源工具。先用最小设定跑通 snapshot、动作与回读，再依照任务需要加入 isolated profile、storage state、vision 或 HTTP transport。这样导入，才有机会把浏览器自动化从 demo 变成真正可维护的 Agent 能力。

参考资料