Enterprise Agent 架构和设计模式为多客服人员架构的可能性带来了结构，确定并强调了如何组合 AI 客服人员的新功能，以提供可靠、可重复、可扩展和可管理的客服人员解决方案。我们从面向对象编程的“设计模式”中获得了灵感，我们列出了可以组合和扩展的模式，以解决在代理技术出现之前许多令人兴奋的挑战，这些挑战超出了基于传统确定性技术构建的业务系统的范围。

在讨论多客服人员架构的基本原理后，我们介绍了许多客服人员模式，从利用自然语言处理来确定用户意图的简单模式，到提供客服人员之间关注点分离的多客服人员模式，再到将客服人员推理带到演示和与系统、信息和内容交互的 UX 客服人员模式。

首先，您将获得关于客服人员的全新思维方式 - 客服人员作为组件，客服人员作为编译器，客服人员作为行为者，客服人员作为协作者，最重要的是，客服人员在更大的架构中，以意图行事，并在他们各自关注的范围内行事。

您将获得所需的指针，以构想跨越用户旅程的丰富客服人员解决方案，并告知重要的客服人员体验，这些体验是以前从未有过的。

本文档的初始部分提供了多客服人员架构的基本原理。阅读这些文档，以更好地了解多客服人员架构带来的挑战和机遇。

以下是客服人员模式的定义和描述，从简单到复杂，涵盖了支持交互的模式、专家客服人员的模式、后台操作的模式和长时间运行的模式。每个模式都包括一个实现该模式的关键组件的图表，以及使用和代表性用例的建议。

最后，附录包含这些模式如何组合成整体代理解决方案的示例，以支持更大的代理体验，例如，支持客户服务或代理销售。请参考本节，了解丰富的客服人员体验如何在客服人员和操作级别利用问题的分解和分离来推动交互级别的重用，共享客服人员在辅助和自主模式中支持内部和外部成员。

当企业架构师将生成式 AI 集成到他们的生态系统中时，他们必须解决一组常见的设计问题：

• 需要多少客服人员？
• 客服人员将如何交互？
• 客服人员和人员之间的分工如何？
• 如何将这些组件组装成一个连贯的系统？

本文档介绍了用于设计和构建代理解决方案的基于模式的方法。

整体客服人员是大多数客服人员解决方案的起点。客服人员 — 更具体地说，Agentforce 客服人员 — 是一系列主题中表现出色的人员。对于常见用例，从单个客服人员开始。

随着贵组织的发展，多客服人员架构是首选方法。与单片、单客服人员系统相比,多客服人员架构支持更大的规模、控制和灵活性。

多客服人员架构提供了这些关键优势：

• 提高性能和复杂性细分:由多个专业客服人员组成的系统提供了更高的功能，并简化了指令遵守。
• 模块化和扩展性:可以更加轻松地添加、替换、修改和测试单个客服人员，从而提高灵活性。
• 弹性和容错:单个组件的故障不会影响整个系统，从而带来更好的整体弹性。
• 分权治理:故障排除和管理可以隔离到特定的客服人员及其相应的应用程序，这简化了维护和监督。

合理安排多客服人员架构首先要将核心架构原则投影到客服人员的功能和结构上。然后，产生的多智能体架构体现了核心系统设计和系统架构原则，与 AI 技术的独特“粒度”相一致。

推动此架构的关键原则包括：

• 通过分解管理复杂性
• 通过解耦提高弹性并降低脆性
• 通过代码重用提高可靠性和效率
• 通过限制任何一个客服人员的关注范围来提高客服人员的可靠性
• 通过模块化和可扩展性改善系统维护和演进
• 通过专业化简化客服人员管理和问责制

与更原始的代理架构不同(例如,侧重于作为核心架构结构的 LLM 的架构),Agentforce 从一开始就是为多代理编排设计的。多客服人员编排是 Atlas Reasoning 引擎和客服人员推理的基础，用于在客服人员响应中创建动态、有效的编程路径，以显著扩展为用户体验提供广泛、深入的客服人员增强 (UX) 的能力。

