多智能体架构选型：同步 vs 异步

想象你在用多 Agent 系统跑一个长任务，3 个子 agent 正在并行干活。你想问一句"进度怎么样了"，随手发了个"?"。

在 Hermes 里，这个"?"会被当成中断信号——所有子 agent 被暴力 interrupt，之前的工作全白费。

在 OpenClaw 里，系统先判断你的意图：只是查进度？那就返回状态，子 agent 继续跑；想调整方向？用 Steer 给运行中的子 agent 发一条引导消息。

本课用两篇硬核长文讲透这个选题：

• @servasyy_ai（2026-04-11）：Hermes 的 delegate_task vs OpenClaw 的 subagent 系统，源码级深度对比；
• @idoubicc（2026-06-22）：基于一年 Agent 基础设施实战（500+ 用户托管），复盘 OpenClaw 做对了什么、错在哪，以及 FastClaw 的云原生重构。

以下来自 @servasyy_ai 对 Hermes 源码的剖析。Hermes 的实现集中在 978 行的 delegate_tool.py 中，支持两种工作模式：

• 单任务模式：给一个 goal 参数，启动单个子 agent 同步执行；
• 批量模式：接受最多 3 个任务的数组，通过 ThreadPoolExecutor 并行处理。

子 Agent 的构造与隔离

每次委派都会创建全新的 AIAgent 实例：独立的对话历史、独立的 Terminal session（每个 task_id 对应独立的工作目录和状态），以及专门构建的 System Prompt。配置遵循严格的继承规则：

• 模型可以继承父 agent，也可用 delegation.model 单独配置；
• 工具集通过交集计算——子不能获得父没有的工具；
• 凭证可以共享父的 credential pool，也可以独立配置；
• System Prompt 特别强调工作空间规则："Never assume a repository lives at /workspace/"，避免路径假设导致的错误。

工具剥夺：天然沙箱

为防止失控，Hermes 对子 agent 进行了严格的工具剥夺：

• 禁用 delegate_task 本身——防止递归委派；
• 移除 clarify——子 agent 无法与用户交互；
• 剥夺 memory 工具——保护共享记忆不被污染；
• 禁用 execute_code——避免子 agent 编写复杂脚本；
• 移除 send_message——防止跨平台消息发送。

生命周期与深度控制

• MAX_DEPTH = 2：父 agent（深度 0）可以 spawn 子 agent（深度 1），但子 agent 不能再 spawn 孙子（深度 2 会被拒绝）；
• 每个子 agent 默认 50 轮迭代上限（DEFAULT_MAX_ITERATIONS，可通过 config.yaml 配置）；

通信模式：纯单向的"有损压缩器"

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

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

凭证三级优先级

子 agent 的凭证解析遵循三级优先级：delegation.base_url → delegation.provider → 继承父 agent 的全部凭证。当子 agent 与父 agent 使用同一 provider 时，共享同一个 credential pool（cooldown 状态同步）；每个子 agent 获取凭证 lease 后，在 finally 块中自动释放。

同样来自 @servasyy_ai 的对比。OpenClaw 走的是完全另一条路：

三角色与并发

• main / orchestrator（可再 spawn）/ leaf（不可再 spawn）三角色；
• 默认全局 8 路并发、每 agent 最多 5 个活跃子 agent、嵌套深度可配。

异步事件驱动

spawn 后立即返回，父 agent 不用原地等待。子 agent 完成后，经 runSubagentAnnounceFlow() 以 user message 的形式把结果推送回父 agent。文档明示：不要轮询 sessions_list。

Steer：运行中遥控

父 agent 可以向运行中的子 agent 发送引导消息，触发其重新调整方向。限流保护：每 2 秒最多 1 次，消息最大 4000 字符。这正是 Hermes 最缺失的能力。

完整的生命周期管理

• runTimeoutSeconds 参数（默认 300 秒）提供时间维度的控制；
• runs.json 持久化运行记录，支持 orphan recovery（孤儿恢复）；
• resumeSessionId 允许恢复已有会话。

这些机制让 OpenClaw 适合长流程、多阶段的复杂任务。

灵活性的代价：多 12% token

announce 推送会把子 agent 的结果注入父 agent 的上下文，频繁的 steer 消息也会产生额外 token 开销。原文算了一笔账：同等 3 子任务场景，每次 announce 约 1K token，父 agent 上下文从 10K 增长到 13K，总消耗约 28K token——比 Hermes 多 12%。

深层逻辑：单体 vs 分布式

• Hermes 更像单体应用：简单、可预测；
• OpenClaw 更像分布式系统：灵活，但需要更复杂的状态管理。

从安全视角看：Hermes 的强隔离形成天然沙箱，适合安全敏感场景；OpenClaw 的子 agent 保留更多能力，但也意味着更大的攻击面。

把两篇对比的核心差异收进一张表（以下均来自 @servasyy_ai 原文）：

选型建议（原文结论）

• 选 Hermes：3 个互不相关并行任务、怕污染主上下文的场景；
• 选 OpenClaw：需要在子 agent 运行中调整方向、需要超时控制防止无限运行、需要调用外部编码 agent（如 Claude Code、Codex）做子 agent、构建多层嵌套 agent 树。

Hermes 的改进方向（原文列出）

• 加 timeout_seconds 参数（最高优先级）；
• Gateway interrupt 逻辑改"进度查询"；
• 引入 Steer 能力；
• 并发上限可配置；
• 支持持久化和恢复；
• ACP 支持外部 Agent。

以下来自 @idoubicc。基于一年 Agent 基础设施实战（500+ 用户托管），他复盘了 OpenClaw 做对的 6 点、8 大架构缺陷，以及重构出的 FastClaw。

FastClaw：轻量、快速、云原生

核心架构决策

• 存算分离：计算层 Gateway 无状态水平扩展；存储层 DB + S3 是唯一真相源；
• 基于 Scope 的配置继承；
• LLM / Tool / Sandbox 三层 Fallback对上层透明。

四个定位

• Assistant：个人助理；
• Factory：在 cloud.fastclaw.ai 上创建、分享 Agent；
• Runtime：weclaw.im 一小时上线，把 FastClaw 当 Backend 用；
• Platform：企业私有化 Agent 协作平台。

原文"七、多 Agent 框架设计经验总结"一节给出 5 条经验（以下逐条引用原文）。点下面单步走一遍：

原文收束金句：好的架构不是设计出来的，是迭代出来的。在迭代之前想清楚存算分离、多租户隔离、Fallback 容错这三件事，你会省下很多时间。