### 1.2 主动客服人员
**定义：**与等待提示的对话客服人员不同，主动客服人员充当了保持警惕的观察者。它们由系统中的特定事件、数据更改或预定义条件触发。在触发时，他们执行任务或启动工作流，而无需用户直接交互。
**重要性：**主动客服人员将系统从被动的数据存储库转变为业务流程的积极参与者。它们识别新出现的业务机会和风险，使企业能够实时根据关键信号采取行动。
### 1.3 环境客服人员
**定义：**环境客服人员是一种特定类型的主动客服人员，可在用户工作流的后台连续运行，无需明确命令。用户通常受益于他们的行动，而没有意识地意识到他们的操作，因为他们的目的是在保持低调的同时增强人的能力。
**重要性：**环境客服人员的目标是通过将世俗的“工作”自动化来减少用户的认知负担。它们通过无缝集成到员工每天使用的工具中，自动捕获和构建信息，提高了流程的效率。
### 1.4 自主客服人员
**定义：**自治客服人员在复杂性方面有了重大飞跃。他们有一个高级目标，能够独立地规划和执行一系列步骤来实现这一目标。他们可以推理、决策，甚至从他们的行动中学习，随着时间的推移提高绩效。
**重要性：**这是我们最接近真正的数字员工的地方。自主客服人员可以被授予复杂的多步骤目标，例如“本季度在制造行业生成 50 个新的合格潜在客户”，并受信于制定和执行实现这一目标的计划。
### 1.5 协作客服人员（客服人员群）
**定义：**协作客服人员，通常称为“客服人员群”，是一组专门客服人员，他们一起工作，以解决任何单个客服人员都无法处理的复杂问题。“指挥员”或“主”客服人员通常分解一个大任务，将子任务委派给适当的专业客服人员，然后综合他们的输出。强大的 Agent2Agent (A2A) 通信协议实现了这一点。
**重要性：**这种方法反映了人类团队。通过分解复杂的问题，每个专业客服人员都可以发挥其独特的技能：一个专门从事数据分析，另一个专门从事客户沟通，第三个专门从事系统集成，从而获得更加强大和全面的解决方案。
## 第 2 章：Agentforce 架构模式
在探索了 AI 客服人员的分类后，一个关键问题仍然存在：我们如何组合这些元素来高效可靠地解决现实世界的业务问题？本章通过提供常见代理设计模式的存储库来回答这个问题。每个模式都是应对重复性挑战的经过验证的解决方案，为从简单的单一用途客服人员到复杂的协作客服人员群的所有内容提供了蓝图。
### 2.1 对话客服人员模式
对话客服人员通常是组织 AI 功能的大门。它们由它们参与有状态的、多轮的对话的能力来定义，充当用户使用自然语言执行任务和检索信息的主要界面。本节介绍了构建对话客服人员的两个基本模式，每个模式都针对特定渠道定制：一个用于消息传递客户端的快速交互式交换，另一个用于电子邮件的结构化异步性质。
对话客服人员的智能来自其在正确时间访问正确数据并进行推理的能力。这种模式依赖于复杂的数据基础，该基础连接到客户记录、Knowledge 文章和业务分析。[第 4 章提供了这些集成的完整、可重用的模式：集成模式](#第-4-章客服人员的集成模式)。
#### 2.1.a 对话客服人员：交互式消息传递客户端模式
**问题**
客户通过多个数字渠道参与，并期望获得**即时、上下文**和智能响应传统聊天机器人要么是**脚本**聊天,要么是**数据盲聊天,**这导致个性化程度低、早期升级到人工聊天,以及服务成本高。
**上下文**
- 贵组织拥有多渠道数字参与（WhatsApp、SMS、Slack 和 Salesforce Experience Cloud）。
- 贵组织的客户以[多种语言](https://help.salesforce.com/s/articleView?id=ai.service_agent_considerations.htm&type=5)与贵组织互动。
- 贵组织需要通过客服人员增强服务和销售工作流，以便：
- 从实时、可信的客户数据中提取
- 遵守护栏和合规要求
- 仅在必要时升级为人工客服人员
**关键组件**
- **渠道抽象：**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。**
**权衡**
**关键组件**
- **电子邮件渠道：**处理捕获入站消息、解析内容和附件以及保持线程连续性以启用异步对话。
- **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，以获取人工服务代表响应。
**权衡**
**关键组件**
- **事件源**
- 在外部数据被接收到 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](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-create-eventbusconnector-data-stream.html) 的事件数据，转换和构建流或实时见解
- **计算、流和实时见解**为客服人员提供有关客户的即时相关数据。这样就能先发制人地解决问题，缓解升级。**数据图形**主动显示来自不同数据源的关系和见解,能够及早发现与客户参与、活动和简档相关的模式或异常。
- **Data 360 向量存储和 RAG** 检索器为客服人员提供了所有相关企业数据和非结构化 Knowledge 文章的统一视图,确保回复准确并符合上下文。
- **事件目标**
- 主动通知员工或联系客户
- 可扩展到客服人员（请参阅[环境客服人员](#23-环境客服人员模式)和[自主客服人员](#25-自主客服人员模式)模式）
**交互**
1. 外部系统发生了显著的变化。
2. 外部系统会发出事件，并通过 API（创建平台事件）或发布/订阅 API 将其发布到 Salesforce 事件总线，或者事件数据会流式传输到 Data 360。
3. 触发事件的订阅者。触发流。
4. 流会使用事件数据调用[客服人员操作](https://help.salesforce.com/s/articleView?id=platform.automate_flow_ref_elements_actions_generate_ai_agent_response.htm&type=5)。客服人员确定并执行正确的操作流程。
5. 结果是触发通知或工作流。通知在协作工具（例如 Slack）中传递给用户。也会生成任务或事件。此外，操作可以调用外部系统。因此，事件不会丢失，而是主动执行、发出信号并采取行动，消除了发现它们的人工开销或复杂的自动化。
**权衡**
**关键组件**
- **事件源层**
- 来自低级别平台活动的 CRM 数据、平台事件、变更数据捕获 (CDC) 数据和实时事件监控 (RTEM) 数据
- **Data 360**
- Data 360 组件，包括 **DLO 和 DMO，**存储 CRM [或平台事件生成](https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-create-eventbusconnector-data-stream.html)的事件数据，转换和构建流或实时见解
- **计算、流和实时见解**为客服人员提供有关客户、员工活动或系统中元数据变化的即时相关数据。这样就能先发制人地解决问题，缓解升级。这种实时情况感知使客服人员能够为治理和合规运营吞吐量提供及时的干预措施。
- **数据图形**主动显示来自不同数据源的关系和见解,能够及早发现与客户参与、活动和简档相关的模式或异常。
- **Data 360 向量存储和 RAG** 检索器为客服人员提供了所有相关企业数据和非结构化 Knowledge 文章的统一视图,确保回复准确并符合上下文。
- **Agentforce 客服人员：**客服人员的行为和目的由以下组件定义。
- **主题和说明：**指定客服人员的任务，以根据 Salesforce 中的数据更改强制执行业务规则和自动化流程。它定义了客服人员的目标（例如，“确保所有业务机会在到达协商阶段之前都由一个主要联系人更新”）以及触发客服人员的特定记录创建、字段更新等。
- **操作：**事件触发和计划的操作，旨在响应内部 Salesforce 事件。虽然这些操作针对常规任务自主操作，但它们通常包括编排涉及人为干预的工作流的能力，升级为用户进行审核、批准或处理需要人为判断的场景。
- **护栏：**防护栏充当一组可配置规则和运行时检查，约束客服人员的行为。充当安全层，可以拦截提示，验证客服人员的建议操作，并筛选最终响应，以防止有害内容，强制执行业务规则，并确保客服人员在其指定范围内运行。
- **提示模板：**通过合并字段或来自 Data 360 RAG 检索器的语义数据，使用实时 CRM 数据动态填充的可重用模板。这些模板允许客服人员生成上下文品牌内容，而 Einstein Trust 层在指令发送到 LLM 之前安全地屏蔽敏感信息。
- **事件目标**
- 主动通知员工或联系客户。
- 可扩展以呼叫其他客服人员（查看[环境 AI](#23-环境客服人员模式) 和[自主 AI](#25-自主客服人员模式) 模式）
**交互**
1. 内部系统会发生显著变化，例如更新 CRM 记录、元数据修改或从 Data 360 触发的数据操作。
2. 内部系统会发出事件，并通过 API（创建平台事件）或发布/订阅 API 将其发布到 Salesforce 事件总线，或者事件数据会流式传输到 Data 360。
3. 触发事件的订阅者，并激活流或 Apex。
4. 激活的流或 Apex 调用[客服人员操作](https://help.salesforce.com/s/articleView?id=platform.automate_flow_ref_elements_actions_generate_ai_agent_response.htm&type=5)。
5. 结果是触发通知或工作流。通知在协作工具（例如 Slack）中传递给用户。也会生成任务或事件。此外，操作可以调用外部系统。
6. 因此，事件不会丢失，而是主动执行、发出信号并采取行动，消除了发现它们的人工开销或复杂的自动化。
**权衡**
**模式 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 客服人员处理响应、更新内部状态、继续执行任务或为用户提供反馈。
**权衡**
CloudHub 2.0 网络架构的基本组件是：
- HTTP 负载平衡器
- Mule 副本 DNS 记录
- 专用空间
- 区域服务
有关更多详细信息，请查看 [CloudHub 2.0 网络架构](https://docs.mulesoft.com/cloudhub-2/ch2-networking-guide)。
**虚域**
创建专用空间时，它会收到 DNS 目标名称，格式为：\
CloudHub 2.0 还支持自定义或虚域，方法是使用 TLS 上下文和 DNS 记录在专用空间中配置它们。要在专用空间的运行时管理器中创建 TLS 上下文，请上传公共证书和私钥，然后在应用程序的设置中添加自定义端点以使用该域。创建 DNS 记录（例如 CNAME），将虚域指向专用空间的默认主机名。
例如，在 us-west-2 中部署的名为 test-api 的应用程序（默认 DNS 为 42y52r.usa-w2.cloudhub.io）的 API 端点为：
https://test-api-mwsklu-42y52r.usa-w2.cloudhub.io
此 URL 不使用虚域或自定义域。要使用 `acme.com` 使 API URL 显示为`https://test-api.acme.com`，请执行以下步骤。
1. 使用公钥和私钥在运行时管理器中创建 TLS 上下文。
2. 在应用程序的设置中添加虚域，以使用该域。
3. 在 AWS 路由 53 中创建 DNS 记录，并配置简单的路由策略（例如 CNAME），以便虚域解析为专用空间的默认主机名。
对于自定义域，您可以使用 AWS Route 53 或任何其他具有路由策略的全局 CDN 服务。在下图中，AWS Route 53 与“简单”路由策略一起使用。当来自公共（外部）网络的使用者请求 acme.com 时，AWS 路由 53 会将请求路由到 MuleSoft 专用空间入口控制器。
## 故障切换策略
在应用程序需要故障切换时使用此选项：在主要区域（例如 us-west-2）部署一个实例，在次要区域（例如 us-east-1）部署另一个实例。
尽可能使用次要区域的现有环境；创建新环境需要额外努力。
**在一个区域（美国西部 2）部署的应用程序示例，故障转移到另一个区域（美国东部 1）**
| 记录名称 | 流量值/路由到 | 路由策略 | 健康检查 ID |
| :---------: | :-----------------------: | :------------: | :-------------: |
| acme.com | 42y52r.usa-w2.cloudhub.io | 故障转移 | 31s3wseq121 |
| acme.com | 31e51s.usa-e1.cloudhub.io | 故障转移 | 43e131s131sq |
在此配置中，AWS 路由 53 将流量路由到美国西部 2 和美国东部 1 的专用空间的入口控制器。故障转移路由策略配置了健康检查。
## 高可用性和低延迟
为了获得更低的延迟和高可用性，请使用图中描述的部署策略。使用此策略，应用程序可以部署在两个区域（在本例中是 us-west-2 和 us-east-1）。
使用 AWS 路由 53 中的延迟路由策略，将请求路由到提供最低延迟的区域，同时保持高可用性。 AWS 路由 53 中的“延迟”路由策略，将请求路由到仍然具有高可用性的较低延迟。
**在两个地区(美国西部 2 和美国东部 1)部署的应用程序，可实现更低的延迟和高可用性**
| 记录名称 | 值/将流量路由到 | 路由策略 | 健康检查 ID |
| :---------: | :-----------------------: | :------------: | :-------------: |
| acme.com | 42y52r.usa-w2.cloudhub.io | 延迟 | 31s3wseq121 |
| acme.com | 31e51s.usa-e1.cloudhub.io | 延迟 | 43e131s131sq |
## 结论
MuleSoft CloudHub 2.0 为区域内的弹性提供了坚实的基础，主要利用了自动化的副本冗余和智能负载平衡。在单个云区域中，部署具有多个副本的应用程序可确保如果一个实例失败，其他实例可以立即接管工作负载。集成的负载平衡器有效地在这些健康的副本之间分配传入流量，最大限度地减少停机时间，并确保在正常操作条件下的持续服务可用性。
然而,完全依赖这种单一区域架构,即使这种架构具有高冗余性,也很有可能出现大范围的灾难性区域中断。历史表明，即使是最可靠、技术最先进的云提供商，也容易受到破坏性事件的影响，从而影响整个地理区域。这些单点故障虽然罕见，但可能由各种事件引起，包括：
- 大规模基础设施事件
- 主要电源故障
- 广泛的网络中断
因此，为了实现真正的高可用性 (HA) 和灾难恢复 (DR)，架构的设计必须超越单区域模式的限制。推荐的策略是跨多个地理位置不同的区域进行部署。这种区域间弹性确保了如果整个云区域由于意外灾难而不可用，流量可以无缝地故障切换到在单独的、不受影响的区域运行的应用程序实例，从而保证最少的服务中断并实现最大的正常运行时间目标。
## 引用
[CloudHub 2.0 网络架构](https://docs.mulesoft.com/cloudhub-2/ch2-networking-guide)
[为标准队列配置跨区域故障切换](https://docs.mulesoft.com/mq/mq-failover)
[对象存储 V2 部署区域](https://docs.mulesoft.com/object-store/osv2-faq#osv2-regions)
[您的对象商店部署区域](https://docs.mulesoft.com/object-store/osv2-faq#is-object-store-v2-persistent-in-the-same-region-as-the-worker)
## 关于作者
Gulal Kumar 是 Salesforce 的软件工程架构师，专注于数据和集成架构。他在集成和 API、现代化计划、安全和 AIML 计划方面拥有超过 20 年的经验，拥有丰富的专业知识。Gulal 一直致力于推进业务转型计划，增强安全性和弹性，促进架构卓越性，并领导各个领域的 AIML 计划。
Ajay Nagaraju 是 MuleSoft 的企业架构师和高级总监，在企业架构、系统集成和大规模数字转型方面拥有超过 28 年的经验。他曾领导财富 100 强和财富 500 强组织中数百万美元的复杂计划的架构和交付，在 API 引导的连接、SOA、云技术和企业集成模式方面拥有深厚的专业知识。Ajay 与管理层领导密切合作,以实现业务流程、数据平台和集成生态系统的现代化,并热衷于构建可扩展的架构、指导团队和通过技术推动可衡量的业务成果。
# Data 360 和集成入门
本节涵盖了如何构建数据平台并将 Salesforce 与企业系统集成。这些文章提供了构建统一数据架构并将 Salesforce 与更广泛的技术生态系统联系起来的基本 Knowledge。
## Data 360 架构
[Data 360 架构](/docs/architect/zh-cn/fundamentals/guide/data-360-architecture)引入了专为 AI 支持的未来设计的 Salesforce 下一代数据平台。本综合指南涵盖：
- **现代数据平台架构**:Data 360 集成了 AI/ML、分散数据、云湖库、非结构化数据、Knowledge 管理和实时处理。
- **设计原则**:开放性、互操作性、多模型存储、元数据驱动的设计、实时混合处理、智能数据、治理和一对多租户。
- **关键优异点**:与 Snowflake、数据块、BigQuery 和 Redshift 联盟，在不重复现有投资的情况下扩展 Customer 360。
- **用例和功能**:支持实时见解、自主决策以及对结构化和非结构化数据的统一访问。
本文档对于为代理企业时代规划数据策略的企业架构师和 CTO 至关重要，它提供了对 Data 360 架构的战略指导和技术深度挖掘。
## 集成模式
[集成模式](/docs/architect/zh-cn/fundamentals/guide/integration-patterns)提供了将 Salesforce 平台与企业中的其他应用程序集成的综合指南。本文档提供：
- 基**于模式的方法**:常见场景的集成模式，从成功的 Salesforce 实施中提取。
- **模式选择指南**:用于为您的特定集成场景选择正确模式的矩阵。
- **集成最佳实践**:快速构建稳定、可扩展和可维护集成的提示。
- **全面覆盖范围**:实时同步、批处理、数据迁移和事件驱动架构的模式。
本文档专为需要将 Salesforce 与其他企业应用程序集成的架构师和开发人员设计。Salesforce 自己的咨询架构师在架构审查期间将这些模式用作参考点，使其成为集成架构的权威指南。
---
这两篇文章相互协作，帮助您了解如何使用 Data 360 构建现代数据平台，以及如何将 Salesforce 与现有企业系统有效集成。从 Data 360 架构开始，了解数据平台功能，然后探索集成模式，了解如何将 Salesforce 与更广泛的技术生态系统联系起来。
# 概览
Salesforce Data 360 改变了企业大规模连接、协调和激活客户数据的方式。然而，它的真正优势在于如何在数据的整个生命周期中对其进行安全的管理。此安全参考架构为保护 Data 360 环境提供了实用的端到端蓝图。我们通过默认的最低特权、Trust任设计和治理的核心原则来实现这一点。
Data 360 中的安全性是其基础，是一种共享责任模型。Salesforce 按照 ISO 27001、SOC 2 和通用数据保护条例 (GDPR) 等全球标准保护基础设施、网络、加密服务、平台、合规性和应用本身。Salesforce 管理员通过定义访问权限、强制实施隐私和管理集成来保护组织在平台内的数据。这包括实施仅授予必要访问权限的强身份和访问权限管理 (IAM)、强制实施双重身份验证 (2FA) 以及遵守最小特权原则以及企业和监管要求。
Data 360 治理将这些责任层连接起来，确保安全和合规保持一致。它确保定义角色、策略、权限和数据处理规则，并在从接收到激活的整个过程中持续强制执行。数据谱系、元数据分类和同意意识内置于每个对象和流程中。这将治理从手动监督职能转变为运营控制平面。
Salesforce 提供了弹性、合规的基础，企业可在其中保留对其数据状态、隐私设置和集成边界的完整权限。它们共同创建了安全和治理结构，其中每个数据集、策略和用户操作都是可跟踪、一致的，并且都基于 Trust。
Data 360 中的安全性超出了静态控制的范围。它嵌入到数据生命周期的每个阶段。从接收数据开始，它就被加密、验证并在企业策略下分类。当元数据被统一和丰富时，元数据谱系和同意属性将被保留，以确保问责制。当为业务或 AI 使用激活见解时，出站流通过加密渠道、强身份验证和授权、策略感知治理和同意强制执行来加以保护，确保数据从接收到激活都保持可信、合规和安全。
## Data 360 的安全基础
Data 360 提供了基于 Hyperforce 架构和云原生功能的设计安全基础。
### 构建于 Hyperforce
Salesforce Data 360 是一个完全基于 Salesforce Hyperforce 架构构建的云原生数据平台，为全球运营提供安全、合规和可扩展的基础。
### 按设计安全基础
* Hyperforce 将安全性和合规性作为内置功能而不是加载项提供。它提供了一套通用的基础控制，这些控制与 Salesforce 的平台和应用程序深度集成，确保从基础设施到应用程序体验的每一层都以安全、隐私和合规性为核心进行设计。
* Data 360 直接从 Hyperforce 的基础控制继承强大的访问控制、加密和监管合规框架。
* 这种默认安全模型最大限度地减少了漏洞，并简化了可信、合规的数据服务的交付。
### 云原生架构
* Data 360 在 Hyperforce 之上托管的专用功能域中运行，Hyperforce 是确保隔离、性能和多租户安全性的统一云平台。
* Data 360 使用微服务架构，所有服务通过 Kubernetes 进行容器化和编排。
* 应用Trust原则，Istio 服务网格管理安全的服务间通信，并提供流量管理、可观察性和策略实施。
### 可扩展和模块化部署
* Data 360 服务通过 Salesforce 受管虚拟私有云 (VPC) 配置和运行，实现了隔离、高效控制和优化的内部网络。
* 该架构支持水平可扩展性，确保 Data 360 可以处理 PB 级别的数据处理工作负载。
### 集成和扩展性
* Data 360 公开了定义明确的 API，以便与 Salesforce CRM 应用程序和其他数据源集成。
* 它支持第一方 (1P) 和基于 Hyperforce 的 Salesforce CRM 组织，确保跨环境的广泛兼容性。
* Data Cloud One 使客户能够使用单个 Data 360 实例连接多个 Salesforce CRM 组织。
### 分担责任模型
Salesforce Data 360 中的安全性在[共享责任模型](https://compliance.salesforce.com/en/documents/a006e000010nW2FAAU)下运行，Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud 等领先的云提供商也使用该框架。
该模型定义了明确的边界：Salesforce 负责云**的**安全性，客户负责云**中**的安全性。了解并操作这一区别对于维护一个有弹性、合规和安全的数据生态系统至关重要。
#### Salesforce：云的安全性
Salesforce 负责保护和维护 Data 360 平台及其全球基础设施的完整性。这包括：
* **物理和环境安全：**Hyperforce 托管在 AWS 基础设施上，Amazon 受委派负责通过访问控制、监视和环境保障措施来保护他们的全球数据中心。
* **网络和周边防御：**分布式拒绝服务 (DDoS) 缓解、入侵检测，以及对所有传输中（TLS 1.2 及更高版本）和静态 (AES-256) 流量的加密。
* **平台强化和补丁管理：**持续漏洞管理、补丁部署和操作系统级安全基准。
* **合规性和认证：**根据 SOC 1/2/3、ISO 27001、ISO 27017、ISO 27018 等标准进行持续审计，并为 GDPR 等框架做好准备。
这些控制确保 Data 360 平台保持安全、可靠和合规，使客户能够专注于业务逻辑和数据管理，而不是基础设施防御。
#### 客户：云中的安全性
客户负责保护其 Salesforce Data 360 组织中的数据、配置和操作流程。问责制的关键领域包括：
* **身份和访问权限管理 (IAM)：**定义角色，强制执行多重身份验证 (MFA) 和单点登录 (SSO)，并应用最小权限原则。
* **数据治理：**分类敏感数据，在需要的地方应用屏蔽，并实施对象、字段和记录级别的访问控制。
* **集成安全性：**使用命名凭据和外部凭据，通过 OAuth 2.0、JSON Web 令牌 JWT 和其他身份验证标准管理 API 访问权限。
* **监控和响应：**使用事件监控和审计跟踪，并将日志转发到安全信息和事件管理 (SIEM) 系统，以进行高级威胁检测。
Salesforce 提供安全基础，但客户通过其配置、控制和警惕来确定其实际安全状况。
#### 以人为本的责任
安全性不仅仅是一个技术结构，还是一个组织纪律。Salesforce Data 360 中的数据保护通过架构、运营和治理团队之间的协作来实现。
**企业应：**
* 持续查看和停用未使用或特权过大的客户。
* 使用策略作为代码和 CI/CD 漏斗，自动化实施。
* 执行桌面演习，模拟未经授权的数据激活或泄露等事件，以加强响应准备。
Data 360 的有效性不仅仅取决于功能，还取决于客户如何负责任地操作它们。
#### 默认安全：主动安全态势
Salesforce Data 360 采用默认安全理念，即从反应式控制转向预防性设计。现在，每个新的 Data 360 组织都以“拒绝所有”的状态开始，而不是稍后开始打开和收紧，从第一次部署开始就强制执行Trust原则。
#### 从反应性控制到预防性设计
在较旧的环境中，客户继承了宽松的“允许所有”模型，以便更快地加入。虽然方便，但这会产生意外过度暴露和配置错误的风险。
新的默认安全架构颠倒了这种方法：
* 没有用户或系统具有隐式访问权限。
* 必须明确授予所有权限。
* 数据访问、集成和治理控制从第 0 天开始强制执行。
这在设计上强制执行了最少的权限，从而大大降低了意外暴露或权限升级的风险。
#### 运营和治理影响
该模型具有技术和行为含义：
* 团队必须有意规划访问模型，使权限与合规和业务边界保持一致。
* 治理成为内置设计要求，而不是事后的想法。
* 数据的所有权和问责制从一开始就定义。
对于仍在“允许所有”下操作的传统 Data 360 组织，管理员必须手动收紧配置，以与新基准保持一致，这是任何安全现代化或 Data 360 成熟度计划中的关键一步。
#### 按设计的Trust
Salesforce Data 360 通过默认零访问和要求明确的策略定义，通过设计建立 Trust，这是企业数据安全的基础发展。
此方法可确保：
* 未授权访问和数据泄露风险最小化。
* 治理框架是结构性的，而不是选择性的。
* 企业可在各种环境中获得更可预测、可审计和更具弹性的安全状况。
本质上，安全性不再是您添加的功能，而是您开始的基础。
## 身份和访问权限管理：数据网关
**Salesforce Data 360** 中的身份和访问权限管理 (IAM) 是第一层也是最重要的防御层。它控制**谁**可以访问平台，以及他们可以在进入后执行**哪些**操作。实施良好的 IAM 框架是企业保护其客户数据并确保运营完整性的最强有力的控制手段。
### 身份验证：验证“您是谁”
身份验证建立**数字信任,**确认访问 Salesforce Data 360 的每个用户、服务或外部系统都合法。
### 聚合身份管理
Data 360 支持使用 [**SAML 2.0**](https://help.salesforce.com/s/articleView?id=xcloud.sso_saml.htm&type=5)、OpenID Connect([**oidC**](https://help.salesforce.com/s/articleView?id=xcloud.sso_provider_openid_connect.htm&type=5)) 或跨域身份管理系统 ([**SCIM**](https://help.salesforce.com/s/articleView?id=xcloud.identity_scim_overview.htm&type=5)) 与企业级身份提供商 (IdP) 进行**联合身份验证**，例如 [**Microsoft Entra ID (Azure AD)**](https://learn.microsoft.com/en-us/entra/identity/saas-apps/salesforce-tutorial)、[**Okta**](https://help.okta.com/en-us/content/topics/provisioning/salesforce/sfdc-provision.htm) 或 [**Ping Identity**](https://docs.pingidentity.com/configuration_guides/salesforce/config_saml_salesforce_pf.html)。
此联合将企业身份生命周期直接扩展到 Salesforce。当员工加入、转移或离开公司时，他们的访问权限会自动调整，从而减少孤立客户并提高合规性准备。
### 单点登录 (SSO)
通过[**单点登录 (SSO)**](https://help.salesforce.com/s/articleView?id=xcloud.sso_about.htm&type=5)，用户使用公司凭据进行身份验证一次，无需单独密码即可安全访问 Salesforce 应用程序。这会减少凭据疲劳，并最大限度地减少密码重复使用或网络钓鱼的风险。
### 自适应和条件访问
身份提供商 (IdP) 成为身份验证决策的唯一权威机构，强制执行多重身份验证 (MFA)、条件访问和基于风险的控制。身份验证根据用户行为和上下文，从单个事件发展到对 Trust 的持续评估。
联合身份验证提供：
* **集中策略执行：**身份验证标准可在所有 Salesforce 环境中的一个地方进行管理。
* **端到端可跟踪性：**统一审计跟踪会将每个操作链接回已验证的身份。
* **以人为本的经验：**无摩擦、安全的登录流程允许团队专注于见解，而不是凭据。
### 授权：定义“您可以做什么”
验证用户后，授权会定义他们可以访问、查看或修改的内容。它设置保护敏感数据和实施最小权限的操作边界。
**最小特权原则 (PoLP)：**每个用户和系统仅被授予作业功能所需的权限，仅此而已。该原则极大地限制了因凭据被盗或配置错误而造成的潜在损害。
**基于角色的访问控制 (RBAC)：**Salesforce Data 360 使用权限集和权限集组来分配与业务角色一致的精细功能。例如：
* 数据工程师可以在 Data 360 Architect 权限集的帮助下管理接收漏斗和转换。
* 市场营销分析师可以查询统一的数据，但不能在 Data 360 激活管理器权限集的帮助下修改模型。
* 激活管理器可以执行出站市场活动，但无法在 Data 360 激活管理器权限集的帮助下访问源数据
访问权限可集中管理和审计，确保数据生命周期的问责制。当与 IdP（例如 Entra ID、Okta 或 Ping 身份）集成时，访问策略通过 SCIM 配置和 SAML/SSO 联盟在企业中无缝扩展。
### 了解 Data 360 中的标准角色和权限
Salesforce 提供预定义的权限集，封装了职责分离和符合 ISO 27001 等行业标准的最佳实践。
| 角色 | 首要责任 | 访问设计系列 |
|---|---|---|
| 系统管理员 | 环境设置、配置和配置 | 无法访问基础数据集 — 确保系统和数据控制之间的分离 |
| Data 360 架构师 | 数据接收、转换、身份解析和建模 | 无法执行数据激活以维护数据暴露边界 |
| Data 360 激活管理器 | 细分创建、渠道管理和激活 | 对数据模型的只读访问权限；无修改权限 |
| Data 360 用户 | 消耗分析和见解 | 只读；零修改权限 |
| Data 360 One 用户 | 通过同伴组织进行跨组织访问 | 由共享空间权限和范围访问策略控制 |
### 作为控制平面的治理
Data 360 围绕“治理优先”模型构建，确保从接收到见解激活的每个数据交互都是策略感知、可审计和合规的。治理作为中央控制平面发挥作用，管理数据在整个生命周期中的发现、分类和保护方式。
此统一控制平面确保：
* **数据访问是上下文授权**的:只有正确的用户在正确的策略下才能对正确的数据进行操作。
* **治理嵌入到语义层和操作层中**,确保数据建模方式和保护方式的一致性。
* **零信任和最低特权**原则得到执行:在授予访问权限之前实时评估身份、上下文和政策。
通过此架构，Salesforce Data 360 将治理从静态权限管理转变为动态的、策略驱动的编排层。一种持续适应环境、通过设计强制执行合规性并保持企业级 Trust 的方法。
### 带数据空间的逻辑数据隔离
在宏级别，数据空间提供了企业数据域的逻辑隔离和隔离，使具有多品牌、多地区或多租户运营模型的组织能够在单个统一平台中管理数据。数据空间可以与业务域（例如销售、市场营销或客户成功）或监管和地理边界（例如欧盟、AMER 或亚太地区）保持一致，允许治理和访问控制反映组织的运营和合规结构，而不会分散底层数据平台。
* 每个数据空间充当虚拟边界，定义用户或团队可以看到或交互的数据收集。
* 明确授予数据空间内的访问权限，确保没有隐含的权限或交叉污染数据可见性。
* 这实现了联合所有权：每个业务部门都可以独立管理其域，同时保持集中的监督和合规。
通过设计，数据空间提供了第一层治理，在整个企业数据集之间建立了结构清晰度和问责。
### 从 RBAC 到 ABAC：转向上下文授权
在 Salesforce Data 360 中，RBAC 和 ABAC 具有不同但互补的目的，它们应用于平台的不同层。
RBAC 主要用于平台和功能访问。它控制谁可以访问 Data 360 结构和功能，例如数据空间、流程创建、管理功能和工具访问权限。RBAC 通过权限和权限集实施，例如，分配用户对具有特定启用功能的数据空间的访问权限。
ABAC 用于数据访问实施。ABAC 策略完全负责确定谁可以访问哪些数据对象和属性，包括对象级安全性 (OLS)、字段级访问权限和行级约束。这些决策通过在运行时评估操作、用户属性和资源属性来动态做出。
在 ABAC 中，权限仍然是模型的一部分，但策略本身决定了访问权限，而不仅仅是角色。策略会评估上下文，例如业务部门、地区、数据灵敏性、使用目的或允许或拒绝访问的监管约束。
例如：
* RBAC 允许用户访问 Data 360 数据空间和分析功能。
* ABAC 确定同一用户是否可以读取特定的客户数据集，他们可以看到哪些行，以及哪些属性被屏蔽或限制。
这种清晰的分离使 Data 360 能够安全地扩展：
* RBAC 提供对平台功能和工作流的控制访问。
* ABAC 提供符合合规性、驻留和数据保护要求的细粒度、策略驱动的数据访问。
它们共同支持受管数据民主化，而不会将平台权限与数据授权逻辑混淆。
实际上，RBAC 会根据权限分配强制执行访问权限，而 ABAC 则在上下文中评估权限 — 结合操作、用户和资源属性，以在 Salesforce Data 360 中提供自适应的精细访问控制
### ABAC：多层安全层次结构
Salesforce Data 360 细粒度访问控制的核心是基于属性的访问控制 (ABAC，由 CEDAR 策略语言提供支持)。
与静态的、基于角色的权限不同,ABAC 动态评估*谁*在请求访问、他们试图访问*什么*以及*在什么条件*下访问----确保每次数据交互都符合企业政策和 Trust 边界。
#### 动态策略评估
Data 360 的 ABAC 引擎根据三种核心属性类型的组合评估访问决策：
* **用户属性：**部门、位置、审批级别
* **数据属性：**分类、灵敏性(PII、PHI、财务数据)、数据空间
这种灵活的策略驱动模型允许强制实施随着用户角色、数据分类或运营条件的发展而自动适应，这对于大型、分布式和受监管的企业至关重要。
#### Salesforce Data 360 中的 ABAC 架构组件
Salesforce Data 360 实施基于标准的基于属性的访问控制 (ABAC) 架构，该架构符合策略驱动的数据治理的行业最佳实践。它由三个主要功能组件组成：
* **策略信息点 (PIP) - 策略、丰富元数据和分类：**
* 包含策略定义本身，包括管理企业数据的数据访问、分类、屏蔽、保留和使用策略。
* 维护丰富的元数据，例如标签、分类、业务上下文和端到端谱系。
* 利用 LLM 和 ML 驱动的分类来自动标记敏感数据（例如 PII.Email、PII.Phone、PHI）。
* 标签传播确保分类沿着数据谱系自动流动（DLO → DLO → DMO）。
* 在转换之间保持灵敏性和合规性。
* **策略决策点 (PDP)**:PDP 是解释 CEDAR 策略的决策引擎。
* 从 PEP（用户身份、请求元数据）接收上下文输入，并从 PIP 接收引用属性。
* 确定地评估策略，以提供一致、可解释和可扩展的访问决策。
* 支持实时和批量评估，即使在高用量环境中也能确保性能和精度。
* **策略执行点 (PEP)**:PEP 是在运行时强制执行授权决策的地方。
* 拦截所有交互渠道中的数据访问请求，例如 API、UI 查询、CRM 丰富或 GenAI 检索扩充生成 (RAG) 漏斗。
* 立即应用 PDP 结果，确保每个查询和检索都符合企业访问策略。
PIP-PDP-PEP 三者共同构成了一个分布式治理结构，在所有 Data 360 服务和访问模式中实施一致的、基于策略的控制。
重要的是，Data 360 中的 [ABAC](https://help.salesforce.com/s/articleView?id=data.c360_a_policy_based_governance_dg.htm&type=5) 是配置的，而不是构建的。架构师不会汇编自定义控制平面或强制逻辑。相反，它们填充并连接三个本地架构组件，它们一起作为统一的治理结构运行。
在实践层面，实施遵循一个简单的过程：分类数据，定义策略，并让平台自动实施它们。一旦配置，访问控制将成为系统行为，而不是手动或程序过程。
这种分布式治理结构确保**所有访问渠道**的一致政策执行,在整个 Data 360 中建立统一 Trust 边界。
#### 多级策略实施
Data 360 的 ABAC 框架支持分层访问边界，确保数据不仅在对象级别受到保护，而且在特定字段和记录中受到保护。
* **对象级安全性 (OLS)**:访问控制的最外部边界。
管理对整个数据结构的访问，例如数据湖对象 (DLO) 或数据模型对象 (DMO)。
示例：授予对*客户*对象的访问权限，但不授予对*交易的*访问权限。
* **字段级安全性 (FLS)**:控制对对象中特定字段的访问。
示例：市场营销用户可以看到客户名称，但被限制查看信用卡号码或国家标识符。
* **记录级安全性 (RLS)**：最精细的控制层。
确定用户可以查看或修改数据集中的哪些单个记录。
示例：区域经理仅可以访问与其分配区域相关的客户数据。
* **动态数据掩码 (DDM ) :**启用实时数据保护。作为 ABAC 的补充，DDM 在不更改基础数据集的情况下，强制执行策略驱动的敏感信息模糊。在查询时，DDM 根据用户角色、上下文或合规规则自动屏蔽 PII 或财务数据等字段。
* 敏感数据在 UI 视图、API 和 AI 工作流中受到保护。
* 通过确保所有消耗层之间一致的屏蔽，降低数据泄露风险。
* 保持可审计性。每个屏蔽查询都会在 Data 360 的治理框架内进行记录和跟踪。
此架构将访问控制从静态权限模型转换为动态上下文感知策略结构。通过将 RBAC 的结构简单性与 ABAC 的上下文深度相结合，Salesforce Data 360 实现了：
* 在接收、协调和激活方面实现一致的策略实施。
* 随数据、角色和合规需求而变化的自适应治理。
* 从接收到 AI 激活的整个数据生命周期中的统一 Trust 边界。
#### 与 Salesforce 平台深度集成
Salesforce Data 360 的治理模型本地嵌入到 Salesforce Platform 中，实现了对运营和分析数据的统一安全性、合规性和访问控制。通过继承 Salesforce 的核心身份和访问权限管理功能，例如身份联合、权限集、集中策略编写和平台加密，Data 360 可在云之间应用一致的 Trust 策略，而无需引入并行治理堆栈。该平台不是将隔离、授权和谱系视为单独的问题，而是将它们集成到一个跨整个数据生命周期的执行感知 Trust 结构中。
在结构层面，该治理结构由三个相互补充的层共同组成：
* **数据空间**为数据隔离和监管细分建立了明确的逻辑边界
* **基于属性**的访问控制 (ABAC) 支持基于身份、目的和数据属性的细粒度上下文感知授权决策
* **语义谱系**,在数据从摄取到见解和激活的过程中保留业务意义、灵敏性和可追溯性
它们共同创建了一种治理模型，在这种模型中，访问决策是可解释的，强制执行是自动的，合规是连续的，而不是回顾性的。其结果是，治理不再是限制因素或事后想法的平台。相反，它成为一个支持层 — 允许架构师自信地设计数据产品和 AI 驱动的工作流，相信系统本身正在强制执行 Trust、隐私和监管要求。
这种组合方法确保企业数据不仅可用，而且负责任地可操作 — 大规模支持见解、激活和自动化，同时不损害透明度、安全性或控制。
## 保护数据生命周期：从摄取到激活
在 AI 驱动的企业时代，保护数据不是一次性的，而是一个持续的过程，从信息进入生态系统的那一刻起，直到它被激活供业务或 AI 使用。
Salesforce Data 360 在数据生命周期的每个阶段嵌入安全和治理控制，确保从接收到见解激活的数据完整性、机密性和 Trust 都得到维护。
### 保护的基础：静态和传输中的加密
Salesforce Data 360 保护模型的核心是 Platform Encryption for Data 360，这是一个透明的高性能加密框架，可以保护静态和传输中的数据，同时不影响可用性或可扩展性。
#### 静态加密：存储层安全性
Data 360 Data Lake 中保留的数据**在存储层自动加密**,确保即使发生物理或未经授权的访问，数据仍不可读。主要功能包括：
* **透明数据湖加密：**在数据湖中保留的所有数据都使用客户受管密钥 (CMK) 在存储层加密。这确保了即使发生对物理存储的未授权访问，数据仍然不可读和解密。
* **客户管理的密钥 (CMK)：**客户保持对加密密钥的完全控制 — 这是金融服务、医疗保健和政府等受监管行业的关键功能。CMK 支持精细的审计、控制和数据主权证明，直接与 GDPR、HIPAA 和 ISO 27001 等法规要求保持一致。
* **外部密钥管理 (EKM)：**借助外部密钥管理（Data 360 平台加密的一项功能），客户将能够使用存储在客户 AWS KMS 帐户中的密钥加密 Data 360 中的数据。这为客户提供了更多的灵活性，同时保持他们在 Data 360 中的数据安全和受保护。
* **自带密钥 (BYOK)：**Data 360 基于 CMK 和 EKM，现在允许客户直接在 Salesforce 中上传他们自己的密钥材料，以加密静态数据和搜索索引。此增强功能为 PII、敏感、机密和专有数据提供了额外的保护层，无需客户在 AWS KMS 中创建或管理密钥。
* **密钥轮换和生命周期管理：**密钥更迭是优雅地处理的。新数据使用新密钥加密，而旧数据仍使用原始密钥加密，避免停机或性能下降。这种轮换机制在不中断运营的情况下加强了合规性。
#### 传输中的加密：网络级安全性
Data 360 服务、API 和连接器之间传输的每个数据都使用传输层安全性 (TLS) 1.2 或更高版本进行保护，并提供动态的端到端加密。
这将确保：
* 数据无法在传输期间被拦截或更改。
* Salesforce 服务、受信连接器和客户端点之间的通信保持专用和可验证。
* 安全性在摄取漏斗、协调流程、激活工作流和外部 API 集成之间一致扩展。
通过将静态客户受管加密与传输中的连续加密相结合，Salesforce Data 360 创建了深度防御架构，可以保护客户数据免受外部攻击和内部基础设施威胁。
### Data 360 中的安全系统到系统集成（数据集成）
虽然加密和访问控制保护 Salesforce Data 360 中的数据，但保护数据在系统之间的移动同样重要。现代企业运行在多云和混合环境中，敏感数据在 Salesforce、分析平台、外部 API 和数据湖之间流动。
为了解决这个问题,Salesforce 设计了以命名凭据 (NC) 和外部凭据 (EC) 为中心的安全集成框架 — 为安全连接提供了策略驱动的零信任基础。
#### Salesforce 的安全集成框架
Salesforce 构建了强大的**[安全集成框架](https://developer.salesforce.com/docs/platform/named-credentials/guide/get-started.html)**,其核心是命名凭据 (NC) 和外部凭据 (EC)。它们一起抽象了凭据的复杂性，强制实施最低权限的访问，并在所有集成之间实现了一致的身份验证管理，而不会暴露代码或配置中的秘密。
这一框架抽象了安全复杂性,强制执行了最佳做法,为所有外部连接建立了**政策驱动控制平面**----符合Salesforce的**Zero Trust**和**逐设计安全**原则。
##### 命名凭据
命名凭据 (NC) 是 Salesforce 安全集成架构的基石。它们提供了一种声明性的集中机制来定义外部端点及其身份验证参数 — 无需硬编码敏感凭据，例如 Apex 代码或配置文件中的用户名、密码或令牌。相反，开发人员和管理员只需引用命名凭据别名（例如 SnowflakeConnector_NC），Salesforce 会自动处理基础身份验证和连接管理。
**架构和安全优势：**
* **简化维护：**NC 将外部端点 URL 和身份验证参数整合到一个受管记录中。任何更新（例如更改端点或轮换凭据）仅需要更改 NC 记录，避免跨环境重新部署代码或流。
* **增强安全性：**凭据安全地存储在 Salesforce 的加密密码存储中，防止在代码存储库、配置文件或日志中泄露。身份验证过程本身在运行时自动管理，减少了人为错误和泄露风险。
**合规遵守：**将凭据与业务逻辑分离简化了对数据保护法规的遵守，例如 **GDPR、HIPAA 和 PCI DSS**。审核员可以轻松验证外部数据访问是否符合企业安全和治理策略。
* **绕过远程站点设置：**NC 消除了对远程站点设置的原有要求，简化了配置和部署，特别是对于大规模或多环境的企业实施。
#### 外部凭据
外部凭据 (EC) 定义了 Salesforce 在连接到外部服务时使用的身份验证协议和流 — 有效地回答了“如何进行身份验证”。单个 EC 可以在共享相同身份验证类型的多个 NC 中重复使用，促进配置重复使用和一致的安全实施。
**支持的身份验证协议：**
* OAuth 2.0（支持所有变体）
* JWT（JSON Web 令牌）
* 基本身份验证
* AWS 签名 v4
* 自定义身份验证
* 无身份验证（适用于开放 API 或公共端点）
外部凭据和命名凭据围绕明确的职责分工而设计。外部凭据定义了如何进行身份验证 — 指定连接到外部系统的身份验证协议、令牌类型和刷新行为。另一方面，命名凭据定义了连接的位置 — 端点 URL，以及用于该连接的外部凭据。这种设计确保了身份验证逻辑和端点配置保持分离，使 Salesforce 能够安全地支持各种集成协议，同时在整个企业中保持集中和一致的凭据管理。
### Data 360 连接器如何利用此框架
虽然 Data 360 的用户界面抽象了大部分底层配置，但命名凭据和外部凭据框架经常被其本机连接器和数据流掩盖起来使用。这意味着，即使管理员只是通过引导式 UI “添加数据连接”，Data 360 仍然在后台应用这种标准化的安全模型。
架构含义：
* **统一安全模型：**每个连接器（无论是外部数据库 、AWS S3 还是企业 API）都受益于命名凭据和外部凭据实施的相同加密、身份验证和密钥管理标准。
* **开发人员抽象：**开发人员和管理员不需要手动处理身份验证流或凭据轮换。Salesforce 管理令牌生命周期、过期和自动刷新。
* **一致的策略执行：**此框架确保所有连接器遵守一致的身份验证、审计和日志记录策略，这对受监管行业的大规模多源接收至关重要。
* **面向未来的扩展性：**随着 Salesforce 增强其身份验证堆栈（例如，支持新的 OAuth 流或 FIDO2 标准），这些改进会自动在所有连接器之间传播，而无需重构或重新部署。
### Data 360 连接器安全和治理
Salesforce Data 360 提供了大量现成的连接器套件，可简化来自各种来源的数据集成。这使得企业能够有效地整合和利用他们的数据。Salesforce 提供多种连接器类型，包括本地 Salesforce 连接器、云存储连接器、数据库连接器以及应用程序和 API 连接器。除了提供的连接器之外，还支持 Zero ETL 工具。Salesforce 连接器支持 Salesforce 产品（例如 Sales Cloud、Service Cloud 和 Marketing Cloud）与 Data 360 之间的无缝集成。此外，还提供一系列到云存储提供商的连接器，包括 Amazon S3、Google Cloud Storage 和 Azure Data Lake。适用于 Snowflake、Redshift 和 BigQuery 等数据库的预构建连接器允许企业将现有数据仓库与 Data 360 链接。此外，Data 360 为各种第三方应用程序和 API 提供连接器，例如 Google 广告、Facebook 广告和其他营销平台。为了提高灵活性，Data 360 与 ETL 工具集成，例如 MuleSoft 和 Informatica。
#### 数据安全和 Salesforce Data 360 连接器
Salesforce Data 360 中存储的数据的安全性一直是许多 Data 360 相关对话的重点。作为 Salesforce 对深度防御安全方法承诺的一部分，同等重视保护数据如何接收到 Data 360 环境中。
Salesforce 认识到企业在不同的数据生态系统中运营，通常跨越多个云平台、存储解决方案和分析工具。我们的 Data 360 连接器是这些环境之间的桥梁。该连接器支持安全、可扩展和高效的数据集成，同时保持 Salesforce 的高安全标准。这些连接器促进了无缝的数据流，而不会损害完整性或隐私。
Data 360 连接器安全性的三个重要组件是：
* **身份验证/授权映射**:安全访问管理是数据安全的基础。不同的云连接器使用不同的身份验证和授权机制来验证和控制用户访问。身份验证确保用户或系统是合法实体，而授权定义了授予的访问级别。Salesforce 确保其连接器尽可能利用行业标准。
* **零复制 (ZETL) 功能交互性**:数据重复带来了安全和操作挑战。这也带来了不必要的存储成本、数据不一致和更大的风险。Salesforce 的零提取、转换和加载 (ZETL) 方法可确保无需物理数据复制即可在平台之间实现实时数据共享。这意味着数据可以保留在原始环境中，同时仍然可以访问以处理、报告和分析。此外，这也大大减少了攻击面，增强了对数据驻留法律的潜在遵守。
* **数据联合支持**:在当今的多云环境中，组织需要全面的数据访问，而无需不必要的数据移动。Data 360 连接器聚合数据模型支持基于文件和基于查询的数据聚合，使企业能够实时利用外部数据源。无论是访问结构化数据库、半结构化日志还是非结构化文件，Salesforce 的连接器都可以确保数据在其整个生命周期中保持安全。
Salesforce 旨在为客户提供所需的透明度，以帮助驾驭数据安全和合规的复杂性，即使我们的集成也是如此。无论是与 AWS S3、Google Cloud Storage、Snowflake 还是其他平台集成，我们的 Data 360 连接器都旨在确保Trust、透明度和对关键业务数据的控制。
##### Salesforce Data 360 连接器安全和身份验证映射
| 连接器类型 | 连接类型支持 | 主要身份验证类型 | 关键安全方面和备注 |
|---|---|---|---|
| Salesforce CRM | 不适用（内部） | 基于会话（内部） | 使用 Salesforce 强大的内部身份和访问权限管理 (IAM) 模型。所有数据都在 Salesforce 基础设施中传输和静态加密。 |
| Marketing Cloud 参与 | 仅限公共 Internet | OAuth 2.0，用户名/密码 | 标准 OAuth 2.0 协议用于安全身份验证。数据通过公共互联网进行传输加密 (TLS)。 |
| B2C Commerce | 仅限公共 Internet | OAuth 2.0 | 标准 OAuth 2.0。依赖安全公共互联网协议 (TLS) 进行数据传输。 |
| Web 和移动应用程序 | 仅限公共 Internet | API 密钥，OAuth 2.0 | 通过 API（摄取 API、串流 API）摄取的数据。通过 API 密钥管理和标准 Web 协议管理的安全性。 |
| Amazon S3 | 专用连接和公共 | IAM 角色、外部凭据 | 支持 AWS PrivateLink，以实现安全的专用连接。公共连接使用安全凭据。数据在传输和静态加密（S3 中的客户受管密钥可选）。 |
| Snowflake | 专用连接和公共 | OAuth 2.0、私钥身份验证、用户名/密码 | 支持 VPC 专用连接 (AWS PrivateLink)。公共连接适用于安全身份验证方法。数据可以使用 Snowflake 中的客户密钥加密。 |
| Amazon Redshift | 专用连接和公共 | 用户名/密码，IAM 身份验证 | 支持专用连接 (AWS PrivateLink)。公共连接使用标准安全最佳实践。 |
| Microsoft Azure（存储/SQL） | 仅限公共 Internet | SAS 令牌、OAuth 2.0、用户名/密码 | 连接依赖于安全的 SAS 令牌或 OAuth 进行身份验证。数据通过加密渠道 (TLS) 通过公共互联网。 |
| Google Cloud Storage (GCS) | 仅限公共 Internet | OAuth 2.0，服务帐户 | 连接依赖于安全的 OAuth 2.0。数据通过加密渠道 (TLS) 通过公共互联网。 |
| MuleSoft (API) | 仅限公共 Internet | OAuth 2.0，API 密钥 | 通过 API 连接。安全性通过标准 API 身份验证和通过 MuleSoft Anypoint 平台实施的强大治理策略进行管理。 |
| 阶段 | 机制 | 安全/治理控制 |
|---|---|---|
| 激活配置 | 在 Data 360 激活设置中定义 | 通过命名凭据和外部凭据保护 |
| 数据准备 | 从 DMO 筛选和联接 | 应用的同意和隐私元数据 |
| 出站转移 | 通过 TLS/专用连接加密 | 策略实施和凭据抽象 |
| 外部交付 | SFTP/云存储/API | 访问控制和可审计交付 |
所有通信都保留在 AWS 主干中，使用专用 IP 地址和不可路由的网络路径，从而消除了在途数据拦截的风险，并满足了严格的企业和法规安全要求。
此架构确保：
* **零互联网曝光：**数据永远不会离开 AWS 专用网络。
* **专用 IP 通信：**流量仍处于隔离状态，外部无法解决。
* **合规性一致性：**满足 ISO 27001、SOC 2 和 FedRAMP 等安全标准。
#### 专用互连：跨云扩展安全性
为了支持在多云环境中操作的客户，Salesforce 正在通过专用互连将相同的安全原则扩展到 AWS 之外。此功能支持 Data 360 和托管在 Azure 或 Google Cloud 中的数据湖之间的跨云专用连接，并保持专用路由、零互联网遍历和加密仅主干流量的相同保证。
两种架构部署模型可用：
* **客户管理的互连：**客户将现有专用网络电路（例如 Azure ExpressRoute、Google Cloud Interconnect 或 Equinix Fabric）直接与 Data 360 VPC 集成。
* **Salesforce 受管互连：**Salesforce 配置和管理跨云链接，在客户的目标云环境中公开专用服务端点，以便进行一站式设置。
### 保护大门：Salesforce Data 360 中的 API 安全功能
Salesforce Data 360 是用于统一企业数据的强大平台，它通过强大的多层安全控制构建。对于客户来说，管理 API 安全性是全面数据保护策略的重要组成部分，使他们能够有效地控制访问、管理集成和监控使用情况。
以下是可供客户在 Salesforce Data 360 中设置、控制和管理 API 安全性的关键功能和特性。
#### 关键 API 安全特性和功能
客户可以利用一些内置的 Salesforce 功能来确保对其 Data 360 实例的安全 API 访问：
##### 1\.强大的身份验证和授权 (OAuth 2.0)
Salesforce 要求对其 Data 360 API 进行严格身份验证，OAuth 2.0 是标准和推荐的协议。
* **连接的应用程序**:客户创建并配置连接的应用程序，以管理外部应用程序访问权限。这是对 Data 360 摄取和查询 API 进行身份验证和授予访问权限的主要机制。
* **OAuth 范围**:管理员可以定义特定的 OAuth 范围（例如，cdp_ingest_api、api），以请求所需的最小权限，并遵守最小权限原则。
* **多重身份验证 (MFA)**:可以强制执行 Salesforce Authenticator 和其他 MFA 解决方案，添加重要的安全层，并确保只有经过验证的用户才能访问系统，包括通过 API 登录。
##### 2\.粒度访问控制和权限
客户可以精细控制哪些用户和应用程序可以访问数据，以及他们可以执行什么操作。
* **API 访问控制（功能）**:在 Salesforce 支持启用后，此功能允许管理员明确批准哪些连接的应用程序可用于访问 API。所有未批准的应用程序都被自动阻止，从而大大降低了未经授权提取数据的风险。
* **权限集和简档**:管理员通过用户简档或专用权限集分配“已启用 API”权限来管理 API 访问权限。这将确保用户仅拥有与其工作职能相关的访问权限。
* **基于角色的访问控制 (RBAC)**:在 Data 360 中，客户可以创建和管理基于角色的访问控制策略，以定义数据访问级别（对象、字段和记录级安全性），从而确保平台的一致性和控制性。
* **专用集成用户**:最佳实践建议为集成创建特定的“仅限 API”用户，将其权限限制为仅 API 调用所需的权限，而不是使用系统管理员帐户。
##### 3\.网络安全控制
* **IP 白名单/登录 IP 范围**:客户可以将 API 访问权限限制为受信 IP 地址的定义范围。任何来自未批准的 IP 范围的登录尝试都可以被拒绝或质疑验证。
* **专用连接**:此功能构建于 AWS PrivateLink 之上，允许管理员管理敏感数据，而不会将端点暴露给公共互联网，消除了对公共可见端点的攻击风险。
* **传输中和静态加密**:所有数据都在传输中（使用 TLS）和静态加密，保护敏感信息不被未经授权的访问，即使被拦截。
##### 4\.监控、审计和治理
可见性是安全性的关键。Salesforce 提供了广泛的工具来监控和审计 API 活动。
* **事件监控**:提供对各种事件的近乎实时跟踪，包括 API 调用和登录尝试。客户可以使用这些数据进行审计，并创建事务安全性策略。
* **安全中心**:此功能为所有 Salesforce 组织的安全运行状况、合规性和治理度量提供了单一、统一的视图，简化了监控和管理。
* **字段审计跟踪**:帮助客户跟踪登录和字段历史，监控设置更改，并履行审计和数据保留合规义务。
* **数据治理功能**:包括数据标记和分类、策略实施和动态数据屏蔽，以确保在所有数据接触点（包括通过 API 访问的接触点）之间应用一致的治理策略。
#### 设置和管理 API 安全性：客户旅程
1. 启用核心控制：从启用组织范围的默认值开始，例如 MFA 和 IP 限制。
2. 请求 API 访问控制：通过 Salesforce 支持记录个案，以在贵组织中启用“API 访问控制”功能。
3. 配置连接的应用程序：为每个集成创建特定的连接的应用程序，定义所需的 OAuth 范围，并将其分配到授权的简档/权限集。
4. 实施最低权限：确保所有集成用户拥有“仅限 API”权限和最少的数据访问权限。
5. 监控和审计：定期使用 Event Monitoring and Security Center，以查看 API 使用情况、检测异常并执行漏洞评估。
6. 强制执行最佳实践：始终强制执行 TLS，安全地存储刷新令牌，轮换会话 ID，并验证数据输入。
通过利用这些强大的、客户可配置的功能，企业可以为 Salesforce Data 360 中的所有 API 交互维护一个安全和合规的环境。
### 合规、审计和持续监控
#### 服务可用性和数据驻留
Salesforce Data 360 旨在通过其地理分布式部署模型满足全球数据驻留和主权要求。该服务目前在多个受监管地区提供，包括美国、加拿大、巴西、德国、印度、澳大利亚和日本。
数据驻留通过将每个客户的核心组织实例映射到最近的相应 Data 360 区域实例来确定。例如，位于美国或加拿大的核心组织与美国区域内的 Data 360 实例配对，而欧洲联盟内的核心组织映射到托管在德国的实例。同样，印度、澳大利亚、新西兰或新加坡的核心组织与托管在印度的 Data 360 实例相关联。
Salesforce 的 Hyperforce 基础设施是该模型的基础,为地理数据控制、安全隔离和监管合规提供了基础。Hyperforce 确保客户数据（包括元数据、备份和派生数据集）保持在定义的区域边界内。该架构允许企业满足本地数据驻留和合规要求，例如 GDPR、FFIEC、HIPAA 以及亚太地区和 EMEA 地区的区域隐私法。
Salesforce 继续将 Data 360 的可用性扩展到其他 Hyperforce 区域，以符合不断发展的全球隐私标准、区域合规性要求和客户对主权数据控制的期望。
#### 监管合规支持
Salesforce Data 360 旨在帮助企业满足严格的全球隐私和监管要求，例如 GDPR 和 CCPA。该平台提供本地功能来管理数据主体权利 (DSR)，包括数据访问、导出和删除（“被遗忘的权利”），确保个人数据在其整个生命周期中得到合规处理。
虽然客户保留对合规性的最终责任，但 Salesforce 作为认证的“服务提供商”根据 CCPA 等法规运营，提供平台级控制、安全保证和合同机制，使组织能够高效、大规模地实施其合规框架。
#### Foundational Trust：认证和证明
Trust 是 Salesforce 平台的基石，这种 Trust 是通过独立验证获得的。Salesforce 拥有广泛的全球安全认证和认证产品组合，表明它始终致力于保护客户数据和维护云安全的最高标准。
这些认证不仅仅是复选框 - 它们代表了严格的重复性审计，可以验证 Salesforce 安全控制、流程和基础设施的强度和一致性。它们共同构成了 Salesforce Foundational Trust 模型的支柱。
**关键认证和证明包括：**
* **ISO/IEC 27001:**验证 Salesforce 的综合信息安全管理系统。
* **ISO/IEC 27017:**建立特定于云的安全控制的最佳实践。
* **ISO/IEC 27018:**专注于保护云中的个人身份信息 (PII)。
* **SOC 1、SOC 2 和 SOC 3：**确认 Salesforce 安全和隐私控制的设计和运行有效性的独立报表。
* **PCI DSS：**确保安全处理和存储付款卡信息。
* **FedRAMP 高和 DoD 影响级别 4：**认证 Salesforce Government Cloud，供管理敏感工作负载的美国联邦机构使用。
通过维护这组全面的认证，Salesforce 让客户相信他们的数据是在满足（通常超过）全球合规性和安全预期的平台中管理的。
### 最大化可见性：Salesforce Data 360 中的记录、监控和可观察性
在当今快节奏的数字环境中，全方位了解客户数据至关重要，但同样重要的是全方位了解管理这些数据的平台。Salesforce Data 360 提供了强大的内置日志记录、监控和可观察性功能，使客户能够确保数据质量、安全性和性能。
这些工具帮助您从反应式问题解决转向主动式管理，确保您的 Data 360 实施平稳高效地运行。
#### 主动威胁检测和响应
安全不仅仅止于预防 — 而是警惕地发展。在不断变化的威胁环境中，Salesforce 将高级平台监控功能与客户管理的审核流程相结合，以确保主动、持续的保护。
Salesforce 为可见性和威胁检测提供了强大的本机工具：
* **设置审计跟踪**捕获管理更改的完整历史，帮助团队跟踪配置或策略更新。
* **事件监控**提供对用户行为、API 活动和数据访问模式的深入见解。此遥测可与**安全信息和事件**管理 (SIEM) 解决方案无缝集成，以实现集中分析和关联。
#### 1\.Event Monitoring：贵组织的脉搏
Event Monitoring 是 Salesforce Shield 产品的一部分，是跟踪 Salesforce 组织中详细用户活动和系统性能数据的中央中心，包括特定于 Data 360 的操作。它会将大量“事件”捕获到日志文件和对象中，以便进行分析。
* **事件日志文件 (ELF)：**这些提供了用户活动和系统事件的精细详细信息，可在短暂延迟（每小时或每天）后下载。您可以通过 API 或事件日志文件浏览器访问最多 30 天的数据，并选择导出以进行长期存储。
* **实时 Event Monitoring：**对于即时见解，实时事件会作为平台事件流式传输，允许您近乎实时地监控和检测活动。这对于安全和性能至关重要，使您能够在需要时立即采取行动。
* **Data 360 特定事件：**Event Monitoring 包含特定于 Data 360 使用情况的事件类型，例如 Lightning 页面视图、Lightning 交互以及与 Data 360 页面和数据相关的报表事件。
* **与外部工具集成：**Salesforce 有助于与流行的第三方监控解决方案（例如 Splunk、Datadog、New Relic 和 Sumo Logic）无缝集成。您可以将 Event Monitoring 数据流式传输或导出到这些平台，以便在整个技术堆栈中整合可观察性。
#### 2\.性能监控和优化
了解 Data 360 实施的性能是获得卓越用户体验的关键。
* **Lightning Usage应用程序：**该内置应用程序为 Lightning Experience 中的 Data 360 页面提供了性能度量的聚合视图，例如页面加载时间（体验页面时间或 EPT）和浏览器性能。
* **自定义报表和仪表板：**您可以使用 Data 360 对象和 Event Monitoring 数据构建自定义报表和仪表板，包括使用名为 Event Monitoring Plus 的免费 CRM Analytics 模板应用程序。这些可视化可帮助您发现趋势，并快速识别性能瓶颈。
但仅有技术是不够的。真正的弹性需要自动检测和人工审核之间有纪律的合作。自动警报可以显示实时异常，但微妙或长期的威胁，例如有效用户缓慢、未经授权的数据泄露，通常通过定期审计和趋势分析来最好地识别。
Salesforce 提供遥测、审计日志和集成挂钩；客户带来流程严谨、操作节奏和特定于上下文的智能。它们共同构成了一个**深入防御模型** — 将自动化、分析和人工监督结合起来,在威胁成为事件之前对其进行检测、调查和响应。
### 推动明智的决策：Salesforce Data 360 中的报表、仪表板、度量和通知
Salesforce Data 360 不仅仅是统一您的客户数据；它还使该数据具有智能性和可操作性。该价值主张的核心部分是提供强大的报表、强大的仪表板、见解深刻的度量和实时通知功能。这些工具使客户能够在熟悉的 Salesforce 环境中监控数据运行状况、跟踪性能并根据统一数据自动化操作。
#### 报表和仪表板：您的数据可视化中心
Salesforce 的本机报表和仪表板功能无缝扩展到 Data 360，允许您可视化和分析统一数据，而无需离开平台。
#### 基于统一数据构建报表
您可以对存储在 Data 360 中的数据创建标准和自定义报表，包括来自各种来源的统一数据和计算见解。
* **标准和自定义报表类型：**Data 360 引入了专为 Data 360 对象设计的新报表类型，例如数据流、细分、激活、身份解析和计算见解。这允许您使用标准 Salesforce 报表生成器查询统一数据。
* **粒度分析：**报表支持最多 10 行分组，允许对客户属性和趋势进行更精细的细分和详细分析。
* **公式和汇总：**您可以使用行级和汇总公式来评估每个记录或记录组，帮助您在单个报表中跟踪详细的度量和高级聚合汇总。
#### 适用于整体视图的动态仪表板
仪表板直观显示 Data 360 实施中的关键度量和趋势。
* **统一视图：**将多个 Data 360 报表中的数据组合在一起，甚至将 Data 360 报表与标准 CRM 报表混合在一起，以获得运营和客户见解的整体视图。
* **可自定义小部件：**使用各种图表类型（条形图、线形图、饼图、标准图等）和表格，以有效显示报表数据。
* **实时见解：**仪表板可以刷新以提供最新信息，帮助快速做出数据驱动的决策。
#### 度量和 KPI：衡量成功
Data 360 使您能够定义和跟踪与业务目标相关的关键绩效指标 (KPI)。这些可以通过以下方式生成：
* **计算见解：**使用高用量批量处理的数据创建强大的度量。例如，计算“平均客户终身价值”或“有效合同总收入”等度量，并将其用作报表和仪表板中的维度或评测。
* **流见解：**近乎实时地处理来自流源的数据，以构建时间序列聚合，例如网站或移动参与数据。这些度量可以推动即时编排和数据操作。
#### 通知和提醒：保持知情和主动
Salesforce 提供强大的自动化和通知功能，以确保您了解 Data 360 中的关键事件或数据更改。
* **基于流的通知：**您可以设置进程流，以根据数据流、细分和激活等 Data 360 对象中的事件触发操作并发送通知。
* **自定义提醒：**创建自定义通知，触发电子邮件或在满足特定条件时显示在 Salesforce 通知铃声中。例如，如果数据流失败、身份解析规则遇到错误或关键度量超过特定阈值，您会收到警报。
* **事件通知服务 (ENS)：**对于开发人员，API 优先的事件通知服务允许外部系统在特定事件发生时接收通知，从而在您的技术堆栈中实现无缝集成和实时反应。
* **数据操作：**根据流见解，您可以触发数据操作，这些操作可以配置为发送警报、调用平台事件或通过 Webhook 与其他 SaaS 应用程序集成。
通过利用这些全面功能，Salesforce Data 360 客户可以有效监控他们的数据生态系统，可视化关键度量，并及时收到警报，以推动主动参与和卓越运营。
### 企业采用的战略建议
在企业级采用 Salesforce Data 360 需要的不仅仅是技术支持，还需要深思熟虑的安全第一架构。以下战略建议为 CTO 和企业架构师提供了在 Data 360 部署的每一层建立Trust、弹性和合规性的路线图。
* **实施“按设计安全”方法：**安全不应被改造——它应该是基本的。从 Salesforce 的默认 *“拒绝所有”*策略开始，并根据需要明确授予访问权限。在接收或激活数据之前，定义治理、策略和访问框架。从第一天开始构建安全性可以消除隐藏暴露的风险，并简化长期合规性。
* **实施强大的身份和访问权限管理 (IAM) 策略：**通过聚合 SSO 集中身份，并实施多重身份验证 (MFA)，以缓解凭据泄露。按登录 IP 范围限制访问，并使用 Salesforce 的身份提供商 (IdP) 功能在用户和集成之间建立端到端的责任。统一的 IAM 层降低了操作复杂性，并强化了身份验证表面。
* **应用最小权限原则：**设计角色是为了精确，而不是方便。使用 Salesforce 的标准权限集作为职责分离的基础，确保用户只访问必要的内容。避免权限的过度自定义 — 每个偏差都会增加维护开销和意外访问的风险。
* **建立多层数据治理框架：**使用数据空间按业务部门或品牌隔离数据，并使用对象级、字段级和记录级安全性（OLS、FLS、RLS）实施基于属性的访问控制 (ABAC)。使用动态数据屏蔽实时保护敏感信息，而不妨碍分析或可用性。这种分层模型确保了治理在数据跨域扩展时保持一致。
* **战略性地利用加密和安全集成：**对于敏感工作负载，使用客户管理密钥 (CMK) 部署平台加密，以维护加密生命周期的主权。使用命名凭据和专用连接来保护所有系统到系统的集成 — 消除硬编码密码，并确保所有流量保持专用、合规和可审计。
* **构建持续安全操作计划：**安全不仅仅止于配置，它还取决于运营纪律。通过对事件日志和访问跟踪的定期审计审查来补充自动监控。建立专门的安全操作 (SecOps) 功能，以识别异常、调查威胁并验证合规性。目标：及早发现，快速响应，并持续改善姿势。
### 前进路径：构建具有弹性的可信数据 360
通向安全和智能企业的旅程不会因为部署而结束 — 它通过纪律、设计和 Trust 而发展。Salesforce Data 360 提供了架构基础，但当组织将安全、治理和智能作为一个统一的运动来操作时，真正的价值就会显现出来。
企业不应将 Data 360 视为另一个数据平台，而应将其视为一个安全的、可组合的Trust层，在一个治理框架下连接数据、AI 和客户参与。通过采用*安全设计*理念、在每个层强制实施最小权限并将专用连接扩展到所有数据流,组织将合规性从复选框转化为竞争优势。
下一步是持续现代化 — 将审计自动化、策略实施和加密生命周期管理嵌入日常运营。随着企业向 AI 驱动的代理架构发展，今天保护数据的相同原则将成为明天 AI 治理的支柱 — 确保每个模型、代理和决策在设计上都是可解释、策略感知和合规的。
最终,Trust 成为数字转型的新货币。借助 Salesforce Data 360，企业可以自信地扩展其数据生态系统，因为企业知道每个字节、每个连接和每个见解都是安全、受管和完整激活的。
## 关于作者
**Krishna Chalamasandra** 是一位经验丰富的网络安全专家,在信息安全技术和合规方面拥有 25 年以上的经验。在 Salesforce 中,他是客户值得信赖的顾问，也是 CISO 组织内部安全与合规 Customer Trust 职能的主要领导。此前,Krishna 在思科工作了 10 年,领导了 IAM、网络安全和 PKI 的安全架构,并推动了包括 ISO 27001、SOC 1-3、PCI、FedRAMP 和 FIPS 140-2 在内的密钥认证。他还在 Novell 工作了 8 年多，为受监管的全球客户实施基础设施级控制并支持复杂的安全审查。
**Yugandhar Bora** 是 Salesforce 的软件工程架构师,专门从事数据和智能应用程序平台中的数据架构。他领导企业架构审查委员会 (EARB) 专注于数据治理和统一数据模型的举措，同时为自动化平台配置解决方案做出贡献。
## 概览
企业处理各种文档类型，包括发票、采购订单、法律合同和技术手册。手动处理速度缓慢，容易出错，并消耗大约 15-25% 的员工时间。早期的自动化方法(例如,_机器人流程自动化 (RPA )_ 、 _光学字符识别 (OCR)_ 和工作流工具)减轻了一些负担,但产生了僵硬的漏斗、高昂的维护开销和单个业务团队之间的相互孤立采用。
文档包含纯文本处理无法保留的丰富结构上下文（例如，表格层次结构、空间字段关系和交叉引用部分）。将文档剥离为纯文本会丢弃使提取准确有用的业务上下文，这会降低下游分析、_人工智能 (AI)_ 推理和流程自动化的质量。
为有效起见,_智能文档处理 (IDP)_ 系统必须按类型对文档进行分类,从变量布局中准确提取结构化数据,并以受管、可查询的形式向下游系统提供这些数据。境内流离失所者还必须大规模处理文档的可变性,而不需要每种新文档格式的每个模板配置,而且它们必须集中起来并在各业务部门之间访问。这一挑战因关键问题的数量而变得更加复杂:非结构化数据约占所有企业数据的 80%,其中大部分以文档形式累积在_客户关系管理 (CRM)_ 系统、AI 客服人员和分析平台之外的文件系统、云存储和内容存储库中。
_Data 360 文档 AI_ 是 _Data 360_ 中的 Salesforce 文档处理功能，旨在解决这一差距。它使用_大语言模型 (LLM)_、_光学字符识别 (OCR)_、_自然语言处理 (NLP)_ 和_机器学习 (ML)_ 来提取、分类和分析非结构化和半结构化文档内容。输出是结构化、受管和可查询的数据,集成到_Data 360_漏斗中,_Agentforce_代理、分析工具和自动化工作流可以通过标准界面访问它,而无需自定义提取或转换层。
## 文档 AI 为何如此重要？
企业数据平台处理结构化的列表式数据。但是，大多数企业数据都是以文档的形式到达的，CRM、ERP、AI 客服人员和分析漏斗仍然无法访问，直到有人手动提取它。这是架构差距，不是工作流问题。
### 基于规则的提取的限制
早期的方法结合了手动重新密钥、基于规则的 OCR 和 RPA 脚本。这些方法在小范围内有效，但它们无法处理现代企业生成的文档类型的数量、种类和速度。基于规则的工具需要每个布局变体的明确模板。任何格式更改都会中断提取，并需要开发人员、新模板和部署周期。
大规模而言，这会产生脆弱的点解决方案，没有集中治理、共享模式和实现 AI 就绪的路径。不一致的提取漏斗会向下游传播。换句话说,分析会继承数据不一致、AI 模型产生不可靠的输出以及_个人健康信息 (PHI)_ 和_个人身份信息 (PII)_ 等受监管内容缺乏系统的治理。
### AI 本地文档处理
LLM 提取没有显式模板的字段。单个模式配置控制跨布局变体、语言和格式的提取，这会适应文档，而不是要求文档符合固定结构。这将文档处理从维护繁重的孤立操作转移到了受管的集中功能。
_Data 360 文档 AI_ 通过两个漏斗在 _Data 360_ 平台中操作文档处理。
- _批处理漏斗_通过接收、身份解析、计算见解、激活、分析和 Agentforce 激活来路由提取的数据。
- _事务处理漏斗_公开了同步返回结构化 _JSON_ 的 REST API，这允许架构师将文档派生的数据路由到 Salesforce _SObjects_、_Data 360 Data Lake 对象_/_数据模型对象 (DLO/DMO)_ 漏斗或外部数据库和仓库，而无需批量设置开销。
在这两种情况下，提取的数据会进入受管的、模式驱动的模型，而不是分散的点工具集。
## 产品范围
[Data 360 文档 AI](https://help.salesforce.com/s/articleView?id=data.c360_a_document_ai.htm&type=5) 是 _Data 360_ 平台中的 Salesforce 本地_智能文档处理 (IDP)_ 功能。它将非结构化和半结构化文档内容转换为可完全参与整个 _Data 360_ 生命周期的受管、可查询的数据。
## 什么是 Data 360 文档 AI？
[Data 360 文档 AI](https://help.salesforce.com/s/articleView?id=data.c360_a_document_ai.htm&type=5) 是 _Data 360_ 中的 Salesforce 本地_智能文档处理 (IDP)_ 功能。它接收非结构化和半结构化文档,使用声明性模式配置提取结构化数据,并将该数据传递到_Data 360_漏斗,进行协调、身份解析、分析和 Agentforce 激活。
Data 360 文档 AI 支持两种处理模式：
- **批量处理：**在事件驱动的基础上处理在_非结构化数据_模型对象 (UDMO) 中定义的大型文档集。
- **事务处理：**通过 REST API 处理单个文档，并同步返回结构化 _JSON_ 负载。然后，架构师可以通过 _MuleSoft_、_Apex_ 标注或 _Einstein Trust Layer (ETL)_ 漏斗将该有效载荷路由到 _Data 360 DLO/DMO_ 漏斗、Salesforce _SObjects_ 或外部数据库和仓库。目标层是由延迟、治理和数据驻留要求驱动的架构决策。
文档 AI 目前支持 PDF 文件、图像文件（JPEG、PNG）和手写文档。
## 核心组件
_Data 360 文档 AI_ 将四种处理技术整合到一个受管漏斗中。每个组件处理文档到数据生命周期的不同阶段：
- **光学字符识别 (OCR)：**在 LLM 处理之前，将扫描图像、手写内容和基于图像的 PDF 转换为机器可读的文本。建议至少 150 DPI 才能可靠地提取。
- **大型语言模型 (LLM)：**使用用户选择的模型，通过 _Einstein_ LLM 网关路由提取。LLM 与 _JSON_ 模式配置一起接收 OCR 输出，并返回结构化提取负载。正在计划未来实施_双子座_和其他型号。
- **自然语言处理 (NLP)：**通过结构化提示工程，直接在 LLM 中执行上下文理解、实体识别、日期解析和语义字段提取 — 模式定义的提示和 OCR 输出作为唯一的输入。所有 LLM 交互都通过 ETL 路由，ETL 对模型提供商实施零数据保留，并在到达模型之前屏蔽基于文本的输入中的 _PII_。不使用单独的 NLP 发动机。
- **多模式处理：**将 PDF 中的嵌入图像作为单独的提取输入进行处理，这允许 LLM 从图表、图像渲染表和混合内容页面中提取数据，而 OCR 无法单独解析这些数据。
除了四种处理技术之外,_文档 AI_ 还处理：
- **Einstein Trust 层：**通过 ETL 路由所有 LLM 交互，ETL 对模型提供商实施零数据保留，并在输入到达 LLM 之前屏蔽 _PII_，但多模态数据（例如，通过_文档 AI_ 处理的附加文档）除外，目前不支持 PII 屏蔽，数据按原样发送到外部模型。ETL 仅控制 LLM 交互路径。写入_数据湖对象 (DLO)_ 的提取数据按原样存储;静态字段级屏蔽必须通过下游数据治理控制来解决。
- **文件大小限制：**_文档 AI_ 处理每个请求最多 10 MB 的文件。LLM 上下文长度限制可能会进一步限制在此边界内处理密集的多页文档。
## 关键架构原则
部署 _Data 360 文档 AI_ 的企业架构师应在承诺实施设计之前应用这些原则。
- **在设计模式之前，选择漏斗。**_批处理_和_事务_处理漏斗在接收模型、模式绑定、目标灵活性和延迟方面有所不同。在定义模式之前，确认每个用例需要哪个漏斗非常重要，因为改造增加了可以避免的返工。
- **在文档类型级别设计模式。**与使用每个用例配置相比，为每个文档类型使用单个精心制作的模式更具可维护性，并且也是提取质量的最大杠杆。正确执行此操作需要使用一组不同的文档（包括边缘个案），而不是从单个示例进行设计。在_字段_、_表格_和_模式_级别迭代使用提示来查找差距，然后在最终确定之前根据多个文档样本测试和改进它们。请记住，在一个文档上运行良好的模式可能不如其他文档，因此广度和迭代至关重要。模式灵活性（包括删除不能跨文档类型可靠地提取的列）同样重要。保留引入噪声或不一致性的字段会破坏整体提取质量，因此将列移除视为一流的设计决策非常重要。
- **为每个字段组选择正确的目标层。**推动 CRM 工作流或批准的字段会写入 _SObject_。正在丰富统一简档或摘要分析的字段属于 _DLO/DMO_ 漏斗。为外部系统提供服务的字段属于 _RDBMS_ 层。请谨记，单个模式可能会同时扇出到多个层。
- **在处理受管内容之前，强制执行治理。**监管数据需要在每个层进行保护。这就是为什么在提取的数据存储在输出_数据湖对象 (DLO)_ 后，配置 _PII_ 掩码、数据分类标记和基于属性的访问控制 (ABAC) 非常重要_。_这提供了基于数据分类、用户角色和组织上下文的微调的实施和上下文感知访问。_治理_分为两条路径:_ELT_ 治理 LLM 交互,而存储在 DLO 中的提取数据必须通过_数据空间_配置、_权限集_和 _ABAC_ 策略直接在 DLO 和数据库级别单独治理。这些控制必须在存储层（而不仅仅是应用程序层）保持一致性，因此无论接收后如何访问数据，访问限制都保持不变。请谨记，即使其他层配置正确，任何层中的间隙都可能向下游暴露受管数据。
- **在生产前设计失败模式。**在第一个生产批处理运行之前，解决空字段处理、OCR 质量阈值、文件大小预验证、LLM 上下文溢出、RDBMS 写入幂等和信用预算限制。这些不是边缘个案，而是可预测的故障表面，必须在漏斗设计中明确处理，而不是在运行时发现。
- **将置信度分数视为一流的路由信号，而不是事后诊断。**提取结果携带字段级置信值，该置信值从基础模型输出的对数概率 (logprob) 中派生。对于每个提取的字段、表格或列，分数反映了模型对提取值的令牌级确定性。这使得置信度分数成为基于统计的信号，足够可靠，可以作为 _HitL_ 升级阈值的主门。使用置信度分数来系统地识别低质量提取，并针对低置信度字段值、模糊的模式匹配或重复的漏斗失败启动 HITL 检查点，而不是依赖启发式或手动抽查。当自动恢复不可能时，HITL 支持的置信度评分确保人的判断被准确地应用于需要的地方。
- **与模式设计并行设计激活路径。**_文档 AI_ 的价值来自能够在 Salesforce 工作流和客服人员中激活提取的数据。它允许您设计 Agentforce _行动_、_流_和_计算见解_，与提取模式设计同时进行，而不是在之后。
## 架构：Data 360 文档 AI 漏斗
_文档 AI_ 在两个漏斗中操作：
- 用于高用量、UDMO 备份处理的_批处理_漏斗
- 用于实时 API 驱动提取的_事务__处理_漏斗
两个漏斗共享相同的模式配置合同和 ETL 治理，但它们在文档进入系统的方式以及提取的数据到达的位置方面有所不同。
让我们仔细看看每个漏斗。
### 批处理漏斗
_批处理_漏斗处理由 UDMO 定义的重复文档集。它适用于计划或事件驱动的用例,其中文档从企业存储中摄取,然后经过文档提取,并交付给_Data 360 DLO/DMO_漏斗进行协调、身份解析和激活。
**真实场景**
每天,保险公司都会收到来自提供商入口网站的数千份医疗索赔文档,这些文档以 PDF 格式上传到 _Amazon S3_。UDMO 定义范围内文档集，并在 24 小时内将所有索赔 PDF 发送到`/claims/incoming/`存储桶。
#### 阶段 1：摄取
文档从企业源系统接收到 _Data 360_ 中，没有物理重复。支持的来源包括 _Amazon S3_、_Google Cloud Storage_、Salesforce CRM 文件对象、_MuleSoft 协调的_漏斗和直接 API 上传。在 _无头 360_ 部署中，文档通过云存储连接器或绕过 CRM 层的_接收 API_ 接收。_模型上下文协议 (MCP)_ 服务器将摄取公开为外部 AI 客服人员和 LLM 客户端的可调用工具。
接收后，原始文档会存储为_非结构化数据_湖对象 (UDLO ) , 这些对象会映射到每个文档的物理位置和元数据，而无需移动或转换源文件。
**示例：**
索赔 PDF 通过云存储连接器从 _S3_ 接收到 _Data 360_ 中。每个文档存储为指向 _S3_ 对象的 UDLO。不会出现物理重复。
#### 阶段 2：提取
_文档 AI_ 根据模式配置处理每个 UDLO，该模式配置定义了要提取的字段及其目标数据类型。UDMO 定义了哪些文档在范围内。LLM（_GPT-4o_、_Gemini_ 或 _Claude_）读取每个文档并返回结构化提取负载。
**示例：**
_文档 AI_ 根据定义字段的索赔模式处理每个 UDLO，例如：ClaimID、PatientName、DiagnosticCode、BillingAmount 和 ServiceDate。然后，LLM 读取每个 PDF，并返回结构化提取负载。
#### 阶段 3：保留
在提取数据后，它会保留在 DLO 中，即 _Data 360_ 的原始存储层。DLO 保留提取的字段，而不强加业务逻辑，这为下游转换和可追溯性保留了准确的物理表示。UDLO 保留对源文档的引用，以在漏斗中的任何一点启用字段级谱系。
**示例：**
所有提取的字段都位于_索赔 DLO_ 中，该 DLO 保留了每个索赔的原始、准确的表示，具有可追溯到源 PDF 的完整谱系。
#### 阶段 4：协调
DLO 字段映射到与标准 _Customer 360 数据模型_一致的 DMO。这是文档派生数据从原始提取字段转换到具有业务意义的实体的边界。_发票 DLO_ 映射到_发票 DMO_，_CustomerID_ 和 _BillingAmount_ 等字段成为连接密钥，并匹配统一数据模型中的属性。统一的文档数据通过 CRM 和事务数据使用的相同界面参与细分、_计算见解_和激活。
**示例：**
_索赔 DLO_ 映射到_索赔 DMO_。PatientID 和 PolicyNumber 字段成为将索赔记录链接到统一患者简档的连接密钥。
#### 阶段 5：统一
统一的 DMO 数据参与身份解析。提取的字段(例如客户名称、电子邮件地址或客户编号)作为匹配密钥，将文档记录链接到_统一个人 (Gold Records)_，从而缩小了文档与简档之间的差距。
**示例：**
提取字段(例如 PatientName、DateOfBirth 和 PolicyNumber)作为身份解析的匹配密钥，将索赔记录链接到正确的_统一个人_。即使同一患者在文档中出现的名称拼写略有不同，也会发生这种情况。
#### 阶段 6：派生见解
架构师定义_计算见解_，这是跨统一文档数据（例如，各种发票行项目的总支出、合同续订风险分数和索赔严重性指数）计算的汇总度量。
**示例：**
_计算见解_计算 Agentforce 查询的统一索赔数据中的 TotalClaimsPerPatient、AverageClaimAmount 和 HighRiskClaimScore。
#### 阶段 7：行动
Agentforce 客服人员、_Tableau_、市场营销平台和 Salesforce _SObject_ 都可以访问统一的身份解析数据。目标层是受延迟、治理和数据驻留要求驱动的架构决策。
**示例：**
_索赔裁定 Agentforce 代理_向 _Data 360_ DMO 和 CI 查询，以查找优先审查的高风险索赔。_Tableau_ 仪表板显示索赔量和异常趋势。批准的索赔记录循环回_索赔 SObject_，以启动付款工作流。
在 _无头 360_ 架构中，激活通过_查询 API_、_发布/订阅 API_ 或云数据仓库激活目标直接路由到外部系统。然后，MCP 服务器找到统一的文档数据和_计算见解_作为外部 AI 客服人员的可调用工具。
### 事务处理漏斗
_事务处理_漏斗在运行时处理单文档提取，没有 UDMO 或预摄取的 UDLO，这适合事件驱动的用例（例如，客户上传表格、客服人员收到 PDF 或在事务处理工作流中启动提取的外部系统）。ETL 治理同样适用于两个漏斗。
**真实场景**
在申请贷款时，银行客户通过银行的移动应用程序上传水电费账单的 PDF。该事件会实时启动提取，这意味着不涉及预先摄取的 UDLO 或 UDMO。
#### 阶段 1：定义模式配置
在调用 API 之前，架构师必须在 _Data 360_ 中定义和存储模式，该模式以 _JSON 模式_格式指定字段、数据类型和提取指令。每个模式被分配一个唯一的_模式 ID_。在运行时，调用应用程序引用模式 ID，以将提取逻辑集中在 _Data 360_ 中，而不是将其嵌入应用程序代码。
**示例：**
该银行的团队在 _Data 360_ 中有一个预定义的`ProofOfAddress`模式，它指定了`CustomerName`、`AddressLine1`、`City`、`PostCode` 和 `DocumentDate` 等字段。此信息存储为可由_模式 ID_ 引用的版本化配置。
#### 阶段 2：提交文档
调用应用程序在单个 REST API 请求中提交文档和方案 ID 作为 base64 编码的有效负载或文件引用。不需要 UDLO 摄取。_文档 AI_ 应用文档提取，并根据提供的模式返回结构化输出。
**示例：**
移动应用程序在单个 REST API 调用中将水电费作为 base64 编码的有效负载与`ProofOfAddress`模式 ID 一起提交。此过程不需要 UDLO 摄取步骤。
#### 阶段 3：提取
LLM 根据模式处理 OCR 输出，并同步返回结构化 JSON 负载。在文档中找不到的字段将返回为 _null_。呼叫者拥有完整的 JSON 响应，并继续路由。
**示例：**
_文档 AI_ 将 OCR 应用于 PDF，LLM 返回带有提取的地址字段的结构化 JSON 负载。未找到的字段（例如，如果账单中缺少`PostCode`）将返回为 _null_。
#### 阶段 4：路由到目标（可选）
提取后，JSON 负载可以路由到一个或多个目标层，这取决于用例：
- **Salesforce SObject：**通过 _Apex_ 或 CRM 工作流和批准的 _Flow_ 直接映射到 _SObject_ 字段。
- **Data 360 DLO/DMO 漏斗：**路由到 DLO 进行协调、身份解析、_计算见解_和 Agentforce 基础训练。
- **外部 RDBMS 或数据仓库：**通过 _MuleSoft_、_Apex_ 标注、_平台事件_或 ETL 为 Salesforce 外部的系统路由。
- **自定义集成：**将结构化 JSON 负载返回到调用应用程序，以存储在任何外部系统或数据存储中。
- **下游流或客服人员：**将结构化的 JSON 输出直接传递给下游流或客服人员，而无需任何持久化到 _SObject_ 中。对于在更大的自动化或客服人员工作流中使用_文档 AI_ 作为实时提取步骤的客户，这是常见的模式。
请谨记，单个模式可能同时扇出到多个层，不同的字段组从同一个提取点路由到不同的目标。
**示例：**
`ProofOfAddress` 负载可能一次扇出到三层(例如,`CustomerName` 和 `AddressLine1` 写入_联系人 SObject_ ) , 从而启动地址验证_流_。然后,完整的有效载荷路由到DLO进行协调和风险评分,副本路由到银行的KYC系统,通过_MuleSoft_进行监管合规记录。
#### 阶段 5：行动
一旦写入，提取的数据会立即在目标系统中激活。对于 _SObject_ 目标，触发器、流和审批流程会在更新插入的记录中激活。对于_DLO/DMO_目标,数据进入_协调和身份解析_漏斗和Agentforce上下文。对于外部 _RDBMS_ 目标，写入完成后，下游查询即可获得数据。
**示例：**
_地址验证流_会在更新插入的_联系_人记录中立即激活，这将推动贷款申请进入下一阶段。Agentforce _贷款官员 Agent_从 _Data 360_ 中找到经过核实的地址，KYC 系统记录提交的文件以供审计。
## 您应在何时使用文档 AI？
_文档 AI_ 最适合特定的架构条件。在这些条件之外应用它会产生不必要的复杂性和额外的成本。
作为架构师，在承诺将 _Document AI_ 作为提取机制之前，评估这些标准非常重要。
**在以下情况下使用文档 AI：**
- **文档是主要数据源。**所需信息仅以文档形式存在，并且无法从结构化 API 或数据库中获得（例如，扫描的合同、实验室报表、接收表单或保险索赔）。
- **文档布局因来源而异。**相同文档类型来自多个供应商、合作伙伴或区域，字段位置和格式不同。模式驱动的 LLM 提取适应，无需每个布局维护。
- **提取的数据必须提供给 Data 360 或 Agentforce。**提取必须参与身份解析、_计算见解_或 Agentforce 基础训练。_文档 AI_ 直接传递到 _DLO/DMO_ 漏斗中，没有单独的 ETL 层。
- **数量证明了受控自动化的合理性。**文档量超出了手动处理所能处理的范围，而没有可衡量的人工成本或数据质量风险。
- **文档包含监管内容。**_PHI_、_PII_ 或财务数据必须在到达 LLM 之前通过零数据保留、PII 屏蔽层进行路由。ETL 会本地满足这一点。对于不需要在任何时间点保留提取内容的客户，也应考虑_事务 API_ 流，该流直接向调用应用程序返回结构化输出，而无需写入任何 _SObject_ 或数据存储。
- **用例由事件驱动。**文档在运行时到达（例如，客户上传、客服人员 PDF 附件或外部系统触发器）。_事务处理_漏斗处理同步的单文档提取，无需批量设置。
**在以下情况下，请勿使用文档 AI：**
- **源数据已结构化。**如果上游系统公开 REST API、数据库表或结构化文件（例如 CSV、JSON 或 XML），请使用标准 _Data 360_ 连接器。通过 LLM 提取漏斗运行结构化数据会增加延迟和信用成本，而不会带来额外的好处。
- **文档使用固定模式由机器生成。**系统从具有稳定布局的已知 ERP 或计费平台生成的 PDF 更适合确定性解析器。LLM 提取专为可变性而设计，并将其应用于固定模式文档浪费上下文和信用。
- **精度要求超过 LLM 置信度阈值。**_文档 AI_ 不能保证 100% 的提取准确性。缺少或不正确的字段值具有重大财务、法律或临床风险的用例需要 HITL 验证步骤。在没有验证工作流的情况下，不要将 _Document AI_ 用作高风险决策的唯一提取层。
- **文档超出平台约束。**当前的 10MB 文件大小限制和 LLM 上下文长度约束使得 _Document AI_ 不适合大型或密集文档，而无需预处理来在平台外拆分和重新组合它们。
- **注意：**在 Salesforce，我们正在积极改进这些验收防护栏，以扩展支持的文件大小、页面计数和文件扩展名。制约因素将继续向前发展。
## 用例：查看实践中的模式
### 批处理漏斗用例
让我们仔细看看几个使用 UDMO 源对象支持的_文档 AI 批处理_漏斗的场景。在这些情况下,提取的数据通过_Data 360 DLO/DMO_漏斗路由,用于协调、身份解析、_计算见解_和 Agentforce 激活。每个用例最适合计划或事件驱动的高用量文档处理。
**Agentforce Sales：合同和发票智能**
_合同_ PDF 通过_批处理_漏斗从云存储中摄取。该模式提取 ContractValue、Re RenewalDate、PaymentTerms 和 CounterpartyName，然后将其映射到_客户_和_合同_ DMO。_计算见解_会导出续订风险分数。Agentforce 会在续订时段关闭前提醒客户主管，这消除了手动合同审核和错过的续订。
**Agentforce 服务：个案转移和 Knowledge 基础训练**
_调查_ PDF 和个案附件通过_批量_漏斗接收。模式提取情绪指标、问题类别和解决说明，然后将其映射到_个案_和_Knowledge 文章_ DMO。Agentforce 会在个案打开时查询协调 Knowledge 库，并找到相关的故障排除步骤，这可以减少客服人员的搜索开销。
**Agentforce Health:临床文档处理**
实验室报告、接收 PDF 和手写临床表格通过_批量_漏斗接收。该模式提取字段 -- -- 包括_患者 ID_、_诊断代码_、_药物名称_和_测试结果_ -- -- 然后将其映射到_Health Cloud_ DMO，该模式支持符合HIPAA的护理协调和临床研究工作流。
**金融服务：贷款和税务文档自动化**
通过批量漏斗接收的贷款申请、纳税申报和损益表。该模式提取字段，包括 AnnualIncome、TaxYear 和 EmployerName，然后将其映射到_财务客户_ DMO。_计算见解_将文档派生的收入数据和 CRM 数据结合起来，以促进自动化信用风险评分。Agentforce 会在客户服务交互期间内联查找提取的贷款详细信息。此模式直接支持在 Salesforce _Agent Enterprise Solutions_ 开发人员中心发布的[贷款资格预审客服人员](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions)用例。
**HR:劳动力文档处理**
入职文档、税务表格和认证 PDF 通过_批量_漏斗接收。提取的字段映射到_员工记录_ DMO，然后链接到_统一员工_简档。特定_流_根据提取的数据启动入职任务和合规检查。此模式直接支持[自动恢复处理](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions)客服人员用例。_文档 AI_ 从简历 PDF 中提取技能、就业历史和资格,Agentforce 然后将其用于根据开放角色标准匹配候选人,并将其路由到招聘工作流。
**专业服务：建议和研究智能**
建议书版面和研究报告通过_批量_漏斗接收。提取的框架、基准和参与汇总映射到自定义 DMO，然后为向量搜索建立索引。Agentforce 在查询时检索上下文相关的推荐，这些推荐基于提取的文档内容。这种模式扩展了[Ground Agentforce on Website Content](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions) 模式。文档通过 _Document AI_ 进行索引，客服人员响应的基础功能与通过 _Data 360_ 连接器进行索引的网站内容相同。
**HIPAA 合规状态：**
本文描述的_Health Cloud_模式将ETL控制(例如,零数据保留和PHI屏蔽)应用于文本输入。这些控制措施本身并不构成 HIPAA 认证。在承诺在这些上下文中使用基于_文档 AI_ 的架构之前，专为受监管临床环境设计的架构师必须向 Salesforce 合规团队确认当前的 HIPAA 认证状态。
### 事务处理漏斗用例
让我们仔细看看几个场景，它们使用不绑定到 UDMO 的模式调用_文档 AI_ REST API。提取的 JSON 负载在运行时直接同步路由到外部系统。
**供应链：供应商发票处理到 ERP**
当_供应商发票_ PDF 到达受监控的存储桶或电子邮件网关时，事件触发器会调用带有发票和预定义模式 ID 的_文档 AI_ REST API。该模式提取 VendorID、InvoiceNumber、LineItems、TotalAmount、TaxAmount 和 DueDate。JSON 负载通过 _MuleSoft_ 路由到具有_空_字段验证和幂等更新插入逻辑的 _ERP 应付款_模块，这消除了供应商格式可变性的模板维护。
**法律操作：合同审查到 CLM**
当_合同_ PDF 上传到法律入口网站时，后端会同步调用_文档 AI_ REST API。该模式提取 GoverningLaw、IndemnityCapAmount、TerminationNoticePeriod、AutoRenewalClause 和 CounterpartySignatory。JSON有效载荷通过_Apex_标注路由到_合同生命周期管理_系统。任何未找到的字段都将返回为 _null_，CLM 会将默认义务规则应用于缺失值。
**保险索赔：第一份损失处理通知**
当保单持有人提交_第一份损失通知 (FNOL)_ 表单时，后端入口网站会同步调用 _Document AI_ REST API。该模式提取 PolicyNumber、EventDate、EventLocation、DamageDescription、Sc claimerName 和 ContactPhone。JSON 有效载荷通过 _Apex_ 标注或 ETL 路由到_索赔管理数据_库，这将创建一个预先填充的索赔记录，供理算员在正式索赔开始之前审查。
## 设计注意事项和失败模式
在进入生产之前，您必须为这些失败场景创建设计。
- **空字段处理：**LLM 对于它无法找到或无法自信地提取的字段返回 _null_。在写入任何具有 _NOT NULL_ 约束或必需匹配密钥的目标之前，请在方案设计时验证空处理逻辑，并在集成层中实施默认值或拒绝逻辑。
- **OCR 质量降级：**OCR 精度在低于 150 DPI、手写不规则或扫描有噪音时下降。错误读取会作为没有错误信号的损坏输入传播到 LLM 提取中。在摄取时强制实施最低扫描质量，并对数字和日期字段实施置信度阈值检查。
- **模式版本不匹配：**在计划批处理作业后更新模式配置会使正在处理的文档与以前的版本进行比较，以前的版本会产生丢失或重命名的字段，从而破坏下游映射。明确版本模式，并将更新与批处理作业计划协调。
- **文件大小限制：**超过 10MB 的文档将被拒绝。在没有配置监控的情况下，批处理漏斗失败是静默的，事务调用者会收到 _4xx_ 错误。在摄取时预验证文件大小并实施预处理，以拆分或压缩经常接近限制的文档。
- **LLM 上下文溢出：**密集或多页文档可能会超出 LLM 上下文窗口的 10MB 限制。LLM 会静默删除超出上下文的内容。实施分块策略，按页面范围拆分文档，并在将它们转移到目标之前重新组合提取的字段。
- **影响提取的信任层掩码:**ETL 在提示级别操作，而不是文档级别，因此屏蔽不适用于通过_文档 AI_ 的文档内容。依赖于文档中 _PII_ 值的模式字段不受 ETL 屏蔽策略的影响。
- **外部 RDBMS 写入幂性：**_事务处理_漏斗没有外部 _RDBMS_ 目标的内置幂等性。_集成层_重试会创建重复行，除非写入逻辑明确处理重复数据消除。在所有外部写入路径上使用文档指纹或外部 ID 实施幂等更新插入。
- **贷项用完中期：**大批量运行可能会在处理所有文档之前耗尽 _Digital Wallet_ 信用，从而产生下游步骤视为完整的不完整的 DLO 数据集。将消耗警报设置为可用信用的 75% 和 90%，并将批次大小限制在每个周期的信用预算范围内。
- **模式字段限制 — 架构约束：**_文档 AI_ 对模式配置中的根级字段强制实施 50 个字段的限制。这是设计时间约束，而不是运行时错误，架构师必须在数据模型和方案设计期间考虑它。
- 对于需要更广泛提取的用例：
- 无情地确定优先级。将模式缩小到推动自动化价值的字段，而不是详尽无遗的文档覆盖范围。
- 利用嵌套对象（最多 3 个级别；仅限源对象的批处理模式）减少根级字段计数，而不牺牲提取深度。
- 跨多个针对不同文档部分的_文档 AI_ 配置分解复杂文档，并将结果写入在 _Data 360_ 中下游连接的单独 DLO。
- **API 速率限制：**_文档 AI_ 强制规定每个租户每分钟最多 50 次提取 API 调用。理论上限是每分钟 300 次呼叫,由 _Einstein LLM 网关_控制。高用量事务集成的设计必须具有指数回退、请求排队和租户级吞吐量预算。不要假设突发容量在多租户生产环境中可用。
- **API 延迟简档：**_文档 AI_ 提取 API 完全同步。典型的响应时间为 5-15 秒，并且因文件大小和模式复杂性而异。
- 这直接影响到集成架构：
- 将呼叫方超时设置为最少 30 秒。
- 不要在具有次秒级 SLA 要求的流中调用_文档 AI_。
- 根据_批处理_漏斗的速率限制上限，将延迟计入吞吐量计算。
- **加密和密码保护的文档：**_文档 AI_ 不处理受密码保护的文件(打开文件需要用户密码)或使用所有者/权限密码加密的 PDF，包括正常打开但在 _PDF 权限_层限制复制、打印或编辑的文件。
- 此约束位于摄取边界：
- 设计_文档接收_漏斗，以在加密文件到达_文档 AI_ 之前检测并将其路由到_拒绝_或_手动处理_路径。
- 不要依赖运行时错误处理作为主门。
## 结构良好的定线
_Data 360 文档 AI_ 与 Salesforce _良好架构框架_的多个支柱保持一致。
- **Trust:**ETL 对 LLM 提供商实施零数据保留，在到达模型之前屏蔽 _PII_ 输入，并扫描输出中的敏感内容。架构师必须将这种态势扩展到静态提取的数据。DLO 中的字段级掩码不会被 ETL 应用，它需要下游_数据空间_策略和_权限集_。
- **可靠性：**“_设计注意事项_”部分中的每个失败模式 — 空字段提取、OCR 错误读取、模式版本不匹配、文件大小泄露、LLM 上下文溢出、ETL 屏蔽干扰、RDBMS 写入幂等和信用耗尽 — 都代表不同的失败类，并带有记录的检测信号和解析路径。
- **卓越运营(变更管理):**模式驱动的提取模型将提取逻辑与文档布局分离。当供应商更改发票格式或更新监管表单时，架构师只需要更新一个模式配置，而不是修改集成代码。
- **卓越运营(可维护性):**在 _Data 360_ 中集中模式配置，而不是在应用程序代码中嵌入提取逻辑，使提取意图明确、版本化和可审计。所有下游目标都使用相同的模式合同，无论其目标层如何。
- **卓越运营(集成重用):**_文档 AI_ 公开了跨多个集成表面的提取：REST API、_Apex_、_Flow_、_MuleSoft_、Agentforce _Actions_和MCP服务器。单个模式配置同时扇出到多个目标层，而无需重新构建每个使用者的提取能力。
- **资源和成本优化：**漏斗选择指导、10 MB 文件大小边界和预汇编 LLM 上下文长度约束代表性能感知的设计决策。“_何时使用”_部分正式确定了_文档 AI_ 不是正确工具时的条件（例如，亚秒级延迟要求、完全结构化的源数据和固定模式的机器生成的文档）。
## 架构师快速入门指南
这是在 Sandbox 环境中配置 _Data 360 文档 AI_ 的结构化起点。在转移到生产之前，完成 Sandbox 中的所有阶段。
### 开始之前
在开始配置之前，您必须确认：
- **文件大小：**验证代表性文档大小是否小于 10MB。
- **漏斗：**确认用例是否需要_批处理_漏斗（UDMO 支持的、高用量）或_事务处理_漏斗（API 驱动的、单文档）。这推动了所有后续配置。
- **目标层：**确认提取的数据位于何处 — Salesforce _SObject_、_Data 360_ DLO/DMO、外部 RDBMS 或组合。
- **Agentforce 依赖性：**在部署任何基于 Agentforce 的文档处理之前，请确认通过 ETL 设置在您的组织中启用了支持的 [LLM](https://help.salesforce.com/s/articleView?id=ai.generative_ai_large_language_model_support.htm&type=5)（例如，_GPT-4o_）。Agentforce 是_文档 AI_ 的硬平台先决条件。整个_文档 AI_ 功能表面 -- -- 包括所有提取 API -- -- 在 Agentforce 在目标组织中处于活动状态之前不可用。将此因素纳入组织就绪评估和配置顺序。请为 API 可用性留出几分钟时间，以稳定启用后的状态。
- **Agentforce 禁用影响：**如果在配置和部署_文档 AI_后禁用 Agentforce，将立即阻止所有提取处理(UI和API)。这同样适用于模型禁用。禁用基础模型对_文档 AI_ 可用性的影响相同。在这两种情况下，现有的模式配置都会保留下来并保持可见 — 不会发生配置或数据丢失 — 但在 Agentforce 和模型重新启用之前，该功能是完全不能操作的。设计操作手册，将 Agentforce 可用性和模型启用视为_文档 AI_ 健康依赖性。
- **信用消耗/定价：**对于从代表性示例文档中得出的 TCO 估计，使用 _Data 360_ 信用或 _Flex Credit_。
#### 阶段 1：模式和漏斗配置
- **创建模式配置。**在 _Data 360 文档 AI_ 设置中，以 _JSON 模式_格式定义提取字段、数据类型和指令。对于_批处理_漏斗，将其绑定到 UDMO。对于_事务处理_漏斗，在没有源对象的情况下创建它。记录模式 ID。
- **将字段名称与目标层对齐。**将字段名称与 DLO 列定义、_SObject_ API 名称或 RDBMS 列名称匹配。名称不一致会在集成层中产生映射开销。
- **配置 UDMO 源对象（仅限批处理）。**定义范围内的文档并配置摄取源连接性（例如，_S3_、_Google Cloud Storage_、_Salesforce Files_ 或 _MuleSoft）_。确认接收服务帐户具有所需的 _IAM_ 或 _OAuth_ 凭据范围。
- **应用 PII 屏蔽策略。**在处理任何受管内容之前，请在 ETL 设置中配置_数据屏蔽_策略。定义在输入到达 LLM 之前屏蔽哪些字段类型（_PHI_、_PII_ 和财务标识符）。**不要**推迟这一步。
- **分配数据空间范围和权限集。**将处理范围限定到适当的_数据空间_，并配置_权限集_，以控制模式创建、批处理作业执行、REST API 调用和下游激活。
- **配置 API 身份验证（仅限事务处理漏斗）。**使用 _OAuth_ 范围 cdp_ingest_api 和 api 创建_连接的应用程序_。对于组织内部调用者，使用链接到_外部凭据_的_命名凭据_。对于外部调用程序，配置 _OAuth 2.0_ 客户端凭据或 JWT 不记名流。在继续之前，测试并验证提取。
#### 第 2 阶段：集成和目标配置
- **SObject 写回：**实施 _Apex_ (@InvocableMethod) 或 _Flow_ 元素，将 JSON 响应字段映射到 _SObject_ 字段。将 Database.upsert() 与外部 ID 一起使用，以防止重复。对目标 _SObject_ 字段应用_字段级安全_性。
- **Data 360 DLO/DMO 漏斗：**将提取的 DLO 字段映射到符合 _Customer 360 数据模型_的 DMO。配置身份解析规则，将文档记录链接到_统一个人_。为 Agentforce 定义_计算见解_并添加 DMO。对于事务处理漏斗，请先通过_接收_ API 将 JSON 负载路由到 DLO。
- **外部 RDBMS 或数据仓库：**选择集成模式：_MuleSoft_(现有集成结构)、_Apex_ HTTP 标注(轻量级、组织本地)、具有_发布/订阅_者_的平台事件_(事件驱动)或 ETL(高用量批次)。在所有外部写入路径上使用文档指纹或外部 ID 实施幂等更新插入。
- **激活路径：**将 Agentforce 操作连接到模式配置，以进行交互式提取。为自动处理工作流配置_流_或 _Apex_ 触发器，并为每个字段组确定激活目标。
- **错误处理(仅限事务处理漏斗)。**配置完整的 HTTP 响应表面：**200**（_成功_，包括部分 _null_ 响应）、**400**（_错误请求_或_未找到模式 ID_）、**413**（文件超过 10MB）、**5xx**（服务错误）。对最多 3 次尝试的 _5xx_ 次重试实施指数回退。记录每个呼叫的原始 JSON 响应和方案 ID。
#### 阶段 3：验证并准备生产
- **根据示例文档测试模式。**通过 _Document AI_ 界面或 REST API 提交代表性示例。确认提取准确性、字段覆盖率和布局变体之间的空处理。
- **验证空字段处理。**请确认，所有下游目标都可以处理文档中_未找到字段_的_空_值。请记住，_NOT NULL_ 约束会在没有显式空处理的情况下静默失败。
- **预验证文件大小。**确认生产文档保持在 10MB 以下。实施预处理，拆分或压缩经常接近限制的文档。
- **验证端到端提取。**对于_批处理_漏斗，启动完整运行，并确认提取的字段正确到达每个目标层。对于_事务处理_漏斗，通过_集成_层跟踪 JSON 响应到目标。验证 _SObject_ 目标的触发器和流执行、_DLO/DMO_ 目标的身份解析链接以及 _RDBMS_ 目标的幂。
- **确认信任层行为。**ETL 不对文档内容应用 _PII_ 屏蔽，因此 LLM 将按原样返回提取字段中的 _PII_ 数据。请确认您的模式字段、数据路由和下游存储旨在适当地处理带有 PII 的输出，并确保在平台之外满足任何合规或保留要求。
- **设置 Digital Wallet 警报。**以可用信用的 75% 和 90% 配置消耗提醒。在每个周期的信用预算中，建立批量大小限制和临时费率估计。
- **验证批次监控（仅限批次漏斗）。**在 _Data 360_ 监控控制台中查看提取成功率、空字段率和作业完成情况。确认标记从 UDLO 通过 DLO 传播到数据谱系中的 DMO。
- **验证 API 错误处理（仅限事务处理漏斗）。**测试所有错误条件：**413**（文档超过 10MB）、**400**（无效模式 ID）、**200**（部分为空的有效提取）。请确认重试逻辑在模拟 **5xx** 响应上触发，而不会创建重复写入。
## 结论
本文档强调了 _Data 360 文档 AI_: 的架构基础
- 两个处理漏斗以及何时使用它们
- 模式配置模型
- 目标层决策框架
- 核心工艺限制
- 失败模式
- _结构良好的框架_定线
[架构师快速入门指南](/docs/architect/zh-cn/fundamentals/guide/data360-document-ai#架构师快速入门指南)提供了 Sandbox 概念验证的配置顺序。
核心架构态势支持在_模式_层受控制的文档派生数据，通过 ETL 强制的 LLM 漏斗进行处理，并交付到管理我们所有其他企业数据的相同 _Data 360_ 数据生命周期。
应用这些原则的架构师（选择正确的漏斗、在文档类型级别设计模式以及在生产前设计失败模式）构建了在受监管的行业治理要求下扩展和持久的提取功能。
### 关于作者
**Yugandhar Bora** 是 Salesforce 的软件工程架构师,专门从事_数据和智能_应用程序平台中的数据架构。他领导_企业架构审查委员_会 (EARB) 重点关注数据治理和统一数据模型的举措,同时也为自动化平台配置解决方案做出了贡献。
**Ananth Anto** 是 Salesforce _Data 360_ 的产品管理总监，负责领导 _Document AI 和数据图表_计划。他在班加罗尔与企业客户合作，解决现实世界的文档处理和数据智能挑战。他喜欢探索_生成式 AI (Gen AI)_ 的_企业_用例。
**Nishan Naseer** 是 Salesforce 的软件工程架构师，从事_非结构化数据处理_、_RAG_ 漏斗和_文档智能_方面的工作。他热衷于利用 AI 的强大功能来解决现实世界的挑战，并找到解决复杂客户问题的创造性解决方案。
# 上下文
数据平台已经发展了三十多年。最初，该行业由内部部署、集中和结构化（主要是关系型）操作/OLTP 数据库主导。它扩展到包括数据仓库 OLAP/大数据平台，这些平台主要用于分析处理，并保持关系性和集中性。云存储推动了分布式架构，例如数据仓库、湖泊小屋和分类存储。但是，操作平台和分析平台仍然是分开的。如今，云计算和 AI 革命正在从根本上改变数据平台架构。
企业已经在成熟的大数据平台上投资，例如 Snowflake、数据块、BigQuery 和 Redshift。但这些平台充当数据孤岛。客户无法从数据中获取业务价值，因为数据不能直接在业务流程和应用程序中操作。这些解决方案缺乏生成式客服人员 AI 处理，无法实时提供数据访问，因此无法在客户参与时提供 AI 驱动的个性化和其他行业领先的功能。
数据平台的未来的特点是统一、灵活、可访问和开放的数据基础设施。这一新架构构建于现代计算和存储趋势（GPU、大内存、NVMe SSD 和云存储），与云计算和 AI 集成。他们能够提供实时见解，支持自主决策，并推动实时应用程序。这包括代理 AI、预测 AI、分析、实时大规模 OLTP 数据库、数据湖和湖泊小屋的兴起。这些现代数据平台旨在实现简单性、可扩展性、灵活性、性能、安全性、可用性和成本效益。
## 下一代数据平台架构的关键趋势
以下数据趋势推动了下一代数据平台架构。
- **AI、机器学习和 Analytics 是核心**:客服人员 AI 的兴起将从根本上改变数据平台的开发、部署和使用/访问。客服人员 AI 将理解对话/查询意图，计划、生成工作流，并自动化决策。客服人员（短期和长期）记忆从对话历史记录中构建，用于个性化客服人员规划和决策、实时对话建模和在数据平台中至关重要的个性化支持。客服人员将帮助自动化操作“功能”，例如数据治理（即安全、合规、Trust）、性能（即针对并发、吞吐量和延迟的自动扩展）、故障转移和可用性以及可观察性和维护。AI 支持的分析、预测、自然语言处理 (NLP) 用于分析问答，以及对非结构化数据（PDF、图像、音频、视频等文本）的分析将是标准功能，使企业能够从各种数据源中获得更深入的见解。
- **数据分散化但统一数据访问**:客服人员需要企业数据来获取见解和决策，并实现业务活动的自动化。数据在企业、不同的应用程序和数据平台中本质上是分散的。但无缝统一企业内不同业务部门之间的孤岛以及与企业外部合作伙伴之间的孤岛并不容易。统一数据涉及数据共享，或者通过从源接收数据，或者与数据源联合；来自数据准备、协调和建模的原始数据，用于分析和 AI 处理；大规模存储和管理数据，以便以较低的 CTS 实现高效的访问;通过各种查询和分析机制和工具进行数据访问，并与底层存储和数据访问平台深度集成
- **基于云的 Open Lakehouse**:基于云的大数据 (OLAP) 平台正在采用开放文件格式 (Parquet) 和表格式 (Iceberg)，支持数据联合（数据输入）和共享（数据输出）。
- **非结构化数据处理**:随着生成式 AI 的出现、进步和采用，企业开始从由大量文本文档、音频脚本、视频记录和其他媒体组成的企业数据集中获得有价值的见解和业务价值。非结构化数据处理，包括分块、矢量化、语义搜索和 Knowledge 图，使这些见解成为可能。像 RAG（检索扩充生成）和 CAG（缓存扩充生成）这样的技术正在成为整个数据集中快速和代理搜索的主流驱动因素。
- **知识管理**:Knowledge 不仅仅是原始内容本身(文档、文章、视频)。它代表通过派生意义、策划元数据并将其放在上下文中来扩充该内容，以便在整个组织或企业中形成对内容的共同理解。Knowledge 本身通常是结构化的。Knowledge 管理涉及内容管理、Knowledge 提取、通过图形等模型表示以及导航。
- **富数据访问**:富数据访问意味着数据、分析和 AI 工具必须由各种角色访问，包括最终用户、业务用户、管理员和分析师。可访问性通过集成查询（具有关系、关键字和语义查询）、自然语言到 SQL (NL2SQL) 查询、实时访问等机制来实现。
- **实时处理**:客服人员应用程序根据当前状态和新事件做出实时决策，个性化响应和操作，这需要访问、处理实时数据并采取行动。实时处理需要最新数据（数据延迟）和交互式访问（访问延迟）。此类数据和访问延迟要求基础数据平台支持从运营和分析商店访问最新数据、低延迟访问（点查找和查询）处理、高数据规模和高吞吐量。
- **数据安全、治理和驻留**:客服人员和对话式 AI 简化了应用程序 UI，允许任何人（从消费者到员工到其他 AI 客服人员）使用口头或书面自然语言与应用程序进行对话式交互。必须为客服人员应用程序存储和建模的宝贵客户和个人数据必须使用定义明确的访问和共享策略进行保护和治理。越来越多的客户必须遵守法规，要求数据驻留在自己的国家或地区，特别是那些在政府部门工作或与政府合作的客户。
Salesforce Data 360 专为未来解决这些数据趋势而设计。Data 360 是一个云原生的元数据驱动的数据平台，它统一了整个企业中孤立的数据，允许组织存储、建模和处理他们的数据，以支持分析、AI、机器学习和 Agentic 应用程序。
本文档是企业架构师和 CTO 的基本指南。它详细介绍了 Data 360 的架构、功能、设计原则和用例。它首先介绍了 Data 360 架构的基础,然后深入探讨了它的关键区别,例如与现有数据平台的互操作性,包括多组织策略、安全性、治理和隐私性、实时激活和数据洁净室。
## 设计原则
Salesforce Data 360 围绕一组核心原则进行设计，这些原则使企业数据具有可操作性、可信赖性和实时性。
- **开放性和交互性**:专为多云生态系统构建。与 Snowflake、Databricks、BigQuery 和 Redshift 等数据平台联合，没有重复，在保留现有投资的同时扩展 Customer 360。
- **存储-计算分离**:独立扩展存储和处理（批处理、流和交互式）。为高用量、高性能工作负载提供灵活性和效率。
- **多模型存储和处理**:支持结构化和各种非结构化数据类型，例如文本、图像音频和视频。提供高效的存储、实时和批处理、可扩展的索引、统一搜索、查询和分析。
- **元数据驱动的设计**:应用程序由元数据定义，而不是代码。元数据被视为一流资产，可实现统一治理、灵活性并深度集成到 Salesforce 平台。
- **实时混合处理**:支持低延迟查询和即时决策，以及批处理和分析工作负载。
- **智能和活动数据**:持续接收、分析和将见解直接推送到业务工作流。通过最新的上下文，支持无代码、低代码、专业代码和 AI 驱动的自动化。
- **按设计的治理和隐私**:系统内置了谱系、访问控制、驻留、数据加密和合规性。 Trust 和监管信心在每个层都得到加强。
- **一对多租户**:集中式 Data 360 组织是 Customer 360 的单一真相来源，无缝支持 Salesforce 客户广泛使用的多组织 Salesforce 环境。
这些原则确保 Data 360 使数据实时开放、智能和可操作。
### 从原则到功能
Salesforce Data 360 是一个现代数据平台，构建于解决当前数据趋势的设计原则之上。其架构功能确保企业数据实时可信、统一和可操作，符合其指导原则。
- **云原生基础**:在 Hyperforce 上运行，部署在 Hyperscaler（例如 AWS）上，具有不可变的、基于微服务的基础架构。提供弹性扩展、零信任安全性、持续交付和全球合规性。
- **Salesforce（核心）元数据驱动**:元数据被设计、建模并存储为 Salesforce 元数据，允许所有 Salesforce 应用程序立即使用。此类元数据存储在完全符合 ACID 的 RDBMS 中。确保治理、生命周期一致性以及与 Salesforce Lightning 平台的深度集成。
- **Lakehouse Storage**:构建于 Apache Iceberg 和 Parquet，将数据湖规模与仓库治理相结合，支持模式演进、时间旅行和高用量更新。Data 360 使用具有现代开放标准的极端大规模存储来存储、建模和处理结构化和非结构化数据，并且具有丰富的转换和数据处理能力来应对批处理和事件驱动的工作负载。
- **具有灵活接收能力的端到端数据漏斗**:涵盖整个生命周期 — 摄取、准备、建模、统一、分析和激活 — 减少对零散点解决方案的依赖。通过 270 多个连接器和 MuleSoft，支持批量、近实时和流。ELT 优先方法通过下游转换灵活性实现了快速的数据可用性。
- **与开放框架和联盟的企业数据交互性**:通过 Snowflake、数据块、BigQuery 和 Redshift 的双向 Zero Copy 联合，统一企业中的思洛存储器数据，避免数据迁移或重复。
- **数据分类、建模和组织**:Data 360 将数据组织为原始摄取数据、清理和存储的数据，以及符合称为 SSOT（单一真相源）的常见信息模式的建模数据。此类 SSOT 对象构成了定义语义数据模型 (SDM) 和其他特定于应用的模型的基础。
- 通过开放语义查询 API 实现可扩展分析的**内置语义数据建模**，推动 Tableau Next 并支持特定于应用程序的分析。
- **高性能 SQL 查询引擎**支持跨结构化、非结构化和图形数据的统一 Data 360 SQL 查询。
- **低延迟数据存储**:具有毫秒响应时间的热数据的键值存储。实时启用个性化和事件驱动的场景。实时收集和处理客户参与数据。将身份、交互和对话统一到一个受信任的 Customer 360 简档和上下文图表中。
- **非结构化数据**处理漏斗,用于灵活和可扩展地支持非结构化数据存储、分块、嵌入生成(矢量化)、元数据提取(扩充)、汇总、索引、Knowledge 提取、智能文档处理、短期和长期(对话)记忆创建等。
- **本地关键字、**向量和混合索引,用于准确和高效的非结构化数据访问,例如快速和代理搜索、RAG、Knowledge 提取、代理记忆派生等。
- 用于启用 AI/ML 和客服人员应用程序的**简档、个性化**、上下文服务。
- 每一层的**内在治理和安全**,用于谱系跟踪、数据屏蔽、数据驻留和零信任安全,确保合规和信任。
- **弹性计算结构**:Kubernetes 本地多租户计算结构。为分布式处理运行 Spark，为 SQL 工作负载运行 Hyper。在不同作业之间灵活扩展，并支持隔离运行不可信代码。
所有这些都在 Hyperforce 上运行，即 Salesforce 的云基础。Hyperforce 提供：
- **零信任安全** 有加密、隔离和最低特权策略
- 通过多区域部署实现**弹性**。虽然 Salesforce Data 360 受益于 Hyperforce 的多区域弹性和平台级容错，但真正的企业级灾难恢复 (DR) 需要更广泛的架构，类似于任何具有关键功能的数据平台：可重放的接收漏斗、复制以及跨所有依赖生态系统的元数据驱动的补水。
- 内置监控、度量和跟踪的**可观察性**。
- **自动规模和 FinOps 感知**，提高效率，而不会造成成本溢出。
Data 360 不会取代现有的企业投资。相反，Data 360 使您已经信任、治理和可操作的数据 — 在最重要的地方提供 AI 驱动的实时参与。简而言之，Salesforce 将所有企业数据（包括外部数据）转换为 (Salesforce) 元数据驱动的对象，并支持 Agent 应用程序进行发现、决策和采取行动。
下图说明了 Data 360 参考架构：
让我们考虑在 Data 360 上分层的假设 Agentforce 贷款代理，以描述示例架构流。假设贷款客服人员是面向客户的客服人员，客户（消费者）可在其中申请贷款并获得即时贷款批准。
Data 360 按计划执行这些步骤，准备贷款代理使用的数据。
- Data 360 从 CRM 接收结构化客户客户数据，并将其存储在数据湖中。
- Data 360 处理非结构化公司贷款和财务保单数据。
- Data 360 从 Snowflake 等外部数据源整合个人数据。
- Data 360 转换并建模摄取和聚合的数据。
- Data 360 构建和维护简档数据图形。
每次客户申请贷款时，都会执行这些操作。
- 客户登录到贷款代理，这将在实时层开始客户会话。客户的统一简档被拉入实时层。
- 客户通过提供所需信息完成贷款申请。
- 客户将财务文档（例如纳税申报表、投资、银行对账单）上传到 Data 360，以便进行非结构化数据处理。
- 上传的数据被分块和矢量化（嵌入生成），并创建索引（关键字和矢量）。
- 接下来，客户填写贷款申请文档并上传。Data 360 会实时提取贷款金额和期限。
- 贷款客服人员使用 Data 360 查询和简档及其他预创建索引的混合搜索检索相关财务数据。
- 贷款代理使用贷款数据和其他财务简档数据激活批准代理，以做出贷款批准决策。
- 贷款代理以决策回应客户。
- 客户和贷款代理之间的整个交互也会被捕获并存储在 Data 360 中。
以上示例概述了用于构建代理应用程序（例如贷款代理）的 Data 360 架构组件。在下一节中，我们将介绍 Data 360 架构层和组件。
## Data 360 架构
在本节中，我们将深入了解 Salesforce Data 360 的基础构建块，从强大的存储模型开始，然后探索连接、接收和准备数据的机制。然后，我们将检查结构化和非结构化数据的存储、建模和处理方式，最终了解其协调、统一、检索和智能激活功能。
### Data 360 Storage
Salesforce Data 360 构建在分层但集成的存储模型上，该模型结合了湖库与实时存储的优势。Lakehouse 层为大量历史数据和批处理数据提供了可扩展的经济高效的存储，支持高级分析和机器学习用例。另一方面，实时存储针对低延迟访问和高频更新进行了优化，确保客户交互、简档和参与信号始终是最新的。这些层一起无缝工作，允许数据在历史和实时上下文之间流畅移动，在统一数据基础中为个性化、AI 和激活提供深度和即时性。
#### Lakehouse
Data 360 采用基于 Iceberg/Parquet 的本地 Lakehouse 架构，旨在处理批量、流和实时场景的大规模数据管理和处理，支持结构化和非结构化数据，这对 AI 和分析应用程序至关重要。
在 Azure、AWS 或 GCP 等基于云的数据湖中，基本存储单元是文件，通常组织成文件夹和层次结构。Lakehouse 通过引入更高级别的结构和语义抽象来促进查询和 AI/ML 处理等操作来增强这种结构。主要抽象是一个带有元数据的表，它定义了其结构和语义，包含了来自开源项目的元素，例如冰山或三角洲湖，并由 Data 360 添加了额外的语义层。
Lakehouse 中的抽象图层：
1. **Parquet 文件摘要**:在基础部分，存储由 Parquet 格式的数据湖文件（例如 AWS 中的 S3 或 Azure 中的 Blob）组成。源表的数据在多个分区中存储为 Parquet 文件，每个表是这些文件的集合。
2. **冰山表摘要**:表格被组织为文件夹，数据分区在这些文件夹中存储为 Parquet 文件。对分区的修改会生成新的 Parquet 文件作为快照。对于每个表，Iceberg 会管理元数据文件，并详细说明模式、分区规格和快照。
3. **Salesforce Cloud 表摘要**:该层构建于 Iceberg 之上，添加语义元数据，例如列名和关系，以及配置，例如目标文件大小和压缩。它抽象了各种平台的表，例如 Snowflake 和数据块，将 Data 360 应用程序与底层存储平台特定功能屏蔽在一起。
4. **Lake Access 库**:此库提供对 Salesforce Cloud 表的访问权限，处理数据和元数据，并为应用程序开发人员抽象底层存储机制。
5. **大数据服务抽象**:这包括处理框架，例如用于查询的 Hyper，以及用于跨任何云表平台的处理的 Spark。
#### 实时存储
为了支持实时分析和客服人员应用程序，Data 360 通过低延迟存储扩充了 Lakehouse 大数据存储。Data 360 实时层会在内存中处理实时信号和参与数据。但是，由于基于内存的存储容量有限，因此无法容纳所有数据，处理可能无法实时完成。Data 360 添加了低延迟存储 (LLS)，以消除此类限制，从而实现可扩展的实时处理。
低延迟存储是 Lakehouse 上的 NVMe (SSD) 存储层。并非所有数据都需要保存在低延迟存储中。它是一个耐用的缓存。大多数数据最终会进入 Lakehouse 进行长期保存。实时层中的会话数据可以刷新到低延迟存储，以便后续快速访问。例如，在客服人员对话中，最近的消息可以在内存中处理；较早的消息可以刷新到低延迟存储。如果需要之前的对话，可以在几毫秒内从低延迟存储中访问它。基于 NVMe 的存储允许以毫秒延迟存储和访问大量数据。数据可能会流向 Lakehouse 云存储，以便长期保留。此外，从 Lakehouse 获取实时处理或增强实时体验所需的数据，并将其保存在低延迟存储中。例如，客户简档上下文是预先提取的，或从 Lakehouse 获取，并缓存在低延迟存储中。此外，任何 Lakehouse 对象和会话处理期间实时处理所需的其他对象也可以缓存在低延迟存储中。
Data 360 低延迟存储支持具有内存 (SSD) Lakehouse 存储层的真正存储层次结构上的实时层，数据可在这些层之间无缝迁移。我们将在本文档的后面讨论 Data 360 实时层。
### 数据组织
Salesforce Data 360 旨在标准化、协调和激活所有客户数据（结构化和非结构化），遵循严格的生命周期，将原始输入转换为统一的最新数据模型。
#### 数据生命周期和对象类型
生命周期侧重于获取各种外部数据输入，并将其构建为持久的建模对象。建模数据可以协调到 Customer 360 统一简档中。
**原始摄取数据和初始转换**
该过程从按原样从源系统（CRM、市场营销、文件等）接收的原始数据开始。这包括完全数据加载和连续变更事件 (delta)，它们被管理并与持久数据合并以保持当前状态。
在摄取期间立即应用**内联转换**(例如修剪、规范化、连接 ) , 以确保初步数据质量和清洁度。
##### 数据湖对象 (DLO)：持久层
**DLO** (数据湖对象) 是 Data 360 中的核心持久存储层。它们存储干净、转换后的数据，并作为所有客户信息的有组织长期存储库。
**高级数据转换**(例如连接、聚合、计算见解)应用于源 DLO，以生成新的、高度策划的派生 DLO。
通过 Zero Copy 数据联合提供的数据直接表示为 DLO。
**非结构化数据和元数据组织**
对于非结构化内容（例如文本、媒体、文档），Data 360 通过在特定 DLO 中提取和保留结构化元数据来合并数据，称为非结构化数据湖对象 (UDLO)。
这些专门的 DLO 充当目录表，提供非结构化资产的物理位置和上下文的映射。此功能允许架构师将非结构化数据的元数据与其他结构化客户数据无缝关联，从而实现统一查询和协调。
##### 数据模型对象 (DMO)：协调图层
**DMO**(数据模型对象)代表最终的、统一的和结构化的数据层。
它们通过将 DLO 字段（从源、派生和非结构化元数据 DLO）映射到标准 Customer 360 数据模型来创建。
DMO 层充当所有客户数据的单一真实来源，支持在更广泛的生态系统中统一简档创建、细分和激活。
#### 数据空间：逻辑容器
数据空间是用于组织 Data 360 中的所有数据和元数据的基本逻辑容器，包括所有 DLO（结构化和非结构化）和 DMO。数据空间为数据处理和建模提供了安全的隔离环境。
数据空间充当逻辑和治理边界，通过分离不同实体（例如业务部门、地区或品牌）的数据来实现内部多租户，同时保持企业范围的可见性、谱系和合规性，作为定义粗粒度访问控制的基础。
数据空间内的隔离在平台的多个层强制执行：
- **数据级隔离**:每个 DLO/DMO 属于一个数据空间，确保查询、转换和对象映射不能跨越数据空间边界，除非明确授权。
- **访问控制集成**:权限集本地绑定到数据空间，允许控制读、写和管理操作。这确保只有授权用户和服务才能访问数据空间中的对象、见解和激活。
- **治理和审计**:数据空间中的所有操作都通过企业级审计跟踪进行记录，从而实现合规性、管理和监管报告的可追溯性。
通过权限集管理访问权限和权限，确保精细可见性、受控更新和防止跨域数据泄露。通过将数据空间边界与 Data 360 的安全和治理架构集成，架构师可以自信地实施集中和分散的治理策略，同时在多个云和业务域中保持一致。
#### 计算结构
Data 360 计算交换矩阵为管理和执行所有大数据工作负载提供了统一层，简化了底层基础设施的复杂性。其核心组件是数据处理控制器 (DPC)。
DPC 是一项全面的多工作负载数据处理编排服务，跨不同的云计算环境提供作业即服务 (JaaS) 功能。它抽象了基础设施的复杂性，并统一了 Spark（EC2 上的 EMR 和 EKS 上的 EMR）和 Kubernetes 资源控制器 (KRC) 工作负载等框架的作业执行。通过充当集中控制平面网关，DPC 跨多个数据平面编排、计划和监控作业，确保可靠性、可扩展性、成本效率和一致的开发人员体验。
对 DPC 的需求源于直接与本地群集管理系统（例如 EMR）交互的限制。
##### 基础设施和云抽象
虽然 EMR 为集群、任务和步骤提供 API，但它仍然为客户团队带来重要的基础设施管理任务，例如配置、扩展、性能调整和成本优化。DPC 通过为作业提交提供简化的平台级 API 来解决这个问题。它支持自动故障处理、重试和动态负载平衡。通过基于二进制、点和重力的节点提供成本效率。通过 TLS、PKI、IAM 隔离和自动修补提供强大的安全性。管理 Spark 和 EMR 运行时版本升级，以提供性能改进、安全补丁和功能增强。
此外，DPC 提供了与云无关的统一界面，用于提交和管理数据作业，抽象了基础云基础（AWS、未来提供商）的复杂性和专有 API。这确保了客户团队仅与基于 Data 360 API 的通用作业提交界面交互，该界面抽象了基础资源管理器的复杂性，例如 Kubernetes 和 YARN。这允许客户团队通过简单、统一的 API 提交 Spark 作业，而无需直接管理 Pod、节点池或 Spark 群集配置。
手动调整 Spark 参数需要专业技能，不正确的配置会导致作业执行缓慢。DPC 团队集中了这些专业知识，提供了优化的配置来防止常见的性能问题。该专业团队不断集成开源社区的 Knowledge，以确保控制器管理的所有工作负载具有最佳性能。
DPC 不限于 Spark；它支持广泛的工作负载。其中包括：
- 实时处理工作负载
- 数据操作的事件递送功能
- Milvus 的管理（用于非结构化数据索引的向量数据库）
- 低延迟存储基础架构
DPC 还利用 **Kubernetes 资源控制器 (KRC)** 框架,该框架支持 Trino for Query、Event Delivery for Data Actions、Data Extraction Job for Connector 和实时处理等工作负载。对于所有 KRC 工作负载，DPC 提供了集中的“作业即服务”功能，在高级别作业抽象中处理计算配置、部署和管理。
##### JaaS 优势和架构
DPC 提供的“作业即服务”模式可确保作业处理漏斗的经济高效且具有弹性。
用户提供简单的集群规范，重点关注所需的 CPU、内存、存储、实例计数以及集群匹配的最小/最大集群计数和标记。然后，DPC 会自动管理抽象基础设施详细信息，包括选择最佳 VM SKU、管理实例车队、确定核心节点与任务节点的比率，并根据输入管理按需与现场实例。它还处理 EMR 和组件版本管理和升级，无需停机。
重要的是，DPC 本身支持多租户，旨在理解和强制执行 Data 360 租户边界和资源分离。它还通过强制执行 Salesforce 认证的机器映像、管理特定于服务的 IAM 角色以及保证传输中和静态的加密来确保安全性和合规性。对于路由和容量控制，使用集群标记管理作业到集群的匹配，基于容量的路由使用最大作业并发设置来有效控制资源利用率。
与云无关的客户端体验是一项核心优势，因为基础云环境的复杂性对客户端服务隐藏，允许他们纯粹专注于业务逻辑。这实现了云提供商抽象的目标。最后，DPC 实现了简单的使用情况和成本跟踪，允许按服务对集群利用率和成本进行细分，以实现准确的核算。总体而言，DPC 遵循可插拔的架构，允许新的执行引擎（例如 Flink、Ray）和云基板 (GKE/Dataproc) 无缝集成，而不会向用户公开底层基础设施的详细信息。此设计将控制平面与执行层分离，确保一致的 API 和操作体验，而不论后端如何。
### Data 360 中的数据处理：从原始到可操作
Data 360 优化和丰富原始数据，弥合原始数据和可操作业务消费之间的差距。它通过为复杂的激活和分析准备复杂的数据来补充数据对象生命周期。Data 360 支持各种处理类型，包括批处理和流数据转换、批处理和流计算见解、非结构化数据处理和身份解析。要高效地实现这些不同的操作，特别是在近乎实时和跨大规模数据集的情况下，需要一个复杂的机制来有效地处理数据变化。
#### 支持增量处理
为了实现高效、近乎实时的数据处理（尤其是使用 TB 大小的表和数百万个潜在更新），Data 360 需要突破。它需要一种方法来准确通知系统数据何时更改，然后高效地识别哪些数据发生了更改，以便只处理相关的更新，并且只更新它们。这一挑战导致了两项相辅相成的创新:存储本地更改事件 (SNCE)，以在更改时通知，并更改数据摘要 (CDF)，以确定更改的内容。
##### 存储本地更改事件 (SNCE)
SNCE 已将 Data 360 从根本上改变为反应式增量数据平台。这种转变涉及从主动轮询数据湖转向被动监控原子提交事件，使用标准化的事件格式和高吞吐量的消息传递系统。
对 Iceberg 表的每次成功写入操作（插入、更新、删除）都最终导致对目录中该表的当前元数据文件指针进行原子交换。基础对象存储层（例如 S3）被配置为每当新的元数据快照被写入表的目录时发出本机通知事件（例如 S3 事件）。
SNCE 库提供了使用这些事件的标准化方法，并且还可以根据请求使用快照元数据来丰富它们。
这使得下游数据漏斗（例如流计算见解、身份解析和细分）能够仅在数据发生变化时订阅并采取行动，从而通过避免代价高昂的全表扫描来显著提高效率。
##### 更改数据摘要 (CDF)
在 SNCE 的基础上，变更数据摘要 (CDF) 提供了一种简化的机制来使用和增量处理变更。
CDF 利用 Iceberg 快照高效地生成更改流。重要的是，Data 360 的优化的 Iceberg 写入器计算并保留更改作为写入操作本身的一部分，使 CDF 生成非常高效，并最大限度地减少额外的开销。这允许处理作业（例如流转换或流计算见解）有选择地只处理更改的记录，避免昂贵的快照差异计算。
这种增量策略为大型数据集提供了几个好处，包括节约成本、减少延迟和提高效率。它支持流转换和增量身份解析等功能，进而带来更快的见解、更可预测的系统负载、更高的性能和更低的运营成本。
### 连接、接收和准备
Data 360 提供强大的接收功能，对 Salesforce 产品提供本机支持，确保无缝数据流。对于外部源，它通过 270 多个连接器、API、SDK 和 MuleSoft 提供了广泛的连接。此外，Data 360 具有零复制联合功能，允许 BI 和分析，而不会造成数据重复。
#### Data 360 连接器框架
Data 360 连接器框架 (DCF) 是大部分 Data 360 连接的基础。它通过统一的架构支持接收、联合和出口。DCF 定义了构建和管理连接器的标准，从设置和管理的 UI，到元数据的持久化、数据提取和交付到 Lakehouse，或者通过对外部源的实时查询。它还支持专用连接选项（例如专用链接、VPN 和安全隧道），以确保连接到客户或合作伙伴环境时的企业级数据安全性和合规性。通过为所有连接器提供一致的方法，DFC 通过确保可扩展性、可靠性和安全集成，使 Data 360 能够无缝连接到更广泛的生态系统中。
#### Data 360 连接器
Data 360 提供了与庞大的数据源生态系统的强大连接，支持本地 Salesforce 产品和大量外部系统。这种广泛的连接对于统一孤立的企业数据以及支持 AI/ML 和客服人员应用程序至关重要。
Data 360 本地或通过 MuleSoft、API 和 SDK 提供超过 270 个连接器，通过批处理、流或实时接收支持端到端数据漏斗功能。这些连接器可以按它们集成的源系统的类型来大致分类。
**Salesforce 本地连接器**
这些连接器确保来自 Salesforce 产品的无缝本地数据流。
示例包括 Salesforce CRM、Data Cloud One、Marketing Cloud Engagement、Marketing Cloud Account Engagement 和 B2C Commerce 的连接器。
**外部应用程序和 SaaS**
各种业务应用程序和云服务的连接器允许从外部软件平台接收数据。
示例包括 Adobe Marketo Engage、Microsoft Dynamics 365、Mailchimp 和 Airtable。
**数据库和数据仓库**
Data 360 连接到各种关系和基于云的数据存储平台。
示例包括 Amazon Redshift、Amazon DynamoDB、Amazon RDS（MySQL、PostgreSQL、Oracle）、Google BigQuery 和 Microsoft SQL Server。
**云对象存储和文件系统**
这些连接器与结构化和非结构化数据的超大规模存储解决方案集成。
示例包括 Amazon S3、Google Cloud Storage (GCS) 和 Azure Blob Storage。
**流和消息传递服务**
处理连续实时数据流的连接器对于事件驱动的场景和实时处理至关重要。
Amazon Kinesis 连接器就是一个例子。
**集成平台**
MuleSoft Anypoint 连接器通过 Anypoint Exchange 与更广泛的应用程序和数据库集成，从而扩大了 Data 360 的覆盖范围。
**非结构化数据和云对象存储连接器**
这些连接器对于接收和引用非结构化数据（缺少预定义模型的数据）至关重要，有助于生成式 AI 功能。
所有这些连接器都构建在 Data 360 连接器框架上，提供一致的体验。
#### 数据转换
数据转换是 Data 360 中的基本架构组件，旨在清理、丰富原始接收的数据并将其塑造成与 Customer 360 数据模型一致的标准化、可操作的数据资产。此流程对于数据协调、质量改进以及确保数据为简档统一、细分和激活等下游用例做好准备至关重要。转换利用源数据湖对象 (DLO) 和数据模型对象 (DMO) 作为输入，分别向新的 DLO 或 DMO 生成结果。
Data 360 提供两个主要转换模式，以满足不同的数据速度要求：批处理数据转换和流数据转换。
##### Batch Data Transforms
批处理数据转换专为基于定义的计划或按需触发器的高用量处理而设计。该引擎针对处理复杂的资源密集型重组操作进行了优化。
批处理转换流程使用可视化的低代码漏斗画布进行配置，使用户能够定义多阶段转换逻辑。该引擎独特地支持对规范数据模型对齐至关重要的复杂重组操作：数据结构和规范化。这包括透视（将非规范化记录分解为多个规范化记录）和扁平化（将层次结构数据（例如 JSON）重组为结构化表）。系统的执行模式支持完全同步（处理所有记录）和高效的增量处理模式。增量模式仅处理自上次成功运行以来发生变化的记录，从而显著减少处理时间和资源消耗。批处理转换非常适合不需要实时更新的任务，例如定期聚合和复杂的数据重组。
##### 流数据转换
流数据在数据流入系统时近乎实时地连续和增量地转换处理数据，使它们对于低延迟用例至关重要。
主要界面是 SQL 优先方法，其中转换被定义为针对传入的记录更改流连续执行的 SQL SELECT 查询。该引擎支持核心转换功能，包括数据清理和标准化（例如，验证 PII 和标准化数据格式）以及数据丰富和合并（使用联接和联合）。重要的是，它支持流查找联接，以根据静态或缓慢变化的参考数据实现实时数据丰富和查找，确保简档即时更新。为了优化服务成本，该架构采用了高密度 (HD) 作业设计，将单个租户的多个流转换定义打包到一个基础计算作业中，最大限度地提高了资源利用率。流转换对于事件监控、即时个性化和实时简档更新等用例至关重要。
### 零复制数据联合和数据共享
Data 360 通过支持 Zero Copy 联合和数据共享彻底改变了数据管理，从而消除了移动或重复数据的需要。此功能允许用户从不同的外部来源无缝直接访问数据，并与外部环境共享数据，从而显著降低复杂性，降低存储成本，并确保所有决策都基于最新、最可靠的信息。
#### 数据联合
Data 360 支持与外部数据仓库（Snowflake、Redshift）、Lakehouses（Google BigQuery、数据块、Azure Fabric）、SQL 数据库和许多其他来源的零复制联合。其抽象层支持直接查询外部数据，无需重复，减少了接收时间、存储成本，并确保了最新信息。
Data 360 通过提供统一的元数据层来抽象 Salesforce 和外部对象，从而简化了对外部和联合数据的访问权限。这使得整个 Salesforce 平台及其应用程序能够无缝使用这些数据。
Data 360 支持文件和基于查询的联盟，具有实时查询和访问加速，如图所示。
标签 (1) 和 (2) 说明了 Data 360 的查询（包括实时查询推送）和基于文件的聚合，用于从外部数据湖/仓库/数据源访问数据；标签 (3) 突出了加速从外部数据湖/数据源进行聚合访问。
##### 查询联盟
Data 360 的联合功能的核心在于其查询联合层，该层管理访问外部数据和执行智能查询推送的复杂过程（由标签 1 表示）。Data 360 使用 JDBC 协议连接到源并从中检索数据，并使用额外的逻辑进行增强以提高效率。查询联盟层负责理解和翻译不同的 SQL 方言，找出查询的最佳部分，以便推送到外部系统进行有效的处理，检索结果，并执行任何必要的进一步处理，从而获得最终见解。
###### 缓存（查询加速）
为增强实用程序，Data 360 为其聚合功能提供了可选加速功能。
在激活加速时，Data 360 会缓存聚合数据，以实现更快的访问和更低的成本，因为它避免重复、直接访问外部源。此缓存被视为加速层，并会进行增量更新，以快速反映外部源数据中的任何更改，从而确保加速视图保持近乎实时。
##### 文件联合
Data 360 支持基于文件的联盟（由标签 2 表示），用于从外部数据湖和源访问数据。这种零复制功能的技术基础依赖于标准化：基础数据必须是 Apache Parquet 文件格式，并使用 Apache Iceberg 表格格式。Data 360 可以合并到任何公开了 Iceberg REST 目录 (IRC) 的源中，以实现元数据和存储访问，确保对驻留在平台外部的文件的无缝、受管访问。
通过基于文件的联盟，Data 360 计算处理所有数据处理，因为它们直接访问基础存储。这消除了查询推送和管理各种 SQL 方言的需要，而这正是基于查询的联盟通常需要的。
除此之外，零复制功能还扩展到非结构化数据源，例如超大规模存储解决方案（S3/GCS/Azure 存储）、Slack 和 Google Drive，它们可由 Data 360 的非结构化处理漏斗访问。
#### 数据共享
Data 360 便于与外部数据湖和仓库进行基于查询和基于文件的数据管理（原始图上下文中的标签 4 和 5 所示）。
##### 基于查询的共享
对于基于查询的数据共享，Data 360 公开了一个 JDBC 驱动程序，使用该驱动程序，外部引擎和应用程序可以安全地访问数据。此机制允许外部系统直接针对 Data 360 中的数据连接、验证和执行实时查询。
##### 基于文件的共享（数据共享和 DaaS）
基于文件的共享的主要机制涉及两个概念：数据共享和数据共享目标，它们利用了 DaaS（数据即服务）API。
- 粒度控制：数据共享概念允许客户精确定义在外部共享哪些对象（DLO、DMO、CIO 等），防止意外的数据泄露。
- 安全定位：它还控制数据共享目标，确保数据只对明确授权的外部环境、客户或合作伙伴组织可用（例如，与特定的 Redshift 或数据块实例共享）。
DaaS API 为外部引擎使用数据提供安全和受管的接口。它授予对基本元数据和基础表存储的访问权限，同时保留所有 Data 360 语义。这确保外部引擎以安全的方式在一致和有意义的上下文中访问数据。
### 专用连接
许多安全敏感的客户，特别是大型企业、受监管行业和公共部门组织，作为其安全状况的一部分，限制对其数据湖的所有互联网访问。此策略对合规性和减少风险至关重要，但也阻止 Salesforce Data 360 和 Agentforce 通过公共互联网连接到这些环境。
其中大多数数据湖部署在 AWS、Azure 或 Google Cloud 等超大规模环境中。由于 Data 360 本身在 AWS 上运行，因此访问托管在不同云提供商上的客户数据湖需要跨云网络连接。如果没有绕过公共互联网的安全专用连接选项，客户通常无法或不愿将 Data 360 或 Agentforce 用于依赖这些数据湖的用例。
#### 专用链接
为了解决这个问题，Data 360 支持跨云与客户受管数据源的专用网络级连接。在 AWS 上，这通过 AWS PrivateLink 启用，这允许 Data 360 直接连接到客户配置的端点，无论是在他们自己的帐户中，还是在第三方数据湖环境（例如 Snowflake）中，而无需通过公共互联网。
该架构确保所有流量完全保持在 AWS 主干上，使用专用 IP 地址和不可路由的网络路径，从而满足严格的安全和合规要求，同时实现对客户数据的无缝访问。
#### 专用互连
对于具有多云架构的客户，Data 360 正在通过跨云互连支持将专用连接扩展到 AWS 之外。这支持从 Data 360 到数据湖和托管在 Azure 或 Google Cloud 中的服务的安全、仅主干网络路径，并保留了与 AWS PrivateLink 相同的原则 — 专用 IP 地址、非公共路由和零互联网暴露。
客户可以在两种部署模式之间进行选择：
- **客户管理的互连**:将现有专用电路（例如 Azure ExpressRoute、Google Cloud Interconnect 或 Equinix Fabric）直接与 Data 360 的 VPC 集成。
- **Salesforce 受管互连**:使用完全受管的交钥匙连接，Salesforce 在其中配置和操作跨云链接，并在目标云中公开专用端点。
在这两种模型中，体验是一致的：Data 360 服务通过超大规模程序连接到外部数据源，就像它们在本地一样，无需通过公共互联网就可以实现安全的接收、激活和查询。
### Data 360 中的数据治理：Trust和控制的基础
对于企业架构师来说，强大的数据治理不仅仅是合规复选框，还是构建可信、可扩展和可操作的客户智能的基础支柱。Salesforce Data 360 采用全面的治理框架构建，可确保数据质量、安全性，并在数据的整个生命周期中遵守监管要求。
Data 360 充当集中治理中心，确保所有数据（从原始摄取到激活的见解）都得到完整和控制的管理。
#### 高级访问控制：为何选择基于属性的访问控制 (ABAC)
虽然数据空间提供了粗粒度的访问控制来确定对数据空间中所有对象的访问权限，但基于 ABAC 的策略提供了对数据空间中单个对象、字段和行的细粒度访问控制。Data 360 采用了基于属性的访问控制 (ABAC) 作为其核心授权模型，以实现精细的访问控制。与传统的基于角色的访问控制 (RBAC) 相比，这种战略选择提供了卓越的灵活性和可扩展性，对于具有大量数据和不同访问需求的动态、复杂企业环境来说尤其重要。ABAC 允许根据用户的属性（例如，部门、角色、位置）、数据（例如，PII、灵敏性、数据空间）和环境（例如，一天中的时间）做出访问决策，而不仅仅是预定义的角色。这将支持高度精细和上下文访问策略，并随着数据和用户属性的变化而调整。
- **CEDAR 策略语言**:Data 360 的 ABAC 实施的核心是使用 CEDAR 策略语言。这种专门构建的正式策略语言提供了一种精确和可验证的方式来定义复杂的授权规则，确保策略明确无误，并且可以在规模上一致地进行评估。
#### 治理架构：策略信息、实施和决策点
Data 360 中的治理系统遵循标准、强大的 ABAC 架构：
- **标记、分类和保单编写（保单信息点 - PIP）**:
- Data 360 提供了自动标记和分类机制，利用 LLM（大型语言模型）和 ML（机器学习）来识别结构化数据（例如联系人表）和非结构化数据（例如来自 Google Drive 的数据）中的敏感数据类别（例如 PII.Email、PII.Phone、PII.Name）和其他专门构建的分类（PHI、FinancialData）。
- 重要的是，标签传播沿着数据谱系 (DLO -> DLO -> DMO) 进行，确保分类自动遵循数据转换和派生，从原始摄取的数据到协调的 DMO 层，并通过从流程定义创建的派生数据。
- 最后，策略编写窗格提供了简单的体验，以利用数据和用户属性来定义组织的动态访问规则。
- 这些丰富的元数据（包括标签、分类、策略和谱系）会输入到策略信息点 (PIP)。
- **授权服务（策略实施点 - PEP）**:
- 授权服务充当策略执行点 (PEP)。它拦截来自各种消耗层（混合结构化/非结构化查询、GenAI RAG 检索器和提示、CRM 丰富）的所有数据访问请求，并咨询策略决策点以确定是否允许访问。
- **策略评估引擎 (策略决策点 - PDP)**:
- 该引擎充当策略决策点 (PDP)。它从 PEP 获取访问请求上下文，以及策略定义（在 CEDAR 中）和来自 PIP 的属性，以做出权威的访问决策。
#### 关键策略实施和集成
- **粒度安全策略**:CEDAR 中定义的策略强制实施各种安全级别，包括：
- **对象级安全性**:根据与这些对象关联的标记，控制对整个 DLO 或 DMO 的访问。
- **字段级安全性**:根据标记限制对对象中特定敏感字段的访问。
- **行级安全性**:筛选特定对象上的数据，以根据用户属性仅显示相关行。
- **动态数据屏蔽**:在不更改基础数据的情况下，动态屏蔽访问点的某些数据（基于标记）。这确保了敏感信息得到保护，同时仍然允许广泛的用途。这适用于掩码结构化数据中的字段以及非结构化数据中的内容。
- **一致执行**:整个 ABAC 框架确保了在所有 Data 360 消费模式中一致地实施策略，无论是直接数据查询、生成式 AI 应用程序的检索 (RAG)，还是通过相关列表来丰富 Salesforce CRM 体验。
- **与 Salesforce Platform 深度集成**:Data 360 的治理功能直接在 Salesforce 核心平台中定义和管理。这种集成允许管理员使用熟悉的 Salesforce 工具管理访问策略、用户身份和属性管理，确保整个 Salesforce 生态系统的统一和一致的治理层。
通过使用 CEDAR 策略构建这个复杂的 ABAC 框架，Data 360 为架构师提供了无与伦比的控制和灵活性，确保客户数据不仅可操作，而且在整个企业中安全、合规和可信。
### Data 360 加密：自带密钥
在各行各业，组织都更加重视端到端的数据安全性，以确保防止数据泄露、未经授权的访问、篡改或破坏。大多数数据平台（包括今天的 Data 360）使用供应商管理的加密密钥提供静态加密。但是，企业（特别是受监管行业的企业）越来越多地要求为静态和传输中的数据提供客户管理的加密功能。
该模型允许公司控制自己的加密密钥，确保即使在极不可能发生的平台级泄露或未授权访问的情况下，数据仍然受到加密保护。如果没有客户的专有密钥，任何实体（包括平台提供商）都不能解密或重建数据，从而保持完全的机密性和控制性。
### 非结构化数据存储和处理
Data 360 支持跨数据接收、处理、索引和查询机制无缝存储和管理结构化（表）、半结构化 (JSON) 和非结构化数据。Data 360 支持文本之外的各种非结构化数据类型，包括音频、视频和图像，从而扩大了数据处理和分析的范围。下图显示了接地的两个方面（摄取和回收）。
Data 360 通过将非结构化数据存储在列中作为文本或存储在大型数据集的文件中来管理它。它支持非结构化内容的数据联合，这允许集成和管理来自多个来源的数据。
然后，准备并分块数据，生成嵌入，并处理关键字索引和向量索引。Data 360 托管多个现成的可插拔模型，用于分块和嵌入生成。Data 360 支持音频和视频内容的自动和可配置转录，以便后续处理和索引。搜索服务用于关键字索引。对于矢量索引，Data 360 支持本地索引（通过 Hyper），也利用开源 Milvus 等矢量数据库。Data 360 还与 Salesforce 搜索平台集成，以支持对非结构化数据进行关键字索引。Data 360 中的这种集成多模式索引支持对任何非结构化数据进行搜索，如本文档后面的代理企业搜索部分所述。
对于检索，Data 360 提供 API 进行搜索。我们基于超的统一查询便于跨结构索引、关键字索引和向量索引进行集成查询，保持严格的可见性和权限，从而增强 RAG 和搜索。
#### 可扩展漏斗
Data 360 的非结构化数据索引漏斗设计为模块化、可扩展的架构，包括五个核心阶段：
1. 解析
2. 预处理
3. 块
4. 后处理
5. 嵌入
所有阶段还支持基于 LLM 的处理，这允许客户提出自定义提示。预处理和后处理阶段都可以包括多个顺序步骤，允许灵活地组成复杂的转换。每个阶段完全由元数据驱动，无需更改代码即可实现无缝配置和扩展。
预处理的示例包括噪声消除、语言规范化和图像理解（光学字符识别和字幕）等操作，而后处理阶段可能包括元数据丰富、语义分组或高级技术，例如猛禽分块。
漏斗完全支持 Data 360 代码扩展，允许客户和内部团队在任何阶段插入自定义逻辑。代码扩展组件是轻量级 Python 函数，其生命周期（执行、扩展和故障处理）完全由 Data 360 管理。这种方法确保可以快速引入创新和特定于域的处理，同时保持整个平台的操作一致性和治理。
##### 上下文索引
对于使用非结构化处理设置 RAG，两个关键因素是关键：
1. **快速迭代**:使用示例测试查询快速验证的能力。
2. **特定于个人的内容**:配置针对消费角色定制的内容的能力。
上下文索引是一个用户友好的工具，旨在解决这两个问题。此交互式 UI 由实时 (RT) 漏斗提供支持，该漏斗执行之前概述的所有五个阶段。当嵌入生成和光学字符识别 (OCR) 等任务需要时，漏斗会使用 GPU。此外，它还允许客户在部署配置之前，通过客服人员快速测试 RAG 漏斗，以便进行全面的内容处理。
##### 文档 AI
Data 360 文档 AI 支持从发票、简历、实验室报表和采购订单等文档中读取和导入非结构化或半结构化数据。此功能支持临时交互处理以及批量处理。这是为客户实现业务流程自动化的关键功能。它由人工智能提供支持，包括 LLM 和 ML 模型。
### Enterprise Knowledge
企业拥有分布在不同系统之间的大量 Knowledge，例如 wiki、文件共享、内容管理系统、内部数据库等。这种分散性使得员工（特别是服务客服人员和销售代表）和客户很难快速有效地找到相关信息。关键问题包括：所有 Knowledge 源之间缺乏单一、统一的搜索体验;来自不同来源的内容呈现和呈现不一致;对分散在系统中的敏感信息缺乏访问权限治理;以及难以在核心业务工作流中利用权威 Knowledge 源(例如将相关文章附加到个案)。
Enterprise Knowledge 代表从更广泛的企业数据池中手动或自动策划的内容。手动策划涉及有意操作，例如创建 Salesforce Knowledge 文章或在外部系统中开发 Knowledge，然后引入。我们设想的自动化策划利用流程（例如 Salesforce 客服人员和转换）运行引入的数据来生成细化的策划层，潜在地混合结构化和非结构化的内容。无论是手动还是自动策划，是在 Salesforce 内部策划，还是在摄取前外部策划，结果都是不同于原始数据的增值内容。
Enterprise Knowledge Hub 解决方案利用 Data 360 功能：
- **摄取和存储**:CRM 连接器正在接收 Salesforce Knowledge 文章，数据连接器框架 (DCF) 非结构化连接器从外部来源接收原始内容和元数据。内容被接收到映射到 SFDrive 上的内容的特定于源的非结构化数据湖对象 (UDLO) 中（或者零复制情况下的源）。
- **协调和结构**:协调漏斗处理 UDLO 和文件数据，执行清理、规范化、丰富（NLP 等）、PII 屏蔽，并转换为统一的中间格式，存储在 SF 驱动器和映射到它的统一 UDLO (HUDLO) 中。
- **索引**:非结构化漏斗 (UDS) 通过协调的内容触发，搜索索引为每个 HUDMO 配置。
- **消耗**:消耗应用程序包括搜索、检索、渲染和链接到业务对象，例如个案。收集消耗应用程序的参与度，以提供使用情况分析（例如点击、评论等）
### 计算见解
Data 360 中的计算见解 (CI) 允许客户从他们的数据中定义和生成聚合度量。然后，这些度量用于及时的客户参与、分析、细分和激活。CI 计算的聚合数据被写入 Lakehouse，并代表为计算见解对象 (CIO)。
计算见解主要有两种类型：
- **批量计算见解**:设计用于复杂的高用量数据聚合，其中度量可以定期计算（例如，每天或每周）。
- **流见解**:提供从实时事件数据生成度量和操作的能力，实现即时、低延迟的客户参与。
计算见解在数据模型对象 (DMO) 上定义，也可以在其他计算见解对象上定义。计算见解服务管理批处理和流作业的编排。
批处理和流见解计算都使用 Spark。关键区别在于，流见解利用 Spark 结构化流，而批处理 CI 使用定期、计划的批处理 Spark 作业执行。为节省成本，计算见解服务会根据源数据对象的相关性和重叠等因素，将 CI 分组到同一批次 CI 作业或流 CI 作业中一起计算。
SNCE 和 CDF 在流见解计算中起着重要作用。
### 身份解析
身份解析负责将来自多个来源的不同数据转换为单一、全面的统一简档。
重要的是要了解，统一简档不是“黄金记录”，身份解析不会在统一简档时选择赢得值或覆盖任何现有数据。统一简档作为一组密钥，通过识别与同一实体、一个数据源内或多个源间相关的所有匹配记录来解锁源数据。有了这些信息，您可以选择正确的源系统数据用于给定的业务用例。
身份解析可以整合各种记录类型，包括个人、客户和家庭。它还可用于将潜在客户与现有客户匹配。统一流程对于实现完整的 Customer 360 视图并推动 B2C 和 B2B 场景中的个性化实时参与至关重要。
身份解析漏斗构建在一个高度可扩展的云原生框架上，旨在连续处理大量数据。该过程包括三个关键阶段，依赖于强大的搜索索引管理匹配过程：
- **匹配（候选选择）**:匹配过程的目标是搜索可能属于同一实体的记录。根据可自定义的规则集分析记录，每个规则包含一组条件，定义在哪个严格级别匹配哪些数据。为了高效地从数据存储中检索潜在的匹配项，系统生成索引，以使用两种技术查找可能的匹配记录：
- **阻止密钥**:阻止密钥是从记录的数据生成的值，匹配规则（例如姓名的前几个字母、规范化电话号码等）将可能相似的记录分组在一起。每个记录有多个块密钥，这些密钥被索引并存储为反向索引，确保系统只对小组记录执行详细的比较，而不是在整个数据集上。
- **位置敏感哈希 (LSH)**:对于具有模糊匹配的匹配规则，哈希会根据训练模型中的嵌入生成。
- **深度匹配**:在候选人选择步骤创建更小的潜在匹配组后，系统将开始更详细的比较。在此阶段，AI 模型和高级算法分析每对记录，以计算概率匹配分数。该分数通过智能比较经常包含拼写错误、变体或格式差异的字段来量化两个记录引用同一实体的可能性。
- **集群和统一**:一旦从候选项中识别出匹配的记录，它们将被分组到一个集群中。此过程至关重要，包括解决传递匹配。例如，如果记录 A 匹配记录 B，而记录 B 匹配记录 C，则所有三个对象都会链接到同一个集群中，即使 A 和 C 从未被直接比较。这些完整的集群构成了统一简档的基础结构。此集群过程确保所有相关源记录在单个持久标识符下正确链接。
- **:对帐**使用定义的调和规则(例如,_最频繁_、_最近_或_源优先级_)评估所有集群源记录中的数据值,以使用简档数据摘录填充生成的统一简档。协调不会覆盖任何现有数据，因为所有源数据都使用链接到统一简档的密钥可用。
#### 身份解析类型
该架构支持多种实体类型的解析，以满足各种用例。
- **个人匹配**:专注于创建统一个人简档，将所有已知个人标识符（电子邮件、电话号码、忠诚 ID、Cookie）链接到单个人。
- **客户匹配**:侧重于创建统一客户简档，该简档链接有关客户的数据。在匹配公司名称时，引擎会在模糊匹配时使用微调的模型。
- **家庭匹配**:扩展匹配逻辑，将统一个人记录聚合到相关个人组中。
- **跨实体匹配**:除了统一之外，身份解析还通过使用相同的匹配规则在简档对象之间创建链接。例如，潜在客户可以使用客户名称上的模糊匹配链接到客户。
#### 近乎实时的处理
为了确保统一简档始终是最新的，身份解析引擎使用近乎实时的架构运行。这种云优化的架构专为连续处理而设计，可实现更快的处理时间。虽然处理速度因源数据的接收方式而异，但身份解析可以每 15 分钟处理一次小批量更改。
#### 源简档链接
系统会维护身份链接对象，将每个源记录 ID 映射到相应的统一简档 ID。这种基础数据结构允许引擎高效地跟踪关系，并将更改和更新快速传播到统一简档，确保客户体验（例如网站个性化、Next Best-Action 推荐和细分）始终利用最新鲜的可用客户数据。
### 细分
细分是将统一客户简档转化为可操作受众的核心流程。此功能对于在市场营销、商业和服务渠道中支持个性化体验至关重要。Salesforce Data 360 Segmentation 平台专为大规模运营而设计。它管理复杂的元数据，使用包含数千个对象和关系的数据模型。该平台支持复杂规则、基于聚合的筛选器和基于窗口的排名，所有这一切同时确保以 PB 级进行快速可靠的计算。
#### 细分类型和节奏
Data 360 支持各种细分类型，以满足速度、复杂性和层次结构的不同业务需求：
1. **标准分段**:主要的批处理细分类型。它以可自定义的计划发布，标准发布节奏最少为 12 小时，最多为 24 小时，或更快的快速发布节奏为 1 到 4 小时，这针对最近的参与数据进行了优化。
2. **实时分段**:该细分在毫秒内完成按需操作，以便根据最近事件和简档数据立即采取行动。它针对即时个性化进行了高度优化，但无法使用排除条件或嵌套细分。
3. **瀑布區**:如果客户符合多个条件，子细分的层次结构用于将客户优先排序为单个最有价值的细分。
4. **嵌套分段**:这允许将现有细分重用为新的、更具体的细分（基本细分的细化）的筛选器，并继承父细分的计划。
#### 细分引擎：架构基础知识
细分引擎在强大的云原生架构上运行，可确保速度、规模和弹性。
核心流程由作业编排服务管理，该服务控制细分的生命周期，生成必要的作业配置并触发执行。该编排层在碎片数据库中维护状态和元数据，以实现可扩展性。
虽然 Data 360 查询处理细分计数计算，但 Spark 计算层负责计算实际细分成员关系。Spark 应用程序对大量客户数据执行 Spark SQL 查询。此数据可以驻留在 Data 360 Lakehouse、通过 Zero Copy 数据联合的外部系统或两者的组合中。
系统通过智能查询生成进行了高度优化，优化了基础的 Spark SQL 查询。这包括智能分区修剪等技术，以最大限度地减少数据扫描和消除冗余子表达式。为了确保服务的可靠性，该架构具有自适应资源管理，可以根据工作量大小和复杂性动态调整计算资源。此外，SLO 遵守通过自适应持续时间和重试逻辑进行主动管理。为了获得快速的用户体验，加速的细分计数使用基于抽样的方法在细分创建期间提供快速的大小估计，避免完整的查询运行。
最后，通过全面的 Spark 执行度量和错误自动分类（例如，客户侧与系统问题），保持对可观察性和根本原因归因的高度重视，从而显著减少诊断时间并确保数据平台的高度弹性。
### 激活
激活是 Data 360 生命周期中的关键最后一步。它的核心职能是将静态、细分、统一的客户简档转换为可操作的丰富数据，并将这些数据传递给内部和外部端点（例如 Marketing Cloud、Commerce Cloud 和 Adtech 平台）。此流程旨在触发个性化的客户旅程和近乎实时的互动。它支持高级功能，例如相关属性、激活成员关系筛选、同意筛选、限制和排名。
激活提供了三种不同的外部交付和渠道合规性方法：
- **批量激活**:专为大规模电子邮件活动和广告受众刷新等高用量计划操作而设计。数据通过将其暂存到安全内部存储桶（云对象存储）或通过安全文件传输来传递，然后是目标系统启动的 API 接收过程。批量激活可以使用特殊的刷新模式 - 增量 - 以减少发送到 Salesforce 合作伙伴并由其处理的体积。
- **流激活**:针对需要事件驱动自动化的近实时用例进行了优化。通过发送到目标端点的直接 API 调用来实现交付。
- **激活触发的流**:这种高度平台化的渠道提供了一种无代码/低代码的方法，将受众数据与数百个支持客户 API 的参与平台集成在一起。激活完成后，Data 360 会填充受众 DMO，然后触发大规模流。随后，流引擎会消耗受众数据，并使用平台功能，例如外部服务和 Mule Outbound 目的地，以调用最终基于 API 的目的地。此方法大大减少了加入新激活目标所需的时间。
激活使用与作业管理、分布式执行和监控的细分相同的模式。这包括用于生命周期管理的作业编排服务和用于处理的计算层 (Spark) 的原则，并依赖于作业遥测来实现性能可观察性和服务级别目标 (SLO) 合规。
除了这些之外，激活还有 -
**激活目标管理**监控所有目标端点的安全连接、凭据和配置。它保证数据格式和安全协议标准化，确保可靠的出站交付到各种平台，包括 Marketing Cloud、Adtech 合作伙伴和其他外部应用程序。
激活会为特定目标定制负载。对于 Salesforce Marketing Cloud，这包括业务部门 (BU) 感知筛选、多 EID 支持和交叉授粉控制。
**通信治理**充当守门员,确保数据使用和通信符合客户首选项和法律要求。集中同意模型统一了所有客户的首选项，从全局选择退出到特定于渠道和目的的同意，并存储在统一个人简档中。在执行期间，平台通过使用排除筛选来自动从最终负载中删除不同意的个人，从而严格执行这些策略。此外，系统应用联系点选择规则，以确保在传输任何数据之前，使用目标渠道的单一、最合规和首选联系点。该强制机制由基础治理框架保护，该框架采用动态数据屏蔽和访问控制等保护措施，在整个激活过程中保护敏感数据字段。
### 统一查询：无缝访问所有客户数据
统一数据平台的真正价值在于它能够提供对所有数据资产的轻松、一致的访问，而不管其来源或结构如何。Salesforce Data 360 的统一查询功能专为提供此功能而设计，它抽象了各种数据存储的潜在复杂性，以提供单一、强大的查询界面。
统一查询层为不同的消费模式提供了复杂的访问权限：
- **混合结构化和非结构化查询**:它提供了广泛的 SQL 支持来无缝查询结构化数据和非结构化数据的结构化元数据。通过表格函数的运算符扩展性增强了这一点，支持跨文本、图像和空间类型的专门搜索。
- **通过 Hyper 加速性能**:Data 360 利用高性能内存引擎 Hyper，加速复杂的分析查询和交互式仪表板，在海量数据集上提供近乎即时的响应。
- **适用于 AI 和个性化的统一方法**:这种统一访问对于生成有针对性的个性化结果至关重要，通过将 AI 模型建立在丰富的企业数据中，直接促进了使用检索扩充生成 (RAG) 的更精确的 LLM 响应。
- **与下游消耗集成**:它作为 UI 驱动的体验、强大的 API、生成式 AI 工作流和 CRM 丰富的基础数据访问层，将数据无缝连接到激活。
通过提供单一、智能和高性能的查询界面，Data 360 的统一查询使架构师能够构建灵活的、数据驱动的应用程序，充分利用他们完整的客户信息。
### 数据操作
Data 360 是一个支持激活漏斗以响应数据事件的活动平台。例如，重大事件（例如客户帐户余额下降）会触发 Salesforce 流来编排相应的操作。同样，对关键度量的更新，例如终身花费，可以自动传播到相关应用程序。
数据操作使用存储本地变更事件 (SNCE) 和变更数据摘要 (CDF) 持续监控增量数据的变更。根据客户配置的操作规则评估此数据，例如阈值监控或状态更改。在满足这些规则时，将生成数据操作事件。此事件会使用其他信息（例如客户忠诚度状态）进行丰富，并立即发送到其配置的目标，例如 Salesforce 流或外部应用程序，以触发业务编排。
#### 客户数据平台
Data 360 支持本机 CDP（客户数据平台）功能，包括高级身份解析功能，创建统一个人标识符和简档以及全面的参与历史记录。如上所述，该平台通过支持使用精确和模糊匹配规则的身份解析和身份图，能够处理企业对企业 (B2B) 和企业对消费者 (B2C) 框架。这些身份图使用来自各种渠道的参与数据丰富，这有助于构建具有宝贵分析见解和细分的详细简档图。
支持客户简档的一个关键概念是数据图。Data 360 提供 JSON 格式的企业数据图，这是一个从各种 Lakehouse 表及其相互关系派生的非标准化对象。这包括 CDP 创建的“简档”数据图，其中包含人员的购买和浏览历史、个案历史、产品使用情况和其他计算见解，并且可由客户和合作伙伴扩展。这些数据图形专为特定应用程序定制，并通过提供相关的客户或用户上下文来增强生成式 AI 提示的准确性。Data 360 的实时层使用简档图进行实时个性化和细分。我们将 Agentforce 上下文建模为数据图形，其中包含对话、会话和客服人员记忆。
此外，CDP 支持跨不同平台的有效细分和激活，例如 Salesforce 的 Marketing Cloud、Facebook 和 Google。它批量、近乎实时和实时地处理客户简档，这允许立即做出决策和个性化。此功能增强了 B2C 和 B2B 场景中的交互，确保企业可以快速准确地响应客户需求和行为。
### 实时图层
Data 360 的实时层由 Data 360 CDP 提供支持，并扩展了适用于实时用例的概念。Data 360 的实时层旨在以毫秒级延迟处理事件，例如 Web 和移动点击流、访问、购物车数据和结账，从而增强客户体验的个性化。它持续监控客户参与，并使用实时参与数据、细分和计算从 Customer 360 更新客户简档，以便立即实现个性化。
例如，当消费者在购物网站上购买商品时，实时层会快速检测和接收此事件，识别消费者，并使用更新的终身支出信息丰富他们的简档。这允许在几秒内个性化他们在站点上的体验。此外，该层包括实时触发和响应的功能，支持基于客户交互的即时操作。
亚秒级实时平台通过几个关键功能支持这种转换：
1. **实时数据图形**:Customer 360 简档使用非规范化图表构建，该图表包含与品牌最相关的关键对象和字段。这些数据图形支持实时数据处理，并在毫秒内提供可操作的内容和见解
2. **实时摄取和转换**:从 Web 和移动源接收用户事件和简档（以毫秒为单位）。
3. **实时身份解析**:跨设备合并客户简档，立即统一未知和已知用户。
4. **实时计算见解**:以毫秒为单位计算终身价值 (LTV) 或用户访问历史等度量，以启用适用于 Web、Chatter 或服务代理的个性化或优惠。
5. **实时细分**:实时细分受众，个性化消息和交互。
6. **实时操作**:授权品牌评估每个用户参与，并通过 Salesforce Flow 或其他相关沟通渠道采取行动。
在 Data 360 中，我们构建了一个新的实时平台，它具有实时漏斗、低延迟存储和亚秒数据处理层。由于从 Web 和移动渠道接收快速交互式数据，因此它会经过一系列快速流程。
我们的 Web 和移动 SDK 以及实时 API 从 Web/移动应用程序（在未来的客服人员交互中）收集数据，并将其发送到我们的信标服务器。然后，这些数据被路由到实时层进行毫秒级处理，并路由到 Lakehouse 层与批处理/流数据集成。实时层在用户简档（匿名或登录）的上下文中处理传入的实时数据，例如更新用户的总支出或终身价值等，以实现会话中的实时个性化。实时层由主内存和 NVme (SSD) 存储支持，用于存储实时数据和客户简档。一旦数据在实时图层中，它会在更新到实时数据图形之前经过以下过程：
- **简单摄取和转换**:数据被接收和转换以便进一步处理。
- **身份解析**:精确匹配规则应用于将简档与所有现有匹配规则集统一，因此数据感知专家无需专为实时创建新的身份解析规则集。
- **计算见解**:评估每个参与，运行简单的计算（例如以毫秒为单位的总和和计数），并在实时数据图中更新数据。
- **实时细分**:评估每个参与数据，以确定它是否满足已定义实时细分的条件，并在毫秒内将用户添加到合格的细分中。
- **实时操作和触发器**:根据定义的规则评估每个参与，以在毫秒内满足规则时实时触发一系列目标的操作。
- **实时数据图形和 API**:实时数据图还包括实时 API，它允许品牌为每个用户检索更新的 JSON 格式数据，确保所有客户交互都获得最新的数据。
#### 个性化
个性化是指了解目标对象、何时何地提供相关内容和推荐、说什么以及频率。个性化服务平台是通过个性化体验优化目标实现的决策制定者。
**个性化服务**提供以下功能：
- 在 Data 360 中解释简档、活动和资产数据的一致模型和方式
- 平台集成实验（A/B/n、多臂强盗）
- 在设计时（配置）、ML 训练时间和运行时（ML 推理）集成目标
- B2C 规模实时和批量交互支持（匿名用户、高用量实时/交互式外部、高用量内部批量）
- 通过 Data 360 驱动的 Analytics
- 集成 AI 模型和其他方服务的模式（内部和外部）
- 集成到核心元数据生态系统 (PLATE 特征)
- 高价值 AI 驱动的用例的 OOTB 实施（具有各种 ML 算法的推荐/决策，包括促销/内容选择的上下文强盗、产品推荐、定价决策等）
- **决策漏斗**
- 为个性化决策的外部请求提供服务，包括简档扩充、实验和推荐。
- **推荐引擎**
- 规则或基于 ML 的推荐的运行时服务。
- **索引管理器**
- 管理/安排异步流程的工作流，包括推荐模型的 ML 培训
- **进程对象服务**
- 负责在核心和非核心之间同步个性化元数据
- **分配引擎和实验**
- Analytics 属性和个性化推荐的实验
### 客服人员企业搜索
Data 360 设计为一个强大和丰富的平台，专门用于支持新兴的客服人员体验。我们通过构建各种现有 Data 360 服务并与 Agentforce 深度集成来实现这些功能。
#### 利用 Data 360 的核心优势
我们的客服人员企业搜索方法基于以下原则：
- 企业数据保存在孤立的服务或商店中，具有访问所需的安全权限。在维护源权限的同时访问和处理这些数据的能力对于确保 Trust 至关重要。
- 整个数据集中的交叉排名和相关性可以产生更好的结果，进而为客服人员体验提供更好的上下文。
为了提供这些体验，客服人员企业搜索构建在这些关键的架构组件之上：
- **连接器**:Data 360 中提供的广泛的连接器集使您能够从各种来源访问和接收数据。
- **非结构化数据处理**:这是处理非列表式内容的基础，使系统能够从不同的数据中获取意义和上下文。
- **治理**:确保搜索消耗的所有数据的企业级安全性、合规性和访问控制。对源可见性权限的支持确保只有授权用户才能访问数据，以获得简单的搜索和客服人员体验。为了确保快速检索，搜索后端会在数据访问的最早阶段本地评估并实施安全权限。
- **统一检索层**:为了解决孤立数据的挑战，连接器馈入到全面的统一检索层。此层为所有数据提供单一访问点，无论是保留在通过聚合搜索访问的外部系统中，还是通过零复制和接收数据的高级索引进行本地管理。
- **智能查询理解**:在检索之前，系统使用 AI 支持的机制来解释用户意图。除了为语义向量匹配嵌入查询的表示之外，它还可以重写和扩展基于关键字的搜索以提高准确性。
- **混合搜索和高级查询**:为了找到最相关的信息，平台并行使用多个策略。混合搜索在优化的数据块上提供精确的关键字匹配和语义向量搜索，而完整记录搜索同时检索整个文档。两者相结合，以确保语义相关性和完整的内容覆盖。
- **层次结构排名**:检索数据后，多阶段层次结构排名架构对每个来源和方法的结果进行评分、合并和重新排名。此流程会创建单个统一列表，为用户或客服人员显示最相关的信息。
#### 客服人员搜索应用程序
生成式 AI 正在将企业搜索的主要消费者从人类用户转移到大语言模型 (LLM)。Data 360 搜索从头开始设计，为两者提供服务。它被优化以处理来自客服人员的更长、更复杂的查询，并返回编程消耗和推理循环所需的丰富的上下文结果。同时，系统可以处理人类用户典型的较短且通常不明确的查询，并提供代码片断等功能，以便在 UI 中快速评估。
客服人员搜索体验的最终交付结合了两种方法：
1. **直接搜索结果**: 应用程序可以使用基于 Data 360 统一搜索基础构建的元数据驱动的 API 显示传统的排名结果列表。
2. **客服人员、多轮对话回答**:客服人员回答通过与 Agentforce 的本机集成来实现。这种对话体验由主要客服人员推动，该客服人员编排操作和查询，将所有信息检索任务委派给专门的内部搜索客服人员。
此专用搜索代理专为企业信息检索优化。它使用推理循环来制定和执行并行搜索，以探索用户请求的不同方面。它使用了一套强大的工具，包括对所有数据类型和结构化查询语言的 Data 360 统一搜索，以从表和实体中检索精确数据。
通过这种架构综合，Data 360 支持创建高度智能、上下文感知和可操作的代理企业搜索体验。
### 使用自定义代码扩展 Data 360
可扩展性是 Salesforce 平台中的一项主要功能。代码扩展在 Data 360 中提供可扩展性，允许专业代码用户直接在 Data 360 环境中运行自定义 Python 逻辑，补充其丰富的声明性和低代码功能。使用代码扩展，用户可以安全地扩展 Data 360 核心功能，例如转换和非结构化数据漏斗（自定义分块）。
我们的代码扩展设计优先考虑灵活性、安全性、效率和简化的开发人员体验。它支持两个主要的执行模型，每个模型都针对特定的架构需求定制：
- **脚本模型**:
- **目的**:适用于需要与 Data 360 Lakehouse 直接交互的综合自定义逻辑。
- **功能**:客户使用代码扩展 SDK 编写完整的 Python 脚本，通过 SDK API 启用对 Lakehouse 的读写访问权限。非常适合自定义/复杂数据准备或定制数据操作。
- **隔离和安全**:当脚本访问 Lakehouse 时，它们的执行被限制在 Data 360 运行时的安全、隔离的环境中，防止干扰其他进程或未经授权的系统访问。
- **函数模型**:
- **目的**:类似于无服务器函数，适用于从现有 Data 360 漏斗调用的模块化、无状态计算（例如，在非结构化漏斗中自定义分块）。
- **功能**:客户提供的函数接收输入、计算和返回输出。
- **隔离和安全**:这些功能专为严格隔离而设计；它们没有直接的 Lakehouse 访问权限。它们的执行是 Sandbox 的、无状态的和资源受限的，使它们适合专注的、无状态的处理步骤，确保安全性、可预测的执行，并最小化爆炸半径。
脚本和函数模型都旨在安全执行客户代码，防止一个租户的代码影响其他租户或未经授权访问其他租户的数据、Salesforce 资源或外部资源。这种安全性是通过分层（深度防御）架构实现的。此架构为每个租户的自定义代码提供了隔离的执行环境，其中包含各种防护。这些包括 Kubernetes (K8) 级别的逻辑隔离、网络隔离、运行时 Sandbox 和最低权限，所有这些都由用于检测和响应的操作监控和事件响应准备来补充。
#### 开发人员体验和运营可见性
为了支持强大的开发生命周期，代码扩展提供了：
- **外部编写和调试**:开发人员可以使用 SDK 在熟悉的环境中（例如 VSCode）创建和调试 Python 代码。
- **灵活部署**:自定义代码可以使用 SDK 实用程序、Data 360 UI 或 API 打包和部署，从而集成到 CI/CD 中。
**操作日志**:访问详细的执行日志提供了透明度，并有助于生产中的故障排除。
通过提供这些安全和灵活的代码扩展功能，Data 360 使架构师能够根据最独特和复杂的数据处理要求定制平台，真正巩固其作为可扩展企业数据结构的角色。
### 通过自带 AI 模型扩展 Data 360
随着企业加速采用 AI，大多数企业会维护异构的 ML 生态系统，包括 Amazon SageMaker、Google Vertex AI 和基于 Python 的自定义环境，托管模型来推动关键任务预测，例如信用风险评分、流失倾向、产品推荐和 Next Best-Action 决策。
传统上，将这些外部模型集成到 Salesforce 中需要定制的 API 层、ETL 漏斗或中间件编排，从而引入了数据重复、治理开销、延迟和操作复杂性 — 这些挑战与统一、合规和实时的客户数据平台 (CDP) 愿景相冲突。
**自带模型 (BYOM)**:通过在 Data 360 中通过 Einstein Studio 交付，无需移动或复制数据即可在 Salesforce 工作流、Apex 逻辑和自动化工具中直接调用外部训练的模型，从而解决了这些挑战。通过零复制联合，Data 360 充当受管的单一真相来源，公开统一的 Customer 360 数据，以便在外部端点进行推理。预测输出实时返回，通过可扩展的智能为业务流程提供支持。
BYOM 通过解耦模型开发、受管数据和消费层，有效地弥合了数据科学和运营执行之间的差距。它保留了平台独立性，降低了集成复杂性，加快了 AI 部署，并保持了对敏感数据的治理。
该架构的工作方式如下：Data 360 提供统一的 Customer 360 数据基础，而 Einstein Studio 会编排与外部 ML 平台的连接（SageMaker、Vertex AI 或自定义端点）。外部模型以实时、批量或流模式执行推理。Salesforce 层 — 流、Apex 和查询 API — 使用输出来提供跨 Sales、Service、Marketing 和 Industry Cloud 的个性化、自动化和分析见解。
从企业的角度来看，BYOM 提供了：
- **数据完整性和治理**:消除不受控制的数据复制，并强制实施策略合规性。
- **AI民主化**:使非技术用户可以通过 Salesforce 工具访问复杂模型。
- **实现价值的时间加速**:外部模型会在 Salesforce 流程中立即激活。
- **可扩展性和混合架构支持**:支持 AI 工作负载的多云部署。
- **面向未来的 AI 架构**:支持可组合 AI 策略，解耦数据、模型和消费层，以实现运营灵活性。
**自带 LLM (BYO-LLM)**:提供相同的可扩展性机制，但适用于生成模型。通过启用外部 LLM 的直接调用，我们允许客户在 Agentforce 平台中使用它们，而不是 Salesforce 提供的模型。对于企业 BYO-LLM 允许：
- 访问微调的模型
- 集成目前 Salesforce 未提供的模型
- 在客户提供的客户中使用模型
### 数据协作
现代企业在一个复杂的数据环境中运营，其特点是两大架构挑战：
1. **企业内碎片化**:大型组织经常使用多个 Salesforce 组织（通常按地区、业务部门或历史获取细分）和许多其他数据系统。这种碎片化造成了内部数据孤岛，使得无法建立客户单一、可信和统一的视图来实时参与整个业务。挑战是统一这些数据，而不在所有系统中进行物理整合或复制，确保治理保持不变。
2. **跨企业协作**:公司通常需要与合作伙伴和供应商共享数据，以便进行联合营销、测量和业务智能。挑战是如何在保护敏感专有数据并遵守 GDPR 和 CCPA 等隐私条例以及竞争壁垒的同时实现这种合作。
Salesforce Data 360 使用基于共享访问和见解而不是移动或复制数据的零复制、逐个设计的 Trust 框架来应对这些挑战。
#### Data 360 协作机制
Salesforce Data 360 通过 Data Cloud One、Data 360 之间的数据共享和隐私优先的数据洁净室来解决数据碎片化和协作挑战。这些解决方案统一了客户数据，实现了安全的数据交换，并提供保护隐私的见解。通过零复制、逐个设计 Trust 方法，组织可以释放数据潜力，实现实时参与、增强合作伙伴关系和智能决策。其中每个数据协作选项都有不同的用途。
##### 使用 Data Cloud One 进行内部企业支持
Data Cloud One 是企业运营多个 Salesforce 组织的基础架构解决方案。它的目的不仅仅是简单的数据共享；它旨在建立一个单一的、可信的客户视图，并在整个组织中启用完整的 Data 360 平台功能。
此机制以指定的 Home Org Data 360 实例为中心，该实例充当数据管理和构建统一客户简档的中央机构。家庭组织是配置 Data 360 的组织。Data Cloud One 连接在 Data 360 和其他 Salesforce 组织之间建立，称为同伴组织。作为 Data Cloud One 连接的一部分，Data 360 与每个伴随组织共享一个或多个数据空间，提供对每个共享数据空间中数据和元数据的访问权限。这通过零复制联盟模型和跨组织元数据同步来实现。
Data Cloud One 还允许同伴组织利用家庭组织的 Data 360 实例来满足自己的激活、个性化和智能需求。此策略对于消除内部数据碎片化至关重要，并确保所有业务部门针对相同、受管和统一的客户简档进行激活，从而最大限度地提高核心 Data 360 实施的投资回报率。
##### Data 360 组织之间的数据共享
对于分布式内部环境（完全集中化不可行）以及与可信外部合作伙伴的协作，Data 360 到 Data 360 数据共享连接独立的 Data 360 实例。
这种零复制共享模型建立了在不同 Salesforce 组织上配置的不同 Data 360 租户之间的连接，目的是安全交换数据对象（DLO、DMO 和 CIO）。一旦连接，整个数据对象就可以在收件人 Data 360 中访问。然后，收件人 Data 360 的管理员可以设置治理规则来管理用户对此数据的访问权限。
##### 隐私优先与 Data 360 洁净室协作
当协作需要最高级别的隐私和合规性时，或者当竞争问题阻止共享原始数据时，Data 360 Clean Room 在架构上是强制性的。
在架构上，Data 360 Clean Room 协作构建在 Data 360 到 Data 360 数据共享使用的零复制共享框架之上，但应用了额外的治理和计算约束层。Data 360 Clean Room 提供了一个安全、可控的计算环境，各方可以在其中根据匿名密钥加入他们的数据集。其核心目的是允许联合分析和见解生成，而不会暴露底层专有数据。环境强制实施严格的可编程规则，例如最小聚合阈值和不可导出的标识符。这些规则确保仅派生和共享批准的、增强隐私的和聚合的见解。这使得 Clean Room 对于用例至关重要，例如跨平台市场活动测量和敏感的受众重叠分析。
## 结论：Salesforce Data 360：Agent 企业不可或缺的数据主干
Data 360 被设计为支持下一代 AI 所必需的智能、可扩展和可信的数据结构。其架构设计解决了碎片化数据的问题，使组织能够大规模统一、处理和激活所有客户数据，使用零复制数据联合来确保效率。
其强大的数据组织建立了从 DLO（包括非结构化数据）到 DMO 的统一视图，所有这些都在分区的数据空间中受到保护。Data 360 的多功能数据处理功能（包括批处理和流转换、计算见解、非结构化数据处理和身份解析）由增量 SNCE 和 CDF 架构提供支持，确保高效、近乎实时的处理并显著节省成本。
扩展性由代码扩展架构提供，通过脚本或隔离函数安全地启用自定义 Python 逻辑，以满足唯一要求。此外，基于基于属性的访问控制 (ABAC) 和 CEDAR 策略构建的全面数据治理框架可以保证粒度安全性、动态数据屏蔽以及所有数据消耗的一致性实施。这最终导致复杂的细分和激活功能，将统一的客户简档转化为具有实时响应的动态、多渠道参与策略。
重要的是，Data 360 能够统一海量、多样的数据，通过其统一查询提供实时上下文（包括混合结构化/非结构化搜索和超加速），并实施严格的治理，这对于支持智能 AI 客服人员至关重要。它提供必要的可信、新鲜和相关数据来基础生成式 AI 工作流 (RAG)，并促进 Agentforce 支持的客服人员的多轮、面向操作的功能，确保他们准确无误地工作。
通过提供面向未来的平台，将源数据转化为可操作的见解，Data 360 成为构建客服人员客户体验的组织不可或缺的架构基础。它是将客户数据转化为复杂、个性化的客户体验的重要支柱，推动了当今现代组织的成功。
# 概览
企业数据架构正处于拐点。组织必须同时支持实时 AI 系统，遵守日益严格的隐私条例，并与无法共享原始数据的外部合作伙伴协作。这些要求正在从根本上改变数据平台的设计方式。
基于 ETL 漏斗和集中数据仓库构建的传统架构难以满足这些需求。跨系统复制数据会增加延迟、成本和治理复杂性。每个副本都成为一项新的合规义务，使整个分布式环境中的同意管理、删除请求和策略实施复杂化。
为应对这些挑战，该行业正在转向零复制、策略强制的协作模式。数据无尘室已成为一项关键的架构功能，使多个组织能够分析共享信号，而无需暴露或转移原始数据。计算不是将数据移动到集中的环境中，而是在每个参与者的受管域中执行，并且只返回隐私安全的结果。
这种架构转变在各个行业中越来越明显。例如，WPP 收购了 InfoSum，这是市场营销和广告领域最大的公司，反映了洁净室作为隐私安全协作基础设施的日益重要性。金融机构使用它们来检测跨机构的欺诈，零售商使用它们来协调与消费品品牌的促销，医疗保健组织使用它们来分析跨提供商的患者群，而无需共享敏感的基础记录。
Salesforce Data 360 通过构建于 Hyperforce 的零复制架构来操作该模型。当聚合查询在运行时强制执行隐私、同意和驻留策略时，数据仍保留在源系统中。此方法支持实时见解、跨云协作和 AI 驱动的决策，无需扩展数据复制创建的风险表面。
本文档研究了数据洁净室如何作为现代企业的基础架构模式发挥作用，同时大规模支持 AI 创新、监管合规和安全的跨域协作。
## 为什么洁净室现在如此重要
要了解为什么需要数据洁净室，企业架构师必须首先面对传统集成模型的结构性失败。该行业正在经历从单一、集中的数据存储库到分散、联合生态系统的决定性转变。在这里，数据是就地访问、管理和计算的，而不是物理移动。此轮班不是增量的。这是对传统架构无法再承受的规模、隐私和灵活性方面的系统压力的直接回应。
### 重新定义 Modern Enterprise 中的数据集成
多年来，企业依赖 ETL 驱动的架构，将数据从 CRM、ERP 和数字系统复制到集中仓库进行报告和分析。这种方法被证明对历史分析有效，但它被设计用于一个速度较慢的、面向批次的世界。
随着数字交互的加速和 AI 驱动系统的出现，该模型的局限性变得更加明显。ETL 漏斗本质上是异步的，这意味着见解通常在事件发生后几小时或几天到达。这种延迟越来越与现代用例不兼容，例如需要即时上下文数据的实时个性化、自适应决策和 AI 系统。
复制还带来了日益严重的治理和安全复杂性。每个新的数据副本都需要额外的策略、监控和合规控制。在受监管的环境中，通用数据保护条例 (GDPR) 等框架要求组织在数据存在的任何地方管理删除、同意和使用限制 — 当数据集在多个系统中重复时，这是一个操作挑战。
从规模上讲，这种重复增加了成本和运营成本。组织在多个平台之间为接收、存储、安全和处理重复付费，而其他副本的边际价值下降。
因此，现代数据架构正在转向最大限度地减少数据移动并直接在源头实施治理的模式。零复制集成和聚合数据访问使组织能够在不复制敏感数据集的情况下生成见解，从而为企业数据协作提供了更具可扩展性、安全性和策略一致性的方法。
### 数据网格和数据结构的出现
为应对这些压力，行业围绕两个互补的架构模式进行了整合：数据网格和数据结构。它们共同代表了从集中控制向聚合的、域感知的数据架构的转变。
数据网格将数据所有权下放给与领域一致的团队，例如销售、市场营销或供应链。每个域都将其数据视为产品，并清楚地定义了合同、质量标准和服务级别目标。该模型改善了问责制和业务一致性，但在企业级，它带来了跨域协调、互操作性和一致治理方面的新挑战。
数据交换矩阵通过提供连接层将分散的域绑定到一个连贯的系统中来应对这些挑战。它提供共享元数据、通用语义、自动化策略实施、谱系和治理，使数据能够被一致地发现、访问和治理，而不会迫使物理整合到一个存储库中。
数据网格和数据结构共同为联合数据访问奠定了基础。但是，它们没有解决关键的下一个问题：实现跨域和组织边界的安全、受控的协作，其中的数据必须被联合分析，而不能被复制或暴露。
### 洁净室的战略支点
随着企业数据的日益分散和隐私法规的日益严格，组织面临着一个核心的架构挑战。他们如何在不共享原始数据的情况下跨团队、合作伙伴和平台协作？传统的数据集成方法不适合这一级别的分发或监管审查，这造成了协作与合规之间的紧张关系。
这一挑战导致了向数据无尘室这一基础架构能力的转变。洁净室将协作从数据传输转向受管计算。分析和 AI 工作负载不是复制或交换数据集，而是通过共享元数据在数据已经存在的地方运行。根据隐私、同意和使用规则实时评估查询，并仅返回批准的聚合结果。
在此模型中，数据洁净室充当现代数据架构的 Trust 边界。它们允许组织与合作伙伴和子公司合作，而不会失去对其数据的控制，通过系统控制而不是仅通过策略来强制执行隐私和同意，并在尊重数据驻留和合同限制的情况下跨云运行。
对于激活、分析和 AI 用例，无尘室提供了一种安全的方式，从外部数据生成见解，而不会暴露敏感信息。它们实现了从数据共享到可信协作的转变。对于激活用例，无尘室提供了生成受众的安全方式，可以直接激活到允许的目标。所有这些都是在不向任何一方公开任何个人身份信息 (PII) 的情况下实现的。这标志着企业数据架构的一个转折点。数据洁净室不再是利基工具。它们正在成为聚合的、保护隐私的、AI 就绪的数据平台的核心基础设施。
## 相关方角色和技术护栏
成功的数据洁净室架构是一个多界面系统，旨在解决数据实用程序、安全性和速度的竞争压力。有三个主要角色，其独特的摩擦点必须通过基础技术设计来解决。
### 隐私与合规官员（风险缓解者）
隐私和合规管理人员将数据洁净室用作治理工具。他们最担心的是合规性偏差，即外部协作环境无法执行与内部系统相同的严格标准的风险。
* **摩擦点：**监管曝光（GDPR、CCPA、DMA）和“网络钓鱼”攻击，合作伙伴试图通过重复的粒度查询来三角测量用户的身份。
### 数据科学家和分析师（实用程序优化器）
数据科学家将数据洁净室视为高级建模的安全港。他们最关心的是实用程序保护，确保隐私措施不会使数据在统计上变得无用。
* **摩擦点：**对于机器学习 (ML)、类似建模和流失预测所需的粒度属性，高延迟和受限访问。
### 市场营销和业务用户（价值实现者）
此角色仅关注价值实现的时间 (TTV)。他们担心的是，数据洁净室项目通常会成为需要几周数据工程支持的技术瓶颈。
* **摩擦点：**复杂的设置流程、手动数据清理，以及需要编写代码才能获得简单重叠结果的“空白页”问题。
### “业务第一”角色模型
虽然传统架构侧重于在用户层之前构建数据层，但我们与“业务优先”方法一致的战略方法颠倒了这种模式。我们优先考虑无代码点击的方法，这允许业务用户生成见解并立即采取行动。
**“见解到行动”工作流：**该架构设计为活动工作区，而不是被动存储库。通过提供用例模板（例如，细分重叠、激活和市场活动绩效），我们使业务用户能够自助获取见解。这确保了见解（例如优化的类似细分）可以立即在整个营销生态系统中激活，而无需数据工程师手动移动文件。
**零复制联盟作为战略资产：**为了最大化 TTV，该架构采用了零复制逻辑。与传统的引入延迟和安全风险的 ETL 流程不同，我们的架构将查询直接聚合到数据所在的位置（例如，Snowflake、BigQuery 或 Amazon S3）。这将组织的现有数据投资转化为战略资产，允许业务用户实时处理最新数据，同时保持严格的管理并消除数据冗余的成本。
## 关键数据洁净室用例
数据清理室出现在广告中，作为对 Cookie 弃用和隐私条例的回应，但已经发展到跨行业的客户分析、受众细分和激活用例。根据 2025 年零售媒体状况报告，66% 的组织现在以某种容量使用洁净室，这主要是由于需要隐私安全的协作来提供可衡量的业务成果。
各部门的模式是一致的：数据归其所有者所有，计算受控制，并且只共享隐私安全的见解。
### 市场营销和广告：不带第三方 Cookie 的测量
**挑战：**营销人员需要衡量市场活动的有效性，避免重复的广告印象，并优化覆盖范围/频率，但不能再依赖第三方 Cookie 或设备标识符。
**洁净室解决方案：**
* 广告商提供散列客户或市场活动曝光数据
* 发布者贡献印象和参与信号
* 洁净室计算覆盖范围、频率、属性和提升
* 通过批准的平台激活，无需导出原始数据
**业务成果：**无尘室提供将广告印象与实际交易联系起来的闭环归因、隔离真实市场活动的增量分析，以及跨渠道的统一测量 — 传统数字广告无法提供的功能。
**行业证据：**测量是当今最成熟的洁净室用例，Pinterest、Disney 和 Paramount 等主要媒体网络都创建了自己的洁净室。
### 零售媒体和 CPG：第一方数据的货币化
**挑战：**CPG 品牌在零售媒体上花费巨大，但缺乏购买结果的可见性。零售商拥有丰富的销售点数据，但必须违反隐私承诺才能公开这些数据。
**洁净室解决方案：**
* 零售商和 CPG 公司将零售位置的销售点数据与市场营销数据结合起来，优化促销活动
* 品牌贡献散列 CRM 或忠诚度标识符
* 无尘室链接广告曝光到店内/在线购买
* 激活保留在零售商的媒体生态系统中
**业务成果：**
* 零售商无需出售原始客户信息即可将第一方数据转化为货币
* 品牌获得闭环属性，显示哪些市场活动推动了购买
* 零售媒体网络的扩展没有隐私风险
**行业证据：**零售媒体网络，例如 Walmart 的 Luminate 和 Kroger Precision Marketing，提供洁净室，帮助 CPG 品牌使用零售商数据分析客户行为并优化营销策略。
### 金融服务：协作欺诈检测
**挑战：**欺诈网络跨机构运营，但由于 GLBA 等法规和新兴的隐私法，银行不能公开共享客户或交易数据。
**洁净室解决方案：**
* 多家银行汇集匿名数据，识别指示欺诈的模式，例如不寻常的跨银行活动
* 联合分析或模型在共享欺诈信号中运行
* 没有机构可以看到另一个机构的客户级别数据
**业务成果：**
* 更早发现跨机构欺诈模式
* 通过丰富的信号集减少误报
* 无需集中敏感数据的法规遵从性
**行业证据：**Experian 和 Trans Union 的金融服务解决方案提供洁净室技术，使银行和保险公司能够在欺诈检测和风险评估方面进行合作，同时保持严格的数据隐私控制。
### 医疗保健和生命科学：没有患者数据暴露的研究
**挑战：**制药公司需要真实患者结果进行药物开发，但数据驻留在医院 EHR 系统中，受 HIPAA 和类似法规的保护。
**洁净室解决方案：**
* 医生和药物研究人员在洁净室内共享数据，以了解患者对治疗的反应。
* 患者数据保留在提供商环境中。
* 研究人员通过洁净室进行批准的统计分析。
* 差异隐私会阻止重新识别。
**业务成果：**
* 统计上有效的按比例真实世界证据
* 通过将匿名患者数据与试验条件匹配，在不违反医疗隐私法的情况下找到合格的候选人，简化了临床试验的患者招募
* 减少对有限临床试验人群的依赖
**行业证据：**Datavant 等专注于医疗保健的洁净室为研究人员和医疗保健组织提供了符合 HIPAA 的环境，以便为临床试验和药物开发安全分析患者数据。
### 跨行业模式：协作的必要性
除了这些主要用例之外，洁净室还支持：
* **供应链优化：**制造商和供应商协作共享库存详细信息、生产计划和需求预测，从而在保护专有信息的同时实现更好的协调。
* **并购尽职调查：**当一家公司收购另一家公司时，尽职调查需要检查财务预测和客户数据库，而无需直接共享敏感信息；无尘室揭示了客户细分的一致性和合规风险等见解。
* **媒体和娱乐：**发布者向广告商证明了受众价值，同时保护了订阅者的身份，实现了由可信评测支持的优质 CPM，而不是概率定向
在 AdTech、零售、金融服务、医疗保健和媒体领域,Data Clean Room 已成为基础 Trust 基础设施。它们实现了以前被隐私、监管或竞争约束所阻止的高价值协作。洁净室是**核心架构组件**，可实现安全的受管协作 — 在不放弃数据控制或合规性的情况下释放见解和实现货币化。
## 数据洁净室：可信数据协作的基础
数据无尘室是一个安全的受管环境，它使多方能够在不公开或交换原始数据的情况下产生联合见解。批准的分析、AI 和激活工作负载会就地执行，并仅返回符合策略的输出，而不是复制数据集。在激活需要个人级记录时，数据会直接传递到预期目标，而不会暴露给协作方。
在架构上，洁净室将协作从数据共享转移到受控计算。每个参与者保留对其数据的保管，而运行时强制执行控制查询行为、输出约束、同意和使用策略。
通过保护隐私的标识符对齐机制，进一步实现了协作，允许来自不同方面的数据集进行关联，而不会暴露基础标识符 — 本文档后面将更详细地介绍这一功能。
因此，数据无尘室是隐私监管的多云 AI 驱动企业的基础基础设施，这些企业基于零复制、聚合数据策略运营。
早期的数据清理室遵循集中的“掩体”模式。所有参与者都需要将数据复制到中立的第三方环境中进行分析。这种方法虽然在概念上简单明了,但引入了严重的摩擦。数据移动增加了延迟和成本，使法律和合规协议复杂化，并迫使组织放弃对敏感数据的直接控制。在受监管的行业中，这些权衡往往使协作不切实际。
现代数据洁净室已经向分布式的联盟模式发展。数据保留在所有者的环境中，分析通过联合查询执行到位。洁净室本身作为治理层，拦截每个查询，在执行时强制执行隐私和策略控制，并仅返回批准的汇总输出。
| 维度 | 传统无尘室 ( " 地堡"模型) | 现代洁净室（分布式/联合模式） |
|---|---|---|
| 数据位置 | 数据被复制到集中的第三方环境中 | 数据保留在所有者的环境中 |
| 数据移动 | 需要物理传输和复制数据集 | 没有原始数据移动，查询运行到位 |
| 控制和监管 | 部分放弃给第三方平台的监护 | 各方保留的原始数据所有权和保管权 |
| 架构模型 | 集中聚合 | 分布式联合计算 |
| 治理执行 | 移动数据后应用的策略 | 在查询执行时强制执行的策略 |
| 隐私模型 | 严重依赖合同和程序控制 | 通过运行时控制和聚合阈值在技术上强制执行 |
| 延迟 | 由于摄取和同步而导致更高的延迟 | 更低的延迟，近乎实时的联合查询 |
| 成本结构 | 更高的存储、转移和复制成本 | 减少重复，计算发生在数据驻留的地方 |
| 合规性复杂性 | 由于跨境数据移动而导致的复杂法律协议 | 简化合规性，因为数据不会离开源边界 |
| 可扩展性 | 扩展需要更多的存储和数据复制 | 在不复制数据的情况下扩展分布式计算 |
| 监管行业适应性 | 由于监护和居住问题，通常不切实际 | 更好地与主权、同意和监管约束保持一致 |
### 可扩展数据洁净室的平台基础
在基础设施层，Salesforce Data 360 在 Hyperforce 上运行，Hyperforce 是 Salesforce 的云原生运行时，在统一控制平面后抽象超大规模资源（AWS、Azure、GCP）。此架构允许数据保持在区域内，以满足主权和居住要求，同时支持全球受管洁净室操作。
重要的是，此基础支持跨云洁净室协作，包括与 AWS 洁净室的本机互操作性。使用 Data 360 作为编排和治理层，企业可以与直接在 AWS 上操作的合作伙伴协作，而不会强制将数据迁移到 Salesforce 管理的存储中。查询被推送到源位置，隐私规则被一致地强制执行，并且只有合规的聚合结果在平台之间交换。
合规性和 Trust 在基础设施和执行边界强制执行，而不是在应用程序层改造 — 为大规模多云、多方协作提供了持久的基础。
### Data 360 从摄取到激活的漏斗
Data 360 实施可跟踪的端到端数据漏斗，确保无尘室操作基于协调的、受治理和身份感知的数据，而不是原始提取。
关键阶段包括：
* **连接**:通过现成的连接器、API、SDK、MuleSoft 或零复制连接器进行数据接收和虚拟化
* **保留**:以本机格式存储原始数据 (Parquet / Iceberg)
* **协调**:映射到规范数据模型对象 (DMO)，以实现一致的连接
* **统一**:身份解析创建 Golden Records
* **派生见解**:计算见解计算受管边界内的聚合度量
* **行动**:受管输出流向 Salesforce 组织、营销平台、广告网络、外部数据平台**或其他洁净室**，结束见解到行动的循环
此漏斗确保洁净室根据企业级数据运行，而不是临时提取。
### 本地集成和“点击-非代码”
与需要单独配置和 SQL 开发的独立数据洁净室平台不同，Salesforce 洁净室本地嵌入到 Data 360 中。这支持重复使用 DMO、身份规则、同意模型和治理策略，消除了重复的安全层。
Salesforce 的模板驱动的洁净室模型是一个密钥加速器，使用：
* **现成的模板**，支持常见的协作模式，例如受众重叠、抑制、覆盖范围和提升测量。
* **自定义模板**允许架构师和高级用户定义针对行业或合作伙伴特定需求的可重用分析逻辑，而不会暴露原始数据或策略复杂性。
这种方法标准化了协作，同时仍然允许灵活性，使洁净室能够作为可重复的企业功能进行扩展，而不是一次性的分析项目。
### “黄金之路”- 结束见解到行动的循环
Data 360 解决了传统洁净室的常见故障模式：激活间隙。其 Golden Path 框架确保可以立即对洁净室内生成的见解采取行动，而无需导出原始数据。
* **设置和发现**:合作伙伴共享模式元数据，并利用模板在合同最终确定之前评估可行性。
* **分析**:预构建和自定义模板推动了重叠分析、抑制、类似建模和提升测量，所有这些都在受管边界内执行。
* **激活**:批准的细分会直接推送到 Marketing Cloud、广告平台或合作伙伴系统，并仅共享聚合的合规结果。
模板成为意见明确的执行路径，确保协作从分析到激活可以预测。
## Salesforce Data 360 洁净室操作手册
部署 Salesforce Data 360 Clean Room 不仅仅是一项配置练习，它还是一项严格的架构工作流，跨越数据就绪、治理设计、安全连接和运营监控。
### 步骤 1：定义协作用例（从意图开始）
在接触数据或配置之前，架构师必须明确界定：
* 我们要回答什么问题？
* 预期的结果是什么？（例如，重叠分析、提升测量、抑制、欺诈检测）
* 需要什么级别的聚合？
* 适用哪些法规或合同约束？
* 什么激活路径会使用结果？
了解协作者的目标会决定接下来的一切 — 连接密钥、身份规则、治理阈值和成本建模。无尘室是专门构建的环境。嘿，应该围绕定义的分析目标进行设计，而不是通用的数据泄露。
### 步骤 2：为洁净室协作准备数据
在协作开始之前，企业数据必须在结构和语义上做好准备。洁净室放大了基础数据的优势和劣势。垃圾扔进来,垃圾扔出去 在这里更真实
**摄取：**将源系统（例如 Salesforce CRM、Marketing Cloud、AWS S3 和 Google Cloud Storage）连接到 Data 360。尽可能使用零复制连接器（例如 Snowflake），以避免不必要的数据移动或重复。
**语义映射：**将数据流映射到 Customer 360 数据模型。将电话号码（E.164 格式）、国家/地区/州代码（ISO 标准）和电子邮件地址等关键字段标准化。不对齐（例如，一方使用“CA”，另一方使用“California”）会静默地失败连接，并降低匹配率。
**身份解析：**配置确定性（精确匹配）和概率性（模糊匹配）规则，以创建统一个人（黄金记录）。该统一实体是洁净室匹配的表面。
身份解析的质量直接影响协作价值。更高的匹配精度提高了重叠率、分析置信度，并减少了假阴性。
### 步骤 3：配置洁净室
在数据协调后，必须配置洁净室本身来定义协作边界。
**许可证验证：**请确认所有参与组织都拥有必要的 Data 360 和无尘室权利。
**数据空间范围：**洁净室对象必须限定在特定数据空间的范围内。只有映射到该数据空间的对象对洁净室可见。这确保了协作在逻辑上是隔离的，而无需仅为洁净室创建新的数据空间。
**定义治理规则：**在执行查询之前，以声明方式建立策略：
* **聚合阈值：**例如，每个输出至少 100 个记录
* **连接键：**例如 Email_Hash_SHA256
* **允许操作：**仅聚合函数，例如计数、求和、AVG
* **显式限制：**阻止行级导出（选择 \*）
治理规则在执行时强制执行，使隐私和合规成为系统级属性，而不是程序指导。
### 步骤 4：建立安全的多方连接
洁净室通常跨越组织和平台边界。连接必须明确，并严格控制。
**客户链接：**
* **Salesforce 到 Salesforce：**使用 Data Cloud One 或批准的跨组织共享机制。
* **多云场景：**在启用查询之前，验证区域对齐和驻留。
**身份验证和授权：**为具有最低权限原则的专用集成用户配置基于 OAuth 的访问 — 将访问严格限制在必要的数据空间，并避免管理权限。
安全故障通常由权限过大的集成用户造成，而不是由加密或平台控制中的弱点造成。
### 步骤 5：运行、监控和控制洁净室工作量
上线后，重点转移到运营监督、查询质量和成本管理。
**查询执行：**分析师或工作流通过计算见解或批准的 SQL 界面执行重叠分析和聚合。所有查询会自动强制执行聚合阈值和隐私控制。
**审计和可追溯性：**Salesforce Data 360 洁净室以审计数据模型对象 (DMO) 的形式提供审计跟踪。这将捕获有关查询活动的元数据，包括谁执行了查询、查询何时运行以及应用了什么策略。审计 DMO 支持合规报告、治理验证和取证可追溯性 — 确保协作既隐私安全又可审查。
**消耗监控：**Data Cloud 使用基于消耗的信用模型。关键驱动因素包括：
* 已处理行（例如，1M 行 = 基准信用单位）
* 查询复杂性
* 身份解析操作（更高的乘数）
* 批量摄取（较低的乘数）
**数字钱包和提醒：**使用 Digital Wallet 跟踪实时消耗，并在 50%、75% 和 90% 阈值时配置警报。将峰值与特定工作负载进行关联，以避免意外成本。
请注意，零复制不会降低计算成本。在删除物理重复时，将在源系统上执行。架构师必须管理查询模式、联接选择性和执行频率，以控制成本和性能。
## 治理、安全和合规
### 大规模构建适用于 Trust 的洁净室
在现代企业中，Trust 不会绑定到数据洁净室。这是一个架构结果。Salesforce Data 360 持续自动地实施治理、安全和合规，将洁净室从策略驱动的环境转移到平台治理的系统。
无论协作发生在 Salesforce 内部、合作伙伴之间还是云之间，执行时间控制（锁定的身份、审计跟踪和差别隐私）都一致适用。
### 执行时间Trust和治理
架构师最重要的转变是Trust是在执行过程中强制执行的，而不是事先假设的。Salesforce Data 360 通过一些核心平台控制来实现这一点：
* **锁定身份：**合作伙伴访问权限以加密方式与已验证的 Salesforce 组织身份绑定，防止欺骗或未经授权的参与。
* **审计跟踪：**记录每个查询、联接、细分重叠和激活，以实现完全的可审计性和监管合规性。
* **差别隐私：**行级检查在结构上是不可能的。对输出进行汇总和统计边界。协作者只能看到隐私安全的结果，例如到达度量或提升百分比，而不能看到个人交易或身份。
这些控制用数学保证和平台级强制执行取代了 contract Trust，降低了运营和法律风险。
### 通过 Einstein Trust 层的 AI 治理
随着 AI 客服人员越来越多地与洁净室数据进行交互，Salesforce 引入了 Einstein Trust 层。它充当敏感企业数据和外部 LLM 之间的架构气闸。这确保了洁净室见解可以安全地为 AI 驱动的决策提供支持，而不会暴露基础数据。
**主要功能：**
* **零数据保留：**发送到 LLM 的数据是短暂的。模型提供商无法存储培训的提示或响应。
* **毒性语言检测和 PII 屏蔽：**输入和输出会自动扫描，PII 根据 Data 360 中配置的数据屏蔽策略进行屏蔽。
### 通过数据空间和权限集进行逻辑隔离
**数据空间**在组织内提供逻辑隔离，并应符合监管、地理和合作伙伴关系边界，例如：
* 欧盟数据空间
* 北美数据空间
只有分配到数据空间的数据集在其洁净室内可见，防止意外的跨界暴露。
权限集提供了对谁可以创建或管理洁净室、执行查询或激活细分的精细控制。数据感知权限在数据模型对象中强制执行字段级限制，例如，营销人员可能看到细分名称和受众规模，但看不到收入或健康指标。
安全性在语义层强制执行，允许业务用户使用安全的自助服务，而无需持续的 IT 监督。
### 合规性和设计同意
同意信号通过 Data 360 自动传播到洁净室执行。默认情况下，撤销同意的用户被排除在分析和激活之外 — 确保合规性是系统强制执行的，而不是手动监管的。
Salesforce Data 360 将治理、安全性和合规性视为一流的架构原素，而不是可选的加载项。通过将执行时间可审计性、锁定身份、差别隐私、数据空间、同意感知身份解析和 Einstein Trust 层结合起来，企业可以在合作伙伴、多云系统和 AI 驱动的工作负载之间扩展洁净室协作，所有这些都不会影响 Trust、隐私或监管合规性。
## 结论和前进道路
### 架构师的实用前进之路
要获取数据洁净室的全部价值，架构师必须将它们视为核心架构基础设施，而不是孤立的分析工具。以下优先级定义了一条务实和可扩展的前进道路：
**使协作成为一流的架构问题：**外部数据协作的设计应与内部集成具有相同的严谨性。洁净室应与数据平台、集成层和 AI 系统一起嵌入企业参考架构，而不是作为临时扩展进行部署。随着互操作性的扩展（例如，Data 360 洁净室与 AWS 洁净室的集成以及未来的跨洁净室兼容性），架构师必须设计预测多平台生态系统的协作模式，而不是单供应商孤岛。
**默认在源位置设计隐私**
**设计数据流动性：架构师应该首先考虑联合和零复制访问,**而不是默认设置为繁重的 ETL 和中央复制。将计算移到数据（在适当时）可以减少不必要的重复，降低成本，并保持真相来源的完整性。“连接与复制”应该是有意识的架构决策，而不是继承的习惯。
**缩小见解到行动的差距 :**停留在分析上的洁净室无法提供业务价值。架构必须将洁净室输出本地连接到激活系统和 AI 工作流。反馈循环、性能测量和下游执行必须从一开始就设计。
**准备 Agentic Enterprise：**随着 AI 客服人员越来越多地使用企业数据，无尘室将作为受控执行环境，客服人员可在其中操作，而不会暴露原始数据。将洁净室战略与 AI 治理和 Trust 框架相协调的架构师将是下一阶段的最佳人选。
### 结论
现代数据洁净室代表了企业数据架构的根本转变。它们通过在不暴露数据的情况下进行协作，解决了数据效用和隐私之间的长期紧张关系。
Salesforce Data 360 等架构表明，这种权衡不是“非此即彼”的考虑。通过零复制模式将数据存储与激活分离，并将隐私增强技术直接嵌入执行，企业可以在不放弃对其数据的控制的情况下就高价值分析进行协作。隐私从合同义务转变为架构保证。
最重要的是，无尘室将数据从静态的孤立资产转换为受管的可操作资源。当本地连接到激活和 AI 层时，见解不再停留在仪表板中。它们直接流向决策、市场活动和自主系统 - 在企业规模上关闭数据、操作和结果之间的循环。
## 关于作者
**Yugandhar Bora** 是 Salesforce 的软件工程架构师,专门从事数据和智能应用程序平台中的数据架构。他领导企业架构审查委员会 (EARB) 专注于数据治理和统一数据模型的举措，同时为自动化平台配置解决方案做出贡献。
**Birendra Kumar Singh** 是 Salesforce 技术人员的主要成员,专门从事 Data 360 中的平台和数据架构。他是激活平台的核心成员，并领导了“洁净室”计划，该计划专注于为 Data 360 客户提供数据洁净室基础设施。
**Priyanka Kshirsagar** 是 Salesforce 的高级产品经理，领导 Data 360 Clean Room — 她从头开始构建这一功能，使企业客户能够在保护隐私的环境中协作处理第一方数据。她推动了基于客服人员的 AI 和 ML 用例的愿景，包括在洁净室上进行类似建模和身份丰富，并已通过普遍上市和一级 Dreamforce 发布会将该产品推向市场。
# 概览
现代 Salesforce 集成必须支持远远超过简单的数据交换。它们有望支持实时客户体验，协调多个系统之间的操作，并在企业级可靠地运行，同时满足严格的安全和合规要求。因此，选择正确的集成方法是一项关键的架构决策，而不是实施细节。
考虑常见的企业场景。客户在移动应用程序中完成购买，触发个性化优惠的实时资格检查。同时，必须在 ERP 系统中记录交易数据，在 Salesforce 中更新客户属性，并将分析流式传输到数据湖，而不会引入延迟、数据重复或合规风险。像这样的场景现在在现代 Salesforce 环境中很常见，Salesforce 很少孤立地运行，必须与更广泛的应用程序和数据平台生态系统无缝集成。
本指南旨在帮助架构师和开发人员清晰自信地设计这些集成。它提供了一组经过**验证的集成模式**,用于解决重复性的企业场景,例如流程编排、数据同步和实时数据访问,而不是专注于点对点的实施。每个模式都强调架构意图、权衡和执行模型，使团队能够做出明智的设计决策，并不断扩展。
在本文档中，您将找到：
* 代表跨流程、数据和虚拟访问场景的通用企业“文件类型”的集成模式
* 模式选择框架，帮助根据集成意图和执行时间确定正确的方法
* 关于可扩展性、弹性、治理和安全注意事项的实用指导
* 从实际 Salesforce 和 Data 360 实施中提取的最佳实践
本文档的目标是为集成提供共享架构语言，帮助团队设计平衡性能、灵活性和 Trust 的解决方案，同时与企业数据和治理战略保持一致。
## 目的和范围
本文档适用于需要将企业中其他应用程序的数据与 Salesforce Data 360（以前的 Data Cloud）集成的设计者和架构师。此内容是 Salesforce 架构师和合作伙伴许多成功实施的提炼。
要熟悉大规模采用 Data 360 可用的集成功能和选项，请阅读以下模式汇总和模式选择指南部分。架构师和开发人员应该在 Data 360 的数据交互项目的设计和实施阶段考虑这些模式详细信息和最佳实践。
如果实施正确，这些模式使您能够尽快投入生产，并拥有尽可能稳定、可扩展和免维护的应用程序集。Salesforce 自己的咨询架构师在架构审查期间将这些模式用作参考点，并积极维护和改进它们。
与所有模式一样，本内容涵盖了大多数集成场景，但不是全部。例如，虽然 Salesforce 允许用户界面 (UI) 集成，但此类集成不属于本文档的范围。
### 模式模板
每个集成模式遵循一致的结构。这使得每个模式中提供的信息具有一致性，也使得比较模式更加容易。
* **名称**:模式标识符，也指示模式中包含的集成类型。
* **上下文：**模式解决的整体集成场景。上下文提供有关用户尝试完成什么以及应用程序如何行为以支持要求的信息。
* **问题：**用问题表示，这是模式设计解决的场景。阅读本节，了解模式是否适合您的集成场景。
* **强制：**使所述场景难以解决的约束和环境。
* **解决方案：**解决集成场景的推荐方式。
* **草图：**UML 序列图，向您展示了解决方案如何解决场景。
* **结果：**解释如何将解决方案应用到集成场景的详细信息，以及它如何解决与该场景相关联的因素。本节还包含应用模式后可能出现的新挑战。
* **侧栏：**与模式相关的其他部分包含关键技术问题、模式的变体、特定于模式的注意事项等。
* **示例：**真实场景，描述了如何在真实 Salesforce 场景中使用设计模式。该示例解释了集成目标以及如何实施模式来实现这些目标。
## 模式汇总
将此表用作本文档中所含集成模式的目录。
### 模式列表
| 模式级别 1 | 模式级别 2 | 模式 | 场景 |
|---|---|---|---|
| 数据接收模式 - 数据入站 | 批量摄取模式 | 从云存储批量接收数据 | 数据以大量原始数据（例如交易或产品日志）的形式从 Amazon S3、Azure Blob 或 Google Cloud Storage 等企业云存储源接收到 Data 360 中。 |
| 从 Salesforce Cloud 批量接收数据 | Data 360 从多个 Salesforce 组织（例如 Sales Cloud、Service Cloud）批量接收 CRM 数据，以构建统一的客户简档。 | ||
| 流和实时接收模式 | 通过摄取 API 的事件驱动摄取 - 流 | Data 360 订阅流接收端点，这些端点从企业系统接收连续的事件负载（例如，购买事件、IoT 遥测），用于实时简档更新。 | |
| 实时 Web 和移动行为摄取 | Data 360 通过 SDK 收集和处理实时网站和移动应用程序行为数据，以丰富参与度量和个性化模型。 | ||
| 通过流实现近乎实时的 CRM 同步 | Data 360 通过事件流近乎实时地接收 CRM 数据更新（例如联系人、个案、业务机会变更），以保持连续同步的 Customer 360 视图。 | ||
| 从云消息传递平台接收事件流 - Kinsis 和 MSK | Data 360 直接从云事件平台（例如 AWS Kinesis 或 Kafka (MSK)）使用流数据，以处理高频运营或 IoT 事件。 | ||
| 零复制模式 - 入站和出站 | 入站零复制 — Data 360 的外部平台 | Data 360 通过零复制接收按需查询外部数据集（例如 Snowflake、BigQuery），而无需将数据物理地移动到 Salesforce 中。 | |
| 出站零复制 — Data 360 到外部平台 | 外部系统（例如数据块或 Tableau）通过零复制出站连接访问 Data 360 中的丰富细分和见解，而无需数据复制。 | ||
| 使用 Data Cloud One 的统一多组织数据平台 | Data Cloud One 将多个 Salesforce 组织和外部数据源统一在一个共享元数据和语义模型下，提供一致的 Customer 360，没有数据重复。 | ||
| 数据激活模式--数据出站 | 批量激活模式 | 市场营销和广告平台的细分激活 | Data 360 将策划的客户细分直接激活到 Marketing Cloud、Meta、Google Ads 或其他广告平台，以实现个性化市场活动交付 |
| 数据导出到云存储 | Data 360 将统一或筛选的数据集（例如，同意的客户记录）作为 CSV 或 Parquet 文件导出到 Enterprise Cloud Storage，用于分析或合规归档。 | ||
| 基于按需 API 的激活 | 通过 Connect API 进行自定义应用程序集成 | 外部应用程序实时调用 Data 360 Connect API，根据当前客户数据检索或触发个性化操作（例如，忠诚度余额检查或 AI 优惠生成）。自定义构建的 Web 或移动应用程序通过 Connect REST API 安全地检索协调的 Data 360 见解，以在企业或合作伙伴 UI 中显示。 | |
| 通过数据图 API 完成客户简档检索 | 系统使用数据图 API 检索客户的统一简档，并返回完整 360° 视图的预连接实时 JSON 表示，以供决策或个性化。 | ||
| 实时数据操作 | 将客户信号转化为即时操作的实时数据操作 | Data 360 检测并处理实时事件（例如同意更新、购买触发器），并立即调用连接的系统或 Salesforce 流进行下游操作。Data 360 中的客户活动信号（例如检测到的流失风险）会触发即时实时操作，例如更新 CRM、调用 Einstein 评分或启动保留过程。 |
| 类型 | 时间 | 出站注意事项 |
|---|---|---|
| 数据集成 | 异步 | 市场营销和广告平台的细分激活 |
| 流程/数据集成 | 同步 | 通过 Connect API 进行自定义应用程序集成 通过数据图 API 完成客户简档检索 |
| 数据集成 | 同步 | 将客户信号转化为即时操作的实时数据操作 |
| 虚拟集成（使用 Zero Copy） | 异步 | 出站零复制 — Data 360 到外部平台 |
| 虚拟集成 | 异步 | 使用 Data Cloud One 的统一多组织数据平台 |
| 类型 | 时间 | 入站注意事项 |
|---|---|---|
| 数据集成 | 异步 | 从云存储批量接收数据 从 Salesforce Cloud 批量接收数据 |
| 数据集成 | 异步 | 从云消息传递平台接收事件流 - Kinsis 和 MSK 通过流实现近乎实时的 CRM 同步 |
| 流程集成 | 同步 | 通过摄取 API 的事件驱动摄取 - 流 实时 Web 和移动行为摄取 |
| 虚拟集成 | 异步 | 入站零复制 — Data 360 的外部平台 |
| 术语 | 定义 |
|---|---|
| 事件处理 | 事件处理是指从源系统或应用程序接收、路由和响应可识别的事件。中间件通过识别目标端点、转发事件和触发所需的业务操作（例如，记录、重试或激活下游服务）来处理事件。在 Data 360 架构中，事件处理对于实时数据接收、激活触发器和发布/订阅模式至关重要。事件可能来自外部系统（Kafka、AWS Kinesis）或 Salesforce 平台事件，由中间件或 Data 360 事件总线路由，以便立即处理。 |
| 协议转换 | 协议转换允许使用不同的数据传输标准在系统之间进行通信。中间件将专有或传统协议（例如 AMQP、MQTT、FTP）转换为支持的 Data 360 协议（REST、gRPC 或 HTTPS）。这确保了异构系统之间的互操作性。由于 Data 360 不本地处理协议转换，中间件提供适应层，将消息封装或转换为 Data 360 API 和连接器可以解释的格式。 |
| 翻译和转换 | 翻译和转换通过将一种数据格式或模式映射到另一种格式或模式来确保互操作性。中间件执行这些转换，将各种数据负载（CSV、XML、JSON）与 Data 360 数据模型对象 (DMO) 和统一数据层对象 (UDLO) 保持一致。这包括在摄取前清理、丰富和应用基于语义或本体的映射。虽然 Salesforce 提供转换工具，例如数据准备模式，但复杂的转换（特别是语义协调）最好在中间件中处理。 |
| 排队和缓冲 | 队列和缓冲依赖于异步消息传递，以确保弹性、解耦的通信。中间件平台（例如 MuleSoft、Kafka 或 Azure Event Hub）提供持久队列，在 Data 360 或下游系统繁忙或无法访问时临时存储数据。这可以防止数据丢失，并支持近乎实时的接收或激活重试。Data 360 支持流接收和基于流的出站消息传递，但持久排队和保证交付通常由中间件处理。 |
| 同步传输协议 | 同步传输协议涉及阻止、实时请求/响应操作。发件人在继续之前等待回复。在 Data 360 中，它们用于基于按需 API 的激活、实时丰富或简档查找，其中需要立即响应。中间件确保连接的可靠性，并管理同步 Data 360 API 调用的重试或后备处理。 |
| 异步传输协议 | 异步传输协议支持非阻塞、解耦通信，其中发送方继续处理，无需等待响应。中间件处理异步流，用于批量激活、流接收和事件驱动的激活。这允许高吞吐量和弹性 — 对于 Data 360 中的事件流和近乎实时的数据接收模式至关重要。 |
| 调解路由 | 中介路由定义了系统之间的复杂消息流，确保正确的数据或事件到达正确的消费者。中间件充当中介，根据规则、标题、内容或事件类型处理路由逻辑。在 Data 360 集成中，中介确保事件和简档更新从多个系统正确路由到数据接收 API、激活端点或外部消费者。这简化了编排，并支持多系统数据同步。 |
| 流程编排和服务编排 | 流程编排和协调多系统流程。编排支持自主、异步的事件驱动流，其中系统基于共享规则运行，无需中央控制器。编排是指导服务执行的集中受管流。在 Data 360 架构中，中间件管理跨系统的接收和激活编排，而 Salesforce 工作流或流处理平台中的轻量级编排。建议在中间件层进行复杂的编排，需要事务协调或状态管理。 |
| 事务性(加密、签名、可靠交付、事务管理) | 事务性确保跨系统的原子、一致、隔离和持久 (ACID) 操作。Salesforce 和 Data 360 在其边界内是事务性的，但不支持跨外部系统的分布式事务。中间件处理全局事务控制，包括加密、消息签名、回滚、补偿和可靠交付。对于任务关键型数据流（例如财务或同意更新），中间件可确保 Data 360 和外部系统的端到端完整性和恢复。 |
| 路由 | 路由指定组件之间的受控消息或数据流。它可以基于标题、内容类型、优先级或规则。中间件处理涉及 Data 360 的事件和激活的路由逻辑，例如将丰富的受众细分定向到不同的下游系统（广告平台、仓库、CRM 应用程序）。虽然路由可以在 Salesforce（Apex、流）中实施，但中间件路由是可扩展性、灵活性和治理的首选。 |
| 提取、转换和加载 (ETL) | ETL 包括从源系统提取数据，将其转换为一致的模式，并将其加载到目标中（例如 Data 360）。中间件或 ETL 工具会在数据接收前处理这些操作。Data 360 可以通过 API、连接器或批量接收漏斗接收 ETL 输出，还支持变更数据捕获 (CDC) 实现近乎实时的同步。在 Data 360 中统一之前，中间件 ETL 流程对于集成原有系统和确保数据质量至关重要。 |
| 长期投票 | 长轮询 (Comet 编程) 是一种保持系统之间开放通信的方法，用于实时更新。客户端发送请求，服务器保持该请求，直到事件发生，然后响应并重新打开新连接。Salesforce 在流 API 和 CometD/Bayeux 协议中使用此协议进行事件驱动的数据同步。中间件可以订阅这些事件，并将其转发到 Data 360 进行实时接收或激活触发器，确保跨企业系统最小化延迟。 |
| 解决方案 | 适合 | 评论 |
|---|---|---|
| 使用本地云存储连接器（Amazon S3、Google Cloud Storage、Azure Blob Storage） | 最佳 | 这是对 Data 360\ 进行大规模、重复的基于文件的接收的推荐和最可靠的模式。本地连接器提供受管身份验证、模式映射，以及将数据直接移动到 Data 360 的数据湖对象 (DLO) 的安全性。非常适合延迟不重要的计划批处理加载（例如，每小时或每天计划）。 |
| 处理大型数据集（超出连接器限制） | 最适合预处理 | 每个连接器强制实施接收限制（例如，S3：100 万行或每个对象 50 GB）。对于较大的数据集，实施 ETL 预处理步骤，将数据分区到属于这些阈值的较小的文件/文件夹中。然后，配置多个数据流以并行接收每个分区，并在 Data 360 中使用批处理数据转换中的附加节点）将分区重新组合成统一的数据集。 |
| 安全和治理 | 最佳 | 所有连接器都支持通过云本地方法（IAM 角色、服务帐户或访问密钥）进行安全身份验证。为增加控制，请通过云提供商的允许列表限制对 Data 360 IP 范围的访问。数据传输通过加密渠道进行，文件在接收期间存储在临时的安全暂存层中。 |
| 何时不使用 | 次优 | 此模式不适用于：
|
在这种情况下：
* 管理员通过 Data 360 设置界面配置与云存储的连接（指定身份验证、存储桶详细信息、IAM 角色和白名单）。
* Data Cloud 设置界面使用云存储平台进行身份验证，验证凭据和访问权限。
* 管理员在 Data 360 中创建数据流，将数据流链接到云存储中的对象/文件夹，并定义接收计划。
* 在计划触发器上，数据流会从云存储平台请求源文件（例如 CSV、Parquet）。
* Cloud Storage 平台提供文件，包括所需的有效 schema_sample.csv 和其他符合命名约定的数据文件。
* 数据流将文件传输到 Data 360 中的内部暂存环境。
* Data 360 漏斗处理文件：使用 schema_sample.csv 中的模式定义验证结构、字段名称，如果高于摄取阈值（每个文件 1 亿行/50 GB），则划分负载。如果检测到大文件，将在外部执行预处理分区步骤（通知管理员下次运行）。
* 记录从暂存导入数据湖对象 (DLO)。
* 如果需要，并且对数据进行分区，请在批处理数据转换中使用附加节点来组合多个 DLO。
* Data 360 记录成功/失败，更新监控状态，并指示数据已准备好进行映射、协调和统一。
##### 结果
此模式的应用支持安全、按计划和大规模地将结构化或非结构化文件从 Enterprise Cloud Storage 平台接收到 Data 360。该过程是自动化、可扩展和具有弹性的 — 将原始数据交付到数据湖对象 (DLO) 中，该对象充当协调和映射到 Customer 360 数据模型的基础。
###### 摄取机制
接收机制取决于 Data 360 中定义的连接器和计划策略。
| 摄取机制 | 描述 |
|---|---|
| 本地云存储连接器（Amazon S3、GCS、Azure） | 建议从企业的云数据湖中直接接收 CSV 或 Parquet 格式的文件。这些连接器支持增量和完全刷新计划。例如，银行可以将客户交易文件从 S3 存储桶配置为每日同步到 DLO。 |
| 分区文件策略 | 对于非常大的数据集（超过 1 亿行或每个对象 50 GB），数据被划分为更小的逻辑集（例如，按月或地区）。每个分区都作为一个单独的数据流来管理，然后使用带有附加节点的批处理数据转换进行重新组合。 |
| 自动计划同步 | Data 360 提供声明性调度程序（每小时、每天或自定义节奏），可自动触发接收作业，确保数据新鲜，无需手动干预。 |
| 连接器类型 | 端点要求 |
|---|---|
| Amazon S3 连接器 | S3 存储桶包含适当的 IAM 策略和定义模式的 schema\_sample.csv 文件。 |
| Google Cloud Storage 连接器 | 具有统一命名约定的服务帐户凭据和存储桶访问权限。 |
| Azure Storage 连接器 | 访问密钥或基于 SAS 令牌的身份验证；blob 或文件夹结构必须遵循 Data 360 约定。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 解决方案拟合 | 最佳 | 在 Data 360\ 中使用本机 Salesforce CRM 连接器和 Marketing Cloud Engagement 连接器。从标准用例的入门数据包开始，并加快入门。对定制或特定于域的数据模型使用手动流自定义。 |
| 处理高度自定义的 CRM 实例 | 最适合映射研讨会 | 将入门软件包视为基准，并执行映射研讨会，以确定：自定义对象和关系。公式或计算字段。受管软件包扩展。对于繁重的公式字段，在前期 ETL 或 Data 360 转换中计算值，以最大限度地减少源组织上的 API 负载。 |
| 何时不使用 | 次优情况 | 如果出现以下情况，请避免此模式：您需要高频或实时事件接收（相反，使用流连接器、平台事件或零复制联合）。源组织的 API 容量有限，无法在没有限制或队列延迟的情况下保持计划的提取。 |
| 安全和治理 | 强制控制 | 最低权限原则 - 使用具有最低读取权限的专用集成用户。请勿使用组织范围的管理员。 身份验证 — 使用 OAuth 2.0 和连接的应用程序；定期轮换客户端密码并监控刷新令牌的使用。 审计和跟踪 — 记录所有接收运行、模式更改和连接器事件。将日志转发到 SIEM 或合规系统，以便审计就绪。 数据分类 — 使用 CEDAR 策略在发布后立即应用 PII/PHI 标记和基于属性的访问控制 (ABAC)，以强制执行屏蔽、同意和下游合规性。 |
在这种情况下：
* **管理员配置集成用户**，并在源组织中分配连接器权限集。
* **管理员配置** Data 360 设置中的连接器（通过 OAuth/连接的应用程序连接到 Salesforce CRM 和 Marketing Cloud）。
* **管理员创建数据流**，选择对象和数据扩展，选择完全或增量刷新，并设置计划。
* **在计划运行**时，Data 360 会从源请求模式和增量令牌。
* **源系统返回记录**（增量或完整负载）。Marketing Cloud 可能会提供提取；CRM 可能会返回 JSON/Query 结果。
* **Data 360 将文件**暂存到内部安全暂存区域，并根据映射的模式进行验证。
* **如果验证失败**，接收日志错误，提醒管理员并停止提交。如果验证成功，Data 360 会将记录原子性地提交到目标 DLO。
* 通过谱系、运行持续时间、行数和凭据使用情况更新**监控和审计日志**。如果触发阈值或错误，将向管理员发出警报。
##### 结果
核心客户关系和市场营销参与数据作为数据湖对象 (DLO) 引入 Data 360。这会产生：
* 包含简档、个案、业务机会和电子邮件/参与度量的**统一数据集**。
* **身份解析的基础**和统一个人简档的构建。
* 为下游协调、丰富、人工智能建模和激活做好**业务准备**,同时保持治理和可审计性。
###### 摄取机制
接收机制取决于 Data 360 中定义的连接器和计划策略。
| 机制 | 何时使用 |
|---|---|
| Salesforce CRM 连接器（本地） | 最适合标准/自定义 CRM 对象；支持完全刷新和增量刷新。 |
| Marketing Cloud 参与连接器（本地） | 最适合数据扩展、发送和跟踪提取；支持完全/增量模式。 |
| 入门数据包 | 加快常见销售/服务/市场营销对象的入门。 |
| 自定义流 + 预处理 | 在需要复杂转换或繁重模式规范化时使用。 |
| 连接器 | 端点要求 |
|---|---|
| Salesforce CRM 连接器 | 源组织必须允许连接的应用程序、OAuth 令牌和具有读取权限的专用集成用户。 |
| Marketing Cloud 连接器 | Marketing Cloud API 凭据或已安装软件包；数据扩展必须通过提取/API 公开数据。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 解决方案拟合 | 最适用于低延迟事件捕获 | 使用 Data 360 接收 API (串流 JSON) 推送单个事件或微型批处理。使用严格的 OAS 3.0 模式 (.yaml) 配置摄取 API 连接器。将批量 CSV 摄取用于更大、更不频繁的同步。 |
| 处理模式更改 | 严格/受管 | 模式更改正在中断：更新 OAS .yaml，对连接器进行版本化，并执行合同测试。如果生产者不能同时更改，实施滚动模式迁移。 |
| 何时不使用 | 次优 | 如果需要预处理（例如：重复数据消除、保证订单等），或对于非常大的批量负载（使用本机批量连接器或批量 ETL），则不理想。如果源无法生成模式有效的负载或无法进行安全身份验证，请使用替代接收方法。 |
| 安全和治理 | 强制性 | 将 OAuth 2.0 用于最低权限范围、更迭密钥、记录令牌使用情况。强制执行 TLS 1.2+，验证客户端 IP（如果需要），并确保负载 PII 标记。所有事件必须携带来源元数据（源、时间戳、模式版本、兑换密钥）。 |
**在这种情况下：**
* 外部系统通过 OAuth/JWT 向身份验证服务器请求身份验证。
* 身份验证服务器向外部系统返回访问令牌。
* 外部系统向 Data 360 接收 API 发送带有授权和 JSON 负载的数据接收 POST 请求。
* 摄取 API 通过暂存和验证模块验证请求模式和身份验证。
* 在方案/身份验证失败时：
* 错误返回到外部系统。
* 记录拒绝以进行监控和提醒。
* 成功验证时：
* 暂存并提交到数据湖对象 (DLO) 中的记录。
* 为监控记录的成功。
* 如果启用，数据会传播到实时数据图 (DMO)，触发下游工作流。
* 否则，通过标准批次或高延迟漏斗处理的数据。
* 接收 API 向外部系统确认成功。
* 监控组件会提醒管理员死信队列、拒绝率或延迟问题。
##### 结果
外部事件数据以低延迟被接收到 Data 360 DLO 中。当目标 DMO 是实时图表的一部分时，数据可用于即时细分、客服人员工作流、AI 模型和操作激活。这使得业务能够快速响应来自任何连接的系统的事件。
###### 摄取机制
接收机制取决于 Data 360 中定义的连接器和计划策略。
| 机制 | 何时使用 |
|---|---|
| 串流 JSON (摄取 API) | 单个事件、微型批处理、行为事件、点击流、IoT 遥测 — 在需要低延迟时。 |
| 批量 CSV（摄取 API 批量模式） | 较大的定期上传，延迟要求放宽。 |
| 边缘/中间件 | 在推送到摄取 API 之前，当您需要验证、转换、丰富或限制速率时使用。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 基于 SDK 的事件捕获 | 最佳 | 部署 Salesforce 交互 SDK（Web）或本地 SDK（移动设备）。这些轻量级库实时捕获和序列化用户交互，并附加元数据（会话 ID、时间戳、上下文）。 |
| 事件流漏斗 | 最佳 | 事件通过安全的 HTTPS 发送到 Marketing Cloud Personalization 的事件流服务。该层可以水平扩展，并针对低延迟传输 (<2s) 进行了优化。 |
| Data 360 集成 | 最佳 | Data 360 的个性化连接器订阅流摘要，近乎实时地将每个事件接收到数据湖对象 (DLO) 中。 |
| 数据模型映射 | 最佳实践 | 接收的 DLO 映射到 Customer 360 数据模型对象 (DMO)。这允许通过身份解析链接匿名和已知用户。 |
| 实时图形启用 | 可选/推荐 | 在实时图形中包含映射的 DMO，以便进行即时细分，通过 Einstein 或 Agentforce 工作流触发个性化操作。 |
| 何时不使用 | 次优 | 在以下情况下，此模式不理想：源数据是 Web 客户端和事件（改用摄取 API）。组织缺乏对 Web/移动客户端的控制。不需要实时行为跟踪（使用批量接收）。 |
| 处理模式更改 | 受管演进 | 事件模式会随着新交互的添加而变化。SDK 应版本化事件定义。向后兼容的更改（添加可选字段）是安全的；中断更改需要连接器重新配置和合同测试。 |
**在这种情况下：**
* 在 Web 或移动渠道中部署 SDK（用户交互捕获）。
* 使用租户 ID、环境和同意控制配置 SDK。
* 将捕获的 JSON 事件（元数据 + 属性）流式传输到 Marketing Cloud 流式端点。
* 在 Data 360 设置中，创建并配置租户的个性化连接器。
* 将事件引入 DLO，并在 Data 360 中映射 DLO → DMO。
* 在实时图形中启用 DMO，以便立即激活。
* 监控延迟、模式一致性、同意标志、吞吐量、错误率。
* 部署到生产环境，并持续监控。
##### 结果
持续、低延迟的行为事件流从数字渠道流向 Data 360。在几秒钟内，每个用户操作都可用于实时细分、预测建模或触发的个性化，从而实现真正的自适应客户体验。
###### 摄取机制
接收机制取决于 Data 360 中定义的连接器和计划策略。
| 机制 | 何时使用 |
|---|---|
| 交互 SDK（Web） | 从 Web 浏览器和 SPA 实时捕获。 |
| 移动 SDK | 从本地移动应用程序实时捕获。 |
| 个性化连接器 | Marketing Cloud 和 Data 360\ 之间的受管订阅。 |
| 实时图形映射 | 在细分、Einstein 和旅程中启用即时激活。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 基于 CDC 的流连接器 | 最佳 | 本地 Salesforce 机制；完全受管并与平台事件基础设施集成。 |
| 事件订阅和交付 | 最佳 | 连接器通过耐用的重放 ID 订阅 ChangeEvent 渠道（例如 /data/ContactChangeEvent）。 |
| 数据映射和模式演变 | 最佳实践 | 将流负载映射到相应的 DLO；处理元数据中的模式版本，以防止摄取中断。 |
| 重放和故障恢复 | 推荐 | 利用重放 ID 和幂等密钥来避免重复并从暂时错误中恢复。 |
| 混合模式（流 + 批处理） | 可选 | 对于不支持的对象或初始批量加载，将批量摄取与 CDC 流结合使用。 |
| 何时不使用 | 次优 | 在以下情况下，此模式可能次优：源对象未启用 CDC。用例不需要实时更新（批量即可）。源组织的网络出口受限或超出事件限制。 |
**在这种情况下：**
* Salesforce CRM 中发生更改（创建/更新/删除/取消删除）。
* CDC 将 ChangeEvent 发布到内部 Salesforce 事件总线。
* Data 360 CRM 连接器使用耐用的重放光标订阅事件总线。
* 事件负载会验证模式、权限和数据完整性。
* Data 360 将验证的事件写入映射的**数据湖对象 (DLO)**。
* 如果启用，映射的**数据模型对象 (DMO)** 会近乎实时地更新，从而支持细分和激活。
##### 结果
Data 360 维护关键 CRM 数据的连续同步镜像。
这将启用：
* 实时触发器（例如，在创建个案时启动 Journey）。
* 最新细分（例如，在客户状态更改时，将客户转移到“黄金”细分）。
* 基于实时 CRM 上下文进行更准确的分析和个性化。
###### 摄取机制
此模式的接收机制通过启用变更数据捕获 (CDC) 的 Salesforce CRM 连接器进行本地管理。Data 360 充当 CDC 事件流的订阅者，确保源 CRM 组织和 Data 360 之间的可靠、低延迟同步。
| 机制 | 何时使用 |
|---|---|
| 通过 CDC 传输流（首选） | 适用于需要近乎实时同步的所有支持的 Salesforce 标准和自定义对象。 |
| 混合模式（CDC + 批处理） | 对于尚未启用 CDC 的对象，或需要初始历史加载的对象。 |
| 重放订阅模式 | 用于在停机或部署后重新同步。 |
| 错误隔离模式 | 适用于测试和验证环境。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| Kinesis 本机连接器 | 最佳 | 与 AWS Kinesis 的第一方集成；支持持续的高吞吐量接收。 |
| MSK 本机连接器 | 最佳 | 具有 OIDC 和基于密钥的身份验证支持的受管 Kafka 接收。 |
| 模式映射和验证 | 最佳实践 | 上传模式 (.json/.avro)，定义事件结构；在摄取期间强制执行一致性。 |
| IAM 配置 | 推荐 | 分配对目标 Kinesis 流或 MSK 主题具有只读访问权限的最低权限 IAM 角色。 |
| 专用网络路由 | 可选 | 为安全的内部路由配置 PrivateLink/VPC 端点。 |
| 混合模式（流 + 批处理） | 可选 | 将流用于增量，将批量摄取用于回填或历史加载。 |
| 错误隔离模式 | 推荐 | 将模式拒绝和暂时错误路由到 DLQ 进行重放 |
**在这种情况下：**
* 应用程序或设备将事件发布到 Kinesis 流或 MSK 主题。
* Data 360 连接器使用 AWS 凭据或 OIDC 令牌进行身份验证。
* Connector 会持续轮询或订阅流。
* 事件被暂存，为模式和策略进行验证，然后提交到数据湖对象 (DLO)。
* 如果映射，数据模型对象 (DMO) 会近乎实时地更新以激活。
* 监控层跟踪度量、模式拒绝和延迟。
##### 结果
将结构化数据直接从 AWS Kinesis 或 MSK 持续、低延迟地接收到 Data 360。数据立即可用于：
* 身份解析
* 实时细分
* Einstein AI 激活
* Agentforce 驱动的触发器
消除了对批处理 ETL 的依赖，实现了与企业事件驱动的设计一致的基于流的架构。
###### 摄取机制
| 机制 | 何时使用 |
|---|---|
| Kinesis 连接器（首选） | 适用于需要连续接收高用量结构化数据的 AWS 本地流源。 |
| MSK 连接器 | 适用于在兼容 Kafka 的平台上运行事件漏斗的组织。 |
| 混合（流 + 批处理） | 用于增量事件摄取与定期批量加载相结合。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| Snowflake Zero Copy 连接器 | 最佳 | 第一方本地集成；通过 Snowflake 的数据共享或外部表 API 建立实时查询联盟。 |
| 数据块零复制连接器 | 最佳 | 支持直接实时访问增量湖中的表/视图；下拉查询在数据块运行时执行。 |
| 文件联合(Apache Iceberg/Delta/Parquet) | 新兴最佳实践 | Data 360 直接从对象存储中读取打开的表格式，无需外部计算依赖性。非常适合大规模数据集。 |
| 专用网络配置 | 推荐 | 使用 Salesforce 专用连接或 VPC 对等来实现安全的网络级联合。 |
| 身份验证和密钥管理 | 最佳实践 | 通过定期轮换和保管库管理，实施基于密钥或 OAuth 的安全身份验证。 |
| 模式注册 | 必填 | Data 360 检索外部模式，并将其映射到外部数据湖对象 (外部 DLO)。 |
| 受管元数据 | 推荐 | 所有外部 DLO 继承分类、同意和谱系元数据，以实现合规性可见性。 |
在这种情况下：
* 管理员在 Data 360 设置（Snowflake、数据块或文件联合）中配置 Zero Copy 连接。
* 建立安全身份验证和网络路由（专用连接/OAuth/密钥对）。
* 管理员创建数据流，选择外部源 — 浏览实时数据库、模式和表格。
* Data 360 不是复制数据，而是创建外部 DLO（数据湖对象）——引用实时表或冰山文件的元数据指针。
* 外部 DLO 映射到 Customer 360 实体（例如，Customer、Transaction、Product）。
* Data 360 在细分、激活或见解计算期间查询源。
* 所有访问、查询谱系和元数据都在 Data 360 Trust 层中进行审计。
##### 结果
* 外部数据保留在 Snowflake、数据块或 S3 中 — 没有 ETL、没有重复、没有额外的存储。
* Data 360 获得对企业级数据的实时读取访问权限，用于身份解析、计算见解和激活。
* 组织在现有治理、加密和合规框架下保持完全控制。
* 这种模式实现了真正的零复制体系结构 — 将本地访问的性能与联合存储的管理结合起来。
###### 调用机制
调用机制取决于为实施此模式选择的解决方案。
| 机制 | 何时使用 |
|---|---|
| Snowflake Federation（首选） | 适用于具有受管企业数据仓库的实时高性能查询联盟。 |
| 数据块联盟 | 适用于具有增量或 Parquet 备份数据集的统一分析和湖滨环境。 |
| 文件联合 (Apache Iceberg / Delta Lake) | 适用于对象存储中的大规模数据集，其中计算分离和成本优化是关键。 |
| 混合模式（零复制 + 摄取） | 当历史数据需要一次性接收，但实时数据可以通过 Zero Copy 访问时。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 数据共享创建 | 最佳 | 管理员在 Data 360 中创建数据共享，添加选定的 DMO 和 CIO（例如，统一个人、客户健康得分）。 |
| 目标配置 | 最佳 | 创建数据共享目标，指定 Snowflake 或数据块帐户标识符和身份验证参数。 |
| 共享发布 | 最佳实践 | 将数据共享链接到数据共享目标，以安全地发布。 |
| 仓库验收 | 必填 | 外部管理员接受共享，将共享对象具体化为仓库中的只读视图/表。 |
| 粒度访问控制 | 推荐 | 在 Data 360 中应用基于对象和角色的权限；与基于仓库级别的访问控制保持一致。 |
| 联合查询访问权限 | 最佳 | 分析师通过标准 SQL 查询实时共享数据；与本地仓库数据结合，用于下游分析和 ML。 |
| 文件联合选项 | 可选 | 对于大型数据集，利用基于 Apache Iceberg 的联盟进行直接 S3 或增量湖读取，而不依赖于计算。 |
**在这种情况下：**
* Data 360 管理员定义的数据共享包括统一客户和计算见解对象。
* 数据共享目标（Snowflake 或数据块帐户）使用安全凭据和治理策略注册。
* Data 360 发布共享；Snowflake/Databricks 管理员接受它。
* 共享数据在仓库中显示为安全的只读表。
* 分析师、BI 工具或 ML 漏斗查询实时统一的客户数据，无需复制或同步。
* 所有访问权限都在 Data 360 Trust 层和仓库治理日志中进行审计。
##### 结果
* 外部仓库可以实时、可查询地访问协调的 Data 360 数据。
* 消除了反向 ETL 漏斗，减少了操作负担和延迟。
* 直接在统一数据上启用 AI/ML 训练、预测建模和高级 BI。
* 保持零重复、强治理和按设计的安全访问控制。
* 完成双向零复制循环，其中入站联合和出站共享在单一治理模式下共存。
###### 调用机制
调用机制取决于为实施此模式选择的解决方案。
| 机制 | 何时使用 |
|---|---|
| Snowflake 安全数据共享（首选） | 当您的企业仓库是 Snowflake 并且您需要实时、有控制地访问统一的 Data 360 数据集而没有数据移动或重复时，请使用。非常适合需要零延迟共享和本地谱系强制的分析、AI 和合规驱动的工作负载。 |
| 数据块增量共享 | 当下游消费者在数据块或增量湖环境中操作，需要通过开放的增量共享协议对统一或激活的数据集进行实时只读访问时使用。 |
| 外部表共享 (Apache Iceberg / Parquet) | 当在对象存储（S3、ADLS 或 GCS）中维护开放格式的架构，并且需要跨分析引擎（例如 Athena、BigQuery 或 Snowflake-on-Iceberg）进行可互操作的低成本共享时使用。 |
| 数据共享 API（编程访问） | 当自定义应用程序或中间件（例如 MuleSoft）必须通过 API 安全地发现、订阅或使用共享数据集时，使用基于事件的刷新通知和细粒度的访问控制。 |
| 混合共享（零复制 + 出站共享） | 在实施双向交换模式时使用 - 将 Zero Copy 用于入站数据，将 Outbound Data Share 用于发布见解，确保跨企业数据平面的语义和治理一致性。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 家庭组织配置 | 最佳 | 指定一个 Salesforce 组织作为配置 Data 360 的家庭组织；这将成为中央数据存储库和治理中心。 |
| 同伴组织连接 | 最佳 | 通过 Data Cloud One 应用程序，配置从家庭组织到一个或多个配套组织的配套连接，无需自定义代码。 |
| 数据空间定义 | 最佳实践 | 定义家庭组织内的数据空间，以逻辑地细分数据（例如，零售、服务、市场营销）并隔离访问边界。 |
| 数据空间共享 | 最佳 | 明确共享从家庭组织到同伴组织的选定数据空间，确保统一数据的受管、基于角色的可见性。 |
| 访问配置 | 必填 | 在同伴组织中，启用 Data Cloud One 应用程序，并为简档、见解和细分访问权限分配用户权限。 |
| 治理和策略控制 | 推荐 | 在家庭组织中集中所有接收、身份解析和 Trust 配置，维护端到端的治理。 |
| 多组织同步 | 最佳 | 家庭组织中的数据更改和计算见解通过受管同步漏斗实时反映在同伴组织中。 |
| 混合部署选项 | 可选 | 对于大型企业，多个同伴组织可以连接到一个家庭组织，同时保持本地上下文和合规边界。 |
**在这种情况下：**
* **主页管理员**：创建数据空间并定义数据共享（选择 DMO/CIO、细分）。
* **主页管理员**:为同伴组织创建数据共享目标并配置 Trust(OAuth 客户端,允许的组织 ID)。
* **主页管理员**：将数据共享发布到目标；附加 ABAC 策略 (CEDAR) 和加密/密钥控制 (CMK，如果需要)。
* **同伴组织管理员**：接收邀请、验证身份映射并接受共享。
* **同伴组织**:Data Cloud One 网桥配置 Data Cloud One 用户，并应用权限集和数据空间可见性。
* **同伴组织应用程序(Flows/Einstein/Apex)**:查询数据图形或调用 Data Cloud One API，以读取共享 DMO 或细分。
* **激活**:同伴组织通过数据操作触发激活或写回（如果允许）。
##### 结果
* 所有连接组织的客户数据(Customer 360)的**单一真实来源** -- -- 没有冗余的Data 360实例。
* **更快实现价值。** 伴随组织可以在几分钟内访问统一数据和 Data 360 支持的功能，而不是几周的自定义编码。
* **受控数据共享。**仅共享授权的数据空间，在保留安全和治理的同时实现业务灵活性。
* 业务功能（销售、服务、市场营销）在相同的统一数据基础上运行，在整个企业中实现一致的度量、激活和见解。
###### 调用机制
调用机制取决于为实施此模式选择的解决方案。
| 机制 | 何时使用 |
|---|---|
| Data Cloud One 本地共享（首选） | 在多个 Salesforce 组织（销售、服务或 Industry Cloud）需要直接从 Data 360\ 实时访问统一客户数据时使用。这消除了复制，并实现了对 Golden Records、细分和计算见解的零延迟访问。 |
| 通过 Data Cloud One 网桥进行组织间共享 | 在多个业务部门或子公司在单独的 Salesforce 组织中运营，但需要从中央 Data 360 实例中共享访问常见客户数据和细分时使用。非常适合维护独立操作系统的多组织企业。 |
| Einstein 1 平台查询 API | 在 Salesforce 应用程序、Flow 或 Einstein Copilot 必须以编程方式查询或激活 Data 360 数据时使用。支持将统一简档、度量或激活结果实时检索到其他 Salesforce 应用程序，无需批量导出。 |
| 激活 Salesforce 渠道 | 在 Data 360 数据（细分、见解或属性）必须激活到 Marketing Cloud、Service Cloud 或 Commerce Cloud 以获得个性化、市场活动执行或客服人员帮助体验时使用。 |
| 数据图访问（语义查询层） | 当您需要通过 Salesforce 数据图对统一数据模型进行语义级访问时使用 — 支持 Co pilot、AI 工作流和实时跨云分析，无需手动连接或转换。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 细分创建 | 最佳 | 营销人员或分析师通过跨任何数据模型对象 (DMO) 或计算见解对象 (CIO) 应用筛选器，在可视细分画布中构建细分。这将定义激活的目标受众。 |
| 激活设置 | 最佳 | 用户创建激活，并选择他们刚刚构建的细分作为源。这定义了 Data 360 将导出到下游系统的受众。 |
| 激活目标选择 | 最佳实践 | 营销人员选择预配置的激活目标（例如 Marketing Cloud、Google Ads、LinkedIn Ads）。每个目标都使用身份验证凭据和字段映射在 Data 360 中注册。 |
| 有效载荷定义 | 必填 | 营销人员通过选择联系人标识符（例如电子邮件、手机、散列 ID）并选择其他简档属性（例如名字、忠诚度等级或 CLV）来定义有效载荷，以便在目标系统中丰富。 |
| 计划和频率 | 推荐 | 激活可以计划运行一次或定期运行（例如，每天或每周）。计划可确保下游受众保持同步和最新。 |
| 执行和导出 | 最佳 | 激活作业运行时，Data 360 会查询细分，收集选定属性，应用同意筛选器，并将数据导出到目标平台。对于 Marketing Cloud，这通常会导致创建或更新共享数据扩展。 |
| 治理和合规 | 必填 | Trust 层强制实施模式验证、同意元数据和策略控制，以确保遵守数据保护和市场营销法规(例如 GDPR、CCPA)。 |
| 监控和可审计性 | 最佳实践 | 在 Trust 层监控仪表板中，通过成功/失败度量、执行日志和谱系可见性跟踪每个激活运行，从而实现操作透明度和 SLA 保证。 |
##### 结果
* Data 360 中有针对性的丰富受众细分直接在下游营销和广告平台中可用。
* 受众会自动刷新并与最新统一的客户数据同步，保持实时市场活动的相关性。
* 营销人员可以使用这些激活的受众作为 Marketing Cloud 旅程、电子邮件市场活动或 Google Ads、Meta 或 LinkedIn Ads 等数字广告平台中的自定义受众的入口来源。
* 每次激活运行都会维护端到端的谱系，确保 Data 360 与外部系统之间的合规性、可追溯性和一致性。
* 业务用户可以提供高度个性化的数据驱动体验，这些体验由完整和可信的 Customer 360 视图提供支持。
###### 调用机制
调用机制取决于目标平台和激活目标配置。
| 机制 | 何时使用 |
|---|---|
| Marketing Cloud 参与激活（首选） | 在 Marketing Cloud 中执行需要动态细分、个性化属性和实时更新的电子邮件或跨渠道旅程时使用。Data 360 直接导出到共享数据扩展中，以便激活市场活动。 |
| 广告平台激活（Google Ads、LinkedIn Ads、Meta Ads） | 在广告平台中激活 Data 360 细分作为自定义受众进行重新定向或类似建模时使用。支持散列标识符和同意感知交付。 |
| CRM 激活（Sales 或 Service Cloud） | 在向 CRM 用户共享丰富的客户数据、见解或倾向分数时用于个性化销售参与或服务交互。数据通过数据操作或统一简档组件作为丰富记录或见解提供。 |
| 通过 MuleSoft 或 API 进行外部激活 | 当激活需要到达非 Salesforce 系统（例如忠诚度、电子商务或第三方数据仓库）时使用。MuleSoft 或 Data 360 激活 API 通过基于事件的刷新选项确保安全、受策略控制的交付。 |
| 混合激活（批处理 + 事件触发） | 在将计划的批量激活与基于事件的触发器组合时使用 — 为时间敏感的市场活动启用“始终开启”的个性化，例如放弃的购物车或流失风险提醒。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 分段选择 | 最佳 | 分析师在 Data 360\ 中选择现有细分或查询定义。细分决定了导出哪些记录和属性。 |
| 激活设置 | 最佳 | 用户创建新的激活，将细分选择为源，将云存储目标（例如，S3）选择为目标。 |
| 激活目标配置 | 必填 | 管理员使用凭据、IAM 角色和输出路径预配置目标。支持的格式包括 CSV、Parquet 和 JSON。 |
| 有效载荷定义 | 最佳实践 | 通过选择所需属性（例如，ID、名称、电子邮件、区域、同意标志），定义导出模式。系统强制执行属性级治理。 |
| 计划和频率 | 推荐 | 导出可以计划以定义的节奏运行（每天、每周、每月），也可以根据需要手动触发。 |
| 执行和交付 | 最佳 | 在执行时，Data 360 会查询细分，编译导出文件，加密，并使用云提供商的 API 将其写入配置的存储桶/文件夹。 |
| 治理和合规 | 必填 | Data 360 的 Trust 层确保所有导出遵守同意策略、模式验证和合规筛选器。 |
| 监控和可审计性 | 最佳实践 | 每个导出都在 Trust 层监控仪表板中跟踪，其中包含状态、执行日志和谱系元数据。 |
##### 结果
* Data 360 中有针对性的丰富受众细分直接在下游营销和广告平台中可用。
* 受众会自动刷新并与最新统一的客户数据同步，保持实时市场活动的相关性。
* 营销人员可以使用这些激活的受众作为 Marketing Cloud 旅程、电子邮件市场活动或 Google Ads、Meta 或 LinkedIn Ads 等数字广告平台中的自定义受众的入口来源。
* 每次激活运行都会维护端到端的谱系，确保 Data 360 与外部系统之间的合规性、可追溯性和一致性。
* 业务用户可以提供高度个性化的数据驱动体验，这些体验由完整和可信的 Customer 360 视图提供支持。
###### 调用机制
调用机制取决于目标云存储平台和激活配置。
| 机制 | 何时使用 |
|---|---|
| Amazon S3 激活 | 在 AWS 上托管企业数据湖时使用。Data 360 使用 IAM 角色或临时凭据直接写入 S3 存储桶，确保导出的安全性和可扩展性。 |
| Azure Blob Storage 激活 | 当您的组织在 Microsoft Azure 上操作时使用。Data 360 使用 SAS 令牌或服务主体将加密文件写入 Blob 容器。 |
| Google Cloud Storage (GCS) 激活 | 当您的数据科学或分析工作负载在 GCP 上运行时使用。Data 360 使用 OAuth 凭据，以 CSV 或 Parquet 格式将文件导出到 GCS 存储桶。 |
| SFTP 或外部文件网关 | 当监管或传统系统需要通过 SFTP 端点或企业管理的文件传输平台进行安全的文件传输时使用。 |
| 混合导出（文件 + API） | 当下游应用程序需要基于文件的导出进行分析和 API 触发器进行工作流编排（例如 MuleSoft 流）时使用。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 身份验证和应用程序注册 | 必填 | 在 Salesforce 中为基于 OAuth 2.0 的身份验证创建连接的应用程序。配置 Data 360 API 访问权限的范围。 |
| 数据访问（简档、细分、见解） | 最佳 | 使用 Connect API 端点 (/services/data/vXX.X/connect) 查询协调的 Data 360 数据、统一简档和计算见解。 |
| UI 集成 | 最佳 | 前端应用程序（反应、Angular、iOS、Android）调用 Connect API，以在仪表板、入口网站或移动界面中呈现 Data 360 数据。 |
| 数据图查询 | 推荐 | 将连接 API 与数据图 API 结合起来，进行语义级查询，简化复杂的连接和关系。 |
| 实时刷新 | 可选 | 将 Connect API 与 WebSocket 或流扩展用于实时数据更新。 |
| 安全和治理 | 必填 | 使用 OAuth 范围、Data 360 策略和 Trust 层审计框架，强制执行数据可见性。 |
##### 结果
开发人员可以创建与 Data 360 紧密集成的安全自定义品牌应用程序。这些应用程序可以：
* 实时显示统一的客户简档和见解。
* 通过统一 API，在 CRM 或自定义对象旁边显示 Data 360 数据。
* 通过 Trust 层利用一致的身份验证、授权和审计控制。
* 为业务用户或合作伙伴提供跨体验的可信客户智能的无缝、受管访问。
##### 调用机制
调用机制取决于目标云存储平台和激活配置。
| 机制 | 何时使用 |
|---|---|
| 连接 REST API（首选） | 在构建需要以 UI 友好的 JSON 格式实时访问 Data 360 数据的 Web、移动或第三方应用程序时使用。 |
| 数据图形 API | 在应用程序需要跨多个对象执行语义级查询时使用（例如，客户 → 交易 → 市场活动）。 |
| 查询 API | 在执行类似 SOQL 的查询时使用，以高精度检索统一的数据集。 |
| Einstein 1 Platform API | 在自定义 UI 中集成 AI 驱动的见解或 Co pilot 生成的推荐时使用。 |
| MuleSoft 或 Apex 网关包装程序 | 当应用程序和 Connect API 之间需要额外的编排、缓存或策略实施时使用。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 数据图形定义 | 必填 | 架构师定义了一个数据图，它将多个 DMO 组合成一个语义实体（例如，UnifiedCustomerProfile）。 |
| 简档查找检索 | 最佳 | 应用程序调用 GET /api/v1/dataGraph/{entity}/{id}，以通过唯一 ID 或密钥检索完整的非规范化简档。 |
| 实时参数使用情况 | 可选 | 附加 ?live=true，以强制新计算，而不是缓存检索；适用于高价值决策。 |
| 身份验证 | 必填 | 通过连接的应用程序使用 OAuth 2.0，以安全地验证 API 调用。 |
| 响应解析 | 最佳实践 | 应用程序直接将 JSON 响应解析到其 UI 或决策引擎中；无需进一步连接。 |
| 缓存策略 | 推荐 | 为重复的简档查找实施短期本地缓存（例如，内存或 CDN）。 |
| 监控和可观察性 | 必填 | 使用 Trust 层仪表板监控查询性能、响应时间和策略遵守情况。 |
##### 结果
现在，应用程序可以立即检索完整的预连接客户简档，支持实时交互，例如个性化、服务和决策自动化。
此模式可确保：
* 即时决策的亚秒响应时间。
* 与 Data 360 语义模型一致的受管数据检索。
* 简化的应用程序逻辑 — 无联接，无模式协调。
* 通过 Trust 层进行可跟踪和合规的访问，以实现审计和可观察性。
###### 调用机制
调用机制取决于目标云存储平台和激活配置。
| 机制 | 何时使用 |
|---|---|
| 数据图形 API（首选） | 用于通过 ID 或密钥即时检索完整的预具体化简档。 |
| 包含 live=true 的数据图 API | 用于需要最新数据的高价值用例（例如，欺诈检测、实时优惠），接受稍高的延迟。 |
| 连接 API（后备） | 用于将数据图检索与其他 Salesforce 数据相结合的复合应用程序场景。 |
| 查询 API | 在构建临时查询或分析读取而不是即时简档检索时使用。 |
| MuleSoft API 代理 | 当通过企业网关路由数据图调用时，或当需要额外的编排/策略实施时使用。 |
| 解决方案区域 | 适合 | 评论/实施详细信息 |
|---|---|---|
| 实时数据操作 | 最佳 | 显示单记录读/写和操作触发器的端点。通过 OAuth/JWT 进行身份验证。 |
| 身份解析 | 必填 | 将传入标识符（电子邮件、externalId、cookie）解析为内联统一个人 ID。使用带有缓存的确定性解析器。 |
| 政策执行 (CEDAR) | 最佳实践 | 在请求时评估同意、ABAC 和屏蔽策略；根据策略决策拒绝或屏蔽字段。 |
| 边缘/缓存层 | 推荐 | 对简档片段和计算见解使用短 TTL 缓存，以减少延迟；对变更事件无效。 |
| 轻量级转换 | 推荐 | 在操作路径中应用简单丰富或计算字段；应预计算繁重转换。 |
| 动作编排 | 最佳 | 支持复杂流的同步单步操作（例如，返回优惠令牌）和异步编排（队列 \+ Webhook）。 |
| 可观察性和跟踪性 | 必填 | 将请求/响应、策略决策和谱系记录到 Trust 层/SIEM 进行审计和调试。 |
| 流量限制和限制 | 必填 | 为高流量时刻强制执行客户端配额和优雅降级策略。 |
##### 结果
* 应用程序可以立即获得对统一简档读/写和操作触发器的受策略控制的访问权限，并具有几秒到几秒的延迟。
* 启用实时个性化、决策和操作工作流（例如，优惠、客服人员帮助、库存更新），没有批量延迟。
* 所有操作都是可审计的、同意感知的，并强制实施属性级屏蔽，以保持隐私性和合规性。
###### 调用机制
调用机制取决于目标平台和激活目标配置。
| 机制 | 何时使用 |
|---|---|
| RESTful 数据操作 API | 需要同步简档读取或操作响应的 Web/移动应用程序和中间件的首选。 |
| gRPC / Binary RPC | 用于具有持久连接的超低延迟企业服务或内部微服务。 |
| GraphQL 单记录查询 | 当客户需要灵活的字段选择并希望最小化负载时使用。 |
| 事件触发的 Webhook | 用于操作触发下游流程的异步工作流（例如，开始旅程）。 |
| 平台事件/发布订阅 | 用于多个系统必须对单个操作事件做出反应的扇出场景。 |
| Edge SDK（客户端库） | 用于缓存简档片段并仅在需要时调用数据操作 API 的低延迟客户端。 |
## 2\.核心架构原则
合理安排多客服人员架构首先要将核心架构原则投影到客服人员的功能和结构上。然后，产生的多智能体架构体现了核心系统设计和系统架构原则，与 AI 技术的独特“粒度”相一致。
推动此架构的关键原则包括：
- 通过分解管理复杂性
- 通过解耦提高弹性并降低脆性
- 通过代码重用提高可靠性和效率
- 通过限制任何一个客服人员的关注范围来提高客服人员的可靠性
- 通过模块化和可扩展性改善系统维护和演进
- 通过专业化简化客服人员管理和问责制
与更原始的代理架构不同(例如,侧重于作为核心架构结构的LLM的架构),_Agentforce 从一开始就_是为多代理编排设计的。多客服人员编排是 Atlas Reasoning 引擎和客服人员推理的基础，用于在客服人员响应中创建动态、有效的编程路径，以显著扩展为用户体验提供广泛、深入的客服人员增强 (UX) 的能力。
在 Agentforce 中，此类协调由这些可互操作的密钥开放协议和 Salesforce 产品启用：
- **Agentforce** 提供客服人员子系统来封装客服人员的所有关键元素：主题、指令、操作、防护、上下文、调用、输出、执行详细信息、日志等。
- **操作**：提供钩子，以访问数据、调用流、调用外部系统和调用其他客服人员。
- **Data 360**：提供数据虚拟化层，为客服人员带来特定的个性化上下文（利用 Data 360 的统一简档和密钥链从整个企业中提取特定信息）。
对于整个企业的客服人员或访问客服人员或资源，我们支持：
- **模型上下文协议**:是一个安全的通信层,将客服人员与企业工具、数据和知识联系起来,以确保上下文的准确性。
- **客服人员到客服人员 (A2A) 协议**: 是客服人员间委派的标准化握手，支持跨系统、组织和供应商进行安全的受管协调。
这些原则为构建可扩展、可治理的编配智能系统提供了基础。
### 其他注意事项
强大的客服人员解决方案需要清晰的方法来满足支撑有效技术交付的非功能需求：
- 安全和治理（身份和访问权限管理、数据隐私、数据安全和威胁建模）。
- 可观察性和监控（分布式跟踪、集中记录、度量和仪表板）。
- 操作和生命周期管理（规格、测试用例生成、测试、反馈、继续学习、弃用）。
这些是构建 Enterprise Agentic 解决方案时的关键架构注意事项，本白皮书中未涉及；但将在未来的出版物中讨论。
## 3\.企业客服人员分类
要管理企业范围的客服人员环境，架构师必须通过两个互补的镜头对客服人员进行分类：技术功能和业务影响。
### 3.1 职能角色分类
此分类对客服人员在架构中可能承担的功能角色进行分类。
- **渠道/UX 角色**:定义交互模式（例如，无头、提示、聊天和消息，或 AI 管理的工作区）。
- **专家角色**:封装深度域 Knowledge（例如，Domain Expert、Knowledge Minion、Assistant 或 Planner）。
- **实用程序服务角色**:执行离散的事务性任务（例如，生成、汇总、转换或配置）。
- **维护和主动服务角色**:关注数据的健康和质量（例如，策划、构建、数据质量或数据丰富）。
- **长期运行的角色**:管理长时间的流程（例如，礼宾、项目经理、护理人员或观察者/提醒者）。
## 4\.客服人员地图模板
为了便于清晰的设计和沟通,**客服人员地图**是描述客服人员解决方案的标准模板。它定义了特定设计模式中的关键实体、系统和交互。
以下是客服人员地图模板组件：
- **用户层**定义了系统中的人工角色(例如客户、经过身份验证的员工 (SF-Users) 和未经身份验证的员工)。
- **客服人员层**描述了所需的客服人员、显示的模式、相互关系以及用于实现特定模式的说明。
- **上下文/操作**是客服人员管理或访问的资源、功能或操作。
- **来源**是客服人员连接的基础数据、应用程序、Knowledge 库和其他系统。
附录 A 和 B 通过演示客服人员地图模板泳道中的组成来说明系统级客服人员模式。
## 5\.代理模式框架
在 Salesforce，我们使用客服人员模式库来组织和提供可靠、可预测的客服人员解决方案。这些模式是我们解决常见架构问题的蓝图。
它们分为四个主要类别：
- **交互模式**:关注客服人员参与和用户体验 (UX)。
- **专家/员工模式**:封装特定域中的深层 Knowledge 或特定技能。
- **实用程序和数据管理模式**:执行支持其他客服人员或流程的特定且通常可重复的任务。
- **长时间运行的模式**:管理长时间发生的流程和工作流，涉及多个步骤。
以下部分详细介绍了每个类别的关键模式。每个模式描述都提供一**个概览**、**输出类型**、**模式使用指导**、**代表性用例**和**解决方案图表**，以及到 **Salesforce 代理成熟度基准**的映射。
## 6\.交互模式
_交互模式_是侧重于客服人员参与和用户体验的基础设计。
### 问候语模式
- **概览**:_Greeter 模式_是一种使用自然语言来确定用户意图的简单、易于实施的模式。然后，它将用户路由到适当的人工客服人员。
- **输出类型**:切换/上报到下一个资源。
- **业务价值**:促进客户无缝、高效的第一次联系，同时最大限度地提高服务提供商的意图解析和上下文收集。
- **模式使用指导**:将客服人员配置为品牌渠道的主要参与资源。根据用户意图，提供关于品牌、产品和服务的说明，并与路由说明配对。客服人员收集并汇总交付热情切换的意图。
- **代表性用例**:想象一个网页，它使用聊天机器人来显示一个选项菜单，用户必须在路由到人类之前单击所有选项。为了提高后台生产力和效率，聊天机器人通常使用复杂、复杂的工作路径和交互。这会导致客户的“填写、选择和单击”疲劳场景，如果上下文在可用菜单选项之外，这通常会导致沮丧。通过使用自然语言交互的_客服人员前门_替换传统的聊天机器人，它减轻了负担并提供类似人类的交互。
- **Agentforce 模式**:
- Agentforce 服务代理：[使用 Agentforce Builder 组建服务代理](https://trailhead.salesforce.com/content/learn/modules/quick-start-assemble-a-service-agent-with-agentforce-builder)
- 打包的服务代理具有支持转移的可配置转移功能：
- 对于人工客服人员
- 对 AI 客服人员
- 至外部客服人员
- 包含代码示例的特定于行业的模式
- **图表**:
- **Salesforce Agent 成熟度**:级别 1（如果使用内置转移和升级的现成服务代理，则为级别 0）
### 运算符模式
- **概览**:_运营商模式_建立在 _Geeter 模式_的基础上，将请求路由到适当的专家客服人员或人员和谈判意图(如果需要)。
- **输出类型**:切换/转移到下一个资源。
- **模式使用指导**:将特定于品牌和服务的说明与根据意图将用户发送到何处的说明配对。定义升级资源，可以是人员或其他客服人员。
- **代表性用例**:将 _Agent 前门_ 用于人员或 AI 代表高度专业化的场景。
- **图表**:
- **Salesforce Agent 成熟度**:级别 2
### Orchestrator 模式
- **概览**:_编排者模式_管理 AI 客服人员"群 " 。当收到用户请求时，它会将话语传递给一个或多个专家客服人员，然后聚合用户的响应。与_运算符模式_不同，它仍然是第一个联系点 (POC)。
- **输出类型**:核对并准备来自工作人员客服人员的回复。
- **模式使用指导**:配置为主要参与者。为每个支持的工作人员客服人员（例如，优先级确定者或域 SME）提供说明，允许编配员向他们中继话语。
- **代表性用例**:将_编排者模式_用作客服人员前门，以帮助每次对话可能需要讨论多个主题的客户，这需要多客服人员解决方案和一致的交互。在多系统架构中，考虑使用_编排者模式_来协调跨系统的响应，并与外部客服人员协作。
- **图表**:
- **Salesforce Agent 成熟度**:级别 3
### 听众/摘要模式
- **概览**:_听众/摘要模式_在对话流中显示上下文和见解。_监听器_在每次对话轮次中触发，以查找并显示员工的相关信息。
- **输出类型**:根据对话提供相关上下文，这些上下文可以格式化以产生效果（例如，进行比较或突出显示关键点）。
- **模式使用指导**:将监听程序附加到基于轮次的渠道（例如，聊天、语音或短信）。为每个主题区域定义主题。客服人员使用脚本，识别主题，并调用操作来搜索相关内容并将其发布到员工的运行摘要。
- **代表性用例**:使用_通用助手_帮助客户服务或销售代表。
- **图表**:
- **Salesforce Agent 成熟度**:级别 3
### 工作区 (Radar O'Reilly) 模式
- **概览**:_工作区 (Radar O’Reilly) 模式_在对话流中管理响应式单窗格 UX。它处理每个语句，以使用相关内容更新 UX 的部分。
- **输出类型**:在更大的单一窗格视图中，提供位于 portlet 中的相关上下文。
- **模式使用指导**:_编排_人员将话语传递给一组_主题_客服人员。每个主题客服人员评估该语句，以确定是否需要 UX 更新。如果是这样，它会将动态更新推送到相应的 LWC。
- **代表性用例**:此功能类似于高级客服人员前门。
- **图表**:
- **Salesforce Agent 成熟度**:级别 3
## 7\.专家模式
_专家模式_包含特定领域的深度 Knowledge 或技能 , 通常由_交互模式_编排。
### Answerbot 模式
- **概览**:_Answerbot 模式_是一种有效的自助模式,它使用 GenAI 来确定 Knowledge 检索的自然语言,而不仅仅是关键字。
- **输出类型**:汇总 Knowledge 和支持材料的引用/引用。
- **模式使用指导**:组织和接收可靠的源材料（例如 Knowledge Stores 或常见问题解答）来配置客服人员。在公司网站或内部入口网站中定位客服人员。监控问题，以识别和解决 Knowledge 差距。
- **代表性用例**:促进公司网站上的自然语言搜索，与人力资源福利机器人交互，并为所有成员提供自助组件。
- **图表**:
- **Salesforce Agent 成熟度**:级别 1
### 域 SME 模式
- **概览**:_域 SME 模式_是一种基础模式，为业务域（例如订单或索赔）提供自然语言前端。
- **输出类型**:提供有关域的相关内容、主题、数据和格式化信息。
- **模式使用指导**:使用此模式封装主题或业务域。为客服人员配置执行适当 CRUD 操作的能力。通过[_交互模式_](/docs/architect/zh-cn/fundamentals/guide/enterprise-agentic-architecture#6交互模式)（例如 - Orchestrator 或监听程序），使这些客服人员可用。
- **代表性用例**:把关业务数据域，提供“订单客服人员”或“库存客服人员”，并为业务域提供客服人员界面。
- **图表**:
- **Salesforce Agent 成熟度**:级别 2
### 询问器模式
- **概览**:_询问者模式_是 SME 客服人员，可以就主题进行询问，以从多个来源收集上下文来回答问题。利用的关键客服人员功能是提取上下文并将概念与内容正文联系起来的能力，就像人类在阅读和内部化内容后一样。这种模式降低了对"轮椅集成"的需求。
- **输出类型**:提供问题的答案。
- **模式使用指导**:它通常配置为连接到用户当前上下文的控制台小部件，以便他们可以直接提问。它还与 Knowledge 资源一起使用，例如常见问题解答、保单和产品目录。将_询问器模式_与标准提示配对，以将常见答案扩展到常见问题。
- **代表性用例**:用作合同助理客服人员；福利查询助理，或多客服人员模式中的专家工作人员客服人员（例如，监听者或工作区）。
- **图表**:
- **Salesforce Agent 成熟度**:级别 2
### 优先级模式
- **概览**:_优先级模式_用于根据定义的目标对一组任务或工作对象进行排序。它利用 GenAI 进行定性分析、非结构化数据分析或跨多个数据域的集成分析。
- **输出类型**:提供生成性见解。
- **模式使用指导**:使用自然语言来描述确定优先级所需的品质。使用一组可选选项对客服人员进行基础训练。与倾听者模式相结合，在工作流中创建响应式“Next Best Action”。
- **代表性用例**:在长时间运行或多客服人员模式中用作 _Next Best Action_ 生成器或专业工作人员客服人员。
- **图表**:
- **Salesforce Agent 成熟度**:级别 2
## 8\.实用程序和数据模式
_实用程序模式_执行支持其他客服人员或流程的特定、可重复的任务。
### 生成器模式
- **概览**:_生成器模式_是从现有输入和标准创建新内容（例如个案汇总或电子邮件草稿）的基本模式。它通常作为提示实施，并可能嵌入其他客服人员。
- **输出类型**:提供符合请求格式和意图的生成内容。
- **模式使用指导**:_生成器模式_可以在大多数其他模式中使用，也可以作为独立模式使用。上下文可以通过请求、执行期间的水合或其他浓缩步骤提供。
- **代表性用例**:向 QBR 提供个案汇总、电子邮件草稿、Knowledge 文章或建议/响应。
- **图表**:
- **Salesforce Agent 成熟度**:级别 1
### 数据管理模式
- **概览**:_数据管理模式_是一种自主的后台模式，将代理步骤引入数据操作，以确保一致的数据质量、一致性和丰富性。
- **输出类型**:在保存前提供更新的记录和数据字段。
- **模式使用指导**:通过在保存数据之前添加记录触发器流的数据管理器，在数据创建点嵌入数据质量。有助于确保分类、汇总和状态数据的应用一致。
- **代表性用例**:确保一致的“披萨跟踪器”样式更新，丰富客户数据，并消除不匹配的邮政编码和地址。
- **图表**:
- **Salesforce Agent 成熟度**:级别 2
### Zen 数据园丁模式
- **概览**:_Zen Data Gardener 模式_是一种用于整理和标准化数据的预定后台模式，它利用低成本推理来验证、丰富和统一其他未连接的数据域的数据。
- **输出类型**:提供更新的记录和/或数据管理任务。
- **模式使用指导**:使用该模式启用定期、定期的数据审查和验证。对于变化缓慢的数据，以缓慢的节奏（例如每月）计划客服人员。与[数据管理模式](/docs/architect/zh-cn/fundamentals/guide/enterprise-agentic-architecture#数据管理模式)结合，提供前瞻性和回顾性数据质量操作。
- **代表性用例**:确保已售福利与索赔系统保持一致，并根据国家登记册定期验证经纪人许可证。
- **图表**:
- **Salesforce Agent 成熟度**:级别 4
### 配置器模式
- **概览**:_配置器模式_从自然语言要求生成配置工件（例如，SQL/SOQL、JSON 和 CSV）。它还可以反向运行，以根据要求验证现有配置。
- **输出类型**:提供更新的记录、数据管理任务或构建问题/错误进行更正。
- **模式使用指导**:使用特定标准、准则或示例对客服人员进行基础训练。使用合同或产品规格等来源配置构建要求。将_配置器模式_连接到目标系统，以推送生成的配置。
- **代表性用例**:为健康保险产品生成产品配置记录，并为健康提供商验证合同/付款条款。
- **图表**:
- **Salesforce Agent 成熟度**:级别 4
### 法官和陪审团模式
- **概览**:_法官和陪审团_模式旨在通过使用一组“陪审员”客服人员和“法官”客服人员来评估回复的一致性，以确保它们实质上的一致性和基础性，从而最大限度地减少幻觉。
- _集成方法_嵌入到 Agentforce 和 Atlas 推理引擎中，以处理回复的准确性和相关性。当高精度至关重要时，_法官和陪审团模式_就以这种能力为基础。
- _数据基础训练_（例如，“在这些记录/文档中查找答案”）和_提示工程_（例如，“仅在这些记录中找到答案时才返回答案”或“根据此外部来源验证答案”）的组合也是最小化幻觉的有效方法。
- **输出类型**:提供生成性见解。
- **模式使用指导**:在强烈需要一致和基础的生成式输出时使用。_法官代理_会编译基准提示，并将其传递给两个或更多_的法官代理_，然后法官评估响应。为了获得最佳结果，请为每个陪审员使用不同的模型（例如，一个来自 OpenAI，另一个来自 Anthropic）。
- **代表性用例**:提供高保真、基于事实的回答，以最大限度地减少幻觉。
- **图表**:
- **Salesforce Agent 成熟度**:级别 2
### 模型模式模型
- **概览**:_模型模式_利用多个专家客服人员生成广泛的视角，然后提取共识。与[法官和陪审团模式](/docs/architect/zh-cn/fundamentals/guide/enterprise-agentic-architecture#法官和陪审团模式)不同,该模式包含多个观点以增强丰富性。
- 当存在具有不同观点 (POV) 的专家模型时，这种模式也可以称为专家小组模式。
- 与意图确保客服人员响应收敛于共同可访问的“真相”的法官和陪审团模式不同，_模型模式_通过利用客服人员环境中的多样性来扩展响应的范围。
- 此模式假设还有其他客服人员具有不同的 POV。例如，在多组织、多客服人员的环境中，或在技术堆栈中有多个供应商提供的客服人员的环境中，_模型模式_提供了集成多个 POV 的结构。
- 在考虑此模式时，也考虑其他通常更轻量级的方法：
- 不要定义多个专家客服人员，而是指定多个提示，让系统作为提示集合工作。
- 通过访问上下文适当的数据的操作，利用“基础训练”。
- **输出类型**:提供生成性见解。
- **模式使用指导**:_聚合_客服人员的角色是根据模型客服人员返回的关键概念形成并返回丰富的 POV。模型客服人员根据其唯一 POV 确定响应。
- **代表性用例**:用于可能受益于汇集不同观点以提高回复质量的情况。
例如，特权客服人员（例如 _ERP 客服人员_）可能拥有有价值的 POV 且无法访问的多系统客服人员环境。
- **图表**:
- **Salesforce Agent 成熟度**:级别 2
## 9\.长时间运行的进程模式
_长期运行进程模式_管理在较长时期内发生的进程，并涉及多个步骤和行为者。
### 项目经理模式
- **概览**:_项目经理模式_是一个复杂的模式，可以监督一个长期运行的项目。它协调活动，跟踪完成情况，通知用户，并向利益相关者代表项目状态。
- **输出类型**:有多个输出（例如，个案、任务、状态更新和通知）。
- **模式使用指导**:用作总括模式，以支持定期、重复、多步骤的活动。_项目经理模式_获取项目的输入模板/大纲（包括任务、角色和依赖性），然后实例化个案和活动并将其分配给用户。
- **代表性用例**:用于客户安装管理和企业销售参与。
- **图表**:
- **Salesforce Agent 成熟度**:级别 4
## 10\.企业编排原型
模式描述了客服人员角色，_编排原型_定义了客服人员团队如何协作的系统级蓝图。这些原型澄清了_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 主导的编排）**
- **定义**: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 中集中推理、治理、策略和可观察性。
## 11\.解决方案汇编：撰写模式
这些单独的模式和编排原型是旨在组成端到端解决方案的建筑构件。代理解决方案映射用于可视化这些组件如何连接在一起。
- 适用于医疗保健提供商的_会员服务解决_方案是 SOMA 原型的标准实施。它使用适用于匿名用户的 Answerbot、适用于经过身份验证的成员的 _Orchestrator_ 以及多个 _Domain SME 客服人员_（例如个案、索赔和福利）来处理特定请求。
- _B2C 经纪人入口_网站是一个复杂的组合，它使用入口网站_管理员_代理来调用长时间运行的 _Project Manager 代理_进行 RFP 流程，而 RFP 流程又使用_无头_代理、_数据管理员_和_询问代理_进行后台数据操作。
## 12\.结论
代理设计模式方法论提供了构建强大的、可扩展的和可维护的企业 AI 系统所需的架构纪律。通过分解复杂性和促进模块化，这些模式使架构师能够提供可靠、可预测的代理解决方案。
编排原型的选择是一项战略决策，它基于用户在哪里工作、上下文在哪里存在，以及企业如何管理人员、客服人员和系统之间的交互。通过了解构建客服人员和编排客服人员之间的区别 — 并通过利用 _MCP_ 和 _A2A_ 等开放协议 — 架构师可以超越创建孤立的机器人,而是设计一个内聚的、受管的和分布式的企业推理系统。这种方法提供了共享语言和一组可重用的蓝图来构建可持续的代理架构。
## 附录：解决方案地图和系统架构
本附录提供了代理模式如何组成系统级解决方案的具体示例。
### 附录 A：基本模式组成示例
此图说明了如何将五个基本模式连接在一起，以创建通用客户服务工作流。
1. **Answerbot**:匿名用户提问，由 Knowledge 客服人员处理。
2. **运算符**:员工的问题由话务员分类，话务员会处理对话，并将其交给更专业的客服人员。
3. **编配员**:经过身份验证的用户 (SF 用户) 与协调多个客服人员的调度员接洽，以处理潜在的多方面查询。
4. **域 SME**:编配员会调用专家客服人员（例如，HR 客服人员或福利客服人员），以执行主题更新并检索特定数据。
5. **发电机**:实用程序客服人员用于在交互完成后汇总客户详细信息或总结个案。
### 附录 B：客服人员解决方案地图 - 成员服务
此解决方案映射详细描述了成员服务用例的代理架构，展示了多个模式的组合。
- **用户简档**:该解决方案为三种不同的用户类型提供服务：匿名用户、验证成员和 SF 用户（例如，人类 CSR）。
- **交互模式**:_Answerbot_ 处理匿名“Find-A-Doc”查询，而 Orchestrator (Agentic Front Door) 管理经过身份验证的用户查询。_听众/摘要模式_有助于 SF 用户。
- **域代理重用**:专用_域 SME 客服人员_(例如个案客服人员、索赔客服人员或福利客服人员)可在不同的交互流中重复使用。
- **自主和辅助**:该系统结合了_自主客服人员_(用于指导用户交互)和_辅助客服人员_(用于增强人的 CSR)。
- **数据源**:该架构集成了公共和企业数据源，并广泛使用 _Data 360_ 和 _MuleSoft_ 进行连接。
### 附录 C：系统架构 - 联系中心
此图说明了联系中心中辅助 AI 解决方案的逻辑架构，并将其组织成功能层。
- **编配员代理**:管理不同角色的用户体验（例如，匿名、外部成员或 CSR），并编排整体交互流。
- **员工客服人员**:_多个中小企业_代理侧重于 Knowledge、个案/索赔/福利和提供商目录等核心业务领域。还包括 _Next Best Action_ 客服人员。
- **实用程序代理**:执行特定的可重用任务，例如翻译、个案总结和呼叫汇总。
集成和核心系统：整个客服人员系统通过跨平台集成层连接到非结构化数据资源、结构化数据资源和核心企业系统。
- **治理**:治理层为客服人员使用的 LLM/SLM 提供可观察性、评估和管理。
### 附录 D：客服人员解决方案地图 - 经纪人入口网站
此解决方案地图详细描述了 B2B 健康保险经纪人入口网站的复杂、长时间的客服人员交互。该模型包括一_个入口网站代理_(_Orchestrator_ ) , 它通过多个步骤(例如,提交 RFP 和接收建议书)为经纪人的旅程提供便利。该编配器调用_项目经理_客服人员，该客服人员反过来协调几个无头客服人员进行后台数据质量和转换，例如 RFP 提取器、人口普查转换和数据管理员。
### 附录 E：系统架构 - B2C 经纪人客服人员
此图显示了 B2C 经纪人解决方案的逻辑架构，展示了与联系中心类似的分层方法。它包括不同用户角色的_编排人员代理_、关键领域(例如 Knowledge、成员服务或佣金)的可重用_工作人员代理_以及翻译和汇总等特定功能的_实用程序代理_。
### 附录 F：系统架构 - 提供商合同
此图显示了提供商合同解决方案的逻辑架构。_协调_员客服人员管理完整的交互，_员工客服人员_管理域中的特定意图（例如，签约的 SME 客服人员），而_实用程序_客服人员执行独立的任务，例如比较合同或生成见解。
### 附录 G：交互模式汇总表
下表总结了一些关键的交互模式、典型用户体验和主要架构目的。
| 模式 | 用户体验 (UX) | 目的 |
|---|---|---|
| 问候 | 逐页显示的文本（聊天、语音、短信等），以回复者将交互转移到人员结束 | 这是用于确定用户意图的简单模式，然后将用户路由到适当的人工客服人员。 |
| 运算符 | 逐页显示的文本（聊天、语音、短信等），以回复者将交互转移到人工或专家客服人员结尾 | 这用于将请求路由到适当的混合客服人员。在 Greeter 的基础上，这是一种协商意图的简单模式，然后将交互转移到专门的人工或 AI 客服人员。 |
| 指揮官 | 回复者收集并汇总专家客服人员回复并将其传递到 UX 的逐页文本（聊天、语音、短信等） | 它用于协调受管 AI-Agent“群”，该群随着对话的进行而响应。Orchestrator 客服人员将每个轮次的文本传递给一个或多个专家客服人员，然后汇总每个轮次的回复。 |
| Answerbot | 提示和响应 | 这是一个自然语言界面，使用 Knowledge 资源、常见问题解答、策略等来形成响应。 |
| 询问者 | 提示和响应 | 这是用于在特定域或区域中提问的自然语言界面。 |
| 听众/摘要 | 以 Orchestrator 模式输入线性摘要结尾的逐页文本（聊天、语音、短信等） | 它用于显示对话流中的上下文和见解。 |
| 工作区（Radar O'Reilly） | 逐页显示的文本（聊天、语音、短信等），以自适应的单窗格抬头显示结尾 | 它用于管理对话流中具有响应性的单一窗格 UX。 |
 |
Salesforce Lightning 平台是一个人工智能驱动的综合平台,将员工、自主人工智能客服人员、公司数据和应用程序统一到一个可信的系统中,以提高生产率和客户体验。它通过连接 Customer 360 应用程序、Data Cloud 和 Slack 来实现端到端自动化，从而支持创建“代理企业”。 |
#### 公平使用
该平台的公平使用机制实施基于等级的系统。该系统确保 Salesforce 平台上的每个组织都能公平地分配给定消息类型的处理时间，包括未来、可排队和批处理消息类型。如果一个组织在其他组织等待执行相同消息类型工作的同时主导了给定消息类型，公平使用算法会减少该组织可用于该特定消息类型的线程数量。
使用异步 Apex 方法的一个好处是一些调控器限制更高，例如 SOQL 查询限制和堆大小限制。但是，不要过于依赖这些方法。由于分配给异步基础设施的资源有限，大量使用 Future、Quueable 和 Batch Apex 会导致处理延迟，这是因为基于公平使用和流控制的限制。
#### 通过异步 Apex 出站标注的特殊注意事项
使用异步 Apex 的出站标注计入异步 Apex 限制。目前，每日限制是适用用户许可证数量的 250,000 或 200 倍，以较大者为准。对于高用量用例，此限制可能是一个问题。如果超过限制，异步 Apex 作业及其关联的出站标注将失败。
此外,由于平台可用的异步线程数量有限,因此通过异步 Apex 进行的出站集成可扩展性有限。任何超出可用线程数量的高用量出站集成都会有较长的处理时间并导致延迟。
对于高用量用例，请考虑这些替代方法。使用这些方法的 API 调用计入每日 API 请求限制，这明显高于每日异步 Apex 限制。因此，这些方法更具可扩展性。但请注意，任何 CPU 可以处理的并发请求数量仍存在物理限制。
- **中间件计划拉取。**通过使用中间件定期提取数据，而不是通过异步 Apex 推送数据，避免与高用量出站集成作业相关的延迟。中间件，例如 MuleSoft Anypoint 平台，可以同步使用本地 SOAP API 或 REST API，这样即使有延迟，也很少引入。中间件还可以对大数据量使用本地批量 API。
- **通过平台事件通知提取中间件。**您可以使用平台事件，而不是将 Future、Quueable 或 Batch 异步 Apex 排队以执行出站集成。平台事件可以传递出站信息，也可以指示中间件工具通过本地 API 提取所需信息，并将其传递到最终目的地。这两种方法都不受异步 Apex 延迟的影响。但[平台事件限制](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_limits_default.htm)仍适用。
#### 异步 Apex 权衡
| 产品/方法 | 用例 | 所需技能 | 与客户端异步 | 与服务器异步 | 强制执行的平台限制的类型 |
|---|---|---|---|---|---|
| Apex 未来方法 | 我们建议您使用 Queueable Apex，而不是 Apex 未来方法。队列具有与未来方法相同的用例，但提供了额外的好处。 | 赞成代码 | 是 | 是 | Asynchronous |
| Queueable Apex | 我们更喜欢这种方法，而不是未来的方法。用于涉及长时间运行的数据库操作或外部 Web 服务标注的进程。Queueable Apex 提供了比未来方法更多的优势，包括作业 ID、支持非原始类型和作业链。 | 赞成代码 | 是 | 是 | Asynchronous |
| 计划 Apex | 在 Cron 表达式定义的计划时间执行 Apex。虽然通过 Cron 表达式计划 Apex 的行为是一个异步过程，但底层代码会在作业开始时同步执行。 | 赞成代码 | 是 | 是 | Synchronous |
| Apex 继续标注 | 在同步事务上下文中运行的 Apex 方法的标注。 | 赞成代码 | 是 | 是 | Synchronous |
[提交后](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm)通过发布发布发布到总线的事件按顺序交付，可以由触发器或流在单独的同步上下文中批量处理。上下文是同步的，并强制执行所有同步调控器限制。请谨慎选择平台事件触发器/流批处理大小，以避免达到限制。
| 产品/方法 | 用例 | 所需技能 | 与客户端异步 | 与服务器异步 | 强制执行的平台限制的类型 |
|---|---|---|---|---|---|
| 平台事件触发器 | 将 Salesforce 与外部系统松耦合，并在异步平台组件之间通信。 | 低代码 + 专业代码 | 是 | 是 | Synchronous |
| 产品/方法 | 用例 | 所需技能 | 与客户端异步 | 与服务器异步 | 强制执行的平台限制的类型 |
|---|---|---|---|---|---|
| 计划路径（提交流后） | 在触发事件后，在动态计划的时间执行。 | 低代码 | 是 | 是 | Asynchronous |
| 异步路径（记录触发的流） | 执行您想要自行运行的操作，并避免混合 DML 错误。 | 低代码 | 是 | 是 | Asynchronous |
| 产品/方法 | 用例 | 所需技能 | 与客户端异步 | 与服务器异步 | 强制执行的平台限制的类型 |
|---|---|---|---|---|---|
| 出站消息 | 通过 SOAP 协议与第三方系统近乎实时地共享数据 | 低代码 | N/A | 是 | N/A |
| 产品/方法 | 用例 | 所需技能 | 与客户端异步 | 与服务器异步 | 强制执行的平台限制的类型 |
|---|---|---|---|---|---|
| 电子邮件转个案 | 根据传入电子邮件中的值自动创建个案并填充个案字段。 | 低代码 | 是 | 是* | Synchronous |
| * 电子邮件转个案作为同步和异步处理，但有同步 Apex 限制 | |||||
| 产品/方法 | 用例 | 所需技能 | 与客户端异步 | 与服务器异步 | 强制执行的平台限制的类型 |
|---|---|---|---|---|---|
| Batch Apex | 复杂、长时间运行的流程，涉及数千条记录 | 赞成代码 | 是 | 是 | Asynchronous |
| 计划触发的流 | 通过流，以指定时间和重复频率在后台对一批记录执行操作。 | 低代码 | 是 | 是 | Synchronous |
| 批量 API | 异步插入、更新、更新插入、查询或删除许多记录。 | 赞成代码 | 是 | 是 | Asynchronous |
**发现：**客服人员注册表提供了整个组织内所有 AI 客服人员和工具的集中目录。它支持发现和重用内部构建的、SaaS 嵌入的和外部资产。通过为所有客服人员资产提供单一的真实来源，客服人员注册表消除了冗余，并确保开发人员可以大规模利用现有功能。
**编排：**MuleSoft 客服人员代理是一个智能路由解决方案，可将任务与最合适的客服人员或工具动态匹配。它由您选择的 LLM 提供支持，跨客服人员和工具进行协调，以确保复杂的多步骤请求和业务流程以高可靠性和可追溯的结果来执行。
**治理：**[MuleSoft Agent 治理](https://www.mulesoft.com/platform/ai/ai-agent-governance)利用 Flex Gateway 及其对[模型上下文协议 (MCP)](https://www.mulesoft.com/platform/ai/model-context-protocol) 和 [Agent2Agent (A2A) 协议](https://www.mulesoft.com/platform/ai/a2a-support)的支持。通过 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 进行**搜索**。
### 示例
请参阅定义企业客服人员网络的[客服人员网络文件](https://docs.mulesoft.com/anypoint-code-builder/af-project-files)。此客服人员网络激活了网络，以便在 Salesforce、Stripe、另一个订单履行客服人员和库存 MCP 服务器之间履行订单，并提供单一、受策略管理的体验。
- **发现**
将现有客服人员和工具（例如 Salesforce、Strip、订单履行和库存）发布为 Exchange 资产，以便重复使用。此外，订单履行定义 (YAML) 是版本化和可共享的，无需重建流即可快速适应角色、区域或子公司。
- **编排**
代理经纪人使用 LLM 将订单履行流程分解为一系列任务，例如验证客户详细信息、分配库存和计算运输成本。然后，它通过调用 MCP 和 A2A 客服人员来执行此工作流，确保在需要时请求人工在环批准。
- **治理**
Anypoint Flex Gateway 强制实施身份验证、最低权限访问和防护。API 管理器策略确保对所有调用和数据交换进行一致的控制。
- **观察**
监控和跟踪提供了对进度、失败和延迟的端到端可见性。可视化显示哪些客服人员交互，以及瓶颈发生的位置。
- **信任与合规**
集中凭据、审计跟踪和保单继承支持安全、隐私和监管要求（PII 处理、批准和职责分离）。
该图显示了 YAML 中定义的客服人员网络（元数据）的不同节点。
## 客服人员注册表（发现）
- **目的**:Exchange 是客服人员、工具和其他资产的目录。其主要目标是通过提供单个受管目录来解决“客服人员蔓延”的问题，该目录用于异构客服人员的发现、管理和生命周期管理。它使开发人员能够找到并重用客服人员，平台所有者保持可见性，编配员能够发现功能。
- **设计异构**:Anypoint 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 中声明和注册。
```
agents:
orders-agent:
label: Order Fulfilment Agent
metadata:
protocol: a2a
platform: OpenAI
salesforce-agent:
label: Salesforce Agent
metadata:
protocol: a2a
platform: OpenAI
stripe-agent:
label: Stripe Payment Agent
metadata:
protocol: a2a
platform: OpenAI
mcpServers:
inventory:
label: Inventory MCP
metadata:
transport:
kind: streamableHttp
path: /mcp
llmProviders:
open-ai:
label: OpenAI
description: OpenAI LLM Provider
metadata:
platform: OpenAI
```
## 客服人员经纪人（组织）
客服人员代理是一个智能路由客服人员，负责协调企业中专业客服人员之间的任务委派。它由用于完成任务的客服人员和 MCP 服务器定义。
经纪人是在发布客服人员网络资产并由其他经纪人重用后显示在 Anypoint Exchange 中的专业客服人员。
经纪人在 YAML 的_经纪人_部分中定义。定义的经纪人被透明地“编译”到应用程序中，不需要任何关于 Mule 的先前 Knowledge。此生成的应用程序会部署到 CloudHub 2.0 (CH2)，并利用强大的 CH2 基础设施。
这意味着客服人员经纪人受益于 CloudHub 2.0 的既定性能特征，包括其日志记录和度量功能。操作方面，例如“运营成本”和“监控/警报/工具”，与任何其他工作负载相同。
对于需要人工干预的场景（人在线），每个交互的状态都通过使用 MuleSoft 对象存储来维护，这是一个分布式解决方案，旨在在高度并发的环境中进行有效的状态管理。
经纪人定义由两个部分组成：卡片和规格。
### 卡片
卡片部分遵循[客服人员对客服人员 (A2A) 规范](https://a2a-protocol.org/v0.2.5/specification/)。除其他外，它描述了经纪人的合同、技能和能力。卡片 URL 会自动填充值 ${ingressgw.url}/broker-name。在部署时，${ingressgw.url} 占位符会自动替换为客服人员入口请求前面的 Anypoint Flex 网关的 URL。
### 规格
规范部分配置经纪人的“源代码”。在这里，开发人员可以指定要使用的 LLM、说明、可用的工具、错误处理，以及最重要的是，该经纪人可以使用的各种客服人员和 MCP 工具。
**LLM 提供商**
该部分是每个经纪人规范的一部分。这是对服务部分中定义的其中一个 LLM 的引用。我们可以选择是否在所有经纪人之间共享一个 LLM，或者如果需要，让不同的经纪人使用更适合其任务的 LLM。
经纪人可以指向 LLM 提供商。我们可以根据需求选择这些提供商的型号。
```
llmProviders:
open-ai:
label: OpenAI
description: OpenAI LLM Provider
metadata:
platform: OpenAI
```
**说明**
此部分是可选的，您可以使用它指定特定于此代理的说明。这些说明通常侧重于特定的业务导向问题。例如，假设客户服务代理协调客户报告事件的管理：
```
instructions:
- |
You are an Incident Management Orchestrator Agent. Your primary responsibility is to coordinate the resolution of incidents reported by customers.
The process for incident management is:
1. Fetch Salesforce Case Details: Retrieve the latest critical case details for the given customer.
2. Fetch Entitlement Details: Obtain the customer's entitlement information.
3. Fetch On-Call Engineer: Identify the current on-call engineer for the incident.
4. Create Slack War Room and invite on-call engineer: Set up a Slack war room channel and invite the on-call engineer.
5. Summarize Actions: Provide a clear, human-readable summary of the steps performed, including information about the created slack channel and the on-call engineer assigned
```
请注意,没有必要提供明确的说明，例如**“将提示拆分为任务”或“选择最佳工具”**，因为经纪人自己处理。这些说明仅在描述特定业务流程时必要。
**工具配置**
工具为客服人员提供外部功能。每当代理需要访问外部系统（不是另一个代理，例如，现有 API 或 SaaS 服务）时，它会联系 MCP（模型上下文协议）服务器：
```
tools:
- mcp:
server: collaboration-mcp # MCP server reference
allowed: # Allowlist specific tools
- create_channel
- invite_user
```
MCP 服务器由交换资产的名称引用。它的连接详细信息在服务部分中指定。
默认情况下，经纪人可以访问 MCP 服务器中的所有可用工具。根据我们的观察，大多数现代 LLM 在每个上下文中只能处理大约 20-25 个工具，然后才会开始产生不准确（或失去上下文）。因此，将可用工具限制到所需的最低数量通常是一个很好的实践。您可以通过允许的列表应用该筛选。
**客服人员链接**
本节是整个定义中最重要的部分。链接部分启用客服人员间通信和编排。这意味着该经纪人依赖于在此处链接的客服人员执行适当的操作来完成用户的目标。
```
links:
- agent:
ref:
name: orders-agent
- agent:
ref:
name: salesforce-agent
- agent:
ref:
name: stripe-agent
```
实际上，本节定义了客服人员-网络协作。
## 弯曲网关（治理）
客服人员治理是客服人员结构的关键支柱，是构建可信客服人员网络并确保安全性和合规性的基础。
对于治理，您的专用空间中总共需要两个弯曲网关（一个入口和一个出口）。
治理建立了必要的结构、控制和证据，以安全地扩展整个客服人员开发生命周期 (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 的“规格”部分中提到的所有策略。您不需要额外的步骤。
```
salesforce-agent-connection:
kind: agent
ref:
name: salesforce-agent
spec:
url: ${salesforce-agent.cardUrl}
policies:
- ref:
name: message-logging
namespace: 68ef9520-24e9-4cf2-b2f5-620025690913
configuration:
loggingConfiguration:
- itemName: "Payload"
itemData:
message: "#[payload]"
firstSection: true
secondSection: true
level: "INFO"
- itemName: "Headers"
itemData:
message: "#[attributes.headers]"
firstSection: true
secondSection: true
level: "INFO"
```
## 客服人员可视化器（观察）
鉴于 LLM 客服人员和多客服人员部署的非确定性和复杂性，可观察性和监控至关重要。
- **基本日志和跟踪**:推理和工具执行跟踪通过日志提供。工作流执行的日志和跟踪可在运行时管理器中查看执行后情况。
- **度量**:在初始阶段，平台将 a2a_total_calls 和 mcp_total_calls 发布为带有标签（例如，路径、状态、方法、工具）的计数器，以确定呼叫总数、成功次数和失败次数。这些度量通过使用 Envoy 的 (Flex Gateway) 本地统计界面从策略代码发布，最好通过 mcp_support_policy 和 a2a_agent_card_policy 等现有策略。
- **增强的可观察性(未来)**:计划包括在未来版本中使用开放式遥测进行分布式跟踪。更高级的可观察性包括：
- **详细请求跟踪**:获取请求的端到端可见性，包括提示、计划员流程、调用的操作以及与子客服人员的交互。
- **客服人员健康监控**:监控客服人员正常运行时间、响应延迟、吞吐量、错误率和基础资源利用率（CPU、内存、网络、GPU）。
- **多客服人员协调监控**:捕获客服人员对客服人员交互的成功和失败率，检测循环调用模式（循环），并跟踪每个客服人员的度量，例如任务完成和调用计数。
- **成本跟踪**:通过仪表板和提醒，跟踪每个 LLM 呼叫的令牌使用情况和相关费用，理想情况下是每个客服人员。
- **认知跟踪**:捕获并显示客服人员会话的详细跟踪，包括内部思想过程和所有工具调用，作为不可变的审计跟踪。
- **客服人员会话播放**:一种 UI，允许直观地“重放”客服人员的认知跟踪，以进行深度调试。
- **DAG 可视化**:为复杂的多客服人员交互提供客服人员工作流执行的定向无环图 (DAG) 可视化。
客服人员可视化器用于识别客服人员网络的各个部分，并查看它们如何协同工作。
- 区分节点类型（客服人员和 MCP 服务器）。
- 查看边，以查看声明和运行时交互。
- 使用图层将视图集中在特定环境
- 打开详细信息卡，以检查节点的元数据和度量以及访问日志和跟踪
- 查看治理指标，例如弯曲网关保护和应用的策略。
在[此处](https://docs.mulesoft.com/agent-visualizer/agent-visualizer-components)查找有关客服人员可视化器组件的详细信息。
## 客服人员结构：四个支柱
通过这四个支柱，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 文件代表每个内部组织（员工成功、安全、财务等）。在每个组织（客服人员-网络）中，您可能有一个层次结构，通过这个结构，行为者进行协作，工作被分成任务和分配。在上图中，通信从上到下流动。而且，假期不仅限于一组经纪人代理的消费。
## 选项 2：域驱动的设计和代理 AI 实施
基于人员组织结构图对客服人员网络进行建模存在需要频繁重新设计的风险，特别是在频繁重组的公司。另一种方法是按功能域组织客服人员。这种分组可能需要跨越传统的人类组织边界。例如，新员工入职涉及硬件和用户配置的 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 计划。
# 导言
二十多年前，Salesforce 率先推出了第一个多租户云平台，开创了行业先例。自那时以来，Salesforce 已经发展成为一个全面的企业平台，能够封装和自动化业务的关键方面，并为各行各业和地区的成千上万家企业和数百万用户提供服务。Salesforce 还通过战略性收购增强了其 Customer360 产品套件。
在过去几年中，市场、行业和技术格局的转变使我们在基础 Salesforce 平台中实现了许多深刻的变革。其中包括：
- 大量投资于基础设施的公共云提供商的出现。
- AI 的快速进步，包括机器学习、生成式 AI 和客服人员体验。
- 跨行业和国家/地区增加数据驻留和监管要求。
- 需要以快速增长的规模处理实时数据和事务。
- 更加关注网络安全、系统可用性、性能和弹性的要求。
- 客户对集成套件的需求，该套件提供高度弹性、松耦合和高度一致的架构。
为应对这些变化，特别是 AI 的地震性转变及其对业务的影响，Salesforce 从头开始全面改造其平台，为下一代应用程序和客户用例奠定了基础，同时坚持我们的Trust目标。
Agentforce 在 Dreamforce 2024 上发布，下图代表了这一广泛努力的结晶，涉及数千名 Salesforce 技术和产品组织团队成员。目前，95% 以上的客户已经迁移到这个新平台。我们大部分客户的成功迁移，包括工作量最苛刻的客户，彰显了我们工程师的聪明才智,也重申了 Salesforce 的 Trust、Customer Success 和 Innovation 的核心价值。
自 Agentforce 发布以来,Salesforce 一直率先在企业应用程序中使用 AI，在开发客服人员体验方面处于市场领先地位，可为现有和新业务功能提供实时对话体验。
在与顶级工程师合作编写的本白皮书中，为了解重大技术变革背后复杂性的开发人员提供了详细的探索。该白皮书探讨了基本的架构增强功能，这些增强功能使平台保持可扩展性、安全性，并准备好处理未来的应用程序，同时满足客户不断变化的需求。建议您从“架构概述”一章开始，以了解全貌。从此处，读者可以按顺序继续，也可以探索最能吸引他们兴趣的章节。
_Emin Gerba__Salesforce 首席架构师_
## 2\.架构概览
以下 Salesforce Platform 的架构原则为我们如何设计特性和功能奠定了基础，并提供了不同之处：
- **企业级信任**:Trust 是 Salesforce 的首要价值,我们不仅优先考虑服务的可用性和安全性,还构建访问控制、合规和安全功能,以便客户可以通过 Salesforce Platform 满足合规和安全标准。
- **多租户**:所有服务和基础设施都专为托管多个客户而构建。这为随用随扩展提供了战略模式，并在可用性和安全性的共同高标准上实现了标准化，无论客户规模如何。
- **元数据驱动**:元数据是我们多租户服务可自定义性的核心。我们的元数据是可扩展的，因此管理员和开发人员可以基于现有的工作，并从 Salesforce 和生态系统合作伙伴未来的产品更新中受益。
- **API 优先：**Salesforce 平台优先考虑丰富和一致的 API 产品组合，该产品组合涵盖了可以通过 Salesforce 本地用户界面完成的一切工作。这允许开发人员和合作伙伴利用和重新组合平台的功能来集成系统或构建新的用户体验。
- **开放和可交互**:Salesforce 平台可以集成到客户的任何企业架构中。我们设计 Salesforce 平台是为了与其他基于云和本地的系统进行协作，并为外部系统集成提供 API、工具和集成标准，以便与 Salesforce 平台集成。
- **客服人员：**Salesforce 平台正在迅速发展成为整个应用程序套件中的客服人员优先。我们希望用户能够通过深入的客服人员对话体验与 Salesforce 互动，让他们能够以越来越自然的方式完成工作并与数据交互。
当前的 Salesforce 平台代表了自 2008 年 Force.com 平台首次发布以来 Salesforce 功能演变的最新阶段。最近的关键转换包括：
- 采用 Hyperforce 并转向基于云的架构。
- 从单片架构发展到具有独立服务的结构。
- 除了传统关系数据存储之外，还引入了 Data 360 和 Lakehouse 技术。
- AI 技术、生成式和机器学习的深度集成，以及向整个平台的客服人员体验的演变。
这些更改在没有显著中断的情况下扩展和完善了平台的功能，这要归功于强大的抽象功能，它允许 Salesforce 工程师以最少的客户中断无缝推进我们的技术。强大的抽象也仍然是 Salesforce Platform 简化企业级软件技术复杂性价值的关键，例如安全性、可用性和技术约定，这样应用程序开发人员就可以专注于解决他们独特的挑战。Salesforce Platform 的功能突出显示如下：
Salesforce 平台显示为组成系统的一组图层。每个层代表一组对构建于平台的应用程序很重要的相关功能。每个图层中的子框提供了这些功能的说明性示例。每个较低层的功能都集成到上面的所有层中，确保整个 Salesforce 应用程序套件之间具有一致和连贯的体验。
Salesforce 平台体现了过去 20 年开发的成熟技术平台所有层的广泛工程转换。在不断发展的客户需求和新技术的推动下，这些变化支持新的应用程序类型和解决方案。转换是相互关联的，较低层的变化会影响以上所有后续层的演变。
Salesforce 平台分为几层，每一层都有助于它的全面功能：
- **Hyperforce**:基础基础设施已从第一方数据中心发展为公共云提供商，并使用 Salesforce 技术进行了增强，以实现安全、合规、高可用性和经济高效的托管。
- **元数据框架**:为应用程序提供稳定的抽象来构建，即使我们拥有和使用的技术不断发展。包括对象关系映射器、规范性执行顺序，以及将元数据定义与元数据驱动的运行时桥接的“核心”运行时。
- **数据**:包括一个多租户关系数据库和一个 PB 级别的 Lakehouse，用于管理 Salesforce 和非 Salesforce 数据，支持非结构化数据和内容管理、高级搜索、治理和分析处理能力。
- **AI**:使用基础的可信 AI 技术构建数据层，这些技术利用预测性和生成性 AI 来支持客服人员体验。
- **应用程序平台服务：**为 IT 管理员、开发人员和供应商提供构建和自定义应用程序的工具，并提供有见地的抽象来简化常见和复杂的任务。
- **业务功能**:提供一系列功能来满足不同的业务需求，允许开发人员根据需要定制应用程序。
- **API 和 API 管理**:确保所有平台功能都可以通过格式良好的 API 访问，促进服务和层的相互依赖性。
- **用户和开发人员体验**:具有面向最终用户的用户友好界面，以及一系列开发工具（从低代码到专业代码），可用于应用程序开发和自定义，并支持现代 AI 驱动的开发。
- **集成**:与任何企业架构集成，通过数据连接器、零复制数据集成和其他工具实现与 Salesforce 和非 Salesforce 系统的兼容性。
- **应用程序和行业**:提供一套基于平台集成功能的可自定义应用程序和行业特定解决方案，利用各种底层功能，并与深度集成的 AI 客服人员协作。
## 3\.Hyperforce
Salesforce 开发全球数据中心基础设施已有近 25 年的历史，早于许多当前的超大规模者和 IaaS 供应商。Hyperforce 是 Salesforce 基础架构发展的新一代产品,旨在跨全球多个公共云提供商运行。
它专为满足客户对弹性 B2C 规模、全球数据驻留、增强可用性、顶级安全性和法规遵从性的需求而定制。Hyperforce 标准化了所有 Salesforce 产品的基础设施，促进了新收购的快速集成。
Hyperforce 确保 Salesforce 平台的交付，允许快速部署新功能和应用，满足全球 20 多个地区的数据驻留和监管合规要求。
### 3.1 架构原则
在 Salesforce 迁移到 Hyperforce 期间，发现超大规模器在服务、界面和合规级别方面存在显著差异。为了给 Salesforce Platform 构建一个强大和可移植的基础，采用了这些架构原则：
- **基础设施作为代码**:使用域驱动的架构，这一原则涉及基础设施的声明性编码，创建不可变的工件，并使用 Kubernetes 和服务网格等标准按需自动化基础设施。
- **零信任安全**:实施具有全面防御策略的 Zero Trust 安全模型，包括身份管理、身份验证、授权、网络隔离、最低特权安全策略，以及对传输和静态数据的加密。
- **受管服务**:该原则强调使用多租户和多云服务，增强了跨不同基础设施和环境的可移植性，例如商业、政府和空隙系统。
- **内置弹性**:关键任务服务分布在多个可用性区域，以确保高可用性。数据在可用性区域之间复制。服务还带有可用性分层标签，以管理服务级别目标和弹性规划。
- **完全可观察**:将所有服务集成到一个标准的可观察性平台中，以实现高效的监控，这包括日志收集、度量收集、警报、分布式跟踪以及服务操作的跟踪，例如流量、错误率和资源利用率。
- **自动化操作**:这包括基础设施生命周期的自动化管理和预测 AIOps（运营的 AI），以保持服务质量，检测和解决服务降级以及故障检测。
- **自动比例**:该原则侧重于可扩展性和成本效益，允许跨不同规模的运营灵活性，而不会增加运营风险，并抽象出与云提供商相关的特定客户限制。
- **FinOps 感知**:公共云带来基础设施灵活性，但存在成本升高的风险。我们在整个服务生命周期中奉行效率驱动的工程文化，同时不影响可用性、安全性和 Customer Trust。
这些原则指导了 Salesforce Hyperforce 平台的开发和运营，确保了它在各种环境中保持适应性、安全性和高效性。
### 3.2 基础设施概念
Salesforce 平台及其支持服务在 Hyperforce Foundation 上运行，该基础包括多个 Hyperforce 实例。这些实例战略性地分布在各个国家/地区，以符合客户对地理位置和可用性的偏好。为了满足严格的数据驻留和操作要求，一个或多个 Hyperforce 实例可以选择分组并指定为操作区域。每个实例都会定期更新，以确保安全性、可扩展性和符合本地和法律标准。
Hyperforce 实例由几个 Hyperforce 功能域实例组成，它们是提供特定功能的服务集群。基础功能域提供关键服务，例如安全、身份验证、日志记录和监控，所有这些都是其他 Hyperforce 服务所必需的。业务功能域支持各种 Salesforce 产品，例如 Sales Cloud、Service Cloud 和其他产品，为其产品功能提供便利。
功能域中的服务可以组织成单元，它们是可扩展和可重复的服务交付单元。Hyperforce 单元格对应于通常称为“Salesforce 实例”的内容，其中驻留一个或多个 Salesforce 组织（组织）。电池是比例单位，也是强爆炸半径边界。超级电池提供多个电池的逻辑分组，以划定更大的爆炸半径，因为电池之间共享服务。一个功能域中可能存在多个超级单元格。单元格和超级单元格允许 Hyperforce 在功能域中水平缩放，同时对爆炸半径的大小保持强大的控制。
每个 Hyperforce 实例都映射到一个可用性区域，这一概念存在于所有公共云基础设施中，并且能够独立于所有其他 Hyperforce 实例运行。Hyperforce 实例中的所有关键任务服务和数据都在至少三个可用性区域中分发和复制，以实现容错和稳定性。此外,数据备份会复制到其他合适的 Hyperforce 实例，以实现业务连续性和法规遵从性。
随着新的 Hyperforce 实例和单元格的创建或刷新到位，Hyperforce 基础设施正在不断发展。客户不会受到 Hyperforce 物理细节变化的影响。所有外部可见的客户端点都可以通过稳定和安全的 Salesforce My Domain（例如，acme.my.salesforce.com）访问，这些域安全地将流量路由到当前数据和服务位置。出站流量（例如，邮件、Web 标注）最好使用域密钥识别邮件 (DKIM) 和 mTLS 等安全机制来实施，以确保客户的本地基础设施不会硬编码 Salesforce 基础设施的物理细节，例如随时间变化的 IP 地址。
### 3.3 网络安全
Hyperforce 功能域采用强大的安全措施。每个域都在外围保护并隔离，域中的服务被分为专用帐户，以提高安全性。通过服务网格或类似协议，安全地促进服务之间的通信。流量管理由入口和出口网关处理，入口和出口网关检查、路由并将必要的控制（例如断路器）或速率限制应用于所有传入和传出流量。
Hyperforce 功能域中的服务被分组为安全组，只有边缘组中的服务才对公共互联网公开。运行时安全策略强制实施不同安全组之间的通信规则，遵守最低权限原则，以确保服务仅具有必要的访问权限。
每个地理区域都有一个 Hyperforce Edge 功能域，可以终止传输层安全性，并使用可编程的 Web 应用程序防火墙策略来先发制人地应对威胁。这确保了只有合法的流量到达 Hyperforce 端点，同时保持安全高效的客户体验。此外，Hyperforce 实例之间的内部网络链接受到严格控制，所有包含个人身份信息的日志数据都经过匿名化处理，以符合 GDPR 标准。
### 3.4 Hyperforce 网格控制平面
Hyperforce 网格包含共享相同控制平面的多个 Hyperforce 实例，用于在适当时隔离敏感工作负载。它确保任何客户或系统数据、平台元数据或跨网格监控数据的零泄漏。控制平面由冗余 Hyperforce 实例组成，这些实例托管创建、管理和监控面向客户的 Hyperforce 实例所需的基本服务。
所有 Hyperforce 服务的服务和基础架构代码都在专用控制平面功能域中安全开发，利用源代码管理、持续集成、测试和工件构建服务。生成的代码在打包到标准化的数字签名容器中并存储在图像注册表中之前，会扫描威胁和漏洞。代码部署由 Hyperforce 连续交付系统中的授权漏斗处理，部署权限仅限于授权团队和操作员。带气隙的控制平面处理此类环境中所需的额外保护措施。
身份和访问权限管理 (IAM) 服务强制实施即时批准，以限制访问持续时间和操作，而审计跟踪监控所有活动，并输入实时检测系统，以识别和提醒任何可疑活动。
### 3.5 Hyperforce 成本管理
随着 Salesforce 将服务从第一方数据中心迁移到公共云上的 Hyperforce,修改预算创建、成本可视化和资源优化策略至关重要。
我们的成本管理方法不仅仅是降低成本，它还是一个战略流程，区分以增长为目标的产品和以稳定为目标的产品。它规划基于消耗的定价和利润，维护产品可用性，符合我们的核心价值 Trust。公共云客户按层次组织，并与特定产品和执行官相关联。详细的服务级别资源标记（通过组织元数据丰富）有助于精确确定单个微服务的成本。Tableau 和 Slack 等工具以及高级预测工具可用于为高管和团队提供有关成本、预测和预算分析的实时数据，从而对未来的财务规划充满信心。
为了确保最佳成本管理，Salesforce 采用了计算节省计划、现场容量和按需容量预订 (ODCR) 的组合，保证了必要的容量。这些预订通过高级时间序列预测和自定义仪表板进行管理，允许人为监督和决策。在降低单位交易成本（处理已定义业务交易量的成本）上设定可实现的目标，是推动改进的有效策略。Hyperforce 单位成本资源管理器工具使团队能够分析和管理单位成本趋势，将成本归因于特定服务，并确定新的改进机会。Salesforce Cloud 优化指数或“COIN”分数根据节省业务机会的动态列表评估服务，激励服务团队保持最佳资源效率。
我们坚定不移地致力于可持续发展,积极追求减少碳足迹,设定具体目标来减少单位碳到服务,这是相对于所做工作的排放指标。
## 4\.企业级 Trust
安全性和可用性是我们企业级平台的关键基础方面，对于维护客户 Trust 至关重要。在 Salesforce，这些控制是 Salesforce 平台的组成部分，通过共享服务和软件框架自动强制执行。这种内置方法确保单个系统受益，而无需额外努力。
在数千个服务和数百个团队中，管理和持续增强这些广泛的安全和可用性控制是一项重大挑战。但是，这是至关重要的，因为忽略哪怕是很小的细节都可能导致安全漏洞或系统中断。
### 4.1 安全性
Hyperforce 是一个安全合规的基础设施平台，支持开发和部署具有高级安全功能的服务。它提供了强大的访问控制、数据加密和安全标准合规性。Salesforce 遵守 40 多个安全和合规标准，例如 PCI/DSS、GDPR、HIPAA、FedRamp 等。
密钥安全原则包括 Zero Trust 架构 (ZTA) 和端到端加密，确保在所有处理阶段保护客户数据。Salesforce 遵守从安全的软件开发生命周期到生产运营的安全标准和最佳实践，以及强大的应用程序级安全实践来缓解潜在的威胁。
#### Zero Trust 架构 (ZTA)
ZTA 网络安全模式确保所有用户、设备和服务连接都经过身份验证、授权和持续验证，而不论位置如何。ZTA 和公钥基础设施 (PKI) 对于现代网络安全、建立 Trust 边界和安全通信而不依赖于周边安全至关重要。
但是，PKI 部署往往忽视了证书撤销和对根证书颁发机构进行治理的重要性。Salesforce 的证书撤销实施功能强大且可扩展，支持端到端的 PKI 安全性。
此外,Hyperforce 通过服务之间的相互传输层安全性、使用短期私钥和基于角色的访问控制的用户即时访问来强制执行 ZTA。
#### 端到端加密
Salesforce 平台通过使用具有完美前向保密密码套件的 TLS 来确保传输中的数据保护，该套件在用户设备和 Salesforce 服务之间以及 Salesforce 基础设施域中传输数据时对其进行保护。
对于静态数据，Salesforce 平台使用由硬件安全模块支持的密钥管理系统。在其多租户平台中，为每个租户分配唯一的加密密钥，防止租户之间的密钥交叉。
通信和加密的安全性严重依赖于生成密钥或随机数据的熵。认识到由于可预测的密钥生成而导致加密协议容易受到攻击，Salesforce 平台通过为所有密钥生成过程从多个来源获取熵来降低这种风险。我们利用云服务提供商启用的各种处理器中提供的内存加密功能，以增强对冷启动攻击的保护。
#### 保护软件开发生命周期
Salesforce 有一个定制的 JDK 来满足许多合规标准，例如联邦信息处理标准 (FIPS)，通过免除开发人员和运营商自己承担合规工作的需要，简化了他们的流程。这种自定义不仅有助于防止 XML 外部实体注入 (XXE) 等风险，而且还增强了 Salesforce 的加密灵活性和根据需要交换加密策略的能力。它允许将不兼容的代码（无论是内部开发还是来自开放存储库）转换为符合 FIPS 的代码，而无需完全重写，从而减少了开发团队的工作量，并保持了对默认安全设计原则的遵守。
此外，Salesforce 通过将保护措施集成到安全软件开发生命周期 (SSDL) 中，整合了应对漏洞的框架，例如跨站点脚本 (XSS)、请求伪造 (CSRF) 和 SQL 注入。
通过基于角色的访问控制 (RBAC)，实施集中密码管理系统来保护服务和用户访问权限。此外，代码扫描工具还可用于防止通过源代码管理系统意外泄露生产环境中的机密。
#### Hyperforce 操作安全功能
网络钓鱼仍然是组织面临的一个重大威胁,导致 Salesforce 按照许多行业最佳实践(包括 CISA (Cybersecurity and Infrastructure Security Agency) Zero Trust 原则)实施抗网络钓鱼的多重身份验证 (MFA)。这包括为具有生产访问权限的员工提供的硬件备份密钥，以及用于控制云服务提供商帐户访问权限的安全内核。
为了保持强大的安全状况,Salesforce 已将安全控制标准化，并将云本地安全服务集成到 Hyperforce 中,从而增强了可见性、威胁检测和策略实施。全面的安全信息和事件管理系统适用于实时监控、警报和报告，由全面的漏洞管理计划和云安全状况管理工具提供支持，以持续识别、评估和补救漏洞。
此外，Web 应用程序防火墙会筛选和监控 HTTP 流量，以抵御各种攻击，并使用一系列网络安全工具，包括防火墙、入侵检测和防护系统、虚拟专用网络以及端点检测和响应代理，以提供持续的监控和威胁检测。实施网络细分和微细分是为了最大限度地减少攻击面并遏制潜在的漏洞。
Salesforce 还针对 Hyperforce 的独特挑战制定并实施了一个强大的事件响应计划，其中包含识别、控制和缓解安全事件的预定义程序，确保对潜在的安全威胁做出快速有效的响应。
### 4.2 可用性
Salesforce 管理需要高可用性的关键客户工作负载。我们的高可用性策略包括各种组织方面，例如服务所有权模型、事件管理和运营审查。我们战略的关键技术元素包括我们的监控架构、AI 驱动的操作自动化以及生产变更的自动化安全机制。
#### 可用性架构标准
为了在数千项服务中一致实现高可用性，三步法可以大规模管理技术风险。
首先，建立可用性架构标准，定义最佳实践，例如：
- **通过自动故障切换实现冗余**为了处理大型基于云的系统经常遇到的故障，Salesforce 通过高度冗余、全自动故障检测以及完全和部分故障的无缝自动恢复来构建其服务。
- **限制爆炸半径**。故障_会_发生,因此团队设计的所有服务都采用故意爆炸半径最大值来限制故障的影响。最经典和可见的示例是 Hyperforce 单元格 (fka Pod)。
- **分割失败**。防止故障在系统的独立单元之间扩散和复合。服务之间的容错 API 调用是防止分布式系统之间故障级联的关键模式。在此过程中，团队仔细平衡了分段和冗余。
- **自动缩放**。要在不降低性能的情况下为不可预测的负载提供服务，无需依赖缓慢、容易出错的人为运算符即可自动快速放大和缩小，这由 CPU、内存或队列深度等资源的饱和点触发。
- **快速回滚**。我们为所有服务设置回滚目标（以分钟为单位），并通过将前滚、后滚和再次前滚设置为默认操作，自动在生产前环境中测试回滚。该团队广泛使用功能标记，以实现更快、更精细的紧急切换和推出。
- **保护接收 API 调用的所有服务。**负载减少、租户公平限制、Web 应用程序防火墙和复杂的第七层保护部署在系统的所有级别，从我们直接暴露在互联网的最外围服务，到团队最深层的内部服务，这些内部服务可能意外受到更高级别呼叫服务中的错误的攻击。
- **通常是依赖**关系。服务之间的依赖性设计为尽可能软，允许它们独立失败或成功。缓存是最常见的模式之一 - 通常，下游依赖性产生的过时结果足以继续运行。
- **支持异步通信**。服务之间的异步代理通信使这些服务彼此分离，并在它们之间缓冲负载峰值。
- **使 API 调用具有容错性**。为了容忍部分故障和瞬时网络问题，我们使用几种模式：超时和截止日期、断路和带回退的重试。我们倾向于尽可能使用非阻止呼叫，以限制资源消耗和阻止。在构建时和集成测试时，通过模式级链接强制实施向后和向前兼容性。
- **管理服务定额和约束**。该团队在其服务车队中设置定额和约束，例如 IP 地址、磁盘 IOps 或给定 Kubernetes 群集的容量。该团队针对这些定额和约束的使用进行集中汇总、监控和提醒，以避免在运行时接近限制而影响系统。
其次，多层检查模型确保服务符合这些标准。这包括自动化的混沌测试、扫描和反模式的内联，以及与高级架构师的架构审查，以发现自动化没有解决的问题。
第三,解决方案集成到 Hyperforce 中,以轻松遵守这些标准。这包括自动遥测收集、默认冗余和故障切换机制，以及内置的保护，例如负载丢弃和 DDoS 防御，所有这些都是默认为单个服务激活的。
#### 监控和可观察性
Salesforce 会处理大量遥测数据，包括度量、日志、事件和跟踪，而传统监控解决方案并不总是能有效地管理这些数据。
为解决此问题，Salesforce 开发了一个与其软件开发生命周期、运营和支持功能集成的综合可观察性系统。该系统为工程和客户支持团队提供了统一的体验，同时满足了大规模需求，降低了第三方软件的授权成本。
Salesforce 的度量基础设施构建于 OpenTSDB 和 HBase，支持时间序列数据的大规模收集、存储和实时查询。非实时用例利用 Trino 和 Iceberg，每分钟处理超过 20 亿个度量，以提供 CPU 利用率、内存使用情况和请求率的见解。对于日志管理，Salesforce 使用 Splunk 的强大索引和搜索功能。Apache Druid 支持大规模事件数据的实时接收和分析，这对于理解用户交互和系统事件至关重要。跨微服务的分布式跟踪由 OpenTelemetry 和 ElasticSearch 管理，有助于识别特定的延迟和故障点。
Salesforce 还实施了应用程序性能监控 (APM) 基础设施，该基础设施与其数据收集和遥测存储的技术堆栈集成在一起。这种自动应用程序检测简化了数据收集，并确保了各项服务之间的一致性遥测。APM 的统一仪表板关联各种数据类型，增强了工程师通过内聚界面监控性能、诊断问题和优化系统的能力。
通过将可观察性工具标准化，Salesforce 使用分布式跟踪将服务之间的不同遥测类型联系起来。这将创建一个全面的服务依赖性图，可视化整个服务生态系统，并以精细的粒度跟踪请求。此功能对于精确定位问题、识别瓶颈和支持 AI 驱动的功能至关重要，例如异常检测、预测分析和自动补救。
#### AIOps 客服人员
为了增加事件解决时间，我们开发了 AI 运营 (AIOps) Agent，它代表人工运营者自动检测、分类和补救事件，并仅在少数情况下进行干预。AIOps 客服人员是一个可扩展的多客服人员反应性工具包，旨在促进基于反应性客服人员的复杂系统的开发。它是高度模块化的，可以使用各种工具来增强它的功能。它旨在随着客服人员数量的增加而高效扩展。主要功能包括：反应式架构，使客服人员能够动态响应其环境中的变化；工具增强，允许轻松集成工具，以扩展客服人员的功能；可插拔的计划模块，通过插入不同的计划模块，支持自定义客服人员的计划策略。
借助 Merlion 库中的高级机器学习模型，实现了 91% 的核心 CRM 产品事件的快速主动检测（在撰写时）。Merlion 库是一个公开可用的开源库，由 AI 研究小组开发。Merlion 是机器学习模型的集合，例如隔离森林、统计、随机森林和长期短期记忆 (LSTM) 神经网络，它们近乎实时地处理我们的系统生成的大量遥测数据。
79% 的事件（在编写本报告时）由客服人员的操作自动解决。我们的 AIOps 客服人员可以处理和分类数据向量，例如日志、简档、诊断、时间序列和特定于服务的工件，以推荐补救操作。AIOps 客服人员控制器和计划员选择具有特定技能的客服人员，以在生产中执行操作。
对于需要人工参与的剩余事件，AIOps 客服人员会高效地将未解决的问题分类到适当的服务团队。为此，它使用内部微调模型 XGenOps 智能地理解每个事件的性质和上下文，该模型根据操作数据集（例如问题记录、事件、JFR 和日志）进行训练，确保它被定向到具有必要专业知识的团队。这每周节省了超过 2800 小时的工程时间，减少了工程师分类未解决问题的需要。
#### 连续部署
为了管理每周进行的近 250,000 次生产更改导致的中断风险，完全自动化的部署系统被用来强制执行安全的更改实践，消除了人为错误。现成的系统没有足够的可扩展性或可定制性，这促使人们开发更定制的解决方案。
自定义连续部署系统遵循行业标准的蓝色/绿色部署策略，通过多层确保安全性：
- 每个更改的强制测试证据。
- 更改的初始金丝雀测试。
- 具有受控爆炸半径的交错部署。
- 部署阶段之间的浸泡和健康检查。
- 缓解与现有暂停和事件的冲突。
此外，持续集成系统已经过优化，可以运行数百万个 AI 选择的测试，实现快速发布，同时最大限度地减少回归风险。
## 5\.元数据框架
Salesforce Platform 的核心架构原则是元数据驱动的设计。Salesforce 工程师创建多租户服务和数据存储。平台上的每个应用程序本质上都是元数据的集合，可以定制单个客户如何使用这些多租户服务。这就是为什么 Salesforce Platform 的一个常见营销短语是“一切都可以通过元数据访问”。
该平台强调结构化和强类型的元数据。此元数据充当客户体验与基础 Salesforce 基础设施和实施之间的抽象层。这种方法提高了应用程序的可用性和质量。例如，客户不使用 SQL 模式定义和查询，而是通过 Salesforce 对象 (sObject) API 与实体、字段和记录等结构化元数据进行交互。这种设计允许平台集成新的数据存储技术或修改现有的数据存储技术，而无需重写应用程序，从而支持持续开发的最佳实践。
Salesforce Platform 架构采用“分层扩展”方法，支持构建和扩展应用程序的四个关键角色：
- **Salesforce 工程：**团队开发本地应用程序，例如 Sales Cloud 和 Service Cloud，它们通过广泛的发布流程部署到所有服务和运行时。这些应用程序通过许可和配置机制对所有租户可用。
- **外部合作伙伴**:独立软件供应商 (ISV) 和其他伙伴可以扩展 Salesforce 创建的元数据来构建增值解决方案，例如 Sales Cloud 数据模型的模式扩展或 Service Cloud 个案记录的其他验证规则。他们可以封装这些解决方案，以分发给多个客户。
- **特定于组织的 IT 管理员和开发人员**:他们可以自定义 ISV 提供的应用程序之外的应用程序，定制解决方案，以应对专有或特定于地区的流程等独特的业务挑战。
- **单个最终用户**:最终用户可以个性化他们的应用程序体验，例如更改列表视图中的列顺序或设置默认选项卡。
通过确保较低层不依赖于较高层中人物角色的更改，并通过维护强版本和向后兼容合同，每个人物角色可以独立迭代相同应用程序。
突出显示“分层扩展”概念的一个功能是记录保存执行顺序，它确保来自所有四个层的业务逻辑以可预测的顺序应用。这允许由组织管理员或 IT 开发人员确定的更具体、更高层次的业务逻辑，以便在保存记录期间适当地覆盖可能由 Salesforce 或外部合作伙伴提供的较低层次的逻辑。
此外，平台的元数据框架利用“核心”运行时和专有的对象关系映射器 (ORM)，该映射器内置多租户，连接到关系数据库。此核心运行时支持共享内存状态、引用完整性验证和事务性提交，这将优先考虑应用程序的稳定性，并增强应用程序部署的可靠性。该架构一直在不断发展，以支持不断增长的应用程序复杂性。例如，截至 2025 年 10 月，Salesforce 定义了超过 85,000 个实体，我们的客户定义了超过 3 亿个自定义实体。
历史上，Core Runtime 托管了大部分平台和应用程序功能。Salesforce Platform 的当前架构现在包括数百个独立的元数据驱动的服务。Core Runtime 仍然是应用程序元数据的单一记录系统，它利用了元数据管理的单片体系结构的独特优势。相关元数据会同步到独立服务的本地缓存，从而为应用程序运行时的各种可扩展服务提供支持。
## 6\.数据
数据是组织的重要资产，Hyperforce 为它在 Salesforce 中的存储提供了可靠的基础。关键挑战是以优化应用程序实用程序的方式存储数据。Salesforce 平台通过适应各种存储和访问要求，改变了数据层。它有效地平衡了成本、读/写速度、存储容量和数据类型，以满足不同的需求。
随着 AI 和分析日益塑造企业应用程序，数据已成为关键元素。它的重要性在于它使 AI 和分析能够学习、分析、决策和自动化流程。
数据源自记录系统 (SOR) 数据库，满足业务的运营要求。然后，它通过各种转换过渡到大数据平台，这对于支持 AI 和分析驱动的应用程序至关重要。
有效管理数据（从事务信息到分析见解），对于提取价值和支持复杂的应用程序至关重要。Salesforce 数据库 (SalesforceDB) 是管理 SOR 数据的最佳事务数据库，而 Data 360 是增强 AI 和分析功能的强大大数据平台。
### 6.1 事务数据库
事务数据和元数据对 Salesforce 平台至关重要。SalesforceDB 是一个现代的云原生关系数据库，专为 Salesforce 的多租户工作负载设计，类似于主要提供商的其他云数据库，但具有适用于 Salesforce 架构的自定义功能。它扩展 PostgreSQL，分离计算和存储，并利用 Kubernetes 和云存储，通过特定于租户的功能（例如加密和 Sandbox）增强操作。
SalesforceDB 处理所有事务性 CRM 数据，每月超过 1.1 万亿次交易，以及 Data 360 和相关服务的元数据。其主要目标是通过耐用性、可用性、性能和安全性确保 Trust；面向大客户扩展；并促进简化、可靠的云操作。它通过分离计算层和存储层的设计、不可变的分布式存储系统以及日志结构的合并树数据访问来实现这些目标。这支持高级功能，例如按租户加密存储中的数据，以及高效的 Sandbox 和迁移。
#### 架构概览
SalesforceDB 服务架构跨三个可用性区域运行，计算和存储跨这些区域复制，以确保系统保持可用，即使任何节点或整个区域丢失。所有服务都在 Kubernetes 中运行，以实现自动故障恢复和服务部署。
为了提供高级别的耐用性和可用性，SalesforceDB 的最终记录系统是云存储，例如 AWS 的 S3。归档和跨区域复制等操作在此云存储级别进行管理。存储对象不可变，增强了数据分发和复制，以实现高可用性。
由于云存储的高延迟，SalesforceDB 使用存储缓存访问数据。这些缓存是分布式存储系统，它们维护节点群集中存储对象的临时副本，确保数据库所需的复制和持久性。单独的缓存用于事务日志存储和数据文件存储。
SQL 计算层由三个不同可用性区域中的主数据库群集和两个备用群集组成。主群集处理所有数据库修改，而备用群集仅处理查询操作。
#### LSM 存储和访问
SalesforceDB 使用日志结构合并树 (LSM) 数据结构，其中更改最初记录在事务日志中并在内存中累积。然后，提交的更改被集体写入密钥排序的数据文件，这些文件被定期合并和压缩，以优化存储效率。
这种结构有效地消除了直接更新存储的数据库中常见的并发更新问题。通过使用 LSM 方法，SalesforceDB 支持不可变存储等关键功能，使其成为管理 Salesforce 工作负载的强大解决方案。
#### 不可变存储
存储中的数据是不可变的；一旦数据文件被写入并变为可见，它们就不会改变。事务日志仅作为附件，简化了数据访问模式，提高了可靠性。此结构支持非协调读取，简化了备份，提高了可扩展性，并促进了存储虚拟化，使其非常适合云环境。
#### 可用性和耐用性
SalesforceDB 中的事务跨多个可用性区域提交，这确保了即使节点或区域失败也不会丢失数据。如果出现故障，事务将在进行中中止，提交的事务将被成功恢复。由于失败不会丢失提交的数据，因此故障切换到新节点是自动的。
群集管理软件通过监控法定人数和管理所有权转移来自动处理故障转移。此流程不仅在紧急情况下使用，而且在定期修补期间也经常使用，通过持续使用增强了系统的可靠性。最终用户通常不会注意到短暂的数据库重新启动，从而保持无缝的用户体验。
Salesforce 每年进行三次主要模式更新，每周进行较小的模式更新。SalesforceDB 提供零停机时间模式操作，使这些更新能够在不影响客户的情况下完成。
#### 记录系统
我们的事务性数据库是客户数据的主要存储库，这些数据在多个可用性区域缓存并存储在云中。每个数据块都使用不可变的校验和进行保护，并由存储层和数据库引擎进行验证。数据库执行谱系跟踪，以检测任何无序更改或缺失的版本，并在索引和基表之间运行持续的一致性检查。
对于勒索软件保护，数据库会在不同帐户下的单独存储中归档，包括完整和增量事务日志备份。这些备份通过还原测试流程定期验证。此外，云基础设施已预配置但未激活，可根据需要管理数据还原请求。
#### 比例
每个 Salesforce 组织都位于 Hyperforce 单元格中，其中包含 SalesforceDB 服务。此设置允许通过 Hyperforce 架构创建新单元格进行快速全局扩展，并且流量可以在单元格之间轻松转移，以管理负载。但是，随着客户工作量和业务需求的增加，单个数据库实例的容量可能不足。
为了解决这个问题，SalesforceDB 为其存储和计算层采用了水平扩展架构。云存储几乎没有限制，缓存层会自动扩展以满足需求。此外，计算层可以通过添加更多数据库计算节点来扩展，这些节点可以高效地从共享的不可变存储中读取，而无需协调。这种方法允许 SalesforceDB 实现与领先的商业集群数据库架构相匹配或更高的可扩展性，而无需特殊的网络或硬件。
#### 多租户
Salesforce 是一个多租户应用程序，其中单个数据库托管多个租户。每个表记录都包括一个租户 ID 来区分其所有权，租户隔离是通过 Salesforce 应用程序层添加的自动查询谓词来维护的。
SalesforceDB 专为此模型定制，支持特定于租户的 DDL、元数据和运行时流程，增强了可靠性、性能和安全性。它结合了每行租户模型的低开销和每数据库租户方案的效率。
在 SalesforceDB 中，租户 ID 是多租户表中主键的一部分，这将在 LSM 数据结构中按租户集群数据，从而提高访问效率。此设置不仅有利于高效的数据访问和按租户加密，还简化了租户数据管理。由于元数据结构紧凑，租户可以轻松复制或移动，元数据调整最少。
### 6.2 Data 360 和数据湖
AI、分析和数据功能在现代企业中至关重要。企业已经在成熟的大数据平台上投资，例如 Snowflake、数据块、BigQuery 和 Redshift。然而，许多
由于数据孤岛、缺乏 AI 处理、数据过时或现有业务流程中的不作为，客户无法从他们的数据中获得业务价值。通过客户参与的单一视图，将客户数据集中到单一的真实来源，这对业务至关重要，并且由于数据分散和系统管理的复杂性而具有挑战性。Salesforce 通过将数据、AI 和 CRM 集成到一个良性循环中，在生成式 AI 和机器学习见解的驱动下，以数据为后盾，在促进客户的整体视图方面发挥领导作用。
SalesforceDB 针对结构化数据的高性能事务性工作负载进行了优化，而 AI 和分析工作负载需要处理来自各种来源的大量非结构化数据，并执行复杂的查询和批处理。为满足这些需求，Salesforce 开发了 Data 360，这是一个旨在打破数据孤岛、安全高效地统一、存储和处理数据的平台，支持 AI 和分析需求，并实现实时企业运营。
Data 360 基于 Hyperforce 构建,是 AI 和 Analytics 的基础平台，提供：
- 集成的基础设施和无代码平台，通过连接整合数据孤岛
- 实时和近乎实时的数据摄取
- 零复制联盟
- 用于处理的数据清理、准备和调整
- 结构化和非结构化数据的统一查询服务
- 开发用于见解生成的分析和 AI/ML 模型
- 数据触发的操作和激活
- 支持生成式 AI 检索扩充生成 (RAG)
- 基于策略的全面治理
Data 360 架构支持许多组件和功能，概述如下。
#### 连接、转换和协调
Data 360 支持来自各种结构化和非结构化数据源的高效接收漏斗，用于批量、近实时和实时数据处理。Data 360 的接收服务以提取-加载-转换 (ELT) 模式运行，专为低延迟设计，适用于 B2C 规模。实时摄取包括 API 和交互式流，而近乎实时的来源涵盖了详细的产品使用情况。一旦被接收，数据将被广泛转换来准备、协调（例如，统一各种联系人类型）和建模，以便进行有效的查询、分析和 AI 应用程序。该平台还包括一系列现成的统一数据模型。
Data 360 与 Salesforce 应用程序无缝集成，例如 Sales Cloud、Service Cloud、Marketing Cloud 和 Commerce Cloud。此外，它为外部数据源提供了数百个连接器，确保平稳的数据集成。
#### 适用于大数据的 Lakehouse
Data 360 采用基于 Iceberg/Parquet 的本地 Lakehouse 架构，旨在处理批量、流和实时场景的大规模数据管理和处理。该架构支持结构化和非结构化数据，这对 AI 和分析应用程序至关重要。
在 Azure、AWS 或 GCP 等基于云的数据湖中，基本存储单元是文件，通常组织成文件夹和层次结构。该 Lakehouse 通过引入更高级别的结构和语义抽象来增强这种结构，以促进查询和 AI/ML 处理等操作。主要抽象是一个带有元数据的表，它定义了其结构和语义，包含了来自开源项目的元素，例如冰山或三角洲湖，并由 Data 360 添加了额外的语义层。
Lakehouse 中的抽象图层：
- **Parquet 文件摘要**:在基础部分，存储由 Parquet 格式的数据湖文件（例如 AWS 中的 S3 或 Azure 中的 Blob）组成。源表的数据在多个分区中存储为 Parquet 文件，每个表是这些文件的集合。
- **冰山表摘要**:表格被组织为文件夹，数据分区在这些文件夹中存储为 Parquet 文件。对分区的修改会生成新的 Parquet 文件作为快照。对于每个表，Iceberg 会管理元数据文件，并详细说明模式、分区规格和快照。
- **Salesforce Cloud 表摘要**:该层构建于 Iceberg 之上，添加语义元数据，例如列名和关系，以及配置，例如目标文件大小和压缩。它抽象了各种平台的表，例如 Snowflake 和数据块，将 Data 360 应用程序与底层存储平台特定功能屏蔽在一起。
- **Lake Access 库**:此库提供对 Salesforce Cloud 表的访问权限，处理数据和元数据，并为应用程序开发人员抽象底层存储机制。
- **大数据服务抽象**:这包括处理框架，例如用于查询的 Trino 和 Hyper，以及用于跨任何云表平台的处理的 Spark。
Data 360 Lakehouse 支持 B2C 规模、实时接收、处理、模式实施和演进、快照，并使用开放存储格式。
#### 实时存储
为了支持实时分析和客服人员应用程序，Data 360 通过额外的低延迟存储 (LLS) 来扩充湖泊小屋的大数据存储。Data 360 的实时处理层分析内存中的实时信号和参与数据。由于基于内存的存储容量有限，无法一次处理所有数据。Data 360 添加此 LLS 以消除此类限制，从而实现可扩展的实时处理。
低延迟存储是 Lakehouse 上的 NVMe (SSD) 存储层。它是一个持久的缓存 - 大多数数据最终会保存到湖泊中，以便长期保存。实时层中的会话数据可以刷新到低延迟存储中，以便后续快速访问。例如，在客服人员对话中，最近的消息可以在内存中处理；较早的消息可以刷新到 LLS。如果需要之前的对话，可以在几毫秒内从 LLS 访问它。基于 NVMe 的存储允许以毫秒延迟存储和访问大量数据。数据可能会流向湖滨别墅，以便长期保存。
此外，实时处理或增强实时体验所需的来自湖泊小屋的数据将被检索并保存在 LLS 中。例如，客户简档上下文是预先提取的，或从湖泊小屋中获取，并缓存在 LLS 中。此外，任何 Lakehouse 对象和会话期间实时处理所需的其他对象也可以缓存在 LLS 中。LLS 支持在真正的存储层次结构上使用内存、SSD 和 Lakehouse 存储层的实时层，数据可在它们之间无缝迁移。
Data 360 还提供强大的安全性支持，包括带有客户受管密钥的租户级加密 (TLE)，以及通过其治理技术的隐私和合规性。核心是基于属性的访问控制 (ABAC) 支持，它根据与实体、操作和环境因素相关的属性动态评估访问权限。此系统支持任意和强制访问控制。
作为 ABAC 的补充，详细的数据分类系统按灵敏性和目的对数据进行分类，增强了合规性、风险管理和事件响应。ABAC 和该分类系统共同提供全面的数据治理，确保 Data 360 中的数据得到安全高效的管理。
#### 元数据驱动
Data 360 与 Salesforce 平台深度集成，适用于元数据、打包、可扩展性、用户体验和通过 AppExchange 的应用程序分发。客户可以定义和管理 Lakehouse 流和表格的元数据，就像其他 Salesforce 元数据一样。每个数据对象（包括联合或外部表）都表示为 Salesforce 对象，并建模为 Data 360 中数据存储支持的虚拟实体。开发人员可以使用它们来在 Salesforce 平台上构建应用程序。
#### 零复制联盟和可扩展性
Data 360 提供对零复制联盟的广泛支持，允许用户与外部数据仓库（例如 Snowflake 和 Redshift）、Lakehouse（例如 Google BigQuery、数据块和 Azure Fabric）以及 SQL 数据库和包括 Excel 在内的各种文件类型集成。Data 360 支持基于文件和查询的联盟，具有实时查询和访问加速，如图所示。标签 (1) 和 (2) 说明了 Data 360 的查询（包括实时查询推送）和基于文件的聚合，用于从外部数据湖/仓库/数据源访问数据；标签 (3) 突出了加速从外部数据湖/数据源进行聚合访问。标签 (4) 和 (5) 说明了 Data 360 中的数据与外部数据湖/仓库的查询和基于文件的共享。功能还扩展到非结构化数据源，例如 Slack 和 Google Drive，它们可以通过 Data 360 的非结构化处理漏斗访问。此外，Data 360 有助于对 Salesforce 对象进行抽象，以及对从外部来源聚合的数据的访问，从而支持跨 Salesforce 平台和应用程序访问此类数据。
#### 客户数据平台 (CDP)
Data 360 集成了具有高级身份解析功能的 CDP，创建统一个人标识符和简档以及全面的参与历史记录。该平台通过支持使用精确和模糊匹配规则的身份图，能够处理企业对企业 (B2B) 和企业对消费者 (B2C) 框架。这些身份图使用来自各种渠道的参与数据丰富，这有助于构建具有宝贵分析见解和细分的详细简档图。
此外，CDP 支持跨不同平台的有效细分和激活，例如 Salesforce 的 Marketing Cloud、Facebook 和 Google。它批量、近乎实时和实时地处理客户简档，这允许立即做出决策和个性化。此功能增强了 B2C 和 B2B 场景中的交互，确保企业可以快速准确地响应客户需求和行为。
#### 数据图形
Data 360 提供 JSON 格式的企业数据图，这是一个从各种 Lakehouse 表及其相互关系派生的非标准化对象。这包括 CDP 创建的“简档”数据图，其中包含人员的购买和浏览历史、个案历史、产品使用情况和其他计算见解，并且可由客户和合作伙伴扩展。这些数据图形专为特定应用程序定制，并通过提供相关的客户或用户上下文来增强生成式 AI 提示的准确性。
此外,还计划扩展这些数据图形,以包含 Knowledge 图形,这些图形捕获和建模派生 Knowledge,例如从非结构化数据中提取的实体和关系。Data 360 的实时层使用简档图进行实时个性化和细分。
#### 实时图层
Data 360 的实时层旨在以毫秒级延迟处理事件，例如 Web 和移动点击流、访问、购物车数据和结账，从而增强客户体验的个性化。它持续监控客户参与，并使用实时参与数据、细分和计算从 CDP 更新客户简档，以实现即时个性化。
例如，当消费者在购物网站上购买商品时，实时层会快速检测和接收此事件，识别消费者，并使用更新的终身支出信息丰富他们的简档。这允许在几秒内个性化他们在站点上的体验。此外，该层包括实时触发和响应的功能，支持基于客户交互的即时操作。
#### 个性化
个性化是知道要针对哪个角色，何时何地提供相关内容和推荐，说什么以及频率。Data 360 的个性化服务平台功能是决策的编排者，通过个性化体验优化目标实现。此平台提供以下功能：
- 在 Data 360 中解释简档、活动和资产数据的一致模型和方式。
- 平台集成实验（例如，A/B/n 或多臂强盗决策）。
- 在设计时通过配置、ML 训练时间和运行时集成目标（ML 推理）。
- B2C 规模、实时和批处理交互支持（匿名用户、高用量实时/交互式外部、高用量内部批处理）。
- 通过 Data 360 进行 Analytics。
- 集成 AI 模型和其他方（内部和外部）的服务的模式。
- 高价值 AI 驱动的用例的 OOTB 实施（使用各种 ML 算法的推荐和决策，包括促销/内容选择的上下文强盗、产品推荐和定价决策）。
#### 数据操作
Data 360 是一个支持激活漏斗以响应数据事件的活动平台。例如，重大事件（例如客户帐户余额下降）会触发 Salesforce 流来编排相应的操作。同样，对关键度量的更新，例如终身花费，可以自动传播到相关应用程序。
#### 数据计算结构
Data 360 具有弹性缩放计算集群，可高效处理处理任务。它为多租户和专用计算环境提供了强大的管理。此外，它为 Spark 和 SQL 提供受管支持。BYOC（自带计算/代码）功能支持多种编程语言，包括 Java、Python 和 Spark，允许集成自定义转换、模型（包括 LLM）和函数，增强了可扩展性。
Data 360 计算交换矩阵提供称为数据处理控制器 (DPC) 的统一层，用于管理和执行所有大数据工作负载。DPC 是一项全面的多工作负载数据处理编排服务，跨不同的云计算环境提供作业即服务 (JaaS) 功能。它抽象了基础设施的复杂性，并统一了 Spark（EC2 上的 EMR 和 EKS 上的 EMR）和 Kubernetes 资源控制器 (KRC) 工作负载等框架的作业执行。通过充当集中控制平面网关，DPC 跨多个数据平面编排、计划和监控作业，确保可靠性、可扩展性、成本效率和一致的开发人员体验。
#### 统一查询
Data 360 的查询服务提供高级查询功能，通过 Trino 和 Hyper 为结构化和非结构化数据提供广泛的 SQL 支持。它通过表函数增强了具有运算符可扩展性的功能，允许跨文本、图像、空间和其他非结构化数据类型进行多种搜索操作。这些功能与关系操作无缝集成，例如选择客户记录。这种统一的方法能够生成有针对性的个性化结果，便于使用 RAG 做出更准确的 LLM 响应。
#### 非结构化数据处理
Data 360 支持跨数据接收、处理、索引和查询机制无缝存储和管理结构化（表）、半结构化 (JSON) 和非结构化数据。Data 360 支持文本之外的各种非结构化数据类型，包括音频、视频和图像，从而扩大了数据处理和分析的范围。下图显示了接地的两个方面（摄取和回收）。
Data 360 通过将非结构化数据存储在列中作为文本或存储在大型数据集的文件中来管理它。它支持非结构化内容的数据联合，这允许集成和管理来自多个来源的数据。
Data 360 的非结构化数据索引漏斗设计为模块化、可扩展的架构，包括五个核心阶段：解析、预处理、分块、后处理和嵌入。然后，这些阶段是关键字和向量索引。预处理的示例包括噪声消除、语言规范化和图像理解（光学字符识别）等操作，而后处理阶段可能包括元数据丰富、语义分组或高级技术，例如分块。
Data 360 提供了多个现成的可插拔模型，用于分块和嵌入生成。Data 360 中的数据漏斗完全支持代码扩展，允许客户和内部团队在任何阶段插入自定义逻辑。这些阶段还支持基于 LLM 的处理，这允许客户根据需要定义自己的提示。
对于索引，Data 360 支持利用搜索服务的关键字索引，以及利用 Milvus 的向量索引；这是一个开源的本地向量索引。对于使用非结构化处理设置 RAG，Data 360 利用上下文索引，利用示例测试查询实现快速迭代和快速验证，并配置特定于角色的内容，以根据消费角色或用户进行定制。
Data 360 的文档 AI 功能支持从发票、简历、实验室报表和采购订单等文档中读取和导入非结构化或半结构化数据。此功能支持临时交互处理，以及批量处理。这是为客户实现业务流程自动化的关键功能。
#### 语义层
Data 360 具有无头语义层，带有 API，旨在增强业务语义和 AI/ML 驱动的分析，类似于 Tableau Next。该层包括一个语义数据建模服务，它使用业务分类（例如评测和度量）来丰富传统的分析模型。
其语义查询服务使用声明性语言与这些模型交互，将查询翻译成 SQL，以从 Data 360 中的本地和联合数据源访问数据。
这种集成促进了可扩展的交互式分析探索、报表和仪表板，并与第三方可视化工具兼容。
#### 数据治理
Data 360 充当集中治理中心，确保所有数据（从原始摄取到激活的见解）都得到完整和控制的管理。Data 360 采用了基于属性的访问控制作为其核心授权模型。ABAC 允许根据用户的属性（部门、角色、位置）、数据（个人信息、敏感度、数据空间）和环境（例如一天中的时间）而不是预定义的角色来做出访问决策。这将支持高度精细和上下文访问策略，并随着数据和用户属性的变化而调整。Data 360 的 ABAC 实施的核心是使用 CEDAR 策略语言。这种专门构建的开源正式策略语言提供了一种精确和可验证的方式来定义复杂的授权规则，确保策略明确无误，并且能够以一致的规模进行评估。
治理生命周期包括有关策略信息、实施和决策点的关键功能：
- **标记和分类（策略信息点）：**使用关键属性识别和丰富数据。Data 360 提供了自动标记和分类机制，利用发现、LLM 和机器学习来识别结构化和非结构化数据中的敏感数据类别（例如，个人身份信息，例如电子邮件、电话、姓名）。
- **授权服务（策略实施点）：**此服务会拦截来自各种消耗层（混合结构化/非结构化查询、RAG 检索器和提示以及 CRM 丰富）的所有数据访问请求，并咨询策略决策点以确定是否允许访问。
- **策略评估引擎（策略决策点）：**该引擎从策略实施点获取访问请求上下文，以及策略定义（在 CEDAR 中）和策略信息点的属性，以做出权威的访问决策。
带有 CEDAR 策略的 ABAC 框架提供了控制和灵活性，确保客户数据不仅可操作，而且在整个企业中安全、合规和可信。
### 6.3 数据缓存
缓存对于快速访问频繁使用的数据至关重要。Salesforce 在 Salesforce 平台中使用多个缓存，包括在核心应用程序服务器、SalesforceDB 和 Edge 中。Salesforce 平台和应用程序需要一个低延迟和高吞吐量的可扩展租户感知缓存解决方案。此解决方案必须允许 Salesforce 工程师控制缓存的内容以及缓存的时间，以确保他们的数据不会被系统噪音或其他客户的数据驱逐。Vegacache 是基于 Redis 的 Salesforce 受管缓存服务，专为多语言、多租户和公共云环境定制。它被 Salesforce 服务广泛使用，平台开发人员可以通过 Apex 编程语言 API 访问它。在 Hyperforce 中大规模运行，截至撰写时，Vegacache 每天以亚毫秒的响应时间处理超过 2 万亿个请求。
Vegacache 实例在通过服务网格访问的 Kubernetes 容器中运行，并跨多个可用性区域部署，以平衡数据可用性和延迟。它根据系统负载自动扩展，确保数据可用性和时段顺序保留。Vegacache 为每个客户提供有保证的缓存大小，并针对干扰邻居提供保护，同时通过复制的数据存储对基础设施故障具有弹性。
对于 Salesforce Platform 开发人员，Vegacache 使开发人员能够缓存 Apex 对象和 SOQL 数据库查询结果，通过消除从 SalesforceDB 获取不必要的数据来减少 CPU 使用和延迟。它支持 Put()、Get() 和 Delete() 操作，使频繁使用的对象易于访问。
### 6.4 Asynchronous Data Processing
Salesforce 本地支持异步数据流程和架构，以增强工作流的灵活性、弹性和可扩展性。
Salesforce 工程师首先利用消息队列来解耦批量和大型数据流程，并协调独立系统之间的流程。这些消息队列是通过平台功能从外部开发人员那里抽象出来的，例如批量 API 查询或异步 Apex。然后，Salesforce 平台引入了基于内部受管 Apache Kafka 群集的强大消息传递基础设施构建的日志组织事件流。这启用了具有发布/订阅交互模型的基于事件的架构，并作为平台事件向外部开发人员进行了产品化。
消息队列和事件流仍然是构建在平台上的应用程序和解决方案的高度利用的技术，特别是因为它们利用了在独立运行时托管的更多功能、云和外部系统。通过版本化事件模式进行通信支持不同运行时的独立软件开发生命周期。通过事件解耦系统也有助于管理单个运行时的负载峰值和弹性/规模，以支持应用程序的整体弹性和可用性。
### 6.5 企业搜索
Salesforce 的搜索功能对于从全局搜索到生成式 AI 的各种应用程序至关重要，它面临着独特的挑战，这些挑战影响着我们的架构方法：
- **比例**:我们的云原生搜索解决方案支持数十万客户和数百万租户，旨在大规模使用，同时保持经济高效。
- **客户多样性**:Salesforce 跨多个行业的不同客户群具有独特而复杂的搜索要求，因为平台的广泛自定义涉及大量对象类型和字段。
- **可操作性**:搜索解决方案必须具有弹性和高可用性，支持数据驻留、租户生命周期操作，例如区域迁移和 Sandbox，并在租户之间保持低索引延迟和公平。
- **规模相关性**:提高搜索结果的相关性以满足不同的用户查询至关重要，尤其是当我们扩展相关性算法以适应不同的租户、数据类型和搜索场景时。
- **AI 和语义功能**:搜索支持机器学习和生成式 AI，特别是检索扩充生成 (RAG) 和代理搜索。
- **无缝集成**:为了确保用户体验的一致性，Salesforce 的搜索技术与更广泛的 Salesforce 平台进行了深度集成，包括元数据模型和 AI/数据服务。
Salesforce 的云原生解决方案 SeaS（搜索即服务）构建于开源分布式搜索引擎 Solr 之上。Salesforce 已显著扩展和优化 Solr，以应对我们独特的挑战，并将其与 Salesforce 应用程序和平台深度集成，同时整合了语义技术，以增强 AI 应用程序和搜索相关性。
SeaS 采用计算/存储分离架构，允许在节点之间扩展索引分配，并在故障期间跨区域重新平衡负载和可用性。它具有自动碎片整理和调整碎片大小、零停机时间升级以及副本惰性加载和归档等优化功能，以满足很少使用的索引。
该架构还包括针对大量字段优化的低级别索引实施、自动完成、拼写更正和自带密钥加密。Hyperforce 搜索基础设施在全球管理大约 6,000 个 Solr 节点,在每个区域使用多个独立的集群(Hyperforce 单元)来平衡成本和控制,并根据负载、域和类型自动放置客户端索引。
Salesforce 的搜索相关性漏斗采用学习排名技术，适应客户的不同需求，并支持结果排名等功能。它还包括来自用户查询和过去交互的实体预测。相关性模型通过学习用户交互不断优化，并通过 A/B 测试进行评估，从而提高搜索结果的准确性。此流程还支持通过 Knowledge 转移为 AI 应用程序建立引导模型。
该堆栈整合了语义搜索和 AI 应用程序的向量搜索引擎，并与 Data 360 集成，以实现生成式 AI 功能。这包括用于数据转换的综合漏斗、混合搜索支持、可配置排名器目录，例如深度融合排名器和自动删除，以筛选出低相关性的搜索结果。
由于生成式 AI 正在将搜索服务的主要消费者从人类用户转移到使用 LLM，Salesforce 搜索堆栈正在调整，以查找并返回针对这种编程消费优化的结果，处理更长和更复杂的查询，并返回更多描述性结果，例如块。这支持新的客服人员搜索功能，其中 Agentforce 客服人员通过推理循环利用搜索来完成复杂的任务。
Salesforce 的搜索功能跨越各种上下文，包括全局搜索、查找、搜索答案、社区搜索、相关列表、设置、移动和生成式 AI 应用程序。通过将搜索堆栈与 Salesforce 的元数据系统和 UI 生态系统紧密集成，实现了这一广泛的功能，实现了对标准和自定义对象的无缝支持。
此外，与 Data 360 的集成通过无代码配置增强了数据对象上的搜索功能，并允许在数据漏斗中组合搜索功能，例如在 SQL 查询中包含搜索语句。搜索堆栈利用 Data 360 丰富的连接器生态系统，例如 Google Drive 权限感知连接器，提供完整的企业搜索功能。该集成扩展到 AI 平台，使搜索查询能够在基础训练的提示生成器和客服人员搜索中用作检索器。
## 7\.AI 和 Agentforce
AI 改变了技术格局，Salesforce 平台及其集成和丰富的数据层使 Salesforce 能够为客户提供具有影响力的 AI 体验。Salesforce 在近 10 年前开始其 AI 转型，自 2013 年以来一直领导该领域，专注于研究、道德和产品开发，以使企业能够解决复杂的问题并推动增长。
利用创新的核心价值,Salesforce 引入了 Einstein 预测式 AI,使企业能够通过一套全面的 AI 支持工具(例如 Einstein 预测生成器和 AI 机器人)来分析数据、自动化流程、了解客户并优化运营。随着生成式 AI 的兴起,Salesforce 推出了 Agentforce，这是一个结合了预测和生成模型的平台，在优先考虑数据隐私的同时提供了高级 AI 功能。
最近发布的 Agentforce 3.0 通过事件驱动的框架构建于 Python 之上,Salesforce 通过内置对话历史记录、端到端会话跟踪、语音支持和自定义推理引擎 (Bring Your Own Planner) 功能等功能引入了增强的灵活性,实现了更具可扩展性、可定制性和智能性的多客服人员系统。
### 7.1 核心 AI 原则
Agentforce 遵循这些核心原则：
- **数据安全和道德**:优先考虑数据保护、合规性和道德 AI 原则。
- **透明度和可解释性**:提供对 AI 生成的输出的明确理解和验证。
- **灵活性和自定义**:根据特定需求和行业定制 AI 应用程序。
- **无缝集成**:与 Salesforce CRM 和其他系统集成。
- 可**扩展性**:处理大规模部署，并提供实时 AI 体验。
- **智能一致的体验**:通过连接的数据和上下文理解，提供个性化的、增强的和自动化的体验。
- **综合可观察性：**提供对 AI 客服人员交互的深度可见性和监控，以使用 Agentforce 交互资源管理器主动优化和微调客服人员。
### 7.2 架构概览
AI 堆栈由几个关键部分组成：
- **AI 平台**:该平台层负责管理、训练和微调在预测和生成应用程序中使用的 AI 模型。它提供现成的 (OOTB) 服务、Trust 服务和基础模型，用于对模型进行培训、测试和执行推理。此外，它支持集成您自己的预测和生成模型，允许您在平台中引入自定义模型。
- **AI 基础服务**:这包括 AI 网关、反馈框架、RAG、客服人员编排、客服人员评估和推理服务，这些服务促进了业务应用程序与 AI 堆栈的集成。
- **AI 支持的用户体验和客服人员体验**:Salesforce 通过其云服务提供专门的 AI 支持的应用程序。客户还可以利用平台的任何组件（例如 Flow、Apex 或 Lightning Web 组件 (LWC)）创建自定义体验，以创建无缝集成到工作流和业务流程中的 AI 支持的体验。
- **Agentforce Studio**:该组件具有客服人员生成器、提示生成器、测试中心和模型生成器等工具，旨在创建生成式和预测式 AI 体验。它为开发/训练、测试和调整 AI 模型提供了端到端的支持。Next Gen Authoring 增强了这些功能，旨在通过改进的 UX 和与 SFDX 的兼容性来简化和加速 AI 客服人员构建。
### 7.3 基础组件
#### Agentforce Trust 层
Agentforce Trust 层适用于选定的用例，通过提供强大的功能来帮助保护生成式 AI 应用程序中的客户数据：
- **数据隐私**:强大的屏蔽和隐私控制保护了敏感信息不被外部 AI 模型访问。
- **安全性**:确保安全的数据处理环境，并防止未经授权的访问。
- **信任**:维护客户对数据的控制，没有第三方 AI 存储或使用。
- **护栏：**强制执行客服人员行为标准，并缓解 LLM 固有的不确定性，验证客服人员是否一致地遵循预定义的说明和工作流。
- **精度**:通过使用相关的 Salesforce 数据对提示进行基础训练，增强 AI 输出。
- **内容管理**:提供内容前和内容后管理、敏感信息的可自定义数据屏蔽 (PII/PCI/PHI)，以及大语言模型 (LLM) 响应的毒性分类。
#### Agentforce AI 网关
AI 网关为访问和管理各种 LLM 和预测模型提供了统一的界面。它充当了 Salesforce 和 LLM 世界之间的桥梁，抽象了不同 LLM 提供商和客户自己的预测 AI 模型的复杂性，提供了与他们交互的一致方式。Agentforce AI 网关与多个 LLM 提供商集成，允许客户选择适合其需求的最佳模型，并包含强大的数据安全措施，以帮助管理与使用不同 LLM 相关的成本。
反馈服务是收集、分析、衡量和利用用户反馈以重新训练和优化 AI 模型的组件。它在持续改进 Salesforce 平台中 AI 驱动的特性和功能方面起着至关重要的作用。
#### 检索扩充生成 (RAG)
RAG 是一种重要技术，它通过生成式 AI 增强搜索功能，从而产生更丰富和更准确的响应。Agentforce 平台利用广泛的 Salesforce Data 360 和集成的向量数据库，快速检索用户查询的相关数据。然后，这些数据用作 LLM 的基础，以生成最佳响应。
此外，该方法通过在响应中包含源数据，提高了响应速度和用户 Trust。RAG 在 Agentforce 平台中广泛使用，特别是适用于 Agentforce for Service 和适用于销售的 Agentforce 等应用程序，突出显示了它如何显示这些用例的相关信息。
### 7.4 Agentforce 平台
随着 AI 模型的推进，开发客服人员来自动化需要推理的任务是下一步。这些客服人员充当智能助手，能够以自然语言理解和响应查询，允许用户为各种任务设计、测试和部署它们。该系统的一个关键组成部分是计划员服务,其职能如下:
- **解释用户请求**:它分析用户的输入以确定意图。
- **构建计划**:它制定结构化计划来满足用户的需求。
- **启动操作**:它通过直接启动操作或通过其他服务执行计划。
计划员服务会编排流程，通过管理和执行必要步骤，确保客服人员高效满足用户请求。
#### Agentforce
Agentforce 代表构建客服人员的平台，使客户和 ISV 能够为服务客服人员和销售客服人员等应用程序创建自动化 AI 客服人员。这些客服人员能够以自然、人性化的方式处理和回复客户查询，处理广泛的业务任务，并为企业和客户带来巨大好处。
客服人员的工作流包括：
- **激活**:客服人员由预定义的条件触发，例如客户跨各种渠道的请求。
- **理解和响应**:它使用自然语言处理 (NLP) 来理解客户的查询、意图和情绪，然后咨询 Salesforce 的 Knowledge 库或其他数据源来制定适当的响应。
- **处理复杂性**:如果遇到复杂问题或需要人工监督，客服人员可以顺利将交互移交给人工客服人员。
- **持续学习**:客服人员从每次交互中学习，不断增强响应和整体性能。
#### Agentforce Studio
Agentforce Studio 提供了一个低代码平台，使客户能够将 AI 集成到他们的 Salesforce 应用程序和工作流中，使 AI 技术不仅仅局限于数据科学家。
Studio 的主要功能包括：
- **模型生成器**:允许构建或导入根据特定业务需求定制的 AI 模型。
- **提示生成器**:一个无代码/低代码工具，方便创建和管理生成式 AI 提示，通过构建、测试和部署提示的简单界面增强用户体验。
- **客服人员生成器**:使客户和 ISV 能够开发定制的对话和自主客服人员。
- **测试中心**:支持模型、提示和客服人员的测试，这对于确保高质量的 AI 应用程序、优化性能和成本效益至关重要，同时增强了确定性响应和用户体验的质量。
Agentforce 结合了预测性和生成性 AI，利用 Salesforce Platform 和 Data 360 的统一元数据框架来提供智能、个性化和有效的业务解决方案。
### 7.5 下一次演进：Agentforce 3.0
为了满足生成式 AI 市场的加速需求，包括推理的快速发展、对可扩展多客服人员系统的需求以及向多模式界面的转变，Salesforce 正在使用 Agentforce 3.0 发展其架构。这一下一代平台建立在几项重要改进之上：
- **异步事件驱动架构：**Agentforce 3.0 建立在 Python 基础上，具有增强的事件驱动框架。这支持异步和高度可扩展的客服人员实施，提高了性能，并为客服人员可以通过事件进行通信的复杂、多客服人员用例奠定了基础。
- **多模态语音功能：**Agentforce 3.0 超越了基于文本的交互,引入了对语音作为主要模态的支持。该架构与电话服务提供商和 WebRTC 网关集成，以处理实时音频流。新服务管理音频到文本 (ASR) 和文本到音频 (TTS) 的转换，为自动化联系中心等用例提供自然的对话语音体验。
- **Agentforce 脚本和确定性：**一种基于状态的拦截机制，在明确定义的结构中约束客服人员的行为，确保一致的执行路径。这支持确定性图表，提供强大的状态管理以防止内存丢失，并促进有条件和 LLM 确定的切换，从而确保关键业务流程的客服人员操作可预测和一致。
## 8\.应用程序平台服务
Salesforce 平台的应用程序生态系统的特点是集成了应用程序平台服务、API、用户体验和开发人员体验层的功能。应用程序平台服务是用于在 Salesforce 平台上构建和自定义大多数应用程序的常见功能，而业务功能通常更特定于解决方案。
### 8.1 关键功能
应用程序生态系统建立在五个关键功能之上，这些功能指导应用程序开发过程。
- **租户**:这涉及多租户服务中数据和元数据的逻辑分离，允许经过身份验证的用户访问特定的数据和功能。当客户在注册时收到 Salesforce 组织时，这一点对他们最明显。
- **实体**:代表数据库表的实体由类似于表列的字段组成。实体和字段元数据包括数据建模的属性，例如数据类型和 API 名称，以及功能属性，例如实体是否可以查询或写入。这种抽象，而不是直接操纵数据存储本身，允许 Salesforce 无缝引入和切换存储技术，而无需 IT 开发人员的更新，从而确保了连续的应用程序功能。
- **访问控制**:这些控制主要根据用户身份和特定策略来规范用户对数据和功能的访问权限。策略由规则和功能切换组成，并管理可以访问的实体、字段和功能。策略和权限在“权限集”中捕获，通过将权限集分配给用户身份来授予访问权限。
- **分层扩展**:如前所述，这支持不同角色（包括 Salesforce 工程师、外部合作伙伴、IT 管理员和最终用户）在结构化保存订单和元数据命名空间的帮助下独立开发元数据和应用程序。
- **打包**:此功能允许在 Salesforce 租户之间捆绑和分发元数据，简化应用程序的更新和分发过程，而无需重新构建。
除了这些主要功能之外，应用程序平台服务还包括：
- **数据运行时和查询**:支持跨几个专用数据存储创建、更新、删除和查询数据等操作。一系列数据规模和性能都由一个架构提供支持，该架构能够直接在数据存储上运行数据操作，通过内部抽象供 Salesforce 工程师使用，或者通过面向客户的“Salesforce 对象”或 sObject 约定。
- **流/工作流/公式**:使用低代码工具定义和执行业务逻辑和验证规则。
- **Apex Code**:应用程序逻辑的专业代码语言，与平台数据运行时和 API 本地集成。
- **云原生基础设施服务：**Heroku 为使用行业编程语言和框架构建、部署和管理与平台数据和事件集成的应用程序的开发人员提供了一个强大的环境。
- **事件和通知**:管理触发器和基于事件的编配。
- **全球化**:支持多语言和多国应用程序。
- **许可和配置**:处理平台功能和应用程序的购买和管理访问权限。
- **Lightning Web Stack**:允许使用结构化元数据（例如布局和标准 Web 技术）自定义可视界面。
- **站点 + CDN**:确保低延迟和高流量 Web 体验，包括未经身份验证的用户。
- **安全与合规**:提供满足特定组织安全和合规要求的工具和控制。
- **数据丢失防护**:包括数据备份、还原和归档的功能。
### 8.2 云应用程序平台
Salesforce 平台通过 Heroku 提供一套工具和功能，使开发人员能够使用他们选择的编程语言和框架在云中构建、运行和管理应用程序。Heroku 的受管云应用程序平台提供应用程序运行时、数据存储、消息传递队列和事件系统作为可扩展的服务，以构建 Salesforce 应用程序的扩展。
在 Heroku 上运行的应用程序可以访问全套 Salesforce 功能、客户数据和业务逻辑，并能够与第三方系统和服务连接。借助 Heroku，开发人员可以专注于交付价值，而不会受到底层基础设施问题的负担。
## 9\.自动化
自动化是使应用程序动态化的因素，对于基本业务流程的数字化变革至关重要。
Salesforce 流程自动化的创建旨在解决客户面临的关键挑战，包括随着组织规模的扩大对简化和高效业务流程的需求。这些挑战通常涉及需要过度手动操作的工作流，导致效率低下和运营成本增加。客户寻求的解决方案可以自动化这些流程，最大限度地减少手动劳动，并保持一致性和准确性。
一个重大问题是缺乏一种用户友好的工具，使非技术用户能够在没有大量编码技能的情况下设计和实施业务流程。此外，需要一种解决方案，它可以安全、可扩展、无缝地与现有的自动化 Salesforce 任务集成，例如数据输入、批准、通知和复杂的多步骤流程。
Salesforce 流程自动化通过为创建自动化工作流提供强大但直观的平台来满足这些需求。它使用户能够通过可视界面构建和自定义流，技术和非技术用户都可以访问，从而在 Salesforce 生态系统中自动化重复任务、强制执行业务规则并简化流程。
对于需要复杂编排与事务数据交互的自动化，Salesforce 提供 Apex 作为编写业务逻辑的专业代码语言。
### 9.1 流程自动化架构和功能
**可视逻辑生成器**:客户和 ISV 使用 Flow Builder（拖放界面）创建流程自动化流，无需编码。该可视化工具对所有技术级别用户友好，允许业务分析师和管理员轻松设计复杂的自动化。
Flow Builder 使客户能够创建在各种上下文中操作的通用流，核心流引擎支持：
- **记录触发器**:流会在记录更新或表单提交时激活，从而根据客户操作启用数据修改、验证和工作流启动。
- **计划或事件驱动的流**:这些流可以按照预定的计划运行，也可以在特定事件后触发，并且可以调出外部服务。
- **屏幕流**:为带有表格、屏幕和其他交互式元素的逐步指导流程提供用户界面，这对数据输入、故障排除或入职培训等任务非常有用。
- **编排流**:管理和集成多个步骤流程，方便处理复杂操作。
离线流引擎可以在没有连接到 Salesforce 应用程序服务器的情况下运行。离线流支持 Field Service 移动用例的自动化。大规模流引擎支持市场营销流。它提供 B2C 规模，用于同时处理大量长时间运行的流。
Flow Builder 中的统一元数据模型增强了所有用例和环境，该模型支持适用于所有流程自动化流的各种强大的逻辑元素：
- **高级逻辑和条件**:用户可以将复杂的逻辑（例如决策元素、循环和等待条件）集成到他们的工作流中，允许处理复杂的业务场景。
- **数据管理和转换**:Flow Builder 支持从各种来源接收、转换和管理数据，包括 Web 服务、Salesforce 组织和 Data 360。它支持全面的数据操作，例如记录的创建、更新、删除和查询。
### 9.2 跨 Salesforce 平台的自动化
Salesforce 流程自动化提供与其他 Salesforce 产品和第三方系统的无缝集成，确保应用程序之间的数据流畅通，以实现业务流程和客户交互的统一视图。它支持各种集成方法，例如 API、Web 标注和 MuleSoft 连接器。
Salesforce 中的外部服务和 MuleSoft 连接支持与外部 API 的连接，并在 Salesforce 流程自动化中利用其数据。注册 API 模式允许创建无缝集成到流中的可调用操作，便于使用外部数据源实现流程的自动化。MuleSoft 强大的集成功能确保了 Salesforce 和其他应用程序之间的无缝数据流，消除了数据孤岛，并提供了业务流程的统一视图。
**Agentforce 整合**:Salesforce 流程自动化利用 Agentforce 通过智能决策增强工作流。它使用 AI 见解自动将潜在客户定向到合适的销售代表，或者根据客户行为启动定制的营销活动，从而通过增加智能来提高自动化的效率。
**平台协同作用**:Salesforce 流程自动化与其他 Salesforce 产品无缝集成，例如 Sales Cloud、Service Cloud、Commerce Cloud 和 Marketing Cloud。这种集成使组织能够自动化各个部门的流程，从而提高运营效率。例如，当客户投诉通过 Marketing Cloud 表单提交时，工作流可以在 Service Cloud 中自动生成支持个案。
### 9.3 使用 Apex 实现 Pro-Code 自动化
Apex 是一种强大的面向对象的编程语言，允许开发人员编写自定义业务逻辑并在 Salesforce 平台上执行复杂操作。它一直是我们平台的支柱,目前该平台每月处理超过 3500 亿 Apex 交易(截至 2025 年 10 月 ) 。
Apex 用于开发各种自定义功能，并与 Salesforce 平台深度集成，包括：
- **基于触发器的自动化**:实施在插入、更新或删除记录之前或之后执行的复杂自动化。这允许复杂的数据验证、相关记录更新，以及根据特定数据更改调用其他流程。
- **Web 服务：**创建与外部系统的自定义集成，并从 Apex 调用 REST 或 SOAP API。
- **自定义用户界面**:使用 Visualforce 和 Lightning Web 组件 (LWC) 构建高度自定义的用户界面和体验，其中 Apex 充当后端控制器来处理数据操纵和业务逻辑。
- **自定义 API：**开发人员可以使用 Apex REST 和 Apex SOAP 将自定义逻辑公开为 API，使外部系统能够以编程方式与 Salesforce 数据和流程进行交互。
- **异步处理**:通过未来方法、Quueable Apex 和 Scheduled Apex 异步运行长时间运行或资源密集型任务。这允许在后台卸载和处理长时间运行的操作，从而改善用户体验和系统性能。
- **计划 Apex：**开发人员可以使用 Apex Scheduler 计划 Apex 类在特定时间运行，以执行夜间数据同步、报表生成和维护活动等定期任务。
## 10\.用户体验
Salesforce 平台上的用户体验功能使最终用户能够通过跨基于浏览器的 Lightning 应用程序、体验站点、移动原生、面向 AI、协作 UX 或使用 Lightning Out 的嵌入式组件的各种部署选项与应用程序进行交互。
### 10.1 Lightning 设计系统
Salesforce Lightning 设计系统 (SLDS) 是一个综合设计框架，支持使用 Salesforce 的设计原则创建一致和可访问的用户界面，以便在所有产品之间实现一致的用户体验。它使 Salesforce 工程师、客户和合作伙伴能够构建在整个 Salesforce 生态系统中感觉原生的应用程序。
设计系统的关键功能包括：
- **设计模式**:针对常见设计挑战的成熟解决方案，为布局、数据展示和用户交互提供了指南，以确保一致的用户体验。
- **造型鉤**:代表设计决策的 CSS 变量，例如颜色、排印、间距和大小，确保应用程序之间的一致性。
- **Lightning 基础组件库**:一组可重复使用的 UI 组件，例如按钮、表单元素和导航元素，符合 Salesforce 的设计原则，便于快速高效地开发。
- **可访问性**:内置无障碍功能和指南，以确保所有组件可供残疾人使用，并遵守 Web 内容无障碍指南 (WCAG) 等标准。
- **响应布局**:灵活的网格系统和布局指南，允许应用程序在不同设备和屏幕尺寸之间无缝适应。
- **工具**:支持组件卫生、反模式减少和设计系统治理的工具、资源和技术的集合。
SLDS 框架继续发展，以支持更丰富的样式挂钩和更深入的自定义功能，这样组件可以重复使用，同时仍然可以自定义，以满足独特的品牌化和主题化要求。我们的设计系统目标是使 Salesforce 快速、轻松和令人信服地与 AI 一起使用。
### 10.2 Lightning Web 堆栈
Salesforce 基于浏览器的界面称为 Lightning，它为 Salesforce 工程师、IT 管理员、开发人员和合作伙伴提供了一致的 UI 容器和元数据驱动的 UI 框架以及技术集合，以通过一致的 Salesforce 美学快速开发 UI，并提供扩展点来完全控制重新设计样式和品牌。Lightning Web 堆栈包括几种技术：
- **Lightning Web 组件**:使用 HTML 和 JavaScript 构建的自定义 Web 组件，遵守 W3C Web 标准。
- **Lightning Web Security**:一个虚拟化引擎，用于管理浏览器中的 JavaScript 代码，确保符合 Salesforce 的第三方代码安全标准。
- **Lightning数据服务**:一个用于与服务器端数据高效交互的框架。
- **Lightning Web Runtime**:确保跨各种客户端的性能和一致的 UI 渲染。
Salesforce 工程结合了以前 UI 技术的经验教训，并为 Web 标准机构做出了贡献，影响了基于标准的组件实施的开发。例如，Salesforce 仍然是大约 20 个 W3C 工作组的成员。Lightning Web 组件和 Lightning Web 堆栈符合这些行业标准，降低了开发人员的复杂性。
### 10.3 移动
对于用户与 Salesforce 应用程序交互，移动设备仍然是增长中的关键界面。
Salesforce 提供本地移动应用程序，因此所有基于浏览器的 Lightning 应用程序都可以成为移动应用程序，而无需编写新代码。Salesforce 还提供一系列工具、SDK 和功能，用于创建针对设备优化的完全自定义本机应用程序。其中包括：
- **移动 SDK**:面向移动操作系统开发人员的专业代码界面，简化了与身份验证、会话/令牌管理、Salesforce API 等的集成。
- **移动本机运行时**:使开发人员能够使用也利用设备上功能的 iOS 和 Android 技术创建元数据驱动的本机体验，并在运行时动态呈现。
- **品牌化**:允许通过 Mobile Publisher 漏斗自定义移动应用程序美学，将 Salesforce 移动应用程序转换为客户品牌化应用程序。
- **离线功能**:确保无缝应用程序功能，互联网连接不一致或没有。
移动自定义框架 (MCF) 通过提供易用性和广泛的自定义选项，显著增强了本地 Salesforce 移动应用程序的开发。关键优势包括：
- **元数据驱动的方法**:MCF 利用元数据（可以从可视生成器、通用存储库和 Salesforce 托管的资源中获取）来创建根据特定需求定制的动态和适应性强的用户体验。
- **实验和优化**:该框架支持不同布局的运行时实验，促进持续的参与优化和用户体验优化。
- 可**扩展性**:MCF 专为灵活性而设计，允许将自定义组件集成到核心元数据框架中，增强了功能和通用性。
- **可组合用户体验**:MCF 利用最新的 iOS 和 Android 技术，支持组装按钮、列表和卡片等可重用组件，以构建复杂的用户界面。
- **运行时自定义**:MCF 支持实时 UI 自定义和实验，培养更具个性化和吸引力的用户体验。
在移动设备上使用应用程序时，离线和低连接场景是一个日益严重的问题。移动技术堆栈优先考虑构建可以离线优先的应用程序。主要功能包括：
- **缓存首次体验**:专注于缓存数据以供离线使用，确保高性能和安全性。用户交互的设计也考虑了离线渲染原则。
- **缓存管理**:保持缓存的相关性和更新，即使在离线时。
- **共享缓存**:为本地和混合屏幕使用单个缓存，促进无缝离线体验。
Nimbus 是该平台的生产就绪解决方案，它简化了混合应用程序开发人员访问设备功能的过程。传统上，弥合 JavaScript 和移动本地代码之间的差距是一项复杂的任务。然而，借助 Nimbus，开发人员现在可以充分利用移动设备的潜力，而无需深入挖掘低级编码。主要功能包括：
- **广泛访问**:提供与各种设备功能的无缝集成，例如摄像头、麦克风、地理位置和 LiDAR。
- **标准化界面**:提供访问设备功能的统一方法。
- **混合应用程序集成**:使混合应用程序能够充分利用设备功能。
- **高效开发**:简化应用程序开发流程，降低复杂性。
随着 AI 继续改变 Salesforce 应用程序的可能功能，Salesforce 还通过利用设备上特定于任务的 AI 模型以及基于云的解决方案来提供差异化的用户体验：
- **小语言模型 (SLM)：**这些可以在移动设备上高效运行，成本更低。
- **隐私和安全：**确保用户隐私，并在与基于服务器的模型相当的级别上保持 Trust 和安全性。
- **离线功能：**在低连接环境中有效运行，启用离线用例。
- **语音：**现在，最先进的语音到文本、自然文本到语音和说话人二值化模型在设备上本地运行，提供完全隐私和零延迟的高保真语音交互。
### 10.4 AI 和协作
适用于自然语言和与我们的应用程序进行多轮交互的非模型 UI 将继续流行。未来的发展预计将增强模型、设备功能和应用程序之间的集成，通过更直观的语音和文本界面改善用户交互。设备上的度量集合也将允许用户根据用户首选项进行个性化调整。
所有用户（包括人工和客服人员）之间的协作至关重要，可以发挥自动化和人工监管的综合优势。这种协作对于涉及组织员工及其客户的复杂业务互动尤其重要。Slack 是 Salesforce 平台中的主要工具，通过直接消息传递和针对特定讨论主题定制的多用户渠道来促进这种交互。这些讨论的范围可以从自发的用户创建的对话到围绕用户工作流中特定数据的更结构化的对话，例如解决重大客户问题的详细 Slack 消息线程。
展望未来，Salesforce 平台计划增强 Slack 目前提供的协作体验。该扩展旨在充分利用该平台的广泛功能，丰富用户在数字工作区中交互和协作的方式。
## 11\.开发人员体验
平台上的 Developer Experience 功能为构建、自定义、测试和部署应用程序提供了工具，通过支持代码的方法重点关注低代码的范围，确保各种技能水平的开发人员都有平等机会。
- **低代码工具**:这些组件包括适用于数据模型的方案生成器、适用于业务规则的流和适用于 UI 自定义的 AppBuilder，所有这些都旨在通过操纵结构化元数据和使用业务解决方案的语言而不是技术概念和行话来简化开发过程。
- **Pro-Code 工具**:对于需要更丰富和复杂自定义的开发人员，该平台提供了 Salesforce Code Builder 等工具，这是一个基于云的 IDE，以及用于高级编码和组件创建的命令行界面 (CLI) 和 API。开发人员可以通过使用 Heroku 部署、管理和优化应用程序的解决方案，使用他们选择的语言进行编码。
- **集成开发环境**:Salesforce 生态系统支持低代码和专业代码工具之间的无缝集成，以及与行业标准工具在云内和本地进行一致的开发。
- **应用程序生命周期管理 (ALM)**:具有一系列独立于生产环境的开发 Sandbox 组织，包括用于初始开发的临时组织和用于针对类似生产的数据和规模进行测试的完全 Sandbox 组织。
### 11.1 AI for Developers
AI 和“开发人员助手”正在通过简化和加速创建高效、高质量的应用程序来彻底改变开发人员的体验。在 Salesforce，我们的 AI 研究和开发人员体验团队不断迭代，并探索如何将具有代理推理的预测性和生成性 AI 转化为强大的开发人员代理。这些开发人员代理与开发人员已经使用的工具本地集成，例如 VS Code、Code Builder、命令行、DevOps Center 和 Code Analytics，使它们更具相关性和影响性。
我们在代码分析方面取得了重大进展,以识别 Apex 代码中的反模式和热点,然后提供重要建议来改进它们的实施。确定的问题通常会浪费计算资源，并经常导致大规模事故。它于 2024 年 1 月作为 ApexGuru 见解发布。
在发布后的第一年，超过 2,800 个 Salesforce 组织使用 ApexGuru 来分析和改进他们的 Salesforce 实施。成功执行了 22,000 多条建议，每周节省了 28,000 个 CPU 小时。这种增强不仅提高了性能,而且通过每周减少 135 kg CO2 排放量而促进了环境可持续性,这符合我们可持续发展的核心价值和对降低碳排放的承诺。
我们还将 AI 集成到支持代码的开发人员工具和功能中，以提高 Developer Productivity。2024 年产品化为“适用于开发人员的 Agentforce”，开发人员可以在 Visual Studio 代码和代码生成器中访问 Salesforce 扩展包中的这些新功能。这些扩展支持：
- 开发人员编写时内联代码建议，以及 Apex 和 Lightning Web 组件的代码生成（JavaScript、CSS、HTML）。
- Apex 和 Lightning Web 组件的代码解释和文档生成。
- Apex 单元测试代码生成。
- IDE 中独特的多轮聊天体验，可用于代码生成、解释和文档的多个响应。
- Lighting Web 组件优化。
- 具有人类可读的 YAML 元数据的客服人员生成，包括客服人员测试和调试功能。
截至 2025 年 10 月，每月有超过 42,000 名开发人员积极使用这项技术，接受了 1760 万行代码。此综合套件可确保灵活、集成和高效的开发环境，满足 Salesforce 平台内的各种开发需求。AI 开发人员工具也通过跨多个外部和 Salesforce 构建的模型工作的架构得到了增强，以便为给定的用例选择最有效和高效的模型。
### 11.2 MCP 支持和 AI 辅助编码
模型上下文协议 (MCP) 是一个新兴的开放标准，旨在允许 AI 客服人员安全一致地与任何工具或数据源交互。Salesforce 正在将 MCP 支持本地集成到 Salesforce 开发人员工具包中，以帮助开发人员客服人员访问其企业中的功能和工具。这包括：
- **本地 MCP 服务器：**本地 MCP 服务器允许开发人员在部署到生产环境之前，在本地 IDE 中轻松构建、测试和调试他们的代理集成，从而极大地提高了工作效率。本地 MCP 服务器为组织交互和开发工作流提供了专用工具，例如移动开发、可访问性测试、Aura 到 LWC 迁移和客服人员 DevOps。本地 MCP 服务器还包括与代理推理和 LLM 的集成，以更好地使开发人员能够以自然语言迭代“生动地编码”他们的应用程序。
- **适用于 Salesforce API 的自定义 MCP 服务器：**开发人员现在可以安全地将 Salesforce API、Data 360 对象和自动化流公开为 MCP "工具 " 。这将整个 Salesforce 平台转化为任何外部 AI 客服人员或应用程序的丰富、可信和可发现的功能集，并带有精细的访问控制和基于消费的新货币化模型的潜力。
- **本地外部 MCP 连接：**开发人员还可以安全地管理与符合 MCP 标准的外部服务器的连接。这使得开发人员能够构建可以在他们的企业中工作的客服人员。
## 12\.应用程序套件
我们的应用程序云，包括 Sales Cloud、Service Cloud、Marketing Cloud、 Revenue Cloud 和 Commerce Cloud，构建在 Salesforce 平台上，提供领先的业务功能，并组成我们的应用程序套件来推动客户成功。主要功能包括：
- **无缝集成**:深度集成，旨在在整个客户旅程中协调一致地工作，并确保客户接触点之间的数据和流程流畅，增强客户体验。
- **端到端的可自定义性**:基于我们的平台，我们的应用程序提供了从无代码到专业代码的广泛自定义选项，允许根据客户需求进行精确定制。
- **高级 AI 功能**:通过 Agentforce 客服人员，提供客服人员协助和基于客服人员自主交互渠道的工作流。整合预测和生成式 AI，通过自动化、预测分析和个性化用户体验提高效率，并提供可操作的见解和建议。
- **实时数据处理**:利用 Data 360 进行实时数据访问和分析，支持基于最新信息的及时和明智的决策。这增强了快节奏环境中的响应性和灵活性。
- **统一数据和 Analytics**:将各种数据源集成到一个集中平台，以获得一致和全面的数据视图，提供准确的分析并改进决策。
- **增强安全性和合规性**:具有强大的安全和合规工具，以保护敏感数据并满足监管标准。
- **消费者级用户体验**:提供直观、用户友好的界面，使应用程序能够在设备、渠道和模式中访问和有效。
- **可靠性**:确保停机时间和可扩展性最小化，以支持任务和生命攸关的操作，包括紧急服务和关键运输系统。
- **弹性可扩展性**:基于 Hyperforce，支持增加数据和用户交互量，同时不牺牲性能或服务成本。
- **持续改进**:定期集成创新以增强功能，而不会中断现有运营。
Salesforce 致力于通过在本白皮书中描述的基础技术的基础上统一平台的功能来推进其应用程序。这种转换由一组关键优先级来指导，这些优先级决定了 Salesforce 应用程序套件的设计和开发。
### 12.1 规模和性能
我们的应用程序团队专注于性能和可扩展性，利用高级性能实验室使用合成数据创建生产环境的精确副本。此设置允许广泛模拟并行用户过程，以确保每个新功能都经过彻底的性能测试并评估其影响。在发现运行时瓶颈时，我们会动态调整速率限制和其他措施，以保护系统运行状况，同时收集数据以推动解决问题。
我们的系统设计用于水平扩展，以有效利用公共云的灵活性。自动检查确保更新或增强不会对性能产生负面影响。我们使用预测性自动缩放器来主动管理系统负载，不仅响应增加的需求，而且提前预测和调整。
自动扩展对于通过减少未使用的容量来最小化服务成本至关重要。我们密切监控系统运行成本，识别并解决自动扩展或资源使用中的任何低效问题。虽然成本效益很重要,但我们优先考虑可靠的应用程序交付,选择快速和缓慢扩展的自动缩放器来保持客户 Trust,即使这需要更高的成本。
### 12.2 无缝集成
#### 通用数据模型
数据模型是 Salesforce 所有业务运营的基础，会影响业务功能、API、导航、UI 显示和可以创建的报表。它们是平台功能的组成部分。
我们的应用程序套件在 Sales Cloud、Service Cloud、 Revenue Cloud、Commerce Cloud、Marketing Cloud 和 Industries Cloud 之间共享通用数据模型。这有助于我们的集成套件，提供一致的行为和互操作性，以及清晰的升级和扩展路径。
例如，在所有云中共享客户和产品实体允许 Marketing Cloud 和 Sales Cloud 中的用户交换数据、元数据、UI 组件和业务逻辑。这种集成有助于打破孤岛并促进跨职能协作。
#### 虚拟数据平台
跨所有 Salesforce Cloud 的通用数据模型显著增强了集成，但可能无法满足所有复杂的合作伙伴集成需求。Data 360 通用数据模型通过扩展 Salesforce 典型数据边界之外的共享数据模型优势来扩展这一点，适应更广泛的集成场景。
#### 分层扩展性
Salesforce 的元数据框架允许各种小组（例如工程团队、ISV、合作伙伴、管理员和最终用户）在不同的扩展层中自定义和扩展他们的应用程序，而不会相互干扰。此结构支持可扩展的环境，其中一个小组的修改不会中断其他小组，从而保持系统完整性。
该框架的一个有效示例是统一知识产品，它将所有 Knowledge 源集成到数据湖中。此设置包含语义层和检索器，增强了 Sales Cloud、Service Cloud、 Revenue Cloud、Marketing Cloud 和 Commerce Cloud 的预测和生成式 AI 功能。它结合了与现有结构化 Knowledge 模型相关联的非结构化和半结构化 Knowledge 的数据模型。
此外，该框架使用元数据来定义数据类型之间的自定义关系，方便高级查询生成。这允许应用程序团队创建利用这一综合 Knowledge 库的可自定义应用程序，而 ISV、合作伙伴和客户可以通过修改元数据关系或为特定业务用例开发自定义检索器来进一步加强应用程序功能。
#### 增强通用数据平台
客户数据在各种平台（例如 SalesforceDB 和 Data 360）上安全存储，并且无论格式是结构化还是非结构化，都实现了标准化和规范化。这确保了通过称为 sObject 的统一格式进行一致的数据处理，该格式支持跨所有客户数据的内聚数据平台。
这种标准化支持所有数据操作的单一 API、Apex 中触发器的统一界面，以及使用流创建自定义工作流。它还支持 Tableau Next，允许自定义数据视图，并与生成式 AI 工具集成，例如根据客户数据生成智能响应的提示生成器。
此外，Salesforce 应用程序与各种数据存储集成，以增强产品中的业务流程灵活性。例如，在 Marketing Cloud 中，Flow 用于管理多点接触客户体验，可以选择使用预先设计的模板或构建将市场营销与其他业务流程集成的自定义流，所有这些都基于基础客户数据。
### 12.3 共享业务功能
应用程序利用并增强共享服务，例如身份解析、内容编排、个性化、分析、LLM 网关和推理服务，从而实现快速创新和交付。这些服务支持实时数据处理、AI 驱动的见解和丰富的用户体验，提供全面的 360 度客户视图。
好处包括通过智能自动化和预测分析提高效率、增加数据和用户交互的可扩展性以及强大的安全性和合规性。该平台的自定义功能允许组织快速适应不断变化的需求，促进增长和卓越运营。
应用程序层的创新由 Salesforce 平台和个人应用程序推动，增强了 Salesforce 生态系统，并使应用程序成为行业领导者。
### 12.4 多渠道和渠道优化
Salesforce 应用程序旨在满足各种平台的用户，包括 Web、移动、电子邮件、短信、WhatsApp 和其他渠道。它们优化了每个渠道的本机功能，以提高用户体验和效率。
功能包括适用于 Salesforce Field Service 用户的多月离线功能、浏览器推送通知和 Lightning 服务控制台中服务客服人员的宽屏布局，以及适用于 Commerce 购物者的高性能店面和副驾驶。
元数据平台确保 Salesforce、其合作伙伴和客户可以立即从这些现成的功能中受益。
### 12.5 快速交付创新
Salesforce 的基础服务、平台和共享业务功能允许应用程序快速适应市场变化和技术趋势，从而实现快速的创新交付。例如，随着生成式 AI 的出现，Salesforce 迅速利用现有的 AI 服务，例如 NLP Trust 层和意图检测，将提示模板纳入通用通信平台。这种集成增强了跨产品的消息传递和电话功能，促进了更多的个人客户端连接。
顺应自主 AI 的趋势,Salesforce 推出了 Agentforce，该解决方案充分利用这些现有投资，通过客服人员高效地自动化业务用例，无需从头开始构建。
### ⁇ 应用程序套件的路径
我们在 Salesforce 平台上重建了 Marketing Cloud、 Revenue Cloud 和 Commerce Cloud，使这些云能够共享相同的基础设施、平台、元数据、数据、AI、UI 组件和业务逻辑，同时受益于 Salesforce 平台的全部功能。例如，我们从 Revenue Cloud 中获取了功能，并嵌入了基于约束的配置器、定价引擎和目录管理等核心功能，使其成为套件中可用的基础服务。这也使我们能够在所有云之间实现无缝集成，而 Commerce Cloud 和 Marketing Cloud 提供的功能成为其他应用程序可以利用的共享业务功能的一部分。这是我们交付的集成应用程序套件愿景。
Salesforce Platform 的旅程导致开发了集成的应用程序套件，将 Sales Cloud、Service Cloud、Marketing Cloud、 Revenue Cloud 和 Commerce Cloud 整合到一个统一的解决方案中。从 Salesforce Starter Edition 开始，此套件在一个内聚软件包中提供多渠道拓展、客户关系管理和业务见解。无论选择哪个版本，用户都可以访问 Sales Cloud、Service Cloud、Marketing Cloud 和 Commerce Cloud 的核心功能，确保在各个级别获得一致的体验。
## 13\.特定于行业的解决方案
适用于金融服务、健康、生命科学、媒体、能源和公用事业、制造、汽车、消费品、零售、Net Zero、公共部门、教育和非营利组织的 Salesforce 行业产品扩展了我们的应用程序产品和平台，以提供定制的解决方案来解决行业的独特挑战。它们通过整合特定于行业的工作流、合规措施和数据模型来简化操作并提高效率。
行业产品组合已在 Salesforce 平台上重新构建，以实现跨垂直方向的可组合性。现在，客户可以利用共享元数据、API 和业务服务，将一个或多个行业功能整合到定制的解决方案中。这种方法平衡了垂直差异化与平台一致性，确保了在不同监管和业务背景下的适应性和规模。
### 13.1 分层架构方法
我们的产品采用分层架构。基础是 Salesforce 平台和水平应用程序，例如 Sales Cloud 和 Service Cloud，是所有行业解决方案的基础。为此，Salesforce 添加了增值的公共服务，增强了嵌入大多数行业的可重用组件。这些示例包括数字自动化、时间线、行动计划等功能。在这一层之上，有一个可重用的业务逻辑层，它封装了水平功能，例如反馈管理、CPQ（配置、价格、报价）和服务管理。
顶层具有为满足特定行业要求而定制的特定于域的自定义，利用底层平台增强可扩展性和效率。例如，在制造垂直领域，此设置通过准确预测优化生产计划。在生命科学领域，它为医药销售团队提供移动离线解决方案，高效管理工作流和样品处理，同时遵守各种地理法规要求。
### 13.2 特定于行业的功能
**可信 AI Excellence**:我们值得信赖的生成式 AI 解决方案提供特定于行业的 AI 功能。其中包括客服人员和即时工程，这将促进医疗保健、生命科学和金融服务等领域的低代码/无代码自动化和数字化。此外，文档/文本挖掘和汇总等功能适合处理大量数据的行业，有助于信息提取和见解收集。
自定义客服人员增强了客服人员与客户之间的三方沟通，从而加快了解决问题的速度。Salesforce 平台的Trust层有助于遵守所有行业的合规和监管标准。
**具有法规遵从性和安全性的数据、见解和智能**:Salesforce 行业提供全面的 360 度视图，并根据 GDPR、HIPAA 和 FedRamp 等特定行业法规定制了严格的数据隐私、共享和安全措施。Salesforce 集成来自各种来源的数据，实现了合规性和安全性，并通过适用于租户数据加密的附加功能（例如 Shield Encryption BYOK（自带密钥））增强了这些解决方案。
**提升用户体验**:Salesforce 行业强调无缝用户体验，根据行业特定需求定制，以增强用户旅程。这包括可操作资源中心、Experience Cloud 模板和基于 OmniStudio 的解决方案等工具。
**数字化、集成和入门**:Salesforce Industries 通过低代码到无代码的解决方案提供数字化、集成和入门服务，为新客户提供 Flows 和 Omnistudio 等工具，并为现有 CRM 系统提供迁移解决方案。通过 MuleSoft 提供的连接器，简化了与外部系统和数据的集成。Salesforce 还包括特定于行业的服务流程，例如Retail Banking的争议管理。
**移动和离线**:Salesforce 行业为 Salesforce 移动应用程序和 Field Service 移动应用程序提供强大的特定于域的支持。对于需要高级离线支持的高度专业化域，Industry 提供了基于 Salesforce 移动 SDK 构建的定制移动应用程序。
**常见业务功能**:Salesforce 行业建立在通用业务功能的基础上，实现了一致性和生产力，同时根据独特的行业需求定制解决方案，例如银行和医院的不同预约系统。Salesforce 与更广泛的 Salesforce 生态系统集成在一起,提供了整体 Customer 360 视图,使其成为 Salesforce 产品套件的重要组成部分。
## 14\.Analytics
多年来，Analytics and Business Intelligence (BI) 平台市场一直在为最终用户推广可视化自助和 AI 驱动的自动化见解，帮助他们做出更快、更数据驱动的决策。然而,我们知道,由于一些挑战,并非每个人都看到了这一结果:
- **断开的见解**:见解未集成到用户的工作流中，因此难以对见解采取行动，尽管这些见解具有为决策提供信息的潜力。
- **数据过载和思洛存储器**:数据继续快速增长，并且仍处于条块分割状态，导致组织混乱和安全风险。组织面临着混乱的自助数据环境和受限的、管理良好的数据环境之间的两难选择。
- **对数据的不信任**:数据的膨胀和碎片化削弱了用户对来自公司数据的见解的 Trust。
- **缺乏可合成性**:工作流程中严重缺乏可组合性和重用性，迫使用户重复任务，也没有明确的货币化渠道。
Tableau Next 旨在通过以新的协作方式将业务用户和数据专业人员集合在一起来扩大可视化分析的周期；所有这些都通过 AI 来增强。它通过 Salesforce 平台提供及时、可信的度量和见解，便于访问无处不在的可操作见解。
Tableau Next 通过以下方式应对这些挑战：
- 为从数据连接到操作的连接体验创建开放的、可组合的 API 优先平台。提供开发工具、富分析应用程序的可组合组件以及管理其打包和分发的功能。
- 以 AI 为核心构建，能够提供上下文和相关见解，并为数据专业人员提供高效审查和验证的工具，以确保 Trust。
- 将 Tableau 语义构建为通用语义层，以便在受控但灵活的生态系统中进行快速、自助和受管数据分析。
- 通过 Data 360 提供实时云规模的数据功能，以实现可信、可扩展和受管的数据访问。
- 为开发人员提供丰富的环境和市场，以构建应用程序并将其货币化。
- 将智能集成为核心，将贵组织的语义和 Knowledge 的强大功能带给为您提供支持的客服人员。
- 优先考虑 Trust，因此您可以通过直接控制和查看其活动和功效，对数据、分析和客服人员工作负载和部署充满信心。
- 将协作作为一流的设计原则，与 Slack 以及贵组织的任何其他协作工具进行深度和丰富的集成。
### 14.1 一流的 Analytics 体验
Tableau Next 通过提供增强功能和集成体验的开放平台，巩固了 Tableau 在数据分析工具方面的领先地位。主要功能包括：
- **富数据可视化**:使用 Tableau 的 VizQL 技术进行扩展的可视化分析。
- **协作、受管工作区**:为分析任务提供统一的界面，并与 Slack 集成，以实现实时协作。
- **受信、受管数据**:通过结构化升级路径支持自助分析，以便在安全的环境中进行全局管理。
- **高级度量编写**:使分析师能够在您的组织中高效地创建和重用 KPI，促进一致性和可靠性。
### 14.2 Agentic Analytics
Tableau Next 基本上以 Agentforce 作为基础架构构建，增强了 Tableau Next 提供高度连接、可信和协作的 AI 支持的数据工具的能力。
- **BI 工具**:提高数据工作人员的自助分析效率，重点关注数据准备以及可视化和语义元数据的管理。
- **上下文体验**:将数据见解、体验和透明的 AI 带入组织大部分工作的上下文（例如 Slack）。
- **Agentforce 架构**:构建于 Agentforce 堆栈，为 Tableau Next 提供高级代理架构上的丰富上下文。
- **语义目录**:提供用于管理元数据、谱系和搜索的集中系统，支持 Tableau Next 用户之间的共享体验。
- **共享和生成的元数据**:促进自助分析和综合生态系统中受管内容之间的无缝工作流。
- **行动框架**:通过预打包、人为策划或生成的工作流，深入了解行动。
- **个性化见解**。了解您的数据首选项、角色等（在您允许的范围内），立即为您提供高度上下文化和个性化的数据见解。
- **主动见解**。智能地探索您的数据生态系统，寻找您感兴趣的数据统计领域；同时主动了解变化的驱动因素，以及该怎么做，并建议下一步要采取的行动。
- 受**信数据代理**。让您作为数据客服人员的司机，通过集成体验构建和调整应用程序。它还为您提供了测试工具，以预先评估您的数据变化及其对客服人员准确性和有效性的影响。
### 14.3 集成解决方案驱动的业务用户体验
Tableau Next 通过 Slack 和 Salesforce 等各种平台以及 Tableau Pulse 等新的分析功能增强业务用户体验，所有这些都可以通过客服人员体验访问，以简化分析参与。关键方面包括：
- **协作**:它是可信分析的核心，它促进了不同分析组件之间的交互，并将验证工具集成到用户的工作流中。
- **脉搏度量**:与传统分析师创建的仪表板相比，更高效地提供策划和自动化见解。
- **AI 驱动的体验**:使用 AI 减少对高级分析技术专业知识的需求，帮助确保确定性元数据和受管数据的可靠性。
- **多人见解交付**:允许业务用户与分析师协作，以获得对系统提供的见解的 Knowledge 和 Trust。
- **深度集成**:构建在共享元数据和数据平台上，赋予不同系统和体验的可组合性，以允许为推广、数据流和不同角色提供可组合性，从而相互帮助，以审查和完成工作。
### 14.4 Tableau 语义
Tableau 语义层是原始数据和用户解释之间的重要桥梁，简化了数据分析、决策和应用程序开发，增强了 AI 驱动的上下文和检索。主要功能包括：
- **集成元数据管理**:支持自助和受管元数据，通过结构化路径促进临时分析，从而成为组织的唯一真相来源。
- **Tableau 的同类最佳功能**:包括多逻辑对象支持、模型可组合性、共享维度、复杂的地理空间层次结构和时间建模。
- **不同数据和 Analytics**:帮助链接非结构化和结构化数据，例如将基于图像的产品类别与结构化销售数据相关联，并包含来自半结构化产品评论的情绪分析。
- **Salesforce 平台集成**:建立统一的真实来源，促进一致的业务语义和跨应用程序的无缝集成，以及支持各种用户体验和用例的内聚元数据模型。
- **客服人员智能**:语义层是客服人员获取智能的关键领域之一，他们不仅可以了解支持业务的数据和元数据，还可以了解定义业务的语义，包括针对贵组织的更深层描述和首选项。
### 14.5 集成工作流和可操作见解
Tableau Next 提供了增强数据驱动的决策和可信自动化的集成解决方案，具有简单的操作、预定义的流、计划和 API 集成。关键组件包括：
- **标准化的智能业务操作**:促进企业内紧急和特定于上下文的通信，这些通信至关重要但很复杂。
- **预定义和生成的流计划**:通过可信但可验证的静态和动态生成的流，启用临时和计划操作。
- **Agentforce**:支持 AI 驱动的数据对话和交互，允许用户在业务应用程序内外参与见解并执行与传统 UI 相似的操作，并通过对话简化操作。
### 14.6 可组合开发人员平台
Tableau Next 为应用程序开发提供了一个可组合开发人员平台，其中包含无代码、低代码和专业代码选项，所有这些都利用了 Data 360 上的 Tableau 语义。
- **预封装行业/智能应用程序**:提供针对特定行业需求定制的模板化和可自定义分析应用程序。
- **第三方和 ISV 应用程序**:支持为分析、行业特定和自定义目的创建动态和交互式应用程序。
- **市场和交易所**:允许 ISV 和开发人员在最大和最值得信赖的业务应用程序开发生态系统中打包和分发他们的应用程序。
### 14.7 深度协作
Tableau Next 专为业务用户和数据专业人员设计，促进数据理解的协作方法。无论技术或非技术，从业务用户到数据专家，所有团队成员都可以查看彼此的数据见解。此外，这些见解不仅限于 BI 平台中的浏览器选项卡。
作为 BI 平台，Tableau Next 是：
- **可跨平台撰写**。见解以相同方式呈现，不论您在哪个平台上查看。这种一致性是可视化处理数据时的支柱设计原则。
- 与 Slack **深度集成**。与 Slack 的集成开发确保了当今市场上最直观和沉浸式的协作数据体验之一。
- **打开任何工具**。在深度统一的平台上应用 API 优先原则，确保集成可以扩展到其他协作和第三方工具，并始终保留丰富性。
## 15\.集成
虽然 Salesforce Platform 提供了一套全面的集成功能来解决广泛的数字挑战，但许多客户是在企业架构中运营的，这些架构是通过使用各种供应商和技术而随着时间的推移而发展的。
现代企业面临着系统集成和业务流程自动化的挑战，这通常会导致数据孤岛和效率低下。Salesforce 集成平台利用 MuleSoft 的功能，通过促进自动化流程的快速发展和增强来解决这些问题。它确保无缝的系统连接，增强信息流，并支持跨不同平台的决策，从而降低人工成本和自动化成本。此层对于创建、管理、控制和监控 Salesforce 服务与其他自定义或第三方服务之间的集成至关重要。
系统通过 API 定义，它们用于：
- 从 ERP、客户和计费系统以及专有数据库等基本系统访问数据。
- 促进数据交互和集成，帮助消除数据孤岛。
- 将业务上下文添加到系统和进程 API 管理的数据和进程。
为有效通信，API 使用以下内容描述：
- 适用于即时同步交换的 OpenAPI 规范 (OAS)
- 异步 API，适用于异步、事件驱动的通信
- 模型上下文协议 (MCP)，适用于结构化、模型上下文交互
- 客服人员到客服人员 (A2A) 协议，用于客服人员到客服人员的直接集成。
Salesforce 集成层提供了强大的功能来集成和管理任何系统，增强了与 Salesforce 的数据、AI 和应用程序功能的连接，无论这些系统是 Salesforce 本地系统还是其他提供商的系统。
复杂的集成需要高级转换，并需要强大的工具，包括通用连接、API 管理和治理、用于构建集成工作负载的集成开发环境 (IDE)、用于部署、管理和监控这些集成的运行时平台，以及用于提供对这些集成的端到端可见性的可观察性平台。
为了进一步加快集成过程，我们提供了加速器和特定于行业的模板来编码常见的集成模式和需求。
### 15.1 与 Salesforce 集成模式
两种主要集成模式解决了 Salesforce 与更广泛的生态系统之间的数据和流程流：出站集成和入站集成。
**将 Salesforce 连接到外部系统（出站）：**此模式涉及来自 Salesforce 内部的进程，这些进程访问外部系统中的数据或触发操作。
- **安全端点管理（命名凭据）：**命名凭据提供了一个安全的集中位置来存储端点和身份验证详细信息。应用程序和自动化引用逻辑名称，而平台处理身份验证生命周期的复杂性。
- **声明性集成（外部服务）：**对于提供标准 OpenAPI 规范的外部系统，管理员可以使用外部服务声明性地注册 API。然后，平台处理规范，使服务的操作自动作为流等工具中的本机操作或 Apex 中的本机对象可用。
- **复杂系统集成 (MuleSoft)**:对于缺少现代界面的系统，MuleSoft 会创建标准的可重用 API 层。这抽象了原有的复杂性，并将内部数据和流程引入 Salesforce 生态系统。
- **实时数据访问（外部对象）：**将外部系统中的表表示为 Salesforce 数据模型中的虚拟对象，使外部数据可以通过标准查询和 UI 组件访问，而无需复制。
- **中央功能管理（统一 API 目录）：**统一 API 目录是一个集中存储库，也是所有 API 规范及其相关元数据（例如位置和安全协议）的唯一真实来源。它确保无论数据或业务逻辑驻留在何处，都可以在整个 Salesforce 生态系统中发现、安全地连接到强大的新应用程序和自动化中，并将其组合在一起。
- **自定义 Pro-Code 逻辑 (Apex REST)：**开发人员可以将 Apex 中编写的自定义业务逻辑公开为 REST API 和操作。然后，该操作可用作流中的一个步骤，或 AI 客服人员的工具。
**将外部系统连接到 Salesforce（入站）：**此模式使外部系统和应用程序能够连接到 Salesforce Platform，以访问数据、触发业务逻辑并编排流程。这种能力建立在经过验证的企业级 API 的基础上，可以大规模运行。截至 2025 年 10 月：
- 查询 API (SOQL) 每天处理超过 500 亿个请求。
- REST API 每天为来自外部系统的近 50 亿次调用提供服务，使用率同比增长 30%。
- 批量 API 每天处理数千亿条记录，用于大规模数据操作。
这种经过验证的可靠性和规模是以下功能的基础：
- **统一 API 体验：**通过一致的端点结构 (api.salesforce.com) 统一对所有 Salesforce 功能的访问权限，开发人员无需了解每个产品的不同模式或身份验证流。
- **全面的专用 API 产品组合：**该平台提供了根据特定需求定制的多种 API 集合，包括用于事务操作的 REST 和 SOAP API、用于大批量数据处理的批量 API、用于事件驱动应用程序的发布/订阅 API 以及专用产品或自定义 Apex API。
- **客服人员集成的未来准备：**通过 MCP 等标准，客户可以将 Salesforce 数据和操作安全地公开为外部 AI 客服人员的“工具”，将 Salesforce 实例转化为数字员工的可扩展技能集。
### 15.2 与 MCP 的代理集成
除了数据和流程集成的既定入站和出站模式之外，客服人员时代正在出现一种新的模式。Salesforce 平台正在实施全面的 MCP 战略，将其定位为 AI 支持的服务的消费者和提供商。这种双向方法实现了客服人员的互操作性，允许企业将 Salesforce 数据和功能与不断发展的 AI 客服人员和工具生态系统无缝集成，同时保持企业级安全和治理。
**Salesforce 作为 MCP 客户端：**客服人员可以通过智能和动态地利用外部系统和 API 来充当 MCP 客户端。这种功能使组织能够将 Agentforce 的覆盖范围扩展到 Salesforce 边界之外，跨任何系统编排操作，无论是具有现代 API 还是需要通过 MuleSoft 连接到传统系统或 RPA 机器人。配置通过熟悉的声明性、基于主题的设置体验来处理，无需自定义开发即可实现快速集成。合作伙伴提供的 MCP 服务器的简化发现机制进一步简化了外部功能的集成。通过大规模堆栈抽象外部连接的复杂性，企业可以快速将 Agentforce 与其更广泛的技术环境集成在一起。
**Salesforce 作为 MCP 服务器：**作为 MCP 服务器，该平台公开其逻辑和资产，包括标准 REST API、自定义端点、可调用操作和流，作为外部客服人员的可发现“工具”。通过声明性界面，客户和 ISV 可以创建和配置自己的自定义 MCP 服务器，将功能整合到为唯一业务流程定制的工具集合中。这延伸到了 MCP 提示，与平台的提示模板功能产生了自然的协同作用，并允许组织让他们对快速工程的投资可以被任何外部 AI 系统访问。
此功能由多层安全模型控制：
- **应用程序控制：**外部客户端应用程序结构为管理员提供了对哪些外部客服人员应用程序可以访问其 Salesforce 组织的强大控制。
- **范围权限：**身份验证通过细化 OAuth 范围来增强，能够精确跟踪和实施允许身份验证客服人员执行的操作。
- **核心平台授权：**这些新控制建立在 Salesforce 强大的授权模型之上，包括记录访问控制、实体和字段级权限，以及在简档和权限集中定义的其他权限。
ISV 和合作伙伴也可以封装和分发 MCP 服务器配置，从而在整个 Salesforce 生态系统中快速部署 AI 就绪集成。
### 15.3 通用连接
Salesforce 的通用连接的现代方法是_解释连接_，这是一种以元数据为中心的方法，用于开发连接器，可以在任何平台(MuleSoft、Flow 或 Data 360)中执行，无需编程即可满足任何用例。元数据模型了解如何连接到远程服务来验证请求、对返回的数据建模、创建查询、翻阅结果以及接收事件（触发器），以实现流程的自动化。
对于不使用基于 HTTP 的 API 的系统，Salesforce 提供了数百个预构建连接器和用于构建自定义连接器的完整 SDK。对于没有任何 API 访问权限的系统，Salesforce 提供了机器人流程自动化 (RPA)，它使用客服人员来自动化通常由人类执行的重复的、基于规则的任务。这些任务可以包括数据输入、事务处理和响应简单的客户服务查询。为了从文档中提取信息，Salesforce 提供了我们的智能文档处理 (IDP)，它利用 AI 自动从各种类型的文档中提取、分类和处理数据，例如发票、合同和表格。但存在信息，Salesforce 会提供检索和操作信息的自动化方式。
随着 AI 的最新发展，Salesforce 提供了构建块来快速启用组织中的客服人员功能：
- 通过**模型上下文协议 (MCP) 连接器**，组织可以快速将其 API 公开为 MCP 工具，并使 API 和资源的发现便于客服人员使用。
- 通过为客服人员提供 A2A 协议支持，**客服人员到客服人员 (A2A) 连接器**使组织能够标准化客服人员到客服人员的通信。每个客服人员（域中的功能专家）可以发现客户的查询，并将其委派给最适合域的客服人员。
- 通过提供 LLM 调用、向量嵌入和搜索、RAG 检索和 MCP 工具支持，**推理连接器**提供了从头开始构建客服人员的构件。
### 15.4 API 管理
MuleSoft 的 API 管理通过 Anypoint API 管理器提供，它提供了一个全面的平台来设计、保护、治理、监控和扩展任何部署环境中的 API 和微服务。无论平台如何，组织都可以从单一窗格中通过一致的企业级控制和见解来管理他们的 API 和微服务，从部署到版本都有集中的管理。主要功能包括：
- **Anypoint Flex Gateway** 是应用程序层 API 网关，用于管理和保护 API，并在 HTTP/S 级别应用速率限制、缓存、身份验证、授权、威胁防护、监控和日志记录策略。这是一个轻量级、高性能、基于特使的网关，专为基于微服务的分布式环境而设计，旨在与 DevOps 和 CI/CD 工作流无缝集成，同时在任何环境中提供企业安全性和可管理性，同时支持入站和出站策略。
- **API 警报**允许组织定义和监控其 API 的特定阈值或条件，以检测异常或不需要的行为。示例包括响应时间超过限制（例如 60 秒）、时间窗口中的请求数量过多、返回特定 HTTP 响应代码或发生策略违规时的提醒。
- 通过 **API Analytics**，您可以了解 API 的使用方式及其表现。Analytics 仪表板使组织能够跟踪和查看高级度量，深入了解图表，创建和自定义仪表板和报表，以了解使用趋势、违反策略、响应时间、请求/响应代码等。
### 15.5 下一代集成开发环境
MuleSoft Anypoint Code Builder (ACB) 是我们下一代的 IDE，专为 API 和集成开发而设计，具有以 VS Code 为后端的现代统一体验。
- **统一开发环境：**将整个 API 和集成开发过程整合到一个工具中，支持异步 API、OAS 和 RAML API、治理规则集、低代码流画布、预构建连接器以及集成的测试和部署选项。此外，ACB 支持调试、故障排除和持续维护，并提供智能上下文建议。
- **客服人员开发经验：**在整个应用程序开发生命周期中提供客服人员体验。核心是 MuleSoft MCP 服务器，它支持代理集成开发。MuleSoft MCP Server 提供了强大的工具，用于从自然语言生成 API 规范和集成、创建数据转换、在 MuleSoft Exchange 中管理资产以及管理应用程序和 API 策略。MuleSoft MCP Server 工具在任何基于 VS Code 的 AI 代码编辑器（包括 Cursor、Windsurf 等）中提升用户的 API 规范和集成开发。
- **AI 集成：**MuleSoft 利用 MuleSoft 主题中心将 API 调用转换为 Agentforce 操作，用于企业系统访问，增强了与客服人员功能的集成开发。Agentforce 连接器将自然语言自动化嵌入集成。推理连接器安全地集成外部 LLM 提供商，在 MuleSoft 应用程序中启用 AI 驱动的逻辑。组织可以使用这些组合功能来构建智能、自适应的集成。
### 15.6 运行时平台
MuleSoft 的运行时平台为运行 MuleSoft 应用程序、API 和跨环境的集成提供了灵活的部署选项。组织可以选择最适合其运营、合规性和可扩展性需求的运行时模型，同时通过 Anypoint 平台保持一致的管理和治理。这种灵活性确保应用程序可以运行在接近数据源的地方，遵守区域法规，并根据需求无缝扩展。
关键托管选项包括：
- **云：**MuleSoft 完全受管的多租户集成平台即服务 (iPaaS)，消除了基础设施管理开销。CloudHub 2.0 提供弹性扩展、高可用性和零停机时间部署/升级，并内置可观察性需求和合规认证。开发人员可以专注于构建 API 和集成，而 MuleSoft 管理运行时基础设施，确保企业级安全性、可靠性和高可用性。
- **混合：**对于需要自行托管应用程序以获得更多控制的组织，MuleSoft 提供了运行时结构，这是一种容器服务，可以在 Kubernetes 或虚拟机之间自动部署和编排 MuleSoft 运行时。它支持水平扩展、零停机时间部署、内置安全控制和简化群集管理。
- **Private Cloud Edition (PCE)：**MuleSoft 的 Private Cloud Edition 提供了 Anypoint Platform（包括控制和运行时平面）的完全自助本地版本，允许组织满足严格的监管、数据驻留和安全要求。它使大型企业能够保持对基础设施的完整控制，同时仍然受益于 Anypoint 平台的统一集成和 API 管理功能。
### 15.7 可观察性
MuleSoft 提供全面的可观察性解决方案，在任何部署模型中提供对 API、集成和应用程序的端到端可见性。无论工作负载运行在何处，可观察性功能都是一致的，提供了环境的统一视图。通过捕获实时和历史遥测数据，MuleSoft 使组织能够在整个应用网络中更快地检测、分析和解决生产问题。可观察性数据可以在 Anypoint 平台中本地查看，也可以通过 OpenTelemetry 导出到客户首选的 APM 中，允许与现有的监控生态系统无缝集成。这使组织能够主动加强基础设施的弹性，并提高任务关键型应用程序的可靠性。
MuleSoft 通过两个主要产品提供可观察性：
- **Anypoint Monitoring** 是内置于 Anypoint 平台的当前市场可观察性解决方案。它提供了现成的可自定义仪表板，用于监控应用程序运行状况、日志管理的高级日志搜索，以及在发生定义的阈值或异常时通知团队的提醒功能。
- **集成智能**是在 Salesforce 平台上重新构想和构建的适用于 MuleSoft 的下一代 AI 优先可观察性平台。此产品将 Data 360 用作遥测数据的统一数据层；将 Tableau 语义用作受信任的语义层，以实现智能、可操作的见解；将 Tableau Concierge 用于实现 AI 辅助故障排除；将 Tableau Next Dashboards 用于提供交互式可视界面，将多个丰富的数据可视化整合到一个内聚视图中。Tableau Next 还为客户提供了在带有可观察性的语义数据模型之上构建自定义仪表板的能力。
该堆栈还支持以客服人员为中心的跟踪，为客户提供了非确定性端到端客服人员调用路径的完全透明性，允许他们观察客服人员在每个中间步骤中的工作，使用户能够更快地找到故障的根本原因并识别任何性能瓶颈。
## 16\.生态系统和 AppExchange
Salesforce 生态系统展示了平台的强大功能。系统集成商 (SI) 和咨询合作伙伴通过开发、配置和优化复杂的 Salesforce 解决方案为客户提供支持。独立软件供应商 (ISV) 在平台上构建创新的应用程序和解决方案，然后客户可以将其安装到他们的 Salesforce 组织中。这些 ISV 应用程序在 AppExchange 上可用，AppExchange 是 Salesforce 于 2006 年推出的应用程序商店，截至 2025 年 10 月，它现在拥有超过 10,000 个应用程序，安装次数超过 1430 万次。
为帮助客户浏览广阔的市场并发现相关应用程序，AppExchange 搜索体验已在 2025 年重新设计，以利用 Data 360。Salesforce Data 360 的向量搜索功能与传统关键字匹配协同工作，通过自然语言理解用户的意图，提供更具有语义相关性的结果。最终愿景是通过将其与 Agentforce 平台集成来发展这一基础，实现完全代理化的“问任何问题”界面，客户可以在其中对话式描述他们的业务挑战，从而获得高度个性化的解决方案推荐。
AppExchange 通过与 Salesforce 密切合作，通过涉及代码分析器、安全扫描仪和参考实施指南的严格审查流程来确保高质量的解决方案。该平台还为 ISV 提供许可证管理工具，以定制应用程序许可和货币化，支持各种定价模型，包括基于用户和基于消费的选项。
“元数据驱动的平台”原则使 ISV 能够扩展 Salesforce 的本地应用程序和元数据，从而简化数据模型、业务逻辑和用户界面的开发。Salesforce 平台支持广泛的解决方案，从特定于行业的应用程序到使用 Lightning Web 组件（用于 UI）和 Apex Code（用于业务逻辑）等技术的高度自定义品牌化应用程序。
“打包”的概念对于这些应用程序在各种 Salesforce 组织之间的分发至关重要。打包包括将元数据序列化为任何 Salesforce 客户都可以安装的工件，并使用为跨各种环境的元数据管理设计的基础技术。打包的一个独特方面是，它允许在开发人员未知的环境中安装。
为了加强控制和安全，封装中的“可管理性”功能使 ISV 能够安全地升级应用程序的部分，因为其他部分不能依赖这些部分，同时允许客户拥有和管理其他部分。例如，ISV 可以将某些元数据（例如自定义设置）设置为“受管”，使其对客户不可见且不可编辑，从而防止客户环境中的中断。受管软件包包含这些可管理性控制，而非受管软件包将部署的元数据视为客户创建的元数据，无法在部署后升级。
自 AppExchange 和 Salesforce 平台诞生以来，正在创建和安装的软件包的数量和复杂性都显著增加。为了满足这些需求，该平台于 2020 年引入了第二代打包架构。这一新架构增强了受管软件包的模块化，提高了版本灵活性，允许命名空间共享，并支持声明性依赖性，以及软件开发生命周期中的其他进步。软件包部署架构还具有一些提高效率和规模的重大增强功能，例如确定哪些元数据发生了变化，以及只部署增量。
开发新产品和新功能的一个关键措施是它们与包装的兼容性和为 ISV 的使用做好准备。该平台强调其功能对合作伙伴的快速可用性，使 Salesforce 生态系统能够有效地利用 Salesforce 平台的创新潜力，超越 Salesforce 现成的产品。但是，这是一个持续投资的领域，以确保本文档中描述的所有对 Salesforce 内部开发人员可用的功能也对 ISV 开发人员可用。
此外，Heroku 市场和 Slack 市场提供了广泛的第三方集成和加载项，可以增强 Salesforce 应用程序的功能。Heroku Marketplace 为其他应用程序功能提供了工具和服务，并改进了开发人员构建、部署和管理应用程序的方式。Slack 市场提供了集成，可以简化工作流并改善 Salesforce 环境中的协作。
## 17\.Salesforce 上的 Salesforce
本着我们的核心价值“客户成功”的精神，Salesforce 充当 Salesforce 平台上所有应用程序和服务的“客户零”角色，尽可能在内部利用面向客户的产品。这提供了显著的优势：
- **严格的产品测试**:通过每天使用产品套件，Salesforce 员工会将平台暴露在真实世界的挑战中，从而提高产品质量并确定改进领域。
- **精制产品**:内部使用的即时反馈允许快速完善功能和可用性，并快速识别和解决任何错误，从而在产品发布时更好地满足客户需求。
- **深厚的行业专业知识**:跨各种功能的内部使用为 Salesforce 提供了对特定产品和行业挑战的宝贵见解，特别是在高科技领域。
- **增强客户同情心**:使用该平台的第一手经验使员工能够更好地理解和解决客户的棘手问题。
- **市场营销和销售见解**:每日产品使用情况为销售和营销策略提供信息，帮助根据客户需求定制平台。
- **更强的市场进入策略**:成功的内部实施允许 Salesforce 自信地将套件作为成熟的解决方案进行营销。
此外,作为交错部署过程的一部分，所有面向生产的软件更新最初都会部署到专用的 "Salesforce on Salesforce" Hyperforce 实例中。自 2020 年 8 月以来，该实例已成功托管适用于工程团队的 Salesforce 组织 GUS 以及 Salesforce 的 CRM 操作，向任何客户展示了 Hyperforce 的强大功能和就绪性。此策略允许内部团队在向外部客户部署生产之前测试和显示任何问题。
Salesforce 技术组织已完全接受 Agentforce 作为提高整个 SDLC 效率和质量的内部平台。这不仅使我们能够通过早期发现和缓解错误来提高我们向客户运送的代码的质量，而且还使我们能够根据第一手内部反馈快速迭代客服人员的体验。
## 18\.大规模交付转换
自 1999 年成立以来，Salesforce 经历了多次技术变革。然而，由于 Salesforce Platform 的规模和变革实施的速度快，因此涉及该平台的转型尤为重要。这种转换需要所有主要架构组件同时演进，以实现集成平台。为了确保这种转换是迭代的，并且对利益相关者和开拓者的破坏性最小，Salesforce 技术组织还必须发展其工程和产品交付实践。
Salesforce 技术组织是一个庞大的多元化团队，由 2500 多个团队组成，分布在 14 个不同国家/地区的 20 多个站点。该小组规模庞大，每周发布 200 多个产品版本并实施 250,000 个系统更改。根据更广泛的公司精神,技术小组遵循五个核心价值：Trust、客户成功、创新、平等和可持续性。这些值对于制定小组的战略、指导其执行和影响日常决策是不可或缺的。
秉承我们的核心价值观，Salesforce Engineering 360 框架为工程团队提供了面向行动的仪表板和对其运营的全面见解，为组织内的标准和最佳实践设定了明确的预期。这种整体视图涵盖了各种关键领域，包括可用性、安全性、合规性、质量、可访问性、Developer productivity、敏捷产品开发和成本效率。为了提供这些见解，该框架处理来自数百个内部工程系统的数十亿条记录，例如安全系统、生产运行状况日志、代码存储库、开发环境、CI/CD 以及发布/工作计划和跟踪系统，所有这些都利用 Agentforce、Data 360、Tableau 和 Slack 的最新创新构建在 Salesforce 平台上。
Salesforce 技术组织植根于这些数据和其他数据，利用 AI 和客服人员技术来提高效率。我们拥有超过 10,000 个内部 AI 工具的每日活跃用户，并且我们已经建立了 100 多个 AI 客服人员，这些客服人员是我们内部 AgentExchange 计划的一部分，推动了整个组织的生产力提高。
由于我们Trust的最高价值，服务所有权深深植根于我们的工程文化。每个服务和产品旨在不仅满足而且超过与可用性和事件管理指标相关的服务级别目标 (SLO)，例如检测时间 (TTD) 和恢复时间 (TTR)。我们的变更管理、发布准备和问题管理方法遵循高标准。安全性已集成到安全开发生命周期的每个阶段，并遵循“默认安全”原则。质量和性能通过敏捷测试方法确定优先级，该方法包括数百万个自动化测试，涉及 CI/CD 漏斗中的单元、功能、集成和负载/规模测试。
在架构上，我们专注于开发共享功能，以提高杠杆率和效率，从而提高质量。例如,我们在 Hyperforce 中开发了受管服务,以满足计算和数据管理等多样化需求,使产品团队能够专注于产品创新,而中心团队则在安全性、可用性和成本效益方面增强了这些服务。
我们的运营非常灵活，有助于向客户提供创新。超过 3000 个团队中的每一个都可以自主使用 Scrum 或 Kanban 实施敏捷框架。整个组织的产品开发计划由各种时间表组成，包括战略方向的 3 年长期计划，然后是年度执行计划，并进一步细分为 4 个月的产品发布计划，为双周冲刺计划提供信息。产品、功能和缺陷修复通过多个发布工具进行部署，以满足不同的客户需求，包括三个主要的年度版本、双周版本和每日版本。
鉴于我们的规模，生产力至关重要。我们利用 SPACE 框架有效地衡量生产力，并由 Engineering 360 系统提供的一套全面的度量提供支持。我们还专注于为内部开发人员改善工具和体验，以简化开发生命周期，并在客服人员体验和 AI、工作流、构建工具、开发设置、更安全的发布和安全服务方面进行投资，从而产生显著收益。
## 19\.结论
总之，Salesforce 平台在过去五年中经历了巨大的转变，从开创性的多租户云平台发展成为一个可信、集成、代理和数据支持的平台，为其选择的区域提供一套应用程序和服务。这种演变是由应对新挑战的需求驱动的，例如公共云提供商的崛起、不断增长的监管要求以及生成式 AI 和机器学习的进步。
Hyperforce、Data 360 和 Agentforce 的引入大大增强了平台的功能，确保了它在保持 Trust 和可靠性的同时保持创新前沿。我们大部分客户成功迁移到这个新平台,这彰显了我们工程师的聪明才智和献身精神。
随着我们不断创新和适应不断变化的市场需求，Salesforce Platform 完全有能力支持下一代应用程序和客户用例，这再次证明了我们致力于客户成功和技术卓越。
## 概览
企业数据架构很少存在于一个系统中。Salesforce 管理客户参与、漏斗和服务交互。Snowflake 等分析平台包含历史交易、财务记录、使用数据和运营度量。传统上，连接这两个世界意味着构建和维护 ETL 漏斗：从源提取数据、转换数据并将副本加载到 Salesforce 的计划作业。由于这些漏斗，数据延迟到达，治理策略在系统中成倍增加，漏斗需要持续的操作护理。
Salesforce 数据虚拟化提供了不同的模型。它使 Salesforce 能够在运行时直接在源位置查询数据，而无需复制，而不是将数据移动到 Salesforce 中。用户通过标准 Salesforce 界面查看实时外部数据。数据从不离开其权威主页。本文档以 Snowflake 为具体工作示例，解释了模式的工作方式、何时使用以及如何开始。
## 什么是数据虚拟化？
Salesforce 数据虚拟化是一种集成架构模式，它使 Salesforce 能够在运行时直接从外部系统查询数据，而无需将数据复制或复制到 Salesforce 存储中。平台不是将数据移入，而是发送查询。
因此，Salesforce 用户通过熟悉的 Salesforce 界面（例如页面布局、相关列表、报表或流）与外部数据进行交互，而数据仍保留在权威源系统中。治理、访问控制和数据驻留应保持不变。
这种模式建立在单一的架构原则之上：数据保留在源位置。计算移到数据。
## 为何如此重要
大多数企业 Salesforce 部署通过复制漏斗与外部数据平台（例如数据仓库、操作数据库或分析存储）集成。漏斗会按计划提取、转换数据并将其加载到 Salesforce。这种方法有效，但复制会引入结构性权衡：
* 复制的数据总是被延迟。漏斗引入滞后和过时的数据导致糟糕的决策。
* 每个数据副本都会扩展合规范围。多个系统中的敏感数据（例如个人身份信息、财务记录或健康数据）需要维护多个治理策略。
* 漏斗需要持续的操作投资、监控、故障处理、模式漂移管理和后处理逻辑。
数据虚拟化直接解决了这些权衡问题。它完全删除了读取量大的用例的漏斗，将数据保存在其权威位置，并为 Salesforce 用户提供外部数据的实时受管视图，而没有复制开销。
## 范围内的产品
 |
Salesforce Connect 是一种平台功能,可在 Salesforce 中启用数据虚拟化。它提供了适配器框架，可以将 SOQL 查询翻译成外部系统的查询语言，管理经过身份验证的标注，并将结果集映射回 Salesforce 字段类型。它支持外部对象，即 Salesforce 元数据结构，将外部数据显示为可查询的平台本地实体，而无需将数据复制到 Salesforce 存储中。外部对象的行为类似于标准 Salesforce 对象 — 在页面布局、相关列表和报表中可见，并且可以通过 SOQL 和标准 API 访问 — 但不保留数据。外部对象是源系统上的模式投影。 |
**收集和验证输入**
第一个子代理从用户那里收集源客户、目标客户和转移金额。在所有这三个项都存在并且有效之前，它不会继续。客服人员脚本按顺序检查每个字段：如果源客户丢失，它会询问。如果目标丢失，它会询问。如果金额为零或负数，则会询问。`validation_passed` 变量仅在清除所有检查后设置为 `true`。
下面的脚本在实践中显示了这一点。请注意，`validation_passed` 在每个故障点明确设置为 `false`，并且指示 LLM 不要继续。确定性检查无条件运行，而提示指令处理面向用户的响应。
```
instructions:->
| Always ensure to request the following data from the user, and to store it using {!@actions.store_details}
- source account number
- destination account number
- amount to transfer
Only after you have all the data, you can proceed with the next steps.
if not @variables.source_account:
set @variables.validation_information = "Missing source account"
set @variables.validation_passed = False
| You need the source account number before proceeding.
Ask the customer for the source account number.
else:
set @variables.validation_passed = True
if @variables.source_account and not @variables.destination_account:
set @variables.validation_information = "Missing destination account"
set @variables.validation_passed = False
| You need the destination account number before proceeding.
Ask the customer for the destination account number.
else:
set @variables.validation_passed = True
if not @variables.source_account or not @variables.destination_account:
| Do NOT proceed with the transfer yet.
if @variables.transfer_amount <= 0:
set @variables.validation_information = "Invalid transfer amount"
set @variables.validation_passed = False
| The transfer amount must be greater than zero. Ask the customer
how much they want to transfer.
Do NOT proceed with the transfer yet.
else:
set @variables.validation_passed = True
```
**强制执行业务规则**
客服人员验证输入后，会检查转移金额是否超过配置的转移限制。这是业务规则成为代码而不是指令的地方。限制不是 LLM 的原因；它是在脚本中定义的硬阈值，并在每个解析上被确定性地检查。
如果金额超过限制，`validation_passed`会设置回`false`，LLM 会为用户提供三个选项：转移最大允许金额、拆分为多个转移或联系支持以获取更高的限制。在用户解决异常之前，客服人员无法继续。请注意，这里的提示指令是如何执行 LLM 推理的：以对话方式显示选项并处理用户的回应。业务规则本身是确定性的，但围绕它的对话不是。
以下脚本显示了限制检查的工作方式。确定性条件根据限制变量评估转移金额，如果超过阈值，将`validation_passed`设置为`false`，并委派给提示指令来处理面向用户的响应。
```
instructions:->
if @variables.transfer_amount > @variables.transfer_limit:
set @variables.validation_information = "Amount exceeds transfer limit"
set @variables.validation_passed = False
| ⚠️ STOP: The requested amount (${!@variables.transfer_amount}) exceeds
the maximum transfer limit of ${!@variables.transfer_limit}.
Inform the customer and ask if they'd like to:
1. Transfer the maximum allowed amount (${!@variables.transfer_limit})
2. Split into multiple transfers
3. Contact support for higher limits
Do NOT proceed with the transfer.
```
**应用保护条款**
金额和限额检查完成后，客服人员会获取源帐户余额，并确认资金充足。保护条款阻止客服人员在不满足先决条件时尝试操作。与告诉 LLM 检查余额的提示指令不同，客服人员脚本中的保护子句使检查无条件。LLM 不决定是否运行它。
如果余额不足，客服人员会计算短缺，并为用户提供具体替代项。`validation_passed` 设置为 `false`，直到此检查通过，这意味着转移操作仍处于关闭状态。
下面的脚本显示了获取余额的确定性操作调用，然后是评估它的条件检查。提取仅在尚未检索余额时运行，避免后续解析器上的冗余 API 调用。
```
instructions:->
# Fetch balance if needed
if @variables.source_account and not @variables.source_balance:
run @actions.get_account_balance
with account_number = @variables.source_account
set @variables.source_balance = @outputs.balance
# Validate sufficient funds
if @variables.source_balance < @variables.transfer_amount:
set @variables.validation_information = "Insufficient funds"
set @variables.validation_passed = False
| ⚠️ STOP: Insufficient funds in the source account.
- Available balance: ${!@variables.source_balance}
- Requested transfer: ${!@variables.transfer_amount}
- Shortfall: ${!@variables.transfer_amount-@variables.source_balance}
Ask if they'd like to transfer a smaller amount.
Do NOT proceed with the transfer.
```
**表面错误清晰**
保护条款设置状态。错误消息会传达它。当`validation_passed`是`false`时，客服人员需要为用户提供足够的信息来解决问题，而无需重新启动。模糊的错误消息会产生摩擦；结构化错误消息会更快地关闭循环。
以下脚本显示了实践中的资金不足错误消息。它不仅仅告诉用户转移失败。它显示了可用的余额、请求的金额、计算的短缺，并提供了具体的下一步，所有这些都是从会话变量中汇总的，而不是由 LLM 生成的。
```
| ⚠️ STOP: Insufficient funds.
- Available: ${!@variables.source_balance}
- Requested: ${!@variables.transfer_amount}
- Short by: ${!@variables.transfer_amount - @variables.source_balance}
Would you like to transfer ${!@variables.source_balance} instead?
```
短缺计算发生在脚本中，而不是在 LLM 中。建议的替代方案（转移可用余额）是从会话状态中确定的。LLM 在这里的作用纯粹是演示性的：它传递脚本已经构建的消息。
**门控转移操作**
上述步骤中的每个验证检查都会设置或清除相同的变量：`validation_passed`.该变量目前正在完成其最重要的工作。`execute_transfer` 操作是有条件可用的，这意味着它仅在 `validation_passed` 为`true`时显示在 LLM 的工具列表中。在通过每个前面的检查并设置该变量之前，从 LLM 的角度来看，该操作不存在。
这是应用于生产工作流的早期大门部分的模式。转移操作不会被提示指令隐藏。它被平台隐藏。无论多大的对话压力或不明确的措辞都不能使 LLM 在满足先决条件之前调用它。
下面的脚本显示了如何配置网关。`available when` 子句直接引用`validation_passed`，操作参数绑定到在前面步骤中收集和验证的会话变量。
```
actions:
execute_transfer: @actions.execute_transfer
available when @variables.validation_passed
with from_account=@variables.source_account
with to_account=@variables.destination_account
with amount=@variables.transfer_amount
```
所有 3 个参数（`from_account`、`to_account` 和 `amount`）都是从会话变量中确定性传递的。在此操作可用时，每个值均已验证。LLM 没有从对话上下文中汇编参数；而是从状态中读取它们。
**在整个工作流中跟踪状态**
以上部分中的模式仅适用于会话状态在整个工作流中持续存在的情况。第一步中捕获的帐号在第四步中可用。验证结果集位于另一个检查门操作中。对话可能会偏离，用户可以提出跟进问题，客服人员仍然可以准确知道对话进行中的位置。
下面的变量块显示了此工作流的完整会话状态。每个变量都有一个定义的类型、一个默认值和一个描述。两个变量处理大部分编配工作：`validation_passed` 控制每个门的操作可用性，`validation_information` 携带有关检查失败原因的可读上下文，LLM 可以向用户显示这些上下文，而无需说明基础状态。
```
variables:
source_account: mutable string = ""
description: "Account to transfer from"
destination_account: mutable string = ""
description: "Account to transfer to"
transfer_amount: mutable number = 0
description: "Amount to transfer"
source_balance: mutable number = 0
description: "Balance of source account"
transfer_limit: mutable number = 10000
description: "Maximum allowed transfer amount"
validation_passed: mutable boolean = False
description: "Whether all validations passed"
validation_information: mutable string = ""
description: "Human readable validation information"
```
每个变量以已知默认状态开始。字符串默认为空，数字为零，布尔`validation_passed`默认为 `false`。这意味着大门默认关闭。工作流必须积极赢得每一步的继续权利，而不是从大门打开开始并依靠检查来关闭它。
## 何时使用确定性逻辑
银行转账示例说明了确定性逻辑是正确的工具，但它并不总是最好的选择。理解边界与理解模式同样重要。
当工作流需要保证的执行顺序时，当错误产生重要后果时，当流程需要产生可重复的审计跟踪时，或者当业务规则定义良好，足以表示为条件和阈值时，确定性逻辑是正确的选择。财务、医疗保健和保险工作流通常属于这一类。
当交互的价值在于灵活性而不是精度时，没有严格确定性约束的纯 LLM 推理更有意义。开放式客户支持、业务流程仍在发展的早期阶段产品以及风险较低的信息查询都是 LLM 推理变化无常的特点，而不是问题。
在实践中，大多数生产客服人员都需要两者。边界落入何处的决定不是确定性和概率性之间的二元选择；而是您在节点级别为客服人员工作流的每个部分做出的设计决策。
| 使用确定性逻辑 | 使用 LLM 推理 |
| ------------------------------------------- | --------------------------------------------------- |
| 输入验证和消毒 | 自然语言理解和意图检测 |
| 业务规则实施 | 生成会话、感同身受的回应 |
| 顺序流程编排 | 处理不明确或意外的输入 |
| 状态管理和上下文保留 | 提供解释和澄清 |
| 防止无效操作的保护条款 | 调整语气和消息传递以适应用户上下文 |
**边界是设计决策**
银行转账示例说明了一种设计哲学：确定性执行和 LLM 推理之间的界限是您在构建生产代理时做出的最直接的架构决策。
设置一个过于僵硬的边界，您最终会得到一个僵硬、维护成本高昂且无法处理真实对话自然变化的客服人员。如果边界错误，就会产生一个灵活但不可预测的客服人员，他们在测试中表现良好，但在生产中表现不同，并且无法产生可靠的审计跟踪，也无法得到高风险交易的信赖。
新的 Agentforce 模型为您提供了有意放置该边界的工具。客服人员脚本允许您在同一文件中表达确定性逻辑和提示指令，并使用显式语法使边界可见。Atlas 推理引擎会在运行时强制执行逻辑和提示。`before_reasoning` 和 `after_reasoning` 块为您提供了 LLM 调用两侧的保证执行区域。条件操作可用性确保 LLM 只能在满足先决条件时采取行动。
这些功能都不是孤立的。他们共同协作，为构建企业可以通过任务关键型工作Trust任的客服人员创建一致的架构。混合推理模型认识到确定性和灵活性在您的架构中都有其作用；架构师的工作是准确决定每个作用的应用。
## 引用
[客服人员脚本模式](https://developer.salesforce.com/sample-apps/agent-script-recipes)
[Agentforce 开发人员指南](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html)
[Agentforce 的客服人员图表：通过混合推理](https://engineering.salesforce.com/agentforces-agent-graph-toward-guided-determinism-with-hybrid-reasoning/)实现指导决定论
## 关于作者
Gulal Kumar 是 Salesforce 的软件工程架构师，拥有超过 20 年的经验。他的专长涵盖 AI、集成、API 和企业架构，专注于通过安全、弹性和创新的 AI 解决方案推动业务转型。在 [LinkedIn](https://www.linkedin.com/in/gulal/) 上与他联系。
Miriam McCabe 是建筑师福音团队的高级总监和领导。她的工作重点是通过深入的技术内容、实时编程和社区参与，使全球 Salesforce 架构师社区在客服人员时代处于领先地位。在 [LinkedIn](https://www.linkedin.com/in/miriammccabe/) 上关注她。
# 导言
本文档描述了企业在未来 3-5 年内需要 IT 架构来充分获取客服人员的价值的观点；它概述了支持大规模部署 AI 客服人员所需的 IT 转型。目标是提供战略指南和参考架构，以帮助 CIO、CDO 和 IT 领导规划他们成为代理企业的旅程。
强大的 AI 模型支持创建客服人员团队，能够感知环境、推理数据、自主决策、执行任务，并与人类员工有效协作。这支新员工队伍有望在创新、生产力和灵活性方面实现飞跃式变革，为股东和客户创造价值。为实现这一愿景，组织必须进行业务和 IT 转型，才能成为代理企业。
## 客服人员企业的业务功能
如今，传统企业面临着由信息孤岛、员工沉浸在手动工作中、组织结构中的激励措施不一致以及战略和结果之间的反馈回路不连贯而造成的运营效率低下。这些问题会导致客户体验不佳、流程效率低下，并错失增长机会。
Agentic Enterprise 通过将智能 AI 客服人员的数字员工与人类员工集成，克服了这些限制。通过这种新的 AI 增强的员工队伍，组织可以通过多种类型的新业务能力来促进增长、提高运营卓越性并建立企业复原力。
**促进创新的新业务功能：**
- 提高人的工作效率：AI 客服人员的速度、规模和始终在线的特性允许企业自动化重复工作，并将人工员工解放出来，专注于更高价值和更富创造性的任务。
- 自适应功能改进：因为可以观察 AI 客服人员的推理，所以他们可以动态地学习和部署新技能，使企业能够不断提高绩效，以满足业务目标并快速适应新的市场机会。
_实践示例 — 在金融服务中创新客户体验：_财富管理公司可以使用 AI 客服人员来重塑其客户参与模式。客服人员可以自主监控产品组合，确定客户审查的关键时刻，并为顾问准备通话前计划，并在出现新闻时调整计划。这允许人工顾问大规模提供主动的个性化客户体验，加强关系并发现新业务机会。
**保护和确保组织弹性的新业务功能：**
- 弹性劳动力容量：企业可以快速扩展其能力，以满足不断变化的业务条件所带来的工作量激增，而无需增加完全由人工组成的员工的成本和延迟。
- 预测性运营弹性：AI 客服人员的全天候特性使他们能够实时自主预测、建模和缓解运营、合规和安全风险，确保企业保持客户和利益相关者的 Trust。
_示例 — 保护客户数据：_大型企业可以部署 AI 数据治理代理来扫描监管环境中的数据隐私法的变化，发现和分类企业数据集中的敏感信息，然后应用适当的治理策略。客服人员可以查看数据访问请求，并将异常路由到人工分析师进行审核，从而降低合规风险，同时使数据能够以可信方式使用。
**优化卓越运营的新业务功能：**
- 自主进程执行：数字化员工能够以机器速度全天候执行复杂的多步骤任务（人工在工作循环中），从而降低成本并高效地扩展流程。
- 跨界编排：AI 客服人员可以跨通常约束人类员工的信息和激励竖井工作，从而提高跨职能流程的灵活性。
_操作示例 — 优化零售中的营销漏斗：_零售营销团队可以部署 AI 客服人员，以加快市场活动流程，从而应对新的消费者趋势。客服人员可以生成市场营销计划，与市场营销、产品和销售团队协作进行审查，然后自动创建数字抵押品并在多个渠道中执行，并根据实时反馈动态调整市场活动。
## 客服人员企业的 IT 架构
本节探讨了传统 IT 架构必须如何发展，以支持与人类员工一起推理和采取行动的自主 AI 客服人员。
### 传统 IT 架构的限制
企业的 IT 架构可以使用层结构来描述。这些层在逻辑上分组相关的技术功能，并促进结构化推理，但不一定意味着具体的实施，或者层应该以单一或更异构的方式设计的程度。在此层视图中（图 1），传统 IT 架构由五个主要层组成：基础设施、数据、集成、应用程序和体验。安全和 IT 运营这两个跨层跨越这些层，以确保治理、监控和保护。
传统的 IT 架构专为这样一种模式而设计，在这种模式中，企业的智能由人工员工来承担，他们在应用程序中采取操作来访问数据、应用业务逻辑、促进协作和执行工作流。它不是为这样一种模式设计的，在这种模式中，AI 客服人员可以对人类之前完成的某些用例（或根本没有完成）进行推理和采取行动，而人类却监督 AI 客服人员并专注于更具创造性和更模糊的任务。
虽然传统架构现在可能支持 AI 客服人员的小规模部署，但它不能完全提供上述 Agentic Enterprise 的业务功能。实现这些功能需要一种专为广泛部署强大的 AI 客服人员而设计的 IT 架构，它可以解决广泛的用例，而不是局限于针对狭窄用例的有限部署。
AI 客服人员将在未来 5 年内继续改进，IT 架构需要发展，以实现功能更强大、更智能的 AI 客服人员的价值，并成为未来证明。首先，随着基础 AI 模型（例如多模态 LLM）和客服人员认知架构的发展（例如，多步骤计划、任务分解等），客服人员将变得更加智能。第二，AI 客服人员将具有更好的学习和适应能力，包括记忆改善、自我反思能力和从反馈中学习的能力。第三，AI 客服人员将拥有与其他客服人员、工具和数据进行交互的更大能力，开放技术标准（例如模型上下文协议、Agent2Agent 等）的快速发展生态系统就是明证。虽然这三种技术趋势将使 AI 客服人员在执行更抽象和复杂的任务时变得更加强大，但它也将为今天的 IT 架构带来许多挑战。
首先，AI 客服人员从根本上依赖于内部开发和外部来源的 AI 模型，这些模型快速发展，需要复杂、共享和标准化的 AI/ML 模型管理。如今，AI 模型是为应用程序中的特定用例而构建的，而不是作为共享功能与用于培训、部署、治理和风险管理的通用工具一起重用。今后，企业将需要能够为各种客服人员用例使用不同的 AI 模型，这需要工具，使客服人员能够根据业务上下文交换基础模型（例如，基础模型与特定于领域的更小模型）。这需要使用统一的生命周期工具管理内部开发或托管的 AI 模型，以确保一致性、可重用性、可扩展性和效率。同样，访问外部托管的 AI 模型需要企业范围的控制框架，以确保最佳性能、安全性、合规性、可用性和可靠性。
第二，AI 客服人员具有不同的扩展模式和运营要求，例如托管、开发、推理、学习、内存管理和运营，这需要为客服人员提供单独的专用架构边界。将此功能直接嵌入当今静态和确定性应用程序架构将引入不必要的架构复杂性和风险。此外，AI 客服人员应通过标准化界面或消息传递系统与现有应用程序交互，以实现实时交互。
第三，AI 客服人员需要能够对不同的数据集进行推理，并经常在孤立的应用程序堆栈之间相互协作，但在今天的架构中，没有共同的语义功能来为这些客服人员提供对不同数据集进行推理的共同理解。因此，虽然可以成功部署单用途客服人员，但将其扩展到大量执行复杂的跨筒仓任务仍然很困难和风险。
最后，当前的企业 IT 架构缺乏一种有效的方式来编排、优化和管理端到端的业务流程，其中包括由更强大的客服人员执行的动态工作流，这将增加并在某些情况下取代人工员工在该流程中完成的角色。今天，自动化工具被用来管理线性的、确定性的工作流，这些工作流通常遵循预定义的顺序，用特定于流程的语言记录，并依赖于很少改变的静态逻辑。AI 技术可以增强其中一些线性流程（例如，使用 ML 模型而不是硬编码的业务规则来计算贷款批准阈值），但大多数关键业务流程的战略和执行方面本质上仍然是动态和灵活的。制定营销策略、解决复杂的客户问题或潜在客户等任务有明确的目标（客户满意度、个案解决速度等），但没有遵循固定的预定义执行顺序。
目前，传统企业主要依靠人工来协调和执行这些复杂的业务流程（例如制定策略和管理复杂的项目）。随着 AI 客服人员在未来 3-5 年不断发展（智能、学习和交互能力更强），他们自主执行此类动态流程的能力将显著扩展，带来的复杂性和集成挑战将远远超过现有集成和自动化工具的能力。AI 客服人员的自适应和动态性质强烈需要新颖的编排功能，以确保企业级控制、全面可见性，并与企业范围的战略目标保持一致，特别是在管理包含 AI 客服人员、人员、自动化工具和其他确定性系统的复杂、漫长和多步骤工作流方面。
Agentic Enterprise 的 IT 架构通过无缝集成人工、AI 客服人员和确定性系统来建立智能操作的平台。该架构使人类和 AI 客服人员能够动态访问和利用来自不同数据源的统一 Enterprise Knowledge，并丰富语义上下文，以高效执行与战略业务目标一致的复杂工作流和流程。一组孤立平台和点解决方案的现有 IT 架构将朝着一组可组合应用服务、语义和数据工具以及 AI 客服人员网络的方向发展，这些网络由新的智能业务流程编排工具监督和控制。
此架构使客服人员能够感知、推理并在各自的范围内采取行动，在业务域内和跨业务域工作，并不断学习、改进和适应。这要求设计侧重于访问数据和 Knowledge 的强大机制（语义理解）、灵活和标准化的通信协议和接口（例如客服人员到客服人员、客服人员到确定性系统和客服人员到人类），以及跨客服人员、人类和自动化工具和确定性系统编排工作流和流程。
### 架构原则
为了实现智能操作平台的架构愿景，这些设计原则被推荐为最佳实践：
- **可组合性和模块化：**将架构元素设计为具有标准化界面的模块化组件，以实现客服人员功能、工作流和面向人的表面的快速动态组装。优先考虑清晰的界面合同和抽象，以使 AI 客服人员在撰写工作流时拥有最大的灵活性。
- **数据和语义优先：**确保全面、准确、快速、安全和经济高效地访问数据，共享语义理解，以便客服人员在孤立的系统中有效推理。这需要将数据（和元数据）视为产品，使用工具确保质量、谱系、治理和访问权限，以及提供客服人员和人员之间共享的语义理解。
- **IT 和业务可观察性嵌入：**在整个架构中嵌入端到端的监控、跟踪、评估和可解释性功能，深入了解客服人员的推理、行为、系统交互以及对业务 KPI 的影响，以实现客服人员绩效的持续优化。这包括成本优化 (FinOps)、可持续性度量和运营遥测，同时保持 Trust、合规性和负责任的资源消耗。由于 AI 客服人员本质上是非确定性的，因此可观察性对于确保 AI 客服人员在人工监督下以可信、合规和可审计的方式运行至关重要。
- **Trust-throughout:**根据客服人员的任务意图（数据访问、操作等）强制执行动态、精细的权限，并实施全面的安全实践，包括红色分组、自动 CVE 扫描、漏洞检测和基于风险的验证控制。鉴于客服人员能够以机器速度工作，因此存在导致级联风险的风险，因此需要更精细和更动态的控制。确保在使用或交付之前，根据定义的合规、安全、毒性和偏见策略，严格验证所有 AI 生成的输出（来自客服人员或模型），这需要具有 AI 决策、操作、内容和预测的可验证审计跟踪的日志记录和可解释性机制。
- **客服人员优先，人工监管：**使 AI 客服人员成为默认工具，以解决业务用例，排除其他注意事项（例如成本、技术适应性），并将 IT 系统设计为客服人员工作流可访问。这包括人类监控、干预和覆盖客服人员流程任何步骤的能力。如果客服人员对决策的信心低于预先编程的阈值，他们需要自我反省的能力来主动寻求人工指导。
- **反应性和多模态交互：**启用架构，以支持所有交互类型的综合客服人员调用和响应机制，包括客服人员到客服人员协议、人工多模式输入（语音、文本、可视）、业务事件、系统信号和流数据。启用事件驱动和实时处理能力，以确保客服人员可以对来自任何来源或格式的任何及时信号做出反应。
- **AI 就绪基础设施：**确保基础设施可以通过内置的冗余来弹性扩展，以处理波动的 AI 工作负载，并将 ML/LLM 漏斗集成到数据和应用程序架构中，同时保持对数据驻留要求的合规性。
- **开放生态系统：**通过支持开放标准、协议和定义明确的接口（API、事件），优先考虑互操作性并避免技术锁定，以从技术生态系统中受益。
## 架构层
要成功启用并扩展客服人员转换，企业必须超越仅增强当前层；他们需要考虑明确引入四个额外的架构层（图 2），这些架构层是专为满足 AI 客服人员的需求而设计的。
**Agent 层**致力于 AI 客服人员的开发和管理，包括规划、推理、记忆、工具使用、状态管理和生命周期控制等认知功能。该层满足 AI 客服人员独特的技术和运营要求，通过标准化协议确保应用程序和数据存储之间的互操作性，并促进客服人员之间的协作。现有的应用程序层将发展为应用程序服务，以便为代理工作流动态组合。
引入**语义层**来解决原始企业数据和 AI 客服人员需要的语义理解之间的脱节问题。它明确编码和管理业务实体、概念、定义和相互关系，创建企业本体和业务 Knowledge 的表示，以实现共享语义理解，从而支持执行更高级别任务的更复杂的多客服人员工作流。除了数据目录之外，语义层将自然语言查询转化为对特定数据存储的精确查询，协调结果，并为客服人员返回上下文中更丰富的答案。同时，现有的数据层通过采用集中的湖库来统一，同时通过 AI 就绪的数据结构来扩展数据访问，以支持数据网格操作模型原则。
**AI/ML 层**集中管理企业 AI 功能，包括大型语言模型、大型操作模型和特定于领域的 ML 模型，在内部开发的 AI 模型和外部 AI 服务的受控访问/使用中处理。与 AI 模型嵌入应用程序的传统架构不同，该层将 AI 模型建立为企业中的一流组件和共享服务。它侧重于企业控制的 AI 功能（不是外部供应商提供的 AI 功能）。该层通过 Trust、安全、合规和部署的标准化机制，为企业中的各种客服人员和其他 AI 工作负载提供智能。
**企业编排层**是用于协调、管理和优化跨 AI 客服人员、人员、自动化工具和确定性系统的复杂、多步骤工作流和业务流程的功能抽象。该层利用混合编排模型，允许单个客服人员和系统使用开放协议（例如 MCP 和 A2A）自主处理本地编排的任务，同时对整个流程进行集中的端到端监督和协调。为实施混合编排模型，该层以机器可读的语义丰富的格式表示关键业务流程，这些格式定义了业务流程的确定性步骤（在设计期间建模）和动态步骤（在运行时由客服人员决定），为治理和优化创建了流程模型基础。
传统上，人类驱动的业务流程的很大一部分仍然以机器可读的形式记录或无法访问。但是，AI 客服人员活动的详细可观察性，包括关于其任务和操作的丰富数据和元数据，支持捕获、记录并将以前未结构化的动态工作与确定性线性工作流集成在一起，以创建全面的流程模型。详细的流程文档捕获了以前不可见的任务相互依赖性和执行路径，使企业能够不断优化运营效率，有效解决瓶颈问题，并将客服人员识别的最佳实践系统地编纂成可重用的企业范围行动手册。这就产生了单个流程的整体数字孪生模型，当扩展时，就是整个企业。
例如，复杂的流程，例如执行全面的销售策略，或培训新员工，涉及许多相互依赖的步骤，其中编排层可以确保适当的人员参与水平（例如异常处理），AI 客服人员的有限自主权，并强制合规。在这些流程中，自上而下的编排层增加了可预测性和治理能力，不断跟踪和评估关键绩效指标 (KPI)，确保工作流和回滚逻辑的事务完整性，并保持工作流每个阶段的可见性，以确保与总体业务目标保持一致。为了实施此功能，该层使用来自安全和治理层（通过策略即代码）的策略、规则和防护以及存储在语义层中的业务目标和 KPI。鉴于 AI 驱动的交互的自主性和快速性，仅依赖分散的编排存在战略失准或合规违规的风险，特别是在长时间运行的多步骤工作流中。混合编排方法通过将企业范围的业务规则、合规性检查和政策执行直接嵌入复杂的工作流中，并整合了关键节点上的人工监督，从而降低了这些风险。
这 11 层中的每一层都贡献了特定的功能，以安全、可信和有效的方式大规模部署 AI 客服人员，从而释放客服人员 AI 的全部潜力，以改变企业中的工作方式。以下部分概述了图层的功能、AI 客服人员兴起带来的新变化及其关键技术功能。
### 体验层
**函数：**体验层作为人类用户的主要界面，通过捕获输入（文本、语音、视觉）并在多个设备之间提供上下文相关的响应来实现多模态交互。它无缝地将用户意图移交给客服人员层进行操作，同时还提供动态 UI 和可视化，便于客服人员工作流中的人工升级和批准。
**与今天相比有什么不同：**AI 将通过自然语言处理、上下文感知和主动决策支持来增强传统的基于 GUI 的界面。AI 客服人员将能够主动发起交互，跨所有渠道和模式提供个性化的实时推荐。
**关键技术功能：**
- **对话式 AI 和数字助手：**默认情况下，启用 UX，以使用 AI 帮助来支持人类用户。
- **属性和透明度 UI：**使响应在用户界面中可解释，例如显示引用、文件/系统的来源以及决策的方法/理由。
- **主动和环境通知服务：**使客服人员能够根据用户的当前上下文，在最合适的渠道和外形规格上主动向用户推送见解或提醒。
- **全方位体验：**通过旅程连续性，在所有渠道中提供无缝、一致和统一的体验，对话和任务遵循人员，而不是应用程序。
- **多模式功能：**允许用户通过文本、语音、图像、触摸、视频和 AR/VR 与客服人员和应用程序交互，以便客服人员能够以最有效的方式理解和显示信息。
- **上下文感知个性化和动态 UI：**支持上下文感知的实时（时间、位置、用户操作）用户体验，以实现个性化，包括随时生成 UI。
### 客服人员层
**函数：**客服人员层充当在企业中工作的默认运行时环境，其中 AI 客服人员使用应用程序和应用程序服务层以及数据层的工具动态组装工作流，从而从体验层分解任务并执行任务。AI 客服人员的配置状态在此层中存储和管理。为特定任务实例化客服人员，之后停用特定客服人员实例。此实施使客服人员始终能够从基于离线优化的最新配置状态调用（使用 AI/ML、可观察性和编排层的功能）。该层负责 AI 客服人员的全面生命周期管理、协调和治理。
**与今天相比有什么不同：**这一层将出现今天完全不同的试点和有限的客服人员部署。虽然存在基于规则的机器人，但很少大规模部署适应性、非确定性和面向目标的软件程序。
**关键技术功能：**
- **客服人员运行时环境：**管理 AI 客服人员的生命周期、执行和资源分配。
- **客服人员生命周期管理套件：**包括开发框架、开发和测试工具以及客服人员活动和版本控制的管理系统。
- **客服人员原因引擎：**客服人员分解目标、计划和决定使用什么工具解决复杂问题的认知框架。
- **客服人员记忆和上下文存储：**允许客服人员实例回顾和维护有关之前交互的上下文，确保一致性和个性化。
- **客服人员交互性协议：**客服人员对客服人员通信 (A2A) 和客服人员与外部系统接口（例如通过模型上下文协议）的标准化接口。
- **工具注册表：**一组精心策划的内部和外部支持的工具，供客服人员调用来完成特定的任务。
- **客服人员注册表：**预构建的 AI 解决方案和客服人员的精心策划的生态系统，支持发现和功能匹配。
- **分布式客服人员策略实施：**通过允许客服人员在采取行动之前自检合规性，启用企业范围的治理。
- **客服人员自我反思和适应框架：**为客服人员提供分析自身性能的机制，并在人工批准的情况下触发改进或建议修改。
### AI/ML 图层
**函数：**该层充当集中智能中心，将 AI 模型作为一组共享服务提供，由客服人员层（和应用程序）使用，以通过内置的安全框架和监控来支持其推理和决策功能。
**与今天相比有什么不同：**传统上，AI 模型嵌入到特定的应用程序中。在 Agent Enterprise 的 IT 架构中，AI/ML 层将是一组一流的集中服务，为许多应用程序和客服人员提供支持，支持从开发到大规模实时服务的整个生命周期。
**关键技术功能：**
- **预构建基础模型：**基于广泛数据训练的大型 ML 模型，能够执行各种一般任务。
- **检索扩充生成 (RAG)：**一种以 AI 为中心的漏斗，将基础模型作为企业特定数据的基础，以提高准确性并减少幻觉。
- **AI Trust、安全和治理中心:**集成到模型生命周期中的一套工具，用于强制执行负责任的 AI 原则，例如偏见检测、可解释性和安全监控。
- **模型网关：**一个路由引擎，充当所有模型推理请求的单一入口点，管理对各种内部和外部模型的调用，以优化成本、性能和合规性。
- **模型开发工作台：**数据科学家的集成开发环境，包含数据预处理、模型训练和实验工具。
- **MLOps 和生命周期自动化漏斗：**用于机器学习的 CI/CD 引擎，自动化了模型从训练到部署和停用的端到端生命周期。
- **模型服务和推理运行时：**一个可扩展的低延迟环境，用于将经过训练的模型部署为实时使用的安全 API 端点。
- **模型和资产注册：**所有 AI/ML 资产的集中版本控制存储库，包括模型、数据集和源代码，确保可再现性和可审计性。
- **合成数据生成和管理：**生成和管理合成数据的工具，可维护真实数据的统计属性，而不会暴露敏感信息。
### 企业编排层
**函数：**企业编排层是代理企业中端到端工作的控制平面。它确保客服人员工作流和交互遵守企业目标和治理策略。它使用来自其他层的可观察性遥测来构建全面的业务流程模型，从而能够针对从语义层中提取的 KPI 进行优化。该层为关键工作流的 AI 客服人员的每个新实例提供共享上下文和长时间运行的内存。
**与今天相比有什么不同：**该层通过创建机器可读的模型来提供对业务流程的统一可见性，该模型捕获结构化的确定性步骤，以及人类和客服人员执行的非结构化的动态工作。通过将业务目标和合规规则作为约束以编程方式编码到客服人员工作流中来治理客服人员，它超越了当今以人为本的协作和治理模式。
**关键技术功能：**
- **混合工作流执行引擎：**执行“混合编排模型”的核心运行时，提供集中监督，同时允许本地客服人员编排。
- **流程治理和约束引擎：**一种实时治理服务，它使用声明性业务规则、策略和约束并将其应用于所有正在进行的流程。
- **共享内存和上下文管理：**工作流中的所有参与者都可以访问的共享内存层，以保持多个步骤之间的连续性和一致性。
- **Process Modeling Studio：**一种设计时环境，用于创建和管理机器可读、语义丰富的流程模型，该模型定义了确定性和动态的、面向目标的步骤。
- **流程优化和仿真：**一种构建业务流程数字仿真的功能，用于高级分析、假设仿真和预测优化。
- **进程发现和健康监控：**引入流程模型和实时数据，以报告流程运行状况的业务度量。
- **数字孪生过程建模：**实时工作流的实时镜像，用于在不影响生产的情况下进行测试、模拟更改和优化。
### 应用程序和应用程序服务层
**函数：**此层将现有业务应用程序功能公开为可组合和模块化的工具和服务，供客服人员使用。它还作为演示运行时，用于将客服人员功能嵌入用户体验。应用程序仍然是记录系统，但经过重新设计，客服人员可以使用“无头”功能。
**与今天相比有什么不同：**应用程序将从整体式 UI 发展到客服人员可以通过 API 和事件动态调用的“后端服务”。这一层将与 AI 客服人员和模型本地集成，代码生成 LLM 的扩散将导致自定义客服人员构建的微型应用程序数量增加。
**关键技术功能：**
- **模块化应用服务：**从传统应用程序中分解的业务逻辑，发布为供客服人员调用的机器可读操作。
- **客服人员嵌入 SDK：**工具包和库，使开发人员能够安全地将客服人员直接嵌入应用程序 UI。
- **动态 UI 生成服务：**允许 AI 客服人员根据用户上下文实时生成或修改 UI 组件的服务。
- **AI 本地 UI 框架：**前端框架内置支持，用于处理 AI 驱动的 UI，例如管理概率数据和流文本响应。
- **客服人员注入的参与系统：**通过可视组件整合 AI 客服人员功能的企业级生产力和协作应用程序。
- **AI 增强的低代码/无代码应用程序开发：**使用户和客服人员能够使用自然语言和提示创建自定义应用程序和服务的工具。
- **适用于客服人员使用的应用程序护栏：**客服人员使用的应用程序侧控制，例如速率限制、范围权限和遥测。
### 语义层
**函数：**语义层提供了整个企业对数据和 Knowledge 的统一理解，使人类和 AI 客服人员能够一致地解释信息并对其采取行动。它使用 Knowledge 表示工具，例如本体论和 Knowledge 图，将自然语言查询转化为精确的上下文感知数据查询。
**与今天相比有什么不同：**虽然今天的企业拥有不同的元数据存储，但 Agentic Enterprise 的 IT 架构需要一个集中的 Enterprise Knowledge 图 (EKG)，该图通过明确定义的语义关系跨域链接数据。这为 AI 客服人员执行复杂推理提供了丰富的上下文，并为一组支持跨多个功能域的 Knowledge 图表的技术能力创造了要求。
**关键技术功能：**
- **元数据服务：**提供描述性元数据，包括数据谱系、所有权和分类。
- **业务词汇和分类管理：**业务用户定义和商定标准业务条款的工具。
- **语义模型管理：**Knowledge 工程师创建、管理和治理语义模型和本体的工作台。
- **Enterprise Knowledge Graph(EKG):**企业本体的运行时实例化，存储和映射业务实体之间的关系。
- **元数据接收和协调引擎:**一种自动漏斗，从各种源系统填充和维护 Enterprise Knowledge 图。
- **语义查询引擎**:解释自然语言查询，并构建基于 EKG 的结构化查询，以从不同来源检索数据。
- **语义推理引擎：**从 EKG 中分析和导出隐式 Knowledge 和隐藏关系。
### 数据层
**函数：**数据层是真相的基础来源，它管理所有企业数据并提供对其进行安全、受控的访问，以便语义层进行解释，AI/ML 层用于训练，应用程序用于事务，客服人员用于推理。
**与今天相比有什么不同：**数据层发展为更加统一、实时和注重治理，通常以云规模的数据湖库为中心。它必须处理更多和更多的数据，并从面向批处理转向实时流，以支持反应性客服人员。数据治理和质量对于防止不良数据产生有缺陷的 AI 输出更为重要。
**关键技术功能：**
- **VectorDB：**专为存储和查询高维向量嵌入优化的专用数据库，对 RAG 至关重要。
- **智能分析数据漏斗：**一种元数据驱动的自动化服务，用于数据接收、转换和加载 (ETL/ELT) 到数据层。
- **Enterprise Data Lakehouse：**结构化、半结构化和非结构化数据的中央存储库，专为分析和 AI 工作负载优化。
- **零复制数据联合和搜索：**无需物理数据移动即可跨多个商店访问、查询和搜索数据的技术。
- **自然语言到 SQL：**一种将自然语言查询转换为 SQL 的技术。
- **企业数据目录和发现服务：**企业中所有数据资产的集中、可搜索的清单。
- **主和参考数据管理 (MDM)：**管理客户和产品等关键业务实体的“黄金记录”。
- **自适应数据质量服务：**一种持续监控服务，使用 AI 实时自动检测和补救数据质量问题。
- **数据合同：**数据生产者和消费者之间的机器可读协议，指定了数据交换的模式、语义和 SLA。
- **AI 专用数据存储：**为特定 AI 用例设计的数据库，例如时间序列或图表数据库。
- **AI 就绪数据结构：**逻辑数据抽象层，跨不同的物理系统提供统一的虚拟化数据视图。
- **实时数据处理：**以机器速度连续处理和分析多模态数据流的功能。
### 基础设施层
**函数：**基础设施层支撑所有其他层，提供以灵活且经济高效的方式大规模运行 AI 和客服人员工作负载所需的计算、存储、网络和云功能。
**与今天相比有什么不同：**AI 工作负载需要更大的可扩展性和灵活性来处理客服人员系统的概率性质。基础设施必须支持快速配置、GPU 等专用硬件以及客服人员间通信的低延迟、高吞吐量网络流量。
**关键技术功能：**
- **基础设施作为代码：**使用 CI/CD 部署漏斗自动配置和管理基础设施。
- **混合和多云 AI 基础设施：**为生成式 AI 工作负载利用公共云弹性和专用基础设施。
- **AI 优化的计算、存储和网络：**根据 AI 工作负载的可变需求，动态分配和扩展基础设施资源。
- **边缘 AI 基础设施：**支持将 AI 模型和客服人员部署到网络边缘，以满足具有唯一延迟或隐私要求的用例。
- **自愈基础设施：**使用 AI 管理系统恢复，无需手动输入，确保高可用性。
- **可持续 AI 计算：**缓解 AI 工作负载环境影响的节能方法。
- **成本和碳感知自动缩放：**使用 FinOps 和可持续性信号来推动容量的扩展和放置。
### 集成层
**函数：**集成层通过 API、事件、协议和中间件充当所有系统（原有和新系统）的通用通信结构，以确保客服人员可以无缝发现服务、数据和工具并与之交互。
**与今天相比有什么不同：**集成必须发展为支持 AI 客服人员的动态多对多通信模式，而不仅仅是处理几个已知系统之间的预定静态交互。它需要实时数据处理，并且必须适应客服人员之间的临时发现和协作。
**关键技术功能：**
- **操作数据连接漏斗：**AI 辅助工具，用于自动模式映射、数据转换和工作流生成，包括 API 引导、事件驱动和反向 ETL 功能。
- **自适应 API 管理和服务网格：**API 网关和服务网格技术，可通过客服人员的自适应策略实施动态注册、发现和治理服务。
- **语义 Knowledge 适配器：**一个集成组件，跨客服人员和应用程序提供共享词汇和数据模型，以实现一致的数据解释。
- **事件驱动的集成结构：**一种高吞吐量、低延迟的消息传递和流主干，支持分离的异步通信。
- **客服人员协议网关：**MCP 服务的网关，允许客服人员安全地发现工具和触发操作，将 MCP 连接到内部 API 和事件。
- **可组合功能目录和市场：**所有企业功能的集中受管目录（API、服务、客服人员技能、模型和数据集），并使用语义元数据进行注释，以便按需组合。
### IT 操作和可观察性层
**函数：**该层监控和管理客服人员和整个系统的健康和运营绩效（可观察性嵌入原则），通过生成见解来提供透明度和控制，从而实现企业客服人员队伍的审计、调试、可解释性、成本和资源优化。
**与今天有什么不同**:鉴于 AI 客服人员以机器速度创建错误的风险，这一层变得更加重要。它必须扩展到基础设施监控之外，以包括自治代理的不可预测的行为，这需要新型遥测和理解语义正确性的能力，而不仅仅是技术性能。
**关键技术功能：**
- **实时监控和观察平台：**通过扩展 ML 度量和客服人员行为，在整个 IT 环境中持续收集日志、度量和跟踪。
- **FinOps 和云成本管理：**负责监控、分析和优化与 AI 和客服人员工作负载相关的基础设施成本。
- **客服人员和特定于 ML 的监控：**在不可变的审计跟踪中记录客服人员运行的每一步，并持续分析客服人员的行为，以检测对既定规范的偏离。
- **AIOps、事件和变更管理：**使用 AI/ML 预测潜在的 IT 问题，确定根本原因，并创建补救工作流。
- **已关闭学习反馈循环：**将客服人员的可观测性遥测集成回 MLOps 漏斗，支持自动模型重新训练或快速调整。
- **语义可观察性引擎：**将可观察性与语义层集成，以实现上下文化，从而支持检测客服人员行为中的语义异常。
### 安全和治理层
**目的：**该层通过保护企业资产免受威胁、管理风险并确保符合监管要求，在整个架构中嵌入 Trust 和安全性。它包括身份管理、威胁检测、GRC 和特定于 AI 的安全措施。
**与今天相比有什么不同：**安全层必须发展，以解决 AI 模型和客服人员呈现的新攻击表面，例如及时注入和模型中毒。身份和访问权限管理必须从静态的、基于角色的控制转移到动态的、基于意图的权限，这些权限可以及时授予，并在使用后立即撤销。
**关键技术功能：**
- **LLM 输入/输出安全和防护栏：**企业防护系统在及时和响应时间应用，以阻止不安全内容、PII 泄漏和越狱。
- **具有 AI 验证的 Zero Trust 架构：**通过基于 AI 的行为分析增强的持续身份验证，客服人员可以根据特定任务进行精细、及时的访问。
- **客服人员安全框架：**细粒度的权限模型、有害行为的监控以及安全中断客服人员活动的包含机制。
- **AI 模型安全性：**一种深度防御策略，在模型生命周期的每个阶段进行控制，以防止中毒、提取和对抗性攻击。
- **隐私保护 AI：**聚合学习和差别隐私等技术来保护敏感数据。
- **AI 增强的 GRC：**使用 AI 客服人员，以持续监控 IT 架构对控制的合规性。
- **策略即代码引擎：**单一的真实来源，用于以声明性、机器可读的格式定义业务规则和合规约束，为客服人员行为设置防护。
- **连续红队：**对 AI 模型和客服人员进行自动、持续的对抗性测试，以在攻击者利用漏洞之前识别漏洞。
## 代理企业的参考架构路线图
转型为 Agent Enterprise 需要通过奠定技术基础同时创造有形的业务价值来经历一个多阶段的过程（请参见下面的图 3）。虽然精确的路线图取决于企业的战略、文化、AI 治理模型和 IT 架构起点，但大多数组织应该采用分阶段的方法，因为持续的 IT 投资推动了范围、复杂性和价值创造的增长。Salesforce 的[客服人员成熟度模型](https://www.salesforce.com/news/stories/agentic-maturity-model/)为企业制定转型策略提供了有用的成熟度框架，概述了客服人员功能如何从基本信息检索（级别 1）发展到编排更复杂的多域（级别 2 和 3）和多客服人员工作流（级别 4）。要成功推进这些阶段，IT 架构必须协调一致地发展，在每个阶段对架构的不同层进行有针对性的投资，以满足 AI 客服人员更复杂、更高价值部署的需求。对于每个成熟度级别，11 个架构层所需的特定技术功能由投资理由确定。
**成熟级别 1：信息检索客服人员**
**业务目标和价值：通过提供可信的对话界面来查询 Enterprise Knowledge，从而提高人类工作人员的生产力。**主要价值在于增强人的能力，而不是取代人的能力。这些客服人员通过检索信息和推荐操作来协助人员。
**架构重点：**重点是建立安全可靠的数据基础和信息检索所需的基本 AI 组件。治理和可观察性对于建立用户 Trust 和控制成本至关重要。
**关键技术投资（图 4）：**
在此阶段，IT 应专注于创建可信的数据到客服人员漏斗和其他基础功能。**数据层**中的技术(例如 **VectorDB**)对于支持信息检索代理的检索扩充生成 (RAG) 技术至关重要。此外,还有一个集中的**AI/ML层**,包括一个**模型网关**,用于对基础模型进行安全和成本可控的访问,还有一个**AI Trust、**安全和治理中心,用于监测不安全的输出和确保合规。**语义****层**中的**主数据管理**和**业务词汇表**是客服人员检索准确信息的基础。需要客服人员运行时和生命周期功能，以确保在此阶段构建的客服人员可以修改和扩展，以用于未来的用例。为了传递价值和建立用户信心,**体验层**必须包含**属性和透明度 UI**,这可以通过显示引用及其信息来源来解释客服人员的回复。基本的可观察性和安全性投资(例如**零** **Trust**)必须开始实施,以便为未来的客服人员部署做好准备。
**成熟级别 2：简单编排，单域客服人员**
**业务目标和价值：在单个业务域中自动化日常任务并编排低复杂性工作流。**这提高了运营效率并减少了手动工作，使人工员工能够专注于更高价值的活动。
**架构重点：**关键的体系结构转变是从只读数据检索到执行操作。这需要开始更长的旅程，将应用程序功能模块化（通常公开为 API），供客服人员访问，为客服人员操作实施强大的安全性，并构建语义和 AI 开发功能，以提高 AI 客服人员的智能。
**关键技术投资（图 5）：**
主题投资侧重于使 AI 客服人员在适当治理的情况下采取行动。**应用程序服务层**发生重要变化,因为整体业务逻辑被分解为**模块化应用服务** (API) 供客服人员调用。通过集成到可观察性工具中，这些受**应用程序防护**栏保护，以防止客服人员使系统不堪重负。为了支持这些客服人员，需要在客服人员推理、工具协议(例如 MCP)和**注册**表方面进行投资。这带来了新的风险,使得专用的**客服人员安全框架**、AI 模型和客服人员监控功能对于治理和安全至关重要。最后，企业可以开始扩展自定义模型的 AI/ML 功能，以帮助这些客服人员处理特定于域的任务。
**成熟度级别 3：多域编排客服人员**
**业务目标和价值：****自动化跨越组织和功能边界的复杂端到端业务流程** （例如“报价到现金”、“潜在客户到订单”）。其价值在于打破孤岛，加快流程周期，并优化业务中的整个价值链。随着组织壁垒开始打破，人类开始更加关注对 AI 客服人员的监督，人类工作人员的工作效率可能会发生更高的变化。
**架构重点：**该架构现在必须支持交叉技术问题。跨企业的共享语义理解、用于治理的集中编排引擎以及分离的、事件驱动的集成结构成为关键的推动因素。
**关键技术投资（图 6）：**
技术投资的主题重点是在企业范围内跨人员、客服人员和确定性系统编排流程。**企业编排层**成为投资的重点,需要**混合工作流执行引擎**来协调活动,需要**流程治理和约束**引擎来在动态流程上强制执行业务规则和合规策略,因为客服人员跨域工作,通常具有不同的策略和语义定义。这种跨域协调只有在具有**Enterprise Knowledge Graph(EKG)**的成熟**语义层**下才有可能,这种语义层对业务实体如何跨域关联产生了共同的理解。**集成层**必须发展到包括**事件驱动集成结构**,该结构使用流主干来解耦系统，并实现长时间运行的业务流程典型的弹性异步通信。鉴于这些工作流的价值和相关风险较高,因此在安全和监控方面增加投资至关重要(例如 **AIOps、策略即代码**)。最后,随着人类用户开始监控和与更强大的 AI 客服人员协作,必须对应用和服务层进行进一步投资(例如**支持 AI 的** LCNC、更具动态性和多模态的用户体验 ) 。
**成熟级别 4：多客服人员、多域编排**
**业务目标和价值：跨域重新设计和优化业务运营，推动生产力和效率的步伐变化。**此阶段将转向创建企业的整体数字模拟 (数字孪生模型)，以便在主要业务流程和工作流中进行持续改进和战略规划。
**架构重点：**最后一个阶段侧重于在客服人员之间实现动态的紧急协作。这需要高级客服人员到客服人员 (A2A) 通信协议、客服人员自学习功能、进一步投资成熟编排、数据和语义层，以及完全动态和自我修复的基础架构，以支持客服人员在整个企业范围内扩展时不断增长的动态 AI 工作负载需求。
**关键技术投资（图 7）：**
主题投资侧重于创建一个自我改进的自主系统。在**客服人员层**中，**客服人员自检和适应框架**为客服人员分析自己的性能日志和触发改进提供了机制。**IT 操作和观察**性层支持这种学习，它实施**封闭学习反馈循环**，将观察性数据自动反馈回 MLOps 漏斗进行模型重新训练，这也可以利用合成数据生成来进一步优化模型性能。随着客服人员网络在各部门的部署以及持续的应用程序模块化工作,客服人员有必要在安全性和**可组合功能目录**方面进一步投资,以动态组合功能，从而解决更抽象和更有价值的任务。这些流程都通过新的**数字孪生流程建模**功能进行编排和优化,该功能使用实时数据为“假设”分析和预测优化创建模拟，允许企业安全地测试和部署新的客服人员部署。
**结论**
客服人员企业的路线图贯穿于 IT 架构的演变。企业架构师将是这一转型的关键驱动因素，与业务和 IT 领域的其他合作伙伴一起推动关键的投资决策，这对组织实现 Agent Enterprise 新业务功能的价值至关重要。
# 从可撰写集成到受管代理企业
向 Agentic Enterprise 的过渡代表了自云诞生以来最重要的架构转变。它承诺实现前所未有的生产力和自动化水平，但也带来了与治理、安全和操作复杂性相关的深刻挑战。使用零敲碎打的方法 - 在没有统一策略的情况下将客服人员部署在孤岛中 - 直接导致了技术债务和组织混乱。
在没有中央管理平面的情况下部署客服人员会产生巨大的运营风险，包括直接访问系统带来的安全漏洞、客服人员交互和操作缺乏可观察性，以及冗余点对点集成带来的高成本。这种孤立的部署策略导致环境脆弱，难以大规模管理。可持续模式需要统一的客服人员集成和治理平台。
_MuleSoft_ 提供了一个全面、统一和开放的平台，可以自信地指导企业的整个旅程。它利用企业现有的 API 环境作为客服人员操作的基础，并通过可信的 AI 支持的开发生命周期加快创建新的客服人员就绪资产。通过对开放标准的企业级支持，例如模型上下文协议 (MCP) 和 Agent2Agent (A2A) 协议，它使这些资产可用于简单的命令和复杂的多客服人员协作，无论 AI 环境如何发展。[_MuleSoft 客服人员结构_](https://docs.mulesoft.com/agent-fabric/)提供了发现、编排、治理和观察整个客服人员生态系统的解决方案。通过这一综合方法,_MuleSoft Agent Fabric_为扩大可信 AI 客服人员网络提供了一个经过验证的基础,将 AI 的前景转化为有形的、自动化的业务结果,并充分发挥了智能企业的潜力。
## **可操作 AI 的可撰写基础**
API 主导的连接的既定三层方法 - 系统、流程和体验 API 为构建客服人员的可操作性提供了强大的框架。
- **系统 API** 为底层记录系统提供了一致、安全和抽象的接口。它们将客服人员与后端协议和数据模型的复杂性分开，从而确保所有客服人员操作都在受管的可靠端点上执行。
- **进程 API** 封装复杂的多步骤业务逻辑。客服人员无需了解创建销售订单、检查库存或启动发货背后的复杂编排。他们可以使用进程 API（例如，“进程订单”），而无需处理潜在的复杂性。进程 API 为客服人员执行业务流程提供了安全的、事务性的和可审计的机制，这大大减少了客服人员所需的推理，并确保了业务规则的一致执行。
- 传统上,**体验 API** 旨在服务于特定的 UI 应用程序(例如订单管理应用程序 ) ; 但是,它们也可以重新用作客服人员的上下文丰富的操作。这为客服人员提供了执行给定任务的基本信息，而无需多次调用下游系统。
## 1\.生成式创建：加速开发客服人员就绪的资产
为了满足对客服人员就绪工具和功能的不断增长的需求，企业必须加快开发构成可撰写基础的 API 和集成。_MuleSoft_ 通过将生成式 AI 直接嵌入开发生命周期来应对这一挑战,从而创造了一个良性循环,使用 AI 来构建其他客服人员消耗的高质量资产。
### **1.1 MuleSoft Vibes**
对于开发人员来说,[MuleSoft Vibes](https://www.mulesoft.com/platform/api/anypoint-code-builder/announcing-mulesoft-vibes) 通过自动化集成开发最重复的方面并为整个软件开发生命周期提供统一的代理界面来充当智能合作伙伴。通过 [Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/) 中的 MuleSoft Vibes, 开发人员与受[信任 _Einstein AI 漏斗_](https://blogs.mulesoft.com/automation/how-mulesoft-turns-generative-output-into-value/)支持的生成功能进行交互, 这使得 AI 辅助开发过程平稳高效。该漏斗 - _推理图执行服务 (IGES)_ 是一个多阶段的过程，用于实现高质量的结果。它包括基础训练、验证、纠错和严格评估。
- _MuleSoft Vibes_中的[**生成流**](https://blogs.mulesoft.com/dev-guides/einstein-for-acb/)能力建立在_Agentforce AI_框架之上。它将自然语言业务逻辑（用户提示）转换为功能性 Mule 应用程序。_IGES 漏斗_包含以下步骤：
- **对话历史汇总：**LLM 会分析当前提示和用户先前的消息，以创建汇总提示，从而捕获用户意图和对话历史。此合并提示提高了后续数据检索和生成步骤的准确性。
- **从矢量数据库进行流语义检索：**系统会获取上一步的汇总提示，并对包含 200 多个连接器、7000 多个连接器操作和 7000 多个示例代码片段的向量数据库执行语义搜索。它检索最相关的连接器、操作和代码示例，以使用准确的数据对生成过程进行基础训练，并确保输出与 MuleSoft 广泛的连接器生态系统保持一致。由于 MuleSoft 是连接器和操作的行业标准，因此这种基础训练为模型提供了通用 LLM 所缺乏的丰富的上下文和域准确性。
- **扩充：**然后，检索到的内容和对话历史消息与汇总的提示相结合。这种增强提示引导 LLM 减少幻觉。它还包括防止产生有毒内容的说明。
- **流生成：**该步骤利用 _Einstein AI LLM_ 模型根据上下文和提供的示例生成原始 XML 代码。这是生成漏斗的核心步骤。
- **后期处理和验证：**后处理器和验证器检查代码，以确保语法正确，并使用有效的连接器操作，同时单独的毒性检查标记有害内容。
- **多步骤纠错：**如果所有初始生成无效，自动纠错机制会分析错误消息，以检测模式。然后，它向 LLM 重新提交提示以及丰富的错误消息和纠正元数据。
- **配置文件生成：**此步骤提取相关连接器元数据，增加提示，并将其发送到 LLM，以生成准确的连接器配置。最后，所有 POM 和 XML 命名空间都使用每个依赖项的最新版本来确定地生成，这消除了幻觉并确保了一致性。
- [**DataWeave 转换生成**](https://blogs.mulesoft.com/dev-guides/dataweave-generative-transformation/)**:** 数据转换通常是集成开发中最耗时的部分。_MuleSoft Vibes_ 使用与 _Mule Flow XML_ 生成相似的多步骤方法来处理此过程。
- **意图原因：**LLM 分析用户输入和输出数据示例，以自然语言推断和阐明高级转换逻辑。此步骤会将用户目标与提示中可能提供的文字数据值分开。
- **DataWeave 语义检索：**为了查找语义最相关的 DataWeave 函数文档和完整的转换示例，系统使用上一步生成的提示作为向量数据库的查询。这为生成过程提供了高质量、可验证的信息。
- **扩充：**检索到的函数和示例与原始用户提示相结合，为后续 LLM 调用创建上下文感知指令集，这会影响 LLM 的行为以减少幻觉。
- **DataWeave 生成：**此步骤利用 LLM 模型生成 DataWeave 转换脚本，以及基于提供的上下文和示例的随附解释。这是生成漏斗的核心步骤。
- **后期处理和验证** 根据两个特定度量评估生成的脚本：有效性和正确性。该脚本必须在没有语法错误（有效性）的情况下编译，并在使用示例输入（正确性）运行时产生预期输出。
- **多步骤纠错：**如果初始验证失败，此插件会识别错误类别，并更正生成的脚本中的问题。这种细化有助于提高系统的整体成功率和准确性。
- **最终后期处理和验证** 来自纠错模块的已更正脚本经过重新验证过程，以确保它在语法上有效，功能上正确。此最终质量门确保输出在发送回用户之前准确可靠。
- [**API 规范**](https://docs.mulesoft.com/anypoint-code-builder/api-ai-create-spec)**和[文档生成](https://docs.mulesoft.com/exchange/generating-documentation-with-ai):**开发人员可以通过自然语言描述所需的 API 来生成完全验证的 _OpenAPI (OAS)_ 或 _RAML_ 规范。_MuleSoft Vibes_ 接收提示(包括关于资源、方法、安全方案和参数的详细信息 ) , 并生成语法正确的有效 API 定义。生成后，它可以在 _Anypoint Exchange_ 中为 API 创建文档，该文档涵盖了从身份验证到端点详细信息和错误处理的所有内容，使开发人员从这些类型的繁琐任务中解放出来。
- **AI 辅助的 MUnit 生成：**对于自主客服人员消耗的资产，质量保证至关重要。_MuleSoft Vibes_ 帮助直接从 Mule 流代码生成 MUnit 测试用例。这有助于模拟外部依赖性和声明，并确定常见的测试差距，这大大减少了实现高测试覆盖率和确保集成逻辑可靠性所需的手动工作。
### **1.2 MuleSoft Your Way**
开发人员在他们的首选环境中发展壮大。这就是为什么 _MuleSoft_ 与开发人员会面,这允许他们在选择的 AI IDE 中构建集成。[MuleSoft 的模型上下文协议 (MCP) 服务](https://www.npmjs.com/package/@mulesoft/mcp-server)器将开发、部署和管理功能公开为 MCP 工具，任何基于 VS 代码的 AI 本机 IDE（例如，光标、Windsurf 或 Trae）都可以使用该工具使用自然语言与 _Anypoint 平台_进行交互。
通过将核心 IDE 功能打包到[标准 VS 代码扩展](https://marketplace.visualstudio.com/items?itemName=salesforce.mule-dx-extension-pack)中,_MuleSoft_ 将其工具与品牌化 IDE shell 分离开来,这使得开发工具与 IDE 无关。这种架构选择使 MuleSoft 的开发工具能够在不断增长的现代 AI 支持 IDE 生态系统中保持兼容性和可访问性，而不是与 IDE 的快速发展竞争。
## 2\.启用可操作性：将 API 转换为客服人员的工具
在 Agentic Enterprise 中，拥有强大的可组合 API 基础是必要的，但还不够。下一个关键步骤是确保这些资产可由 AI 客服人员发现、理解和调用。这需要基于专为客服人员通信设计的开放标准的“可操作性层”。_MuleSoft_ 为两种主要新兴协议提供了企业级工具：
- 适用于客服人员到系统交互的 **MCP**
- 适用于客服人员到客服人员交互的 **A2A**
### **2.1 模型上下文协议 (MCP)**
_MCP_ 已迅速成为客服人员到工具通信的行业标准，类似于 _REST_ 在 Web 服务中的变化。_MCP_ 允许 AI 客服人员动态发现系统的功能，了解其输入和输出，并调用它来执行操作，所有这些都不需要预先编程或硬编码的逻辑。
[MuleSoft MCP 连接器](https://docs.mulesoft.com/mcp-connector/latest/)允许将实施为 Mule 应用程序的任何 API 发布为 MCP 服务器。由于 _MuleSoft_ 为几乎所有主要企业系统(例如 SaaS、原有和数据库)提供了数百个预构建连接器,因此这会立即将组织的 API 和应用程序转换为一组客服人员就绪的工具。设计用于检查 SAP 库存的 API、在 Salesforce 中处理新潜在客户的流或通过 _MuleSoft_ 连接的自定义应用程序都可以作为使用 _MCP 连接器_的原子化受管工具提供给 AI 客服人员。
### **2.2 客服人员到客服人员协议 (A2A)**
虽然 _MCP_ 擅长层次结构、客服人员调用工具交互，但复杂的业务流程通常需要多个专业客服人员之间的协作。_客服人员对客服人员 (A2A)_ 协议是新兴的开放标准，旨在促进对等通信，从而实现复杂的多客服人员工作流。
MuleSoft 对 A2A 的支持允许企业设计和构建高级系统，其治理和可靠性水平与他们期望的 API 相同。[MuleSoft A2A 连接器](https://docs.mulesoft.com/a2a-connector/latest/)允许开发人员将任何客服人员轻松公开为 A2A 服务器，或从 Mule 应用程序调用任何符合 A2A 标准的客服人员。例如，抵押申请流程可能会跨“信用检查客服人员”、“文档签名客服人员”和“监管合规客服人员”进行编排，每个客服人员发现并调用其他客服人员的功能（根据需要）来推进申请。
通过为 MCP 和 A2A 提供强大的企业级工具，MuleSoft 支持构建灵活的生态系统，该生态系统由客服人员到系统的直接交互（通过 MCP 工具）和客服人员到客服人员 (A2A) 交互组成。无论 AI 环境如何发展，这种方法都将 _MuleSoft_ 定位为连接所有形式客服人员通信的基础。
## 3\.MuleSoft 客服人员结构：客服人员企业的中枢神经系统
随着企业采用客服人员 AI，不可避免地面临客服人员蔓延的挑战。为了防止这种情况演变成混乱，需要一个专用的编排层。[MuleSoft 代理结构](https://docs.mulesoft.com/agent-fabric/)([演示](https://www.youtube.com/watch?v=GAqwPie16ic))是一个全面的架构解决方案,旨在直接应对这一挑战。它提供了一个中央管理平面来发现、治理、编排和观察整个 AI 客服人员网络，无论他们在哪里构建或如何操作。_MuleSoft Agent Fabric_ 作为企业数字员工的"空中交通控制者 " , 将分散、孤立的客服人员集合转换为一个有凝聚力、安全、高性能的智能网络。
_MuleSoft 客服人员结构_构建于四个集成支柱之上，涵盖了客服人员作为一流企业资产的整个生命周期管理。
### **3.1 代理注册表（发现）**
任何受管生态系统的基础都是可发现性。_客服人员注册_表是企业中每个客服人员资产的通用集中目录。这包括自定义构建的客服人员、嵌入 SaaS 应用程序的客服人员、公开原有系统的 MCP 服务器以及客服人员之间协作的 A2A 端点。通过提供单一的真实来源，_客服人员注册_中心通过阻止团队构建冗余功能，并使人类开发人员和其他 AI 客服人员能够大规模动态查找和重用现有资产，从而解决了关键的发现问题。
_客服人员注册_表构建在 _Anypoint Exchange 上_，它添加了三种新的资产类型：客服人员、MCP 服务器和 LLM。它捕获有关这些资产的信息，包括 MCP 工具、传输协议和客服人员卡，以及客服人员和他们使用的 MCP 服务器和工具之间的依赖性。开发人员可以直接在注册表中创建和管理资产。在创建新编配时，他们还能够以编程方式发现和重用 MuleSoft Vibes 中的现有资产（通过 _MuleSoft MCP 服务器的_ search_asset 工具）。这为开发人员提供了理解和使用这些资产所需的所有信息。
### **3.2 代理经纪人（组织）**
一旦发现资产，就必须对其进行编排以执行有用的工作。_客服人员代理_是一个执行多步骤业务流程的编排服务。它使用可配置的 LLM 来解释高级任务并生成相应的工作流。_客服人员代理_人动态发现、排序并调用所需的客服人员和工具，以完成这些流程。
连接通过适用于工具的 _MCP_ 和适用于客服人员的 _A2A_ 协议进行管理。这允许系统将客服人员组织到特定于业务的域中（例如，供应链或财务），并在所有这些域中路由任务。单个自然语言提示（例如，“入职员工”）被分解为一系列离散的操作，这些操作由跨多个后端系统的不同客服人员或工具执行。客服人员经纪人编排包括：
- **动态编排模式：**这是客服人员循环模式，确定子任务，并在最合适的客服人员和工具之间编排它们，以实现总体目标。通过利用这种模式，可以构建[协作客服人员](/docs/architect/zh-cn/fundamentals/guide/agentic-patterns#15-协作客服人员客服人员群)来解决复杂的用例（例如，[处理复杂的服务](/docs/architect/zh-cn/fundamentals/guide/agentic-patterns#35-协作客服人员用例复杂服务升级)升级）。
- **LLM 支持的原因：**使用 LLM 来解释自然语言目标并生成执行计划，这就不需要硬编码的严格工作流逻辑。
- **可配置 LLM 模型：**允许开发人员指定使用哪个 LLM 模型，这提供了对成本、性能和功能的控制。
- **自然语言开发：**通过 _MuleSoft Vibes_，使用自然语言定义_客服人员代理_逻辑。
- **可观察性：**_Anypoint Monitoring_ 在部署时提供日志记录和跟踪，以帮助用户了解和调试客服人员代理的推理以及与 _MCP_ 工具和 _A2A_ 客服人员的交互。
- **受管部署：**_客服人员代理_是一个由 _Mule Runtime_ 支持的容器化应用程序，它管理部署的可用性和可扩展性。
### **3.3 MCP 和 A2A 的弯曲网关（治理）**
_任意点弯曲网关_是在技术上强制执行某些策略的机制。_MuleSoft 客服人员结构_利用 _Anypoint Flex Gateway_ 来[保护、检查](https://docs.mulesoft.com/gateway/latest/flex-agent-secure)和管理通过 _MCP_ 和 _A2A_ 协议发生的每个客服人员交互。这允许组织将丰富[的企业级策略](https://docs.mulesoft.com/gateway/latest/flex-agent-policies)应用于所有客服人员流量，以确保每个操作在执行前都是安全的、合规的和可审计的。要安全和负责任地扩大 AI 采用，这些防护措施至关重要。
| 保单名称 | 协议 | 描述 |
| :----------------------------------------------------- | :---------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **JWT 验证策略/客户端 ID 实施策略** | A2A、MCP | **JWT 验证策略/**客户端 ID 实施策略通过限制仅对经过身份验证的调用者的访问权限来保护 _A2A_ 客服人员和 _MCP_ 服务器。 |
| **模式验证** | A2A、MCP | **模式验证**确保传入客服人员请求符合 _A2A_ 或 _MCP_ 规范，从而防止格式错误的流量。 |
| **A2A PII 探测器** | A2A | **A2A PII 检测器**识别请求和响应中的_个人身份信息 (PII)_，并启用日志记录或阻止以满足合规性要求。 |
| **A2A 提示装饰器** | A2A | **A2A 提示装饰**程序将自定义上下文或指令注入发送到客服人员的提示，以指导他们的行为并实施防护。 |
| **基于 MCP 属性的访问控制** | MCP | **基于 MCP 属性**的访问控制根据用户属性（例如，等级、IP 或 JWT 声明）来规范对 _MCP_ 服务器公开的特定工具和资源的访问。 |
| **SSE 日志记录** | A2A、MCP | **SSE 日志**记录代理协议用于全面审计和可追溯性的_服务器发送事件 (SSE)_ 流的内容。 |
| **流量限制和峰值控制** | A2A、MCP | **速率限制和峰值控制**通过强制执行请求限制，保护后端客服人员和系统免受流量激增和拒绝服务攻击。 |
| **A2A 客服人员卡** | A2A | **A2A 客服人员卡**会重写客服人员卡 URL，以确保所有流量都通过受管的 Flex 网关实例正确代理。 |
**代理协议的企业治理策略**
除了管理入站请求之外，_Anypoint Flex Gateway_ 还管理从客服人员到外部服务（例如 _MCP_ 服务器和工具或其他客服人员）的所有出站连接和请求。这包括：
- **记录：**提供集中的可观察性点，以监控和记录所有出站客服人员请求，从而进行审计和故障排除。
- **安全性：**通过检查出站流量，防止敏感数据泄露。
- **身份验证：**通过应用出站身份验证机制（包括 API 密钥、OAuth 和 ClientId/ClientSecret），从单点管理外部系统的凭据。
当现成的策略不符合特定要求时，_Anypoint Flex Gateway_ [**Policy Development Kit (PDK**)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview) 允许用户创建自定义策略。通过使用 _PDK_，开发人员可以使用 _Rust_ 编程语言编写策略逻辑，并将其编译为 _Web Assembly (WASM)_ 模块。然后，将自包含模块加载到 _Anypoint Flex 网关_，以直接在 API 边缘强制执行唯一的安全规则、自定义数据转换或专用集成逻辑。这为独特或复杂的用例提供了扩展网关功能的强大高性能方式。
以下是 _PDK_: 的四个关键组件
- **Anypoint CLI PDK 插件：**此插件创建 _PDK_ 项目，并将编译的策略上传到 _Exchange_。它还生成了一个_Makefile_，通过提供一组清晰的命令来构建和管理策略，从而简化了开发过程。
- **策略模板：**创建新项目时，_PDK_ 会生成基本支架或模板。此结构包括成功编译策略所需的所有必需文件和配置，这为开发人员提供了自定义逻辑的起点。
- **SDK 构建工具：**这些工具抽象了基础_特使_代理的复杂、事件驱动的架构。通过使用反应器和执行器模式，_SDK_ 提供了一种直接的线性编码方法。这有助于降低复杂性，改进调试，并降低开发人员的学习曲线。
- **策略管理：**[MuleSoft MCP 服务器](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools)提供 _MCP_ 工具，帮助用户管理自定义策略生命周期。这些工具的示例包括：
- get_flex_gateway_policy_example
- manage_api_instance_policy
- manage_flex_gateway_policy_project
### **3.4 客服人员可视化器（观察）**
_客服人员可视化_器提供整个客服人员网络的实时动态地图，将可能是 AI 交互的"黑匣子"变成一个完全可观察的系统。架构师和运营团队可以使用 _Agent Visualizer_ 查看客服人员的连接方式，跟踪他们的决策流，监控他们的运行状况和性能，并确定依赖性。此可见性级别对于优化性能、高效故障排除、检测瓶颈和建立对已部署客服人员的信心至关重要。
## **4\.Salesforce 平台统一**
### **4.1 API 目录和主题中心**
_MuleSoft API目录_和_主题中心_旨在改进发现、使用和管理 API 的方式,特别是与 _Agentforce_ 结合使用。
通过 _Salesforce 平台_中的 [API 目录](https://help.salesforce.com/s/articleView?id=platform.api_catalog.htm&type=5)，所有设计和发布的 _MuleSoft_ API 都可以被发现和使用。_API 目录_用作集中存储库，它将组织的所有 API 从 _MuleSoft_、_Salesforce_、_Heroku_ 和其他云统一到一个视图中。这使得开发人员和管理员能够很容易地发现、理解和重用现有的API, 使这些API能够在自动化(例如,_Agentforce_、_Flow_和_Apex_)中使用。
Agentforce 的 [MuleSoft：主题中心](https://blogs.mulesoft.com/news/mulesoft-for-agentforce-topic-center/)允许开发人员在设计时定义 Agentforce **主题**和**行动**元数据，围绕具体的业务用例来构建他们的 API。这包括：
- **操作**，即客服人员可以执行的任务
- 指导客服人员如何应用特定操作的**说明**
通过[添加语义层](https://docs.mulesoft.com/anypoint-code-builder/ai-enabling-api-project-topic-center),_主题中心_使 API 可被 _Agentforce_ 理解和使用,从而确保它可以有效地与企业系统进行交互。
### **4.2 Agentforce 网关**
_Agentforce 网关_是一个集中的治理层,旨在管理和保护不断扩大的 _Agentforce_ 生态系统内的互动。由于 _Agentforce_ 通过 _MCP_ 等协议与其他第三方 API 和工具集成,_Agentforce 网关_的主要功能是对 _Agentforce_ 发起的所有出站流量强制执行策略(例如,速率限制和工具限制),并审计所有出站请求。
_Agentforce 网关_利用现有的 _MuleSoft_ API 治理策略引擎,该引擎本地内置于 _Salesforce 平台_中。此基_于特使_的策略引擎拦截客服人员流量，应用配置的策略(例如，基于属性的访问控制和配额限制),并管理身份验证和授权,所有这些都不需要客户安装额外的网关基础设施。
### **4.3 集成智能**
部署受管客服人员网络是一项里程碑式的成就。但是，它引入了新的“第 2 天”运营挑战。它需要增强的运营智能级别来监控、测量和排除自主行为者的动态分布式系统。最终的架构愿景是一个系统，其中 AI 不仅用于执行业务流程，而且还用于监控、管理和修复它所运行的基础设施。
_MuleSoft 的_集成智能愿景利用更广泛的 _Salesforce_ 生态系统的强大功能，为集成结构和代理网络的性能提供深入、可定制的见解。通过在 **Salesforce Data 360** 中捕获和存储 [OpenTelemetry (OTEL) 合规](https://opentelemetry.io/)数据(新出现的可观察性标准 ) , 组织可以为整个环境中的日志、度量和跟踪创建统一存储库。此数据可通过预构建仪表板和自定义可视化在 **Tableau** 中查看，以获取有关 API 性能、客服人员交互模式和整体系统运行状况的详细见解。
该系统有三个关键组件：
1. **摄取：**接收服务是从各种 _Mule_ 应用程序、_客服人员代理_人和 _Flex Gateway_ 收集和处理遥测数据的集中入口点。它执行模式验证、数据规范化和筛选，以保持各种应用程序的数据质量和一致性。此外，它在接收漏斗中强制执行控制（例如，身份验证、加密、租户公平和速率限制）。
2. **存储：**高吞吐量流作业在 _Data 360_ 中运行，从多租户 _Kafka_ 主题中读取数据，并将其转换为 _OTEL_ 格式。然后，OTEL 数据被提交到租户在 _Lakehouse_ 的 _TelemetryTraceSpan_、_TelemetryLogs_ 和 _TelemetryMetrics DMO_ 中的 _Data 360_。
3. **可视化/消耗：**借助 _Data 360_ 提供的遥测数据,客户可以通过 _Tableau Next_ 使用预构建或自定义仪表板查看系统运行状况并获取见解。客户还可以利用 [Tableau Concierge](https://help.salesforce.com/s/articleView?id=analytics.tua_metric_questions.htm&type=5),这是 _Tableau Next_ 中预构建的代理分析技能,允许用户以自然语言提出有关遥测数据的问题，并通过可视化获得可信、可操作的答案。客户也可以将数据导出到现有的_应用程序性能管理 (APM)_ 系统(例如 _DynaTrace_、_Datadog_、_Splunk_ 等)。
## **结论**
向 Agentic Enterprise 的过渡不仅仅是 IT 升级，还是一个基本的架构转折点。AI 客服人员的分散、孤立部署是导致运营混乱、影子 IT 和无法管理的技术债务的直接途径。唯一可持续的前进道路是通过统一的可组合架构。_MuleSoft Agent Fabric_ 建立在 API 引导的连接的成熟基础上,提供了管理这些新数字员工所需的"中枢神经系统 " 。它提供了发现、编排、企业级治理和端到端可观察性的关键功能。这就是我们如何超越 AI 实验,开始构建真正智能、自动化和安全的企业,将自主潜力转化为有形、有管理的业务成果。
## **技术指南和参考**
- [开始使用 Anypoint 代码生成器](https://docs.mulesoft.com/anypoint-code-builder/start-acb)
- 适用于 Anypoint 代码生成器的 Einstein [技术指南：生成流](https://blogs.mulesoft.com/dev-guides/einstein-for-acb/)
- [DataWeave 生成式转换深入挖掘：适用于快速数据转换](https://blogs.mulesoft.com/dev-guides/dataweave-generative-transformation/)的 AI 创新
- [使用 MuleSoft 开发人员创建 API 规格](https://docs.mulesoft.com/anypoint-code-builder/api-ai-create-spec)
- [使用 Einstein 生成式 AI 生成 API 文档](https://docs.mulesoft.com/exchange/generating-documentation-with-ai)
- [MuleSoft MCP 服务器概览](https://docs.mulesoft.com/mulesoft-mcp-server/)
- [MuleSoft MCP 服务器工具](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools)
- [MCP 连接器](https://docs.mulesoft.com/mcp-connector/latest/)
- [A2A 连接器](https://docs.mulesoft.com/a2a-connector/latest/)
- [开始使用客服人员结构](https://docs.mulesoft.com/agent-fabric/learning-map-agent-fabric)
- [使用 Flex 网关保护客服人员交互](https://docs.mulesoft.com/gateway/latest/flex-agent-secure)
- [灵活网关客服人员策略](https://docs.mulesoft.com/gateway/latest/flex-agent-policies)
- [灵活网关策略开发工具包 (PDK) 概述](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)
- [适用于 Salesforce 的 MuleSoft API 目录](https://help.salesforce.com/s/articleView?id=platform.api_catalog.htm&type=5)
- [为主题和客服人员操作启用 API 项目](https://docs.mulesoft.com/anypoint-code-builder/ai-enabling-api-project-topic-center)
- [使用 Tableau Next](https://help.salesforce.com/s/articleView?id=analytics.tua_consume.htm&type=5)
- [OpenTelemetry](https://opentelemetry.io/)
- [模型上下文协议](https://modelcontextprotocol.io/docs/getting-started/intro)
- [Agent2Agent (A2A) 协议](https://a2a-protocol.org/latest/)
## 关于作者
Nikhil Aggarwal 是 Salesforce 的首席架构师，负责 MuleSoft 和 Salesforce Automation Cloud 的架构。Nikhil 拥有超过 18 年的大规模产品交付经验，并热衷于可扩展架构、直观的开发人员体验和构建高性能团队。在加入 Salesforce 之前，从概念到发布，他在 Microsoft Power Platform、Dataverse 和 Office 365 中领导了多项计划。他的工作继续塑造现代企业如何在 AI 优先时代连接系统、自动化工作流并释放业务价值。
# 其他资源入门
本节介绍了如何在 Salesforce 平台功能（包括流、Apex 和相关工具）中应用最佳实践和设计模式。
## 基于步骤的异步框架
## 其他资源
[基于步骤](/docs/architect/zh-cn/fundamentals/guide/step-based-async-framework)的 Aysnc 框架是一个处理框架，用于运行具有任意数量步骤的异步作业。本文涵盖了每个架构师必须掌握的三个重要领域：
- **计划和调用**:使用计划流和可调用 Apex 通过环境检查和故障处理来编排、触发和控制执行。
- **步骤设计和灵活性**:定义可重复使用的步骤界面，支持 Apex、流、基于光标的处理和可配置模式，例如功能标记和无操作步骤。
- **编排和执行引擎**:利用步骤处理器，通过集中日志记录和生命周期控制对步骤进行排序、执行、重试和管理。
本文为 Salesforce 提供了可扩展的、基于步骤的异步框架，该框架将复杂的流程分为模块化、独立执行的步骤，具有集中的编排、日志记录和高用量性能。
## Salesforce 数据同步
[基于步骤](/docs/architect/zh-cn/fundamentals/guide/data-synchronization)的 Aysnc 框架是 Salesfore CRM Analytics 的核心功能部分。它是生态系统的原生商业智能平台，适用于交互式仪表板和 AI 驱动的见解，通过两个核心功能促进与外部系统的无缝双向数据移动：SyncOut 和 SyncIn。CRM Analytics SyncOut 将 Salesforce 对象数据推送到外部平台，支持完整和增量变更数据捕获 (CDC) 模式，以及内置的硬删除跟踪，以保持下游的绝对数据完整性。完成循环后，CRM Analytics SyncIn 将外部数据拉回 Salesforce 对象，利用批量 API 2.0 可靠高效地接收大量数据集，以便立即投入使用。本文档以 Snowflake 为具体工作示例，解释了模式的工作方式、何时使用以及如何开始。
## Salesforce 数据虚拟化
[基于步骤](/docs/architect/zh-cn/fundamentals/guide/data-virtualization)的 Aysnc Framework 是一种集成架构模式，它使 Salesforce 能够在运行时直接从外部系统查询数据，而无需将数据复制或复制到 Salesforce 存储中。它使 Salesforce 能够在运行时直接在源位置查询数据，而无需复制。用户通过标准 Salesforce 界面查看实时外部数据。数据从不离开其权威主页。本文档以 Snowflake 为例，解释了模式的工作方式、何时使用以及如何开始使用。
## Field Service 的架构模式：大规模优化承包商共享和可见性
Field Service 的[架构模式：优化大规模](/docs/architect/zh-cn/fundamentals/guide/field-service-contractor-sharing-patterns)承包商共享和可见性比较了在 Salesforce Field Service 中管理外部承包商网络的两种架构模式：**基于区域共享**和**基于客户共享**。本指南涵盖：
- **承包商角色**:命名承包商、承包商公司和临时工，以及每个角色如何构建适当的共享架构。
- **基于区域的共享**:使用专用服务区域作为主要安全边界，以及这种方法在可扩展性方面的权衡。
- **基于客户的共享**:使用基于条件的共享规则将可见性与地理位置分离，从而在合同工和内部技术人员之间实现统一资源池。
- **决策框架**:决策树和比较矩阵，用于根据竞争重叠和地理排斥性选择合适的模式。
帮助架构师平衡平台安全性与计划性能，同时构建可通过 Agentforce 和 Data Cloud 扩展的基础。
# 利用 MuleSoft 和 Informatica：“更好地在一起”
本文档为使用 MuleSoft 和 Informatica 进行实时应用程序连接和数据管理框架。
## 实时应用程序连接和数据管理框架
## 概览
MuleSoft 和 Informatica 为现代高性能集成策略提供了基础支柱。虽然两者都位于同一个生态系统中，但它们解决了不同的架构挑战。领先的企业会同时部署这些平台，以创建一个全面的“一起更美好”框架，满足全方位的数据和应用程序需求。
最敏捷的组织通过将数据管理与应用程序连接分离而取得成功。MuleSoft 和 Informatica 是专业合作伙伴。MuleSoft 通过基于服务的架构提供安全、高性能、交互式的应用体验，而 Informatica 则大规模确保数据完整性、质量和治理。架构师利用两者将正确的引擎应用于正确的集成模式，从而优化性能和长期可扩展性。
## 范围内的产品
 |
MuleSoft 是 Salesforce 领先的集成平台。它使组织能够跨本地和云环境连接应用程序、数据和设备。MuleSoft 为 IT 提供了跨系统解锁数据、开发可扩展集成和自动化框架以及快速创建差异化互联体验的工具。 |
 公司 |
Informatica 是领先的企业数据管理和集成平台。它帮助组织收集、管理、集成和分析来自不同来源的数据。它使用 ETL（提取、转换、加载）流程来提供连接、可靠的数据，这是支持现代分析和自主 AI 客服人员所必需的。 |
以下部分展示了 MuleSoft 和 Informatica 如何在关键基础支柱（集成、数据管理以及客服人员编排和治理）之间协同工作。
### 集成：桥接应用程序和数据竖井
对于每个现代企业，成功的运营依赖于集成应用程序和数据平面。应用程序集成和数据集成平台是互补的，而不是可互换的。试图利用一个而不利用另一个会产生运营盲点和瓶颈。
孤立集成方法的缺点是显而易见的。
**1\.没有强大的数据治理**的应用程序集成
连接应用程序或应用程序集成允许企业跨系统快速移动流程和事务。但是，如果该执行层缺乏基础数据的统一、受管和可信视图，则无论速度如何，产生的操作都将基于零散、不一致或过时的信息。
组织可以快速编排流程，但没有可信的数据，决策仍然具有高风险。不一致的客户互动、库存管理和财务报告源于缺乏“单一的真实来源”，导致效率低下和监管风险。
MuleSoft 通过为高度监管的行业提供现成的合规性来降低这种风险，它携带有效的认证，包括 FedRAMP、ISMAP、hitrust、SOC 1/2/3 和 ISO 27001。但是，即使应用层安全地通信，它仍然可以共享不一致的数据。
**2\.没有敏捷应用程序集成**的数据集成和管理
确定数据集成和管理平台的优先级（特别是通过强大的数据仓库或主数据管理 (MDM) 系统）对于清理、标准化和统一数据至关重要。这些平台创建了单一的真实来源：客户、产品或供应商等实体的可靠、整体视图。
虽然数据是干净、整合和可信的，但将其派生智能注入实时业务流程和面向客户的应用程序的机制缓慢或不存在。如果没有应用程序集成，企业就无法将单一的真实来源转化为实时行动。高质量的数据位于后台，无法影响即时的销售决策、个性化的服务交互或关键的供应链调整。情报已存在，但操作漏斗仍被堵塞。
**整体解决方案：MuleSoft 和 Informatica 合作**
MuleSoft 和 Informatica 为数据驱动的业务运营提供了行业领先的统一框架。
这种架构一致性确保：
* **实时操作**:MuleSoft 提供了灵活的机制，通过安全的 API 公开这些受信任的数据。通过 API 引导的连接，它将 Informatica 的单一真相来源直接集成到关键业务应用程序和流程中。这允许企业基于 Informatica 提供的单一真相来源实时采取行动。
* **受信上下文**:作为云数据管理领域的领导者，Informatica 确保流经企业的数据干净、一致、受管和合规。它通过掌握数据、启用质量保证和促进企业数据治理来创建可信的上下文。
##### “数据到客服人员”的时刻
这种集成使客户能够拥有数据到客服人员的时刻。这是最终目标：当员工（客服人员）或自动化系统必须采取行动时，系统会立即提供成功所需的完整、可信和实时的环境。这种强大的协同作用将数据从纯粹的历史资产转化为动态、可操作的情报流，从而推动卓越的业务结果和竞争优势。
#### 适用于应用程序集成的 MuleSoft
MuleSoft 提供了 AI 支持的端到端集成生命周期。通过 MuleSoft Vibes，开发人员可以使用自然语言提示来设计 API、构建集成和生成单元测试。该平台支持任何 IDE 中的开发，包括光标或 VSCode，并使用本地 MCP 服务器加速交付。
该架构以可扩展连接为中心：连接 AI 客服人员、SaaS 应用程序、传统系统和合作伙伴的通用桥梁。该单一平台确保任何资产都可以实时支持业务，无论资产位于何处。
没有监督的连接会产生风险。因此，我们允许团队注册、保护和观察每个资产和应用程序。通过提供全面的 AI 工具集，我们为 IT 提供了可见性和防护措施，以完全自信地管理应用程序生命周期。
MuleSoft 还通过 Enterprise B2B 和 EDI 支持更广泛的生态系统。这种集成简化了合作伙伴管理，同时保持了端到端的合规性。
最终，MuleSoft 确保企业的每个部分不仅相互连接，而且得到治理和准备实时采取行动。
#### 适用于数据集成的 Informatica
业务速度需要 Trust 的基础。Informatica 确保企业根据可信的高质量数据采取行动，避免快速但不可靠的见解带来的负担。
Informatica 平台可以将原始数据转换为企业就绪的资产。其低代码环境便于在不增加人员的情况下即时扩展。通过 300 多个预构建的连接器，支持所有集成样式，包括 ETL、ELT 和反向 ETL，它可以为 AI 驱动的计划集成、管理和准备几乎任何现有数据。
### AI 的可信数据管理基础
Informatica 是数据管理的引擎，是 AI 成功的关键。它提供了从目录到治理的完整功能套件，将组织从数据丰富转变为见解驱动。
AI 只与为其提供数据的数据一样有效，对于大多数组织，这些数据是孤立的、重复的和不一致的。这代表了一个重大风险，因为“脏”数据会导致不可信的 AI 输出。
这是 Informatica MDM 的长处。我们不仅仅连接数据，而是统一它。它打破相互脱节的孤岛，创建客户、产品和供应商的 360 度视图，建立单一、可信的真相来源。这种统一视图允许团队自信地做出 AI 驱动的决策，而无需辩论数据准确性。
Informatica 对于启动 AI 和在整个企业中扩展可信 AI 基础至关重要。
最重要的是，Informatica 已经自动完成了繁重的工作。通过 CLAIRE GPT，该平台简化了匹配、合并和治理流程。这以 Lightning 的速度为客户提供单一的真实来源，同时消除了手动工作。
实现单一真相来源是第一步。随着数据流入分析、应用程序和 AI，CDO 和 CIO 面临一个关键问题：我们能否真正Trust这些数据呢?
在 AI 时代，数据治理和质量至关重要。它们必须是自动化的和内在的内置功能，这正是 Informatica 设计提供的功能。Informatica 嵌入了一层 Trust,确保数据在到达仪表板或 AI 模型之前准确合规。
Informatica 不仅跟踪数据，而且跟踪谱系，精确显示其来源和访问历史，以树立对其可靠性的信心。这种确定性是大规模运作所必需的。
最终，Informatica 将元数据与业务上下文联系起来。当客户启动 AI 项目时，他们不仅仅是在快速移动，而是在绝对确定地移动。
### 解锁客服人员企业
MuleSoft 和 Informatica 提供了互补的客服人员功能。MuleSoft 客服人员结构充当统一控制平面，提供端到端的治理、编排和可观察性。Informatica 的数据代理和 MCP 服务器插入该交换矩阵，提供可信的数据访问和受管的数据操作，例如将 MDM 数据或目录元数据馈送到生态系统。
它们共同允许客户无缝扩展他们的投资。为了在企业级运营这个集成的生态系统，MuleSoft Agent Fabric 提供了一个系统的四支柱框架：
1. **发现：**全面了解客服人员生态系统。客服人员注册表和内置扫描仪会自动同步和编目每个 A2A 客服人员和 MCP 服务器，包括 Informatica 资产和来自 Amazon Bedrock 或 Google Vertex 的外部客服人员，确保即时发现和重用。
2. **编排：**协调客服人员和 API，以执行复杂工作流。客服人员经纪人将任务动态路由到正确的客服人员或工具，消除了手动切换，并将分散的单个客服人员转变为可靠、协调的员工。
3. **治理：**将安全的、策略驱动的控制应用于每个交互。受信客服人员身份和 Flex Gateway 在三个级别强制执行合规和访问控制：端到端交互、模型层 LLM 请求和执行层操作。
4. **观察：**实时跟踪客服人员推理、绩效和协作。客服人员可视化器和集中监控提供了完全的透明度，允许 IT 团队验证决策、检测异常并优化客服人员结果。
MuleSoft 的控制平面和 Informatica 的数据代理的集成为受管实时操作提供了统一的框架。通过将敏捷编排锚定在可信上下文的基础上，这种协同作用为代理企业提供了动力。
## 了解有关 MuleSoft 和 Informatica 的更多信息
要构建弹性的客服人员企业，组织必须超越将数据集成和应用集成视为孤立的工作。通过利用 Informatica 治理高用量数据资产，利用 MuleSoft 编排实时应用程序和客服人员工作流，企业建立了安全、可扩展的基础。
探索每个平台的专用资源，以加深您的理解。要了解有关实时应用程序连接、API 引导的集成和适用于 AI 编排的 MuleSoft 客服人员结构的更多信息，请浏览官方 [MuleSoft](https://www.salesforce.com/mulesoft/) 产品页面。有关数据管理、治理和主数据管理 MDM 功能的全面详细信息，请访问 [Informatica](https://www.informatica.com/salesforce.html) 资源中心。您将找到每个平台功能的详细规范，这将帮助您将正确的架构映射到特定的环境。
# 概览
现代 Salesforce 架构越来越多地由异步处理提供支持；异步处理不是为了方便，而是规模的战略要求。近年来,我们看到越来越多的公司面临着数据量激增、涉及多个接触点的复杂集成以及全天候运行的自主系统的兴起等问题。所有这些因素都推动架构师设计异步优先的系统。
Salesforce 上的异步处理通常意味着围绕调控器限制和复杂性进行设计。这些限制充当防护栏和架构约束，有助于生产批量安全的、可扩展的系统。虽然没有平台限制直接用于管理复杂性，但[设计模式](https://refactoring.guru/design-patterns)可以帮助降低这方面的风险。在内部，Salesforce 通常会推动平台向前发展，以测试新功能并自动化复杂的业务流程。我们构建了一个基于步骤的异步处理框架，用于运行具有任意数量步骤的异步作业。通过集中日志记录，每个步骤都可以独立运行、重试和重新启动，并具有共享治理控制和完全操作可见性。本文档概述了其主要架构组件：可排队 Apex 和最终确定器、计划流、Apex 光标、可调用操作以及与 Slack 的集成。这些组件共同提供了一个适合不断发展的业务需求的模块化、可扩展和可观察的架构。
## 重要外卖
- 现代 Salesforce 架构应采用异步优先的方法，以实现规模、弹性和运营透明度。
- 将复杂工作分解为独立可执行的步骤可实现可预测的性能、更安全的重试、检查点、回滚和模块化演进，而无需重新设计核心工作流。
- 该框架提供了对整体式和老化批处理作业、链式异步调用和深度嵌套流的可扩展替代方案，并专为必须在 Salesforce 中水平扩展而没有平台外编排的高用量工作负载构建。
- 确定性和可观察的执行通过集中的日志记录和治理来确保进度跟踪、SLA 监控、故障诊断和审计级透明度。
- 设计用于企业级严格性，包括跨长时间运行的业务流程的统一治理、合规性和分布式状态控制。
## 平台最佳实践
在查看要求之前，以下是何时使用类似框架的一些注意事项。首先，请考虑哪个系统是真理的唯一来源。如果您的 Salesforce 组织对外部数据的依赖最少，但需要从数百条记录扩展到数百万条记录，请考虑基于步骤的异步框架。
如果满足以下条件**，请**使用此框架：
- 大部分（或所有）要处理的信息已经存在于您的 CRM 中。
- 维护提取转换加载 (ETL) 作业以协调外部数据的前期或持续成本太高。
- 您需要推迟按既定计划处理大量 Salesforce 记录。
- 您可以将处理分解为离散的步骤。例如，您可以创建一组层次结构或基于树的记录，特别是如果数据量向下扇出层次结构或树。
如果出现以下情况**，请勿**使用此框架：
- 创建或更新记录需要立即重新计算。
- 集成具有挑战性，因为外部系统托管记录更新的主要数据。（考虑使用批量 API 将更新的数据推送到 Salesforce。）
请记住这些实践，让我们回顾一下我们的要求并开始构建。
## 细分要求
考虑问题陈述：
> 给定需要每天运行的作业，请检查某些记录是否满足预先建立的标准，以便进一步处理。如果是，则启动这些处理作业。处理记录可能意味着从多个外部系统提取数据以执行计算。作业中的步骤应通过 Slack 通知人员已处理记录已准备好进行审核。步骤还应根据第一轮通知后的可配置延迟，将通知上报到角色层次结构中的经理和上级。
此问题涉及几个不同的步骤，其中一些步骤可以相互独立发生。拆分工作有很多方法。以下是一组：
- 计划程序。
- 处理记录的步骤界面和具体实施（无论处理类型如何）。
- 组织步骤的处理器。
- 计划程序调用的 Apex 可调用。
- 通知部分。我们使用 [Apex Slack SDK](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/guide/overview.html)。
- “可配置的延迟”短语隐藏着一些复杂性。我们将在本文后面回顾这种复杂性。
以下是构建框架的意见图：
现在，分解该图表，并开始构建各个部分。
## 使用计划流计划
计划流作为计划机制提供了几个优势：
- 计划流可以打包并部署为元数据。对于通过 Apex（或通过计划作业页面）计划的作业，情况并非如此。
- “等待”元素对于需要标注的框架至关重要。通过在流中使用它，在框架的可调用部分中不需要标注。
- 计划粒度满足要求：计划流的最小间隔是每天。如果您需要更高的频率（例如每小时），请重新考虑此要求的计划流。
配置计划流时的另一个注意事项是环境门控。在调用 Apex 操作前，添加评估`{!$Api.Enterprise_Server_URL_100}`变量的决策元素。这确保了作业仅在预期的环境中运行，例如 UAT 和生产。这种模式很重要，因为 Sandbox 在 SDLC 期间经常刷新或新创建，如果没有明确的环境检查，计划流可能会无意中在框架不打算运行的环境中执行。在决策元素中使用 `contains` 运算符会使设置适应未来的 Sandbox 创建或 URL 更改。
最后，考虑框架应如何捕获失败。在流调用任何操作时，请始终添加错误路径；例如，您可以将错误连接到 [Nebula Logger 的](https://www.nebulalogger.com/)“添加日志条目”操作。星云日志记录器将日志写入自定义对象，因此客户应了解日志数据会消耗组织存储 — 默认情况下，日志会在组织中存储 14 天，然后进行清理；此保留期可配置。星云日志记录器还使用平台事件发布日志，因此日志条目独立于主要数据处理事务保存 — 这将确保捕获失败，即使主要流或 Apex 操作回滚。在考虑添加日志记录框架时，客户应评估预期的日志量和保留要求。
以下是流的外观：
现在，让我们继续讨论 Apex 代码的第一部分，满足计划要求。
## 创建步骤界面
定义`Step`界面：
```java
public interface Step {
void execute();
void finalize();
String getName();
Boolean shouldRestart();
}
```
对于本文，为清楚起见，`step`界面显示为外部类。框架本身是灵活的 — 只要所有步骤类引用相同的界面，团队就可以使用他们喜欢的任何 Apex 打包模式来组织界面及其实施。
关于在我们的界面中定义的方法，有一些需要注意的事项：
- `execute` 目前虽然没有参数，但在我们传递`State`类(或接口)以在顺序重要时在步骤之间编排数据时有所改进。
- `getName` 可以返回`System.Type`值，而不是`String`。目标是为编排层提供一种在不公开其他属性的情况下记录步骤名称的方法。
以下是第一个具体实施，显示了这些组件如何相互配合。除了稍后的一个例外,我们建议使用可排队 Apex 在 Apex 中实施异步处理;批量 Apex 通常是不必要的(不鼓励使用`@future`方法)。Queueable Apex 启动迅速，通过 Apex 光标，与批处理 Apex 相比有许多优势。
### Apex 类似光标的实施
[Apex 光标](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cursors.htm)为传统的批量 Apex 模型提供了现代替代方案。与批处理相似，光标实施可以分块获取记录（每批最多 2,000 条）。但是，光标允许在单个事务中进行多次提取，从而为大批量操作提供了更高的吞吐量。
当将光标作为此框架的一部分时，团队应该了解当前的测试和可模拟性限制。测试中的光标行为可能与生产行为不同，因此重要的是设计测试策略，避免依赖光标内部，而是在边界处验证编排逻辑。随着平台的发展，这些领域将继续改进，但核心指导仍然是：与批处理 Apex 相比，光标在许多用例中提供了更高的性能和更低的编排开销。
要定义系统提供的光标和您自己的代码之间的明确边界，我们建议在实施`Step`界面时创建类似光标的表示。考虑以下代码：
```java
public inherited sharing abstract class CursorStep implements Step {
private static final Integer MAX_CHUNK_SIZE = 2000;
protected Cursor cursor;
private Integer chunkSize = System.Limits.getLimitDMLRows();
private Integer position = 0;
protected abstract Cursor getCursor();
protected abstract void innerExecute(List