OpenClaw 的 Sub-Agent 架构是一种 主从式（Master-Slave）多 Agent 协作模式，其核心思想是将复杂的单线程任务拆解为多个可并行执行的子任务，由主 Agent（Master Agent）统一调度，多个子 Agent（Sub-Agent）各自独立执行，最终将结果汇聚回主 Agent 进行整合输出。
sessions_spawn 工具创建和管理子 Agent 的生命周期。| 优势 | 说明 |
|---|---|
| 并行加速 | 多个子 Agent 可以同时执行，充分利用 API 并发能力，将整体耗时从串行的 T 缩短至接近 max(T1, T2, ..., Tn) |
| 上下文隔离 | 每个子 Agent 拥有独立的上下文窗口，避免跨领域信息相互干扰，减少幻觉 |
| 专注力提升 | 子 Agent 只需关注单一子任务，Prompt 更加聚焦，输出质量更高 |
| 可扩展性 | 新的子任务类型可以通过定义新的 Sub-Agent 模板轻松加入 |
| 容错性 | 单个子 Agent 失败不影响其他子 Agent 的执行结果 |
sessions_spawn 是 OpenClaw 中实现 Sub-Agent 创建的核心工具。它负责在主 Agent 的会话中动态派生出全新的子 Agent 会话，并为每个子会话注入独立的系统提示词（System Prompt）和执行目标。
| 参数 | 类型 | 必需 | 说明 |
|---|---|---|---|
task | string | 是 | 子任务的描述，主 Agent 用于追踪和记录本次派生子任务的用途 |
prompt | string | 是 | 子 Agent 的系统级指令，定义了子 Agent 的身份、行为准则和执行目标 |
subagent_name | string | 否 | 子 Agent 的名称标识，便于在结果返回时识别来源 |
prompt 参数的质量直接决定子 Agent 的输出质量。建议在 prompt 中明确指定：子 Agent 的角色身份、需要完成的具体任务、输出格式要求（如 Markdown 结构）、输出长度限制、以及是否需要返回特定数据结构。
sessions_spawn 工具调用。prompt 参数作为系统提示词注入新会话。OpenClaw 的子 Agent 采用 推送式（Push-based）结果返回机制。与传统的请求-响应（Request-Response）模式不同，子 Agent 在完成任务后主动将结果推送给主 Agent，主 Agent 无需轮询等待。
| 特性 | 推送式（OpenClaw） | 拉取式（传统） |
|---|---|---|
| 实时性 | 高，子 Agent 完成即通知 | 中，取决于轮询间隔 |
| 资源消耗 | 低，无需持续轮询 | 高，需要周期性检查状态 |
| 实现复杂度 | 低，框架自动处理 | 中，需自行实现轮询逻辑 |
| 可扩展性 | 高，适合大量子 Agent | 中，轮询开销随数量增加 |
主 Agent 在接收到所有子 Agent 的推送结果后，需要执行结果聚合（Aggregation）。常见的聚合策略包括：
steer 是 OpenClaw 中用于 会话重定向 的重要工具。它允许在多个子 Agent 会话之间进行流转控制，将一个会话的上下文或执行权转移给另一个会话。
主 Agent 使用 steer 将任务上下文传递给特定的子 Agent，子 Agent 在此基础上继续执行。
子 Agent 完成工作后，使用 steer 将执行权交还给主 Agent，同时携带执行结果。
两者的核心区别在于：sessions_spawn 用于创建新的子 Agent 会话，而 steer 用于在已有的会话之间进行流转。通常的组合用法是：先用 sessions_spawn 创建子 Agent，再通过 steer 管理后续的交互流程。
在复杂的工作流中，可以在多个子 Agent 之间建立链式流转：
这种链式模式适用于需要多阶段流水线处理的场景，如：数据采集 -> 数据清洗 -> 数据分析 -> 报告生成。
并行任务分解是 Sub-Agent 架构中最关键的环节。合理地将任务分解为可并行执行的子任务，直接决定了系统的效率和输出质量。
适用于长文档生成，将文档按章节或模块切分，每个子 Agent 负责一个章节。
适用于多源信息检索与整合，每个子 Agent 负责查询和分析一个独立数据源。
适用于多维度分析，每个子 Agent 从不同角度分析同一组数据。
| 特性 | 静态分解 | 动态分解 |
|---|---|---|
| 分解时机 | 在发起子 Agent 前一次性完成 | 根据中间结果逐步调整 |
| 灵活性 | 低，分解方案固定 | 高，可根据实际情况调整 |
| 适用场景 | 任务结构清晰、可预见性强 | 任务不确定性高、需探索性执行 |
| 实现复杂度 | 低 | 高（需要反馈循环） |
在实际应用中，推荐采用 半动态分解 策略：主 Agent 先进行初步的静态分解，执行过程中根据子 Agent 返回的中间结果动态调整后续分解方案。
本章通过一个完整的实际案例——"AI 芯片行业市场分析报告"的生成过程，展示 Sub-Agent 架构如何在实际场景中落地。
目标：生成一份涵盖 AI 芯片行业概况、市场规模、竞争格局、技术趋势和投资建议的完整市场分析报告。
预计输出：约 8000-10000 字的中文专业报告。
+------------------+
| 主 Agent (Master) |
| (统筹 & 整合) |
+--------+---------+
|
+--------------+--------------+
| | |
v v v
+-----------+ +-----------+ +-----------+
| Sub-Agent | | Sub-Agent | | Sub-Agent |
| 行业概况 | | 市场规模 | | 竞争格局 |
+-----------+ +-----------+ +-----------+
| | |
v v v
+-----------+ +-----------+ +-----------+
| Sub-Agent | | Sub-Agent | | Sub-Agent |
| 技术趋势 | | 投资建议 | | 风险提示 |
+-----------+ +-----------+ +-----------+
sessions_spawn 并行创建 6 个子 Agent子 Agent "竞争格局" 的 Prompt 设计：
你是一位资深的 AI 芯片行业分析师，专注于竞争格局分析。请基于你的知识，撰写一份关于 AI 芯片行业竞争格局的详细分析，内容包括：1) 主要市场参与者（NVIDIA、AMD、Intel、华为、寒武纪等）的市场份额和定位；2) 各厂商的核心竞争优势；3) 新兴创业公司的突破方向；4) 竞争格局的未来演变趋势。请使用专业客观的语气，引用具体数据（可标注估计值），篇幅约 1500 字，使用 Markdown 格式输出。
| 指标 | 单 Agent（串行） | 多 Sub-Agent（并行） | 提升 |
|---|---|---|---|
| 总执行时间 | ~12 分钟 | ~3 分钟 | 4x 加速 |
| 上下文 Token 消耗 | ~80K tokens（单次长上下文） | ~60K tokens（6 * 10K 独立上下文） | 减少 25% |
| 各章节质量评分 | 6.5/10（长上下文后期质量下降） | 8.5/10（每个子 Agent 专注单一章节） | +30% |
| 内容重复度 | 中高（跨章节引用同一信息） | 低（上下文隔离） | 显著改善 |
本案例展示了 Sub-Agent 架构在真实复杂任务中的显著优势。最关键的成功因素是：合理的任务分解粒度（6 个子 Agent 恰好覆盖所有章节）和高质量的 Sub-Agent Prompt 设计（明确角色、任务、格式要求）。
Sub-Agent 架构虽然带来了并行加速的好处，但也引入了额外的资源开销。合理的性能与资源管理是确保系统稳定高效运行的前提。
总 Token 消耗 = 主 Agent Token + Σ(各子 Agent Token)。需要关注以下方面：
| 参数 | 说明 | 推荐值 |
|---|---|---|
| max_concurrency | 同时运行的子 Agent 最大数量 | 5-10（取决于 API Rate Limit） |
| rate_limit_rpm | 每分钟 API 请求数限制 | 根据 API 提供方设定 |
| rate_limit_tpm | 每分钟 Token 消耗限制 | 根据 API 提供方设定 |
| retry_max_attempts | 失败重试最大次数 | 2-3 |
| timeout_per_agent | 单个子 Agent 超时时间 | 120-300 秒 |
并发数并非越高越好。过高的并发可能导致 API Rate Limit 触发、Token 配额快速耗尽、以及结果质量下降。建议从较低的并发数开始（如 3-5），根据实际运行情况逐步调优。
在生产环境中运行 Sub-Agent 架构时，建议监控以下关键指标：
对于耗时特别长的子 Agent（如需要多次工具调用的），可以考虑将嵌套工具调用也优化为并行模式，或提前拆分更细粒度的子任务。
prompt 参数设计质量直接决定子 Agent 的执行效果。好的 Prompt = 清晰的角色 + 明确的任务 + 具体的格式要求。