第 4 章 AI AgentAgentic PatternsSub-Agent

第 4 章委派：让主 Agent 学会把活分出去

一个 Agent 的上下文装不下所有事

前两章讲的都是"怎么让单个 Agent 干得更好"。但有一个根本限制绕不过去：单个 Agent 的上下文窗口是有限的。

假设你让它"帮我在这个大型项目里实现一个新功能"。这个功能涉及十几个文件、几百个函数。如果你把相关资料全塞进一个 Agent 的上下文，它要么装不下，要么装下了之后"注意力"被稀释，越往后越糊涂。

这就需要一个真实团队的管理者早就学会的本事：把活分出去。

让主 Agent 像项目经理一样，把大任务拆成小块，派给一个个"子 Agent"（sub-agent），让它们并行干活，最后汇总结果。这就是委派（delegation）。

这一章讲三个模式：

Sub-Agent Spawning（子 Agent 派生）：主 Agent 派生子 Agent，各干各的，最后汇总。
Subject Hygiene（任务命名规范）：给每个子任务起一个清楚、可追溯的名字——看起来小事，其实决定成败。
Recursive Best-of-N Delegation（递归择优委派）：在不确定的子任务上，多派几个候选，择优录取。

模式一：子 Agent 派生（Sub-Agent Spawning）

问题

大型多文件任务会撑爆主 Agent 的上下文窗口和推理预算。它读的文件越多，越难保持清醒。你需要一种方式，把工作委派给上下文隔离、工具受限的专业化子 Agent。

方案

让主 Agent 派生一个个专注的子 Agent，每个子 Agent 有自己的全新上下文，在可切分的子任务上并行工作，最后把结果汇总回来。

一个关键要求：每个子 Agent 的调用都必须有一个清晰、具体的任务名称，否则并行工作会无法追踪、难以汇总（详见模式二 Subject Hygiene）。

实现方式有两种：

方式一：声明式配置（YAML）

在配置文件里定义好各种"子 Agent 类型"，每个类型有自己的系统提示词、可用工具和上下文窗口：

# subagents/planning.yaml
name: planning
system_prompt: "把复杂任务拆解成步骤..."
tools:
  - list_files
  - read_file

然后主 Agent 通过一个专门的工具来调用：

子Agent(名称, 提示词, 文件列表)

这样能实现：虚拟文件隔离（子 Agent 只能看到显式传给它的文件）、工具范围控制（可以继承父 Agent 全部工具，或只给一部分）、专业化提示词（每种子 Agent 有预设行为）。

方式二：动态派生

按需在运行时派生子 Agent，处理可并行的任务：

文件列表 = 扫描("**/*.md")
批次 = 切分(文件列表, 每批9个)
for 每批 in 批次:
    并行派生子Agent处理该批
汇总所有结果

证据

这个模式在多个生产级 Agent 工具中已经是标配（Claude Code 的 subagents、各种 agent 框架的 Task 工具），来源包括 Sourcegraph 的 Quinn Slack 等一线实践者的经验总结。
状态标签是 validated-in-production——已经在生产环境大规模验证过。

怎么用

适合这些场景：

大型多文件任务，需要拆成可并行的小块。
需要给不同子任务不同工具/不同上下文的时候。
需要隔离——某个子任务不该看到其它子任务的数据时。

实施要点：

每个子 Agent 的任务要清晰、具体、可命名（这是下一个模式的核心）。
文件隔离要做好：只给子 Agent 它需要的东西。
结果汇总要想清楚：谁来做汇总、格式是什么。

取舍

好处：突破了单个上下文窗口的限制；并行提升速度；天然隔离。
代价：需要额外的编排逻辑（派发、汇总、错误处理）；子 Agent 之间的边界要设计好。
注意：如果任务切分得不好，汇总阶段可能变成新的瓶颈。

模式二：任务命名规范（Subject Hygiene）

问题

如果你用 Task 工具（或任何委派机制）给子 Agent 派活，但任务名称是空的、或者很笼统，会发生什么？

无法追踪：你根本不知道每个子 Agent 在干什么。
无法引用：事后想讨论"某个子 Agent 干的活"，说不出指哪个。
一片混乱：好几个空名称的子 Agent，长得一模一样，无法区分。

你可能觉得这是小事。但这个模式背后有真实的教训——分析过 88 个真实会话、48 次 Task 调用之后发现，空的任务名称是一个主要痛点。

方案

给每一次委派都起一个清晰、具体的任务名称。这是一个"元模式"（meta-pattern）——它本身不解决具体业务问题，但它让其它所有委派类模式（子 Agent 派生、工厂化、Planner-Worker）都能正常发挥作用。

一个好的任务名称应该满足四条：

不为空（底线要求）
具体、有描述性（在做什么）
可引用（事后能讨论）
符合命名规范（祈使语气、目标明确）

看例子：

❌ 糟糕的命名：

""（空的）
"research"（太笼统）
"explore"（太笼统）
"task"（说了等于没说）

✅ 好的命名：

