OpenClaw 子代理系统：多任务并行编排实战

七夜zippoe

266人浏览 · 2026-06-20 10:36:10

七夜zippoe · 2026-06-20 10:36:10 发布

🦞 当单个 AI Agent 面对海量任务时，串行执行往往成为瓶颈。OpenClaw 的子代理系统提供了一套轻量而强大的多任务并行编排机制——从任务分发到结果聚合，从上下文隔离到错误恢复，让你能够像指挥一个团队一样调度 AI Agent，而不是像排队一样一个接一个地等待。

一、为什么需要子代理系统

在传统的单代理架构中，所有任务都在一个会话上下文中串行执行。这在简单场景下足够高效，但当任务规模和复杂度上升时，三个核心瓶颈会迅速凸显：

🚧 瓶颈一：串行执行的效率天花板

假设你需要同时处理 10 个独立的翻译任务，串行模式下第 10 个任务必须等待前 9 个全部完成。即使每个任务只需要 5 秒，总耗时也高达 50 秒——而并行模式下，理论耗时仅为 5 秒。

🚧 瓶颈二：上下文窗口的膨胀

单会话中累积的工具调用、中间结果和对话历史会持续占用上下文窗口。当任务量增大时，宝贵的 token 空间被历史信息填满，模型可用于推理的容量被压缩，输出质量随之下降。

🚧 瓶颈三：故障的级联效应

串行流水线中，任何一个环节失败都可能中断后续所有任务。一个网络超时就能让整个批处理任务前功尽弃，缺乏局部恢复能力。

OpenClaw 的子代理系统正是为解决这些问题而设计。它通过 sessions_spawn 机制让主代理能够创建独立的子代理来并行执行任务，同时提供灵活的上下文传递、结果回收和错误恢复策略。

🔗 了解 OpenClaw 的整体架构，请参考官方文档：docs.openclaw.ai

二、子代理架构核心机制

2.1 架构全景

OpenClaw 的子代理系统建立在 Gateway 的会话管理之上。每个子代理都拥有独立的会话上下文，但可以通过特定机制与父代理通信。整个架构可以分为三层：

2.2 sessions_spawn 的工作原理

sessions_spawn 是子代理系统的核心入口。当主代理调用它时，Gateway 会完成以下操作：

创建子会话：在 ~/.openclaw/agents/<agentId>/sessions/ 下生成独立的会话记录
注入任务上下文：将任务描述、上下文模式等元数据写入子代理的系统提示
建立追踪记录：在任务追踪器中创建一条 subagent 类型的任务记录
启动执行：子代理开始独立运行，生命周期由 Gateway 管理

每个子代理的会话 ID 遵循格式 agent:main:subagent:<uuid>，确保与主会话的命名空间隔离。

2.3 生命周期状态机

子代理从创建到完成，遵循清晰的状态流转：

状态	含义	典型触发条件
`queued`	已创建，等待执行	spawn 调用成功
`running`	正在执行中	Gateway 分配资源并启动
`succeeded`	执行成功	子代理正常完成并返回结果
`failed`	执行失败	工具调用异常、模型错误
`timed_out`	超时	超过配置的超时阈值
`cancelled`	已取消	`openclaw tasks cancel`
`lost`	丢失	支撑会话消失超过 5 分钟

💡 lost 状态是运行时感知的：Gateway 会检查支撑子会话是否仍然存在。如果只是暂时性断连，5 分钟的宽限期内不会标记为 lost。

三、任务分发策略：并行与串行的选择

3.1 何时选择并行

并行分发适合以下场景：

任务之间无依赖：每个子代理的输入不依赖其他子代理的输出
I/O 密集型操作：网络请求、文件读写等等待时间长的工作
批量同构任务：对一组数据执行相同操作（翻译、摘要、分析等）

# 并行分发示例：同时生成 5 篇文章摘要
for i, article in enumerate(articles[:5]):
    sessions_spawn(
        task=f"请为以下文章生成 200 字摘要：\n{article}",
        context="isolated",   # 独立上下文，互不干扰
        label=f"summary-{i}"  # 可读标签，便于追踪
    )

3.2 何时选择串行

串行分发适合以下场景：

任务间存在数据依赖：后续任务需要前序任务的输出
共享资源竞争：多个子代理同时写入同一文件或数据库
顺序敏感操作：部署流水线、配置更新等需要严格顺序的场景

