选择 Agent 工作模式
选择 Agent 工作模式
Agent 启动前需要选择工作模式。工作模式决定任务如何拆分、子 Agent 如何协作、什么时候需要你确认、怎样验收交付结果。
Heicode 的工作模式分为两类：
- 协作模式：决定多个 Agent 如何一起工作，包括 Sub 模式和蜂群模式。
- 交付模式：决定任务如何推进和验收，包括瀑布模式和敏捷模式。
Sub 模式不是蜂群模式。Sub 模式是主 Agent 拆分任务、子 Agent 显式协作的基础能力；蜂群模式是 Heicode 的另一种协作方式——一台租户级虚拟机上运行一个 lead（主管）Agent 和多个 worker（工作）Agent，lead 负责接收目标、拆解任务并派发，worker 负责领取并执行子任务，worker 数量最多 8 个、默认 3 个（随套餐可调整）。这是 lead 派发、worker 执行的主从架构，不是没有中心调度、Agent 自行竞争任务的去中心化自组织系统。
瀑布模式和敏捷模式则对应"开发模式团队"一键部署功能的两个固定模板，角色和数量固定：敏捷 = 产品(planner) + 开发(executor) + 评审(code-reviewer) 共 3 个角色；瀑布 = 分析(analyst) + 架构(architect) + 开发(executor) + 测试(qa-tester) + 评审(code-reviewer) 共 5 个角色。
四种模式快速对比
| 维度 | Sub 模式 | 蜂群模式 | 瀑布模式（5 角色固定模板） | 敏捷模式（3 角色固定模板） |
|---|---|---|---|---|
| 类型 | 协作模式 | 协作模式 | 交付模式 | 交付模式 |
| 核心思想 | 主 Agent 拆分任务，子 Agent 按职责执行 | lead 拆解任务，多个 worker 并行执行 | 按固定阶段顺序推进 | 按短周期持续迭代 |
| 协调方式 | 主 Agent 显式分配、交接、聚合 | lead 派发任务，worker 领取执行并上报，lead 聚合结果 | 上一阶段确认后进入下一阶段 | 每轮计划、执行、验收、调整 |
| 用户参与 | 关键问题、审批和验收时介入 | 设定预算边界、处理异常、验收聚合结果 | 每个阶段结束时确认 | 每个迭代结束时反馈 |
| 适合任务 | 明确分工、多模块开发、复杂排障 | 多源研究、复杂探索、大规模并行审查 | 生产发布、合规文档、迁移、正式交付 | 产品功能、MVP、UI/体验优化 |
| 主要风险 | 主 Agent 拆分不准，子任务重复 | worker 数量或预算失控、成本不可控 | 前期需求错误会影响后续 | 频繁变更可能扩大范围 |
| 预算控制 | 按子 Agent 控制 | 按总预算和单 worker 上限控制 | 按阶段控制 | 按迭代控制 |
| 验收方式 | 主 Agent 聚合后验收 | lead 聚合 worker 结果后验收，必要时人工裁决 | 阶段验收和最终验收 | 每轮增量验收 |
Sub 模式
Sub 模式是 Heicode 的基础多 Agent 协作方式。它的重点不是“蜂群自组织”，而是“主任务可控拆分”。
在 Sub 模式中，主 Agent 负责理解用户目标、拆分子任务、分配给子 Agent、汇总结果并对用户交付。子 Agent 负责单一职责，例如研究、前端、后端、测试、审查或部署。
Sub 模式如何工作
用户目标
-> 主 Agent 理解目标
-> 主 Agent 拆分子任务
-> 创建或唤起子 Agent
-> 子 Agent 执行自己的任务
-> 子 Agent 显式交接结果
-> 主 Agent 聚合
-> 验证和交付Sub 模式讲解要点
| 概念 | 含义 |
|---|---|
| 主 Agent | 中央协调者，负责拆分、分配、聚合和汇报 |
| 子 Agent | 单一职责执行者，只处理被分配的局部任务 |
| 显式任务 | 子 Agent 的任务由主 Agent 或用户明确给出 |
| Handoff | 子 Agent 完成后把结果或问题交给主 Agent 或下一个子 Agent |
| 聚合 | 主 Agent 汇总各子任务，形成统一交付 |
| 可控边界 | 每个子 Agent 有明确资源、权限、预算和审批规则 |
Sub 模式和蜂群模式的关系
Sub 模式和 Heicode 的蜂群模式都属于"多 Agent 协作"，但控制方式不同：
- Sub 模式没有 lead/worker 的角色划分，子任务由主 Agent 显式分配。
- 蜂群模式有明确的 lead 和 worker：lead 拆解任务并派发，worker 领取执行、上报心跳。
- Sub 模式以交接和聚合为主，蜂群模式还需要 lead 对多个 worker 的结果做聚合。
- Sub 模式适合边界清楚的可控分工，蜂群模式适合需要多个 worker 并行处理的探索性任务。
简单说：Sub 模式和蜂群模式是 Heicode 中两种不同的多 Agent 协作方式，蜂群模式不是 Sub 模式的简单升级，而是 lead 加 worker 的主从架构。
什么时候选择 Sub 模式
选择 Sub 模式的情况：
- 一个任务需要多个专业角色参与。
- 子任务边界比较清楚。
- 需要主 Agent 统一控制方向。
- 需要代码实现、测试、审查分开处理。
- 问题复杂，但还不需要完全自组织协作。
- 需要把任务控制在明确预算和权限内。
不建议选择 Sub 模式的情况：
- 任务很小，单个 Agent 可以完成。
- 需求不清楚，连目标都没有定义。
- 子任务之间强依赖共享状态和动态调整。
- 需要大量 Agent 自动寻找任务和相互影响。
- 输出必须完全按固定阶段签收。
Sub 模式配置建议
子 Agent 数量按任务实际需要增减，没有固定档位，根据任务边界和职责划分来决定。
常见角色组合（角色取自 Product、Architect、Frontend、Backend、Reviewer、Ops 六个角色目录）：
| 场景 | 推荐组合 |
|---|---|
| 新功能 | Product、Frontend、Backend、Reviewer |
| 复杂 bug | Backend、Reviewer |
| 文档和资源中心 | Product、Reviewer |
| 云部署 | Ops、Reviewer |
| 大型重构 | Architect、Backend、Reviewer |
权限建议：
- 每个子 Agent 只拿自己需要的资源。
- Reviewer Agent 默认不负责直接修改生产资源。
- Ops Agent 可以准备部署，但生产部署必须审批。
- 子 Agent 之间共享的是任务状态和结果，不共享不必要的密钥。
蜂群模式
蜂群模式是 Heicode 的多 Agent 协作方式之一，采用 lead 加 worker 的主从架构：每个租户对应一台 Azure 虚拟机，虚拟机上以 docker-compose 运行一个 api 容器、一个 lead 容器和若干 worker 容器。lead 接收用户目标、拆解任务并派发给 worker；worker 领取任务、执行并把结果回传给 lead。worker 数量最多 8 个，默认 3 个（随套餐可调整）。
蜂群模式适合复杂、需要多个 worker 并行处理的任务。它不是没有中心调度、Agent 自行竞争任务的去中心化系统，而是有明确 lead 负责拆解和调度的主从架构。
蜂群模式如何工作
用户目标
-> lead Agent 接收目标
-> lead 拆解为若干子任务
-> worker 领取被派发的子任务
-> worker 执行、上报心跳和进度
-> 高危操作进入审批
-> lead 聚合 worker 结果
-> 验证和交付蜂群模式的核心组件
| 组件 | 作用 |
|---|---|
| lead Agent | 接收目标、拆解任务、派发给 worker、聚合结果 |
| worker Agent | 领取 lead 派发的子任务并执行，上报心跳 |
| api 容器 | 处理请求入口，对接 Manager 和客户端 |
| 权限与资源引用 | 管理 Git、文档、SK、云资源和密钥引用 |
| 审批 | 管理生产部署、云操作、密钥访问等高危确认 |
| 审计 | 记录每个动作的主体、资源、时间、结果和用量 |
蜂群模式和 Sub 模式的差异
| 维度 | Sub 模式 | 蜂群模式 |
|---|---|---|
| 控制方式 | 主 Agent 明确分配任务 | lead Agent 拆解并派发任务给 worker |
| 任务来源 | 主 Agent 拆分后下发 | lead 拆解后下发给 worker |
| 协作方式 | 显式交接为主 | lead 派发、worker 执行并上报 |
| 失败处理 | 主 Agent 重新分配或停止 | lead 可以重新派发给其他 worker |
| 结果形成 | 主 Agent 汇总 | lead 聚合 worker 结果 |
| 适用规模 | 小到中型多角色任务 | 需要多个 worker 并行处理的任务，worker 上限 8 个 |
| 风险控制 | 容易控制 | 依赖预算、worker 数量上限和审批边界 |
什么时候选择蜂群模式
选择蜂群模式的情况：
- 任务需要多个 Agent 从不同方向同时探索。
- 子任务之间存在动态依赖，无法一次性拆清楚。
- 需要持续吸收新信息并调整路径。
- 需要多个结果互相校验、补全或竞争。
- 需要处理大规模代码审查、资料研究、复杂故障定位。
- 单个主 Agent 容易成为瓶颈。
不建议选择蜂群模式的情况：
- 任务目标很小。
- 验收标准不清楚。
- 预算很紧。
- 没有人处理异常审批。
- 涉及生产高危操作但没有明确边界。
- 需要强一致事务或严格线性流程。
蜂群模式配置建议
启动前确认：
- lead 打算如何拆解任务。
- 每个 worker 可以访问哪些资源。
- worker 数量上限（最多 8 个，默认 3 个，随套餐可调整）。
- 最大运行时间和最大预算。
- 哪些动作必须人工审批。
推荐约束：
- 按套餐确认 worker 数量上限，不超过 8 个。
- 设置单个 worker 最大连续运行时间。
- 设置总预算和单 worker 预算上限。
- 生产操作必须退出蜂群自动流程，进入审批。
蜂群模式监控重点
重点观察：
- lead 拆解出的任务是否堆积。
- 是否有 worker 重复处理同一任务。
- worker 是否卡住或长时间没有心跳。
- 哪个 worker 消耗最多预算。
- 是否有高危权限请求。
- lead 聚合的结果是否有明确证据。
发现问题时可以：
- 停止某个异常 worker。
- 降低 worker 并发数量。
- 要求 lead 提前汇总当前结果。
- 切换到 Sub 模式做可控拆分。
- 切换到瀑布模式处理正式交付。
瀑布模式
瀑布模式适合目标清楚、阶段顺序明确、风险需要严格控制的任务。它要求一个阶段完成并确认后，才进入下一个阶段。
瀑布模式如何工作
需求确认
-> 方案设计
-> 实现
-> 测试
-> 审查
-> 发布准备
-> 发布审批
-> 交付归档每个阶段都应该有明确输出。
| 阶段 | 典型输出 |
|---|---|
| 需求确认 | 需求摘要、范围边界、验收标准 |
| 方案设计 | 技术方案、风险点、资源计划 |
| 实现 | 代码 diff、文档改动、配置变更 |
| 测试 | 测试结果、失败项、修复记录 |
| 审查 | 审查结论、风险说明、是否可发布 |
| 发布准备 | 构建记录、部署计划、回滚方案 |
| 发布审批 | 审批记录、凭证 TTL、影响范围 |
| 交付归档 | 交付说明、审计摘要、后续事项 |
什么时候选择瀑布模式
选择瀑布模式的情况：
- 需求已经明确。
- 交付边界固定。
- 涉及生产发布。
- 涉及客户交付、合规、法律或安全内容。
- 需要完整审计链路。
- 团队希望每个阶段都可签字确认。
不建议选择瀑布模式的情况：
- 目标还在探索。
- 产品方向需要频繁调整。
- 需要快速试错多个方案。
- 不知道最终交付应该是什么。
敏捷模式
敏捷模式适合需要持续迭代的任务。它不追求一次性把所有内容做完，而是每一轮交付一个可验证的增量。
敏捷模式如何工作
建立目标
-> 选择本轮范围
-> 执行
-> 验证
-> 演示或交付
-> 收集反馈
-> 调整下一轮每一轮都应回答三个问题：
- 本轮做什么。
- 本轮不做什么。
- 本轮怎样算完成。
什么时候选择敏捷模式
选择敏捷模式的情况：
- 产品需求还会变化。
- 希望先完成 MVP。
- UI、交互、文案需要多次调整。
- 需要客户或团队每轮反馈。
- 任务可以拆成多个小增量。
- 不希望一次性开放太大权限。
不建议选择敏捷模式的情况：
- 一次性迁移或发布，不能分多轮。
- 需求已经严格冻结。
- 每一轮反馈都无人负责。
- 团队没有时间验收增量。
如何选择模式
可以按以下规则选择：
| 任务特征 | 推荐模式 |
|---|---|
| 多角色分工清楚，需要主 Agent 控制 | Sub 模式 |
| 多方向探索，任务会动态生成和互相影响 | 蜂群模式 |
| 需求明确、风险较高、需要阶段签收 | 瀑布模式 |
| 需求会变化、需要持续反馈 | 敏捷模式 |
| 先探索方案，再进入稳定交付 | 蜂群模式或 Sub 模式，然后切换瀑布模式 |
| 先做 MVP，再不断优化 | 敏捷模式 |
| 涉及生产部署和回滚 | 瀑布模式 |
| 需要多个 Agent 分别审查安全、性能、测试并互相补全 | 蜂群模式 |
模式可以组合吗
可以。协作模式和交付模式通常组合使用。
常见组合：
- 敏捷加 Sub：每轮迭代中，由多个子 Agent 分工完成本轮目标。
- 敏捷加蜂群：每轮迭代中，用蜂群的多个 worker 快速探索方案、风险和实现路径。
- 瀑布加 Sub：每个阶段内用子 Agent 分工，阶段之间严格验收。
- 蜂群到瀑布：探索完成、方案稳定后，进入正式发布阶段。
- Sub 到蜂群：发现静态拆分不足，需要更多 worker 并行处理。
切换前应确认：
- 当前交付物是否已保存。
- 未完成任务是否已归档。
- 预算是否重新设置。
- 权限是否需要收缩或扩大。
- 审批规则是否仍然适用。
- 审计中是否记录切换原因。
模式选择示例
示例一：修复登录失败
推荐：Sub 模式。
原因：
- Backend Agent 分析报错、检查接口。
- Frontend Agent 检查客户端回跳逻辑。
- Reviewer Agent 验证修复。
- 子任务边界清楚，不需要蜂群模式的多 worker 并行处理。
示例二：大规模代码审查
推荐：蜂群模式。
原因：
- 安全、性能、测试、依赖、架构可以由多个 worker 并行审查。
- 发现问题后可以生成后续检查任务。
- 多个 worker 的审查结果可以互相校验。
- 最终由 lead 聚合，统一输出风险清单。
示例三：上线法律条款页面
推荐：瀑布模式。
原因：
- 内容需要准确。
- 发布前需要审查。
- 生产部署需要审批。
- 交付后需要归档审计。
示例四：设计资源中心
推荐：敏捷模式。
原因：
- 内容和结构需要多轮确认。
- 可以先做文档版，再做站内页面。
- 每一轮都能产出可检查内容。
关于"蜂群"这个说法
“蜂群”一词容易让人联想到没有中心调度、Agent 自行竞争任务的去中心化系统，但 Heicode 目前落地的蜂群模式并不是这样：它是 lead 加 worker 的主从架构，一台租户虚拟机上一个 lead 负责拆解和派发任务，最多 8 个（默认 3 个）worker 负责领取和执行。
Heicode 在这套架构上叠加了平台约束：
- 权限边界。
- 审批规则。
- 预算上限。
- 凭证 TTL。
- 审计记录。
- 停止和接管能力。
这意味着客户获得的是可控的 lead/worker 协作，而不是不可追踪的自动化扩散。