确定客服人员和传统工作流自动化

借助 Agentforce,企业现在可以为不容易简化为规则的自动化工作释放新的范式。这些新功能包括从非结构化对话中解析客户意图，协调跨系统的多方流程，并实时响应运营条件。客服人员工作流使用旨在推理结果的自动化，而不是执行预定义的步骤。满足这一需求需要一个跨所有自动化复杂性的平台，以及一个显示每种功能适合位置的框架。

Agentforce 将 Einstein Trust 层、推理引擎、客服人员脚本、流、Apex 和 Data 360 整合到一个统一平台中。这种组合可以处理从简单的记录触发器自动化到跨语音、视觉、文档和实时遥测的复杂多客服人员编排的所有事情。MuleSoft 通过连接整个企业的客服人员工作流所需的 MuleSoft 结构、治理和跨系统编排来扩展该平台。Agentforce 运营（以前的 Agentforce 供应链）将这些功能应用于运营和制造流程的特定需求。

本指南介绍了编排密度框架和指南，以便在此产品布局中做出明智的决策。该框架为架构师提供了一种可重复的方法，以使用 Salesforce 平台上智能自动化用例的密度级别选择合适的工具和模式。

Agentforce 代表了 Salesforce 平台上工作方式的根本转变，从基于规则的自动化到基于推理的工作流。为了释放它的潜力，架构师必须就客服人员适合的位置、他们的组成方式以及他们的编排做出审慎、明智的决定。以下原则为客服人员决策提供了可重复的指导。

• **为正确的任务使用正确的工具。**使用基于执行路径、模态组合和目标复杂性的编排密度来确定最佳拟合解决方案。

  • 将带流的传统自动化和 Apex 用于基于规则的确定性工作，其中的结果可以由一组规则完全限定和定义。传统的自动化导致静态执行路径，这保证了结果的可预测和可重复，并且对于可审计性至关重要。对于需要严格遵守和法律合规的任务，选择传统自动化。

  • 将 Agentforce 网格用于低到中等编排复杂性的批量推理用例。此模式使用单轮生成式推理对大量 CRM 记录中的数据进行分类、评分或汇总，确保高吞吐量执行和即时审计。

  • 对于目标未定的任务，使用Agentforce 和 Agent Script，已知目标结果，但在设计时无法指定确切的执行路径。将此模式应用于需要通过指导确定性进行推理的要求，以确保结果可预测和可追溯。

  • 使用 Agentforce 操作，通过支持 AI 的供应链工作流管理，简化和自动化协作业务流程。

• **避免将代理工作流应用于低组织密度用例。**评估功能和非功能需求的传统自动化和代理自动化之间的权衡。传统自动化可以提供用例所需的规模、可靠性和性能。

• 采用客服人员自动化混合方法,将 Agentforce 和传统自动化与 Flows 和 Apex 结合起来,当这种协同作用比单独使用客服人员或传统自动化具有更大的价值时。

Salesforce sObject 传统上是记录自动化的主要入口点。系统根据规则执行逻辑，并在数据操纵语言 (DML) 事件（例如插入、更新或删除）后立即开始。为了在高效的记录触发自动化工具之间做出决定,我们引入了自动化密度作为衡量系统复杂性的手段,考虑了自动化数量、记录量和依赖性蔓延。传统的自动化受到将数据导入结构化、符合模式和基于规则的构造所需的大量前期工作的限制。

客服人员自动化使用用户意图或非结构化数据作为输入来升级传统自动化，在这些输入中可以应用推理来达到期望的结果。架构师必须决定何时对多模态非结构化数据使用概率推理，以及何时实施引导式、确定性工作流来降低不可预测的结果的风险。

当需求从执行基于规则的步骤转移到推理到结果时，架构师需要一个标准化的框架来评估建议的解决方案的推理深度和目标复杂性。