# 串行分发示例：先翻译，再校对，最后排版
result1 = sessions_spawn(task="翻译以下文档...", context="fork")
# 等待 result1 完成后
result2 = sessions_spawn(
    task=f"校对以下翻译结果：\n{result1}", 
    context="fork"
)
# 等待 result2 完成后
result3 = sessions_spawn(
    task=f"排版以下内容：\n{result2}", 
    context="fork"
)

3.3 混合策略

实际业务中，最常见的模式是混合编排：同一层级的任务并行执行，层级之间串行衔接。

这种 “Map-Reduce” 风格的编排在大规模任务处理中极为有效。Map 阶段并行分散，Reduce 阶段串行聚合，既保证了效率，又确保了数据一致性。

四、上下文传递：fork 与 isolated 模式

上下文传递模式决定了子代理能够看到什么信息，是子代理架构中最重要的设计决策之一。

4.1 fork 模式——继承式上下文

fork 模式下，子代理会继承父代理当前的对话上下文，包括会话历史、工作空间文件和工具状态。这就像 Git 的分支——子代理从父代理的"快照"上创建分支，拥有起点时刻的所有信息。

适用场景：

子代理需要理解当前对话的来龙去脉
任务依赖主会话中已产生的变量和状态
需要保持对话连续性的分支操作

注意事项：

fork 会复制上下文，因此子代理对上下文的修改不会回传给父代理
大量 fork 子代理可能导致上下文膨胀，因为每个子代理都持有一份副本
适合少量、需要上下文感知的子代理创建

# fork 模式：子代理需要知道我们刚才讨论的内容
sessions_spawn(
    task="基于我们刚才讨论的架构方案，列出详细的实施步骤",
    context="fork"  # 继承当前对话上下文
)

4.2 isolated 模式——隔离式上下文

isolated 模式下，子代理获得一个完全干净的上下文，仅包含任务描述本身和系统级的工具定义。子代理对父代理的对话历史一无所知。

适用场景：

批量任务处理（每个任务独立，无需上下文）
安全敏感操作（隔离上下文避免信息泄露）
高并发场景（避免上下文复制开销）
大规模并行分发（默认推荐模式）

注意事项：

如果子代理需要某些上下文信息，必须通过 task 参数显式传递
无法访问主会话中的变量和中间结果
适合大量、独立的同构任务

# isolated 模式：每个翻译任务完全独立
sessions_spawn(
    task=f"将以下英文翻译为中文：\n{english_text}",
    context="isolated"  # 干净上下文，不继承任何对话历史
)

4.3 模式选择决策矩阵

维度	fork	isolated
上下文继承	✅ 完整继承	❌ 全新隔离
Token 开销	🔴 高（复制上下文）	🟢 低（仅任务描述）
并发能力	🟡 受上下文大小限制	🟢 高并发友好
信息安全	🟡 可能泄露对话历史	🟢 完全隔离
典型场景	上下文依赖的分支任务	批量独立任务
推荐并发数	≤3	≤10

⚠️ 安全提示：当子代理处理来自不同用户的数据时，务必使用 isolated 模式。fork 模式下，一个用户的对话历史可能通过子代理的上下文泄露给另一个用户的数据处理过程。

五、结果回收：sessions_yield 与回调机制

5.1 sessions_yield 的角色

子代理执行完毕后，结果如何回到主代理？OpenClaw 采用推式（push-based）完成通知机制，而非轮询式。

当子代理完成时，Gateway 会自动将结果推送给父代理的会话。主代理调用 sessions_yield 后结束当前回合，等待子代理的结果作为下一条消息返回。

5.2 为什么不用轮询

你可能想问：为什么不直接轮询子代理状态？原因有三：

资源浪费：轮询意味着主代理持续占用会话资源，即使子代理还在执行
延迟增加：轮询间隔太长导致结果延迟，太短则浪费 API 调用
竞态条件：轮询时机不当可能读到中间状态，而非最终结果

推式通知完美解决了这些问题——主代理在 yield 后释放资源，子代理完成时自动唤醒，零轮询开销。

5.3 结果格式

子代理的结果以结构化格式返回，包含：

字段	类型	说明
`status`	string	任务终态：succeeded / failed / timed_out
`result`	string	子代理的最终输出文本
`label`	string	spawn 时设置的标签，用于关联
`sessionId`	string	子代理的会话 ID
`error`	string	仅失败时出现，错误描述