在 Agentforce 中，此类协调由这些可互操作的密钥开放协议和 Salesforce 产品启用：

• Agentforce 提供客服人员子系统来封装客服人员的所有关键元素：主题、指令、操作、防护、上下文、调用、输出、执行详细信息、日志等。
• 操作：提供钩子，以访问数据、调用流、调用外部系统和调用其他客服人员。
• Data 360：提供数据虚拟化层，为客服人员带来特定的个性化上下文（利用 Data 360 的统一简档和密钥链从整个企业中提取特定信息）。

对于整个企业的客服人员或访问客服人员或资源，我们支持：

• 模型上下文协议:是一个安全的通信层,将客服人员与企业工具、数据和知识联系起来,以确保上下文的准确性。
• 客服人员到客服人员 (A2A) 协议: 是客服人员间委派的标准化握手，支持跨系统、组织和供应商进行安全的受管协调。

这些原则为构建可扩展、可治理的编配智能系统提供了基础。

强大的客服人员解决方案需要清晰的方法来满足支撑有效技术交付的非功能需求：

• 安全和治理（身份和访问权限管理、数据隐私、数据安全和威胁建模）。
• 可观察性和监控（分布式跟踪、集中记录、度量和仪表板）。
• 操作和生命周期管理（规格、测试用例生成、测试、反馈、继续学习、弃用）。

这些是构建 Enterprise Agentic 解决方案时的关键架构注意事项，本白皮书中未涉及；但将在未来的出版物中讨论。

要管理企业范围的客服人员环境，架构师必须通过两个互补的镜头对客服人员进行分类：技术功能和业务影响。

此分类对客服人员在架构中可能承担的功能角色进行分类。

• 渠道/UX 角色:定义交互模式（例如，无头、提示、聊天和消息，或 AI 管理的工作区）。
• 专家角色:封装深度域 Knowledge（例如，Domain Expert、Knowledge Minion、Assistant 或 Planner）。
• 实用程序服务角色:执行离散的事务性任务（例如，生成、汇总、转换或配置）。
• 维护和主动服务角色:关注数据的健康和质量（例如，策划、构建、数据质量或数据丰富）。
• 长期运行的角色:管理长时间的流程（例如，礼宾、项目经理、护理人员或观察者/提醒者）。

为了便于清晰的设计和沟通,客服人员地图是描述客服人员解决方案的标准模板。它定义了特定设计模式中的关键实体、系统和交互。

以下是客服人员地图模板组件：

• 用户层定义了系统中的人工角色(例如客户、经过身份验证的员工 (SF-Users) 和未经身份验证的员工)。
• 客服人员层描述了所需的客服人员、显示的模式、相互关系以及用于实现特定模式的说明。
• 上下文/操作是客服人员管理或访问的资源、功能或操作。
• 来源是客服人员连接的基础数据、应用程序、Knowledge 库和其他系统。

附录 A 和 B 通过演示客服人员地图模板泳道中的组成来说明系统级客服人员模式。

在 Salesforce，我们使用客服人员模式库来组织和提供可靠、可预测的客服人员解决方案。这些模式是我们解决常见架构问题的蓝图。

它们分为四个主要类别：

• 交互模式:关注客服人员参与和用户体验 (UX)。
• 专家/员工模式:封装特定域中的深层 Knowledge 或特定技能。
• 实用程序和数据管理模式:执行支持其他客服人员或流程的特定且通常可重复的任务。
• 长时间运行的模式:管理长时间发生的流程和工作流，涉及多个步骤。

以下部分详细介绍了每个类别的关键模式。每个模式描述都提供一个概览、输出类型、模式使用指导、代表性用例和解决方案图表，以及到 Salesforce 代理成熟度基准的映射。

交互模式是侧重于客服人员参与和用户体验的基础设计。

• 概览:Greeter 模式是一种使用自然语言来确定用户意图的简单、易于实施的模式。然后，它将用户路由到适当的人工客服人员。

• 输出类型:切换/上报到下一个资源。

• 业务价值:促进客户无缝、高效的第一次联系，同时最大限度地提高服务提供商的意图解析和上下文收集。

