让多个 Agent 分别完成任务并不难难的是让它们按正确的顺序协同工作、遇到异常能处理、需要人工时能停下最后还能把结果可靠地交付给用户。最近这段时间聊 Agent的人越来越多。有的团队在做单 Agent让模型调用几个工具完成查询、分析、内容生成等任务有的团队开始尝试 Multi-Agent把任务拆开交给不同的智能体分别处理还有一些团队已经把 Agent 接进了企业的 CRM、ERP、数据平台和内部业务系统。但真正做过企业级项目的人很快就会碰到一个问题「让多个 Agent 分别完成任务并不难难的是让它们按照正确的顺序协同工作遇到异常能够处理需要人工介入时能够停下来最后还能把结果可靠地交付给用户。」举个例子。业务负责人提出一个需求「帮我分析一下本月销售业绩为什么下滑找出主要原因生成一份分析报告再给出改进建议。」如果把这句话直接交给一个大模型它可能很快就能生成一份看起来像模像样的报告。但仔细想想这份报告真的可靠吗本月销售数据从哪里来使用的是订单金额还是实际回款与上个月比较还是与去年同期比较哪些区域的业绩下滑最明显造成下滑的原因究竟是客户流失、订单减少还是交付延迟这些结论有没有数据支撑再往下走假如分析需要调用三个不同的业务系统其中一个接口超时了另外两个任务已经完成接下来怎么办如果系统发现数据口径不一致是继续生成报告还是暂停下来让人确认这些才是企业级 Agent 真正要解决的问题。所以今天这篇文章不打算继续讨论 Multi-Agent 是什么也不准备简单罗列几个热门框架。我们直接从一套完整的企业级多 Agent 架构出发沿着一项业务任务从提出需求到最终交付的全过程把背后的设计逻辑、关键组件和工程实现讲清楚。一、先看全貌企业级多 Agent 究竟由哪些部分组成先看整张架构图。这张图把整个执行过程划分成五个阶段1.需求输入与意图理解2.任务分解与可用智能体查询3.策略优化与人工确认4.DAG 编排与调度执行5.结果交付系统中有十个主要参与角色用户、前端界面、人机协同接口、意图理解引擎、任务规划器、策略优化器、编排算法引擎、智能体注册中心、Dify 智能体和数据库。第一次看到这张图可能会觉得组件有点多。其实不用急着记住这些名字。理解整个架构关键是先弄清楚三个问题。第一谁负责决定做什么意图理解引擎负责理解用户需求任务规划器负责拆解任务策略优化器负责评估和调整执行方案。第二谁负责真正把任务跑起来编排算法引擎负责组织任务依赖、调度执行、管理运行状态并把具体任务交给匹配的智能体。第三系统如何知道自己有哪些能力可用智能体注册中心维护智能体的能力信息和元数据数据库为注册中心提供持久化存储。执行时编排器再根据任务要求和运行状态选择合适的智能体实例。这三个问题对应了整个系统最重要的三个边界规划与执行分离能力管理与任务调度分离模型推理与业务控制分离为什么要这样设计因为企业级多 Agent 系统并不是把几个模型连接起来就结束了。它更像一个能够动态组织专业能力的任务执行系统。模型负责理解、推理和生成规划模块负责组织任务编排模块负责推动任务向前运行注册中心负责管理可调用的能力人机协同机制则让用户能够在关键节点介入。只有这些部分形成闭环多 Agent 才有机会从演示程序走向生产环境。二、第一阶段意图理解先把用户真正想做的事情搞清楚回到刚才的销售分析需求。用户只说了一句话「帮我分析一下本月销售业绩为什么下滑。」从人的角度看这句话没有什么理解难度。但对于企业系统来说里面隐藏着不少没有明确表达的条件。比如「本月」究竟指哪个时间区间「销售业绩」采用什么统计口径「下滑」是和上个月比较还是和去年同期比较分析范围是整个公司还是某个区域、产品线或销售团队这些信息如果没有处理好后面的任务拆解做得再漂亮也可能从一开始就走错方向。因此企业级 Agent 的第一步不是马上生成答案而是先把自然语言需求转化为结构化意图。1. 意图理解引擎到底做什么在这套架构中意图理解引擎主要承担三项工作。第一项语义分析理解用户希望完成什么任务识别目标、上下文和约束条件。例如用户说「分析本月销售业绩下滑的原因」系统识别出的目标不是简单查询销售额而是分析业绩变化并解释可能的影响因素。这两个目标完全不同。查询销售额可能只需要调用一个数据查询工具分析业绩下滑则可能涉及历史数据对比、指标计算、异常识别和业务原因分析。第二项实体抽取从需求中识别关键业务对象和参数。例如· 业务对象销售业绩· 时间范围本月· 分析目标识别下滑原因· 输出要求分析报告· 后续任务提出改进建议在更复杂的企业场景中实体还可能包括客户编号、订单号、产品编码、组织机构、合同金额和业务状态等。第三项意图分类判断用户请求属于什么类型以及需要哪些能力。例如可以区分数据查询、指标计算、根因分析、文档生成、业务操作、审批申请。意图分类并不一定只靠一个固定的分类模型也可以结合规则、模型输出和上下文进行判断。关键是让后续模块拿到相对明确的任务描述而不是继续猜测用户到底想做什么。2. 信息不完整怎么办让系统主动追问这也是架构图中第一个值得关注的机制意图澄清。假设用户提出「帮我看看本月销售情况。」系统可能需要进一步确认「你希望按订单金额分析还是按实际回款金额分析」用户补充之后前端把信息重新提交给意图理解引擎。引擎结合前面的上下文更新需求再向任务规划器输出结构化意图。这就是图中的 alt分支所表达的过程。它不是一个简单的异常处理分支而是正常业务流程的一部分。当然并不是所有缺失信息都要追问。如果时间范围能够依据明确的业务规则确定系统可以自动补全如果某个参数对结果影响很大又没有可靠的默认值就应该向用户确认。这里有一个很实用的原则「能够依据明确规则补全的信息可以自动处理会显著改变业务结果的信息不要让模型随意猜测。」比如报表默认采用自然月统计而且用户没有提出其他要求那么系统可以使用默认口径但应当把口径明确展示出来。如果企业同时存在订单金额、开票金额和回款金额三种指标就不能随便挑一个当成「销售业绩」。3. 结构化意图应该长什么样实际工程中可以把意图理解结果设计成一份结构化对象。例如...json { goal: 分析销售业绩下滑原因, business_object: 销售业绩, time_range: 本月, analysis_scope: 待确认, metric_definition: 待确认, output_format: 分析报告, follow_up_actions: [ 识别主要影响因素, 提出改进建议 ] }这里的字段只是示例实际项目应根据业务场景设计 Schema。踩坑提示 结构化输出不等于需求已经完全明确。像上面的分析范围和指标口径仍然处于「待确认」状态系统不能因为生成了一份 JSON就把这些问题当成已经解决。真正有价值的是后续规划器能够识别哪些信息已经确定、哪些信息仍然缺失以及哪些约束必须在执行前得到满足。到了这里第一阶段才算真正完成。用户说的是自然语言系统拿到的却是一份可以继续处理的任务描述。三、第二阶段任务规划把一个大需求拆成多个可执行任务意图明确之后接下来就轮到任务规划器了。它需要回答一个问题为了完成用户的目标系统具体要做哪些事还是以销售分析为例。假设用户已经确认采用本月订单金额并要求与上月进行对比。规划器可以把任务拆成以下几个步骤T1 获取本月销售数据T2 获取上月销售数据T3 计算总体及分区域的销售变化T4 识别下滑明显的区域、产品和销售团队T5 结合业务记录分析可能的影响因素T6 汇总分析结果生成报告T7 检查报告中的数据与结论是否一致这时候系统已经不再面对一个模糊的大目标而是面对一组具有明确输入、输出和完成条件的任务。不过任务规划还不只是拆分步骤。更重要的是它必须理解任务之间的依赖关系。1. 任务之间存在依赖不能想当然地依次调用 Agent比如T1 和 T2 分别获取本月、上月的销售数据这两个任务没有直接依赖可以同时执行。T3 要计算销售变化就必须等待 T1 和 T2 完成。T4 要识别哪些区域下滑明显需要使用 T3 的计算结果。T5 可以在相关数据准备完成后进一步结合客户流失、订单取消、交付延迟等业务记录开展分析。最后T6 汇总报告T7 检查数据和结论。把它画出来大致就是这就是有向无环图也就是 DAG 的基本思想。节点表示任务有向边表示依赖关系。它的意义不是把流程画得更漂亮而是让系统知道哪些任务现在就能执行哪些任务还要等待哪些任务可以并行哪些任务必须按顺序推进。2. 为什么不能直接让一个 Agent 自己安排所有事情当然可以把任务规划、工具调用和结果汇总全部交给一个强大的 Agent。对于简单任务这种方式往往更直接成本也更低。但随着任务复杂度增加单个 Agent 可能需要同时维护大量上下文反复判断下一步做什么还要处理不同工具的调用结果。一旦执行过程中出现异常系统就很难清楚地回答哪些任务已经完成哪些结果可以继续使用哪些任务因为依赖未满足而无法执行当前计划是否仍然有效重新规划会不会导致已经完成的工作被重复执行将任务规划与执行调度分开可以让任务结构变得更明确。规划器负责形成计划编排器负责执行计划。执行过程中如果发生变化系统可以根据实际状态决定是否调整计划而不必把所有逻辑都交给模型临时发挥。3. 任务规划器如何知道应该调用哪些 Agent这就引出了架构图中的智能体注册中心。假设系统中已经部署了多个智能体销售数据分析 Agent、客户经营分析 Agent、订单履约分析 Agent、报告生成 Agent、数据质量检查 Agent。规划器要完成销售分析任务就得先知道这些能力是否存在以及它们分别能够处理什么工作。于是它向智能体注册中心查询可用智能体。注册中心再从数据库读取智能体元数据并把符合条件的能力列表返回给规划器。这里值得注意的是任务规划器不必直接查询底层数据库注册中心负责统一管理能力目录和查询入口。这样做有几个好处1.智能体可以动态注册、更新或下线不必把所有能力写死在规划逻辑里2.能力描述可以采用统一格式方便规划器判断任务与智能体之间是否匹配3.注册中心可以集中维护版本、输入输出协议、运行状态等信息为后续调度提供依据当然注册中心不应只是一个保存 Agent 名称的表。真正有用的能力目录还要描述智能体能够做什么、不能做什么、需要什么输入以及它的输出能否被下游任务直接使用。第三阶段策略优化让系统选对执行方案有了初始任务计划为什么还要增加一个策略优化器原因很简单「能够执行的计划不一定是最合适的计划。」假设系统已经知道要完成销售分析需要获取两组数据、计算指标、分析异常并生成报告。但具体怎么执行仍然存在选择空间。数据查询可以调用现成的分析接口也可以调用专门的数据分析 Agent根因分析可以先根据指标进行初步判断也可以进一步检索业务记录报告可以直接生成也可以增加一个独立的质量检查任务。不同方案之间可能存在成本、耗时、结果质量和权限要求上的差异。策略优化器的任务就是在这些约束下判断哪种执行方案更合适。1. 资源评估当前有哪些能力可以使用策略优化器可以参考可用智能体及其能力、当前资源和运行负载、预估执行时间、模型及工具调用成本、任务的质量要求、数据访问和执行权限、任务之间的依赖约束。例如一个简单的数据汇总任务没有必要调用多个复杂的分析 Agent。直接使用已经验证过的数据查询接口可能更快、更稳定。但如果需要解释复杂的业务变化仅仅调用一个查询工具就未必足够。系统应该根据任务本身的复杂程度选择执行方式而不是为了体现多 Agent 架构的复杂性把每个任务都拆给不同的智能体。2. 策略生成找到合适的任务执行路径策略优化器可以从比较简单的实现开始。例如先用规则过滤不符合要求的执行方案再对剩余方案进行评分排序。评分因素可以包括能力匹配度、预估耗时、调用成本、历史执行质量、当前负载、数据与权限约束。对于有严格业务约束的任务权限和必要条件不应该仅仅作为评分项而应该作为硬性约束。一个没有权限的 Agent即使成本更低、响应更快也不应该被选中执行受限操作。工程实现不一定一开始就要使用复杂的优化算法。规则引擎、约束检查和简单的评分机制已经能够覆盖不少实际场景。等任务规模、资源竞争和优化目标变得更复杂再考虑更高级的调度与优化算法也不迟。3. 冲突检测计划有没有明显问题假设规划器安排了两个任务同时修改同一份业务数据或者某个下游任务依赖的输出格式与上游 Agent 实际提供的格式不一致。这些问题如果等到执行阶段才发现就可能造成不必要的失败。因此策略优化器还可以检查任务依赖是否完整、资源约束是否冲突、输入输出是否兼容、执行方案是否符合权限要求、是否存在不合理的并发安排、是否需要增加校验或人工介入节点。这里需要明确一点策略优化器与任务规划器可以有交互也可能在复杂系统中融合成同一个服务。但从架构职责上看把「任务怎么拆」和「采用什么方案执行」分开思考有助于系统设计和问题定位。4. 人机协同有些方案应该先让人看一眼这也是整张图里第二个非常重要的机制。当策略优化器判断任务需要人工确认时它会通过人机协同接口请前端展示候选方案。用户可以确认也可以修改。决策结果再回传给策略优化器之后才进入执行阶段。例如系统发现销售下滑主要集中在某个区域进一步分析需要查询客户流失记录。如果数据访问涉及敏感客户信息或者后续动作可能影响业务状态系统就不能仅凭模型判断直接推进。它可以先向用户展示分析范围、执行步骤和可能影响等待授权或审批。不过人机协同不应该变成每一步都要求用户点确认。对于规则明确、风险较低的操作可以自动执行对于存在歧义的方案可以请求用户选择对于高风险操作则应按照企业权限和审批制度处理。踩坑提示 用户确认方案并不等于后端权限检查已经通过。真正执行时系统仍然要验证当前用户、智能体和工具是否具备相应权限。这样人机协同才不是一个简单的弹窗而是整个执行控制链路中的一环。五、第四阶段DAG 编排真正决定多 Agent 如何协同运行走到这里需求已经理解任务已经拆解执行方案也已经确定。接下来系统终于要开始干活了。这时候编排算法引擎就成为整套架构的核心。它接收策略优化器输出的计划然后负责将计划转换成能够运行的任务图按照依赖关系调度各个任务并把任务分配给合适的智能体。这里有一个很重要的区别任务规划器负责生成任务计划编排算法引擎负责让任务计划在真实环境中运行起来。前者更关注任务结构后者更关注运行状态和执行过程。1. 编排器拿到计划之后要先做什么通常可以拆成几个步骤。STEP 01检查计划检查任务定义是否完整依赖是否合理必要的输入输出约束是否存在。STEP 02构建 DAG把每个任务转换成图中的节点把任务之间的依赖关系转换成有向边。STEP 03识别可执行任务只有在依赖条件满足、执行条件允许的情况下任务才可以进入就绪状态。STEP 04调度任务根据优先级、资源情况、任务约束和并发限制选择下一批可以执行的任务。STEP 05调用智能体为任务选择合适的智能体实例并传入经过校验的任务输入。STEP 06接收结果并更新状态任务返回后编排器记录执行结果判断后续任务是否已经满足执行条件。这些步骤组合起来才是完整的执行链路。2. DAG 解决的是依赖问题不是所有运行时问题很多人在了解 DAG 时容易把它理解成一种万能工作流。实际上DAG 主要解决的是任务之间的依赖关系。它能够清楚表达哪些任务必须等待、哪些任务可以并行但对于运行过程中出现的动态变化还需要其他机制配合。例如某个任务失败需要重试还是终止用户在执行过程中取消任务后续节点怎么办某个 Agent 返回的数据不完整是否需要重新规划人工审批迟迟没有完成整个工作流如何暂停外部业务系统发生变化原来的执行计划是否仍然有效这些问题涉及任务状态管理、异常处理、动态分支、恢复机制和人工介入。因此DAG 是执行编排的重要基础但不是完整的运行时系统。3. Loop为什么图中还要设计一个循环看架构图第四阶段可以看到一个 loop表示编排器会不断遍历任务队列。这个循环可以理解为假设本月销售数据已经获取完成但上月数据接口暂时超时。编排器不一定要让整个流程立即失败。只要任务之间不存在其他阻塞关系系统就可以先推进已经满足条件的任务等待失败任务按既定策略恢复。当两组数据都准备好之后指标计算任务才进入就绪状态。任务完成后编排器更新依赖关系再继续调度后续节点。踩坑提示 这里的循环不意味着反复执行同一个任务。每次调度都应根据任务状态、依赖关系和执行策略决定下一步动作。DAG 描述关系Loop 推动运行二者结合才是可执行的任务机制4. 如何选择最合适的 Agent架构图里有一步选择最优智能体并获取智能体实例。这里的「最优」并不意味着找一个万能 Agent而是为当前任务找到满足约束的执行者。比如当前任务是计算区域销售额就应该选择具备相应数据访问和计算能力的智能体或服务。如果任务是分析客户流失原因就应该选择能够访问相关业务证据、具备分析能力的智能体。系统可以综合考虑能力是否匹配、输入输出协议是否兼容、当前实例是否健康、运行负载是否合适、权限是否满足、成本与耗时是否符合要求。需要特别说明注册中心和编排器的职责并不相同。注册中心负责提供能力信息和实例发现能力编排器根据当前任务、运行状态和调度策略决定使用哪个实例。这种职责分离会让系统更容易扩展和维护。5. 调用 Dify Agent只是执行链路中的一个环节在这张图中编排器最终将任务交给 Dify 智能体执行。这是一种具体的技术实现方式。Dify 可以承载具体的智能体应用处理任务内部的提示词、模型调用、工具使用和工作流逻辑外层编排器则负责跨任务的依赖管理、调度、状态控制和结果汇总。两者解决的问题并不完全相同。外层编排器不必深入控制每个 Agent 内部的全部推理过程但需要知道每个任务何时开始、何时结束、输出是什么以及失败后该如何处理。 图中把执行对象画成 Dify 智能体是为了说明调用关系。实际项目可以接入 Dify 应用、自研 Agent 服务、普通 API 或其他执行器不必把整个架构绑定在某一个框架上。企业级架构真正需要统一的是任务契约、执行状态、错误处理和权限边界而不是所有智能体都必须采用相同的内部实现。六、任务执行失败怎么办这才是多 Agent 工程化真正难的地方前面讲的是一条理想执行链路。但生产环境里任务不可能永远顺利。接口可能超时数据库可能暂时不可用模型可能返回不符合预期的结果外部服务也可能发生限流。如果系统只考虑正常执行路径一旦出现异常就可能陷入反复调用、状态混乱或者结果丢失的问题。因此编排引擎还要具备异常处理能力。1. 先区分失败类型再决定怎么处理不同的失败不能使用同一种处理方式。例如临时性故障网络抖动、短暂限流、部分服务暂时不可用。这类问题可以在满足条件时进行有限重试。输入或业务校验失败任务缺少必要参数或者业务规则不允许继续执行。此时重复调用通常没有意义应当修正输入或转交人工处理。模型输出不合格Agent 返回的结果缺少必填字段或者无法满足下游任务的输入要求。可以根据场景进行格式校验、有限修复或重新生成。权限与安全问题当前用户或执行组件不具备相应权限。此时不能把重试当成解决办法更不能通过更换一个权限更宽松的 Agent 来绕过限制。把错误分类是建立可靠重试机制的第一步。2. 重试之前先考虑幂等性假设某个 Agent 负责生成分析报告调用超时之后重新执行通常问题不大。但如果某个 Agent 负责创建订单、提交付款申请或修改客户等级情况就不一样了。第一次请求可能已经在业务系统中成功执行只是返回结果时发生了超时。如果系统直接重试就可能造成重复操作。因此对于具有业务副作用的任务应设计幂等键、操作记录、执行结果查询等机制在重试前判断操作是否已经完成。「一次调用没有收到成功响应不等于业务操作一定没有成功。」这句话在企业级 Agent 开发中非常重要。3. 一个任务失败不代表整条任务链都要重新执行继续使用销售分析案例。假设获取本月和上月数据的任务都已完成指标计算也已经成功只是在生成报告时发生了临时故障。这时没有必要把前面的数据查询和指标计算全部重新执行。编排器可以保留已经确认有效的任务结果仅恢复失败的报告生成任务。当然前提是前序结果仍然有效且没有发生需要重新计算的业务变化。这就要求系统持久化任务状态和执行结果而不能把所有运行信息都放在一个进程的内存里。生产环境还要考虑任务取消、断点恢复、人工接管和异常审计等问题。如果一项业务任务可能运行很长时间那么可恢复的运行时能力往往比多接入几个 Agent 更有实际价值。七、第五阶段SSE 实时反馈让用户知道任务正在进行企业级 Agent 还有一个容易被忽视的问题用户体验。一个复杂的任务可能需要查询多个系统、执行若干分析步骤再生成最终报告。如果前端只显示一个「正在处理中」用户很难判断系统是否正常运行。更糟糕的是用户可能以为请求已经失败重新提交一次结果系统重复执行了同一项任务。因此架构图中专门设计了 SSE实时推送机制。1. SSE 解决什么问题SSE 是 Server-Sent Events 的缩写通常用于服务端向客户端持续推送事件。在这套架构中编排器在任务执行过程中产生状态变化再将进度事件推送给前端。例如· 任务已经创建· 正在获取销售数据· 本月和上月数据均已返回· 正在计算区域销售变化· 正在分析异常原因· 报告生成完成· 任务执行结束用户看到的就不再是一个静止的加载图标而是任务真实推进的过程。2. 为什么不直接把 Agent 的思考过程全部展示出来企业级系统不应该把模型的内部推理过程直接当成进度展示。用户真正关心的是任务执行到了哪里、哪些工作已经完成、是否遇到问题、是否需要自己做决定。因此更适合推送的是经过整理的任务状态和业务事件而不是未经处理的内部推理文本。例如「已完成本月与上月销售数据获取正在计算各区域业绩变化。」这样的反馈既有实际信息也更适合企业业务场景。3. SSE 不是编排器也不是任务队列这一点容易混淆。SSE 只解决服务端向前端推送事件的问题不负责决定任务的执行顺序也不负责管理任务依赖。真正的任务状态仍应由后端编排系统管理。前端可以通过 SSE 接收事件并更新界面如果连接中断重新连接之后还应该能够根据任务 ID 查询当前状态必要时从已持久化的事件记录中恢复进度展示。同样用户的确认、修改和取消操作通常还需要通过独立的 API 提交给后端。把这些职责分清楚系统才不容易出现前端显示「执行成功」、后端实际却仍在运行的情况。九、结果交付任务跑完了不代表事情就做对了当编排器发现所有必要任务已经结束就可以进入最后的结果交付阶段。但这里有一个问题多个 Agent 都返回了结果是否就意味着最终结果一定可靠显然不是。假设数据分析 Agent 计算出销售额下降了 12%客户分析 Agent 认为主要原因是客户流失而订单分析 Agent 却发现主要变化来自部分大额订单取消。这些结果可能并不矛盾但也不能直接拼接成一份报告就交给用户。系统还需要判断它们之间是否一致结论是否有数据支撑是否存在尚未解决的关键问题。1. 结果汇总需要有统一的输入输出约定每个 Agent 的输出最好都能按照明确的 Schema组织。例如数据分析任务可以输出指标名称、统计口径、时间范围、计算结果、数据来源、异常情况。根因分析任务可以输出观察到的现象、支持该判断的证据、可能的影响因素、判断的局限、仍需确认的问题。这样汇总模块就可以区分事实、分析判断和待验证假设而不是把不同 Agent 的自然语言回答混在一起。2. 关键结论要能够追溯到证据如果报告中写着「本月销售额下降的主要原因是华东地区客户流失。」用户自然会追问依据是什么系统最好能够进一步说明· 采用了什么统计口径· 与哪个时间区间进行了比较· 哪些数据支持这个判断· 相关业务记录来自哪里· 这个结论是否经过交叉验证对于企业场景来说能够解释结论的来源往往比生成一段流畅的文字更重要。3. 任务状态要区分成功、失败和部分完成如果所有必要任务都成功完成系统可以交付完整报告。如果关键数据没有获取到系统就不应该假装已经完成全部分析。可以明确区分成功完成、部分完成、执行失败、等待人工处理、用户主动取消。部分完成时可以交付已经验证的内容同时明确哪些分析尚未完成、原因是什么。这比为了给出一个完整答案而掩盖执行失败要可靠得多。最后编排器将执行完成状态推送给前端前端展示最终结果整个任务链路才算结束。九、这套架构如何真正落地五个容易被忽略的工程问题如果只是画出前面这张架构图实际上并没有解决所有问题。架构设计的价值要看它能否落实为具体的接口、数据模型、状态管理和运行机制。下面这五件事往往决定了系统能否稳定运行。1. 建立统一的任务状态模型先把任务可能经历的状态定义清楚。例如...state-machine CREATED ↓ PLANNING ↓ WAITING_APPROVAL ↓ READY ↓ RUNNING ↓ SUCCEEDED / FAILED实际系统还应根据业务需要增加暂停、取消、部分完成等状态。状态定义只是第一步更重要的是明确状态迁移条件。例如等待审批的任务不能因为调度器误触发就直接执行已成功完成的任务不能被普通重试逻辑重新启动被取消的任务也不能继续无限派生新的子任务。状态机可以放在编排引擎中也可以结合工作流引擎实现。具体技术选型并不是重点重点是系统必须有统一、可验证的状态语义。2. 为每个 Agent 定义统一的执行契约一个 Agent 可以使用 Dify另一个可以是自研服务还有一个可能只是普通的 API。这些实现方式不同没有关系但外层系统需要有一套统一的调用约定。至少应该明确Agent 的能力描述、输入和输出 Schema、任务标识、超时与取消机制、错误码、重试策略、权限要求、版本信息。如果每个 Agent 都有自己的输入格式、错误处理方式和返回语义编排器就会越来越复杂。统一契约的价值是让编排器不必深入理解每个 Agent 的内部实现也能管理它们的生命周期。3. 建立完整的运行轨迹企业系统经常会遇到这样的问题「这次分析为什么得出这个结果」「为什么这个任务比上一次慢了三倍」「究竟是哪个 Agent 返回了错误数据」如果没有统一的运行轨迹这些问题会非常难查。因此可以为一次用户请求生成唯一的任务 ID并把它关联到后续的计划、DAG 节点、智能体调用、工具调用和结果记录。同时记录关键事件、执行耗时、错误信息和必要的模型调用指标。这样工程人员才能定位故障业务人员才能追溯结果系统也才有条件持续优化。日志中涉及客户数据、敏感信息或模型输入输出时还应按照企业的数据保护和访问控制要求进行处理。4. 把权限检查放到真正执行的位置权限不能只在意图理解阶段判断一次。用户在前端提出请求并不代表后续所有 Agent 都天然拥有访问相关系统的权限。即使策略优化器已经选定执行方案具体调用工具和业务接口时仍然要验证当前身份、操作范围和授权条件。尤其是涉及修改业务数据、发起审批、创建订单或执行其他有副作用的操作时必须将授权校验、业务规则和必要审批放在真正执行操作的链路上。踩坑提示 模型给出的参数也不能直接视为可信输入。关键参数应经过 Schema 校验、业务规则校验和必要的数据验证。模型可以提出行动建议但是否允许执行应该由可验证的业务控制机制决定。5. 从小规模工作流开始不要一上来就追求复杂的多 Agent 系统这也是实际落地时很重要的一点。并不是任务拆得越细、Agent 数量越多系统就越先进。每增加一个 Agent都会带来额外的调用成本、延迟、失败概率和上下文传递开销。任务拆分过细甚至可能让系统花在协调上的时间超过真正执行任务的时间。因此建议从一条真实业务链路开始。先明确需求、输入输出、任务依赖和验收标准再判断哪些任务确实需要独立的 Agent哪些用普通 API 或确定性程序就能完成。例如· 数据查询交给受控的数据服务· 指标计算交给经过验证的计算逻辑· 需要综合证据的分析任务交给分析 Agent· 报告生成交给生成类 Agent· 高风险业务操作经过权限与审批控制这样形成的多 Agent 系统才是围绕业务目标设计的而不是为了使用 Multi-Agent 而使用 Multi-Agent。最后再看这张图企业级多 Agent 的核心究竟是什么回头看整张架构图可以发现它真正想表达的并不是十个组件之间的连接关系。更重要的是一条完整的执行链路理解需求 → 规划任务 → 优化策略 → 编排执行 → 交付结果意图理解引擎解决的是「用户究竟想做什么」任务规划器解决的是「为了完成目标需要做哪些事」策略优化器解决的是「采用什么方案更合适」编排算法引擎解决的是「如何按照依赖关系把任务真正跑起来」智能体注册中心解决的是「有哪些能力可以被发现和调用」Dify 智能体或其他执行器负责完成具体任务人机协同机制让用户能够在关键节点澄清需求、确认方案或介入处理工程基础设施数据库、状态管理、权限校验、运行轨迹和异常恢复为整个系统提供持续运行所需的工程基础把这些部分放在一起才是一套相对完整的企业级多 Agent 架构。还有一点值得特别强调「多 Agent 并不是企业级 AI 的必选项任务编排与执行控制才是复杂业务自动化绕不开的问题。」如果一个任务只需要查询数据、调用一个工具并返回结果单 Agent 甚至普通程序可能更合适。如果任务涉及多个专业能力、明确的依赖关系、长时间运行、人工审批和复杂异常处理那么独立的规划与编排机制就会逐渐体现价值。真正值得追求的不是系统里有多少个 Agent也不是架构图画得有多复杂。而是当用户提出一个真实的业务需求时系统能否理解它、拆解它、按照规则执行它并在遇到问题时清楚地知道该怎么办。最后用一句话总结这套架构单个 Agent 解决一次任务调用多 Agent 解决多个专业能力的协同而企业级编排系统要解决的是如何让整项业务任务可控、可追踪、可恢复地走到终点。最后说一句技术成长不只是写代码职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料适合想在职场上走得更远的朋友看看。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。 
长河君 · 2026/10/14 2:12:29 · 阅读 1.2k 万字长文拆解：一套能跑在生产环境的企业级多 Agent 架构到底长什么样？
让多个 Agent 分别完成任务并不难难的是让它们按正确的顺序协同工作、遇到异常能处理、需要人工时能停下最后还能把结果可靠地交付给用户。最近这段时间聊 Agent的人越来越多。有的团队在做单 Agent让模型调用几个工具完成查询、分析、内容生成等任务有的团队开始尝试 Multi-Agent把任务拆开交给不同的智能体分别处理还有一些团队已经把 Agent 接进了企业的 CRM、ERP、数据平台和内部业务系统。但真正做过企业级项目的人很快就会碰到一个问题「让多个 Agent 分别完成任务并不难难的是让它们按照正确的顺序协同工作遇到异常能够处理需要人工介入时能够停下来最后还能把结果可靠地交付给用户。」举个例子。业务负责人提出一个需求「帮我分析一下本月销售业绩为什么下滑找出主要原因生成一份分析报告再给出改进建议。」如果把这句话直接交给一个大模型它可能很快就能生成一份看起来像模像样的报告。但仔细想想这份报告真的可靠吗本月销售数据从哪里来使用的是订单金额还是实际回款与上个月比较还是与去年同期比较哪些区域的业绩下滑最明显造成下滑的原因究竟是客户流失、订单减少还是交付延迟这些结论有没有数据支撑再往下走假如分析需要调用三个不同的业务系统其中一个接口超时了另外两个任务已经完成接下来怎么办如果系统发现数据口径不一致是继续生成报告还是暂停下来让人确认这些才是企业级 Agent 真正要解决的问题。所以今天这篇文章不打算继续讨论 Multi-Agent 是什么也不准备简单罗列几个热门框架。我们直接从一套完整的企业级多 Agent 架构出发沿着一项业务任务从提出需求到最终交付的全过程把背后的设计逻辑、关键组件和工程实现讲清楚。一、先看全貌企业级多 Agent 究竟由哪些部分组成先看整张架构图。这张图把整个执行过程划分成五个阶段1.需求输入与意图理解2.任务分解与可用智能体查询3.策略优化与人工确认4.DAG 编排与调度执行5.结果交付系统中有十个主要参与角色用户、前端界面、人机协同接口、意图理解引擎、任务规划器、策略优化器、编排算法引擎、智能体注册中心、Dify 智能体和数据库。第一次看到这张图可能会觉得组件有点多。其实不用急着记住这些名字。理解整个架构关键是先弄清楚三个问题。第一谁负责决定做什么意图理解引擎负责理解用户需求任务规划器负责拆解任务策略优化器负责评估和调整执行方案。第二谁负责真正把任务跑起来编排算法引擎负责组织任务依赖、调度执行、管理运行状态并把具体任务交给匹配的智能体。第三系统如何知道自己有哪些能力可用智能体注册中心维护智能体的能力信息和元数据数据库为注册中心提供持久化存储。执行时编排器再根据任务要求和运行状态选择合适的智能体实例。这三个问题对应了整个系统最重要的三个边界规划与执行分离能力管理与任务调度分离模型推理与业务控制分离为什么要这样设计因为企业级多 Agent 系统并不是把几个模型连接起来就结束了。它更像一个能够动态组织专业能力的任务执行系统。模型负责理解、推理和生成规划模块负责组织任务编排模块负责推动任务向前运行注册中心负责管理可调用的能力人机协同机制则让用户能够在关键节点介入。只有这些部分形成闭环多 Agent 才有机会从演示程序走向生产环境。二、第一阶段意图理解先把用户真正想做的事情搞清楚回到刚才的销售分析需求。用户只说了一句话「帮我分析一下本月销售业绩为什么下滑。」从人的角度看这句话没有什么理解难度。但对于企业系统来说里面隐藏着不少没有明确表达的条件。比如「本月」究竟指哪个时间区间「销售业绩」采用什么统计口径「下滑」是和上个月比较还是和去年同期比较分析范围是整个公司还是某个区域、产品线或销售团队这些信息如果没有处理好后面的任务拆解做得再漂亮也可能从一开始就走错方向。因此企业级 Agent 的第一步不是马上生成答案而是先把自然语言需求转化为结构化意图。1. 意图理解引擎到底做什么在这套架构中意图理解引擎主要承担三项工作。第一项语义分析理解用户希望完成什么任务识别目标、上下文和约束条件。例如用户说「分析本月销售业绩下滑的原因」系统识别出的目标不是简单查询销售额而是分析业绩变化并解释可能的影响因素。这两个目标完全不同。查询销售额可能只需要调用一个数据查询工具分析业绩下滑则可能涉及历史数据对比、指标计算、异常识别和业务原因分析。第二项实体抽取从需求中识别关键业务对象和参数。例如· 业务对象销售业绩· 时间范围本月· 分析目标识别下滑原因· 输出要求分析报告· 后续任务提出改进建议在更复杂的企业场景中实体还可能包括客户编号、订单号、产品编码、组织机构、合同金额和业务状态等。第三项意图分类判断用户请求属于什么类型以及需要哪些能力。例如可以区分数据查询、指标计算、根因分析、文档生成、业务操作、审批申请。意图分类并不一定只靠一个固定的分类模型也可以结合规则、模型输出和上下文进行判断。关键是让后续模块拿到相对明确的任务描述而不是继续猜测用户到底想做什么。2. 信息不完整怎么办让系统主动追问这也是架构图中第一个值得关注的机制意图澄清。假设用户提出「帮我看看本月销售情况。」系统可能需要进一步确认「你希望按订单金额分析还是按实际回款金额分析」用户补充之后前端把信息重新提交给意图理解引擎。引擎结合前面的上下文更新需求再向任务规划器输出结构化意图。这就是图中的 alt分支所表达的过程。它不是一个简单的异常处理分支而是正常业务流程的一部分。当然并不是所有缺失信息都要追问。如果时间范围能够依据明确的业务规则确定系统可以自动补全如果某个参数对结果影响很大又没有可靠的默认值就应该向用户确认。这里有一个很实用的原则「能够依据明确规则补全的信息可以自动处理会显著改变业务结果的信息不要让模型随意猜测。」比如报表默认采用自然月统计而且用户没有提出其他要求那么系统可以使用默认口径但应当把口径明确展示出来。如果企业同时存在订单金额、开票金额和回款金额三种指标就不能随便挑一个当成「销售业绩」。3. 结构化意图应该长什么样实际工程中可以把意图理解结果设计成一份结构化对象。例如...json { goal: 分析销售业绩下滑原因, business_object: 销售业绩, time_range: 本月, analysis_scope: 待确认, metric_definition: 待确认, output_format: 分析报告, follow_up_actions: [ 识别主要影响因素, 提出改进建议 ] }这里的字段只是示例实际项目应根据业务场景设计 Schema。踩坑提示 结构化输出不等于需求已经完全明确。像上面的分析范围和指标口径仍然处于「待确认」状态系统不能因为生成了一份 JSON就把这些问题当成已经解决。真正有价值的是后续规划器能够识别哪些信息已经确定、哪些信息仍然缺失以及哪些约束必须在执行前得到满足。到了这里第一阶段才算真正完成。用户说的是自然语言系统拿到的却是一份可以继续处理的任务描述。三、第二阶段任务规划把一个大需求拆成多个可执行任务意图明确之后接下来就轮到任务规划器了。它需要回答一个问题为了完成用户的目标系统具体要做哪些事还是以销售分析为例。假设用户已经确认采用本月订单金额并要求与上月进行对比。规划器可以把任务拆成以下几个步骤T1 获取本月销售数据T2 获取上月销售数据T3 计算总体及分区域的销售变化T4 识别下滑明显的区域、产品和销售团队T5 结合业务记录分析可能的影响因素T6 汇总分析结果生成报告T7 检查报告中的数据与结论是否一致这时候系统已经不再面对一个模糊的大目标而是面对一组具有明确输入、输出和完成条件的任务。不过任务规划还不只是拆分步骤。更重要的是它必须理解任务之间的依赖关系。1. 任务之间存在依赖不能想当然地依次调用 Agent比如T1 和 T2 分别获取本月、上月的销售数据这两个任务没有直接依赖可以同时执行。T3 要计算销售变化就必须等待 T1 和 T2 完成。T4 要识别哪些区域下滑明显需要使用 T3 的计算结果。T5 可以在相关数据准备完成后进一步结合客户流失、订单取消、交付延迟等业务记录开展分析。最后T6 汇总报告T7 检查数据和结论。把它画出来大致就是这就是有向无环图也就是 DAG 的基本思想。节点表示任务有向边表示依赖关系。它的意义不是把流程画得更漂亮而是让系统知道哪些任务现在就能执行哪些任务还要等待哪些任务可以并行哪些任务必须按顺序推进。2. 为什么不能直接让一个 Agent 自己安排所有事情当然可以把任务规划、工具调用和结果汇总全部交给一个强大的 Agent。对于简单任务这种方式往往更直接成本也更低。但随着任务复杂度增加单个 Agent 可能需要同时维护大量上下文反复判断下一步做什么还要处理不同工具的调用结果。一旦执行过程中出现异常系统就很难清楚地回答哪些任务已经完成哪些结果可以继续使用哪些任务因为依赖未满足而无法执行当前计划是否仍然有效重新规划会不会导致已经完成的工作被重复执行将任务规划与执行调度分开可以让任务结构变得更明确。规划器负责形成计划编排器负责执行计划。执行过程中如果发生变化系统可以根据实际状态决定是否调整计划而不必把所有逻辑都交给模型临时发挥。3. 任务规划器如何知道应该调用哪些 Agent这就引出了架构图中的智能体注册中心。假设系统中已经部署了多个智能体销售数据分析 Agent、客户经营分析 Agent、订单履约分析 Agent、报告生成 Agent、数据质量检查 Agent。规划器要完成销售分析任务就得先知道这些能力是否存在以及它们分别能够处理什么工作。于是它向智能体注册中心查询可用智能体。注册中心再从数据库读取智能体元数据并把符合条件的能力列表返回给规划器。这里值得注意的是任务规划器不必直接查询底层数据库注册中心负责统一管理能力目录和查询入口。这样做有几个好处1.智能体可以动态注册、更新或下线不必把所有能力写死在规划逻辑里2.能力描述可以采用统一格式方便规划器判断任务与智能体之间是否匹配3.注册中心可以集中维护版本、输入输出协议、运行状态等信息为后续调度提供依据当然注册中心不应只是一个保存 Agent 名称的表。真正有用的能力目录还要描述智能体能够做什么、不能做什么、需要什么输入以及它的输出能否被下游任务直接使用。第三阶段策略优化让系统选对执行方案有了初始任务计划为什么还要增加一个策略优化器原因很简单「能够执行的计划不一定是最合适的计划。」假设系统已经知道要完成销售分析需要获取两组数据、计算指标、分析异常并生成报告。但具体怎么执行仍然存在选择空间。数据查询可以调用现成的分析接口也可以调用专门的数据分析 Agent根因分析可以先根据指标进行初步判断也可以进一步检索业务记录报告可以直接生成也可以增加一个独立的质量检查任务。不同方案之间可能存在成本、耗时、结果质量和权限要求上的差异。策略优化器的任务就是在这些约束下判断哪种执行方案更合适。1. 资源评估当前有哪些能力可以使用策略优化器可以参考可用智能体及其能力、当前资源和运行负载、预估执行时间、模型及工具调用成本、任务的质量要求、数据访问和执行权限、任务之间的依赖约束。例如一个简单的数据汇总任务没有必要调用多个复杂的分析 Agent。直接使用已经验证过的数据查询接口可能更快、更稳定。但如果需要解释复杂的业务变化仅仅调用一个查询工具就未必足够。系统应该根据任务本身的复杂程度选择执行方式而不是为了体现多 Agent 架构的复杂性把每个任务都拆给不同的智能体。2. 策略生成找到合适的任务执行路径策略优化器可以从比较简单的实现开始。例如先用规则过滤不符合要求的执行方案再对剩余方案进行评分排序。评分因素可以包括能力匹配度、预估耗时、调用成本、历史执行质量、当前负载、数据与权限约束。对于有严格业务约束的任务权限和必要条件不应该仅仅作为评分项而应该作为硬性约束。一个没有权限的 Agent即使成本更低、响应更快也不应该被选中执行受限操作。工程实现不一定一开始就要使用复杂的优化算法。规则引擎、约束检查和简单的评分机制已经能够覆盖不少实际场景。等任务规模、资源竞争和优化目标变得更复杂再考虑更高级的调度与优化算法也不迟。3. 冲突检测计划有没有明显问题假设规划器安排了两个任务同时修改同一份业务数据或者某个下游任务依赖的输出格式与上游 Agent 实际提供的格式不一致。这些问题如果等到执行阶段才发现就可能造成不必要的失败。因此策略优化器还可以检查任务依赖是否完整、资源约束是否冲突、输入输出是否兼容、执行方案是否符合权限要求、是否存在不合理的并发安排、是否需要增加校验或人工介入节点。这里需要明确一点策略优化器与任务规划器可以有交互也可能在复杂系统中融合成同一个服务。但从架构职责上看把「任务怎么拆」和「采用什么方案执行」分开思考有助于系统设计和问题定位。4. 人机协同有些方案应该先让人看一眼这也是整张图里第二个非常重要的机制。当策略优化器判断任务需要人工确认时它会通过人机协同接口请前端展示候选方案。用户可以确认也可以修改。决策结果再回传给策略优化器之后才进入执行阶段。例如系统发现销售下滑主要集中在某个区域进一步分析需要查询客户流失记录。如果数据访问涉及敏感客户信息或者后续动作可能影响业务状态系统就不能仅凭模型判断直接推进。它可以先向用户展示分析范围、执行步骤和可能影响等待授权或审批。不过人机协同不应该变成每一步都要求用户点确认。对于规则明确、风险较低的操作可以自动执行对于存在歧义的方案可以请求用户选择对于高风险操作则应按照企业权限和审批制度处理。踩坑提示 用户确认方案并不等于后端权限检查已经通过。真正执行时系统仍然要验证当前用户、智能体和工具是否具备相应权限。这样人机协同才不是一个简单的弹窗而是整个执行控制链路中的一环。五、第四阶段DAG 编排真正决定多 Agent 如何协同运行走到这里需求已经理解任务已经拆解执行方案也已经确定。接下来系统终于要开始干活了。这时候编排算法引擎就成为整套架构的核心。它接收策略优化器输出的计划然后负责将计划转换成能够运行的任务图按照依赖关系调度各个任务并把任务分配给合适的智能体。这里有一个很重要的区别任务规划器负责生成任务计划编排算法引擎负责让任务计划在真实环境中运行起来。前者更关注任务结构后者更关注运行状态和执行过程。1. 编排器拿到计划之后要先做什么通常可以拆成几个步骤。STEP 01检查计划检查任务定义是否完整依赖是否合理必要的输入输出约束是否存在。STEP 02构建 DAG把每个任务转换成图中的节点把任务之间的依赖关系转换成有向边。STEP 03识别可执行任务只有在依赖条件满足、执行条件允许的情况下任务才可以进入就绪状态。STEP 04调度任务根据优先级、资源情况、任务约束和并发限制选择下一批可以执行的任务。STEP 05调用智能体为任务选择合适的智能体实例并传入经过校验的任务输入。STEP 06接收结果并更新状态任务返回后编排器记录执行结果判断后续任务是否已经满足执行条件。这些步骤组合起来才是完整的执行链路。2. DAG 解决的是依赖问题不是所有运行时问题很多人在了解 DAG 时容易把它理解成一种万能工作流。实际上DAG 主要解决的是任务之间的依赖关系。它能够清楚表达哪些任务必须等待、哪些任务可以并行但对于运行过程中出现的动态变化还需要其他机制配合。例如某个任务失败需要重试还是终止用户在执行过程中取消任务后续节点怎么办某个 Agent 返回的数据不完整是否需要重新规划人工审批迟迟没有完成整个工作流如何暂停外部业务系统发生变化原来的执行计划是否仍然有效这些问题涉及任务状态管理、异常处理、动态分支、恢复机制和人工介入。因此DAG 是执行编排的重要基础但不是完整的运行时系统。3. Loop为什么图中还要设计一个循环看架构图第四阶段可以看到一个 loop表示编排器会不断遍历任务队列。这个循环可以理解为假设本月销售数据已经获取完成但上月数据接口暂时超时。编排器不一定要让整个流程立即失败。只要任务之间不存在其他阻塞关系系统就可以先推进已经满足条件的任务等待失败任务按既定策略恢复。当两组数据都准备好之后指标计算任务才进入就绪状态。任务完成后编排器更新依赖关系再继续调度后续节点。踩坑提示 这里的循环不意味着反复执行同一个任务。每次调度都应根据任务状态、依赖关系和执行策略决定下一步动作。DAG 描述关系Loop 推动运行二者结合才是可执行的任务机制4. 如何选择最合适的 Agent架构图里有一步选择最优智能体并获取智能体实例。这里的「最优」并不意味着找一个万能 Agent而是为当前任务找到满足约束的执行者。比如当前任务是计算区域销售额就应该选择具备相应数据访问和计算能力的智能体或服务。如果任务是分析客户流失原因就应该选择能够访问相关业务证据、具备分析能力的智能体。系统可以综合考虑能力是否匹配、输入输出协议是否兼容、当前实例是否健康、运行负载是否合适、权限是否满足、成本与耗时是否符合要求。需要特别说明注册中心和编排器的职责并不相同。注册中心负责提供能力信息和实例发现能力编排器根据当前任务、运行状态和调度策略决定使用哪个实例。这种职责分离会让系统更容易扩展和维护。5. 调用 Dify Agent只是执行链路中的一个环节在这张图中编排器最终将任务交给 Dify 智能体执行。这是一种具体的技术实现方式。Dify 可以承载具体的智能体应用处理任务内部的提示词、模型调用、工具使用和工作流逻辑外层编排器则负责跨任务的依赖管理、调度、状态控制和结果汇总。两者解决的问题并不完全相同。外层编排器不必深入控制每个 Agent 内部的全部推理过程但需要知道每个任务何时开始、何时结束、输出是什么以及失败后该如何处理。 图中把执行对象画成 Dify 智能体是为了说明调用关系。实际项目可以接入 Dify 应用、自研 Agent 服务、普通 API 或其他执行器不必把整个架构绑定在某一个框架上。企业级架构真正需要统一的是任务契约、执行状态、错误处理和权限边界而不是所有智能体都必须采用相同的内部实现。六、任务执行失败怎么办这才是多 Agent 工程化真正难的地方前面讲的是一条理想执行链路。但生产环境里任务不可能永远顺利。接口可能超时数据库可能暂时不可用模型可能返回不符合预期的结果外部服务也可能发生限流。如果系统只考虑正常执行路径一旦出现异常就可能陷入反复调用、状态混乱或者结果丢失的问题。因此编排引擎还要具备异常处理能力。1. 先区分失败类型再决定怎么处理不同的失败不能使用同一种处理方式。例如临时性故障网络抖动、短暂限流、部分服务暂时不可用。这类问题可以在满足条件时进行有限重试。输入或业务校验失败任务缺少必要参数或者业务规则不允许继续执行。此时重复调用通常没有意义应当修正输入或转交人工处理。模型输出不合格Agent 返回的结果缺少必填字段或者无法满足下游任务的输入要求。可以根据场景进行格式校验、有限修复或重新生成。权限与安全问题当前用户或执行组件不具备相应权限。此时不能把重试当成解决办法更不能通过更换一个权限更宽松的 Agent 来绕过限制。把错误分类是建立可靠重试机制的第一步。2. 重试之前先考虑幂等性假设某个 Agent 负责生成分析报告调用超时之后重新执行通常问题不大。但如果某个 Agent 负责创建订单、提交付款申请或修改客户等级情况就不一样了。第一次请求可能已经在业务系统中成功执行只是返回结果时发生了超时。如果系统直接重试就可能造成重复操作。因此对于具有业务副作用的任务应设计幂等键、操作记录、执行结果查询等机制在重试前判断操作是否已经完成。「一次调用没有收到成功响应不等于业务操作一定没有成功。」这句话在企业级 Agent 开发中非常重要。3. 一个任务失败不代表整条任务链都要重新执行继续使用销售分析案例。假设获取本月和上月数据的任务都已完成指标计算也已经成功只是在生成报告时发生了临时故障。这时没有必要把前面的数据查询和指标计算全部重新执行。编排器可以保留已经确认有效的任务结果仅恢复失败的报告生成任务。当然前提是前序结果仍然有效且没有发生需要重新计算的业务变化。这就要求系统持久化任务状态和执行结果而不能把所有运行信息都放在一个进程的内存里。生产环境还要考虑任务取消、断点恢复、人工接管和异常审计等问题。如果一项业务任务可能运行很长时间那么可恢复的运行时能力往往比多接入几个 Agent 更有实际价值。七、第五阶段SSE 实时反馈让用户知道任务正在进行企业级 Agent 还有一个容易被忽视的问题用户体验。一个复杂的任务可能需要查询多个系统、执行若干分析步骤再生成最终报告。如果前端只显示一个「正在处理中」用户很难判断系统是否正常运行。更糟糕的是用户可能以为请求已经失败重新提交一次结果系统重复执行了同一项任务。因此架构图中专门设计了 SSE实时推送机制。1. SSE 解决什么问题SSE 是 Server-Sent Events 的缩写通常用于服务端向客户端持续推送事件。在这套架构中编排器在任务执行过程中产生状态变化再将进度事件推送给前端。例如· 任务已经创建· 正在获取销售数据· 本月和上月数据均已返回· 正在计算区域销售变化· 正在分析异常原因· 报告生成完成· 任务执行结束用户看到的就不再是一个静止的加载图标而是任务真实推进的过程。2. 为什么不直接把 Agent 的思考过程全部展示出来企业级系统不应该把模型的内部推理过程直接当成进度展示。用户真正关心的是任务执行到了哪里、哪些工作已经完成、是否遇到问题、是否需要自己做决定。因此更适合推送的是经过整理的任务状态和业务事件而不是未经处理的内部推理文本。例如「已完成本月与上月销售数据获取正在计算各区域业绩变化。」这样的反馈既有实际信息也更适合企业业务场景。3. SSE 不是编排器也不是任务队列这一点容易混淆。SSE 只解决服务端向前端推送事件的问题不负责决定任务的执行顺序也不负责管理任务依赖。真正的任务状态仍应由后端编排系统管理。前端可以通过 SSE 接收事件并更新界面如果连接中断重新连接之后还应该能够根据任务 ID 查询当前状态必要时从已持久化的事件记录中恢复进度展示。同样用户的确认、修改和取消操作通常还需要通过独立的 API 提交给后端。把这些职责分清楚系统才不容易出现前端显示「执行成功」、后端实际却仍在运行的情况。九、结果交付任务跑完了不代表事情就做对了当编排器发现所有必要任务已经结束就可以进入最后的结果交付阶段。但这里有一个问题多个 Agent 都返回了结果是否就意味着最终结果一定可靠显然不是。假设数据分析 Agent 计算出销售额下降了 12%客户分析 Agent 认为主要原因是客户流失而订单分析 Agent 却发现主要变化来自部分大额订单取消。这些结果可能并不矛盾但也不能直接拼接成一份报告就交给用户。系统还需要判断它们之间是否一致结论是否有数据支撑是否存在尚未解决的关键问题。1. 结果汇总需要有统一的输入输出约定每个 Agent 的输出最好都能按照明确的 Schema组织。例如数据分析任务可以输出指标名称、统计口径、时间范围、计算结果、数据来源、异常情况。根因分析任务可以输出观察到的现象、支持该判断的证据、可能的影响因素、判断的局限、仍需确认的问题。这样汇总模块就可以区分事实、分析判断和待验证假设而不是把不同 Agent 的自然语言回答混在一起。2. 关键结论要能够追溯到证据如果报告中写着「本月销售额下降的主要原因是华东地区客户流失。」用户自然会追问依据是什么系统最好能够进一步说明· 采用了什么统计口径· 与哪个时间区间进行了比较· 哪些数据支持这个判断· 相关业务记录来自哪里· 这个结论是否经过交叉验证对于企业场景来说能够解释结论的来源往往比生成一段流畅的文字更重要。3. 任务状态要区分成功、失败和部分完成如果所有必要任务都成功完成系统可以交付完整报告。如果关键数据没有获取到系统就不应该假装已经完成全部分析。可以明确区分成功完成、部分完成、执行失败、等待人工处理、用户主动取消。部分完成时可以交付已经验证的内容同时明确哪些分析尚未完成、原因是什么。这比为了给出一个完整答案而掩盖执行失败要可靠得多。最后编排器将执行完成状态推送给前端前端展示最终结果整个任务链路才算结束。九、这套架构如何真正落地五个容易被忽略的工程问题如果只是画出前面这张架构图实际上并没有解决所有问题。架构设计的价值要看它能否落实为具体的接口、数据模型、状态管理和运行机制。下面这五件事往往决定了系统能否稳定运行。1. 建立统一的任务状态模型先把任务可能经历的状态定义清楚。例如...state-machine CREATED ↓ PLANNING ↓ WAITING_APPROVAL ↓ READY ↓ RUNNING ↓ SUCCEEDED / FAILED实际系统还应根据业务需要增加暂停、取消、部分完成等状态。状态定义只是第一步更重要的是明确状态迁移条件。例如等待审批的任务不能因为调度器误触发就直接执行已成功完成的任务不能被普通重试逻辑重新启动被取消的任务也不能继续无限派生新的子任务。状态机可以放在编排引擎中也可以结合工作流引擎实现。具体技术选型并不是重点重点是系统必须有统一、可验证的状态语义。2. 为每个 Agent 定义统一的执行契约一个 Agent 可以使用 Dify另一个可以是自研服务还有一个可能只是普通的 API。这些实现方式不同没有关系但外层系统需要有一套统一的调用约定。至少应该明确Agent 的能力描述、输入和输出 Schema、任务标识、超时与取消机制、错误码、重试策略、权限要求、版本信息。如果每个 Agent 都有自己的输入格式、错误处理方式和返回语义编排器就会越来越复杂。统一契约的价值是让编排器不必深入理解每个 Agent 的内部实现也能管理它们的生命周期。3. 建立完整的运行轨迹企业系统经常会遇到这样的问题「这次分析为什么得出这个结果」「为什么这个任务比上一次慢了三倍」「究竟是哪个 Agent 返回了错误数据」如果没有统一的运行轨迹这些问题会非常难查。因此可以为一次用户请求生成唯一的任务 ID并把它关联到后续的计划、DAG 节点、智能体调用、工具调用和结果记录。同时记录关键事件、执行耗时、错误信息和必要的模型调用指标。这样工程人员才能定位故障业务人员才能追溯结果系统也才有条件持续优化。日志中涉及客户数据、敏感信息或模型输入输出时还应按照企业的数据保护和访问控制要求进行处理。4. 把权限检查放到真正执行的位置权限不能只在意图理解阶段判断一次。用户在前端提出请求并不代表后续所有 Agent 都天然拥有访问相关系统的权限。即使策略优化器已经选定执行方案具体调用工具和业务接口时仍然要验证当前身份、操作范围和授权条件。尤其是涉及修改业务数据、发起审批、创建订单或执行其他有副作用的操作时必须将授权校验、业务规则和必要审批放在真正执行操作的链路上。踩坑提示 模型给出的参数也不能直接视为可信输入。关键参数应经过 Schema 校验、业务规则校验和必要的数据验证。模型可以提出行动建议但是否允许执行应该由可验证的业务控制机制决定。5. 从小规模工作流开始不要一上来就追求复杂的多 Agent 系统这也是实际落地时很重要的一点。并不是任务拆得越细、Agent 数量越多系统就越先进。每增加一个 Agent都会带来额外的调用成本、延迟、失败概率和上下文传递开销。任务拆分过细甚至可能让系统花在协调上的时间超过真正执行任务的时间。因此建议从一条真实业务链路开始。先明确需求、输入输出、任务依赖和验收标准再判断哪些任务确实需要独立的 Agent哪些用普通 API 或确定性程序就能完成。例如· 数据查询交给受控的数据服务· 指标计算交给经过验证的计算逻辑· 需要综合证据的分析任务交给分析 Agent· 报告生成交给生成类 Agent· 高风险业务操作经过权限与审批控制这样形成的多 Agent 系统才是围绕业务目标设计的而不是为了使用 Multi-Agent 而使用 Multi-Agent。最后再看这张图企业级多 Agent 的核心究竟是什么回头看整张架构图可以发现它真正想表达的并不是十个组件之间的连接关系。更重要的是一条完整的执行链路理解需求 → 规划任务 → 优化策略 → 编排执行 → 交付结果意图理解引擎解决的是「用户究竟想做什么」任务规划器解决的是「为了完成目标需要做哪些事」策略优化器解决的是「采用什么方案更合适」编排算法引擎解决的是「如何按照依赖关系把任务真正跑起来」智能体注册中心解决的是「有哪些能力可以被发现和调用」Dify 智能体或其他执行器负责完成具体任务人机协同机制让用户能够在关键节点澄清需求、确认方案或介入处理工程基础设施数据库、状态管理、权限校验、运行轨迹和异常恢复为整个系统提供持续运行所需的工程基础把这些部分放在一起才是一套相对完整的企业级多 Agent 架构。还有一点值得特别强调「多 Agent 并不是企业级 AI 的必选项任务编排与执行控制才是复杂业务自动化绕不开的问题。」如果一个任务只需要查询数据、调用一个工具并返回结果单 Agent 甚至普通程序可能更合适。如果任务涉及多个专业能力、明确的依赖关系、长时间运行、人工审批和复杂异常处理那么独立的规划与编排机制就会逐渐体现价值。真正值得追求的不是系统里有多少个 Agent也不是架构图画得有多复杂。而是当用户提出一个真实的业务需求时系统能否理解它、拆解它、按照规则执行它并在遇到问题时清楚地知道该怎么办。最后用一句话总结这套架构单个 Agent 解决一次任务调用多 Agent 解决多个专业能力的协同而企业级编排系统要解决的是如何让整项业务任务可控、可追踪、可恢复地走到终点。最后说一句技术成长不只是写代码职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料适合想在职场上走得更远的朋友看看。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。