Hermes Kanban：多 Agent 任务编排的持久看板——架构、原理与竞品全景分析

AI Agent 正在从"单兵作战"走向"团队协作"。当你需要两个研究员并行调研、一个分析师汇总、再由写手出稿——谁协调谁？谁来处理崩溃重试？人想插一嘴怎么办？Hermes Kanban 就是回答这些问题的系统。

这篇文章从零开始拆解 Hermes Kanban 的设计：核心概念、状态机与并发模型、依赖引擎、人机协作机制，以及如何将其集成到 shujietai 这样的第三方平台。最后与 6 款主流编排系统做横向对比，帮你理解它为什么这样设计、适合什么场景。

为什么需要看板而不是 subagent？

Hermes 本身已有 delegate_task 子代理机制，但看板解决的是完全不同的问题：

维度	delegate_task	Kanban
生命周期	RPC 调用（fork → join）	持久消息队列 + 状态机
崩溃恢复	无——失败即终	block → unblock → 重跑；崩溃 → reclaim
人工介入	不支持	任意阶段 comment / unblock
跨代理审计	压缩后丢失	SQLite 永久保留
协调模式	层级（调用方→被调用方）	对等——任何 profile 读写任何 task

一句话：delegate_task 是函数调用，Kanban 是工作队列。工作跨 Agent 边界、需要存活于重启、可能需要人工输入——就用 Kanban。

Hermes Kanban 架构总览

核心概念

Task（任务）

任务是看板的最小单元。一行 SQLite 记录，包含标题、正文、指派人（profile 名）、状态、可选的命名空间（tenant）和幂等键（idempotency key，用于去重重复自动化调用）。

7 种状态：triage → todo → ready → running → blocked → done → archived。

triage：原始想法暂存区，specifier 扩充后再进入工作流
todo：已创建但被依赖阻塞，或尚未分配
ready：已分配且等待 dispatcher 领取
running：worker 正在执行
blocked：等待人工输入，或熔断器跳闸
done：完成
archived：归档

Link（依赖）

task_links 表记录 parent → child 依赖。Dispatcher 在所有 parent 到达 done 时自动把 child 从 todo 晋升为 ready——这是依赖引擎的核心。无需手动协调，引擎自动推进。

Comment（评论）

跨 Agent 协议。Agent 和人类都可以追加评论。Worker 被重新 spawn 时，会读取完整评论链作为上下文的一部分。

Workspace（工作空间）

Worker 执行任务的目录，三种类型：

scratch（默认）：独立临时目录，任务归档后可被 GC
dir:：共享持久目录（Obsidian vault、运维脚本目录等），必须是绝对路径
worktree：git worktree，编码任务使用

Board（看板）

独立队列，拥有自己的 SQLite DB、工作空间目录和 dispatcher 循环。一个安装可以有多个 board（如每个项目一个），board 之间完全隔离——Worker 进程通过 HERMES_KANBAN_BOARD 环境变量被钉在自己的 board 上，看不到其他 board 的任务。

Tenant（租户）

board 内的软隔离。同一个专家团队可以服务多个业务方，通过 --tenant 标记任务，Worker 在写 memory 时自动添加前缀以避免上下文泄漏。

Dispatcher（调度器）

长期运行的循环，默认每 60 秒执行一次：回收过期 claim → 回收崩溃 worker → 晋升 ready 任务 → 原子 claim → spawn 指定 profile。默认嵌入 gateway 进程运行，无需额外服务。

关键容错：连续约 5 次 spawn 失败后自动 block 该任务并附上最后一次错误——防止不存在的 profile 或挂载不了的工作空间造成无限重试。

Kanban 状态机与并发 Claim 流程

状态机与并发模型

状态转换

triage ──→ todo ──→ ready ──→ running ──→ done
  │          ↑         ↑         │    ↓
  └──────────┘         │      blocked ──→ (unblock) → ready
                       │         │
                  (all parents    └──→ 每次重试创建新 run
                   done)

blocked → unblock → ready 是人机协作的关键路径。Worker 调用 kanban_block(reason="...") 暂停任务，人类在 dashboard 或 CLI 中 unblock，dispatcher 在下一个 tick 重新 spawn worker。

原子 Claim 与 WAL 并发

