本页是一次课堂模拟演练：让多个 Agent 围绕同一开发任务分工协作，把各自产生的候选修改统一送入自动化测试与验收网关；只有满足可执行验收标准的修改才能进入历史基线，不合格修改会被拦截并返回可复现反馈。这样做的目标不是让 Agent 互相“讨论出正确”，而是把“协作开发—自动验收—历史继承”的工程闭环跑通。
演练目标
- 理解多 Agent 协作开发中的任务分工、候选修改汇合，以及验收网关对不合格修改的拦截作用。
- 体验用可执行测试和验收条件替代主观审批，观察哪些候选能进入基线、哪些需要重试。
- 比较高阶问题：验收规则是否可复现、反馈是否可行动、误拦截与漏拦截风险、拆解粒度与协作成本。
角色分工与基本流程
可以把课堂小组分成规划/拆解 Agent、实现 Agent、测试生成 Agent、审查/协调 Agent。同一任务允许产生多个候选修改，再由网关统一裁决。
- 任务拆解：把目标拆成可独立验证的子任务，例如“接口校验—算法修复—回归测试”。
- 并行实现：多个实现 Agent 提交候选补丁，测试 Agent 生成边界用例。
- 自动验收：运行自动化测试、静态检查与契约检查，由验收网关按可执行标准判定。
- 历史继承：通过的修改合入历史基线，成为后续 Agent 继续工作的基础；被拒修改保留失败原因与复现信息，用于重试。
验收网关标准
网关的判据必须可执行，不能停留在“看起来正确”。重点拦截不满足接口约定、引入回归、未覆盖边界条件或违反质量约束的修改。一个可用的反馈至少应包含：失败用例、日志、复现步骤、期望行为与相关约束。
历史继承与高阶观察
通过的修改进入基线后，后续 Agent 不必从零开始；被拒修改则成为可检索的负例，避免重复犯错。评估这类协作系统时，要特别关注验收规则是否可复现、反馈是否可行动，以及误拦截与漏拦截带来的不同风险。拆解粒度过细会抬高合并与验收成本，过粗又会让候选修改互相覆盖；更稳的做法是按“可独立验证”的边界拆分。
演练提醒
如果网关缺失或标准模糊，多 Agent 协作可能不会更高效，反而会因为缺少统一裁决而变得混乱。自动化门禁的价值在于用可复现证据替代主观审批。
多 Agent 协作与验收网关演练
该演练图把规划拆解、实现、测试生成与审查协调等角色并行产出的候选补丁，统一送入自动化测试与验收网关裁决。满足可执行标准的修改合入历史基线供后续 Agent 继承，被拒修改保留失败用例、日志与复现步骤，作为可检索负例用于重试，从而用可复现证据替代主观审批。
多 Agent 协作与验收网关演练
该演练图把规划拆解、实现、测试生成与审查协调等角色并行产出的候选补丁，统一送入自动化测试与验收网关裁决。满足可执行标准的修改合入历史基线供后续 Agent 继承，被拒修改保留失败用例、日志与复现步骤，作为可检索负例用于重试，从而用可复现证据替代主观审批。
