客服人员根据目标进行推理，从上下文推断参数，并动态选择操作。因此，客服人员接触的每个集成都必须处理模糊性，支持安全的重复，并以客服人员可以自主恢复的方式失败。

代理系统使一些传统集成设计视为理所当然的假设无效。输入并不总是格式良好。单个用户操作可能会跨组织边界产生一系列客服人员，其中每个客服人员都需要授权才能操作。

本文档描述了从该现实中产生的架构变化：新的设计原则、代理模式以及 Salesforce 平台如何交付它们。

本文档中的每个模式遵循相同的结构：

名称:表示模式中包含的集成类型的模式标识符。

上下文:模式解决的整体集成场景。上下文提供有关用户尝试实现什么以及应用程序如何满足其需求的信息。

问题:模式旨在解决的挑战（以问题表示）。查看模式时，请阅读本节，以快速了解模式是否适用于您的集成场景。

部队:使问题难以解决的约束和环境。

Salesforce 模式应用程序:将模式应用到场景的推荐方式。

素描:统一建模语言 (UML) 序列图，显示模式应用程序如何处理场景。

结果:模式如何解决与场景关联的力量。本节还包含应用模式后可能出现的新挑战。

**设计注意事项：**正确应用解决方案的与平台无关的指导，然后是特定于 Salesforce 的实施说明。这些注意事项涵盖了操作设计原则和特定于平台的配置要求。

**错误处理和恢复：**在模式应用期间管理失败的指导。此参数涵盖四个区域：

• 操作如何通过结构化的可操作错误响应向客服人员传达失败，从而为下游决策提供足够的上下文
• 客服人员如何确定重试、自我更正或停止执行
• 补偿操作如何解决部分结果和不匹配的跨平台状态
• 停用写入操作的幂等要求

**安全注意事项：**安全应用模式的安全要求。这些注意事项包括凭据管理、集成用户和连接的应用程序的最低权限范围、客服人员调用操作的审计日志记录，以及来自用户提供或 LLM 推断内容的参数的输入验证要求等。

**示例：**一个端到端的场景，描述了如何在真实世界的 Salesforce 场景中使用设计模式。该示例解释了目标以及如何应用模式来实现这些目标。

下表列出了涵盖的实施模式。

模式列表

本文档中的模式分为三个类别。这种分类有助于架构师快速识别哪些模式与他们正在解决的集成挑战相关，无论他们是在设计客服人员调用的内容、什么触发客服人员，还是在客服人员采取行动之前如何以 Knowledge 为基础。您可以直接导航到与您的设计关注相匹配的类别，而不是阅读每个模式。

操作调用：

这些模式涵盖了客服人员如何调用外部系统检索数据或作为其推理周期的一部分执行操作。这些是出站模式，其中客服人员是启动器。它们解决了顺序（当步骤相互依赖时）、并行性（当它们不相互依赖时）、幂等性和部分失败处理。在设计客服人员将调用以完成工作的工具时，使用这些模式。

客服人员调用：

这些模式解决了外部系统或事件如何将客服人员带入操作的问题。这些是外部系统触发这些客服人员的入站模式。触发器可以是面向人的应用程序进行编程调用并等待响应，也可以是触发客服人员的自主数据条件。在设计如何以及何时触发客服人员时，使用这些模式。

围绕 Enterprise Data：

此类别的模式涵盖了客服人员在原因或行为前如何基于特定于组织的准确、最新 Knowledge。

选择正确的策略并非易事。每个模式都针对特定的关注点：系统功能、数据量、故障处理和事务性。

选择矩阵表列出了模式及其关键方面，以帮助您确定哪个模式最适合您的集成要求。使用这些维度对模式进行分类。

此表列出了模式及其关键方面，以帮助您确定在从 Salesforce 集成到另一个系统时哪个模式最适合您的要求。

模式的每个部分描述了如何构建它们。每个模式都是代理架构中特定集成问题的可重复解决方案。它涵盖了何时使用模式、形成决策的因素以及 Salesforce 平台如何交付决策。

上下文

许多业务工作流本质上是顺序的 - 每个步骤都需要上一个步骤的验证结果，然后才能继续。例如，在确认资格之前，不能启动退款；在订单记录存在之前，不能创建开单客户；在检查通过之前，不能记录合规检查。

在传统自动化中，这些依赖性被编码为硬编码流逻辑。在客服人员系统中，客服人员会评估每个操作的结果，并确定是否满足下一步的先决条件。

此模式描述了基本的出站集成模型。在这里，一个客服人员在一个域中操作并调用一个序列，其中每个操作的输出都会阻止调用链中的下一个操作。编配客服人员维护整个链的事务上下文，累积标识符、状态代码和每个步骤返回的数据。它使用此上下文来推动后续决策。

此模式是集成模式指南中远程流程调用 – 请求和回复的代理对应项，该指南描述了单个同步标注。客服人员模式将模式扩展到单个推理周期内客服人员驱动的依赖调用链。

问题

当客服人员执行跨主机系统和一个或多个远程系统的多步骤工作流时，必须解决四个挑战：

• 顺序 - 必须以正确的顺序调用操作，每个步骤都会在上一个步骤成功完成时关闭。
• 数据传播 - 每个步骤的响应数据必须作为输入传递到下一个步骤。
• 故障隔离 - 链中的任何一点故障都不得在系统之间产生部分或不一致的状态。
• 完成验证 - 客服人员在报告结果之前必须确认所有步骤已成功完成。

武力

应用此模式时，请回答以下问题：

• 链中的每个操作是否取决于前一个操作返回的数据，或者依赖性是否仅取决于成功或失败状态？

  数据依赖性要求客服人员跨步骤携带标识符和属性。

• 是否所有远程端点都能够在客服人员的推理周期超时内响应？

  在链中的任何步骤，缓慢的外部系统都会阻止整个顺序。

• 该链是否需要端到端的完整成功，或者部分完成是否可接受？

• 如果需要完全的端到端成功，请为发生下游故障时需要回滚的步骤定义补偿策略。

• 是否可以安全地重试链中的任何写操作？

  所有写入操作必须幂等；由于大语言模型 (LLM) 重试或不明确的确认，客服人员的推理循环可能会多次调用相同的操作。

• 链是由用户交互（会话、低并发）还是由自动触发器（潜在高并发）调用？

  这决定了同步阻止是否可接受，或者是否需要异步模式。

Salesforce 模式应用程序

草图

顺序操作调用的顺序图

结果

客服人员将跨系统工作流执行为一个连贯的、受监督的顺序，而不是一个“一失足”的脚本。在调用下一个步骤之前，会评估每个步骤的结果，因此客服人员会在最早的时间点检测失败，而不是事后发现部分完成。

主机系统 (Salesforce CRM) 仅在远程操作确认状态（成功或失败）后更新。外部系统返回的标识符和状态（例如开单帐号、交易 ID、确认代码）通过链传播并保留，从而创建工作流结果的完整、可跟踪的记录。

客服人员负责对结果进行推理，并对决策进行排序。每个操作只负责自己的操作和返回结构化结果。这两层都不编码另一层的逻辑。

设计注意事项

与平台无关的指导

• 确保链中的每个操作都带有以基于意图的语言编写的语义描述，而不是作为技术方法签名。客服人员根据这些描述选择操作。显示“调用开单 API”的描述不如显示“在开单系统中创建开单帐户并返回新帐户标识符”的描述有用。
• 使链中的所有写操作幂等。如果收到不明确的响应，客服人员的推理循环可能会重试操作。该操作必须在重复调用时产生相同的结果。
• 在操作边界防御性地验证所有 LLM 推断的输入参数。请勿假设客服人员传递的参数格式正确、在范围内或属于预期类型。
• 为单个责任设计每个操作。在同一呼叫中创建开单客户并发送确认电子邮件的操作比两个离散操作更难重试、更难测试，客服人员也更难进行推理。

Salesforce 实施说明

• 对于 Apex 操作，用 @InvocableMethod(label=’…’ description=’…’) 注解。客服人员读取“描述”以确定何时调用操作。使用描述性“标签”和“描述”字段，使用 @InvocableVariable 声明所有输入和输出变量。返回带有明确成功/失败指示符和人类可读错误消息的结构化结果对象。
• 对于流操作，仅使用自动启动的流；自主客服人员上下文不支持屏幕流。保持每个流原子化；一个操作，一个责任。在每个外部标注元素上配置错误路径，以捕获集成错误并向客服人员返回可操作的错误消息，而不是让未捕获的异常终止会话。
• 对于外部服务,导入目标系统的 OpenAPI 规范,并在 Agentforce 主题中注册生成的操作。在命名凭据中封装生成的存根，以避免在操作定义中对端点或凭据进行硬编码。
• 对于所有外部标注，设置显式标注超时。在没有超时的情况下挂起的标注将阻止客服人员的推理周期，直到达到会话限制。当超过超时时，返回带有描述性错误消息的异常失败。所有外部标注的可配置超时最多为 120 秒。它们还受 Apex 同步事务调控器限制，因此请确保降低实例化 50 个以上运行时间超过 5 秒的事务的风险。

错误处理和恢复

• 客服人员会根据步骤前缀的明确成功情况对每个步骤进行身份验证。操作必须返回包含明确成功或失败指示符的结构化结果。客服人员无法仅从缺失或空响应中可靠地推断失败。
• 当操作失败时，客服人员会使用操作返回的错误消息来确定下一步：提示用户输入正确输入，尝试使用调整后的参数进行自愈重试，或停止链并记录失败以供人工审核。因此，错误消息必须具体和可操作：“无效日期范围：endDate 不能早于 startDate”可用；仅 400 状态代码不可用。
• 对于部分完成创建不一致状态的链（例如，创建了开单客户，但未更新 CRM 记录），客服人员会调用补偿操作，以在出现故障前回滚或标记部分状态。将补偿路径设计为向前路径旁边的命名操作。
• 如果写入操作可能成功，但返回不明确的响应（网络超时，无确认），重试必须使用与原始调用相同的幂等密钥或外部引用 ID。请勿对非幂等写入发出未选中的重试。

