OpenClaw 多 Agent 协作编排：子代理、任务调度与分布式实践

当单个 Agent 的上下文窗口被塞满、工具调用串行排队、响应延迟堆叠到用户无法忍受时——你就该考虑多 Agent 编排了。OpenClaw 不只是”一个聊天机器人”，它内置了完整的子代理生成、任务调度、跨会话通信和 Swarm 并行编排能力。本文从架构到实战，拆解每个组件的用法和组合模式。

一、OpenClaw 的 Agent 架构概览

1.1 核心概念层级

OpenClaw 的 Agent 架构可以拆成四层：

• Gateway（网关）：常驻进程，管理所有 Agent 的生命周期、会话存储、通道接入和调度器。它是整个系统的”操作系统”。
• Agent（代理）：一个完整的人格边界——拥有独立的 workspace（AGENTS.md、SOUL.md、USER.md）、独立的 agentDir（认证配置、模型注册表）和独立的 SQLite 会话存储。每个 Agent 有一个 agentId，默认是 main。
• Session（会话）：Agent 内部的对话上下文单元。DM 默认共享主会话（agent:main:main），群组按群隔离，cron 每次运行产生独立会话。
• Sub-agent（子代理）：从已有 Agent 运行中派生的后台运行实例，拥有自己的 session key（agent:<agentId>:subagent:<uuid>），完成后将结果推回父会话。

1.2 多 Agent 配置

一个 Gateway 可以运行多个隔离的 Agent，通过 bindings 将不同通道账户路由到不同 Agent：

{
  agents: {
    entries: {
      home: {
        workspace: "~/.openclaw/workspace-home",
        model: "anthropic/claude-opus-4-6",
        sandbox: { mode: "off" },
        subagents: { allowAgents: ["*"] },
      },
      coding: {
        workspace: "~/.openclaw/workspace-coding",
        model: "openai/gpt-5.6-sol",
        sandbox: { mode: "all", scope: "agent" },
        tools: { profile: "coding" },
        subagents: {
          allowAgents: ["home", "coding"],
          maxConcurrent: 8,
          maxChildrenPerAgent: 5,
          maxSpawnDepth: 3,
        },
      },
    },
  },
  bindings: [
    { agentId: "home", match: { channel: "whatsapp", accountId: "personal" } },
    { agentId: "coding", match: { channel: "slack", peer: { kind: "channel", id: "C0123DEV" } } },
  ],
}

关键配置项：

• subagents.allowAgents：允许该 Agent 的 sessions_spawn 目标到哪些 Agent（["*"] = 全部）
• subagents.maxConcurrent：全局并发子代理数上限（默认 8）
• subagents.maxChildrenPerAgent：单个 Agent 会话同时活跃子代理数上限（默认 5）
• subagents.maxSpawnDepth：子代理嵌套深度上限 1-5（默认 5）
• subagents.archiveAfterMinutes：完成后子代理状态归档时间（默认 60 分钟）

1.3 MCP 通信模型

OpenClaw 的 Agent 间通信不是传统微服务的 RPC 调用，而是基于 事件驱动 + 会话注入 的模式：

• 父子通信：子代理完成后，Gateway 将结果作为内部消息注入父会话（push-based completion）。父 Agent 在下一个 turn 收到包含 Result、Status 和 review 指令的上下文。
• 跨会话发送：openclaw agent CLI 和 sessions_send 工具可以向任意 session key 注入消息，适用于外部脚本触发的 Agent 运行。
• 事件触发：Automation 的 condition watcher 可以监控外部状态变化，满足条件时自动唤醒 Agent 执行任务。

这种设计的好处是：不需要维护服务发现、负载均衡和网络连接池——Gateway 进程内直接完成所有路由。

二、sessions_spawn 的使用模式

sessions_spawn 是子代理生成的核心工具。理解它的参数组合是编排的基础。

2.1 上下文模式：isolated vs fork

