Hermes 多 AI Agent 协作开发系统 · 从单人编码到虚拟团队的进化之路

当 AI 编码代理能独立完成中型功能时，真正的瓶颈不再是模型能力，而是「多个 AI 之间如何协作」。本文以 C456 系统开发为背景，完整讲述基于 Hermes Agent 搭建多角色 AI 虚拟团队的实践体系。

一、开篇：AI 开发的「单人困局」

2025 年，AI 编码代理（Coding Agent）已经从一个概念变成了实实在在的生产力工具。Cursor Agent、Claude Code、Codex、OpenCode 等工具让个人开发者能以前所未有的速度产出代码。一个开发者加一个 AI 代理，完成过去需要三五人团队的功能模块——这听起来像是独立开发者的终极梦想。

但在真实项目中，尤其是像 C456 这样涉及前端、后端、数据库、部署、数据分析的全栈 SaaS 系统，单人 + AI 的模式很快就暴露了深层次的问题。

单人 AI 开发的典型痛点

这些痛点的本质是：AI 编码代理的能力越强，「一个人」的瓶颈就越突出——不是因为这个人不够聪明，而是因为软件开发本质上是一个多人协作的信息处理过程，需要不同的视角、不同的专长、不同的审查机制。

C456 团队在经历了数月的「单人 + AI」开发后，意识到需要引入一个全新的范式：不是用更强大的 AI 替代开发者，而是用多个 AI 代理组成一个虚拟团队，各自扮演不同的专业角色，通过结构化的协议协同工作。

而这个虚拟团队的「大脑」——协调者、调度者、通信中枢——就是我们今天的主角：Hermes Agent。

二、背景：C456 系统——一个需要「团队」的项目

在深入技术细节之前，有必要了解一下 C456 是什么。

C456 是一个云端知识底座平台，提供收录管理、工具/渠道/信号分类、打法（Playbook）体系、素材库以及 CLI 工具链。用通俗的话说，它是一个帮助个人和团队构建、管理、分享碎片化知识的产品。

从技术栈来看，C456 的复杂性不容小觑：

• 前端：React + TypeScript，基于 Inertia.js 与 Rails 集成
• 后端：Ruby on Rails 8（API + SSR）
• 数据库：SQLite（开发）、PostgreSQL（生产）
• 部署：Kamal，新加坡服务器
• CLI 工具：Node.js，通过 API v1 与主站通信
• AI 集成层：多个 Agent 平台（Hermes、OpenCode、Cursor）配合技能体系
• 知识维基：三层架构（llm-wiki → llm-wiki-domains → c456-llm-wiki）
• 数据流水线：股票市场数据重建、信号提炼

对于一个单人核心开发者来说，要同时维护以上所有层的代码、确保它们之间的接口兼容、处理部署问题、撰写文档——即使是 AI 辅助，也已经远超单线程的认知容量。

C456 需要的不是更快的编码代理，而是一个真正的「开发团队」——只不过这个团队的成员是 AI。

三、Hermes Agent 的引入：指挥家的诞生

3.1 为什么选择 Hermes

在评估了市面上多个 AI Agent 框架后，C456 团队选择了 Hermes Agent（Nous Research 出品）作为整个虚拟团队的协调核心。Hermes 之所以脱颖而出，有几个关键原因：

1. 技能体系（Skills）—— 让 AI 拥有「程序性记忆」

Hermes 的 Skill 系统允许 Agent 将解决复杂问题的经验固化为可复用的知识包。每当 Hermes 发现一个有效的工作流、克服一个困难、或者被用户纠正了某个做法，它都可以将这些经验保存为 Skill 文档，在未来的会话中自动加载。

在 C456 团队的实际使用中，这个能力意味着：当 Hermes 成功协调了一次「Arch → Dev → Analyst → PM」的完整开发循环，它可以将整个流程的模式抽象为一个 Skill（即 doc-driven-multi-agent），后续所有类似任务都自动遵循这个经过验证的工作流。

2. 多平台网关（Gateway）—— 敏捷团队不能只有一台终端

Hermes 支持 Telegram、Discord、Slack、WhatsApp 等 20+ 平台作为接入点。虽然 C456 的开发主要在终端完成，但 Hermes 的 Gateway 架构意味着任务通知、状态更新、验收确认可以推送到团队偏好的沟通渠道。

