12.1 这一课在整套课程中的位置

第11课，我们第一次把：

封装成：

Skill

也就是：

让 Claude 知道“这类任务应该怎么做”。

例如：

但是现在出现一个新的问题。

假设任务不是：

阅读1篇论文。

而是：

阅读20篇论文，并形成一篇文献综述。

如果全部让同一个 Claude：

会发生什么？

可能出现：

那么问题来了：

能不能让多个“研究助理”分别承担不同子任务，再由主 Agent 统一汇总？

答案就是：

Subagent

12.2 先不要讲技术，先想一个真实课题组

假设老师要完成：

20篇论文的文献综述。

有两种工作方式。

方式A：一个研究助理全部完成

优点：

一个人知道整个过程。

问题：

信息量非常大。

方式B：建立分工

这就是理解：

Subagent

最简单的方式。

12.3 第一个正式概念：Subagent

英文：

Subagent

中文通常叫：

子代理 / 子智能体。

大白话：

主 Agent 临时把一部分工作交给另一个拥有自己独立工作桌面的 AI 助手。

这个子代理：

完成任务以后：

把结果返回主 Agent。

12.4 Subagent 最核心的价值不是“多一个 Claude”

很多人第一次听到：

会想：

“不就是多开几个 Claude 吗？”

这还没有抓住本质。

真正重要的是：

Context Isolation

中文：

上下文隔离。

12.5 用办公桌理解 Context Isolation

第5课我们一直使用：

如果一个 Agent 阅读20篇论文：

20篇论文都逐渐堆在同一张桌子上。

桌面越来越乱。

Subagent 的思路：

每个人：

只处理自己负责的材料。

最后主 Agent 收到：

而不是：

所有人的完整工作草稿。

12.6 官方当前怎么定义 Subagent 的价值？

Claude Code 官方目前明确说明：

Subagent 适合处理那些会产生大量搜索结果、日志、文件内容或其他中间信息，而这些内容没有必要全部进入主对话的任务。

换成人话：

脏活、累活、信息量大的工作，放到独立 Context 里做；主 Agent 只接收最后有价值的结果。

12.7 这就是为什么 Subagent 特别适合科研阅读

例如一个 Subagent 阅读一篇20页论文。

它可能经历：

整个过程可能产生：

大量 Context。

但主 Agent 真正需要的可能只是：

所以：

让阅读过程留在 Subagent，把结构化结果返回 Main Agent。

12.8 Subagent 的基本工作模式

可以把 Main Agent 理解成：

项目负责人

Subagent：

专项研究助理

12.9 第二个正式概念：Delegation

英文：

Delegation

中文：

委派。

大白话：

主 Agent 判断“这件事不必我亲自把全部过程塞进自己的 Context”，于是交给 Subagent。

12.10 Delegation 不是简单复制任务

好的委派必须说明：

也就是：

主 Agent 需要给 Subagent 写一份清楚的任务单。

12.11 Subagent 默认会继承主对话全部内容吗？

不会。

这是本课最重要的认知之一。

普通 Subagent 当前默认：

从一个全新的、独立的 Context Window 开始。

它不会自动看到：

12.12 那 Subagent 怎么知道任务？

Main Agent 会写：

Delegation Prompt

也就是：

把当前真正需要的信息整理成任务说明交给 Subagent。

所以：

12.13 这就是 Subagent 的优势，也是风险

优势：

Context 干净。

风险：

如果主 Agent 委派时漏掉关键背景，Subagent 就不知道。

所以使用 Subagent 的能力之一是：

会切任务，也会交代任务。

12.14 一个错误委派

Subagent 会问：

看什么？

任务边界太模糊。

12.15 一个更好的委派

这就是：

好的 Delegation Prompt

12.16 Subagent 到底会加载什么？

普通自定义 Subagent 当前启动时通常会获得：

但是：

不会自动继承主会话完整聊天历史。

12.17 一个重要例外：Explore 和 Plan

Claude Code 当前有一些内置 Subagent。

其中最常见的是：

Explore 和 Plan 为了：

更轻、更快地做研究与探索，

当前官方实现会跳过部分常规项目上下文，例如：

所以不要假设：