"探索 newsletter 组件的实现"
"在代码库中搜索暗色模式实现"
"分析 API 路由的错误处理"
"找出所有 OAuth 配置文件"

规律很明显：动作动词 + 明确目标。

证据

基于 88 个真实会话的分析（48 次 Task 调用），空任务名称被识别为主要痛点。
学术界也有根基：多 Agent 通信标准（FIPA ACL、KQML）和分布式系统的命名原则（REST、MapReduce）都强调清晰的命名。

怎么用

把"给任务起好名字"当成流程的一部分，而不是可选项。
派活前，先过一遍那个问题："这个任务，我能用一个动词加一个目标把它说清楚吗？"
不能的话，先别派，先把任务定义清楚。

取舍

好处：几乎是零成本，却大幅提升可追踪性、可排查性、可讨论性。
代价：几乎为零——唯一的要求是养成习惯。
注意：这不是一个"要不要用"的问题，而是一个"必须遵守"的纪律。

模式三：递归择优委派（Recursive Best-of-N Delegation）

问题

递归委派（主 Agent → 子 Agent → 孙 Agent）能把大任务层层分解，但它有一个失败模式：

一个弱子 Agent 的结果，会污染父 Agent 的下一步（错误假设、漏看的文件、坏补丁）。
错误向上累积：树上一个"坏叶子"就能毁掉整个结果。
纯递归浪费了并行能力：在某个节点不确定的时候，你希望在不确定的地方多试几次，而不是一路硬着头皮往下走。

而"best-of-N"（从 N 个候选中选最好的）能提升可靠性，但如果没有结构，它会反复解决同一个问题，浪费算力。

方案

在递归 Agent 树的每一个节点上，先对这个子任务做一次 best-of-N（并行生成 N 个候选，择优），再继续往下拆。这结合了递归委派的结构化分解和自洽采样（self-consistency）的可靠性：

分解：父 Agent 把任务拆成子任务（和普通递归委派一样）。
并行候选：对每个子任务，在隔离沙箱里派生 K 个候选 Worker（K 通常取 2-5）。
评分：用一个裁判，综合两方面信号：
- 自动化信号（测试、lint、退出码、diff 大小、运行时间）
- LLM 裁判的评分标准（正确性、约束遵守、简洁性）
择优提升：挑出最佳候选，作为该子任务的"标准结果"。
不确定性升级：如果裁判信心低（或候选之间意见不合），要么加大 K，要么派生一个专门的"调查子 Agent"去补事实，然后重选。
向上汇总：父 Agent 汇总选出的结果，继续递归。

怎么用

适合这类任务：

子任务可切分，但每一块都可能有点棘手（API 用法有歧义、项目有自己的惯例）。
你能低成本地给输出打分（单元测试、类型检查、lint、黄金文件）。
一步走错代价高（迁移 diff、安全敏感改动、大型重构）。

实用默认值：K 取 2-5；用便宜的自动化信号优先，LLM 裁判其次。

取舍

好处：可靠性大幅提升；把并行算力用在最需要的地方（不确定的子任务），而不是盲目铺开。
代价：多花算力（K 个候选要跑 K 遍）；需要能快速打分的信号。
注意：如果任务本身没法低成本打分，这个模式的价值会大打折扣。

三个模式怎么选

场景	推荐模式
大任务塞不进一个上下文，需要拆开并行	Sub-Agent Spawning
任何一次委派	Subject Hygiene（无条件遵守）
子任务可能很棘手、一步错代价高	Recursive Best-of-N
有测试/lint 能快速打分	Recursive Best-of-N（尤其适合）

三个模式是配合使用的：Sub-Agent Spawning 是"怎么派"，Subject Hygiene 是"派的时候必须守的纪律"，Recursive Best-of-N 是"派出去的活不放心时怎么多试几个"。

实践清单

大任务先问：能不能切成可并行的小块？
每个子任务用"动作动词 + 明确目标"命名，绝不为空
子 Agent 只给必要的文件（虚拟文件隔离）
工具范围按需收窄，别一股脑全给
不确定的子任务：派生 2-5 个候选，用测试/lint/裁判择优
裁判信心低时：加大候选数或派调查 Agent 补事实，而不是硬选
汇总步骤要有明确的责任人和格式

本章小结

Sub-Agent Spawning：主 Agent 拆任务、派生子 Agent 并行干活、最后汇总——突破单个上下文的限制。
Subject Hygiene：给每个委派起清晰的名字，零成本但决定可追踪性。
Recursive Best-of-N：在递归的每个节点上并行生成多个候选、择优晋级——把并行用在刀刃上。
三个模式配合使用，构成一套完整的"委派体系"。

到这里，第一部分的四章就讲完了。你已经有了一套能跑起来的最小体系：先计划再执行（第 2 章）、学会自我检查（第 3 章）、学会把活分出去（第 4 章）。下一部分，我们进入全书最独特的主题——上下文治理：把上下文当操作系统一样管起来。

第 4 章 委派：让主 Agent 学会把活分出去