📚 系列导航：上一篇 Hermes Agent Kanban 教程 已经讲清“Kanban 多 Agent 编排教程”；本篇聚焦 Hermes Agent Swarm 调度；下一篇 Hermes Agent 多 Agent 协作模式指南 继续学习“多 Agent 协作模式与成本控制”。
先给结论：Kanban 内核只负责重算就绪任务、原子认领和启动 Worker，策略放在用户空间。 内核越少懂业务，越容易保持稳定；每个 Worker 使用独立操作系统进程，则让任务生命周期不再绑死在某次 SDK 调用上。
ℹ️ 版本说明： 原稿基于 Hermes Agent v0.16.0（2026 年 6 月）源码整理。本文保留其版本化机制分析；命令、数量和界面请以 Hermes Agent 官方文档 与本地输出为准。
Hermes Kanban Dispatcher 的工作流程
Kanban 看板系统的心脏，是一个叫 dispatcher 的进程。名字听着唬人，其实它就是个 cron：每隔一会儿醒来一次，扫一遍看板，然后干活。
它能干的活，掰着手指头数得过来，一共三件。
重算 ready，意思是看哪些任务的前置依赖都完成了，可以开工了。原子认领，是用一句 SQL 把这个任务的锁抢到手， WHERE status=‘ready’ AND claim_lock IS NULL ，靠数据库的行级竞争，保证同一个任务最多只有一个认领者赢。spawnworker，就是起一个操作系统进程去执行。
就这三件。没有了。
你以为多 Agent 协作里那些花活，智能路由、预算分配、审批治理、谁该优先，dispatcher 一概不管。它不知道哪个任务更重要，不知道该派给最便宜的模型还是最贵的，也不操心万一两个 worker 打架怎么办。这些判断全被推到了它管不着的地方：profile 的 system prompt 里、用户装的 plugin 里、卡片自己带的配置里。
这就是「笨内核」的全部意思：内核只保证机制正确（任务不会被两个进程同时认领、死掉的 worker 会被回收），至于策略，派谁、花多少钱、要不要人来批，全交给用户空间。机制和策略分离，是 Unix 写了五十年的老规矩。
Kanban 机制与策略分离的原因
把聪明往外推，听起来像偷懒，其实是种克制。
我见过太多系统死在「内核太聪明」上。一旦你让调度器开始懂业务，懂哪个任务该优先、懂怎么分预算、懂什么时候该叫人，它就再也改不动了。每加一个新场景，都得回去动那个最核心、最不敢碰的部分。Hermes 反过来：内核笨到没有业务知识，所以它几乎不需要改；想加新玩法，去用户空间加，内核纹丝不动。
有意思的是，Nous 拿这套哲学跟同代的一个系统做了对照。Google 在 2026 年 4 月的 Gemini Enterprise 里，把 Agent 栈拆成两个平面：一个「治理控制平面」管审批合规，一个「速度执行平面」管干活。Hermes 刻意只待在执行平面，治理这事它根本不在内核里碰，谁要谁自己用 plugin 装。一个选了大公司要的全套治理，一个选了开发者要的简单，取舍不同，但都自洽。
Hermes Swarm 如何复用 Kanban 原语
Hermes 有个一键起多 Agent 的命令， hermes kanban swarm 。你给它一个目标，再点几个角色，它就铺开一张协作网：几个专家 worker 并行干活，一个 verifier 把关，一个 synthesizer 收尾。
第一次看到的人会以为，这背后肯定藏着一套专门的 swarm 引擎。没有。
swarm 模块开头自己就写了一句话：故意不引入第二个调度器。它做的事，只是往现有的 Kanban 内核里写一张固定形状的任务图。
那张图里的每一根线、每一个状态，都是看板早就有的原语：fan-out 并行、pipeline 串行、任务之间的依赖 link。连 worker 之间共享信息的「黑板」，都不是新建的存储，它就是根任务上的一条结构化 JSON 评论，后写的覆盖先写的，顺手记一笔是谁写的。dashboard、通知、命令行，没有一个组件需要为 swarm 加新代码，因为它压根没造新东西。
所以 swarm 本质是什么？是 fan-out 加 pipeline 加黑板这几样老料，拌出来的一道组合糖。语法上你一条命令就拥有了一套复杂拓扑，底下却没有新的运行时在跑。这是「不动内核的前提下加一个高层能力」的漂亮范例：想加能力，去用户空间拼，别往内核里塞引擎。
进程内子 Agent 的生命周期风险
讲到这，得请出一个反例，才能看清 Hermes 为什么这么轴。
有个叫 NanoClaw 的项目，号称是第一个支持「进程内 subagent」的个人助理。它的多 Agent 是这么搭的：team-lead 在自己的进程里，通过上游 SDK 的一个查询接口，孵化出一堆子 Agent 帮忙干活。听起来很优雅，所有 Agent 都在一个进程里，省了进程间通信的麻烦。
问题出在生命周期上。这些子 Agent 的命，攥在那个查询接口手里。当 team-lead 那一轮调用结束，子 Agent 会被悄无声息地杀掉。哪怕它正干到一半、文件还没落盘。Nous 的设计文档里记了这个坑，一句话特别狠：看起来成功了，实际产出零个文件。
Hermes 把这条教训刻进了设计文档的一个标题，「关键不变量：不要进程内 subagent 群」。它的原话大意是：
每一个协调 worker 都是用户掌控下的操作系统进程，不是某个 SDK 查询生命周期里的子 Agent。当 worker 退出，干净退出也好、崩溃也好、被强杀也好，它的认领锁过期，下一次 dispatcher 扫描时，这个任务被重新认领。没有任何一个我们不拥有的生命周期。
这句「没有任何一个我们不拥有的生命周期」，是整套哲学的题眼。Hermes 宁可承受进程间通信、心跳检测、崩溃回收这些笨重的成本，也不肯把 worker 的命交给一个它控制不了的上游 SDK。
推荐：
Hermes：每个 worker 是独立 OS 进程。worker 死了（崩溃/被杀/正常退出），认领锁自动过期，任务被重新派发。生命周期完全自己掌控，最坏情况是重跑一次，不会静默丢结果。
不推荐：
NanoClaw 式进程内群：子 Agent 的命挂在上游 SDK 的查询生命周期上。team-lead 那轮一结束，子 Agent 被静默杀掉，干到一半的活直接蒸发，「看起来成功，产出为零」。
OpenClaw 那一类强调进程内 Agent 群的方案也有同样的脆弱性。倒不是说进程内一定错。我想说的是，当你的 Agent 的生死取决于一个你不拥有的生命周期，你就埋了一颗不定时的雷。Hermes 选了看上去更笨重、实则更诚实的路：边界就是操作系统进程，仅此而已。
Kanban Worker 内部使用 delegate_task
看板这么强，是不是该把老的 delegate_task 扔了？没扔。上一节（§15）已经把两者的分工逐条列过了，判据就一句：这个交接，需要活过单次 API 循环、并且对别人可见吗？需要就上看板，不需要就用 delegate_task。
这里只补一个上一节没细说的点：两者能套着用。看板里的某个 worker，在自己一次运行内部，照样可以调 delegate_task 去做点内部推理。函数调用嵌在持久队列里，各司其职—这恰恰又是「笨内核」的体现，Kanban 没有吞掉 delegate_task，只是给它加了一层持久的外壳。
独立 Worker 进程的恢复价值
回头看，Hermes 这套「笨内核+用户空间装饰」，省下的不只是代码量。
它省下的是未来的改动成本。内核笨，意味着它稳定，意味着加 swarm、加新协作模式、加新的成本控制策略，都不用回去碰那个最核心的部分。聪明的东西活在用户空间，坏了、过时了、想换了，随时换，内核当没看见。
更深一层，它省下的是对生命周期的失控风险。坚持「每个 worker 都是我拥有的 OS 进程」，看起来笨重，换来的是最坏情况只是重跑一次，而不是 NanoClaw 那种悄无声息的清零。一个把复杂性往外推、把边界守得死死的内核，往往比一个什么都想替你想好的聪明内核，活得更久。
下一节我们把这套底座真正用起来，看八种协作模式怎么从这几样笨原语里长出来，以及怎么按卡片把多 Agent 的成本一笔笔算清楚。
常见问题
Hermes Agent Swarm 是独立调度器吗？
不是。原稿所述 Swarm 是基于 Kanban 原语生成固定任务图的高层组合，不再维护第二套任务状态机。
为什么 Hermes Worker 使用独立进程？
独立进程的生命周期由 Hermes 和操作系统掌控，崩溃后可以释放认领并重新调度，避免子任务随某次 SDK 调用结束而静默消失。
这篇教程里的版本数字会变化吗？
会。原稿以 Hermes Agent v0.16.0 为分析基线，平台、工具、命令参数和默认配置可能继续变化；实际操作前请核对当前官方文档和本地命令帮助。