多Agent协作的两种极端：同步阻塞与异步编排的深度实战对比

当你需要让多个AI Agent协同完成复杂任务时，应该选择”命令-控制”式的紧密管理，还是”交响乐团”式的松散编排？这个选择将直接决定系统的响应速度、资源消耗和可扩展性。

在现代AI Agent系统的演进中，多Agent高效协作已成为核心命题。市场上主流的方案呈现两极分化：一端是以Hermes为代表的同步阻塞模式，追求极致的隔离性和token效率；另一端是以OpenClaw为代表的异步编排系统，强调灵活性和动态干预能力。本文将深入剖析这两种设计哲学在架构、通信模式和适用场景上的本质差异，帮助你在实际项目中做出正确决策。

两种设计哲学的根本差异

核心问题：Hermes和OpenClaw在本质上有何不同？为什么它们代表了多Agent协作的两个极端？

Hermes采用”总承包商-分包商”模式，父Agent像项目经理一样，将任务拆解后分发给子Agent，然后阻塞等待所有结果返回。这种设计追求极致的隔离性：子Agent的所有中间推理过程都不会污染父Agent的上下文窗口，最终只返回一个精炼的summary。

同步阻塞模式示意图

相比之下，OpenClaw的subagent系统更像交响乐团的编排。父Agent定义全局拓扑后，各个Agent作为固定角色异步运行，通过事件推送机制相互协作。更关键的是，父Agent甚至可以在子Agent运行期间发送”引导消息”调整方向，这种灵活性是Hermes所不具备的。

异步编排模式示意图

这种差异不仅是技术实现的不同，更是设计哲学的分歧：Hermes相信”越少上下文越好”，通过严格隔离防止信息污染；OpenClaw则认为”适度可见性是必要的”，通过受控的信息流动实现动态协调。

Hermes Delegate：精简高效的并行执行器

核心问题：Hermes的delegate_task机制具体如何工作？它的技术实现有哪些关键细节？

Hermes的实现集中在978行的delegate_tool.py中，代码行数本身就暗示了这是一个轻量级、专注单一职责的设计。它支持两种工作模式：

单任务模式：提供一个goal参数启动单个子Agent同步执行，适用于简单的子任务委派。

批量模式：接受最多3个任务的数组，通过ThreadPoolExecutor并行处理。这是Hermes的硬编码限制，无法通过配置更改。

子Agent的构造与隔离策略

每次委派都会创建全新的AIAgent实例，这种”用完即弃”的哲学确保了严格的上下文隔离：

  • 独立的对话历史：子Agent不会继承父Agent的任何中间推理过程
  • 独立的Terminal session：每个task_id对应独立的工作目录和状态
  • 专门构建的System Prompt：结构简洁明确，以”You are a focused subagent working on a specific delegated task”开头，包含任务目标、可选的上下文信息，以及从父Agent解析出的工作目录路径

子Agent的配置遵循严格的继承规则：模型可以继承父Agent或使用delegation.model配置；工具集通过交集计算（子不能获得父没有的工具）；凭证可以共享父的credential pool或独立配置。

工作空间规则是System Prompt中的重点强调：”Never assume a repository lives at /workspace/……”。这种显式的路径声明避免了子Agent因假设错误而导致的文件操作失败，在实际开发中，这种防御性编程显著减少了路径相关的bug。

安全沙箱：工具剥夺机制

为了防止失控，Hermes对子Agent进行了严格的工具剥夺，这种”最小权限原则”在安全敏感场景中至关重要：

  • delegate_task本身被禁用：防止递归委派导致的无限循环和资源耗尽
  • clarify被移除：使其无法与用户交互，避免用户体验碎片化
  • memory工具被剥夺：保护共享记忆不被子Agent意外修改或污染
  • execute_code被禁用：避免子Agent编写复杂脚本带来的安全风险
  • send_message被移除：防止跨平台消息发送导致的潜在滥用

