编辑文档 - 实战！用 Hermes Kanban 盘活我的 AI 团队：任务自动流转，全程不用催

标题

工具栏

点击或拖拽上传图片

支持 PNG, JPG, GIF, WebP 格式

内容 (Markdown 格式)

# 实战！用 Hermes Kanban 盘活我的 AI 团队：任务自动流转，全程不用催

上一篇文章（doc/21）我们聊了怎么用 Profile 把自己克隆成一整支 AI 团队—— researcher、analyst、writer、reviewer 各有各的角色设定和专属技能。

但光有角色不够，**谁来派活？谁等谁？谁说了算？**

这就是今天要聊的：**Hermes Kanban**。它解决的是多角色协作里的核心问题——任务流转、依赖管理、结果交付。经过几个项目的测试和实践，真心觉得这是目前最好用的多 Agent 协作方案。

---

## 一、先说痛点：为什么 Profile 协作需要 Kanban

你有多个 Profile 之后，正常流程是这样：

```
用户 → orchestrator（我）→ 拆解任务 → delegate_task 给 researcher
→ researcher 完成 → delegate_task 给 analyst
→ analyst 完成 → delegate_task 给 writer
→ writer 完成 → 返回用户
```

问题来了：

- analyst 怎么知道 researcher 什么时候做完？轮询？写死等待时间？
- researcher 跑了一半卡住了，谁来重试？
- 用户中途想改需求，已经在跑的 task 怎么处理？
- 跑了 2 小时，中间哪步挂了完全不知道

用 `delegate_task` 做流水线，单任务是顺的。但**多角色 + 多任务 + 长期运行**，你需要一块真正的看板。

---

## 二、Hermes Kanban 是什么

Hermes Kanban 是 Hermes Agent 内置的任务管理系统，每张卡片的生命周期如下：

```
ready → in_progress → done（或 blocked / archived）
```

核心特性：

| 特性 | 说明 |
|------|------|
| 任务依赖 | `parents=[task_id]` 挂在父任务完成前 |
| 跨 Profile 流转 | assignee 指定执行角色 |
| 心跳保活 | 长时间任务自动续命 |
| 阻塞机制 | 需要人工介入时 block，等你回来 |
| 自动推进 | dispatcher 监听 ready 状态，自动派给对应 Profile |

---

## 三、完整示例：写一篇产品分析报告

需求很简单：**分析最近 3 个月的 AI 编程工具市场，写一篇报告给 CTO 看**。

### 1. 规划任务图

这是最关键的一步——**先画图，再开工**。谁来规划？就是你自己（或者你作为 orchestrator 的角色）。

这里有个很重要的分工需要提前说清楚：

| 工作 | 谁来做 |
|------|--------|
| 规划任务图（拆解需求、画任务依赖） | **你自己**，或者 orchestrator Profile |
| 写 `kanban_create` 代码 | **你自己**，调用 `kanban_create` 工具 |
| 任务执行（research、analyze、write） | 对应的 worker Profile，自动被 dispatcher 调度 |
| 人工介入（block 处理、异常恢复） | **你自己**，看板上有提示才会找你 |

换句话说：**任务图是你画的，代码是你写的，Kanban 负责把任务跑起来、流转起来**。不是 Kanban 自动替你规划——这个分工必须搞清楚，不然你会等 Kanban "自己帮你分解任务"等到崩溃。

规划出来的任务图是这样的：

```
T1a  researcher   调研 AI 编程工具市场现状（2025 Q1-Q2）
T1b  researcher   调研开发者社区对主流工具的口碑变化
T1c  researcher   调研投融资情况
T2a  researcher   调研 Cursor 竞品动态
T2b  researcher   调研新兴 AI 编程工具（国产为主）
T3   analyst      汇总 T1a-T2b，生成市场分析报告
T4   reviewer     审核 T3 报告，给出修改意见
T5   writer       根据审核意见，输出 CTO 版报告
```

三个 researcher 并行跑 T1a/T1b/T1c/T2a/T2b（每人负责一个方向），analyst 等全部完成后开始 T3，reviewer 把关 T4，writer 负责最终输出。

### 2. 创建任务

规划完任务图，接下来要把这些任务创建到 Kanban 看板里。这一步需要你在 orchestrator 的对话里，调用 `kanban_create` 工具把这些任务一个个写进去。

下面是一段完整的示例代码（可以直接复制到你自己的 orchestrator Profile 里修改使用）：

```python
import os

# T1a - researcher 并行调研 AI 编程工具市场
t1a = kanban_create(
    title="research: AI 编程工具市场现状（2025 Q1-Q2）",
    assignee="researcher",
    body="""调研 AI 编程工具市场现状，重点包括：
1. 市场规模与增长率（数据来源：公开财报、行业报告）
2. 主流玩家市场份额变化
3. 技术趋势（上下文窗口、Agent 能力、多模态）
输出格式：Markdown 要点列表，附数据来源链接""",
    tenant=os.environ.get("HERMES_TENANT"),
)

# T1b - researcher 并行调研开发者社区热度
t1b = kanban_create(
    title="research: 开发者社区对主流工具的口碑变化",
    assignee="researcher",
    body="""从以下渠道收集开发者对 Cursor、Claude Code、OpenCode 的评价趋势：
1. GitHub Stars 增长曲线（近 6 个月）
2. Stack Overflow / Hacker News 讨论热度
3. X/Twitter 开发者圈的口碑反馈
输出格式：时间线 + 关键事件标注""",
)

# T1c - researcher 并行调研投融资情况
t1c = kanban_create(
    title="research: AI 编程工具赛道投融资动态",
    assignee="researcher",
    body="""调研 2024Q4-2025Q1 期间，AI 编程工具相关公司的融资事件：
1. 融资金额与轮次
2. 投资方背景
3. 资金用途与战略方向
输出格式：表格 + 关键洞察""",
)

# T2a - researcher 调研 Cursor 竞品
t2a = kanban_create(
    title="research: Cursor 竞品动态（Claude Code、OpenCode）",
    assignee="researcher",
    body="""深度调研竞品近况：
1. Cursor：最近 3 个月的大版本更新、用户增长数据
2. Claude Code：Anthropic 的商业化进展
3. OpenCode：生态建设与社区反馈
输出格式：各工具单独章节，含关键时间节点""",
)

# T2b - researcher 调研新兴玩家
t2b = kanban_create(
    title="research: 新兴 AI 编程工具（国产为主）",
    assignee="researcher",
    body="""调研国产 AI 编程工具：
1. 阿里云通义灵码、百度 Coding助手、字节扣子的最新进展
2. 独立开发者社区的反馈
3. 定价策略对比
输出格式：竞品对比表""",
)

# T3 - analyst 汇总所有调研结果
t3 = kanban_create(
    title="analyze: 汇总市场分析报告",
    assignee="analyst",
    body="""读取 T1a、T1b、T1c、T2a、T2b 的调研结果，整合成一份市场分析报告。
报告结构：
1. 执行摘要（1页）
2. 市场现状（2-3页）
3. 竞争格局（2-3页）
4. 技术趋势判断（1-2页）
5. 战略建议（1页）
要求：数据说话，避免空泛结论""",
    parents=[t1a, t1b, t1c, t2a, t2b],
)

# T4 - reviewer 审核报告
t4 = kanban_create(
    title="review: 审核市场分析报告",
    assignee="reviewer",
    body="""审核 T3 的市场分析报告，重点检查：
1. 数据来源是否可靠、是否过期
2. 逻辑是否自洽，有没有自相矛盾的地方
3. 结论是否有数据支撑
4. 表述是否客观，有没有明显偏向
输出：修改意见清单（blocking issues）+ 认可点""",
    parents=[t3],
)

# T5 - writer 输出最终 CTO 报告
t5 = kanban_create(
    title="write: 输出 CTO 版最终报告",
    assignee="writer",
    body="""根据 reviewer 的修改意见，修订 T3 的报告，输出最终 CTO 版。
要求：
1. 语言精炼，去掉所有废话
2. 结论要明确，不能模棱两可
3. 附一页关键数据摘要（供决策参考）
4. 格式：Markdown，方便内部分享""",
    parents=[t4],
)

# 完成 orchestrator 的规划任务
kanban_complete(
    summary="已创建 T1a-T5 共 8 个任务：5个 researcher 并行调研，1个 analyst 汇总，1个 reviewer 把关，1个 writer 输出最终报告",
    metadata={
        "task_graph": {
            "T1a": {"assignee": "researcher", "parents": []},
            "T1b": {"assignee": "researcher", "parents": []},
            "T1c": {"assignee": "researcher", "parents": []},
            "T2a": {"assignee": "researcher", "parents": []},
            "T2b": {"assignee": "researcher", "parents": []},
            "T3":  {"assignee": "analyst",   "parents": ["T1a","T1b","T1c","T2a","T2b"]},
            "T4":  {"assignee": "reviewer",  "parents": ["T3"]},
            "T5":  {"assignee": "writer",     "parents": ["T4"]},
        },
        "total_tasks": 8,
    },
)
```

### 3. 任务自动流转，不用催

创建完成后，dispatcher 自动监听 ready 状态的卡片。

**T1a-T2b 这 5 个卡片直接进入 ready**，researcher Profile 的 worker 会被自动调度，每人抢一个任务开始干活——**完全并行，不用我发话**。

T3 因为声明了 `parents=[t1a, t1b, t1c, t2a, t2b]`，会一直卡在 ready 之前（实际上是 pending 状态），等 5 个父任务全部 done 才自动晋升为 ready。

analyst 拿到 T3，开始综合分析。完成后 T4 进入 ready，reviewer 上。

如果 reviewer 发现问题——比如某个数据来源不可靠——他会 `kanban_block(reason="T3 的第三方数据需要核实来源，请补充")`，然后这张卡就停在 blocked，等我人工介入。

我处理完反馈，reviewer 继续，T5 启动，writer 输出最终报告。

**全程我只做了一件事：规划任务图 + 创建任务**。剩下的流转、等待、重试，Kanban 全包。

---

## 四、我踩过的坑

### 坑 1：忘记传 tenant，导致子任务丢失

如果你的环境设置了多租户隔离（`HERMES_TENANT`），但创建子任务时漏传了 `tenant=os.environ.get("HERMES_TENANT")`，这些任务会创建在默认租户下，和父任务不在同一个命名空间，**依赖关系直接断掉**，子任务永远等不到父任务完成。

解决：创建任务时一律显式传 tenant。

### 坑 2：blocking reason 写得太模糊

我第一次用的时候，reviewer 写了句 "needs improvement" 就 block 了。等我打开看板完全懵——**哪里要改？为什么改？完全没有上下文**。

后来强制自己：block 必须一句话说明核心问题，详细背景写在 `kanban_comment` 里。

```python
# 好例子
kanban_comment(task_id=t4, body="完整背景：第三方数据来源是 XXX 网站，该网站在 2024 年停止更新...")
kanban_block(reason="第三方数据来源已停更，需替换为可靠来源")

# 坏例子
kanban_block(reason="数据有问题")
```

### 坑 3：用 delegate_task 代替 kanban_create

一开始我偷懒，想"反正都在同一个对话里，直接 delegate_task 给 researcher 不就行了"。

结果：researcher 的输出直接返回到我这里，我再手动整理再派给 analyst，analyst 的输出再手动派给 writer。中间任何一个环节出了问题——模型重启、上下文丢失——整条链全断。

教训：`需要跨 Agent 交付、长周期运行、人工可能中途介入` 的任务，一律用 `kanban_create`，不要用 `delegate_task`。

### 坑 4：worker 崩溃后没有 reclaim

researcher 跑了 30 分钟突然挂了（OOM），我看看板显示它还卡在 in_progress。等了 1 小时才发现它其实早就失败了。

解决：看到 worker 长时间没心跳，直接 `hermes kanban reclaim <task_id>` 重置任务状态，别傻等。

---

## 五、真实数据：我的协作效率

经过多个项目的测试和实践，接了 10 个项目，以下是我的真实数据：

| 指标 | 纯 delegate_task | + Kanban |
|------|-------------------|----------|
| 平均项目完成时间 | 4.2 小时 | 3.1 小时 |
| 人工介入次数 | 4.3 次/项目 | 0.7 次/项目 |
| 任务失败率 | 12% | 2% |
| 输出质量评分（1-10） | 7.1 | 8.4 |

最明显的变化：**我不用再盯着谁做完没做了**。看板上一眼看清所有任务状态，有问题才介入。Kanban 把"协调成本"这件事，几乎降到了零。

---

## 六、什么时候不用 Kanban

Kanban 不是银弹。以下情况直接用 Profile 对话或 `delegate_task` 就够了：

- 单次任务，不需要多角色
- 5 分钟内能完成的简单问答
- 纯调研，不需要交付结构化文档

---

## 写在最后

Profile 给了每个 AI 角色灵魂，Kanban 给了他们分工协作的秩序。

有了这块看板之后，我的 AI 团队终于从"我喊一嗓子他们各自干活"进化成了"任务自己跑、结果自己交付、中途有情况才来找我"的状态。

这才是多角色协作该有的样子。

**你在用多 Profile 协作吗？遇到了什么协调难题？评论区聊聊。**

摘要

标签多个标签用逗号分隔

分类