SQLite 以 WAL 模式运行 + BEGIN IMMEDIATE 写事务 + compare-and-swap (CAS) 更新 tasks.status 和 tasks.claim_lock。SQLite 通过 WAL 锁串行化写入者——最多一个 claimer 赢得任何给定任务，失败者观察到 0 行受影响并继续。无需分布式锁，无需重试循环。

Claim TTL 默认 15 分钟；worker 超过此窗口应定期调用 kanban_heartbeat() 续期。

Run——一次尝试一行记录

Task 是逻辑工作单元，Run 是一次执行尝试。Dispatcher claim 一个 ready 任务时创建 task_runs 行并指向它。当这次尝试结束（完成、阻塞、崩溃、超时、spawn 失败、被回收），run 行关闭并记录 outcome。

一个被尝试三次的任务有三行 task_runs。这为事后复盘提供了完整的尝试历史。

Worker 生命周期

Worker 不 shell out 到 hermes kanban，而是通过 7 个内嵌工具（tool）驱动看板：

工具	用途
`kanban_show`	读取当前任务的标题、正文、父任务交接、先前尝试、评论
`kanban_complete`	完成——写入 summary + metadata 结构化交接
`kanban_block`	阻塞——升级给人，附带 reason
`kanban_heartbeat`	长操作中发送存活信号
`kanban_comment`	追加持久评论
`kanban_create`	编排者扇出子任务
`kanban_link`	编排者后补依赖边

一个典型 worker 回合：

# 1. 读取任务
kanban_show()
# 2. 执行实际工作（terminal/file/code tools）...
kanban_heartbeat(note="4 of 8 files transformed")
# 3. 完成
kanban_complete(
    summary="migrated to token-bucket; 14 tests pass",
    metadata={"changed_files": ["limiter.py"], "tests_run": 14},
)

结构化 handoff 是精髓：summary 供人类和下游 agent 阅读，metadata 是机器可读的 JSON 字典——下游 worker 通过 kanban_show() 的 worker_context 字段直接读取父任务的 metadata，无需重新解析散文。

八种协作模式

模式	形状	例子
扇出	N 兄弟，同角色	5 个角度并行研究
流水线	角色链：scout → editor → writer	每日简报组装
投票/仲裁	N 兄弟 + 1 汇总者	3 个研究员 → 1 个评审选定
长期日志	同 profile + 共享目录 + cron	Obsidian vault 持续积累
人机协作	worker block → 人 comment → unblock	模糊决策
@提及	从散文中内联路由	`@reviewer 看看这个`
线程作用域	/kanban here 在线程中	每个项目网关线程
舰队耕作	一个 profile，N 主体	50 个社交账号

三种操作界面

同一个 kanban_db 层，三种入口：

Agent tool 调用——worker 进程内的 kanban_* 工具
CLI / 斜杠命令——hermes kanban create ... 或聊天内 /kanban list
Dashboard GUI——拖拽、内联创建、批量操作、WebSocket 实时更新

三者始终一致——写操作都通过同一个 kanban_db 层，不存在漂移。

集成到第三方平台：以 shujietai 为例

shujietai（数据台）是一个 FastAPI + Vue 3 的 AI Agent 编排平台，已有自己的 dispatch 层（dispatch_tasks + dispatch_events 表、DispatchWorkerPool、WebSocket 流式推送）。看板如何与这样的平台集成？

集成架构

┌─────────────────────┐      REST API
│  shujietai 前端       │ ◀───────────────┐
│  Vue 3 + WebSocket    │                  │
└──────────┬───────────┘                   │
           │ POST /api/v1/dispatch         │
           ▼                                │
┌─────────────────────┐   HTTP client       │
│  shujietai 后端       │ ──────────────── ▼
│  FastAPI dispatch     │      Hermes API Server (8642)
│  service              │ ──────────────── → kanban.db
└─────────────────────┘                    (via hermes CLI
                                             or API bridge)

方案 A：API Server 桥接（推荐）

Hermes API Server 在 gateway 中默认运行于 8642 端口，暴露 OpenAI 兼容接口。shujietai 后端已通过此端口调用 Hermes 的 LLM 能力。

扩展集成路径：