所有 Subagent 的启动 Context 完全相同。

12.18 Built-in Subagent：Explore

大白话：

专门负责“找东西、读东西、理解项目”的只读研究助理。

特点：

例如：

这种任务就很适合 Explore。

12.19 Built-in Subagent：Plan

大白话：

在 Plan Mode 里帮助主 Agent 调研项目，然后支持制定方案的研究助理。

例如：

先研究整个项目结构，再设计一个改造方案。

12.20 Built-in Subagent：General-purpose

大白话：

既能研究，又能执行比较复杂任务的通用研究助理。

如果一个任务：

Claude 可能使用 General-purpose。

12.21 那为什么还需要自己创建 Subagent？

因为内置 Subagent 是：

通用工作人员。

你可能需要：

这些有稳定专业分工。

这时可以建立：

Custom Subagent

12.22 Custom Subagent 放在哪里？

和 Skill 类似，

主要有：

和：

12.23 项目级 Subagent

位置：

例如：

大白话：

这个项目自己的专业研究助理。

12.24 用户级 Subagent

位置：

Windows 可以理解为：

例如：

这些可以：

跨项目使用。

12.25 怎么判断放哪里？

问：

“这个角色换一个项目后还适用吗？”

例如：

多个科研项目都能用。

适合：

例如：

只服务某一篇论文。

适合：

12.26 Subagent 文件长什么样？

Subagent 本质上也是：

Markdown 文件 + YAML Frontmatter

例如：

12.27 Frontmatter 最重要的两个字段

当前官方要求：

是必需字段。

name

大白话：

这个研究助理叫什么。

description

大白话：

什么时候主 Agent 应该把任务交给它。

12.28 Description 为什么又一次很重要？

第11课 Skill 已经学过：

Description 是发现机制。

Subagent 也一样。

Main Agent 会参考：

判断：

是否应该委派给这个 Subagent。

12.29 一个很差的 Description

太模糊。

Claude 不知道：

12.30 一个更好的 Description

它说明：

12.31 Subagent 正文是什么？

和 Skill 不一样。

Subagent Markdown 正文会成为：

这个 Subagent 自己的 System Prompt

也就是说：

这是这个“员工”的岗位说明书。

12.32 Skill 和 Subagent 的本质区别

Skill

它回答：

这类工作怎么做？

Subagent

它回答：

谁单独去做这部分工作？

12.33 最简单的一句话

这里的“人”只是类比，

但非常好记。

12.34 再用课题组解释

这个研究助理：

可以预先加载那套 Skill。

于是：

12.35 Skill + Subagent 的组合

例如：

Frontmatter 中可以：

意思：

这个 Subagent 一上岗，就把 literature-note Skill 完整加载进自己的 Context。

12.36 注意：Subagent 中预加载 Skill 和主 Agent 不一样

主 Agent 里：

Skill 通常按需加载。

但如果 Subagent Frontmatter 写：

那么：

这个 Skill 的完整内容会在 Subagent 启动时直接进入它的 Context。

因为：

这是它上岗必须掌握的专业 SOP。

12.37 一个完整 paper-reader Agent

12.38 tools 是什么？

例如：

意思：

这个 Subagent 只拥有这些 Tool。

12.39 为什么要限制 Tool？

paper-reader 的任务只是：

它不需要：

所以：

Least Privilege

第9课再次回来。

12.40 一个只读文献 Subagent

优点：

即使它理解错了任务，也很难直接改坏项目文件。

12.41 为什么 Subagent 特别适合做“角色隔离”？

主 Agent 可能同时负责：

而 Subagent 可以只负责：

或者：

角色越聚焦，

System Prompt 越容易写清楚。

12.42 model

Subagent 可以指定：

或者使用当前 Claude Code 支持的模型别名 / 模型 ID。

大白话：

不同研究助理可以使用不同模型。

12.43 为什么这可能有价值？

例如：

可能不需要最昂贵模型。

而：

可能需要更强模型。

于是可以：

把成本和能力按任务匹配。

12.44 初学阶段怎么选？

最简单：

让它：

继承主 Session 的模型。

先不要把课程变成模型配置课。

12.45 permissionMode

