在不断发展的多客服人员环境中，客服人员在分配特定的精细任务时最有效。这需要由可重复使用的专门客服人员组成的多样化网络。然而，核心挑战是协调这些来自各种来源的众多异构客服人员，为实现共同业务目标进行有效协作。如果没有统一的平台，这种复杂性会导致客服人员的蔓延和严重缺乏治理。

这些 AI 客服人员正在快速增加，嵌入 SaaS 平台，内部开发，或与流行的 LLM 打包。这种乘法会导致组织孤岛断开。虽然客服人员在其本地应用程序中优化任务，但它通常缺乏整体的企业视图。这种缺乏可见性的情况使客服人员无法跨不同的域和系统有效地编排、保护和管理操作。

MuleSoft 客服人员结构解决了管理“客服人员蔓延”的挑战，并支持不同客服人员的无缝编排，无论他们来自哪里。它建立了架构最佳实践，并提供了创建客服人员网络所需的工具。客服人员网络是指 AI 客服人���、工具和资源的协调集合，它们一起工作来执行复杂的多步骤业务流程。

MuleSoft 客服人员结构是一个统一平台，它为每个企业提供了一种简单的方法来发现、编排、治理和观察任何客服人员，无论它构建在哪里。

**发现：**客服人员注册表提供了整个组织内所有 AI 客服人员和工具的集中目录。它支持发现和重用内部构建的、SaaS 嵌入的和外部资产。通过为所有客服人员资产提供单一的真实来源，客服人员注册表消除了冗余，并确保开发人员可以大规模利用现有功能。

**编排：**MuleSoft 客服人员代理是一个智能路由解决方案，可将任务与最合适的客服人员或工具动态匹配。它由您选择的 LLM 提供支持，跨客服人员和工具进行协调，以确保复杂的多步骤请求和业务流程以高可靠性和可追溯的结果来执行。

治理：MuleSoft Agent 治理利用 Flex Gateway 及其对模型上下文协议 (MCP) 和 Agent2Agent (A2A) 协议的支持。通过 Flex Gateway，企业可以将安全和合规策略强制实施到每个客服人员-客服人员和客服人员-工具交互中。

**观察：**客服人员可视化器通过客服人员交互的动态交互式地图提供实时观察性。它跟踪决策，监控系统运行状况，从而实现对整个客服人员生态系统的持续优化和可靠监督。

客服人员结构支持规范优先 (YAML) 方法，其中用户通过元数据描述符（“YAML 文件”）定义客服人员网络。此 YAML 文件与 MuleSoft 无关，它使客服人员网络的定义与其执行脱钩。

每个客服人员网络 (YAML) 使用其客服人员资产定义特定的功能区域，包括其操作规则和策略。YAML 用于启用四个客服人员结构支柱：

1. 发现：使用现有客服人员资产填充客服人员注册表，例如：
   1. 跨各种平台部署的客服人员（MuleSoft 或其他）
   2. MCP 服务器
   3. LLM 提供商
2. 编排：为编排创建客服人员经纪人
3. 治理：为安全和治理应用资产策略
4. 观察：定义并重复使用与已定义资产的连接。此外，客服人员网络也具有可观察性和监控功能。

用户旅程从 Anypoint 代码生成器开始。使用通过名为“MuleSoft:创建客服人员网络项目”以创建新项目。此命令会创建一个包含两个文件的新项目（“客服人员网络”）。

• **agent-network.yaml:**该文件定义了多客服人员系统的配置，支持使用外部工具（通过 MCP）和客服人员（通过 A2A 协议）对 AI 客服人员进行编排。此格式提供了定义客服人员功能、依赖性和集成的声明性方式。

• **exchange.json:**所有客服人员网络项目也都有一个 exchange.json 文件。此文件包含发布客服人员网络资产后 Anypoint Exchange 可用的资产元数据。

客服人员网络的开发遵循标准的软件开发生命周期 (SDLC)，包括四个主要阶段：