编排密度是客服人员工作流中复杂性的度量。三个因素决定了编排密度：执行路径、目标复杂性和模态组合。自动化密度衡量系统规则和容量的物理复杂性，而编排密度衡量客服人员实现目标的路径的推理复杂性。使用复合编排密度来评估您的设计要求，并映射到建筑标准。

• 执行路径:工作流在设计时可以完全限定和指定的程度。完全指定的工作流意味着工作流定义了导致预定执行路径的每个分支和结果。不可指定的工作流有一个路径，可以在运行时根据上下文数据和指令进行推理。
• 目标复杂性:工作流必须在运行时解决的不同结果、决策点和路径变体的数量。低复杂性工作流处理具有预定结果的单个包含的任务，而高复杂性目标跨越多个阶段，具有在设计时无法预期的边缘个案的竞争或冲突目标。
• 模式组合:工作流必须处理的输入类型范围，以及必须生成的输出表单。低模态组合读取标准 CRM 字段并生成记录更新。中等模式使用结构化 CRM 字段和静态非结构化数据（例如电子邮件正文或个案脚本）的组合来生成记录更新。高模态组合消耗动态实时流，例如实时音频或遥测，并跨多个外部系统产生多模态输出。

确定适当的编排密度级别需要按顺序评估执行路径、目标复杂性和模态组合。首先检查执行路径。如果路径可以完全指定，请从传统的自动化开始。使用客服人员解决方案来编排和执行没有任何推理要求的确定性路径是一种反模式。它会导致客服人员蔓延（过度、不受管的 AI 客服人员扩散）和客服人员流失（低质量、不必要的 AI 生成的输出），导致低价值回报。

对于部分或不可指定路径，继续评估目标复杂性。如果目标复杂性定义良好，但路径上的某些节点需要概率评估，请考虑从 Flow 或 Apex 调用客服人员，以满足特定的本地化需求。相反，如果执行路径中的步骤需要跨大量记录的一个或多个 AI 驱动的要求，请考虑 Agentforce 网格。网格支持通过多个 AI 或客服人员列的多步骤、基于表单的工作流。它最适合批量、面向行的执行。这种方法确保工作流保持高性能和可审计性，仅在路径无法预定义时调用概率推理。

随着竞争维度（例如，确定保险索赔赔付以及欺诈检测、合规和客户满意度）和不特定的执行路径，目标复杂性增加，请考虑使用 Agentforce 和 Agent Script 实现自动化中的指导确定性。对于涉及 Salesforce 和第三方系统的跨企业用例，使用 MuleSoft 交换矩阵和客服人员代理。

最后，评估模态组合，以确定必要的技术能力，例如多模态连接或专门集成。模式混合用作功能选择器，而不是密度计算器。它有助于确定处理解决方案的输入和输出形状所需的基础设施，而不改变其基本编排逻辑。

使用此矩阵来确定客服人员自动化的架构标准。通过选择解决自动化问题的方法，平衡传统自动化和客服人员自动化。

• **传统自动化(低编排密度):**当流程由记录更改触发、数据结构化、逻辑基于规则和预先确定，并且结果必须是可预测的（例如，标准价格计算或自动任务创建）时，使用传统的自动化。
• **Agentforce 网格（低到中编排密度）：**当必须处理现有记录中的批量 AI 任务时，使用 Agentforce 网格（例如，汇总此列表中每个客户的最近 50 个个案，计算情绪得分，并在个案字段中保留得分）。
• **混合编配(高阶增强自动化 ) :**在自动化复杂的端到端业务流程(例如索赔处理或入职培训)时，请使用混合编排，该流程需要 AI 的规划功能，但需要 Flow 和 Apex 的事务完整性。
• **Agentforce 客服人员脚本（意图复杂性高）：**当入口点是非结构化的（例如，聊天、电子邮件和语音）并且解决方法需要对话或能够处理不明确的用户请求时，请使用客服人员脚本。

此表为各种用例提供了一般最合适的推荐。

延迟

