研究 OpenClaw 多 Agent 编排，不能把它简单理解成“多个 Agent 一起聊天”或者“做一个 Agent 群聊系统”。

更准确的判断是：

OpenClaw 当前更像是一个多 Agent 原语平台，而不是已经完整产品化的 Agent Team 系统。

它已经提供了多 Agent 的关键底层能力：Agent 隔离、workspace 隔离、agentDir、session history、channel bindings、subagent spawn、ACP 外部 harness、Task、Task Flow、Workboard、per-agent sandbox/tool policy、Delegate identity 等。

但它还没有把“多个 Agent 如何作为一个团队被声明、创建、管理、复用”完全产品化。GitHub 上的 Agent Teams RFC 提到，OpenClaw 已有 agents.list、bindings、sessions_spawn、sessions_send 等原语，但 coordinated team 仍然需要手动创建多个 workspace、配置 binding/auth/channel、手写通信模式，而且缺少 shared state。该 RFC 当前状态是 “Closed as not planned”。

所以，OpenClaw 多 Agent 的正确落点不是先做 Swarm，而是：

以 Agent 作为能力单元，以 Session 作为上下文隔离单元，以 Task 作为生命周期单元，以 Task Flow 作为长期流程状态机，以 Coordinator / Workboard / Governance 作为生产控制面。

这才是 OpenClaw 多 Agent 编排真正值得研究和产品化的方向。

OpenClaw 多 Agent 不应该从 Swarm 开始，而应该构建 Multi-Agent Task OS。
一张图看清楚：OpenClaw 的产品化关键不是“能创建多个 Agent”，而是能把多个 Agent 纳入任务、状态、权限、审查和交付的统一控制面。

一、OpenClaw 多 Agent 的底层能力拆解

OpenClaw 的多 Agent 能力可以拆成六层。

1. Agent 隔离层：每个 Agent 是一个独立工作主体

OpenClaw 中的 Agent 不是简单的 prompt alias，而是一个完整作用域。一个 Agent 可以拥有自己的 workspace、state directory、auth profiles、model registry、session store 和 persona rules。

这意味着 OpenClaw 的多 Agent 首先解决的是：

  • 身份隔离
  • 权限隔离
  • workspace 隔离
  • 上下文隔离
  • session history 隔离
  • 工具策略隔离

这对生产环境非常重要。因为一旦 Agent 能读邮件、改文件、发消息、跑 shell、调用浏览器，最危险的不是“回答错了”，而是不同 Agent 之间权限、身份、上下文和工具边界混在一起。

因此，多 Agent 的第一原则不是协作，而是隔离。

2. Routing 层：按 channel / account / peer 把请求路由到正确 Agent

OpenClaw 的 Multi-agent Routing 允许一个 Gateway 承载多个 Agent，并通过 bindings 把不同入口路由给不同 Agent。比如 WhatsApp 家庭群路由给 family agent，Slack 工程频道路由给 coding agent，Telegram 个人号路由给 personal agent。

这类模式解决的不是复杂协作，而是：

  • 多入口接入
  • 多身份隔离
  • 多客户隔离
  • 多业务线隔离
  • 多 channel 分流

这是 OpenClaw 多 Agent 最基础、也是最应该先落地的能力。

如果产品一开始就做“Agent 团队协作”，但连入口路由、session 隔离、权限边界、agentDir 隔离都没有做好，后面一定会失控。

3. Session / Subagent 层：把长任务从主会话中剥离出去

OpenClaw 的 sessions_spawn 可以创建隔离的 background session。它默认创建 isolated session，用于 background task，并且是 non-blocking，会立即返回 runId 和 childSessionKey。子 Agent 完成后通过 announce 机制把结果回传。

这就是 OpenClaw 原生多 Agent 执行能力的核心。

它解决的问题是：

  • 主会话不被长任务阻塞
  • 子任务拥有独立上下文
  • 子任务可以并行执行
  • 子任务可以在完成后回传结果
  • 父 Agent 可以统一综合、审查、交付

