Heicode Agent 蜂群特色说明

一句话说明

Heicode 的 Agent 蜂群，是一种面向真实软件交付的 AI 协作机制。它不是简单地同时启动多个 AI，而是让多个 Agent 围绕同一个用户目标，在统一的任务、资源、产物和审计体系中协同工作。

蜂群模式采用 lead（主管）加 worker（工作）的主从架构：每个租户对应一台 Azure 虚拟机，虚拟机上以 docker-compose 运行一个 api 容器、一个 lead 容器和若干 worker 容器。lead 接收用户目标、拆解任务并派发给 worker；worker 领取任务、执行、上报心跳，并把结果回传给 lead 聚合。worker 数量最多 8 个，默认 3 个（随套餐可调整）。

用户提出目标
-> Heicode 理解需求
-> lead Agent 拆解任务
-> lead 把子任务派发给 worker Agent
-> worker 执行、上报心跳、回传结果
-> 高危操作进入审批
-> lead 聚合结果
-> 产物、日志、用量和审计统一回传

Heicode 会根据你的目标自动组织一支 AI 开发团队，让不同 Agent 分别处理需求、架构、代码、测试、审查、部署和维护，并把过程安全地记录下来。

为什么需要 Agent 蜂群

单个 AI 助手适合回答问题或完成局部任务，但真实软件开发通常不是一个单点动作。

一个产品从想法到上线，通常会涉及：

• 需求理解。
• 产品拆解。
• 技术方案。
• 前端开发。
• 后端开发。
• 数据库设计。
• 测试验证。
• 安全检查。
• 部署上线。
• 日志排查。
• 后续维护。

如果只依赖一个 Agent，它容易出现几个问题：

• 上下文过长后容易遗漏重点。
• 复杂任务拆解不稳定。
• 代码、测试、部署之间缺少交接。
• 失败后不知道如何回流修复。
• 资源权限、密钥和生产操作难以控制。
• 客户无法清楚看到谁做了什么、用了什么资源、结果是什么。

Agent 蜂群的价值，就是把一个大目标交给 lead Agent 拆成多个可追踪、可协作、可验证的子任务，再由多个 worker Agent 在受控边界内并行完成。

Heicode 产品中的蜂群技术

Heicode 的蜂群技术由以下部分组成：

目标理解 -> lead 任务拆解 -> worker 并行执行 -> 结果聚合 -> 治理与审计

这些能力共同构成了 Heicode 的 AI 开发团队运行机制。

1. lead Agent：拆解和派发任务

客户每次启动一个目标，lead Agent 都会接收目标、理解需求、拆解成若干子任务，再派发给 worker Agent 执行。

例如客户输入：

帮我基于现有代码增加团队成员邀请功能，并完成测试。

lead 会围绕这个目标拆解任务、派发给 worker，后续所有任务、产物、用量和审计都归属于这次运行。

客户价值：

• 每次任务有独立记录。
• 过程可查看。
• 结果可验收。
• 失败可追踪。
• 用量可归因。

2. worker 并行执行：把任务真正跑起来

worker Agent 从 lead 派发的子任务开始执行。执行过程中发现新问题，lead 可以派发新的任务，例如：

• 测试失败，自动生成修复任务派发给 worker。
• 发现权限不足，进入资源补充或审批。
• 发现部署风险，生成回滚计划。
• 发现需求不完整，回到客户确认。

客户价值：

• 系统不是机械执行固定流程。
• 任务可以根据实际情况自我调整。
• 失败后可以继续推进。
• 客户能看到任务为何新增、为何暂停、为何需要审批。

3. 能力编队：按任务需要组织 worker

Heicode 不要求客户手动选择 worker 数量，lead 会根据任务目标决定需要拆解出多少子任务、派发给多少个 worker（不超过套餐规定的上限，最多 8 个，默认 3 个）。

简单任务可能只需要少量 worker 完成目标理解、实现和验证；复杂任务会用到更多 worker，分别处理产品理解、架构分析、前端实现、后端实现、安全审查、测试验证、运维部署、文档整理等工作。

客户价值：

• 不需要理解底层 Agent 配置。
• 任务越复杂，系统自动组织更多 worker。
• 每个 Agent 都有明确职责和边界。
• 客户可以看到"谁在做什么"。

4. 共同资源层：蜂群协作的共享工作台

