软件的模式正在从直接操纵转向面向目标的授权。处于这一转变前沿的是 AI 客服人员 — — 能够理解、推理和代表用户的自主智能实体。本白皮书对 AI 客服人员的主要类型进行了技术探索：会话、主动、环境、自主和协作。它定义了每种类型,提出了具体的客户关系管理(CRM)用例,为在 Salesforce Agentforce 平台上构建这些客服人员提供了架构蓝图,并提供了利用 Flow、Apex、Data 360、Agent2Agent (A2A) 通信和模型上下文协议(MCP) 互操作性的技术示例。

AI 客服人员是感知环境并采取行动实现具体目标的系统。虽然这一概念并不新鲜，但功能强大的大型语言模型 (LLM) 的出现增强了它们的能力。我们可以根据客服人员的主要操作和交互模式对其进行分类。

**定义：**对话客服人员是最熟悉的客服人员类型。它们以反应性、请求-响应的方式运行，主要通过自然语言界面（文本或语音）。它们的核心职能是理解用户的意图并提供相关的回答，无论是回答问题、获取信息还是执行简单的命令。

**重要性：**对话客服人员是组织的数字前门。他们擅长处理定义明确的重复任务，从而释放人力资源。它们的有效性由它们快速准确地解决用户意图以及代表用户采取行动的能力来衡量。

**定义：**与等待提示的对话客服人员不同，主动客服人员充当了保持警惕的观察者。它们由系统中的特定事件、数据更改或预定义条件触发。在触发时，他们执行任务或启动工作流，而无需用户直接交互。

**重要性：**主动客服人员将系统从被动的数据存储库转变为业务流程的积极参与者。它们识别新出现的业务机会和风险，使企业能够实时根据关键信号采取行动。

**定义：**环境客服人员是一种特定类型的主动客服人员，可在用户工作流的后台连续运行，无需明确命令。用户通常受益于他们的行动，而没有意识地意识到他们的操作，因为他们的目的是在保持低调的同时增强人的能力。

**重要性：**环境客服人员的目标是通过将世俗的“工作”自动化来减少用户的认知负担。它们通过无缝集成到员工每天使用的工具中，自动捕获和构建信息，提高了流程的效率。

**定义：**自治客服人员在复杂性方面有了重大飞跃。他们有一个高级目标，能够独立地规划和执行一系列步骤来实现这一目标。他们可以推理、决策，甚至从他们的行动中学习，随着时间的推移提高绩效。

**重要性：**这是我们最接近真正的数字员工的地方。自主客服人员可以被授予复杂的多步骤目标，例如“本季度在制造行业生成 50 个新的合格潜在客户”，并受信于制定和执行实现这一目标的计划。

**定义：**协作客服人员，通常称为“客服人员群”，是一组专门客服人员，他们一起工作，以解决任何单个客服人员都无法处理的复杂问题。“指挥员”或“主”客服人员通常分解一个大任务，将子任务委派给适当的专业客服人员，然后综合他们的输出。强大的 Agent2Agent (A2A) 通信协议实现了这一点。

**重要性：**这种方法反映了人类团队。通过分解复杂的问题，每个专业客服人员都可以发挥其独特的技能：一个专门从事数据分析，另一个专门从事客户沟通，第三个专门从事系统集成，从而获得更加强大和全面的解决方案。

在探索了 AI 客服人员的分类后，一个关键问题仍然存在：我们如何组合这些元素来高效可靠地解决现实世界的业务问题？本章通过提供常见代理设计模式的存储库来回答这个问题。每个模式都是应对重复性挑战的经过验证的解决方案，为从简单的单一用途客服人员到复杂的协作客服人员群的所有内容提供了蓝图。

对话客服人员通常是组织 AI 功能的大门。它们由它们参与有状态的、多轮的对话的能力来定义，充当用户使用自然语言执行任务和检索信息的主要界面。本节介绍了构建对话客服人员的两个基本模式，每个模式都针对特定渠道定制：一个用于消息传递客户端的快速交互式交换，另一个用于电子邮件的结构化异步性质。

对话客服人员的智能来自其在正确时间访问正确数据并进行推理的能力。这种模式依赖于复杂的数据基础，该基础连接到客户记录、Knowledge 文章和业务分析。第 4 章提供了这些集成的完整、可重用的模式：集成模式。

问题

客户通过多个数字渠道参与，并期望获得即时、上下文和智能响应传统聊天机器人要么是脚本聊天,要么是**数据盲聊天,**这导致个性化程度低、早期升级到人工聊天,以及服务成本高。

上下文

• 贵组织拥有多渠道数字参与（WhatsApp、SMS、Slack 和 Salesforce Experience Cloud）。
• 贵组织的客户以多种语言与贵组织互动。
• 贵组织需要通过客服人员增强服务和销售工作流，以便：
  • 从实时、可信的客户数据中提取
  • 遵守护栏和合规要求
  • 仅在必要时升级为人工客服人员

关键组件

• **渠道抽象：**Service Cloud 增强聊天（以前称为应用程序内和 Web 消息传递）允许客服人员通过单一体验在多个渠道进行通信。
• **Agentforce 服务代理：**客服人员的行为和目的由以下组件定义。
  • **主题和说明：**为直接用户交互定义客服人员的角色和对话目的。这包括其核心任务（例如，“您是解决客户支持问题的专家”），关于保持富有同情心和专业精神的说明，以及关于授权其处理的查询范围的明确防护。
  • **操作：**面向服务的操作，即客服人员用于实时诊断和解决客户问题的工具。这些工具旨在执行任务，例如检查订单状态、在 Knowledge 库中搜索解决方案或直接从对话界面创建新支持个案。
  • **护栏：**防护栏充当一组可配置规则和运行时检查，约束客服人员的行为。充当安全层，可以拦截提示，验证客服人员的建议操作，并筛选最终响应，以防止有害内容，强制执行业务规则，并确保客服人员在其指定范围内运行。
  • **提示模板：**通过合并字段或来自 Data 360 RAG 检索器的语义数据，使用实时 CRM 数据动态填充的可重用模板。这些模板允许客服人员生成上下文品牌内容，而 Einstein Trust 层在指令发送到 LLM 之前安全地屏蔽敏感信息。
• Data 360
  • Data 360 组件，包括 DLO、DMO、向量存储和 RAG 检索器，为客服人员提供所有相关企业数据的统一视图，从结构化客户记录到非结构化 Knowledge 文章，确保响应准确且基于上下文。
• Service Cloud
  • **CRM 数据：**将客服人员连接到完整的个案历史，提供关于客户详细信息、联系人记录和权利的关键上下文
  • **实时客服人员队列：**支持升级并路由到人工服务代表，并注入完整的对话上下文

交互

1. 贵组织的客户通过渠道发起对话。
2. 消息会发送到 **Agentforce，**由 Agentforce 确定范围（主题）并应用防护措施。
3. AI 使用提示模板撰写回复 而 Flow 或 Apex 可能触发后端逻辑
4. 通过 RAG 检索器，从 Data 360 对象、向量存储和 CRM 检索上下文。
5. AI 返回上下文答案。
6. 如果 AI 无法解析，对话会升级到 Service Cloud Live Agent。

权衡

相关模式

格里特模式:一种简单易于实施的模式，使用自然语言理解用户意图，然后将用户路由到适当的服务代表

运算符模式:构建于问候语，将请求路由到适当的专家 AI 客服人员或人工服务代表，如果需要，协商意图

编配器模式:管理 AI 客服人员群。它接收用户请求，确定意图，创建计划，将必要的数据传递给一个或多个专家客服人员，然后聚合用户的响应。与运算符不同，它仍然是第一个联系点。

问题

您的客户大量使用基于电子邮件的异步对话，这仍然是拓展的最佳方式。贵组织需要通过电子邮件联系这些客户，但销售开发代表无法在 SLA 中回复入站电子邮件，从而导致潜在客户流失。此外，员工会将时间花在不合格的潜在客户上。

上下文

• 贵组织将电子邮件作为主要潜在客户参与渠道。
• 您的 SDR 在大规模鉴定潜在客户方面的能力有限。
• 在与 SDR 或业务发展代表 (BDR) 会面之前，您的销售流程具有多点潜在客户培养。
• 贵组织需要通过以下方式增加客服人员的服务和销售额：
  • 从实时销售支持和销售产品和市场营销数据中提取
  • 遵守护栏和合规性
  • 根据潜在客户资格标准计划会议

关键组件

• **电子邮件渠道：**处理捕获入站消息、解析内容和附件以及保持线程连续性以启用异步对话。
• **Agentforce SDR 代理：**客服人员的行为和目的由以下组件定义。
  • **主题和说明：**定义客服人员的使命，通过对话吸引并鉴定入站潜在客户。这包括了解潜在客户需求、收集关键资格数据（例如，预算、授权和时间表）以及指导对话朝着明确的下一步前进的说明，例如安排与客户主管会面。
  • **操作：**使客服人员能够管理潜在客户生命周期的专用销售操作。这些工具旨在执行核心 SDR 任务，例如丰富潜在客户数据、发送模板化跟进电子邮件或与日历系统集成以预订发现呼叫。
  • **护栏：**防护栏充当一组可配置规则和运行时检查，约束客服人员的行为。充当安全层，可以拦截提示，验证客服人员的建议操作，并筛选最终响应，以防止有害内容，强制执行业务规则，并确保客服人员在其指定范围内运行。
  • **提示模板：**通过合并字段或来自 Data 360 RAG 检索器的语义数据，使用实时 CRM 数据动态填充的可重用模板。这些模板允许客服人员生成上下文品牌内容，而 Einstein Trust 层在指令发送到 LLM 之前安全地屏蔽敏感信息。
• Data 360
  • Data 360 组件，包括 DLO、DMO、向量存储和 RAG 检索器，为客服人员提供所有相关企业数据的统一视图，从结构化客户记录到非结构化 Knowledge 文章，确保响应准确且基于上下文。
• Sales Cloud
  • **CRM 数据：**将客服人员连接到完整的个案历史，提供关于客户详细信息、联系人记录和权利的关键上下文
  • **客户和 SDR 之间的计划会议：**SDR Live Agent 切换可以配置为使用任务和会议计划（后续操作）设置实时会议。
  • **活动日志记录：**捕获事件、任务和电子邮件活动，并将其与作为 SDR 客服人员交互结果的潜在客户、客户和业务机会相关联。

交互

1. 客户通过该渠道发送和接收电子邮件，该渠道路由到 Agentforce。
2. Agentforce 将主题、操作和防护应用于解析意图。
3. Agentforce 使用富含 CRM 和 Data 360 上下文的提示模板起草上下文响应。
4. 多轮电子邮件对话继续，直到解决或策略指南。
5. 对于合格的潜在客户，Agentforce 会安排会议并更新 CRM。
6. 如果意图超过 AI 范围，Agentforce 会升级到 Sales Cloud SDR，以获取人工服务代表响应。

权衡

相关模式

回答机器人模式:一种有效的自助服务模式，使用生成式 AI 来理解 Knowledge 检索的自然语言，而不仅仅是关键字

虽然上一节中的对话客服人员擅长对用户命令做出反应，但主动客服人员代表了一种范式转变：他们无需询问即可采取行动。本节提供了构建代理的架构模式，这些代理可以自主监控来自 Salesforce 外部和内部的数据和事件。

