客服人员可靠性模式

了解有关架构良好的可靠性的更多信息 → Agent Enterprise 可靠性

模式

何处查看好样的
平台 | 平台缓存✅ 实施断路器，在平台缓存中跟踪 LLM 服务运行状况，进行低延迟实时读取，并以阈值和配置的自定义元数据类型为后盾；由于平台缓存已尽力而为，因此在持久存储（例如自定义对象）中保持打开/跳闸状态，而不仅仅是缓存。在调谐的故障阈值上打开电路（例如，五个连续的推理故障），并路由到后备模式
平台 | 平台缓存✅ 在平台缓存中存储验证的响应模式，以便根据预期结构快速验证客服人员的响应
Agentforce | 提示模板✅ 当响应验证失败时，使用细化的提示重试，包括验证错误和正确结构的示例（最多 3-5 次重试）
Agentforce | 会话跟踪✅ 使用 Agentforce 会话跟踪推理跟踪检查客服人员的推理路径，并检测输出中的幻觉
Data 360 | 矢量搜索✅ 需要客服人员引用 Data 360 矢量搜索源，以便在操作执行之前将声明与检索到的来源进行交叉引用
平台 | Proactive Monitoring✅ 对于拥有签名成功权利的客户，依赖 Proactive Monitoring，Salesforce 员工可在其中监控组织是否存在新出现的问题；这不是自助可配置的提醒
平台 | 比例中心✅ 使用比例中心识别接近调控器限制的特定客服人员操作
Agentforce | 操作✅ 在检索大型记录集合的客服人员操作中实施分页
Agentforce | 操作✅ 设计具有硬限制的客服人员操作（每个父级最多 200 个子级），并在超过限制时实施抽样策略

反模式

何处查看什么不好的样子
平台 | 自定义元数据类型允许在没有断路器的情况下进行无限推理重试，并在 LLM 服务降级时创建无限重试循环
Agentforce | 提示模板重试失败的客服人员响应，而不在重试提示中包含验证错误和预期结构
Agentforce | 操作允许客服人员请求无边界上下文（例如“所有历史”），而每个父级记录的子级没有硬性限制
Agentforce | 操作设计客服人员操作，在不分页的情况下检索大型记录集合，导致调控器限制峰值
Einstein | Trust 层信任客服人员响应，无需交叉引用基础数据源的声明，允许幻觉到达操作执行
平台 | 组织将 LLM 服务可用性视为与 Salesforce 平台可用性相同，而不是将其作为单独的依赖性进行监控

模式

何处查看好样的
Agentforce | 客服人员配置✅ 设计多层后备链：全上下文客服人员 → 还原上下文客服人员 → 确定性规则引擎 → 通过全方位进行人工切换
Agentforce | 客服人员配置✅ 使用精简上下文（过去 30 天与所有历史、前 5 个向量搜索结果与前 20 个）配置辅助客服人员，以减少失败概率
平台 | 流✅ 在平台事件触发的编排流或 Apex 中实施回退逻辑，记录哪层成功查看失败模式
平台 | 流✅ 构建确定性流或 Apex 逻辑，在客服人员推理失败时将常见场景作为后备处理（例如，标准验证规则、基于规则的分数计算）
Agentforce | 全方位✅ 为人工切换配置基于技能的路由，确保升级达到适当的专业知识
Agentforce | 全方位✅ 将完整的对话上下文传递到人工队列，包括尝试的策略、客服人员置信度分数和失败原因

反模式

何处查看什么不好的样子
Agentforce | 客服人员配置设计具有单个执行路径的客服人员，该路径在任何组件降级时完全失败
Agentforce | 客服人员配置⚠ 使用相同的完全上下文代理配置进行后备尝试，而不是逐步简化上下文
Agentforce | 全方位⚏ 路由到人工切换，而不传递对话上下文、尝试的策略或失败原因，迫使客服人员从头开始
平台 | 流⚠ 不记录哪个回退层成功，失去对失败模式和回退有效性的可见性

模式

