从一家外卖店说起
想象你开了一家外卖店，但只有你一个人。你既是老板，也是采购员、洗菜工、厨师、收银员、打包员、配送员。早上去买菜，回来洗菜切菜，刚开火炒菜，顾客吃完要收银，外卖平台又来单了赶紧打包，打包完还得自己送。送完回来，锅里的菜已经糊了。
问题不是你不够努力，而是一个人同时干太多事，迟早会乱。
这其实就是很多人用AI的真实状态。主Agent一会儿搜索资料，一会儿写内容，一会儿核对事实，一会儿改格式，还要记住前面说过的所有要求，全挤在一个会话里。任务一长，上下文一多，它就开始混乱、分心、漏东西。
那聪明的做法是什么？不是让老板更拼命，而是招人，把工作拆解后交给不同的专业角色分别执行：
- 主Agent（老板）：只负责统筹安排任务、验收结果
- 采购SubAgent：专门负责找供应商、比价格、下单补货
- 备菜SubAgent：负责洗菜、切菜、准备食材
- 烹饪SubAgent：专门负责炒菜、控制火候、保证出品
- 收银SubAgent：处理结账、核对订单、网上接单
- 打包SubAgent：分类、装盒、贴单
- 配送SubAgent：准时送达
每个人只做自己那一件事，谁也不会互相打扰。这就是SubAgent的核心逻辑——主Agent整理需求、拆解任务，然后分发给SubAgent去做，做完把结果拿回来验收。
SubAgent到底是什么
简单说，SubAgent是一个专门处理某类任务的子代理。它不是一个普通功能，也不是简单调用一下工具。它更像是主Agent把任务交给一个独立的小助手，这个小助手在自己的上下文里完成工作，然后把结果交回来。
每个子代理都有独立上下文、单独提示词、特定工具权限，用来处理特定任务。
所以可以这样理解：
- Skill相当于给同一个人配更好的工具
- SubAgent相当于给这个人又配了一个能独立完成子任务的助手
这两个不是一回事。
什么任务最适合用SubAgent
SubAgent不是万能的，它最适合那些可以拆开、可以分工、每一步相对独立的任务。
拿内容生产流程举个例子。你输入一个关键词，想自动生成一篇能发布的文章，这个过程可以拆成：
- 搜索资料——去网上找相关内容，收集信息
- 筛选资料——去重、过滤广告、挑出最有价值的内容
- 写初稿——根据筛选后的材料写文章
- 事实核查——检查数据、例子、表述是否准确
- 风格统一——让文章语气一致，读起来更顺
- 格式整理——统一标题、段落、列表、代码块
- 配图生成——做视觉部分
- 人工审阅润色——去AI味，检查是否通顺
这种任务最怕什么？最怕所有东西都堆在同一个上下文里。
假设信息源来自多个平台，每个平台搜索5篇文章，光搜索阶段上下文就很长了。搜索阶段带来一大堆杂乱信息，写作阶段又出现大量草稿，核查阶段还会不断修改。全塞给同一个主Agent，它的"脑子里全是噪音"。
换成SubAgent就不一样了。搜索的归搜索SubAgent，写作的归写作SubAgent，核查的归核查SubAgent，排版的归排版SubAgent。主Agent只看每一环的结果，不看中间产生的冗余过程。
总结一下，SubAgent最适合这些场景：
- 多步骤任务
- 流程型任务
- 每一步职责清晰的任务
- 中间过程没必要共享给主Agent的任务
- 可以并行推进的任务
比如代码审查、内容生产流水线、多语言翻译、资料搜索与整理、测试校验与格式统一、长流程自动化任务。
一句话：越复杂、越能拆分、越容易被上下文污染的任务，越适合交给SubAgent。
SubAgent的优势
上下文更干净——这是SubAgent最核心的价值。每个子代理都有自己的独立上下文。搜索时产生的噪音不会污染写作，写作时的草稿不会干扰核查，核查发现的问题也不会把前面的上下文搅乱。主Agent看到的，始终是整理过的结果。就像老板不需要盯着后厨切了多少根葱，他只需要知道菜做好没有、能不能上桌。
更专注，结果更稳——一个Agent同时做五件事，和一个Agent只做一件事，效果通常完全不一样。专门找资料的SubAgent更像研究员，专门写作的SubAgent更像作者，专门核查的SubAgent更像审稿人。因为各自不会分心，质量通常更稳定。
可以并行——有些任务没必要排队一个个做。比如A在查资料，B在准备提纲，C在整理参考格式，几个SubAgent同时动起来，速度快很多。
可复用——一旦写好了一个好用的SubAgent，比如"文章审查员""事实核查员""排版整理员"，以后可以一直复用。它不像临时写提示词，更像你已经招好了一个老员工，下次直接派活就行。
能处理更复杂的任务——很多复杂任务不是AI做不了，而是一个Agent装不下。当任务长度、步骤、信息量都上来后，SubAgent往往是突破复杂度上限的办法。
SubAgent的局限
不过SubAgent也不是万能的，有几个需要注意的点：
配置有门槛——你要告诉它负责什么、什么情况下调用、能用哪些工具、最后要交付什么结果。这些写得不清楚，它就容易跑偏。
信息交接可能丢细节——SubAgent和主Agent之间通常传递"任务说明"和"结果摘要"。这很高效，但有些关键细节可能在交接过程中被压缩掉。隔离上下文是优点，信息压缩也是风险。
调试更麻烦——如果最后结果有问题，你需要逐环排查：是搜索拿错了资料？还是写作理解错了方向？还是核查漏掉了问题？还是排版阶段处理坏了？链条越长，定位问题越复杂。
小任务不值得用——如果只是改一句话、润一小段文案、改个标题，直接让主Agent做更快。为了煮一碗泡面专门设采购、厨师、配送三个岗位，明显过度了。
Skill和SubAgent怎么选
这是接触SubAgent后最常被问到的问题。答案很简单：它们解决的不是同一个问题。
Skill解决的是能力问题——让主Agent学会一项新本事。格式检查、固定模板生成、文档整理、规范输出，这些都是给主Agent直接加能力。适合轻量、规则明确、过程不复杂、需要主Agent一直掌握上下文的任务。Skill更像给同一个人配上一把更顺手的工具。
SubAgent解决的是分工问题——把某一整块任务外包给独立专业的角色去做。适合重型任务、多步骤任务、中间过程很长、不适合把所有信息都堆在主上下文里的任务。SubAgent更像直接把这项工作交给一个专门的人。
判断标准也很直觉：
用Skill——当你想的是"我希望主Agent多会一个能力""这件事不复杂""过程我希望它一直知道""我不想多一层调度"。
用SubAgent——当你想的是"这事能不能单独拆出去做""这一步不该污染主上下文""最好由一个专门角色来处理""中间过程很长，但最终只要结果"。
而现实中最好的方案，往往不是二选一，而是混合使用：主Agent负责整体协调，轻量规则能力交给Skill，重型独立任务交给SubAgent。Skill负责补能力，SubAgent负责分工执行子任务，两者是搭档关系，不是竞争关系。
各工具中的SubAgent支持
目前SubAgent的概念已经在多个主流AI开发工具中落地。OpenClaw支持Sub-Agents，甚至还有ACP Agents的玩法。Claude Code和Codex中也都支持SubAgent，只是使用方式不同。你甚至可以用Claude Code来规划任务，然后让Codex来执行——跨工具协作的可能性很多。
回到最根本的一点：真正成熟的AI工作方式，不是让一个Agent拼命干活，而是让它学会把合适的工作交给合适的角色。会做事很重要，但会分工，才是走向高级玩法的关键一步。
那么问题来了——你手头现在最复杂的那个AI工作流，哪些环节其实已经可以拆给SubAgent了？