安全注意事项

• 用命名凭据换行所有外部标注。切勿在 Apex 代码或流配置中硬编码端点或凭据。这些必须通过平台的安全凭据存储进行管理，并在不更改代码的情况下轮换。
• 将最小权限原则应用于每个操作使用的集成用户或连接的应用程序。仅读取订单数据的操作不应拥有计费系统的写入权限。将凭据的范围限定为操作所需的最少操作。
• 记录链中每个操作的调用及其会话 ID、输入参数（对敏感值进行消毒）和结果。如果结果有争议，此审计跟踪是重新构建客服人员执行给定操作序列的原因的主要机制。
• 在将源自用户提供的文本的所有输入参数传输到外部系统之前，请对其进行消毒。通过客服人员传递到外部 API 标注的用户输入是潜在的注入向量。在进行标注之前，验证操作边界的类型、格式和范围。

示例

处理退款请求的客户服务代理执行四步顺序链：

1. GetOrderDetails(Apex 操作)使用用户提供的订单 ID 从订单管理系统检索订单记录。它返回订单状态、行项目、购买日期和付款方式。客服人员在继续之前会评估订单是否处于可退款状态。
2. ValidateRefundEligibility（自动启动流）应用退款资格的业务规则，包括退货窗口、产品类别限制和之前的退款历史。它返回“合格”布尔值，如果不合格，则返回客服人员可以向用户显示的简单原因。
3. InitiateRefund(Apex 操作)调用外部付款网关 API，其中包含订单 ID 和退款金额。成功时返回“refundTransactionId”。此操作无效。如果第二次调用相同的订单 ID，将返回现有的交易 ID，而不是创建重复的退款。
4. UpdateCaseStatus（自动启动流）使用退款交易 ID 更新 CRM 个案记录，将个案状态设置为“已解决退款问题”，并为客户所有人创建后续任务。此步骤仅在“InitiateRefund”返回确认的交易 ID 后执行。

如果InitiateRefund超时或返回错误，客服人员会停止链，不调用UpdateCaseStatus，并向用户显示可操作的消息。个案保持未处理和未解决状态，并在 CRM 中保留准确状态。

上下文

当执行步骤相互依赖时，顺序操作链是高效的。一个步骤会打开下一个步骤。但许多工作流包含一组没有相互依赖性的步骤。例如，包含检索产品库存、获取客户权利和检查发货预估的步骤可以同时发生，因为没有步骤的输入需要另一个步骤的输出。按顺序执行这些步骤会浪费时间，这与步骤的数量成正比。

在并行调用模式中，客服人员识别一组操作是独立的，并同时调用它们，而不是按顺序调用。整体工作流时间受最慢的单个操作的约束，而不是所有操作时间的总和。在返回所有结果后，客服人员会将它们聚合为一个一致的响应，或者将它们一起用作下一阶段推理的输入。

关键的架构挑战不是并行调用本身。它在平台并发约束中管理扇出，并确保聚合步骤优雅地处理部分失败，而不会丢弃成功的结果。

问题

客服人员如何高效地协调多个独立功能的同时执行，并将单个结果聚合到单个、一致的响应中，供用户或后续步骤使用？

武力

应用此模式时，请回答以下问题：

• 有关线程安全和共享可变状态的操作注意事项是什么？
• 该解决方案将如何管理和避免达到单个事务中并行 Apex 标注的 Salesforce 调控器限制？
• 是否需要使用异步模式(例如 Queueable Apex 或 Platform Events)来避免调控器限制？
• 客服人员继续之前是否需要同步聚合结果？

Salesforce 模式应用程序

草图

并行操作调用的顺序图

结果

在并行执行独立操作时，端到端工作流时间受最慢的单个操作的约束，而不是所有操作的总和。对于具有三个平均 300 毫秒的独立标注的工作流，并行执行在 ~300 毫秒内完成；顺序执行在 ~900 毫秒内完成。在规模上，这种差异会在每个同时运行的客服人员会话中复合。

设计注意事项

与平台无关的指导

• 在并行化之前，请确认独立性。只有当两个操作都没有读取另一个操作写入的状态时，操作才安全地并行运行，并且两个操作的失败都不应该取消另一个操作。如果存在依赖关系，即使是软依赖关系，也使用顺序链。
• 明确设计聚合步骤。预先定义完整的结果集是什么样子，部分结果集对下游推理意味着什么，以及客服人员是否应该等待所有结果，或者在阈值（例如，总共七个呼叫中的五个）返回后继续。
• 所有并行写入操作必须幂等。每个操作在没有共享事务边界的情况下单独运行，因此重试任何单个分支都不会重复副作用。

Salesforce 实施说明

• **对于可查询 Apex：**在单个事务中提交所有作业，以最大化并发执行的机会。请注意，可用的并发时段在组织中共享；在设计时假设时段可能并不总是可用，并在不可用时构建顺序执行的后备。
• **对于平台事件：**将每个操作的结果写入专用暂存记录（由共享相关 ID 键控），而不是直接更新目标记录。一旦达到预期计数，最终聚合流或 Apex 触发器会读取所有暂存记录，然后原子应用合并更新。
• **对于中间件扇出：**在单个标注上设置显式超时，该超时长于最慢后端的预期最坏情况响应时间，但仍在 Salesforce 标注超时限制内。中间件返回部分结果，并明确指出哪些后端失败，而不是超时整个响应。

错误处理和恢复

• 将部分成功视为一流的结果。如果三个或四个并行操作成功，客服人员会使用三个成功的结果，并处理向用户明确显示的失败，记录重试，或调用补偿操作，而不是丢弃所有结果或继续，就像失败没有发生一样。
• 对于可排队和平台事件模式，使用相关 ID（在扇出点生成）将所有并行分支链接回原始客服人员会话。重新组合结果并在日志中将失败追溯到其来源需要此 ID。
• 如果并行分支失败，并且该操作可以安全地重试，请使用原始相关 ID 和幂等密钥仅对失败的分支重新排队。请勿重新调用所有分支。
• 定义聚合步骤的超时阈值。如果并非所有结果都在阈值内，请继续处理可用结果，并标记不完整集，而不是无限期等待。

安全注意事项

• 每个并行执行上下文，无论是可排队作业、平台事件触发器还是中间件标注，都必须应用与顺序标注相同的访问控制。并行不会放宽数据访问规则。每个分支必须在相同的最低特权凭据下运行，就像单独调用时一样。
• 对于中间件扇出，中间件层不会缓存或记录聚合窗口之外单个后端的响应负载。每个后端的响应可能包含敏感数据，这些数据不应保留在即时操作的范围之外。
• 确保客服人员的最终用户无法读取用于平台事件聚合的暂存记录。这些记录可能包含尚不适合使用的中间部分形成的数据。

示例

服务代理回答了一个复杂的履行问题：「你能在周五前将此订单发货给我吗 ? 」该答案需要同时来自所有独立系统的数据，如下所述：

1. 客服人员确定三个独立的数据需求：当前库存水平、客户的有效权利，以及客户位置的运营商估计交货时段。
2. 并行调用 3 个操作：GetInventoryStatus（通过中间件从外部库存系统）、GetCustomerEntitlements（从 Salesforce CRM）和 GetDeliveryEstimate（通过中间件从运营商 API）。
3. 每个操作独立返回。客服人员等待，直到收到所有三个响应（或达到聚合超时）。
4. 在所有 3 个结果可用的情况下，客服人员会考虑合并数据的原因，评估库存是否充足，客户的权利是否涵盖快递，承运人是否确认周五交付对客户的邮政编码是可行的。
5. 客服人员在三个呼叫中响应最慢的时间，向用户返回一个基于基础的回答，该回答从三个系统中提取。

上下文

一些客服人员发起的操作不会产生客服人员需要继续其当前推理周期的结果。发送通知、触发下游批处理、将事件发布到消息队列或提交长时间运行的作业是客服人员义务在派遣时结束的所有操作；下游系统获得所有权并独立完成工作。

在传统自动化中，这些被建模为“忘却”标注或平台事件发布。在代理系统中，客服人员在推理期间决定操作是非阻塞的，派遣它，记录派遣的确认，并继续或结束轮次，而无需等待下游结果。

此模式是集成模式指南中远程流程调用 – 触发并忘记的代理对应项。客服人员模式通过使派遣决策成为客服人员推理的一部分来扩展它，并确保派遣是可跟踪的，即使没有响应返回到客服人员。

问题

当客服人员需要启动超出客服人员会话或推理周期的下游操作时，必须解决三个挑战：

• **非阻塞调用：**客服人员必须触发操作并确认交付，而无需等待结果而保持推理周期打开。
• **交付确认：**客服人员必须区分成功派遣（消息已接受）和成功结果（下游流程已完成）。它只能断言前者。
• **可跟踪性：**由于客服人员未收到任何结果，因此必须通过独立于客服人员会话的日志、事件记录或平台监控来观察操作。

武力

应用此模式时，请回答以下问题：

• 客服人员是否需要此操作的结果来完成当前轮次？ 如果是，这不是正确的模式。改用顺序操作调用。

• 在没有同步确认的情况下，下游系统是否能够接收并可靠地处理分派的消息或事件？ 目标系统必须耐用。如果消息暂时不可用，则不得丢失。

• 操作是否无效，或是否需要防范重复派遣？ 网络级重试和客服人员推理重试会使同一派遣被尝试多次。如果下游操作不是幂等的，则该操作必须携带重复数据消除密钥。

• 用户或下游流程是否需要知道操作何时完成？ 客服人员只能确认派遣。如果需要完成状态，请设计单独的通知或跟进机制。平台事件、个案更新或回调 - 在此推理周期之外。

Salesforce 模式应用程序

草图

异步操作调用的顺序图

结果

客服人员调用下游操作，而不会阻止其对结果的推理循环。当确认操作已被接受时，而不是确认操作已完成。下游系统拥有执行的完整所有权。派遣操作可通过派遣时记录在 CRM 中的平台事件订阅者、作业 ID 或外部队列确认 ID 进行跟踪。如果下游操作失败，该失败将通过下游系统自己的监控出现，而不是通过发起它的客服人员会话。

