Agentic Enterprise 的可靠性

客服人员企业的可靠性

自主客服人员引入了与传统 Salesforce 自动化根本不同的非确定性执行模式。虽然 Salesforce Flow 和 Apex 遵循在受控条件下产生可重复结果的可预测路径，但客服人员会动态地推理问题。例如，两次提问的同一个问题可能会采用不同的执行路径，消耗不同的资源，并产生不同的结果。这种非确定性带来了传统测试和监控方法无法应对的可靠性挑战。

客服人员可靠性故障模式与 Salesforce Flow 或 Apex 故障完全不同。大语言模型 (LLM) 推理服务代表外部依赖性，其可用性特征独立于 Salesforce 平台。尽管有提示说明，客服人员生成的响应偶尔会违反预期结构。客服人员上下文准备会不可预测地消耗调控器限制。无边界数据检索对客服人员的影响更严重，因为客服人员可以请求开放式上下文，而确定性查询具有明确的范围控制。

可靠的客服人员架构需要多层次的后备链，这种后备链可以优雅地降级 — 从复杂的客服人员，到上下文简化的简单客服人员，再到确定性规则引擎，最后到通过全方位进行的人工切换。平台事件通过检查点模式支持持久的重试队列，允许失败的工作流从上次成功的步骤恢复。断路器在平台缓存中跟踪 LLM 服务运行状况以了解实时状态，并以阈值和配置的自定义元数据类型为后盾，在连续失败后路由到后备模式。监控需要跟踪对话成功率、平均故障间隔时间 (MTBF)、平均恢复时间 (MTTR) 和接地准确性。Agentforce 可观察性提供会话跟踪、运行状况和延迟度量以及升级和转移率，但您仍然需要自行测试可靠性度量，例如 MTBF、MTTR 和接地精度。

本文档涵盖了客服人员在照片中时的变化。有关适用于所有 Salesforce 解决方案的基础可靠性模式(服务级别对象 (SLO) 设计、容错、扩展和监控 ) , 请参阅可靠性支柱。

Agentforce 客服人员的失败方式不同于 Salesforce Flow 或 Apex。了解这些故障模式是塑造可靠性架构的因素。

  • **LLM 服务不可用：**LLM 推理端点偶尔会遇到延迟峰值或可用性问题。Agentforce 在 trust.salesforce.com 上与 Analytics 和其他 Salesforce 服务并列为受监测的产品。但是，粒度 LLM 推理延迟和每个请求的性能指标没有公开。通过使用平台缓存实现低延迟实时状态，以阈值和配置的自定义元数据类型为后盾，实施断路器，以跟踪 LLM 服务运行状况。平台缓存是最大的努力 — 条目可以在生存时间 (TTL) 之前被逐出 — 因此将打开/跳闸状态保存在持久存储中，例如自定义对象，而不仅仅是缓存。将跳闸条件调整到端点：连续失败的计数（例如 5 次）或在滚动窗口中超过阈值的错误率。当电路跳闸时，将其打开并路由到后备模式，例如更简单的提示、缓存的响应或人为切换，直到成功的测试请求指示恢复。
  • **响应验证失败：**尽管有提示说明，客服人员偶尔会生成违反预期结构的响应。客服人员有时会返回格式错误的 JSON、忽略必填字段或包含意外的数据类型。平台缓存可以存储经过验证的响应模式，从而实现快速验证。当验证失败时，请用改进的提示重试，包括验证错误和结构正确的示例。设置最大重试次数 (3-5)，以防止无限重试循环。
  • **幻觉检测：**当基础训练数据不完整时，客服人员会产生似是而非的信息。与返回“未找到”的确定性查询不同，客服人员使用推理来填补空白。Einstein Trust 层审计跟踪会记录每个提示、屏蔽提示、响应、毒性检测结果和用户反馈，以供临时治理后审查。但是，它不会捕获逐步推理跟踪。对于逐步推理捕获，使用 Agentforce 会话跟踪，这将记录推理引擎的执行。需要客服人员引用 Data 360（以前称为 Data Cloud）检索扩充生成 (RAG) 检索源。将客服人员索赔与检索到的来源进行交叉引用，以便在操作执行之前发现事实偏差。内联检查几乎不会增加延迟，因为它针对已经在上下文中的源运行。需要单独往返的检查，例如第二次模型调用或外部服务，成本更高。为影响大的写入保留这些检查，包括财务或订单更新，并在实时对话期间异步运行。
  • **州长限制峰值：**客服人员上下文准备会根据对话流不可预测的消耗 Salesforce 对象查询语言 (SOQL) 查询、CPU 时间和堆内存。Proactive Monitoring 是 Salesforce 成功计划中的一项签名成功(以前称为签名支持)权利服务，Salesforce 可在其中主动监控客户账户。Proactive Monitoring 不是对所有客户可用的自助可配置警报。对于自助调控器限制监控，使用 Scale Center 识别接近限制的资源密集型客服人员操作。在检索大型记录集合的客服人员操作中实施分页。对于频繁访问的参考数据，使用平台缓存。
  • **客服人员上下文中的数据偏差：**对于拥有超过 10000 个业务机会的客户或具有相对较大活动历史的个案，客服人员检索上下文时会遇到与批处理 Apex 相同的数据偏差挑战。与您控制范围的确定性查询不同，客服人员推理可以不可预测的方式请求“所有历史”。为防止这种情况，设计具有合理硬限制的客服人员操作（例如，每个父级最多 200 个子级），并在超过限制时实施抽样策略。上限会限制输入客服人员上下文的数据数量。将其与选择性索引筛选器配对，以便查询本身保持便宜，因为偏移父级上的未索引筛选器或聚合会在应用上限之前扫描完整子集。

