什么场景下需要多 Agent 协作而不是单个 Agent 解决？OpenClaw 是怎么支持子 Agent（Subagent）的？
参考答案
多 Agent 协作的核心判断标准是：单个 Agent 搞不定的时候（不是废话）。就像一个人干不完的活，你需要组一个团队分工协作。
具体来看，有三种典型场景：
1）任务天然可以拆成并行的独立子任务。比如你要做一次竞品分析，需要同时去搜 Google、GitHub、Twitter 三个信息源，一个 Agent 一个个串行去搜太慢了，开三个 Agent 并行抓取，效率直接翻倍。
2）不同子任务需要不同的模型、工具、权限配置。比如一个子任务需要调 GPT-4o 做推理，另一个需要用 Claude 写代码，还有一个只需要调搜索 API。单个 Agent 想同时搞定这些配置差异很大的任务，prompt 会变得又臭又长，不如拆开各管各的。
3）单个 Agent 的 context window 装不下所有信息。一个 128K 上下文的模型，如果你往里面塞 10 份文档让它做综合分析，context 早就爆了。用多 Agent 做分治，每个 Agent 只处理一部分数据，最后汇总结果，才是高效做法。
OpenClaw 的子 Agent 支持可以用”派活 → 干活 → 交差”三步来理解：
第一步：派活（创建子 Agent）。父 Agent 通过 sessions_spawn（创建/派生）工具发起创建，就像经理在项目管理工具里给下属建了一张任务卡。系统会给子 Agent 分配一个独立的 session（可以理解为独立的工作空间），子 Agent 在自己的空间里干活，跟父 Agent 完全隔离，互不阻塞。同时系统会确保子 Agent 不会直接给用户发消息，它只对父 Agent 汇报，用户感知不到后台有多个 Agent 在并行工作。
第二步：干活（独立执行）。子 Agent 拿到任务描述后，在自己的 session 里独立完成工作。它有自己的工具集、模型配置，甚至可以指定用不同的 LLM。父 Agent 创建完子 Agent 后不用轮询等待，可以继续处理其他事情或者再派更多子任务。
第三步：交差（结果回传）。子 Agent 执行完毕后，系统通过 Announce 机制 自动把结果推送回父 Agent 的 session，就像下属完成任务后自动在群里 @了经理。这是推模式（push-based），不是拉模式。也就是父 Agent 不需要反复去问”你做完了没有”。并且为了防止网络抖动导致重复通知，每次回传都带一个唯一的幂等 key，同一个结果不会被处理两次。
扩展知识
子 Agent 的两种运行模式
子 Agent 创建时可以指定两种 mode：
1）run 模式，执行完任务就自动结束，适合一次性的计算或查询任务。比如让子 Agent 去搜一条信息，搜完返回结果就销毁。
2）session 模式，任务完成后子 Agent 不销毁，保持会话状态。父 Agent 后续可以通过 /subagents send 继续给它发消息、追加指令。这种模式适合需要多轮交互的复杂任务，比如让子 Agent 持续监控某个数据源。
Orchestrator 编排模式
默认情况下 maxSpawnDepth = 1，也就是子 Agent 不能再创建自己的子 Agent，只有一层。
如果把 maxSpawnDepth 设成 2，就变成了经典的”编排者 + 工人”两级架构。编排者 Agent 负责拆解任务、分配工作，spawn 出多个工人 Agent 并行处理不同的子任务，最后编排者汇总所有工人的结果。
这种模式在需要处理大量并行子任务的场景下特别有用。比如要对 50 个 GitHub 仓库做代码审查，编排者 Agent 把仓库列表拆成 10 组，spawn 10 个工人 Agent 各自处理 5 个仓库，最后编排者收集所有审查报告做汇总。
子 Agent 管理命令
OpenClaw 提供了一套斜杠命令来管理运行中的子 Agent：
1）/subagents list 查看当前所有活跃的子 Agent 及其状态
2）/subagents kill 终止指定的子 Agent
3）/subagents send 给某个 session 模式的子 Agent 发送新消息
4）/subagents steer 重定向子 Agent 的任务，相当于给它换一个新的指令
这套管理机制让父 Agent 对子 Agent 有完整的生命周期控制能力，不会出现子 Agent 跑飞了没人管的情况。
与其他多 Agent 框架的对比
OpenClaw 的多 Agent 方案走的是轻量级路线，核心就是 spawn + announce 两个原语，没有搞复杂的消息总线或者共享状态。
跟 AutoGen 那种多 Agent 对话框架比，OpenClaw 更偏向”主从”模式，父 Agent 有绝对的控制权。
跟 CrewAI 的角色化 Agent 比，OpenClaw 没有预定义角色的概念，子 Agent 的能力完全由创建时传入的 prompt 和工具集决定，灵活度更高但也需要调用方自己设计好任务拆分策略。
面试官追问
提问：子 Agent 的 session 跟父 Agent 完全隔离，那如果子 Agent 执行过程中需要访问父 Agent context 里的信息怎么办？
回答：创建子 Agent 的时候，父 Agent 需要把必要的上下文信息通过 prompt 传过去。这是有意为之的设计，强制做信息的显式传递而不是共享内存。好处是子 Agent 不会意外读到父 Agent 的敏感信息，坏处是如果要传的上下文太多，prompt 会比较臃肿。实际使用中一般会把关键的摘要信息传过去，而不是原始数据。
提问：如果子 Agent 执行失败了，父 Agent 怎么知道？有没有重试机制？
回答：子 Agent 失败后，announce 机制依然会触发，只不过返回的内容是错误信息而不是正常结果。父 Agent 拿到错误信息后可以自行决定怎么处理，比如重新 spawn 一个子 Agent 重试，或者换个策略。OpenClaw 本身没有内置自动重试机制，这个逻辑交给了父 Agent 在 prompt 层面去处理，保持了框架的简洁性。
提问：多个子 Agent 并行执行时，怎么控制并发数量，防止资源打满？
回答：靠的是 subagent lane 做资源隔离。lane 本质上就是一个并发控制的槽位，同一个 lane 里的任务共享资源配额。如果 lane 的容量设成 5，那最多同时跑 5 个子 Agent，后面的排队等。再加上 maxSpawnDepth 限制嵌套深度，两者配合基本能防住子 Agent 无限扩散把系统资源吃光的问题。
提问：你觉得 OpenClaw 的 spawn + announce 这种模式，跟消息队列驱动的多 Agent 方案比，各有什么优劣？
回答：spawn + announce 的优势是简单直接，父 Agent spawn 一个子 Agent 就跟调函数差不多，不需要额外部署消息队列中间件，开发调试都很方便。劣势是扩展性有限，所有子 Agent 都跑在同一个进程或服务实例里，没法做跨机器的分布式调度。消息队列方案正好反过来，天然支持分布式、可以做持久化和重放，但复杂度高得多，光是 Agent 之间的消息协议设计就够折腾一阵的。小规模场景用 OpenClaw 这种轻量方案完全够用，上了规模再考虑引入消息队列做解耦。