OpenClaw SubAgent 编排模式 - 让AI Agent组队打怪

📅 2026-06-05 | 🏷️ OpenClaw · SubAgent · 多Agent协作 | ⏱️ 阅读约15分钟

一个Agent搞不定？那就来一群

你有没有遇到过这种场景：用户问了一个复杂问题，需要同时搜索多个信息源、对比分析、生成报告——单个Agent忙得焦头烂额，上下文窗口都快撑爆了。

这就是 SubAgent 大显身手的时候了。想象一下：你是一个项目经理，手下有三个研究员，你只需要说"去，把这三个方向都调研一遍"，然后坐等他们交报告。SubAgent 就是你的"AI研究员团队"。

OpenClaw 的 SubAgent 系统让你可以从一个 Agent 中 spawn 出多个子 Agent，每个子 Agent 独立执行任务，完成后自动汇报结果给父 Agent。这不是科幻，这是真实可用的架构模式。

什么是 SubAgent？

SubAgent（子代理）是由父 Agent 通过 sessions_spawn 工具创建的独立 Agent 实例。它们具有以下特征：

独立会话：每个 SubAgent 有自己的对话上下文，不会互相干扰
继承能力：SubAgent 继承父 Agent 的工具集和权限配置
自动汇报：SubAgent 完成后，结果自动推送回父 Agent
可被终止：父 Agent 可以随时终止不需要的 SubAgent
层级限制：默认最多支持 3 层嵌套（父→子→孙），防止失控

简单来说：SubAgent = 独立会话 + 继承能力 + 自动汇报。更多基础概念可以看 SubAgent 基础指南。

Fork vs Isolated：两种上下文模式

Spawn SubAgent 时，你需要决定上下文模式。这是最关键的架构选择。

Fork 模式：继承父Agent的上下文

// Fork 模式：SubAgent 可以看到父 Agent 之前的对话历史
// 适合：需要理解上下文的场景
sessions_spawn({
  task: "根据上面的讨论，帮我生成一份总结报告",
  context: "fork"  // 继承父Agent的完整对话历史
})

Fork 模式下，SubAgent 能看到从对话开始到 spawn 时刻的所有消息。好处是不需要重复交代背景，SubAgent 直接上手干活。但代价是消耗更多的上下文 token。

Isolated 模式：干净的白纸

// Isolated 模式：SubAgent 只看到 spawn 时传入的 task
// 适合：独立任务，不需要上下文
sessions_spawn({
  task: "搜索最新的 OpenClaw 版本更新日志，整理成要点列表",
  context: "isolated"  // 只看到 task 内容
})

Isolated 模式下，SubAgent 的上下文完全干净，只有 task 中的信息。适合独立的、不依赖对话历史的任务。token 消耗更低，也更可控。

选择建议

用 Fork：任务依赖当前对话内容、需要理解用户意图、需要引用之前的讨论
用 Isolated：独立的搜索/采集任务、不依赖上下文的标准化流程、需要并行执行多个不相关任务
默认用 Isolated：除非你明确需要上下文，否则 isolated 更安全、更省 token

深入了解 spawn 机制的细节，可以看 SubAgent Spawn 详解。

Yield/Wait 模式：优雅地等待结果

spawn 了 SubAgent 之后，父 Agent 有两种等待策略：

方式一：sessions_yield（推荐）

// 父 Agent spawn 多个 SubAgent 后 yield
// yield 会暂停父 Agent，等所有 SubAgent 完成后自动唤醒

// Step 1: spawn 多个任务
sessions_spawn({
  task: "搜索 OpenAI 最新动态",
  label: "openai-research"
})

sessions_spawn({
  task: "搜索 Anthropic 最新动态",
  label: "anthropic-research"
})

sessions_spawn({
  task: "搜索 Google AI 最新动态",
  label: "google-research"
})

// Step 2: yield，等待所有子任务完成
sessions_yield({
  message: "已启动3个研究SubAgent，等待结果..."
})

// Step 3: 自动唤醒后，SubAgent 的结果已经在上下文中
// 直接整合结果即可
"根据三个研究团队的报告，综合分析如下：..."

sessions_yield 是"发射后不管"模式：spawn 完任务就 yield，系统会自动在所有 SubAgent 完成后唤醒父 Agent。这是最优雅的等待方式。

方式二：手动轮询（不推荐）

// ❌ 不推荐：手动轮询 SubAgent 状态
// 这种方式浪费 token，增加延迟，且容易出错
while (true) {
  status = check_subagent_status("openai-research")
  if (status === "completed") break
  wait(1000)
}

除非有特殊需求，否则永远用 sessions_yield。它是 OpenClaw 专门为 SubAgent 协作设计的机制。

实战模式一：并行研究（Fan-out/Fan-in）

这是最经典的 SubAgent 模式：把一个大任务拆成多个小任务并行执行，最后汇总结果。就像餐厅后厨——切菜、炒菜、煲汤同时进行，最后一起上桌。