3. 持久化记忆（Memory）—— 跨会话的团队记忆

Hermes 的记忆系统跨越会话和模型切换。这意味着：当你从一个任务切换到另一个，或者升级了底层模型，Hermes 仍然记得你的偏好、工作环境、以及之前做出的架构决策。

4. 子代理委托（Delegation）—— 真正的并行执行

delegate_task 工具让 Hermes 可以同时启动多个独立子代理，每个都有自己的上下文和工具集。这是整个多 Agent 协作体系的运行时基础——因为没有真正的并行，就谈不上「团队协作」。

5. 开源 + 模型无关

Hermes 是 MIT 开源的，支持 20+ 模型提供商。这意味着 C456 团队可以根据任务场景选择最合适的模型——复杂架构推理选择深度模型，简单编码任务选择快速模型，数据分析选择高精度模型——而不需要被任何单一厂商锁定。

3.2 Hermes 在 C456 中的定位

在 C456 的虚拟团队架构中，Hermes 的角色非常明确：

Hermes 是「指挥家」，不是「演奏家」。

它的核心职责是：

• 理解人类需求 —— 接收产品方向、功能需求、优先级调整
• 分解任务 —— 将大需求拆解为可执行的子任务
• 分派给专业角色 —— 判断任务适合哪个 AI 角色（Arch/Dev/PM/PO/Analyst）
• 维护通信日志 —— 记录所有决策、手递手（Handoff）、阻塞事项
• 协调进度 —— 跟踪各角色进度，处理阻塞，推动任务至完成
• 保障审计 —— 确保每个步骤都有文档记录，可回溯

在 C456 的实际开发中，人类开发者（辉哥）的角色更多的是产品经理 + 最终决策者，而 Hermes 作为 AI 指挥家，负责调度那些 AI 执行者——这些执行者可以是 Hermes 自己 fork 出的子代理，也可以是运行在 tmux 会话中的 Cursor Agent 实例，还可以是 OpenCode 或其他 AI 编码工具。

四、五角色模型：虚拟团队的「组织架构」

如果说 Hermes 是指挥家，那么「谁来演奏」？C456 的虚拟团队包含五个专业角色，每个角色有清晰的职责边界、交付物和决策权限。这个体系在 doc-driven-multi-agent 技能中被完整定义。

角色全景

4.1 架构师（Arch）—— 系统设计的守护者

在传统的开发团队中，架构师的角色往往被忽视——尤其是在小团队中，「边写边设计」是常态。但在 AI 代理的语境下，没有架构约束的编码就是一场灾难：AI 代理会自然地选择最熟悉的模式（通常是千篇一律的样板代码），而不是最适合项目的方案。

Arch 角色的核心职责包括：

• 编写架构决策记录（ADR）：当需要引入新技术、改变模块边界、调整数据流时，Arch 负责撰写 ADR，记录决策背景、选项分析、最终结论
• 代码评审：Dev 完成实现后，Arch 进行结构性审查——检查是否符合 ADR、是否有过度工程、是否有安全漏洞
• 小范围直接修改：对于命名修正、接口微调、类型补全等不需要完整开发流程的改动，Arch 可以直接操作

Arch 的边界：Arch 不编写产品功能代码，不修改产品规格说明书，不越俎代庖接手完整的 Dev 任务。

4.2 开发者（Dev）—— 唯一的代码生产者

Dev 是整个体系中唯一被允许编写产品代码的角色。这个「唯一」是有意为之的——它确保了：

• 代码来源可追踪：所有代码改动都经过 Dev 之手，不会出现「不知道谁改了哪里」的情况
• 代码风格一致：Dev 遵循编码规范、测试要求、提交约定
• 审查机制有效：因为只有 Dev 产代码，Arch 和 Analyst 的审查才有明确的输入

Dev 的工作方式遵循 TDD（测试驱动开发） 原则：

• 红色阶段：先写失败的单测
• 绿色阶段：实现功能使测试通过
• 重构阶段：优化代码质量

Dev 在 Git 工作树（worktree）中完成所有工作，与主开发线的隔离保证了即使任务失败，也不会污染主要代码库。

4.3 项目经理（PM）—— 进度与流程的看护者

