openclaw + hermes 混合集群：用一个 Router 把两套 Agent“编成一队”（不卸载、不迁移、可灰度）

适用人群：已经稳定使用 openclaw 一段时间，又想尝试新出的 hermes，但不想卸载/迁移；更进一步，希望两者“混合在一起用”，形成一个 Agent 集群：对外只有一个入口，内部按能力/负载把任务分发给 openclaw 或 hermes。

文章目标：给出一套可落地的“统一入口路由（Router/Gateway）”方案，让 openclaw 与 hermes 既能各自独立运行，又能被统一调度、灰度、降级、扩缩容。

---

先说结论：为什么选“统一入口 Router”这条路

很多人一开始会把“共存”理解为：两套都装上、改改端口就行。但你想要的是更高级的形态：

• 对外一个入口：CLI/API/Web 只需要记一个地址

• 对内多后端：openclaw 与 hermes 同时在线，都能接活

• 可控调度：按任务类型/能力标签/负载情况来决定去哪边跑

• 可灰度可回滚：hermes 先分 10% 流量试跑，稳定后再逐步加

实现这些能力，最通用也最稳的方式是：把两者都当成“后端 Agent Service”，在前面加一层 Router/Gateway。

---

1. 总体架构（一图看懂）

下面这张图就是本文的“标准答案”：

你可以把它理解成：

• openclaw / hermes：两个“技能不同的队伍”（各自可扩容成多个实例）

• Router：队长/调度中心，接到任务后决定派谁上

• 共享记忆（可选）：让两边在同一个记忆库/向量库上协作（不强制，有就更强）

---

2. 你会遇到的“真实冲突点”（提前避坑）

把两套系统同时拉起来并不难，难的是长期稳定地一起跑。常见冲突点有：

1. 端口冲突
   两边默认可能都监听 8000/8080/3000 等端口。解决：明确为每套服务分配端口，再由 Router 统一入口。

2. 配置/数据目录冲突
   比如都写 ~/.config/...、~/.cache/...、/var/lib/...。解决：给每个后端划分独立的 DATA_DIR / CACHE_DIR / LOG_DIR。

3. 模型/缓存并发写冲突
   即便模型可共享，下载/解压/索引文件并发写很容易踩踏。解决：

• 最稳：每套服务各自一份缓存目录

• 进阶：模型目录共享但只读挂载（谁负责更新模型，统一一个“模型管理员”流程）

1. 资源抢占（尤其是 GPU 显存）
   “同时在线”不等于“同时满负载跑”。解决：在 Router 做并发/速率控制，必要时给某一侧设置最大并发。

---

3. 落地思路：把两套后端统一成“内部标准请求”

这里有个关键点：不要求 openclaw 与 hermes 的 API 形态完全一致。Router 的核心职责是做两件事：

1. 归一化输入（Internal Agent Request）
   把客户端请求统一成一个内部 JSON 结构（类似“内部协议”）。

2. 适配器（Adapter）
   对 openclaw、hermes 分别写适配器：把内部请求转换成它们各自能理解的 API 调用，再把返回结果统一格式化。

一个推荐的内部请求模型（示例）：

{
  "request_id": "uuid",
  "user_id": "optional",
  "task": {
    "intent": "chat|tool|search|plan|code|...",
    "priority": "low|normal|high",
    "tags": ["planning", "tool-heavy", "fast-response"]
  },
  "input": {
    "messages": [
      {"role": "system", "content": "you are ..."},
      {"role": "user", "content": "帮我..."}
    ]
  },
  "context": {
    "memory_namespace": "team-a",
    "tool_allowlist": ["browser", "shell", "db"],
    "trace": {"upstream": "forum-demo"}
  },
  "routing": {
    "preferred": "auto|openclaw|hermes",
    "canary": {"hermes_ratio": 0.1}
  },
  "runtime": {
    "timeout_ms": 60000,
    "max_steps": 20
  }
}

说明：字段不必一字不差照抄，重点是“内部先统一”，后面你想加记忆库、工具调用、队列化都更容易。

---

4. Router 的三件套：节点注册、健康检查、路由策略

4.1 节点注册：把 openclaw/hermes 都当成“候选节点”

用一个简单的配置就能描述你的集群（示例）：

clusters:
  openclaw:
    - name: oc-1
      base_url: http://127.0.0.1:8080
      capability: ["tool-heavy", "stable"]
      weight: 10
    - name: oc-2
      base_url: http://127.0.0.1:8082
      capability: ["tool-heavy", "stable"]
      weight: 10
  hermes:
    - name: hm-1
      base_url: http://127.0.0.1:8081
      capability: ["planning", "fast"]
      weight: 2

你可以先从“每边 1 个实例”开始跑通，再扩成多实例。

