OpenClaw 101｜10｜Multi-Agent and Delegation

多 Agent 不是简单并发。OpenClaw 用 named agents、session isolation、tool policy 和 specialist lanes 管理 delegated work。

OpenClaw 101 是一组面向 Agent Engineering 的系统拆解文章。它不把 OpenClaw 当成单一聊天产品，而是把它当作一个长期运行的 Personal Agent OS 来观察。

这一篇讲 Multi-Agent and Delegation。当一个 Agent 开始分派任务时，真正的问题不是“能不能并行”，而是隔离、预算、权限、交接和可观察性。

读完本文，你应该能回答

delegation 解决的是并行、隔离还是专业化？
子任务需要继承哪些上下文，哪些不该继承？
多 agent 的结果如何回到主 session？
什么时候不应该 delegate？

本篇在系列中的位置

任务分解篇，说明什么时候需要多个 agent / worker，而不是让主 loop 独自承担所有工作。OpenClaw 101 的主线是：先看控制面，再看执行面和状态边界，再进入上下文、能力系统、长期记忆、自动化、真实设备、扩展和 QA。下一篇进入 Automation，看没有用户在线时任务如何被触发和交付。

贯穿案例

后文会反复使用同一个任务来落地抽象机制：用户在手机上对 OpenClaw 说：“帮我看一下这个 repo 的测试为什么失败；如果需要跑命令就先做，修好后在聊天里提醒我。”

在本篇中，重点观察这个任务在 Multi-Agent and Delegation 这一层会遇到的边界：谁接收它，谁拥有状态，谁能触发工具，谁记录结果，以及失败后从哪里恢复。

Delegation 拓扑表

环节	读者应该抓住的问题
Fan-out	多个独立调查或代码区域可并行处理
Isolation	子 agent 不污染主上下文和主工具状态
Specialization	不同 worker 处理检索、实现、审查、验证
Merge	主 agent 汇总结果并承担最终判断
Guardrail	用户交互、外部副作用和持久状态要谨慎委托

核心判断

Delegation 是受约束的工作分派：子 Agent 应该有自己的 workspace、session、tool policy 和回传格式。

如果只看表面，很多 Agent 框架都像是“模型 + 工具 + UI”。但真正决定系统稳定性的，是这些边界如何被拆开：谁拥有状态，谁能触发副作用，谁负责恢复，谁暴露观察面，谁承担长期维护成本。

在 OpenClaw 里，Multi-Agent and Delegation 不是一个孤立模块，而是 Gateway、Session、Context、Tools、Plugins、Memory 之间的连接点。理解这个连接点，比记住某个命令或配置项更重要。

运行路径

一条真实消息进入系统后，大致会经过这些步骤：

主 Agent 判断任务可以被拆分。
为 specialist lane 选择 agent identity、workspace、tool posture。
子 Agent 在隔离 session 中执行，不污染主对话。
必要时限制工具、模型、预算和超时。
子 Agent 返回 summary、artifact path、URL 或结构化结果。
主 Agent 验证关键副作用，再把结果合并回父 session。

这些步骤看起来很多，但它们解决的是同一个问题：让 Agent 的行为从“模型临场发挥”变成“系统可控制、可观察、可恢复的运行过程”。

可迁移伪实现：Multi-Agent and Delegation

下面的伪代码是机制抽象，不对应 OpenClaw 的真实 API 或文件结构。

async function delegate(task: Task) {
  const lane = chooseSpecialistLane(task)
  const child = await startAgentRun({
    agent: lane.agentId,
    workspace: lane.workspace,
    tools: lane.allowedTools,
    prompt: task.brief,
  })
  const result = await waitForLifecycle(child.runId)
  return verifyAndMerge(result)
}

这段伪代码的重点不是函数名，而是边界：输入先被标准化，状态通过明确的 store 或 lane 管理，副作用通过 runtime 或 policy 执行，结果再回到 transcript、event stream 或 delivery target。

设计取舍

并行能提高吞吐，但会增加状态和成本管理。
子 Agent 自报成功不能直接相信；外部副作用要可验证。
多 Agent 的价值在专家分工，不在制造一堆聊天人格。

这些取舍解释了 OpenClaw 为什么不像一个最小 demo。最小 demo 追求路径短，长期系统追求边界清晰。路径短会让第一个 demo 很快跑起来；边界清晰才会让系统在多渠道、长会话、多人入口、插件扩展和自动化场景下不崩。

评估清单

评估任何 Agent 框架的 Multi-Agent and Delegation 设计，可以看这几个问题：

这个层级是否有明确 owner，还是散落在多个客户端或插件里？
它是否把状态、权限、运行时副作用和展示逻辑分开？
它是否能被观测、被调试、被回放？
它失败时是否有恢复路径，而不是只给用户一个模型错误？
它是否避免把 provider/channel/tool 的私有细节写死进 core？

如果这些问题没有答案，系统一旦从单用户 demo 走向真实使用，很快就会在上下文污染、重复副作用、权限失控、长任务丢失和调试困难中付出代价。

下一篇继续拆 Automation。OpenClaw 101 的主线会继续沿着 Personal Agent OS 的边界往下走：从运行时，到状态，到能力系统，再到安全、扩展和 QA。

References

Multi-agent routing
Parallel specialist lanes
Session tools
Agent workspace