Appearance
Hermes Agent v0.12.0更新核心：把任务放到看板上，让Agent自己去抢。不是你安排谁干什么，是任务上板，Agent自己认领。
以前的多Agent是怎么干活的
最常见的做法：主Agent调用子Agent。主Agent觉得"该让翻译Agent干了"，于是spawn一个子Agent，等它干完，再spawn下一个。
问题：
- 主Agent得操心所有调度，谁先干谁后干，谁卡住了怎么处理
- 一旦任务复杂了，主Agent自己就成了瓶颈
- 子Agent一旦崩了，整个流程就卡住
这次更新了什么
核心思路：把任务放到看板上，让Agent自己去抢。
底层是本地SQLite数据库，每个任务是一条记录。Agent认领任务走的是原子事务——多个Agent同时抢一个任务，只有一个能抢到。
看板六列
| 状态 | 说明 |
|---|---|
| Triage | 任务刚进来，还没想清楚具体干什么 |
| Todo | 想清楚了，但还在等别的任务完成 |
| Ready | 可以被认领了 |
| In Progress | 正在干 |
| Blocked | 卡住了，需要人帮忙 |
| Done | 搞定 |
Triage不是简单的待办列表，而是让"规划者"先把任务描述、验收标准、依赖关系都写清楚的地方。任务在Triage阶段会被反复打磨。
两个内置角色
| 角色 | 职责 |
|---|---|
| Orchestrator | 拆任务。把大目标拆成具体任务，分配给特定角色 |
| Worker | 干活。看Ready队列里有没有自己能干的活，有就认领 |
关键：Orchestrator不用盯着每个Worker干活。Worker自己会来取。
依赖关系处理
bash
# 创建有依赖关系的任务
hermes kanban create "设计auth数据库schema" --assignee backend-dev
hermes kanban create "实现auth API" --assignee backend-dev --parent $SCHEMA_ID
hermes kanban create "写测试" --assignee backend-dev --parent $API_ID第一个任务完成时，系统自动把第二个任务从Todo提升到Ready。不是手动推，是依赖引擎自动做的。
崩溃处理
| 机制 | 说明 |
|---|---|
| Dispatcher检查 | 定期检查Worker进程是否还活着 |
| 任务释放 | 发现Worker挂了，任务释放回Ready队列 |
| 熔断机制 | 连续失败3次，自动锁到Blocked列，通知你 |
9种协作模式
| 模式 | 说明 |
|---|---|
| 扇出并行 | 大任务拆成多个小任务同时跑 |
| 流水线 | A做完传给B，B做完传给C |
| 投票仲裁 | 多个Agent各出一版，选最好的 |
| 人工介入 | 关键节点等你审批 |
快速开始
bash
hermes kanban init
hermes dashboard
# 浏览器打开 http://127.0.0.1:9119核心价值
| 以前 | 现在 |
|---|---|
| 写脚本串起来 | 定义任务和依赖关系，系统自动调度 |
| subagent delegate层层调 | 任务自己上板，Agent自己抢 |
| 调度逻辑变成Bug来源 | 调度逻辑可视化、可中断、可重试 |
你要做的就是看看看板，偶尔解个锁。
📖 官方文档：hermes-agent.nousresearch.com/docs/user-guide/features/kanban-tutorial