问题

贵组织会在 Salesforce 内部和外部生成关键业务事件。很难将它们转化为及时的上下文操作，因为它们分散在应用程序和部门中。

上下文

• 您的业务流程跨越 CRM、付款处理、发货、营销自动化、遥测和 CDP 的多个系统。
• 您的组织事件全天候发生，但您的劳动力在工作时间之外的可用性有限。系统始终打开，但人类未打开。
• 事件缺乏上下文感知 — 它们错过了 Salesforce 中可用的客户上下文，迫使信息进行多步骤连接。如今，实施要么作为离散的复杂自动化存在，要么手动执行。
• 人类充当编译器来收集数据(以不同的格式 ) , 并对不相交的事件做出智能反应。
• 您的目标操作应用于多个系统。

关键组件

• 事件源
  • 在外部数据被接收到 Data 360 后，数据操作触发的事件
  • 能够通过 Salesforce 发布/订阅 API 将事件发送到 Salesforce 的第三方或 Salesforce Heroku MCP 服务器
  • 能够通过 Salesforce 发布/订阅 API 发送事件通知的外部应用程序
• **可选中间件：**MuleSoft 或 Data 360 用于转换
• **Agentforce 客服人员：**客服人员的行为和目的由以下组件定义。
  • **主题和说明：**指定客服人员的核心任务及其触发器，包括定义主要目标（例如，“监控所有高优先级个案并防止违反 SLA”）。包含客服人员启动任务时应监听的特定事件或数据条件
  • **操作：**事件触发和计划的操作，旨在响应外部事件。虽然这些操作针对常规任务自主操作，但它们通常包括编排涉及人为干预的工作流的能力，升级为用户进行审核、批准或处理需要人为判断的场景。
  • **护栏：**防护栏充当一组可配置规则和运行时检查，约束客服人员的行为。充当安全层，可以拦截提示，验证客服人员的建议操作，并筛选最终响应，以防止有害内容，强制执行业务规则，并确保客服人员在其指定范围内运行。
  • **提示模板：**通过合并字段或来自 Data 360 RAG 检索器的语义数据，使用实时 CRM 数据动态填充的可重用模板。这些模板允许客服人员生成上下文品牌内容，而 Einstein Trust 层在指令发送到 LLM 之前安全地屏蔽敏感信息。
• Data 360
  • Data 360 组件，包括 **DLO 和 DMO，**存储外部系统生成并发送到 Salesforce 的事件数据，转换和构建流或实时见解
  • 计算、流和实时见解为客服人员提供有关客户的即时相关数据。这样就能先发制人地解决问题，缓解升级。数据图形主动显示来自不同数据源的关系和见解,能够及早发现与客户参与、活动和简档相关的模式或异常。
  • Data 360 向量存储和 RAG 检索器为客服人员提供了所有相关企业数据和非结构化 Knowledge 文章的统一视图,确保回复准确并符合上下文。
• 事件目标
  • 主动通知员工或联系客户
  • 可扩展到客服人员（请参阅环境客服人员和自主客服人员模式）

交互

1. 外部系统发生了显著的变化。
2. 外部系统会发出事件，并通过 API（创建平台事件）或发布/订阅 API 将其发布到 Salesforce 事件总线，或者事件数据会流式传输到 Data 360。
3. 触发事件的订阅者。触发流。
4. 流会使用事件数据调用客服人员操作。客服人员确定并执行正确的操作流程。
5. 结果是触发通知或工作流。通知在协作工具（例如 Slack）中传递给用户。也会生成任务或事件。此外，操作可以调用外部系统。因此，事件不会丢失，而是主动执行、发出信号并采取行动，消除了发现它们的人工开销或复杂的自动化。

权衡

相关模式

法官和陪审团模式:可与此模式结合使用，通过利用多个“陪审员”客服人员和“法官”客服人员进行一致性评估，确保 AI 支持的决策的准确性和可靠性

模型模式:这种模式包含来自多个专家客服人员的不同观点，以产生更丰富的见解，从而补充主动 AI 的智能响应。

问题

贵组织的 Salesforce 生态系统会生成持续的信号流，但难以将它们转化为及时的上下文操作，因为它们需要业务逻辑、治理和人员来分类和行动。在许多情况下，信号丢失，而没有任何操作导致业务机会丢失。

上下文

• 贵组织使用一个或多个 Salesforce Cloud：销售、服务、市场营销、商业、健康、制造和其他。
• 您需要智能分类，而不仅仅是简单的路由或基于规则的分类。贵组织维护数百个复杂的业务规则。
• 您需要对事件进行实时或接近实时的响应。
• 偶尔，您最特权的管理员会因为看不到信号而成为链中最薄弱的一环。

关键组件

• 事件源层
  • 来自低级别平台活动的 CRM 数据、平台事件、变更数据捕获 (CDC) 数据和实时事件监控 (RTEM) 数据
• Data 360
  • Data 360 组件，包括 **DLO 和 DMO，**存储 CRM 或平台事件生成的事件数据，转换和构建流或实时见解
  • 计算、流和实时见解为客服人员提供有关客户、员工活动或系统中元数据变化的即时相关数据。这样就能先发制人地解决问题，缓解升级。这种实时情况感知使客服人员能够为治理和合规运营吞吐量提供及时的干预措施。
  • 数据图形主动显示来自不同数据源的关系和见解,能够及早发现与客户参与、活动和简档相关的模式或异常。
  • Data 360 向量存储和 RAG 检索器为客服人员提供了所有相关企业数据和非结构化 Knowledge 文章的统一视图,确保回复准确并符合上下文。
• **Agentforce 客服人员：**客服人员的行为和目的由以下组件定义。
  • **主题和说明：**指定客服人员的任务，以根据 Salesforce 中的数据更改强制执行业务规则和自动化流程。它定义了客服人员的目标（例如，“确保所有业务机会在到达协商阶段之前都由一个主要联系人更新”）以及触发客服人员的特定记录创建、字段更新等。
  • **操作：**事件触发和计划的操作，旨在响应内部 Salesforce 事件。虽然这些操作针对常规任务自主操作，但它们通常包括编排涉及人为干预的工作流的能力，升级为用户进行审核、批准或处理需要人为判断的场景。
  • **护栏：**防护栏充当一组可配置规则和运行时检查，约束客服人员的行为。充当安全层，可以拦截提示，验证客服人员的建议操作，并筛选最终响应，以防止有害内容，强制执行业务规则，并确保客服人员在其指定范围内运行。
  • **提示模板：**通过合并字段或来自 Data 360 RAG 检索器的语义数据，使用实时 CRM 数据动态填充的可重用模板。这些模板允许客服人员生成上下文品牌内容，而 Einstein Trust 层在指令发送到 LLM 之前安全地屏蔽敏感信息。
• 事件目标
  • 主动通知员工或联系客户。
  • 可扩展以呼叫其他客服人员（查看环境 AI 和自主 AI 模式）

交互

1. 内部系统会发生显著变化，例如更新 CRM 记录、元数据修改或从 Data 360 触发的数据操作。
2. 内部系统会发出事件，并通过 API（创建平台事件）或发布/订阅 API 将其发布到 Salesforce 事件总线，或者事件数据会流式传输到 Data 360。
3. 触发事件的订阅者，并激活流或 Apex。
4. 激活的流或 Apex 调用客服人员操作。
5. 结果是触发通知或工作流。通知在协作工具（例如 Slack）中传递给用户。也会生成任务或事件。此外，操作可以调用外部系统。
6. 因此，事件不会丢失，而是主动执行、发出信号并采取行动，消除了发现它们的人工开销或复杂的自动化。

权衡

相关模式

听众/摘要模式:可与监听器模式结合，根据内部 Salesforce 事件触发主动操作

数据管理模式:主动式 AI 可以利用数据管理员来确保响应内部事件时的数据质量和一致性

Zen Data Gardener 模式:对于由内部事件触发或定期触发的预定的主动数据整理和标准化

我们从在对话渠道中交互响应的客服人员开始，然后发展到对特定事件做出反应的客服人员。超越主动客服人员的事件驱动模型，环境客服人员代表了从直接交互到主动后台帮助的范式转变。这些是在后台观察数字环境的无头客服人员。他们充当系统的“耳目”，从用户活动或数据流中感知上下文，然后与其他客服人员或人员协调，以完成任务、显示见解或提供指导。

问题

贵组织的业务活动会生成持续的宝贵信息流（通话、会议、聊天、传感器数据等），但这些数据会实时消失，无需捕获或分析。当人类手动记录这些交互时，关键见解已经丢失，及时干预的时刻已经过去。组织错过了实时需要的大部分可操作智能,并被淹没在短暂的流中,导致差距、失去辅导机会和在没有完整上下文的情况下做出决策。

上下文

• 业务活动会从各种来源生成连续流，包括语音和视频会议、实时聊天、传感器遥测、屏幕活动和事务数据。
• 您需要实时或接近实时的见解（在几秒钟或几分钟内，而不是几小时或几天内），以有效地响应这些流并采取行动。
• 手动文档流程失败，其特点是合规性和刷新率低，员工认知负担重，以及重要信息捕获不完整。
• 您需要多模态理解，结合音频、视频、屏幕共享、聊天和其他元数据中的数据，以创建完整准确的交互和事件上下文。
• 您需要即时分析进行实时辅导和警报，还需要历史分析进行互动后汇总和长期趋势识别。
• 时间上下文（情节记忆）对于您的分析至关重要，包括了解数据流中各个时间窗口的顺序、时间、转换和模式。

关键组件

• 流源
  • 语音和视频：视频会议工具（例如 Slack Huddle、Zoom、Google Meet 和 Microsoft 团队）和电话系统
  • 协作工具：Slack、团队和其他
• 流捕获连接器
  • 本地 SDK：供应商提供的 SDK，帮助检索支持实时流段或脚本的脚本或消息
• （可选）流处理层
  • 对于音频流，如果脚本不是实时可用的，是一种将音频转换为文本的语音到文本的功能。您也可以使用受管提供商，例如 Amazon Transcribe。
  • 对于其他数据流，可以选择流处理引擎，例如 Data 360 或 Apache Flink
• Data 360
  • Data 360 组件，包括 **DLO 和 DMO，**用于存储事件数据，转换和构建流或实时见解
  • 计算、流和实时见解为客服人员提供有关客户、活动和关键见解的即时相关数据。这样就能先发制人地解决问题，缓解升级。这种实时情况感知使客服人员能够为员工提供及时的干预和个性化支持，从而优化客户满意度和运营吞吐量。
  • Data 360 组件，包括 **DLO 和 DMO，**用于存储客户数据，转换和构建实时见解
  • Data 360 向量存储和 RAG 检索器为客服人员提供了所有相关企业数据和非结构化 Knowledge 文章的统一视图,确保回复准确并符合上下文。