• 模式使用指导:将客服人员配置为品牌渠道的主要参与资源。根据用户意图，提供关于品牌、产品和服务的说明，并与路由说明配对。客服人员收集并汇总交付热情切换的意图。

• 代表性用例:想象一个网页，它使用聊天机器人来显示一个选项菜单，用户必须在路由到人类之前单击所有选项。为了提高后台生产力和效率，聊天机器人通常使用复杂、复杂的工作路径和交互。这会导致客户的“填写、选择和单击”疲劳场景，如果上下文在可用菜单选项之外，这通常会导致沮丧。通过使用自然语言交互的客服人员前门替换传统的聊天机器人，它减轻了负担并提供类似人类的交互。

• Agentforce 模式:

  • Agentforce 服务代理：建立服务代理
    • 打包的服务代理具有支持转移的可配置转移功能：
      • 对于人工客服人员
      • 对 AI 客服人员
      • 至外部客服人员
  • 包含代码示例的特定于行业的模式

• 图表:

• Salesforce Agent 成熟度:级别 1（如果使用内置转移和升级的现成服务代理，则为级别 0）

• 概览:运营商模式建立在 Geeter 模式的基础上，将请求路由到适当的专家客服人员或人员和谈判意图(如果需要)。

• 输出类型:切换/转移到下一个资源。

• 模式使用指导:将特定于品牌和服务的说明与根据意图将用户发送到何处的说明配对。定义升级资源，可以是人员或其他客服人员。

• 代表性用例:将 Agent 前门 用于人员或 AI 代表高度专业化的场景。

• 图表:

• Salesforce Agent 成熟度:级别 2

• 概览:编排者模式管理 AI 客服人员"群 " 。当收到用户请求时，它会将话语传递给一个或多个专家客服人员，然后聚合用户的响应。与运算符模式不同，它仍然是第一个联系点 (POC)。

• 输出类型:核对并准备来自工作人员客服人员的回复。

• 模式使用指导:配置为主要参与者。为每个支持的工作人员客服人员（例如，优先级确定者或域 SME）提供说明，允许编配员向他们中继话语。

• 代表性用例:将编排者模式用作客服人员前门，以帮助每次对话可能需要讨论多个主题的客户，这需要多客服人员解决方案和一致的交互。在多系统架构中，考虑使用编排者模式来协调跨系统的响应，并与外部客服人员协作。

• 图表:

• Salesforce Agent 成熟度:级别 3

• 概览:听众/摘要模式在对话流中显示上下文和见解。监听器在每次对话轮次中触发，以查找并显示员工的相关信息。

• 输出类型:根据对话提供相关上下文，这些上下文可以格式化以产生效果（例如，进行比较或突出显示关键点）。

• 模式使用指导:将监听程序附加到基于轮次的渠道（例如，聊天、语音或短信）。为每个主题区域定义主题。客服人员使用脚本，识别主题，并调用操作来搜索相关内容并将其发布到员工的运行摘要。

• 代表性用例:使用通用助手帮助客户服务或销售代表。

• 图表:

• Salesforce Agent 成熟度:级别 3

• 概览:工作区 (Radar O’Reilly) 模式在对话流中管理响应式单窗格 UX。它处理每个语句，以使用相关内容更新 UX 的部分。

• 输出类型:在更大的单一窗格视图中，提供位于 portlet 中的相关上下文。

• 模式使用指导:编排人员将话语传递给一组主题客服人员。每个主题客服人员评估该语句，以确定是否需要 UX 更新。如果是这样，它会将动态更新推送到相应的 LWC。

• 代表性用例:此功能类似于高级客服人员前门。

• 图表:

• Salesforce Agent 成熟度:级别 3

专家模式包含特定领域的深度 Knowledge 或技能 , 通常由交互模式编排。

• 概览:Answerbot 模式是一种有效的自助模式,它使用 GenAI 来确定 Knowledge 检索的自然语言,而不仅仅是关键字。

• 输出类型:汇总 Knowledge 和支持材料的引用/引用。