反思：这种严格的安全策略让我联想到微服务架构中的”故障隔离舱”设计。虽然看起来过于严格，但在生产环境中，一个没有经验约束的子Agent确实可能因为一次不当的execute_code调用而耗尽服务器资源，或者通过memory工具污染全局状态。Hermes的设计者显然经历过这些痛点。

生命周期与深度控制

Hermes实施了严格的深度限制：MAX_DEPTH = 2。这意味着父Agent（深度0）可以spawn子Agent（深度1），但子Agent不能再spawn孙子Agent（深度2会被拒绝）。每个子Agent在构造时会递增深度标记_delegate_depth，在调用前检查是否超限。

这种”仅一代”的限制看似束缚，实则是对复杂度的刻意控制。在实际项目中，我观察到过深的Agent嵌套往往会导致调试困难和故障定位的复杂性呈指数级增长。

子Agent的迭代上限默认为50轮（DEFAULT_MAX_ITERATIONS，可通过config.yaml配置）。关键缺陷在于没有时间维度的超时控制：future.result()调用不带timeout参数，这意味着子Agent理论上可以无限期运行直到耗尽迭代次数。如果子Agent每轮都调用慢速LLM，50轮可能跑数小时。

Token效率对比示意图

Token效率与通信模式

Hermes采用纯粹的单向Request-Response通信模式。父Agent构造goal和context后调用delegate_task()，然后阻塞等待。子Agent之间完全无通信，所有中间tool调用和推理链都不进入父的上下文窗口。

唯一的”进度通知”是UI层面的callback（在CLI的spinner上方打印工具调用，或在Gateway中批量中继工具名称），但这不是语义通信，只是进度显示。

这种设计在Token消耗上极其高效：假设父Agent上下文为10K token，委派3个子任务，每个子任务消耗5K token，总消耗仅为10K + 3×5K = 25K token。子Agent的结果被压缩为精炼的summary，父Agent的上下文几乎零膨胀。

异常终止的级联机制

子Agent的凭证解析遵循三级优先级：

  1. 首先检查delegation.base_url配置，如果存在则使用该端点和api_key
  2. 其次检查delegation.provider配置，通过runtime provider系统解析完整凭证
  3. 如果都没配置，子Agent继承父Agent的全部凭证

当子Agent与父Agent使用同一provider时，它们共享同一个credential pool（cooldown状态同步）；否则加载该provider独立的pool。每个子Agent获取凭证lease后，在finally块中自动释放。

学到的教训：这种设计存在一个明显短板——缺少超时机制。在实际生产环境中，如果一个子Agent陷入死循环或调用外部慢速API，父Agent将无限期等待。我曾经历过一个数据分析子任务因处理异常大文件而卡住，导致整个工作流停滞数小时的尴尬局面。这是Hermes最需要改进的地方。

OpenClaw Subagent：异步协作的编排系统

核心问题：OpenClaw提供了哪些Hermes不具备的能力？它的异步架构如何解决实际痛点？

OpenClaw构建了完整的层级化Agent架构，定义了三种角色：

  • main：主Agent，负责全局协调
  • orchestrator：编排器，可继续spawn子Agent
  • leaf：叶节点，不可再spawn，专注执行

默认配置下，全局最多支持8路并发，每个Agent最多管理5个活跃子Agent，嵌套深度可配置（而非Hermes的硬编码限制）。

异步事件驱动的通信模式

OpenClaw的核心创新在于异步推送机制。父Agent spawn子Agent后立即返回，继续处理其他任务。子Agent完成后，通过runSubagentAnnounceFlow()将结果以”user message”形式推送回父Agent。

文档明确声明：”不要调用sessions_list、sessions_history或任何轮询工具，等待完成事件自动到达。”这种推送式设计避免了轮询开销，在事件驱动架构中，父Agent可以并发管理多个子Agent而不会阻塞。

