TOPIC / RESOURCE

OpenClaw 多 Agent 架构模式:流水线、并行和层级怎么选

OpenClaw 的多 Agent 架构不是简单多开几个机器人。这页帮你先分清流水线、并行和层级三种架构模式各自的适用场景和局限性,再决定工作区如何划分、bindings 怎么配置、共享记忆机制和失败回退策略该怎么设计,避免架构越做越复杂混乱。

适合谁

  • 已经理解多 Agent 不是多开几个机器人那么简单
  • 想先分清流水线、并行和层级三种架构模式
  • 准备在路由、共享记忆和失败处理上做更稳的设计

先分模式,再分角色

多 Agent 的第一步不是起名字,也不是先开一堆机器人,而是先决定:你要的是流水线、并行,还是层级协作。

单个 Agent 的局限通常出现在:

  • 上下文太长
  • 任务类型太杂
  • 既要执行又要审校
  • 需要并行时只能串行跑

模式一:流水线(Pipeline)

适合:

  • 内容生产
  • 报告生成
  • 明显有前后顺序的任务

典型形态:

输入
-> 研究 Agent
-> 整理 Agent
-> 写作 Agent
-> 审校 Agent
-> 输出

优点:

  • 结构清楚
  • 便于排障
  • 很适合做“最低可交付版本”

代价:

  • 每个阶段都依赖上一步
  • 任何一环慢,整条链都会慢

模式二:并行(Parallel)

适合:

  • 市场调研
  • 多维分析
  • 同一主题要从几个角度同时展开

典型形态:

输入
-> 分发给 A / B / C
-> 并行完成不同维度
-> 汇总 Agent 回收结果
-> 输出

优点:

  • 速度快
  • 很适合信息型任务

代价:

  • 汇总逻辑更重要
  • 如果每个 Agent 都拿完整上下文,成本会迅速膨胀

模式三:层级(Hierarchical)

适合:

  • 复杂项目管理
  • 需要主 Agent 分发任务
  • 需要不同角色长期协作

典型形态:

主 Agent
-> researcher
-> writer
-> reviewer
-> ops

优点:

  • 角色边界清楚
  • 容易扩容

代价:

  • 路由和状态目录设计更容易出错
  • 如果协调者太强,容易退化成“一切都回主 Agent”

工作区、状态目录和路由,三样别混

真正需要分清的不是“几个机器人”,而是这三样:

  1. workspace
  2. agentDir
  3. bindings

你至少应该做到:

  • 每个 Agent 有自己的工作区
  • 每个 Agent 有独立状态目录
  • 路由规则能解释清楚为什么消息会到它那里

一份够用的多 Agent 结构骨架

{
  "agents": {
    "list": [
      {
        "id": "researcher",
        "workspace": "~/.openclaw/workspace-researcher",
        "agentDir": "~/.openclaw/agents/researcher/agent"
      },
      {
        "id": "writer",
        "workspace": "~/.openclaw/workspace-writer",
        "agentDir": "~/.openclaw/agents/writer/agent"
      },
      {
        "id": "reviewer",
        "workspace": "~/.openclaw/workspace-reviewer",
        "agentDir": "~/.openclaw/agents/reviewer/agent"
      }
    ]
  }
}

这不是你版本里唯一正确的最终字段,而是提醒你:
工作区和状态目录必须独立。

最常见的 3 个设计错误

错误 1:每个 Agent 都拿完整材料

结果通常是:

  • 成本飙升
  • 上下文爆炸
  • 角色差异变弱

更稳的做法:

传摘要 + 传 memory id
不要传完整 5 万字材料
需要时再让下游 Agent 拉全文

错误 2:没定义失败回退

并不是每个 Agent 都必须成功。更实际的设计是:

  • 哪些失败可跳过
  • 哪些失败必须中断
  • 失败后是降级、重试还是切人工

错误 3:先上多 Agent,再补单 Agent 验证

如果你还没证明单 Agent 已经能稳定完成最小任务,多 Agent 通常只会把问题放大。

一个够用的架构选择清单

多 Agent 架构判断 checklist

1. 任务是否天然有前后顺序
2. 是否需要并行处理多个维度
3. 是否真的存在长期角色分工
4. 单 Agent 是否已经跑稳
5. 是否知道每个 Agent 失败后怎么处理

什么时候该直接看具体项目页

如果你已经确定自己不是来学概念,而是来搭系统,下一步更应该去看:

官方文档 / 延伸阅读

相关链接

FAQ

本页常见问题

主要不是“更多人格”,而是更清楚的分工、并行效率、相互校验,以及把复杂任务拆成可维护的结构。

当单 Agent 还没稳定、输入输出还说不清、日志和路由还看不懂时,先别上。那时多 Agent 只会放大混乱。