主代理收到结果后，可以根据 label 将结果映射回原始任务，实现精准的结果聚合。

六、资源管理：并发数控制

6.1 为什么需要并发控制

虽然子代理可以并行运行，但资源并非无限。不受控的并发会导致三个问题：

API 速率限制：模型提供商通常有 RPM（每分钟请求数）和 TPM（每分钟 token 数）限制
内存压力：每个子代理会话占用 Gateway 内存，过多子代理可能导致 OOM
工具竞争：多个子代理同时操作同一资源（文件、数据库）可能引发冲突

6.2 OpenClaw 的并发策略

OpenClaw 在架构层面提供了内置的并发保护：

默认并发上限： 在 Team 模式下，系统建议同一时刻并行运行的 Worker 不超过 3 个。这不是硬性上限，而是经过实践验证的最佳值——在 API 速率限制、内存开销和任务完成速度之间取得平衡。

资源隔离： 每个子代理拥有独立的会话存储和工作空间引用，不会相互干扰。会话文件存储在 ~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl，互不重叠。

自动清理： 子代理完成后，Gateway 会自动清理相关的浏览器标签页、进程等资源。终止状态的记录默认保留 7 天后自动清理。

6.3 手动并发控制模式

对于需要精细控制的场景，可以采用以下模式：

# 信号量模式：控制最大并发为 3
MAX_CONCURRENT = 3
active_tasks = []

for i, item in enumerate(task_list):
    # 等待某个任务完成后再启动新任务
    if len(active_tasks) >= MAX_CONCURRENT:
        # yield 等待最早的任务完成
        sessions_yield("等待任务槽位释放")
        active_tasks = [t for t in active_tasks if t not in completed]
    
    result = sessions_spawn(
        task=f"处理任务: {item}",
        context="isolated",
        label=f"task-{i}"
    )
    active_tasks.append(f"task-{i}")

6.4 资源监控

使用 CLI 命令监控子代理资源使用情况：

# 查看所有运行中的任务
openclaw tasks list --status running

# 查看子代理类型的任务
openclaw tasks list --runtime subagent

# 查看特定任务的详细信息
openclaw tasks show <task-id>

# 健康审计
openclaw tasks audit

七、错误处理：子代理失败策略

7.1 常见失败模式

子代理执行过程中可能遇到以下失败场景：

失败类型	根因	典型表现
模型错误	API 限流、模型过载	`429 Too Many Requests`
工具异常	网络超时、文件不存在	工具返回错误信息
上下文溢出	任务描述过长	输出截断或中断
超时	任务复杂度超预期	`timed_out` 状态
会话丢失	Gateway 重启	`lost` 状态

7.2 错误恢复策略

OpenClaw 提供了多层次的错误恢复机制：

策略一：自动重试

对于瞬态错误（网络波动、API 限流），Gateway 内置了指数退避重试。子代理的工具调用失败后，会自动重试若干次，无需主代理干预。

策略二：降级回退

当子代理失败且重试耗尽时，主代理可以降级到串行执行或使用更简单的策略：

# 降级策略：并行失败则串行重试
results = []
for item in batch:
    result = sessions_spawn(
        task=f"处理: {item}",
        context="isolated",
        label=f"retry-{item}"
    )
    if result.status == "failed":
        # 降级：主代理直接处理
        results.append(process_locally(item))
    else:
        results.append(result.output)

策略三：部分成功容忍

在批量处理场景中，部分子代理失败不应阻塞整体流程。主代理可以收集所有成功结果，对失败项记录日志后继续：

# 部分成功容忍
successes = []
failures = []

for result in all_results:
    if result.status == "succeeded":
        successes.append(result)
    else:
        failures.append({
            "label": result.label,
            "error": result.error
        })

# 汇总报告
summary = f"成功: {len(successes)}/{len(all_results)}"
if failures:
    summary += f"\n失败项: {json.dumps(failures, ensure_ascii=False)}"

策略四：超时防护

为每个子代理设置合理的超时阈值，防止任务无限挂起：

{
  // 在 openclaw.json 中配置默认超时
  agents: {
    defaults: {
      subagentTimeout: "5m"  // 子代理默认 5 分钟超时
    }
  }
}

7.3 失败诊断