Subagent 还可以拥有自己的：

例如：

这说明：

Subagent 不只是独立 Context，还可以有自己的行动边界。

12.46 这和第9课再次连接

例如：

只读。

可以直接限制 Tool，

甚至设计为：

不拥有 Edit。

可能需要写文件，

但：

不应该允许 git push。

所以不同 Subagent：

可以有不同权限配置。

12.47 Subagent 可以有自己的 Memory 吗？

可以。

当前官方支持：

12.48 为什么 Subagent Memory 很有意思？

假设：

长期帮你审查同一项目。

它可以逐渐记住：

这就变成：

一个会积累经验的专业助理。

12.49 但主 Agent 的 Auto Memory 会自动给 Subagent 吗？

不会。

普通 Subagent：

不会加载主对话的 Auto Memory。

如果 Subagent 需要长期记忆：

给它自己的 memory 配置。

12.50 这再次说明：Subagent 真的是独立工作人员

它不是：

主 Claude 的一个临时脑区。

而更像：

独立工作空间 + 独立 Context + 独立配置。

12.51 当前 /agents 命令有一个重要变化

很多旧教程会告诉你：

然后：

打开交互式创建向导。

但当前 Claude Code 新版本中：

/agents 已不再打开旧的交互创建向导。

现在更推荐：

或者：

12.52 所以第一次创建 Agent 最简单的方法

可以直接告诉 Claude：

Claude 会帮你生成 Agent 文件。

12.53 但为什么教材仍然教手写？

和：

一样。

如果你不知道：

自动生成以后：

你也不会调试。

所以：

先懂，再自动生成。

12.54 第一次实操：建立 paper-reader

项目：

12.55 paper-reader.md

12.56 为什么第一版 Agent 也要简单？

和 Skill 一样：

MVP

先做到：

再加：

12.57 Git 保存 Agent

Project Subagent：

非常适合进入 Git。

因为团队成员也可以：

共享、修改、改进。

12.58 Agent 创建以后一定要重启吗？

当前 Claude Code 会监控：

和：

如果这些目录在 Session 启动时已经存在，

后面修改 Agent 文件通常：

几秒内就会检测到。

12.59 什么时候可能需要重启？

一个常见情况：

Session 启动时根本还没有 .claude/agents/ 目录。

你中途第一次创建：

当前 Session 可能没有监听它。

这时：

重启 Claude Code

最简单。

12.60 怎样让 Claude 调用 Subagent？

主要有几种方式。

12.61 第一种：自然语言

例如：

通常 Claude 会：

根据你的要求进行委派。

12.62 第二种：让 Claude 自己判断

你只说：

如果 Agent 的：

足够清楚，

Claude 可能自动判断：

应该交给 paper-reader。

12.63 第三种：@-mention

当前 Claude Code 支持：

输入 @，从 Agent 列表里选择一个 Subagent。

这可以：

保证指定 Agent 被调用

而不是：

只给 Claude 一个建议。

12.64 为什么 @-mention 很适合调试？

当你测试：

时，

你不希望：

Claude 自己决定不用它。

所以：

直接 @ 指定 Agent。

这样可以把：

和：

分开测试。

12.65 Subagent 完成以后发生什么？

通常：

主 Agent 再：

使用这个结果继续综合。

12.66 这就是“Context Compression by Delegation”

可以理解成：

通过委派完成上下文压缩。

不是数学压缩。

而是：

12.67 这和 /compact 有什么不同？

/compact

Subagent

所以：

Subagent 更像“提前隔离”。

12.68 一个论文阅读例子

如果主 Agent 自己读：

主 Context：

越来越大。

如果 Subagent 读：

主 Agent 最终主要接收：

更容易综合。

12.69 但 Subagent 并不是“免费 Context”

这是一个非常重要的现实。

每个 Subagent：

有自己的模型调用和 Token 消耗。

所以：

有时候：

总 Token 反而更多。

12.70 第三个正式概念：Context Cost vs Total Cost

你要区分：

和：

Subagent 主要优化：

主 Context 的干净程度、并行性和任务分工。

不保证：

总成本一定下降。

12.71 为什么并行 Subagent 会更快，但不一定更省？

