AI 智能体编排模式

当架构师和开发者设计工作负载以充分利用语言模型能力时，AI 智能体（agent）系统会变得越来越复杂。这些系统常常超出单个智能体在可访问许多工具和知识源时的能力。相反，这些系统使用多智能体编排来可靠地处理复杂的协作任务。本指南涵盖多智能体架构的基本编排模式，并帮助你选择适合特定要求的方法。

从合适的复杂度级别开始

在采用多智能体编排模式之前，评估你的场景是否需要它。智能体架构处于复杂度谱系上，每一级都会引入协调开销、延迟和成本。使用能够可靠满足要求的最低复杂度级别。

本指南聚焦多智能体级别的编排模式，那里的协调挑战最为显著。

概述

本指南中的模式展示了编排多个智能体共同工作并完成结果的已验证方法。每种模式针对不同类型的协调要求进行优化。这些 AI 智能体编排模式通过应对在 AI 驱动的工作负载能力中协调自主组件的独特挑战，补充并扩展传统云设计模式。

顺序编排

顺序编排模式把 AI 智能体按预定义的线性顺序串联。序列中的每个智能体处理前一个智能体的输出，从而形成专用转换的管道。

顺序编排模式也称为管道（pipeline）、提示词链（prompt chaining）或线性委派（linear delegation）。

[图：若干带箭头和连接线的部分。箭头从输入指向智能体 1。一条线把智能体 1 连接到写着模型、知识和工具的部分。箭头从智能体 1 指向智能体 2。一条线把智能体 2 连接到写着模型、知识和工具的部分。箭头从智能体 2 指向带省略号的方框。箭头从该方框指向智能体 n。一条线把智能体 n 连接到写着模型、知识和工具的部分。箭头从智能体 n 指向结果。写着公共状态的部分横跨智能体 1 到智能体 n。]

顺序编排模式解决需要逐步处理的问题，其中每个阶段建立在前一阶段之上。它适合具有清晰依赖并通过逐步精炼提高输出质量的工作流。此模式类似于管道和过滤器（Pipes and Filters）云设计模式，但它使用 AI 智能体而不是定制编码的处理组件。下一步调用哪个智能体作为工作流的一部分被确定性地定义，而不是交给流程中的智能体选择。

何时使用顺序编排

在下列场景中考虑顺序编排模式：

• 具有清晰线性依赖和可预测工作流推进的多阶段流程
• 数据转换管道，其中每个阶段增加下一阶段所依赖的特定价值
• 不能并行化的工作流阶段
• 逐步精炼要求，例如草稿、审阅、润色工作流
• 你理解管道中每个 AI 智能体的可用性和性能特征，并且一个 AI 智能体处理中的失败或延迟对于完成整体任务是可容忍的系统

何时避免顺序编排

在下列场景中避免此模式：

• 各阶段极度适合并行。你可以并行化它们，而不损害质量或造成共享状态争用。
• 只包含少数阶段、单个 AI 智能体就能有效完成的流程。
• 早期阶段可能失败或产生低质量输出，并且没有合理方法阻止后续步骤使用累积的错误输出进行处理。
• AI 智能体需要协作而不是交接工作。
• 工作流需要回溯或迭代。
• 你需要基于中间结果的动态路由。

顺序编排示例

一家律师事务所的文档管理软件使用顺序智能体生成合同。该智能应用通过四个专用智能体的管道处理请求。顺序且预定义的管道步骤确保每个智能体使用前一阶段的完整输出工作。

[图：若干带箭头和连接线的部分。箭头从文档创建要求指向模板选择智能体。一条线把模板部分智能体连接到写着模型、模板库和研究工具的部分。箭头从模板选择智能体指向条款定制智能体。一条线把条款定制智能体连接到写着微调模型的部分。箭头从条款定制智能体指向监管合规智能体。一条线把监管合规智能体连接到写着模型、监管知识的部分。箭头从监管合规智能体指向风险评估智能体。一条线把风险评估智能体连接到写着模型、责任知识和持久化工具的部分。箭头从风险评估智能体指向写着拟定文档的部分。写着文档状态的部分横跨条款定制智能体到拟定文档部分。]