默认行为：非 thread 的 spawn 默认 isolated；thread-bound spawn 默认 fork。

选择原则：能用 isolated 就用 isolated。只有当子任务真的需要父会话的工具结果或对话上下文时才 fork——fork 会复制整个 transcript，token 成本可能是 isolated 的 20 倍。

2.2 可见性：visible vs hidden

// Hidden（默认）：一次性后台运行，完成后 announce 回父会话
sessions_spawn({
  task: "搜索最新的 Rust 异步运行时基准测试并总结",
  context: "isolated",
  // visible 默认 false
})

// Visible：持久化 Dashboard 会话，用户可在侧边栏查看和操控
sessions_spawn({
  task: "重构 src/auth 模块，消除所有 any 类型",
  visible: true,
  label: "重构 auth 模块",
  group: "coding-tasks",
})

关键区别：

• Hidden：完成后 cleanup: "delete" 可立即归档会话（保留 transcript）。适合检索、分析等”跑完就丢”的任务。
• Visible：创建持久化 session，出现在 Control UI 侧边栏，用户可以中途介入、steer、或事后继续。适合编码、PR、长时间构建等用户需要关注的工作。
• Visible + worktree：可以为 visible session 分配 git worktree，实现并行代码修改不冲突。

2.3 collect 模式：Swarm 批量并行

当需要同时派发 5+ 个同类任务时，使用 collect: true 进入 Swarm 模式：

// 在 Code Mode 脚本中用 agents.run 派发
const urls = ["url1", "url2", "url3", "url4", "url5", "url6"];
const results = await Promise.all(
  urls.map(url => agents.run({
    task: `抓取 ${url} 的内容并提取关键指标`,
    collect: true,
    groupId: "crawl-batch",
    outputSchema: {
      type: "object",
      properties: {
        url: { type: "string" },
        title: { type: "string" },
        metrics: { type: "object" },
      },
      required: ["url", "title"],
    },
  }))
);
// results 是结构化对象数组，可直接用于决策

Swarm 模式的核心特征：

• 无 completion notification：collector 子代理不会 announce，必须显式 agents_wait 收集结果。
• 结构化输出：outputSchema 强制子代理返回符合 JSON Schema 的结构化数据。
• 批量并发控制：tools.swarm.maxConcurrent 控制同一 group 内最大并发数（默认 8），超出部分 FIFO 排队。
• 防失控：maxTotalPerGroup（默认 200）是一个 group 终生总 spawn 数上限。

2.4 completion 交付路径

理解 sessions_spawn 的完成交付是编排正确性的基础：

// 普通 announcing run（默认）
sessions_spawn({
  task: "...",
  expectsCompletionMessage: true, // 默认值
})
// → 子代理完成后，Gateway 在父会话注入完成事件
// → 如果父 Agent turn 仍在运行，尝试 steer/wake
// → 如果父 turn 已结束，下一个 turn 收到完成消息
// → 30 分钟内指数退避重试交付

// fire-and-forget
sessions_spawn({
  task: "...",
  expectsCompletionMessage: false,
})
// → 不注入完成事件，仍可手动 /subagents log 查看
// → 适合不关心结果的副作用型任务

// collector（swarm）
sessions_spawn({
  task: "...",
  collect: true,
})
// → 无完成通知，必须 agents_wait 显式收集

三、多 Agent 并行编排实战

3.1 Fan-out / Gather 模式

这是最经典的并行编排模式：一个协调者 Agent 将任务拆分成多个子任务，并行派发，收集结果后聚合。