当子代理失败时，使用以下工具快速定位问题：

# 查看失败任务的详细信息
openclaw tasks show <task-id>

# 运行健康审计，检查常见问题
openclaw tasks audit

# 查看子代理的会话日志
cat ~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl | tail -50

八、实战案例1：批量内容生成

8.1 场景描述

假设你运营一个技术博客，需要每周生成 10 篇不同主题的技术文章摘要和推荐语。串行处理需要约 50 分钟（每篇 5 分钟），而通过子代理并行可以缩短到约 10 分钟。

8.2 实现代码

# 批量内容生成：并行生成 10 篇文章摘要
topics = [
    {"id": 1, "title": "Rust 异步编程深度解析", "keywords": "Rust, async, tokio"},
    {"id": 2, "title": "Kubernetes 网络策略实战", "keywords": "K8s, NetworkPolicy, Cilium"},
    {"id": 3, "title": "WebAssembly 性能优化指南", "keywords": "Wasm, SIMD, optimization"},
    # ... 共 10 个主题
]

for topic in topics:
    sessions_spawn(
        task=f"""你是一位技术博客编辑。请为以下文章生成：
1. 150 字中文摘要
2. 30 字推荐语
3. 3 个标签

文章标题：{topic['title']}
关键词：{topic['keywords']}""",
        context="isolated",  # 每个任务独立，无需上下文
        label=f"blog-{topic['id']}"
    )

# 释放当前回合，等待所有子代理完成
sessions_yield("等待所有文章摘要生成完成")

8.3 代码解析

上述代码的关键设计点：

isolated 模式：每个文章摘要生成任务完全独立，无需继承对话历史，节省上下文开销
结构化 task 描述：通过明确的要求模板（摘要字数、推荐语长度、标签数量），确保输出格式一致
label 命名规范：使用 blog-{id} 格式，方便在结果回收时按 ID 映射回原始主题
批量 spawn 后统一 yield：所有子代理并行启动后，主代理一次性 yield 等待，最大化并行度

8.4 结果聚合

子代理完成后，主代理自动唤醒并收到所有结果。接下来进行聚合：

# 假设 results 是收到的所有子代理结果
blog_summaries = {}

for result in results:
    if result.status == "succeeded":
        # 从 label 中提取文章 ID
        blog_id = int(result.label.split("-")[1])
        blog_summaries[blog_id] = result.output
    else:
        print(f"文章 {result.label} 生成失败: {result.error}")

# 按原始顺序输出
for topic in topics:
    if topic["id"] in blog_summaries:
        print(f"=== {topic['title']} ===")
        print(blog_summaries[topic["id"]])
        print()

九、实战案例2：多源数据并行抓取

9.1 场景描述

在市场调研场景中，你需要同时从多个数据源获取信息：GitHub 仓库统计、HackerNews 热帖、技术博客最新文章、社交媒体趋势。不同数据源的 API 和格式各不相同，但抓取过程相互独立，非常适合子代理并行。

9.2 架构设计

9.3 实现代码

# 多源数据并行抓取
data_sources = [
    {
        "name": "github",
        "task": """使用 web_fetch 工具抓取以下信息：
1. 访问 https://api.github.com/search/repositories?q=stars:>10000&sort=stars
2. 提取前 5 个仓库的名称、星标数、语言和描述
3. 以 JSON 格式返回结果""",
        "label": "source-github"
    },
    {
        "name": "hackernews",
        "task": """使用 web_fetch 工具抓取以下信息：
1. 访问 https://hacker-news.firebaseio.com/v0/topstories.json
2. 获取前 10 个文章的详情
3. 返回每个文章的标题、得分和链接""",
        "label": "source-hackernews"
    },
    {
        "name": "techblogs",
        "task": """使用 web_fetch 工具抓取以下信息：
1. 访问 https://blog.cloudflare.com/rss/
2. 解析 RSS 提取最新 5 篇文章
3. 返回每篇文章的标题、发布日期和摘要""",
        "label": "source-techblogs"
    },
    {
        "name": "social",
        "task": """使用 xfyun-search 技能搜索以下内容：
1. 搜索关键词："AI Agent 2024"
2. 提取前 10 条结果的标题、摘要和链接
3. 以结构化格式返回""",
        "label": "source-social"
    }
]

