| 类别 |
描述 |
失败示例 |
| 主题分类 |
客服人员无法正确识别用户的意图或目标。 |
- 为给定的查询触发不正确的主题。
- 经常不适当地默认设置为“关闭主题”分类。
|
| 回复质量 |
客服人员回复的内容、准确性和格式有问题。 |
- 提供不是来自 Knowledge 库的未基础信息。
- 生成超出其指定域专业知识的响应。
- 包含不正确的信息，尽管引用了有效的源。
- 发送过长的消息，这对移动用户尤其成问题。
|
| 操作执行 |
客服人员在尝试执行特定功能或任务时失败。 |
- 调用错误操作或意外操作。
- 返回错误消息，而不是完成请求的操作。
- 不必要地建议升级为人工客服人员。
- 无法从用户正确收集所需的输入变量。
|
| 护栏和说明 |
客服人员违反了预定义的规则、约束或对话边界。 |
- 无视明确的操作说明。
- 对人工客服人员进行意外或过早的升级尝试。
- 在执行操作期间显示不适当的“请稍等”消息。
- 显示通用错误消息，例如“现在无法提供帮助”或“系统错误”。
|
| Knowledge 检索 |
客服人员从 Knowledge 库中获取和显示信息时遇到问题。 |
- 从 Knowledge 库中检索不相关的文章。
- 在回复中包含不必要或不需要的信息。
|
| 结构化指导 |
客服人员很难指导用户完成多步骤流程。 |
- 提供通用的、不接地气的故障排除建议。
- 在一条消息中显示过多步骤。
- 在正在进行的故障排除过程中，失去上下文。
- 停留在单个故障排除步骤上。
- 重复问题，尽管已收到有效回复。
|
##### 测试 AI 客服人员的最佳实践
以下概述了在 Agentforce 上测试客服人员时需要记住的最佳实践。
1. **增强测试数据**
有效测试的基础是全面、真实的测试数据。遵循这些原则，以确保您拥有用于测试客服人员的有效测试数据：
- **足够覆盖范围**:力求有足够的测试数据来涵盖所有关键主题和用户角色。
- **现实场景**:确保您的测试数据准确地代表了真实世界的用户交互。
- **消极和边缘个案**:包括消极测试用例（客服人员*不*应该做什么）和边缘场景，以挑战客服人员的边界。
- **护栏测试**:添加特定测试用例，用于验证客服人员的防护装置是否正常工作。
2. **优化测试运行**
要充分利用测试资源，请优化测试的运行方式。以下是测试 Agentforce 客服人员时的注意事项：
- **测试个案数量**:您最多可以使用 1000 个测试用例。
- **运行并发测试**:最多可以在 10 小时的时间内同时运行 10 个测试用例。
- **管理资源**:请记住，运行测试会消耗信用。在启动运行之前，请确保您对测试数据满意，以避免不必要的成本。
3. **审查结果**
仔细分析测试结果，以确定需要改进的领域：
- **分析失败**:分别检查每个失败的测试用例。请仔细阅读并了解预期结果和实际结果之间的差异，以找出问题所在。
- **使用 Sandbox 环境**:测试客服人员可以修改 CRM 数据。_为了防止对实时数据的意外更改，请始终在非生产环境中进行测试，例如 Sandbox 或临时组织。_
4. **调整和重新测试**
测试是一个迭代过程，随着客服人员的发展而继续：
- **连续测试**:在每次修改客服人员的主题或操作后执行测试。这将验证更改，并确保保持质量。
- **扩大测试覆盖范围**:使用新的测试用例不断策划和扩展数据集，以提高客服人员的整体覆盖率和鲁棒性。
##### 测试方法
鉴于客服人员的复杂性，没有一种测试方法是足够的。全面的验证策略必须分层，将不同的方法结合起来，以涵盖从可预测的、确定性的操作到其非确定性、对话行为的细微差别的所有内容。这些方法为系统评估客服人员的每个组件提供了一个框架，以确保它强大、可靠和安全。
1. **使用客服人员模拟器和计划跟踪器进行手动测试**
- **目的**:这是测试客服人员的初始方式，通常也是最简单的方式。它非常适合一小部分示例用例，并有助于对客服人员的行为有一个基本的了解。
- **机制**:客服人员模拟器提供了开发人员和管理员可以直接与客服人员交互的受控环境。此模拟器允许详细跟踪管理员/开发人员提供的信息，提供有关客服人员如何处理输入和生成输出的见解。
- **好处**:
- 快速反馈
- 易于识别即时问题
- 有助于了解客服人员的逻辑流
2. **使用测试中心或 AFDX 测试套件进行自动测试**
- **目的**:在手动测试建立功能基准后，自动化测试对于可扩展性、彻底性和回归测试至关重要。
- **机制**:测试中心或 AFDX 测试套件等工具支持根据预定义的示例用例生成自动化测试。这些测试旨在验证客服人员的说明和子客服人员分类是否在更广泛的场景中正常工作。
- **好处**:
- 确保性能一致
- 识别微妙的错误
- 支持持续集成/持续部署 (CI/CD) 漏斗
- 提供全面的覆盖范围
3. **使用 Apex 和流进行特定于操作的单元测试**
- **目的**:验证封装在客服人员操作中的确定性业务逻辑。虽然客服人员的整体行为是非确定性的，但客服人员操作通常由流和 Apex 等技术提供支持，标准开发实践适用于这些技术。
- **机制**:开发人员为客服人员操作调用的特定流或 Apex 类编写单元测试。这些测试会验证客服人员逻辑的单个组件，并确保它们为一组给定的输入产生预期的输出。
- **好处**:
- 将这些单元测试集成到 DevOps 漏斗中提供了自动化的安全网
- 验证对操作逻辑的任何更改或增强不会引入回归
- 确保客服人员的功能在部署到生产之前的可靠性
4. **对抗测试 - 安全和防护栏实施**:
- **目的**:构建各种类型的客服人员需要着重强调安全性，并确保它们在定义的参数和防护范围内运行。这对于防止意外操作、数据泄露或滥用至关重要。因此，对抗测试的目的是通过故意使用旨在规避其安全机制的输入来挑战客服人员，从而主动识别和补救这些潜在的漏洞，从而测试其鲁棒性和抗操纵性。
- **机制**:对抗性测试通过精心设计具有挑战性、不明确或恶意的输入来实施，这些输入会打破客服人员预期行为的边界。虽然客服人员生成器中的“护栏”功能等平台工具提供了有关指令遵守的见解，但开发人员还应创建自定义对抗性测试用例，积极尝试使客服人员在受控环境中失败。
- **好处**:这种方法在部署之前系统地降低了安全和合规风险。通过识别潜在的故障点，对抗测试增强了客服人员的可信度，并确保在与用户交互时安全、如预期地运行。
##### 临时组织和 Sandbox 中的迭代测试
“内循环”是关键的迭代循环，客服人员从概念转移到验证的组件，准备进行部署。这种不断细化的过程需要开发和测试的环境。Agentforce 通过临时组织和 Sandbox 提供此框架，临时组织是孤立的临时环境，用于在不影响共享环境的情况下进行快速原型设计，Sandbox 允许使用现实数据进行彻底测试，以加速生产。
1. **临时组织的发展**:初始开发应在临时组织中进行。开发环境中提供的工具，例如 Agent Builder 和 AFDX，在这里得到了充分利用。临时组织是 CI/CD 漏斗的有力候选组织，用于运行单元测试、执行代码分析，并将更改升级到更高的环境。
2. **部署到 Sandbox 进行真实数据测试**:在临时组织中开发客服人员的核心功能后，部署到 Sandbox。Sandbox 是生产环境的副本，提供更真实的测试场。
- **真实数据与模拟数据**:虽然一些开发人员可能会在临时组织中模拟数据进行初始测试，但部署到 Sandbox 允许使用“真实数据”进行测试。这对于在密切反映实际客户互动的场景中评估客服人员的表现至关重要。在 Sandbox 中使用更具代表性的数据会显著加快开发和优化过程。
- **适用于核心 CRM 数据的全部或部分 Sandbox**:根据数据量和特定的测试要求，可以使用完全或部分 Sandbox。
- **完全 Sandbox**:提供生产环境的完整副本，包括所有元数据和数据。非常适合使用大型数据集进行广泛的测试和性能调整。
- **部分 Sandbox**:包含生产数据的子集，通常足以测试特定特性或功能，而严格来说，完全数据集不是必需的。
- **Knowledge 和 RAG 管理**:如果客服人员依赖于 Knowledge 库或检索扩充生成 (RAG) 模型，请将所有相关内容引入 Sandbox 并重新索引。这确保了客服人员在测试期间使用当前信息，并可以准确地检索和合成内容。
#### 第 4 阶段：部署和发布
Agentforce 通过元数据定义客服人员，因此可以使用标准 Salesforce 程序进行部署，例如更改集或 AFDX。此阶段强调通过重要功能（例如客服人员版本）进行安全和受控的推出，以及单独的激活步骤，这将确保系统稳定性并允许从问题中快速恢复。
按照这些步骤部署和释放新客服人员。
1. **通过更改集/元数据 API 或 AFDX 部署**:客服人员的部署流程利用标准 Salesforce 程序，将客服人员视为元数据。对于任何习惯于 Salesforce 开发和部署的人员来说，这应该是熟悉的流程。使用更改集或 AFDX 可确保在环境之间迁移客服人员配置的结构化和一致方法，例如从 Sandbox 迁移到生产环境。此方法有助于版本控制和正确变更管理，这对保持系统稳定性和可靠性至关重要。
2. **部署后激活客服人员**:在成功部署后，系统管理员必须主动“激活”客服人员。部署只需将客服人员的代码和元数据放入目标环境；激活是使客服人员可操作和可用的步骤。这种分离允许在客服人员上线并与最终用户或其他系统组件交互之前进行受控的推出和测试。
3. **使用版本控制进行安全客服人员管理**:客服人员版本化是一项关键功能，可显著增强客服人员开发和维护的安全性和灵活性。
1. **创建、测试和发布新版本**:推荐的实践包括在需要更改或增强时创建客服人员的新版本。然后，该新版本可以在 Sandbox 环境中彻底测试，而不会影响实时激活的客服人员。一旦新版本经过验证并被认为准备就绪，就可以发布并随后激活它，以替换以前的操作版本。这种迭代过程允许持续改进和创新，同时最大限度地减少中断。
2. **回滚到早期版本**:如果新部署或激活的客服人员出现问题，版本化的一个主要好处是能够快速轻松地恢复到以前的稳定版本。如果出错（例如，如果客服人员行为不当或出现意外错误），管理员只需回滚到上一个已知良好版本并将其激活。此功能提供了关键的安全网络，允许快速恢复并最大限度地减少停机时间，从而确保业务连续性和用户满意度。
#### 第 5 阶段：监控和调整
##### 客服人员监控
Agentforce 会话跟踪是一个基于 Data 360 构建的开放、可扩展的模型，可以捕获端到端的客服人员交互。Agentforce 会话跟踪从不同来源接收数据（从推理引擎日志开始），并将所有内容合并到会话 ID 下。
会话跟踪数据模型 (STDM) 提供了关于客服人员会话期间发生情况的详细信息，包括：
- 逐轮交互
- 引擎执行原因
- 操作、提示和网关输入/输出
- 错误消息
- 最终答复
STDM 是一款重要工具，可帮助开发人员：
- 在构建期间调试客服人员设置和配置问题。
- 了解某些测试用例在批量测试期间失败的原因。
- 解决客服人员无法处理一组用户问题或偏离主题的原因。
开发人员应使用此会话跟踪数据来观察、监控、调查和排除客服人员事件、事件和行为模式。
STDM 包括存储客服人员行为详细日志的数据湖对象 (DLO) 和数据模型对象 (DMO)。关于推理引擎进行的每个 LLM 调用的元数据可以与反馈或防护度量结合。数据流到 Data 360 中的 DLO，并映射到适用的 DMO。
开发人员可以通过针对 STDM 运行查询和报表来访问这些数据并获得见解。STDM 的组件描述如下。
**Agentforce 会话跟踪数据模型 ERD**
本章显示了 Agentforce 如何**在单一统一平台**内支持 ADLC 的每个阶段
#### 阶段 1：意见和设计
##### 意见
意见阶段是 ADLC 的基础阶段，在这里制定客服人员的初始愿景和要求。它涉及深入了解问题，确定潜在的解决方案，并概述客服人员的核心职能。
通过定义客服人员的关键属性，开始他们的想法过程：
1. **目的/目标**:明确定义客服人员的主要目标。它旨在解决什么具体问题，或者它打算完成什么任务？客服人员应为谁提供服务？这应当是指导整个发展进程的简明和可衡量的声明。
2. **角色**:为客服人员制定详细的角色。这包括定义其身份、通信风格，以及在与用户或其他系统交互时将扮演的角色。考虑它的语气、正式程度，以及使它在预期上下文中有效的任何特定特征。
3. **模式**:确定并链接到相关的客服人员模式和实施策略。这涉及架构设计或最佳实践，可为客服人员的结构和行为提供信息。"Salesforce Agentforce 上的[代理模式和实施:技术白皮书](/docs/architect/zh-cn/fundamentals/guide/agentic-patterns)》是这一步骤的宝贵资源,提供了关于 Salesforce 平台和 Agentforce 上有效客服人员设计的见解。
##### 设计
设计阶段将概念从构想转化为客服人员构建的详细蓝图。这涉及定义客服人员的架构、用户流、交互模型和技术规格，例如主题、工具和防护。
在设计阶段，您将为客服人员的构建创建详细的蓝图，其中包括：
- **客服人员设计**:概述客服人员的内部结构，包括其组件、模块以及它们如何交互。这可能涉及定义 Knowledge 库、配置和逻辑来控制客服人员行为、自然语言处理 (NLP) 组件以及与其他系统的集成点。
- **用户流/交互设计**:映射完整的用户旅程和客服人员的交互。定义对话流、决策树、错误处理和反馈机制，以创建直观、有效的体验。
- **技术规格**:记录客服人员的技术非功能要求，例如性能度量、可扩展性注意事项、安全协议和集成规范。
- **原型和模型**:创建客服人员界面和交互的可视表示或交互原型。这允许早期测试和反馈，有助于在开始全面开发之前完善设计。
- **数据**:在确定客服人员需要的数据类型和来源时，确定客服人员必须访问的数据集、API、数据库和存储库。对于 Agentforce，关注作为上下文提供的数据，无论是结构化还是非结构化，以及它是实时的还是批量的。Agentforce 平台通过与 Data 360 的深度集成构建，允许您使用来自 Salesforce CRM 和其他来源的结构化和非结构化数据。非结构化内容可以针对 RAG 进行本地分块和索引。MuleSoft 允许您连接到外部系统。
- **工具**:确定客服人员必须执行的操作。使用 Agentforce 操作公开实现业务目标的工具。这些操作利用现有的 Salesforce 资产，例如通过提示生成器、MuleSoft、Apex、流和 API 进行提示，并具有 OpenAPI 规范。任何可调用操作都可以集成到 Agentforce 中并由客服人员使用，从而使所有熟悉的 Salesforce 开发工具都可以作为 Agentforce 操作随时使用。
- **输入客服人员的数据**:在传统的 SDLC 中，输入是精确指定的。在 ADLC 中，输入通常是自然的、非确定性的、自由形式的话语。收集预计将产生适当响应的代表性话语语料库。
#### 第 2 阶段：开发
开发阶段的重点是将意见和设计阶段中确定的已定义客服人员的目的、功能和操作范围转换为新的 Agentforce Agent。
为了帮助开发人员创建客服人员,Agentforce 提供了 **Agent Builder** 和 **Agentforce Developer Experience (AFDX)。**这些基础工具是构建和配置客服人员的主要环境。
- **客服人员生成器**为定义客服人员的核心功能提供了 UI 体验。
- **AFDX** 为自定义和与其他系统集成提供了编程界面。
开发和构建客服人员涉及这些步骤，可以使用客服人员生成器或 AFDX 执行：
1. **定义角色**:客服人员设计的一个关键方面是建立独特的角色。这涉及配置：
- **客服人员描述**:客服人员角色、目标和旨在处理的特定客户服务任务的详细描述。
- **语气**:客服人员的沟通风格、共鸣程度，以及需要遵守的任何特定品牌准则。
2. **定义客服人员主题和操作**:要使客服人员变得复杂，能够处理各种任务，就必须通过相应的操作将其能力细分为不同的主题。
- **主题**:每个主题都可以被概念化为自己的专业客服人员，具有一组独特的说明和工具。
- **模块化架构。**主题的模块化方法允许更高的组织和可扩展性。通过定义多个主题，客服人员可以处理更广泛的复杂场景。例如，客服人员可能有单独的“订单管理”、“常见问题解答”、“技术支持”和“计费查询”主题。
- **主题说明(护栏)**:每个主题都有充当保护屏障的特定说明，定义了客服人员可以在该主题中讨论或执行的操作的范围。这些说明可防止客服人员偏离主题或提供无关信息。它们也有助于保持回复的一致性和准确性。
- **操作**:主题还配有“工具”，表示客服人员可以采取的操作。这些工具可以是：
- **信息操作**:从 Knowledge 库或外部系统检索数据以回答查询。
- **事务操作**:代表用户执行操作，例如下订单、更新客户记录或启动退款流程。这些操作通常与其他系统集成（例如 CRM、ERP）。
#### 阶段 3：测试和验证
在评估 AI 客服人员的性能和可靠性时，测试人员通常会遇到一系列可能降低用户体验的挑战。这些问题从误解用户意图到无法正确执行任务。
##### 常见客服人员失败情况
构建强大的客服人员需要了解失败的方式和地点。下表分类了客服人员生命周期中遇到的常见问题，从推理错误到 Knowledge 检索不当。将此用作开发期间的战略指南和测试期间的核对清单，以确保客服人员不仅功能正常，而且对最终用户可靠直观。这些失败场景应有助于您定义测试用例。
##### 话语分析
话语分析显示 Agentforce（默认）用户如何使用客服人员、他们请求的内容以及客服人员是否能够处理这些请求。这些可自定义报表可以帮助您优化主题和操作，以便客服人员更有效、更准确地做出响应。
##### Agentforce Python SDK：使用 Data 360 集成进行监控
Agent SDK 实施使用高级监控和分析与 Data 360 Python 连接器，建立与 Salesforce Data 360 的连接，查询客服人员绩效指标，并创建全面的监控仪表板。
系统会跟踪响应时间、成功率、用户满意度和成本度量，以为客服人员优化提供可行的见解。
```py
# Data 360 Python Connector Integration
from salesforce_cdp_connector import SalesforceCDPConnector
# Initialize Data 360 Connector
cdp_connector = SalesforceCDPConnector(
client_id='your_client_id',
client_secret='your_client_secret',
username='your_username@example.com',
password='your_password'
)
# Query agent performance data
performance_data = cdp_connector.query("""
SELECT timestamp, response_time_ms, success_rate, user_satisfaction
FROM AgentPerformanceMetrics
WHERE agent_id = 'Coral_Cloud_Resorts_Resort_Manager'
""")
# Create monitoring dashboard
def create_monitoring_dashboard(performance_data):
fig = go.Figure()
fig.add_trace(go.Scatter(
x=performance_data['timestamp'],
y=performance_data['response_time_ms'],
mode='lines+markers'
))
return fig
```
##### Agentforce DX：客服人员监控
实施使用标准 AFDX 命令和基于 CLI 的客服人员管理，使客服人员了解平台的最新变化，并纳入用户反馈，以实现持续改进。
```zsh
# List all agents and their status
sf agent list --target-org "production-org"
# Get detailed agent information
sf agent get \
--api-name "Resort_Manager" --target-org "production-org"
# Activate agent if needed
sf agent activate --api-name "Resort_Manager" --target-org "production-org"
# Query agent performance data
sf data query \
--query "SELECT Id, Name, Status, LastModifiedDate FROM BotDefinition WHERE DeveloperName = 'Resort_Manager'" \
--target-org "production-org"
```
```python
# AgentforceDX Dashboard Creation (Similar to Agent SDK)
import pandas as pd
import plotly.graph_objects as go
from salesforce_cdp_connector import SalesforceCDPConnector
# Initialize Data 360 Connector for AgentforceDX
cdp_connector = SalesforceCDPConnector(
client_id='your_client_id',
client_secret='your_client_secret',
username='your_username@example.com',
password='your_password'
)
# Query agent performance data from Data 360
performance_data = cdp_connector.query("""
SELECT timestamp, agent_id, response_time_ms, success_rate, user_satisfaction
FROM AgentPerformanceMetrics
WHERE agent_id = 'Resort_Manager'
AND timestamp >= CURRENT_DATE - 30
ORDER BY timestamp DESC
""")
```
有关使用 Agent SDK 和 AFDX 实施 ADLC 的信息，请参考[这里](https://github.com/akshatasawant9699/ADLC_Whitepaper)的 GitHub 存储库。
## 最佳实践
掌握客服人员开发生命周期需要遵守一套核心原则，以确保效率、可靠性和战略一致性。以下指导原则将从 ADLC 每个阶段的关键经验教训综合到架构师和开发人员的战略框架中。
**1\.计划和构想**
此初始阶段的重点是使客服人员的目的与业务目标保持一致，并确保建立在坚实的基础上。
- **优先考虑业务影响**:首先将潜在用例直接映射到战略业务目标。使用优先级矩阵对潜在影响进行评分，并从单个重点用例开始，用例具有明确的 KPI。
- **尽早让利益相关者参与**:收集痛点的见解，并确保保持一致。
- **利用数据见解**:客服人员仅与其数据一样好。使用 Data 360 探索可用的结构化和非结构化数据，以告知客服人员上下文和功能。查看现有报表和仪表板，以确定当前趋势，为用例选择提供信息。
- **使用意见框架**:应用结构化意见方法集思广益并优化潜在应用，例如设计思维或 SWOT 分析。
**2\.建筑代理**
此阶段涵盖了构建高性能高效客服人员的最佳实践。
- **避免过多主题**:限制主题数量，以减少创建可能混淆客服人员的相似或重叠主题的风险。
- **保持说明和提示简洁**:使用直接、简单的语言，并提供示例话语，以有效指导客服人员。
- **利用变量和确定性操作**:使用这些工具来指导客服人员的行为，并优化其性能，以获得更可预测的结果。
- **保持操作输出简洁**:确保客服人员的回复简洁明了。较长的输出使用较多的上下文，生成速度较慢。
- **针对速度优化操作**:设计流和 Apex 类，以返回最少的所需数据。尽可能通过预处理减少生成响应所需的操作。
- **定义明确范围**:编写适当的描述、说明和操作范围，以防止客服人员调用 RAG（检索扩充生成）处理范围外的问题。
- **混合搜索**:只有在绝对必要的情况下才使用混合搜索，因为它会对延迟产生负面影响。
**3\.测试、监控和调整**
此迭代阶段对于提高客服人员的准确性和性能至关重要。
- **建立测试流**:遵循一致的测试周期：
1. **运行批处理测试**:执行一组全面的测试。
2. **查看分数/错误**:分析性能度量并识别失败。
3. **检查失败**:检查每个故障行，以了解差异。
4. **更新客服人员**:对客服人员或其评估数据进行必要的调整。
- **审查会话跟踪信息**:在发现问题或意外行为时，使用会话跟踪数据模型和 Agentforce 交互资源管理器执行根本原因分析。根据信息调整客服人员，并继续迭代客服人员。
## 结论
*客服人员开发生命周期*代表了传统软件开发原则的关键演变，专为智能自主系统时代而设计。
- **进化而非替换**:客服人员开发生命周期扩展和增强了传统的应用程序生命周期管理，无需替换。
- **作为一等公民的数据**:数据在客服人员开发中扮演着更加动态的核心角色。
- **专用工具和技能**:需要新的工具和更广泛的跨数据科学、ML 工程和客服人员开发的专业技能。
- **持续学习**:客服人员开发增加了系统本身的持续*学习*和*调整*。
- **未来影响**:客服人员 AI 有望进一步自动化和优化复杂的 IT 操作和软件开发工作流。