• 模板选择智能体接收客户规格，例如合同类型、司法管辖区和相关方，并从事务所资料库中选择适当的基础模板。
• 条款定制智能体取得所选模板，并根据协商的商业条款修改标准条款，包括付款计划和责任限制。
• 监管合规智能体对照适用法律和行业特定法规审阅定制后的合同。
• 风险评估智能体对完整合同进行全面分析。它评估责任敞口和争议解决机制，同时提供风险评级和保护性用语建议。

并发编排

并发编排模式在同一任务上同时运行多个 AI 智能体。这种方法使每个智能体能够从其独特视角或专业领域提供独立分析或处理。

并发编排也称为并行（parallel）、扇出/扇入（fan-out/fan-in）、分散-聚集（scatter-gather）或映射-归约（map-reduce）。

[图：包含三个关键部分。在顶部，箭头从输入指向发起者和收集者智能体。箭头从发起者和收集者智能体指向写着基于合并、比较和选定结果的聚合结果的部分。一条线把发起者和收集者智能体连接到一条通过箭头连接四个部分的线。这些部分是智能体 1、智能体 2、带省略号的未标记部分和智能体 n。箭头从智能体 1 指向中间结果。一条线从智能体 1 指出并分成两路。第一路显示子智能体 1.1 和写着模型、知识和工具的部分。第二路显示子智能体 1.2 和写着模型、知识和工具的部分。箭头从智能体 2 指向中间结果。一条线把智能体 2 连接到写着模型、知识和工具的部分。箭头从带省略号的未标记部分指向中间结果。箭头从智能体 n 指向中间结果。一条线把智能体 n 连接到写着模型、知识和工具的部分。]

此模式应对需要对同一问题获得多样洞察或方法的场景。所有智能体并行工作，而不是顺序处理，从而缩短总体运行时间并全面覆盖问题空间。此编排模式类似于扇出/扇入云设计模式。每个智能体的结果常常被聚合以返回最终结果，但这不是必需的。每个智能体可以在工作负载内独立产生自己的结果，例如调用工具完成任务或并行更新不同的数据存储。需要聚合时，选择适合任务的策略。例如，对分类进行投票或多数规则，对评分建议应用加权合并，或使用语言模型综合的摘要把结果调和成连贯叙述。

智能体独立运行，不互相交接结果。智能体可能使用自己的编排方法调用额外 AI 智能体，作为其独立处理的一部分。编排器必须知道哪些智能体已注册并可用。此模式既支持对所有已注册智能体的确定性调用，也支持根据任务要求动态选择要调用的智能体。

何时使用并发编排

在下列场景中考虑并发编排模式：

• 可以并行运行的任务，既可以使用固定的一组智能体，也可以根据特定任务要求动态选择 AI 智能体。
• 受益于多个独立视角或不同专业领域的任务，例如技术、业务和创意方法，它们都能为同一问题做贡献。这种协作通常发生在具有下列多智能体决策技术的场景中：
• 头脑风暴
• 集成推理
• 法定人数和基于投票的决策
• 并行处理降低延迟的时间敏感场景。

何时避免并发编排

在下列场景中避免此编排模式：

• 智能体需要在彼此工作的基础上推进，或需要按特定顺序累积上下文。
• 任务要求特定操作顺序，或要求按定义顺序运行才能得到确定性、可复现的结果。
• 资源约束，例如模型配额，使并行处理低效或不可能。
• 智能体在同时运行时不能可靠地协调对共享状态或外部系统的变更。
• 没有明确的冲突解决策略来处理每个智能体相互矛盾或冲突的结果。
• 结果聚合逻辑过于复杂，或降低结果质量。

并发编排示例

一家金融服务公司构建了智能应用，使用专长于不同类型分析的并发智能体同时评估同一只股票。每个智能体从其专业视角贡献洞察，为快速投资决策提供多样、时间敏感的输入。

[图：包含三个关键部分。在顶部，箭头从股票代码指向股票分析智能体。一条线把模型、交易所代码映射知识连接到股票分析智能体。箭头从股票分析智能体指向写着基于合并中间结果、带支持证据的决策的部分。一条线把股票分析智能体连接到指向四个独立部分的线。这四路是：基本面分析智能体、技术分析智能体、情绪分析智能体和 ESG 智能体。一条线把模型连接到基本面分析智能体流程。箭头从基本面分析智能体流程指向中间结果。一条线从基本面分析智能体流程指出并分成两路：财务与收入分析智能体，以及竞争分析智能体。一条线把财务与收入分析智能体连接到写着模型、已报告财务知识的部分。一条线把竞争分析智能体连接到写着模型、竞争知识的部分。箭头从技术分析智能体指向中间结果。一条线把技术分析智能体连接到写着微调模型、市场 API 的部分。箭头从情绪分析智能体指向中间结果。一条线把情绪分析智能体连接到写着模型、社交 API、新闻 API 的部分。箭头从 ESG 智能体指向中间结果。一条线把 ESG 智能体连接到写着模型、ESG 知识的部分。]

