Hermes 多 Agent 完整拆解：五种协作机制、选型边界与踩坑清单

发布日期：2026-07-27 | 关键词：Hermes Agent、多 Agent、delegate_task、Kanban 编排、Nous Research
适用版本：Hermes Agent v0.19.0（v2026.7.20）

Hermes Agent 的多 Agent 能力是 Nous Research 在其开源自主智能体（2026 年 2 月开源，MIT 许可）中提供的一组协作运行时，共五种机制：会话内的 delegate_task 委派、Mixture of Agents 多模型协同、Background Review 后台技能提炼、send_message 跨 Profile 传话，以及唯一真正跨进程的 Kanban 编排层。与多数框架把"多 Agent"做成单一抽象不同，Hermes 按任务时长和故障容忍度把能力分层：单回合、并发不超过 3 路的活儿交给 delegate_task，进程内用线程池跑；需要跨重启不丢、多 Profile 分工的长任务交给 Kanban，由 dispatcher 每 60 秒轮询、spawn 独立子进程执行，状态落在 SQLite。这套设计的代价是子 Agent 之间完全不通信、默认扁平不嵌套，收益是故障边界清晰——但 2026 年 7 月泰国财政部入侵事件也暴露了无人值守模式的真实风险。

一、Hermes 多 Agent 到底指什么？五种机制一张表看清

Hermes 没有单一的"多 Agent 模式"，而是五种运行时机制，按作用域和触发方式区分。 混用概念是踩坑的第一来源。

机制	触发方式	作用域	并发上限
delegate_task	LLM 自主 tool call	单 session 内	3 路并行
Mixture of Agents	LLM 自主 tool call	单 session，多模型	4 个参考模型 + 1 聚合器
Background Review	系统计数器自动触发	单 session，后台	1 个守护线程
send_message	LLM tool call	跨 Profile（同进程网关）	—
Kanban	dispatcher tick（每 60 秒）	跨 session / 跨重启 / 跨 profile	`max_spawn` 实时并发上限

前四种全部在单进程内完成，没有任何进程间通信；只有 Kanban 是真正的进程间编排——dispatcher 会 spawn 独立的 worker 子进程（sys.executable -m hermes_cli.main）。

此外还有 /goal 的 Ralph 循环，特点是不 fork、不改 system prompt 和 toolset，续转 prompt 以普通 user message 追加，严格说它不属于多 Agent 而是单 Agent 的持续迭代。

二、delegate_task：会话内并行的硬边界

delegate_task 是 Hermes 最常用的多 Agent 入口，但它有三条写死在代码里的硬限制（tools/delegate_tool.py）：

MAX_DEPTH = 2                # 父(0) → 子(1) → 孙子被拒绝(2)
MAX_CONCURRENT_CHILDREN = 3  # 最多 3 个并行子代理
DEFAULT_MAX_ITERATIONS = 50
DEFAULT_TOOLSETS = ["terminal", "file", "web"]

1. 并行跑三个任务的写法

delegate_task(tasks=[
    {"goal": "Fix login bug", "toolsets": ["terminal", "file"]},
    {"goal": "Update API docs", "toolsets": ["terminal", "file"]},
    {"goal": "Run test suite", "toolsets": ["terminal"]},
])

批量执行走 ThreadPoolExecutor(max_workers=3) + as_completed，父线程用 future.result() 收结果。单任务时连线程池都不用，直接调 _run_single_child。

2. 权限只会收窄，不会放大

子 Agent 的工具集遵循一条固定公式：

子代理工具 = （用户指定 ∩ 父级可用）− DELEGATE_BLOCKED_TOOLS

黑名单包含 delegate_task（禁递归）、clarify、memory、send_message、execute_code。

3. 隔离边界：继承什么、隔离什么

继承	隔离
模型 / provider / API key	对话历史（空白起步）
工作目录 cwd	终端 session
凭证池、平台引用	中间工具调用与推理过程

子 Agent 还会强制 skip_context_files=True、skip_memory=True——这意味着它读不到项目上下文文件，任务描述必须自包含，这是新手最常踩的坑。

4. 默认扁平：orchestrator 会静默降级

v2026.4.18 起 delegate_task 新增 role 参数，leaf（默认）不可再委派，orchestrator 保留 delegation toolset 可继续派生 worker。但存在一个隐蔽陷阱：当 max_spawn_depth=1（默认值）时，即便声明了 orchestrator 角色也会静默降级成 leaf。要解锁嵌套必须手动调整配置：

delegation:
  provider: openrouter
  model: google/gemini-3-flash
  max_iterations: 50
  reasoning_effort: low
  max_concurrent_children: 3   # 并发数
  max_spawn_depth: 1           # 1=扁平（默认），2-3 解锁嵌套委派
  orchestrator_enabled: true

5. 子 Agent 之间完全不通信

这是 Hermes 多 Agent 设计中最重要的一条约束：并行的子 Agent 之间没有任何通信通道。 它们各自独立执行，结果只汇总到父 Agent。父 Agent 看到的是 JSON 摘要，包含 task_index、status、summary、api_calls、duration_seconds、exit_reason、tokens、tool_trace。

