8.0
热点
AI SCORE
技术实践2026-10-17 23:01
用 Playwright 验证网页提供的智能体动作
dev.to · AI#自动化测试#WebMCP#智能体
Editor brief · 编辑速览
文章介绍 Playwright 1.64 对 WebMCP 动作枚举与调用的实验性支持，并说明应用注册和浏览器开关要求。测试需同时检查动作返回值与数据变更，继续保留正常浏览器流程测试。
最初发布于 anton.qa。
如果你的网站提供了可供 AI Agent 调用的操作，那么这次发布就值得关注。WebMCP 让页面能够提供这些操作，Playwright 1.64 则新增了列出和调用这些操作的实验性支持。
如果你的网站没有提供 WebMCP 操作，目前也就没有这方面的内容需要测试。如果团队正在添加这些操作，你可以在测试常规页面流程的同时，一并检查它们。
保留现有的浏览器测试。新增的检查主要关注这些网站操作返回了什么，以及改变了什么。
假设你的网站向 AI 提供了一个查询订单送达日期的操作。tool 就是网站提供的、可被调用的操作。
假设测试订单 1043 保存的送达日期是 10 月 16 日。用这个订单号调用查询操作，将返回结果与保存的日期进行比较，并确认记录没有发生变化。
这只是一个说明性的例子，并非实际测试运行的记录。你的网站必须注册这个操作，浏览器也需要启用 WebMCP。
应用必须通过浏览器的实验性 WebMCP 接口注册 tool。浏览器也需要启用 WebMCP。Chromium 需要在浏览器启动时传入 --enable-features=WebMCP。Firefox 需要同时启用 dom.modelcontext.enabled 和 dom.modelcontext.testing.enabled 这两个首选项。WebKit 尚未实现这项功能。
在 Playwright API 中，主 frame 的实例是 page.webmcp。frame 是页面中拥有自身内容的一块区域。子 frame 中的 tool 属于该 frame 的 frame.webmcp 实例。要选择实际注册了 tool 的那个 frame。
在排查 tool 缺失的问题之前，这些前提条件很重要。页面没有注册 tool，并不能说明测试环境配置失败了。对于没有 tool 的页面，返回空列表完全可能是正确的。
tools() 返回所选 frame 中当前注册的 tool。将这些 tool 的名称与应用原本打算提供的操作进行比较，同时检查描述和输入结构。输入 schema 描述了 tool 期望接收的值。
名称、描述、输入规则和 annotation 都由页面提供，其中 annotation 是关于行为的提示。应将这些页面提供的信息视为不可信输入。即使某个 annotation 声称操作是只读的，那也只是页面提供的提示，不能证明该操作不会修改数据。
如果缺少某个 tool，先检查所选的 frame 和注册时机，再检查应用是否确实注册了它。如果浏览器不支持 WebMCP，tools() 也可能抛出异常。
callTool() 会在所选 frame 中调用指定名称的 tool。选择你自己的应用中一个预期结果已知的操作，并提供符合其 schema 的输入。调用会返回页面中该 tool 提供的结果。
既要检查返回内容，也要检查应用中的实际结果。对于前面的订单查询，要将返回结果与已知的送达日期进行比较。对于更新操作，要在调用之后读取已保存的记录，检查预期修改是否生效，并确认其他记录没有变化。检查时要遵循应用文档中规定的保存时机。拿到返回值，只能说明 tool 作出了响应，不能证明回答正确，也不能证明更新已经持久化。
对于会修改数据的操作，要使用受控的记录进行测试。不要在这项检查中执行购买操作或发送客户通知。callback 就是运行该 tool 的代码。
最后两种情况都会通过抛出异常的方式失败。仅凭这个失败，无法判断具体原因。需要检查已注册的名称，以及你在测试中主动触发的受控失败。
页面 tool 检查能告诉你，面向 AI 的操作报告了什么、改变了什么，但它不能替代用户正常使用浏览器的流程。保留针对可见控件、提示信息以及完整用户任务的测试。这些检查回答的是另一个问题：用户能否通过页面完成任务？
对于你自己启用了 tool 的页面，可以问：
这份清单可以作为使用 Playwright 1.64 的实用起点。每一项的预期结果，都要根据应用实际约定的行为进行调整。
我是 Anton，开发 AI 工具，也衡量它们实际运行得有多快。我曾是 Apple 工程师。我开发了 ollamatps.com，并在 anton.qa 撰写有关 AI 开发与性能测量的文章。
如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。