例如4篇论文。

顺序：

可能时间长。

并行：

墙钟时间可能下降。

但：

四个 Agent 都在消耗模型请求。

所以：

Parallel ≠ Free

12.72 第四个正式概念：Parallelism

英文：

Parallelism

中文：

并行。

大白话：

几个相互独立的任务同时做。

12.73 什么任务适合并行？

关键判断：

它们彼此依赖吗？

例如：

彼此不需要对方结果。

适合：

并行

12.74 什么任务不适合并行？

例如：

第二步依赖第一步。

第三步依赖第二步。

这种更适合：

Sequential

顺序执行。

12.75 官方当前的建议也一样

Subagent 并行研究最适合：

不同调查路径彼此独立。

如果后一个任务必须知道前一个结果：

应该链式执行。

12.76 第五个正式概念：Fan-out / Fan-in

这是多 Agent 中非常重要的模式。

Fan-out

可以理解成：

分发。

Fan-in

可以理解成：

回收。

12.77 文献综述就是典型 Fan-out / Fan-in

这是非常典型的科研 Agent 架构。

12.78 为什么“统一提取框架”必须在 Fan-out 前完成？

如果你直接说：

每个 Agent 自由发挥。

结果可能是：

最后：

没法横向比较。

12.79 正确做法

Main Agent 先定义：

然后所有 Subagent：

使用同一个结构。

这样最终才能：

横向综合

12.80 多 Agent 的关键不是“数量”

多 Agent 质量不只取决于：

Agent 数量。

更关键的是：

任务拆分接口是否标准化。

12.81 一个很差的多 Agent 流程

结果：

很可能变成20份摘要的堆砌。

12.82 一个更好的流程

这才是真正的：

Multi-agent Literature Review

12.83 为什么这比“一个 Agent 直接读20篇”更有优势？

主要不是因为：

“多 Agent 更聪明。”

而是因为四个结构优势。

12.84 优势1：Context Isolation

每个 Subagent：

只专注自己负责的论文。

减少：

12.85 优势2：Parallelism

独立论文可以：

同时阅读。

降低总等待时间。

12.86 优势3：Specialization

可以让不同 Agent：

承担不同专业角色。

12.87 优势4：Context Compression

主 Agent 不接收：

每个 Subagent 的全部过程。

而主要获得：

结构化结果和摘要。

主 Context 更干净。

12.88 但也有四个风险

12.89 风险1：信息损失

Subagent 返回：

摘要。

摘要一定会：

舍弃部分信息。

如果 Main Agent 后面需要某个细节，

可能要：

12.90 风险2：标准不一致

不同 Agent 如果：

输出标准不统一，

结果很难综合。

12.91 风险3：错误传播

如果 Subagent：

把论文结论理解错了，

Main Agent 又直接接受，

错误会进入最终综述。

所以：

Subagent 结果也需要 Verify。

12.92 风险4：Token 成本

Subagent 数量越多：

模型调用越多。

所以：

不要把“多 Agent”当成越多越高级。

12.93 到底是一篇论文一个 Agent，还是一个 Agent 读几篇？

没有固定答案。

取决于：

12.94 一篇一个 Agent 适合什么？

例如：

优势：

Context 最干净。

缺点：

成本高，Agent 多。

12.95 一个 Agent 读3–5篇适合什么？

例如：

优点：

成本和管理更平衡。

12.96 一个很实用的科研建议

初学多 Agent 文献综述时：

不要一上来就20篇=20个Agent。

先测试：

理解结构以后再扩展。

12.97 当前 Claude Code 的并发技术上限

当前官方默认：

同一个 Session 同时运行的 Subagent 达到20个时，再继续 Spawn 会触发并发限制。

但必须强调：

20是技术上限，不是推荐数量。

科研任务通常没有必要：

为了“多 Agent”刻意跑满20个。

12.98 为什么太多 Agent 反而可能更差？

因为：

所以：

分工要有意义。

12.99 Main Agent 应该做什么？

成熟的文献综述多 Agent 架构中，

Main Agent 不应该：

只是负责把结果粘在一起。

它应该承担：

所以：

Main Agent 是总编辑，不是搬运工。