PM 是 C456 团队中容易被低估但其实至关重要的角色。在 AI 代理的工作流中，PM 的主要职责包括：

• 工作树生命周期管理：创建隔离的工作树分配给 Dev → 任务完成后清理工作树
• 任务拆解与排期：将 PO 交付的规格拆解为可执行的计划项
• 门控管理：检查 G0-G4 各门的条件是否满足，推动流程前进
• 通信日志维护：确保所有决策和手递手记录在案

PM 不写代码、不做产品定义、不做架构决策。 它的核心价值在于流程纪律——确保每个环节不遗漏，确保每次手递手都有完整的上下文。

4.4 产品负责人（PO）—— 做什么、为什么

PO 回答软件开发中最难的两个问题：「做什么」和「为什么做」。

在 C456 的工作流中，PO 的交付物包括：

• 功能规格（Spec）：清晰定义「什么是不做的」比「做什么」更重要——PO 需要明确 MVP 边界
• 验收标准：每条功能附带可验证的接受条件
• 产品决策：当 Arch 或 Dev 遇到产品层面的歧义时，PO 是最终裁决者

PO 不写代码、不参与架构决策。它的产品视角与 Tech 视角形成了有效的制衡——防止团队在技术细节中迷失用户价值。

4.5 数据分析师（Analyst）—— 客观的验证者

Analyst 角色在 C456 中被赋予了一个独特的责任：数据验证。

与传统的 QA 不同，C456 的 Analyst 关注的是：

• 功能实现的正确性：Dev 声称「完成了」的功能，真的有按 spec 工作吗？
• 数据一致性：数据库中的记录是否反映了业务规则？
• 边界情况：空数据、大量数据、异常输入——系统在这些情况下表现如何？

Analyst 的输出是带有可复现步骤的审查报告，标记为 DATA_PASS 或 DATA_FAIL。在 DATA_FAIL 的情况下，报告会清晰地描述问题、复现步骤、以及预期行为。

五、文档驱动协作：没有文档就没有手递手

五个角色各司其职，但如果它们之间没有有效的通信机制，再好的分工也只是空中楼阁。C456 虚拟团队的核心协作原理是：

「代理之间不对话；它们为彼此写文件。」

这是 文档驱动多代理协作协议（doc-driven-multi-agent） 的核心理念。

5.1 为什么要「文档驱动」，不是「聊天驱动」？

很多人的第一反应是：「AI 之间不能对话吗？让 Arch Agent 直接给 Dev Agent 发消息不就行了？」

问题在于：

在 C456 的实际运行中，这个区别被反复验证：当一个 Dev Agent 完成实现后，如果只在会话中说「搞定了」，Arch Agent 无法检验；但如果 Dev 在 review 目录下提交了验证证据和执行日志，Arch 就有了明确的审查对象。

5.2 文档链结构

整个协作体系围绕一条文档链展开，每条链的节点都是一个可寻址的文件路径：

AGENTS.md                              ← 入口点（所有代理的强制性启动清单）
  └── WORKFLOW.md                     ← 规范流程（本协议全文）
        └── GOALS.md                  ← 产品/项目目标
              └── spec                ← 构建内容 + 验收标准
                    ├── comm          ← 通信日志（决策、手递手）
                    ├── plan          ← 任务分解（含复选框）
                    └── code          ← 工作树实现 + 测试
                          └── review  ← 验证证据
                                └── daily  ← 工程日报

5.3 手递手三要素（Handoff Protocol）

这是整个协议中最核心的机制。每一次任务在不同角色之间的传递，都必须包含三个结构化字段，写入通信日志：

一个标准的手递手块长这样：

**Handoff:**
- **Target:** 开发者 (Dev)
- **Address:** `docs/superpowers/comms/xxx.md`（此条目）, `docs/superpowers/specs/xxx.md`
- **Task:** 按 spec §4 验收标准实现 plan 任务 3.2；在 .worktrees/feat-xxx 中工作

如果手递手缺少这三个要素中的任何一个，接收方必须拒绝——不能开始工作。

这条规则听起来严苛，但在实践中，它是整个体系质量的基石。它强制每个任务传递方在移交前就想清楚：谁来做、在哪里做、做什么。没有这种强制力，任务就会在「我觉得你应该知道怎么做」的模糊状态中迷失。

