Hermes Kanban 入门手册：多智能体协作的正确姿势
版本：基于 kanban-orchestrator v2.0.0 和 kanban-worker v2.0.0 创建时间：2026-05-07 目标读者：初次使用 Hermes Kanban 多智能体协作系统的用户
开篇
容我先说句不太中听的话：如果你还在用 delegate_task 处理所有复杂任务，那你大概每天都在经历同一件事——任务跑着跑着断了，上下文丢了，然后你不得不从头再来。
这不是你的问题。这是工具的问题。
Hermes Kanban 解决的就是这个事：当任务复杂到需要多个 AI 专家协作、需要抗崩溃、需要审计追踪的时候，你该怎么组织它们？
答案不是"更聪明的 prompt"，而是一套协作系统。
为什么需要看板？
先说个常识。《孙子兵法》讲：“凡治众如治寡，分数是也。” 管理大部队和管理小分队，道理不一样。
AI 协作也一样。
一个小任务，一次推理就能搞定——直接用 delegate_task 或者让 AI 自己答，没问题。但当任务变成这样：
- 需要研究员查资料、工程师写代码、测试员跑测试，三个角色协作
- 任务跑了一半，服务挂了，重启后还能接着干
- 你需要在中途介入，看看进度，改改方向
- 子任务之间有依赖关系，A 没完 B 不能动
这时候，“更聪明的 prompt” 不管用了。你需要的是一个任务管理系统，而不是一句更好的话。
Hermes Kanban 的核心概念就四个：
| 概念 | 说明 |
|---|---|
| Task（任务） | 看板上的卡片，包含标题、描述、状态、负责人 |
| Profile（专家） | 具有特定技能的 AI 角色（researcher、writer、backend-eng 等） |
| Parent-Child（父子关系） | 任务之间的依赖关系，子任务等父任务完成 |
| Status（状态） | todo → ready → running → completed/blocked/archived |
说白了，就是把复杂任务拆成卡片，分给不同的人，然后看着它们一张张翻过去。
两个角色：包工头和工人
Hermes Kanban 的设计哲学很朴素：拆任务的人和干活的人，必须是两个角色。
编排者（Orchestrator）：包工头
包工头的工作就五件事：
- 理解你要干什么
- 画一张任务图——谁先干、谁后干、谁可以并行
- 把任务分出去
- 向你汇报结构
- 不自己干活
第五条最重要。编排者最大的陷阱就是"这个我顺手就干了"。别干。你的工作是路由，不是施工。
标准专家名册长这样：
| Profile | 职责 | 典型工作空间 |
|---|---|---|
researcher | 查资料、收集事实 | scratch（临时目录） |
analyst | 综合分析、去重、排名 | scratch |
writer | 按用户风格写文档 | scratch 或 vault |
reviewer | 审查输出、把关 | scratch |
backend-eng | 写服务端代码 | worktree（Git 工作树） |
frontend-eng | 写客户端代码 | worktree |
ops | 跑脚本、管服务 | dir: 脚本仓库 |
pm | 写需求规格、验收标准 | scratch |
工人（Worker）：干活的专家
工人拿到的任务已经拆好了，他要做的是四步：
- Orient（定向）：读任务详情，检查环境
- Work（工作）：在分配的工作空间里干活
- Heartbeat（心跳）：定期汇报进度（可选，几分钟一次）
- Complete/Block（完成/阻塞）：提交结果，或者请求人工介入
工人的陷阱跟编排者正好相反——工人容易越界。比如用 delegate_task 替代 kanban_create 来创建子任务。前者是短期推理，后者是跨任务交接，不是一回事。
任务是怎么流转的
状态机长这样：
created → ready → running → completed
↓
blocked → (unblock) → ready
↓
crashed/timed_out → ready (重试)
↓
archived (最终状态)核心机制是依赖自动管理：
- T1 完成了，状态变
completed - 调度器检测到 T2 的依赖（T1）已满足
- T2 自动从
todo变ready，等待派发 - T3 同理
你不需要手动触发。系统会自动把满足依赖的任务推过去。
实战：用户认证系统
说个具体的。用户说：“帮我实现一个用户认证系统，包括方案调研、代码实现和测试。”
编排者会这样处理：
第一步，理解目标。 需求明确，需要多个专家，适合用看板。
第二步，画任务图。
父任务：实现用户认证系统
├── T1 (researcher): 调研 OAuth2 和 JWT 方案
├── T2 (backend-eng): 实现认证中间件和 API (依赖 T1)
└── T3 (qa-engineer): 编写单元测试和集成测试 (依赖 T2)第三步，创建任务。 用 hermes kanban create 命令，先建父任务，再建子任务并指定 --parent。
第四步，等工人干活。 T1 研究员调研完提交结果，T2 自动变成 ready，工程师开始写代码。T2 完了 T3 接着跑。
第五步，收工。 所有子任务完成后，完成父任务。
整个过程你只需要在关键时刻介入——比如 T1 研究员遇到决策点，kanban_block() 问你"选 OAuth2 还是 JWT？"——你回答就行。
四种常见协作模式
扇出 + 扇入（Fan-out + Fan-in）
需要并行研究多个方案，然后综合。三个研究员各跑各的，分析师等他们全完了再汇总。
流水线 + 审核门（Pipeline with Gates）
PM 写需求 → 工程师实现 → 审查者把关。审查者可以 kanban_block() 打回，修改后创建新任务，不重新运行原任务。
同专家队列（Same-Profile Queue）
需要翻译 50 个文档？全分给 translator，调度器按优先级串行处理。每个任务都能积累经验到该 profile 的记忆中。
人工介入（Human-in-the-Loop）
关键决策点，工人 kanban_block() 等你确认。你看完回复，kanban_unblock() 继续跑。
踩过的坑
编排者别自己干活
“这个我顺手就干了”——这是编排者最常见的错误。你的工作是路由，不是施工。创建任务，分出去。
工人别幻觉 ID
kanban_complete(created_cards=[...]) 里只能放从 kanban_create 返回值拿到的真实 ID。放幻觉 ID，网关会拦截并记录审计事件。
重试时先读之前的结果
任务是重试（之前运行过）？先看 kanban_show 返回的 runs 字段：
| outcome | 原因 | 处理方式 |
|---|---|---|
timed_out | 超时 | 拆分工作或减少工作量 |
crashed | OOM 或段错误 | 减少内存占用 |
spawn_failed | 缺凭证、坏 PATH | 用 kanban_block 请求人工介入 |
reclaimed | 被操作员归档 | 检查状态，可能不应运行 |
blocked | 之前被阻塞 | 查看 unblock 评论，了解上下文 |
完成时的 summary 要结构化
别写"做完了"三个字。写清楚：做了什么、关键决策是什么、产出了什么。下游任务要靠这个信息继续工作。
好的 summary 长这样：
“调研完成：对比 OAuth2 授权码模式与 JWT 无状态认证，推荐采用 JWT+Redis 方案，支持水平扩展。阅读 8 个资料源，评估了 3 种方案。”
写在最后
《道德经》讲：“治大国若烹小鲜。” 管理多智能体协作系统也一样——别折腾。
Hermes Kanban 的设计思路很清晰：
- 编排者负责拆，工人负责干，各司其职
- 依赖关系自动管理，不用你手动调度
- 任务持久化，崩溃了能恢复
- metadata 结构化，下游能直接用
记住五条就够了：
- 复杂任务用看板，简单问题直接答
- 编排者不干活，只路由
- 工人按生命周期走，别越界
- metadata 要结构化，方便下游解析
- 有疑问就问用户，别盲目执行
就这么简单。
文档基于实际技能文档整理，更多细节请参考：
kanban-orchestrator技能：~/.hermes/skills/devops/kanban-orchestrator/SKILL.mdkanban-worker技能：~/.hermes/skills/devops/kanban-worker/SKILL.md