# 1 - 深度研搜：DeepAgents 基础与核心概念

---

**本章课程目标：**

- 理解为什么在普通大模型调用、工具型 Agent 之后，还需要 DeepAgents 这类深度智能体框架。
- 掌握 `LangChain`、`LangGraph`、`DeepAgents` 三者之间的定位差异。
- 理解 DeepAgents 的四个核心能力：任务规划、上下文管理、子智能体、长期记忆。
- 理解高阶提示词为什么会和 DeepAgents 一起出现，以及它在复杂任务中的作用。
- 建立多智能体设计的边界感：知道什么时候适合使用子智能体，什么时候不应该滥用多智能体。

**学习建议：** 这一章先建立边界，不急着写代码。重点看普通 Agent 为什么处理长任务会吃力，DeepAgents 把规划、文件、子智能体、长期上下文这些能力放在什么位置。读完后最好能回答：什么任务值得交给 DeepAgents，什么任务用普通 Agent 或一条链就够了。下一章再进入 `create_deep_agent()`、`invoke()`、`stream()`。

---

## 1、项目导读

### 1.1 项目背景

「深度研搜（DeepAgents 多智能体）」是一个面向复杂研究任务的企业级智能体实战项目。它最终要做的不是简单问答，而是让智能体围绕一个开放问题进行资料搜索、信息整理、反思补充和报告生成。

如果把后续项目目标说得更具体一点，可以理解为一个「深度研搜」系统：

- 用户提出一个研究问题；
- 系统自动拆解研究方向；
- 不同工具或子智能体分别完成搜索、阅读、分析、校验等任务；
- 主智能体汇总中间结果，生成一份结构完整的研究报告。

这类任务和普通聊天问答不一样。它通常没有固定答案，也不一定能提前写死完整流程。系统需要一边执行，一边根据中间结果调整后续动作。

这正是 DeepAgents 适合发挥作用的地方。

### 1.2 为什么需要 DeepAgents

前面我们已经学习过不少大模型应用开发方式，例如：

- 直接调用大模型接口，让模型返回文本；
- 使用 LangChain 封装模型、提示词、输出解析器和工具；
- 使用 LangGraph 把复杂任务拆成多个固定节点；
- 使用 Agent 让模型在执行过程中自主决定是否调用工具。

这些方式都很重要，也能完成很多任务。但当任务进一步变长、变开放、变复杂时，普通 Agent 会逐渐遇到几个问题：

- 上下文越来越乱，工具返回结果和历史消息容易挤在一起；
- 任务拆解不稳定，模型可能想到哪做到哪；
- 所有事情都压在一个主智能体身上，专业分工不清晰；
- 中间过程难以观察，出错时不好定位；
- 多轮搜索、多轮反思、多方向并行时，执行链路容易失控。

比如用户让智能体完成一份“人工智能与机器人行业热点新闻研究报告”。这件事至少包括理解问题、联网搜索、筛选资料、总结观点、组织报告等步骤。如果继续扩展成深度搜索，还可能需要补充搜索、交叉验证、反思遗漏信息，甚至让不同子智能体分别处理不同方向。

DeepAgents 要解决的，正是这类更复杂、更长链路、更需要自主规划的智能体任务。

简单来说：

**DeepAgents（深度代理） 不是只让模型回答问题，而是让智能体像一个会规划、会分工、会使用工具、会管理上下文的任务负责人。**

---

## 2、智能体演进：从 LLM 到 DeepAgents

### 2.1 三个发展阶段

可以先用一张图建立整体印象。

![从 LLM 到 AI Agent 再到 Agentic AI 的能力演进示意图](images/1/1-2-1-1.png)

这张图表达的是大模型应用能力的递进关系：最早的大模型主要负责语言生成；进入 Agent 阶段后，模型开始能调用工具、执行动作；再往后发展到 Agentic AI，系统开始具备更强的规划、协作和长期任务推进能力。

如果拆成学习路径，可以分成三个阶段。

**第一阶段：直接调用大模型**

最早的大模型应用通常很简单：把提示词发给模型，模型返回文本。

```text
用户问题 -> Prompt -> LLM -> 文本结果
```