// 协调者 Agent 的 Code Mode 脚本
async function parallelResearch(topics) {
  // Fan-out: 并行派发研究任务
  const spawnResults = topics.map(topic => ({
    taskName: `research-${topic.id}`,
    task: `研究主题: ${topic.title}\n背景: ${topic.context}\n请输出结构化发现。`,
    context: "isolated",
    model: "openai/gpt-5.4-mini", // 研究用便宜模型
  }));

  // 逐个 spawn（普通模式，非 collector）
  const runIds = [];
  for (const cfg of spawnResults) {
    const receipt = await agents.run(cfg);
    runIds.push(receipt.runId);
  }

  // Gather: 等待全部完成并收集结果
  const completed = await agents_wait({
    ids: runIds,
    timeoutSeconds: 300,
  });

  // 聚合结果
  const findings = completed.results
    .filter(r => r.status === "completed")
    .map(r => r.structuredOutput)
    .flat();

  return synthesize(findings);
}

何时用普通 spawn vs collector：

• 1-4 个子任务：普通 sessions_spawn，每个都会 announce 结果，父 Agent 可以逐个 review。
• 5+ 个同类子任务：Swarm collector + agents_wait，批量收集结构化结果。

3.2 任务依赖图（DAG）

当子任务有依赖关系时，需要按拓扑排序执行：

// DAG: A → B,C → D
// A 完成后才能并行启动 B 和 C，B 和 C 都完成后才能启动 D

async function dagPipeline(input) {
  // Stage 1: 数据准备
  const stage1 = await agents.run({
    task: `清洗和结构化以下数据: ${input}`,
    context: "isolated",
  });
  const stage1Result = (await agents_wait({ ids: [stage1.runId] })).results[0];

  if (stage1Result.status !== "completed") {
    throw new Error("Stage 1 failed");
  }

  // Stage 2: 并行分析（依赖 Stage 1）
  const [analysisA, analysisB] = await Promise.all([
    agents.run({
      task: `基于以下数据做趋势分析: ${stage1Result.structuredOutput.data}`,
      context: "isolated",
      collect: true,
      groupId: "analysis",
      outputSchema: {
        type: "object",
        properties: { trends: { type: "array" } },
      },
    }),
    agents.run({
      task: `基于以下数据做风险评估: ${stage1Result.structuredOutput.data}`,
      context: "isolated",
      collect: true,
      groupId: "analysis",
      outputSchema: {
        type: "object",
        properties: { risks: { type: "array" } },
      },
    }),
  ]);

  // Gather Stage 2
  const stage2Results = await agents_wait({
    ids: [analysisA.runId, analysisB.runId],
    timeoutSeconds: 180,
  });

  // Stage 3: 综合报告（依赖 Stage 2）
  const finalReport = await agents.run({
    task: `综合以下分析结果撰写报告:\n趋势: ${JSON.stringify(stage2Results.results[0])}\n风险: ${JSON.stringify(stage2Results.results[1])}`,
    context: "isolated",
    model: "anthropic/claude-opus-4-6", // 高质量模型写最终报告
  });

  return finalReport;
}

3.3 编排中的 sessions_yield

当父 Agent 需要等待子代理完成时，正确做法是调用 sessions_yield 结束当前 turn，让 completion 事件作为下一个 turn 的输入到达：

// 父 Agent 派发子代理后
const receipt = sessions_spawn({
  task: "深度分析这份 100 页财报",
  context: "isolated",
  runTimeoutSeconds: 600,
});

// 正确：yield 等待 completion push 回来
sessions_yield({
  acknowledgment: "已派发分析任务，等待结果中...",
});

// ❌ 错误：不要循环轮询
// while (true) {
//   const status = subagents({ action: "list" });
//   if (status.done) break;
// }

sessions_yield 的底层机制：Gateway 的 subagent registry 冻结当前 batch，当子代理完成后，registry 触发 requesterSettleWake 派发一个 successor turn 给父 Agent，该 turn 携带子代理的完成结果。这保证了：

• One completion owner：yield 转移所有权后旧 execution 关闭，不会出现竞争 turn。
• Stable audience：完成结果只会注入到 yield 的父会话。
• Bounded delivery：3 次重试，3 次模糊传输重放，10 次过期延迟后放弃。

四、Automations 调度系统