12.100 Subagent 应该做什么？

例如 paper-reader：

不要让它：

直接决定整篇文献综述的最终论点。

因为它只看：

自己局部材料。

12.101 “局部认知”和“全局认知”

这是非常重要的多 Agent 设计原则。

12.102 第二次实操：4篇论文并行阅读

项目：

12.103 给 Main Agent 的任务

12.104 观察什么？

不要只看最终答案。

观察：

12.105 这次练习真正学的是 Orchestration

英文：

Orchestration

中文：

编排 / 调度。

大白话：

Main Agent 怎么把多个 Subagent 组织成一个完整工作流程。

12.106 好的多 Agent 系统不是“Agent 很多”

而是：

这才叫：

Orchestration

12.107 前台和后台 Subagent

Claude Code 当前支持：

和：

两种运行方式。

12.108 Foreground

大白话：

主 Agent 等这个 Subagent 做完，再继续。

适合：

12.109 Background

大白话：

Subagent 在后面工作，主 Agent 还可以继续做别的。

适合：

例如：

12.110 当前交互模式下的实际行为比较复杂

新版本 Claude Code：

交互 Session 中的 fork mode 会影响 Subagent 默认前台 / 后台行为。

初学阶段不要背内部规则。

只要理解：

即可。

12.111 /tasks

当前 Claude Code 可以用：

查看：

正在运行或刚完成的后台 Subagent / 后台任务。

大白话：

看看研究助理们现在都在干什么。

12.112 为什么 /tasks 对多 Agent 很重要？

如果同时跑：

你需要知道：

不然就像：

课题组派了4个人出去，却不知道谁回来了。

12.113 Permission 在 Subagent 中还存在吗？

当然存在。

Background Subagent 如果遇到：

需要人工批准的 Tool Call，

Claude Code 当前会：

把权限请求显示到主 Session，并告诉你是哪一个 Subagent 在请求。

所以：

Subagent 不绕过 Permission。

12.114 这和第9课再次连接

例如：

只是读取，

基本不需要很多权限。

而：

可能需要运行 Python。

它的权限：

应该单独设计。

12.115 Subagent 也受 Sandbox 吗？

如果 Subagent 使用：

运行命令，

仍然会受到：

第10课的 Sandbox / 工作环境边界。

所以：

12.116 Subagent 之间会不会互相改坏文件？

如果多个 Subagent：

当然存在：

冲突风险。

所以科研多 Agent 初学阶段一个很安全的做法：

Subagent 主要负责只读分析，Main Agent 负责最终写入。

12.117 为什么这非常适合文献综述？

Reader Agents：

Main Agent：

不会出现：

4个 Agent 同时改 literature-review.md。

12.118 如果确实要并行修改文件怎么办？

Claude Code 当前支持：

让 Subagent 在：

独立 Git Worktree

中工作。

大白话：

每个研究助理拿一份自己的项目副本，不直接挤在同一张文件桌上。

12.119 但这一课不深入 Worktree

因为这涉及：

会把主线拉远。

目前先记：

并行读很安全，并行写要更谨慎。

12.120 Subagent 能不能再调用 Subagent？

当前 Claude Code：

可以。

也就是：

这叫：

Nested Subagents

嵌套子代理。

12.121 当前默认深度

当前官方默认允许：

主对话下面继续嵌套约3层 Subagent。

技术上可以配置。

但再次强调：

不是层级越深越高级。

12.122 什么情况才适合嵌套？

例如一个：

发现3个重要问题。

它再分别让：

核实每个发现。

这就有逻辑。

12.123 什么情况不适合嵌套？

只是为了：

“看起来多 Agent。”

没有清晰功能分工。

只会增加：

12.124 第七个正式概念：Agent Depth

大白话：

Agent 委派链条有多深。

设计原则：

能平就别深。

如果任务可以：

完成，

通常不要故意：

12.125 Sequential Chaining

并不是所有多个 Subagent 都要并行。

官方还支持：

Chain Subagents

也就是：

一个完成后，把结果交给下一个。

12.126 科研例子

这是：

顺序链

12.127 Parallel 和 Chain 怎么选？

问：