这种方式适合问答、摘要、改写、分类等相对简单的任务。它的优势是简单直接，但缺点也明显：模型只能基于已有上下文回答，不能主动访问外部系统，也不能真正执行动作。

比如你问它“今天有哪些人工智能新闻”，如果没有联网工具，它只能基于训练知识或上下文猜测，无法拿到实时信息。

**第二阶段：工具型 Agent**

后来我们开始给模型配工具，例如搜索工具、数据库工具、计算工具、文件工具。Agent 的核心变化是：模型不再只是回答问题，它可以根据任务判断是否调用工具。

```text
用户问题 -> Agent -> LLM 判断 -> 调用工具 -> 工具结果 -> LLM 总结 -> 最终结果
```

这时的 Agent 已经具备了“行动能力”。它可以先让模型判断下一步该干什么，再调用对应工具，最后把工具结果整理成自然语言。

但普通 Agent 通常还是一个主智能体在处理所有事情。随着任务变长，所有工具说明、历史消息、工具返回结果都会挤进同一个上下文窗口，主智能体既要规划，又要搜索，又要分析，还要写报告，压力会越来越大。

**第三阶段：DeepAgents 多智能体**

DeepAgents 在普通 Agent 的基础上进一步增强：除了调用工具，还可以调用子智能体。

```text
用户任务
  -> 主智能体负责规划和调度
  -> 调用工具或分派给子智能体
  -> 子智能体独立完成局部任务
  -> 主智能体汇总并输出最终结果
```

这里的关键变化是：主智能体不再什么都亲自干，而是更像一个项目负责人。它可以把不同任务交给不同子智能体，让子智能体在各自的上下文中完成专业任务，再把结果汇总回来。

这就是 DeepAgents 名字里 “Deep” 的含义：它面向的是更深层、更长链路、更复杂的智能体执行过程。

### 2.2 固定工作流与自主智能体

理解 DeepAgents 之前，还需要区分一个概念：固定工作流和 Agent 自主决策不是一回事。

在 LangGraph 项目里，我们经常会写一个固定的图。例如：

```text
START -> extract_keywords -> recall_info -> generate_sql -> validate_sql -> END
```

这种图的特点是：节点和边基本由开发者提前写好。运行时可以有条件分支，但整体路线是清晰、可控、固定的。

Agent 的执行方式更灵活。它会根据用户问题、系统提示词、工具描述、子智能体描述，动态决定下一步做什么。它可能先调搜索工具，也可能先写待办清单，也可能把任务分派给某个子智能体。

可以用下面这张表快速对比：

| 形态            | 谁决定流程                                 | 适合场景                         |
| --------------- | ------------------------------------------ | -------------------------------- |
| 普通 LLM 调用   | 开发者提前写好 Prompt                      | 简单问答、摘要、分类             |
| LangChain Agent | 模型根据工具描述动态决策                   | 简单工具调用型任务               |
| LangGraph       | 开发者显式编排节点和边                     | 流程明确、需要强控制的任务       |
| DeepAgents      | 主智能体基于提示词、工具、子智能体自主规划 | 长链路、复杂、多步骤、多角色任务 |

这张表里最容易混淆的是 LangGraph 和 DeepAgents。

如果你已经明确知道“第一步做什么、第二步做什么、失败后走哪里”，LangGraph 很合适；如果任务本身比较开放，执行路线需要智能体自己规划和调整，DeepAgents 更合适。

### 2.3 Deep Agents 与高阶提示词

在深度搜索项目里，除了 Deep Agents（深度代理），还会反复遇到一个概念：**高阶提示词**。

这两个概念最好放在一起理解。

Deep Agents 解决的是“任务怎么组织”的问题。面对复杂任务时，智能体不再只做一次性回答，而是要具备下面这些能力：

- 先把复杂任务拆成可执行的子目标；
- 为不同子目标匹配工具或子智能体；
- 执行过程中观察中间结果，发现缺口后继续补充；
- 根据工具返回和子任务结果调整计划；
- 出现偏差时，通过反思和修正让任务继续向目标收敛。

高阶提示词解决的是“模型应该怎么思考”的问题。

普通提示词通常告诉模型“做什么”，例如：

```text
请分析这条用户评论的情绪，并给出改进建议。
```

高阶提示词会进一步告诉模型“按什么步骤思考”，例如：

