如一 Agent 架构解读（二十一）：SubAgent 体系——封装、闭环与可交互
前二十篇拆完了单 Agent 的 internals：loop、上下文、压缩、工具、记忆、缓存。这些文章共享一个前提——一个 Agent 就是一个上下文窗口、一档模型、一条串行执行线。这篇讲 SubAgent：先分析这个前提在复杂任务下的结构性约束，再对齐业界各家的实现取舍，最后讲如一的受管 SubAgent 体系怎么设计。
单 Agent 的结构性约束
复杂任务——比如一次覆盖五家竞品的调研并成稿——在单 Agent 形态下会撞上四类约束。
上下文质量。调研过程产生大量中间产物：几十轮搜索的噪声结果、上百个页面的正文、走不通的探索路径，全部以工具回传的形式进入同一个上下文。有实测观察到上下文填充到 45% 左右模型表现开始退化，而任务后段恰恰是最需要判断力的成稿环节。压缩能缓解但救不了场——这个系列第三到六篇的结论是压缩有损，关键数据（比如一张定价对比表）在需要它之前被折叠成摘要的概率不小。
执行成本。探索是体力活，成稿是判断力活，但单 Agent 不区分这个：所有 token 按同一档模型计费。OpenRouter 的对比数据是 Opus 4.8 输入每百万 token 5 美元、GLM 5.2 为 1.4 美元，复杂任务里大部分 token 花在探索上，等于全程按三到五倍溢价支付。ICML 今年的 AgentRouter 论文给出过量化结论：按任务粒度做模型路由，成本可降 72%，完成率损失不到 3%——但前提是有“任务粒度”的路由单位，单 Agent 形态下这个单位不存在。
串行时间线。loop 是串行的，任务时长受限于一组 run 的存活。长任务中途进程重启、或需要等待外部输入，整个任务就得重来。行业对这条约束的反应已经很明确：微软 Agent Framework 的 BackgroundAgentsProvider 给父 Agent 提供启动任务、等待完成、取回结果三个工具，Google Interactions API 增加 background=True——长任务异步化是 2026 年的明确趋势，而它的前提同样是存在一个有生命周期的独立执行体。
注意力守恒。前三类约束的本质是同一个：单个上下文窗口的注意力和单条时间线的吞吐量都是守恒的，上下文工程（压缩、缓存、回读）优化的是分配效率，不改变总量。要突破总量，只能引入另一个执行体。
委派与函数调用的技术区别
引入另一个执行体，最省事的形态是函数调用：参数进去、结果出来。但复杂任务的委派在语义上不同于函数调用，差别在判断权的转移。函数调用的入参出参可以完全枚举；委派的任务会在执行中产生无法预先枚举的子问题——调研中临时需要翻财报、需要对比历史价格——这些判断只能由执行方现场做出。
判断权的转移对执行体的形态提出三个技术要求。一是能力封装：执行方需要围绕任务方向配齐领域知识、工具集和模型档位，是一个完整的能力单元，不是一段临时拼装的提示词。二是闭环：执行过程（探索、试错、中间产物）在执行方自己的上下文中完成，返回的是结论而不是历史。三是可交互：闭环不等于断联，执行中需要能向委派方提问，委派方需要能追问、纠偏、叫停。
业界实现的取舍
用这三条量业界的主流实现，格局很一致：封装基本都做，闭环做一半，可交互基本不做。
Claude Code 的自定义子代理（.claude/agents）和 Codex 的 agent thread 代表主流形态。封装层面两者都齐：专属系统提示、独立工具权限（只读 reviewer 是典型配置）、可选模型档位。闭环只到一半：子代理在独立上下文中执行、返回摘要——隔离成立，但实例是一次性的，调用结束即销毁；嵌套深度钉死在 1；追问、纠偏、叫停没有协议入口，因为协议里没有“执行中途”这个概念。这类设计的目标是把探索噪声挡在主上下文之外，对应上面的上下文质量约束，管不到时间线和交互。
Anthropic 的 Research 系统是 orchestrator-worker 架构价值的最硬证据：比单 Agent 高 90.2%，复杂查询研究时间最多省 90%，代价是约 15 倍 token。他们自己分析 BrowseComp 评测数据，token 用量一项解释 80% 的性能方差，加工具调用次数和模型选择共解释 95%——多投入的算力就是性能提升的机制本身。Noam Brown 在访谈里给了并行的扩展曲线：4 个 agent 并行，两倍成本换一倍速度，16 个 agent 仍为正收益、边际递减。但 Research 的子代理同样是运行时派生的临时实例，存活于单个请求边界内。
成本侧还有一个常被忽略的工程细节。模型路由分两级：请求级路由在同一任务内把不同调用分给不同模型，prompt 缓存前缀随之失效（第十三篇讲过缓存是前缀字节匹配）；任务级路由把整个任务交给同一模型，缓存窗口独立完整。SubAgent 天然是任务级路由的单位——AgentRouter 那 72% 的成本优化，落到工程上需要一个任务粒度的执行体来承接。
反方观点值得记录。Cognition 反对多智能体协作的文章批评的是隐性决策：子代理的推理过程对主 Agent 不可见，出错无法归因。这个批评对一次性实例成立，但它的指向其实不是“不该拆”，而是执行体缺少身份和通信通道——问题在形态，不在方向。
如一的受管 SubAgent 体系
如一的实现按封装、闭环、可交互逐层落地，外加一层业界普遍没做的：实例身份。
封装层，定义即配置。一个 SubAgentDefinition 包含七项：type 与 description（渲染进 spawn_subagent 的工具描述，供主模型做路由判断）、systemPrompt、toolFilter（正向工具 allowlist）、skills（默认拒绝，按定义授予）、scene（模型档位）、toolChoice 与 maxSteps。定义存于 subagent_definition 表，DB 驱动，目录 60 秒刷新，admin UPSERT 即生效，新增分型不需要发版。也支持 spawn 时现场合成 volatile 定义，用完即销毁，与预置定义走同一条装配流水线。工具集收窄同时服务于两个目标：权限最小化，以及降低模型在工具选择上的决策噪声。此外子 Agent 不挂用户记忆、不加载 persona、不与用户直接交互，是纯任务执行体——用户输入永远归主 Loop。
闭环层，独立 loop、独立账本。子 Agent 复用同一个 AgentLoopEngine，只替换 transcript 后端为 DB 持久化（第一篇的 Run/Turn/Attempt 模型原样继承，含恢复与压缩），引擎零改动。执行痕迹全部留在实例自己的 transcript 中。终态汇报经 relay 回推父会话时压成 3000 字以内的摘要，超长附实例指针；产物（写出的文件）单独成清单，与汇报文本分离。账务上，每个分型绑定自己的 scene，整段执行使用同一档模型，缓存前缀稳定，任务级路由的成本红利完整保留。
可交互层，双向通道。下行：子 Agent 工具集内含 ask_parent，执行中将问题连同上下文写入信箱，实例转入 ASKING 态挂起，父会话的答复经信箱送达后恢复执行。上行：父侧有六个控制工具，覆盖状态查询、追加消息、暂停、恢复、销毁；子实例崩溃时 relay 会把失败事实回推父会话，不产生静默丢失。
身份层，受管实体。追问、叫停、查账、异步长跑都以实例“仍然存活”为前提，所以子 Agent 实例落库（subagent_instance 表），跨 run 存活，带完整的生命周期状态机。这层是闭环能力真正的地基，也是与一次性实例的本质区别——生命周期管理本身是一门独立的学问，下一篇展开。
成本与适用边界
账单必须摊开。多智能体执行约消耗普通聊天 15 倍的 token；并行收益随实例数边际递减；串行依赖强的任务（多数编码任务）拆分反而更慢。适用条件 Anthropic 总结得很准确：高度可并行、信息规模超出单上下文窗口、任务价值足够高。委派的决策因此是经营问题：这个任务的预期收益，是否覆盖上下文隔离、模型差价、并行时长这几项的实际成本。
从约束到形态
单 Agent 的四类约束里，上下文质量可以靠上下文工程缓解，成本、时间线、注意力总量是结构性的，必须引入独立执行体。业界实现普遍解决了隔离，如一的受管体系补上的是交互通道和实例身份——子 Agent 在各自方向上闭环，主 Agent 掌控全局，能力边界随分型编制扩展，不再受单个窗口封顶。
SubAgent 系列这是第一篇。下一篇讲实例的生命周期：run 不等于实例。第三篇讲 Leader 与子 Agent 之间的契约——我们自己定义了一套 A2A 协议。