所以，OpenClaw 多 Agent 编排里最重要的生产原则是：

长任务不要塞进主会话。每个长任务应该新建独立 Task Session。

OpenClaw 多 Agent 的六层底层能力：Agent 隔离、Routing、Session、Orchestrator、Task Flow 和 Governance。
多 Agent 不是从协作开始，而是从隔离、路由、会话、任务生命周期和治理边界开始。

4. Orchestrator 层：允许有限深度的层级编排，但要防止失控

OpenClaw 支持嵌套 sub-agent。默认情况下 sub-agent 不能再 spawn 子 Agent；如果设置 maxSpawnDepth: 2，可以形成 main → orchestrator sub-agent → worker sub-sub-agents 的两层结构。

这说明 OpenClaw 的多 Agent 设计倾向是：

有限层级编排，而不是无限递归 Swarm。

这个设计非常合理。因为 Agent 一旦能递归创建 Agent，就容易出现：

  • fan-out 失控
  • token 成本爆炸
  • 同一任务重复执行
  • 子 Agent 互相等待
  • 状态不可追踪
  • 权限边界失控
  • 最终结果无法归因

所以多 Agent 编排必须默认有限、可解释、可回收，而不是默认自治扩散。

5. Task / Task Flow 层：生产级编排不能只靠 Agent 对话，要靠任务状态机

OpenClaw 的 Background Tasks 是 detached work 的 activity ledger。Task 本身不是 scheduler，而是记录 detached work 发生了什么、何时发生、是否成功。

Task 生命周期包括：

queued → running → succeeded / failed / timed_out / cancelled / lost

这对生产级多 Agent 非常关键。因为多 Agent 系统一旦进入真实业务，就必须回答几个问题：

  • 当前有多少任务在跑？
  • 哪些任务失败了？
  • 哪些任务超时了？
  • 哪些任务丢失了？
  • 哪个 Agent 正在处理哪个任务？
  • 哪个任务可以重试？
  • 哪个任务应该取消？
  • 哪个结果已经交付？
  • 哪个结果需要人工 review？

如果没有 Task Ledger，多 Agent 系统就是黑箱。

而 Task Flow 是更上层的 durable flow orchestration，用于管理多步骤流程、分支流程、状态持久化、revision tracking，并能跨 gateway restart 保留进度。

因此：

  • 单个后台任务，用 Task。
  • 多步骤 pipeline，用 Task Flow。
  • 需要跨重启恢复，用 Task Flow。
  • 需要统一追踪外部任务，用 mirrored Task Flow。
  • 需要端到端自动推进，用 managed Task Flow。

这说明 OpenClaw 的生产级多 Agent，不应该停留在“Agent 互相发消息”，而应该升级成：

Agent 执行任务，Task 记录生命周期，Task Flow 管理流程推进。

长任务应该进入 Task Session，并由 Long Task Manager 管理 queued、running、waiting、review、delivered 等状态。
Task Session 是从聊天产品升级为任务系统的关键：长任务必须可排队、可暂停、可恢复、可重试、可审查、可交付。

6. Governance 层：多 Agent 的核心不是智能，而是边界

OpenClaw 支持 per-agent sandbox 和 tool policy。在 multi-agent setup 中，每个 Agent 可以覆盖全局 sandbox 和 tool policy，并且 auth 是按 agent scoped 的。

这意味着生产级 OpenClaw 多 Agent 必须具备：

  • 每个 Agent 最小权限
  • 每个 lane 最小工具面
  • 不同 Agent 不复用 agentDir
  • 子 Agent 默认不给 session tools
  • ACP harness 默认不暴露 OpenClaw plugin tools
  • 高风险工具必须分层授权
  • 所有 detached work 必须进入 task ledger
  • 所有交付必须可追踪

这也是为什么 OpenClaw 的 Delegate Architecture 很有价值。Delegate 不是简单的 bot，而是一个有独立身份、独立账号、明确授权边界的组织代理。