```text
请按以下流程分析：
1. 先提取评论中出现的具体问题；
2. 再判断情绪倾向，并给出理由；
3. 按影响程度对问题排序；
4. 每个问题给出可落地的改进建议；
5. 最后用一句话总结核心痛点。
```

可以把两者的关系理解成：

- Deep Agents 是智能体系统的组织架构，决定任务如何规划、分工、执行和反馈；
- 高阶提示词是智能体系统的思考规范，决定模型如何分析问题、拆解逻辑和组织输出。

所以后续做深度搜索项目时，不能只关注“有没有工具”和“有没有子智能体”。真正决定系统稳定性的，往往是这两件事能不能配合好：**用 DeepAgents 组织执行链路，用高阶提示词约束推理过程。**

---

## 3、DeepAgents 框架定位

### 3.1 与 LangChain、LangGraph 的关系

DeepAgents 是 LangChain 生态中的一个独立库，建立在 LangChain 和 LangGraph 的基础能力之上，用来构建更复杂的自主多智能体系统。

它的目标不是替代 LangChain 或 LangGraph，而是在它们之上补齐更高层的智能体能力：

- 内置任务规划能力；
- 内置上下文管理和文件系统能力；
- 支持子智能体分工；
- 支持长期记忆；
- 支持复杂任务的持续执行和流式观测。

![DeepAgents、LangGraph、LangChain 的能力栈关系示意图](images/1/1-3-1-1.png)

这张图可以从内到外看：

- 最内层是 `LangChain`，负责大模型与工具之间的基本交互；
- 中间层是 `LangGraph`，负责把执行过程组织成有状态、可持久化、可流式输出的图；
- 最外层是 `DeepAgents`，进一步提供规划工具、文件系统工具、子智能体和后端存储能力。

也就是说，DeepAgents 并不是重新发明一套模型调用框架，而是在已有的模型、工具和图执行能力之上，继续补齐“复杂任务如何长期组织”的能力。

### 3.2 三类框架使用场景对比

这三个框架都在 LangChain 生态里，但使用场景并不完全一样。

| 框架         | 核心定位                                                     | 更适合什么时候使用                                     |
| ------------ | ------------------------------------------------------------ | ------------------------------------------------------ |
| `LangChain`  | 基础开发框架，封装模型、Prompt、工具、Agent 等能力           | 快速构建简单 Agent，或者自己组合模型与工具             |
| `LangGraph`  | 图执行框架，强调状态、节点、边、分支、持久化和流式输出       | 流程明确、需要细粒度控制、需要稳定编排的复杂工作流     |
| `DeepAgents` | 深度智能体框架，强调自主规划、子智能体、上下文管理和长期记忆 | 长任务、多步骤、多角色、需要智能体自己规划和调度的任务 |

可以再换一种更工程化的说法：

- 如果你只是想让模型调用几个工具，`LangChain Agent` 就够了。
- 如果你已经知道业务流程每一步怎么走，并希望强控制每个节点，优先用 `LangGraph`。
- 如果任务非常开放，步骤不固定，还需要智能体自己拆任务、调工具、分配子任务，就适合使用 `DeepAgents`。

本项目最终要做的是一个“深度搜索”类应用：用户给出一个开放问题，系统需要搜索资料、阅读信息、反思缺口、继续补充、最终生成报告。这类任务很难提前把每一步完全写死，因此非常适合作为 DeepAgents 的实战项目。

![LangChain、LangGraph、Deep Agents 在 Framework、Runtime、Harness 三层中的能力对比](images/1/1-3-2-1.jpg)

可以从左到右理解这三层：

- `Framework` 层更关注基础抽象和集成，重点是让开发者更快接入模型、工具和 Agent；
- `Runtime` 层更关注稳定执行，重点是持久化、流式输出、人机交互和状态管理；
- `Harness` 层更关注复杂任务组织，重点是预定义工具、提示词、子智能体和更强的自主性。

对应到本项目里，可以这样理解：

- `LangChain` 更像“基础组件库”，提供模型、工具、提示词、Agent 等基础能力；
- `LangGraph` 更像“流程运行时”，负责把多步骤任务组织成有状态、可恢复、可流式观察的执行过程；
- `DeepAgents` 更像“任务组织套件”，在前两者之上进一步提供规划、文件系统、子智能体和长期记忆等能力。