1. **环境设置：**设置运行时环境和网关
2. 项目创建和设计:创建客服人员网络项目规范
3. **构建和发布：**构建资产并将其发布到客服人员注册表
4. **部署：**将客服人员网络部署或升级到指定环境

在您构建项目并生成所需的 MuleSoft 应用程序和资产后，请使它们在 Exchange 中可用。在 Anypoint 代码生成器中，使用 **“MuleSoft:将客服人员代理项目发布到 Exchange”**命令可通过命令选项板使用。

发布步骤将 YAML 文件中的每个代理资产转换为 A2A、MCP 或 LLM 规范，并将其发布到 Exchange。

此外，系统使用新的客服人员网络资产类型将 YAML 发布到 Exchange。您可以在客服人员注册表 UI 中查看此资产，并通过 Exchange API 进行搜索。

请参阅定义企业客服人员网络的客服人员网络文件。此客服人员网络激活了网络，以便在 Salesforce、Stripe、另一个订单履行客服人员和库存 MCP 服务器之间履行订单，并提供单一、受策略管理的体验。

• 发现
  将现有客服人员和工具（例如 Salesforce、Strip、订单履行和库存）发布为 Exchange 资产，以便重复使用。此外，订单履行定义 (YAML) 是版本化和可共享的，无需重建流即可快速适应角色、区域或子公司。
• 编排
  代理经纪人使用 LLM 将订单履行流程分解为一系列任务，例如验证客户详细信息、分配库存和计算运输成本。然后，它通过调用 MCP 和 A2A 客服人员来执行此工作流，确保在需要时请求人工在环批准。
• 治理
  Anypoint Flex Gateway 强制实施身份验证、最低权限访问和防护。API 管理器策略确保对所有调用和数据交换进行一致的控制。
• 观察
  监控和跟踪提供了对进度、失败和延迟的端到端可见性。可视化显示哪些客服人员交互，以及瓶颈发生的位置。
• 信任与合规
  集中凭据、审计跟踪和保单继承支持安全、隐私和监管要求（PII 处理、批准和职责分离）。

该图显示了 YAML 中定义的客服人员网络（元数据）的不同节点。

• 目的 是客服人员、工具和其他资产的目录。其主要目标是通过提供单个受管目录来解决“客服人员蔓延”的问题，该目录用于异构客服人员的发现、管理和生命周期管理。它使开发人员能够找到并重用客服人员，平台所有者保持可见性，编配员能够发现功能。
• 设计异构 Exchange 现在支持三个新资产 - 客服人员、MCP 和 LLM。Exchange 设计为通用目录，用于注册和管理任何类型的客服人员。它支持来自任何来源的符合 A2A 标准的客服人员、MCP 服务器和 LLM 提供商，包括第三方、Agentforce 和自定义 MuleSoft 客服人员。
• 核心元数据:每个注册的资产都有一个不可变元数据的基线集，包括唯一名称和版本、所有权和发布者。也会跟踪生命周期状态（开发、暂存、生产、弃用）。
• 发现:
  • 设计时间:开发人员可以通过现有的 Exchange UI 或通过 Anypoint 代码生成器中的 Vibes 进行自然语言搜索来发现注册的客服人员。
• 标记和分类:通过使用基本的键值标记系统，启用动态链接、搜索和选择策略，资产可以按类型（客服人员、MCP、LLM、经纪人）和域（例如，HR、天气）分类。
• 目录:存储库支持专用和内部目录模型，用于在组织中共享客服人员。
• 可视化:提供可视化工具，支持网络视图，显示单个资产的连接或整个组织中的节点和链接地图，并具有筛选功能。

客服人员网络中的客服人员可以引用存储在 Anypoint Exchange 中的注册客服人员、MCP 服务器和 LLM 提供商。但如果尚未注册，可在客服人员网络 (YAML) 的元数据中声明，并自动注册。在示例中，多个客服人员、MCP 服务器和 LLM 提供商在 Anypoint Exchange 中声明和注册。