# 并行启动所有数据源抓取
for source in data_sources:
    sessions_spawn(
        task=source["task"],
        context="isolated",
        label=source["label"]
    )

# 等待所有数据源返回
sessions_yield("等待所有数据源抓取完成")

# 聚合代理：合并所有数据源结果生成报告
all_data = "\n\n".join([
    f"## {r.label}\n{r.output}" 
    for r in results if r.status == "succeeded"
])

sessions_spawn(
    task=f"""基于以下多源数据，生成一份市场调研报告：
1. 技术趋势总结（500 字）
2. 热门项目列表（表格形式）
3. 建议关注的方向（3-5 条）

原始数据：
{all_data}""",
    context="isolated",
    label="report-aggregation"
)

sessions_yield("等待报告生成完成")

9.4 代码解析

这个案例展示了 MapReduce 风格的编排模式：

Map 阶段：4 个子代理并行抓取不同数据源，每个子代理独立使用 web_fetch 或搜索技能
Reduce 阶段：所有 Map 结果汇总后，再派生一个聚合代理生成最终报告
isolated 模式贯穿始终：数据源之间无依赖，报告生成代理通过 task 参数获取所有数据
两阶段 yield：第一次等待 Map 完成，第二次等待 Reduce 完成，确保时序正确

🔗 关于 OpenClaw 的 web_fetch 工具和搜索技能，详见 docs.openclaw.ai/tools

十、实战案例3：任务链编排

10.1 场景描述

在某些复杂场景中，任务之间存在严格的依赖关系：分析 → 方案 → 实施 → 验证。每个环节的输出是下一个环节的输入，形成一条执行链。同时，某些环节内部可以并行化，形成"链内并行"的混合编排。

10.2 流程图

10.3 实现代码

# 任务链编排：需求 → 方案 → 实施 → 验证

# === 第一阶段：需求分析 ===
sessions_spawn(
    task=f"""分析以下软件需求，输出：
1. 功能点拆解（每个功能点一行）
2. 技术难点评估（高/中/低）
3. 预估工时（人天）

需求描述：{user_requirement}""",
    context="fork",  # 需要理解用户对话上下文
    label="phase-analyze"
)
sessions_yield("等待需求分析完成")

# 获取分析结果
analysis_result = get_result_by_label("phase-analyze")

# === 第二阶段：并行方案设计 ===
sessions_spawn(
    task=f"""基于以下需求分析，设计技术方案 A（偏重性能优化）：
{analysis_result}""",
    context="isolated",
    label="phase-plan-a"
)
sessions_spawn(
    task=f"""基于以下需求分析，设计技术方案 B（偏重开发效率）：
{analysis_result}""",
    context="isolated",
    label="phase-plan-b"
)
sessions_yield("等待方案设计完成")

# 获取两个方案
plan_a = get_result_by_label("phase-plan-a")
plan_b = get_result_by_label("phase-plan-b")

# === 第三阶段：方案评估与实施 ===
sessions_spawn(
    task=f"""评估以下两个技术方案，选择最优方案并给出实施步骤：

方案 A：
{plan_a}

方案 B：
{plan_b}""",
    context="isolated",
    label="phase-evaluate"
)
sessions_yield("等待方案评估完成")

eval_result = get_result_by_label("phase-evaluate")

sessions_spawn(
    task=f"""根据以下评估结果，输出详细的实施代码和配置：
{eval_result}""",
    context="isolated",
    label="phase-implement"
)
sessions_yield("等待实施完成")

# === 第四阶段：并行验证 ===
impl_result = get_result_by_label("phase-implement")

sessions_spawn(
    task=f"""为以下代码编写单元测试：
{impl_result}""",
    context="isolated",
    label="phase-unit-test"
)
sessions_spawn(
    task=f"""为以下代码编写集成测试方案：
{impl_result}""",
    context="isolated",
    label="phase-integration-test"
)
sessions_yield("等待验证完成")

10.4 代码解析

这个案例展示了任务链编排的三个核心模式：

串行关卡：每个阶段的 sessions_yield 形成一个同步关卡（barrier），确保前序阶段完成后才进入下一阶段
链内并行：方案设计、验证阶段内部的子代理并行执行，缩短链内耗时
fork 首节点：第一个子代理使用 fork 模式获取用户对话上下文，后续子代理均使用 isolated 模式并通过 task 参数传递前序结果
结果传递链：每个阶段的输出通过 get_result_by_label 提取，再作为下一个阶段的输入

