我用 Hermes Agent 搭了一套多 Agent 协作系统，选型思路和踩坑实录

这半年 AI Agent 热潮一波接一波，各家都在推自己的「智能体编排框架」，听起来都很厉害。但真正在生产环境里跑过的人知道，演示 Demo 和能用的系统之间，隔着整整一道工程化的鸿沟。

这篇文章不讲概念，不追热点，就讲一件事：我怎么把 Hermes Agent + Kanban + Skill 机制串成一套真正能用的多 Agent 协作系统，以及这个过程中踩了哪些坑。

1. 为什么选 Hermes 而不是 LangGraph/AutoGen

选型之前先说背景。我的需求是团队任务协作——不是纯研究，是真的要把一个需求从调研到交付跑完。

LangGraph 适合做图执行流，AutoGen 偏对话式协作。Hermes 打动我的是两件事：

第一，Profile 机制。每个 Profile 是一个独立 OS 进程，有自己的身份定义（SOUL.md）和可用工具集。这比在一个进程里模拟多 agent 要稳定得多——进程挂了不影响其他 agent，重启也不丢状态。

第二，Kanban + /goal 双轨并行。/goal 解决单 agent 持续执行的问题（不用反复催它）；Kanban 解决多角色分工的问题（谁做什么、谁等谁、谁block谁）。

2. 架构全貌

Gateway 是核心枢纽，18789 端口跑的是 WebSocket 服务。所有渠道（飞书、微信、CLI）的消息都先到这里，再路由到对应 agent。

3. Kanban 怎么跑起来

3.1 先建 Profile

hermes profile create researcher
hermes profile create analyst  
hermes profile create writer

每个 profile 目录下会有 SOUL.md，定义角色行为：

$ cat ~/.hermes/profiles/writer/SOUL.md
你是专业技术写作者，擅长把复杂概念用简洁语言解释清楚。
你写的文章结构清晰，有具体例子，有代码段落。
输出风格：简洁、不废话、直接给结论。

3.2 建任务和依赖链

# 建主任务
hermes kanban create "竞品调研报告" --assignee researcher

# 建子任务（自动等待主任务完成）
hermes kanban create "分析竞品功能差异" --assignee analyst --parent <research_id>

# 建第三级
hermes kanban create "输出技术博客初稿" --assignee writer --parent <analyst_id>

任务状态机：Created → Ready → In Progress → Done。中途可以 Block 等人工介入（比如 writer 发现数据不够，要 block 住让 analyst 补充）。

3.3 启动 Gateway

hermes gateway start
# 或者后台
hermes gateway start --port 18789 &

Gateway 重启不丢状态——Kanban 任务存在 SQLite 里，Gateway 起来以后继续读。

4. Skill 加载机制：三级分层按需加载

Hermes 的 Skill 机制是我目前见过最实用的 Agent 扩展方案。不是什么「插件市场」大而全的概念，而是按需加载、版本可控。

4.1 三级加载结构

第一级（builtin-skills）：内核级技能，随 agent 启动自动加载，不能删。比如 writing-plans、systematic-debugging。

第二级（installed-skills）：用户通过 hermes skills install 安装的技能。只有显式调用才加载，不占用启动时间。

第三级（dynamic-skills）：运行时按需发现和加载，适合一次性任务。

4.2 Skill 目录结构

SKILL.md 的 frontmatter 里有触发条件判断：

---
name: systematic-debugging
description: 四阶段根因排查法...
trigger:
  when:
    - "出现 error / exception / failed"
    - "用户要求排查问题"
  avoid:
    - "只是问概念"
    - "纯创作类任务"
---

Agent 收到消息后，Skill Loader 会遍历所有 installed-skills，用 frontmatter 的 trigger 条件判断当前任务是否匹配，优先加载匹配度最高的。

4.3 创建自己的 Skill

hermes skills create my-checklist

会创建标准目录结构，然后你自己写 SKILL.md：

