摘要TRAE Agent公开的方法里一个容易被忽略的变化是系统不再只让模型生成一份补丁而是先制造多个候选经回归过滤后再选择。真正值得测试团队研究的不是榜单名次而是“选择器会不会稳定地选中业务上正确的答案”。这不是“让模型再想一次”TRAE 团队公开的 Agent 方案里有一段很容易被榜单成绩盖过去针对同一个仓库级问题系统可以让不同模型产生多份补丁先用回归测试过滤再由 Selector Agent 做语法聚类、多Agent验证和最终选择。官方文章报告的 75.2% 是 SWE-bench Verified 的实验结果——500个任务中解决376个——它不是企业线上缺陷修复率更不是“交给Agent就能自动发布”的证明。真正值得测试团队关注的是工作方式变了。过去我们面对一份开发提交问题是“这份改动对不对”现在面对几十份机器候选问题变成“选择机制凭什么认定这一份最值得进入主干”。生成能力增加后质量风险没有消失而是从单个补丁扩散到候选生成、过滤、比较和裁决四个环节。同一个测试通过不代表补丁同样好假设支付服务出现一个问题优惠券抵扣后的订单在部分退款时金额计算错误。Coding Agent生成三份补丁A只修正本次计算公式现有回归全部通过B同时调整金额模型和历史兼容逻辑回归通过但改动范围更大C在接口层补了一个条件分支样例通过却让“退款后再次退款”进入错误状态。如果选择器只看“测试是否通过”A、B、C可能没有明显差异如果用代码改动最小作为偏好C甚至更容易获胜。这里的退款例子是基于候选补丁选择机制构造的业务推演并非 TRAE 披露的生产事故。它要说明的是回归集只负责暴露已表达的规则选择器还会继承回归集没有表达的盲区。因此测试团队不能把“多候选投票”理解成可靠性的自然叠加。多个模型可能共享训练语料、提示词、仓库上下文和错误验收标准。五个候选都赞成同一个错误不叫共识只能叫同源共错。把选择器当成新的被测系统TRAE 的公开说明把候选数据组织成 instance_id、issue、patches、success_id 和可选的 regressions选择过程还能按组处理大量候选并选择是否启用 majority voting。这里至少出现四类新的测试对象。第一类是候选多样性。若十个候选只是同一补丁换了变量名数量没有带来新的解空间。可记录 AST 差异、受影响模块、错误处理路径和状态变化而不是只计算文本 diff。第二类是过滤可信度。回归测试通过究竟代表核心规则没被破坏还是只代表旧用例没有覆盖新路径测试集至少应同时包含原缺陷复现、相邻状态、关键不变量和反例。对退款问题不变量包括“累计退款不得超过实付”“成功副作用最多一次”“跨用户订单不可操作”。第三类是选择稳定性。同一批候选改变排列顺序、分组大小或选择模型后赢家是否剧烈变化如果轻微扰动就换答案系统给出的不是可靠选择而是不稳定偏好。第四类是选择后的独立验证。候选生成模型、补丁选择模型和验收模型如果共享上下文与判断框架仍然可能一起错。最终候选进入主干前需要一套不参与生成和投票的业务断言。一组真正承担业务判断的断言下面的示例不是 TRAE 项目代码而是测试团队可在独立验证阶段复用的最小规则。它不判断补丁“长得像不像正确答案”只验证任何候选都不能突破退款不变量。def assert_refund_invariants(before, request, after, events): assert request[user_id] before[owner_id], 禁止跨用户退款 assert 0 request[amount] before[refundable_amount] assert after[refunded_amount] before[refunded_amount] request[amount] assert after[refunded_amount] before[paid_amount] success [e for e in events if e[type] refund_succeeded] assert len(success) 1, 退款副作用必须且只能发生一次 assert success[0][idempotency_key] request[idempotency_key]这段代码的价值不在 pytest 语法而在判断权与生成过程分离。无论候选来自哪个模型、采用何种投票只要越过金额、归属、幂等或状态规则就不能被“多数意见”带进主干。选择机制还要做三组反事实测试第一组删掉关键测试。故意移除“重复退款”用例观察赢家是否从A切到C。若变化明显说明选择器高度依赖某条证据团队应把这条用例标成发布红线而不是让它混在普通回归里。第二组注入诱饵候选。准备一份改动很小、命名漂亮、注释充分但业务错误的补丁。如果选择器频繁偏向它就能发现“代码外观偏好”压过业务正确性。第三组交换上下文。把 issue 描述里的模糊措辞替换为明确验收规则看选择结果是否改变。若明确规则显著改善结果修复重点可能不是换更强模型而是让需求成为可判定的规格。这些测试最后应落在 Trace 里候选由谁生成、通过了哪些回归、被哪条规则淘汰、选择器理由是什么、最终独立门禁是否通过。只保存最终 diff会把最有价值的质量证据全部丢掉。CI里不要把所有候选都跑到最贵多候选会带来直接成本。生成50份补丁、完整构建50次、再让多个Agent交叉验证令牌、沙箱和CI时间都会上涨。更现实的做法是分层快速层格式、编译、静态检查、禁止路径和最小缺陷复现回归层高风险业务不变量、受影响模块和历史缺陷集选择层差异聚类、扰动稳定性、选择理由完整性发布层对最终1—2个候选运行独立全量验证和人工审查。门禁不应只输出 pass/fail还要留下淘汰原因。如果候选都在同一规则上失败说明需要回到需求或上下文如果候选各有不同失败说明生成多样性有效但选择器缺少清晰的风险优先级。测试工程师的新位置不是“替AI收尾”当Coding Agent一次能给出多份可编译、能过一部分测试的补丁测试工作的价值不再只是为最终答案补用例。更上游的任务是设计候选空间如何被比较哪些证据允许淘汰哪些业务不变量拥有一票否决权以及何时必须把选择权交回人。TRAE 的公开实践给出了一个重要信号AI写代码正在从“模型能不能产生答案”走向“系统能不能管理多个答案”。测试团队最值得迁移的能力是把模糊的“这个补丁看起来更好”改造成可重放、可扰动、可审计的选择过程。你可以从一个真实缺陷开始让不同模型各生成3份补丁不急着比较谁修得快先记录它们在哪些规则上被淘汰。完成这一步你搭建的就不再是一次性的AI演示而是一套候选补丁行为回归资产。还要警惕“更会考试”的候选候选补丁系统还有一个反常风险生成器越熟悉公开Benchmark越可能针对测试形状优化而不是针对真实维护性优化。一份补丁可以精确修复可见用例却通过硬编码、吞异常或绕开公共接口获得高分。它在本题上成功进入真实仓库后却留下更难察觉的债务。因此选择器不能只读取测试结果还要检查修复的因果关系。缺陷来自日期边界补丁是否真正修正日期计算还是只为某一天增加特例缺陷来自并发补丁是否建立互斥或幂等还是延长等待时间。测试团队可以要求候选提交“失败原因—修改点—验证证据”三元组再用代码差异和Trace核对解释是否与实际改动一致。可以增加变异测试把补丁声称修复的关键条件轻微反转原用例是否会失败删除补丁中的核心一行缺陷是否重新出现。如果无论怎么变异测试都通过往往说明用例没有真正约束修复机制。候选之间不只比正确率真正进入生产仓库的补丁还要比较维护成本和运行影响。可建立一张选择矩阵维度需要的证据典型淘汰条件业务正确红线断言、状态变化、副作用金额、权限或幂等任一失败回归安全受影响模块与历史缺陷集修好当前问题却破坏相邻流程修改边界diff、依赖变化、公共接口无必要扩大权限或改动范围可维护性根因对应、命名、测试意图硬编码样本、吞掉异常运行代价延迟、资源、外部调用为通过测试引入不可接受成本可恢复性回滚、开关、数据兼容上线后无法安全撤回这张表也能避免选择器偏爱“改动最小”。小diff通常更易审但不是天然更正确涉及数据模型或状态机时一行条件分支可能只是把错误藏得更深。相反大diff也不应因为复杂就直接淘汰关键是它是否有明确必要性和独立证据。Trace要支持复盘选择本身一次候选选择至少保留五组记录原始issue和仓库版本每个候选的生成模型、Prompt和工具轨迹过滤测试及失败原因聚类与投票结果最终门禁和人工决定。模型或测试集升级后可以在同一候选池上重放选择区分“生成变好了”还是“裁判变了”。若只保存赢家团队会失去最有价值的反例。落选候选告诉你哪些错误最容易重复、哪些用例具有区分度、选择器偏爱什么表面特征。它们适合成为后续回归集的困难样本而不是运行结束后立即删除。小团队怎么从零开始第一周不必构建复杂Selector Agent。选一个已经修复且有明确根因的历史缺陷隐藏正式补丁让两种模型各生成三份候选用现有测试过滤并由两名工程师独立排序。比较机器与人工排序分歧记录分歧来自业务规则、改动范围还是维护性。第二周加入一组独立红线断言和一个诱饵补丁观察排序是否改变。第三周再做顺序扰动与分组扰动把不稳定选择标记为需要人工复核。只有当团队能解释“为什么选它、为什么不选其余候选”才考虑提高自动化程度。这条路线不会立刻带来漂亮的自动修复数字却会积累一套更难被榜单替代的能力测试团队知道怎样把多个看似正确的答案压到同一把业务尺子上。
