Hermes Agent v0.16 Kanban Swarm 功能深度解析(面向 AI 开发者)
写作日期:2026-09-03。本文描述的系统行为均基于 2026-09-03 在作者本机正在运行的 Hermes Agent(任务上下文标注为 v0.16)上的现场观察与第一手工具面,而非照抄宣传材料——作者写作时正作为 dispatcher 派生的 worker 运行在该系统的看板上。凡未能现场核验的时效性内容(版本号、变更日志、外部系统细节)均已标注,并统一列入附录 A 核验清单,引用前请以官方仓库与文档为准。 Hermes Agent v0.16 Kanban Swarm 功能深度解析(面向 AI 开发者) 你写过这样的代码吗:一个 Agent 会话跑长任务,中途断网、进程被杀、上下文爆炸,一切归零;或者你想让"调研 Agent"和"写作 Agent"接力,却发现它们活在各自的进程里,谁也看不见谁。 Hermes Agent v0.16 的 Kanban Swarm 解决的就是这件事:用一块持久化的 SQLite 看板,把多个独立 Agent(每个是一个 profile,各自有独立的配置、会话、技能与记忆)组织成一支能接力、能并行、能失败重试、能跨进程存活的"工人队伍"。看板是它们唯一的共识层——任务状态、依赖关系、交接产物,全部落在磁盘上,进程死了看板还在。 这篇文章不打算复述 README。作者写作时正被 dispatcher 派生、以 worker 身份跑在这块看板上(任务 t_b1e3c641),文中的状态机、工具面、调度语义来自对现场事件日志的直接观察与本文写作时实时可用的工具 schema;配置项与 CLI 动词来自随环境安装的官方 skill 参考(v3.2.0)。我们从数据模型讲起,一路拆到调度器、worker 协议与编排模式。 1. 为什么 Agent 需要一块"看板" 先给 Kanban Swarm 一个坐标系。Hermes 的多智能体能力按"存活时间"分成三层: 系统 形态 存活 典型用途 delegate_task(委托) 同一进程内派生子代理,隔离上下文 分钟级,进程退出即丢 并行推理子任务、短时侦察 cronjob(定时) 独立会话按调度触发,结果投递 跨进程、持久 周期巡检、定时报告 Kanban Swarm 跨 profile 的任务队列 + 工作区 + 事件账本 跨进程、持久、可接力 多 Agent 流水线、长任务、需要人工/评审介入的工作流 关键分界在"接力":delegate 的子代理不知道彼此的产出,父进程一死全部蒸发;cron 只解决"到点跑一次"。Kanban Swarm 解决的是分工与交接——任务卡在板上流转,任何 profile 派生出的 worker 都能认领、执行、写回结构化交接信息,下游任务在上游 done 之前不会启动。 ...