设计注意事项

与平台无关的指导

• 使用基于意图的语言编写操作描述。例如，“向消息传递队列提交续订通知并返回派遣参考 ID”比“调用通知端点”对客服人员更有用。
• 请勿将派遣操作描述为“发送并确认送达”。客服人员只能确认接受。下游交付和处理不在客服人员的观察范围内。

Salesforce 实施说明

• 从每个调用操作返回引用 ID，例如平台事件ReplayId、可排队作业 ID、发布/订阅 API PublishResultplayId 或外部确认令牌。在调用时将其记录在 CRM 记录中。这是客服人员会话将产生的唯一审计跟踪。
• 对于发布/订阅 API，客服人员调用 Apex 操作，该操作对发布/订阅 API ‘/Publish’ 端点进行 gRPC 标注。该操作必须处理模式注册步骤 - 事件必须以 Avro 格式针对注册的模式进行序列化。将PublishResult ‘replayId’返回给客服人员作为派遣参考。
• 对于平台事件，在向客服人员返回成功指示器之前，请在 Apex 操作中调用EventBus.publish()并检查 SaveResult 是否有错误。不要假设发布成功；请验证它。
• 对于可排队作业，实施可排队界面并从操作中调用 System.enqueueJob()。将生成的 AsyncApexJob ID 返回给客服人员。
• 对于外部异步端点，目标端点必须立即返回带有参考 ID 的确认（HTTP 202 已接受）。如果端点在处理完成之前一直阻止，则它是同步的，此模式不适用。

错误处理和恢复

• 调用操作必须区分派遣失败（消息未被接受）和处理失败（消息被接受，但下游操作稍后失败）。客服人员只能处理前者。
• 如果调用失败，该操作必须返回带有明确原因的结构化失败。客服人员可以重试派遣、升级为人工或记录失败的派遣记录，但无法在同一会话中恢复下游处理失败。
• 对于最终必须显示下游故障的操作，请设计单独的反馈循环，例如下游流程发布的平台事件、检查作业状态的计划流或客服人员会话外部的后续个案。

安全注意事项

• 使用命名凭据封装所有外部异步标注。调用操作不会在代码中嵌入端点 URL 或凭据。
• 在嵌入事件负载或消息正文之前，验证并清理传递给调用操作的所有参数。传递到异步消息中的用户提供的文本是下游消费者中的潜在注入向量。
• 在派遣时使用会话 ID、参考 ID 和消毒负载记录每次派遣。因为没有响应返回到客服人员，所以此日志是重新构建客服人员发起内容的主要机制。
• 对集成用户或连接的应用程序应用最小权限。发布到通知队列的派遣操作不应持有允许在不相关系统上读取或写入的凭据。

示例

处理即将到期合同的续订管理客服人员确定客户是否有资格获得自动续订通知。客服人员不需要在结束轮次之前确认电子邮件是否已送达。

1. CheckRenewalEligibility（自动启动流）评估合同条款、客户层和选择退出状态。返回“合格”布尔值和首选通知渠道。
2. DispatchRenewalNotification(Apex 操作)发布一个RenewalNotification\_\_e平台事件，其中包含合同 ID、客户 ID、通知渠道和生成的授权密钥。返回 ReplayId，确认事件已被平台接受。
3. UpdateContractRecord（自动启动流）将ReplayId和派遣时间戳写入合同记录，并设置“通知已派遣”状态标记。

上下文

外部应用程序，例如客户入口网站、移动应用程序、第三方 SaaS 平台和合作伙伴系统，需要以编程方式调用客服人员，以处理服务请求、启动工作流或在他们自己的界面中显示 AI 驱动的响应。客服人员充当智能后端服务。外部系统提供上下文、客服人员原因和行为，呼叫方使用响应。

呼叫者本身越来越多地是 AI 客服人员或编配员，而不是面向人的应用程序。在这些 AI 到 AI 模式中，编配客服人员将推理步骤、CRM 查找或操作作为离散的工具调用委派给 Agentforce。我们需要公开模型上下文协议 (MCP) 服务器来支持这种模式。

问题

当外部系统或 AI 客服人员需要按需利用 Agentforce 客服人员的功能时，它如何进行身份验证，创建客服人员会话，传递必要的对话和上下文数据，并可靠地接收客服人员的结构化响应来驱动自己的下游逻辑？

武力

应用此模式时，请回答以下问题：

• 外部调用方是否期望获得同步的低延迟响应，或者异步回调是否可接受？
• 如何建立呼叫者的身份并将其传播到客服人员的执行上下文中，以实现数据访问和个性化？
• 并发 API 触发的会话的预期数量是多少，它与 Salesforce API 速率和并发限制有什么相互作用？
• 外部系统是否需要在多次轮次（多次轮次对话）之间保持会话连续性，或者每个请求是否处于无国籍状态？
• 客服人员的响应应如何构建，以便呼叫系统能够以编程方式对其进行解析和操作？
• 调用者是需要直接 REST 集成的面向人的应用程序，还是可以通过标准协议（例如 MCP）调用 Agentforce 作为工具的 AI 客服人员或编配员？

Salesforce 模式应用程序

草图

按需客服人员调用的顺序图

结果

这种模式将 Agentforce 公开为可调用的 AI 服务。外部系统可以访问客服人员的推理、工具和 CRM 上下文，而无需复制该逻辑。调用者仍负责会话生命周期管理和呈现响应。客服人员仍负责所有推理、工具选择和响应综合。

当调用者是 AI 客服人员或编配员时，Agentforce via MCP 机制（可通过 Salesforce Headless 360 立即使用）完全不需要自定义 REST 集成。MCP 服务器代表呼叫客服人员处理会话生命周期，使 Agentforce 能够作为一流的工具参与多客服人员工作流，而无需额外的管道。

设计注意事项

与平台无关的指导

• 避免在时间敏感的 UI 流中同步和阻止外部 API 调用。采用轮讯或 Webhook 回调模式，其中客服人员的响应时间不重要，以将用户体验与客服人员的处理时间分离。
• 根据呼叫者的性质而不是可用性选择呼叫机制。面向人的应用程序和系统集成应直接使用客服人员 API。支持 MCP 的工具应使用 Agentforce MCP 服务器。相同调用者类型的混合机制增加了不必要的复杂性，没有架构优势。

Salesforce 实施说明

• 在会话创建 POST 请求中注入会话上下文，而不是在第一个用户消息中。当外部系统创建会话时，它有机会直接作为命名会话参数传递结构化上下文变量（客户 ID、权利数据、之前的交互汇总）。这些变量在处理单轮之前对客服人员可用，因此它会从基础状态开始推理，而无需发出查找调用来确定客户是谁或他们有权获得什么。相反，在消息正文中传递相同的数据会迫使客服人员解析非结构化文本，以提取可能作为类型变量接收的事实 - 增加延迟、引入提取错误，并消耗不会增加业务价值的推理步骤。
• 将客服人员响应设计为结构化和机器可解析。当调用者是系统而不是人类时，使用输出变量约定和提示指令来指导客服人员返回 JSON 友好或明确分隔的响应。
• 明确管理会话生命周期。在使用DELETE /einstein/ai-agent/v1/sessions/{sessionId}释放并发时隙后，迅速终止会话，避免过时的上下文在不相关的交互中持续存在。
• 考虑 Salesforce 并发会话限制。对于高吞吐量场景，在呼叫系统中实施会话池或队列层，以防止在峰值负载期间拒绝请求。
• 当通过 MCP 调用 Agentforce 时，将上下文作为工具输入参数而不是会话变量传递。MCP 服务器透明地管理会话生命周期，因此调用客服人员无法在创建时直接设置命名会话参数。确保所有必需的上下文（记录 ID、用户身份、权利数据）都包含在工具调用负载中，以便客服人员从基础状态开始推理。
• 将 MCP 服务器的透明会话管理视为一种方便，而不是一种并发绕过。每个工具调用仍会消耗 Salesforce 客服人员会话时段。通过 MCP 大规模调用 Agentforce 的高频编配器必须考虑适用于直接客服人员 API 调用者的相同并发会话限制。

错误处理和恢复

• 客服人员 API 返回标准 HTTP 错误代码。调用系统必须处理具有指数回退的“429 请求过多”（速率限制）和具有重试逻辑的“503 服务不可用”。
• 当客服人员自身遇到无法解析的工具故障时，它会在响应正文中返回优雅的自然语言错误。调用系统会检测这些哨兵响应（例如，检查响应中的“错误”状态字段），并通过使用其他上下文重试、提供后备体验或升级为人工来相应地路由。
• 当通过 MCP 调用时，错误出现在两个不同的层：MCP 传输错误（格式错误的工具调用、服务器不可用）和 Agentforce 推理失败（工具执行错误、无法解析的操作）。编配客服人员必须独立处理这两个图层。MCP 传输错误应触发协议级别的重试；工具响应中返回的 Agentforce 推理失败应由编配器自己的后备或升级逻辑处理。

安全注意事项

• 对外部客户端应用程序使用尽可能窄的 OAuth 范围。仅需要调用客服人员的集成不应包含超出客服人员本身要求的数据访问范围。
• 在将外部系统的所有输入注入为会话变量之前，请对其进行验证和消毒。外部输入是及时注入的攻击表面。例如，恶意呼叫者可以创建“customerQuery”字段，用于覆盖客服人员指令。
• 在外部客户端应用程序上应用 IP 允许列表，以限制哪些外部系统可以验证和调用客服人员 API。
• 出于审计和安全目的，使用呼叫者身份、会话 ID 和请求/响应元数据记录所有入站 API 触发的会话。
• 当通过 MCP 调用 Agentforce 时，MCP 服务器代表调用用户向 Salesforce 进行身份验证。请确保 MCP 服务器连接的应用程序凭据的范围最小，并且最终用户的身份（使用 MCP 工具，例如 Claude）- 身份通过工具输入参数明确传播到会话上下文中。

示例

金融服务入口网站会触发 Agentforce 客服人员处理抵押贷款查询。

