📚 系列导航：上一篇 Hermes Agent 使用入口指南 已经讲清“CLI、桌面 App 与 Web Dashboard 使用入口”；本篇聚焦 Hermes Agent Kanban ；下一篇 Hermes Agent Swarm 调度指南 继续学习“Swarm 与子 Agent 调度原理”。
先给结论：短任务用 delegate_task，需要跨轮次、可恢复、可审计的协作才用 Kanban。 前者像一次函数调用，后者像持久工作队列。两者不是替代关系，而是不同粒度的原语。
ℹ️ 版本说明： 原稿基于 Hermes Agent v0.16.0（2026 年 6 月）源码整理。本文保留其版本化机制分析；命令、数量和界面请以 Hermes Agent 官方文档 与本地输出为准。
delegate_task 的适用范围
翻回两个月前的旧书，Hermes 的多 Agent 那一章其实挺单薄。它只有一个原语，叫 delegate_task 。
机制很好懂：父 Agent fork 出一个短命的子 Agent，把任务丢过去，然后阻塞着等返回。子 Agent 在隔离的会话里跑完，吐一段 summary 回来，然后就消失了。最多三个并发。能让不同子 Agent 用不同模型，推理用强模型、搜索用快模型，也就到此为止了。
这是个标准的 fork-join 结构。适合短的、自包含的推理子任务。但它撑不起社区里越来越常见的那几种活：一个要跑几小时的工程流水线、一个每天早上自动出日报的循环、一个你想给它起个名字、养上几个月的持久助理。这些都需要「活过单次 API 调用」的东西， delegate_task 给不了。
Hermes Kanban 的最初设计边界
2026 年 4 月 25 日，Nous Research 在仓库里放了一份 PDF，叫 Hermes Kanban v1 spec。我第一次读到它的扉页时，是有点意外的。
扉页的 Abstract 上，几句话写得斩钉截铁：
设计文档原文（扉页）：Status: DESIGN ONLY. No implementation accompanies this document. / The kernel requires no changes to run_agent.py , no new core tools.
翻译过来：这只是设计，没有任何实现跟着它。这个内核不需要改动 run_agent.py 一行，不需要任何新的核心工具。
整份 spec 的调性都是这种克制到近乎洁癖的极简主义。它把内核的边界画得清清楚楚，恨不得用尺子量过：
维度 v1 设计文档的承诺
状态机 恰好 6 个状态：todo / ready / running / blocked / done / archived
数据库表 原文写「exactly four tables」，恰好 4 张
新增核心工具 零。一个都不许加
CLI 命令 一个子命令
其余 一个 skill、一个 cron job，完事
spec 里那个 dispatcher（调度器）也被设计得故意「笨」。它只干三件事：重新算哪些任务 ready 了、用 CAS 原子地认领一个任务、spawn 出一个 worker 进程。不做智能路由，不做预算，不做审批。所有聪明的活都推给上层的 profile 和插件去干。
这是一份很漂亮的设计。问题是，它没能管住自己。
Hermes Kanban 从设计到落地的变化
到了 v0.16.0，我把实际 shipped 出来的代码和这份 spec 逐条对了一遍。落差大到有点好笑。
💡 推荐
设计文档说：6 状态·4 张表·0 新工具·1 个 CLI 子命
⚠️ 不推荐
令
落地代码是：9 状态·7 张表·一整套 kanban_*工具集 · 30+个 CLI 子命令
每一条都被突破了。状态机多出了三个： triage （人随手丢个粗想法进来）、 scheduled （等时间不等人的任务）、 review （评审门控）。表从 4 张涨到 7 张，光是核心那张 tasks 表的列数就从十几列暴涨到三十列左右。
最打脸的是那句「no new core tools」。实际代码里，dispatcher 每 spawn 一个 worker，就把 kanban_show 、kanban_complete 、 kanban_block 这一整套工具直接塞进它的 schema 里。这恰恰就是新的核心工具。
那个里程碑发生在 v0.15.0，官方自己的 release notes 写得很直白：「Kanban grew into a real multi-agentplatform— 104PRs」。一份极简主义的设计宣言，被现实需求在 104 个 PR 里一口一口喂成了一个平台。
💡 核心建议
这条「设计文档 vs 落地实现」的落差，本身就是观察开源项目演化最好的样本之一。它说明一件事：克制是一种姿态，但真实用户的工作形态会持续往内核里灌东西。能写出「exactlyfourtables」的团队，两个月后照样会因为有人真的要拿它管 50 个 Instagram 账号，而把表加到 7 张。这不是设计失败，是设计在和现实谈判。
delegate_task 与 Kanban 的选择标准
有人可能会问：Kanban 这么强，那 delegate_task 是不是被淘汰了？
没有。它还在，源码里反复强调 kanban 的 worker 在自己一次运行内仍然可以调 delegate_task 。变的是它的位置。它从「多 Agent 的全部」降格成了「函数调用级」的子能力，而 Kanban 成了「队列级」的协作底座。两者共存，分工被官方写死成一句话。
这条分界线值得记住，它干净利落：
| 维度 | delegate_task | Kanban |
|---|---|---|
| 形态 | RPC 调用(fork→join) | 持久消息队列+状态机 |
| 父 Agent | 阻塞到子返回 | fire-and-forget,建完即 done |
| 子身份 | 匿名子 Agent,无持久自我 | 有名 profile,自己的记忆/skill/历史 |
| 可恢复 | 无,失败就是失败 | block 后能 unblock 重跑;崩溃自动回收 |
| 人能不能插手 | 不行,全程 headless | 随时 comment/block/reassign |
| 每任务 Agent 数 | 一次调用一个 | 任务一生 N 个(重试/评审/跟进) |
| 审计 | 父上下文一压缩就丢 | SQLite 行永久留存 |
怎么选？官方给了一句判据，特别适合背下来：这个交接，需要活过单次 API 循环、并且对别人可见吗？需要就上看板，不需要就用 delegate。一句话就把两个原语的边界划干净了。
用大白话讲： delegate_task 是一次函数调用，调完就忘；Kanban 是一个持久工作队列，每一次交接都是一行任何 profile（或者你这个人）都能读、能改的数据。
Hermes Kanban 的持久任务基础设施
把这个反转串起来看，Hermes 多 Agent 这两个月的演化路径其实很清楚。
一个 SQLite 支撑、跨进程、能扛住单点失败的看板平台。它有自动任务分解、有 swarm 拓扑、有定时任务、有按任务覆盖模型、有断路器重试、有多租户、有多看板。这些后面几节会一个一个拆开讲。
但这一节我只想让你先记住这个反转本身。旧书最弱的一章，现在成了全书最有料的 Part。而它之所以这么有料，恰恰是因为那份 spec 一开始想得太克制。克制给了它一个干净的内核，现实又逼着它在这个内核之上长出了一整个平台。
下一节我们钻进这个平台的内核，看看那个被设计成「笨」的 dispatcher，到底笨在哪、又为什么这种笨反而是它能扛住生产环境的原因。
常见问题
Hermes Kanban 和 delegate_task 怎么选？
父 Agent 需要一个短答案后继续时用 delegate_task；任务要跨轮次、跨角色、可恢复或允许人工介入时用 Kanban。两者可以嵌套使用。
Hermes Kanban 的任务会在重启后保留吗？
Kanban 的目标就是把任务和交接持久化到工作队列中，使任务可以恢复和审计。具体恢复行为仍取决于当前调度器配置和工作区状态。
这篇教程里的版本数字会变化吗？
会。原稿以 Hermes Agent v0.16.0 为分析基线，平台、工具、命令参数和默认配置可能继续变化；实际操作前请核对当前官方文档和本地命令帮助。