5.4 门控机制 G0-G4

C456 的工作流定义了五个门控阶段，控制着工作从一个阶段到下一个阶段的推进。每个门必须被明确的角色批准才能通过：

这些门控不是官僚主义的繁文缛节，而是质量保障的网络。每一道门都需要一个不同角色的人（或 AI）主动检查、记录、签署。联合欺骗的概率远远低于单点失误。

5.5 判断标签系统

通信日志中使用的判断标签让状态一目了然：

标签系统让 Hermes（或者任何一个查看日志的人类）可以在 5 秒内理解一个任务的当前状态，而不需要阅读几百行的通信记录。

六、运行时层：tmux + Cursor Agent 的执行保障

文档驱动协作定义了「做什么」和「为什么」，但「怎么做」需要一个稳定、可监控的运行时环境。C456 的选择是基于 tmux 的 Cursor Agent 部署。

6.1 为什么选择 tmux

在 C456 的开发环境中，多个 AI Agent 需要同时运行在远程 Linux 服务器上。tmux 提供了一个轻量、可靠的多路复用终端解决方案：

• 持久会话：SSH 断开连接后，tmux 会话继续运行
• 多窗口管理：每个角色有自己的专属窗口
• 状态检测：通过 tmux capture-pane 实时检查 Agent 状态
• 独立工作目录：每个窗口可以在不同的项目目录中工作

6.2 Cursor Agent 在 tmux 中的部署

一个典型的 Cursor Agent 启动流程如下：

# 在远程服务器上创建 tmux 会话
tmux new-session -d -s cursor-dev -n dev -c /path/to/project

# 启动 Cursor Agent
tmux send-keys -t cursor-dev:0 "cursor-agent --model auto agent" Enter

# 等待 Agent 就绪（OAuth 登录、工作区信任等）
sleep 30
tmux capture-pane -t cursor-dev:0 -p -S -3
# 预期输出：→ Plan, search, build anything

6.3 四步消息协议

向已运行的 Cursor Agent 发送消息需要遵循一个精确的四步流程，这是 C456 团队在实践中总结出的关键经验：

1. 验证空闲 + 清空输入缓冲区：用 capture-pane 确认 Agent 当前处于「待命」状态
2. 输入消息（不要敲回车）：tmux send-keys -t cursor:0 "你的消息"
3. 等待 2 秒：确保消息完全写入输入栏
4. 发送回车 + 验证：敲 Enter 触发 Agent 处理，稍后 capture-pane 确认消息已被接收

这个看似简单的协议解决了 C456 早期开发中反复出现的「输入被吞」「消息与前一输出混淆」「回车丢失」等问题。在 AI 代理的异步交互中，节奏控制至关重要——发送过快、过慢都会导致通信失败。

6.4 监控守护进程

为了自动检测 Agent 完成任务（状态从 executing 变为 stopped），C456 团队开发了一个监控守护进程：

# 注册 Agent 组
python3 -m core.monitor group-create c456-react --label "c456-react team"
python3 -m core.monitor add --group c456-react cursor-dev 0 --label "Dev"
python3 -m core.monitor add --group c456-react cursor-arch 0 --label "Arch"

# 启动守护进程
python3 -m core.monitor daemon --group c456-react

守护进程持续轮询 tmux 中 Agent 的状态，在检测到 CURSOR-STOPPED 事件时通过 Hermes 的通知系统向上汇报。这样 Hermes 不需要轮询——它只需要等待通知，然后检查输出、做出判断、继续下一个步骤。

七、任务流转全景：从需求到上线的十二步

理论说够了，我们来看一个真实的任务在 C456 虚拟团队中是如何流转的。假设 PO 提出：「我们需要为信号（Signal）列表增加一个标签筛选功能。」

标准交付链

