一个真实的“AI压测翻车”复盘血的教训换来的8条铁律2026年7月16日上午10:23。我盯着Grafana面板上那条直线往下砸的CPU曲线手里的美式咖啡差点洒在键盘上。“所有服务全部超时登录和支付模块同时挂了。”运维老张在群里艾特我的时候我正悠哉悠哉地看昨天跑完的自动化测试报告。我心里还想着这AI Agent真他娘的好用一晚上把回归用例全跑完了还顺手帮我生成了测试数据。然后我就笑不出来了。故障持续了整整7个小时。原因我让AI同时测了登录和支付。今天这篇文章我不跟你扯什么高大上的“AI驱动测试”、“智能体工作流”。我就老老实实复盘一下我是怎么把公司服务器搞崩的以及你该怎么避免踩这个坑。先说结论你可能不信很多人觉得AI跑测试无非就是替代手工点鼠标或者替代写代码。大错特错。AI Agent跑测试相当于你同时雇了100个刚毕业的实习生而且这100个人完全不沟通各干各的还都觉得自己特别聪明。我这次翻车就是栽在这三个字上并发、数据、锁。事情是怎么发生的我们团队上个月刚把WorkBuddy和Hermes Agent接进来。说实话一开始确实爽。你只要说一句“帮我测一下登录功能”WorkBuddy就会调起Hermes Agent自动拆解任务、生成用例、执行脚本、输出报告。我这种干了七八年测试的老油条头一回觉得“明天可能要失业”。然后就飘了。那天我寻思着既然登录能测支付也能测那为什么不一起测呢我对着WorkBuddy说了一句“帮我并行执行登录模块和支付模块的全量回归测试越快越好。”AI很听话。太听话了。翻车全过程复盘第一阶段蜜糖期上午10:00-10:15AI同时起了20个并发线程跑登录又起了20个并发线程跑支付。登录和支付共用一套用户体系这是第一个雷。AI很聪明地自动生成了1000个测试账号然后用这些账号同时去做两件事登录用例里登录、登出、刷新token支付用例里下单、支付、查询订单问题出在哪登录用例跑完一个账号会把这个账号的token刷新一遍。支付用例跑着跑着突然发现token失效了于是自动重试登录。重试登录又触发了登录模块的防暴力破解机制——同一个IP一秒钟发了200次登录请求。WAF直接给我封了。第二阶段崩溃期上午10:16-10:30WAF封禁的瞬间登录模块开始返回503。AI检测到异常自动启动了“重试降级”策略——这是Hermes内置的容错机制本来是好事。但它降级的方式是用更短的间隔重试。好家伙本来一秒200次现在一秒冲进去500次。同时支付模块里的订单状态机被搞乱了。一个账号在10秒内同时发起了3笔支付但登录token已经被刷新了两次导致支付回调的时候带的是旧token。订单系统的分布式锁直接被打爆。Redis连接数飙升到8000连接池耗尽。然后就是连锁反应支付挂了 → 订单回调超时 → 消息队列积压 → 消费者线程全被阻塞 → 应用服务器线程池满 → 健康检查失败 → K8s自动重启PodPod刚起来又被AI的流量冲垮。一天重启了47次。第三阶段排查期上午10:30-下午2:00这期间我干了三件事先停了所有AI测试任务——结果发现停不掉因为任务已经下发到Hermes的执行队列里了WorkBuddy只是下发指令的不负责中断。手动把Hermes的进程kill了——世界安静了。开始看日志。日志里最扎眼的一条[WARN] Hermes Agent: Task “login_regression” and “payment_regression”share same test data pool. Potential data contention detected.AI自己都检测到数据竞争了但它没有停下来而是选择“尽力执行”。这不能怪AI。是我给它配的Prompt里有这么一句“遇到问题时尝试自动修复并继续执行。”“自动修复”的意思是——绕过问题而不是解决问题。于是AI的“修复”方案是跳过token校验直接用session_id硬怼。结果就是一堆脏数据写进了订单表。技术深挖为什么登录和支付不能一起测你可能觉得不就是两个模块并行跑吗Jenkins上不也经常并行跑任务区别在于AI是“自适应”的。普通的自动化脚本每一步都是写死的。登录脚本就是登录脚本支付脚本就是支付脚本它们不会“越界”。但AI Agent会。Hermes在执行支付用例时发现token过期它会自动生成一段代码去重新获取token。获取完token之后它还会“好心”地把这个新token更新到公共数据池里方便其他任务复用。问题来了登录模块那边正在用旧token跑用例突然发现数据池里的token变了于是它也自动去刷新了一遍。两个Agent在互相抢数据池的控制权。这就像两个人在同一个白板上写字A写了1B擦掉改成2A发现不对又改回1B又改回2……最终结果是白板花了谁都看不清。我是怎么解决的临时方案下午2点我做了这几个操作数据池隔离给登录和支付各自分配独立的测试数据池账号不共用。登录用账号段10001-11000支付用20001-21000。关闭AI的自动修复能力在WorkBuddy的Prompt里加了硬约束“检测到异常时立即暂停任务并通知人工禁止自动重试。”限流在API网关层对测试流量做了限流测试来源IP每秒最多100个请求超过的直接返回429。手动清理脏数据写了条SQL把订单表里今天10点以后status0且金额为0的记录全删了——一共删了3700多条。做完这些服务在下午2:30左右恢复。但彻底恢复稳定一直等到下午5点多——因为消息队列里的积压消息消费者跑了将近3个小时才消化完。复盘8条血的教训这次事故之后我给自己和团队立了8条规矩。希望你用不上但最好存一下永远不要让AI同时操作“共享状态”的模块登录和支付共用了用户token这就是共享状态。共享状态必须有隔离否则AI的“智能”会放大冲突。做法每个测试任务分配独立的数据空间互不干扰。AI的“自动修复”能力要分级开放不是所有场景都适合自动修复。我现在的分级网络超时 → 允许重试最多3次数据异常 → 立即暂停通知人工接口报错 → 记录日志继续执行其他用例性能瓶颈 → 自动降级降低并发数3. 测试数据要“染色”每个AI生成的测试数据都要带上任务ID的标签。这样出问题了能快速定位是哪条指令产生的数据也方便回滚清理。AI测试任务必须有“熔断器”我现在的配置错误率超过10% → 自动暂停单接口响应时间超过3秒 → 自动降并发Pod重启超过3次/10分钟 → 全局暂停所有AI任务5. 永远保留“手动kill”的通道WorkBuddy和Hermes再方便也要有一个不依赖任何AI组件的紧急停机按钮。我现在的方案是写了一个Shell脚本放在跳板机上执行就是pkill -f hermes简单粗暴但有效。压测环境和生产环境必须彻底隔离这次最惊险的是——测试流量差点打穿了生产环境的Redis因为测试环境的Redis和生产共用了一个实例只是DB不同。现在我已经把测试环境的Redis、MySQL、MQ全部独立部署连网络都做了VPC隔离。AI生成的测试代码要经过“静态审查”我加了一条规矩所有AI生成的测试脚本在正式执行前必须先过我的人工审查。不追求100%覆盖但至少要看一眼它要调用哪些接口、生成多少数据、并发度是多少。这次教训是我没看就让它跑了。给AI设置“业务安全边界”有些操作AI永远不能做不能调用真实的支付接口只能用Mock不能往生产库写数据不能修改线上配置不能发真实的短信/邮件这些我现在写进了WorkBuddy的System Prompt里硬约束。最后说几句心里话我不是来黑AI的。恰恰相反我现在依然每天在用WorkBuddy和Hermes。它们帮我节省的时间比我手动写脚本不知道快了多少倍。但工具越强使用工具的人责任越大。AI Agent不是魔法棒。它不会自动理解“登录和支付共用一个token池会死锁”这种业务层面的隐式约束。它会做的事情是你让它做什么它就拼尽全力去做哪怕是把你服务器搞崩。所以关键不在于要不要用AI而在于——你怎么给它画边界怎么给它设规矩怎么在它失控的时候能一秒摁住它。这就是我们这一代测试开发工程师的新课题。别让你的AI成为下一个“把服务器搞宕机一整天的凶手”。这是我的真实经历改编。如果你也在用AI Agent做测试自动化欢迎加我微信一起交流踩坑经验。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。