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 的能力演进示意图

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

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

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

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

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

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

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

第二阶段：工具型 Agent

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

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

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

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

第三阶段：DeepAgents 多智能体

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

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

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

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

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

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

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

1
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 解决的是“任务怎么组织”的问题。面对复杂任务时，智能体不再只做一次性回答，而是要具备下面这些能力：

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

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

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

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

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

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

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

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

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

3、DeepAgents 框架定位

3.1 与 LangChain、LangGraph 的关系

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

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

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

DeepAgents、LangGraph、LangChain 的能力栈关系示意图

这张图可以从内到外看：

  • 最内层是 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 三层中的能力对比

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

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

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

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

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

4、DeepAgents 核心能力

4.1 任务规划与任务分解

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

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

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

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

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

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

4.2 上下文管理与文件系统

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

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

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

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

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

4.3 子智能体与上下文隔离

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

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

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

DeepAgents 子智能体通过 task 工具实现上下文隔离的示意图

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

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

4.4 长期记忆

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

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

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

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

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

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

4.5 四个核心能力小结

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

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

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

5、多智能体设计边界

5.1 子智能体定义

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

1
2
3
你是搜索专家。
你是分析专家。
你是写作专家。

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

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

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

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

在 DeepAgents 里也是类似的：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3 子智能体核心价值

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4 子智能体使用边界

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

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

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

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

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

比如：

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

但如果任务是：

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

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

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

不适合场景 为什么不适合 更合适的做法
一步就能完成的小任务 委派本身也要花时间和费用 直接回答或直接调用工具
必须连续阅读的短任务 拆开后反而容易丢上下文 让同一个智能体一次完成
子任务说不清楚 子智能体不知道该返回什么 先写清任务说明和输出格式
只是为了“看起来高级” 会增加成本、日志和失败点 先用单 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 中主调度器拆分任务并汇总输出的示意图

它的流程通常是：

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

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

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

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

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

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

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

协作工作流 Collaborative Network 中生成者与评估者循环反馈的示意图

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

它的缺点是更容易失控。多个 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 章再专门展开子智能体的配置、调度和异步执行。