OpenClaw 多 Agent 路由与多步流程怎么拆

OpenClaw 的多 Agent 基础能力是隔离 workspace、状态和会话，再用 bindings 路由入站消息；顺序多步流程需 Task Flow、Lobster、插件或外部编排。

内容更新 2026-07-26

先看结论

先用 bindings 把不同渠道、账号或发送者路由到隔离 Agent；只有真的需要顺序执行时，再选择可审计的 Task Flow、Lobster 或插件。

操作步骤

  1. 先判断需求是「入站路由」还是「顺序编排」：前者用多个隔离 Agent + bindings，后者另选编排机制
  2. 用 openclaw agents add <id> 为真正需要隔离的角色创建独立 workspace、state 和 session store；不要复用 agentDir
  3. 通过 onboarding 或配置 bindings，把具体 channel/account/sender 路由到目标 Agent，并用 openclaw agents list --bindings 验证
  4. 顺序、多步骤、需要持久状态的任务用受控插件驱动 Task Flow；单次确定性工具链可评估可选的 Lobster，并设置审批点
  5. 先跑最小场景，保留失败状态、日志和人工接管；确认隔离与路由正确后再扩大

命令与示例

openclaw agents add work
openclaw agents list --bindings
# bindings 解决“消息交给哪个 Agent”
# Task Flow / Lobster / 插件解决“多个步骤如何依次执行”
# 两者不要混为同一个拖拽式 pipeline 功能

小白先准备什么

  1. 列出需要隔离的身份、渠道、账号、workspace、模型凭据和数据边界。
  2. 先确认 bindings 的匹配规则，不让多个 Agent 共享同一个 agentDir。
  3. 如果是多步任务，再画出步骤、状态、审批点、重试与人工接管，不要先创建一堆 Agent。
  4. 准备正常、异常和越权样例，测试消息是否路由到正确 Agent、流程是否在敏感动作前停下。

验收标准

  • 每个 Agent 都有独立 workspace、状态目录和会话，bindings 能把测试消息送到正确目标。
  • 敏感凭据和客户数据不会因共享 agentDir、workspace 或插件存储而意外串到其他 Agent。
  • 多步流程能显示当前状态、失败步骤和审批点，并支持安全取消或恢复。
  • 日志能区分入站路由与流程步骤，低置信度、资料缺失或敏感动作会转人工。

可复制提示词

请把下面业务拆成多 Agent 流程。

业务目标：___
用户入口：___
可用资料：___
必须转人工的情况：___

请输出：
1. 需要几个 Agent，每个 Agent 的名字和职责。
2. 每个 Agent 的输入字段和输出字段。
3. 正常流程图。
4. 异常和转人工流程。
5. 最小可运行版本先做哪 3 步。

常见误区和不适合场景

  • 误区一：一开始就拆很多 Agent。先证明身份或数据确实需要隔离。
  • 误区二：bindings 就是顺序工作流。bindings 只决定入站消息交给谁。
  • 误区三：复用 agentDir。这样会造成凭据与会话状态冲突，官方明确不建议。
  • 误区四：多步自动化不需要审批。发送、删除、发布等副作用必须设置明确审批点。
  • 不适合：业务规则还没稳定、连人工流程都说不清的场景。

适合谁看

  • 单 Agent 越改越乱，想分工
  • 想让工作、个人或不同渠道使用相互隔离的 Agent
  • 确实需要一个可暂停、可恢复、可审计的多步任务

需要解决的问题

  • 一个 Agent 同时做太多事，回答质量下滑
  • 想加新规则就要改一大段 Prompt
  • 无法判断是分类错还是回答错

先理解这些

  • 多个身份共用同一 workspace、凭据和会话，容易混淆上下文与权限
  • bindings 负责入站路由，并不会自动形成接收→分类→处理→回复的顺序 pipeline
  • 多步流程若没有显式状态、审批点和失败恢复，很难审计或重试

遇到困难时

  • 只是回答风格或提示词问题就保留单 Agent，不要为“看起来高级”增加路由与状态复杂度
  • 需要 Dify / n8n 式可视化流程时，使用明确的外部编排器或插件，不要假设 OpenClaw 基础 Control UI 能直接拖拽完成