// 场景：用户问"帮我对比三个主流AI框架的优劣"

// 父 Agent 的执行逻辑：

// 1. 并行 spawn 三个研究任务
sessions_spawn({
  task: "深入调研 LangChain 框架：\n- 核心特性\n- 优势\n- 劣势\n- 适用场景\n- 社区活跃度\n输出结构化报告。",
  label: "langchain-research",
  context: "isolated"
})

sessions_spawn({
  task: "深入调研 AutoGen 框架：\n- 核心特性\n- 优势\n- 劣势\n- 适用场景\n- 社区活跃度\n输出结构化报告。",
  label: "autogen-research",
  context: "isolated"
})

sessions_spawn({
  task: "深入调研 CrewAI 框架：\n- 核心特性\n- 优势\n- 劣势\n- 适用场景\n- 社区活跃度\n输出结构化报告。",
  label: "crewai-research",
  context: "isolated"
})

// 2. 等待所有研究完成
sessions_yield({
  message: "3个研究任务已启动，正在并行调研..."
})

// 3. 汇总结果（SubAgent 结果自动注入上下文）
"根据三份独立调研报告，以下是三个框架的综合对比：
[对比表格]
[推荐建议]"

这个模式的威力在于：三个研究任务同时执行，总耗时约等于最慢的那个任务的时间，而不是三者之和。如果有5个研究方向，时间也不会线性增长。

实战模式二：代码审查流水线（Pipeline）

不同于并行模式，流水线模式是串行的——每个 SubAgent 的输出是下一个 SubAgent 的输入。就像工厂的流水线，每个环节负责一道工序。

// 场景：自动化代码审查流水线

// Stage 1: 代码风格检查
sessions_spawn({
  task: "审查以下代码的风格问题：\n" + code_content + "\n\n检查项：命名规范、代码格式、注释质量。输出问题列表。",
  label: "style-review",
  context: "isolated"
})
sessions_yield()

// Stage 2: 安全审查（基于 Stage 1 的结果）
sessions_spawn({
  task: "基于风格审查结果，进行安全审查：\n" + style_results + "\n" + code_content + "\n\n检查项：SQL注入、XSS、敏感信息泄露。输出安全问题列表。",
  label: "security-review",
  context: "isolated"
})
sessions_yield()

// Stage 3: 性能审查
sessions_spawn({
  task: "进行性能审查：\n" + code_content + "\n\n检查项：时间复杂度、内存使用、并发安全。输出性能问题列表。",
  label: "performance-review",
  context: "isolated"
})
sessions_yield()

// Stage 4: 综合报告
"代码审查完成，以下是综合报告：
- 风格问题：N项
- 安全问题：N项
- 性能问题：N项
[详细报告]"

流水线模式适合有前后依赖关系的场景。每个阶段可以专注于自己的领域，输出结构化的结果供下一阶段使用。想要了解更多的多 Agent 协作模式，推荐看多Agent协作指南。

实战模式三：内容生成流水线

用 SubAgent 实现"研究→写作→审核"的内容生产流水线：

// 内容生产流水线

// 阶段1：素材收集（并行）
sessions_spawn({
  task: "搜索 'OpenClaw 2026年新特性' 的相关信息，整理5个关键点",
  label: "素材-1"
})
sessions_spawn({
  task: "搜索 'AI Agent 最新趋势' 的相关信息，整理5个关键点",
  label: "素材-2"
})
sessions_spawn({
  task: "搜索 '多Agent协作 案例' 的相关信息，整理3个案例",
  label: "素材-3"
})
sessions_yield()

// 阶段2：文章撰写（基于素材）
sessions_spawn({
  task: "基于以下素材，撰写一篇2000字的技术博客：\n" + 
        collected_materials + "\n\n" +
        "要求：标题吸引人、逻辑清晰、有代码示例、口语化风格",
  label: "writer",
  context: "isolated"
})
sessions_yield()

// 阶段3：内容审核
sessions_spawn({
  task: "审核以下文章：\n" + draft_article + "\n\n" +
        "检查：事实准确性、逻辑连贯性、技术细节正确性、错别字",
  label: "reviewer",
  context: "isolated"
})
sessions_yield()

// 最终输出
"文章已生成并通过审核。以下是最终版本：..."

实战模式四：A/B 测试式方案生成

当用户需要多个备选方案时，可以让多个 SubAgent 独立生成方案，最后由父 Agent 综合评估。

// 场景：用户需要一个系统架构方案

// 并行生成3个方案
sessions_spawn({
  task: "设计一个高并发API网关架构方案。要求：\n- 支持10万QPS\n- 99.9%可用性\n- 成本可控\n输出详细技术方案。",
  label: "方案A-高并发",
  context: "isolated"
})

sessions_spawn({
  task: "设计一个低成本API网关架构方案。要求：\n- 支持1万QPS（峰值可弹性扩展）\n- 99.5%可用性\n- 最小化基础设施成本\n输出详细技术方案。",
  label: "方案B-低成本",
  context: "isolated"
})

