单个 Agent 处理简单任务没什么问题，但遇到「先搜索资料、再分析、再写报告、最后发通知」这类多步骤任务，让一个 Agent 全包往往会出问题——上下文太长、步骤之间容易串、出错了也不好定位。OpenClaw 的 Sub-Agent 机制就是用来解决这个问题的。
openclaw的Sub-Agent 是怎么工作的
简单来说，主 Agent 把一个大任务拆成几个子任务，每个子任务交给一个独立的 Sub-Agent 去跑。Sub-Agent 跑完把结果返回给主 Agent，主 Agent 再汇总处理。每个 Sub-Agent 有自己独立的上下文，互不干扰。
这和人类团队分工的逻辑是一样的：一个项目经理统筹，下面几个专职的人各自负责一块，最后汇报结果。比一个人什么都做要可靠得多。
一个实际例子：每日竞品监控
假设你要每天监控 5 个竞品的官网更新、发布到飞书群。用单 Agent 的做法是：依次打开每个网站、记录变化、汇总、发飞书。一旦某个网站加载慢，整个流程就卡在那里。
用 Sub-Agent 的做法是：主 Agent 同时派出 5 个 Sub-Agent，每个只负责一个网站，并行抓取，全部完成后主 Agent 汇总。总时间等于最慢那个网站的加载时间，而不是 5 个网站的总和。
在 OpenClaw 里怎么配置
2026.3.7 引入 ContextEngine 插件化之后，Sub-Agent 的生命周期管理变得更可控。主要用到两个 hook：prepareSubagentSpawn（在子 Agent 启动前注入初始上下文）和 onSubagentEnded（子 Agent 结束后处理返回结果）。
最简单的方式是直接在 Skill 里描述任务拆分逻辑，OpenClaw 会根据描述自动决定是否启动 Sub-Agent。复杂场景可以用代码显式控制并发数量和超时。
几个注意点
Sub-Agent 并发跑起来爽，但要注意几个问题：并发数别设太高，OpenClaw 默认上限是 10，超了会排队；每个 Sub-Agent 都会消耗 Token，成本比单 Agent 高；Sub-Agent 之间不能直接通信，必须通过主 Agent 中转。
另外，Sub-Agent 的错误处理要单独考虑。某个子任务失败了，主 Agent 需要决定是重试、跳过还是整体中止，这个逻辑建议在 Skill 里写清楚，不要靠 Agent 自己判断。
适合用 Sub-Agent 的场景
需要并行处理多个同类任务（爬多个网站、处理多份文件）、任务步骤之间有明显边界且可以独立运行、单 Agent 上下文经常超限——这几种情况下上 Sub-Agent 收益最明显。如果只是简单的线性步骤，单 Agent 就够了，不用过度设计。