页面显示成功，代理测试就能判通过吗

AI Agent 跑完下单流程，页面也显示成功，就能放心发版吗？作者给出的反例是：订单接口返回 500，服务端一条订单都没存，测试却通过了。问题出在判定标准：页面说成功，不代表业务真的成功。

作者基于 Playwright 做了开源工具 Vedha，给测试步骤增加网络检查、数据回读和结果状态。它试图补上 Agent 容易漏写的断言，但现有实验还不足以证明它适合所有应用。

页面显示成功，为什么测试还能漏掉故障

作者构造了一个带故障的订单表单：POST /api/orders 返回 500，没有保存数据，前端却照样显示「Order placed」。两次测试都只等待这条成功提示，结果如下：

Playwright  PASS   "Order placed" is on the page
Vedha       FAILED declared checks passed, but the page reported: POST /api/orders returned 500
Server      0 orders stored

要看第二行：声明的页面检查已经通过，Vedha 仍然根据接口错误判定失败。

这个例子并不能证明 Playwright 检不出问题。作者也承认，认真编写网络响应断言，同样能发现故障。Vedha 要解决的是另一件事：当测试只检查文案、URL，尤其由 Agent 临时探索页面时，如何减少遗漏。

作者称，在仓库中运行 npx tsx examples/demo/run.ts，约 3 秒可以复现演示。

Vedha 补的是验证规则，还有失败后的处理

Vedha 保留 Playwright 的自动等待、定位器和浏览器能力，在每个步骤外增加验证层。步骤会得到五种结果之一：verified、failed、outcome_unknown、unverified 或 blocked，分别表达验证成功、失败、结果未知、未经验证或受阻。

对于标记为 mutating 的数据变更步骤，它会观察操作发出的请求。即使页面检查通过，出现 5xx、请求被拒绝或页面错误，仍会判失败。API 符合 REST 约定时，它还会读取数据，确认写入结果。

提交超时后，先确认结果，比直接重试更可靠。

点击「下单」后超时，可能只是浏览器没等到反馈，订单已经创建。Vedha 此时报告 outcome_unknown，等待只读检查确认，不会再次点击而制造重复订单。不过，这属于测试执行策略，不能替代服务端的幂等设计。

它也提供 Agent 使用时的默认约束：MCP server 没有域名白名单就不启动，把页面文字视为不可信数据，并对传入的秘密信息做脱敏。已验证的流程还能导出为普通 @playwright/test spec，放进 CI。

实验支持了什么，还有什么没证明

作者声明，数字来自仓库里的原始试验文件，各留出测试集都在首次运行前写好。脚本测试不使用模型，结果包括：

• 使用常见的文案、URL 检查时，Vedha 检出 140 个预置故障中的 60 个，Playwright 和 Selenium 基线均为 0。
• 最后一次修改后，作者进行了 1,120 次试验的审计，报告误通过、误失败均为 0。
• 相对手写 Playwright，中位开销为 1.05x，但正文没有进一步说明开销的具体口径。

60/140 说明它补到了部分漏检，不能读成全面覆盖；1,120 次审计的双零结果，也不能直接推广到真实项目。

AI Agent 对比采用同一模型、同一组留出任务，比较 Playwright MCP 和 Vedha MCP。但只用了一个免费模型，每个任务跑 3 次，作者自己也将其定位为初步试验。输入正文没有列出完整的 Agent 成绩，无法据此判断提升幅度。

限制同样具体：专家手写完整检查时，两者打平；在第 4 组测试中，Vedha 比 Playwright MCP 少通过一个正常流程，而且工具调用更多。数据回读依赖同路径或单复数对应路径的 REST 读取接口，不覆盖 GraphQL、独立读取端点，以及带过滤条件或按用户划分的集合。

我的判断

我认可把网络故障检查和「结果未知」做成默认规则。Agent 很容易把页面反馈当成业务事实，而提交超时也确实不应该自动变成再次提交。

但这里的优势有明确前提：原有测试断言比较薄弱。对已经检查响应、数据和业务约束的团队，作者的实验没有展示额外检错收益。它更像是在常见疏漏外加一层护栏。

同样，接口返回成功、记录能够读回，也不代表金额、权限、库存等业务规则正确。针对这些问题，仍要编写业务断言。现有结果属于作者自有实验集上的证据，真实项目中的误报率和维护成本，还需要独立验证。

能拿来做什么

• 检查现有前端端到端测试，把只等待成功文案的提交步骤找出来，优先补上请求结果和持久化检查。
• 在本地项目试用 Vedha 时，可以运行下面的命令，再让 Agent 执行「test the checkout flow on localhost:3000」。

claude mcp add vedha -- npx -y @vedhajs/mcp --allow-domain localhost

这里要看 --allow-domain localhost，它限定了允许访问的域名。其他 MCP client 使用同一启动命令 npx -y @vedhajs/mcp --allow-domain localhost。

• 用项目自己的失败案例评估工具，至少覆盖接口 500、提交超时和正常提交；如果后端使用 GraphQL，不能预期获得文中描述的自动回读覆盖。
• 将验证过的探索流程导出到 CI，再补齐业务断言。原文还提供 Agent skill 安装命令 npx skills add HMAKT99/VEDHA、CLI 安装命令 npm i -D @vedhajs/cli，以及包装现有 Playwright page 的 SDK，可按现有测试入口选择接入方式。