独特见解：这种模式让我想到现代Web开发中的WebSocket与传统轮询的区别。Hermes像同步Ajax调用，简单但阻塞；OpenClaw像WebSocket，复杂但能处理真正的并发。对于需要同时监控多个长耗时任务的场景，异步模式几乎是唯一选择。

Steer机制：运行时的动态干预

OpenClaw最强大的能力是Steer机制。父Agent可以向运行中的子Agent发送引导消息，触发其重新调整方向。这种能力有限流保护（每2秒最多一次），消息最大4000字符。

这正是Hermes最缺失的能力——当用户在Gateway中发送新消息时，Hermes只能暴力interrupt所有子Agent，而OpenClaw可以判断用户意图，选择性地引导或查询进度。

实际场景：想象一个 research agent正在检索资料，用户突然想修改搜索关键词。在Hermes中，你必须杀死整个research agent然后重启；在OpenClaw中，你可以发送一个steer消息：”请重点关注2024年以后的论文”，子Agent会调整方向继续运行，已完成的检索工作不会浪费。

生命周期管理

OpenClaw提供了完整的生命周期管理：

  • runTimeoutSeconds参数（默认300秒）：提供时间维度的控制，防止无限运行
  • runs.json持久化：保存运行记录支持orphan recovery
  • resumeSessionId：允许恢复已有会话，避免重复工作

这些机制使其适合长流程、多阶段的复杂任务。在需要跨会话保持状态的生产环境中，持久化能力是不可或缺的。

通信成本分析

灵活性是有代价的。OpenClaw的announce推送会将子Agent的结果注入父Agent的上下文，频繁的steer消息也会产生额外token开销。

假设同样的3个子任务场景，每次announce约1K token，父Agent的上下文会从10K增长到13K，总消耗约28K token，比Hermes多12%。在高频交互场景下，这种开销会累积。

反思：这种trade-off让我思考”隐形成本”问题。虽然OpenClaw单任务消耗更多token，但如果考虑到Hermes因缺少超时机制导致的资源浪费（一个卡住的任务可能占用资源数小时），OpenClaw的总拥有成本可能更低。架构选择不能只看表面指标。

架构对比示意图

架构差异的深层逻辑

核心问题：为什么会有这些设计差异？从信息论和安全角度看，各自的优势在哪里？

两者最大的分水岭在于同步与异步的本质差异：

Hermes的同步阻塞意味着父Agent在子运行期间完全停滞，无法响应新需求。这种”单线程”思维简化了状态管理，但牺牲了并发性。

OpenClaw的异步推送允许父Agent同时管理多个子Agent，动态调整策略。这需要更复杂的状态机，但提供了真正的并行处理能力。

从信息论视角看，Hermes的子Agent是有损压缩器：将大量中间tool调用和推理链压缩为一个summary字符串。这种设计在”单点决策 + 批量执行”场景下极其高效：父Agent做规划，子Agent只负责执行和返回，上下文零膨胀。

OpenClaw则更像分布式系统，需要维护复杂的拓扑状态和消息路由。它的Steer能力解决了Hermes的最大痛点：用户查询进度时的优雅处理。

从安全视角看，Hermes的强隔离形成天然沙箱，子Agent被剥夺所有”向外逃逸”的工具，适合安全敏感场景。OpenClaw的子Agent保留更多能力，但也意味着更大的攻击面和潜在的副作用风险。

实战选择指南

核心问题：面对具体项目时，如何做出正确的选择？

选择Hermes的场景

如果你需要并行处理3件互不相关的事情，且不希望中间数据污染主对话，Hermes是最佳选择：

  • 快速集成：天然并行、隔离干净、一个tool call搞定
  • Token敏感：极致的token效率，适合长上下文模型成本敏感的场景
  • 简单子任务：不需要中途调整方向的确定性任务

具体操作：在config.yaml中配置max_iterations控制运行轮数，通过delegation.model指定子Agent模型（可以使用比父Agent更轻量的模型以节省成本）。

选择OpenClaw的场景