系统通过把同一股票代码分发给四个并行运行的专用智能体来处理股票分析请求。

• 基本面分析智能体评估财务报表、收入趋势和竞争定位，以评估内在价值。
• 技术分析智能体检查价格形态、成交量指标和动量信号，以识别交易机会。
• 情绪分析智能体处理新闻文章、社交媒体提及和分析师报告，以衡量市场情绪和投资者信心。
• 环境、社会和治理（environmental, social, and governance，ESG）智能体审阅环境影响、社会责任和治理实践报告，以评估可持续性风险和机会。

这些独立结果随后被合并成全面的投资建议，使投资组合经理能够快速做出知情决策。

群聊编排

群聊编排模式使多个智能体通过参与共享对话线程来解决问题、做出决策或验证工作，它们通过讨论进行协作。聊天管理器通过决定哪些智能体可以下一个响应，并管理从协作头脑风暴到结构化质量门的不同交互模式，来协调流程。

群聊编排也称为圆桌（roundtable）、协作（collaborative）、多智能体辩论（multiagent debate）或委员会（council）。

[图：若干带箭头和连接线的部分。箭头从输入指向群聊管理器。箭头从模型开始，经过群聊管理器，指向累积聊天线程。此线下方的部分写着基于累积上下文的新群组指令。一条线连接到写着人类聊天参与者或观察者的部分。箭头从群聊管理器指向智能体 2。双向箭头连接智能体 1、带省略号的未标记方框和智能体 n。一条线连接智能体 1、智能体 2、未标记方框和智能体 n。一条线把智能体 1 连接到模型和知识。一条线把智能体 2 连接到模型和知识。一条线把智能体 n 连接到模型和知识。箭头从写着来自智能体的聊天输出的部分指向累积聊天线程。一条线把累积聊天线程连接到结果。]

此模式应对最适合通过群体讨论达成决策的场景。这些场景可能包括协作构思、结构化验证或质量控制流程。该模式支持多种交互模式，从自由流动的头脑风暴到使用固定角色和批准门的正式审阅工作流。

此模式适合人在回路（human-in-the-loop，HITL）场景，人类可以选择承担动态聊天管理器职责，并把对话引导向有成效的结果。在此编排模式中，智能体通常处于只读模式。它们不使用工具对运行中的系统做出变更。

何时使用群聊编排

当你的场景可以通过自发或引导的协作，或迭代的制作-检查循环来解决时，考虑群聊编排。这些方法都支持实时的人类监督或参与。因为回路中的所有智能体和人类都把输出发到单个累积线程中，此模式提供透明性和可审计性。

#### 协作场景

• 创意头脑风暴会议，具有不同视角和知识源的智能体在聊天中彼此的贡献之上继续构建
• 受益于辩论和建立共识的决策流程
• 需要通过讨论迭代精炼的决策场景
• 需要跨职能对话的多学科问题

#### 验证和质量控制场景

• 涉及结构化审阅流程和迭代的质量保证要求
• 需要多个专家视角的合规和监管验证
• 需要编辑审阅、并在创作与验证之间有清晰关注点分离的内容创建工作流

何时避免群聊编排

在下列场景中避免此模式：

• 基本任务委派或线性管道处理已经足够。
• 实时处理要求使讨论开销不可接受。
• 清晰的层级决策或不经讨论的确定性工作流更为合适。
• 聊天管理器没有客观方法判断任务是否完成。

管理对话流并防止无限循环需要仔细注意，尤其是更多智能体使控制更难维持时。为保持有效控制，考虑把群聊编排限制在三个或更少的智能体。

制作-检查循环

