[AI书房] 第24章 子智能体：分工的艺术
Claude Code完全掌握
Claude Code完全掌握
第24章 子智能体：分工的艺术
金京镇
主会话与辅助智能体的关系
终端窗口里启动了Claude Code。调用轮播技能（Carousel Skill）后，屏幕一侧出现了一个小小的智能体标识。「正在规划轮播幻灯片，将使用智能体。」主会话没有亲自构建幻灯片，而是把任务交给了一个独立的辅助智能体（Subagent）。
辅助智能体埋头搭建幻灯片结构的同时，主会话可以继续处理其他工作。
这个场景浓缩了辅助智能体的本质。
在Claude Code中开启新会话时，我们对话的对象就是主会话。主会话拥有自己的上下文窗口，持续积累对话记录，统管整个项目。可如果所有工作都让主会话亲力亲为，会怎样？
代码审查、调研、编写测试、调试、撰写文档，，全部塞进同一个上下文里处理，窗口很快就会饱和。上下文腐化（Context Rot）随之而来，前面对话中建立的脉络开始模糊。
辅助智能体正是为解决这个问题而设计的结构。如果说主会话是项目负责人，辅助智能体就是专业团队成员。项目负责人把控全局，具体工作委派给专家执行。
[图 24-1] 主会话与辅助智能体关系图：主会话（项目负责人）向代码审查员、构建者、调试器、测试运行器、架构师、调研员等6个辅助智能体分配任务的结构]
下面更具体地看看辅助智能体的运作方式。
辅助智能体平时处于休眠状态。不被唤醒时，它几乎等于不存在。主会话发出「起来，帮我处理这个任务」的调用指令时，辅助智能体带着一个全新的上下文苏醒。它可以使用自己专属的模型，配备自己专属的工具集，专注于自己的使命。
拥有独立上下文，这一点至关重要。辅助智能体不共享主会话的对话记录。它只接收主会话传来的提示词作为输入，独立完成任务后，仅将结果返回。
能够使用不同模型，这一点同样关键。即使主会话运行的是Opus，辅助智能体也可以用Haiku或Sonnet来工作。这就打开了精细调节成本和速度的通道。
辅助智能体还支持并行执行。在一次演示中，有人提出「请同时调研中小企业和大型企业的AI应用情况」，主会话随即派出两个调研辅助智能体同步行动。两个智能体各自独立完成调查，把结果送回主会话。中小企业AI应用简报、大型企业AI应用简报，以及两者的交集分析，一并整理完毕。
用组织管理来类比：主会话专注于制定计划、分配任务、汇总结果。专业工作的执行是辅助智能体的职责。这样一来，主会话的上下文始终保持干净。
定制面包房的比喻
想象你正在筹备一场派对，需要一批真正好吃的纸杯蛋糕。
有两条路。去大型超市，拿几盒流水线生产的纸杯蛋糕。快、便宜、省事。味道嘛，也就那样。另一条路是找到街角那家手工面包房，下一份定制订单。「香草奶油底，加薰衣草香，顶上放食用花。」等待时间长一些，但成品的品质不可同日而语。
[图 24-2] 定制面包房比喻：超市纸杯蛋糕（通用处理） vs 定制面包房（专业辅助智能体）对比]
辅助智能体就是那家定制面包房。
主会话亲自处理所有任务，类似于去超市买蛋糕。用通用能力一口气处理多项工作，速度确实快，但每项工作的质量有天花板。代码审查、调研、测试编写、调试全挤在同一个上下文窗口里，哪一项都难以深入。
委派给辅助智能体则不同。一个「代码审查专家」辅助智能体，拥有专为代码审查设计的系统提示词、针对代码审查优化的工具集、聚焦于代码审查的上下文。就像定制面包房把全部心思倾注在一款蛋糕上，辅助智能体把所有能力集中在被委派的那一项任务上。
这个比喻里还有一层值得留意。向定制面包房下单时，我们会把需求说得清清楚楚。「香草奶油，薰衣草香，食用花。」委派任务给辅助智能体也是同理。主会话发送给辅助智能体的提示词，就是那张订单。订单越清晰，返回的成品质量越高。
定制面包房还支持复购。「上次做的那款蛋糕，这次再来20个。」辅助智能体也一样，一旦打磨成熟，就可以跨项目、在整个组织中复用。
使用辅助智能体的5个理由
辅助智能体是什么、以怎样的结构运作，前面已经讲清楚了。接下来看看辅助智能体在哪些具体场景中表现突出。
为了保护上下文。使用Claude Code时，最需要珍惜的资源就是上下文窗口。上下文腐化是真实存在的威胁。操作者的职责是尽可能高效地管理上下文窗口，辅助智能体是实现这一目标的核心手段之一。
辅助智能体处理大量数据、执行广泛的调研，然后从结果中筛选出主会话真正需要的关键信息发送回来。在一次演示中，辅助智能体执行了约40,000 token的工作量，而主会话的上下文消耗始终维持在29,000 token。
辅助智能体处理的那40,000 token内容，没有污染主会话的上下文。
为了施加约束。主会话需要调用各种工具。但执行高风险操作时情况不同，比如GitHub Actions或某些代码层面的操作。把这类任务交给专门的辅助智能体，只赋予它有限的工具集，就能防止意外损害。
把主会话的强权限和辅助智能体的受限权限分离开来，提升整个工作流的安全性。
为了复用配置。辅助智能体的定义就是一个Markdown文件。把这个文件复制到另一个项目，就能立即使用同一个辅助智能体。从组织层面想，如果打造出一个擅长项目管理或季度规划的辅助智能体，整个组织都能受益。
原理和技能（Skill）类似，但辅助智能体多了独立上下文和模型选择这两个维度。
为了实现专业化。AI在目标具体且聚焦时，产出质量更高。与其用一个全能智能体负责规划、构建、测试、文档、调研、审查全部环节，不如让多个小型智能体各司其职。主会话负责综合它们的成果就好。「小智能体赢（Tiny agents win）」这条原则在实战中已被反复验证。
为了控制成本。每个辅助智能体可以指定不同的模型，不必所有任务都用Opus。需要快速调研的辅助智能体分配Haiku，需要生成代码的辅助智能体分配Sonnet，时间和token成本就能同步降低。
[表 23-1] 辅助智能体使用理由汇总
委派与亲力亲为的判断标准
了解了辅助智能体的优势后，很容易产生把所有工作都委派出去的冲动。但那样做会陷入过度设计（Over-engineering）。什么时候该委派、什么时候该自己来，需要一套判断标准。
应由主会话直接处理的情况：
需要多轮往返（Back-and-forth）的任务。「把这里改一下」，看到结果后再说「不对，换个方向」，，这种反复交互在主会话中直接做更高效。委派给辅助智能体的话，每次都要从全新上下文起步，反而低效。
需要快速修复的任务也是如此。改一个变量名、修一个拼写错误、调整一段简单逻辑，为此唤醒辅助智能体并等待结果返回，开销比任务本身还大。
需要共享上下文的任务，即需要基于此前对话记录做出判断的工作，同样应由主会话承担。辅助智能体不会继承对话记录。
对低延迟（Low Latency）有要求的场景，主会话也更合适。调用辅助智能体、执行任务、接收结果，这个过程不可避免地需要时间。
应委派给辅助智能体的情况：
自包含（Self-contained）的任务。像「分析这个代码库，找出安全漏洞」这样的工作，接到输入后独立执行、返回结果即可，非常适合委派。
需要限制工具权限的任务，辅助智能体同样合适。可以只给某个辅助智能体赋予只读权限，或限制它只能使用特定的MCP连接服务器。
只需要汇总结果的情况，同样是委派的信号。即便辅助智能体处理了海量数据，主会话只需接收其核心摘要即可。这正是上下文保护的关键机制。
前台（Foreground）与后台（Background）执行是另一个选择维度。在前台运行辅助智能体时，主会话会等待其完成；在后台运行时，主会话可以继续处理其他任务。如何选择，取决于任务的紧迫程度和依赖关系。
[图 24-3] 委派判断流程图：「是否需要多轮对话？」→ 是：主会话 / 否 →「任务能否自我完结？」→ 是：辅助智能体 / 否 → 主会话
有一个根本性的区别需要厘清。辅助智能体与智能体团队（Agent Teams）名称相近，概念看似重叠，但本质截然不同。辅助智能体是单向关系。主会话发送输入，辅助智能体执行任务，再将结果返回给主会话。辅助智能体之间无法互相通信。
即使并行运行，它们也各自独立工作。
智能体团队则是双向的。团队成员拥有共享任务列表，可以互相发送消息，也可以互相分配任务。那是完全不同维度的协作，将在后续章节中具体展开。
到这里，我们已经建立了辅助智能体的概念基础：它是什么、为什么需要、何时使用。接下来，该动手看看如何将这些概念落到实处了。
人工智能专家 金京镇 律师
AI法律政策专家 · 前国会议员 · 著作等身
如果这本书曾在您身边停留片刻，请支持我们，让下一个故事得以问世。
（自愿赞助账户：农协 302-1096-0948-81 户名：金京镇）