设计多层后备链，使客服人员能够在能力降低的情况下继续工作，而不是完全失败。

  • **具有完整上下文的主要客服人员：**经验丰富的客服人员，拥有完整的 Data 360 基础、广泛的对话历史和复杂的推理。最高质量，但资源最密集，失败风险最高。
  • **上下文减少的次要客服人员：**使用精简上下文的更简单客服人员（例如，过去 30 天与所有历史、前 5 个向量搜索结果与前 20 个）。更小的上下文意味着更少的令牌、更快的推理和更低的失败机会，但前提是减少的上下文仍然涵盖了任务需要的数据。
  • **确定性规则引擎：**当客服人员推理失败时，处理常见场景的传统 Salesforce 流或 Apex 逻辑。规则无法适应新情况，但它们可靠地处理已知模式。订单验证客服人员返回标准验证规则，而潜在客户评分客服人员返回基于规则的分数计算。
  • **通过全方位进行人工切换：**在自动选项用尽时路由到人工队列。配置基于技能的路由，以确保升级达到适当的专业知识。传递完整的对话上下文，包括尝试的策略、您为客服人员计算的任何置信度分数和失败原因，以实现高效的人工干预。

在平台事件触发的编排 Salesforce 流或 Apex 中实施回退逻辑。每层记录哪个策略成功，创建失败模式和后备有效性的可见性。