Step 1:  PM + PO      Init ──→ comm + spec placeholder
Step 2:  PO            Design Freeze ──→ spec `approved`, comm `APPROVED` → PM
Step 3:  PM            Schedule ──→ plan with tasks, comm schedule → Arch
Step 4:  Arch          Pre-review ──→ comm `ARCH_PRE_PASS` + ADR → PO
Step 5:  PO            Assign ──→ comm Handoff → Dev（三要素）
Step 6:  Dev           Implement ──→ code + tests + verification → Arch
Step 7:  Arch          Code Review ──→ review + comm `ARCH_PASS/FAIL` → Analyst（PASS）/ Dev（FAIL）
Step 8:  Analyst       Verify ──→ DATA_PASS/FAIL + review → PO（PASS）/ Dev（FAIL）
Step 9:  PO            Accept ──→ PRODUCT_ACCEPTED → PM
Step 10: PM            Commit Request ──→ COMMIT_REQUEST → PO + Dev + Analyst
Step 11: PO/Dev/Analyst Commit Done ──→ git commit + daily; COMMIT_DONE → PM
Step 12: PM            Close ──→ merge + worktree cleanup; TASK_CLOSED

任务的通信日志

在整个流程中，最重要的资产是通信日志（Comm Log）。每次手递手、每次决策、每次阻塞都需要记录。一个典型的日志条目：

## 2026-06-30T14:30CST
agent=Hermes (Coordinator)
Skills used: doc-driven-multi-agent, tmux-cursor-agent
Read: docs/superpowers/specs/signal-tags.md, docs/superpowers/plans/2026-06-30-signal-tags.md
Said / Decided:
- PO 确认 MVP 范围：信号标签的 CRUD + 列表筛选，不考虑批量操作
- Arch 预审通过：现有 SignalController 只需新增 index 参数，不需要重构
Blockers: 无

**Handoff:**
- **Target:** 开发者 (Dev)
- **Address:** `.worktrees/feat-signal-tags/`
- **Task:** 按 plan 任务 1-4 实现标签功能；TDD 流程；完成后提交验证证据

Git 工作树隔离

每个任务都在独立的 Git 工作树中完成。这保证了：

1. 多个任务可以并行开发：Dev Agent 在 feat-signal-tags 工作树中工作，同时 Arch Agent 可以在 feat-api-v2 工作树中进行架构审查
2. 主分支不受干扰：即使某个工作树中的开发完全失败，主分支也不会被污染
3. 工作树生命周期由 PM 管理：创建、分配、清理——流程纪律贯穿始终

# PM 在 G2 门控开启后创建工作树
git fetch origin
git worktree add .worktrees/feat-signal-tags -b feat/signal-tags origin/main

# Dev 在指定工作树中工作
cd .worktrees/feat-signal-tags
# ... implement, test, verify ...

# PM 在 G4 门控通过后清理
git checkout main && git pull
git merge feat/signal-tags
git worktree remove .worktrees/feat-signal-tags
git branch -d feat/signal-tags

八、越界拒绝体系：让 AI 对「不合理」的要求说「不」

在所有多角色协作体系中，角色越界是最常见的破坏力量。一个效率很高的 Developer Agent 写完了代码，看到 spec 中有个模糊的地方，顺手把 spec 改了——这看起来是「积极主动」，但实际上破坏了 PO 定义产品的权力。

C456 的协作体系引入了三层越界拒绝机制：

拒绝脚本的范本：

我是 Developer (Dev)。你请求的任务（「把 API 接口从 RESTful 改成 GraphQL」）属于
Architect (Arch)，不是我的角色。我不会执行它。

正确的路径：
1. comm Handoff → Target: Architect (Arch)
2. Address: 架构决策记录路径
3. Task: 评估 GraphQL vs RESTful 的迁移方案

如果你仍然坚持要我（作为 Dev）执行，请明确书面确认第 3 次；
确认后我会记录 OVERRIDE_ROLE_BOUNDARY 并继续。

这个系统看起来有些过度设计——但在实践中，我们遇到过无数次 Agent 因「帮忙」而引入技术债务的情况。越界拒绝不是为了制造障碍，而是为了防微杜渐。

九、实战场景：C456 React 项目的一天

让我们通过一个真实的开发日来感受这套体系的实际运作。以下是某个星期三发生在 C456 React 项目（c456-react）中的开发流水线。

上午 9

— PO 提出需求

PO（人类开发者）通过 Hermes 提交需求：「信号详情页需要显示该信号的引用统计——有多少内容引用了它，并支持点击跳转到引用列表。」

上午 9

— Hermes 启动 G0

Hermes（协调者）：