制作-检查循环是群聊编排的一种特定类型：一个智能体，即制作者，创建或提议某事物；另一个智能体，即检查者，对照既定标准评估结果。如果检查者发现缺口或质量问题，它把带有具体反馈的对话推回制作者。制作者修订其输出并重新提交结果。此循环重复，直到检查者批准结果，或编排达到最大迭代限制。虽然群聊模式不要求智能体轮流聊天，制作-检查循环要求由聊天管理器驱动的正式轮次序列。

制作-检查循环也称为评估者-优化器（evaluator-optimizer）、生成者-验证者（generator-verifier）、批评循环（critic loops）或反思循环（reflection loops）。

此模式要求检查者智能体有清晰的验收标准，以便做出一致的通过或失败决定。设置迭代上限以防止无限精炼循环，并定义达到上限时的回退行为。故障转移行为可能包括升级给人类审阅者，或在尽可能好的结果旁附上质量警告。

群聊编排示例

一个城市公园和娱乐部门使用包含群聊编排的软件来评估新的公园开发提案。软件读取提案草稿，多个专家智能体辩论不同的社区影响视角，并努力就提案达成共识。此过程发生在提案开放社区审阅之前，以帮助预判它可能收到的反馈。

[图：若干带箭头和连接线的部分。箭头从公园开发提案指向群聊管理器。一条线从模型开始，经过群聊管理器，指向累积对话。一条线把公园部门员工连接到此线。下方部分写着基于累积上下文和新洞察的指令。箭头从群聊管理器指向环境规划智能体。双向箭头连接社区参与智能体与公园预算和运营智能体。一条线把社区参与智能体连接到环境规划智能体以及公园预算和运营智能体。一条线把社区参与智能体连接到写着模型和市政知识的部分。一条线把环境规划智能体连接到写着模型和当地环境知识的部分。箭头把写着来自市政智能体的聊天输出的部分连接到累积对话。一条线把累积对话连接到公园提案共识。一条线把公园预算和运营智能体连接到写着模型和城市知识的部分。]

系统通过发起与从多个市政视角参与任务的专用市政智能体的群体磋商来处理公园开发提案。

• 社区参与智能体评估无障碍要求、预期居民反馈和使用模式，以确保公平的社区访问。
• 环境规划智能体评估生态影响、可持续性措施、本地植被置换，以及对环境法规的合规。
• 预算和运营智能体分析建设成本、持续维护费用、人员配备要求，以及长期运营可持续性。

聊天管理器促进结构化辩论，智能体质疑彼此的建议并辩护自己的推理。一名公园部门员工参与聊天线程，以实时增加洞察并回应智能体的知识请求。此过程使该员工能够更新原始提案以处理已识别的关切，并更好地为社区反馈做准备。

交接编排

交接编排模式实现专用智能体之间的动态任务委派。每个智能体可以评估手头任务，并决定是直接处理，还是根据上下文和要求把它转移给更合适的智能体。

交接编排也称为路由（routing）、分诊（triage）、转移（transfer）、派遣（dispatch）或委派（delegation）。

[图：显示五个关键部分。智能体 1 部分包括输入、模型和一般知识部分，以及结果。智能体 2 部分包括结果以及模型和知识部分。智能体 3 部分包括模型、知识和工具部分、结果，以及连接到结果的未标记部分。智能体 n 部分包括模型和知识部分以及结果。客户支持员工部分包括结果。弯曲箭头在智能体之间以及到客户支持员工之间流动。]

此模式应对事先不知道任务的最优智能体，或任务要求只在处理过程中才变清楚的场景。它实现智能委派，并确保任务到达最有能力的智能体。此模式中的智能体通常不并行工作。完整控制权从一个智能体转移到另一个智能体。

何时使用交接编排

在下列场景中考虑智能体交接模式：

• 需要专业知识或工具、但所需智能体数量或其顺序不能预先确定的任务
• 专业知识要求在处理过程中出现，从而基于内容分析进行动态任务路由的场景
• 需要不同专家一次一个地操作的多领域问题
• 可以预先确定的逻辑关系和信号，用以表明一个智能体何时达到其能力极限，以及下一个应由哪个智能体处理任务

何时避免交接编排

在下列场景中避免此模式：