创建任务：shujietai 后端调用 hermes kanban create ... CLI 或直接操作 kanban_db 的 SQLite 文件（如果同主机部署）
监听状态：通过 hermes kanban notify-subscribe 订阅任务事件到 shujietai 的 WebSocket channel
人工介入：shujietai 前端的 "等待输入" 状态映射到 kanban 的 blocked，用户回复时调用 hermes kanban unblock
结果回写：worker 的 kanban_complete 中的 summary/metadata 可被 shujietai 的 dispatch event 系统消费

方案 B：共享 SQLite 直接读取

如果 shujietai 后端与 Hermes 同主机部署，可以直接读取 ~/.hermes/kanban.db（WAL 模式允许并发读取）。shujietai 的 cockpit API 已经有 build_runtime_state() 模式，可以增加一个看板面板轮询任务统计。

需要注意：shujietai 的 dispatch 层有独立的状态机（queued → running → completed/failed/aborted），与 kanban 的 7 状态不完全对应。集成时建议做状态映射层而非修改 kanban 本身。

关键注意事项

API Server 绑定：Hermes 有安全守卫——设置 host: 0.0.0.0 但未设置 API_SERVER_KEY 时会静默回退到 127.0.0.1。Docker 容器内必须配 API_SERVER_KEY 且环境变量正确
API Key 匹配：shujietai 的 HERMES_API_KEY 必须与 Hermes gateway 的 API_SERVER_KEY 一致，否则 401
.env 热更新：docker compose restart 不重读 .env，必须 docker compose up -d --force-recreate
会话-分发断层：shujietai 的 dispatch_tasks 和 sessions 表不自动同步，创建 dispatch 任务后需显式调用 store.ingest() 创建 session 记录

竞品雷达对比 & shujietai 集成架构

竞品横向对比

维度	Hermes Kanban	CrewAI	LangGraph	Airflow	Temporal	Prefect
核心模型	持久 SQLite 看板 + dispatcher	进程内 Agent 编排	图状态机	DAG 调度器	持久工作流引擎	动态工作流
状态持久化	SQLite WAL（本机）	内存为主，可选数据库	检查点存储（可插拔）	数据库（MySQL/PG/SQLite）	事件溯源（Cassandra/PG/SQLite）	数据库（PG/SQLite）
依赖处理	parent→child Link 自动晋升	任务依赖队列	图边 + 条件路由	DAG 依赖	await + signal	依赖 + 条件
人工介入	block/unblock + comment 原生支持	需自定义 HumanInputTool	需自定义 interrupt	极有限（外部 sensor）	原生 signal + activity	极有限
崩溃恢复	claim TTL + reclaim + run 历史	无原生支持	检查点回放	重试策略	事件溯源完整回放	重试 + 缓存结果
跨 Agent 协调	对等——任何 profile 读写任何 task	顺序/层级流程	图节点隐式传递状态	任务实例上下文	workflow 间 signal/child	流程间引用
集成模型	CLI + REST + WebSocket + 工具调用	Python SDK	Python SDK（LangChain）	Python SDK + REST API	多语言 SDK + gRPC API	Python SDK + REST
多租户	原生 tenant 标记 + board 隔离	无	无	无原生	命名空间	无原生
实时 UI	内置 dashboard 插件	无原生	LangGraph Studio（付费）	Flower 监控	Web UI	Cloud UI / 开源
定价	开源免费	开源免费	开源免费 / Studio 付费	开源免费	开源免费 / Cloud 付费	开源免费 / Cloud 付费
适合场景	多 Agent 持久协作 + 人机混合	快速原型验证	复杂图状态流	定时批处理	长事务/微服务编排	轻量数据管道

详细分析

CrewAI 把编排做进了 Python 对象——Agent、Task、Crew 即代码。上手最快，但状态全在内存，进程挂了就没了。适合概念验证和轻量级一次性流水线。

LangGraph 把 Agent 流建模为有状态的图，条件边允许复杂的分支逻辑，中断-恢复检查点比 CrewAI 好得多。但它的"图即代码"模型意味着编排逻辑与业务逻辑耦合——修改流程要改代码重新部署。Studio 是付费产品，免费层的调试能力有限。