何处查看好样的
平台 | 平台事件✅ 在多步骤客服人员工作流中的每个成功步骤后发布检查点事件，并在事件负载中存储相关性 ID、完成的步骤和继续所需的状态
平台 | 平台事件✅ 将客服人员工作流设计为松耦合的事件链，其中每个客服人员可以独立失败并重试，而不会阻止整个工作流
平台 | 平台事件✅ 使用负载中具有重试计数的平台事件，实施具有指数后退延迟的重试队列（30 秒、2 分钟、8 分钟、30 分钟）
平台 | 平台事件✅ 在最大重试次数（通常是 5 次）用完后，路由到死信队列和警报操作
平台 | 平台事件✅ 在所有相关事件中包含相关 ID；使用平台事件重放 API 重建完整的工作流历史进行调试
平台 | 平台事件✅ 利用高用量平台事件可用的 72 小时重放保留窗口（标准用量事件保留 24 小时），通过组织维护窗口或部署停机保留重试队列

反模式

何处查看什么不好的样子
平台 | 平台事件无需检查点即可构建多步骤客服人员工作流，当任何中间步骤失败时，需要完全重新执行
平台 | 平台事件重试失败的客服人员请求，而不进行指数回退，对恢复服务产生惊人的群效应
平台 | 平台事件设计紧密耦合的顺序工作流，其中单个客服人员故障会阻止所有下游处理
平台 | 平台事件忽略事件中的相关 ID，使其无法跟踪和调试完整的工作流执行
平台 | 平台事件⚠ 在没有最大重试次数或死信队列的情况下无限重试，在永久失败的操作上消耗平台资源

模式

何处查看好样的
平台 | Apex✅ 使用批处理 Apex 进行客服人员操作，分析 1,000 多条记录，利用异步调控器限制（200 次 SOQL 查询、150 次 DML 操作、每次执行 60 秒 CPU）
平台 | Apex✅ 将可查询 Apex 链用于需要多次外部 API 调用或延长处理时间的多步骤客服人员工作流；跟踪自定义对象中的进度，以便在失败时恢复
平台 | Apex✅ 在允许失败的情况下，使用 @future 方法进行轻量级的“救火-忘记”客服人员操作（通知、外部日志、非紧急更新）
平台 | Apex 作业✅ 通过 Apex 作业页面（设置 → Apex 作业）和 Apex 弯曲队列监控异步处理能力：最多 5 个并发批处理作业（弯曲队列中的额外作业队列，最多 100 个处于保持状态），以及组织范围内的异步 Apex 执行每日限制 (DailyAsyncApexExecutions)（取较大者为 250,000 或 200 × 每 24 小时用户许可证数量），在批处理、可队列、未来和计划 Apex 中共享
平台 | 组织✅ 在异步消耗方法限制时发出警报，以在客服人员处理被阻止前启用主动容量管理

反模式

何处查看什么不好的样子
平台 | Apex在同步客服人员事务中处理 1000 多条记录，而不是移动到批量 Apex，仅在一些记录后达到 100 条 SOQL 查询限制
平台 | Apex使用可排队链，而不跟踪自定义对象中的进度，防止故障时恢复功能
平台 | 组织⚏ 未监控 5 个并发批处理作业限制或共享每日异步 Apex 执行限制（DailyAsyncApexExecutions — 批次、可排队、未来和计划 Apex 之间每 24 小时 250,000 或 200 个用户许可证中较大者），导致客服人员处理静默排队或失败

模式

何处查看好样的
平台 | 组织✅ 在具有生产规模数据量的完全复制 Sandbox 中加载测试客服人员性能；模拟匹配峰值需求的并发对话
平台 | 组织✅ 测量负载下的 p95 和 p99 延迟，识别压力下的性能下降；验证峰值负载下的调控器限制消耗保持在阈值以下
Agentforce | 客服人员配置✅ 执行故障注入：在断路器监控的服务层模拟 LLM 推理故障，注入 SOQL 异常测试错误处理，损坏响应测试验证逻辑
Agentforce | 客服人员配置✅ 在测试期间引入数据偏差（包含 10,000 多个子级的客户），以验证分页逻辑处理最坏情况
平台 | 平台事件✅ 进行混沌工程：随机禁用平台事件订阅者测试重放恢复，终止异步作业中执行测试检查点重新启动
平台 | 组织✅ 随着客服人员的发展，在保持弹性的暂存环境中安排定期混乱日
平台 | 组织✅ 执行长时间运行的稳定性测试（72 小时以上）监控依赖于时间的故障：累积错误并逐渐降低性能
平台 | 组织✅ 跟踪 CPU 时间趋势和长期堆消耗，检测上下文管理中的逐步降级

