在上一篇文章从 OpenClaw 再谈 Prompt Engineering中，我们详细拆解了大模型是如何通过系统动态注入的 System Prompt 来感知上下文边界和工具能力的。

然而，大模型的 Context Window 长度和单线程处理能力都有其物理上限。当面对复杂的组合型任务时，单点的大模型必然会出现推理能力衰减或上下文过载。

这就引出了 Agent 框架设计的另一个核心命题：
系统如何管理多个 Agent 的并发执行、状态隔离，以及它们之间的通信机制？

OpenClaw 的多 Agent 架构并没有依赖复杂的分布式协议，而是通过 Session 沙盒隔离、Tool 驱动的 Agent 调度、Gateway 异步路由以及 Event Bus 生命周期回调，构建了一套极简但高效的 Agent Runtime。

这种设计本质上把 LLM 的不可预测行为限制在一个可控的系统边界之内。

1. 结构基础：Agent 的静态定义与 Session 的动态隔离

在 OpenClaw 中，Agent 不是运行实例，而是一份静态的行为模板；真正运行的，是绑定在 Session 上的上下文沙盒。

在理解 OpenClaw 的多 Agent 协作之前，需要先理清两个核心概念在代码架构中的分野：Agent Definition / Custom Mode（静态配置）与 Session（动态会话）。

• • Agent Definition（静态角色定义）：
  在系统配置层面，“Agent”本质上是一套静态的规则集合（即 Custom Mode 或 System Role）。
  它预设了使用的基础大模型通道（Profile）、角色身份（Identity Prompt），以及能够被授予的上下文工具（Tooling）白名单权限。
• • Session（动态运行时）：
  真正承载上下文历史、充当运行期内存沙盒的，是 Session。
  所有的变量、执行状态和文件读写挂载点都与底层的一个 SessionKey 强绑定。

当主控 Agent 需要执行一个独立子任务时，它并不会在当前的上下文数组中混入指令，而是会通过框架工具启动一个子 Agent。此时，系统会为子 Agent 创建一个全新的 childSessionKey（如 agent:xxx:subagent:xxx）。

这种设计的工程价值在于状态的硬隔离。

在并发多任务中，子 Agent 拥有完全干净的初始 Prompt（往往被缩减为 Minimal Mode），它的任何执行崩溃、幻觉发散或上下文溢出，都不会越界污染主控 Agent 的状态机。

2. 调度机制：核心工具 sessions_spawn

OpenClaw 的多 Agent 并发并不是模型能力，而是由 sessions_spawn 这个系统工具驱动的运行时调度能力。

OpenClaw 并没有赋予底层 LLM 凭空创建线程的能力，Agent 之间的层级派发完全依赖于标准的系统工具调用。

核心的调度入口是一个名为 sessions_spawn 的受控工具。

在 src/agents/subagent-spawn.ts 的源码中，我们可以清晰地看到子 Agent 创建生命周期的规则与约束：

生命周期模式：Run 与 Session

sessions_spawn 暴露出两种执行生命周期：

1. 1. mode="run"（无状态子任务）：
   主 Agent 下发一个一次性的明确 task。

子 Agent 启动独立 Session，完成计算后将其最终结果投递进父级线程，随后自身的 Session 进入清理队列销毁。

主控系统无需介入轮询，由底层 Registry 负责流转与调度等待。

1. 2. mode="session"（持久化线程）：

子 Agent 创建后，其 Session 状态会一直保活，类似于在系统中拉起一个持久的守护进程。

主 Agent 可以在后续的任务流中向这个 Session 追加（Follow-up）消息，实现多次状态交互。

嵌套保护：资源与调用链控制

为了防止大模型不可控地陷入“死循环创建子代理”的资源耗尽陷阱，发起端（subagent-spawn.ts）在入口处硬死了两大拦截阈值：

// 1. 调用栈深度限制
const callerDepth = getSubagentDepthFromSessionStore(requesterInternalKey);
if (callerDepth >= maxSpawnDepth) { // 默认上限
  return { status: "forbidden", error: `sessions_spawn is not allowed at this depth (current: ${callerDepth}, max: ${maxSpawnDepth})` };
}

// 2. 当前 Session 实例活跃子节点数量限制
const activeChildren = countActiveRunsForSession(requesterInternalKey);
if (activeChildren >= maxChildren) { // 默认上限
  return { status: "forbidden", error: `sessions_spawn has reached max active children (${activeChildren}/${maxChildren})` };
}