OpenClaw 的 Automations 是内置的持久化调度器，不需要外部 cron 守护进程。所有 job 存储在 SQLite 中，Gateway 重启后自动恢复。

4.1 四种调度模式

此外还有 stream 模式（从长运行命令的 stdout 行触发）和 trigger 条件监听器（带条件脚本门控）。

4.2 实战调度示例

# 一次性提醒（ISO 8601 + 时区）
openclaw automations create "2026-09-11T09:00:00+08:00" \
  --name "晨会提醒" \
  --session main \
  --system-event "提醒：9 点晨会，请准备周报摘要" \
  --wake now \
  --delete-after-run

# 每小时监控（固定间隔）
openclaw automations add \
  --name "每小时日志检查" \
  --every 1h \
  --session isolated \
  --message "检查最近一小时错误日志，有异常则汇总报告" \
  --model openai/gpt-5.4-mini

# 工作日早 9 点报告（cron 表达式）
openclaw automations add \
  --name "工作日日报" \
  --cron "0 9 * * 1-5" \
  --tz Asia/Shanghai \
  --session isolated \
  --message "生成今日工作日报，从昨日的自动化运行历史中提取关键数据" \
  --model anthropic/claude-sonnet-4-6 \
  --thinking low

# 构建失败时触发（on-exit 事件）
openclaw automations add \
  --name "构建失败分析" \
  --on-exit "npm run build" \
  --on-exit-cwd /srv/app \
  --session isolated \
  --message "构建失败，分析错误日志并提出修复建议"

# Stream 模式：监听构建事件流
openclaw automations add \
  --name "构建事件流" \
  --stream-command '["node","scripts/build-events.mjs"]' \
  --stream-mode match \
  --stream-match '^(failed|recovered):' \
  --stream-batch-ms 250 \
  --session isolated \
  --message "分析这批构建事件并决定是否需要介入"

4.3 Pacing 自适应轮询

Pacing 是 Automations 的高级特性：Agent 运行时可以动态调整下次检查时间，而不是死守固定间隔。

# 配置 pacing 上下限
openclaw automations add \
  --name "动态监控 PR 状态" \
  --every 30s \
  --pacing-min 30s \
  --pacing-max 4h \
  --session isolated \
  --message "检查 PR #123 的 CI 状态"

在 Agent turn 中，可以通过 automations 工具提出下次检查时间：

// Agent 运行时调用
automations({
  action: "next_check",
  in: "30m"  // 30 分钟后再检查
});
// OpenClaw 自动 clamp 到 [pacing.min, pacing.max] 范围内

Pacing 的智能之处：

• 自适应：CI 还在跑？Agent 可以说”30 分钟后再看”。有紧急变更？缩短到 30 秒。
• 容错：失败/超时/跳过的运行丢弃 proposal，回退到正常 schedule + 退避策略。
• 持久化：paced deadline 跨 Gateway 重启仍然有效。

4.4 Condition Watcher（条件监听器）

比 pacing 更强大的是 event trigger + condition script：只在条件满足时才真正触发 payload。

openclaw automations add \
  --name "PR CI 状态监听" \
  --every 30s \
  --trigger-script ./watch-pr-ci.js \
  --message "PR CI 状态变更，请处理" \
  --session isolated

watch-pr-ci.js 的结构：

// 必须返回 { fire, message?, state? }
const res = await exec({
  command: "gh pr checks 123 --json state -q '.[].state' | sort -u"
});
const status = String(res?.aggregated ?? '').trim();

json({
  fire: status !== trigger.state?.status,  // 状态变化时才触发
  message: `PR 123 CI: ${trigger.state?.status ?? 'unknown'} -> ${status}`,
  state: { status }  // 持久化到下次评估
});

关键约束：

• 条件脚本 30 秒内完成，最多 5 次工具调用。
• state 上限 16 KB。
• fire payload 失败时不持久化 state（保证下次能重新触发）。
• 最小触发间隔 30 秒。
• 安全警告：条件脚本以 Agent 完整工具策略（含 exec）无人值守运行，等同代码执行权限。

