4 小时压到 35 分钟：通用 Agent 框架落进测试的三道坎

昨晚十一点，你刚准备下班，群里弹出一条「移动端回归还没跑完」。你心里算的是这一版要熬到几点，以及明天早会怎么交代进度。这押上的不只是今晚的休息，更是版本上线延期的风险——一旦回归卡住，发布就只能往后拖。明明脚本都写好了，为什么一跑就是四五个小时？问题往往不在「写没写脚本」，而在「谁来调度这些脚本」。 一、发生了什么：从手写脚本到结构化调度 最近半年，通用 Agent 框架开始往测试场景里沉。我们组三个测试同学，原来把核心回归全靠手工串脚本，一轮要卡在 4 个小时左右。后来接了一层自研的 Agent 调度，把零散脚本整成可复用的结构，同样的用例集稳定压到了 35 分钟上下。 差距不是算力，是「调度」把一次性劳动变成了可继承的资产。这也是为什么越来越多团队喊着「上 Agent」，跑起来却更慢——它们缺的不是模型，而是把模型接进真实测试流程的那层工程化。模型负责「写」，工程化负责「跑得稳、查得清」。少了这层，Agent 写得再快，也只是在更快地生产会崩的脚本。换句话说，工程化不是给测试加智能，而是给智能一条能落地的轨道。 二、为什么多数人会误判：把「自动化」当成「无人化」 顺着上面的事往下想，最常见的坑是：以为上了 Agent，测试就自己跑、人能撤了。现实是 Agent 花大把时间生成脚本，你反而要多花时间修那些因弹窗、弱网、权限而失败的边缘用例。 根子在于，大家把「自动化」当成了「无人化」，忘了屏幕交互天生不确定。通知、权限请求、网络切换随时插进来，脚本一旦写死步骤，就会在无效路径上反复空转。你投入的时间成本，往往不是在「运行测试」，而是在「修补测试」——这部分最容易被低估，却最拖进度。一个具体例子：有次发版前，一条支付回归因为权限弹窗被顺手点掉，静默失败，直到上线后用户投诉才暴露。如果当时把「授权通过」写成状态，系统会在状态没达成时立刻报警，而不是把失败藏进日志里。 三、拆解：工程化落地的三道坎 第一坎：场景先定义成「状态」，不是「步骤」。 别写「点登录按钮」，改成「在当前角色下达成『已登录且可见首页』这一状态」。失败了系统能告诉你卡在状态还是路径，排查从小时级压到分钟级。这一步不改，Agent 再能写脚本也只是更快地写出会崩的脚本。 第二坎：复用层要单独建。 把「登录态保持」封装成一个基础模块，新功能直接继承，别每次重写。边际成本才能往下走。复用是降低维护成本的核心——同一个逻辑只在一处迭代，所有用例同步受益。 第三坎：调度和执行解耦。 调度层只管「下一步调哪个动作」，执行层只管屏幕交互稳不稳。两者分开，你才能单独优化抗干扰能力，比如适配不同分辨率的手机，而不必重写整套测试逻辑。最终那个 35 分钟的稳定结果，正是建立在两者清晰边界之上。这三点，正是《AI 测试自动化实战》这一系列想掰开讲清楚的工程化落地。这也解释了为什么不少人接了 Agent 反而更慢——他们只加了执行，没补调度。 四、今晚就能做的两件事 不要等组建大团队才开始反思自动化策略。你可以今晚就动手： 1、把你最常被弹窗打断的那条用例，改成「状态声明」写法，先跑通一条，感受排查时间的变化。 2、把「登录态保持」抽成一个公共模块，明天的新用例直接复用，先关掉那些重复造轮子的旧脚本。 先关掉重复造轮子的旧脚本，再导入结构化的调度层——这一步不做，Agent 接得再多也是空转。把框架真正落进测试工程，靠的不是堆工具，而是把边界条件先想清楚。今晚少熬这一夜，从把一条用例写「对」开始。工具是杠杆，支点在你的流程设计上；先把支点找准，再谈放大。