1. 创建通信日志占位符 comms/signal-references.md
2. 创建 spec 占位符
3. 在 Git 主库中执行 git worktree add .worktrees/feat-signal-refs -b feat/signal-refs origin/main
4. 在 tmux 中为 Dev Agent 和 Arch Agent 创建会话窗口

上午 9

— PO 完成 Spec

PO 完成了 spec 的 <details> 部分：

• MVP 边界：只展示引用数量 + 可点击跳转列表；不包含趋势图或导出
• 不接受的标准：加载时间不得超过 500ms；空状态需要友好的占位文本
• 数据类型：引用来源类型（playbook/intake/tool/channel）需显示图标区分

上午 10

— Arch 预审

Arch Agent 在 tmux 会话中被激活。它读取了 spec 和现有代码结构，在通信日志中记录：

• ARCH_PRE_PASS：现有 SignalController 有 show 和 references 两个方法，可以直接复用
• 建议：引用统计直接通过 counter_cache 实现，不需要额外的查询优化
• 无 ADR 需要——修改范围明确，不影响现有架构

上午 10

— PM 拆解计划

PM Agent 将任务拆解为 5 个计划项：

1. 在 Signal 模型中添加 has_many :references 关联 + counter_cache
2. 在 API 中暴露引用统计接口
3. 在详情页 UI 中添加引用统计板块
4. 实现引用列表弹窗（带类型过滤）
5. 添加空状态和加载状态处理

上午 10

— Dev 开始实现

Dev Agent 在其 tmux 窗口中被激活，手递手三要素齐全。它按照 TDD 流程开始工作：

• 先写模型关联的数据库迁移和测试（红）
• 实现模型关联（绿）
• 写 API 端点的请求规范测试（红）
• 实现 API（绿）
• ...（每个步骤循环）

下午 2

— Dev 完成 + 提交审查证据

Dev 完成了所有 5 个任务项，提交了验证证据：

• 测试覆盖率报告（96%）
• API 响应时间（avg 23ms）
• 截图：详情页显示引用统计、弹窗列表、空状态
• 通信日志更新：Handoff → Target: Architect (Arch)

下午 2

— Arch 审查

Arch Agent 被通知（通过 CURSOR-STOPPED 事件）并开始代码审查。检查了：

• 架构合规性：没有违反现有模式
• 代码质量：Rails 惯用法使用正确
• 安全隐患：新增接口做了分页限制，防 N+1
• 结论：ARCH_PASS

下午 2

— Analyst 验证

Analyst Agent 检查：

• 功能完整性：所有 5 个计划项都实现了
• 边缘情况：无数据时显示空状态；大量引用时分页正常
• 数据一致性：引用的计数与数据库记录一致
• 结论：DATA_PASS

下午 2

— PO 验收

PO（人类）检查了部署预览后，签署 PRODUCT_ACCEPTED。

下午 3

— PM 关闭

PM Agent 执行 COMMIT_REQUEST，三个角色分别签署 COMMIT_DONE。PM 最后：

• 合并到 main 分支
• 清理工作树 (git worktree remove .worktrees/feat-signal-refs + git branch -d feat/signal-refs)
• 关闭任务：TASK_CLOSED

从需求提出到合并上线，一个完整的特性——包含 spec、计划、架构审查、TDD 实现、代码审查、数据验证、验收、合并——在 6 小时内完成。

对于传统开发团队，这至少需要 2-3 天（如果沟通顺畅的话）。更重要的是：每一步都有文档记录，每次手递手都有审计追踪，每个决策都经过至少一个其他角色的验证。

十、挑战与教训

当然，这套体系不是一蹴而就的。在从「单人+AI」向「虚拟团队」转型的过程中，C456 团队踩过了不少坑。

10.1 Agent 状态检测的不可靠性

问题：通过 tmux capture-pane 检测 Agent 状态不是 100% 可靠的。有时候 Agent 已经完成了任务，但 pane 内容仍显示 executing；有时候看似空闲，实际上后台进程正在静默处理。

解决方案：

• 引入两层检测机制：除了 tmux pane 状态外，还监视文件系统变更（工作树中的新提交）
• 守护进程的 watch_patterns 配合 Hermes 的 notify_on_complete，双重确认
• 增加显式确认步骤：手递手后，接收方必须在 comm log 中声明「已读取并接受任务」

10.2 上下文窗口溢出

