--- schema_version: "1" id: 564fc9661bf10b03f1464669f3ce53f562e8af06b34dbc68e3a0f38a91ac9f05 title: 适用于客服人员企业的卓越运营 collection: architect version: current locale: zh-cn portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/agentic-enterprise-operational-excellence.md canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-operational-excellence.html source_site: architect.salesforce.com content_type: documentation content_hash: 45ad445f3297880df7dab5981f04ba9cb730f74616d033aa2914551beefece93 products: - 架构良好的框架 - Architect Site Content Repo --- # 适用于客服人员企业的卓越运营 适用于客服人员企业的卓越运营 ## 概览 客服人员系统的卓越运营扩展了传统的 DevOps 实践，以解决 AI 客服人员的独特特征：非确定性行为、依赖于上下文的推理和记忆、目标复杂性和可变的推理成本。常规应用程序遵循可预测的代码路径，但客服人员会根据上下文生成新颖的响应。传统监控跟踪已知度量，而客服人员可观察性需要了解语言模型推理和决策模式。标准测试会验证确定性输出，但客服人员验证会跨多个维度评估响应质量，包括准确性、相关性、安全性和公平性。 产品和系统会随着时间的推移而变化，因此应用以下五个设计原则，将卓越的运营嵌入您的运营方式：通过可观察性进行发展，标准化运营程序，拥抱 DevOps 文化，自动化提高效率，并从所有运营事件中学习。核心卓越运营原则“通过可观察性发展”对客服人员系统至关重要，因为客服人员行为来自提示、检索的上下文、模型行为和对话历史之间的复杂交互，而不是确定性代码执行。架构师无法在设计时预测每个客服人员响应，因为响应由模型、提示和实时上下文决定，所以设计时要考虑可观察性和防护。综合可观察性揭示了客服人员在实际条件下的行为方式。当客服人员产生意外的输出时，这种可见性支持数据驱动的改进和快速问题诊断。 “作为代码操作”为客服人员提供了新的维度。传统的基础设施即代码扩展到提示版本、模型配置管理和客服人员部署自动化。客服人员操作程序解决模型版本更改、提示演变和 Knowledge 库更新，以及常规部署和回滚操作。 通过客服人员系统，“从所有运营事件中学习”变得更有价值。客服人员事件通常显示微妙提示的工程问题、脚本和编排错误、Knowledge 库差距或意外的用户交互模式。验尸与客服人员遥测的系统分析相结合，将操作经验转化为随着时间的推移而复合的组织能力。 ## 客服人员可观察性架构 ### 对话记录和审计跟踪 完整的对话记录构成了客服人员可观察性的基础。捕获每个对话，包括用户输入、客服人员响应、推理步骤、调用的操作、检索的数据和最终结果。此遥测服务于多种目的：调试特定事件、跨许多交互的质量分析、合规性审计、模型改进和使用模式分析。 通过自定义构建的日志记录，使用本地会话跟踪模型。Agentforce 会话跟踪在 Data 360 的统一数据模型中捕获客服人员交互数据，而不是要求您构建并行遥测系统。会话跟踪数据模型 (STDM) 将对话记录为跟踪层次结构。每个会话包含交互（轮次），每个交互包含步骤（UserInputStep、LLMExecutionStep、FunctionStep），步骤包含消息（用户和客服人员通信）。STDM 使用标准 Data 360 对象，例如 AIAgentSession、AIAgentSessionParticipant、AIAgentInteraction、AIAgentInteractionStep 和 AIAgentInteractionMessage。交互携带分布式跟踪标识符 (TelemetryTraceId 和 TelemetryTraceSpanId)，步骤携带跨度标识符 (TelemetryTraceSpanId)，反映了 OpenTelemetry 风格的跨度模型。 将客服人员对话建模为跟踪和跨度是客服人员可观察性的行业标准方法，重复使用本机模型可以避免手动构建对象遇到的规模问题：存储多轮对话、大型 JSON 负载和快速数据增长。构建自定义事务对象来记录对话是一个蓄意的例外 — 例如，一个轻量级的自定义对象，将客服人员行为与业务结果相关联，而不是与主要记录基底相关联。 会话和对话元数据捕获关键上下文，包括会话和交互标识符、用户身份、客服人员身份、开始时间和结束时间。STDM 还将每个交互步骤链接到其大语言模型 (LLM) 调用记录（通过 GenerationId 和 GenAiGatewayRequest/Response 引用）。令牌使用情况、模型和提示详细信息可通过这些联接获得，而不是存储为会话字段。元数据支持为模式分析筛选和聚合对话。 交互和步骤级详细信息捕获每个轮次，包括用户输入、客服人员响应、推理解释（在可用时）、置信度分数、检索的上下文、尝试的操作和遇到的错误。步骤级跟踪支持详细的事件调查，以准确重建推理链中每个点发生的情况。 操作步骤会记录客服人员采取的每个操作，包括 API 调用、数据修改、外部系统交互和调用的集成。操作记录回答了“此客服人员更改了什么？”和“此客服人员访问了哪些系统？”等问题。这些答案支持安全调查和合规要求。STDM 将本地捕获操作作为交互步骤。 Atlas 推理引擎中的原因跟踪揭示了客服人员的决策过程，有助于诊断客服人员选择具体行动或生成特定响应的原因。会话跟踪会将计划员的步骤记录为每次交互的一部分。公开推理的深度取决于模型和规划器，但在可用时，这些跟踪会显著提高可调试性。 Einstein Trust 层生成式 AI 审计跟踪会捕获每个生成式 AI 交互、提示和响应文本（包括个人身份信息 (PII) 屏蔽版本）、检索的基础数据、响应安全和毒性分数以及 LLM 模型详细信息，所有这些都会流式传输到 Data 360 并存储在 Data 360 中。打开 Einstein 生成式 AI 和反馈数据收集和存储，以便在 Data 360 中捕获审计和反馈数据，您可以在 Data 360 中通过 Data 360 报告对其进行查询和分析，以便长期保留。 > **示例：** > > 良好：存储在自定义 Salesforce 对象中的对话日志，其中包含用户输入、客服人员响应、采取的操作、令牌消耗和对话结果的字段。仪表板按客服人员和用例显示对话成功率。更好：综合日志记录包括显示客服人员决策过程的推理跟踪、显示基于什么信息的响应的检索上下文以及表示不确定性的置信度分数。最佳：对话分析将客服人员行为与业务结果相关联，通过模式分析确定改进机会，并使用带有质量标签的示例提供持续学习漏斗。 ### 客服人员绩效监控 监控运营绩效，确保客服人员满足服务级别，并在预期参数内运营。 **响应延迟**跟踪从用户输入到客服人员响应的端到端时间。延迟直接影响用户体验。以百分位数 (p50、p95、p99) 衡量延迟，揭示典型性能和最糟糕的情况。当 p95 延迟超过阈值表示性能下降时发出警报。 客服人员的延迟因素包括模型推理时间、数据和上下文检索持续时间、外部工具和操作执行以及网络延迟。分别检测每个阶段，以便在整体延迟超过目标时实现有针对性的优化。 **令牌消耗**衡量每个对话、每个客服人员和每个用例使用的令牌。令牌消耗会增加推理成本，并影响响应时间（更多的令牌需要更多的推理计算）。跟踪令牌分发，揭示实际使用是否与预测匹配。检测消耗过多令牌的异常对话，提示提示问题或滥用。 令牌度量包括提示令牌（模型的输入）、完成令牌（模型输出）和总令牌（提示和完成的总和）。提示令牌比完成令牌更容易控制。优化提示和检索的上下文，减少提示令牌消耗，同时保持质量。 **吞吐量监控**会跟踪并发对话、每秒请求和对话量趋势，并有助于项目容量和扩展要求。将当前吞吐量与在接近阈值时提醒的已知速率限制或容量基线进行比较。 **错误率跟踪**按类型监控失败，包括特定于模型的错误、超时错误、拒绝权限错误和外部集成失败。错误模式显示了需要补救的系统问题。计算错误率占请求总数的百分比，以便在客服人员和时间段之间进行比较。 区分需要不同响应的错误类别。特定于模型的错误可能需要及时调整或切换到更好的模型。权限错误需要更改安全配置。集成错误需要外部系统调查或断路器激活。 **可用性监控**衡量客服人员的正常运行时间和成功操作周期。将可用性计算为客服人员成功响应请求的时间百分比。根据服务级别目标 (SLO) 跟踪可用性，在可用性低于目标时主动响应。 **Proactive Monitoring** 评估您的组织是否存在平台异常和资源利用问题,这些问题会影响客服人员基础设施的健康。它会在信号升级为用户可见的问题之前显示它们。使用它保持领先于基础设施级条件（例如异常 API 活动或资源消耗趋于平台限制），这些条件可能会降低客服人员的性能。根据客服人员的正常工作基线查看其信号，以便您可以区分可操作的异常和预期的变化。 ### 质量度量和评估 持续监控响应质量，在影响业务结果之前检测降级。在平台提供内置评估工具时，使用它们，而不是自定义或手动流程。从本地测试和评估工具开始。Agentforce 测试中心允许您维护可重用的测试用例集，并针对它们批量运行客服人员，检查客服人员是否选择了预期的主题和操作，并产生了可接受的响应，而不是构建和运行自己的测试工具。它还支持本地评估者，包括现成的质量维度和用于对对话质量进行评分的 LLM 作为判断者的方法，并允许为特定于组织的标准编写自定义评估者。在测试集中使用代表对话，以便评估反映真实使用情况。 **回复准确性**衡量客服人员回复是否包含正确信息。准确的评估需要已知答案声明或人工审核。对于具有已知答案的事实问题，自动评估会将客服人员的回答与正确回答进行比较；将这些回答作为测试用例保存在测试中心，以便进行可重复的评估。对于开放式问题，人工评估员会评估抽样对话的准确性。跟踪一段时间内的准确性趋势，揭示提示性更改、模型更新或 Knowledge 库修改是提高还是降低性能。 **回复相关性**衡量客服人员的回复是否适当地解决了用户问题，即使它们并不完全准确。相关回复了解用户意图，并提供帮助信息，即使不可能提供完整的答案。通过本地评估器（如果可用）、对抽样对话的人工审核和用户信号来评估相关性。对于基于 Knowledge 库的客服人员，本地检索质量分析可以评估回复的上下文相关性、答案相关性和忠诚度（基于）。 **防护**系统会检测不安全、不适当或有害的响应，包括偏见、攻击性内容、危险建议和超出范围的响应。Einstein Trust 层在运行时将毒性检测应用于 LLM 交互，这是您的第一道防线。通过内容筛选、手动审查抽样、用户报告机制和公平性审计来改善安全监控，从而评估人口统计组之间的结果分布。 **用户满意度**度量捕获主观体验质量。Agentforce 反馈流入 Einstein 的生成式 AI 审计和反馈数据模型(Data 360 中的 GenAIFeedback/GenAIFeedbackDetail)。这些模型从人或系统源捕获明确的用户信号（拇指向上/向下、接受/拒绝、编辑和逐字评论），以及网关请求和生成数据。在您需要的地方捕获明确的反馈（在升级前、对话结束后和通过跟进调查询问），并将明确和隐式信号结合起来以获得全面的质量视角。 ### 模型漂移检测 Salesforce 提供各种模型表面。生成层提供运行在以下对象的对话推理客服人员：Agentforce 托管的模型在 Salesforce Trust 边界内提供现成的推理，并将您自己的 LLM (BYOLLM) 链接带到外部 LLM 或提供商。预测层为客服人员提供基于以下内容的决策的结构分数：BYOM 从外部托管的平台提取零复制预测分数，本地 Einstein 模型对 CRM 对象产生自动评分和分类。这些表面共同允许自主客服人员使用自然语言进行推理，同时将其工作流基于结构化的统计数据。 模型漂移的监控器，它指示性能随时间下降或条件变化需要调整。在每个主要版本投入生产之前，查看发行说明并在 Sandbox 中测试关键用例。使用发布矩阵和 Sandbox 预览窗口，以尽早发现兼容性问题。 当客服人员的准确性、相关性或安全性随时间下降时，会出现**性能偏差**。随着时间的推移跟踪质量度量，以检测具有统计学意义的下降。性能漂移可能由模型退化、Knowledge 库过时、提示与不断变化的使用模式不一致或输入与目标输出之间的关系发生变化的概念漂移引起。 在初始客服人员部署后立即建立基准性能，衡量代表性测试用例的准确性、相关性、安全性和满意度。根据相同的测试用例定期重新评估，揭示与使用模式变化无关的性能变化。 当质量度量下降超过可接受的阈值时发出警报。根据业务影响容限定义阈值。一些用例容忍适度的质量下降；其他用例需要立即响应任何下降。 当用户输入模式从训练或调整数据分布中发生显著变化时，会出现**分布漂移**。当客服人员遇到并非设计用于处理的输入类型时，分发偏差会降低性能。监控输入特征，包括问题长度、主题分布、语言复杂性和检测显著变化的领域术语。 将当前输入分布与历史基准进行比较。大型分发轮班可以指示新的用例、不断变化的用户行为或不断发展的业务流程。分发轮班可能需要即时更新、Knowledge 库扩展或客服人员功能增强。 当客服人员响应模式意外改变时，会出现**行为偏差**。监控响应特征，包括平均响应长度、操作调用率、升级频率和错误模式。重大行为更改可以指示提示问题、模型问题或基础系统更改。 在生产早期建立行为基准，捕获正常操作特征，例如常规性能模式、工具使用和决策路径。这些基准成为稍后异常检测评测的基准。将正在进行的行为与基线进行比较，并在偏差超过预期变化时发出警报。 **自动警报**支持主动漂移响应。配置在漂移度量超过阈值时触发调查和潜在补救的警报，包括及时调整、Knowledge 库更新、测试集扩展或 BYOM 模型重新训练。 ### 异常检测和警报 自动检测需要调查的异常客服人员行为。 **成本异常**，包括令牌消耗峰值、推理率增加或总成本加速。成本飙升可能表示提示问题导致令牌生成过多、滥用或误用导致意外使用，或基础设施问题导致冗余调用。 监控令牌消耗分配，检测异常对话。调查消耗典型令牌计数 10 倍的对话，以了解它们是否代表合法的边缘个案或需要修复的问题。 **错误率峰值**，包括故障率的突然增加、基线中不存在的新错误类型或影响特定用户、客服人员或用例的局部错误集中。错误峰值通常在客户看到质量下降问题之前出现。主动检测可在广泛影响前进行补救。 **响应模式变化**，包括响应长度、操作调用频率或升级率变化的突然变化。模式更改可能表示提示问题、模型行为更改或演变的使用模式。 当用户以更高的速度放弃对话时，**对话放弃增加**，这表示质量下降、延迟增加或功能不足。按对话阶段跟踪放弃情况，确定用户是在初始交互、对话中还是在尝试任务完成后放弃。放弃模式显示了特定的改进机会。 设计警报架构，平衡快速通知和警报疲劳。将关键客服人员故障立即路由到随叫随到的工程师。在工作时间将质量下降警告发送给产品团队进行调查。将微小的异常汇总到每日摘要中，以便进行趋势分析。 ## 客服人员生命周期和机器学习操作 ### 提示版本控制和管理 版本控制提示、配置和模型元数据支持回滚、A/B 测试和审计跟踪维护。 **提示模板**是在提示生成器中创建的可重用提示，用于定义客服人员的目标、约束和品牌准则，以及动态基础数据的占位符，例如客户或产品详细信息。将提示模板与应用程序代码一起存储在 Git 中，将提示视为关键应用程序逻辑，应与代码一样严格。提示更改通过代码审查、测试和受控部署。 使用提示生成器进行具有版本历史和测试功能的迭代提示开发。将提示模板用作客服人员操作时，请在提示生成器中预览模板，以确认合并字段解析正确。然后，使用测试中心运行端到端测试，确认客服人员选择操作并生成正确的输出。 将生产就绪提示导出到版本控制，在提示生成器开发和源控制的部署漏斗之间创建同步。 **配置管理**跟踪型号选择、温度设置、检索配置和功能标记。将配置存储为代码，以便您可以使用特定于环境的值、自动化部署并检测配置偏差。 **语义版本**适用于客服人员版本。主要版本表示破坏性更改，例如修改的输入/输出合同或显著更改的行为。次要版本表示功能添加或改进，以保持兼容性。补丁版本表示缺陷修复。版本号会向运营团队和用户传达变更影响。 为客服人员组件实施语义版本，包括提示模板、客服人员配置和 Knowledge 库。日志中的版本号允许事件与特定部署关联。 **变更文档**记录了提示变更、配置修改和模型更新的理由。记录更改的内容、更改的原因、验证更改的测试以及存在哪些回滚程序。变更文档加快了事件调查和Knowledge转移。 ### 模型注册表和部署跟踪 维护模型版本、提示、配置和部署历史的全面注册表。 **模型注册表**记录部署哪些模型版本，包括模型系列、特定版本、微调状态、部署环境（生产、暂存和开发）、部署日期和负责团队。注册表为客服人员基础设施状态提供了单一的真实来源。 **部署跟踪会**记录每个客服人员部署，包括部署的版本、环境、部署时间戳、部署用户、获得的批准和部署结果。使用部署历史记录在出现问题时评估影响（例如，“哪些客服人员在此事件开始前已部署？”），并支持合规报告。 **依赖性跟踪**映射客服人员、提示、Knowledge 库、操作和集成之间的关系。当共享 Knowledge 库更新时，依赖性跟踪会揭示哪些客服人员受到影响。当外部集成更改时，依赖性跟踪会识别受影响的客服人员。 明确记录依赖性，而不是在事件期间发现它们。创建通过开发和部署流程维护的依赖关系图。 **弃用策略**定义了模型版本的生命周期，包括支持持续时间、弃用时间表和迁移要求。明确的弃用策略管理技术债务，防止无限期支持旧模型版本。制定弃用计划，提前足够时间传达时间表，以便进行计划的迁移，而不是对强制弃用做出应急响应。沟通良好且策略支持的最小通知期为重要更改提供了足够的迁移时间。 通过**回滚程序**，团队可以快速从有问题的部署中恢复。记录每个客服人员的回滚程序，并包含以下内容： - 触发回滚的条件 - 还原到哪个版本 - 如何执行回滚 - 谁授权和执行回滚 - 哪些测试确认回滚成功，以及通知哪些团队。 在非生产环境中定期测试回滚程序，以便在生产事件期间依赖它们之前确认它们是否正常工作。通过模拟部署进行演练，以便团队确切知道要做什么。未经测试的回滚程序通常在最需要的时候失败。 ### 持续训练和域适应 通过持续培训、微调和细化工作流，保持客服人员质量。 **反馈收集**系统收集用户反馈、人工审核更正、质量评估和结果评测。反馈为改进提供原材料。如果没有系统收集，改进就变成了猜测。通过在升级前、对话结束后或通过跟进调查提问来收集明确的反馈。通过完成率、升级频率和重试模式收集隐式反馈。组合显式和隐式信号，提供全面的质量视角。 **数据策划**通过策划、质量审查和偏见检查来维护高质量的训练数据集。训练数据质量直接决定模型质量。糟糕的数据会产生不可靠的模型；出色的数据会产生卓越的性能。 通过以下方式将对话日志纳入训练数据集： - 筛选质量 - 包括高评级对话和成功结果 - 删除有问题的例子 - 包括违反安全和错误 - 确保代表性 - 包括不同的场景和边缘个案 - 重复数据消除 - 删除几乎相同的示例 **使客服人员适应**您的领域 -- -- 专门的词汇、独特的业务流程、特定于组织的 Knowledge -- -- 主要通过基于 Data 360 的检索扩充生成和提示调整 -- -- Salesforce 本地路径。 Salesforce 中没有对生成模型进行微调；您可以通过 AI 模型和提示生成器选择和配置模型。当接地不足时，从外部微调，然后通过 BYOLLM 连接。 使用提示生成器根据性能数据迭代**改进提示**。提示工程是持续的实践，而不是一次性的实践。随着使用模式的发展、业务流程的变化和用户期望的变化，提示需要调整以保持最佳性能。 建立定期的提示审查节奏，检查最近的对话、质量度量和用户反馈，以确定改进机会。通过 A/B 测试在全面推出前验证改进，逐步实施提示性更改。 **评估自动化**对等待的测试集运行质量评估，从而快速评估改进候选人。自动评估提供了客观的测量，补充了主观的人的评估。 维护测试集，涵盖幸福之路、边缘个案、对抗性输入和历史问题场景。设置测试自动化，以定期运行测试场景。包括自动结果监控、阈值和通知，以提醒管理员异常。这种自动测试对于检测外部因素（例如模型漂移）的不利影响至关重要。 在生产中出现新的边缘个案时，不断扩展测试集。测试自动化是关键，但也要定期运行手动抽查、一次性测试和大猩猩测试，以确保您的客服人员部署抵御边缘个案。 ### 逐步推出和 A/B 测试 逐步部署客服人员变更，并在全面推出前监控质量，以限制问题的爆发半径。当更改跨越多个区域时（提示、模型配置、操作、基础训练、集成），它会以测试没有发现的方式降低行为。当出现这种情况时，导致的质量回归很少指向单一、明显的根本原因。一次运送一个小的更改，以便回归可以追溯到其来源，并首先将每个更改释放到有限的流量层，以便在您诊断时控制影响。 通过部署在配置后禁用功能的客服人员，**功能标记**可将部署与发布分离。使用逻辑或自定义元数据类型或自定义设置实施功能标记。功能标记支持在生产环境中进行测试，而无需向用户公开功能、向特定用户群逐步推出、比较实施的 A/B 测试，以及通过禁用标记而不重新部署来即时回滚。 对客服人员的重大更改使用功能标记，其中故障的爆发半径可能很大，例如影响业务关键客服人员的更改、生产行为不确定的新推理模式与外部系统的集成，其中交互模式可能与测试不同。 在更广泛的推出之前，**金丝雀部署**会先将客服人员更改为小用户子集，以监控错误率、质量度量和性能。使用权限集控制金丝雀部署 — 将客服人员访问权限限制为用户子集，或根据用户属性在编排逻辑中进行筛选。 监控和衡量成功率、回复质量和用户反馈。将金丝雀度量与使用上一个客服人员版本的对照组进行比较。仅在金丝雀展示同等性能或改进性能时扩展推出。 **A/B 测试会**比较评测质量、成本和用户满意度的客服人员变体。A/B 测试为改进决策提供了经验证据。将变体部署到随机选择的用户子集，确保统计有效性。跨多个维度（准确性、满意度、成本和延迟）衡量结果，提供全面的比较。 在开始 A/B 测试之前，定义成功条件和假设。明确的标准可以防止一些度量提高而其他度量降低时出现不明确的结果。成功标准应与业务目标保持一致（例如，“变量 B 必须与变量 A 的准确率在 2% 以内匹配，同时降低成本 15%”）。 与当前冠军版本相比，**冠军挑战者测试**会将改进的客服人员版本部署到流量子集。拥护者-挑战者模式通过将经过验证的版本维护为后备版本来管理改进风险。如果挑战者表现不佳，请恢复为拥护者，而不会影响用户。如果挑战者表现优异，请将其升级为新冠军。 建立客观的促销标准，包括统计有效性的最小样本量、挑战者必须超过的质量阈值以及促销决策前的评估持续时间。记录促销决策，创建客服人员版本更改原因的审计跟踪。 ## 客服人员失败的事件响应 ### 事件检测和分类 通过全面监控，建立事件检测，快速识别客服人员操作问题。 **客服人员失败模式**与传统应用程序失败不同。常见故障模式包括： - 幻觉 - 生成似是而非的信息 - 主题外回复 - 误解用户意图 - 成本消耗过多 - 令牌生成失控 - 超时失败 - 推理耗时过长 - 权限错误 - 尝试未经授权的操作 - 集成失败 - 外部系统不可用 - 安全违规 - 生成不适当的内容 通过对错误率、质量度量下降、成本异常、延迟增加和用户升级的自动监控提醒来检测故障。通过用户自报告机制进行补充，包括反馈请求，以及关于反馈方式和位置的明确指导，以便您可以修复报告的自动化差距。 **严重性分类**以适当的紧迫性将事件发送给适当的响应者。关键事件表示影响许多用户的生产不可用、客服人员操作的数据损坏风险、安全妥协或需要立即响应的安全违规。严重性高表示影响业务关键客服人员的质量下降或成本大幅超支。中等严重性表示孤立的问题或接近阈值，需要在工作时间进行调查。低严重性表示在事件管理流程之外跟踪的小问题。 根据用户影响、爆炸半径、数据完整性风险和恢复紧迫性，客观地定义严重性标准。客观标准可以防止低估实际问题和过度低估次要问题。维护事件解决结果的文档，以持续改进流程。 **初步反应程序**指导立即采取行动稳定局势。程序包括： - 禁用故障客服人员 - 断路器激活 - 将用户路由到后备选项 - 人工切换、更简单的客服人员、静态响应 - 收集诊断信息 - 最近对话、错误日志、资源度量 - 通知利益相关者 - 随叫随到的工程师、产品所有者、受影响的用户 - 启动事件通信 - 状态页面更新、内部协调渠道 - 将初始响应程序记录为 Runbook，无需特定于事件的调查即可快速执行。 - Runbook 必须由没有深厚客服人员专业知识的随叫随到的工程师执行。 ### 断路器和后备模式 在客服人员事件期间，防止级联故障并维护部分功能。 **断路器模式**会自动禁用出现故障的客服人员，防止在解决问题时出现重复故障和用户影响。实施断路器，在错误率超过持续时间的阈值时监控错误率和断开（禁用代理）。 使用错误阈值、持续时间窗口和恢复测试配置断路器。例如，50% 的错误率，滚动窗口为 5 分钟，定期试用，要求测试客服人员是否恢复。在电路打开时，将请求路由到后备选项。在超时后，电路转换到半开状态，允许通过试用请求。当试用请求始终成功时，关闭电路，恢复正常操作。 当主要客服人员失败时，**后备层次结构**提供了温和的降级。设计后备序列，尝试越来越简单的选项，直到实现可接受的响应。后备层次结构示例：主要复杂客服人员 → 更简单的备份客服人员 → 静态常见问题解答 → 人工切换。 在编排层中实施后备逻辑，而不是在客服人员中实施后备逻辑，以便在客服人员生态系统中实现一致的行为。定期测试后备路径，以验证在需要时是否有效。 当 AI 客服人员无法处理请求时，**人工切换会**升级为人工客服人员。设计切换工作流，保留对话上下文，传达切换原因，路由到具有相关专业知识的适当人工客服人员，并跟踪切换频率，揭示改进机会。 按主题、客服人员和失败原因监控升级率。较高的比率表明客服人员的能力差距需要迅速改进、Knowledge 库扩展或用例优化。 在降级操作期间，**温和降级会**保持部分功能。当复杂的推理失败时，回到更简单的逻辑。当实时数据不可用时，对缓存的数据进行操作。当外部集成失败时，以只读模式操作。通过温和降级，系统能够以较低的容量运行，而不是完全失败。 ### 事件后分析和学习 进行无可指责的事件后审查，重点关注系统改进，而不是单个错误为诚实评估创造心理安全。 **时间线重建**从初始条件到第一个信号、检测、确认、调查、响应操作、恢复和验证创建详细的顺序。为每个事件添加时间戳，从而对每个阶段的持续时间进行分析，揭示事件响应延迟的位置。 在时间线中包含以下内容： - 最近部署了什么（提示、配置、模型、集成）？ - 在使用模式方面观察到哪些变化（流量突然增加、新的对话类型）？ - 哪些外部因素造成了影响（第三方服务降级、平台更新）？ - 是什么使检测速度不理想？ **根本原因识别**决定了直接的技术原因。区分直接原因（模型超时）和影响因素（在特定对话模式下，提示设计超出令牌限制）。根本原因分析会阻止简单化的结论（“客服人员有错误”），而支持导致有效补救的特定发现。 使用“五个为什么”技术，从症状到根本原因进行深入挖掘。 **表面示例：**“客服人员产生了不正确的信息” → “为什么？检索的上下文包含过时的数据”→“为什么？Knowledge 库未使用最近的产品更改进行更新" → "为什么？产品团队没有触发 Knowledge 库更新的流程" → 根本原因：缺少将产品发布连接到 Knowledge 库维护的工作流。 **影响因素**揭示了支持或扩大事件影响的组织、流程或架构条件。常见因素包括监控使问题持续时间超过检测到的时间的差距、测试使故障场景未被揭示的差距、文档差距减慢快速诊断的速度、自动化差距迫使手动恢复步骤以及架构差距，例如单点故障或缺少冗余。 影响因素分析揭示了直接根本原因修复之外的改进机会。大多数事件都有多个影响因素，每个因素都会扩大影响。 **检测分析**检查事件是如何检测的，以及检测是否更快。许多客服人员事件首先由用户报告，而不是由自动监控报告，这表明存在监控差距。确定：什么信号应该更早地检测到问题？什么监控可以加快检测速度？什么警报标准会适当地触发？ 检测分析改进包括：添加缺失的监控覆盖范围，调整警报阈值以消除假阴性，丰富警报上下文以加快分类，并改进仪表板以主动识别问题。 **响应评估**会评估哪些进展顺利，哪些进展缓慢或难以完成。回复评估问题：Runbook 是否有帮助和准确？升级路径是否清晰有效？回滚程序是否已测试并准备就绪？工具是否提供了必要的诊断信息？沟通是否及时有效？ 响应评估的改进包括：使用吸取的经验教训更新运行手册，澄清升级标准，定期测试回滚程序，添加诊断工具，以及改进事件通信模板。 **操作项目**指定具体的、分配的、有时限的改进，以防止重复或改进未来的响应。避免模糊的操作项目，例如“改进监控”，以有利于特定任务，例如“为客服人员在 10 分钟内的错误率超过 5% 添加提醒”，分配：亚历克斯,由于:2 周。" 在后续审核中跟踪操作项目的完成情况，确保持续改进实际发生。在每次事件后审查期间，审查以前事件的未处理操作项目。完成率低表明持续改进过程失败需要关注。 **Knowledge 共享**文档在共享 wiki、Knowledge 库或协作空间中进行事件后审查，并带有标签，支持跨多个事件的模式分析。事件回顾应该可以按故障模式、受影响的组件和时间段进行搜索，使未来的响应者能够从历史事件中学习。 在直接事件响应者之外，广泛共享事件后审查。组织学习需要信息传播。考虑在团队会议或边吃边学的会议中介绍重大事件学习，以传播 Knowledge 并建立集体能力。 ## 客服人员治理和批准 ### 部署审批流程 在部署生产客服人员之前需要批准，以确保审查、风险评估和利益相关者的一致性。 **部署前核对清单**验证就绪情况，包括： - 完成全面测试 - 功能、质量、安全、性能 - 安全审查已批准 - 权限边界、数据访问、操作授权 - 合规性已验证 - 监管要求、策略遵守 - 文档完成 - 运行手册、回滚程序、升级路径 - 已配置的监控 - 质量度量、错误率、成本跟踪 - 获得相关方批准 - 产品所有者、安全性、合规性 核对清单为客服人员提供了一致的评估标准。根据客服人员的重要性、数据敏感性和自主性级别，调整客服人员风险简档的核对清单，使其具有不同的深度。 **风险评估**评估客服人员故障的潜在影响，包括： - 爆破半径 - 受故障影响的用户数量 - 数据灵敏性 - 数据客服人员访问的内容 - 操作权限 - 客服人员可以进行哪些修改 - 集成依赖性 - 哪个系统代理会影响 - 恢复复杂性 - 回滚有多难 - 合规性影响 - 适用哪些法规 风险评估确定批准要求。高风险客服人员需要主管批准、安全审查和逐步推出，而低风险客服人员可能需要同行审查和标准测试。 **批准工作流**通过适当的审查者路由部署请求。使用 Salesforce 审批流程或外部部署工具实施审批工作流。自动化、跟踪和审计批准工作流，以支持合规报告和事件调查。 记录批准决定，创建谁批准部署、批准时需要哪些信息、应用了哪些条件或限制以及做出了哪些监控承诺的审计跟踪。 在正常审批流程延迟关键修复时，**紧急绕过程序**可在生产事故期间快速部署。紧急程序需要行政批准，包括理由文件，并触发部署后快速审查，以验证紧急变化。 从标准版本单独跟踪紧急部署。高紧急部署频率表示需要调查的进程问题。 ### 质量门和测试 定义客服人员在生产部署之前必须通过的质量门，以防止有问题客服人员联系用户。 **功能测试**验证客服人员在代表性场景中正确执行预期任务。测试涵盖典型交互的幸福路径、涵盖不常见但有效场景的边缘个案、测试客服人员是否正常处理无效输入的错误路径，以及检查客服人员是否在调控器限制、令牌限制和数据量限制内的边界条件。 客服人员的功能测试与传统测试不同，因为非确定性输出会阻止精确匹配。测试输出特征（包含所需信息、保持适当语气、包含必要引用），而不是精确文本。 **响应质量测试**评估测试场景之间的响应准确性和相关性。质量测试需要人工评估或具有预期输出的基础真相数据集。建立客服人员必须满足的最低质量阈值（例如，“坚持测试集的准确率为 95%，安全违规为零，公平审计显示人口统计差异不超过 5%”）。随着新边缘个案的发现，持续维护和扩展测试集。 **安全测试**验证客服人员拒绝危险、不道德或超出范围的请求。安全测试尝试对抗性输入，包括： - 提示注入尝试 - 尝试覆盖指令 - 越狱尝试 - 尝试绕过安全约束 - 请求升级 - 请求越来越敏感的操作 - 超出范围的请求 - 尝试未经授权的任务 将安全测试分配给未参与构建客服人员的独立团队成员。对于高风险客服人员，请引入红色团队专家。 **性能测试**验证延迟、吞吐量和成本是否满足预期。在实际负载下测试，包括并发对话、典型对话长度和预计使用量。性能测试揭示了单用户测试中不可见的调控器限制问题、资源约束和可扩展性瓶颈。 在性能测试期间测量测试环境消耗，并将其用于预测生产能力需求。 **安全测试**验证权限边界、数据访问控制和操作授权。安全测试确认：客服人员无法访问未经授权的数据，客服人员无法执行未经授权的操作，提示注入无法升级权限，审计日志记录捕获所有客服人员活动。 使用 Salesforce 代码分析器将静态代码安全扫描集成到部署漏斗中，该分析器扫描 Apex、Flows、Lightning 和 Visualforce 的安全漏洞，并可以通过命令行界面 (CLI) 或 GitHub 操作在持续集成/部署 (CI/CD) 中运行。使用专门的 AI/客服人员安全测试来检测提示注入漏洞和敏感数据泄露风险，因为这些是静态代码分析范围之外的运行时 LLM 输入的威胁。 ### 变更管理纪律 将变更管理纪律应用于客服人员部署，确保变更被记录、审查和传达。 **变更文档**捕获： - 发生了什么变化 - 提示修改、配置更新、模型更改 - 为何进行此更改 - 质量改进、成本优化、缺陷修复 - 哪些测试验证了该更改 - 测试结果、质量分数、安全扫描 - 存在什么回滚过程 变更文档支持事件调查、合规报告和 Knowledge 转移。记录更改会创建一个学习型组织，它基于以前的经验，而不是重新发现经验教训。 **通信计划会**通知相关方客服人员的变化，包括受影响的用户、运营团队、支持团队和业务相关方。沟通应描述：正在变化的内容、何时部署变化、用户会看到什么好处、存在什么风险以及联系谁解决问题。 为不同的变更类型建立通信模板，标准化消息并降低部署准备开销。 **部署计划**时间由 Event Monitoring 数据显示实际使用模式，从而确定客服人员在低用量期间的部署时间。避免在使用高峰、月底结算、季度末结算或主要业务事件期间进行部署。传达部署窗口，包括预期持续时间和回滚决策时间线。 考虑将重大更改安排在周初至周中，并避免周末部署，以便使用充足的资源解决问题。优先考虑快速回滚和强大的部署后监控，而不是任何固定的日历规则。 **更改窗口和冻结**会保护关键业务周期。在主要业务活动（会计年度结束、产品发布和主要市场营销活动）之前建立变更冻结期，以防止在高风险期间出现部署引起的问题。 文档变更冻结日历每年提前通知限制期间，使团队能够相应地进行计划。过多的冻结会降低速度；冻结不足会产生业务风险。 ## 客服人员的持续改进 ### 反馈循环架构 建立反馈回路，将操作遥测连接到客服人员改进。 **用户反馈收集**通过问题或跟进调查收集明确的反馈。通过完成率、上报到人工客服人员、重试模式和表示不满意的跟进问题收集隐式反馈。组合显式和隐式信号，提供全面的质量视角。 内联收集反馈，仅在发生时，而不是稍后。延迟反馈收集降低了回复率，并引入了召回偏见。 **使用 Analytics** 会公开重复出现的主题、问题和趋势等真实对话模式。它们测试客服人员的复杂性是否得到保留，功能是否由于可发现性差而未使用，以及实际使用是否验证了原始设计假设。 查询对话日志，按主题分析问题类型、对话长度、成功率，按对话特征分析用户满意度。使用模式分析指导快速细化、Knowledge 库扩展和功能优先级。 **错误模式分析**确定了需要补救的系统质量问题。按错误类型、受影响的用户、对话模式和时间分布分析错误日志分组。错误模式显示提示问题、Knowledge 库差距、集成问题或需要处理的边缘个案。 按频率和影响确定错误补救的优先级。影响许多用户的高频错误需要立即关注。根据业务影响和补救成本，低频错误可以代表可接受的边缘个案。 **质量趋势监控**会跟踪准确性、相关性、安全性和满意度，并随着时间的推移在恶化之前检测其恶化情况。在初始客服人员部署后，建立质量基准。根据基线监控持续质量，并在趋势下降超过可接受阈值时发出警报。 质量监控揭示了提示性更改、模型更新或 Knowledge 库修改是提高还是降低了性能，从而支持数据驱动的改进决策。 ### 实验跟踪和 A/B 测试 通过经验证据系统地跟踪实验，为改进决策提供信息。 **实验框架**为测试改进提供了一致的结构，包括： - 假设 - 预期改进的内容 - 实验性设计 - 如何部署变体 - 度量 - 测量什么结果 - 样本大小 - 统计有效性所需的交互次数 - 成功标准 - 什么结果证明升级是正确的 在执行前记录实验，防止对结果的解释不明确。预定义的成功标准支持清晰的升级决策，避免对结果是否“足够好”进行冗长的辩论。 **变体跟踪**日志记录了哪些用户收到了哪些变体支持结果关联。在对话元数据中跟踪变体分配，支持按变体分析质量、成本和满意度。 **统计有效性**确保实验运行时间足够长，样本量足够大，得出可靠的结论。根据预期效应大小、统计功率要求和可接受的错误率，在实验前计算所需的样本大小。样本不足会产生噪声结果，导致决策不当。 在实验期间，**多臂强盗优化**会将更多流量动态分配给性能更好的变体。多武装强盗方法减少了对劣质变体的暴露，同时仍然为统计分析收集了足够的数据，从而降低了实验的机会成本。 **实验目录**记录每个实验的变体、结果和决策。它阻止团队重新测试失败的方法，在整个组织中传播学习，并建立实际工作的共享记录。 ## 汇总 代理系统的卓越运营需要扩展传统的 DevOps 实践来解决独特的 AI 特征。全面的可观察性能够理解紧急客服人员行为。系统的生命周期管理可确保质量、安全和成本控制。事件响应程序解决客服人员特定的失败模式。持续改进将运营经验转化为组织能力。 客服人员系统中卓越运营的关键实践： - 记录完整的对话，包括输入、输出、推理跟踪、操作和结果。 - 通过准确性、相关性、安全性和满意度度量，持续监控响应质量。 - 通过基线比较和异常检测，检测模型漂移和行为变化。 - 支持回滚和 A/B 测试的版本控制提示、配置和模型。 - 使用功能标记和限制爆破半径的金丝雀部署实施逐步推出。 - 设计断路器和后备层次结构，防止级联客服人员故障。 - 进行无可指责的事件后审查，重点关注系统改进。 - 建立质量大门和审批流程，防止有问题的客户进入生产环境。 - 构建反馈回路，将操作遥测与客服人员改进联系起来。 - 使用经验证据系统地跟踪实验，以指导增强决策。 为客服人员卓越运营投资的组织通过可靠的高质量 AI 功能获得可持续的竞争优势，这些功能会随着业务需求的不断发展而变化。

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