1. 入口网站使用客户端凭据 OAuth 流进行身份验证，并获取不记名令牌。
2. 它使用会话变量“{ “accountId”: “001xx…”, “productType”: “mortgage”, “loanAmount”: 450000 }”调用“POST/einstein/ai-agent/v1/sessions”。
3. 用户提交问题：“我需要什么文件来完成我的申请？”
4. 入口网站使用用户的文本调用“POST/einstein/ai-agent/v1/sessions/{sessionId}/messages”。
5. Agentforce 客服人员调用“GetDocumentChecklist”流操作，检索特定于贷款类型的要求，并返回结构化列表。
6. 入口网站内联显示客服人员的响应，并在用户退出时关闭会话。

上下文

并非所有客服人员工作流都源自人类请求。运营数据中频繁出现关键业务信号，例如产品使用度量突然下降、高价值购物车放弃或付款失败超过风险阈值。当这些信号需要智能的多步骤响应时，等待人类注意到并采取行动会引入延迟，从而增加实际业务成本。

此模式描述了实时事件如何作为客服人员的自主入口点。客服人员由数据条件调用，而不是由用户调用，原因取决于事件上下文，并且执行响应工作流，无需人为启动。

问题

当实时业务事件发生在 Data 360 或 Salesforce 平台中时，该事件如何自动实例化客服人员会话，提供事件负载作为基础上下文，并在无需人为发起或指导交互的情况下完成非对话操作工作流？

武力

应用此模式时，请回答以下问题：

• 是否需要在事件触发时立即响应，或者是否可以接受近乎实时的处理（秒到分钟）？
• 事件负载是否包含足够的上下文来训练客服人员，或者客服人员是否需要执行额外的查找才能有效地推理？
• 预期的事件数量和频率是多少？高吞吐量事件流需要流量管理，以避免耗尽客服人员的并发限制。
• 同一事件能否为同一业务实体触发多次（至少交付一次）？如果是，操作必须幂等。
• 如果客服人员无法自主解决事件，是否有人为升级路径？
• 应如何显示失败的事件处理？使用死信队列、警报或个案创建？

Salesforce 模式应用程序

草图

事件驱动的客服人员执行顺序图

结果

客服人员成为实时业务运营的反应性参与者，而不是对人类请求的被动响应者。事件触发的客服人员能够以数据的速度而不是人类关注的速度执行恢复、分类和升级工作流。

触发系统（Data 360 或平台事件）仍负责事件检测和负载形成。客服人员仍负责对该负载进行推理，并选择正确的操作链。无需对话轮次；事件负载是完整输入。

设计注意事项

与平台无关的指导

• 为非对话调用设计所有操作。没有用户轮次；客服人员必须仅从初始基础上下文达成解决方案。行动应返回结构化、确定性的输出，而不是提示澄清。
• 在创建客服人员会话之前，请确保事件负载包含足够的基础上下文。精益负载迫使客服人员在推理之前进行多次查找调用，这会增加延迟和并发消耗。
• 使事件驱动的客服人员触发的所有写操作无效。事件传递系统通常提供至少一次保证。重复事件处理不会产生重复的副作用。

Salesforce 实施说明

• 在 Data 360 触发的流中，在会话创建时将事件负载属性（例如，“accountId”、“eventType”、“metricValue”、“productIds”）直接映射到命名会话变量。这从第一个推理步骤开始为客服人员提供基础，而无需检索操作。
• 对于平台事件触发器，使用自动启动流，而不是屏幕流。自主、非对话上下文不支持屏幕流。
• 在事件触发的会话上设置显式会话超时。与会话不同，没有用户来扩展交互；在失败操作上停滞的会话不应无限期地保持并发时段。
• 使用流错误路径处理客服人员会话创建失败。如果无法创建会话，错误路径应发布补偿事件或创建人工跟进的个案，而不是静默地丢弃该事件。

错误处理和恢复

• 由于并发限制、会话创建错误或负载验证失败而未能成功触发客服人员会话的事件应路由到错误路径，该路径创建个案、触发警报或将事件发布到死信队列进行重新处理。
• 客服人员在执行过程中失败（例如，所需操作的超时）应使用原始事件 ID 进行记录。由于触发是异步的，并且没有等待的调用者，因此错误表面完全基于可观察性：日志、仪表板和警报阈值。
• 实施重试上限。如果事件可靠地导致客服人员失败，无限制的重试将耗尽并发限制。在可配置的最大尝试次数后，将事件路由到附加完整上下文的人工审查队列。
• 在整个客服人员会话生命周期中跟踪事件 ID。这种跟踪支持原始数据信号与所有下游操作之间的关联，以便进行审计和调试。

安全注意事项

• 在将它们注入为客服人员会话变量之前，请验证并清理所有事件负载属性。Data 360 或外部发布者的事件负载是及时注入的攻击表面。例如，精心制作的负载字段可以设计为覆盖客服人员指令。
• 在专用的最低权限集成用户下运行事件触发的客服人员会话，而不是在高权限管理员身份下。客服人员仅拥有执行其定义的操作集所需的权限。
• 使用原始事件 ID、事件类型和创建时注入的会话变量记录所有事件触发的会话。如果结果有争议，则需要此审计跟踪来重新构建客服人员采取给定操作的原因。

示例

一家零售公司使用 Data 360 跟踪实时购物车行为。当放弃价值高于定义阈值的购物车时：

1. Data 360 检测放弃信号，并触发带有事件负载的触发流：“customerId”、“cartValue”、“productIds”和“abandonmentTimestamp”。
2. 流将这些属性映射到 Agentforce 会话变量，并创建新的客服人员会话。无需用户交互。
3. 客服人员使用其可用的检索操作评估客户的购买历史、当前权利和购物车组成。
4. 客服人员调用SelectRecoveryOffer操作，该操作根据客户细分应用适当的折扣层，并调用SendProactiveNotification操作，通过客户的首选渠道提供优惠。
5. 客服人员调用 CreateFollowUpTask 在 CRM 中记录交互，以便客户所有人查看。
6. 操作链完成后，会话会自动关闭。原始事件 ID 保留在会话日志中，以便进行跟踪。

上下文

LLM 接受公共数据培训。他们不Knowledge组织的产品、策略、个案历史或合同，除非在推理时明确提供这些信息。如果没有基础，客服人员询问客户的服务权利或特定合同的条款，他们会幻觉答案，或承认不知道。这两种结果在企业环境中都是不可接受的。

检索扩充生成 (RAG) 通过从 Enterprise Knowledge 商店检索相关文档并在生成响应之前将它们注入客服人员的上下文窗口来解决这个问题。客服人员会考虑检索到的内容，例如 Knowledge 文章、过去的个案解决方案、产品规格，就像直接获得这些信息一样。LLM 提供推理；检索层提供事实。

例如，处理复杂保修索赔的服务代理无需在其说明中嵌入保修条款。相反，当客户描述他们的问题时，客服人员会对保修文档的向量索引执行语义搜索或混合搜索（关键字搜索 + 语义搜索），检索适用的术语，并使用它们来确定资格和后续步骤。答案基于当前权威的政策文档，而不是模型的训练数据。

问题

客服人员需要回答问题或做出决策，这取决于专有组织 Knowledge，例如保单、合同、产品文档或不属于 LLM 培训数据的历史个案数据。客服人员如何在推理时检索最相关的内容，确保检索的内容是最新的和权威的，并足够准确地将其注入上下文以避免干扰？

武力

应用此模式时，请回答以下问题

• Knowledge 内容是否静态且不常更新(例如产品手册),或是否持续更改(例如个案解决方案、库存描述)?更新频率决定了接收漏斗设计。
• 内容有多大？小型 Knowledge 库可以穷举检索；大型 Knowledge 库需要分块、嵌入和语义索引，以仅返回最相关的段落。
• 查询是否受益于单一重点检索，或者合并来自多个 Knowledge 来源的结果（例如，文档和过去的个案同时）会产生基础更牢固的答案？后者需要集成检索。
• 是否需要在语义排名之前按元数据筛选检索到的内容，例如，将结果限制为与客户的产品层或地理位置相关的文档？
• Knowledge 内容的敏感度如何？检索到的内容被注入到 LLM 上下文窗口中，并影响客服人员的响应；不应向特定用户显示的内容必须在检索层进行控制，而不是假设由 LLM 筛选。

Salesforce 模式应用程序

草图

从企业内容进行 Knowledge 基础训练的顺序图

结果

客服人员的回复取决于组织当前的权威 Knowledge，而不是 LLM 的培训数据。保单条款、产品规格、权利详细信息等事实问题上的幻觉风险降低，因为模型是对检索的证据进行推理，而不是从记忆中生成。

Knowledge 内容保持可独立维护。更新策略文档或将新个案解决方案添加到索引会立即对所有后续客服人员交互生效，无需重新培训或重新部署模型。

检索也会提供隐式审计跟踪。因为客服人员的答案来自特定的检索文档，所以源内容可以与响应一起记录，这样就有可能跟踪客服人员给出特定答案的原因。

设计注意事项

与平台无关的指导

• 以正确的粒度分块并嵌入 Knowledge 内容。过大的块会稀释相关性。太小的块会丢失 LLM 需要正确推理的环境上下文。对于大多数企业文档类型，具有重叠上下文窗口的段落级分块会产生最佳检索质量。
• 将检索精度视为一流的设计问题。将低相关性内容注入客服人员的上下文窗口并非中立。它引入了降低响应质量的噪声。调整检索阈值和前 K 限制，以平衡每个 Knowledge 域的召回率和精确度。
• 接收延迟是操作 SLA。如果策略文档已更新，但向量索引尚未刷新，客服人员将检索过时信息并采取行动。为每类内容定义可接受的过时容限，并相应地设计接收漏斗。

Salesforce 实施说明