本节中的所有平台事件模式都假设了高用量平台事件类型，它们提供了 72 小时的重放保留窗口。标准卷平台事件仅保留 24 小时。将高用量事件类型用于所有客服人员弹性、重试队列和检查点模式，其中重放持久性是可靠性要求。平台事件提供持久的消息传递，使客服人员工作流能够在失败后生存并自动恢复。

  • **检查点客服人员进度：**多步骤客服人员工作流在每个成功步骤后发布检查点事件。合同处理客服人员完成文档提取，使用提取的数据发布 ContractParsed 事件，然后进行条款分析。如果条款分析失败，重放 ContractParsed 事件，以从提取的数据恢复，无需重新分析。当检查点负载携带该数据并且订阅者幂等时，这有效，因为重放会重新传递事件，而不是在中间恢复工作流。在事件负载中存储检查点状态，包括相关性 ID、完成的步骤和继续所需的状态。
  • **具有指数回退的重试队列：**失败的客服人员请求发布到 AgentRetryRequested 事件，负载中包含重试计数。事件订阅者处理具有指数后退延迟的重试（例如，30 秒、2 分钟、8 分钟、30 分钟）。在重试次数最多（通常为 5 次）后，路由到死信队列和警报操作。高用量平台事件保留 72 小时的重放窗口。将高用量事件类型用于客服人员重试队列，以便订阅者在组织维护时段或部署停机后赶上。标准卷平台事件仅保留 24 小时。
  • **事件驱动的编排：**将客服人员工作流设计为松耦合事件链。潜在客户创建发布 LeadCreated。潜在客户评分客服人员订阅、评分并发布 LeadScored。潜在客户路由客服人员订阅 LeadScored，并分配到适当的队列。每个客服人员可以独立失败并重试。单个客服人员故障不会阻止整个工作流 — 下游客服人员会在依赖性恢复时处理。
  • **关联 ID 跟踪：**在所有相关事件负载中包含相关 ID 作为自定义字段。通过使用发布/订阅 API by replayId（不透明、不连续的标识符）重放事件，以在 72 小时保留时段内重建工作流历史。要启用基于相关性 ID 的调试，请实施订阅者侧模式，将传入事件及其 replayId 和相关性 ID 记录到自定义对象，从而实现跨事件可追溯性。此日志记录模式是您自己构建的自定义实施，而不是本机平台查询功能。

将超过同步限制的客服人员操作移到异步上下文，这允许更高的调控器限制和更长的超时。

  • **批量客服人员操作的批量 Apex：**分析 1,000 多条记录的客服人员受益于批处理 Apex，它为每个执行方法提供 200 个 SOQL 查询、150 个 DML 语句（最多 10,000 个 DML 行）和 60,000 毫秒（60 秒）的 CPU 时间。潜在客户评分客服人员处理夜间潜在客户导入。跨历史个案的个案情绪分析。分析完整漏斗的业务机会预测。
  • **多步骤工作流的队列链：**需要多次外部 API 调用、大型数据集分析或延长处理时间的复杂客服人员工作流使用可排队 Apex 链。每个可排队作业获得 60 个 CPU 时间和 12 MB 堆。对于超过单个作业限制的工作流，链接到下一个可排队。跟踪自定义对象中的进度，以便失败的作业可以从上次完成的步骤恢复。
  • **@future 适用于简单的异步切换：**轻量级客服人员操作，例如发送通知、登录外部系统或非紧急更新，使用 @future 方法。当工作流不需要返回结果并且能够容忍失败时，触发和忘记模式就适合。

通过 Apex 作业页面（设置 → Apex 作业）和 Apex 弯曲队列监控异步处理能力。最多 5 个并发批处理作业会限制并行客服人员处理；Apex 弯曲队列中的其他作业会排队，其中最多包含 100 个处于“保持”状态的作业。所有异步 Apex 类型，即批处理、未来、可排队和计划 Apex，在异步 Apex 执行方面共享相同的组织范围每日限制(DailyAsyncApexExecutions)：大于 250,000 或用户许可证数量的 200 倍。当您运行高频客服人员轮讯或重试订阅者队列时，可排队者可以快速耗尽此配额。为了避免这种情况，请对这些队列进行批量或节流，使其保持在限制范围内 — 这适用于所有异步 Apex 类型的组织范围，而不仅仅是作为可排队的单独分配。当消耗接近这些限制时发出警报，以便团队可以主动管理工作量。