如果你的任务需要在子Agent运行中调整方向，或者需要超时控制防止无限运行：

  • 动态干预：需要Steer机制调整运行中任务
  • 外部Agent集成：调用Claude Code、Codex等外部工具作为子Agent（通过ACP协议）
  • 长流程任务：需要持久化和恢复机制（runs.json + orphan recovery）
  • 高并发需求：超过3个Agent并行工作，需要8路并发+每Agent 5子的配置

具体操作：配置runTimeoutSeconds防止无限运行，利用resumeSessionId实现断点续传，通过orchestrator角色构建多层嵌套的Agent树。

决策矩阵

评估维度 Hermes OpenClaw
并发上限 3个（硬编码） 8个（可配置）
嵌套深度 2层（固定） 可配置
超时控制 无（仅迭代限制） 有（默认300秒）
动态干预 不支持 Steer机制
Token效率 高（上下文零膨胀） 中（结果注入父上下文）
持久化 不支持 runs.json支持
外部Agent 不支持 ACP协议支持
适用场景 批量并行执行 复杂编排、长流程

混合架构：取长补短的实践路径

核心问题：能否在一个系统中同时使用两种模式？如何设计？

两者并非互斥。最佳实践是根据任务特性选择合适模式：在OpenClaw的异步编排层处理复杂工作流和多Agent协作，当遇到需要隔离并行的子任务时，嵌入Hermes风格的delegate调用。

实际案例：main agent通过OpenClaw的sessions_spawn启动：

  • research agent（通过ACP调用Claude Code进行深度检索）
  • analysis agent（本地embedded处理）
  • writer agent（负责文档生成）

其中analysis agent内部使用Hermes的delegate_task并行处理3个互不相关的数据分析任务，利用其上下文零膨胀的优势；而research和writer agent之间通过OpenClaw的announce和steer机制协作，保持灵活性。

混合架构示意图

反思：这种”分层隔离”的设计让我想起了计算机体系结构中的缓存层级。L1缓存（Hermes）速度快但容量小，适合局部计算；L2缓存（OpenClaw）容量大但延迟高，适合全局协调。好的架构师懂得在不同层级使用合适的工具，而不是试图用一个方案解决所有问题。

Hermes的进化空间：基于对比的改进建议

核心问题：基于与OpenClaw的对比，Hermes有哪些明确的改进方向？

基于实际使用中的痛点，Hermes有几个高优先级的改进机会：

最高优先级：超时机制
为delegate_task增加timeout_seconds参数，防止子Agent无限运行。这是生产环境中最迫切的需求，可以参考OpenClaw的runTimeoutSeconds实现。

改进Gateway的interrupt逻辑
当用户发送”？”、”进度”等短消息时，应返回进度而非杀死所有Agent。这需要区分”查询意图”和”新指令意图”。

中等优先级改进

  • 引入Steer能力：允许父Agent向运行中的子Agent发送引导消息，这需要重新设计通信协议
  • 放开并发上限：将MAX_CONCURRENT_CHILDREN改为可配置参数（目前硬编码为3）
  • 支持持久化和恢复：保存子Agent状态以便被interrupt后恢复，参考runs.json的实现

长期演进方向
支持外部Agent（通过ACP启动Claude Code/Codex作为子Agent）将显著扩展Hermes的能力边界，使其从”内部工具”升级为”开放生态”。

实用摘要与操作清单

核心问题：如果只能记住三点，应该是什么？如何在明天就开始应用这些知识？

一页速览（One-page Summary）

Hermes Delegate = 同步阻塞 + 严格隔离 + Token高效

  • 像项目经理分包任务，等待所有结果返回
  • 子Agent无中间过程可见，仅返回summary
  • 适合：批量并行、简单子任务、Token敏感场景
  • 限制：无超时、硬编码3并发、无法动态干预