---
name: my-checklist
description: 重复性任务检查清单
trigger:
  when:
    - "检查清单"
    - "例行巡检"
  avoid:
    - "一次性研究任务"
---
## 使用步骤

1. 读取上次巡检记录 `~/.checklist/last-run.json`
2. 执行各项检查命令
3. 对比变化，有异常输出警告
4. 保存本次结果

5. 把 Hermes 接进飞书和微信

Hermes 本身不处理渠道消息，靠 OpenClaw 做桥接层。架构是这样的：

OpenClaw Gateway 负责跟各个 IM 平台建立 WebSocket 长连接，收消息、转消息。Hermes Gateway（19000）是状态层，OpenClaw 通过 RPC 调用它的能力。

5.1 飞书配置

在 /root/.openclaw/openclaw.json 的 channels 字段里配置：

{
  "channels": {
    "feishu": {
      "enabled": true,
      "connectionMode": "websocket",
      "accounts": {
        "bot_common": {
          "appId": "cli_xxxx",
          "appSecret": "xxxx",
          "allowFrom": ["oc_your_channel_id"]
        }
      }
    }
  }
}

配置完成后，openclaw plugins enable feishu 启用插件，systemctl --user restart openclaw-gateway 重启服务。

5.2 踩过的坑：HOME 路径问题

systemd service 里 Environment=HOME=/root 和 Environment=HOME=/root/.hermes/profiles/commander/home 读到的是完全不同的两套配置。

OpenClaw 数据目录默认在 ~/.openclaw/，如果 HOME 指向了其他路径，它会读另一个目录的数据。我的飞书配置全在 /root/.openclaw/ 里，但 service 里 HOME 指到了 pipeline 目录，导致飞书 bot 始终读不到真实配置，crash 了 9000 多次。

修复：把 user service 的 HOME 改回 /root。

6. LLM Wiki：知识的复利系统

6.1 为什么不是 RAG

RAG（检索增强生成）是每次 query 从原始文档里检索相关内容，缺点是：知识是散的，每次都重新发现。

LLM Wiki 是 Andrej Karpathy 提出的概念，核心是知识持久化积累。新资料进来 → LLM 提取关键概念 → 写入 wiki → 下次 query 直接从 wiki 综合回答。越用越聪明，有复利效应。

6.2 三层架构

Layer 2 的 wiki 目录结构：

• wiki/sources/：每篇原始文章一个摘要
• wiki/concepts/：跨文档提炼的概念模式
• wiki/entities/：实体（人/工具/组织）

6.3 Obsidian 图谱的价值

所有 wiki 页面用 [[wikilink]] 互链，Obsidian 的图谱视图（Ctrl+G）可以直观看到知识间的关联。当某个概念被多篇文章引用，它在图谱里节点越大、边越粗——这是 RAG 没法给你的全局视野。

7. 实际跑起来的感受

好用的部分：

• Profile 隔离稳定，researcher 挂了不影响 analyst 和 writer
• /goal 真的省心，设置完不用催，等结果就行
• Skill 机制灵活，需要什么装什么，不用全塞进启动项

踩坑的部分：

• OpenClaw 的 self-update 会改写 CLI 二进制，可能写到错误目录（pipeline 目录 vs 真实目录）
• systemd service 的 HOME 环境变量容易被其他安装过程改掉，需要定期检查
• Hermes Gateway（19000）和 OpenClaw Gateway（18789）是两套独立进程，排障时要分别看日志

不推荐的用法：

• 不要把 Hermes 当通用 ChatGPT——它的强项是任务协作，单 agent 场景不如直接用 Claude Code CLI
• 不要上来就装一堆 skill——按需加载，装多了每次触发判断慢

8. 总结：什么场景适合用这套架构

核心判断逻辑就一句话：任务越复杂、角色越多、时间跨度越长，这套架构优势越明显。简单任务用轻量工具反而更划算。