 
> **一句话定位**：这不是"哪个 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、等跨模块联调、等发布窗口。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/b96353bbd0f857281ffb403150999c23.png)

这组数字来自阿里云社区 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 个角色的交接链画成泳道，重点关注一件事：证据在哪几个交接点会被丢。


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/6ce9f5fd7aeb8f23856b01b55199205f.png)


### 实现与验证必须换人，这条不能让

原文在总结实践经验时写了两条，第二条是"实现和验证由不同的 Agent 承担，让验证有独立视角"。第一条是"跨轮次保留必要的上下文"。

这一条在测试行业里是老原则（四眼原则、开发不测自己的代码），但放进 Agent 协作里，它的含义变了：**不是"人"不能自己验，是"上下文"不能自己验。**

同一个 Agent 的实现和验证共享同一个上下文，意味着验证时它已经知道自己是按什么思路写的。这时它写出的断言会自然贴合自己的实现——包括实现里的错误假设。原文在第四个问题里描述的现象正是这个：改一个 Skill，当前用例通过了，另一个用例却回归了。

我建议把这条写进验收清单，作为一个可检查项，而不是原则口号。具体检查方式是：在 trace 里定位"写代码"和"跑验证"两个 Session，看它们是不是同一个，以及验证 Agent 的输入里是否包含了实现 Agent 的完整推理过程。

如果包含了，验证的独立性就被削弱了。可以仍在同一个 Agent 里做，但验证阶段的输入应该被裁到只有 Spec 和产物，不含实现思路。

### 人工闸：不是兜底，是一个有触发条件的状态

原文提到 Leader 要决定三件事：测试不过怎么办、方向错了怎么办、反复不收敛怎么办。答案分别是：回到原来的 Code Session 继续修、带着失败证据重做 Research 和 Explore、**触发 Human Gate 请人给判断**。

第三个是本文认为最值得单独画出来的部分，因为它是一个有明确进入条件的机制，而多数团队把它做成了"出错就找人"。

这两者差别很大。做成"出错就找人"，人工闸会变成日常，人就成了最慢的那个环节。做成"有条件的闸"，它只在特定状态下开，其余时间不打扰人。

原文给的触发条件是"反复尝试仍不收敛"。这在测试上可以翻译成一个可配置的判定：同一任务在同一类失败上重试次数超过 N，或连续两轮验收结论均为不通过，则升级。

下面这张状态机把任务的四种状态和四条跳转画在一起，重点是那条指向"人"的虚线——它只在一种条件下被激活。


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/7d18e6ccbabfebaf5bb87bcdecfcc22b.png)


### 19 道题的成绩单，该怎么读

这是全篇最需要小心的一段数字。

原文的评测构造是：从代码库挑 20 个人类专家的高质量提交，从这些代码**反推出对应的需求**，组成一个 Benchmark；然后让 Agent 团队去做这些任务，把结果和专家实现并排比较，看思路有没有漂、代码有没有问题、验证够不够、分工对不对。

最终验证抽了 19 道题，其中约 10 道产出的实现与专家方案大致相当，另有 5 道接近专家水平。在"限定且约束明确"的场景里，交付周期从约一个月缩到一周以内。

这组数字有三个限定，缺一个就会读错。

第一，**题是从已有代码反推的**。这意味着需求描述与实现之间存在天然的对齐，Agent 拿到的需求比真实需求干净得多。真实需求的模糊度远高于此。

第二，**"大致相当"是作者团队自己的判定**，口径是"思路有没有漂、代码有没有问题、验证够不够"，没有第三方盲评。

第三，**19 道题**是小样本，且来自两个已上线的受限场景（其中之一是把 Trace 数据转成轨迹数据的服务，持续遇到新的解析异常）。

我把它读成：在需求清楚、验收条件可写的场景里，多 Agent 协作已经能做到接近专家的水平；一旦需求模糊，这个成绩不能外推。这个读法对测试团队最有用——它恰好划出了"什么场景可以交给 Agent 跑、什么场景必须人来定验收"。

### 最值得抄的四个问题，其实是四类回归