• 通过内容更新频率的适当摄取漏斗，填充 Data 360 矢量索引。对静态文档使用批量接收，对连续变化的记录使用流或变更数据捕获 (CDC)。
• 对于集合检索器，配置每个来源的相关性排名权重。已解决个案索引可能需要最近偏差；策略文档索引可能不需要。根据客服人员预计处理的查询类型调整权重。
• 在执行语义搜索之前，使用自定义 Apex 或流检索器中的元数据筛选器来确定检索的范围。在排名前按产品线、地区或文档类型筛选可以减少噪音，并提高注入上下文内容的精度。
• 请勿将检索到的完整文档注入 LLM 上下文。仅传递相关块或摘录。大型上下文注入会消耗令牌预算，增加延迟，并降低客服人员推理可用的上下文窗口的比例。

错误处理和恢复

• 如果检索未返回任何结果，则返回明确的“未找到结果”状态，而不是继续不接地。然后，客服人员可以扩大查询范围，要求用户澄清，或升级为人工。
• 从检索器返回的每个块都包含一个相关性分数。根据用例，应配置一定的阈值置信度/相关性值，超过该值，客服人员应将检索视为置信度，否则将返回到澄清或上报。
• 如果向量索引或检索服务暂时不可用，检索器操作或 Apex 标注应返回带有描述性原因的结构错误。使用会话 ID 和查询记录失败，以便识别检索差距，并监控索引或服务的可用性。
• 对于时间敏感的 Knowledge 域，作为检索响应的一部分实施新鲜度检查。如果最近的匹配文档上次更新超过定义的过时阈值，请将此标记给客服人员，以便其符合其响应或验证提示的条件。

安全注意事项

• 检索必须尊重客服人员所代表的用户的数据访问权限。在面向客户的交互上下文中运行的客服人员会话不得检索内部操作文档、定价策略备注或最终用户否则无权访问的记录。在检索层应用字段级和记录级安全性。请勿依赖 LLM 保留敏感的检索内容。
• 检索的内容被注入到 LLM 上下文窗口中，并可能影响或出现在客服人员的响应中。将检索内容中的每个文档视为对最终用户可能可见的文档，并相应地管理内容成员关系。
• 将所有检索查询和检索到的块的文档标识符与会话 ID 一起记录。此审计跟踪允许重建客服人员在回复时使用的证据，这可能是合规、争议解决或解释性义务所必需的。

示例

金融服务客服人员处理客户关于定期储蓄产品早期赎回处罚的查询：

1. 客户询问：“如果我提前六个月提取资金，会受到什么处罚 ? ”
2. 客服人员调用针对产品条款和条件文档的向量索引配置的个人检索器操作。
3. 检索器使用查询上下文执行语义搜索，例如产品类型和客户客户，以及具体问题，并返回三个最相关的文档块 - 早期兑换条款、惩罚计算表和适用于困难情况的异常。
4. 检索到的块会与客户的问题一起注入到客服人员的上下文窗口中。
5. 客服人员对检索到的条款进行解释，确定客户产品等级和兑换时间线的适用处罚率，并返回基于保单的精确答案，并引用其使用的条款的生效日期。
6. 检索到的块的文档标识符与会话记录一起记录，以便进行审计。

上下文

LLM 本质上是概率性的。当被要求就特定客户进行推理时，他们会推断、估计或幻觉他们没有明确给出的事实。客服人员在不知道客户是首选层上的高价值企业客户的情况下调用定价操作，可能会应用错误的折扣逻辑。客服人员在不知道客户流失风险分数的情况下升级支持个案，可能会使距离流失还有几天的客户失去优先级。

验证的客户上下文注入通过在客服人员调用操作之前使用统一简档中验证的结构化属性预填充操作输入参数来解决这个问题。客服人员不会推断客户的细分、终身价值或客户满意度 (CSAT) 趋势。它接收这些事实作为基础输入及其原因。这种模式降低了客户特定决策的幻觉风险，并消除了推理周期中的冗余查找调用。

例如，在定价客服人员调用“生成报价”操作之前，子客服人员配置会自动从他们的统一简档中注入客户的细分、等级和终身价值。该操作接收经过验证的事实，而不是 LLM 推断的近似值，并且报价定位于客户的实际商业关系。

这不是“从企业内容进行 Knowledge 基础训练”模式的替代方案。设计良好的客服人员可以使用以下两者：“基于 Enterprise Content 的 Knowledge”提供基于文档的 Knowledge，而“验证的客户上下文注入”建立客户身份。

问题

您如何确保客服人员在采取行动之前拥有特定于客户的准确事实，例如细分、等级、终身价值、流失风险或其他简档属性，而不是自己猜测这些事实？

武力

应用此模式时，请回答以下问题：

• 哪些操作输入参数代表特定于客户的事实，如果推断而不是来源，它们会产生不正确或不一致的结果？
• 所需的简档属性是否可用作标准 Data 360 统一简档字段，或者它们是否需要从原始行为和事务数据派生的计算见解？
• 相关简档属性多久更改一次？流失风险得分或 CSAT 趋势等属性需要新鲜度保证；过时的简档数据会导致与幻觉数据相同的错误结果。
• 简档属性是在会话创建时注入的（在会话持续时间内保持不变），还是在操作点调用时获取新的（以反映会话期间的状态更改）？
• 客服人员是否需要直接对简档属性进行推理，或者它们是否仅被操作消耗，对客服人员的推理循环不透明？

Salesforce 模式应用程序

草图

已验证客户上下文注入的顺序图

结果

操作接收经过验证的结构化客户事实，而不是 LLM 推断的近似值。客服人员的推理取决于客户的实际简档状态，减少了决策的幻觉风险，因为事实准确性决定了结果质量，例如定价、权利检查、升级路由、保留优惠。

简档基础训练还减少了推理延迟。当客服人员不需要发出查找调用来建立基本客户上下文时，推理周期更短，并发消耗更少。

Data 360 统一简档仍然是客户事实的权威来源。子代理配置或连接的流是集成接缝。客服人员负责对这些事实进行推理并选择操作，而不是寻找事实本身。

设计注意事项

与平台无关的指导

• 识别所有具有幻觉风险的操作输入，其中 LLM 推理可能会产生错误的结果，而不是验证值。具有幻觉风险的输入是轮廓接地的候选项。并非每个输入都需要接地；过度注入简档数据会为客服人员的上下文窗口添加噪音。
• 将简档新鲜度视为设计决策，而不是事后的想法。为每个基础属性定义可接受的过时容忍度，并相应地选择注入机制：稳定属性的会话级映射，易失性属性的基于流的刷新。
• 计算见解应编码业务逻辑，而不是原始度量。客服人员推理的“churnRiskScore”为 0.87，比客服人员推理的 14 个原始行为信号更有效。在 Data 360 中计算解释；将结果传递给客服人员。

Salesforce 实施说明

• 简档基础与背后的统一一样可信。例如，统一简档的值完全取决于上游的身份解析质量。如果客户在源系统中的身份不完整，并且尚未统一，客服人员收到的简档属性将不完整，或者它们仅代表部分视图（例如，用一个渠道的数据而不是另一个渠道的数据计算的终身价值）。
• 对于 Data 360 连接的流，使用“获取记录”元素与当前会话“recordId”或“accountId”上的筛选器，以仅检索相关简档记录。仅返回下游操作所需的属性；不返回完整简档对象。
• 计算见解必须通过 Data 360 接收漏斗保持最新。为对时间敏感的决策中使用的见解设置流或近实时刷新（例如，保留工作流中的流失风险）。移动速度较慢的属性可以接受批量刷新的见解（例如，年度合同价值层）。
• 在操作调用前，验证映射的简档属性是否非空。传递给定价操作的空“customerTier”与幻觉值一样有害。使用流决策元素检测缺失的简档数据，并路由到检索默认值或提示澄清的回退。
• 在子代理配置中，使用描述性、语义清晰的变量名称（例如，“customerTier”、“lifetimeValueUSD”、“churnRiskScore”）将简档属性映射到操作输入参数。LLM 会在选择和撰写操作时读取这些名称；不明确的名称会降低选择的准确性。

错误处理和恢复

• 如果在操作调用时必填简档属性为空或不可用，客服人员不应使用可能不正确的默认值继续。该操作应返回指示缺少属性的结构错误，客服人员应提示用户澄清，或者如果以非对话方式操作，应升级为人工。
• 如果 Data 360 连接的流无法检索简档数据（例如，由于 Data 360 服务中断），流的错误路径应向客服人员返回结构错误，并带有特定的失败原因。然后，客服人员可以决定是否重试，继续降级体验，或向用户显示失败。
• 将会话创建或操作调用时注入的所有简档属性值与会话 ID 一起记录。这确保了任何有争议的客服人员决策都可以用客服人员当时获得的确切客户事实来重建。

安全注意事项

• 注入客服人员上下文的简档属性受与任何 CRM 记录相同的数据访问控制。确保用于解析简档属性的集成用户或连接的应用程序仅拥有显示的属性所需的字段级权限，而不是更广泛的简档读取访问权限。
• 编码敏感派生度量（例如，预测健康得分、财务风险等级）的计算见解应被视为敏感字段，并受与基础数据相同的访问控制。在面向客户的上下文中工作的客服人员面临高流失风险分数时，需要仔细考虑客服人员可能沟通的内容。
• 请勿显示操作不需要的简档属性。客服人员上下文窗口中的每个附加属性都是可以在客服人员响应中复制的附加数据元素。将最小必要原则应用于剖面接地。
• 审计计算见解或敏感简档属性作为输入注入的所有会话。这些会话代表根据派生的客户智能做出的决策，并可能受某些行业的解释性或监管要求的约束。

示例

一家电信公司使用 Agentforce 处理与发起取消请求的客户的保留对话。

• 在打开取消个案时，将使用客户的“accountId”作为上下文创建客服人员会话。
• 子代理配置在创建时将三个 Data 360 统一简档属性映射到会话变量：“customerTier”（企业）、“lifetimeValueUSD”（42,000）和“contractRenewalDate”（60 天）。
• 像“churnRiskScore”（0.91，从使用情况下降、支持票证频率和 NPS 趋势计算）这样的计算见解通过作为第一个操作步骤调用的 Data 360 连接的流被映射为额外的会话变量。
• 客服人员现在基于已验证的客户事实，调用“SelectRetentionOffer”操作。因为输入包含“customerTier = Enterprise”、“lifetimeValueUSD = 42000”和“churnRiskScore = 0.91”，所以该操作会返回最大层保留优惠，而不是标准保留优惠。
• 客服人员调用“PresentOffer”在对话中传递报价，并调用“LogRetentionAttempt”在 CRM 中记录交互，所有基础属性都保留以供审计。