后一个任务需要前一个结果吗？

如果：

不需要。

如果：

需要。

12.128 一个常见错误：什么都并行

例如：

模型 Agent 还不知道：

变量最终是什么。

这不是并行，

这是：

逻辑错乱。

12.129 Main Conversation 什么时候反而更好？

官方当前明确建议：

如果任务：

就应该：

留在 Main Conversation

12.130 一个简单任务不要 Subagent

例如：

如果还：

纯属浪费。

12.131 第八个正式概念：Delegation Overhead

中文：

委派开销。

大白话：

叫一个新研究助理来，也有成本。

它需要：

所以：

小任务直接做更快。

12.132 一个实用判断：值得不值得派 Subagent？

问四个问题：

多数回答：

是。

再考虑 Subagent。

12.133 Skill vs Subagent 再做一次最终判断

如果你的痛点是：

“我每次都要重新解释审稿步骤。”

答案：

Skill

如果你的痛点是：

“这次任务要读20篇论文，不想把全部阅读过程塞进主 Context。”

答案：

Subagent

12.134 Skill 和 Subagent 可以同时使用

这是最重要的高级认知之一。

所以：

可以得到：

4个按照同一 SOP 工作的独立研究助理。

12.135 这就是科研多 Agent 系统的雏形

已经非常接近：

AI科研协作系统

12.136 第三次实操：创建 method-reviewer

建立：

例如：

12.137 为什么 paper-reader 和 method-reviewer 要分开？

paper-reader：

理解论文。

method-reviewer：

挑战方法。

如果全部写成一个：

系统提示会越来越复杂。

分开后：

各自职责更清楚。

12.138 但是不要“角色碎片化”

错误：

任务太碎。

协调成本：

比直接做还高。

所以：

Agent 粒度要适中。

12.139 什么是好的 Agent 粒度？

一个 Subagent 应该：

例如：

就比较合理。

12.140 第四次实操：两阶段审稿

让 Main Agent：

这就是：

Chain Subagents

或者：

在条件允许时让两个角色独立并行后再汇总。

具体取决于：

method-reviewer 是否需要前一步的输出。

12.141 Subagent 的返回结果应该多详细？

这是一个非常关键的问题。

很多人以为：

越详细越好。

不一定。

如果10个 Subagent：

每个返回5000字。

Main Context：

又被塞满了。

12.142 第九个正式概念：Return Contract

可以翻译成：

返回协议

大白话：

主 Agent 要提前规定 Subagent 最后必须以什么形式交作业。

12.143 一个好 Return Contract

这样：

Main Context 可控。

12.144 为什么“只返回结论”还不够？

如果完全没有：

证据定位，

Main Agent 很难 Verify。

所以科研 Subagent 最好还返回：

12.145 Multi-Agent 不能替代 Evidence

一个 Agent 说：

“这篇论文有内生性问题。”

Main Agent 不应该直接：

相信。

应该问：

所以：

多 Agent 仍然需要 Evidence-grounded Workflow。

12.146 第十个正式概念：Verifier Agent

大白话：

专门检查其他 Agent 结果是否可靠的复核助理。

例如：

Verifier：

回原文确认是否真的用了 IV。

12.147 为什么 Verifier 很适合高价值科研任务？

因为多 Agent 的一个风险就是：

错误传播

增加一个独立复核路径：

可以降低：

Main Agent 直接接受错误摘要的风险。

12.148 但也不要所有结果都双重验证

否则：

都会明显增加。

更合理：

只验证高风险、关键结论。

例如：

12.149 Subagent 可以拥有自己的 Skill 和 Memory

现在已经学会：

和：

这意味着一个专业 Subagent 可以越来越像：

长期稳定岗位。

例如：

它可以：

12.150 这是不是越复杂越好？

不是。

初学阶段：

比：

全堆在一起更容易学习。

12.151 Subagent 的常见失败1：Description 太模糊

Main Agent 不知道什么时候该委派。

12.152 常见失败2：Subagent 什么都做

这不是专业 Agent，

这是：

另一个 Main Agent。

12.153 常见失败3：Main Agent 没给足任务背景

因为 Subagent：

不自动继承完整聊天历史。