客服人员代理是一个智能路由客服人员，负责协调企业中专业客服人员之间的任务委派。它由用于完成任务的客服人员和 MCP 服务器定义。

经纪人是在发布客服人员网络资产并由其他经纪人重用后显示在 Anypoint Exchange 中的专业客服人员。

经纪人在 YAML 的_经纪人_部分中定义。定义的经纪人被透明地“编译”到应用程序中，不需要任何关于 Mule 的先前 Knowledge。此生成的应用程序会部署到 CloudHub 2.0 (CH2)，并利用强大的 CH2 基础设施。

这意味着客服人员经纪人受益于 CloudHub 2.0 的既定性能特征，包括其日志记录和度量功能。操作方面，例如“运营成本”和“监控/警报/工具”，与任何其他工作负载相同。

对于需要人工干预的场景（人在线），每个交互的状态都通过使用 MuleSoft 对象存储来维护，这是一个分布式解决方案，旨在在高度并发的环境中进行有效的状态管理。

经纪人定义由两个部分组成：卡片和规格。

卡片部分遵循客服人员对客服人员 (A2A) 规范。除其他外，它描述了经纪人的合同、技能和能力。卡片 URL 会自动填充值 ${ingressgw.url}/broker-name。在部署时，${ingressgw.url} 占位符会自动替换为客服人员入口请求前面的 Anypoint Flex 网关的 URL。

规范部分配置经纪人的“源代码”。在这里，开发人员可以指定要使用的 LLM、说明、可用的工具、错误处理，以及最重要的是，该经纪人可以使用的各种客服人员和 MCP 工具。

LLM 提供商

该部分是每个经纪人规范的一部分。这是对服务部分中定义的其中一个 LLM 的引用。我们可以选择是否在所有经纪人之间共享一个 LLM，或者如果需要，让不同的经纪人使用更适合其任务的 LLM。

经纪人可以指向 LLM 提供商。我们可以根据需求选择这些提供商的型号。

说明

此部分是可选的，您可以使用它指定特定于此代理的说明。这些说明通常侧重于特定的业务导向问题。例如，假设客户服务代理协调客户报告事件的管理：

请注意,没有必要提供明确的说明，例如**“将提示拆分为任务”或“选择最佳工具”**，因为经纪人自己处理。这些说明仅在描述特定业务流程时必要。

工具配置

工具为客服人员提供外部功能。每当代理需要访问外部系统（不是另一个代理，例如，现有 API 或 SaaS 服务）时，它会联系 MCP（模型上���文协议）服务器：

MCP 服务器由交换资产的名称引用。它的连接详细信息在服务部分中指定。

默认情况下，经纪人可以访问 MCP 服务器中的所有可用工具。根据我们的观察，大多数现代 LLM 在每个上下文中只能处理大约 20-25 个工具，然后才会开始产生不准确（或失去上下文）。因此，将可用工具限制到所需的最低数量通常是一个很好的实践。您可以通过允许的列表应用该筛选。

客服人员链接

本节是整个定义中最重要的部分。链接部分启用客服人员间通信和编排。这意味着该经纪人依赖于在此处链接的客服人员执行适当的操作来完成用户的目标。

实际上，本节定义了客服人员-网络协作。

客服人员治理是客服人员结构的关键支柱，是构建可信客服人员网络并确保安全性和合规性的基础。

对于治理，您的专用空间中总共需要两个弯曲网关（一个入口和一个出口）。

治理建立了必要的结构、控制和证据，以安全地扩展整个客服人员开发生命周期 (ADLC)。特别是，治理实施关键流程，例如客服人员认证、编目、生命周期决策和运行时策略的实施。

• 编目：
  • 交换：支持记录客服人员目的、所有人、环境、数据和分类边界。它还会向版本注册功能、工具、资源、提示和外部依赖性。