这代表多 Agent 从“个人工具”进入“组织代理”阶段。

多 Agent 的治理边界：权限、上下文、工具、成本、审计与组织代理身份。
Agent 越能执行真实动作，就越需要 sandbox、tool policy、audit log、cost budget 和 human approval。

二、OpenClaw 多 Agent 编排的 8 种成熟模式

下面不是简单罗列，而是按产品成熟度排序。

OpenClaw 多 Agent 编排的 8 种成熟模式：Virtual Board、Routing、Delegation、Orchestrator、Specialist Lanes、Task Session、ACP Harness、Workboard Delegate。
一张图看清楚 8 种成熟模式：不要一上来做 Swarm，而要按成熟度逐层引入隔离、委派、泳道、长任务、外部 harness 和组织控制面。

模式 1：Single Agent + Virtual Board

这是最轻量的多 Agent 模式。

它不是 OpenClaw 原生多 Agent，而是在一个 Agent 内部模拟多个角色，例如：

  • 产品架构师
  • 技术架构师
  • 商业化分析师
  • 反方审查员
  • 传播编辑
  • 最终裁判

适合方案评审、文章分析、产品判断、架构讨论。

优点是成本低、速度快、上下文集中；缺点是角色不是真隔离，也没有独立工具和权限。

建议：默认优先使用这个模式。

很多任务并不需要真的 spawn subagent。尤其是内容分析、方案讨论、商业判断、产品 Review，用 Virtual Board 就够了。

模式 2：Multi-Agent Routing

这是 OpenClaw 官方最基础的多 Agent 能力。

多个 Agent 独立存在，每个 Agent 有自己的 workspace、agentDir、auth profile 和 session store；入口通过 bindings 分发。

适合：

  • personal agent
  • work agent
  • family agent
  • coding agent
  • research agent
  • customer A agent
  • customer B agent

这个模式的本质不是协作，而是隔离和分流。

建议：产品化第一阶段优先做这个。

因为它最稳定、最可解释、最容易运维，也最符合企业客户对权限和数据隔离的要求。

模式 3：Main Agent → Subagent Delegation

这是 OpenClaw 真正进入多 Agent 执行的起点。

主 Agent 接收任务，拆解目标，然后通过 sessions_spawn 创建一个或多个 isolated sub-agent。子 Agent 完成后 announce 回主 Agent，由主 Agent 统一综合。

适合：

  • 并行检索
  • 代码分析
  • 测试执行
  • 多文档整理
  • 长任务拆解
  • 慢工具调用
  • 外部 API 查询
  • 多角色审查

推荐结构：

User
 ↓
Main Agent / Coordinator
 ├─ Research Subagent
 ├─ Code Subagent
 ├─ Review Subagent
 └─ Test Subagent
 ↓
Main Agent 综合、审查、交付

核心原则：

  • 子 Agent 不直接面对用户
  • 子 Agent 只做局部任务
  • 子 Agent 结果必须回到 Main Agent
  • Main Agent 负责最终判断
  • 不允许子 Agent 无限递归 spawn
  • 所有子任务进入 Task Ledger

建议：这是复杂任务的主力模式。

模式 4：Orchestrator → Worker 分层模式

当任务更复杂时，可以启用有限深度的嵌套 sub-agent。

OpenClaw 支持在 maxSpawnDepth >= 2 时形成 main → orchestrator → worker 的结构。depth 1 orchestrator 可以 spawn 子 worker，depth 2 worker 不能继续 spawn。

适合：

  • 大型代码改造
  • 多阶段研究报告
  • 多文件重构
  • 数据收集 + 分析 + 总结
  • 多 Agent pipeline

推荐结构：

Main Agent
 ↓
Orchestrator Subagent
 ├─ Worker A
 ├─ Worker B
 └─ Worker C
 ↓
Orchestrator 汇总
 ↓
Main Agent 验收

这个模式的重点不是“更智能”，而是让主 Agent 不必管理所有 worker 的细节。

