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

安逸Ai大约 10 分钟Multi-AgentSub-Agent协作

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

这道题考的是多 Agent 系统的设计能力，既要理解为什么要用多 Agent，也要懂具体怎么实现。面试官想看你能不能说清楚"什么时候该分，什么时候该合"。

我从五个方面来讲：单个 Agent 的局限、多 Agent 的适用场景、OpenClaw 的 Sub-Agent 实现机制、父子 Agent 的通信协作、最后给个实战案例。

一、为什么单个 Agent 有时候不够用？

先说个场景。

你让一个客服 Agent 处理 100 个用户咨询，它只能一个一个来。这个用户问物流，那个用户问退款，都得排队等着。这就是单个 Agent 的核心问题：串行处理，效率有上限。

再比如这个场景：你让一个 Agent 写代码，同时还要它做代码审查。写代码需要creative mode，审查需要critical mode，两种思维模式混在一起，模型容易精神分裂。

单个 Agent 的局限主要在这几个地方：

并行处理需求。你有一批任务，它们之间没有依赖关系，但 Agent 只能一个个处理。100 个任务，每个 1 分钟，串行就是 100 分钟。如果拆成 10 个 Agent 并行处理，10 分钟搞定。

复杂任务分解。一个复杂任务包含多个子任务，每个子任务需要不同的能力。比如"做一个电商系统"，需要产品设计、技术架构、数据库设计、接口规范——这些拆给不同 Agent 做，比一个 Agent 从头做到尾效果好得多。

资源隔离。不同任务可能需要不同的模型、不同的工具、甚至不同的权限。一个 Agent 配一套能力，其他任务用不上，资源浪费。

稳定性考虑。一个 Agent 处理长任务，挂了就得重来。拆成多个子 Agent，每个任务短平快，挂了只影响一小块。

打个比方：

一个厨师做一桌菜，从洗菜切菜到炒菜装盘，全他一个人来。手忙脚乱，出品质量还不稳定。但如果分成洗菜组、切菜组、炒菜组，每个人专注自己的环节，效率和质量都上去了。

多 Agent 就是把"一个人干所有事"变成"一群人分工干"。

阅读全文

二、什么时候该用多 Agent？

不是所有场景都需要多 Agent。

简单、独立、不需要复杂判断的任务，一个 Agent 搞定就够了。比如"查一下今天北京的天气"，没必要搞出来 3 个 Agent 协同。

但下面这些场景，多 Agent 协作就很有必要：

任务能并行拆分。你有一堆文章要总结、一批合同要审核、一组数据要清洗——这些任务之间没有先后依赖，拆开并行处理，效率翻倍。

任务需要多角色分工。复杂业务通常涉及不同专业领域。一个法律 Agent 负责合同审查，一个财务 Agent 负责风险评估，一个技术 Agent 负责可行性分析——每个 Agent 做自己专业的事，汇总给主 Agent 决策。

需要隔离不同上下文。不同客户的对话、不同的项目数据，可能需要完全隔离的处理环境。子 Agent 拥有独立上下文，互不干扰。

后台批量处理。有些任务不需要实时响应，可以在后台跑。比如每天凌晨生成报表、分析用户行为数据——子 Agent 默默干活，结果上报给主 Agent。

成本和性能权衡。简单任务用小模型，复杂任务用大模型。不同子 Agent 可以配置不同能力的模型，平衡效果和成本。

举几个具体例子：

一个客服系统，可以拆成：意图识别 Agent（判断用户要什么）、知识库检索 Agent（查相关答案）、回复生成 Agent（组织语言）。三个 Agent 流水线作业，比一个 Agent 全包效果更好。

一个代码审查场景，可以拆成：代码扫描 Agent（静态分析）、安全检测 Agent（查漏洞）、性能分析 Agent（评估效率）。每个 Agent 输出自己的报告，主 Agent 汇总成最终审查意见。

三、OpenClaw 的 Sub-Agent 是怎么实现的？

说完了为什么需要多 Agent，再来看 OpenClaw 是怎么支持的。

核心机制：sessions_spawn 工具

父 Agent 可以通过 sessions_spawn 工具动态创建子 Agent。每个子 Agent 有自己的：

独立 session（隔离的对话上下文）
独立工具集（可以配置不同的能力）
独立模型配置（可以用不同的模型）

创建过程是这样的：

父 Agent 判断任务需要拆分
调用 sessions_spawn，指定子 Agent 的配置
OpenClaw 动态实例化一个新的 Agent
子 Agent 开始处理自己的任务
处理完成后，结果通过异步机制上报

ContextEngine 插件：生命周期管理

2026.3.7 版本引入的 ContextEngine 插件，提供了更精细的生命周期控制，靠两个 Hook：

on_subagent_start：子 Agent 启动时触发。可以用来注入上下文、初始化资源、或者做权限校验。比如主 Agent 把任务详情、用户信息、业务规则传给子 Agent。

on_subagent_end：子 Agent 结束时触发。可以用来收集结果、清理资源、或者做日志记录。比如子 Agent 把执行结果、耗时、状态上报给主 Agent。

这两个 Hook 就像是任务交接时的签到和签退——子 Agent 开始干活要报到，干完活要销假。保证任务有始有终，不会出现"派出去没人管"的情况。

类比理解：

父 Agent 像项目经理，子 Agent 是被派出去的专项小组。

项目经理（父 Agent）接到一个复杂项目，拆成几个子任务，通过公司的任务系统（sessions_spawn）派给不同的小组（子 Agent）。每个小组有自己的工作空间（独立 session）和工具（独立工具集）。