• 可以从初始输入识别出适当的智能体或智能体序列。在这种情况下，使用确定性路由或一个不在处理中扮演主动角色的更简单调度器。此调度器先对输入分类，然后把它发送给适当的智能体。
• 任务路由是确定性和基于规则的。它不基于动态上下文窗口或动态解释。
• 次优路由决策可能导致糟糕或令人沮丧的用户体验。
• 应并发运行多个操作来处理任务。
• 避免无限交接循环或避免智能体之间过度来回弹跳是困难的。

智能体交接模式示例

一家电信客户关系管理（customer relationship management，CRM）解决方案在其客户支持 Web 门户中使用交接智能体。初始智能体开始帮助客户，但在对话中发现需要专业知识。初始智能体把任务传给最合适的智能体来处理客户的关切。一次只有一个智能体对原始输入操作，交接链产生单个结果。

[图：包括五个关键部分。分诊支持智能体部分包括模型和一般知识部分、输入和结果。技术基础设施智能体部分包括结果以及模型、基础设施知识和工具部分。财务解决智能体部分包括模型、账单账户知识和账单 API 访问部分，以及结果。账户访问智能体部分包括结果以及模型和客户知识部分。客户支持员工部分包括结果。弯曲箭头在智能体之间以及到客户支持员工之间流动。]

在此系统中，分诊支持智能体解释请求并尝试直接处理常见问题。当它达到极限时，把问题交接给其他智能体。例如，它把网络问题交接给技术基础设施智能体，把账单争议交接给财务解决智能体。当当前智能体认识到自己的能力极限并知道另一个智能体能更好地支持该场景时，这些智能体内部还会发生进一步交接。

如果智能体确定已实现客户成功，或没有其他智能体能进一步使客户受益，每个智能体都能够完成对话。一些智能体也被设计为：当问题重要到必须解决、但当前没有 AI 智能体具备处理它的能力时，把用户体验交接给人类支持座席。

图中突出了一个交接实例。它从分诊智能体开始，把任务交接给技术基础设施智能体。技术基础设施智能体随后决定把任务交接给财务解决智能体，后者最终把任务重定向到客户支持。

Magentic 编排

Magentic 编排模式针对没有预定方法计划的开放且复杂的问题而设计。此模式中的智能体通常拥有帮助它们在外部系统中直接做出变更的工具。重点既在于构建并记录解决问题的方法，也在于实施该方法。任务列表通过专用智能体与 magentic 管理器智能体之间的协作，作为工作流的一部分被动态构建和精炼。随着上下文演变，magentic 管理器智能体构建任务账本，以制定带有目标和子目标的方法计划，该计划最终被定稿、遵循并跟踪，以完成期望的结果。

Magentic 编排也称为动态编排（dynamic orchestration）、基于任务账本的编排（task-ledger-based orchestration）或自适应规划（adaptive planning）。

[图：显示管理器智能体部分。它包括输入和模型。标为调用智能体的箭头从管理器智能体指向智能体 2。标为评估目标循环的箭头指向任务完成部分。标为是的箭头指向结果部分，标为否的箭头指回管理器智能体。箭头从管理器智能体指向任务和进度账本部分。一条线把任务和进度账本部分连接到人类参与者部分。一条带三个箭头的线指向智能体 1、智能体 2、未标记部分和智能体 n。一条线把智能体 1 连接到写着模型和知识的部分。一条线把智能体 2 连接到写着模型、知识和工具的部分。一条线把智能体 n 连接到模型和工具。箭头从写着模型、知识和工具的部分指向外部系统，并从模型和工具部分指向外部系统。]

管理器智能体直接与专用智能体通信，以便在构建和精炼任务账本时收集信息。它按需要多次迭代、回溯和委派，以构建一个能够成功执行的完整计划。管理器智能体定期检查原始请求是已满足还是停滞，并更新账本以调整计划。

在某些方面，此编排模式是群聊模式的扩展。Magentic 编排模式聚焦于构建方法计划的智能体，而其他智能体使用工具在外部系统中做出变更，而不是只使用其知识库来达成结果。

何时使用 Magentic 编排

在下列场景中考虑 magentic 模式：

• 没有预定解决路径的复杂或开放用例。
• 需要考虑来自多个专用智能体的输入和反馈以形成有效解决路径的要求。
• 要求 AI 系统生成可供人类在实施之前或之后审阅的、充分制定的方法计划。
• 配备了与外部系统交互、消耗外部资源或能在运行中的系统中引起变更的工具的智能体。一份显示这些智能体如何排序的文档化计划，可以在允许智能体执行任务之前呈现给用户。