这也是为什么 DeepAgents 会出现在更高一层：它面对的不是“怎么调一次模型”，而是“怎么让一个智能体系统持续推进复杂任务”。如果说 LangChain 帮我们把工具接起来，LangGraph 帮我们把流程管起来，那么 DeepAgents 更关注的是让智能体自己学会“拆任务、管资料、分派子任务、汇总结果”。

---

## 4、DeepAgents 核心能力

### 4.1 任务规划与任务分解

复杂任务最怕一上来就直接执行。

比如用户要求：“帮我调研一下最近机器人产业的发展，并写一份报告。”普通模型可能马上开始写内容，但这份内容很可能只是凭感觉拼接，没有清晰的资料来源、分析结构和补充机制。

DeepAgents 更推荐的方式是：先规划，再执行。

它内部提供了类似 `write_todos`、`read_todos`、`update_todos` 这样的待办清单能力，让智能体可以把复杂任务拆成多个步骤。例如：

```text
1. 明确研究主题和范围
2. 搜索近期机器人产业新闻
3. 筛选高价值信息来源
4. 总结产业趋势
5. 补充典型企业和案例
6. 生成最终研究报告
```

这样做的好处是，智能体不再只是“想到哪写到哪”，而是有了一个可以被更新、被追踪、被检查的任务计划。

### 4.2 上下文管理与文件系统

大模型上下文窗口是有限的。工具返回内容越多，历史消息越长，模型越容易被无关信息干扰。

DeepAgents 内置了文件系统相关能力，例如：

- `ls`：查看当前有哪些文件；
- `read_file`：读取文件内容；
- `write_file`：写入文件；
- `edit_file`：修改文件。

这套能力不是为了让智能体随便操作本地文件，而是为了给智能体一个外部工作区。它可以把长资料、阶段性笔记、中间报告写到文件里，主上下文里只保留当前最需要的信息。

可以把它理解成：模型的上下文只放当前正在思考的内容，文件系统负责保存大量中间资料。

### 4.3 子智能体与上下文隔离

单个智能体的能力再强，也会受到上下文、工具权限、专业提示词的限制。

多智能体的核心思路是“分而治之”：

- 主智能体负责理解用户目标、拆解任务、调度资源、汇总结果；
- 子智能体负责某一类专业任务，例如搜索、数据库查询、代码审查、报告撰写；
- 每个子智能体有自己的系统提示词、工具集合和执行上下文。

![DeepAgents 子智能体通过 task 工具实现上下文隔离的示意图](images/1/1-4-3-1.png)

这张图里最关键的点是：主智能体并不直接吞下所有上下文，而是通过 `task` 工具把工作委派出去。子智能体在独立上下文中完成搜索、代码、通用任务等细节工作，最后只把可汇总结果交回主智能体。

这样做能明显缓解上下文膨胀问题。尤其是当工具输出很大时，例如网页搜索、文件读取、数据库查询，如果全部塞给主智能体，主智能体很快就会被中间过程淹没。子智能体机制的意义，就是让细节工作发生在局部上下文里，让主智能体保留全局视角。

### 4.4 长期记忆

普通智能体经常有一个问题：当前会话结束后，它就不记得之前做过什么了。

但很多企业级任务不是一次性问答，而是持续推进的。例如：

- 长期跟进某个客户需求；
- 多次迭代同一个研究报告；
- 持续维护一个项目文档；
- 在不同会话中复用之前沉淀的经验。

DeepAgents 可以借助 LangGraph 的 Store 等能力，把关键记忆保存到外部存储中，让智能体跨会话读取历史信息。

这一章只需要先理解长期记忆的价值：**让智能体不只是当前会话里的助手，而是可以持续积累上下文的任务伙伴。**

具体的后端存储、文件系统后端、StoreBackend、StateBackend 等内容，会在后续进阶章节展开。

### 4.5 四个核心能力小结

把上面的内容收束一下，DeepAgents 最核心的是下面四类能力：