共同资源层是 Heicode 蜂群技术的核心。它让 lead 和多个 worker 使用同一套任务、资源、产物和审计记录。如果没有共同资源层，多个 Agent 只是同时运行；有了共同资源层，lead 和 worker 之间才能协作。

共同资源层包含：

客户价值：

• 多个 Agent 不会各自为战。
• 任务可以交接。
• 失败可以回流。
• 产物可以集中查看。
• 权限和密钥不会失控。
• 过程可以审计。

5. 受控自治：允许自动协作，但不能越权

Heicode 蜂群不是完全放任 AI 自动操作。它采用的是受控自治：

Agent 可以自动拆解任务、领取任务、调用工具、生成产物、修复失败。
但 Agent 不能越过权限、密钥、预算、审批和审计边界。

受控内容包括：

• 用户身份。
• 资源访问范围。
• Git 路径范围。
• SK 技能调用范围。
• 云资源操作范围。
• 模型预算。
• 生产部署。
• 数据删除。
• 生产密钥访问。
• 审计记录。

客户价值：

• 自动化带来效率。
• 审批和权限保证安全。
• 所有关键动作可追溯。
• 企业客户可以放心接入自己的代码和云资源。

6. 最小上下文：给每个 Agent 恰好够用的信息

Heicode 不会把所有历史对话、所有代码和所有资源一次性塞给每个 Agent。系统会为每个任务准备最小可用的上下文，包括：

• 当前任务目标。
• 相关需求摘要。
• 可编辑文件范围。
• 可使用资源引用。
• 可调用 SK。
• 禁止动作。
• 验收标准。
• 失败历史。
• 审批要求。

客户价值：

• Agent 不会拿到不必要的信息。
• 上下文更准确。
• 代码修改范围更可控。
• 密钥和敏感资源不进入普通上下文。

7. 交付物：让结果可查看、可验收

Heicode 蜂群强调产物，而不只是对话。每个关键任务都应该沉淀可查看的交付物，常见包括：

• 需求摘要。
• 技术方案。
• 代码 diff。
• 测试报告。
• 失败原因。
• 修复记录。
• 部署计划。
• 回滚方案。
• 使用说明。
• 交付总结。

客户价值：

• 不是只看 AI 说了什么。
• 可以看到实际产出。
• 可以复盘每一步。
• 可以判断是否达到验收标准。

Heicode 蜂群的产品特色

1. 从想法到交付的连续体验

客户不需要把需求、代码、部署、安全和审计拆到多个系统中手动协调。Heicode 会把这些环节组织在一个连续流程中：

想法 -> 需求 -> 任务 -> 开发 -> 测试 -> 审查 -> 部署 -> 审计 -> 维护

这让客户看到的是完整软件生命周期，而不是单次 AI 对话。

2. 客户只确认关键事项，不填写底层参数

客户不需要理解：

• Kubernetes。
• Azure 虚拟机和 docker-compose 编排细节。
• OpenBao 路径。
• secret_ref 的具体格式。
• Agent 内部调度策略。

客户只需要确认：

• 要做什么。
• 允许使用哪些资源。
• 哪些动作需要审批。
• 是否接受当前执行结果。

3. 能接入客户已有代码和云资源

Heicode 的蜂群不是只在空白环境中生成代码。它可以围绕客户已有资源工作：

• Git 仓库。
• 项目文档。
• SK 技能。
• 云账号。
• 云资源。
• 测试环境。
• 部署环境。

客户价值：

• 可以基于现有项目继续开发。
• 可以把 AI 引入真实工程流程。
• 不需要重新搭一套独立开发环境。

4. 安全地使用密钥和云资源

客户授权资源后，Heicode 不把长期密钥暴露给 Agent。系统通过：

• 密钥保管器。
• secret_ref。
• 短期凭证。
• 权限范围。
• 客户端审批。
• 审计记录。

来控制资源访问。

客户价值：

• 不需要把密钥复制给 AI。
• 不需要担心 Agent 长期持有生产密钥。
• 高危操作可审批、可拒绝、可追踪。

5. 失败可解释，过程可复盘

传统 AI 工具失败后，客户经常只看到一个错误结果。Heicode 蜂群会记录：

• 哪个任务失败。
• 哪个 worker 执行失败。
• 失败发生在哪一步。
• 是否已经重试。
• 是否生成修复任务。
• 是否需要客户审批或补充资源。