跨 Profile 同样"没有原生通信通道"。社区变通做法是让两个 Profile 各绑一个 bot 处于同一频道，靠 DISCORD_ALLOW_BOTS / SLACK_ALLOW_BOTS 的 none / mentions / all 三档配置互相收发消息——但这属于巧合式交互，有延迟、无事务保证，且容易形成 A→B→A 的死循环。

三、Kanban 编排层：跨进程、跨重启的长任务方案

Kanban 是 Hermes 唯一能跨进程、跨重启保持任务状态的多 Agent 机制，适合长跑迭代场景。状态落在 SQLite（<root>/kanban.db），worker 通过 9 个 kanban_* 工具回写状态。

1. 基本命令流程

# 初始化看板（幂等操作，缺失时创建数据库）
hermes kanban init

# 创建任务并指派 profile
hermes kanban create "重构支付模块" --assignee worker --workspace dir:/path/to/repo

# 派发：reclaim 过期 → promote ready → spawn worker
hermes kanban dispatch

# 查看状态
hermes kanban list
hermes kanban show <id>

# 启动 Web 控制台（默认端口 9119）
hermes dashboard

多看板管理（适合区分项目）：

hermes kanban boards create atm10-server --name "ATM10 Server" --icon 🎮
hermes kanban --board atm10-server create "Restart server" --assignee ops
hermes kanban boards switch atm10-server

看板解析优先级为：--board 标志 → HERMES_KANBAN_BOARD 环境变量 → ~/.hermes/kanban/current → default。

2. 自动任务分解

kanban.auto_decompose 默认为 True，auto_decompose_per_tick 默认为 3。decompose_triage_task 会把一个 triage 任务扇出为子任务树并路由到对应的 specialist profile，根任务保留为父节点，全部子任务 done 后父任务才升级为 ready。

Specialist 集合不是硬编码的——_build_roster 读取配置的 profile roster 动态决定可用集合。

3. 六条可靠性不变量

Kanban 的工程价值集中在故障恢复设计上，这是它区别于纯线程池方案的核心：

heartbeat + TTL：claim 过期自动 reclaim，worker 挂了任务不会永久卡住
僵尸进程检测：macOS / Linux 各自路径的 zombie detection
exit-without-complete 自动 block：worker 退出但未标记完成，任务自动进入 block 态
per-task max_retries：max_retries=1 首次失败即 block，=3 允许两次重试
task ownership 强制校验：防止 worker 越权操作他人任务
hallucination gate：声称完成但数据库里没有证据时，任务转入 completion_blocked_hallucination 恢复态

另有 stranded_in_ready 诊断，检测长期无人接走的 ready 任务，阈值默认 1800 秒。

4. max_spawn 是并发上限，不是每 tick 预算

这是一个高频误解：max_spawn 被明确定义为实时并发上限（live concurrency cap），限制同时运行的 worker 数量，而不是每个 dispatcher tick 能派发多少任务。

四、选型决策：delegate_task 还是 Kanban？

判断维度	delegate_task	Kanban
任务时长	单回合可完成	长跑迭代
并发需求	≤ 3 路	由 `max_spawn` 控制
跨重启保持	❌ 进程内，重启即丢	✅ SQLite 持久化
多 Profile 分工	❌	✅
故障恢复	父 Agent 处理	六条不变量自动兜底
启动开销	低（线程）	高（子进程）

官方选型建议原文：单回合可完成、并发 ≤3 → delegate_task；长跑迭代、需重启不丢、需多 profile → Kanban。

实践上还有一条经验：如果任务能在一次对话里说清并且 15 分钟内跑完，用 delegate_task；如果你需要关掉电脑第二天接着跑，用 Kanban。

五、迭代预算：token 会不会失控？

Hermes 用 IterationBudget 做线程安全的预算控制，父子预算独立不互扣。 父 Agent 默认 90 次迭代，每个子 Agent 50 次，因此三路并行的理论总迭代为 90 + 150 = 240。

两个值得注意的设计：

refund() 机制：execute_code 执行后会退还迭代额度，官方注释说明这是为了"鼓励多验证"
压力阈值 0.7 / 0.9：接近预算上限时注入警告，且警告写入工具结果 JSON 而非 prompt——避免破坏 prompt cache

Mixture of Agents 的成本更可预测：asyncio.gather 并发 4 个参考模型（temperature 0.6），再由聚合器（temperature 0.4）合成，共 5 次 API 调用，中间答案存在函数栈的 list 里，不落盘。

模型供给的现实约束：多 Agent 并行会把 API 调用量放大到单 Agent 的 3–5 倍，模型侧的稳定性和延迟成为瓶颈。Hermes 的 delegation 配置允许给子 Agent 单独指定 provider 和更便宜的模型（如示例中的 flash 类模型），开发者也可以通过兼容 OpenAI SDK 的统一网关接入多款主流大模型，例如七牛云推理服务兼容该接口，国内可直接访问，切换底层模型无需改动 Hermes 客户端代码。