• 模式使用指导:组织和接收可靠的源材料（例如 Knowledge Stores 或常见问题解答）来配置客服人员。在公司网站或内部入口网站中定位客服人员。监控问��，以识别和解决 Knowledge 差距。

• 代表性用例:促进公司网站上的自然语言搜索，与人力资源福利机器人交互，并为所有成员提供自助组件。

• 图表:

• Salesforce Agent 成熟度:级别 1

• 概览:域 SME 模式是一种基础模式，为业务域（例如订单或索赔）提供自然语言前端。

• 输出类型:提供有关域的相关内容、主题、数据和格式化信息。

• 模式使用指导:使用此模式封装主题或业务域。为客服人员配置执行适当 CRUD 操作的能力。通过交互模式（例如 - Orchestrator 或监听程序），使这些客服人员可用。

• 代表性用例:把关业务数据域，提供“订单客服人员”或“库存客服人员”，并为业务域提供客服人员界面。

• 图表:

• Salesforce Agent 成熟度:级别 2

• 概览:询问者模式是 SME 客服人员，可以就主题进行询问，以从多个来源收集上下文来回答问题。利用的关键客服人员功能是提取上下文并将概念与内容正文联系起来的能力，就像人类在阅读和内部化内容后一样。这种模式降低了对"轮椅集成"的需求。

• 输出类型:提供问题的答案。

• 模式使用指导:它通常配置为连接到用户当前上下文的控制台小部件，以便他们可以直接提问。它还与 Knowledge 资源一起使用，例如常见问题解答、保单和产品目录。将询问器模式与标准提示配对，以将常见答案扩展到常见问题。

• 代表性用例:用作合同助理客服人员；福利查询助理，或多客服人员模式中的专家工作人员客服人员（例如，监听者或工作区）。

• 图表:

• Salesforce Agent 成熟度:级别 2

• 概览:优先级模式用于根据定义的目标对一组任务或工作对象进行排序。它利用 GenAI 进行定性分析、非结构化数据分析或跨多个数据域的集成分析。

• 输出类型:提供生成性见解。

• 模式使用指导:使用自然语言来描述确定优先级所需的品质。使用一组可选选项对客服人员进行基础训练。与倾听者模式相结合，在工作流中创建响应式“Next Best Action”。

• 代表性用例:在长时间运行或多客服人员模式中用作 Next Best Action 生成器或专业工作人员客服人员。

• 图表:

• Salesforce Agent 成熟度:级别 2

实用程序模式执行支持其他客服人员或流程的特定、可重复的任务。

• 概览:生成器模式是从现有输入和标准创建新内容（例如个案汇总或电子邮件草稿）的基本模式。它通常作为提示实施，并可能嵌入其他客服人员。

• 输出类型:提供符合请求格式和意图的生成内容。

• 模式使用指导:生成器模式可以在大多数其他模式中使用，也可以作为独立模式使用。上下文可以通过请求、执行期间的水合或其他浓缩步骤提供。

• 代表性用例:向 QBR 提供个案汇总、电子邮件草稿、Knowledge 文章或建议/响应。

• 图表:

• Salesforce Agent 成熟度:级别 1

• 概览:数据管理模式是一种自主的后台模式，将代理步骤引入数据操作，以确保一致的数据质量、一致性和丰富性。

• 输出类型:在保存前提供更新的记录和数据字段。

• 模式使用指导:通过在保存数据之前添加记录触发器流的数据管理器，在数据创建点嵌入数据质量。有助于确保分类、汇总和状态数据的应用一致。

• 代表性用例:确保一致的“披萨跟踪器”样式更新，丰富客户数据，并消除不匹配的邮政编码和地址。

• 图表:

• Salesforce Agent 成熟度:级别 2

• 概览:Zen Data Gardener 模式是一种用于整理和标准化数据的预定后台模式，它利用低成本推理来验证、丰富和统一其他未连接的数据域的数据。

• 输出类型:提供更新的记录和/或数据管理任务。

• 模式使用指导:使用该模式启用定期、定期的数据审查和验证。对于变化缓慢的数据，以缓慢的节奏（例如每月）计划客服人员。与数据管理模式结合，提供前瞻性和回顾性数据质量操作。

