任务能并行拆解、各子任务需要独立上下文或不同模型、或者要隔离权限时，多 Agent 协作优于单个 Agent。OpenClaw 通过子 Agent（subagent）支持这套：主 Agent 用 sessions_spawn 派发任务，子 Agent 在独立会话里跑，完成后经 announce 链把结果回传，默认最多 8 个并发。
一、单 Agent 的瓶颈在哪
单个 Agent 的所有推理共享一个上下文窗口。任务一长，历史记录挤占空间；子任务之间状态互相干扰，一个失败拖垮整条链路；工具权限只能一刀切。任务又大又串时这些问题不明显，一旦要并行、要隔离、要专用模型，单 Agent 就吃力了。
二、什么场景值得换多 Agent
| 场景 | 单 Agent 为什么不够 | 协作模式 |
|---|---|---|
| 并行调研 | 依次查资料，慢且上下文膨胀 | 多个子 Agent 各查一个方向 |
| 研写流水线 | 角色混杂，提示词互相污染 | 研究→写作→校验按阶段分工 |
| 编排器模式 | 任务层级深，单 Agent 上下文爆掉 | 主→协调子 Agent→工作子 Agent |
| 竞争式生成 | 无法对比多个方案 | 多份输出同时跑，择优 |
OpenClaw 官方文档把嵌套模式叫 orchestrator 模式：主 Agent → 协调子 Agent → 工作子子 Agent，每层只看到直接子级的 announce。
三、判断清单
按顺序过一遍，命中两条以上再上多 Agent：
- 任务能不能拆成互不依赖的块？能拆才有并行收益；
- 各块是否需要不同模型或不同上下文？模型路由才有价值；
- 是否需要权限隔离？子 Agent 工具被裁剪，能防越权；
- 串行做完的耗时是否不可接受？
- 编排、监控、失败重试的维护成本，值不值。
四、OpenClaw 的子 Agent 支持
4.1 派发与命令
子 Agent 在独立会话运行，不阻塞主 Agent，控制台命令齐全：
# 启动子 Agent
/subagents spawn <agentId> <任务描述>
# 查看运行中的子 Agent
/subagents list
# 查看某个子 Agent 的日志
/subagents log <id>
# 引导方向
/subagents steer <id> <消息>
# 终止
/subagents kill <id|all>sessions_spawn 永远非阻塞，立即返回 { status: “accepted”, runId, childSessionKey }。
4.2 结果回传：announce 链
子 Agent 完成后通过 announce 把结果逐级上传。深度 2 的工作者先向深度 1 的协调者宣告，协调者综合后向主 Agent 宣告，主 Agent 投递给用户。每层只能看到直接子级的 announce。sessions_send 对子 Agent 默认禁用，通信只走这条链。
4.3 常用配置
{
agents: {
defaults: {
subagents: {
maxSpawnDepth: 2, // 允许一层嵌套（默认 1，范围 1-5）
maxChildrenPerAgent: 5, // 每个 Agent 最多 5 个活跃子级
maxConcurrent: 8, // 全局并发上限
runTimeoutSeconds: 900, // 单次运行超时
announceTimeoutMs: 120000
}
}
}
}4.4 落地套路
独立工作优先用 isolated 上下文（干净 transcript，省 token），依赖当前对话再用 fork。子 Agent 之间不直接通信，要协作时用共享工作区文件：调研子 Agent 把结果写 workspace/research-data.json，写作子 Agent 读它产出草稿，校验子 Agent 对照核实。工作区当共享内存，同时保住隔离。
常见问题（FAQ）
Q1：怎么判断任务要不要拆子 Agent？
先问能否并行拆解、是否需要隔离与专用模型，命中两条再拆。
Q2：子 Agent 之间能直接对话吗？
默认不行，结果只走 announce 链，协作靠共享文件。
Q3：子 Agent 用哪个模型？
可在 subagents.model 配置默认模型，spawn 时也可按需指定。
