Hermes Agent Kanban：多智能体任务编排系统搭建指南

Hermes Agent 是由 NousResearch 开源的自主 AI 智能体框架，其 Kanban（看板）模块是一套专为多 Agent 协作设计的持久化任务编排系统，底层基于 SQLite 实现任务队列与调度。本文介绍如何正确搭建 Hermes 多 Agent 系统，以及在实际部署中最容易踩到的几个关键问题。

为什么不能用群聊替代看板

搭建多智能体系统时，一个常见的误区是：把多个 Agent 接入同一个飞书/企微群组，让它们直接通信。

这种方案在实践中有三个致命问题：

  1. 通信不可控：Agent 之间无法主动读取对方消息，只能靠人工复制粘贴转发，效率极低。
  2. 死循环风险：一旦两个 Agent 进入相互回复的状态，极易陷入无限讨论循环，Token 消耗失控。
  3. 可观测性为零：没有任何机制能记录任务状态、追踪进度或从中断点恢复。

Kanban 模式的核心价值就在于此：Agent 之间不直接通信，而是通过共享的任务看板进行解耦协作。Orchestrator 将大任务拆分写入看板，各 Worker Agent 独立认领、执行并回写结果，全程可追踪、可恢复、可干预。

核心工作流程

完整的 Hermes Kanban 执行链路如下：

用户在消息平台（企微/飞书/Telegram 等）发出指令
  ↓
Orchestrator 拆解目标，用 kanban_create 写入子任务
  ↓
Dispatcher 每 60 秒扫描看板，拉起 ready 状态的任务
  ↓
Researcher Agent 独立执行 → kanban_complete
Writer Agent    独立执行 → kanban_complete
  ↓
Orchestrator 检测到全部完成，向用户发送通知 📢

适用场景

Hermes Kanban 适合以下类型的任务：

  • 需要多个专业角色分工协作（调研、分析、撰写、审阅）
  • 任务周期较长，需要跨天/跨周持续执行
  • 需要在执行中途修改需求或插入人工决策
  • 存在可并行执行的子任务，需要加速完成
  • 需要完整的执行日志和审计轨迹

系统关键组件

组件职责
Orchestrator分解目标、创建子任务、路由给合适的 Agent 角色
Dispatcher常驻 Gateway，定期扫描看板，拉起处于 ready 状态的任务
Worker独立进程执行具体任务，拥有独立上下文和工具集，完成后写入 handoff 总结
Kanban Board任务持久化到 SQLite，状态机：todo → ready → in_progress → done / blocked

Agent Profile 配置

每个子 Agent 需要独立的 Profile，并根据职责配置专属的技能和模型。以 Researcher（调研）角色为例：

# 创建 Profile
hermes profile create researcher

# 安装 Kanban Worker 技能（必须）
hermes skills install devops/kanban-worker

# 安装专属技能
hermes -p researcher skills install web-search
hermes -p researcher skills install summarize

Token 成本控制：不同角色用不同档次的模型

在实际运行中，多 Agent 系统的 Token 消耗往往超出预期——单次复杂任务就可能消耗数十万甚至上百万 Token。控制成本的关键在于：不同职责的 Agent 使用不同档次的模型。

Hermes 支持为每个 Profile 单独配置模型，推荐分层策略如下：

Profile 角色推荐模型档次原因
Orchestrator（调度）高推理能力（Claude 3.5 / GPT-4o）需要理解复杂意图、拆解任务和路由决策
Researcher（调研）长上下文/包月模型（Kimi / GLM）处理大量文本搜索和摘要，性价比优先
Writer（写作）中等模型输出质量有要求，但不需要复杂推理
Coder（编码）代码专用模型（DeepSeek-Coder 等）专项能力更强，成本远低于通用大模型
# 为不同 Profile 分别配置模型
hermes -p orchestrator model set anthropic:claude-3-5-sonnet
hermes -p researcher   model set openrouter:moonshotai/kimi-k2
hermes -p writer       model set openrouter:glm-4-plus

这样，只有调度层使用高成本模型，执行层使用经济型模型，整体 Token 开销可降低数倍。

持久化：不怕崩溃，不怕重启

所有看板数据存储在 ~/.hermes/kanban.db，这意味着：

  • Agent 进程意外崩溃 → 任务进度完整保留
  • 关机重启后 → 自动从中断点继续执行
  • 跨天跨周的长周期任务 → 无缝衔接
hermes kanban list          # 查看所有任务及状态
hermes kanban stats         # 按状态汇总统计
hermes kanban tail <id>     # 实时跟踪指定任务的执行日志

目前 Hermes Kanban 尚未提供 Web UI，以上命令行是监控任务进度的主要方式。

Human-in-the-Loop：人工介入与防死循环机制

全自动的多 Agent 流程存在一个风险：当 Agent 遭遇歧义或数据矛盾时，如果没有干预机制，它可能自行做出错误决策，或陷入反复推理的循环状态。

Kanban 的 kanban_block() 机制解决了这个问题——它既是人工决策的入口，也是系统防止失控的安全阀：

T3: 综合分析
   │
   ├── 发现数据矛盾
   │
   └── block("两篇论文的结论相反，需要确认采纳哪篇")
         │
         ↑ 任务状态变为 blocked，用户收到通知
         │
         └── /unblock 采用 2025 年的最新论文数据
               │
         Dispatcher 重新拉起 T3
               │
         T3 读取用户反馈 → 继续执行

实现原理：

  1. Worker 调用 kanban_block(reason="...") → 任务状态变为 blocked
  2. 用户通过任意消息渠道发送 /unblock + 补充说明
  3. Dispatcher 重新拉起 Worker，注入用户的反馈内容
  4. Worker 读取反馈，继续执行后续步骤

多实例部署：在飞书/企微中同时操作多个 Agent

如果你希望在飞书或企微中同时与多个专业 Agent 对话（例如一个窗口与 Researcher 交互，另一个窗口与 Writer 交互），需要注意以下配置要点：

每个 Profile 必须对应独立的 Bot 和独立的 Gateway 端口。

# Profile A：Researcher，绑定飞书机器人 A，监听端口 8080
hermes -p researcher gateway start --port 8080

# Profile B：Writer，绑定飞书机器人 B，监听端口 8081
hermes -p writer gateway start --port 8081

操作步骤：

  1. 在飞书/企微创建多个独立的机器人，每个机器人对应一个 Profile
  2. 每个 Gateway 实例配置不同的端口，同时保持运行
  3. 通过各自的机器人对话窗口发送指令，即可定向控制对应的 Agent

⚠️ 已知问题：不要执行 --clone-all 指令，该操作会导致 profile 文件夹递归复制陷入无限循环。

小结

Hermes Kanban 的核心价值在于三点：解耦（Agent 不直接通信）、持久化（任务不因崩溃丢失）、可干预（人工随时插入修正）。

使用 Kanban 的配置复杂度高于简单的 delegate_task，但当你面对"3 个研究员并行搜索 → 1 个分析师汇总 → 1 个写手成稿 → 负责人审阅"这样的真实工作流时，它的可靠性和可控性会让整个过程上一个数量级。

项目地址：github.com/NousResearch/hermes-agent 官方文档：hermes-agent.nousresearch.com/docs