何时避免 Magentic 编排

在下列场景中避免此模式：

• 解决路径已经制定，或应以确定性方式处理。
• 没有产生账本的要求。
• 任务复杂度低，更简单的模式可以解决它。
• 工作对时间敏感。该模式聚焦于构建和辩论可行计划，而不是为速度优化。
• 你预期会频繁停滞或出现没有清晰解决路径的无限循环。

Magentic 编排示例

一个站点可靠性工程（site reliability engineering，SRE）团队构建了使用 magentic 编排处理低风险事件响应场景的自动化。当自动化范围内发生服务中断时，系统必须动态创建并实施补救计划。它在事先不知道所需具体步骤的情况下这样做。

[图：显示包括输入和模型的 SRE 自动化管理器智能体部分。箭头从 SRE 自动化管理器智能体指向任务和进度账本部分。标为调用知识和行动智能体的箭头指向一条指向基础设施、诊断、回滚和沟通智能体的线。标为评估目标循环的箭头从 SRE 自动化管理器智能体指向现场问题已解决部分。标为是的箭头从现场问题已解决指向结果。任务和进度账本部分包括解决方法计划、解决任务状态和现场问题已解决部分。标为否的箭头从现场问题指向 SRE 自动化管理器智能体。一条线从诊断智能体开始，经过模型和日志与指标知识部分，指向工作负载系统。一条线从基础设施智能体开始，经过模型、图知识和 CLI 工具部分，并汇入指向工作负载系统的线。一条线从回滚智能体开始，经过模型、Git 访问、CLI 工具部分，指向工作负载系统。一条线从沟通智能体开始，经过模型和沟通 API 访问部分，指向人类参与者部分。]

当自动化检测到符合条件的事件时，magentic 管理器智能体首先创建带有高层目标的初始任务账本，例如恢复服务可用性和识别根因。管理器智能体随后咨询专用智能体以收集信息并精炼补救计划。

• 诊断智能体分析系统日志、性能指标和错误模式以识别潜在原因。它把发现报告回管理器智能体。
• 基于诊断结果，管理器智能体用具体调查步骤更新任务账本，并咨询基础设施智能体以理解当前系统状态和可用恢复选项。
• 沟通智能体提供利益相关者通知能力，管理器智能体根据 SRE 团队的升级程序，把沟通检查点和批准门纳入不断演变的计划。
• 随着场景变得更清楚，如果需要部署回退，管理器智能体可能把回滚智能体加入计划，或者如果事件超出自动化范围，则升级给人类 SRE 工程师。

在整个过程中，管理器智能体根据新信息持续精炼任务账本。它随着事件演变添加、移除或重排任务。例如，如果诊断智能体发现数据库连接问题，管理器智能体可能把整个计划从部署回滚策略切换为聚焦于恢复数据库连接的计划。

管理器智能体留意恢复服务中的过度停滞，并防范无限补救循环。它维护不断演变的计划和实施步骤的完整审计跟踪，为事件后评审提供透明度。这种透明度确保 SRE 团队可以根据经验教训改进工作负载和自动化。

选择一种模式

下表比较编排模式，以帮助你识别适合协调要求的方法。

实施考虑

为避免常见陷阱，并确保智能体编排稳健、安全且可维护，在实施这些智能体设计模式中的任何一种时审阅下列考虑。

单个智能体、多工具

如果给单个智能体足够的工具和知识源访问，你可以解决一些问题。更多信息请参阅从合适的复杂度级别开始。模型上下文协议（Model Context Protocol）等协议标准化智能体如何发现和调用工具。随着知识源和工具数量增加，提供可预测的智能体体验会变得困难。如果单个智能体能可靠解决你的场景，考虑采用该方法。决策和流控制开销常常超过把任务拆成多个智能体的收益。但是，安全边界、网络视线和其他因素仍可能使单智能体方法不可行。

确定性路由

一些模式要求你确定性地在智能体之间路由流程。另一些依赖智能体选择自己的路由。如果你的智能体定义在无代码或低代码环境中，你可能无法控制这些行为。如果你使用 Microsoft Agent Framework 或 Semantic Kernel 等 SDK 在代码中定义智能体，你有更多控制。

上下文和状态管理