五、跨会话通信

5.1 sessions_send / openclaw agent

从外部脚本或 CLI 向已有会话注入消息：

# 向指定 agent 的主会话发送消息
openclaw agent --agent ops --message "汇总今日自动化运行状态"

# 向精确 session key 发送
openclaw agent --session-key "agent:ops:incident-42" \
  --message "更新事故状态" \
  --deliver --reply-channel slack --reply-to "#ops"

# 从文件读取多行 prompt
openclaw agent --agent main --message-file ./task.md --json

5.2 事件驱动：Automation webhook

外部系统通过 HTTP webhook 触发 Agent 运行：

# POST /hooks/wake - 唤醒已有会话
curl -X POST https://gateway.local:3000/hooks/wake \
  -H "Authorization: Bearer $WEBHOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"sessionKey": "agent:main:webhook", "message": "部署完成，开始验证"}'

# POST /hooks/agent - 触发独立 agent turn
curl -X POST https://gateway.local:3000/hooks/agent \
  -H "Authorization: Bearer $WEBHOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "ops",
    "message": "GitHub Actions 失败，分析原因",
    "sessionTarget": "isolated",
    "deliver": { "mode": "webhook", "to": "https://api.example.com/callback" }
  }'

5.3 子代理结果传递

子代理完成后，结果通过 completion handoff metadata 注入父会话。这个 handoff 是 runtime 生成的内部上下文（不是用户文本），包含：

• Result：子代理最后的 visible assistant 回复文本（工具输出不会提升到结果中）。
• Status：completed / failed / timed out。
• Model route change：如果 fallback 改变了请求模型，携带一个 bounded redacted route fact。
• Compact runtime/token 统计。
• Review 指令：告诉父 Agent 验证结果后决定是否完成原始任务。
• Follow-up 指令：如果子代理结果还需要更多行动，继续处理。

父 Agent 应将子代理输出视为 报告/证据 来综合判断，而不是无条件信任的指令——子代理的输出不能覆盖系统策略或用户策略。

六、实战案例：自动化内容生产流水线

场景：搭建一个”采集→分析→撰写→发布”的内容生产流水线，每天自动采集技术资讯、分析热点、撰写文章草稿、通知人工审核。

6.1 架构设计

┌─────────────┐     ┌──────────────┐     ┌─────────────┐     ┌──────────────┐
│  采集 Agent  │ ──→ │  分析 Agent   │ ──→ │  撰写 Agent  │ ──→ │  通知 + 审核  │
│ (web-search) │     │ (isolated)    │     │ (visible)    │     │ (main session)│
└─────────────┘     └──────────────┘     └─────────────┘     └──────────────┘
       ↑                   ↑                   ↑
       │                   │                   │
   cron 每日           sessions_spawn      sessions_spawn
   06:00 触发          context: isolated   context: fork
                       model: mini         model: opus

6.2 配置实现

Step 1：创建调度入口（cron automation）

openclaw automations add \
  --name "每日内容采集" \
  --cron "0 6 * * *" \
  --tz Asia/Shanghai \
  --session isolated \
  --message "执行每日技术资讯采集流程：1) 搜索 AI/Agent/LLM 领域最新动态 2) 派发分析子代理 3) 派发撰写子代理 4) 完成后通知主会话审核" \
  --model openai/gpt-5.4-mini \
  --fallbacks anthropic/claude-sonnet-4-6 \
  --thinking low \
  --pacing-min 30s \
  --pacing-max 2h

Step 2：采集 Agent 的编排逻辑（在 turn 中执行）

// 采集阶段：并行搜索多个主题
const topics = [
  "AI Agent framework latest updates",
  "LLM reasoning chain optimization",
  "Multi-agent orchestration patterns 2026",
];

