Sub 模式结合瀑布和敏捷的优势
Sub 模式结合瀑布和敏捷的优势
Sub 模式解决的是“多个子 Agent 如何分工协作”。瀑布和敏捷解决的是“任务如何推进和交付”。
需要先说明：Heicode 的“开发模式团队”一键部署功能里，瀑布和敏捷各对应一个固定角色模板——敏捷 = 产品(planner) + 开发(executor) + 评审(code-reviewer) 共 3 个角色；瀑布 = 分析(analyst) + 架构(architect) + 开发(executor) + 测试(qa-tester) + 评审(code-reviewer) 共 5 个角色，角色和数量都是固定的。本文讨论的是把 Sub 模式（自由组建子 Agent）和瀑布/敏捷的交付节奏结合起来使用，这是在固定模板之外，你可以自行搭建 Sub 团队并按瀑布或敏捷的节奏推进的一种用法，不代表一键部署的固定模板本身可以自由增减角色。
因此，Sub 模式不是瀑布或敏捷的替代品。更准确的理解是：
- 瀑布定义阶段和验收。
- 敏捷定义迭代和反馈。
- Sub 模式提升每个阶段或每轮迭代内部的执行能力。
为什么要把 Sub 和交付流程结合
传统瀑布和敏捷通常依赖人来分工、执行、测试、审查和整理交付物。引入 Sub 模式后，一个任务可以同时唤起多个子 Agent，让不同角色并行处理局部问题。
这样可以带来三个变化：
- 复杂任务不再全部压在一个 Agent 上。
- 执行、审查、测试、部署可以分离。
- 每个阶段或每轮迭代都能形成更完整的证据链。
Sub 加瀑布
瀑布模式强调阶段顺序和正式验收。它适合高风险、强合规、需要审计的任务。
Sub 模式叠加到瀑布中，作用是提升每个阶段内部的处理效率和质量。
工作方式
需求确认
-> Sub：Product Agent 整理范围，Reviewer Agent 检查歧义
-> 方案设计
-> Sub：Architect Agent 设计方案，Reviewer Agent 检查风险，Ops Agent 检查部署影响
-> 实现
-> Sub：Frontend / Backend 分工实现并自测
-> 测试和审查
-> Sub：Reviewer Agent 跑验证并审查 diff
-> 发布审批
-> Ops Agent 准备部署，人工审批后执行主要优势
| 优势 | 说明 |
|---|---|
| 阶段质量更高 | 每个阶段可以由多个专业子 Agent 同时检查，减少遗漏。 |
| 风险更容易前置发现 | 安全、部署、测试可以在方案阶段就介入，而不是发布前才发现问题。 |
| 审查更独立 | 执行子 Agent 和 Reviewer Agent 分离，避免自己审自己。 |
| 交付证据更完整 | 每个阶段都可以沉淀需求、方案、diff、测试、审批和审计记录。 |
| 生产风险更可控 | Sub 可以提升执行效率，但发布仍然由瀑布阶段和人工审批控制。 |
| 责任边界更清楚 | 每个子 Agent 的职责、资源和输出可以绑定到具体阶段。 |
适合场景
- 生产部署。
- 法律和隐私条款发布。
- 安全整改。
- 数据迁移。
- 客户正式交付。
- 主分支合并和版本发布。
控制重点
- 阶段之间不能自动跳过。
- 高危操作必须审批。
- 每个子 Agent 只拿当前阶段需要的权限。
- Reviewer 和执行角色要分离。
- 发布前必须有回滚方案。
- 每个阶段都要留下审计记录。
Sub 加敏捷
敏捷模式强调小步迭代和持续反馈。它适合需求会变化、需要快速验证的任务。
Sub 模式叠加到敏捷中，作用是提升每一轮迭代内部的并行能力。
工作方式
第 1 轮迭代：确定 MVP
-> Sub：Product Agent 整理本轮范围
-> Sub：Frontend / Backend 分工实现
-> Sub：Reviewer Agent 审查结果
-> 本轮验收
第 2 轮迭代：补充功能
-> Sub：继续按本轮目标拆分
-> 本轮验收
第 3 轮迭代：优化体验和上线准备
-> Sub：UI、测试、文档、Ops 分工
-> 准备切换到瀑布发布主要优势
| 优势 | 说明 |
|---|---|
| 每轮交付更快 | 多个子 Agent 可以在同一轮内并行处理产品、前端、后端、测试和审查。 |
| 反馈更容易落地 | 用户反馈可以转成下一轮子任务，而不是打断当前轮。 |
| 范围更容易控制 | 敏捷控制本轮范围，Sub 只在本轮范围内拆分。 |
| MVP 更容易成型 | 第一轮可以快速完成最小闭环，后续再持续补充。 |
| 质量不牺牲 | 即使节奏快，也可以保留 Reviewer、Test、Docs 等子 Agent。 |
| 成本更容易分段控制 | 每轮单独设置预算，避免长期任务无限消耗。 |
适合场景
- MVP 开发。
- 产品功能迭代。
- UI 和交互优化。
- 文档站、资源中心、帮助中心。
- 需要客户或团队连续反馈的任务。
- 探索性功能验证。
控制重点
- 每轮只保留 1 到 3 个主要目标。
- 本轮新增需求进入下一轮。
- 每轮都要有可验收交付物。
- 每轮预算单独设置。
- 连续多轮方向变化很大时，要重新确认目标。
- 准备正式上线时，应切换到瀑布发布流程。
Sub 同时结合瀑布和敏捷
真实项目经常同时需要敏捷和瀑布。
常见方式是：
敏捷阶段：快速做出 MVP 和多轮迭代
-> 每轮内部使用 Sub 模式分工
-> 功能稳定后进入瀑布阶段
-> 瀑布阶段内部继续使用 Sub 模式做审查、测试、部署准备
-> 人工审批后发布这种组合的好处是：
- 前期用敏捷获得速度和反馈。
- 中期用 Sub 提升并行执行能力。
- 后期用瀑布控制发布风险。
- 全程保留权限、预算、审批和审计。
和蜂群模式的关系
Sub 加瀑布或敏捷，仍然是可控协作，不是完整蜂群。
它的优势是：
- 容易解释给客户。
- 容易设置权限边界。
- 容易控制预算。
- 容易审计。
- 适合当前正式交付。
蜂群模式适合需要多个 worker 并行处理的探索性任务：一台租户虚拟机上由 lead Agent 拆解任务，派发给最多 8 个（默认 3 个）worker Agent 并行执行。当任务需要这种并行探索能力时，再进入蜂群模式。
可以这样理解：
Sub + 敏捷：快速迭代
Sub + 瀑布：正式交付
蜂群模式：复杂动态协作总结
Sub 模式本身提供多 Agent 分工能力。
结合瀑布后，它让正式交付更高效、更可审查、更可控。
结合敏捷后，它让每轮迭代更快、更完整、更容易持续反馈。
最终，Heicode 可以形成一套完整路径：
敏捷探索
-> Sub 分工执行
-> 瀑布发布
-> 蜂群处理更复杂的动态协作最后更新于