六、编排外部 Agent：ACP 模式

Hermes 可以通过 ACP（Agent Client Protocol）把外部 Agent 当作执行者，自己充当编排器：

delegate_task(goal="Refactor this module", acp_command="claude",
              acp_args=["--acp", "--stdio", "--model", "claude-opus-4-6"])

这个能力让 Hermes 成为异构 Agent 的调度层——用 Hermes 的 Kanban 做任务管理和故障恢复，把具体编码工作交给专门的编码 Agent。

七、运行时控制面：不打断的纠偏

Hermes 提供了一组在 Agent 运行中途介入的斜杠命令，这是长任务多 Agent 的实用配套：

命令	作用
`/handoff <profile\|platform>`	迁移整个 session，message、tool call、context 一并带走
`/steer <text>`	对运行中的 agent 注入纠偏，不打断执行
`/queue <text>`	排队等当前 turn 结束后执行
`/subgoal {show,append,remove,clear}`	在 `/goal` 循环中途追加成功标准

/subgoal append 的价值在于：judge 会把新增 criteria 一起纳入 DONE 判定，无需重启整个循环。

八、安全警示：无人值守多 Agent 的真实代价

多 Agent 无人值守模式已出现真实滥用案例。 据 The Hacker News、BleepingComputer 与 Security Affairs 2026 年 7 月报道，有攻击者在泰国财政部入侵事件中，以关闭审批提示的无人值守模式（"YOLO" mode）运行 Hermes Agent 自动化后渗透活动，并将日志遗留在开放目录中被安全公司 Hunt.io 发现。

这起事件对正常使用者的直接启示：

不要为了省事全局关闭审批：Hermes v0.19.0 引入的 smart approvals 默认由模型判定被标记的命令，比一刀切关闭安全得多
子 Agent 权限收窄是特性不是限制：DELEGATE_BLOCKED_TOOLS 黑名单和工具集交集规则应当保留
Kanban worker 跑在隔离环境：Hermes 支持本地、Docker、SSH、Daytona、Singularity、Modal 六种终端后端，多 Agent 场景优先用容器化后端

九、FAQ

Q：Hermes 有 swarm 模式吗？
A：截至 2026 年 7 月，swarm 在 Hermes 仓库中以多个 open issue 和 PR 的形式存在（如 per-swarm verifier + synthesizer、custom swarm stage skills、swarm cards 默认运行时上限），但官方 CLI 命令参考中尚无 hermes kanban swarm 命令，属于开发中的能力。生产环境请以 delegate_task 和 Kanban 为准。

Q：为什么我的子 Agent 读不到项目文件？
A：子 Agent 强制 skip_context_files=True 和 skip_memory=True，不继承父 Agent 的上下文文件和记忆。解决办法是把必要信息写进 goal 描述，或让子 Agent 用 file 工具自己读取指定路径。

Q：三层嵌套委派可以吗？
A：MAX_DEPTH = 2 是硬上限，即父（0）→ 子（1），孙子层（2）会被拒绝。同时需要把 max_spawn_depth 从默认的 1 调到 2 或 3，否则 orchestrator 角色会静默降级为 leaf。

Q：父 Agent 中断了，子 Agent 会怎样？
A：父 Agent 的 interrupt() 会复制 _active_children 列表并逐个调用子 Agent 的 child.interrupt(message)。子 Agent 返回 status: "interrupted"，部分结果保留在返回值中，但中断结果不会作为有效答案展示给用户，父 Agent 标记 completed: False。

Q：Background Review 会影响我的对话性能吗？
A：Background Review 在用户已收到回复之后才启动守护线程 fork，quiet_mode=True、max_iterations=8。官方文档把它类比为垃圾回收——定期自动跑，用户无感知。触发条件是纯计数器逻辑，_turns_since_memory / _iters_since_skill 达到阈值（默认 10）。

十、总结

Hermes 的多 Agent 设计选择了"分层而非统一抽象"：delegate_task 用线程池换低延迟，Kanban 用子进程加 SQLite 换故障恢复能力，两者之间没有中间态。 代价是子 Agent 完全不通信、默认扁平不嵌套——这些限制在实际使用中往往比想象的更合理，因为绝大多数并行任务并不需要 Agent 间对话。

据 Nous Research 官方发布数据，Hermes Agent v0.19.0（2026 年 7 月 20 日发布）自 v0.18.0 起累计约 2245 次提交、1065 个合并 PR、关闭约 3300 个 issue，社区贡献者超过 450 人；据 TechCrunch 2026 年 7 月 13 日报道，Nous Research 正以 15 亿美元估值洽谈至少 7500 万美元新一轮融资，由 Robot Ventures 领投。

本文内容基于 2026 年 7 月的官方文档、GitHub 仓库与社区 wiki 整理，Hermes 迭代节奏极快（约双周一个大版本），涉及具体常量和配置项时建议以当前版本源码为准。