| 核心能力           | 解决什么问题                                       | 可以怎么理解                             |
| ------------------ | -------------------------------------------------- | ---------------------------------------- |
| 智能规划与任务分解 | 复杂任务不知道从哪开始、做完哪些步骤才算完成       | 先拆任务、再执行、再更新进度             |
| 高效上下文管理     | 搜索结果、文件内容、工具返回值太大，容易塞爆上下文 | 把大块信息写到文件系统，需要时再读回来   |
| 子智能体机制       | 主智能体既要规划又要干活，专业性和上下文都会被稀释 | 主智能体负责调度，子智能体负责专业子任务 |
| 长期记忆           | 多轮会话之间容易失忆，历史经验无法复用             | 把关键记忆保存下来，后续会话可继续读取   |

本章只建立概念。下一章会真正写到工具调用、非流式执行和流式解析，并在流式输出中初步识别 `task` 子智能体调用。至于子智能体如何配置、什么时候拆分、如何异步并发，会放到第 3 章系统展开。文件系统、长期记忆、后端存储等能力会放到后续章节继续讲。

---

## 5、多智能体设计边界

### 5.1 子智能体定义

很多同学第一次看到“子智能体”，容易把它想成“多写几个角色 Prompt”。比如：

```text
你是搜索专家。
你是分析专家。
你是写作专家。
```

这只说对了一小部分。真正的子智能体，不只是一个角色名字，而是一个可以被主智能体调用的小助手。

可以先用一个生活例子理解：

如果你要装修房子，你不会一个人同时做设计、水电、木工、验收。更合理的方式是：

- 你负责确定总目标和预算；
- 设计师负责出设计方案；
- 水电师傅负责水电线路；
- 木工负责柜子和吊顶；
- 最后你把各部分结果汇总验收。

在 DeepAgents 里也是类似的：

- **主智能体**负责理解用户目标、拆任务、决定交给谁做、最后整合结果；
- **子智能体**负责完成某一类更具体的任务，比如搜索、分析、写作、审核。

所以子智能体可以简单理解为：**主智能体请来的专业助手。**

它的执行链路大致是这样：

```text
用户目标
  -> 主智能体判断任务太复杂，需要分工
  -> 主智能体通过 task 工具把一部分任务交给子智能体
  -> 子智能体独立完成这部分任务
  -> 子智能体把结果返回给主智能体
  -> 主智能体整合所有结果，回复用户
```

这里最关键的不是“Agent 数量变多了”，而是**分工变清楚了**。

如果没有清楚的分工，多智能体就容易变成多个模型互相聊天，调用次数变多了，结果却不一定更好。

### 5.2 主智能体和子智能体的关系

DeepAgents 更适合用“主从关系”来理解：

```text
主智能体：项目负责人
  ├─ 搜索子智能体：负责查资料
  ├─ 分析子智能体：负责提炼观点
  ├─ 写作子智能体：负责组织报告
  └─ 审核子智能体：负责检查遗漏和错误
```

主智能体不一定亲自做所有细节，它更像一个项目负责人，重点是：

1. 理解用户目标；
2. 判断任务该拆成哪些部分；
3. 决定哪些部分自己做，哪些部分交给子智能体；
4. 接收子智能体返回的结果；
5. 把结果整理成最终答案。

子智能体则更像具体岗位的人，只关注自己负责的那一块。

例如在「深度研搜」项目里，一个用户问题可能是：`请调研最近半年人形机器人行业的发展情况，并写一份带来源的分析报告。`

这个任务并不是一句话就能回答好的。它可能需要：

- 先查新闻和政策；
- 再查企业和产品进展；
- 再整理趋势和风险；
- 最后写成报告。

这时就适合让主智能体统筹，让不同子智能体分别处理局部任务。

### 5.3 子智能体核心价值

子智能体不是为了让系统“看起来高级”，它主要解决三个实际问题。

**第一，上下文隔离：避免主智能体被大量中间信息淹没。**

深度搜索任务里，真正占空间的往往不是最终答案，而是中间过程：

- 搜索工具返回的很多网页内容；
- 文件读取返回的大段资料；
- 数据库查询返回的表格结果；
- 多轮补充搜索和反复对比产生的过程记录。

如果这些内容全部塞给主智能体，主智能体很容易被细节带偏，忘记最开始的目标。

子智能体的好处是：**细节工作在子智能体那里完成，主智能体只拿回整理后的结论。**