反模式

何处查看什么不好的样子
平台 | 组织⚏ 在数据量减少的部分复制 Sandbox 中进行负载测试，提供误导性信心，因为数据量直接影响客服人员的性能
Agentforce | 客服人员配置⚠ 仅测试幸福路径，而不故意引入失败来验证断路器、重试逻辑和超时处理
平台 | 组织⚠ 仅运行短期测试，缺少仅在持续 72 小时以上运行下出现的依赖于时间的故障（累积错误、逐渐降级）
平台 | 平台事件⚠ 从不测试平台事件重放恢复或检查点重新启动，保持弹性机制未验证

模式

何处查看好样的
业务 | 文档✅ 在构建客服人员之前而不是在生产失败之后建立 SLO；定义每种客服人员类型的对话成功率目标（通常为 95-99%）
平台 | 组织✅ 跟踪对话成功率作为主要客服人员的可靠性度量：没有错误或超时完成的对话的百分比。将优雅地移交给人员视为成功，因为升级是设计的最终后备层；仅根据度量计算失败或意外的升级
平台 | 组织✅ 按客服人员类型和用例分别跟踪成功率，因为客服人员目的之间的成功标准不同
平台 | 组织✅ 计算每个客服人员类型的平均故障间隔时间 (MTBF)，以识别需要优化投资的最不可靠的客服人员
平台 | 组织✅ 测量平均恢复时间 (MTTR);通过平台事件重放和断路器自动恢复,实现比手动干预更快、更不容易出错的恢复
Einstein | Trust 层✅ 随机客服人员响应示例，根据 Data 360 源验证索赔，以测量接地精度；调查准确性何时降至 95% 以下
平台 | 平台事件✅ 通过订阅者侧日志记录模式监控平台事件重放差距（错过或未送达的事件），该模式将每个事件的重放 ID 和相关 ID 记录到自定义对象
平台 | 组织✅ 当任何 SLI 低于其定义的 SLO 阈值时发出警报操作

反模式

何处查看什么不好的样子
业务 | 文档构建客服人员，无需先定义 SLO，仅在生产失败后建立可靠性目标
平台 | 组织在所有客服人员类型中使用单个聚合成功率，而不是按客服人员类型和用例单独跟踪
平台 | 组织仅依赖传统的 Salesforce 监控 (trust.salesforce.com)，不跟踪特定于客服人员的 CLI，例如对话成功率、MTBF、MTTR 和基础训练准确性
平台 | 组织需要手动干预所有客服人员故障，而不是使用平台事件重放和断路器自动恢复
Einstein | Trust 层⚠ 从不采样试剂响应进行接地精度验证，允许在生产中检测不到幻觉

模式

何处查看好样的
Agentforce | 客服人员配置✅ 从初始设计开始，将重试模式、后备链和升级阈值设计到客服人员工作流中，而不是事后考虑
Agentforce | 操作✅ 在客服人员操作中批量化上下文准备和分页大型记录集合
平台 | 平台缓存✅ 在平台缓存中缓存频繁访问的参考数据，减少客服人员上下文准备期间的冗余查询
平台 | 比例中心✅ 使用规模中心确定需要优化的资源密集型客服人员操作
平台 | 平台事件✅ 使用平台事件作为耐用的重试队列设计自恢复工作流，断路器保护外部依赖性
Agentforce | 客服人员配置✅ 始终将人工切换作为每个客服人员降解链的最终后备
平台 | 组织✅ 当度量下降到 SLO 以下时，监控客服人员 SLI 持续报警
Agentforce | 客服人员配置✅ 通过适当的监督平衡自主能力：在信心下降或出现边缘个案时，从暂时故障中自我恢复

反模式

何处查看什么不好的样子
Agentforce | 客服人员配置添加可靠性机制（重试、回退、升级）作为事后考虑，而不是从一开始就设计它们
Agentforce | 操作未批量化上下文准备，导致真实查询模式下的调控器限制失败
平台 | 组织未主动监控 API 消耗和平台事件分配，仅在客服人员失败时发现限制
Agentforce | 客服人员配置⚠ 将无需人工切换的客服人员链设计为最终后备，在用尽所有自动化选项时不保留恢复路径
Agentforce | 客服人员配置⚏ 为低置信度情况或边缘个案授予客服人员完全自主操作，没有升级阈值