问题：长时间运行的 Cursor Agent 会话逐渐填满上下文窗口，导致模型「失忆」——忘记初期的需求细节和架构决定。

解决方案：

• 严格限制每个 Agent 会话的持续时间（不超过一个完整的计划项）
• 任务之间强制 comm log 手递手——关键上下文沉淀为文档，不依赖 Agent 记忆
• 使用 Hermes 的 /compress 命令定期压缩上下文
• 复杂特性中间增加「Arch 同步检查点」，同步状态后重新加载 Agent

10.3 文档冗余与「过度记录」

问题：早期执行中，团队要求在每次手递手后都重写完整的上下文摘要，导致文档量急剧膨胀，反而降低了阅读效率。

解决方案：

• 引入「增量日志」原则：comm log 只记录与上一次手递手不同的信息，已有内容通过 Address 字段引用
• Read: 字段必须引用已有文档路径，而不是重写它们的内容
• 门控检查允许跳过某些低风险任务的部分文档要求

10.4 固定协议 OR 灵活适配？

问题：简单任务（如修复 typo）也走完整的 G0-G4 流程，明显过于冗余。

解决方案：

• 引入「特例」机制：改动 ≤3 个文件且 comm 标记 EXCEPTION: trivial 的任务可以跳过 G1/G2
• 复杂的架构变更（>3 文件、新模块、存储变更）必须走完整流程
• 这个「分级响应」在 doc-driven-multi-agent 技能中被定义为默认规则

十一、成果与数据

这套体系在 C456 项目中运行了几个月后，积累了一些值得分享的数据：

效率指标

质量指标

• 代码审查通过率：首次提交即通过 Arch 审查的比例约 60%，说明 Dev 和 Arch 之间存在质量对话
• Analyst DATA_FAIL 率：约 15% 的 Dev 交付物在 Analyst 阶段发现至少一个可复现的问题——这证明了「第三双眼睛」的价值
• 门控拦截率：约 5% 的特性在某个门控阶段被红灯拦截（主要是 spec 定义不清晰），避免了「做完了发现不对」的浪费

团队感知

人类开发者（辉哥）的反馈：

「以前我写代码时总感觉自己是『一个人在战斗』——虽然 AI 帮我写了很多代码，但没有人帮我审查、没有人提醒我边界、没有人记录我为什么做了某个决策。多 Agent 体系带来的最大改变不是速度，而是安心感——我知道交付的代码至少经过了架构审查和数据验证，我知道如果出了问题可以从 comm log 追溯到决策点。」

十二、未来展望

当前 C456 的多 Agent 协作体系已经稳定运行，但远未达到它的最终形态。以下几个方向是正在探索或计划中的：

12.1 实时协作板（Kanban）

Hermes 内置的 Kanban 系统正在被引入 C456 的工作流。Kanban 提供了一个 SQLite 支持的持久化任务板，让多 Agent 可以异步认领、更新、完成任务。这比完全依赖 tmux + 文件文档的模型更结构化，也更容易被人类开发者可视化地理解。

12.2 自适应角色分配

当前的五角色模型是固定的——每个任务都走 Arch → Dev → Analyst → PO → PM。但实际中，不同特性的复杂度差异巨大。正在开发的是自适应角色路由：简单任务（单文件修改）直接走 Dev → PO 快车道；复杂特性走完整链路。

12.3 多语言 Agent 互操作

当前体系中的 Agent 都运行在 Hermes/Cursor 生态中。未来正在探索的是如何将专业领域的 AI 工具（如数据可视化的专用 Agent、安全审计的专用 Agent、UI 设计的专用 Agent）作为「插件角色」接入标准的手递手协议。

12.4 自动化门控检查

当前的 G0-G4 门控还需要一定程度的人工判断（尤其是 PO 的验收）。长期目标是将更多门控条件自动化：例如，G3 的 DATA_PASS 检查可以基于预定义的测试用例自动触发和判断，只有当自动化检查失败或需要人类判断时才触发人工介入。

十三、如何开始你自己的多 Agent 团队

如果你对这个体系感兴趣，想在自己的项目中实践多 Agent 协作，有两种方式体验：一键启动 或 逐手上路。

🚀 一键启动：把这段话发给 AI

