Workflow、单 Agent、多 Agent，项目到底该选哪个？

Workflow 和 Agent 的主要区别是谁来组织任务的执行过程。

• Workflow 由开发者预先设计主要步骤和转移规则，模型可以在节点里做分类、生成或评价。它也能分支、并行和循环，只是这些处理路径由程序约束。
• Agent 由模型结合目标和执行反馈，持续决定使用什么工具、还需要查什么、何时结束。程序仍会限制它的工具、权限和调用预算。

例如写一份市场报告，按预设来源检索、生成、审核，属于工作流；如果需要模型发现资料冲突后，判断应该补查哪个时间段、换什么来源，就适合引入 Agent。前者更容易约束路径和排查问题，后者能处理难以提前列全的调查过程，但也增加了成本和执行的不确定性。

实际项目可以组合使用：工作流控制固定步骤和审核，Agent 处理其中需要根据新证据调整行动的部分。

ReAct 是把推理与行动交替组织起来的一种 Agent 工作方式：模型结合当前目标和已有信息判断下一步，应用执行工具取得真实反馈，模型再根据反馈继续判断，直到完成任务或触发停止条件。经典表达是 Reasoning → Action → Observation，关键在于观察结果会影响后续行动。

例如研搜任务中，第一次搜索发现资料缺少发布日期，下一步就可以调整关键词或打开原始页面补证据，而不是照着最初的步骤一直生成。现代 Tool Calling Agent 可以用结构化工具调用实现这种循环，不要求把模型完整的内部思考展示出来。以深度研搜项目为例，信息获取采用这种反馈循环，整体还结合任务规划与子 Agent 分工。

我主要看下一步有多依赖新观察、任务是否需要显式维护全局计划，以及延迟和费用预算来选择。

• ReAct 把推理、行动和观察交替起来：根据当前信息选择工具，执行后读反馈，再决定下一步。它适合搜索、排障这类路径难以预先确定的任务，优点是能及时适应新信息；代价是多轮模型与工具往返，长任务也容易重复探索或遗漏整体目标。
• Plan and Execute 先生成可检查的多步骤计划，再由执行器完成子任务，并根据结果判断继续、结束或重规划。它适合目标能拆解、依赖关系较清楚、需要跟踪多项交付的长任务；代价是规划与计划维护本身有开销，初始假设错误时也需要及时调整。

两者可以组合：例如产业调研先规划研究维度和报告交付项，每个维度内部用 ReAct 搜索、读取和补查，再根据执行结果更新计划。显式规划有助于管理全局目标，但不会自动保证更正确、更快或更便宜。如果步骤已经固定，用普通工作流就能完成，也不一定需要再让模型规划。

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

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

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

深度研搜（Python）

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

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

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

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

设计多 Agent 系统，先确定谁负责什么、谁决定下一步、交付什么结果、失败后怎样继续，再选择框架和 Agent 数量。每个角色要能独立完成一个可验收的子目标，单纯把提示词换成几个角色名，不能解决协作问题。

以研搜系统为例，我会采用“主智能体协调、专家取证、统一汇总”的结构：网络、数据库和内部知识库专家分别获取不同来源的信息，主智能体理解目标、派发任务、检查信息是否齐全并组织最终答案。具体把协作落到五件事上：

1. 职责与任务契约：给每个专家明确目标、输入、可用工具、输出格式和完成条件，避免重复检索或遗漏问题。
2. 控制流与依赖：固定步骤由代码编排，不确定的搜索方向交给模型；输入齐备且互不依赖的任务才并行，有依赖的任务按顺序执行。
3. 通信与上下文：传必要背景、结论和证据引用，各自保留局部上下文，不把所有原始对话广播给每个 Agent。
4. 状态与恢复：编排器记录任务状态和产物，约定并行结果如何合并，对超时、重试、总预算和停止条件做硬限制；涉及外部写操作时保证幂等。
5. 汇总与验证：统一检查来源、缺失项和冲突，必要时补查；用任务成功率、事实与引用准确性、延迟和费用评估，确认多 Agent 的收益覆盖协调成本。