4.2 健康检查：不健康就自动剔除

Router 最少要做两层健康检查：

• 存活：能连上（TCP/HTTP 可达）

• 就绪：后端是否加载完成、模型是否可用（避免“服务启动了但不能干活”）

实操建议：

• Router 每隔 5～10 秒探测一次

• 连续 N 次失败就把节点标记为 unhealthy，暂时不分配流量

4.3 路由策略：你想要“集群感”，主要靠它

推荐从简单到高级分三步走：

（1）手动指定优先级（最简单）
请求里传 routing.preferred=openclaw|hermes，Router 直接定向。

（2）按标签/意图分流（最常用）
例如：

• tags 包含 planning → 优先 hermes

• tags 包含 tool-heavy → 优先 openclaw

（3）灰度/权重（最实用）
把一小部分流量打到 hermes：
hermes_ratio=0.1（10%），有问题立刻改回 0。

路由决策流程图：

---

5. 最小可用部署步骤（MVP：先跑起来再变强）

Step 1：确保两套后端“独立可跑”（端口 & 目录隔离）

你需要做到两件事：

• 端口不同：openclaw 例如 8080；hermes 例如 8081

• 目录分开：数据/缓存/日志各自一套

示意（路径仅供参考）：

/srv/openclaw/   -> data/, cache/, logs/
/srv/hermes/     -> data/, cache/, logs/

如果你现在 openclaw 是“官方脚本安装”，建议先别动它的安装位置，只要能在启动参数或环境变量里指定 data/cache 目录，就尽量指定；不能指定就至少先把 hermes 做好隔离。

Step 2：部署 Router（对外唯一入口）

Router 对外只暴露一个地址，比如：

http://your-host:8000

对内维护两个 pool：

• http://127.0.0.1:8080 → openclaw

• http://127.0.0.1:8081 → hermes

Router 的实现语言随你：Go/Node/Python 都行。本文重点不是“写哪个框架”，而是“协议归一化 + 适配器 + 路由策略”这套方法论。你甚至可以先用最小的 HTTP 转发服务快速验证链路。

Step 3：先用“手动 preferred”验证链路

先用最笨但最稳的方法：显式指定走哪边。

• preferred=openclaw：确认 openclaw 能通

• preferred=hermes：确认 hermes 能通

两条链路都 OK，再进入下一步。

Step 4：开启灰度（例如 10% → hermes）

建议从 1% 或 5% 开始，观察日志、失败率、响应时间，再逐步加到 10%/30%/50%……

---

6. 进阶：共享记忆/工具库，让“两套系统真的协作”

如果你想要的是“集群协作感”而不是“二选一”，可以逐步引入：

6.1 共享向量库/记忆库（推荐优先级：中）

把记忆库抽到外部组件（例如一个 Vector DB + 命名空间隔离），让 Router 在请求里注入：

• memory_namespace

• user_id/team_id

这样 openclaw 与 hermes 即便轮流处理任务，也能在同一知识底座上延续上下文。

6.2 统一工具调用层（推荐优先级：视情况）

如果两边 tool 体系不同，建议把“工具执行”也抽成独立服务（Tool Service）：

• Router/后端只负责“决定调用哪个工具”

• Tool Service 负责“真正执行 + 权限控制 + 审计日志”

这一步会让系统更像“平台”，但工作量也会明显增加。建议先把 Router 跑稳再做。

---

7. 常见问题（FAQ）

Q1：为什么不直接 Nginx 分流？
Nginx 适合静态路由（按域名/路径），但你要的是按任务能力、按灰度比例、按健康状况的“智能调度”，Router 更合适。

Q2：两边 API 不一样怎么办？
这正是“内部标准请求 + Adapter”的价值：Router 统一输入输出，后端差异都在适配器里消化。

Q3：如何快速回滚 hermes？
把灰度比例改成 0（或直接从 Hermes Pool 下线），流量立刻全回 openclaw。

Q4：同时跑会不会抢资源？
会。解决思路不是“祈祷不会抢”，而是：

• Router 端限制并发

• 给某一池设置最大并发/最大 QPS

• 必要时做资源隔离（例如不同 GPU、不同容器配额）

---

8. 小结

如果你想实现的是“openclaw + hermes 混合成 agent 集群”，最稳的落地路径是：

1. 两套后端独立可跑（端口/目录隔离）

2. 前置一个 Router，统一内部请求模型

3. 用 Adapter 吃掉两边 API 差异

4. 路由策略从手动 → 规则分流 → 灰度权重 → 健康检查降级

5. 需要“协作感”再逐步引入共享记忆/工具服务

我的博客即将同步至腾讯云开发者社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=7rdhy4heqmy