**第二，能力专业化：让不同任务交给更合适的助手。**

不同任务需要不同能力。比如深度研搜项目可以这样分工：

| 子智能体 | 负责什么                 | 返回什么                 |
| -------- | ------------------------ | ------------------------ |
| 搜索助手 | 查网页、新闻、报告、论文 | 来源、摘要、关键信息     |
| 分析助手 | 从资料中提炼观点         | 结论、依据、风险点       |
| 写作助手 | 把内容组织成报告         | 结构清楚、语言顺畅的正文 |
| 审核助手 | 检查遗漏、冲突和不确定性 | 修改建议、风险提醒       |

这样每个助手的任务更清楚，提示词也不用写得又长又杂。

**第三，任务并行：多个方向可以同时推进。**

如果一个调研任务可以拆成“政策、市场、技术”三个方向，而且它们互不依赖，主智能体就可以分别交给三个子智能体去做。

这样整体耗时可能会更短。但要注意，并行不是免费的。子智能体越多，模型调用次数、费用和调试难度也会增加。

### 5.4 子智能体使用边界

多智能体不是默认选项。判断是否要用它，可以先问一句：

> 这个任务真的复杂到需要分工吗？

先看适合使用的情况。一般来说，满足下面任意一种情况，才值得考虑多智能体：

| 判断标准       | 说明                                               | 示例                                  |
| -------------- | -------------------------------------------------- | ------------------------------------- |
| 问题极度开放   | 任务没有固定路线，需要探索、试错和动态调整         | 行业研究、战略分析、开放式调研        |
| 存在领域冲突   | 任务涉及多个专业领域，放在一个上下文里容易互相干扰 | 法律 + 医疗、金融 + 工程、代码 + 产品 |
| 需要多方向并行 | 任务天然可以拆成多个独立方向并行推进               | 多源搜索、多方案设计、多文件分析      |

反过来，如果任务很简单，就不需要多智能体。

比如：

- “北京今天多少度？”直接调用天气工具就够了；
- “把这句话翻译成英文”一个普通 Agent 就够了；
- “总结这篇短文章”通常也不需要拆成多个子智能体。

但如果任务是：

```text
从新闻、报告、论文、企业公告中调研某个行业，
并生成一份带引用来源、趋势判断和风险分析的深度报告。
```

这类任务就更适合多智能体，因为它需要多源资料、多步骤处理和最后汇总。

再看不适合使用的情况。子智能体不是越多越好，下面几种场景反而不建议拆：

| 不适合场景           | 为什么不适合                   | 更合适的做法             |
| -------------------- | ------------------------------ | ------------------------ |
| 一步就能完成的小任务 | 委派本身也要花时间和费用       | 直接回答或直接调用工具   |
| 必须连续阅读的短任务 | 拆开后反而容易丢上下文         | 让同一个智能体一次完成   |
| 子任务说不清楚       | 子智能体不知道该返回什么       | 先写清任务说明和输出格式 |
| 只是为了“看起来高级” | 会增加成本、日志和失败点       | 先用单 Agent 跑通        |
| 工具权限不好控制     | 子智能体可能调用不该调用的工具 | 明确工具白名单和审批规则 |

一个很实用的经验是：

> 先用单 Agent 跑通流程，再观察哪里反复变长、变乱、变专业，最后再把那一块拆成子智能体。

不要一开始就设计很多子智能体。初学时先掌握主线，比堆复杂架构更重要。

### 5.5 DeepAgents 中的委派机制

在 DeepAgents 中，主智能体想调用子智能体时，通常会使用一个特殊工具：`task`。可以把 `task` 理解成“派活”的动作。

本章只需要先了解：**看到 `task`，通常就说明主智能体正在把一部分任务委派给子智能体。**

至于 `task` 的参数长什么样、如何在 `stream()` 输出中识别它、普通工具调用和子智能体调用有什么区别，会放到第 2 章和第 3 章结合代码讲。子智能体的 `name`、`description`、`system_prompt`、`tools` 等配置字段，也会在第 3 章正式展开。

### 5.6 多智能体的缺陷

多智能体能解决复杂问题，但也会带来代价。

**第一，调用次数和费用会增加。**