如果任务依赖：

必须在委派 Prompt 中明确。

12.154 常见失败4：返回结果太长

你本来想：

保护主 Context。

结果10个 Agent：

每个返回一大篇报告。

主 Context 还是爆了。

12.155 常见失败5：让所有 Agent 同时改同一个文件

这会增加：

初学阶段优先：

Reader Agents 只读。

12.156 常见失败6：独立任务却串行执行

4篇互不依赖论文：

浪费了并行优势。

12.157 常见失败7：依赖任务却强行并行

上下游信息不同步。

12.158 常见失败8：Agent 太多

“我有20篇论文，所以20个Agent一定最好。”

不一定。

需要考虑：

12.159 常见失败9：没有统一 Schema

最终结果：

Main Agent 很难综合。

12.160 常见失败10：主 Agent 只是拼接

最终文献综述变成：

这不是综述。

Main Agent 必须做：

12.161 多 Agent 不能替代“总编辑能力”

Subagent 提高：

信息处理能力。

但最终：

Synthesis

仍然是最高价值环节。

12.162 第十一个正式概念：Synthesis

中文：

综合。

大白话：

不是把多个答案拼起来，而是从多个局部结果中建立更高层次结构。

例如：

12.163 文献综述的真正价值就在 Synthesis

所以：

是一种非常合理的分工。

12.164 Subagent 和 Agent Team 有什么区别？

先只学最简单版本。

Subagent

核心模式：

主 Agent：

是中心协调者。

Agent Team

更像：

适合：

更复杂的多 Agent 协作。

12.165 所以 Subagent 不等于“完整 AI 团队”

它更像：

主任 + 专项助理

而 Agent Team 更像：

多个相对独立成员组成课题组

下一课我们会详细讲。

12.166 一个成熟的科研文献综述架构

可以是：

12.167 为什么这个架构比“每篇一个自由Agent”更稳？

因为：

每一层：

职责清楚。

12.168 本课综合毕业实操

建立：

12.169 你需要独立完成

12.170 本课最重要的十一个概念

1. Subagent

拥有独立 Context 的专业子代理。

2. Delegation

Main Agent 把明确子任务交出去。

3. Context Isolation

子任务的大量中间信息不进入主 Context。

4. Parallelism

互不依赖的任务同时执行。

5. Fan-out / Fan-in

先分发，再汇总。

6. Orchestration

组织多个 Agent 的任务、顺序和结果流。

7. Return Contract

规定 Subagent 最终怎样交作业。

8. Agent Depth

Agent 委派链条有多深。

9. Verifier Agent

专门复核关键结果的 Agent。

10. Delegation Overhead

叫一个独立 Agent 来工作本身也有成本。

11. Synthesis

Main Agent 从多个局部结果建立全局结论。

12.171 Skill 与 Subagent 最终对照表

最容易记的一句话：

Skill = 方法；Subagent = 人。

12.172 什么时候应该留在 Main Conversation？

这时：

不要为了 Agent 而 Agent。

12.173 什么时候优先考虑 Subagent？

这就是当前最典型的 Subagent 使用场景。

12.174 本课一句话总结

如果第12课只允许记住一句话：

Subagent 不是“多开一个 Claude”，而是把一个相对独立的子任务放进新的 Context 中完成，让大量中间信息留在子代理里，只把高价值结果返回 Main Agent。

如果再多记一句：

科研多 Agent 的关键不是 Agent 越多越好，而是 Main Agent 先定义统一任务接口，让独立 Subagent 按统一标准工作，再由 Main Agent 负责全局综合和关键结果验证。

12.175 把前12课完整串起来

到这里，

你已经第一次真正进入：

多 Agent 科研协作

12.176 下一课为什么学习 Agent Teams？

Subagent 已经可以：

但是还有一种更复杂的科研任务。

例如：

围绕一个新的国家自然科学基金选题，让几个 Agent 分别提出竞争性理论解释，并且互相质疑、讨论、修正。

这时我们希望：

这已经不只是：

Main Agent 派任务、Subagent 交作业。

而更像：

真正的课题组协作

Claude Code 当前把这种更复杂的协作机制称为：

Agent Teams