§21笨内核 + 用户空间装饰

Dumb Core, Userspace Decoration

一个看起来很复杂的多Agent平台，内核居然只干三件笨事。Hermes把所有聪明的东西都推到了外面，自己守着一个朴素到近乎固执的调度器。这套Unix式的品味，恰好是它和那些「进程内Agent群」

最深的分野。

先看调度器在干什么

Kanban看板系统的心脏，是一个叫dispatcher的进程。名字听着唬人，其实它就是个cron：每隔一会儿醒来一次，扫一遍看板，然后干活。

它能干的活，掰着手指头数得过来，一共三件。

重算谁ready

原子认领任务

spawn一个worker进程

重算ready，意思是看哪些任务的前置依赖都完成了，可以开工了。原子认领，是用一句SQL把这个任务的锁抢到手，WHERE status='ready' AND claim_lock IS NULL ，靠数据库的行级竞争，保证同一个任务最多只有一个认领者赢。spawn worker，就是起一个操作系统进程去执行。

就这三件。没有了。

你以为多Agent协作里那些花活，智能路由、预算分配、审批治理、谁该优先，dispatcher一概不管。它不知道哪个任务更重要，不知道该派给最便宜的模型还是最贵的，也不操心万一两个worker打架怎么办。这些判断全被推到了它管不着的地方：profile的system prompt里、用户装的plugin里、卡片自己带的配置里。

这就是「笨内核」的全部意思：内核只保证机制正确（任务不会被两个进程同时认领、死掉的worker会被回收），至于策略，派谁、花多少钱、要不要人来批，全交给用户空间。机制和策略分离，是Unix写了五十年的老规矩。

为什么宁可让内核笨

把聪明往外推，听起来像偷懒，其实是种克制。

我见过太多系统死在「内核太聪明」上。一旦你让调度器开始懂业务，懂哪个任务该优先、懂怎么分预算、懂什么时候该叫人，它就再也改不动了。每加一个新场景，都得回去动那个最核心、最不敢碰的部分。Hermes反过来：内核笨到没有业务知识，所以它几乎不需要改；想加新玩法，去用户空间加，内核纹丝不动。

有意思的是，Nous拿这套哲学跟同代的一个系统做了对照。Google在2026年4月的Gemini Enterprise里，把Agent栈拆成两个平面：一个「治理控制平面」管审批合规，一个「速度执行平面」管干活。Hermes刻意只待在执行平面，治理这事它根本不在内核里碰，谁要谁自己用plugin装。一个选了大公司要的全套治理，一个选了开发者要的简单，取舍不同，但都自洽。

swarm：一个不带新运行时的「组合糖」

Hermes有个一键起多Agent的命令，hermes kanban swarm 。你给它一个目标，再点几个角色，它就铺开一张协作网：几个专家worker并行干活，一个verifier把关，一个synthesizer收尾。

第一次看到的人会以为，这背后肯定藏着一套专门的swarm引擎。没有。

swarm模块开头自己就写了一句话：故意不引入第二个调度器。它做的事，只是往现有的Kanban内核里写一张固定形状的任务图。

规划根任务（建完即完成）

并行专家worker verifier门控synthesizer收尾

那张图里的每一根线、每一个状态，都是看板早就有的原语：fan-out并行、pipeline串行、任务之间的依赖link。连worker之间共享信息的「黑板」，都不是新建的存储，它就是根任务上的一条结构化JSON评论，后写的覆盖先写的，顺手记一笔是谁写的。dashboard、通知、命令行，没有一个组件需要为swarm加新代码，因为它压根没造新东西。

所以swarm本质是什么？是fan-out加pipeline加黑板这几样老料，拌出来的一道组合糖。语法上你一条命令就拥有了一套复杂拓扑，底下却没有新的运行时在跑。这是「不动内核的前提下加一个高层能力」的漂亮范例：

想加能力，去用户空间拼，别往内核里塞引擎。

NanoClaw：一个值得记住的反面教材

讲到这，得请出一个反例，才能看清Hermes为什么这么轴。

有个叫NanoClaw的项目，号称是第一个支持「进程内subagent」的个人助理。它的多Agent是这么搭的：

team-lead在自己的进程里，通过上游SDK的一个查询接口，孵化出一堆子Agent帮忙干活。听起来很优雅，所有Agent都在一个进程里，省了进程间通信的麻烦。

问题出在生命周期上。这些子Agent的命，攥在那个查询接口手里。当team-lead那一轮调用结束，子Agent会被悄无声息地杀掉。哪怕它正干到一半、文件还没落盘。Nous的设计文档里记了这个坑，一句话特别狠：看起来成功了，实际产出零个文件。

Hermes把这条教训刻进了设计文档的一个标题，「关键不变量：不要进程内subagent群」。它的原话大意是：

每一个协调worker都是用户掌控下的操作系统进程，不是某个SDK查询生命周期里的子Agent。当worker退出，干净退出也好、崩溃也好、被强杀也好，它的认领锁过期，下一次dispatcher扫描时，这个任务被重新认领。没有任何一个我们不拥有的生命周期。

这句「没有任何一个我们不拥有的生命周期」，是整套哲学的题眼。Hermes宁可承受进程间通信、心跳检测、崩溃回收这些笨重的成本，也不肯把worker的命交给一个它控制不了的上游SDK。

OpenClaw那一类强调进程内Agent群的方案也有同样的脆弱性。倒不是说进程内一定错。我想说的是，当你的Agent的生死取决于一个你不拥有的生命周期，你就埋了一颗不定时的雷。Hermes选了看上去更笨重、实则更诚实的路：边界就是操作系统进程，仅此而已。

那delegate_task还有用吗

看板这么强，是不是该把老的delegate_task扔了？没扔。上一节（§20）已经把两者的分工逐条列过了，判据就一句：这个交接，需要活过单次API循环、并且对别人可见吗？需要就上看板，不需要就用delegate_task。

这里只补一个上一节没细说的点：两者能套着用。看板里的某个worker，在自己一次运行内部，照样可以调delegate_task去做点内部推理。函数调用嵌在持久队列里，各司其职——这恰恰又是「笨内核」的体现，Kanban没有吞掉delegate_task，只是给它加了一层持久的外壳。

这套品味值多少

回头看，Hermes这套「笨内核 + 用户空间装饰」，省下的不只是代码量。

它省下的是未来的改动成本。内核笨，意味着它稳定，意味着加swarm、加新协作模式、加新的成本控制策略，都不用回去碰那个最核心的部分。聪明的东西活在用户空间，坏了、过时了、想换了，随时换，内核当没看见。

更深一层，它省下的是对生命周期的失控风险。坚持「每个worker都是我拥有的OS进程」，看起来笨重，换来的是最坏情况只是重跑一次，而不是NanoClaw那种悄无声息的清零。一个把复杂性往外推、把边界守得死死的内核，往往比一个什么都想替你想好的聪明内核，活得更久。

下一节我们把这套底座真正用起来，看八种协作模式怎么从这几样笨原语里长出来，以及怎么按卡片把多Agent的成本一笔笔算清楚。