面经策

什么场景下需要多 Agent 协作而不是单个 Agent 解决？OpenClaw 是怎么支持子 Agent（Subagent）的？ ​

  • 标签：AI、OpenClaw、大模型应用开发、AI应用开发、Agent开发

🏛 业务架构师 ​

什么时候需要多 Agent 协作而不是单 Agent？我的判断标准是三条，满足其一才考虑：

  1. 上下文隔离需求：子任务会产生海量中间结果（代码库全量搜索、长文档分析），单 Agent 上下文会被淹没——子 Agent 独立跑完只回传结论，主上下文保持干净；
  2. 专业分工需求：不同任务需要不同的 System Prompt、工具包、模型（写作 Agent 用强模型、检索 Agent 用快模型）——专业配置提升各环节质量；
  3. 并行加速需求：可拆分的子任务（多渠道数据采集、批量文件处理）并行执行，墙钟时间大幅缩短。

反过来说：任务单一、上下文可控、串行依赖强——单 Agent 更稳更省，多 Agent 只会引入通信开销和失败面。

OpenClaw 对 Subagent 的支持模式：主 Agent 运行中可 spawn 子 Agent——声明式指定子 Agent 的配置（系统提示、工具集、模型），子 Agent 拥有独立上下文和会话空间，完成任务后向父 Agent 回传结构化结果；父 Agent 可并行派发多个、等待聚合，子 Agent 的成本与日志独立计量。

落地经验：多 Agent 的真实难点在"编排与聚合"——结果怎么合并、冲突怎么裁决、失败怎么降级。我建议从"1 父 N 子、子不互动"的星型结构起步（最可控），网状自由协作等编排能力成熟后再上。多 Agent 是组织问题不是技术堆砌，架构要像设计团队分工一样设计它。

🏗 系统架构师 ​

判断标准：任务的子部分需要独立的上下文、专用工具集或并行执行时，上多 Agent。具体场景：

  • 上下文隔离：子任务的知识量大（研究 3 个竞品各要读 20 篇文档），塞进一个上下文会爆窗或互相干扰——子 Agent 各自持上下文，父级只收结论（MapReduce 模式）；
  • 专业分工：不同环节需要不同工具集/System Prompt（代码 Agent + 测试 Agent + 文档 Agent），单 Agent 的 Prompt 会膨胀成怪物；
  • 并行加速：独立子任务（抓取 10 个页面）并行执行，墙钟时间除以 N；
  • 权限隔离：子任务跑不可信代码/处理敏感数据，用受限权限的子 Agent 执行（最小权限原则）。

OpenClaw 的 Subagent 支持：父 Agent 可 spawn 子 Agent——声明式配置（专用 Prompt、工具子集、模型、资源预算），子 Agent 在受控边界内独立跑 Agent Loop，父级通过结果对象拿到结论（不是原始对话），异常与超时由父级接管处理。

代价提醒（别滥用）：子 Agent 不共享父级上下文，交接要显式传递（信息有损风险）；token 成本是单 Agent 的数倍；调试链路变深。我的纪律：顺序步骤能用工具解决就不拆 Agent，只在"上下文隔离/并行/权限边界"三要素出现时才拆。

💻 全栈开发专家 ​

什么时候多 Agent：任务可并行分头执行、需要专业分工、或需要上下文隔离。单 Agent 搞定的别上多 Agent（协调成本是真实的）。

适合多 Agent 的信号：任务能拆成独立子任务（并行调研 5 个主题）；不同步骤需要不同工具集/模型（研究用强模型、编码用代码模型）；上下文互相污染（A 的中间结果对 B 是噪声）；需要对抗校验（生成者+审查者）。

OpenClaw 支持子 Agent（Subagent）的方式：

  1. spawn 语义：父 Agent 通过工具调用（spawn_subagent）派生子 Agent，传入任务描述+可选的工具白名单，立即拿到句柄继续自己的工作（非阻塞）；
  2. 独立上下文：子 Agent 全新上下文窗口，只接收任务 brief，不继承父对话——这正是它的价值：父上下文不被子任务的海量中间结果污染；
  3. 结果回传：子 Agent 完成后产出摘要级报告（不是完整轨迹）回给父，父决定采纳/追问/重派；
  4. 编排模式：并发扇出（同时 spawn 多个再 collect）、串行流水（A 的产出是 B 的输入）、层级委派（子再派孙，有深度限制）。
父Agent("调研竞品定价")
 ├─ spawn(竞品A分析) ──┐
 ├─ spawn(竞品B分析) ──┼─ collect → 汇总报告
 └─ spawn(促销策略)   ──┘

关键约束：并发数上限（我们设 3~5）、子任务超时、失败只重派不无限递归、子 Agent 权限默认小于等于父（不能自我提权）。