• Agentforce 客服人员此模式重点关注观察连续数据流的环境客服人员，例如实时通话脚本或视频摘要。它充当实时监听程序，在发生非结构化数据时对其进行解释。例如，监听实时通话的客服人员可能会调用数据发现客服人员，以根据对话中共享的新上下文丰富潜在客户的记录。以下是此类无头客服人员的示例：
  • **反馈客服人员。**客服人员的行为和目的由以下组件定义。
    • **主题和说明：**定义客服人员的主要任务，以分析对话流并提取结构化反馈和绩效指标。这包括监控客户情绪的说明，确定对关键产品或竞争对手的提及，并评估人工客服人员是否遵守公司最佳实践或销售手册。
    • **操作：**将非结构化对话数据转换为可操作的业务智能的操作。这些操作使客服人员能够创建“反馈汇总”记录，记录产品功能请求，标记带有负面情绪的呼叫以供经理审查，并更新仪表板以根据关键度量跟踪客服人员的整体绩效。
    • **护栏：**防护栏充当一组可配置规则和运行时检查，约束客服人员的行为。充当安全层，可以拦截提示，验证客服人员的建议操作，并筛选最终响应，以防止有害内容，强制执行业务规则，并确保客服人员在其指定范围内运行。
    • **提示模板：**结构化、模板化的 LLM 指令，可以接收输入并提供 LLM 生成的输出
• 环境目标
  • 在客服人员和用户所在的位置通知用户，例如在视频通话或桌面应用程序中

交互

1. 当流被激活时（例如当用户加入视频通话时），客服人员将自己附加为观察者。
2. 客服人员开始接收流数据，增量检测意图，做出决策，并调用操作。
3. 客服人员根据意图进行上下文化，并获取其他数据（结构化或非结构化）。
4. 客服人员提供即时的实时响应，无需用户提示：它可以在销售电话中检测到异议，并提供重要信息来处理异议。
5. 客服人员可以编译合并汇总和操作，并与其他客服人员和用户共享。

权衡

相关模式

听众/摘要模式:可与监听器模式组合，以处理实时对话和用户交互数据流，并显示相关上下文和见解

询问者模式:可与此模式结合使用，以从流中的多个来源汇总上下文并回答问题

问题

您的员工每天通过电子邮件、日历、通话和应用程序执行数百个关键业务活动，但在手动记录之前，这些活动对组织系统不可见，这种情况很少发生。这种活动盲目性意味着 CRM 数据不完整，AI 模型缺乏智能推荐所需的信号，经理没有实时了解客户参与度。手动活动日志会创建生产力税，同时仍缺少大部分实际工作。

上下文

就像流观察器一样，这是一个数据和内容观察器，它提供可操作的任务或代表用户执行操作。

关键组件

• 数据层
  • CRM 数据 中可用的客户数据为客服人员提供上下文（例如，当用户在业务机会页面上时，客服人员可以从 CRM 检索有关业务机会和相关客户的信息）。
  • Data 360 组件，包括 **DLO 和 DMO，**存储从不同来源接收的相关客户数据
  • 计算、流和实时见解为客服人员提供有关客户、活动和关键见解的即时相关数据。这样就能先发制人地解决问题，缓解升级。
  • Data 360 向量存储和 RAG检索器为客服人员提供了所有相关企业数据和非结构化 Knowledge 的统一视图。
• **Agentforce 客服人员：**此模式重点关注直接在 UI 中观察用户操作的环境客服人员。它充当实时助手，了解用户工作流的上下文以提供指导。例如，客服人员可能会监控服务代表填写个案记录，并主动显示相关 Knowledge 文章。以下是此类无头客服人员的示例：
  • **反馈客服人员。**客服人员的行为和目的由以下组件定义。
    • **主题和说明：**定义客服人员的任务，以监控用户在 UI 中的操作并提供上下文帮助。这包括它的目标（例如，“指导服务代表完成个案解决过程”）以及它应该注意的特定 UI 事件或数据输入模式，以便主动提供帮助。
    • **操作：**使用 Apex 或流构建的操作，直接在用户的工作流中显示相关信息和 Next Best Action。这些操作使客服人员能够获取并显示相关 Knowledge 文章，建议流程中有效的下一步，或标记可能违反业务规则的数据输入字段，所有这些都是对用户实时活动的响应。
    • **护栏：**防护栏充当一组可配置规则和运行时检查，约束客服人员的行为。充当安全层，可以拦截提示，验证客服人员的建议操作，并筛选最终响应，以防止有害内容，强制执行业务规则，并确保客服人员在其指定范围内运行。
    • **提示模板：**通过合并字段或来自 Data 360 RAG 检索器的语义数据，使用实时 CRM 数据动态填充的可重用模板。这些模板允许客服人员生成上下文品牌内容，而 Einstein Trust 层在指令发送到 LLM 之前安全地屏蔽敏感信息。
• 环境目标
  • 在客服人员和用户所在的位置通知用户，例如在网页或管理员页面上

交互

1. 在用户访问页面或应用程序时，客服人员将自己附加为观察者。
2. 客服人员开始检查数据和操作，增量检测意图，做出决策，并调用操作。
3. 客服人员根据意图进行上下文化，并获取其他数据（结构化或非结构化）。
4. 客服人员提供即时实时响应，无需用户提示，并可以代表用户建议 Next Best Action 或主动执行。
5. 客服人员可以与其他客服人员和用户无缝共享。

权衡

相关模式

听众/摘要模式:可与监听器模式结合，根据观察到的活动触发主动操作

数据管理模式:活动拦截 AI 可以利用数据管理员来确保记录拦截的活动时的数据质量和一致性。

发电机模式:可用于根据拦截的活动自动生成活动汇总或后续任务

本节详细介绍了协作客服人员的模式，其中一个或多个客服人员与人工用户协作以实现共同目标。这些模式侧重于创建无缝的伙伴关系：客服人员处理复杂的数据收集和任务执行，同时让人员掌握决策、批准和战略指导。

在此模型中，客服人员处理工作流的可自动化部分。该过程成为动态反馈循环。

• 人员可以通过对话客服人员启动任务，这会触发主动客服人员管理后端步骤。
• 同时，环境客服人员可能会观察他们的操作，以提供实时指导。

该流程实现了人类和数字劳动力的无缝融合。此模式展示了 Agentforce 如何促进多客服人员、人工在环系统，以处理任何单个客服人员或人工都无法单独管理的复杂工作。

问题

您的业务流程需要来自不同组织（内部和外部）的员工之间的协作，每个组织都有不同的工作需要不同的技能和优先级来完成。由于资源容量、技能限制或交换的信息量，流程瓶颈可以随时随地出现。

上下文

• 流程跨越团队，需要多个团队成员协作，才能取得成功结果。
• 客服人员助手已经在一对一的场景中作为对话、主动和环境客服人员帮助员工。
• 进程在业务流程的适当分段中使用客服人员。但是，流程也需要人力-客服人员协作。这种协作可能涉及在客服人员的协助下的人与人之间的协作，或人-客服人员-人的协作。
• 技能差距由客服人员填补。
• 客服人员通过减少跟进和交换重要信息以帮助决策等任务中的人力，帮助改善协作。
• 客服人员也可以根据策略和准则进行协作和委派。

关键组件

• 协作表面
  客服人员协作需要一个共享空间，所有参与者（包括人员和客服人员）都可以在其中交互。这些协作表面不再是静态的、仅限人类的环境。相反，这些渠道可以邀请客服人员加入、参与甚至发起对话，从根本上改变了团队合作的性质。例如，客服人员可以在 Slack 中创建并启动个案群，邀请人工主题专家和其他客服人员就个案进行协作。

• Agentforce 客服人员
  该模式超越了单个客服人员模式，以展示他们如何在协作客服人员模型中收敛，编排复杂的流程，从而智能地增强人员的能力。上述模式（对话 (2.1)、主动 (2.2) 和环境 (2.3)）定义了 Agentforce Agent components.c 方向。对话客服人员充当主要界面，与人员并肩工作，充当人员与参与协作的所有客服人员之间的界面。当任务过多时，对话客服人员会启动协作会话，将人工用户和必要的无头客服人员召集在一起，同时处理问题。 该流程成为一个动态反馈循环，其中人员可能发起任务，然后触发主动客服人员管理后端步骤，而环境客服人员可能会观察以提供实时指导，从而创建人员和数字工作人员的无缝融合。

• 数据层
  在协作客服人员模型中，数据层扮演的角色比简单地提供信息更动态；它成为整个人工客服人员团队的持久记忆和共享工作区。虽然每个参与的客服人员都有其各自模式中定义的特定数据需求，但他们在复杂任务上的协作取决于跟踪整体作业状态的共享数据基础。

  此共享状态至关重要。当任务从对话客服人员转移到主动客服人员，然后转移到人员进行审批时，数据层必须跟踪每个步骤的进度、上下文和决策。这将确保每个参与者对事件拥有一致的最新视图。

交互

1. 人员发起与其他人员和客服人员的协作会话。
2. 定义了上下文、目标、作业和结果。
3. 客服人员通过引入更多信息来丰富上下文，并主动计划完成工作所需的步骤，以及所有人（人或客服人员）。
4. 观察进度，更新上下文，并执行操作。
5. 在客服人员执行任务时，客服人员会提供详细信息，以帮助人类利益相关者理解推理、提供反馈并允许拦截。
6. 客服人员以完全透明和合规的方式完成工作。

权衡

相关模式

运算符模式:协作客服人员通常充当接线员，将请求路由到适当的专家 AI 客服人员或人工服务代表，并协商意图。

编配器模式:在涉及协作的场景中，编配员客服人员管理一群 AI 客服人员，聚合他们的响应，以获得无缝的用户体验。