Airflow 是定时批处理的王者。DAG 声明式定义、调度器可靠、生态庞大。但它没有原生的"人机协作"原语——一个需要人类审批的 Airflow task 要靠外部 sensor 来模拟，笨拙且脆弱。

Temporal 是最接近 Hermes Kanban 哲学的竞品——事件溯源、崩溃自动回放、原生支持长事务和信号中断。学习曲线陡峭（workflow 代码有严格约束），但对于微服务编排和跨天/跨周长事务，它是最健壮的选择。

Prefect 在 Airflow 的重量和 CrewAI 的轻量之间——动态 DAG、Python 原生 @flow/@task 装饰器、不错的 Dashboard。但人机协作和跨代理审计偏弱。

Hermes Kanban 的差异化在于三点：一是人机协作是第一公民（block/unblock/comment 不是补丁），二是 Agent 对等协调（任何 profile 读写任何 task，而非层级调用），三是结构化 handoff（summary + metadata 的 JSON 交接让下游 agent 不用解析散文）。

10 分钟上手

# 1. 初始化
hermes kanban init

# 2. 确保 gateway 运行（内嵌 dispatcher）
hermes gateway start

# 3. 创建一个研究任务
hermes kanban create "research AI agent orchestration patterns" \
    --assignee researcher --priority 2

# 4. 创建带依赖的任务链
SCHEMA=$(hermes kanban create "Design auth schema" \
    --assignee backend-dev --json | jq -r .id)

hermes kanban create "Implement auth API" \
    --assignee backend-dev --parent $SCHEMA

# 5. 实时观察
hermes kanban watch

# 6. 查看统计
hermes kanban stats

# 7. 打开 dashboard
hermes dashboard   # 点击 Kanban 选项卡

从 gateway 聊天中操作

/kanban list
/kanban create "write launch post" --assignee writer --parent t_research
/kanban comment t_abcd "use the 2026 schema, not 2025"
/kanban unblock t_abcd

创建任务时自动订阅——当任务完成或阻塞时你会收到通知。

什么时候该用什么

场景	推荐
快速并行子任务，无需持久化	`delegate_task`
多角色协作、需要人工审批	Kanban
定时批处理、数据管道	Airflow / Prefect
微服务间长事务编排	Temporal
复杂图状态流、条件分支	LangGraph
快速原型、一次性流水线	CrewAI

资料来源

Hermes Agent:

Repository: https://github.com/NousResearch/hermes-agent (MIT, ⭐7k+)
Documentation: https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban
Key source files inspected:
- hermes_cli/kanban_db.py — SQLite 看板核心，4000+ 行，含状态机、claim、dispatch 逻辑
- hermes_cli/kanban.py — CLI 子命令入口
- hermes_cli/kanban_diagnostics.py — 诊断与熔断
- tools/kanban_tools.py — Agent 侧 kanban_* 工具定义
- plugins/kanban/dashboard/plugin_api.py — Dashboard REST/WS 插件
- website/docs/user-guide/features/kanban.md — 官方文档（776 行）
- website/docs/user-guide/features/kanban-tutorial.md — 官方教程

CrewAI:

Repository: https://github.com/crewAIInc/crewAI (MIT, ⭐30k+)
Documentation: https://docs.crewai.com/

LangGraph:

Repository: https://github.com/langchain-ai/langgraph (MIT, ⭐10k+)
Documentation: https://langchain-ai.github.io/langgraph/

Apache Airflow:

Repository: https://github.com/apache/airflow (Apache-2.0, ⭐40k+)
Documentation: https://airflow.apache.org/docs/

Temporal:

Repository: https://github.com/temporalio/temporal (MIT, ⭐12k+)
Documentation: https://docs.temporal.io/

Prefect:

Repository: https://github.com/PrefectHQ/prefect (Apache-2.0, ⭐18k+)
Documentation: https://docs.prefect.io/

shujietai (数据台):

项目路径: /home/guancy/workspace/shujietai (内部项目)
关键文件:
- backend/app/services/dispatch_service.py — 分发状态机与 CRUD
- backend/app/services/dispatch_worker.py — 异步 worker 流式 AI 响应
- backend/app/api/routes_dispatch.py — REST 端点
- frontend/src/composables/useDispatchTask.js — 前端任务生命周期