但它也有明显风险：

  • 编排链路更长
  • 成本更高
  • 失败点更多
  • 子结果更难审计
  • 需要更强的 task / run / session 可观测

建议：只在任务足够复杂、且子任务边界清楚时使用。

模式 5：Parallel Specialist Lanes

这是 OpenClaw 生产化最值得学习的模式之一。

parallel specialist lanes 的关键不是“更多 Agent”，而是把 parallelism 视为 scarce-resource design problem。

真实瓶颈包括：

  • 谁拥有任务？
  • 哪个 session 能被写？
  • 哪个模型额度被占用？
  • 哪个工具被阻塞？
  • 哪个上下文过长？
  • 哪些 Agent 在重复做同一件事？

Parallel Specialist Lanes 的正确做法是先定义 lane contract：

Research Lane：负责资料收集和事实核查
Coding Lane：负责代码修改和测试
Review Lane：负责审查、验收、风险提示
Ops Lane：负责部署、监控、故障排查
Delivery Lane：负责最终整理和交付

每个 lane 都要定义：

  • Owns：负责什么
  • Does not own：不负责什么
  • Chat budget：哪些直接答，哪些进入后台任务
  • Handoff rule：什么时候移交
  • Tool posture：允许使用哪些工具

没有 lane contract 的 coordinator，只是在协调混乱。

建议：这是 OpenClaw 多 Agent 产品化的核心范式。

真正要做生产级多 Agent，应该从 Specialist Lanes 开始，而不是从 Swarm 开始。

OpenClaw 专家泳道：Research、Coding、Review、Ops、Delivery，每条泳道都要有 lane contract。
并行不是多开 Agent，而是稀缺资源设计。每条泳道都必须定义 Owns、Does not own、Chat budget、Handoff rule 和 Tool posture。

模式 6：Task Session + Long Task Manager

这是我认为最适合产品化的一层。

每个长任务都应该创建独立 Task Session，而不是污染主聊天 session。

推荐结构：

User
 ↓
Main Agent
 ↓
Create New Task
 ↓
Task Session
 ↓
Long Task Manager
 ├─ queued
 ├─ running
 ├─ paused
 ├─ waiting_for_user
 ├─ failed
 ├─ retrying
 ├─ review
 ├─ delivered
 └─ archived

OpenClaw 的 Background Tasks 已经提供了 detached work ledger，Task Flow 又提供多步骤 durable orchestration。

在产品层，应该进一步抽象出 Long Task Manager：

  • 任务创建
  • 任务排队
  • Agent 分配
  • Session 创建
  • 子任务拆解
  • 并发控制
  • 暂停 / 恢复
  • 取消 / 重试
  • 失败归因
  • 成本统计
  • 产物归档
  • 人工 Review
  • 最终交付

这个模式是从“聊天产品”升级为“任务操作系统”的关键。

建议：如果你要做 OpenClaw 多 Agent 产品，Long Task Manager 是核心。

模式 7：ACP External Harness 模式

OpenClaw 的 ACP agents 可以把外部 coding harness 接入，例如 Claude Code、Cursor、Copilot、Gemini CLI、Codex ACP、OpenCode 等。

这意味着 OpenClaw 可以作为上层协调器，把外部强执行器纳入编排系统。

适合：

  • Claude Code 执行复杂代码任务
  • Codex 处理仓库级改造
  • Gemini CLI 做特定工具链任务
  • Cursor agent 做编辑器相关任务
  • OpenCode / Droid 等外部 harness 作为 worker

推荐结构：

OpenClaw Coordinator
 ├─ Native Research Subagent
 ├─ Native Review Subagent
 └─ ACP Claude Code / Codex / Gemini CLI

但 ACP 模式的安全边界要更谨慎。ACP harness 拥有自己的 provider login、model catalog、filesystem behavior 和 native tools；OpenClaw 负责 routing、background task state、delivery、bindings 和 policy。

ACP 不应该默认开放给所有任务，而应该作为高能力、高风险 worker。

模式 8：Workboard / Delegate / Organization Agent 模式