任何尝试突破 maxSpawnDepth（最大嵌套层级）或 maxChildren（最大同级活跃数）的异步请求，都会在请求网关处被立刻拦截并返回错误信息给上层大模型。

3. 异步通信协议：Gateway 路由与 Event Bus 回调

当子 Agent 在独立的沙盒中开始运作，跨越不同 Session 隔离墙的通信协议便成为关键。

OpenClaw 没有让大模型去互相读取对方的 Messages 历史缓存，而是设计了一套极度解耦的异步信令机制。

本质上，OpenClaw 的 Agent 之间 并不直接通信，而是通过 Runtime 事件总线间接通信。

1. 异步投递（Gateway Routing）：

当 sessions_spawn 收到创建指令时，它不会阻塞等待子 Agent 完成，而是调用 callGateway({ method: "agent", ... })。

Gateway 作为全局的路由组件，会将这个任务异步派发到子 Agent 对应的消息总线和事件队列中。

Gateway 实际上承担了 Agent Runtime 的统一入口与任务调度中心。

2. 全量状态监控（Global Lifecycle Hooks）：

父级引擎如何知道子进程的状态？

在 src/agents/subagent-registry.ts 中，系统启动了一个全局守护监听器：

listenerStop = onAgentEvent((evt) => {
    // 捕获所有 agent 的 lifecycle 广播，依据 runId 映射追踪
    if (!evt || evt.stream !== "lifecycle") return;
    const phase = evt.data?.phase; // 追踪 "start", "end", "error" 阶段
    
    if (phase === "end" || phase === "error") {
    await completeSubagentRun({
        runId: evt.runId,
        outcome: phase === "error" ? { status: "error" } : { status: "ok" },
        triggerCleanup: true,
    });
    }
});

3. 结果反向写回（Announce 回调）：

当子 Agent 运行终结事件抛出时（无论是正常 end 还是发生崩溃了的 error）， Registry 将自动触发 runSubagentAnnounceFlow 函数。

这一层机制会收集子 Agent 执行输出的总结载荷（Payload），并将这些数据强制以一种 System Message 的形态，异步插回原本主代理的活跃上下文中。

Event Bus 让 Agent 执行过程变成一个 可订阅的状态流（Observable Lifecycle Stream）。

4. 架构的减法：不盲从重量级协议

在当下的 Agent 基础架构演进中，业界往往倾向于引入极其重型的标准协议来解决多节点的协同与外拓能力。例如：

• • 为了解决 Agent 层间的复杂对话网络，采用像 Google A2A（Agent-to-Agent） 这样的重量级 RPC 握手和协商协议；
• • 为了解决外部能力的接入，全面拥抱 MCP（Model Context Protocol），将工具定义、资源获取和 Prompt 拼装强行分离成多进程的 Server-Client 模式。

但 OpenClaw 给出的答卷却透露出一种反向的“工程实用主义”。

它舍弃了那些华丽或时髦的规范，没有去实现复杂的 A2A 心跳、投票机制或协商队列，而是利用一个原生的 sessions_spawn 系统工具（配合 Gateway 和 Event Bus），就极其高效地完成了“唤起 -> 隔离运算 -> 回调归档”的进程级通信。

这与它在 Tooling 层面的处理有着惊人的相似之处：与其引入 MCP 启动一批本地 Server 进行跨进程通信，不如直接通过代码组装静态化的 Profile 和 Tool Definitions 在内存中合成上下文。这种抛弃“过度设计（Over-engineering）”，依靠精简机制堆叠来实现复杂业务组合的做法，极大地拉平了整体架构的认知与调试门槛。

结语：通过机制约束不可控力

从多节点的角度观察 OpenClaw 的架构，不难发现，它的所有复杂设施——Session 强隔离绑定、调用链深度熔断器、基于 Gateway 的异步结果流转，都是为了一个共同的目标服务：建立起能够承受 LLM 不可预测性的系统边界。

通过把 Agent 的算力流降维成独立的沙盒会话，用严峻的代码拦截了“过度延展的智能幻觉”，最终利用事件总线将异步状态有条不紊地组装回主线上。

这也就是为什么在面对庞大且失序的工程任务时，OpenClaw 依然能够维持高并发、低耦合与行为可预测性。

所以，Agent 系统的核心不是“让模型更聪明”，而是 为模型建立一套可控的运行时环境（Runtime Boundary）。