• 代表性用例:确保已售福利与索赔系统保持一致，并根据国家登记册定期验证经纪人许可证。

• 图表:

• Salesforce Agent 成熟度:级别 4

• 概览:配置器模式从自然语言要求生成配置工件（例如，SQL/SOQL、JSON 和 CSV）。它还可以反向运行，以根据要求验证现有配置。

• 输出类型:提供更新的记录、数据管理任务或构建问题/错误进行更正。

• 模式使用指导:使用特定标准、准则或示例对客服人员进行基础训练。使用合同或产品规格等来源配置构建要求。将配置器模式连接到目标系统，以推送生成的配置。

• 代表性用例:为健康保险产品生成产品配置记录，并为健康提供商验证合同/付款条款。

• 图表:

• Salesforce Agent 成熟度:级别 4

• 概览:法官和陪审团模式旨在通过使用一组“陪审员”客服人员和“法官”客服人员来评估回复的一致性，以确保它们实质上的一致性和基础性，从而最大限度地减少幻觉。

  • ��成方法嵌入到 Agentforce 和 Atlas 推理引擎中，以处理回复的准确性和相关性。当高精度至关重要时，法官和陪审团模式就以这种能力为基础。
  • 数据基础训练（例如，“在这些记录/文档中查找答案”）和提示工程（例如，“仅在这些记录中找到答案时才返回答案”或“根据此外部来源验证答案”）的组合也是最小化幻觉的有效方法。

• 输出类型:提供生成性见解。

• 模式使用指导:在强烈需要一致和基础的生成式输出时使用。法官代理会编译基准提示，并将其传递给两个或更多的法官代理，然后法官评估响应。为了获得最佳结果，请为每个陪审员使用不同的模型（例如，一个来自 OpenAI，另一个来自 Anthropic）。

• 代表性用例:提供高保真、基于事实的回答，以最大限度地减少幻觉。

• 图表:

• Salesforce Agent 成熟度:级别 2

• 概览:模型模式利用多个专家客服人员生成广泛的视角，然后提取共识。与法官和陪审团模式不同,该模式包含多个观点以增强丰富性。

  • 当存在具有不同观点 (POV) 的专家模型时，这种模式也可以称为专家小组模式。
  • 与意图确保客服人员响应收敛于共同可访问的“真相”的法官和陪审团模式不同，模型模式通过利用客服人员环境中的多样性来扩展响应的范围。
  • 此模式假设还有其他客服人员具有不同的 POV。例如，在多组织、多客服人员的环境中，或在技术堆栈中有多个供应商提供的客服人员的环境中，模型模式提供了集成多个 POV 的结构。
  • 在考虑此模式时，也考虑其他通常更轻量级的方法：
    • 不要定义多个专家客服人员，而是指定多个提示，让系统作为提示集合工作。
    • 通过访问上下文适当的数据的操作，利用“基础训练”。

• 输出类型:提供生成性见解。

• 模式使用指导:聚合客服人员的角色是根据模型客服人员返回的关键概念形成并返回丰富的 POV。模型客服人员根据其唯一 POV 确定响应。

• 代表性用例:用于可能受益于汇集不同观点以提高回复质量的情况。 例如，特权客服人员（例如 ERP 客服人员）可能拥有有价值的 POV 且无法访问的多系统客服人员环境。

• 图表:

• Salesforce Agent 成熟度:级别 2

长期运行进程模式管理在较长时期内发生的进程，并涉及多个步骤和行为者。

• 概览:项目经理模式是一个复杂的模式，可以监督一个长期运行的项目。它协调活动，跟踪完成情况，通知用户，并向利益相关者代表项目状态。

• 输出类型:有多个输出（例如，个案、任务、状态更新和通知）。

• 模式使用指导:用作总括模式，以支持定期、重复、多步骤的活动。项目经理模式获取项目的输入模板/大纲（包括任务、角色和依赖性），然后实例化个案和活动并将其分配给用户。

• 代表性用例:用于客户安装管理和企业销售参与。

• 图表:

• Salesforce Agent 成熟度:级别 4