工作区 (Radar O'Reilly) 模式:协作客服人员使用此模式来管理响应迅速的单窗格 UX，并在对话流中实时更新相关内容。

与帮助用户的协作模式相反，自主客服人员专为完全委派而设计。本节为客服人员提供了架构蓝图，客服人员可以独立规划和执行复杂的多步骤任务，以实现高级别目标，而无需人工干预。此处的重点是创建一个您可以分配目标和 Trust 任务的系统，以便从头到尾执行它。

问题

贵组织通过一组高度复杂的流程实现价值，每个流程都有不同的策略驱动的工作、行动手册和执行所需的特定技能。这些计划通常需要大量的时间和资源投资。

设置新计划需要很高的开销，并且可能需要几个月的时间才能实现价值。实施反馈和改进通常需要额外的时间和精力。复杂性主要由您的组织的结构所驱动，其中分布式应用程序和流程会导致依赖性，需要人类来管理项目。

上下文

• 客服人员可以从头到尾独立操作。客服人员经过设计和配置，因此目标、计划和策略已预先确定。
• 客服人员可以做出所有决定，而无需寻求人工批准。为客服人员提供策略和合规指南。
• 客服人员可以访问所需的必要上下文和数据，并可以执行必要操作，而无需人工。
• 人员会收到通知，但不会“在循环中”。

关键组件

• 目标和策略定义层
  • **进程行动手册：**自动执行的详细描述，以及客服人员必须遵守的确定性规则
  • **自主决策条件：**使客服人员无需人工批准即可做出决策的规则
  • **后备规则：**在客服人员的主要流程失败时处理默认或异常情况的预定义操作
  • **范围：**清晰定义的边界，概述客服人员可以做什么和不可以做什么，包括如何处理范围外的情况
  • **完成的成功条件和定义：**确定客服人员任务何时成功完成的度量和条件
• Agentforce 客服人员
  • **客服人员编配员或编配员：**负责目标、原因和计划执行的主要客服人员
    • 主题和说明:在定义目标后，编配员或编配员客服人员会率先将该总体目标分解为更小的、易于管理的工作或子任务。它设计了一个全面的计划，概述工作的顺序，并确定每个步骤所需的特定客服人员或工具。最后，编配员客服人员确保无缝执行计划，监控进度，管理依赖性，并根据需要进行调整，以高效有效地实现目标。在编舞客服人员的情况下，它会将上下文和状态传递给下游客服人员，以完成作业。
    • **操作：**操作调用工具以执行功能、检索数据或委派给其他无头客服人员，从而支持更广泛的功能和更复杂的工作流。
    • **护栏：**防护栏充当一组可配置规则和运行时检查，约束客服人员的行为。充当安全层，可以拦截提示，验证客服人员的建议操作，并筛选最终响应，以防止有害内容，强制执行业务规则，并确保客服人员在其指定范围内运行。
• 数据层
  • **CRM 数据：**CRM 中可用的客户数据，可为一个或多个客服人员提供上下文
  • Data 360 组件，包括 **DLO 和 DMO，**存储从不同来源接收的相关客户数据
  • 计算、流和实时见解为客服人员提供有关客户、活动和关键见解的即时相关数据。这允许先发制人地解决问题（例如处理电子邮件退回），缓解升级。
  • Data 360 向量存储和 RAG检索器为客服人员提供了所有相关企业数据和非结构化 Knowledge 的统一视图
  • 提供对话上下文的 Slack 渠道消息或对话数据，例如个案历史和对话客服人员历史
• 监控和监督
  • **客服人员目标进度监控：**跟踪自主客服人员会话的进度，以衡量结果并确保与目标保持一致
  • **客服人员操作监控：**跟踪自主客服人员的实时状态，以进行干预和故障排除，确保平稳运行
  • **客服人员治理监控：**跟踪跟踪和审计日志，以确保自主客服人员遵守预定义的目标、目的和道德准则

交互

1. 作业定义具有明确的结果。
2. 作业通过以下方法之一启动：
   • 客服人员被分配任务。
   • 客服人员根据资格主动获取作业。
   • 客服人员在后台执行任务。
3. 客服人员清楚地建立预期并通知员工，详细说明目标、计划和策略。该计划详细说明了逐步流程、使用的客服人员、使用的数据、范围、客服人员评估计划和检查点，以便人员监控进度、运营和治理。
4. 客服人员开始执行。在每个重大事件上，它会更新状态和进度。人员可以根据需要提供反馈或拦截客服人员。
5. 客服人员完成作业。结果和结果在监控仪表板中可用。

权衡

相关模式

项目经理模式:自治客服人员通常体现这种模式，以最少的人为干预来监督从启动到完成的长期、多步骤的过程。

配置器模式:自治客服人员可以使用此模式根据自然语言要求或预定义策略自动生成和验证配置，无需手动监督即可确保合规性和准确性。

Zen Data Gardener 模式:自主客服人员可以使用此模式进行计划的后台数据整理和标准化，确保数据质量和长期一致性，以支持客服人员做出准确的决策。

现在，我们将通过探索如何在 Salesforce 平台上实施客服人员分类和客服人员模式来介绍它们。对于那些不熟悉 Agentforce 核心组件的人,附录提供了本章和下一章中引用的关键技术的有用复习材料。

本节对客服人员进行分类，并使用常见用例对每个客服人员进行说明，以显示如何在真实应用程序中使用。

客户 Jane 访问公司网站，查看最近订单的状态。

• **交互：**Jane 会打开聊天窗口（Agentforce 聊天客户端）。
• **客服人员操作：**对话客服人员问候她，并询问如何提供帮助。Jane 问：“我的最新订单在哪里？”
• 进程：
  1. 客服人员根据 Salesforce 中的 Jane 客户信息，识别她最近的订单。
  2. 它（通过 MuleSoft 连接器）向运输系统查询最新的跟踪信息，并为 Jane 提供实时更新和跟踪链接。
  3. 然后，它会查找保单，并自动升级到快速发货。
  4. 当 Jane 提出客服人员无法处理的复杂问题时，它会将聊天无缝升级到人工服务代理，并提供上下文的完整脚本。

模式

使用的模式：对话式 AI 模式，将事务数据集成到客服人员

设计时间

1. 设置对话客服人员。

   设置增强聊天	→	创建服务代理	→	定义支持订单主题	→	创建获取订单操作
   						↓
   添加出站升级全方位流	←	创建升级主题	←	将操作添加到主题	←	创建获取状态操作
   ↓
   发布客服人员

2. 将增强聊天设置为 Jane 的聊天入口点，以便她在网页中打开 Agentforce 窗口。
3. 启用 Agentforce 并在 Agentforce 生成器中创建服务代理，以处理对话和触发自定义操作。
4. 使用描述和说明定义支持订单主题，以便客服人员自然识别“我的最新订单在哪里？”。
   1. 创建自定义客服人员操作：
      1. 获取联系人的最新订单操作，以检索 Jane 的最新订单
      2. 按订单 ID 获取发货状态操作，通过 MuleSoft 获取跟踪信息
      3. 或者，使用外部服务操作，在流中编排两个操作 — 获取最新订单和调用 MuleSoft。
      4. 将这两个操作添加到生成器中的服务代理，将它们链接到订单和跟踪主题，然后发布。
5. 定义升级主题，其中包含要升级为服务代表的描述。
   • 创建并激活出站全方位流。
   • 将其添加到生成器中的“连接”选项卡，以便使用升级消息进行升级。
6. 设置全方位。

   配置全方位

   →

   在说明中定义升级规则

   →

   设置优先级和容量

   →

   测试和验证

7. 在 AI 客服人员无法解析查询时，启用无缝升级到人工客服人员。配置全方位路由，将聊天分配到服务代表，并为上下文传输完整脚本。
8. 将升级逻辑集成到 Agentforce 指令和升级操作中，以便客服人员了解何时转移复杂个案。通过全方位主管管理路由优先级和容量。
9. 测试完整体验：Jane 打开聊天，客服人员问候她，识别她的订单，检索发货数据，并在需要人为干预时无缝升级(另请参见启用增强事件日志)。
10. 设置数据集成。

    映射上下文数据

    →

    创建 MuleSoft API 凭据

    →

    注册 MuleSoft 外部服务

11. 通过经过身份验证的聊天或聊天前表单映射联系人和订单记录，将客服人员与 Jane 的 Salesforce 上下文联系起来。
12. 使用外部凭据和命名凭据进行身份验证，将 Salesforce 安全地连接到 MuleSoft 运输 API。
13. 如果 MuleSoft 公开 OpenAPI 规范，请将其注册为外部服务，以便流和客服人员可以声明性地调用它。
14. 设置非结构化数据集成。
    1. 从“设置”中创建新数据库。将其命名为“订单和发货策略”。
    2. 添加包含运输策略例外的保单文档的 PDF。
    3. 在后台，文档会自动分块、编入索引并准备好使用。

客服人员运行时流程流

在设置和部署客服人员后，以下步骤将在运行时发生。

1. **聊天启动：**Jane 打开 Agentforce 聊天（嵌入服务）。Jane 登录后，会话和联系人上下文加载。

2. **问候和意图：**客服人员问候 Jane。Jane 询问订单的状态，意图检测将“最新订单”映射到订单和跟踪主题。

3. **CRM 查找：**客服人员触发“获取最新订单”操作，并向 Salesforce（订单汇总/订单）查询 Jane 的最新记录。

4. **发货查询：**客服人员通过命名凭据调用 MuleSoft API，/shipping/status/{orderId} 返回实时状态和跟踪 URL。

5. **响应组成：**Agentforce 合并结果并撰写响应：“您的订单 [OrderID] 通过 [承运人] 发货，明天到达 — [跟踪这里]。”

6. **回退：**如果没有匹配项或 API 失败，客服人员将道歉，并表示重试，以解决任何数据问题。

7. **升级：**复杂或情绪查询通过全方位自动转移到人员，传递完整的聊天和上下文。

8. **记录：**所有意图、操作和结果都存储在交互日志中。在 Anypoint Monitoring 中监控 API 延迟。

9. **持续改进：**升级会为 Agentforce 重新培训提供摘要；常见流将在后续版本中完善。

一位高价值客户 John 将价值 1,000 美元以上的产品添加到了他的在线购物车中，但没有在 60 分钟内完成购买。

• **触发器：**Salesforce 平台事件 Cart_Abandoned__e 从电子商务系统中触发，其中包含 John 的联系人 ID 和购物车值。
• **客服人员操作：**订阅此事件的主动客服人员会立即投入行动。
• 进程：
  1. 客服人员会在 Salesforce 中检查 John 的记录，并查看他是 VIP 客户。
  2. 它为 John 的客户经理 Sarah 创建了一个高优先级的任务，其中包含了已放弃购物车的所有详细信息。
  3. 它通过 Slack 向 Sarah 发送通知，敦促她跟进。
  4. 同时，它会将 John 注册到目标 Marketing Cloud 旅程中，该旅程会发送一封带有限时 10% 折扣代码的提醒电子邮件，以鼓励他完成购买。

模式

此模式详细介绍了在 Salesforce 平台上实施主动式 AI 客服人员，以解决 VIP 客户放弃高价值购物车的问题。该解决方案利用 Salesforce Platform Events、Data 360 for Knowledge 检索和 Agentforce 来编排及时和智能的后续行动，从而将被动数据转化为主动的业务参与。

设计时间

1. 设置当 VIP 客户 John 放弃购物车时触发的放弃购物车事件。

   创建自定义联系人字段

   →

   定义新平台事件

   1. 使用联系人 ID、购物车价值、购物车上次更新日期时间和购物车详细信息字段创建 Cart_Abandoned__e 平台事件。
   2. 配置放弃事件：使用 Commerce Cloud，为 Checkout 事件通知创建平台事件。当购物车 Checkout 会话状态处于中间状态，并且会话在阈值后超时时，检测到放弃。或者，如果您的电子商务是外部系统，请使用以下任何方法将事件发布到 Salesforce：流、Apex、Salesforce API 或发布/订阅 API。
   3. 在联系人对象中，使用选项列表值标准、高级和 VIP 创建新字段 Customer_Tier__c。
2. 在 Data 360 中设置非结构化数据接收：通过 Amazon S3，将来自文档存储库的折扣策略文档添加到 Data 360。

   创建 AWS S3 凭据	→	创建新的 S3 数据流	→	配置和部署流	→	创建搜索索引
   						↓
   				测试检索功能	←	配置和部署索引

   1. 创建外部凭据以访问 S3：为 IAM 用户创建新访问密钥和密码集，或为 IdP 创建 IAM Amazon 资源名称 (ARN)。
   2. 创建新的 S3 数据流：在数据流选项卡上，创建数据流策略文档流，选择 S3 源，选择 PDF 文件类型，设置刷新频率，映射元数据字段（文件名和大小），然后部署。
   3. 数据流完成后，创建搜索索引：将通道提取用于分块、E5-large-v2 嵌入模型和混合搜索类型，然后部署索引。
   4. 测试创建的检索功能。
3. 设置 VIP 购物车恢复客服人员。

   从模板创建客服人员	→	添加恢复 VIP 购物车主题	→	添加主题说明	→	创建 Slack 警报操作
   						↓
   将操作添加到主题	←	创建旅程注册操作	←	创建折扣优惠操作	←	创建购物车恢复任务

   1. 从 Agentforce 员工客服人员模板创建客服人员。
   2. 添加新主题“恢复 VIP 购物车”，并说明该客服人员为 VIP 客户处理高价值购物车放弃。
   3. 添加主题说明，以验证 VIP 状态，授予购物车资格，通知 Slack 中的客户经理，推荐折扣优惠，并将客户加入购物车恢复电子邮件旅程。
   4. 创建操作和任务。
      • 提醒客户经理操作：发送主动 Slack 通知
      • 恢复丢弃的购物车任务，分配给经理，并提供购物车详细信息
      • 获取折扣优惠操作：分析保单和以前的购买历史。使用基础训练创建提示模板，在提示模板中引用检索功能，并使用数据。
      • 注册恢复旅程操作：通过 API 注册 Marketing Cloud 恢复过程，并接收所有订阅者数据和客服人员生成的折扣优惠电子邮件消息。
   5. 将操作添加到主题。
   6. 在 Marketing Cloud 中使用模板创建 VIP 客户购物车恢复旅程，或创建新旅程。
4. 发送平台事件以呼叫客服人员。

   创建事件触发的流

   →

   订阅平台事件

   →

   添加客服人员可调用操作

   →

   将事件数据传递给客服人员

   1. 创建新的平台事件触发的流，即 VIP 购物车放弃恢复。
   2. 选择流应订阅的购物车已放弃事件。
   3. 在 Flow Builder 中设置自定义客服人员可调用操作，并选择 VIP 购物车恢复客服人员。发送请求，为客户启动 VIP 放弃的购物车恢复，并发送平台事件负载。

客服人员运行时流程流

在设置和部署客服人员后，以下步骤将在运行时发生。

1. **购物车放弃检测：**John 将 1200 美元添加到购物车，60 分钟后没有 Checkout 或阶段进度触发放弃。
2. **平台事件发布：**Commerce Cloud 发布 Cart_Abandoned__e 事件，其中包含 John 的联系 ID、购物车价值 1200 美元、购物车修改日期和其他详细信息。
3. **流初始化：**平台事件触发 VIP 购物车放弃恢复流。
4. **员工客服人员激活：**在流运行时，将调用 VIP 购物车恢复代理。
5. **主题执行：**客服人员解析为“恢复 VIP 购物车”主题，并执行说明。
6. **通知创建：**客服人员会提醒 John 在 Slack 的客户经理 Sarah。
7. **任务创建：**客服人员会为 Sarah 创建任务，并向她建议将执行的后续行动。
8. **折扣分析：**客服人员通过调用 Data 360 检索器函数来运行折扣分析，根据购物车价值、客户等级和购买历史请求“允许的最大折扣”。在这种情况下，该函数建议 10% 的折扣优惠。
9. **电子邮件准备和旅程注册：**客服人员准备折扣优惠电子邮件，并使用新的购物车价格将 John 注册到 Marketing Cloud 旅程 VIP 客户购物车恢复。
10. **日志记录和归因：**John 会兑换优惠，这将创建日志属性和转换度量。
11. **反馈分析：**分析结果会进一步确定优惠、恢复时间和其他优化因素。

销售代表 David 正在接见一位新潜在客户的发现电话。智能客服人员会主动实时监控呼叫，通过回答潜在客户的问题为 David 提供即时支持。

**示例：**如果潜在客户询问特定产品规格，客服人员会自动检索相关详细信息，并通过 Slack 或私人消息将其发送给 David。

• **触发器：**在与销售代表 (David) 的发现通话中，潜在客户提出了需要特定产品信息的问题。
• **客服人员操作：**环境客服人员持续分析呼叫记录和消息，智能识别和获取所需信息。
• 进程：
  1. 客服人员会实时解析通话脚本。
  2. 它自动识别关键操作项目并检索相关信息。
  3. 在这种情况下，客服人员直接从 Salesforce 获取产品信息。
  4. 然后，它会自动通过 Slack 或私人消息向 David 显示检索到的信息。

模式

此模式中有一些先决条件需要实时语音到文本的功能，我们假设它们可以通过您的通信提供商获得。例如，以下是集成缩放调用的模式。

**先决条件：**Zoom 调用的实时转录示例：

• 在 Zoom 开发人员平台中创建 Zoom 应用程序，其中包含读取录音、Webhook 发送和会议流所需的范围。启用所需的产品功能，例如实时媒体流 (RTMS)。
• 设置中间信令服务器(Zoom RTMS 示例 ) , 接收音频流，将其转发到 Amazon Transcribe 服务，并获取转录的文本。然后将脚本作为平台事件发布到 Salesforce。

设计时间

1. 设置销售呼叫实时响应客服人员。

   从模板创建客服人员	→	添加协助呼叫主题	→	添加主题说明	→	创建脚本分析操作
   						↓
   		将操作添加到主题	←	创建 Slack 见解操作	←	创建产品规格操作

   1. 从 Agentforce 员工客服人员模板创建客服人员。
   2. 添加新主题“协助呼叫”，并说明该客服人员收听实时脚本，了解意图，并帮助处理产品数据。
   3. 添加主题说明以解析脚本、检索产品规格并发送 Slack 消息。
   4. 创建操作。
      • 分析通话脚本操作：分析实时收到的通话脚本数据，并提取关键问题或操作
      • 获取产品规格操作：查询产品 Knowledge 文章
      • 向“内部”用户发送 Slack 见解
   5. 将操作添加到主题。
2. 设置 Product Knowledge 数据库。

   创建新数据库

   →

   添加 Knowledge 文章

   →

   系统块和索引

   →

   基础库在运行

   1. 从“设置”中创建新数据库。将其命名为 "Product Knowledge"。
   2. 添加包含产品信息的 Knowledge 文章。
   3. 在后台，文档会自动分块、编入索引并准备好使用。
   4. 在获取产品规格操作中使用基础训练。
3. 通过发布/订阅 API 将实时脚本发布到 Salesforce。

   服务器接收音频脚本

   →

   服务器发布平台事件

   1. 使用呼叫 ID、顺序、演讲者、分段开始时间、分段结束时间、持续时间和脚本数据字段创建平台事件 Transcript_Segment__e。
   2. 在信令服务器中(请参阅先决条件部分 ) , 一旦您收到来自音频的转录文本,立即通过 Transcript_Segment__e 事件发布数据。您可以使用以下任何方法将事件发布到 Salesforce：流、Apex、Salesforce API 或发布/订阅 API。
4. 订阅已发布 Transcript_Segment__e 事件的电线流。

   创建事件触发的流	→	订阅脚本事件	→	添加客服人员可调用操作	→	向客服人员发送负载
   						↓
   						客服人员发送 Slack DM

   1. 创建新的平台事件触发的流，即发现呼叫见解。
   2. 选择流应订阅的 Transcript_Segment__e 事件。
   3. 在 Flow Builder 中设置自定义客服人员可调用操作，并选择销售呼叫实时响应客服人员。发送事件负载，以路由到协助呼叫主题。在从主题派生问题后，问题会发送到“获取产品规格”操作进行回答。
   4. 最终答案被编译并通过 Slack DM 立即发送给用户。

客服人员运行时流程流

在设置和部署客服人员后，以下步骤将在运行时发生。

1. **呼叫发起：**David 在缩放呼叫中与潜在客户开始发现呼叫。缩放 RTMS 将实时音频流式传输到信令服务器转录端点。
2. **实时转录：**信令服务器接收音频，将音频转录为文本，并在 Salesforce Platform 中发布转录段平台事件。
3. **客服人员监听和上下文分类：**Salesforce 接收平台事件，并触发 Discovery 呼叫见解流。
4. 该流启动接收细分的销售呼叫实时响应客服人员，识别问题（例如“烤面包机 2XP 是否与移动设备集成？”），并将其分类到“协助呼叫”主题下。
5. **Knowledge 检索：**客服人员触发“获取产品规格”操作，并查询 Knowledge 数据以获取匹配答案。
6. **发送专用 Slack DM：**客服人员执行发送 Slack 见解，发布到 David 的 Slack DM：Product Toaster 2XP 可与 Apple 和 Android 设备集成，并可通过蓝牙连接。安装应用程序后，只需通过蓝牙连接并操作烤面包机。以下是手册的链接。"
7. **实时继续：**客服人员继续接收脚本文本；如果出现多个见解，它会线程上下文 Slack 回复，而不会中断呼叫流。
8. **通话后汇总：**在会话结束时，客服人员会自动编译汇总：关键问题、采取的操作和引用的产品。
9. **持续改进：**Agentforce Analytics 会评估脚本响应延迟、产品匹配准确性和销售结果，以随着时间的推移完善主题说明。

销售经理 Bob 为自主客服人员分配任务，目标是：在未来 60 天内，我们在加州制造行业的销售漏斗将增加 500 万美元 。 "

• **触发器：**经理通过 Slack 中的命令分配目标。
• **客服人员操作：**自主客服人员开始其计划和执行循环。
• 进程：
  1. **研究：**客服人员查询 Salesforce Data 360 和外部数据源（通过 MuleSoft），以识别加州制造行业中不是当前客户的公司。
  2. **确认：**它会分析这些公司，寻找购买信号，例如最近的几轮融资、新的高管招聘或相关的工作帖子。它为前 20 个潜在客户评分并确定优先级。
  3. **识别联系人：**它查找这些公司的关键联系人（例如运营副总裁和工厂经理）。
  4. **外联：**它为每个联系人起草个性化的推广电子邮件，引用特定的公司新闻或痛点。它计划在下周发送这些电子邮件。
  5. **后续行动：**它跟踪电子邮件打开和回复。潜在客户的积极回复会触发对其日历的分析，以建议会议时间，并在确认后自动生成 Salesforce 事件和新业务机会。
  6. **报表：**它向 Slack 中的销售经理提供每周进度报表。

模式

这是一个多客服人员场景，其中每个客服人员执行特定任务，并将上下文、数据和控制权移交给下一个客服人员。我们将使用一些自定义无头客服人员进行研究和资格鉴定，并使用现成的销售开发代表 (SDR) 客服人员进行潜在客户拓展和监控。我们还会假设 Bob 的公司使用 ZoomInfo 进行市场调查。该公司还接收保存在数据库中的供应商网络数据，其中包含有关与其合作的公司的宝贵信息。

设计时间

1. 设置多客服人员架构。

   研究客服人员收集情报

   →

   资格客服人员得分潜在客户

   →

   SDR 客服人员开始外联

   1. 研究客服人员：通过 MuleSoft 查询 Data 360 和外部源
   2. 资格客服人员：确定潜在客户的优先级、评分和丰富潜在客户
   3. SDR 客服人员：获取潜在客户分配、执行拓展、跟进和安排会议。使用 Agentforce Analytics for SDR 客服人员监控 SDR 客服人员的活动和进度。
2. 发现并接收新的公司数据。

   创建新数据空间

   →

   引入 Salesforce CRM 数据

   →

   摄取 ZoomInfo 数据

   →

   引入供应商数据库数据

   1. 设置名为销售和市场营销的新数据空间。此新数据空间将保存自治客服人员所需的所有数据。
   2. 使用 Salesforce 连接器将潜在客户、客户、联系人和业务机会 CRM 数据流到数据空间。
   3. 为 ZoomInfo 配置 Data 360 连接器。将数据流入 Data 360 销售和市场营销数据空间。
   4. 配置 Anypoint Salesforce Data 360 连接器，以连接到供应商数据库，并将数据引入 Data 360。
3. 设置平台事件，以启动无头研究和资格客服人员。

   创建新平台事件

   1. 使用捕获人类用户高级目标的字段目标，创建新的 AgentGoal__e 平台事件。
4. 设置目标管理器客服人员，即接收用户目标并将其编排给其他客服人员的对话式 AI 客服人员。

   从模板创建客服人员	→	添加解析目标主题	→	添加主题说明	→	创建目标事件操作
   						↓
   						将操作添加到主题

   1. 从 Agentforce 员工客服人员模板创建客服人员。
   2. 添加新主题“解析目标”，并说明此客服人员了解目标意图，并可以根据需要呼叫其他客服人员。
      • 添加主题说明，以将目标解析为其他客服人员并触发事件。
   3. 创建目标事件 AgentGoal__e。
5. 设置潜在客户研究和资格客服人员，由编排客服人员触发。

   创建研究主题	→	创建重复数据消除操作	→	创建潜在客户丰富操作	→	创建潜在客户评分操作
   						↓
   				将操作添加到主题	←	创建潜在客户资格认证操作

   1. 使用描述“研究区域或州的新潜在客户”创建潜在客户研究主题。
   2. 创建操作。
      • 重复的潜在客户 Apex 操作：根据现有客户检查和验证新潜在客户
      • 丰富潜在客户 Apex 操作，该操作使用提示模板：查看非结构化营销见解和供应商数据库数据，以丰富潜在客户数据
      • 得分潜在客户操作：使用更新的潜在客户数据主动对潜在客户进行评分
      • 符合客服人员潜在客户资格操作：根据评分，分配符合 SDR 客服人员潜在客户资格的参数
6. 设置 Agentforce SDR 客服人员，以执行拓展、潜在客户培养和会议计划。

   从模板创建 SDR 客服人员	→	配置客服人员Knowledge库	→	配置客服人员电子邮件设置	→	设置潜在客户分配规则
   						↓
   						定义合格的潜在客户条件

   1. 使用预配置的潜在客户培养代理模板，从“设置”页面创建新的 SDR 客服人员。配置电子邮件设置和潜在客户分配规则，选择潜在客户对象或联系人对象，并定义分配规则的资格条件（潜在客户得分阈值和新潜在客户）。
   2. 通过配置客服人员、分配权限以及设置节奏和分配规则来设置 Agentforce 潜在客户培养。
   3. 为特别提款权代理人回答问题配置必要 Knowledge。
7. 设置新流，订阅已发布的 AgentGoal__e 事件。

   创建事件触发的流

   →

   订阅客服人员目标事件

   →

   添加客服人员可调用操作

   1. 创建新的平台事件触发的流，称为将目标路由到客服人员。
   2. 选择流应订阅的客服人员目标事件。
   3. 在 Flow Builder 中设置自定义客服人员可调用操作，并选择潜在客户研究和资格客服人员。

客服人员运行时流程流

在设置和部署客服人员后，以下步骤将在运行时发生。

• **目标分配：**Bob 要求自主客服人员“在 60 天内将加州制造业的漏斗增加 500 万美元”。
• **目标编排：**自主目标 Orchestrator 客服人员接收目标，解析意图，并创建平台事件 AgentGoal__e。目标 Orchestrator 客服人员旨在不断扩展其处理多个目标的能力。您可以扩展它来添加额外的编排功能，或者要求用户澄清，以便更好地理解意图并启动目标。
• **路由：**触发流路由目标到客服人员，并调用潜在客户研究和资格客服人员。
• **研究：**潜在客户研究和资格客服人员查询 Data 360 以获取新的潜在客户信息，对现有客户进行重复数据消除，从 Data 360 中提取额外的市场研究数据，并丰富潜在客户。它进一步对潜在客户进行评分，确定关键联系人，并对潜在客户进行资格鉴定。
• **外联：**一旦潜在客户合格，该潜在客户就有资格通过潜在客户分配规则获得 SDR 客服人员的资格。SDR 客服人员进行最初的拓展，并通过回答与产品相关的问题来保持与联系人的对话。
• **后续行动：**在节奏结束时或应潜在客户的请求，如果潜在客户符合服务代表参与的条件，客服人员会提示您会议日程安排。然后，它安排会议并退出流。
• Agent Analytics：SDR Agent Analytics 仪表板提供了有关客服人员工作效率的见解。

一位长期客户遇到一个多层面的问题：他们开过高的发票，他们收到的更换零件不正确，他们的服务现在断开。

• **触发器：**客户发起聊天，初始对话客服人员快速识别复杂性，并升级为客服人员群。
• **客服人员操作：**编配员客服人员负责。
• 进程：
  1. **组织者：**保持与客户的对话，提供更新
  2. **主管代表：**使用 A2A 协议实施， Orchestrator 发现具有所需功能的“相关客服人员”（开单、物流和配置），并派遣任务。
     • 至开单客服人员："调查客户 X 的发票 #INV-7890。是否存在差异?"
     • 至物流客服人员："检查客户 X 的跟踪编号 #TN-12345。请确认已发货零件编号和当前库存是否正确。"
     • 要配置客服人员："检查客户 #ACC-5678 的服务状态。如果断开连接，原因代码是什么？”
  3. **专业客服人员执行：**每个客服人员收到 A2A 请求，查询各自的系统，并制定响应。
  4. **合成：**客服人员通过 A2A 响应向 Orchestrator 报告他们的发现。Orchestrator 会综合信息："客户确实多付了 50 美元。由于仓库错误，运送了错误的零件。由于计费问题，服务自动断开连接。"
  5. **鸣谢：**指导员会向客户通报问题，并主动将问题上报到人工服务代表，并提供后续步骤的明确指导。
  6. **解决方法：**然后，它向服务代表提出完整的解决方案以供批准。服务代表加入对话。服务代表快速查看与问题相关的所有数据，包括客服人员推荐的解决方案："通过快速运输，为正确零件创建新的运输订单。为错误零件发起退货。批准新订单的 10% 折扣，并使用最新改进版本追加销售零件。更新付款信息，并提议设置重复计费安排 。 "

模式

此模式概述了协作客服人员系统的实施，旨在解决涉及多个方面的复杂客户服务问题。通过使用编配员客服人员通过 A2A 协议将任务委派给专业客服人员（开单、物流和配置），然后综合他们的发现，系统提供了全面的解决方案，并无缝集成服务代表进行最终批准和客户交互。

设计时间

1. 将增强聊天设置为客户的聊天入口点，以便他们可以在网页中打开 Agentforce 窗口。
2. 设置 Agentforce 开单客服人员，这是一个无头的专门客服人员，可以接受订单或发票并执行开单查询。

   从模板创建客服人员

   →

   定义开单查询主题

   →

   创建自定义流操作

   →

   将操作添加到主题

   1. 启用 Agentforce 并从 Agentforce 员工代理模板创建员工代理。
   2. 定义主题“开单查询”，描述“调查发票差异、付款问题和开单错误”。
      1. 添加自定义流操作“检查发票差异”，输入发票编号、客户 ID 和日期范围，输出差异金额、根本原因和受影响交易。
3. 设置 Agentforce 物流客服人员，这是一个无头的专门客服人员，可以验证发货、跟踪发货和检查库存。

   从模板创建客服人员

   →

   定义发货验证主题

   →

   创建自定义流操作

   →

   将操作添加到主题

   1. 启用 Agentforce 并从 Agentforce 员工代理模板创建员工代理。
   2. 定义主题：发货验证，以及用于验证发票发货的描述。
      1. 添加自定义流操作“验证发货详细信息”，输入发票编号、客户 ID 和日期范围，输出发货零件、日期和库存状态。
4. 设置 Agentforce Provisioning Agent，即可以验证配置和服务状态的无头专用客服人员。

   从模板创建客服人员

   →

   定义服务检查主题

   →

   创建自定义流操作

   →

   将操作添加到主题

   1. 启用 Agentforce 并从 Agentforce 员工代理模板创建员工代理。
   2. 定义主题“服务检查”，其中包含用于验证服务连接和客户状态的描述。
      1. 添加自定义流操作“验证服务”，输入客户 ID 和资产 ID，输出服务状态和服务异常原因。
5. 将开单、物流和配置客服人员公开为 A2A 服务器，并在客服人员注册表中注册。

   通过 MuleSoft 公开客服人员

   →

   在注册表中注册客服人员

   1. 在 Agentforce 客服人员没有直接 A2A 支持的情况下，MuleSoft 连接器可用于将客服人员 API 显示为 A2A 服务器。
   2. 在客服人员注册表中注册这些 A2A 服务器。
   3. 使用 Anypoint 客服人员结构编排客服人员。
      1. MuleSoft 客服人员代理人可以根据客服人员卡中提到的客服人员功能，帮助跨平台编排任何客服人员。
6. 设置 Agentforce 帮助客服人员，即与客户互动、评估复杂性并与多个专业客服人员协调解决问题的对话式 AI 客服人员。

   创建服务代理	→	定义调查主题	→	创建通知操作	→	定义编排主题
   						↓
   定义升级主题	←	创建创建个案操作	←	创建呼叫客服人员操作	←	创建客服人员编排流
   ↓
   创建全方位流	→	连接用于升级的流

   1. 启用 Agentforce 并在 Agentforce 生成器中创建服务代理，以处理对话和触发自定义操作。
   2. 使用描述和说明定义主题服务调查，以便客服人员自然地识别通常有多个同时存在的复杂主题。
      1. 创建自定义客服人员操作。
         • 状态通知操作，以确认问题并提供进度更新
   3. 定义可以通过操作调用其他客服人员的编排主题。
      1. 创建调用流操作的呼叫客服人员操作。流操作有几个客服人员操作，可以启动每个无头客服人员：开单客服人员、物流客服人员和配置客服人员。
      2. 创建创建个案操作，以创建个案、添加详细信息并设置状态。
   4. 定义升级主题，其中包含要升级为服务代表的描述。
   5. 创建并激活出站全方位流。
      • 通过升级消息将其添加到客服人员的“连接”选项卡进行升级。

客服人员编排流程流

Anypoint 代码生成器现在支持构建客服人员经纪人。客服人员代理是一个智能路由和编排层，跨域连接客服人员，并让最合适的客服人员和工具参与进来。MuleSoft 开发人员生成代码，以为经纪人奠定基础。

根据客服人员卡（A2A 服务器）中提到的客服人员功能（此前已在客服人员注册表中注册），进一步配置将由 Anypoint 代码生成器自动完成。最后，我们可以将此客服人员代理部署到云。

一旦客服人员经纪人可以使用，这些请求将被路由到适当的客服人员。经纪人收到提示，并使用 LLM 将其分解为任务，并确定首先致电哪个客服人员。在每个迭代循环中，它确定自己是否成功处理了原始提示，或者是否需要与其他客服人员合作来完成作业。

客服人员运行时流程流

在设置和部署客服人员后，以下步骤将在运行时发生。

1. **聊天启动：**客户打开 Agentforce 聊天（嵌入服务）。客户登录后，会话和联系人上下文加载。
2. **问候和意图：**客服人员问候客户。客户明显感到沮丧，他们会通知多收的费用、错误的零件和服务断开。
3. **CRM 查找：**客服人员触发“获取最新订单”操作，并查询 Salesforce（订单汇总/订单）以获取客户的最新记录。然后，客服人员根据上下文确认订单，并通知客户将进行调查。它还会进一步查找发票 ID、与发票关联的跟踪编号以及与服务关联的资产 ID。
4. **组织者激活：**编配员客服人员接收升级和订单 ID，然后创建个案。它将上下文数据传递给三个客服人员并与之通信：开单客服人员、物流客服人员和配置客服人员。
5. **开单客服人员响应：**开单客服人员返回零件、单位成本和总成本的详细信息。它还注意到订单中的零件和发票中的零件之间的差异。开单客服人员会查找订单中零件的价格以及多收的原因。
6. **物流客服人员响应：**物流客服人员返回时会显示已发货零件的详细信息，以及物流系统创建的异常通知，其中指出由于标签问题，发送了错误的零件。物流客服人员也会验证问题是否已修复，并且正确的零件在原始版本和较新版本中可用。
7. **配置客服人员响应：**配置代理返回有关服务断开连接和过期付款信息问题的详细信息。它还提供发送的通知，以建议客户更新付款信息。
8. **编配器合成：**编配员客服人员综合来自所有这些客服人员的回复，并通过查看每个问题的 Knowledge 文章来撰写解决方案。首先，它查找错误部分的信息并发起退货。其次，它根据解决策略文档为问题提供折扣，并建议升级到客户可以购买的新版本（但存在价格差异）。第三，它需要来自客户的新付款信息，所以它会升级到服务存储库来传达解决方案。
9. **升级：**编配员客服人员升级为服务代表，提供所有必要的上下文、调查备注和解决方案建议，以及必要的批准，并将服务代表纳入通话。
10. **循环中的人员：**服务代表感谢客户的耐心，对造成的麻烦表示歉意，并解释问题。然后，服务代表为零件提供 10% 的折扣作为补偿，并通知客户新的升级零件及其好处。最后，他们解释了断开连接的情况，获得了新的付款信息，并更新了系统。
11. **主动恢复：**AI 客服人员观看对话，并主动采取行动恢复服务、订购升级的零件，并使用折扣和调整后的价格创建新发票。
12. **个案结束：**最后，它编译汇总，更新个案，并关闭个案。

要使客服人员有效，必须能够与广泛的企业数据和工具集集成。这提供了客服人员执行配置目标所需的基本上下文。Agentforce 框架提供了一个复杂的集成架构，整合了 Salesforce 内部和 Salesforce 外部的数据。

本节探索将客服人员连接到这些资源的模式。这些模式基于两种基本的集成方法。

• **内部集成（数据访问和工具访问）：**对于 Salesforce 生态系统中的资源，客服人员有两种操作方式。
  • 数据访问：Agentforce 核心运行时与 Data 360 深度集成，使其能够直接查询内部数据服务。它可以针对数据图形本地制定和执行查询以获得客户的全方位视图,通过RAG执行语义搜索以了解非结构化的 Knowledge,并使用Data 360 查询 API访问批量信息此直接路径针对数据检索的速度和灵活性进行了优化。
  • 工具访问权限：当任务涉及复杂的业务逻辑或多步骤流程时，或者当它需要严格的治理时，它的功能被封装在操作中。通过 Apex 或 Flow 构建，这些操作为客服人员提供了一个安全和可重用的界面，以便执行更多操作，而不仅仅是读取数据，它们还允许客服人员更新记录、触发平台事件或执行任何既定的业务流程。
• **外部集成 (MCP/A2A)：当客服人员需要 Salesforce 外部的信息时(例如来自外部应用程序、微服务或其他客服人员 ) , 它会使用模型上下文协议 (MCP ) 。**该开放标准为互操作性提供了通用语言。MCP 服务器可以从 AgentExchange 添加，管理员也可以将客服人员注册表或 Apex 标注添加到 MCP 服务器。然后，该操作向外部 MCP 服务器发起请求，以结构化的方式桥接内部和外部世界。同样，当客服人员需要与其他客服人员通信时，Agent2Agent (A2A) 协议会促进这种交互。这允许创建复杂的多客服人员系统，其中专门的客服人员可以协作解决复杂的问题，促进模块化和可重用性。

以下模式围绕客服人员需要的特定数据集成主题进行组织。我们将展示如何应用这些模式来解决不同的数据挑战，从使用 MCP 连接到外部应用程序，到使用 Data 360 中的直接访问和正式操作的强大组合访问 Data 360 中的大量批量数据、实时事务记录和非结构化内容。

问题

客服人员的效率取决于其操作外部工具的能力。然而，这些工具（从传统 ERP 到现代 SaaS 应用程序）缺少共享语言。每个都有唯一的 API、身份验证模型和数据格式。这迫使开发人员进入一个脆弱和不可扩展的周期，为客服人员需要使用的每个新工具构建和维护自定义的点对点集成。

上下文

考虑负责解决损坏货运个案的客服人员。要取得成功,它必须与三个不同的外部系统进行交互:需要查询供应商的 API 来检查替代库存、调用物流合作伙伴来安排新的交付以及访问财务系统来处理信用。如果没有通用协议，客服人员将需要三个单独的定制集成，每个集成都是潜在的故障点。MCP 提供了标准化的通信层，使这些交互无缝可靠。

以下是如何集成通过 MCP 向客服人员公开的外部服务的模式。

**模式 1：****使用 MCP 启用外部工具**

问题

组织运行在传统 ERP 和现代 SaaS 的混合之上，但是将它们与客服人员集成很困难，因为没有通用的协议 — 每个工具都有自己的 API、身份验证和数据模型。开发人员最终会为每个工具构建和维护自定义点对点连接器，从而产生脆弱、不可扩展且成本高昂的集成。

模式

客服人员通过结构化操作调用外部工具（通过 MCP 公开），允许其在 Salesforce 平台之外使用专用工具。

上下文

• 客服人员充当 Salesforce 平台外部存在的一组工具的代理。
• 这些外部工具可能具有不同的 API、身份验证机制和数据格式。
• 需要标准化的通信协议来实现客服人员和这些外部工具之间的无缝交互。
• 可重用性是一个关键问题，因为相同的外部工具可能被多个客服人员用于不同的目的。

交互

1. **触发器：**Agentforce 中的用户请求或内部事件需要使用外部工具。
2. **行动意图：**Agentforce 客服人员识别意图，并确定需要基于 MCP 的外部工具。
3. **计划员（内部）：**Agentforce 客服人员的计划员根据其配置的说明和可用工具选择合适的 MCP 工具或操作。
4. **执行：**Agentforce 客服人员向外部 MCP 服务器发送符合 MCP 的请求（例如，通过到 MuleSoft 端点的 Apex 标注，然后路由到外部 MCP 服务器）。
5. **外部处理：**外部 MCP 服务器处理请求，与基础外部应用程序交互，并准备符合 MCP 的响应。
6. 结果:外部 MCP 服务器将响应返回到 Agentforce Agent。
7. **后续行动：**Agentforce 客服人员处理响应、更新内部状态、继续执行任务或为用户提供反馈。

权衡

客服人员的决策逻辑与其基础数据一样可靠。客服人员要明智行事，必须对周围的世界有丰富的实时了解。如果没有定义的数据接收架构，客服人员无法访问或处理对其运行至关重要的高用量实时信息。

与客服人员集成交易数据

问题

客服人员经常需要对驻留在记录系统中的单个记录执行低延迟读/写操作（例如，更新个案或获取订单状态）。这些操作需要数据的完整性和可靠性，以确保基础数据模型的一致性。核心架构挑战是为这种事务性数据访问提供安全、实时和可扩展的模式，而不会创建脆弱的点对点集成。

上下文

要将客服人员成功连接到这些记录，需要一个功能强大的架构，其中包含几个核心组件。

• **交易系统：**这些是数据的权威来源，例如记录系统，例如 Salesforce、Workday 或 **SAP，**或者托管在平台上的服务，例如 AWS。
• 集成层：通常由MuleSoft处理的强大集成层对于安全地连接到这些不同的系统、转换数据并将其公开给 Agentforce 平台至关重要。
• **MCP 服务器：**为了确保互操作性，客服人员使用 MCP 标准与这些外部系统进行通信。集成层可以连接到托管外部服务或客服人员的各种 MuleSoft、Heroku 或第三方 MCP 服务器。
• **客服人员交换：**此组件充当目录或总机，允许 Salesforce 客服人员发现并安全地连接到正确的外部服务或客服人员，以完成任务。

模式 1：通过 MCP 直接记录操作

模式

客服人员使用 MCP 连接到事务性数据系统，并对具有即时一致性要求的特定已识别记录执行有状态的 CRUD 操作。

上下文

• 对话式协作客服人员必须在工作流中处理记录系统数据。
• 记录系统是外部系统。
• 事务需要幂等。

关键组件

• **Agentforce 客服人员：**包含进行事务性更新的主题和说明。操作调用外部 MCP 服务器或 Agentforce Exchange 注册的 MCP 服务器。
• **MCP 服务器：**公开事务数据和函数的 MCP 服务器（例如，包含输入数据的 tool=billing.update_record）
• **外部记录系统：**发生状态更改的系统

交互

1. **触发器：**发生需要记录上事务的命令或事件。
2. **行动意图：**Agentforce 客服人员识别状态更改意图。
3. **计划员（内部）：**计划员选择 MCP 工具。
4. **执行：**该工具将在策略、记录和字段级访问权限检查通过后执行。
5. **结果：**MCP 服务器返回响应
6. **后续行动：**Agentforce 客服人员处理响应。

权衡

模式 2：通过 Mulesoft API 进行复杂编排

模式

客服人员利用 Mulesoft API 进行复杂的多步骤跨系统原子事务。这将提供单一受管端点，确保可靠的端到端处理，并避免与直接调用单个系统相关的一致性、可靠性、延迟和数据问题。

上下文

• 对话和自主客服人员通常需要可靠地执行一些操作。
• 事务中有多个事务系统和操作。
• 工作流需要事务/回滚、重试和策略实施。
• 事务需求是实时、幂等、可观察和合规的。

交互

1. **触发器：**发生命令或事件，需要完成复杂的事务。
2. **行动意图：**Agentforce 客服人员识别意图。
3. **计划员（内部）：**计划员选择 API 或 API 操作的可调用操作。
4. **执行：**执行 API 并返回响应。
5. **后续行动：**Agentforce 客服人员处理响应。

权衡

将分析数据与客服人员集成

问题

组织已在分析基础设施（数据仓库和湖泊、实时分析系统和业务智能平台）方面投入巨资，但 AI 客服人员仍与这些系统脱节。这造成了客服人员获取丰富上下文的能力差距（例如，客户在上一季度退还了三次零件），以帮助做出更好的决策（在本例中是升级）。

上下文

客服人员的运营智能源自其从根本不同的数据格式和来源综合信息的能力。因此，这种架构模式不是为单个用例设计的，而是作为基础数据接收框架设计的。有效的客服人员必须有能力处理结构化源，以执行逻辑的、数据驱动的分析；客服人员需要访问高用量的、结构化的摘要。这包括与企业数据湖集成(通过与 Data 360 的零复制集成 ) 、 处理中间件转换的数据流或接收批处理文件，例如 CSV。

模式 1：通过 Data 360 零复制集成的数据湖

问题

在使用传统数据漏斗复制、管理和转换存储在数据湖（例如 Snowflake）中的分析数据时，组织面临着高昂的成本。从历史上看，Analytics 基本上处于离线状态，导致错失及时采取行动的机会。

模式

客服人员查询 Data 360 中可用的零复制数据（和计算见解），而不是查询外部数据仓库以获取关键见解。这有助于客服人员将事务和分析数据作为基础，从而做出更好的决策。

上下文

• 贵组织将客户和运营数据存储在数据仓库和湖中。
• 客服人员需要访问聚合度量、历史趋势和分析见解。
• 客服人员的上下文需要事务和分析数据（考虑研究客服人员对历史趋势数据的需求）。

交互

1. **触发器：**客服人员会收到有关见解的查询，需要访问分析数据或计算见解。
2. **执行：**客服人员执行通过查询 API 调用 Data 360 计算见解的操作，并返回计算见解。
3. **后续行动：**Agentforce 客服人员处理响应。

权衡

模式 2：从数据流触发操作

问题

组织不断从业务活动中生成有价值的信息，例如网站访问、通话、会议、聊天和传感器数据。但是，当这些交互变得可用或从数据仓库检索时，关键见解就失去了，及时干预的机会已经过去。因此，组织错过了实时所需的大部分可操作智能，而这些智能通常埋藏在这些短暂的流中。这将导致差距、错过辅导机会，以及在没有完整上下文的情况下做出决策。

模式

客服人员通过数据操作从 Data 360 中的流见解或实时见解接收实时或近实时见解，或者客服人员通过查询与实时处理引擎（例如 Apache Flink）接口的 MCP 服务器来实时访问流见解。

上下文

• 平台事件、发布/订阅 API 和 RTEM 等流系统会生成大量流数据。
• Data 360 和 Apache Flink 等流处理系统会在这些单个事件到达时处理它们。
• Agentforce 需要查询流系统（例如，具有其他上下文的实时会议的最近 30 秒脚本）或由数据操作触发（例如，欺诈检测）。
• 需要近乎实时、低延迟的操作。

交互

1. **流发射：**源系统会发出连续的数据流。
2. **流处理：**Data 360 或 Apache Flink 等流处理引擎处理信息。
3. **转换：**在中间件（用于复杂转换）或 Data 360 中，见解被聚合、转换并合成为客服人员感知的数据。
4. **流见解事件：**对于合成的数据（例如，30 秒音频流的脚本），触发 Data 360 数据操作。
5. **丰富：**客服人员添加上下文并检测意图。
6. **执行：**客服人员执行操作。
7. **后续行动：**客服人员等待下一个流见解。

权衡

将语义数据与客服人员集成

组织具有不同格式和形状的业务工件 — 目录、手册、策略、Knowledge 图、关系图。要超越简单的任务执行并参与复杂的推理，客服人员必须能够理解存储大部分人类 Knowledge 的这些数据。

模式 1：RAG：为客服人员释放非结构化数据的强大功能

问题

组织经常拥有无法搜索的信息，这阻碍了客服人员自信地访问这些信息。这种缺陷通常导致客服人员的回复不完整，缺乏建立 Trust 所需的上下文深度和可验证的引用。因此，显然需要一种标准化的方法，使客服人员能够一致地检索语义相关和准确的内容。

模式

此模式提供了架构，使客服人员能够接收和解释各种非结构化信息，从内部文档到公共 Web 内容。让客服人员访问这些数据是释放高级功能的关键，例如市场情绪分析、文档汇总和竞争对手研究。

上下文

• Knowledge 以不同的格式和形状存在于文件中。
• 冗余内容在这些文档中普遍存在。
• 客服人员需要可以引用的准确信息。
• Knowledge 会频繁更改，因此需要刷新和重新索引文件。

交互

客服人员无法按原样接收或使用内容。内容需要分块、嵌入、存储在矢量数据库中，并在客服人员检索和使用之前编入索引。

摄取和准备

1. **爬网和摄取源：**源可以通过两种方式识别：手动，例如上传 PDF 文件，或者通过它们的位置，例如 AWS S3。
2. **跺脚：**接收的内容被分解成更小的、可管理的块，以促进高效的处理和检索。这是 RAG 的关键步骤，因为它确保只检索最相关的信息，而不是整个文档。
3. **嵌入：**然后，每个块会使用专用语言模型转换为称为嵌入的数字表示。这些嵌入捕获文本的语义含义，允许基于相似性的搜索。
4. **矢量存储：**嵌入存储在 Data 360 向量存储中，这是一个针对高性能相似性搜索优化的专用数据库。这允许客服人员快速查找相关内容。
5. **索引：**内容及其嵌入在矢量存储中编入索引，使其易于搜索检索。

Data 360 检索器函数

• **检索内容：**该函数将查询作为输入，并对 Data 360 向量存储执行语义搜索，以查找最相关的内容块。
• **筛选内容：**该函数允许根据元数据（例如文档类型、作者或日期）筛选检索到的内容，以进一步优化结果。
• **排名内容：**该函数根据相似性得分（向量搜索）、关键字得分或两者的组合（混合搜索）对检索到的内容块进行排名。

检索并生成

• **查询：**当客服人员需要信息时，它会制定也嵌入到向量中的查询。
• **语义搜索：**客服人员针对 Data 360 向量存储执行语义搜索，将查询的嵌入与存储的内容块的嵌入进行比较。这将根据向量分数或混合分数（向量和关键字组合）检索语义最相关的块。
• **检索扩充生成 (RAG)：**然后，检索到的内容块作为上下文与原始查询一起提供给 Agentforce 客服人员。LLM 使用此上下文生成精确、准确和可引用的答案。
• **回复和引用：**客服人员显示生成的答案，通常带有对原始源文件或 Web 链接的引用，以建立 Trust 并允许验证。

权衡

模式 2：数据图形：为客服人员预先构建的结构化图表数据

问题

组织经常拥有孤立的关系数据，这阻碍了客服人员检索它的能力。此问题通常导致客服人员提供的回复不完整，缺乏足够的上下文详细信息来建立 Trust，以了解不同实体是如何连接的，或者在客服人员必须从多个数据库中检索信息时造成延迟。

模式

此模式提供了架构，使客服人员能够接收和解释各种结构化和半结构化关系信息，从内部 CRM 数据到外部 Knowledge 图表。让客服人员访问这些数据是释放高级功能的关键，例如 Customer 360 视图、复杂的依赖性分析和动态上下文构建。

上下文

1. 关系数据分散在各种系统和格式中。
2. 客服人员需要了解实体之间的联系（例如，客户、个案、订单和相关产品）。
3. Knowledge 图表和连接的数据模型对于理解复杂的关系至关重要。
4. 客服人员需要有关可引用实体关系的准确信息。

交互

在客服人员可以有效查询和使用关系数据之前，需要用图表结构对其进行协调和表示。

摄取和准备

1. **牧场摄取源：**数据源（例如，CRM 系统、ERP、外部 API 和 CSV）被识别并接收到 Data 360 中。
2. **数据协调:**原始数据映射到 Data 360 中的数据模型对象 (DMO)，标准化其结构并创建统一视图。
3. **身份解析：**合并重复的客户简档并链接相关记录，以创建每个客户的单一、准确视图。
4. **数据图创建：**DMO 被连接以形成数据图，表示不同实体之间的关系（例如，客户 DMO 连接到个案 DMO，个案 DMO 连接到产品 DMO）。此图允许高效遍历关系。
5. **计算见解：**聚合度量和派生属性（例如，客户的总购买历史）被计算并添加到数据图形中，以获得更丰富的上下文。

检索并生成

1. **查询：**当客服人员需要涉及实体之间关系的信息时，它会针对数据图制定查询（例如，“此客户的所有未结个案是什么，哪些产品与其相关联？”）。
2. **图形遍历和查询 API：**客服人员使用 Data 360 查询 API 遍历数据图，并检索基于查询的连接的记录、计算见解和相关属性。
3. **上下文生成：**然后，检索到的关系感知数据作为上下文与原始查询一起提供给 Agentforce 客服人员。LLM 使用此丰富的上下文生成精确、准确和可引用的答案，反映数据的相互关联性。
4. **回复和引用：**客服人员显示生成的答案，通常引用作为响应依据的数据图形中的特定记录或关系，以建立 Trust 并允许验证。

权衡

该企业站在由 AI 客服人员领导的自动化和智能化新时代的边缘。从处理简单的客户查询到自主执行复杂的业务策略，客服人员承诺重新定义生产力和客户参与度。Salesforce Agentforce 平台为此转换提供了重要、可信的基础。Agentforce 通过强大的声明性和专业代码工具套件、统一的数据平台以及通过 A2A 和 MCP 对开放标准的承诺,为构建每种类型的客服人员提供了全面、可信的基础。这种架构允许组织部署智能的、面向目标的客服人员，他们充当连接的合作伙伴，而不是孤立的，以推动可衡量的业务成功。

Salesforce 提供了一套由 Agentforce 平台统一的强大集成工具，作为构建复杂客服人员的基础。本文档中的模式和示例假定您熟悉 Agentforce 平台的功能以及客服人员如何交互。本节提供了您需要了解的关键组件的复习，以充分利用本文档中的模式和模式。

本节概述了架构师和开发人员在 Agentforce 上构建客服人员所必需的基础平台功能。

• **Salesforce 流：**定义客服人员逻辑的主要工具。其声明性可视界面非常适合编排客服人员将采取的步骤。
• **Apex:**为复杂的自定义逻辑、自治客服人员的状态管理和复杂的集成提供支持
• **平台事件：**主动协作客服人员的神经系统，充当 A2A 协议的传输层。
• **数据 360：**客服人员的统一长期记忆。它提供了智能操作所需的上下文，并且是检索扩充生成 (RAG) 的基础。
• **MuleSoft：**客服人员与外部世界的桥梁，通过 MCP 实现系统集成和跨平台客服人员通信。
• **Slack：**人与客服人员交互的主要表面，包括任务分配、通知和批准
• **Agentforce 聊天客户端：**面向客户的对话客服人员的可自定义、可嵌入前端

要使客服人员真正有效，他们不能存在于孤岛中。Agentforce 包含两个核心互操作性模式：

• Agent2Agent (A2A) 通信：该协议控制 Salesforce 生态系统中的客服人员如何相互通信。Agentforce 平台既是 A2A 客户端又是服务器 分别发出和监听请求 这对于协作客服人员群至关重要客服人员可以配置相关客服人员，以发现并调用具有特定技能的其他客服人员，从而创建动态和可扩展的系统。平台事件充当这些 A2A 消息的持久异步传输机制。

• **模型上下文协议 (MCP)：**此标准确保客服人员不会锁定在一个平台中。MCP 定义了通用的消息格式，允许构建在不同框架上的客服人员进行通信。在该模型中,Agentforce充当 MCP 客户端例如，Salesforce 客服人员可以通过向专门从事复杂物流计算的外部客服人员发送符合 MCP 的请求来查询它。MuleSoft 充当网关，将内部 A2A 请求转换为外部 MCP 格式的 API 调用，确保整个企业的无缝互操作性。