AI Agent 已经开始进入自动化测试流程。
以前，测试工程师需要自己编写脚本、处理元素定位、分析失败日志。现在，借助 Playwright MCP 或 CLI + Skills，Agent 可以理解页面、操作浏览器，甚至根据执行结果调整测试步骤。
但在实际项目中，一个问题越来越明显：
正常流程能跑通，接口一旦超时、页面发生变化，Agent 还能继续执行吗？
有的 Agent 会不断刷新页面，有的重新执行整条用例，还有的绕过失败步骤，最后报告测试成功。
当这些任务进入持续集成流水线，执行稳定性就成了必须解决的问题。
目录
一、测试能跑通，为什么还不够？
二、MCP 与 CLI 的执行机制有什么差异？
三、故障注入后，Agent 如何恢复？
四、如何设计一次可复现的稳定性评测？
五、工程落地需要解决哪些问题？
六、AI 自动化测试将如何演进？
一、正常执行成功，不代表测试足够稳定
假设有一条订单查询用例：
登录系统 → 进入订单页面 → 输入订单号 → 查询结果 → 验证订单状态。
在网络正常、页面结构稳定的情况下，MCP 和 CLI + Skills 都能完成这些操作。
现在人为制造几个异常：
订单查询接口返回 HTTP 503。
页面请求超时，数据一直加载不出来。
页面重新渲染，原来的元素引用失效。
浏览器会话中断，登录状态丢失。
这时，测试执行器需要判断故障类型、保留执行上下文，并决定是否恢复。
例如，页面元素失效可以重新获取页面快照；接口返回 503，则需要检查重试条件。
测试执行成功率衡量的是能否完成任务，故障恢复能力衡量的是异常发生后能否继续完成正确的任务。
二、MCP 与 CLI 的差异来自执行组织方式
Playwright MCP 通过工具接口向 Agent 提供浏览器操作能力。Agent 可以调用 browser_snapshot、browser_click 等工具完成页面交互。
Playwright CLI 则通过命令行执行操作，Skills 为 Agent 提供操作规范、调试方法和工作流程。
两者都具备页面快照、网络请求检查和 Mock 能力。
对比维度
MCP
CLI + Skills
工具调用
MCP 协议接口
命令行
页面状态
工具返回页面信息
快照文件及命令结果
故障分析
多轮工具调用
命令组合与脚本分析
恢复策略
Agent 或编排层控制
Agent、Skills 或脚本控制
例如，元素定位失败后，MCP 可以重新调用页面快照工具，CLI 可以重新执行 snapshot 并查找元素。
这两种方案都需要 Agent 判断下一步。
因此，不能简单认定某种方案天然更稳定。模型能力、上下文管理和重试策略都会影响执行结果。
三、故障恢复需要一个明确的状态机
在工程实践中，可以将恢复过程划分为四个阶段：
故障检测、故障分类、策略执行、结果验证。
图 1：Agent 故障恢复状态机
这里需要特别处理重试边界。
例如，订单查询属于读取操作，通常可以在限定次数内重试。
但创建订单属于写入操作。请求超时可能发生在服务器已经创建订单、客户端尚未收到响应的时候。
如果 Agent 直接重新提交，就可能产生重复订单。
所以恢复策略必须结合请求幂等性、业务状态和最大重试次数。
Agent 能重新执行操作，不代表它有权重复执行业务操作。
四、如何完成一次故障注入评测？
以订单查询接口返回 503 为例。
实验设计为：前两次查询返回 503，第三次恢复正常，观察 Agent 能否识别异常并完成查询。
Playwright CLI 可以通过 run-code 注册条件式网络 Mock：
打开测试会话
playwright-cli open about:blank
开始记录 Trace
playwright-cli tracing-start
前两次请求返回 503
playwright-cli run-code "async page => {
let count = 0;
await page.route('**/api/orders', route =>
++count <= 2
? route.fulfill({ status: 503 })
: route.continue()
);
}"
随后让 Agent 访问实际订单页面并执行查询。可以使用以下命令采集证据：
playwright-cli requests
playwright-cli snapshot
playwright-cli tracing-stop
这段代码适合在可控测试环境中验证恢复流程，实际项目需要调整接口路径。CLI 官方支持通过 run-code 完成条件 Mock。
MCP 可以启用 --caps=network，使用 browser_route 注入固定状态码，再通过网络工具检查结果；如果需要“前两次失败、第三次成功”，可以由独立故障注入服务统一控制。
正式对比时，建议两种方案都使用独立故障注入服务，并保持相同模型、浏览器版本、业务数据和恢复规则。
每种故障至少重复 20 轮，记录以下指标：
评测指标
统计方法
故障识别率
正确识别次数 / 注入次数
自主恢复率
无人工干预且业务断言通过的次数 / 故障执行次数
恢复耗时
从故障被触发到业务验证通过
工具调用次数
恢复阶段新增的调用次数
无效重试次数
未满足重试条件的重复操作
还需要单独统计重复提交、错误断言等业务风险。
本文展示的是可复现的评测设计，并未运行 MCP 与 CLI 的完整对照实验，因此不提供未经实测的性能排名。
五、工程落地要把恢复策略写进执行规则
实际接入项目时，建议先建立故障分类与恢复规则：
接口异常：按状态码、请求类型和幂等性决定是否重试。
元素失效：重新获取页面快照，不直接复用旧引用。
会话中断：尝试恢复认证状态，并重新确认当前业务页面。
断言失败：停止自动恢复，保留 Trace 和业务证据。
对于 CLI + Skills，可以将这些规则写入 Skills，由 Agent 按规则执行。
对于 MCP，可以通过 Agent 编排层实现相同的恢复约束。
还应将恢复记录接入测试报告，包括故障类型、恢复动作、重试次数、最终断言和证据文件。
没有业务断言的恢复，只能证明执行过程继续了，无法证明测试结果正确。
六、AI 自动化测试将从执行能力走向恢复能力
随着 Agent 承担更多测试任务，测试平台会逐步增加执行状态管理、故障分类、恢复策略和结果校验能力。
MCP 与 CLI + Skills 都可以参与这一过程。
不同项目的选择也会不同。探索性测试可能需要更灵活的交互决策，持续集成场景则通常需要稳定的执行规则和可追溯的恢复记录。
无论采用哪种架构，业务断言、幂等性控制和重试边界都不能完全交给模型自由决定。
如果你们团队已经使用 Agent 执行 Web 自动化测试，当接口超时、页面失效或浏览器会话中断时，现在的测试系统能够从故障位置恢复，还是只能从头重新执行？
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
