---
schema_version: "1"
id: bf718d41f3201568ee02d8720cf03ced1797abf347ad9eb83962be014ac1b018
title: 客服人员可靠性模式
collection: architect
version: current
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/reliability-agentic-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/reliability-agentic-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 84ef03882186819cbc7a3d328e8ec5f0bbb6732e608f161285cde57248c3a505
products:
  - 架构良好的框架
  - Architect Site Content Repo
---
# 客服人员可靠性模式

了解有关架构良好的[可靠性](/docs/architect/zh-cn/well-architected/guide/reliability.html)的更多信息 → [Agent Enterprise 可靠性](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-reliability.html)

## 客服人员故障模式检测

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| 平台缓存 | ✅ 实施断路器，在平台缓存中跟踪 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 小时以上运行下出现的依赖于时间的故障（累积错误、逐渐降级） |
| 平台 \| 平台事件 | ⚠ 从不测试平台事件重放恢复或检查点重新启动，保持弹性机制未验证 |

## 客服人员 SLI 监控

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 文档 | ✅ 在构建客服人员之前而不是在生产失败之后建立 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 \| 客服人员配置 | ⚏ 为低置信度情况或边缘个案授予客服人员完全自主操作，没有升级阈值 |