分身有术：一文读懂大模型里的 Sub Agent 机制

Sub Agent 直译是「子智能体」但你完全可以把它想象成主智能体雇来的临时工或者专科医生。当主智能体遇到一件适合外包的事——比如「把整个代码库摸一遍」「跑一轮对抗性的代码审查」「把这十个互不相干的小修改并行做掉」——它就召唤出一个子智能体来专门干这件事。前言你有没有过这种体验让 AI 帮你改一个复杂的项目它先翻了几十个文件、跑了一堆测试、又顺手查了三份文档等真正要动手写代码时前面那些七零八碎的搜索结果、报错日志、半截思路已经把对话塞得满满当当。结果就是——它越聊越「上头」越聊越容易忘记你最初到底想要什么。这在业内有个挺形象的说法叫「上下文污染」context pollution更狠一点的叫「上下文腐烂」context rot。大模型的上下文窗口再大也是有边界的。把所有杂活都堆在同一个对话里就像让一个人一边开重要的战略会一边还要在同一张桌子上拆快递、对账单、回消息——桌子很快就乱成一锅粥。于是大牛们想到了一个特别朴素、又特别管用的点子与其让「主脑」事必躬亲不如让它学会「分身」把脏活累活外包出去。这就是我们今天要聊的主角——Sub Agent子智能体机制。脏活外包主线清爽过程留在泡泡里主脑只看结论一、到底什么是 Sub AgentSub Agent 直译是「子智能体」但你完全可以把它想象成主智能体雇来的临时工或者专科医生。当主智能体遇到一件适合外包的事——比如「把整个代码库摸一遍」「跑一轮对抗性的代码审查」「把这十个互不相干的小修改并行做掉」——它就召唤出一个子智能体来专门干这件事。这个子智能体是一个完全独立的实例有自己独立的对话循环、自己的工具集、自己的权限边界甚至有自己专属的「人设」系统提示。它干完活把结果交回来主智能体只看到最终产出看不到它内部那些抓耳挠腮的推理过程。这套机制最关键的三个特性拆开来其实特别好懂第一上下文是隔离的。每个子智能体启动时都是一张「干净的白纸」——它看不到主对话此前的聊天记录也不知道主智能体刚才读过哪些文件。主智能体唯一能塞给它的就是召唤它时写的那段任务说明。所以一个好用的派活姿势是把文件路径、报错信息、关键决定都直接写进任务里别指望子智能体「心有灵犀」。也正因为隔离子智能体那边再怎么翻江倒海、堆满日志都不会弄脏主线。第二工具和权限是定制的。子智能体可以只拿到它这趟任务真正需要的工具权限也能单独收紧。让一个「只读探索」的子智能体老老实实只读不写既安全又省心。第三只交回结论。这是整套机制的精髓。子智能体在自己的上下文窗口里把搜索、试错、验证全部消化掉最后只把一段「总结」吐回给主智能体。噪音留在原地主线保持清爽——这就是为什么用了子智能体主对话能「越聊越清醒」而不是「越聊越糊涂」。顺带提一个有意思的变体fork分叉。普通子智能体是白纸出生而 fork 出来的子智能体会继承主对话的全部上下文——同样的系统提示、同样的工具、同样的历史记录。它牺牲了「输入隔离」换来的是「不用重新解释背景」特别适合那种「要讲清楚来龙去脉太费劲」的支线任务或者想从同一个起点并行尝试好几种方案的场景。但即便是 fork它自己的那些工具调用依然不会回灌进主对话最后还是只把结论带回来。二、拆开看从架构上讲子智能体机制其实是一套「主—从」结构。主智能体是指挥官子智能体是专业工兵。这套结构往上能长出各种花样最简单的是「一个主管 几个工人」复杂一点能搭成「协调者—工人」的层级团队再往上甚至能组织起多智能体的「蜂群」协作。但万变不离其宗每一个子智能体的生命周期都遵循一条清清楚楚的流水线。我们可以把它想象成一个临时工的一天第一步「派生」——主智能体发现有活儿适合外包按下召唤开关一个新的子智能体诞生。第二步「装备」——系统给这个新人配齐三样东西一个全新空白的上下文我补充一下这里说的不严谨实际上应该是 sub agent在启动的那一刻它会拿到一份main agent的一份context快照而且这个快照并不一定是完全继承而可能是摘要继承。之后 main agent 的 context有变化时 sub agent是感知不到的相当于起始时继承了一下 main agent的上下文、一套带权限锁的专属工具箱、一顶写着角色名的「人设帽子」。第三步「干活」——子智能体在自己的小泡泡里埋头苦干搜索、读文件、跑命令、反复试错过程要多乱有多乱反正外面看不见。第四步「交付」——活干完了它把一张「结论摘要」递回给主智能体。第五步「回收」——泡泡收起资源清理干净任务彻底结束。这套生命周期还藏着两个让它特别强大的「隐藏属性」。一是可并行既然每个子智能体都是独立小泡泡那就可以同时开好几个——一个去审计登录流程一个去梳理出错的测试一个去追踪数据库调用链主智能体在中间稳稳地当「拍板的人」整体效率自然水涨船高。二是可嵌套与可追溯子智能体在某些实现里还能再召唤自己的子智能体当然有深度上限免得无限套娃同时它的完整工作记录会被单独存档事后可以回放、可以追溯这对调试和复盘特别友好。一个子智能体的一生派生 → 装备 → 干活 → 交付 → 回收三、什么时候该叫上「分身」子智能体虽好可不是「凡事都喊一帮人来」就显得高级。它真正发光的场景有一个共同特征这件事能被干净地切成互不打架的小块而且大多是「读得多、写得少」的活。最典型的四类一是代码库探索——满世界找定义、理调用关系这种会产生海量中间结果却又不需要回头反复看的活扔给子智能体最合适二是并行调研——同一个问题从几个角度同时挖谁先挖到算谁的三是独立审查——专门派一个「唱反调」的子智能体来挑刺、找漏测、做安全检查因为它视角独立反而更容易发现主线里被惯性忽略的问题四是大批量同质任务——比如几十个长得差不多的小工单一个子智能体处理一行处理完统一汇总。反过来说有两种情况要悠着点。一是写操作密集的并行好几个子智能体同时改代码很容易互相踩脚、产生冲突这种「需要协调」的活就别盲目并行了。二是本来就很轻、很线性的任务召唤子智能体本身是有开销的杀鸡用牛刀只会更慢更贵。说白了子智能体不是「免费的超能力」它把工程里的「任务拆解与协调」这件事原封不动地搬到了你写提示词的那一刻——你拆得越干净分身们带回来的东西就越有用拆不干净那就是收获一堆更同步的噪音而已。四、Claude Code 是怎么玩的在 Claude Code 里子智能体是一等公民而且玩得相当「自动化」。它的入口是一个叫 Agent 的工具当主模型判断某件事值得委派它就调用这个工具背后由一段约四百行、被称作 runAgent() 的生命周期函数接管从创建、权限过滤、工具解析一直到最后的清理每个子智能体都走这同一条流水线。最妙的是「自动判断」——你甚至不用预先定义任何角色Claude 也会在合适的时候自己召唤一个内置的「通用型」general-purpose子智能体去做调研或探索。如果你想要专属的「专科助手」做法也很轻量在 .claude/agents/ 目录下放一个 Markdown 文件开头用一段 YAML 写明这个角色叫什么、擅长干什么、能用哪些工具、有什么权限正文就是给它的系统提示。当主智能体遇到匹配描述的任务就会自动把活派给对应的角色。前面提到的 fork 也在这里当一个具名角色需要太多背景才能开工时直接 fork 一份带着完整上下文的分身往往更省事还能复用已经缓存的提示片段、更省钱。它还有几个值得一提的细节。会嵌套从 Claude Code v2.1.172 起子智能体可以再生子智能体但有深度上限大约到第五层就不让再往下生了防止无限套娃。可追溯、可恢复每个子智能体的完整对话会被存成独立的 JSONL 记录文件事后能凭它的 agentId 回放甚至恢复会话。有更重的「升级版」如果你要协调的不是几个、而是几十上百个智能体官方建议改用 Workflow 工具把编排逻辑搬到一段脚本里由运行时执行而不是硬塞进逐回合的对话里。五、Codex 又是怎么玩的OpenAI 的 Codex 在 2026 年 3 月 16 日正式向所有开发者开放了子智能体App 和命令行都能用。它的设计哲学和 Claude Code 有一处很关键的不同Codex 不会自作主张地分身。它只在你明确开口时才召唤子智能体——你得说出「派两个 agent」「这块并行处理」「一个要点一个 agent」之类的话它才动手。官方把这点讲得很直白子智能体不是更省它们各自要跑模型、用工具反而比单个 agent 更费 token。所以要不要分身决定权牢牢攥在你手里。配置上Codex 走的是 TOML 路线在 .codex/agents/ 里定义自定义角色可以单独指定模型、沙箱模式、MCP 工具、技能配置等没写的字段就从父会话继承。并发与深度则在 config.toml 的 [agents] 段里管控两个默认值很值得记住max_threads 默认 6也就是最多同时开 6 个 agent 线程max_depth 默认 1意思是允许直接的子 agent但不让它再往下嵌套。官方特意提醒把 max_depth 调大要谨慎否则一句宽泛的「都去并行」可能引发层层 fan-outtoken、延迟和本地资源消耗都会失控。Codex 还有两个挺实用的招数。一个是实验性的 spawn_agents_on_csv 工具你给一张 CSV它一行派一个工人 agent等整批跑完再把结果合并导出成 CSV——批量同质任务的福音。另一个是命令行里的 /agent你可以随时切进某个正在跑的 agent 线程看看它在忙什么或者直接喊话去引导、叫停、关闭它。毕竟「委派」不等于「闭眼信任」关键决策还是得有人盯着。模型搭配上官方的务实建议是主线用强一点的模型、轻量子任务交给更小更快的 mini 档难啃的工程活再上专门的 codex 档。两位选手同一个目标Claude Code 自动委派 vs Codex 显式召唤六、提醒聊到这儿得给热情泼一点点冷水。子智能体很迷人但它解决的是「上下文压力」不是「工程管理」本身。第一它更费钱每个分身都是一次独立的模型与工具消耗分得越多账单越长别为了「看起来很并行」而无脑开分身。第二它不是额外的安全护盾子智能体继承的是你的沙箱和审批策略并行写代码还可能制造协调难题真正安全的做法是只在「确实能并行、且以读为主」的活上用它。第三它把管理责任搬到了提示词层会拆活的人能借它把调研并行化、跑得飞快不会拆的人只会用更多同时输出更快地撞上同一堵墙。结语从「一个人扛」到「带一支队伍」说到底Sub Agent 机制标志着 AI 编程助手的一次思路转变从「一个超级大脑硬扛所有事」进化成「一个清醒的指挥官 一支召之即来、用完即散的专业小队」。Claude Code 让它聪明地自动发生Codex 让它老实地听你调遣路径不同但都指向同一个朴素的目标——让主线别被淹没让 AI 在复杂任务里始终记得「我到底要干嘛」。下一次当你的 AI 又开始「越聊越上头」时也许你该轻轻提醒它一句这活儿要不叫个分身 三十秒收尾子智能体 主脑临时召唤的专业小助手独立上下文、独立工具、只交回结论适合「能拆开、读得多」的活不适合「要协调、写得多」的活Claude Code 自动委派、靠 Markdown 定义、可嵌套Codex 必须显式召唤、靠 TOML 配置、默认最多 6 个并行只下一层。本质都是为了——主线清爽思路不丢。