每个子智能体都可能单独调用模型。子智能体越多，消耗的 Token 和费用通常也越多。所以不要因为“多智能体听起来更高级”就到处拆。简单任务直接让主智能体完成，反而更快、更便宜。

**第二，排查问题会更麻烦。**

单智能体出错时，通常只需要看一条执行链路。

多智能体出错时，需要追踪：

- 主智能体为什么选择这个子智能体；
- 子智能体收到了什么任务；
- 子智能体调用了哪些工具；
- 子智能体返回了什么；
- 主智能体如何整合这些结果。

所以后续写代码时，我们会特别关注 `stream()` 输出和日志。它们不是装饰，而是排查问题的重要线索。

### 5.7 两类多智能体架构

多智能体常见有两种组织方式。这部分先了解，不需要背概念。

**第一种：层级模式，也叫指挥官模式。**

层级模式（Orchestrator-Workers）的核心逻辑是：**一个主智能体负责调度，多个子智能体负责执行**。

可以把它理解成一个项目负责人带着多个专业助手工作。主智能体先理解用户目标，再拆解任务、选择合适的子智能体、收集子智能体结果，最后统一整理成最终输出。子智能体不需要关心全局目标，只需要把自己负责的局部任务做好。

![层级工作流 Orchestrator-Workers 中主调度器拆分任务并汇总输出的示意图](images/1/1-5-7-1.png)

它的流程通常是：

1. 用户输入一个复杂任务；
2. 主智能体理解目标，并拆成多个子任务；
3. 主智能体把子任务分给不同的专业子智能体；
4. 子智能体在自己的上下文里完成局部任务；
5. 子智能体把结果返回给主智能体；
6. 主智能体汇总、判断、整理成最终结果。

这种模式的优点是路线清楚、责任明确，比较适合工程项目落地。出问题时，我们也更容易追踪：是主智能体拆错了任务，还是子智能体执行错了任务，还是最后汇总时出了问题。

它的缺点也很明显：主智能体非常关键。如果主智能体一开始理解错了目标，或者分配错了子任务，后面的执行就会跟着偏。另外，所有任务都要经过主智能体调度，任务特别复杂时，主智能体也可能成为瓶颈。

DeepAgents 更偏向这种模式。它强调的是：**主智能体负责规划和调度，子智能体负责专业执行**。

**第二种：协作模式，也叫网状模式。**

协作模式（Collaborative Network）的核心逻辑是：**多个智能体围绕同一个问题共享信息、互相补充、共同推进**。

它更像多位专家开会。每个 Agent 都可以根据自己的角色和上下文发表意见，也可以根据其他 Agent 的输出继续补充、质疑或修正。这里不一定有一个绝对的“领导”，系统更依赖 Agent 之间的互动来让结果逐步收敛。

![协作工作流 Collaborative Network 中生成者与评估者循环反馈的示意图](images/1/1-5-7-2.png)

这种方式的优点是灵活，适合开放式探索、方案讨论、观点碰撞。比如多个专家一起评估一个商业方案、讨论一个技术路线，协作模式可能产生更多角度。

它的缺点是更容易失控。多个 Agent 可能不断补充、反驳、再补充，最后讨论很久却没有明确结论。调试时也更麻烦，因为你很难快速判断：最终答案到底是哪个 Agent 的判断影响最大。

本课程第一阶段先学习 DeepAgents 的层级模式：**主智能体负责调度，子智能体负责执行。**

### 5.8 和其他多智能体框架的区别

有了上面的两种架构，再看不同多智能体框架，就不只是记名字了，而是看它们更偏向哪种“组织方式”。

**DeepAgents** 更像层级/指挥官模式：主智能体先规划，再把任务分派给子智能体，最后统一汇总结果。

**AutoGen** 更像去中心化/网状协作模式：多个 Agent 像在一个群聊里讨论问题，根据上下文自由接话、互相补充。

**CrewAI** 更像角色和任务流程驱动的团队协作：开发者通常会先定义角色、任务和流程，再让不同 Agent 按设定完成各自职责。它可以做层级式流程，也可以做更灵活的角色协作。

