给 Agent 接浏览器前，我会先把 Playwright MCP 当成可收回的操作边界

最近给 Agent 接浏览器操作时，我会先问一个很小的问题：这次到底要让模型看见什么、能点什么、失败后留下什么证据。Playwright MCP 的价值正在这里。它把 Playwright 的浏览器能力包装成 MCP 工具，让模型通过结构化页面快照和受控动作来完成浏览器任务，适合放在自动化验收、资料采集、后台巡检和产品回归这类低频但容易出错的链路里。

从 Agent 请求到 MCP 边界、浏览器会话和证据留存的流程示意 来源：Codex image generation

我会先把它当成边界层

MCP 官方文档把 Tools 描述成模型可以调用的函数，关键在于清楚声明能力、输入结构和返回结果。落到浏览器场景，我不会直接把整套浏览器能力裸露给 Agent，而是先拆出一层边界：哪些站点可以打开，是否允许登录态，能否提交表单，下载文件写到哪里，遇到支付、删除、发信这类副作用是否需要停下来确认。

Playwright MCP 的 README 强调它可以用浏览器可访问性快照帮助模型理解页面，这比只让模型看截图更适合做可重复的工程任务。快照能把按钮、输入框、链接和页面层级交代清楚，Agent 的动作也更容易写进日志。对团队来说，这意味着一次失败不只剩下一张图，还能留下访问地址、工具调用参数、页面状态和错误原因。

最小可用落地方式

我通常会从三个约束开始。第一，把浏览器会话做成一次任务一份，storage state 和下载目录都放进临时工作区，任务结束后清理。第二，用 allowlist 限制 origin，内部系统、生产后台和第三方账户页分开放行。第三，把工具分成读取、导航、输入、提交四类，默认只开放读取和导航，真正提交前走人审确认。

这套分层看起来保守，但能换来两个直接收益：排障有线索，权限能收回。比如让 Agent 检查一次仪表盘数据时，它可以打开页面、读取结构化节点、截图留证、导出 trace 摘要；如果它判断需要改配置，只生成建议和定位路径，不直接点保存。这样浏览器自动化仍然能帮人省时间，风险也不会越过流程边界。

适合先接的场景

我会优先把 Playwright MCP 放进可验证的工作流：前端回归走查、文档链接巡检、运营后台只读检查、表单可用性验证、演示环境冒烟测试。它们共同的特点是输入明确、页面范围有限、失败能重跑。暂时不适合一上来就交给它处理资金、账号权限、批量删除和对外发送，这些动作需要更强的审批和审计链路。

如果团队已经在用 Playwright 写测试，Playwright MCP 可以先作为 Agent 侧的浏览器入口，而现有 Playwright 测试继续承担确定性断言。一个偏探索，一个偏验收，两边共享浏览器知识和 trace 思路。等边界跑稳后，再把高频任务沉淀成普通测试脚本或后台任务，Agent 只保留异常排查和临时探索的职责。

参考来源：Microsoft Playwright MCP GitHub 仓库，https://github.com/microsoft/playwright-mcp；Model Context Protocol Tools 文档，https://modelcontextprotocol.io/docs/concepts/tools；Playwright 官方文档，https://playwright.dev/docs/intro。