sessions_spawn({
  task: "设计一个平衡型API网关架构方案。要求：\n- 支持5万QPS\n- 99.9%可用性\n- 合理成本\n输出详细技术方案。",
  label: "方案C-平衡型",
  context: "isolated"
})
sessions_yield()

// 综合评估
"基于三个独立团队的方案，以下是综合对比分析：
[对比维度表]
[推荐方案及理由]"

这个模式的价值在于：每个方案是独立思考的结果，不会受到其他方案的影响。这比单个 Agent 连续想三个方案要好得多——后者容易陷入锚定效应。

错误处理：SubAgent 失败了怎么办

SubAgent 也可能失败——超时、工具调用异常、输出格式不对。父 Agent 需要优雅地处理这些情况。

// 错误处理最佳实践

// 1. 在 task 中明确要求错误处理
sessions_spawn({
  task: "搜索最新AI新闻。如果搜索失败，尝试备用关键词。\n" +
        "如果所有搜索都失败，输出 'SEARCH_FAILED: [失败原因]'。\n" +
        "不要编造信息。",
  label: "news-search"
})

// 2. yield 后检查结果
sessions_yield()

// 3. 处理可能的失败
if (subagent_results["news-search"].includes("SEARCH_FAILED")) {
  // 搜索失败，使用缓存数据或通知用户
  "新闻搜索暂时不可用，以下是昨天的新闻摘要：..."
} else {
  // 正常处理
  "以下是今天的AI新闻：..."
}

关键原则：

在 task 中定义失败行为：告诉 SubAgent 失败时输出什么标记，而不是让它自己决定
不要假设所有 SubAgent 都会成功：并行任务中，部分失败是正常的
设置合理的超时：SubAgent 默认有超时限制，但你可以在 spawn 时自定义
降级而非崩溃：某个 SubAgent 失败时，用备选方案而不是直接报错

关于 Agent 的整体编排架构，可以看 Agent Spawn 架构详解和多Agent编排指南。

SubAgent 的资源管理

SubAgent 不是免费的——每个 SubAgent 都消耗 token、占用计算资源。盲目 spawn 大量 SubAgent 会导致：

Token 爆炸：10个 SubAgent 各用 4K token，汇总到父 Agent 就是 40K+
延迟增加：SubAgent 越多，汇总时间越长
成本飙升：按 token 计费的模型，SubAgent 是成本放大器

// 资源管理最佳实践

// ✅ 合理：3-5个 SubAgent 并行
sessions_spawn({ task: "研究A", label: "A" })
sessions_spawn({ task: "研究B", label: "B" })
sessions_spawn({ task: "研究C", label: "C" })
sessions_yield()

// ❌ 过度：20个 SubAgent 同时跑
// 大概率触发限流，且汇总结果会撑爆上下文
for (let i = 0; i < 20; i++) {
  sessions_spawn({ task: `研究方向${i}`, label: `R${i}` })
}

// ✅ 折中：分批执行
// 先 spawn 5个，完成后再 spawn 下一批5个
sessions_spawn({ task: "批次1-任务1" })
sessions_spawn({ task: "批次1-任务2" })
// ... 共5个
sessions_yield()
// 处理批次1结果后，再启动批次2

经验法则：同时运行的 SubAgent 不超过 5 个。如果任务更多，分批执行。

最佳实践清单

优先用 Isolated 模式：除非明确需要上下文，否则保持 SubAgent 的上下文干净
Task 描述要具体：SubAgent 看不到你的想法，所有信息都要写在 task 里
用 Label 标记：给每个 SubAgent 起有意义的 label，方便在结果中识别
定义输出格式：在 task 中明确要求输出格式（Markdown、JSON、要点列表等）
控制并发数量：同时不超过 5 个，更多则分批
用 sessions_yield 等待：不要手动轮询
处理失败情况：在 task 中定义失败标记，父 Agent 做好降级准备
监控 Token 消耗：SubAgent 是 token 放大器，定期检查成本
避免深层嵌套：尽量控制在 2 层以内（父→子），3层是极限
测试先行：先用简单任务测试 SubAgent 流程，再扩展到复杂场景

总结

SubAgent 是 OpenClaw 最强大的能力之一。它让一个 Agent 可以"分身"执行并行任务，大幅提升复杂场景下的处理效率和质量。

核心模式回顾：

Fan-out/Fan-in（并行研究）：拆分→并行→汇总，适合独立子任务
Pipeline（流水线）：串行执行，每个阶段的输出是下一阶段的输入
A/B Testing（方案对比）：独立生成多个方案，综合评估
Content Pipeline（内容生产）：素材→写作→审核的多阶段流程

记住：SubAgent 是"组队打怪"，不是"人海战术"。合理拆分任务、控制并发、处理异常，才能发挥它的最大威力。

相关推荐：SubAgent基础 · Spawn详解 · 多Agent协作 · Agent Spawn架构 · 多Agent编排