Chapter 09
多智能体设计模式
(点击上方图片观看本课视频)
多智能体设计模式
一旦你开始参与一个涉及多个智能体的项目，你就需要考虑多智能体设计模式。然而，何时切换到多智能体，以及它的优势是什么，可能并不立即清楚。
引言
在本课中，我们希望回答以下问题：
- 多智能体适用的场景有哪些？
- 使用多智能体相比单一智能体执行多任务的优势是什么？
- 实现多智能体设计模式的构建模块是什么？
- 我们如何获得多智能体之间相互作用的可视性？
学习目标
学习完本课后，你应该能够：
- 识别多智能体适用的场景
- 认识到多智能体相较于单一智能体的优势
- 理解多智能体设计模式的构建模块
大局观是什么？
多智能体是一种设计模式，允许多个智能体协同工作以实现共同目标。
该模式广泛应用于机器人技术、自动系统和分布式计算等多个领域。
多智能体适用的场景
那么哪些场景适合使用多智能体？答案是，在很多情况下，特别是以下情况，使用多个智能体是有益的：
- 大工作负载：大工作负载可细分为更小任务分配给不同智能体，从而实现并行处理和更快完成。例如大型数据处理任务。
- 复杂任务：复杂任务，如大工作量，可以拆分为更小子任务分配给不同智能体，每个智能体专注任务的特定方面。比如自动驾驶汽车中，不同智能体分别管理导航、障碍检测和与其他车辆通信。
- 多样的专长：不同智能体具备不同的专长，比单一智能体能更有效处理任务的不同方面。一个典型例子是医疗保健，智能体可分别管理诊断、治疗方案和病人监测。
使用多智能体相比单一智能体的优势
单一智能体系统适合简单任务，但对于更复杂的任务，使用多个智能体可带来多种优势：
- 专业化：每个智能体可专注于特定任务。单一智能体专业性不足，面对复杂任务时易混淆，可能会执行不适合自己的任务。
- 可扩展性：增加更多智能体比让单一智能体承担更多任务要更易实现系统扩展。
- 容错性：某个智能体失败时，其他智能体可继续运行，保障系统可靠性。
举个例子，帮用户预订旅游。单一智能体需负责航班查找、酒店和租车预订的所有环节。为实现这一点，智能体需配备处理所有这些任务的工具，导致系统复杂且难以维护和扩展。而多智能体系统中，不同智能体分别专注于航班查找、酒店和租车预订，使系统更加模块化、易维护且可扩展。
这可以类比为普通旅游局与特许经营旅游局的对比。普通旅游局由单一智能体处理所有预订环节，而特许经营局由不同智能体负责不同部分。
实现多智能体设计模式的构建模块
在实施多智能体设计模式之前，需要了解构成该模式的构建模块。
以为用户预订旅游为例，构建模块包括：
- 智能体通信：负责航班、酒店和租车预订的智能体需要交流并共享用户偏好与限制信息。需要决定通信协议和方式。具体来说，航班智能体需与酒店智能体通讯，确保酒店预订时间与航班一致。即需要决定哪些智能体共享信息以及如何共享。
- 协调机制：智能体需协调行动以满足用户偏好和约束。例如用户偏好靠近机场的酒店，而约束是租车只在机场提供，酒店预订智能体需与租车智能体协调，确保满足这些条件。需决定智能体如何协调行动。
- 智能体架构：智能体需具备内部结构以作出决策并从与用户的交互中学习。比如航班智能体需具备决策能力，推荐合适航班。需决定智能体如何决策及学习。例如航班智能体可使用机器学习模型，根据用户过往偏好推荐航班。
- 多智能体交互可视性：需能查看多智能体间的交互情况。需要工具与技术跟踪智能体活动与交互。形式包括日志监控工具、可视化工具和性能指标。
- 多智能体模式：多智能体系统可采用集中式、分散式和混合架构模式。需选定最适合用例的模式。
- 人机交互：在多数情况下，人类在环中，需要指导智能体何时请求人工介入。例如用户要求特定酒店或航班未被智能体推荐，或预订前需确认等。
多智能体交互的可视性
了解多智能体间的交互情况十分重要。该可视性对调试、优化和保证系统整体有效性至关重要。为此，需配备跟踪智能体活动和交互的工具和技术，形式包括日志记录和监控工具、可视化工具及性能指标。
例如预订旅游时，可设仪表盘显示每个智能体状态、用户偏好与约束、智能体间的交互。仪表盘可显示用户出行日期、航班智能体推荐的航班、酒店智能体推荐的酒店、租车智能体推荐的车辆。如此一来，可清晰了解智能体间的交互及用户偏好和约束是否满足。
让我们更详细地看看这些方面。
-
日志和监控工具：需记录每个智能体执行的动作。日志条目可包括执行动作的智能体、动作内容、动作时间及结果。此信息可用于调试、优化等。
-
可视化工具：帮助直观展示智能体间的交互。例如绘制智能体间信息流图，有助识别瓶颈、低效及其他问题。
-
性能指标：用于跟踪多智能体系统有效性。例如记录完成任务所用时间、单位时间内完成任务数量、智能体推荐准确率等。此信息有助识别改进空间并优化系统。
多智能体模式
让我们探讨一些创建多智能体应用的具体模式，以下是一些值得考虑的有趣模式：
群聊
当你想创建一个支持多个智能体相互通信的群聊应用时，这种模式非常有用。典型用例包括团队协作、客户支持和社交网络。
在该模式中，每个智能体代表群聊中的一个用户，智能体间通过消息协议交换信息。智能体可以发送群聊消息、接收消息并回应其他智能体。
该模式可以通过集中式架构实现，所有消息通过中央服务器转发，也可通过分散式架构直接交换消息。
工作交接
当你想创建一个支持多个智能体间交接任务的应用时，这种模式非常有用。
典型用例包括客户支持、任务管理和工作流程自动化。
在该模式中，每个智能体代表一个任务或工作流程中的某个步骤，智能体可根据预定规则将任务交接给其他智能体。
协同过滤
当你想创建一个多智能体协作向用户推荐内容的应用时，这种模式非常有用。
多智能体协作的理由在于，每个智能体具备不同专长，可以不同方式为推荐过程做出贡献。
以用户想获得股票市场最佳买入建议为例。
- 行业专家：一个智能体可以是特定行业专家。
- 技术分析：另一个智能体擅长技术分析。
- 基本面分析：还有一个智能体擅长基本面分析。通过协作，这些智能体可为用户提供更全面的建议。
场景：退款流程
考虑客户申请产品退款的场景，可能涉及许多智能体，我们将其分为专门处理退款流程的智能体和可以用于其他业务部分的通用智能体。
专门处理退款流程的智能体：
可能涉及的退款流程智能体包括：
- 客户智能体：代表客户，负责发起退款流程。
- 卖家智能体：代表卖家，负责处理退款。
- 支付智能体：代表支付流程，负责退还客户款项。
- 解决方案智能体：负责解决退款过程中出现的任何问题。
- 合规智能体：确保退款流程符合相关法规和政策。
通用智能体：
这些智能体可被你业务的其他部分使用。
- 运输智能体：代表运输流程，负责将产品退回给卖家。该智能体可用于退款流程，也可用于类似购买产品的运输流程。
- 反馈智能体：负责收集客户反馈，反馈可在任何时间段收集，而不仅限于退款流程。
- 升级智能体：负责将问题升级至更高支持层级，适用于任何需要问题升级的流程。
- 通知智能体：负责在退款流程的各个阶段向客户发送通知。
- 分析智能体：负责分析与退款流程相关的数据。
- 审计智能体：负责审计退款流程，确保其按规范执行。
- 报告智能体：负责生成退款流程的相关报告。
- 知识智能体：负责维护与退款流程相关的知识库，可能涵盖退款及业务其他部分知识。
- 安全智能体：负责保障退款流程的安全。
- 质量智能体：负责确保退款流程的质量。
前文列举相当多的智能体，涵盖退款流程具体智能体及可用于业务其他部分的通用智能体。希望这能帮助你理解如何确定多智能体系统中使用哪些智能体。
练习
设计一个客户支持流程的多智能体系统。识别该流程涉及的智能体、它们的角色和职责，以及它们如何相互协作。考虑既有客户支持流程专用智能体，也有可用于业务其他部分的通用智能体。
在阅读以下解决方案之前先思考一下，你可能需要的代理比你想象的要多。
提示：考虑客户支持流程的不同阶段，并且考虑任何系统所需的代理数量。
解决方案
知识测试
问题 1
哪种情境最适合多代理系统？
- A1：一个支持机器人使用一个知识库和一小套工具回答常见问题。
- A2：退款工作流需要独立的欺诈、支付和合规角色，每个角色都有自己的工具，且结果必须协调一致。
- A3：同一个简单的分类请求每小时成千上万次地到达。
问题 2
什么时候单个代理通常是更好的选择？
- A1：任务可以通过一套指令和工具完成，无需专业交接。
- A2：代理可以访问超过一个的工具。
- A3：工作流程需要不同权限和独立审计跟踪的独立角色。
总结
在本课中，我们了解了多代理设计模式，包括多代理适用的场景、使用多代理相比单一代理的优势、实现多代理设计模式的构建模块，以及如何洞察多个代理之间的交互。
对多代理设计模式有更多疑问？
加入 Microsoft Foundry Discord 与其他学习者交流，参加答疑时间，获取你的 AI 代理相关问题的解答。
额外资源
- Microsoft Agent Framework 文档
- 代理设计模式
上一课
下一课
免责声明： 本文件由 AI 翻译服务 Co-op Translator 翻译完成。尽管我们力求准确，但请注意，自动翻译可能包含错误或不准确之处。原始语言版文件应视为权威来源。对于重要信息，建议使用专业人工翻译。我们对因使用本翻译而产生的任何误解或误释不承担责任。