模式描述了客服人员角色，编排原型定义了客服人员团队如何协作的系统级蓝图。这些原型澄清了Agentforce作为编配大脑和MuleSoft作为通用连接器和适配器的角色。

Archetype 1：SOMA（单个组织，多个客服人员）

• 定义:多个客服人员在一个使用共享治理和数据的 Salesforce 组织中协作。
• 架构流:在 Agentforce 中，主管客服人员充当单个前门，将请求路由到组织内的专家客服人员。对于外部功能,客服人员使用具有 MuleSoft 的 Agentforce MCP Client 作为未启用 MCP 的 API 的 MCP 包装程序。
• 关键注意事项:此模式会集中 Salesforce 中的编排逻辑（类似于 CRM 上下文和 Data 360），以保持统一的治理、身份、权限和可观察性。

Archetype 2：MOMA（多个组织、多个客服人员）

• 定义:客服人员在多个 Salesforce 组织中协作，这需要跨数据和权限边界进行安全协调。
• 架构流:一个组织中的主管客服人员通过标准化的客服人员对客服人员 (A2A) 协议将任务委派给其他组织中的客服人员。此握手可确保组织级 Trust、用户身份流和共享对话上下文。
• 关键注意事项:这种模式保留了组织的自主权，同时支持企业范围的工作流，这为复杂、多组织庄园中一致的客服人员操作提供了基础。

Archetype 3：多供应商 A2A（Salesforce 主导的编排）

• 定义 中的主管客服人员通过 A2A 协议协调 Salesforce 本地客服人员和其他供应商（例如 Google/Vertex 或 LangGraph）客服人员之间的工作。
• 架构流:主管客服人员通过 A2A 协议调用内部和外部供应商客服人员，处理请求并编排计划。对于不支持 A2A 的外部系统，MuleSoft 可以公开“轻量级客服人员外观 ” , 封装现有工具并与 A2A 通信。
• 关键注意事项:这种原型通过使用 A2A 来生成干净、可治理的编配，而无需单独的编配层，从而使编配大脑与 CRM 和 Data 360 保持密切联系。

Archetype 4：多供应商 A2A（MuleSoft 主导的编排）

• 定义:编配从非 Salesforce 入口点启动，这需要中立的外部编配员来执行推理和路由。
• 架构流:外部系统中的 UI 客服人员将请求转发到编排服务(概念化为 MuleSoft Conductor ) , 该服务解释意图并计划任务。然后，指导员使用 A2A 将呼叫路由到供应商客服人员，包括适用于 CRM 或服务操作的 Agentforce 客服人员。
• 关键注意事项:此模式适用于非 Salesforce 入口点，其中中立编配器在架构上更可取。它将 UX 保留在域系统中，同时在 MuleSoft 中集中推理、治理、策略和可观察性。

这些单独的模式和编排原型是旨在组成端到端解决方案的建筑构件。代理解决方案映射用于可视化这些组件如何连接在一起。

• 适用于医疗保健提供商的会员服务解决方案是 SOMA 原型的标准实施。它使用适用于匿名用户的 Answerbot、适用于经过身份验证的成员的 Orchestrator 以及多个 Domain SME 客服人员（例如个案、索赔和福利）来处理特定请求。
• B2C 经纪人入口网站是一个复杂的组合，它使用入口网站管理员代理来调用长时间运行的 Project Manager 代理进行 RFP 流程，而 RFP 流程又使用无头代理、数据管理员和询问代理进行后台数据操作。

代理设计模式方法论提供了构建强大的、可扩展的和可维护的企业 AI 系统所需的架构纪律。通过分解复杂性和促进模块化，这些模式使架构师能够提供可靠、可预测的代理解决方案。

编排原型的选择是一项战略决策，它基于用户在哪里工作、上下文在哪里存在，以及企业如何管理人员、客服人员和系统之间的交互。通过了解构建客服人员和编排客服人员之间的区别 — 并通过利用 MCP 和 A2A 等开放协议 — 架构师可以超越创建孤立的机器人,而是设计一个内聚的、受管的和分布式的企业推理系统。这种方法提供了共享语言和一组可重用的蓝图来构建可持续的代理架构。

