你的项目采用单 Agent 还是多 Agent，分别承担什么职责？

核心回答

下面以一个整合公开资料、企业数据库和内部知识库的研搜助手为参考示例。

项目采用主从式多 Agent：一个主智能体统一面对用户，配置三个自定义业务专家子智能体，按信息来源分工。后端使用 Python 和 FastAPI，DeepAgents 负责主从调度，底层由 LangGraph 承接执行状态；大模型负责理解问题、选择调用和整理结果，Tavily、MySQL、RAGFlow 分别提供真实信息。

• 主智能体：理解目标、拆分任务、选择专家，拿到结果后判断是否还缺信息，最后汇总回答。读取上传文件、生成 Markdown 和转换 PDF 由它调用文件工具完成。
• 网络搜索子智能体：通过 Tavily 搜索公开网页，补充最新公开信息。
• 数据库查询子智能体：先确认表和字段，再生成、执行 SQL，获取结构化业务数据。
• RAGFlow 子智能体：选择合适的知识库助手，查询企业内部的非结构化文档。

例如新能源团队研究某类电池的技术路线与量产进展，主智能体把政策和竞品公告查询交给网络助手，把相关业务统计交给数据库助手，把内部产品资料查询交给 RAGFlow 助手；结果回来后统一解释，再按要求生成文件。拆开的主要原因是三类数据源的工具、查询步骤和上下文不同，能把各领域的细节留在子任务里；代价是多了调度、信息交接和模型调用开销。若需求只有单一知识库问答，一个 Agent 配检索工具通常就足够。

展开说明

选型的依据是任务边界，而不是模型数量

这个例子按信息来源拆分，因为“查公开网页”“查业务表”“查内部文档”的处理过程不同。数据库助手需要表结构和查询结果，网络助手需要网页与搜索记录，把这些原始材料都放进主智能体会挤占上下文，也容易让它混淆工具用途。

子智能体在自己的上下文中选择工具、读取反馈并完成局部任务，主智能体主要接收结果。它和“一个 Agent 挂很多工具”的区别，在于存在独立的任务执行边界；给几次模型调用换上角色名称，并不能体现这种分工。

多 Agent 也不要求多种模型。这个参考实现通过统一配置创建模型，三个业务子智能体没有覆盖 model，因此沿用主智能体的模型。职责差异来自提示词、工具集合和任务上下文。需要进一步控制成本时，可以评估给不同角色配置不同模型，但要比较工具调用、结果质量、延迟和费用，而不是默认小模型一定适合 Worker。

一次调用如何完成交接

主智能体根据子智能体的能力描述，利用框架的 task 工具下发子目标和必要背景。例如给数据库助手的任务应包含统计对象、时间范围和指标口径；给知识库助手的任务应说明要核实哪项产品或制度信息。子智能体执行后把结果交回主智能体，由主智能体决定补查还是汇总，子智能体不分别给用户输出三份最终答案。

数据库查询与文档查询只有在输入已经齐备、互不依赖时才适合并行。如果要先查出产品型号，再检索对应内部资料，就必须先完成前一步。接口采用异步执行、流式推送进度，也不代表每个子任务都会自动并行。

角色分工与权限控制要分别落实

配置不同工具集合可以缩小角色的业务范围，但实际权限仍由工具和数据源执行。例如数据库场景应使用只读账号、查询校验、行数和执行时间限制，不能把“只查询”的提示词当作数据库权限。该参考代码的自定义 SQL 工具直接执行传入语句，进一步加固属于后续工程工作。

示例使用 thread_id 关联会话，用 InMemorySaver 保存进程内状态。它有助于同一会话持续执行；若要在服务重启后恢复任务，还需要持久化检查点和产物记录。WebSocket 用于推送进度，不承担这些状态的持久化。

常见追问

为什么不用一个 Agent，把三个数据源都做成工具？

完全可以作为简单版本。若请求主要落在同一领域，工具选择稳定，单 Agent 的成本和排障负担更小。拆分的理由应是领域上下文、工具选择或独立执行已有明确需求；用相同任务比较成功率、来源准确性、延迟和 Token 消耗，才能判断拆分是否值得。

主智能体和子智能体用相同模型，为什么还算多 Agent？

模型是能力底座，Agent 是围绕目标、指令、上下文和工具组织起来的执行单元。同一个模型可以驱动多个独立子任务；反过来，先后调用两个不同模型，也不自动构成多 Agent 协作。

子智能体返回的结果互相矛盾怎么办？

先比较数据来源、时间范围和统计口径，判断是否确实在回答同一件事。例如数据库返回实际销售记录，内部文档描述计划销量，两者不能直接互相覆盖。主智能体应保留各自依据，补查能验证分歧的证据，仍无法确认时在最终结果中说明缺口。

对应教程

• 深度研搜：项目总览与工程初始化：查看主智能体、三个业务专家和信息来源的对应关系，以及从查询到文件交付的完整流程。
• 深度研搜：主智能体搭建与异步执行：查看文件工具为何由主智能体持有，以及主从组装、会话标识和流式执行如何连接。
• 深度研搜配套源码：主智能体组装：对照 tools、subagents 和 checkpointer 的实际配置，区分业务角色与框架提供的运行能力。

参考资料

• 国内：JavaGuide：多 Agent 协作系统设计：借鉴文中对独立执行边界的划分，解释正文中多 Agent 与多阶段 Prompt Chain 的区别及拆分的代价。
• 国内：zero2Agent：多智能体协作：角色分工、通信机制与冲突仲裁：参考角色分工与结构化交付的设计，说明正文中子 Agent 如何接收必要背景、交付结果，以及单 Agent 与多 Agent 的选型条件。
• 国内：Datawhale：第六章 框架开发实践：借鉴软件开发团队与图式编排案例，区分正文中的角色职责设计和执行顺序安排。
• 国内：zero2Agent：记忆与上下文：参考运行状态、模型上下文和记忆的分工，解释正文中会话标识、检查点与文件产物为什么需要分别管理。
• 国外：LangChain：Deep Agents Subagents：依据子智能体委派、上下文隔离及模型配置约定，解释正文中不同角色为何可以使用同一模型。
• 国外：Anthropic：How we built our multi-agent research system：借鉴主研究者拆分方向、子代理独立取证后汇总的实践，说明正文中并行研究的适用条件与协调成本。