客户价值：

• 失败不是黑盒。
• 团队可以复盘。
• 系统可以继续修复。

6. 用量和成本可见

Agent 蜂群运行中会产生模型调用和运行资源消耗。Heicode 会把用量与任务关联：

• 哪个任务消耗了模型。
• 哪个 worker 产生了调用。
• 当前预算是否接近上限。
• 是否发生大额消耗审批。

客户价值：

• 成本可解释。
• 预算可控制。
• 团队使用更透明。

7. 适合个人、团队和企业逐步扩展

个人用户可以用蜂群完成从想法到 MVP 的快速交付。团队用户可以用蜂群协作推进需求、开发、测试和部署。企业用户可以把蜂群放在已有代码、云资源、权限和审计体系内使用。不同规模的客户看到的是同一套产品能力，但 worker 数量上限、审批、预算和安全边界可以随套餐调整。

Heicode 蜂群的核心特色

1. 目标驱动，不要求客户选择复杂流程

客户不需要先规划好任务图或角色分工。客户只需要描述目标，例如：

我想做一个小团队任务管理 SaaS，
需要登录、项目、任务、评论、通知和后台管理，
希望部署到 Azure。

Heicode 会根据目标自动判断：

• 需要哪些任务。
• 需要哪些 worker 能力。
• 是否需要读取代码仓库。
• 是否需要项目文档或 SK 技能。
• 是否涉及云资源。
• 是否需要测试。
• 是否需要部署。
• 哪些操作属于高危操作。
• 预计会产生哪些模型和运行消耗。

客户看到的是清晰的推荐摘要，而不是底层复杂参数。

2. lead 拆解任务，而不是固定流水线

传统流程通常是一条固定链路：

需求 -> 开发 -> 测试 -> 部署

真实任务往往不是这么线性的。开发过程中可能会出现：

• 需求不清，需要补充澄清。
• 代码依赖复杂，需要先阅读架构。
• 测试失败，需要回到实现修复。
• 部署前发现风险，需要生成回滚方案。
• 云资源权限不足，需要等待客户确认。

lead Agent 会根据实际情况调整派发给 worker 的任务：

用户目标
-> lead 拆解为需求理解、架构分析、前端实现、后端实现、测试验证、安全审查、部署准备等子任务
-> 派发给 worker 并行执行
-> 发现问题后新增修复、交接、审批或验证任务
-> lead 聚合、生成交付总结

3. 能力编队，而不是固定岗位

worker 不是传统公司岗位，也不是固定 Scrum 角色。每次任务开始时，lead 会根据目标临时决定需要多少 worker、承担哪些能力。

常见能力包括：

一个简单任务可能只需要少量 worker；复杂任务会派发给更多 worker，但总数不超过套餐上限（最多 8 个，默认 3 个）。

4. 共同资源层，让 lead 和 worker 真正协作

蜂群不是多个 Agent 各自独立工作，而是需要一个共同资源层。这个共同资源层可以理解为 lead 和 worker 共享的工作台，包含：

简单说：

lead 决定拆解出什么任务
worker 执行并上报进度
lead 聚合各 worker 的结果
治理层保证安全和可审计

这也是 Heicode 蜂群区别于普通多 Agent 对话的关键。

5. 任务派发与心跳机制

worker 不是被随意调用，而是执行 lead 派发给自己的任务。任务派发时，系统会检查：

• 当前 worker 是否具备对应能力。
• 是否有访问相关资源的权限。
• 依赖任务是否完成。
• 是否存在高危操作审批要求。
• 是否超过预算或运行限制。

worker 领取任务后，会持续上报 heartbeat。如果某个 worker 异常退出或长时间没有响应，lead 可以释放任务，重新派发给其他 worker，避免整个任务卡死。

6. 失败回流，而不是失败后停止

真实开发中，失败是正常情况。例如：

• 测试失败。
• 构建失败。
• 接口不兼容。
• 部署失败。
• 权限不足。
• 上下文缺失。

普通 AI 工具往往只是返回失败结果。Heicode 蜂群会把失败变成新的任务：

测试失败 -> 记录失败原因 -> lead 生成修复任务 -> 交给合适的 worker -> 修改后重新验证

这叫失败回流。它让系统具备持续修复能力，而不是一次失败就中断。

