实测分享把多Agent流水线砍成1个长上下文Agent用例生成快了9倍便宜了6.7倍背景我们那条AI生成E2E用例的流水线是去年底搭的当时用Opus 4.5。跑得通但死慢一个页面探索完上下文就快满了只能handoff给下一个Agent审查审查完再handoff回去改。一条用例来回三个人接力接力棒还越传越短。上周看到Checksum10月1日公开了重构过程一句话点醒我为模型短板搭的架构等短板没了就是负债。我照着拆了一遍自己的流水线效果比预期好。操作步骤第一步先量出接力损耗。别急着改先在CI里记日志每个Agent的输入输出token、handoff文档字数。我们跑一周一条用例平均3.2次handoffhandoff文档合计约1.1万token——其中90%是上一个Agent已知的东西。第二步把多Agent合并成1个。前提是模型上下文够大。我们换到百万级上下文的模型把探索→写用例→自修塞进同一个Agent。判断标准很简单同一份上下文能不能装下需求页面结构已写用例失败trace能就别拆。第三步把确定性的活儿踢出Agent。最关键也最容易被忽略。跑测试流程固定让Agent跑好了浪费token坏了是它敲错命令。我们抽给一个Python服务Agent只产出脚本服务层负责打标、起隔离环境、执行、回传trace。Agent只做需要判断的事。第四步给失败加一次自修。测试挂了trace回传Agent它要先判断是应用挂了还是用例写错了。是用例的错就改改完回服务层重跑是应用的错就直接报缺陷。第五步加记忆别每次从零写。把跑通的浏览器操作代码存起来下次遇到语义相似的一步哪怕措辞不同直接复用跑挂的标记失效、不再信任。同一个点击第一次要模型现写第一百次就不该再花钱。踩坑记录别为了长上下文而长上下文。合并不是目的。如果你的链路本身就是多角色分工比如一个人写、一个人专门审硬合并反而丢掉了审查独立性得不偿失。长上下文≠不看token。1M窗口不等于免费。Checksum重构后单条用例成本降6.7倍很大一部分来自少了3.2次handoff的系统提示重复计费不是模型变便宜了。自修必须设上限。一次就够。让它反复我觉得我修好了你会看到同一段代码被改五版。Checksum是失败回传一次不再自修就升级给人。记忆要有失效机制。应用改版后昨天跑通的代码今天是错的。我们给每个记忆条目挂了页面快照hash对不上就作废重写。别让Agent自己判断该不该跑测试。它会挑简单的跑。执行范围要由服务层的配置决定。效果对比维度多Agent流水线单长上下文Agent一条用例生成耗时基准快约9倍单条用例成本基准降约6.7倍handoff次数平均3.2次0失败处理人工看日志trace回传自动判因维护成本改一个Agent要顺一遍链路单点9倍/6.7倍是Checksum内部基准的数字我们的体量小实测约7倍方向一致。总结AI测试这一年的架构其实在经历一次还债去年大家为了绕开模型短板拆出一堆Agent、写一堆编排逻辑今年模型变强了那些编排全成了累赘。所以别急着上新工具先把自家流水线的设计假设拿出来重读一遍——哪些是为2024年的模型写的今天还成立吗该拆的拆该并的并。你们团队开始用AI做测试了吗欢迎评论区聊聊。