• 版本和生命周期：
  • 在整个客服人员开发生命周期中，记录和管理客服人员、工具和资产的语义版本。
  • 版本控制有助于管理客服人员弃用时间线，并支持双重运行（在可能时），以确保顺利迁移。
• 策略实施:
  • 代理 AI 架构扩展了攻击表面（对话界面、提示和新协议，例如 MCP）。对任何组件的任何妥协都可能导致多个系统出现级联效应，这些系统提供协议、提示、API 或工具等组件。
  • 保护企业客服人员的 AI 部署需要一种专门的方法，因为这些自主和不可预测的环境通过客服人员之间的交互而必然扩大攻击范围。虽然静态系统的现有安全工具至关重要，但仅靠这些工具是不够的。企业必须主动规划和实施 4 个特定的安全解决方案，每个解决方案都直接解决与客服人员 AI 相关的关键业务风险。
  • 弯曲网关：所有 A2A 和 MCP 流量都通过 Flex Gateway 路由，即使目标系统不安全，也能确保在每个端点上应用策略。此路由对于保护客服人员通信和与授权服务器集成至关重要。
  • 保单捆绑包：在执行前，用户可以定义预定义策略捆绑并将其应用到工作流，从而强制执行一组一致的安全和操作策略。
  • 保单类型：该平台支持各种入站和出站策略，包括：
    • A2A 策略：客服人员卡、PII 检测器、提示装饰器、模式验证。
    • MCP 策略：基于属性的访问控制、模式验证、MCP 支持。
    • LLM/AI 策略：AI 提示装饰器、AI 提示保护（过滤有害内容）、AI 提示模板（应用预定义模板）、AI 基本令牌速率限制。
    • 遥测策略：A2A 和 MCP 遥测，以扩展用于日志数据收集和导出的开放式遥测解决方案。
• 记录:由于自动跟踪，客服人员网络的日志可用于跟踪每个客服人员交互，解释行为并建立Trust。

该示例描述了消息记录的策略，该策略通过使用客服人员网络元数据进行配置。Orderfullfillment 经纪人是指名为 Salesforce 客服人员的现有客服人员，消息传递策略通过使用元数据进行配置。请注意，客服人员结构会自动配置在 Flex Gateway 的“规格”部分中提到的所有策略。您不需要额外的步骤。

鉴于 LLM 客服人员和多客服人员部署的非确定性和复杂性，可观察性和监控至关重要。

• 基本日志和跟踪:推理和工具执行跟踪通过日志提供。工作流执行的日志和跟踪可在运行时管理器中查看执行后情况。
• 度量:在初始阶段，平台将 a2a_total_calls 和 mcp_total_calls 发布为带有标签（例如，路径、状态、方法、工具）的计数器，以确定呼叫总数、成功次数和失败次数。这些度量通过使用 Envoy 的 (Flex Gateway) 本地统计界面从策略代码发布，最好通过 mcp_support_policy 和 a2a_agent_card_policy 等现有策略。
• 增强的可观察性(未来):计划包括在未来版本中使用开放式遥测进行分布式跟踪。更高级的可观察性包括：
  • 详细请求跟踪:获取请求的端到端可见性，包括提示、计划员流程、调用的操作以及与子客服人员的交互。
  • 客服人员健康监控:监控客服人员正常运行时间、响应延迟、吞吐量、错误率和基础资源利用率（CPU、内存、网络、GPU）。
  • 多客服人员协调监控:捕获客服人员对客服人员交互的成功和失败率，检测循环调用模式（循环），并跟踪每个客服人员的度量，例如任务完成和调用计数。
  • 成本跟踪:通过仪表板和提醒，跟踪每个 LLM 呼叫的令牌使用情况和相关费用，理想情况下是每个客服人员。
  • 认知跟踪:捕获并显示客服人员会话的详细跟踪，包括内部思想过程和所有工具调用，作为不可变的审计跟踪。
  • 客服人员会话播放:一种 UI，允许直观地“重放”客服人员的认知跟踪，以进行深度调试。
  • DAG 可视化:为复杂的多客服人员交互提供客服人员工作流执行的定向无环图 (DAG) 可视化。

