最近圈子里大家都在疯狂折腾 “Vibe Coding”，不管是用 Claude Code 还是在本地部署 OpenClaw 搞多智能体工作区，最终目的都是想让 AI 们自己打配合，把整个开发流水线或者业务闭环跑通。
但现实往往很骨感。当你满怀期待地看着几个 AI 开始“开会”时，经常会遇到让人高血压的场景：
“我明明建了研究员、写手、测试三个独立的 Agent，结果总控节点（Orchestrator）一上头，经常自己就把代码写了。它本该是个坐在控制室里的调度员，结果非要下场当打工人。”
不仅如此，很多框架在跑跨度较长的任务时非常脆弱。一旦主进程结束，底下跑了一半的子智能体就会静默死亡。
为了彻底根治这些痛点，Nous Research 社区发布了一份全新的架构设计规范（2026年4月版）—— Hermes Kanban。今天，我们就来深度拆解这份规范，看看它是如何真正把多智能体协同管明白的。
什么是 Hermes Kanban？（规范总览）
用一句话概括：Hermes Kanban 是为 Hermes Agent 框架设计的多智能体协同层。
它摒弃了脆弱的“主从式”代码层调用，在底层建立了一个由 SQLite 驱动的持久化任务看板。通过这个看板，各种异构的智能体（比如负责规划的研究员、负责执行的工程师、甚至长期的数字分身助理）可以实现异步协作，共同完成生命周期极长的复杂任务。
它的核心设计完全践行了极客社区里 “Your assistant. Your machine. Your rules” 的底层哲学——拒绝臃肿的云端企业级控制面板，把控制权完全交还给本地。
1. 三层解耦的“极简架构”
整个系统被极其干净地划分为互不干扰的三层：
- 控制层（Control Plane）：面向用户。你可以通过终端 CLI 敲命令，或者在 Telegram、Discord 等聊天网关里直接下达指令。
- 状态层（State Plane）：系统的单点“真理之源”。它的核心仅仅是一个本地的kanban.db（SQLite WAL 模式），外加一个每 60 秒跑一次的“无脑” Cron 调度器（Dispatcher）。调度器只干三件事：重算任务状态、原子化抢占锁、拉起工作进程。
- 执行层（Execution Plane）：由一系列完全相互隔离的 Profile 进程组成。研究员就在scratch草稿区查资料，工程师就在worktree代码树里敲代码。
划重点：在这个架构下，智能体进程之间永远不会进行直接通信，所有的任务交接全部通过读写底层看板来完成。
2. 状态机的优雅流转（工作流）
一个任务在看板上的生命周期是极其严谨的，共有五个核心状态：
- Todo（待办）：任务已创建，但在等它的前置节点完工。
- Ready（就绪）：前置条件满足，等待调度器认领。
- Running（执行中）：已被某个智能体进程认领并在干活了。
- Blocked（阻塞）：这是设计的精髓！ 遇到无权限或卡壳时，智能体会挂起任务并留言。此时人类或高权限 AI 可以介入，回复后将其unblock回就绪态。
- Done（完成）：产出结果，并自动触发下游子任务。
3. 极速上手：怎么用？
Hermes Kanban 的交互表面做得极其克制且丝滑。
终端极客玩法：
# 创建一个需要前置依赖的任务 hermes kanban create "写一份技术简报" --assignee writer
聊天网关玩法（@mention 委托）：
如果你接了 Slack 或 TG，它吸取了 Google Gemini CLI 的灵感，支持极其自然的上下文委派。
当你（或某个 AI）在聊天框里打出：@researcher 帮我查一下这三个 API 的限流规则，系统会自动将其解析为看板任务，直接推给研究员进程。
为什么 delegate_task 早就该被淘汰了？
在 Kanban 出现之前，多智能体协同主要靠delegate_task原语。这本质上是个 RPC 调用：父智能体拉起子智能体，然后一直阻塞死等结果返回。
对于简单的“帮我查个资料”没问题。但如果你要做的是带人工确认的工程流水线（需求拆解 -> 并发写代码 -> PR 审查），或者是跨越数周的数字分身，它就彻底歇菜了。
真正的复杂业务，需要的是跨越运行周期的持久化状态、可见的工作进度，以及人类随时随地介入打断的能力，这些都是delegate_task无法提供的。
避坑指南：NanoClaw 的血泪教训
提到多智能体，很多人会想到直接在代码里开一堆子线程去跑。NanoClaw 之前就试图做这样的事情，结果成了典型的反面教材。
NanoClaw 把子智能体绑定在了主轮次的生命周期里。主节点的对话一结束，底下的子智能体就会被系统“静默斩首”，表面上看似执行成功，实际上硬盘里连个产出文件都没有。
Hermes Kanban 从中吸取了一个核心铁律：绝对不要搞进程内的子智能体集群。
在 Kanban 的设计里，每一个工作节点都是受操作系统完全控制的独立进程。哪怕主机意外重启，任务也会因为“锁定超时”而被调度器重新接管。没有哪个生命周期是我们无法掌控的。
绝杀机制：如何治好 AI 主管的“微操病”？
回到我们开头说的痛点：怎么防止编排器（Orchestrator）自己下场干活？
Hermes 给出的解法非常优雅——这不属于系统内核要管的事，只需在“用户态”做限制。官方提供了一个 Orchestrator 模板，下了三剂猛药：
- 物理没收作案工具：配置层面，只允许拥有看板、网关和记忆工具，强制禁用终端执行、文件读写和写代码能力。它就是想写代码也会直接报错，只能乖乖派发任务。
- 死板的 System Prompt：在提示词中明文规定：“你是一个调度员，不是打工人。如果没人能干，去问人类，绝对不要自己尝试执行。”
- 标准化专家名册：搭配一套标准的角色库（研究员、写手、后端等），让它的任务拆解路径保持高度稳定。
降维打击：50个账号的矩阵是如何跑起来的？
架构到底好不好用，得看真实业务场景。规范中提到了一个极具代表性的实战案例：用一个智能体控制 50 个 Instagram 营销号矩阵。
如果是传统的 RPA 工具，你得搞专门的运行时、复杂的定时器和臃肿的账号库。但在 Hermes Kanban 里，优雅得让人发指：
- 只需要定义一个 insta-manager专家配置文件。
- 利用 SQLite 中新增的极轻量tenant（租户）字段，通过 Cron 每天向看板批量派发 50 个任务。每个任务带上不同账号的tenant标签，并隔离在不同的本地文件夹（如~/insta/acct-17/）中。
- 调度器一跑，并发拉起 50 个独立进程。如果账号 17 弹了验证码卡住了，任务会自动挂起等待人类介入，而另外 49 个账号继续疯狂发帖，完全不受影响。
这简直就是为了多租户业务和矩阵工作室量身定制的“赛博包工头”。
总结：把复杂留给用户态，把稳定还给内核
早在 2026 年初，业界就有一个趋势：AI 智能体技术栈正在走向“控制面”（审计、权限）与“执行面”（快速迭代）的分化。
Hermes Kanban 的选择非常明确：死守执行面。
它拒绝把企业级的审批流、复杂的负载均衡塞进内核。它只用 1 个 SQLite 文件、1 个 Cron 定时任务、1 行 CLI 指令，就搭出了一个坚不可摧的底层协调介质。剩下的那些花活（比如智能路由、前端 UI），全都留给用户态的插件去折腾。
告别脆弱的进程内调用，告别越权乱写的 AI 主管。这，或许才是多智能体协同真正该有的样子。
文章摘自：https://www.cnblogs.com/softlin/p/21140766
京ICP备14020293号-4