企业官网建设流程全解析

实测分享：把多Agent流水线砍成1个长上下文Agent，用例生成快了9倍便宜了6.7倍

背景

我们那条"AI生成E2E用例"的流水线是去年底搭的，当时用Opus 4.5。跑得通，但死慢：一个页面探索完上下文就快满了，只能handoff给下一个Agent审查，审查完再handoff回去改。一条用例来回三个人接力，接力棒还越传越短。

上周看到Checksum（10月1日）公开了重构过程，一句话点醒我："为模型短板搭的架构，等短板没了就是负债。"我照着拆了一遍自己的流水线，效果比预期好。

操作步骤

第一步：先量出"接力损耗"。别急着改，先在CI里记日志：每个Agent的输入输出token、handoff文档字数。我们跑一周：一条用例平均3.2次handoff，handoff文档合计约1.1万token——其中90%是上一个Agent已知的东西。

第二步：把多Agent合并成1个。前提是模型上下文够大。我们换到百万级上下文的模型，把"探索→写用例→自修"塞进同一个Agent。判断标准很简单：同一份上下文能不能装下"需求+页面结构+已写用例+失败trace"，能，就别拆。

第三步：把确定性的活儿踢出Agent。最关键也最容易被忽略。跑测试流程固定，让Agent跑，好了浪费token，坏了是它敲错命令。我们抽给一个Python服务：Agent只产出脚本，服务层负责打标、起隔离环境、执行、回传trace。Agent只做需要判断的事。

第四步：给失败加一次自修。测试挂了，trace回传Agent，它要先判断"是应用挂了还是用例写错了"。是用例的错就改，改完回服务层重跑；是应用的错就直接报缺陷。

第五步：加记忆，别每次从零写。把跑通的浏览器操作代码存起来，下次遇到语义相似的一步（哪怕措辞不同）直接复用；跑挂的标记失效、不再信任。同一个点击，第一次要模型现写，第一百次就不该再花钱。

踩坑记录

1. 别为了长上下文而长上下文。合并不是目的。如果你的链路本身就是多角色分工（比如一个人写、一个人专门审），硬合并反而丢掉了审查独立性，得不偿失。
2. 长上下文≠不看token。1M窗口不等于免费。Checksum重构后单条用例成本降6.7倍，很大一部分来自"少了3.2次handoff的系统提示重复计费"，不是模型变便宜了。
3. 自修必须设上限。一次就够。让它反复"我觉得我修好了"，你会看到同一段代码被改五版。Checksum是失败回传一次，不再自修就升级给人。
4. 记忆要有失效机制。应用改版后，昨天跑通的代码今天是错的。我们给每个记忆条目挂了页面快照hash，对不上就作废重写。
5. 别让Agent自己判断"该不该跑测试"。它会挑简单的跑。执行范围要由服务层的配置决定。

效果对比

（9倍/6.7倍是Checksum内部基准的数字，我们的体量小，实测约7倍，方向一致。）

总结

AI测试这一年的架构其实在经历一次"还债"：去年大家为了绕开模型短板，拆出一堆Agent、写一堆编排逻辑；今年模型变强了，那些编排全成了累赘。所以别急着上新工具，先把自家流水线的设计假设拿出来重读一遍——哪些是为2024年的模型写的，今天还成立吗？该拆的拆，该并的并。

你们团队开始用AI做测试了吗？欢迎评论区聊聊。