7. 交接机制，让不同能力连续工作

一个 worker 完成的结果，往往需要另一个 worker 继续处理。例如：

产品能力生成需求说明
-> 架构能力设计技术方案
-> 后端能力实现 API
-> 前端能力接入页面
-> 测试能力验证功能
-> 运维能力准备部署

交接时，系统会记录：

• 来源 Agent。
• 目标能力。
• 交接原因。
• 输入产物。
• 期望输出。
• 风险等级。

这样客户可以看到任务不是"黑盒运行"，而是有明确过程和交付链路。

8. SK 技能调用，让 Agent 能使用专业工具

Heicode 的 Agent 不只是调用模型生成文本。在客户授权后，Agent 可以使用 SK 技能和工具能力，例如：

• 代码检查。
• API 审查。
• 测试执行。
• 部署检查。
• 文档生成。
• 云资源检查。
• 日志分析。

SK 技能会进入共同资源层，Agent 只能调用被授权的技能。

客户可以理解为：

Agent 不只是会"想"，还可以在授权范围内使用工具完成实际工程动作。

9. 高危操作必须审批

蜂群可以自动推进任务，但不能越过客户的安全边界。以下操作属于高危操作：

• 生产部署。
• 云资源创建、删除、扩缩容。
• 数据库迁移或写入。
• 访问生产密钥。
• 删除数据。
• 大额模型预算消耗。
• 对外发布。

这些操作必须进入审批。审批时，客户应该看到：

• 操作类型。
• 请求的 Agent。
• 目标资源。
• 风险等级。
• 短期凭证 TTL。

请求原因、预计影响等信息，视具体审批场景可能提供，不是每次都保证展示。

客户可以批准，也可以拒绝。审批通过后，平台只会给 Agent 派发短期、最小权限、可审计的访问能力。

10. 密钥不交给 Agent 长期保存

Heicode 的设计原则是：

长期密钥进入密钥保管器
Agent 只拿短期权限或资源引用

长期密钥不会进入：

• Git。
• Markdown。
• 普通日志。
• 前端响应。
• Agent 长期状态。
• 任务事件正文。

Agent 使用资源时，默认拿到的是：

• secret_ref。
• 资源范围。
• 权限边界。
• 审批记录。

这可以降低凭证泄露风险，也方便企业客户审计。

客户日常使用时，不需要理解所有底层机制。典型流程是：

1. 登录 Heicode
2. 在客户端输入目标
3. 按准备清单连接 Git、文档、SK 和云资源
4. 查看 Heicode 推荐的资源范围和 worker 数量
5. 确认启动 Agent 蜂群
6. 在客户端和 Manager 查看执行进度
7. 对高危操作进行审批或拒绝
8. 查看代码、文档、测试、部署计划等交付物
9. 查看模型用量、日志和审计
10. 持续提出维护或升级需求

与普通多 Agent 的区别

与 Chain、Sub 的区别

客户可以这样理解几种协作方式：

Heicode Agent 蜂群给客户带来的核心价值：

1. 从一个想法开始，自动组织 AI 开发团队。
2. 把复杂任务拆成可执行、可追踪、可验证的子任务。
3. 让多个 Agent 围绕同一目标协作，而不是各自输出建议。
4. 让失败可以被记录、解释、修复和回流。
5. 让代码、测试、文档和部署结果形成可验收产物。
6. 让密钥、云资源和生产操作处于受控状态。
7. 让模型消耗和运行成本可见。
8. 让每次任务都有完整审计，便于企业复盘和合规。

Heicode 的 Agent 蜂群不是简单启动多个 AI，而是让 lead Agent 拆解任务、派发给多个 worker Agent 并行执行，所有 Agent 在统一的任务、资源、产物和审计体系中协作。Agent 可以自主领取任务、交接产物、修复失败，但不能越过权限、密钥、预算和审批边界。客户看到的是清晰的任务进度、交付物、高危审批和审计记录，而不是复杂的底层参数。

总结

Heicode Agent 蜂群的特色可以概括为四句话：

目标驱动，而不是流程驱动。
能力协作，而不是单点问答。
失败回流，而不是失败终止。
受控自治，而不是无边界自动化。

它让 AI 从"回答问题的工具"，变成"可以参与软件交付的受控 AI 开发团队"。