上下文

企业数据是零碎的。只能对 Salesforce 平台内部的内容采取行动的客服人员仅限于有效推理所需的一小部分信息。回答服务问题可能需要在 Service Cloud 中阅读客户的未处理票据。准备建议可能需要从 Google Drive 检索文件。分析产品使用情况可能需要查询数据仓库。这些系统都有自己的 API、身份验证模型和数据方案，而为每个系统编写定制的集成代码的成本一直是客服人员到系统连接昂贵和脆弱的原因。

MCP 是一个直接解决这个问题的开放标准。它定义了统一的界面，客服人员可以通过该界面发现和调用任何符合 MCP 的服务器公开的工具，而不管底层系统如何。每个 MCP 服务器充当适配器：它将目标系统的本机界面封装在一个标准化的、以工具为中心的界面中，客服人员可以查询、调用和撰写这些界面，而无需了解系统的特定协议或模式。

从客服人员的角度来看，连接到 Slack、结构化查询语言 (SQL) 数据库和文档管理系统看起来是相同的，即三个 MCP 服务器，每个服务器公开一组描述的可调用工具。客服人员根据语义描述和尝试实现的目标进行选择和排序。

问题

当客服人员需要跨多个外部系统检索信息或触发操作时（每个系统都有不同的 API、身份验证和模式），它如何发现、调用和撰写它们的功能，而无需为每个系统定制集成代码，或者与任何系统的实施紧密耦合？

武力

应用此模式时，请回答以下问题：

• 客服人员是否需要访问 Salesforce 平台之外的系统，例如文档存储、协作工具、数据库、第三方 SaaS，它们的 API 不是本地表示为 Agentforce 操作？
• 是否需要动态工具发现，客服人员可以根据当前请求在推理时识别正确的集成端点，而不是在其配置中对集成进行硬编码？
• 集成环境是否经常变化；添加新系统、更新现有系统以及其他变化是否需要，以至于每个系统定制的方法会产生不可持续的维护开销？
• 是否需要将客服人员的推理层与下游系统的实施细节分离，以便目标系统的 API 更改不需要更改客服人员的指令或子客服人员配置？
• 目标系统是否由不同的团队或供应商拥有，每个团队或供应商负责公开自己的功能，从而使提供商侧 MCP 服务器模型比每个客服人员的消费者侧集成更实用？

Salesforce 模式应用程序

草图

已验证客户上下文注入的顺序图

结果

客服人员的可访问表面积会扩展，而不会增加集成复杂性。添加新的外部系统意味着为其部署或配置 MCP 服务器，而不是为每个客服人员编写定制的 Apex 标注或流集成。客服人员的推理层保持不变；仅根据语义描述发现并调用新工具。

MCP 标准还创建了明确的所有权分离：负责系统的团队将其功能公开为 MCP 服务器；客服人员团队使用这些功能，而无需了解系统的内部。随着集成系统数量的增加，此边界减少了协调开销。

工具的可组合性是直接结果。因为所有工具共享相同的调用界面，所以客服人员可以链接来自不同系统的工具，从 Google Drive 检索文件，从中提取数据，并将结果写入 CRM 记录，就像在一个系统中链接操作一样自然。

设计注意事项

与平台无关的指导

• 工具描述是客服人员决定是否以及如何调用工具的唯一依据。用清晰、基于意图的语言编写描述，说明工具的功能、应用时间和返回的内容。表示“查询 CRM 数据库”的描述不如“检索给定客户 ID 的客户未结个案（按优先级排序）”有用。描述不当会导致工具选择不当。
• 将每个 MCP 工具的范围限定为单个原子功能。一个检索文档并将汇总写回源系统的工具比两个不相关的工具更难为客服人员进行推理，更难在失败时重试，也更难确保安全。一个工具，一个责任。
• 设计工具，以便输出是可组合的输入。检索工具的结果应以一种自然的方式映射到通常跟随它的操作工具的输入参数，从而减少客服人员必须在步骤之间执行的转换工作。
• 远程主机 MCP 服务器。本地二进制安装会创建部署和版本复杂性，并随着客服人员环境的数量增长。远程托管服务器可以独立于使用它的客服人员进行更新。

Salesforce 实施说明

• 如果您想要在所有出站 MCP 调用之间实现一致的 MCP 身份验证、速率限制、负载验证，请使用支持 MCP 服务器的 AI 网关，例如 MuleSoft 全方位网关，并在向客服人员公开任何 MCP 服务器之前对其进行配置。
• 将 OAuth 2.0 凭据用于 MCP 服务器连接所需的所有凭据。凭据不得出现在工具参数、操作配置或 Apex 代码中。
• 一些 MCP 工具可能需要最终用户凭据，才可以根据业务用例采取一些操作（例如资金转移）。要传播最终用户身份令牌，请使用目前 MuleSoft 全方位网关支持的 OAuth 2.0 代表凭据注入策略。
• 对于自定义 MuleSoft MCP 服务器：在 MuleSoft 的 API 规范中定义 MCP 工具模式，并在 Agentforce 工具目录中注册服务器的端点。根据代表客服人员的查询测试工具描述，以验证客服人员在部署到生产环境之前是否为正确任务选择正确工具。

错误处理和恢复

• 当 MCP 工具调用返回错误时，客服人员会检查机器可读的错误代码，以确定适当的恢复操作：向用户请求缺少的参数，使用更正的输入重试，或升级为人工操作。它从不静默地消耗错误或继续推理，就像工具调用成功一样。
• 客服人员直接对暂时性失败实施重试逻辑。
• 使用工具名称、经过消毒的输入参数和结果，从客户端记录每个 MCP 工具调用。当工作流没有产生预期结果时，这种客户端跟踪与服务器端日志相结合是诊断客服人员为什么采取特定操作路径的主要机制。

安全注意事项

• 所有出站 MCP 服务器连接都通过网关。网关强制执行身份验证、速率限制以防止工具滥用，以及负载检查以检测工具参数中的提示注入尝试。从客服人员到 MCP 服务器的未经中介的直接连接绕过这些控制，是不允许的。
• 将每个客服人员的 MCP 服务器连接范围限定为该客服人员实际需要其工具的服务器。配置为访问所有可用 MCP 服务器的客服人员的攻击面比仅连接到其定义的任务所需的工具的攻击面更大。
• 在将工具输入参数传递给工具之前，对其进行验证和消毒，特别是在参数值来自用户提供的文本或 LLM 生成的内容时。不要直接将未经验证的 LLM 输出作为工具参数传递；可以影响客服人员推理的攻击者可以使用该路径将恶意值注入下游系统调用。
• 将客服人员的连接 MCP 服务器列表及其工具库存视为敏感配置。知道客服人员拥有哪些工具以及他们接受哪些参数的攻击者拥有旨在滥用这些工具的即时注入负载的映射。

示例

销售客服人员在高价值客户致电前准备全面的客户简报：

1. 客服人员收到请求：“在明天的续订讨论之前，准备关于 Acme Corp 的简报。”
2. 客服人员查询 MCP 工具目录，并跨两个 MCP 服务器识别三个相关工具：GetRecentEmails、GetOpenOpportunities 和 GetSupportTicketSummary。
3. 客服人员并行调用所有三个工具。每个 MCP 服务器将调用翻译为目标系统的本地 API，检索相关数据，并返回结构化结果。
4. 客服人员会收到 3 个结果。最近电子邮件线程、包含交易规模和阶段的未处理续订业务机会，以及按优先级划分的未处理支持票证摘要，并将其综合为结构化的客户简报。
5. 客服人员调用CreateAccountNote将简报保存到客户记录，并向请求用户返回汇总。
6. 网关会记录所有四个 MCP 工具调用，其中包含会话审计记录的工具名称、服务器身份和结果。

上下文

出站 MCP 模式描述了 Agentforce 客服人员使用外部 MCP 服务器中的工具。入站模式会反过来。CRM 记录、流、Apex 逻辑和 Data 360 见解等 Salesforce 平台功能公开为 MCP 工具，运行在任何 LLM 框架上的外部客服人员可以发现和调用这些工具。

这种模式很重要，因为企业 AI 部署很少是单一供应商。基于不同框架构建的合作伙伴客服人员可能需要在 Salesforce 中查找客户的客户状态。运行基于 Python 的客服人员的内部数据科学团队可能需要触发 Salesforce 流来启动审批流程。如果没有标准化的曝光机制，每个外部消费者都需要定制集成。将 Salesforce 功能公开为 MCP 服务器，为每个兼容 MCP 的客服人员提供了与平台工具的统一、可发现的界面，无论调用客服人员如何构建。

例如，基于第三方框架构建的合作伙伴采购代理需要在批准采购订单之前在 Salesforce 中验证供应商的合同状态。它调用 Salesforce MCP 服务器上的GetContractStatus工具，而不是构建直接的 REST 集成。该工具实施与任何本地 Salesforce 操作相同的访问控制；调用客服人员仅查看结果。

问题

当构建在不同框架上的、由合作伙伴拥有的、或者在 Salesforce 平台之外运行的外部客服人员需要调用 Salesforce 功能作为其自己的工作流的一部分时，如何以一种标准化的、可发现的和安全治理的方式公开这些功能，而不需要为每个外部消费者定制集成？

武力

应用此模式时，请回答以下问题：