复制下面这段提示词，发给你的 Hermes Agent（或 Claude、ChatGPT 等 AI 助手），它会自动帮你完成所有设置：

请按照以下步骤，在我的项目中搭建多 Agent 协作体系（doc-driven-multi-agent）：

1. **安装 Hermes Agent**（如果尚未安装）：
   - 执行 `curl -fsSL <https://hermes-agent.nousresearch.com/install.sh> | bash`

2. **安装核心技能**：
   - `hermes skills install c456-com/skills/tmux-cursor-agent`
   - `hermes skills install c456-com/skills/doc-driven-multi-agent`

3. **创建文档骨架**（在当前项目根目录）：
   - 创建 `AGENTS.md`：写入代理启动清单，引用 WORKFLOW.md
   - 创建 `docs/ops/WORKFLOW.md`：复制 doc-driven-multi-agent 协议全文
   - 创建 `docs/product/GOALS.md`：写入项目目标（如果未知，先创建占位符）

4. **初始化 Git 工作树支持**：
   - 执行 `mkdir -p .worktrees`
   - 确认当前在 main 分支，执行 `git worktree add .worktrees/_template -b _init/main origin/main` 验证工作树正常，然后删除 `git worktree remove .worktrees/_template && git branch -D _init/main`

5. **创建第一个特性的通信日志和 spec 占位符**：
   - 在 `docs/superpowers/comms/` 下创建以特性命名的 .md 文件
   - 在 `docs/superpowers/specs/` 下创建对应的 spec 占位符

每完成一步都向我确认结果，遇到问题就停下来问我。开始吧！

粘贴后，AI 会依次执行每一步，每完成一步向你确认。不想对话式操作？下面是完整的分步说明，适合喜欢自己动手的读者。

📋 分步上手（动手派路线）

如果你对这个体系感兴趣，想在自己的项目中实践多 Agent 协作，这里是最精简的启动路径：

第一步：安装 Hermes Agent

curl -fsSL <https://hermes-agent.nousresearch.com/install.sh> | bash

第二步：安装核心技能

# 安装文档驱动多代理协作技能
hermes skills install c456-com/skills/tmux-cursor-agent
hermes skills install c456-com/skills/doc-driven-multi-agent

第三步：创建文档骨架

在项目根目录创建：

• AGENTS.md — 代理启动清单
• docs/ops/WORKFLOW.md — 工作流定义
• docs/product/GOALS.md — 产品目标

第四步：选择一个特性，走一遍

不要试图一开始就搭建完整的体系。选一个小特性，人工走一遍 Arch → Dev → Analyst → PO → PM 的完整链，感受一下文档驱动的节奏。

第五步：逐步完善

• 添加更多角色 SOP
• 引入 Git 工作树隔离
• 部署监控守护进程
• 集成持续交付

关键是：从第一天就对手递手三要素「零容忍」。没有完整三要素的手递手不接受，没有文档记录的决策不承认。这套体系的强度来自于纪律，而不是工具。

结语

软件开发在过去二十年中经历了从「单人作坊」到「团队协作」，再到「AI 辅助」的演变。今天，我们可能正在见证下一个范式转移的起点：从「人类团队 + AI 工具」到「人类 + AI 虚拟团队」。

在 C456 的实践中，Hermes Agent 不是取代任何人的工具——它是一座桥梁。它连接了人类的战略视野与 AI 的执行能力，连接了架构师的系统思维与开发者的实现细节，连接了产品定义的「为什么」与代码实现的「怎么做」。

如果软件开发的下一个十年真的属于「人类与 AI 的深度协作」，那么这种协作需要的不仅仅是更聪明的模型，更是更好的协作协议、更清晰的角色分工、以及更可靠的执行纪律。

C456 的开源实践只是一个开始。我们希望这套体系能激发更多的探索——无论你是一个独立开发者、一个小团队、还是一个大型组织，多 Agent 协作的理念都值得在你的下一个项目中试一试。

延展阅读：

• C456 是如何开发出来的 — 项目全景介绍
• AI 开发五大核心技能工具组合打法 — 从代码规范到产品交付
• tmux-cursor-agent — 运行时层源码
• doc-driven-multi-agent — 协作协议源码
• Hermes Agent 官方文档 — 配置与使用指南

本文中使用的配图来自 Unsplash 免费图片库。