| 框架       | 更像什么                   | 主要组织方式    | Agent 之间怎么协作                                         | 更适合的任务                                 | 主要风险                                       |
| ---------- | -------------------------- | --------------- | ---------------------------------------------------------- | -------------------------------------------- | ---------------------------------------------- |
| DeepAgents | 项目负责人带多个专业助手   | 层级调度        | 主智能体通过 `task` 等机制分派任务，子智能体完成后返回结果 | 深度研究、长任务、报告生成、多步骤资料整理   | 主智能体判断质量很关键，拆错任务会影响后续结果 |
| AutoGen    | 多个专家在群里讨论         | 网状协作        | 多个 Agent 围绕上下文自由对话、互相补充、互相修正          | 头脑风暴、方案讨论、开放式探索、复杂问题求解 | 容易发散，调试时难追踪关键判断来自哪里         |
| CrewAI     | 预设好的团队按任务流程协作 | 角色 + 任务流程 | 先定义角色、目标和任务，再让 Agent 按流程协作              | 标准业务流程、多角色执行、较清晰的团队分工   | 效果依赖角色和任务设计，流程设计不好时容易僵硬 |

简单说，三者最大的区别不是“谁更高级”，而是任务组织方式不同：

- 如果你希望有一个主智能体负责全局调度，让其他子智能体完成局部任务，DeepAgents 更合适；
- 如果你希望多个智能体自由讨论、互相启发，AutoGen 更合适；
- 如果你希望提前设计好团队角色和任务流程，CrewAI 更合适。

本课程重点学习 DeepAgents。原因很简单：它的主线更清楚，适合先建立工程化思维：

- 谁负责调度；
- 谁负责执行；
- 谁保存中间信息；
- 谁输出最终结果。

这也和「深度研搜」项目非常匹配。用户提出一个开放问题后，系统需要先规划，再搜索，再分析，再补充，再生成报告。这样的任务天然适合层级模式：主智能体把握全局，子智能体分别处理搜索、阅读、分析、写作等局部工作。

### 5.9 子智能体设计小清单

后续真正配置子智能体时，可以用下面这张清单检查：

| 检查项       | 问自己一句话                                      |
| ------------ | ------------------------------------------------- |
| 职责是否单一 | 它是不是只负责一类清晰任务？                      |
| 描述是否清楚 | 主智能体看完 `description` 后知道什么时候叫它吗？ |
| 工具是否够少 | 它是不是只拿到了必须使用的工具？                  |
| 输出是否好用 | 它返回的是结论，还是一堆未经整理的过程信息？      |
| 成本是否值得 | 这个任务真的值得多调用一次智能体吗？              |
| 日志是否可查 | 出错时能不能看出它接了什么任务、做了什么？        |

如果一个子智能体说不清楚：什么时候调用；输入应该是什么；输出应该是什么；不能做什么。那它就还不是一个好子智能体，只是一个听起来很厉害的名字。

---

**本章小结：**

这一章我们先从项目背景出发，理解了为什么 DeepAgents 会出现在普通 Agent 之后。普通大模型主要解决“回答问题”，工具型 Agent 进一步解决“调用工具”，而 DeepAgents 更关注“复杂任务如何规划、分工、执行和持续推进”。

接着，我们区分了 `LangChain`、`LangGraph` 和 `DeepAgents` 的定位：

- `LangChain` 更偏基础抽象；
- `LangGraph` 更偏确定性工作流编排；
- `DeepAgents` 更偏自主规划和多智能体组织。

然后，我们梳理了 DeepAgents 的四个核心能力：任务规划、上下文管理、子智能体和长期记忆。它们共同服务于一个目标：让智能体能处理更长、更复杂、更开放的任务。

最后，我们重点补齐了子智能体的认知基础：子智能体不是多写几个角色 Prompt，而是通过 `task` 工具被主智能体委派的独立执行单元。它的核心价值在于上下文隔离、能力专业化和可控并行。同时我们建立了一个重要工程判断：多智能体不是越多越好。只有当任务足够开放、存在领域冲突，或者天然需要多方向并行时，才值得承担多智能体带来的成本与调试复杂度。

本章打的是认知基础。下一章会正式进入代码层面，创建第一个 DeepAgent，并学习如何解析 `invoke()` 和 `stream()` 的执行结果；第 3 章再专门展开子智能体的配置、调度和异步执行。