Agent 协作模式：蜂群、Sub，及链式概念参考
Agent 协作模式：蜂群、Sub，及链式概念参考
Heicode 当前可以选择的 Agent 协作模式只有两种：
- 蜂群模式：一台租户级虚拟机上，lead（主管）Agent 拆解任务并派发，多个 worker（工作）Agent 领取并执行，worker 数量最多 8 个、默认 3 个（随套餐可调整）。
- Sub 模式：主 Agent 拆分任务，多个子 Agent 分工执行。
本文也会介绍"链式模式"这个概念，它来自 Agent 蜂群模式（Swarm）解析 一文，用来帮助理解多 Agent 协作的不同形态。需要明确：链式模式目前不是 Heicode 产品中可以选择的模式，代码中也没有对应实现，这里只作为概念参考，不代表 Heicode 提供第三种可选协作模式。
这些模式解决的是"多个 Agent 如何协作"的问题。它们不是计费套餐，也不是模型等级。
一句话理解
| 模式 | 是否可选 | 一句话 |
|---|---|---|
| 蜂群模式 | 可选 | lead Agent 拆解任务并派发，多个 worker Agent 并行执行，lead 聚合结果。 |
| Sub 模式 | 可选 | 有主 Agent 负责拆分、分配、汇总，子 Agent 按职责完成局部任务。 |
| 链式模式 | 不可选，仅概念参考 | 任务按固定步骤从上一个 Agent 交给下一个 Agent，像流水线一样执行。 |
一、蜂群模式
文章中的 Swarm 思想强调"没有强中心调度、个体自组织"，但 Heicode 实际落地的蜂群模式并不是这样。它是 lead 加 worker 的主从架构：一台租户级 Azure 虚拟机上以 docker-compose 运行一个 api 容器、一个 lead 容器和若干 worker 容器，lead 负责接收目标、拆解任务并派发，worker 负责领取并执行，worker 数量最多 8 个、默认 3 个（随套餐可调整）。
在 Heicode 中，可以理解为：
用户目标
-> lead Agent 拆解任务
-> lead 把子任务派发给 worker
-> worker 领取、执行、上报心跳
-> 高危操作进入审批
-> lead 聚合 worker 结果
-> 输出结果蜂群模式的关键特征
| 特征 | 说明 |
|---|---|
| 主从架构 | lead 负责拆解和调度，worker 负责领取和执行，不是无中心的自组织。 |
| 显式派发 | 子任务由 lead 拆解后派发给 worker，不是 worker 自行竞争任务。 |
| 心跳上报 | worker 领取任务后持续上报心跳，便于 lead 判断进度和异常。 |
| Handoff | 某个 Agent 可以把任务、上下文或控制权交给另一个 Agent。 |
| 结果聚合 | lead 汇总多个 worker 的结果，判断是否达到验收标准。 |
| 鲁棒性 | 单个 worker 失败时，lead 可以重新派发给其他 worker。 |
蜂群模式适合什么任务
适合：
- 多源资料研究。
- 大规模代码审查。
- 复杂故障排查。
- 多方案探索。
- 安全、性能、测试多维度并行检查。
- 子任务会动态生成、互相影响的复杂任务。
不适合：
- 很小的单步任务。
- 预算非常紧的任务。
- 必须严格线性执行的任务。
- 强一致性事务。
- 没有明确停止条件的任务。
- 涉及生产高危操作但没有审批边界的任务。
Heicode 中蜂群模式需要额外控制什么
蜂群模式能力强，但也更容易失控。因此在 Heicode 中，蜂群模式必须保留平台约束：
- worker 数量上限（最多 8 个，默认 3 个，随套餐可调整）。
- 最大预算和最长运行时间。
- 高危操作审批。
- 人工停止和接管。
- 审计记录。
二、Sub 模式
Sub 模式是 Heicode 中另一种更可控的多 Agent 协作方式。它和蜂群模式是两种独立的协作方式，不是蜂群模式的基础能力或子集。
Sub 模式的核心是“主 Agent 可控拆分”。主 Agent 负责理解目标、拆分任务、分配给子 Agent、接收结果并统一汇总。
用户目标
-> 主 Agent 理解目标
-> 主 Agent 拆分子任务
-> 子 Agent 分工执行
-> 子 Agent 交付结果
-> 主 Agent 聚合和验证
-> 输出最终结果Sub 模式和文章中的 Supervisor 模式关系
文章中对比了 Swarm、Supervisor、Chain。Heicode 的 Sub 模式更接近“Supervisor + 子 Agent 分工”的形态：
- 有一个主 Agent 负责协调。
- 子 Agent 的职责由主 Agent 或用户明确指定。
- 子任务边界相对清楚。
- 结果由主 Agent 汇总。
- 风险、权限和预算更容易控制。
但 Heicode 的 Sub 模式不只是简单 Supervisor。它还会结合任务视图、权限边界、审批、用量和审计，让子 Agent 协作可以用于真实交付。
Sub 模式适合什么任务
适合：
- 多模块开发。
- 复杂 bug 修复。
- 文档、前端、后端、测试需要分工的任务。
- 需要 Reviewer 独立审查的任务。
- 任务可以提前拆成几个明确部分的场景。
不适合：
- 子任务会不断动态生成的任务。
- 需要大量 Agent 自主竞争或补全的任务。
- 没有主线目标的开放探索。
- 更适合固定流水线的简单任务。
Sub 模式的价值
- 比单 Agent 更能处理复杂任务。
- 比蜂群模式更容易控制风险。
- 可以给不同子 Agent 设置不同权限。
- 可以让执行、审查、部署分离。
- 可以按子任务查看进度、失败原因和模型用量。
三、链式模式（概念参考，非 Heicode 现有模式）
以下内容来自参考文章中的 Chain 概念，用来帮助理解协作光谱中的另一端。Heicode 目前不提供可选择的链式模式，产品中没有对应功能。
链式模式对应文章中的 Chain。它的核心是“固定顺序流水线”。
任务会按预设步骤依次传递：
Agent A
-> Agent B
-> Agent C
-> Agent D
-> 输出结果链式模式中，每个 Agent 只处理上游传来的内容，然后把结果交给下游。
链式模式适合什么任务
适合：
- 流程固定的任务。
- 数据清洗、分析、报告生成。
- 文档格式化。
- 固定发布检查。
- 固定审核流程。
- 不需要动态调整路径的任务。
不适合：
- 复杂探索。
- 多方案竞争。
- 任务路径不确定。
- 需要多个 Agent 并行补全。
- 上游结果不稳定且需要反复回退的任务。
链式模式的价值
- 最容易理解。
- 最容易复现。
- 最容易审计。
- 成本可预测。
- 每一步输出都清楚。
链式模式的风险
- 灵活性低。
- 上游失败会影响下游。
- 某一步设计错误，整个流程都会偏。
- 不适合动态任务。
模式对比（含链式概念参考）
| 维度 | 蜂群模式（可选） | Sub 模式（可选） | 链式模式（概念参考，不可选） |
|---|---|---|---|
| 协调方式 | lead 拆解并派发，worker 执行 | 主 Agent 拆分和协调 | 固定顺序传递 |
| 任务结构 | lead 派发给最多 8 个 worker（默认 3 个） | 明确子任务 | 固定流水线 |
| 灵活性 | 中到高 | 中 | 低 |
| 可控性 | 中，依赖预算和 worker 上限 | 高 | 高 |
| 容错性 | 中到高，lead 可重新派发 | 中 | 低 |
| 成本可预测性 | 低到中 | 中到高 | 高 |
| 适合任务 | 需要多 worker 并行处理的探索性任务 | 多角色分工、可控交付 | 固定流程、标准化处理（仅概念） |
| 主要风险 | worker 数量或成本失控 | 主 Agent 拆分不准、子任务重复 | 链条断裂、流程僵化（仅概念） |
如何选择
Heicode 当前只能在蜂群模式和 Sub 模式之间选择：
| 任务特征 | 推荐模式 |
|---|---|
| 任务需要多个 worker 并行探索 | 蜂群模式 |
| 子任务边界清楚，需要多个子 Agent 分工 | Sub 模式 |
| 大规模代码审查，需要多个 worker 分别检查 | 蜂群模式 |
| 修复复杂 bug，问题可以拆成前端、后端、验证 | Sub 模式 |
| 文档从采集、整理到审查 | Sub 模式 |
| 产品功能开发 | Sub 模式 |
链式模式作为概念参考，只用于说明"如果流程完全固定、不需要动态调整，可以设想成一条流水线"，但这不是 Heicode 当前提供的实现方式。
总结
- Sub 模式适合边界清楚的可控分工。
- 蜂群模式适合需要多个 worker 并行处理的探索性任务，采用 lead 派发、worker 执行的主从架构。
- 链式模式仅作为理解协作光谱的概念参考，Heicode 目前没有对应的可选模式或实现。
参考
- Agent 蜂群模式（Swarm）解析（本文链式模式部分的概念来源，非 Heicode 产品文档）
最后更新于