• 需要使用 Salesforce 功能的外部客服人员是否构建在支持 MCP 标准的框架上？如果没有，REST API 或 Webhook 方法可能比 MCP 更合适。
• 哪些 Salesforce 功能需要公开 - 只读数据检索、写入操作、流调用或组合？暴露范围直接决定了必须控制的安全表面积。
• 应如何验证外部呼叫客服人员的身份，其调用应在哪些 Salesforce 权限下运行？客服人员对平台的调用不得继承比特定操作所需的权限更广泛的权限。
• Salesforce MCP 服务器面向内部消费者（同一组织内的其他团队的客服人员）还是外部消费者（合作伙伴和客户客服人员）？Trust 模型和身份验证要求在这些受众之间差异很大。
• 随着时间的推移，公开工具集将如何演变？添加到 MCP 服务器的新 Salesforce 功能可立即被所有连接的客服人员发现；必须通过谨慎的发布流程控制意外的工具暴露。

Salesforce 模式应用程序

草图

作为可调用工具的业务功能顺序图

结果

Salesforce 成为多供应商客服人员生态系统中的一流参与者。外部客服人员可以发现和使用平台功能，而无需每个消费者或每个用例的自定义 REST 集成。消费者数量可以增长，但集成维护开销不会按比例增长。

通过无头 360，Salesforce 权限模型控制每个入站工具调用。外部 MCP 客户端不会绕过现有数据访问控制；它们可在其中操作。这意味着通过 MCP 公开功能的安全状况相当于通过任何其他经过身份验证的 API 表面公开它们。

工具可发现性是一项复合优势。随着新的 Salesforce 功能添加到 MCP 服务器的工具目录中，它们将立即对所有连接的外部客服人员可用，而无需这些客服人员更新配置。

设计注意事项

与平台无关的指导

• 仅发布外部客服人员需要的内容。添加到 MCP 服务器目录的每个工具都会扩大攻击面和治理负担。有意审核工具库存。定义哪些功能被批准供外部使用，并将未批准的暴露视为配置差距，而不是默认值。
• 为外部消费者编写工具描述。外部客服人员的运算符不Knowledge的内部数据模型或命名约定。保持描述自包含：工具的功能、每个参数的含义、结果代表什么，以及调用者必须满足的任何约束或先决条件。
• 在输入或输出模式更改时明确使用版本工具。如果模式更改，恕不另行通知，则依赖于工具当前模式的外部客服人员将静默中断。对 MCP 工具界面的破坏性更改与对公共 REST API 的破坏性更改具有相同的规则。

Salesforce 实施说明

• 在最终用户下运行每个入站 Salesforce 现成 (OOTB) MCP (Headless 360) 工具调用，该用户的权限范围仅限于公开工具所需的操作。请勿以高权限管理员身份运行入站客服人员呼叫。
• 要在所有 MCP 工具中一致应用身份验证、速率限制、模式验证和个人身份信息 (PII) 检测，请使用 MuleSoft 全方位网关等 AI 网关。
• 对于 MuleSoft MCP 门面，在 MuleSoft 中定义 MCP 工具模式，独立于基础 Salesforce API 模式。MCP 界面应反映呼叫客服人员的概念需求，而不是支持它的 Salesforce 对象的形状。这种解耦允许 Salesforce 实施在不破坏外部工具合同的情况下不断发展。

错误处理和恢复

• 工具调用失败必须返回带有机器可读代码和简单语言描述的结构化 MCP 错误响应。调用外部客服人员无法查看 Salesforce 平台的内部，例如错误消息必须独立且可操作，无需Knowledge特定于 Salesforce 的错误代码或对象模型。
• 必须及时返回速率限制错误和身份验证失败，并提供足够的信息，以便外部客服人员的操作员诊断和补救哪个速率限制已达到，或者哪个凭据被拒绝，而不会暴露内部配置详细信息。
• 使用呼叫客服人员的身份、调用的工具、输入参数（对敏感值进行消毒）和结果，记录全方位网关的所有入站 MCP 工具调用。此日志是诊断外部消费者报告的故障和审计外部客服人员访问内容的主要证据跟踪。

安全注意事项

• 每个入站 MCP 连接必须在可访问任何工具之前进行身份验证。不允许未经身份验证发现工具目录；公开的功能列表本身就是敏感信息。
• 除了连接级身份验证之外，应用工具级授权。注册的外部客服人员应只能调用已明确授予访问权限的特定工具，而不能调用完整目录。在网关而不是应用程序层强制执行。
• 在将所有入站工具参数传递给 Salesforce 平台操作之前，请对其进行验证和消毒。来自外部客服人员的参数是不可信的输入表面 - 恶意构建的参数可能会尝试覆盖查询筛选器、注入 Salesforce 对象查询语言 (SOQL) 片段或影响流变量。在 MCP 服务器或正面边界验证类型、格式和范围。
• 对注册的外部消费者进行定期访问审查。撤销不再有效或访问范围已更改的客服人员的凭据。停用的合作伙伴集成的休眠但有效的凭据是不必要的长期风险。
• 通过在网关中限制入站 MCP 消息的速率，防止违反平台限制。使用基于 SLA 的分层策略，控制非关键客服人员加载时的流量。

示例

物流合作伙伴运营的采购代理需要在批准高价值采购订单之前验证供应商的合同和信用状态：

1. 合作伙伴的客服人员使用注册的 OAuth 2.0 客户端凭据对网关进行身份验证，并收到范围访问令牌。
2. 客服人员查询 Salesforce MCP Server 的工具目录，并识别两个相关工具：GetSupplierContractStatus 和 GetAccountCreditSummary。
3. 客服人员使用供应商的标识符调用GetSupplierContractStatus。MCP 服务器将其转换为 Salesforce 记录查询，应用集成用户的字段级安全性，并返回合同的当前状态、到期日期和任何标记的合规保留。
4. 客服人员调用 GetAccountCreditSummary，它通过 MuleSoft MCP 门面路由。正面从两个 Salesforce 对象汇总供应商的未偿发票余额和付款历史，并返回单个复合信用汇总。
5. 有了这两种结果，合作伙伴的客服人员确定合同有效，信用状况在可接受的范围内，并在自己的系统中批准采购订单。
6. 网关记录了这两个工具调用，其中包含合作伙伴客服人员的身份、调用的工具以及创建可审计记录的结果，记录授予了哪些外部访问权限以及返回了哪些数据。

上下文

企业系统现在依赖于协作客服人员群或网络，其中复杂的请求被分解并委派给跨不同域或供应商平台的专业客服人员。这些客服人员都有自己的角色、能力和工具，他们需要一种标准化的安全通信方法，以协调实现共同目标，而无需每一步的人工干预。

问题

调用 AI 客服人员如何动态发现、安全地交互复杂或特定于域的任务，并将其委派给远程对等客服人员，这些任务可能构建在不同的框架上或由不同的供应商操作，并接收结构化结果来完成更大的企业工作流？

武力

应用此模式时，请回答以下问题：

• 使用不同框架开发的客服人员或跨孤立的应用程序资产操作的客服人员如何交互？
• 客服人员如何在不公开内部逻辑、内存或专有工具的情况下协作和委派任务？
• 客服人员如何在提供实时状态更新、流和推送通知的同时支持复杂、长时间运行的任务？
• 客服人员如何为跨客服人员通信强制执行企业级安全性（身份验证、授权）和策略遵守？
• 客服人员如何处理超出简单 API 调用的结构化任务工作流（启动、进度、完成）？

Salesforce 模式应用程序

A2A 协议是一个开放标准，它使客服人员能够发现、委派其他客服人员作为对等方并与之协作。它为客服人员提供了一种通用语言，以安全地在不同平台和供应商之间交换信息并协调行动。A2A 侧重于对等通信，是对 MCP 的补充，MCP 侧重于将客服人员连接到工具和 API。

草图

该架构涉及呼叫客服人员发起通信，由客服人员目录/注册表进行发现：

跨客服人员委派的顺序图

对等客服人员使用特定于域的逻辑、内存和工具处理请求，然后向调用客服人员返回结构化结果。

结果

A2A 委派将域所有权与工作流编排分开。呼叫客服人员不需要知道对等客服人员是如何构建的，在什么平台上运行，或者在内部使用什么工具；它委派任务并接收结构化工件。此边界意味着，专家客服人员（后台验证、财务风险评分、物流路由）可以独立于调用它的工作流进行开发、部署和改进。

协议的任务生命周期模型（已提交、正在处理、已完成、失败）支持
本地长时间运行的操作。呼叫客服人员可以注册状态更新，而不是
而不是保持阻止连接，这意味着 A2A 任务可以跨越几分钟或几小时
而无需编排客服人员始终处于活动状态。

设计注意事项

与平台无关的指导

• 在复杂场景中，客服人员代理可以充当智能路由服务或“智能总机”，以协调专业客服人员之间的任务委派并管理多步骤流程。
• 由于 A2A 支持长时间运行的任务，通信必须面向任务完成，定义任务对象的生命周期，并提供实时状态更新和通知。
• 该协议旨在支持各种内容类型，包括文本、文件、结构化数据、音频和视频流。
• 客服人员及其功能之间的关系和依赖性在配置文件（例如，“agent-network.yaml”）中声明性定义，并发布到客服人员注册表。

Salesforce 实施说明

• 为了进行有效的 SOMA 编排，请将连接的子客服人员保持在 7 以下，以保持路由质量。
• 目前，仅支持单委派层（超级客服人员 → 子客服人员）；更深的链会将延迟推到“无法维持的速度”。目前，子客服人员无法委派给其他连接的子客服人员。
• 只有编配员级别支持人工切换；子客服人员无法升级。
• 在 SOMA 中，当基于 LLM 的路由在确定性路由的不明确输入上产生错误路由时，请使用客服人员脚本。客服人员脚本启用客服人员之间的策划共享上下文。

错误处理和恢复

A2A 协议定义了全面的错误代码，以促进强大的调试和错误管理。

• **恢复逻辑：**客服人员应包含重试策略（重试）、故障转移逻辑到其他有能力的客服人员，以及显式超时。
• **任务状态跟踪：**任务管理工作流确保客服人员可以与任务的最新状态保持同步，便于在中断时恢复。
• **可观察性：**记录交互详细信息，例如延迟、成功率和错误频率，对于监控质量和故障排除至关重要。

安全注意事项