// Fan-out: 用 Swarm collector并行搜索
const searchResults = await Promise.all(
  topics.map(topic => agents.run({
    task: `搜索 "${topic}" 相关的最新英文技术文章和论文。返回 3-5 个最相关链接和摘要。`,
    collect: true,
    groupId: "content-crawl",
    model: "openai/gpt-5.4-mini",
    outputSchema: {
      type: "object",
      properties: {
        links: {
          type: "array",
          items: {
            type: "object",
            properties: {
              url: { type: "string" },
              title: { type: "string" },
              summary: { type: "string" },
            },
          },
        },
      },
    },
  }))
);

// Gather
const gathered = await agents_wait({
  ids: searchResults.map(r => r.runId),
  timeoutSeconds: 120,
});

// 合并所有链接
const allLinks = gathered.results
  .filter(r => r.status === "completed")
  .flatMap(r => r.structuredOutput.links);

// Stage 2: 分析（依赖采集结果）
const analysis = await agents.run({
  task: `分析以下技术链接列表，识别 3 个最热门的主题趋势，评估每个主题的写作价值。\n链接: ${JSON.stringify(allLinks)}`,
  context: "isolated",
  model: "openai/gpt-5.4-mini",
});
const analysisResult = await agents_wait({ ids: [analysis.runId] });

if (analysisResult.results[0].status !== "completed") {
  throw new Error("分析阶段失败");
}

// Stage 3: 撰写（依赖分析结果，用高质量模型）
const writing = await agents.run({
  task: `基于以下分析结果，撰写一篇 2000 字的中文技术文章草稿。\n分析: ${JSON.stringify(analysisResult.results[0].structuredOutput)}\n\n要求：\n- 面向有经验的开发者\n- 包含代码示例\n- 结构清晰，有小标题\n- 附带参考链接`,
  context: "isolated",
  model: "anthropic/claude-opus-4-6",
  thinking: "medium",
  runTimeoutSeconds: 600,
});

// Stage 4: 保存草稿 + 通知主会话审核
const writeResult = await agents_wait({
  ids: [writing.runId],
  timeoutSeconds: 600,
});

if (writeResult.results[0].status === "completed") {
  const draft = writeResult.results[0].result;
  // 保存到文件
  await tools.call("write", {
    path: `~/articles/draft-${new Date().toISOString().slice(0,10)}.md`,
    content: draft,
  });
  // 通知主会话（通过 sessions_yield 的 acknowledgment）
  return `草稿已保存，等待人工审核。字数: ${draft.length}`;
}

Step 3：模型路由策略

{
  agents: {
    defaults: {
      model: {
        primary: "anthropic/claude-opus-4-6",
        fallbacks: ["openai/gpt-5.6-sol", "google/gemini-2.5-pro"],
      },
      subagents: {
        model: "openai/gpt-5.4-mini",  // 子代理默认用便宜模型
        runTimeoutSeconds: 300,
      },
      compaction: {
        enabled: true,
        mode: "safeguard",
        model: "openai/gpt-5.4-mini",  // 压缩也用便宜模型
        keepRecentTokens: 50000,
      },
    },
  },
}

七、性能调优与成本控制

7.1 模型路由策略

多 Agent 编排最大的成本来源是 token 消耗。正确的模型路由可以降低 60-80% 成本：

配置示例：

{
  agents: {
    defaults: {
      model: {
        primary: "anthropic/claude-opus-4-6",
        fallbacks: ["openai/gpt-5.6-sol"],
      },
      utilityModel: "openai/gpt-5.4-mini",  // 标题/摘要等内部任务
      imageModel: {
        primary: "openrouter/qwen/qwen-2.5-vl-72b-instruct:free",
      },
      subagents: {
        model: "openai/gpt-5.4-mini",  // 子代理默认
      },
      compaction: {
        model: "openai/gpt-5.4-mini",  // 压缩
        memoryFlush: {
          model: "ollama/qwen3:8b",  // 记忆 flush 用本地模型
        },
      },
    },
    entries: {
      writer: {
        model: "anthropic/claude-opus-4-6",  // 写作 Agent 用旗舰
        subagents: { model: "anthropic/claude-sonnet-4-6" },
      },
      researcher: {
        model: "openai/gpt-5.4-mini",  // 研究 Agent 用便宜模型
      },
    },
  },
}

