Playwright MCP混沌工程实战：构建坚不可摧的Web自动化系统

做AI驱动的Web自动化做了几年，最让我睡不着觉的不是功能bug，而是自动化系统在自己的生产环境里突然崩掉。一个Playwright脚本今天跑得好好的，明天同一台机器上就超时；一个看似简单的MCP工具调用，碰上第三方接口抖动，能把整条业务链路带崩。后来我把混沌工程的方法搬进来，主动给系统制造故障，才算真正理解了什么叫“坚不可摧”。

这篇东西核心说的是：如何把Playwright MCP这套技术栈，从“能跑自动化”升级成“扛得住混乱的自动化系统”。包括混沌工程怎么跟浏览器自动化合体、故障注入的几种实操玩法、重试退避与熔断降级的落地方式，以及我在模拟项目里踩过的一堆坑。适合正在用Playwright做AI Agent、自动化测试、数据采集，又被稳定性问题折磨的开发者。内容不写教科书，全部按我实际操作时的心路历程来。

1. 为什么Web自动化必须谈“韧性工程”

先别急着写代码。我见过太多团队，自动化用例全绿，但一到真实环境就甩锅给“网络波动”“页面改版”“第三方不稳定”。这不是某个工具的问题，而是我们一直把自动化当成“脚本执行”，没当成“分布式系统工程”来对待。

1.1 一次“全绿但脆弱”的教训

之前做过一个模拟项目X，用Playwright MCP给某内部系统的积分商城写了一套自动化兑换流程。本地测试时所有用例都是绿的，上午十点上线，下午两点就开始出问题：商品详情页加载超过了预设的10秒超时、支付接口偶尔返回500、前端一个按钮的class在夜间发版时换了名字。最狠的一次，整个兑换流程卡在“结算中”，因为重试逻辑直接把重复订单提交了。

那时候我才意识到：自动化测试绿，只是说明“简化环境里没炸”。真实世界的Web系统，网络会丢包、后端会限流、前端会改版、浏览器会被内存撑爆。这些不是异常，是常态。与其祈祷别出事，不如主动假设它一定会出事。

1.2 脆弱自动化的六种典型死法

我复盘了那段时间的所有故障，发现死法翻来覆去就那几种：