客服人员可视化器用于识别客服人员网络的各个部分，并查看它们如何协同工作。

• 区分节点类型（客服人员和 MCP 服务器）。
• 查看边，以查看声明和运行时交互。
• 使用图层将视图集中在特定环境
• 打开详细信息卡，以检查节点的元数据和度量以及访问日志和跟踪
• 查看治理指标，例如弯曲网关保护和应用的策略。

在此处查找有关客服人员可视化器组件的详细信息。

通过这四个支柱，MuleSoft 客服人员结构将安全性和控制扩展到任何具有内置治理的客服人员。它通过利用新的协议（例如 A2A（客服人员到客服人员）和 MCP（模型上下文协议）来构建和扩展业务流程，使客服人员能够在任何地方采取行动。我们连接一切 - 应用程序、数据和系统，以便在客服人员在整个业务中工作时为他们提供支持和治理。智能工具支持通过本地使用 AI 或引入第三方 AI 工具创建和扩展业务流程或 API。

不需要一起使用所有四个支柱，但建议一起使用。您可以根据需要独立选择支柱。例如，您可以将代理结构用于注册表和治理，而无需使用编排层。同样，您可以使用代理来编排通过另一个平台管理的客服人员。

该图表显示了所有四个组件如何相互作用：

1. 在 Anypoint Code Builder 中定义客服人员网络 YAML 中的客服人员网络（客服人员、客服人员、MCP 服务器）后，将客服人员资产发布到 Anypoint Exchange 进行发现和重用。
2. 将客服人员资产部署到 CloudHub 2.0（在运行时管理器中受管）。
3. 使用入口 Flex 网关对网络的传入流量强制执行策略，该网关位于代理和 API 端点之前。
4. 通过出口 Flex 网关，强制执行策略、管理连接并排放遥测数据。此网关位于从经纪人和客服人员到外部服务的出站路径上。
5. 从 Anypoint Monitoring 中的 Flex 网关和运行时收集日志、度量和跟踪。

通过能够访问每个可用的 AI 资产的一个编配员，诱使每个专业客服人员都可以在一个扁平的、不受限制的架构中立即访问，这很有吸引力。然而,这种方法很快被证明不利于整个系统的效率和可靠性。与适用于过多单个工具的原则相似，许多客服人员选项会为中央客服人员(或编配员)引入大量噪音和复杂性。这种复杂性的增加直接导致经纪人决策的准确性（为工作选择合适的客服人员）和系统响应的确定性（类似查询的可预测、一致的结果）的明显下降。经纪人客服人员实际上存在选项瘫痪的问题，导致路由速度变慢，可靠性降低。

我们强烈建议使用多级层次方法来构建客服人员网络，而不是扁平结构。这一组织原则提供了许多关键优势。首先,它本质上有利于可跟踪和管理。层次结构反映了既定的组织最佳实践，使得审计请求的流、通过精确定位故障层来调试问题以及管理特定客服人员或子网的部署和停用变得更加容易。

其次,在为这些客服人员提供支持的大型语言模型 (LLM) 的上下文中,层次结构非常有助于控制上下文大小。通过细分客服人员情况，任何给定层的客服人员仅考虑其下方的有限客服人员或子客服人员。此结构可防止主要编配器将_每个客服人员_的描述、功能和历史上下文加载到工作内存中，避免快速超出 LLM 上下文窗口限制的风险，并产生高昂的成本和延迟。

客服人员网络可以通过多种方式实施。其中两个是：

1. Conway 定律 - 将其映射到真实层次结构的直观方式。
2. 域驱动的设计 - 更关注业务域

选项 1：使用真实层次结构映射

在分层组织中，沟通从经理到下属垂直流动，决策通常被集中。根据康威定律：