OpenClaw Subagent = 异步编排 + 动态干预 + 生命周期管理

  • 像交响乐团指挥，异步协调多个角色
  • 支持Steer机制调整运行中任务
  • 适合：复杂工作流、长流程、需外部Agent集成
  • 代价：Token开销高12%、架构复杂

落地操作清单

如果你选择Hermes：

  • [ ] 在config.yaml中设置合理的max_iterations（默认50，根据任务复杂度调整）
  • [ ] 确保所有子任务确实无关，避免需要协调的场景
  • [ ] 监控任务运行时间，准备外部超时控制机制（如Docker timeout）
  • [ ] 使用轻量级模型作为子Agent模型以节省成本

如果你选择OpenClaw：

  • [ ] 配置runTimeoutSeconds防止资源浪费（建议根据任务类型设置300-600秒）
  • [ ] 设计好Agent角色拓扑（main/orchestrator/leaf的层级关系）
  • [ ] 利用resumeSessionId实现容错，特别是长流程任务
  • [ ] 监控token消耗，避免频繁的steer操作导致上下文膨胀

如果你选择混合架构：

  • [ ] 在OpenClaw的orchestrator层做全局协调
  • [ ] 在leaf节点内部嵌入Hermes处理并行子任务
  • [ ] 明确区分”需要协调的任务”和”可隔离的任务”
  • [ ] 建立监控体系，分别跟踪两种模式的资源消耗

结语

Hermes和OpenClaw代表了多Agent协作的两种极端：一个追求极致的隔离和效率，一个追求最大的灵活性和控制力。理解它们的设计权衡，才能在实际项目中做出正确的架构选择。

未来的Agent系统，很可能是这两种哲学的融合——在需要隔离时强隔离，在需要协作时强协作，让架构服务于任务本质，而非相反。作为开发者，我们的任务不是选择”最好”的方案，而是选择”最合适”的方案，并在实践中不断演进。

常见问答（FAQ）

Q: Hermes的3个并发限制能否通过修改源码突破？
A: 理论上可以修改delegate_tool.py中的硬编码值，但不建议。这个限制是设计哲学的一部分，强行突破可能导致 unforeseen 的稳定性问题。如果需要更高并发，应迁移到OpenClaw架构。

Q: OpenClaw的Steer机制会中断子Agent的当前操作吗？
A: 不会立即中断，而是将引导消息加入子Agent的上下文，影响其下一轮决策。这种”软干预”比强制中断更优雅，但起效有延迟（取决于子Agent的迭代频率）。

Q: 在Hermes中，如果子Agent在50轮内无法完成任务怎么办？
A: 任务会正常结束并返回当前结果（通常是部分完成状态）。建议在任务设计时确保50轮足够，或者在应用层实现检查点机制，将大任务拆分为多个可序列化的子任务。

Q: OpenClaw的token开销增加12%是固定值吗？
A: 这是基于3个子任务的估算值。实际开销取决于announce频率和steer消息数量。在高频交互场景下，开销可能显著增加，需要进行实际测试。

Q: 两种模式能否在同一个Agent实例中混用？
A: 技术可行，但需谨慎设计。建议将OpenClaw作为外层编排（处理会话管理），在特定leaf Agent内部使用Hermes风格处理批量子任务，避免循环依赖。

Q: Hermes子Agent的工作目录是如何确定的？
A: 从父Agent解析出的工作目录路径会显式写入子Agent的System Prompt，遵循”绝不假设路径”的原则。确保父Agent在调用时提供明确的working_dir参数。

Q: 在Gateway产品中，用户发送”？”查询进度时，如何避免误杀所有子Agent？
A: 当前Hermes实现会interrupt所有子Agent，这是已知限制。短期解决方案是在应用层预处理用户输入，识别查询意图并直接返回缓存的进度信息，不传递到Agent层。

Q: 对于需要调用外部API的长耗时任务（如视频生成），哪种模式更合适？
A: OpenClaw更合适。其超时机制和异步推送能更好地处理不可控的外部API延迟，且支持orphan recovery应对外部服务的不稳定性。