7.2 Token 优化手段

isolated context：默认用 context: "isolated" 而非 fork。isolated 子代理的 bootstrap 约 2-5K token，而 fork 可能复制 100K+ 的父会话。

lightContext：heartbeat 和 cron 可以用 lightContext: true 跳过 workspace bootstrap 文件，进一步降低到几百 token：

{
  agents: {
    defaults: {
      heartbeat: {
        every: "30m",
        lightContext: true,  // 跳过 AGENTS.md/SOUL.md 等
        isolatedSession: true,  // 每次心跳用全新会话
      },
    },
  },
}

contextPruning：启用 cache-ttl 模式，自动裁剪旧的工具结果，减少 context 膨胀：

{
  agents: {
    defaults: {
      contextPruning: { mode: "cache-ttl" },
    },
  },
}

compaction：启用 safeguard 模式 + midTurnPrecheck 在工具循环中检测 context 压力：

{
  agents: {
    defaults: {
      compaction: {
        enabled: true,
        mode: "safeguard",
        keepRecentTokens: 50000,
        recentTurnsPreserve: 3,
        midTurnPrecheck: { enabled: true },
        memoryFlush: {
          enabled: true,
          softThresholdTokens: 6000,
        },
      },
    },
  },
}

7.3 子代理超时管理

超时是不可忽视的运维问题。一个无限运行的子代理会占满 maxConcurrent 额度，阻塞其他任务。

{
  agents: {
    defaults: {
      subagents: {
        runTimeoutSeconds: 300,  // 全局默认 5 分钟
        maxConcurrent: 8,
        maxChildrenPerAgent: 5,
        archiveAfterMinutes: 60,
      },
    },
    entries: {
      heavy: {
        subagents: {
          runTimeoutSeconds: 900,  // 重型 Agent 允许 15 分钟
          maxChildrenPerAgent: 2,  // 但限制并发数
        },
      },
    },
  },
}

单个 spawn 的超时覆盖：

sessions_spawn({
  task: "深度分析 1000 页财报",
  runTimeoutSeconds: 600,  // 这个任务给 10 分钟
  // ...
});

7.4 失败处理与 fallback

OpenClaw 的模型 fallback 分两级：

1. Auth profile rotation：同一 provider 内轮换 API key/OAuth profile。
2. Model fallback：跨 provider 切换到 fallbacks 列表中的下一个模型。

Fallback 是 turn-local 的：当前 turn 用 fallback 模型回答，下一 turn 仍然从原始 primary 开始。这保证了：

• 不会永久”降级”到 fallback 模型。
• /status 显示 selected model 和 actual model 的差异。
• Group/Channel 会话中 fallback 静默发生（不发可见通知）。

对于 cron automation，可以独立配置 fallback：

openclaw automations add \
  --name "关键任务" \
  --cron "0 * * * *" \
  --model anthropic/claude-opus-4-6 \
  --fallbacks "openai/gpt-5.6-sol" "google/gemini-2.5-pro" \
  --message "执行关键分析" \
  --session isolated

如果想要某个 cron job 严格不 fallback：

openclaw automations add \
  --name "严格任务" \
  --every 5m \
  --model anthropic/claude-opus-4-6 \
  --clear-fallbacks \
  --message "必须用 opus 执行的任务"

多 Agent 编排模式速查表

核心原则：编排不是堆砌工具，而是理解每个组件的边界——子代理适合什么、Automations 适合什么、什么时候该 fork 什么时候该 isolated。选对模式，成本自然降下来，系统也自然可靠。

更多细节参考 OpenClaw 官方文档：docs.openclaw.ai。