本附录提供了代理模式如何组成系统级解决方案的具体示例。

此图说明了如何将五个基本模式连接在一起，以创建通用客户服务工作流。

1. Answerbot:匿名用户提问，由 Knowledge 客服人员处理。
2. 运算符:员工的问题由话务员分类，话务员会处理对话，并将其交给更专业的客服人员。
3. 编配员:经过身份验证的用户 (SF 用户) 与协调多个客服人员的调度员接洽，以处理潜在的多方面查询。
4. 域 SME:编配员会调用专家客服人员（例如，HR 客服人员或福利客服人员），以执行主题更新并检索特定数据。
5. 发电机:实用程序客服人员用于在交互完成后汇总客户详细信息或总结个案。

此解决方案映射详细描述了成员服务用例的代理架构，展示了多个模式的组合。

• 用户简档:该解决方案为三种不同的用户类型提供服务：匿名用户、验证成员和 SF 用户（例如，人类 CSR）。
• 交互模式:Answerbot 处理匿名“Find-A-Doc”查询，而 Orchestrator (Agentic Front Door) 管理经过身份验证的用户查询。听众/摘要模式有助于 SF 用户。
• 域代理重用:专用域 SME 客服人员(例如个案客服人员、索赔客服人员或福利客服人员)可在不同的交互流中重复使用。
• 自主和辅助:该系统结合了自主客服人员(用于指导用户交互)和辅助客服人员(用于增强人的 CSR)。
• 数据源:该架构集成了公共和企业数据源，并广泛使用 Data 360 和 MuleSoft 进行连接。

此图说明了联系中心中辅助 AI 解决方案的逻辑架构，并将其组织成功能层。

• 编配员代理:管理不同角色的用户体验（例如，匿名、外部成员或 CSR），并编排整体交互流。
• 员工客服人员:多个中小企业代理侧重于 Knowledge、个案/索赔/福利和提供商目录等核心业务领域。还包括 Next Best Action 客服人员。
• 实用程序代理:执行特定的可重用任务，例如翻译、个案总结和呼叫汇总。 集成和核心系统：整个客服人员系统通过跨平台集成层连接到非结构化数据资源、结构化数据资源和核心企业系统。
• 治理:治理层为客服人员使用的 LLM/SLM 提供可观察性、评估和管理。

此解决方案地图详细描述了 B2B 健康保险经纪人入口网站的复杂、长时间的客服人员交互。该模型包括一个入口网站代理(Orchestrator ) , 它通过多个步骤(例如,提交 RFP 和接收建议书)为经纪人的旅程提供便利。该编配器调用项目经理客服人员，该客服人员反过来协调几个无头客服人员进行后台数据质量和转换，例如 RFP 提取器、人口普查转换和数据管理员。

此图显示了 B2C 经纪人解决方案的逻辑架构，展示了与联系中心类似的分层方法。它包括不同用户角色的编排人员代理、关键领域(例如 Knowledge、成员服务或佣金)的可重用工作人员代理以及翻译和汇总等特定功能的实用程序代理。

此图显示了提供商合同解决方案的逻辑架构。协调员客服人员管理完整的交互，员工客服人员管理域中的特定意图（例如，签约的 SME 客服人员），而实用程序客服人员执行独立的任务，例如比较合同或生成见解。

下表总结了一些关键的交互模式、典型用户体验和主要架构目的。

David Harshbarger 是一位成功的企业家和技术领导者,他曾为多家领先的软件公司工作,他设计的解决方案将架构的粒度与业务粒度保持一致,以便技术人员使用而不是反对他们的支持技术。如今，David 在 Salesforce 担任首席企业架构师，为健康和生命科学提供支持。

Chacha Choudhury 是一位成就卓著、富有远见的 IT CTO/首席架构师,拥有数十年的经验,目前担任首席企业架构师,领导 Salesforce 架构计划和全球架构师社区。他在制定企业范围技术战略、推动架构现代化以及开拓创新解决方案（包括生成式 AI 和客服人员 AI 应用程序）方面的专长得到了认可。