原文第四节列了四个在真实研发流程里遇到的持久问题，逐个看，每一个都是测试团队熟悉的老朋友的 Agent 版本。

一，需求说清楚了，但架构约束没带过去。原文的例子是想扩展现有 API 的能力，Agent 却选择新加一个 API——单看当前任务更简单，放到系统里不符合设计要求。这对应测试里的**约束校验**：约束不在需求文本里，在代码、文档和人的经验里。

二，真实场景总有想不到的输入。原文举的例子是在外卖应用里问怎么写 Python 程序，这已经超出原本的业务边界。这对应**输入域边界的持续发现**，不是一次性设计得出来的。

三，同一个问题反复出现。经验和没积累一样，Agent 一遍遍掉进同一个坑。这对应**缺陷复发的追踪**。

四，改一处，别处回归。改一个 Skill，当前用例过了，另一条可能坏。这对应**变更影响面分析**。

四个问题里，第四个是唯一有现成工程手段的，也是原文自己点明要"相对稳定的 Benchmark 和回归检查"。这句话可以直接搬进任何团队的 Agent 上线流程：**任何一次 Skill、Tool 或协作流调整，都必须跑同一套固定题集。**

四个问题按"能否在离线复现"和"是否需要在真实流量里发现"两个维度定位，用气泡大小表示它对交付周期的实际影响（大小为本文字数估计，非原文数据）。


![](https://developer.qcloudimg.com/http-save/yehe-9678105/455ec530c5275b199efd95d239524b98.png)


### 三个可以直接写进验收单的检查项

从这套实践里，我挑三件成本最低、收益最直接的事。

其一，**交付物清单里加 trace**。不是"建议留存"，是"缺了不算交付"。理由前面说过：没有 trace，你无法区分"实现符合 Spec"和"实现恰好过了那个测试"。

其二，**验证 Agent 的输入做裁剪**。把实现推理从验证上下文里摘掉，只给 Spec 和产物。不改架构，改的是喂进去的字段。

其三，**固定题集先行**。在接入任何 Agent 改动之前，先把 10 到 20 条覆盖主要路径的题固化下来，每次调整都跑。原文用的是 20 个专家提交反推的题，你可以用自己仓库里最近一年被 review 打回过的高质量提交反推。

这三件事加起来大概一两天工作量，能挡住的问题是同一类：**不知道该相信哪一个 Agent 的结论。**

>本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。

一句话定位：这不是"哪个 Agent 写代码更强"，而是"一个任务在七八个 Agent 之间转手之后，验收证据还能不能对上"——被测对象是交接链路上的证据完整性，不是单点的代码质量。同样的断言可迁移到多角色审批、客服工单跨组流转、订单履约分仓拆单、发布审批多级会签。

阿里云把 15 个 Agent 编成一个研发小组：19 道题里只有 10 道追平专家

人工智能

测试

架构设计

多Agent协作的验收关键在交接处证据完整性，而非单点代码质量。阿里云实践揭示15角色协作流中，TestHarness、JudgeVerify、Deploy三角色产出可复现证据链。核心约束：实现与验证必须由不同Agent承担，验证上下文应裁剪至仅含Spec和产物。人工闸仅在"反复不收敛"时触发，四类持久问题中回归测试有现成工程手段，需固定题集支撑。

软件测试

客服工单

Python

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

多Agent协作的验收关键在交接处证据完整性，而非单点代码质量。阿里云实践揭示15角色协作流中，TestHarness、JudgeVerify、Deploy三角色产出可复现证据链。核心约束：实现与验证必须由不同Agent承担，验证上下文应裁剪至仅含Spec和产物。人工闸仅在"反复不收敛"时触发，四类持久问题中回归测试有...

阿里云把 15 个 Agent 编成一个研发小组：19 道题里只有 10 道追平专家-腾讯云开发者社区-腾讯云

阿里云把 15 个 Agent 编成一个研发小组：19 道题里只有 10 道追平专家

阿里云把 15 个 Agent 编成一个研发小组：19 道题里只有 10 道追平专家

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