项目为什么选单 Agent、多 Agent 或 Workflow，和其他方案相比有何优势？

核心回答

以下以研搜系统为参考示例：它用 Python 和 DeepAgents 组织一个主 Agent 与三个业务专家，分别访问网络、MySQL 和 RAGFlow，主 Agent 负责理解需求、按需委派、汇总并生成文件。

选择这种主子结构，是因为三类信息获取任务有不同的工具、操作步骤和资料范围，可以形成清楚的子目标；主 Agent 保留最终交付责任。相比把所有规则和工具都交给单 Agent，专业职责更集中，但也增加了任务转述、结果汇总和失败处理的成本。

单 Agent、多 Agent 与 Workflow 不是完全互斥的三选一：前两者主要涉及是否拆分执行者，Workflow 则决定哪些执行路径由程序明确控制。任务简单时用单 Agent；步骤稳定时用函数流程或 Workflow；多个子目标能独立交付、确实需要不同上下文或工具时，再引入多 Agent，并让稳定步骤继续由程序管理。

展开说明

1. 先判断任务的变化发生在哪里

如果用户只是查一份文档，再根据材料回答，一个 Agent 配合检索工具通常就能完成。拆成“检索 Agent、阅读 Agent、回答 Agent”可能只是多传几次相同内容。

如果处理步骤和分支已知，例如取数据、转换格式、校验并导出，Workflow 能明确表达依赖、失败路径和结束条件。节点里可以使用 LLM，但执行顺序不必每次都重新规划。

若任务需要根据新证据选择数据源、继续搜索或改变调查方向，Agent 的动态决策更有价值。进一步拆成多个 Agent，则还要证明子任务边界和独立交付成立，不能把“多步任务”直接等同“多 Agent”。

2. 研搜为什么是三个业务专家，而不是随意增加角色？

这个参考实现的三个自定义专家按数据访问方式划分：网络专家使用搜索工具，数据库专家按表、结构与数据查询步骤工作，RAGFlow 专家访问已配置的知识库助手。主 Agent 直接掌握附件读取、Markdown 生成和 PDF 转换工具。

因此，三个角色对应当前三类专业能力；若出现新的独立数据源或明显不同的任务方法，再决定新增专家还是给现有专家补工具。仅增加一个“思考专家”或“检查专家”，却没有不同的输入、工具和可验收产物，未必值得多一次调用。

用户请求也不必每次经过三个专家。只问公开信息时可以只查询网络；需要对照内部资料时再增加相应来源。独立方向可以考虑并行，有数据依赖的步骤仍应等待上游结果。异步运行入口本身不代表所有专家调用都会同时执行。

3. 哪些地方适合保留明确流程？

“查什么、资料不够时往哪里补查”适合让 Agent 根据当前信息决定；“先有 Markdown 文件才能转换 PDF”则是稳定依赖。可以用函数顺序或 Workflow 控制这些步骤，再让相关 Agent 在节点内完成不确定的分析任务。

如果业务要求某些数据齐全才能生成结论，程序也应检查相应状态，而不是依赖多个 Agent 相互提醒。固定流程和模型决策的边界越清楚，就越容易判断失败来自哪里。

参考代码通过 thread_id 和进程内 checkpointer 延续会话，并按会话组织输出目录。若要支持进程重启后的恢复或更严格的资源权限，需要增加相应存储和执行限制；目录分开不等于具备系统级沙箱。

4. 优势要对应原方案的问题，也要算新增代价

拆分的预期收益可以是：降低单个角色要处理的职责数量、让不同来源各用合适的方法、减少主窗口中的探索细节，或并行处理确实独立的方向。代价则包括上下文转述、主 Agent 汇总、更多模型调用以及部分失败后的协调。

可以用相同任务对照“单 Agent 配全套工具”“当前主子结构”和“步骤明确的工作流方案”，比较答案与证据完整性、任务成功率、耗时和成本。若只是简单问题，拆分后质量没有改善却更慢，就应减少角色或缩短路径；如果几个角色必须频繁同步同一份状态，也可能适合合并。

常见追问

为什么不把所有工具直接给单 Agent？

可以，尤其是工具少、任务简单时。只有当不同工具的说明和使用过程开始互相干扰，或专业任务能独立完成时，拆分才有理由。动态筛选工具、按需加载 Skill 也可能缓解问题，不一定必须增加 Agent。

多 Agent 一定比串行 Workflow 快吗？

不一定。多 Agent 可以串行执行，Workflow 也支持并行。速度取决于依赖关系、并发能力、模型调用量和汇总成本，不能把“多 Agent”直接当成“并发更快”。

用了 LangGraph，就一定是 Workflow 吗？

LangGraph 可以表达固定流程，也能承载模型驱动的工具循环和多 Agent 交接。要看实际节点、边和状态由谁决定，不能只根据框架名判断架构模式。

对应教程

参考资料