10.5 与 Team 模式的关系

OpenClaw 还提供了更高级的 Team 模式（通过 team_provision 和 team_execute），适合需要长期存在的多角色团队。Team 模式在子代理之上增加了 Leader-Worker 架构、进度追踪和频道推送等能力：

维度	手动子代理编排	Team 模式
生命周期	临时，任务完成即销毁	持久，可复用
协调方式	主代理手动 yield	Leader 自动协调
进度追踪	手动管理	内置 todo.md 追踪
频道推送	需手动 message	Leader 自动推送
适用场景	一次性复杂任务	长期团队协作

🔗 关于 Team 模式的详细用法，请参考 docs.openclaw.ai/concepts/multi-agent

十一、最佳实践与性能调优

11.1 任务粒度设计

任务粒度直接影响子代理系统的效率。过细的粒度导致调度开销占比过高，过粗的粒度则失去并行优势。

建议粒度： 每个子代理的执行时间在 30 秒到 5 分钟之间。短于 30 秒的任务建议在主代理中直接执行，长于 5 分钟的任务考虑拆分为更小的子任务。

11.2 上下文传递最佳实践

场景	推荐模式	理由
批量翻译/摘要	isolated	任务独立，节省 token
基于对话的分支任务	fork	需要理解对话历史
多用户数据处理	isolated	安全隔离，防止信息泄露
代码审查/重构	fork	需要访问当前项目上下文
数据抓取+分析	isolated + task 参数	任务间通过结构化数据传递

11.3 并发数调优

根据不同场景调整并发数：

场景	推荐并发数	依据
API 限流严格（如 GPT-4）	2-3	避免触发速率限制
API 宽松（如本地模型）	5-10	充分利用计算资源
I/O 密集型（网络抓取）	5-8	等待时间可重叠
CPU 密集型（代码分析）	2-4	避免资源竞争
涉及文件写入	1-2	避免写入冲突

11.4 错误处理最佳实践

始终检查 status 字段：不要假设所有子代理都会成功
记录失败项：使用 label 映射回原始任务，方便重试
设置合理超时：根据任务复杂度设置 2-10 分钟的超时
实现降级策略：子代理失败时有备选方案
定期审计：使用 openclaw tasks audit 检查异常任务

11.5 监控与可观测性

# 查看所有子代理任务状态
openclaw tasks list --runtime subagent --json

# 检查是否有卡住的任务
openclaw tasks audit

# 查看特定子代理的执行日志
openclaw tasks show <task-id>

# 清理过期的任务记录
openclaw tasks maintenance --apply

十二、总结与展望

12.1 核心要点回顾

OpenClaw 的子代理系统为 AI Agent 的多任务编排提供了一套轻量而完整的解决方案：

核心能力	关键机制	核心价值
任务分发	`sessions_spawn`	灵活的并行/串行编排
上下文隔离	`fork` / `isolated`	按需共享或隔离上下文
结果回收	`sessions_yield` + 推式通知	零轮询开销的异步回调
资源管理	并发控制 + 自动清理	防止资源耗尽
错误恢复	多层策略 + 降级回退	保障任务最终完成

12.2 架构选型指南

根据你的具体需求，选择合适的编排层级：

简单并行：直接使用 sessions_spawn + sessions_yield
复杂流水线：组合串行关卡和并行分发
长期团队：使用 team_provision + team_execute 的 Team 模式
定时任务：结合 Cron 机制自动触发子代理

12.3 未来展望

子代理系统仍在持续演进中。未来可能的发展方向包括：

🔄 自动重试与容错：Gateway 层面的声明式重试策略，无需主代理手动处理
📊 子代理性能画像：自动记录每个子代理的执行时间和成功率，辅助并发数调优
🔗 跨 Gateway 子代理：支持分布式部署下的子代理调用，突破单机资源限制
🎯 优先级调度：高优先级任务抢占式调度，确保关键任务及时完成

🦞 OpenClaw 的子代理系统让 AI Agent 从"单兵作战"进化为"团队协作"。无论是批量内容生成、多源数据抓取，还是复杂的任务链编排，合理运用子代理机制都能显著提升执行效率和系统可靠性。动手试试吧——从一个小小的 sessions_spawn 开始，你会发现 AI Agent 的潜力远超想象。

参考资料：