AI 智能体常常有有限的上下文窗口。此约束可能影响它们处理复杂任务的能力，尤其是上下文随着每次智能体转移而增长时。实施这些模式时，决定下一个智能体要有效工作需要什么上下文。在某些场景中，你需要迄今收集的完整原始上下文。在其他场景中，压缩版本，例如先前智能体输出的摘要，更为合适。如果你的智能体可以在没有累积上下文的情况下工作，并且只需要一组新指令，就采用该方法，而不是提供无助于完成智能体任务的上下文。

在多智能体编排中，上下文窗口可能迅速增长，因为每个智能体都添加自己的推理、工具结果和中间输出。监控累积上下文大小，并在智能体之间使用压缩技术，例如摘要或选择性裁剪。这些技术可以帮助你保持在模型限制内，并避免响应质量下降。

对于跨越多次用户交互或长时间运行任务的编排，在外部持久化共享状态，而不是只依赖内存中的上下文。为使智能体能够在中断后恢复工作，把任务进度、中间结果和对话历史存储在持久存储中。为减少令牌开销和隐私风险，把持久化状态限定为最少必要信息。

可靠性

这些模式要求正常运行的智能体以及它们之间可靠的转移。它们常常导致经典分布式系统问题，例如节点故障、网络分区、消息丢失和级联错误。应有缓解策略来应对这些挑战。智能体及其编排器应执行下列步骤。

• 实施超时和重试机制。
• 包含优雅降级实现，以处理模式中一个或多个智能体发生故障。
• 暴露错误而不是隐藏它们，以便下游智能体和编排器逻辑能够适当响应。
• 在把智能体输出传给下一个智能体之前验证它。低置信度、格式错误或离题的响应可能在管道中级联。编排器或接收智能体应检查输出质量，并重试、请求澄清或停止工作流，以避免不良输入传播。
• 考虑对智能体依赖项使用断路器模式。
• 把智能体设计得彼此尽可能隔离，不在智能体之间共享单点故障。例如：
• 确保智能体之间的计算隔离。
• 评估单个模型即服务（models as a service，MaaS）终结点或共享知识库如何在智能体并行运行时引入速率限制。
• 使用 SDK 中可用的检查点功能，以帮助从中断的编排中恢复，例如故障或新的代码部署。

安全性

在这些设计模式中实施适当的安全机制，可尽量降低 AI 系统遭受攻击或数据泄漏的风险。保护智能体之间的通信并限制每个智能体对敏感数据的访问，是关键的安全设计策略。考虑下列安全措施：

• 实施身份验证，并在智能体之间使用安全网络。
• 考虑智能体通信的数据隐私影响。
• 设计审计跟踪以满足合规要求。
• 设计智能体及其编排器以遵循最小权限原则。
• 考虑如何跨智能体处理用户身份。智能体必须对知识库有广泛访问以处理来自所有用户的请求，但它们不得返回用户无法访问的数据。必须在模式中的每个智能体里实施安全裁剪。
• 在编排的多个点应用内容安全护栏，包括用户输入、工具调用、工具响应和最终输出。中间智能体可能引入或传播有害内容。

成本优化

多智能体编排成倍增加模型调用，每个智能体为其指令、上下文、推理和工具交互消耗令牌。你选择的模式直接影响成本。顺序和交接模式逐个调用智能体，这限制并发资源使用，但在每个步骤上累积成本。并发模式提高吞吐量，但当多个智能体同时调用模型时可能使资源消耗激增。Magentic 编排变化最大，因为管理器智能体持续迭代直到构建出可行计划，这使得总成难以预测。

要在多智能体编排中管理成本：

• 为每个智能体分配与其任务复杂度匹配的模型。并非每个智能体都需要能力最强的模型。执行分类、抽取或格式化的智能体常常可以使用更小、更便宜的模型，而不降低整体质量。
• 为识别哪些智能体或模式最昂贵，按智能体和按编排运行监控令牌消耗。使用这些数据来确定优化工作的目标。
• 为减少通过编排传递的令牌量，在智能体之间应用上下文压缩。更多信息请参阅上下文和状态管理。

可观测性与测试

把 AI 系统分布到多个智能体上，需要单独监控和测试每个智能体以及整个系统，以确保功能正常。设计可观测性和测试策略时，考虑下列建议：