这是 OpenClaw 多 Agent 进入组织级应用的形态。

Workboard 插件提供 Kanban-style board，用来收集 agent-sized work cards、分配给 agents，并追踪 linked background task、run 和 session。

这很重要，因为多 Agent 系统一旦进入团队协作，就不能只靠聊天记录管理任务。需要一个“任务看板 + 执行状态 + 产物 + 审查”的控制面。

Workboard 适合：

  • 把用户需求转为 card
  • 给 card 分配 agent
  • card linked session
  • card linked task
  • card 进入 running / review / blocked / done
  • 失败后重新启动 fresh session
  • 人工验收后归档

Delegate Architecture 则把 Agent 从工具变成组织代理。Delegate 有自己的 identity、email、calendar，可以代表一个或多个 principal 工作，但不冒充人类。

这适合企业场景：

  • CEO delegate
  • SRE delegate
  • Sales delegate
  • Research delegate
  • Project delegate
  • Customer success delegate

建议：企业级 OpenClaw 多 Agent，最终会走向 Workboard + Delegate + Task Flow。

三、产品化架构建议：不要做 Swarm，要做 Multi-Agent Task OS

如果要基于 OpenClaw 构建生产级多 Agent 编排系统，我建议架构分成七层。

L1. Channel Router
负责多入口、多账号、多客户、多场景路由

L2. Agent Registry
管理 agentId、workspace、agentDir、auth profile、tool policy、sandbox

L3. Session Manager
管理主会话、Task Session、Subagent Session、Thread-bound Session

L4. Task Manager
管理 queued / running / failed / cancelled / timed_out / review / delivered

L5. Orchestration Engine
负责 task decomposition、lane routing、subagent spawn、ACP spawn、retry policy

L6. Workboard / Control UI
把任务、session、run、artifact、review 状态可视化

L7. Governance Layer
负责权限、成本、审计、工具面、模型额度、token budget、人工审批

这个架构的核心不是“让 Agent 更自由”，而是：

让 Agent 的自由被任务、状态、权限、审计和产物边界包住。

四、推荐落地路线

第一阶段：Router + Agent 隔离

先解决：

  • 多 Agent 配置
  • bindings 路由
  • workspace 隔离
  • agentDir 隔离
  • auth profile 隔离
  • per-agent tool policy
  • per-agent sandbox

目标是让不同入口、不同客户、不同业务线不会互相污染。

第二阶段：Task Session 化

所有超过 3 分钟、涉及多个工具、多个步骤、多个文件、多个外部系统的任务，都不要放在主会话里跑。

统一进入：

New Task → Task Session → Task Ledger → Review → Delivery

这一步是从“聊天机器人”升级为“任务系统”的关键。

第三阶段：Subagent Delegation

在 Task Session 内部，Main Agent 才按需 spawn subagent。

不要在所有任务里默认多 Agent。只有满足以下条件才 spawn：

  • 可并行
  • 可拆解
  • 有明确子交付物
  • 子任务不强依赖主上下文
  • 子结果可以被验证
  • 成本收益明显

第四阶段：Specialist Lanes

当任务类型开始稳定后，建立专家泳道：

  • Research Lane
  • Coding Lane
  • Review Lane
  • Ops Lane
  • Delivery Lane

每个 lane 配 lane contract、tool policy、成本预算、并发上限、handoff rule。

第五阶段：Task Flow

当任务开始多步骤、可恢复、可重试、跨 gateway restart 时，引入 Task Flow。

典型流程：

collect → analyze → execute → review → deliver → archive

Task Flow 负责流程推进，Agent 只负责执行具体步骤。

第六阶段：ACP 外部强执行器

接入 Claude Code、Codex、Gemini CLI、Cursor Agent 等外部 harness。

OpenClaw 做协调和状态管理，ACP harness 做强执行。

这一步适合代码、仓库、CLI、自动化、部署类任务。

第七阶段：Workboard + Delegate 企业化

最终形态是：

User / Team
 ↓
