你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
当架构师和开发人员设计其工作负载以充分利用语言模型功能时，AI 代理系统变得越来越复杂。 这些系统通常超过了有权访问许多工具和知识源的单个代理的能力。 相反，这些系统使用多代理业务流程可靠地处理复杂协作任务。 本指南介绍多代理体系结构的基本业务流程模式，并帮助你选择符合特定要求的方法。
概述
使用多个 AI 代理时，可以将复杂的问题分解为专门的工作单位或知识单元。 将每个任务分配给具有特定功能的专用 AI 代理。 这些方法反映了人类团队合作中发现的策略。 与整体式单一代理解决方案相比，使用多个代理提供了多种优势。
专业化： 单个代理可以专注于特定的域或功能，从而减少代码和提示复杂性。
可伸缩性： 无需重新设计整个系统即可添加或修改代理。
可维护性： 测试和调试可以专注于单个代理，从而减少这些任务的复杂性。
优化： 每个代理都可以使用不同的模型、任务求解方法、知识、工具和计算来实现其结果。
本指南中的模式演示了协调多个代理以协同工作并取得结果的成熟方法。 每个模式都针对不同类型的协调要求进行优化。 这些 AI 代理业务流程模式通过解决协调 AI 驱动工作负载功能中自主组件的独特挑战，来补充和扩展传统的 云设计模式 。
顺序编排
顺序编排模式以预定义的线性顺序连接 AI 代理。 每个代理都在序列中处理上一个代理的输出，这会创建专用转换的管道。
顺序编排模式解决了需要分步处理的问题，其中每个阶段都建立在上一阶段的基础上。 它适合具有明确依赖项的工作流，并通过渐进式优化提高输出质量。 此模式类似于 管道和筛选器 云设计模式，但它使用 AI 代理，而不是自定义编码的处理组件。 接下来调用哪个代理是在工作流中确定性定义的，进程中的代理不做此选择。
何时使用顺序编排
在以下场景中，请考虑顺序编排模式：
具有明确的线性依赖关系和可预测工作流进度的多阶段进程
数据转换管道，其中每个阶段都会添加下一阶段所依赖的特定值
无法并行化的工作流阶段
渐进式优化要求，如 草稿、审阅、优化 工作流
在这些系统中，你能够了解管道中每个 AI 代理的可用性和性能特征，并且即使某个 AI 代理在处理过程中出现故障或延迟，整体任务依然可以完成。
何时避免顺序编排
在以下方案中避免此模式：
阶段是易并行的。 可以并行化它们，而不会降低质量或导致共享状态冲突。
仅包含少数阶段且单个 AI 代理可有效完成的流程。
早期阶段可能会失败或生成低质量的输出，并且没有合理的方法来防止后续步骤使用累积的错误输出进行处理。
AI 代理需要协作，而不是移交工作。
工作流需要回溯或迭代。
需要基于中间结果的动态路由。
顺序编排示例
律师事务所的文档管理软件使用顺序代理生成合同。 智能应用程序通过四个专用代理的管道处理请求。 顺序和预定义的管道步骤可确保每个代理使用上一阶段的完整输出。
模板选择代理接收客户规范，如合同类型、管辖权和参与方，并从公司库中选择适当的基本模板。
子句自定义代理采用所选模板，并根据协商的业务条款修改标准条款，包括付款计划和责任限制。
法规合规性代理根据适用法律和行业特定的法规审查自定义合同。
风险评估代理对完整的合同执行全面分析。 它评估责任暴露和争端解决机制，同时提供风险评级和保护语言建议。
并发编排
并发业务流程模式在同一任务上同时运行多个 AI 代理。 此方法允许每个代理从其独特的角度或专用化提供独立的分析或处理。
此模式适用于需要对同一问题进行多样见解或方法的场景。 与顺序处理相反，所有代理并行工作，这可减少整个运行时，并提供问题空间的全面覆盖。 这种编排模式类似于扇出/扇入云设计模式。 每个代理的结果通常聚合以返回最终结果，但这不是必需的。 每个代理可以在工作负荷中独立生成自己的结果，例如调用工具来完成任务或并行更新不同的数据存储。
代理独立运行，不会相互传递结果。 代理可以使用自己的业务流程方法作为独立处理的一部分来调用额外的 AI 代理。 可用代理必须知道哪些代理可用于处理。 此模式支持对所有已注册代理的确定性调用，以及根据任务要求调用的代理的动态选择。
何时使用并发编排
在以下场景中，请考虑并发编排模式：
可以使用固定代理集或根据特定任务要求动态选择 AI 代理来并行运行的任务。
受益于多个独立视角或不同专业化的任务，如技术、业务和创意方法，都可能导致相同的问题。 此协作通常发生在具有以下多代理决策技术的方案中：
头脑风暴
集成推理
法定人数和基于投票的决定
在时间敏感的方案中，并行处理可降低延迟。
何时避免并发编排
在以下方案中避免此业务流程模式：
代理需要以特定顺序在彼此的工作基础上构建或需要累积上下文。
该任务需要按照特定顺序进行操作，或确保在规定的序列中运行时能够产生确定的、可重现的结果。
资源约束（如模型配额）使并行处理效率低下或是不可能的。
代理在同时运行时无法可靠地协调对共享状态或外部系统的更改。
没有明确的冲突解决策略来处理来自每个代理的矛盾或冲突结果。
结果聚合逻辑过于复杂或降低结果质量。
并发编排示例
金融服务公司构建了一个智能应用程序，该应用程序使用专用于不同类型的分析的并发代理同时评估同一股票。 每个代理从其专用角度提供见解，为快速投资决策提供多样化的时间敏感输入。
系统通过将相同的刻度符号调度到并行运行的四个专用代理来处理股票分析请求。
基本 分析代理 评估财务表、收入趋势和竞争定位，以评估内在价值。
技术分析代理检查价格模式、成交量指标和势头信号，以确定交易机会。
情绪分析代理处理新闻文章、社交媒体提及和分析师报告，以衡量市场情绪和投资者信心。
环境、社会和治理（ESG）代理审查环境影响、社会责任和治理实践报告，以评估可持续性风险和机会。
然后，这些独立结果合并为全面的投资建议，使投资组合经理能够快速做出明智的决策。
群聊协调
通过群组聊天业务流程模式，多个代理可以通过参与共享对话线程（通过讨论）解决问题、做出决策或验证工作。 聊天管理器通过确定哪些代理可以接下来响应以及管理不同的交互模式（从协作头脑风暴到结构化质量关卡）来协调流程。
此模式解决了通过分组讨论实现决策的最佳方案。 这些场景可能包括协作式创意生成、结构化验证或质量控制流程。 该模式支持各种交互模式，从自由流动的头脑风暴到具有固定角色和审批入口的正式评审工作流。
此模式适用于人机交互场景，其中人类可以选择承担动态聊天管理器职责，并指导对话实现富有成效的结果。 在此业务流程模式中，代理通常处于 只读 模式。 它们不使用工具在正在运行的系统中进行更改。
何时使用群聊编排
当你的场景可以通过自发或引导式协作或迭代的制作者-检查者循环来解决时，请考虑群组聊天协调。 所有这些方法都支持实时人工监督或参与。 由于循环中的所有代理和人类都会将输出发出到单个累积线程中，因此此模式提供透明度和可审核性。
协作场景
创造性的集思广益会话，其中具有不同观点和知识来源的参与者在聊天中相互借鉴
受益于辩论和共识建设的决策过程
需要通过讨论进行迭代优化的决策方案
需要跨职能对话的多学科问题
验证和质量控制方案
涉及结构化评审流程和迭代的质量保证要求
需要多个专家观点的合规性和法规验证
需要编辑评审且在创建和验证之间有明确职责划分的内容创建工作流
何时避免群聊编排
在以下方案中避免此模式：
简单的任务委派或线性管道处理已足够。
实时处理要求使讨论开销不可接受。
更适合不讨论的明确分层决策或确定性工作流。
聊天管理器没有确定任务是否完成的目标方法。
管理聊天流和防止无限循环需要仔细注意，尤其是在更多的代理使控制更难维护时。 若要保持有效的控制，请考虑将群组聊天业务流程限制为三个或更少的代理。
制造者-检查者循环
制作者-检查者循环是一种特定的群组聊天编排，其中一个代理，即制作者，创建或提出某些内容。 另一个代理 （检查器）提供对结果的批评。 此模式是迭代的，检查器代理将会话推送回创建者代理以进行更新并重复该过程。 尽管群聊模式不要求代理轮流聊天，但制作-检查循环需要聊天管理器驱动的正式轮流序列。
群组聊天编排示例
城市公园和娱乐部门使用包括群聊业务流程的软件来评估新的公园开发建议。 该软件阅读了提案草案，多个专家代理就不同的社区影响观点进行辩论，并努力就提案达成共识。 在建议打开社区评审之前，此过程将发生，以帮助预测其可能收到的反馈。
该系统通过启动与专业市政代理人的小组磋商，从多个市政视角处理公园发展建议。
社区参与专员评估可达性要求、预期的居民反馈和使用模式，以确保社区公平访问。
环境规划代理评估生态影响、可持续性措施、本地植被流离失所以及遵守环境法规。
预算和运营代理分析建筑成本、持续维护费用、人员配备要求和长期运营可持续性。
聊天经理促进结构化辩论，代理挑战对方的建议，并捍卫他们的推理。 公园部门员工参与聊天线程，以实时添加见解并响应代理的知识请求。 此过程使员工能够更新原始建议，以解决已确定的问题，并更好地为社区反馈做好准备。
交接协调
专业代理之间的任务交接协调模式允许动态委派任务。 每个代理都可以评估手头的任务，并确定是直接处理任务，还是根据上下文和要求将其传输到更合适的代理。
此模式解决以下场景：任务的最佳代理预先未知，或者任务要求仅在处理过程中才明确。 它支持智能路由，并确保任务到达最有能力的代理。 此模式中的代理通常不能并行工作。 完全控制权从一个代理转移到另一个代理。
何时使用交接编排
请考虑以下方案中的代理移交模式：
需要专业知识或工具但无法预先确定所需代理数或其订单的任务
在处理过程中需要专业知识的情境出现，导致基于内容分析的动态任务分配。
需要不同专家一次操作的多领域问题
逻辑关系和信号，你可以预先确定何时一个代理达到其功能限制，以及哪个代理应处理下一个任务
何时避免交接协调
在以下方案中避免此模式：
适当的代理及其顺序始终预先已知。
任务路由简单且具有确定性地基于规则，而不是基于动态上下文窗口或动态解释。
不理想的路由决策可能会导致用户体验不佳或令人沮丧。
应并行运行多个操作来处理任务。
避免无限交接循环或避免代理之间过度跳转具有挑战性。
代理移交模式示例
电信客户关系管理（CRM）解决方案在其客户支持 Web 门户中使用移交代理。 初始代理开始帮助客户，但在对话过程中发现需要专业知识。 初始代理将任务传递给最合适的代理，以解决客户的担忧。 每次只有一个代理对原始输入进行操作，而交接过程最终结果为单个结果。
在此系统中，分类支持人员解释请求并尝试直接处理常见问题。 达到其限制时，它会将网络问题交给技术基础设施代理，将计费纠纷交给财务解决代理，依此类推。 当当前代理认识到自身能力限制并知道另一个代理可以更好地支持该场景时，这些代理内部会发生进一步的交接。
如果每个代理确定已实现客户成功，或者其他代理无法进一步使客户受益，则每个代理都能够完成对话。 当问题很重要时，某些代理还设计为将用户体验移交给人工支持代理，但目前没有 AI 代理具有解决此问题的功能。
关系图中突出显示了移交实例的一个示例。 首先，分诊代理将任务移交给技术基础设施代理。 然后，技术基础结构代理决定将任务移交给财务解析代理，最终将任务重定向到客户支持。
磁性编排
磁性编排模式专为没有预定方法计划的开放式和复杂问题而设计。 此模式中的代理通常具有允许它们在外部系统中进行直接更改的工具。 重点不仅在于构建和记录解决问题的方法，还在于实施该方法。 任务列表作为工作流的一部分，通过专用代理与磁性管理代理之间的协作进行动态构建和优化。 随着上下文的演变，磁性管理代理会生成一个任务账本，以制定包含目标和子目标的方法计划，最终定稿并加以遵循和跟踪，以实现所需的结果。
管理器代理直接与专用代理通信，以在生成和优化任务账本时收集信息。 它根据需要多次迭代、回溯和委托，以生成可成功执行的完整计划。管理代理经常评估原始请求是完全满足还是出现停滞。 它会更新账本以调整计划。
在某些方面，此业务流程模式是 群组聊天 模式的扩展。 磁性编排模式侧重于构建方法计划的代理，而其他代理使用工具在外部系统中进行更改，而非仅使用其知识存储来达成结果。
何时使用磁性编排
在以下场景中考虑磁性模式：
没有预先确定的解决方案路径的复杂或开放式用例。
考虑来自多个专用代理的输入和反馈以开发有效的解决方案路径的要求。
AI 系统需要生成一个全面的行动计划，供人类在实施之前或之后进行审查。
装备有与外部系统交互、使用外部资源或能够导致运行系统变化的工具的代理。 一个记录在案的计划，展示了这些代理的任务顺序，并可以在允许代理执行任务前展示给用户。
何时避免磁性编排
在以下方案中避免此模式：
解决方案路径已经制定，或者应该以确定的方式进行处理。
无需生成账本。
该任务的复杂性较低，并且更简单的模式可以解决它。
工作时间敏感，因为模式侧重于构建和辩论可行的计划，而不是针对最终结果进行优化。
你预期会出现频繁停滞或没有明确解决路径的无限循环。
磁性协调示例
站点可靠性工程（SRE）团队构建了自动化，并使用磁性编排来处理低风险事件响应方案。 在自动化范围内发生服务中断时，系统必须动态创建和实施修正计划。 它无需事先知道所需的特定步骤即可执行此作。
当自动化系统检测到符合条件的事件时，磁性管理代理会首先创建一个初始任务清单，包含的高级目标包括恢复服务可用性和确定根本原因。 然后，经理代理会与专用代理协商，以收集信息并优化修正计划。
诊断代理分析系统日志、性能指标和错误模式，以确定潜在原因。 它将调查结果报告给管理代理。
根据诊断结果，管理器代理使用特定的调查步骤更新任务账本，并咨询 基础结构代理 以了解当前的系统状态和可用的恢复选项。
通信代理提供利益干系人通知功能，经理代理根据 SRE 团队的升级程序将通信检查点和审批入口纳入不断发展的计划。
随着情境变得更清晰，如果需要部署回退，管理代理可能会将 回滚代理 添加到计划中，或者在事件超出自动化范围时，将其升级给人工 SRE 工程师。
在此过程中，管理器代理会根据新信息持续优化任务账本。 随着事件的发展，它会添加、删除或重新排序任务。 例如，如果诊断代理发现数据库连接问题，管理器代理可能会将整个计划从部署回滚策略切换到专注于还原数据库连接的计划。
管理器代理监视服务恢复中的过度停滞，并防止无限修复循环。 它维护了不断发展的计划和实施步骤的完整审核线索，为事后审查提供了透明度。 这种透明度可确保 SRE 团队可以根据所学到的教训改善工作负荷和自动化。
实施注意事项
实现这些代理设计模式中的任何一种时，必须解决几个注意事项。 查看这些注意事项有助于避免常见的陷阱，并确保代理业务流程可靠、安全且可维护。
单个代理，多工具
如果授予对工具和知识源的足够访问权限，则可以解决单个代理的一些问题。 随着知识源和工具的数量的增加，难以提供可预测的代理体验。 如果单个代理能够可靠地解决你的方案，请考虑采用这种方法。 决策和流程控制的开销通常超过了将任务分解为多个代理的好处。 但是，安全边界、网络视线和其他因素仍会导致单代理方法不可行。
确定性路由
某些模式要求你确定性地在代理之间路由流程。 其他人依赖代理选择路由。 如果代理是在无代码或低代码环境中定义的，则可能无法控制这些行为。 如果使用语义内核等 SDK 在代码中定义代理，则拥有更多控制权。
上下文窗口
AI 代理通常具有有限的上下文窗口。 此约束可能会影响其处理复杂任务的能力。 实现这些模式时，请确定下一个代理需要哪些上下文才能生效。 在某些情况下，需要收集到目前为止的完整的原始上下文。 在其他方案中，汇总或截断的版本更合适。 如果代理在没有累积上下文的情况下工作，并且只需要新的指令集，请采用该方法，而不是提供不有助于完成代理任务的上下文。
可靠性
这些模式需要正常运行的代理和它们之间的可靠转换。 它们通常会导致经典分布式系统问题，例如节点故障、网络分区、消息丢失和级联错误。 应制定缓解策略来解决这些挑战。 代理及其协调者应执行以下步骤。
实现超时和重试机制。
实现平稳降级以处理模式中一个或多个代理出错的情况。
显示错误而不是隐藏它们，以便下游代理和协调逻辑可以适当响应。
考虑代理依赖项的断路器模式。
设计代理时，应尽可能使其与其他代理隔离，并且每个代理不应共享单一故障点。 例如：
确保代理之间的计算隔离。
评估使用单个模型即服务（MaaS）模型或共享知识存储如何在代理并发运行时导致速率限制。
使用 SDK 中提供的检查点功能来帮助从中断的业务流程（例如故障或新代码部署）中恢复。
安全性
在这些设计模式中实现适当的安全机制可以最大程度地降低向攻击或数据泄露公开 AI 系统的风险。 保护代理之间的通信并限制每个代理对敏感数据的访问是关键安全设计策略。 请考虑以下安全措施：
实现身份验证并使用代理之间的安全网络。
考虑代理通信的数据隐私影响。
设计审核线索以满足合规性要求。
设计代理及其编排器以遵循最小权限原则。
考虑如何跨代理处理用户的标识。 代理必须对知识存储具有广泛的访问权限才能处理所有用户的请求，但不能返回用户无法访问的数据。 必须在模式中的每个代理中实现安全剪裁。
可观测性和测试
跨多个代理分发 AI 系统需要单独监视和测试每个代理以及整个系统，以确保正常运行。 设计可观测性和测试策略时，请考虑以下建议：
将所有代理的操作和交接进行记录。 分布式系统故障排除是一项计算机科学挑战，协调的 AI 代理也不例外。
跟踪每个代理的性能和资源使用情况指标，以便可以建立基线、查找瓶颈和优化。
为单个代理设计可测试接口。
为多代理工作流实现集成测试。
常见陷阱和反模式
实现代理业务流程模式时，请避免以下常见错误：
在简单的顺序或并发编排已足够时，使用复杂模式会导致不必要的协调复杂性。
添加不提供有意义专业化的代理。
忽略多跳通信的延迟影响。
在并发代理之间共享可变状态，这可能会导致事务上不一致的数据，因为假设跨代理边界进行同步更新。
对本质上是不确定的工作流使用确定性模式。
对本质上具有确定性的工作流使用不确定模式。
选择并发编排时忽略资源约束。
消耗过多的模型资源，因为上下文窗口会随着代理积累更多信息而增长，代理通过查询它们的模型来在任务上取得进展。
组合编排模式
应用程序有时要求合并多个业务流程模式来满足其要求。 例如，可以将顺序业务流程用于初始数据处理阶段，然后切换到并发业务流程以执行可并行分析任务。 在工作负荷的不同阶段具有不同特征，并且每个阶段都能从采用不同模式中获益的情况下，请勿尝试强行将一个工作流限定为单一模式。
与云设计模式的关系
AI 代理业务流程模式通过应对协调智能自主组件的独特挑战来扩展和补充传统的 云设计模式 。 云设计模式侧重于分布式系统中的结构和行为问题，但 AI 代理业务流程模式专门解决组件与推理功能、学习行为和不确定输出的协调。
Microsoft语义内核中的实现
其中许多模式依赖于基于代码的实现来解决业务流程逻辑。 语义内核中的代理框架支持以下许多 代理业务流程模式：
有关动手实现，请浏览 GitHub 上的 语义内核多代理业务流程示例 ，这些示例在实践中演示了这些模式。 还可以在 AutoGen 中找到其中许多模式，例如 Magentic-One。
Azure AI Foundry 代理服务中的实现
还可以使用 Azure AI Foundry 代理服务 通过其 连接的代理 功能将代理链接在相对简单的工作流中。 使用此服务实现的工作流主要是不确定的，这会限制在此无代码环境中完全实现哪些模式。
供稿人
Microsoft维护本文。 以下参与者撰写了本文。
主要作者：
其他参与者：
- 赫马瓦蒂·阿拉加南达姆 |首席软件工程师
- James Lee |数据科学家 2
- Ritesh Modi | 首席软件工程师
- Mahdi Setayesh | 首席软件工程师
- Mark Taylor | 首席软件工程师
- 亚尼夫·瓦克宁 |高级技术专家
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。