• 为所有智能体操作和交接加上检测。排查分布式系统是计算机科学挑战，编排的 AI 智能体也不例外。
• 跟踪每个智能体的性能和资源使用指标，以便建立基线、找到瓶颈并优化。
• 为单个智能体设计可测试的接口。
• 为多智能体工作流实施集成测试。智能体输出是非确定性的，因此使用评分量表或语言模型作为评判的评估，而不是精确匹配断言。

人类参与

若干编排模式支持 HITL 参与。HITL 的形式包括群聊中的观察者、制作-检查循环中的审阅者，以及交接和 magentic 编排中的升级对象。识别哪些点需要人类输入，决定该输入是可选还是强制，并确定人类响应是推进工作流的批准，还是回送给智能体以供精炼的反馈。强制门使编排在该步骤上成为同步的，因此在这些检查点持久化状态，以便恢复操作而不必重放先前的智能体工作。你也可以把 HITL 门限定到特定工具调用，而不是完整的智能体输出，以便编排可以对低风险动作自主进行。在此状态下，仅敏感操作需要批准。

常见陷阱和反模式

实施智能体编排模式时避免这些常见错误：

• 在基本的顺序或并发编排已经足够时，使用复杂模式制造不必要的协调复杂度。
• 添加不提供有意义专业化的智能体。
• 忽视多跳通信的延迟影响。
• 在并发智能体之间共享可变状态，这可能因为假设跨智能体边界的同步更新而导致事务上不一致的数据。
• 对本质上非确定性的工作流使用确定性模式。
• 对本质上确定性的工作流使用非确定性模式。
• 选择并发编排时忽略资源约束。
• 消耗过多模型资源，因为随着智能体累积更多信息并咨询其模型以推进任务，上下文窗口不断增长。

组合编排模式

应用有时要求你组合多种编排模式来满足其要求。例如，你可能对初始数据处理阶段使用顺序编排，然后对可并行的分析任务切换到并发编排。当工作负载的不同阶段具有不同特征，并且每个阶段使用不同模式能受益时，不要试图让一个工作流套进单一模式。

与云设计模式的关系

AI 智能体编排模式通过应对协调具有推理能力、学习行为和非确定性输出的组件这一独特挑战，扩展并补充传统云设计模式。云设计模式聚焦分布式系统中的结构和行为关切，而 AI 智能体编排模式专门应对具有推理能力、学习行为和非确定性输出的组件的协调。

实现

这些编排模式与技术无关。你可以根据语言、基础设施和集成要求，使用各种 SDK 和平台来实现它们。

Agent Framework

Agent Framework 是一个开源 SDK，可以帮助你在 Microsoft 平台上构建多智能体编排。Agent Framework 为下列工作流编排提供内置支持：

• 顺序编排
• 并发编排
• 群聊编排
• 交接编排
• Magentic 编排

提示

这些编排支持用于工作流执行批准和反馈的 HITL 能力。

关于动手实现，请在 GitHub 上查看 Agent Framework 声明式工作流（Agent Framework Declarative Workflows）。

Semantic Kernel 继续提供智能体编排支持。如果你已有 Semantic Kernel 工作负载，请遵循迁移指南过渡到 Agent Framework。

Foundry Agent Service

Foundry Agent Service 通过其已连接智能体功能，提供托管的、无代码的智能体链方法。此服务中的工作流主要是非确定性的，这限制了你可以完整实现的模式范围。当你需要托管环境且编排要求直接时，使用 Agent Service。

其他框架

本文描述的编排模式并非特定于 Microsoft SDK。其他支持多智能体编排的框架包括 LangChain、CrewAI 和 OpenAI Agents SDK。每个框架对模式实现有自己的方法，无论你选择哪个 SDK，都可以应用本文中的架构指导。

贡献者

Microsoft 维护本文。下列贡献者撰写了本文。

主要作者：

• Chad Kittel | Principal Software Engineer - Azure Patterns & Practices
• Clayton Siemens | Principal Content Developer - Azure Patterns & Practices

其他贡献者：

• Hemavathy Alaganandam | Principal Software Engineer
• James Lee | Data Scientist 2
• Ritesh Modi | Principal Software Engineer
• Mahdi Setayesh | Principal Software Engineer
• Mark Taylor | Principal Software Engineer
• Yaniv Vaknin | Senior Technical Specialist

PRIMARY_SOURCE: https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns