上一篇文章（doc/21）我们聊了怎么用 Profile 把自己克隆成一整支 AI 团队—— researcher、analyst、writer、reviewer 各有各的角色设定和专属技能。
但光有角色不够，谁来派活？谁等谁？谁说了算？
这就是今天要聊的：Hermes Kanban。它解决的是多角色协作里的核心问题——任务流转、依赖管理、结果交付。经过几个项目的测试和实践，真心觉得这是目前最好用的多 Agent 协作方案。
你有多个 Profile 之后，正常流程是这样：
用户 → orchestrator（我）→ 拆解任务 → delegate_task 给 researcher
→ researcher 完成 → delegate_task 给 analyst
→ analyst 完成 → delegate_task 给 writer
→ writer 完成 → 返回用户
问题来了：
用 delegate_task 做流水线，单任务是顺的。但多角色 + 多任务 + 长期运行，你需要一块真正的看板。
Hermes Kanban 是 Hermes Agent 内置的任务管理系统，每张卡片的生命周期如下：
ready → in_progress → done（或 blocked / archived）
核心特性：
| 特性 | 说明 |
|---|---|
| 任务依赖 | parents=[task_id] 挂在父任务完成前 |
| 跨 Profile 流转 | assignee 指定执行角色 |
| 心跳保活 | 长时间任务自动续命 |
| 阻塞机制 | 需要人工介入时 block，等你回来 |
| 自动推进 | dispatcher 监听 ready 状态，自动派给对应 Profile |
需求很简单：分析最近 3 个月的 AI 编程工具市场，写一篇报告给 CTO 看。
这是最关键的一步——先画图，再开工。谁来规划？就是你自己（或者你作为 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 负责最终输出。
规划完任务图，接下来要把这些任务创建到 Kanban 看板里。这一步需要你在 orchestrator 的对话里，调用 kanban_create 工具把这些任务一个个写进去。
下面是一段完整的示例代码（可以直接复制到你自己的 orchestrator Profile 里修改使用）：
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,
},
)
创建完成后，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 全包。
如果你的环境设置了多租户隔离（HERMES_TENANT），但创建子任务时漏传了 tenant=os.environ.get("HERMES_TENANT")，这些任务会创建在默认租户下，和父任务不在同一个命名空间，依赖关系直接断掉，子任务永远等不到父任务完成。
解决：创建任务时一律显式传 tenant。
我第一次用的时候，reviewer 写了句 "needs improvement" 就 block 了。等我打开看板完全懵——哪里要改？为什么改？完全没有上下文。
后来强制自己：block 必须一句话说明核心问题，详细背景写在 kanban_comment 里。
# 好例子
kanban_comment(task_id=t4, body="完整背景：第三方数据来源是 XXX 网站，该网站在 2024 年停止更新...")
kanban_block(reason="第三方数据来源已停更，需替换为可靠来源")
# 坏例子
kanban_block(reason="数据有问题")
一开始我偷懒，想"反正都在同一个对话里，直接 delegate_task 给 researcher 不就行了"。
结果：researcher 的输出直接返回到我这里，我再手动整理再派给 analyst，analyst 的输出再手动派给 writer。中间任何一个环节出了问题——模型重启、上下文丢失——整条链全断。
教训：需要跨 Agent 交付、长周期运行、人工可能中途介入 的任务，一律用 kanban_create，不要用 delegate_task。
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 不是银弹。以下情况直接用 Profile 对话或 delegate_task 就够了：
Profile 给了每个 AI 角色灵魂，Kanban 给了他们分工协作的秩序。
有了这块看板之后，我的 AI 团队终于从"我喊一嗓子他们各自干活"进化成了"任务自己跑、结果自己交付、中途有情况才来找我"的状态。
这才是多角色协作该有的样子。
你在用多 Profile 协作吗？遇到了什么协调难题？评论区聊聊。
💬 评论区