6. 多智能体委托 — 什么分出去，什么留给自己

这是 Alice Way 系列的第 6 篇。在第 5 篇 Hooks and automation 之前，本系列涵盖了如何设计单个协作者的心智。本篇关于一种结构：让那个协作者不必做所有事——把心智横向分配。

0. 委托是拆分心智，让一个上下文不必承载一切

把每项任务都交给一个协作者，其context window 很快就会填满。一旦填满，决策质量下降。质量下降迫使操作者每次都要反复检查。然后操作者的心智负担又上去了。

委托打破这个循环。大型任务被拆分交给子协作者；主协作者只收到每个结果的摘要。 每个子协作者用自己的上下文专注于一件事。主协作者的上下文只填充决策所需的内容。

不过委托有代价——说明书必须写，结果必须验证，整合必须发生。如果分配的收益不超过那些代价，委托就是亏损。

本篇是对哪些工作值得委托、如何建立追责委托的关卡、以及要避免的陷阱的记录。

子智能体机制本身借鉴自 Anthropic Claude Code 的 subagents 系统。本篇是如何使用那个机制的记录，而非对它的发明。

1. 主-子分工 — 谁承载什么

我收敛出来的分工。

核心是——主协作者承载决策权限和记忆；子协作者承载工作和深度上下文。它们从不承载相同的内容。重叠就是浪费的上下文。

这个分工最常见的崩溃方式——主协作者试图了解子协作者工作的每个细节。然后主协作者的上下文填满，使用子协作者的理由也随之消失。

主协作者必须知道它不知道什么。未知的部分由子协作者持守。

2. 什么是可委托的 — 五个条件

并非所有工作都是可委托的。只有通过以下全部五条的工作才会下放给子协作者。

2.1 输入是封闭的吗？

子协作者接受主协作者上下文的一次性切片。「告诉我更多关于 X 的事」这样的任务中途双向对话很难处理。所以开始时需要的一切都必须封闭在说明书中。

如果输入不封闭，子协作者就用猜测填充。猜测经常偏离。

2.2 输出可以被摘要吗？

当子协作者的结果返回主上下文时，只有摘要应该进来。如果结果本质上很长且不可摘要——比如「审查所有 100 个文件」——委托的价值就会缩小。主协作者最终还是要吸收一个 100 个文件的摘要。

2.3 决策权限留在主协作者手中吗？

子协作者不能在任务中途踏入操作者的决策领地。「我可以修改 DB 架构吗？」不是子协作者决定的事情。如果这样的决策可能在任务中途出现——要么在说明书中预先声明权限表，要么设计子协作者在决策点停下来汇报。

2.4 验证是可自动化的吗？

如果操作者每次都要手动验证子协作者的结果，委托的收益就消失了。只有附带自动验证脚本的工作才是可委托的。（见第 4 节关于关卡。）

2.5 专注于一件事吗？

子协作者做一件事。"重构这个组件 + 添加测试 + 更新文档"这样的复合工作不作为一个整体委托。拆成三个，发给三个不同的子协作者。单个子协作者承载多件事会产生纠缠的上下文和模糊的输出。

3. 委托的代价 — 何时直接做更好

委托并不总是净正值。代价摘要如下。

• 说明书撰写成本 — 把什么/为何/如何/在哪里停止写成文字
• 上下文准备成本 — 只提取子协作者需要的内容并移交
• 验证成本 — 自动检查 + 主协作者的再次确认以信任结果
• 整合成本 — 把结果吸收回主上下文

这四者之和必须小于直接做的成本，委托才有价值。根据我的经验——30 分钟内完成的工作委托会亏损；耗时 2 小时以上或涉及 5 个以上文件的工作从委托中受益。

无视任务规模的委托不是委托——只是推卸责任。

4. 委托关卡 — 在代码中强制执行承诺

委托失败最常见的方式——说明书写好了，但验证和合并关卡被跳过了。然后承诺与结果之间的漂移不断积累，直到很久以后才浮现。

被这个模式坑过一次之后，我现在任何委托都总是在同一个 PR 中捆绑三样东西。

4.1 说明书

详细说明什么/为何/如何/在哪里停止的文档。子协作者在开始前读一遍。说明书包含：