• 此类组织构建的系统或软件架构也往往是分层和分层的。
• 每个团队倾向于设计反映自己边界和权限的子系统。
• 系统之间的接口反映了各部门之间的通信渠道。

客服人员网络也可以按照康韦定律直观地映射到大型企业的层次结构。

• **概念模型：**正如公司拥有不同的部门、部门和管理层（例如，C-Suite、VP、Director、Manager），在特定域中运行的客服人员网络可以建模为并行组织结构图。
• **节点和叶：**在此层次结构中：
  • 树结构的叶子是专家客服人员或 MCP。它们是执行实际工作的功能单元（例如，“数据库查询客服人员”、“客户身份验证客服人员”、“情绪分析客服人员”）。它们代表组织的个人投稿人或工作单位。
  • 层次结构中的所有其他节点，包括根层和中间层，都是客服人员（或子编配员）。这些客服人员不执行最终任务，但负责特定域或层内的路由、委派、聚合和冲突解决。高级经纪人将任务委派给“销售域经纪人”，销售域经纪人又委派给“业务机会管理经纪人”，业务机会管理经纪人通过“业务机会状态更新客服人员”执行任务（叶）。

这种结构确保复杂性在本地管理，上下文包含在内，并且系统可以预测和可靠地扩展。您可以将新的专家客服人员引入组织树的特定、适当的分支。

考虑一下数字劳动力的组织结构图的类比。每个 YAML 文件代表每个内部组织（员工成功、安全、财务等）。在每个组织（客服人员-网络）中，您可能有一个层次结构，通过这个结构，行为者进行协作，工作被分成任务和分配。在上图中，通信从上到下流动。而且，假期不仅限于一组经纪人代理的消费。

基于人员组织结构图对客服人员网络进行建模存在需要频繁重新设计的风险，特别是在频繁重组的公司。另一种方法是按功能域组织客服人员。这种分组可能需要跨越传统的人类组织边界。例如，新员工入职涉及硬件和用户配置的 IT 运营，而销售申请需要运营和市场营销。

Nikhil Aggarwal 是 Salesforce 的首席架构师，负责 MuleSoft 和 Salesforce Automation Cloud 的架构。Nikhil 拥有超过 18 年的大规模产品交付经验，并热衷于可扩展架构、直观的开发人员体验和构建高性能团队。在加入 Salesforce 之前，从概念到发布，他在 Microsoft Power Platform、Dataverse 和 Office 365 中领导了多项计划。他的工作继续塑造���代企业如何在 AI 优先时代连接系统、自动化工作流并释放业务价值。

Mariano Gonzalez 早在 2011 年加入 MuleSoft，专门从事关键任务分布式系统、集成、PaaS 和云计算。今天，Mariano 的重点是推进 AI 平台，并特别关注治理、编排、发现和可观察性。Mariano 在 IT 行业拥有 20 多年的工作经验,曾担任软件架构师和团队主管,设计和交付 BPM、ERP 和集成解决方案,涵盖农业、能源、政府、IT、电信和内容管理等领域。

Pedro Colunga 是 Salesforce 的软件工程师架构师，专门从事 API 和元数据架构。Pedro 专注于整个平台生命周期，在塑造组织如何与系统智能、语义和元数据驱动的解决方案交互方面发挥了关键作用。Pedro 的 20 年职业生涯包括创业经验，跨越 Fuego、BEA Systems、Oracle 和 TekGenesis 等公司，该公司后来被 MuleSoft 收购，他一直在推动平台导向架构，在 BPM、RAD 和集成等领域提供了深厚的专业知识。

Gulal Kumar 是 Salesforce 的软件工程架构师，专注于数据和集成架构。他在集成和 API、现代化计划、安全和 AIML 计划方面拥有超过 20 年的经验，拥有丰富的专业知识。Gulal 一直致力于推进业务转型计划，增强安全性和弹性，促进架构卓越性，并领导各个领域的 AIML 计划。