Workboard
 ↓
Task Flow
 ↓
Coordinator
 ├─ Native Subagents
 ├─ Specialist Lanes
 ├─ ACP Harness
 └─ Delegate Agents
 ↓
Review / Audit / Delivery

这时 OpenClaw 就不只是个人 AI 助理，而是一个组织级 Agent Operating System。

OpenClaw 多 Agent 产品化路线：P0 Agent 隔离，P1 Task Session，P2 Task Manager，P3 Subagent Delegation，P4 Specialist Lanes，P5 Task Flow，P6 ACP，P7 Workboard Delegate。
落地路线：先做隔离与生命周期，再做复杂编排；先能追踪、恢复、审查，再谈自治和规模化。

五、关键风险与反方审查

OpenClaw 多 Agent 编排最容易犯五个错误。

1. 过早 Swarm 化

多个 Agent 互相讨论，看起来很智能，但生产价值不一定高。没有 task ownership、lane contract 和 task ledger 的 swarm，本质上是高成本混乱。

2. 忽视权限边界

OpenClaw Agent 可以读文件、发消息、调浏览器、执行命令。多 Agent 场景下，一旦权限没有分层，风险会放大。

3. 忽视成本治理

GitHub RFC 中也有人指出，当前 multi-agent tasks 可能消耗 4–6 倍 token，而不是理想状态下的 1.5–2 倍，原因包括重复 system prompt、任务描述传播、结果摘要开销等。

所以多 Agent 必须有 token budget、spawn budget、maxConcurrent、maxChildrenPerAgent 和 task-level cost accounting。

4. 缺少共享状态机制

当前 OpenClaw 多 Agent 更偏 isolated + hierarchical delegation。GitHub RFC 指出，这种架构会带来 information silos、ambiguous task boundaries、single coordination mode 等问题。

所以未来更成熟的方向会是：

  • shared blackboard
  • capability profiling
  • layered memory
  • cost governance
  • performance-based routing

但这些不应一开始就做复杂，而应在 Task / Workboard / Lane 稳定后再加。

5. 把 Agent 当人，而不是当执行单元

Agent 可以模拟人，但生产系统里不应该完全按“人类团队聊天”设计。更稳的抽象是：

  • Agent = 能力单元
  • Session = 上下文容器
  • Task = 生命周期记录
  • Task Flow = 流程状态机
  • Workboard = 控制面
  • Delegate = 组织身份
  • Governance = 安全边界

六、最终结论

OpenClaw 多 Agent 编排真正有价值的方向，不是做一个“多 Agent 群聊”，而是构建一个 Multi-Agent Task OS。

它的核心范式是：

请求进入
 ↓
路由到正确 Agent
 ↓
判断是否创建 Task Session
 ↓
长任务进入 Task Manager
 ↓
按 lane / capability 拆解
 ↓
spawn native subagent 或 ACP external harness
 ↓
Task Ledger 追踪状态
 ↓
Task Flow 管理多步骤推进
 ↓
Workboard 承载人工 review 和产物沉淀
 ↓
最终交付

一句话总结：

OpenClaw 的多 Agent 编排，不应该从 Swarm 开始，而应该从 Routing、Session 隔离、Task 生命周期、Specialist Lanes 和 Task Flow 开始。Agent 不是核心，任务状态和治理边界才是核心。

如果要做产品，我建议优先级是：

P0：Agent 隔离 + bindings 路由
P1：每个长任务独立 Task Session
P2：Task Manager + 状态可观测
P3：Main Agent → Subagent Delegation
P4：Specialist Lanes + lane contract
P5：Task Flow 长流程状态机
P6：ACP 接 Claude Code / Codex / Gemini CLI
P7：Workboard + Delegate 企业化

最终判断：

OpenClaw 已经具备构建生产级多 Agent 系统的底层原语，但真正的产品化关键，不在“能不能创建多个 Agent”，而在“能不能把多个 Agent 纳入任务、权限、成本、状态、审查和交付的统一控制面”。