• 目标和完成定义
• 输入（从主上下文提取）
• 输出格式（哪些文件，什么结构）
• 决策权限表（自主 / 向主汇报 / 禁止）
• 验证方法（命名的自动脚本）
• 合并关卡（CI 中必须通过什么才能合并）

4.2 自动验证脚本

让人类不必每次手动检查结果——一个可操作的脚本。对于"重构组件 X"的委托，npm run verify:component-x 这样的脚本与说明书在同一个 PR 中发布。

没有验证脚本的说明书不是说明书。只是意图的表达。

4.3 合并关卡

验证脚本在 CI 中运行，如果不通过则阻断合并。承诺验证而不建立关卡——最终会有东西在验证从未运行的情况下被合并。

三样东西（说明书 + 验证脚本 + 合并关卡）一起移动。丢掉任何一个，承诺就不再在代码中强制执行，承诺就会破裂。

如果承诺没有在代码中强制执行，漂移就会积累。

5. 实际轮转中的委托

我每周委托的一部分内容。

5.1 广泛的代码库探索

"找出 X 关键词在哪些地方被使用以及如何使用"——交给子协作者。子协作者用 grep/glob/find 梳理整个仓库并写出结果。主协作者只收到那份报告。

如果主协作者直接做——数百个匹配结果挤满主上下文，没有空间留给决策。

5.2 构建·测试运行

「对这次变更运行 lint + 构建 + 测试并总结」——也交给子协作者。子协作者承受完整输出；主协作者只得到「通过」/「失败（3 个，前两行：……）」风格的摘要。

5.3 审查

「从安全角度审查这个 PR」——子协作者读完整内容并写出问题列表。主协作者只得到问题数量和最重要的三条。

5.4 广泛的外部研究

「这个库的已知安全问题和替代方案」——外部研究。子协作者从多个来源收集并写出报告。主协作者只吸收决策所需的简短摘要。

5.5 积累效果

每个任务节省的上下文都很小。但当每天发生 5—6 次委托时——主协作者的上下文全天保持在仅决策模式。操作者看到的汇报格式变得一致，"主协作者因为承载了一切而困惑"这样的模式消失了。

6. 陷阱 — 委托失败的模式

我至少踩过一次的失败模式。

6.1 未经验证的委托

最常见的陷阱。说明书写好，委托出去。结果回来，没办法验证，只能每次手动检查。所有收益消失。→ 第 4 节的三件套关卡是答案。

6.2 开放输入的委托

「随便你怎么处理这个」——子协作者用猜测填充，猜测偏离。→ 即使说明书简短，也要保持封闭。

6.3 模糊的权限

子协作者在工作中途遇到「我应该修改这个吗？」并按自己的判断继续。操作者看到了偏离意图的结果。→ 说明书中的权限表 + 决策点停下来汇报的模式。

6.4 过度碎片化的委托

委托五分钟的任务。说明书撰写成本超过任务本身。直接做更快。→ 30 分钟以下不委托。

6.5 忽视整合成本

一次性难以整合的子协作者结果。五个子协作者同时触及不同文件发生冲突。→ 在说明书中预先划分子协作者工作区域，使它们不重叠。

7. 委托 vs 直接 的决策流程

新工作来时，我在心里运行的决策流程。

新工作
  ↓
30 分钟以内？→ 是 → 直接做
  ↓ 否
输入封闭？→ 否 → 直接做（或先准备输入）
  ↓ 是
验证可自动化？→ 否 → 直接做（风险太大）
  ↓ 是
单件事？→ 否 → 拆分，分别委托
  ↓ 是
→ 委托（说明书 + 验证脚本 + 合并关卡捆绑）

这个流程内化后，委托 vs 直接的判断就很快了。每次不用重新斟酌。

8. 压缩成一条原则

委托设计的核心压缩成一句话：

「主协作者持守决策和记忆；子协作者持守工作和深度上下文。委托总是以说明书 + 验证脚本 + 合并关卡作为一个整体发布。」

这条成立时，委托成为让主上下文保持在决策模式的加速器。它崩溃时，委托变成推卸责任，结果整合成为操作者反复出现的负担。

下一篇涵盖强制确认委托（和直接）工作真正"完成"的装置——验证循环，即如何锁定代码工作"完成"的定义。