同步记录触发的流在平台事务中执行，并在毫秒内完成。Agentforce 推理时间取决于 Atlas 推理引擎，并随推理深度和模态复杂性而变化。Agentforce 不适用于高用量同步记录处理，其中延迟是主要约束。

成本

代理工作流的推理成本必须根据结果的业务价值进行证明。对于存在确定性路径的高用量、低编排密度任务，传统的自动化或 Agentforce 网格可能比端到端的客服人员工作流更经济。确保设计适应具有明确最大重试限制和中断的正确重试模式。此防护栏限制了与批量处理相关的复合成本超支风险。

州长限制

根据异步执行的日常平台限制，评估高用量客服人员工作流。Agentforce 网格批处理操作遵循标准平台事务限制。对于涉及 Salesforce 对象的自动化，请考虑每日 DML 操作总数，因为 Salesforce 在多租户环境中强制执行共享资源管理，并强制执行管理者限制，以防止失控自动化独占共享资源。

可审计性和合规性

传统自动化通过流触发器资源管理器和 Apex 日志产生完全可审计的执行跟踪。基于 Agentforce 的端到端或混合模式生成推理日志，为客服人员决策提供透明度，但需要专业知识来解释。对于完全执行可审计性是合规要求的受监管行业，通过客服人员脚本进行指导确定性是推荐的模式。

升级

高密度运行的客服人员工作流应包含明确的人工批准或上报门限，以处理具有不可逆后果的操作，例如财务交易、监管提交或供应商承诺。客服人员脚本条件控制提供了在其他客服人员工作流中确定性地强制执行这些大门的机制。

**在编排设计中优先考虑简单性。**从实现目标的最小编排级别开始，在真实负载下验证，并迭代。链中的每个额外的客服人员、切换或依赖性都会引入一个新的表面，这会产生不一致的行为。

在指定的执行路径中，在需要推理的节点上，开始嵌入客服人员。遵循在 Agentforce 中构建客服人员的最佳实践。避免打包大量子代理（以前称为“主题”），并且不要使用臃肿的指令。在自动化用例中部署的客服人员能够做到精益求精，因为他们不是唯一的界面。为链接选择正确的基元。编配（委派）模式对执行顺序的控制更严格，可以将子任务委派给专家。避免编排（切换）模式。如果您必须实施切换设计，请为接收客服人员提供目标、上下文和状态，以便它可以全局优化，而不是本地目标。

避免操作或工具蔓延。操作是实现客服人员推理的地方，操作的设计决定了操作是产生可靠的结果还是失败。每个操作必须返回结构化的可观察响应，AI 客服人员可以使用该响应来计划对话的下一个回合。

让多个操作（和不同的输出结构）执行相同的任务会降低客服人员推理或选择适合作业的工具的能力。这可能会导致客服人员错过细微差别。重叠操作定义存在错误分类的风险。确保您的操作库经过审核、版本化并符合子代理（以前的主题）范围。

**定义可观察的目标。**将目标定义为可观察的结果，而不仅仅是程序。模糊的目标会引发客服人员流失。使用可指定的执行路径进行扩充。使用具有混合推理的客服人员图，将目标建模为具有显式状态的图节点。运行时跟踪客服人员在工作流中的当前位置，并在切线输入后恢复；当在上下文窗口中收到其他信息时，它不会丢失目标。

测试和评估。实施强大的测试和评估框架，以验证概率节点的推理和客服人员自动化的输出。根据预期的结果路径验证执行路径，以确保模型获得正确的结果。通过在执行步骤中声明结果，防止客服人员误报成功或进入无限或不可恢复循环的静默失败。使用会话跟踪来检查逐次交互、推理引擎执行、操作、提示和网关输入/输出、错误消息和最终响应。

关于作者

Arvind Palaniswamy 是首席架构师办公室良好架构团队的软件工程架构师。他喜欢使用第一原则以最简单的形式构建复杂的系统。凭借数十年的经验和硕士/工商管理硕士(凯洛格)教育,他懂工程、运营和业务。