一句话定位：这不是"哪个 Agent 写代码更强"，而是"一个任务在七八个 Agent 之间转手之后，验收证据还能不能对上"——被测对象是交接链路上的证据完整性，不是单点的代码质量。同样的断言可迁移到多角色审批、客服工单跨组流转、订单履约分仓拆单、发布审批多级会签。
摘要
阿里云社区 11 月 6 日公开了一套多 Agent 研发小组的工程实践：15 个角色，Leader 调度，最终交付除代码和 PR 还包括测试报告、审查证据、阻塞信息与完整运行 trace。最值得测试团队抄的不是"15 个 Agent"，而是它列出的四个持久问题，尤其是第四个——改一个 Skill，当前用例过了，另一条悄悄回归。这篇把这份实践拆成可执行的验收设计：交接处要留什么证据、人工闸该在哪一层触发、以及为什么"实现与验证必须由不同 Agent 承担"是一条不该让步的设计约束。
一个复杂需求从提出到上线大约 20 个工作日，写代码占其中 2 天。假设 Coding Agent 让写代码快 10 倍，2 天变成 0.2 天，整个交付周期从 20 天变成 18.2 天。
省了 1.8 天。剩下 18 天干什么去了？等需求确认、等 Spec 对齐、等测试、等 Review、等跨模块联调、等发布窗口。
这组数字来自阿里云社区 2026 年 11 月 6 日的一篇工程实践文章。作者用这组粗估说明一件事：编码加速到某个点之后，瓶颈就不在编码上了。 他们的做法是把其余环节也交给 Agent，用 15 个角色编成一个研发小组，让任务从需求一路推到可验证的交付。
15 个角色里，跟测试团队直接相关的是三个：Test / Harness 负责编译、测试和端到端验证，产出可复现的测试证据；Judge / Verify 负责独立挑选最优方案、做语义验收和对抗式审查；Deploy 负责环境准备与发布验证，产出发布与回滚证据。
这篇文章不讨论"15 个 Agent 是不是太多了"。它要解决的是：如果你接手一套多角色协作的研发流，验收该盯哪里。
交接处最容易掉的，不是代码，是证据
原文有一句我认为应当被当作设计原则抄下来：最终的交付物除了代码和 PR，还包括测试报告、审查证据、进度、阻塞信息和完整的运行 trace。
这句话的测试含义是：验收对象从"产物"扩展到了"产物＋过程"。
单 Agent 的时候，你审的是 diff。多 Agent 之后，一个 diff 背后可能经过 Research（查清相关模块与历史变更）、Explorer（找同构实现形成候选方案）、Spec（定目标和验收条件）、Code Worker（实现）、Test（验证）、Judge（挑选与对抗审查）六道手。
如果中间某一道的证据没留下来，验收时你就无法判断：这个 diff 是"实现符合 Spec"，还是"实现恰好跑通了那个测试"。这两件事在结果上看起来一样。
下面这张图把 15 个角色的交接链画成泳道，重点关注一件事：证据在哪几个交接点会被丢。
实现与验证必须换人，这条不能让
原文在总结实践经验时写了两条，第二条是"实现和验证由不同的 Agent 承担，让验证有独立视角"。第一条是"跨轮次保留必要的上下文"。
这一条在测试行业里是老原则（四眼原则、开发不测自己的代码），但放进 Agent 协作里，它的含义变了：不是"人"不能自己验，是"上下文"不能自己验。
同一个 Agent 的实现和验证共享同一个上下文，意味着验证时它已经知道自己是按什么思路写的。这时它写出的断言会自然贴合自己的实现——包括实现里的错误假设。原文在第四个问题里描述的现象正是这个：改一个 Skill，当前用例通过了，另一个用例却回归了。
我建议把这条写进验收清单，作为一个可检查项，而不是原则口号。具体检查方式是：在 trace 里定位"写代码"和"跑验证"两个 Session，看它们是不是同一个，以及验证 Agent 的输入里是否包含了实现 Agent 的完整推理过程。
如果包含了，验证的独立性就被削弱了。可以仍在同一个 Agent 里做，但验证阶段的输入应该被裁到只有 Spec 和产物，不含实现思路。
人工闸：不是兜底，是一个有触发条件的状态
原文提到 Leader 要决定三件事：测试不过怎么办、方向错了怎么办、反复不收敛怎么办。答案分别是：回到原来的 Code Session 继续修、带着失败证据重做 Research 和 Explore、触发 Human Gate 请人给判断。
第三个是本文认为最值得单独画出来的部分，因为它是一个有明确进入条件的机制，而多数团队把它做成了"出错就找人"。
这两者差别很大。做成"出错就找人"，人工闸会变成日常，人就成了最慢的那个环节。做成"有条件的闸"，它只在特定状态下开，其余时间不打扰人。
原文给的触发条件是"反复尝试仍不收敛"。这在测试上可以翻译成一个可配置的判定：同一任务在同一类失败上重试次数超过 N，或连续两轮验收结论均为不通过，则升级。
下面这张状态机把任务的四种状态和四条跳转画在一起，重点是那条指向"人"的虚线——它只在一种条件下被激活。
19 道题的成绩单，该怎么读
这是全篇最需要小心的一段数字。
原文的评测构造是：从代码库挑 20 个人类专家的高质量提交，从这些代码反推出对应的需求，组成一个 Benchmark；然后让 Agent 团队去做这些任务，把结果和专家实现并排比较，看思路有没有漂、代码有没有问题、验证够不够、分工对不对。
最终验证抽了 19 道题，其中约 10 道产出的实现与专家方案大致相当，另有 5 道接近专家水平。在"限定且约束明确"的场景里，交付周期从约一个月缩到一周以内。
这组数字有三个限定，缺一个就会读错。
第一，题是从已有代码反推的。这意味着需求描述与实现之间存在天然的对齐，Agent 拿到的需求比真实需求干净得多。真实需求的模糊度远高于此。
第二，"大致相当"是作者团队自己的判定，口径是"思路有没有漂、代码有没有问题、验证够不够"，没有第三方盲评。
第三，19 道题是小样本，且来自两个已上线的受限场景（其中之一是把 Trace 数据转成轨迹数据的服务，持续遇到新的解析异常）。
我把它读成：在需求清楚、验收条件可写的场景里，多 Agent 协作已经能做到接近专家的水平；一旦需求模糊，这个成绩不能外推。这个读法对测试团队最有用——它恰好划出了"什么场景可以交给 Agent 跑、什么场景必须人来定验收"。
最值得抄的四个问题，其实是四类回归
原文第四节列了四个在真实研发流程里遇到的持久问题，逐个看，每一个都是测试团队熟悉的老朋友的 Agent 版本。
一，需求说清楚了，但架构约束没带过去。原文的例子是想扩展现有 API 的能力，Agent 却选择新加一个 API——单看当前任务更简单，放到系统里不符合设计要求。这对应测试里的约束校验：约束不在需求文本里，在代码、文档和人的经验里。
二，真实场景总有想不到的输入。原文举的例子是在外卖应用里问怎么写 Python 程序，这已经超出原本的业务边界。这对应输入域边界的持续发现，不是一次性设计得出来的。
三，同一个问题反复出现。经验和没积累一样，Agent 一遍遍掉进同一个坑。这对应缺陷复发的追踪。
四，改一处，别处回归。改一个 Skill，当前用例过了，另一条可能坏。这对应变更影响面分析。
四个问题里，第四个是唯一有现成工程手段的，也是原文自己点明要"相对稳定的 Benchmark 和回归检查"。这句话可以直接搬进任何团队的 Agent 上线流程：任何一次 Skill、Tool 或协作流调整，都必须跑同一套固定题集。
四个问题按"能否在离线复现"和"是否需要在真实流量里发现"两个维度定位，用气泡大小表示它对交付周期的实际影响（大小为本文字数估计，非原文数据）。
三个可以直接写进验收单的检查项
从这套实践里，我挑三件成本最低、收益最直接的事。
其一，交付物清单里加 trace。不是"建议留存"，是"缺了不算交付"。理由前面说过：没有 trace，你无法区分"实现符合 Spec"和"实现恰好过了那个测试"。
其二，验证 Agent 的输入做裁剪。把实现推理从验证上下文里摘掉，只给 Spec 和产物。不改架构，改的是喂进去的字段。
其三，固定题集先行。在接入任何 Agent 改动之前，先把 10 到 20 条覆盖主要路径的题固化下来，每次调整都跑。原文用的是 20 个专家提交反推的题，你可以用自己仓库里最近一年被 review 打回过的高质量提交反推。
这三件事加起来大概一两天工作量，能挡住的问题是同一类：不知道该相信哪一个 Agent 的结论。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