任务开始时（on_subagent_start），小组开个小会，领任务、领资源。任务结束时（on_subagent_end），小组开会总结，汇报成果、交接文档。

四、子 Agent 之间是怎么通信的？

多 Agent 协作，关键在于通信机制。

OpenClaw 采用的是异步通告机制。子 Agent 完成任务后，结果自动上报给父 Agent，不需要父 Agent 一直等着。

具体流程：

父 Agent 创建子 Agent，开始执行
父 Agent 可以继续处理其他请求，不阻塞
子 Agent 完成后，通过通告机制把结果推给父 Agent
父 Agent 收到结果后，继续后续处理

这种设计的好处：父 Agent 不会被某个慢子任务卡住，可以同时调度多个子任务，最大化吞吐量。

差异化配置：

不同子 Agent 可以配置不同的模型、超时时间、工具集。比如：

简单查询任务用小模型 fast
复杂分析任务用大模型 pro
敏感操作设置短超时，防止hang住

这种灵活性让你可以在性能和成本之间做trade-off。

父子通信的类比：

想象微信群里的任务分配。子 Agent 是群成员，主 Agent 是群主。群主把任务发到群里，各个成员领任务、执行、完成后在群里发结果汇报。群主不需要一直盯着谁在做啥，成员做完自然会报。

五、单 Agent vs 多 Agent，怎么选？

这个问题的本质是：架构复杂度要匹配业务复杂度。

简单任务用多 Agent，反而增加不必要的复杂度。一个任务本来 1 分钟能搞定，非要拆成 3 个 Agent 协作，光协调成本就 2 分钟，得不偿失。

复杂任务用单 Agent，效果和效率都会打折扣。一个 Agent 既要写代码、又要做测试、又要部署，手忙脚乱，不如拆开专业分工。

选择指南：

场景	推荐方案
简单独立任务，一次性搞定	单 Agent
任务可并行，互不依赖	多 Agent 并行
任务需要多角色/多能力	多 Agent 分工
需要隔离不同业务上下文	多 Agent 隔离
实时性要求高	单 Agent（减少通信开销）
后台批量处理	多 Agent 提效

一个判断标准：

问自己一个问题——"这个任务能不能自然地拆成几个独立的子任务？"

如果能拆分，且拆分后每个子任务有明确的边界和输入输出，那就适合多 Agent。如果拆分后耦合很高，子任务之间要频繁通信同步，那还不如一个 Agent 搞定。

架构设计的原则：

多 Agent 模式能显著提升系统吞吐量，但增加了架构复杂度。不是一个 Agent 包打天下，也不是上来就搞一堆 Agent。根据业务需求，从简单开始，逐步演进。

六、实战案例：龙虾场主模式

说个 OpenClaw 的典型应用场景——龙虾场主模式。

这个模式可以配置多个智能体同时运作，比如：

main Agent：主协调者，负责接收用户请求、分解任务、汇总结果
qihang Agent：专项能力 Agent，负责某个特定领域的任务
yanan Agent：另一个专项能力 Agent

每个 Agent 专注自己的任务领域，主 Agent 统筹协调。

类比理解：

就像一个创业公司。CEO（主 Agent）统筹协调，知道公司整体方向，接客户需求，拆解任务分给各部门。各部门负责人（子 Agent）专注自己领域——技术负责人管开发、产品负责人管需求、运营负责人管用户。各部门独立执行，定期汇报，CEO 做最终决策。

这种模式的好处：

专业的人做专业的事
可以独立扩展某个 Agent，不影响其他
隔离性好，不同业务线不会互相干扰

面试怎么答？

基础版

多 Agent 协作适用于三种场景：一是任务需要并行处理，比如批量处理一批数据；二是复杂任务需要分解，每个子任务需要不同能力或不同模型；三是需要隔离不同上下文，比如处理不同客户的请求。
OpenClaw 通过 sessions_spawn 工具创建 Sub-Agent，每个子 Agent 有独立的 session、上下文和工具集。ContextEngine 插件提供 on_subagent_start 和 on_subagent_end 两个 Hook 来管理生命周期。子 Agent 采用异步通告机制返回结果，不阻塞父 Agent。
关键点是：不是所有场景都需要多 Agent，简单任务单 Agent 就够了，多 Agent 会增加不必要的复杂度。

加分版

从架构设计角度看，动态实例化 + 上下文隔离是 OpenClaw 的核心设计理念。父 Agent 通过 sessions_spawn 动态创建子 Agent，每个子 Agent 可以配置不同的模型、工具集和超时策略，平衡效果和成本。
ContextEngine 的 Hook 机制保证了生命周期可控——on_subagent_start 做上下文注入和资源初始化，on_subagent_end 做结果收集和资源清理。这两个点也是扩展点，可以在上面做监控、审计、限流等能力。
我理解多 Agent 的核心价值在于吞吐量和专业化的trade-off。并行处理提升吞吐量，多角色分工提升效果，但增加了架构复杂度。要根据业务场景选择，不是非多 Agent 不可。
实际用过龙虾场主模式，配置过 main、qihang、yanan 多个智能体协作，确实比单 Agent 在处理复杂业务时效果更好。

一句话总结

多 Agent 协作解决的是并行性、专业分工和上下文隔离的问题，OpenClaw 通过 sessions_spawn 动态创建子 Agent，用 ContextEngine 的 Hook 管理生命周期，异步通告机制实现结果上报——本质是把"一个Agent干所有事"变成"一群Agent分工协作"。