模型负责在子目标内探索，编排层负责约束执行和推进状态。这样既能利用专业分工，也能在部分任务失败或意见不一致时有明确处理路径。

多 Agent 通信要先看运行边界和交接内容，不一定都需要网络消息：

1. 同一应用内，可以通过函数参数和返回值委派，也可以由图状态传递信息；每个 Agent 提交自己负责的结果，由编排器按规则合并。
2. 主 Agent 调用子 Agent，通常把目标、约束和必要上下文作为任务输入，子 Agent 返回结论、证据或产物引用。各自完整的内部对话不必互相复制。
3. 跨进程或跨服务，需要把任务和结果序列化，经 API、RPC 或队列传输；独立 Agent 服务之间需要统一能力发现和任务生命周期时，可以采用 A2A。

不论采用哪种方式，都要明确任务 ID、输入版本、状态、错误和结果归属，并处理依赖、超时、重复与晚到结果。消息 ID 用于识别一次消息，业务幂等键用于保护同一个业务操作，两者不能混用。

以研搜参考项目为例，主 Agent 通过框架的 task 工具委派三个自定义业务专家，结果返回主 Agent 汇总；当前链路并没有把专家拆成经消息队列通信的独立服务。

我会分别控制**“选对执行者”和“正确交接、回收当前任务”**。路由准确靠能力边界、信息完整性和评测；消息正确靠可校验的任务契约与运行时状态管理。

• 先判断任务需要什么能力。 按数据来源、操作目标和必要输入匹配 Agent；模型可以做语义分类，程序再校验目标是否存在、能力和权限是否满足。缺少时间范围、对象或统计口径时先澄清；多个角色都可能接手时，补足信息或退回主 Agent 决定，不让它们反复转交。
• 把交接内容说清并绑定身份。 消息携带会话与任务 ID、接收者、输入版本、目标、必要上下文和依赖；返回结果也带任务 ID、状态、数据或产物及依据。只把属于当前任务、满足约定的结果交给汇总者。
• 由运行时处理失败。 设置截止时间和有限重试，识别重复与过期结果；有外部副作用的操作还要实现业务幂等。最后分别检查路由选得对不对，以及消息是否漏收、串任务或重复合并。

例如“统计内部药品销量并结合内部说明解释变化”，销量应交给数据库助手，说明交给知识库助手。仅因出现“药品”就派给网络搜索，即使消息送达也仍是路由错误。

多 Agent 应共享协作所需的任务信息和可交付结果，而不是把所有 Agent 的完整历史放进同一个 Prompt。通常可以分成三部分：

• 任务公共信息：当前目标、有效约束、必要的用户确认、任务版本，以及供执行层使用的身份和资源范围；每个 Agent 按职责读取其中需要的部分。
• 可共享结果：各子任务的完成状态、结论、证据位置、数据时间、产物引用和待解决问题，便于下游继续处理。
• 分支私有内容：各自的详细工具过程、临时草稿和无关历史，默认留在分支内，需要核查时再提供必要证据。

同步时由编排器传入明确的输入快照，子 Agent 返回局部更新；并行结果按分支保存，再由归并节点形成最终结论。对共同修改的字段定义合并或单一写入规则，对旧版本、重复和迟到结果做检查。简单的同进程任务用参数、返回值和 State 就能实现，需要跨进程恢复或并发写入时，再补可靠存储、条件更新或消息机制。

多 Agent 的隔离要落在三处：每个 Agent 看什么、运行状态写到哪里、工具能访问什么。

我会让每个子任务拥有独立的消息历史和局部状态，只接收完成任务需要的目标、约束和证据；用会话、任务、Agent 或分支标识定位检查点、记忆和产物，避免复用可变的全局上下文。协作时通过明确的输入和结果契约交换信息，共享字段由指定角色更新。文件和外部资源的访问范围则由工具执行层校验。

例如两个用户同时生成报告，即使都使用同一套 Agent 定义，也必须分别读取自己的历史、附件和工作目录，结果回到对应请求。独立上下文能减少信息干扰，实际资源安全还需要权限和执行环境保证。