• **企业级身份验证：**A2A 旨在与企业级身份验证和授权标准保持一致，例如 OAuth 2.0 和 JWT，通常由 Okta 等外部平台管理。
• **保护 A2A 的网关：**网关（例如 MuleSoft 全方位网关）对于在所有 A2A 通信上强制执行策略至关重要，它既是入口网关又是出口网关，用于保护客服人员并控制到外部客服人员和服务的出站流量。
• **策略执行：**客服人员卡重写、模式验证、峰值控制、PII 检测器和其他策略应用于 A2A 服务器和数据保护。

示例

候选采购工作流

招聘经理责成他们的中央编配员客服人员寻找与工作列表和技能集匹配的候选人。

1. **发现：**编配员客服人员查询客服人员注册表，并发现专门的招聘客服人员和背景调查客服人员（均为对等客服人员）。
2. **委派 (A2A)：**编配员客服人员向招聘客服人员发送结构化任务请求（A2A 消息），以寻找候选人。
3. **对等处理：**招聘客服人员执行自己的工作流（例如，通过 MCP 调用外部 LinkedIn 工具）。
4. **退货 (A2A)：**招聘客服人员返回建议候选人的列表（工件）。
5. **顺序委派：**然后，编配员客服人员将另一个任务 (A2A) 委派给热门候选人的背景检查客服人员。该客服人员执行检查并返回结果，完成整体任务。

上下文

复杂的企业工作流通常需要托管在外部平台或合作伙伴系统上的专业客服人员来启动任务、委派查询或向内部客服人员（例如，Salesforce 平台上的客服人员）提供更新。此模式解决内部 Agentforce 客服人员如何安全可靠地接收和处理来自远程对等客服人员的请求，以执行特定于域的功能。

问题

内部专用 AI 客服人员(例如 Agentforce 上的背景检查客服人员)如何安全地向外部对等客服人员公开其特定于域的功能、处理传入的结构化 A2A 请求并管理任务生命周期(包括实时状态更新)以将结构化工件返回到远程调用客服人员?

武力

应用此模式时，请回答以下问题：

• 您如何安全地向外部客服人员公开内部客服人员功能，而不损害内部逻辑或工具？
• 您如何强制执行企业级安全策略，以便在处理请求之前验证呼叫客服人员的身份和授权？
• 您如何处理长时间运行的入站任务，同时提供结构化的异步状态更新？
• 您如何确保与构建于多种外部框架的客服人员进行无缝交互？

Salesforce 模式应用程序

A2A 协议为安全的对等委派和协作提供了开放标准。内部客服人员充当对等客服人员，通过客服人员目录/注册表宣传其功能，并通过安全渠道使用 A2A (HTTPS/SSE) 接收和响应结构化请求。

草图

客服人员作为可呼叫服务的顺序图

结果

此模式将内部客服人员公开为多客服人员网络中的专用服务。外部客服人员可以安全地将任务委派给内部功能，同时组织保持控制、可审计性和策略实施。

设计注意事项

与平台无关的指导

• 网关（例如 MuleSoft 全方位网关）必须定位为入口点，以在所有传入 A2A 请求上强制执行策略，包括速率限制、身份验证和负载验证。
• 内部客服人员必须管理任务对象从外部启动到完成的状态，确保远程呼叫客服人员收到一致、可验证的状态更新。
• 确保客服人员在客服人员卡中发布的功能清晰、基于意图，并包含必要的委派安全范围。

错误处理和恢复

• **结构错误代码：**在失败时，内部客服人员必须向调用客服人员返回符合 A2A 标准的结构化错误消息，以启用远程重试逻辑或备用故障切换机制。
• **幂等：**客服人员必须验证由外部客服人员重试的 A2A 请求触发的任何副作用（由于网络中断或恢复）是否无效。

安全注意事项

• 入站策略实施:网关必须强制执行允许列表/阻止列表外部客服人员和验证 JWT/OAuth 2.0 令牌的策略，以验证_呼叫客服人员_的身份和委派权限。
• **输入消毒：**验证并清理所有传入请求负载，以缓解潜在的提示注入或恶意数据攻击。
• **身份传播：**在对内部系统执行操作之前，将外部客服人员的身份及其委派的权限安全地映射到内部安全上下文（例如，Salesforce 用户简档）。

示例

外部系统查询

1. **请求：**合作伙伴系统上的招聘客服人员向 Agentforce 上的内部员工验证客服人员(对等客服人员)发送 A2A 任务请求，以确认新候选人的就业状态。
2. **正在处理：**员工验证客服人员通过网关接收请求，验证合作伙伴客服人员的凭据，执行其内部工作流（例如，调用内部人力资源系统），并格式化响应。
3. **回复：**对等客服人员向远程招聘客服人员返回结构化 A2A 工件（例如，就业开始日期和职务），然后远程招聘客服人员继续执行其外部工作流。

1. 用于保护 MCP、A2A 和 API 的网关

   所有客服人员到系统和系统到客服人员的流量都需要网关作为单一实施点。

• 安全连接:网关通过限制访问来确保只有经过身份验证和授权的客服人员与 MCP、A2A 和 API 端点交互。

• **强制 SLA：**网关可以强制执行速率限制，帮助组织满足性能要求，并防止 MCP 和 A2A 服务器过载。

• **简化治理：**网关提供了对所有服务器交互的集中可见性和控制，简化了客服人员的活动管理和监控。

• **数据一致性和保护：**策略（例如模式验证）强制数据一致性，PII 检测可以保护敏感信息。

MueleSoft 全方位网关

2. 身份传播链

随着企业采用代理模式，出现了一个新的安全挑战：最终用户身份如何通过自主 AI 客服人员网络？在传统 API 架构中，用户验证一次，应用程序代表用户调用后端服务。身份链简短，易于理解，通常在单个 Trust 域中管理。

然而，客服人员架构具有更长的链，其中单个请求会跨多个客服人员、服务和 MCP 服务器扇出，每个服务器都可能跨越服务边界、Trust 域，甚至组织边界。如果没有审慎的身份传播策略，企业将面临安全和功能之间的选择，这是架构师不需要解决的难题。

MuleSoft 通过其受信客服人员身份功能解决了身份传播的复杂性。此解决方案使用基于策略的网关受管策略，以确保最终用户身份在各种交互类型中得以维护，包括 A2A 协议、MCP 工具调用和 REST API 请求。通过出站身份验证策略在全方位网关层集中身份管理，企业可以保护整个客服人员网络的安全，而无需修改后端服务或客服人员。有关更多详细信息，请查看客服人员企业的受信客服人员身份。

3. Data 360 中的 RAG 安全性

Data 360 通过数据治理策略设置，在对象、字段和行级别支持基于属性的访问控制 (ABAC)。这是控制哪些数据对谁可见的主要方法，包括在 RAG 搜索索引中。对于结构化数据，使用用户属性和权限集实施用户访问条件。对于非结构化数据，元数据筛选（搜索索引上的预筛选）可以限制检索的内容。

与 LLM 的通信通过 Einstein Trust 层进行，该层在机密/PII 信息到达模型之前对其进行屏蔽，不仅在搜索期间而且在生成之前保护数据隐私。

为了防止 RAG 中毒，请确保在数据可用于向量搜索之前应用严格的数据治理和验证规则。Einstein Trust 层也可以强制实施即时掩码/毒性检查。您可以对客服人员用户简档应用严格的权限集。

4. 新命名凭据模型 Salesforce 已经通过引入一个两层命名凭据模型来改进其身份验证架构，该模型将连接和身份之间的顾虑清楚地分开。每当通过 Apex 进行标注时，请使用此选项，并避免创建自己的身份验证协议。该模型还提供了可扩展性和增强的安全性。 外部凭据是该模型的基础。它们存储实际的身份验证详细信息，并支持丰富的协议集，包括 OAuth 2.0 客户端凭据、JWT 不记名和 AWS 签名 V4，同时还定义了主体的映射方式：作为单个命名主体（在所有用户之间共享）或作为每个用户主体（其中每个用户使用自己的身份进行身份验证）。 命名凭据又充当端点层。它们定义标注 URL 并引用外部凭据来处理身份验证握手，使端点配置与凭据管理保持干净分离。 为了启用每个用户的身份验证流，管理员将权限集映射到适当的外部凭据主体，以便只有具有正确权限集分配的用户才能使用他们自己的身份调用标注。这种两级设计不仅简化了安全标注配置，而且为架构师提供了更大的灵活性和治理控制，以了解如何跨 Salesforce 连接的系统进行集成身份验证。有关更多详细信息，请查看命名凭据文档。

本节将架构的数据处理模式映射到受管企业部署中最常遇到的合规义务。

**访问控制：**在整个集成模式（命名凭据范围、每个客服人员 OAuth 2.0 范围、网关允许列表）中描述的最小权限集成用户模型直接映射到逻辑访问控制。保留每个客服人员的凭据范围已审核和批准的证据。

**审计日志记录：**每个模式的审计日志记录要求（会话 ID、工具调用、敏感值消毒的输入参数、结果）满足监控和日志记录控制。确保日志防篡改，保留所需时间，安全团队可以访问，而无需访问生产系统。

**变更管理：**影响使用者的 MCP 工具模式更改和 A2A 客服人员卡更新会构成界面更改，并应受更改管理控制。明确版本工具（在 MCP 入站模式中提及），并将破坏性更改视为需要批准的配置事件。

**可用性：**客服人员并发限制、事件触发模式的重试上限以及失败事件的死信路由构成了可用性控制。作为可用性证据软件包的一部分，记录每个已部署模式的预期吞吐量信封和失败行为。

备注:此列表不代表确保您的代理解决方案合规性的完整指南。必须满足所有适用的法规要求。

• 客服人员 API 入门指南
• 使用 Data 360 启用受信客服人员
• MuleSoft 全方位网关概览
• OAuth 2.0 代表凭据注入策略
• 客服人员企业的受信客服人员身份

Gulal Kumar 是 Salesforce 的软件工程架构师，拥有超过 20 年的经验。他的专长涵盖 AI、集成、API 和企业架构，专注于通过安全、弹性和创新的 AI 解决方案推动业务转型。在 LinkedIn 上与他联系。