通过解决非确定性行为的测试策略，在生产前验证客服人员的弹性。

  • **完全复制 Sandbox 中的负载测试：**使用完整数据量，测试客服人员在生产规模负载下的性能。模拟匹配峰值需求的并发对话。测量 p95 和 p99 延迟，识别压力下的性能下降。验证调控器限制消耗在峰值负载时保持在阈值以下。在数据减少的部分复制 Sandbox 中进行负载测试会产生误导性信心，因为数据量直接影响客服人员的性能。在运行这些测试之前，请从 Salesforce 获得批准（性能测试请求至少提前一周）。可以限制或阻止未批准的测试。
  • **故障注入：**故意引入失败来验证恢复机制。在您的断路器监控的服务层中模拟 LLM 推理故障，以验证断路器是否激活。注入 SOQL 异常，以测试错误处理。测试验证逻辑的损坏客服人员响应。引入数据偏差（包含 10,000 多个子项的客户）来测试分页逻辑。设置激进超时，以测试超时处理和重试策略。
  • **混沌工程：**随机禁用平台事件订阅者，以测试重放恢复。在执行过程中终止异步作业，以测试检查点重新启动。为外部系统引入可变延迟，以测试渐进式超时策略。混沌实验验证了实际故障组合中的弹性。在暂存环境中安排定期混乱日，随着客服人员的发展保持弹性。
  • **长时间运行的稳定性测试：**连续 72 小时以上执行客服人员工作负载，监控依赖于时间的故障。只有在持续运行的情况下,才会出现累积误差和性能逐渐下降的问题。跟踪 CPU 时间趋势，以识别运行中的逐步降级。

定义服务级别指标 (SLI)，实现客观的可靠性测量。在构建客服人员之前而不是在生产失败之后建立 SLO。

  • **对话成功率：**没有错误或超时的情况下完成的客服人员对话的百分比。将优雅的人员交接视为成功，而不是失败 — 升级是设计的最终后备层。根据度量统计失败或意外的升级 — 这是一个有用的可靠性信号，但对用户体验来说是一个不完美的代理，因为礼貌的签名可以掩盖一个未解决的问题。按客服人员类型和用例单独跟踪，因为潜在客户评分成功标准不同于合同审查。当成功率下降到 SLO 以下时发出警报（通常是 95—99%）。
  • **平均故障间隔时间 (MTBF)：**客服人员失败之间的平均工作时间。MTBF 越高，故障越少，可靠性越高。计算为客服人员总工作时间除以失败计数。跟踪每个客服人员类型，以确定需要优化投资的最不可靠的客服人员。
  • **平均恢复时间 (MTTR)：**从故障检测到服务恢复的平均时间。通过平台事件重放和断路器的自动恢复比手动干预恢复服务更快，手动错误更少。降低 MTTR 会降低每个事件的业务影响。
  • **定位精度：**基于源数据验证的客服人员响应事实上正确的百分比。随机客服人员响应示例，以根据 Data 360 源验证声明。定线精度低于 95% 表示存在幻觉问题，需要及时调整或更好的上下文检索。
  • **平台事件重放差距：**错过或未送达的事件计数，例如订阅者在保留时段之外离线。零差距是健康事件驱动架构的积极信号。差距表示订阅者问题、事件发布失败或容量限制。使用上述订阅者侧日志记录模式跟踪这些差距，并将每个事件的 replayId 和相关 ID 记录到自定义对象。

可靠的客服人员来自前期故障设计 — 在构建之前定义 SLI/SLO、调控器限制感知上下文处理和多层后备链，而不是在构建之后将它们固定在一起。分层断路器和基于平台的重试和检查点逻辑，因此工作流会自动恢复，而人为切换是最后的手段。通过系统加载、故障注入和混沌测试来验证该设计，然后在生产中继续监控相同的SLI，以确认它随着时间的推移而保持不变。

主要可靠性支柱中的可靠性指导适用于具有此处涵盖的平台特定注意事项的客服人员。成功的客服人员架构平衡了自主能力与适当的监督，实现了从暂时性故障的自我恢复，同时在信心下降或出现边缘个案时升级。

分享您对良好架构框架的反馈。