Hermes Orchestrator（编排器）— 完整手册

Orchestrator 是 Hermes 的"大脑"，收到复杂任务时自动判断要不要拆解、怎么拆、派发给谁。

一、为什么需要 Orchestrator

没有 Orchestrator 时，Agent 只有一个会话、一条线：

你：帮我把登录系统做完
     ↓
Agent：好的
     → 先写界面（30s）
     → 再写网络层（30s）
     → 再写服务端（60s）
     总共耗时：120s 串行
     ↓
你：干等着它一个个做

有 Orchestrator 时：

你：帮我把登录系统做完
     ↓
Orchestrator：
  "这个任务可以拆成 3 个互不依赖的子任务"
     ↓
  并发派发：
    Worker A → 写界面     (30s)
    Worker B → 写网络层    (30s)    ← 同时进行
    Worker C → 写服务端    (60s)
    总共耗时：60s（最慢的那个）
     ↓
  收集结果 → 汇报

时间节省：120s → 60s，而且你不用参与中间过程。

二、Orchestrator 的判断逻辑

收到一个任务时，Orchestrator 的工作流程：

收到任务
    ↓
是否开启编排？（orchestrator_enabled）
    ├── 否 → 当作普通任务，自己不拆，单线程做
    └── 是 → 判断能否分解
            ↓
    有 auto_decompose？
    ├── 否 → 等待你用 writing-plans 告诉它怎么拆
    └── 是 → 自动分析任务，决定：
            │
            ├── 太简单（改个变量名）→ 不拆，自己直接做
            ├── 中等（改一个模块）→ 拆 2-3 个子任务
            └── 复杂（重构整个项目）→ 拆多个子任务 + 分批派发
                 ↓
    派发给 worker（最多 max_concurrent_children 个）

三、配置详解

# ~/.hermes/config.yaml
delegation:
  orchestrator_enabled: true       # 是否启用编排
                                   # true → 自动拆解大任务
                                   # false → 所有任务单线程做

  max_concurrent_children: 3       # 同时最多几个子任务并行
                                   # 设置太大：API 并发超限
                                   # 设置太小：串行效率低
                                   # 3 是平衡值

  max_async_children: 3            # 后台异步子任务上限
                                   # 和上面的区别：
                                   # concurrent = 你还在对话中
                                   # async = 你切去做别的事了

  max_spawn_depth: 1               # 子任务能不能再拆孙子任务
                                   # 0 = 不拆
                                   # 1 = 子任务不能再拆
                                   # 2 = 子任务可以拆孙子任务
                                   # 防止无限递归

  child_timeout_seconds: 0         # 子任务超时时间
                                   # 0 = 不限时
                                   # 3600 = 1 小时没做完强制终止

  subagent_auto_approve: false     # 子任务操作是否自动批准
                                   # false → 每个子任务操作需要你确认
                                   # true → 子任务自己决定，不打扰你

  max_iterations: 50               # 单个任务的总体迭代次数上限
                                   # 防止死循环

  orphan_timeout: 300              # 子任务失联后多久判定为孤儿（秒）
                                   # 仅 gateway 模式有效

和 Claude Code 的对比

四、实际使用方式

方式 1：完全自动（推荐）

什么都不用配置，直接说：

重构战斗系统的核心逻辑，包括状态机、AI、伤害计算

Hermes 自动判断能不能拆、怎么拆、并发跑。

方式 2：指定 worker profiles

如果有多台机器的 Hermes 实例：

# ~/.hermes/profiles/client.yaml → 客户端开发机器
# ~/.hermes/profiles/server.yaml → 服务端开发机器

帮我把登录系统做了，客户端部分用 client profile，服务端部分用 server profile

方式 3：和 Kanban Swarm 配合

hermes kanban swarm "实现登录系统" \
  --worker client:登录界面 \
  --worker server:登录接口 \
  --verifier senior-dev \
  --synthesizer lead-dev

Kanban 上会看到 5 张卡片（3 Worker + 1 Verifier + 1 Synthesizer），Orchestrator 控制执行顺序。

五、常见问题

Q: Orchestrator 能编排 Claude Code 吗？

不能。Orchestrator 只能在 Hermes 自己的 profiles 之间编排。如果需要编排 Claude Code，需要通过 Nacos 或共享看板的方式间接协作。

Q: 自动拆错了怎么办？

auto_decompose: true 不一定每次拆得对。可以显式关闭自动拆解：

auto_decompose: false

然后你自己用 writing-plans 输出方案让 Hermes 执行。

Q: 子任务做一半失败了？

failure_limit=2：同一任务重试 2 次还是失败，就标记 Failed 并通知你。你修复后手动 promote 重新执行。

Q: 3 个并发不够？

max_concurrent_children: 5

但注意 API 并发限制，一般 3 是安全值。

六、Orchestrator 执行过程（有 Kanban 时）

Orchestrator 检测到看板上有新任务
    ↓
Kanban: Todo → In Progress（标记为有人在做）
    ↓
子任务拆分
    ↓
每个子任务创建为独立卡片，建立依赖关系
    ↓
子任务 Ready → worker claim → 执行
    ↓
worker 完成 → Kanban: Done
    ↓
依赖该子任务的其他子任务自动变为 Ready
    ↓
所有子任务 Done
    ↓
父任务 Done