• 选择器失效：前端工程师把>import random import time max_attempts = 4 base_delay = 1.0 for attempt in range(max_attempts): try: result = submit_order(order_id) return result except Exception as exc: if attempt == max_attempts - 1: raise delay = base_delay * (2 ** attempt) + random.uniform(0, 0.5) time.sleep(delay)

  注意的是，不是所有操作都适合重试。加入购物车这种“新增型”操作，如果重试前没有检查是否已经加入成功，就会产生重复数据。正确姿势是先查购物车状态，确认没有目标商品再重试。

  3.3 等待策略从“时间”转向“状态”

  别再数秒了。这是我在自动化稳定性上最大的转折点。之前脚本里到处都是time.sleep(2)，后来全部改成状态等待：等待某个元素可见、等待某个接口返回、等待某个文本出现。

  在Playwright里，我会尽量使用自动等待API，比如等待元素可交互、等待URL变化、等待选择器附加。如果必须自己写循环，就轮询状态，而不是固定睡死。

  from playwright.sync_api import expect # 等待结算页面的“确认支付”按钮可点击 expect(page.get_by_role("button", name="确认支付")).to_be_visible(timeout=10000)

  判断等待结束的条件，也得和业务挂钩。页面出现“支付成功”文案，比URL变成/success更可靠，因为有的前端路由半天不更新，但文案已经出来了。

  3.4 选择器策略和兜底路径

  我在脆弱自动化里踩过选择器的坑，现在的做法是优先级策略：

  • 第一优先：>async def inject_network_fault(context): await context.route("**/api/payment", lambda route: route.abort()) await context.route("**/api/orders", lambda route: route.fulfill( status=500, content_type="application/json", body="{}", ))

    注意，route.abort()模拟断网和连接被拒；route.fulfill()直接伪造响应。我常用一个“延迟代理”，不真正abort，而是先让请求睡几秒再继续，模拟慢接口。这个玩法对测试等待策略极其有效——你会发现哪些地方还在用固定等待，哪些已经改成状态等待。

    4.2 服务端故障注入：改写响应制造404/429/畸形JSON

    网站后端真出问题时，表现最多的不是断网，而是各种HTTP状态码。混沌实验里我最爱注入429和畸形JSON。

    async def inject_server_faults(context): await context.route("**/api/goods/**", lambda route: route.fulfill( status=429, content_type="application/json", body='{"error": "rate limited"}', )) await context.route("**/api/coupon", lambda route: route.fulfill( status=200, content_type="application/json", body='{"code": 0', # 故意截断的JSON ))

    服务端故障注入的价值在于：它能验证MCP工具拿到非预期响应时，AI Agent这个“大脑”会不会正确处理。如果你的Agent看到429就放弃任务，说明韧性不够；如果它能自动切换备用支付通道或者延迟重试，这套系统才算立住。

    4.3 前端动态故障注入：DOM变化与资源异常

    前端故障没有HTTP层那么明显，但破坏力更大。常见手段有：

    • 删除某个按钮的>async def inject_dom_faults(page): await page.evaluate(""" () => { const btn = document.querySelector('[data-testid="checkout-btn"]'); if (btn) btn.removeAttribute('data-testid'); const overlay = document.createElement('div'); overlay.id = 'chaos-overlay'; overlay.style.position = 'fixed'; overlay.style.top = '0'; overlay.style.left = '0'; overlay.style.width = '100%'; overlay.style.height = '100%'; overlay.style.zIndex = '99999'; overlay.style.background = 'rgba(0,0,0,0.5)'; document.body.appendChild(overlay); } """)

      这种故障注入最贴近真实环境。页面结构变了、文案变了、被抢焦点，自动化脚本还能不能识别当前状态，全靠之前设计的选择器策略和状态验证逻辑。

      4.4 系统级故障：CPU、内存与页面崩溃

      浏览器自动化最容易被忽视的故障是资源枯竭。我在模拟项目里试过同时开多个上下文，结果内存涨到2GB，整个系统像死了一样。

      注入方法也很简单：用页面脚本跑一个高占用的循环，模拟CPU打满；或者干脆page.close()模拟页面崩溃，再验证系统能不能重新拉起一个新的浏览器上下文。

      async def inject_cpu_pressure(page): await page.evaluate(""" () => { const end = performance.now() + 5000; let x = 0; while (performance.now() < end) { x += Math.random(); } } """)

      系统级故障通常比接口故障危害更大，因为它会拖垮整个MCP Server进程。这个时候，成熟的做法是给浏览器进程加健康检查：周期性发送一个探活请求，连续失败就重启BrowserContext，而不是让整个队列卡死。

      4.5 把混沌实验写成可重复的演练脚本

      一次两次手动注入故障只能叫“测试”，只有把故障场景固化下来，可重复执行，才配叫“混沌实验”。我通常用一张计划表描述每次实验的参数：

      实验编号	故障类型	注入目标	持续时间	期望表现
      EXP-001	网络延迟5000ms	支付接口	30秒	交易不重复提交，最终成功
      EXP-002	返回429	商品列表接口	15秒	重试退避，自动恢复
      EXP-003	删除data-testid	结算按钮	10分钟	选择器降级成功
      EXP-004	CPU打满	整个页面	10秒	操作等待超时后自行恢复

      每次实验结束后，系统要自动收集日志、断言结果和关键指标，比如“是否完成兑换”“平均耗时”“重试次数”。如果一套实验跑下来，所有预期表现都能满足，自动化系统才算真的抗造。

      5. 故障响应链的落地：重试、降级、熔断与恢复

      混沌实验会不停暴露问题，但暴露问题后系统必须能自我恢复。这一节讲我把故障响应链拆成了哪几个部分。

      5.1 给所有MCP操作包上一层统一封装

      不管直接调Playwright API还是走MCP工具，我都会用一个自动化操作包装函数，统一处理超时、重试、日志和异常分类。

      class ResilientAction: def __init__(self, max_attempts=3, max_retry_time=15): self.max_attempts = max_attempts def execute(self, action, verify=None, fallback=None): last_error = None for attempt in range(self.max_attempts): try: result = action() if verify and not verify(result): raise AssertionError("action verification failed") return result except Exception as exc: last_error = exc if fallback: result = fallback() if verify and verify(result): return result time.sleep(self._backoff(attempt)) raise last_error

      这个封装看起来简单，但它解决了最核心的问题：MCP工具调用本身只返回“执行成功”，不代表“业务目标达成”。我要求所有操作必须带verify回调，用来确认点击是否真的生效、表单是否真的提交。

      5.2 断路器和阈值设计

      重试不是万能的，如果接口连续失败，必须熔断，否则整个系统会陷入无意义的循环。我参照微服务里的断路器模式，给自动化流程加了三个状态：关闭、打开、半开。

      • 连续失败超过3次，熔断器打开，直接跳过该步骤，进入降级路径
      • 熔断后冷却10秒，进入半开状态，放少量请求探活
      • 探活成功，熔断器关闭，恢复完整流程

      在Python里用一个简单类就能实现：

      class CircuitBreaker: def __init__(self, threshold=3, cooldown=10): self.threshold = threshold self.cooldown = cooldown self.failures = 0 self.state = "closed" self.last_failure_time = 0 def call(self, func): if self.state == "open": if time.time() - self.last_failure_time > self.cooldown: self.state = "half_open" else: raise RuntimeError("circuit breaker open") try: result = func() self.failures = 0 self.state = "closed" return result except Exception as exc: self.failures += 1 self.last_failure_time = time.time() if self.failures >= self.threshold: self.state = "open" raise exc

      熔断的意义不是“让操作失败”，而是“快速失败并让系统有机会恢复”。我在积分商城的演练里，支付接口连续失败三次后，系统直接放弃自动支付，改为记录订单号并转入人工审核队列，这就是一个典型的降级策略。

      5.3 可观测性与混沌实验的判断依据

      混沌实验如果看不到任何指标，等于白做。我给每个自动化操作都加了日志和指标收集：

      • 操作类型、开始时间、结束时间、耗时
      • 重试次数、失败原因、是否走了降级路径
      • 当前浏览器实例的内存占用和页面加载性能数据

      有了这些数据，我才能判断韧性策略是“假成功”还是“真恢复”。比如接口返回200但页面渲染失败，这种“假成功”最坑人，必须靠页面关键状态断言来兜底。

      5.4 会话与页面状态的自愈

      最后一块是状态恢复。自动化跑久了，登录态过期、页面缓存膨胀、路由栈错乱，都是常态。我的自愈策略分三层：

      1. 页面级：检测到关键元素消失或错误弹窗，先刷新页面，再等待状态恢复
      2. 会话级：检测到登录态失效，自动跳转登录页，填入凭证，重新进入目标页
      3. 流程级：检测到业务状态异常，比如购物车为空，回到上一步重建数据

      自愈逻辑让系统不再是“一次性的脚本”，而像是有人盯着运行的自动化运维链路。

      6. 实战录像：一个购物支付流程的混沌演练

      理论说太多，不如直接看一场演练。我用积分商城兑换流程做了一次完整实验，下面是我记录的现场情况。

      6.1 故障场景配置

      这次混沌实验我配置了两个故障同时注入：

      • 支付接口：30%概率返回500，20%概率延迟8秒
      • 商品详情页：50%概率移除“加入购物车”按钮的>