跳到主要内容

Hermes-Agent：多 Agent 方案

目录​

这一篇解决什么问题​

当你只有一个 Agent 进程时，所有任务都串行堆叠在同一条对话里：上下文会迅速膨胀，工具失败会污染后续推理，且不同任务之间很难做「强隔离」。Hermes 的官方 README 在特性列表里明确提到 Delegates and parallelizes：可以 spawn 隔离子代理（subagents）用于并行工作流，并提到用 Python 脚本通过 RPC 调用工具（README 中 Delegates and parallelizes 小节）。

本篇把这些能力翻译成工程语言：什么时候该并行、如何拆分子任务、失败如何隔离、权限如何收口，并提醒你在 Security 框架下做多 Agent 的必要控制。
具体 API、类名与 CLI 参数以你版本及 Architecture、CLI Reference 为准。

Hermes 官方叙事里的「多 Agent」能力​

从 README 的可读性角度，Hermes 的多 Agent 能力至少包含三层含义（每层都对应不同的工程决策）：

  1. 并行工作流：把独立子任务并行推进，缩短总耗时；适合「检索 + 生成 + 校验」这类可并行阶段。
  2. 隔离失败域：子代理失败不应拖垮主会话；否则你会把一次工具错误放大成整段对话不可用。
  3. 工具调用形态变化：README 提到用 Python 脚本通过 RPC 调用工具，把多步流水线压缩成更少轮次的对话交互（属于“工程化降本”方向）。

下面用一张抽象图帮助理解「主会话与子代理」的关系（教学用，非官方架构图）：

为什么要并行：吞吐、隔离与失败域​

并行不是「更快」这么简单：在 Agent 系统里，并行通常同时解决三个问题。

吞吐（Wall-clock time）​

当任务包含多个彼此独立的子查询（例如同时查三个数据源），串行会线性放大延迟；并行能把总耗时压到近似「最慢子任务」水平。

隔离（Blast radius）​

子代理隔离的意义是：一个子任务的工具调用失败、输出过长、或触发异常，不应污染主会话的推理链。否则你会看到「模型为了修复 A 的错误，把 B 的结论也搞乱」。

失败域（Failure domain）​

你需要提前定义：子代理失败时主会话是：

  • 重试（同样输入再来一次），
  • 降级（用更弱工具或只读模式），
  • 转人工（把任务挂起并通知）。

没有明确策略时，多 Agent 只会把失败变成更复杂的失败。

子代理与任务切分：如何定义边界​

好的切分通常满足：

  • 输入输出明确：子代理的输入是结构化 JSON/表格字段，而不是「把整段聊天历史丢进去」。
  • 依赖关系清晰：DAG（有向无环）优先；若必须循环，需显式最大迭代次数与终止条件。
  • 可验证：每个子任务都有可自动检查的完成条件（例如返回码、schema 校验）。

差的切分通常是：

  • 把「同一问题的不同表述」拆成多个子代理，彼此重复上下文，反而更费 token。
  • 子代理之间互相共享未脱敏的敏感数据，隔离名存实亡。

与工具链结合：RPC 脚本与「零上下文成本」叙事​

README 提到可以用 Python 脚本调用工具并压缩多步流水线（Delegates and parallelizes 段落中的描述）。工程上你可以把它理解为：

  • 把确定性步骤移出对话：能用代码写清楚的控制流，就不要让模型在对话里“猜下一步”。
  • 把工具输出裁剪后再回注：减少超长工具输出对上下文窗口的冲击。

但注意：这不是“没有成本”，而是把成本从“模型推理轮次”转移到“工程维护成本”。你需要测试、日志与回滚策略。

与终端后端（Docker/SSH/Modal…）叠加时的拓扑​

README 提到多种 terminal backends（本地、Docker、SSH、Daytona、Singularity、Modal 等）。当你叠加多 Agent 时，会出现新的问题：子代理是否共享同一后端？

  • 共享后端：运维简单，但隔离弱；一个任务把环境弄脏会影响后续。
  • 分后端：隔离强，但调度复杂、冷启动成本更高。

建议把选择写进架构文档：明确哪些任务允许共享后端、哪些必须独立容器/独立环境。

安全与权限：多 Agent 不是自动安全​

多 Agent 往往让人误以为「更高级就更安全」。实际上：

  • 子代理越多，工具调用面越多，需要更严格的 Security 与命令审批（README 亦强调安全相关能力）。
  • 供应链风险（MCP、外部脚本）会被并行放大；见 MCP Integration。

与 OpenClaw 迁移/并存时的注意点​

若你从 OpenClaw 迁移配置与技能（hermes claw migrate），多 Agent 策略不要假设两边完全一致：路由模型、会话工具与沙箱语义可能不同。迁移后请用 hermes doctor 作为基线检查，并阅读 Migrating from OpenClaw。

落地检查清单​

检查项说明
子任务边界每个子代理输入输出 schema 是否明确
失败策略重试/降级/人工的触发条件是否写清
权限子代理工具白名单是否比主会话更窄（默认建议）
日志能否关联子代理与主会话的 trace id
成本并行是否引入重复检索/重复调用

子代理输入输出：建议用“数据契约”而不是长文本​

并行时最大的坑是：子代理之间靠“自然语言”传状态，导致不可解析、不可重试、不可测试。建议至少把子任务输出约束为结构化 JSON（字段名按你业务定义），例如：

{
  "task_id": "t-20260416-001",
  "status": "ok",
  "result_summary": "一句话结论",
  "evidence_refs": ["url-or-doc-id-1", "url-or-doc-id-2"],
  "errors": []
}

这样做的直接好处是：

  • 可重试：同样输入再跑一次，便于定位 flaky 工具。
  • 可合并：主会话合并多个子结果时不容易丢字段。
  • 可审计：出事故时能复盘“到底哪一步返回了什么”。

失败重试：建议显式上限与退避​

并行任务遇到外部 API 限流时，若无限重试会把对话拖死。建议约定：

  • 最大重试次数（例如 3 次）
  • 退避（线性或指数）
  • 失败后的降级路径（只读、缩小工具集、转人工）

原文与延伸阅读​