在传统的软件开发中，软件开发生命周期 (SDLC) 为构建应用程序提供了一种结构化的分阶段方法。它确立了质量，降低了风险，并提供了从想法到发布的清晰路线图。客服人员开发生命周期 (ADLC) 是一种类似的方法，专门为解决构建自主客服人员的独特复杂性而定制。

客服人员不是被动应用程序；他们是在动态执行环境中推理、行动和学习的系统。它们的非确定性行为使得传统的 QA 不足。Agent 开发生命周期 (ADLC) 由 Agentforce 等平台支持,通过五个阶段解决此问题：意见和设计、开发（“内循环”）、测试和验证、部署以及持续监控和调整（“外循环”）。

对于已经熟悉软件开发生命周期 (SDLC) 复杂性并想要将专业知识扩展到基于客服人员的系统的开发人员和企业架构师，本文档为他们提供了全面的指南。我们的主要目标是通过强调客服人员开发生命周期 (ADLC) 与传统 SDLC 方法的关键区别，并提供结构化框架来构思构建、部署和管理智能客服人员的整个过程，从而帮助快速了解客服人员开发生命周期 (ADLC)。

该文档分为三个不同的章节，每个章节旨在逐步建立您的 Knowledge 和实践技能：

• **第 1 章 框架。**本章介绍了客服人员开发生命周期 (ADLC)，详细描述了由于开发自主客服人员的独特挑战而与 SDLC 的差异。它为设计、开发、测试和部署客服人员建立了一个框架。
• **第 2 章 平台。**本章探索 Agentforce，这是一个简化和加速整个客服人员开发生命周期的统一平台。Agentforce 为客服人员设计、数据处理、模型训练、部署和持续监控提供了工具，简化了复杂的任务并提高了效率。
• **第 3 章: Pro-Code 实施。**本指南使用 Agentforce 的专业代码工具，为客服人员开发提供实际的逐步说明和实际示例。它涵盖了整个客服人员开发生命周期，从原型和功能工程到模型部署、性能调整和维护，使开发人员具备构建生产就绪客服人员的技能。

本文档旨在为您提供 Agentforce 专业代码工具的理论和实践 Knowledge。您将学习高效、安全可靠地构建、部署和监控客服人员，全面了解 ADLC，并最大限度地发挥 Agentforce 在智能客服人员开发中的潜力。

AI 客服人员的非确定性需要专门的开发框架。本章通过介绍客服人员开发生命周期 (ADLC) 概述了该框架。本章全面概述了 ADLC 的五个核心阶段，从最初的想法和设计到持续的监控和调整。本章建立了构建强大可靠的客服人员所需的基础 Knowledge。

本节将 SDLC 概念映射到 ADLC 的五个阶段。

这是定义客服人员战略目标和运营边界的基础阶段。结构合理的设计阶段是成功的最重要一步，因为它将业务需求转化为技术蓝图。设计流程确保客服人员不仅具有功能性，而且还负责并与用户期望保持一致。它是在编写任何代码之前确定“什么”和“为什么”的地方。

1. 定义客服人员目标和功能:首先，您必须清楚地阐明客服人员的主要目标，以及将执行的具体、可衡量的任务。这涉及定义其角色（例如，“客户服务助理”）、其核心职能（例如，“预订预约”、“回答产品问题”）以及每个角色的成功度量。
2. 建立人格和道德护栏:此步骤涉及设计客服人员的个性并定义其道德边界，以确保其可信和安全。它确定了客服人员的语气（例如，“正式”、“友好”），并实施严格的规则来防止有害、有偏见或不适当的回应。
3. 映射上下文和理解:您必须确定客服人员需要了解并记住哪些信息才能有效。这包括定义 Knowledge 库及其对话记忆的范围，这允许它进行连贯的多轮对话。
4. 识别工具和系统集成:这涉及清点客服人员执行任务时必须连接的外部系统、API 和数据源。系统会识别每个工具（例如，预订 API、客户数据库），并将其功能映射到特定的客服人员功能。
5. 制定在环人员升级计划:定义客服人员升级为人员的条件至关重要。这涉及检查潜在的故障点和对话“死角”，以确定客服人员何时应该升级为人工操作员。设计应描述如何执行此切换，以确保转移足够的上下文，以便可以快速消耗以确保无缝的客户体验。

这是实践构建阶段，设计蓝图转化为功能客服人员。开发人员构建客服人员，将其连接到工具，并使用履行职责所需的数据为其提供支持。这种构建和细化的迭代“内循环”是客服人员真正发挥作用的地方。

1. 配置客服人员的逻辑和决策:此步骤包括将客服人员的决策框架连接到上下文、工具和数据源，形成客服人员的推理。开发人员的角色是通过创建 API 或重复使用现有 API、设置操作防护以及指定客服人员如何选择和使用可用工具来完成复杂的多步骤任务来定义客服人员的行为。
2. 工程师提示和微调模型:客服人员的角色、说明和约束通过细致的提示工程进行编码。此过程包括设计指导大型语言模型 (LLM) 的主提示，对于更高级的用例，调整特定于领域的数据的模型以提高其性能。
3. 集成和保护 AI 工具:在设计阶段识别的函数和 API 连接到客服人员。使用 SDK，开发人员封装现有功能或创建新功能，使它们可被客服人员安全地调用，并确保它们具有适当的身份验证和错误处理。
4. 构建数据和 RAG 漏斗:为了通过外部 Knowledge 为客服人员提供支持，开发人员为检索扩充生成 (RAG) 构建数据漏斗。这涉及连接和索引来自向量存储、关系数据库、图形数据库或内部文档等来源的数据，使客服人员可以访问这些信息，以提供准确的上下文感知响应。

测试 AI 客服人员会从传统软件的确定性验证引入范式转变。虽然常规应用程序会测试正确性（特定输入必须产生单一预期输出），但客服人员的非确定性需要更复杂的方法。目标不是验证一个正确答案，而是确保客服人员的行为符合预期目的，对意外输入具有鲁棒性，并且在一系列可接受的结果中保持可靠。

1. 单元测试:此层重点关注客服人员的确定性非 AI 组件。它涉及传统的单元测试，以验证每个单独的工具和功能是否单独正常工作，确保在应用客服人员的复杂推理之前有一个可靠的基础。
2. 端到端 (E2E) 测试:此阶段评估客服人员在现实场景中实现目标的能力，鉴于其不确定性，这是至关重要的。这些端到端的测试不是检查准确的输出，而是验证客服人员是否成功完成了任务，并且其性能不会随着更改而下降。
3. 对抗性和鲁棒性测试:这是故意试图让客服人员主动发现其弱点的做法。测试人员使用不明确的请求、恶意提示和其他边缘个案来揭露漏洞，并确保客服人员在压力下保持弹性和安全。
4. 人工在环 (hitL) 评估:由于自动测试无法测量语气或对话流等细微的质量，因此此阶段依赖于人类的反馈。测试人员与客服人员交互，对客服人员的回答进行评分，以了解帮助和整体用户体验，为微调客服人员的行为提供必要的数据。
5. 性能和规模测试:这是防止性能瓶颈影响用户的关键步骤。此流程模拟了真实的峰值使用情况场景，以确保客服人员和应用程序可以平稳和预测地处理大量数据。它验证解决方案不仅正确，而且可扩展。

部署 AI 客服人员是一个受管流程，侧重于确保验证的客服人员是用户以可靠和可重复的方式交互的对象。这需要一种结构化的方法，将客服人员从版本控制的资产转移到实时的监控服务。

1. 打包和版本控制:客服人员的整个定义，包括其提示和工具，都被捕获为文件中的元数据，并存储在源控制系统中，例如 Git。这将创建单一的真实来源和所有更改的可审计历史。
2. CI/CD 漏斗:生产路径是自动化的，以消除人为错误并确保一致性。这些漏斗通过开发、测试和生产环境自动升级客服人员，在每个阶段运行端到端测试，以充当质量网关。
3. 分阶段推出策略:为了最大限度地减少风险，首先使用金丝雀发布等策略向一小部分用户发布新的客服人员版本。这允许在完全推出之前进行实际的性能监控，如果发现任何问题，能够快速恢复。
4. 激活和治理:推出客服人员的关键步骤包括安全地激活具有正确权限的客服人员，并确保它连接到监控工具。这将从新部署的客服人员上线的那一刻起立即提供对其运行状况和性能的可见性。

部署不是客服人员开发生命周期的结束；而是持续“外循环”的开始。客服人员是在不可预测的真实环境中运行的动态系统。该阶段致力于观察客服人员的实时表现，从其互动中收集见解，并使用这些数据随着时间的推移系统地完善和改进其有效性、安全性和效率。

1. 实时性能监控:这是跟踪客服人员与用户交互时的关键操作度量的实践。仪表板用于监控延迟、令牌消耗（成本和 API 错误率，并提供客服人员运行状况和效率的即时高级视图。
2. 行为和 Success Analytics:这涉及分析对话日志，以了解客服人员实际如何履行职责。它侧重于跟踪任务完成率，确定常见的故障点或对话“死角”，并衡量用户满意度，以确定客服人员是否成功实现了目标。作为服务客服人员的示例，它可以提供有关客服人员升级为人工的频率和原因的度量。
3. 智能调整和完善:这是使用来自监控的见解来改进客服人员的有效过程。这可以从提示工程到工具优化。
4. 数据驱动的 RAG 增强:根据真实查询，客服人员 Knowledge 库的质量会不断提高。监控可能会发现客服人员正在处理某些主题，从而导致数据源或检索流程的细化 (RAG 细化)，以提高其回复的准确性。
5. 持续学习和适应:这涉及创建反馈循环，其中生产数据用于使客服人员更智能。通过标记交互日志（使用人工监督或基于 LLM 的标记），构建了经过策划的数据集，可用于微调基础模型并建议进一步改进

Agentforce 通过设计、开发、测试、部署、监控和分析的集成工具支持每个 ADLC 阶段，所有这些都在一个统一平台中，用于快速构建和测试强大的客服人员。

Agentforce ADLC 基于以下指导原则：

• 专为低代码和专业代码构建:支持基于配置的部署（低代码）和程序扩展性（专业代码）。
• 持续的 AI 驱动的帮助和反馈循环:捕获和分析对话数据，为客服人员调整提供信息，以实现持续 AI 驱动的改进。
• 所有级别的测试驱动开发:跨所有阶段的严格测试，通过传统的单元测试来验证确定性组件，并为测试客服人员推理和非确定性行为提供新的方法。
• 主管和 LOB 可观察性:为运营和执行利益相关者提供成本、使用情况和绩效指标。

本章显示了 Agentforce 如何在单一统一平台内支持 ADLC 的每个阶段

意见

意见阶段是 ADLC 的基础阶段，在这里制定客服人员的初始愿景和要求。它涉及深入了解问题，确定潜在的解决方案，并概述客服人员的核心职能。

通过定义客服人员的关键属性，开始他们的想法过程：

1. 目的/目标:明确定义客服人员的主要目标。它旨在解决什么具体问题，或者它打算完成什么任务？客服人员应为谁提供服务？这应当是指导整个发展进程的简明和可衡量的声明。
2. 角色:为客服人员制定详细的角色。这包括定义其身份、通信风格，以及在与用户或其他系统交互时将扮演的角色。考虑它的语气、正式程度，以及使它在预期上下文中有效的任何特定特征。
3. 模式:确定并链接到相关的客服人员模式和实施策略。这涉及架构设计或最佳实践，可为客服人员的结构和行为提供信息。"Salesforce Agentforce 上的代理模式和实施:技术白皮书》是这一步骤的宝贵资源,提供了关于 Salesforce 平台和 Agentforce 上有效客服人员设计的见解。

设计

设计阶段将概念从构想转化为客服人员构建的详细蓝图。这涉及定义客服人员的架构、用户流、交互模型和技术规格，例如主题、工具和防护。

在设计阶段，您将为客服人员的构建创建详细的蓝图，其中包括：

• 客服人员设计:概述客服人员的内部结构，包括其组件、模块以及它们如何交互。这可能涉及定义 Knowledge 库、配置和逻辑来控制客服人员行为、自然语言处理 (NLP) 组件以及与其他系统的集成点。
• 用户流/交互设计:映射完整的用户旅程和客服人员的交互。定义对话流、决策树、错误处理和反馈机制，以创建直观、有效的体验。
• 技术规格:记录客服人员的技术非功能要求，例如性能度量、可扩展性注意事项、安全协议和集成规范。
• 原型和模型:创建客服人员界面和交互的可视表示或交互原型。这允许早期测试和反馈，有助于在开始全面开发之前完善设计。
• 数据:在确定客服人员需要的数据类型和来源时，确定客服人员必须访问的数据集、API、数据库和存储库。对于 Agentforce，关注作为上下文提供的数据，无论是结构化还是非结构化，以及它是实时的还是批量的。Agentforce 平台通过与 Data 360 的深度集成构建，允许您使用来自 Salesforce CRM 和其他来源的结构化和非结构化数据。非结构化内容可以针对 RAG 进行本地分块和索引。MuleSoft 允许您连接到外部系统。
• 工具:确定客服人员必须执行的操作。使用 Agentforce 操作公开实现业务目标的工具。这些操作利用现有的 Salesforce 资产，例如通过提示生成器、MuleSoft、Apex、流和 API 进行提示，并具有 OpenAPI 规范。任何可调用操作都可以集成到 Agentforce 中并由客服人员使用，从而使所有熟悉的 Salesforce 开发工具都可以作为 Agentforce 操作随时使用。
• 输入客服人员的数据:在传统的 SDLC 中，输入是精确指定的。在 ADLC 中，输入通常是自然的、非确定性的、自由形式的话语。收集预计将产生适当响应的代表性话语语料库。

开发阶段的重点是将意见和设计阶段中确定的已定义客服人员的目的、功能和操作范围转换为新的 Agentforce Agent。

为了帮助开发人员创建客服人员,Agentforce 提供了 Agent Builder 和 **Agentforce Developer Experience (AFDX)。**这些基础工具是构建和配置客服人员的主要环境。

• 客服人员生成器为定义客服人员的核心功能提供了 UI 体验。
• AFDX 为自定义和与其他系统集成提供了编程界面。

开发和构建客服人员涉及这些步骤，可以使用客服人员生成器或 AFDX 执行：

1. 定义角色:客服人员设计的一个关键方面是建立独特的角色。这涉及配置：
   • 客服人员描述:客服人员角色、目标和旨在处理的特定客户服务任务的详细描述。
   • 语气:客服人员的沟通风格、共鸣程度，以及需要遵守的任何特定品牌准则。
2. 定义客服人员主题和操作:要使客服人员变得复杂，能够处理各种任务，就必须通过相应的操作将其能力细分为不同的主题。
   • 主题:每个主题都可以被概念化为自己的专业客服人员，具有一组独特的说明和工具。
     • **模块化架构。**主题的模块化方法允许更高的组织和可扩展性。通过定义多个主题，客服人员可以处理更广泛的复杂场景。例如，客服人员可能有单独的“订单管理”、“常见问题解答”、“技术支持”和“计费查询”主题。
   • 主题说明(护栏):每个主题都有充当保护屏障的特定说明，定义了客服人员可以在该主题中讨论或执行的操作的范围。这些说明可防止客服人员偏离主题或提供无关信息。它们也有助于保持回复的一致性和准确性。
   • 操作:主题还配有“工具”，表示客服人员可以采取的操作。这些工具可以是：
     • 信息操作:从 Knowledge 库或外部系统检索数据以回答查询。
     • 事务操作:代表用户执行操作，例如下订单、更新客户记录或启动退款流程。这些操作通常与其他系统集成（例如 CRM、ERP）。

在评估 AI 客服人员的性能和可靠性时，测试人员通常会遇到一系列可能降低用户体验的挑战。这些问题从误解用户意图到无法正确执行任务。

常见客服人员失败情况

构建强大的客服人员需要了解失败的方式和地点。下表分类了客服人员生命周期中遇到的常见问题，从推理错误到 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 并重新索引。这确保了客服人员在测试期间使用当前信息，并可以准确地检索和合成内容。

Agentforce 通过元数据定义客服人员，因此可以使用标准 Salesforce 程序进行部署，例如更改集或 AFDX。此阶段强调通过重要功能（例如客服人员版本）进行安全和受控的推出，以及单独的激活步骤，这将确保系统稳定性并允许从问题中快速恢复。

按照这些步骤部署和释放新客服人员。

1. 通过更改集/元数据 API 或 AFDX 部署:客服人员的部署流程利用标准 Salesforce 程序，将客服人员视为元数据。对于任何习惯于 Salesforce 开发和部署的人员来说，这应该是熟悉的流程。使用更改集或 AFDX 可确保在环境之间迁移客服人员配置的结构化和一致方法，例如从 Sandbox 迁移到生产环境。此方法有助于版本控制和正确变更管理，这对保持系统稳定性和可靠性至关重要。
2. 部署后激活客服人员:在成功部署后，系统管理员必须主动“激活”客服人员。部署只需将客服人员的代码和元数据放入目标环境；激活是使客服人员可操作和可用的步骤。这种分离允许在客服人员上线并与最终用户或其他系统组件交互之前进行受控的推出和测试。
3. 使用版本控制进行安全客服人员管理:客服人员版本化是一项关键功能，可显著增强客服人员开发和维护的安全性和灵活性。
   1. 创建、测试和发布新版本:推荐的实践包括在需要更改或增强时创建客服人员的新版本。然后，该新版本可以在 Sandbox 环境中彻底测试，而不会影响实时激活的客服人员。一旦新版本经过验证并被认为准备就绪，就可以发布并随后激活它，以替换以前的操作版本。这种迭代过程允许持续改进和创新，同时最大限度地减少中断。
   2. 回滚到早期版本:如果新部署或激活的客服人员出现问题，版本化的一个主要好处是能够快速轻松地恢复到以前的稳定版本。如果出错（例如，如果客服人员行为不当或出现意外错误），管理员只需回滚到上一个已知良好版本并将其激活。此功能提供了关键的安全网络，允许快速恢复并最大限度地减少停机时间，从而确保业务连续性和用户满意度。

客服人员监控

Agentforce 会话跟踪是一个基于 Data 360 构建的开放、可扩展的模型，可以捕获端到端的客服人员交互。Agentforce 会话跟踪从不同来源接收数据（从推理引擎日志开始），并将所有内容合并到会话 ID 下。

会话跟踪数据模型 (STDM) 提供了关于客服人员会话期间发生情况的详细信息，包括：

• 逐轮交互
• 引擎执行原因
• 操作、提示和网关输入/输出
• 错误消息
• 最终答复

STDM 是一款重要工具，可帮助开发人员：

• 在构建期间调试客服人员设置和配置问题。
• 了解某些测试用例在批量测试期间失败的原因。
• 解决客服人员无法处理一组用户问题或偏离主题的原因。

开发人员应使用此会话跟踪数据来观察、监控、调查和排除客服人员事件、事件和行为模式。

STDM 包括存储客服人员行为详细日志的数据湖对象 (DLO) 和数据模型对象 (DMO)。关于推理引擎进行的每个 LLM 调用的元数据可以与反馈或防护度量结合。数据流到 Data 360 中的 DLO，并映射到适用的 DMO。

开发人员可以通过针对 STDM 运行查询和报表来访问这些数据并获得见解。STDM 的组件描述如下。

Agentforce 会话跟踪数据模型 ERD

Agentforce 优化

Agentforce 优化是一项强大的功能，旨在通过提供对用户交互的深入见解来提高 AI 客服人员的性能。它构建于会话跟踪数据模型 (STDM) 的分析功能之上，允许管理员和开发人员了解用户主题、参与模式和客服人员解析的有效性。

Agentforce 优化的关键方面包括：

• 特定于时刻的数据 优化通过引入"时刻"来扩展 STDM，"时刻"代表会话期间专注于特定用户意图或请求的交互。这些粒度数据允许详细检查交互的每个方面，从最初的用户请求到客服人员的解决。
• 自动时刻处理:时刻每天生成，然后使用高级大语言模型 (LLM) 在所有活动客服人员中每周进行集群和标记。这种细分简化了查询，并提供了对客服人员会话各个方面的见解。
• 查询和分析:用户可以根据标记、质量分数和其他条件查询时刻。这可以通过时刻持续时间和相关性质量分数等指标评估用户参与度，帮助确定需要改进的领域。
• 统一数据模型 优化利用统一的会话跟踪数据模型 (STDM)，该模型捕获会话中的每个记录事件，包括个人对话轮次。在设置中启用 STDM 时，会配置所有相关实体。

通过分析 AI 客服人员交互，Agentforce 优化使用户能够识别需要改进的领域，并优化配置，以更好地满足用户需求。

有关更多信息，请查看 Data Model for Agentforce Optimization。

本章是专业代码开发人员的实用指南。它显示了如何使用 Agentforce DX (AFDX) 和 Python SDK 快速安全地构建、测试和部署客服人员。我们将使用 AFDX 和 Python SDK 的强大组合，完成从初始设计到版本控制的客服人员的整个生命周期。

以下示例将利用两个用于在 Agentforce 平台上构建和管理客服人员的关键工具集。建议对这些工具有基本了解，以充分利用本指南。

1.Agentforce DX (AFDX)：用于管理生命周期

Agentforce DX 扩展了熟悉的 Salesforce Developer Experience (SFDX) 工具集，包括 Salesforce CLI 和 VS Code 扩展，以支持整个客服人员开发生命周期。它用于作为版本控制的元数据管理客服人员，从命令行自动化测试，并编排开发 Sandbox 和生产之间的部署。

要了解更多信息，请参阅：Agentforce DX 开发入门

2.Agentforce Python SDK：用于构建客服人员

Python SDK 为开发的“内部循环”提供了编程界面。它允许您定义客服人员的推理逻辑，连接工具，并直接在熟悉的 Python 环境中管理提示模板，从而简化 ADLC 的核心构建阶段。

SDK 在 PyPI 上可用：https://pypi.org/project/agentforce-sdk/。

完整的项目在此处可用：
https://github.com/akshatasawant9699/ADLC_Whitepaper.

此基础阶段定义了客服人员的目的、角色和核心功能。它涉及回答关键问题，以便在编写任何代码之前构建客服人员的“大脑”。在本例中，我们正在为 Coral Cloud Resorts 设计客服人员。

• 任务:客服人员充当度假村经理，处理客户投诉，管理员工日程安排，并确保度假村运营平稳。
• 角色:客服人员的语气有帮助、专业和会话。
• 工具和功能:客服人员需要访问预订系统、员工计划软件和度假村策略。
• 决策逻辑:客服人员使用 AI 生成的主题来确定用户意图并生成适当的操作。

通过Agentforce DX,设计阶段转化为有形的规范文件:Agentforce DX：生成客服人员规格。Pro-Code 过程的第一步是生成 agentSpec.yaml 文件。YAML 文件捕获客服人员的核心设计，包括其角色、相关公司详细信息，以及 AI 生成的主题列表，这些主题定义了客服人员可以处理的作业。

使用 Salesforce CLI 通过交互式提示生成此规格。要开始使用 Agentforce DX 创建客服人员，请运行：

您需要提供在意见阶段定义的特定详细信息：

• 客服人员类型:客户
• 公司名称:珊瑚云度假村
• 公司描述:珊瑚云度假村为客户提供卓越的目的地活动、难忘的体验和预订服务，所有这些都以承诺提供一流的客户服务为后盾。
• 客服人员角色:度假村经理处理客户投诉，管理员工日程安排，并确保所有流程平稳运行。

运行此命令会在 DX 项目的规格目录中创建 agentSpec.yaml 文件。该文件包含提供的信息，以及 AI 生成的主题列表，其中包含每个主题的名称和描述。根据需要查看和编辑文件，以优化客服人员的功能。

相似地，Python SDK 实施使用交互式规范集合自动生成具有 SDK 兼容性所需的正确范围字段的客服人员主题。
此外，将创建完整的客服人员规范 JSON 文件，该文件将用于在阶段 2 中创建客服人员。

开发阶段的重点是构建客服人员的核心组件：推理引擎、可以使用的工具及其 Knowledge 库。Agentforce 抽象了大部分的复杂性, 这使得开发人员能够专注于业务逻辑。

本节共享 Agentforce 开发阶段的两种支持代码的方法。首先，使用 Agentforce DX，然后使用 Python。

Agentforce DX：从规范创建客服人员

在 agentSpec.yaml 文件准备就绪后，在 Salesforce 组织中创建客服人员。运行此命令创建客服人员，并将其关联的元数据同步回本地 DX 项目：

出现提示时，接受默认 API 名称 Resort_Manager。该命令解析规格，创建客服人员，并检索元数据。元数据包括 Bot、BotVersion 和 GenAiPlannerBundle，它们将 AI 智能和引用添加到客服人员的主题和操作。

通过添加 -- 预览标志，在创建客服人员结构之前预览客服人员结构，以生成本地 JSON 文件，该文件详细说明 LLM 将创建的客服人员类型，包括建议的操作。例如：

有关更多信息,请参阅从 Trailhead 从 DX 项目创建客服人员。

Agentforce Python SDK：定义特定工具

客服人员 SDK 通过创建模拟操作来促进客服人员测试。这些模拟操作最终需要由 Salesforce 中的实际操作替换。Salesforce 提供一系列平台功能，包括流、Apex、提示模板和 API，所有这些都可以封装为 Agentforce 操作。

以下是模拟操作代码片段，以说明 Agentforce 操作的外观。

实施建立与 Salesforce 的连接，创建客服人员实例，并定义客服人员可用于与外部系统进行交互和执行特定业务功能的自定义工具和操作。

正如我们上文所讨论的，测试客服人员比传统的软件测试更加复杂。它需要在各种场景中验证行为、推理和鲁棒性。这包括单个工具的单元测试、对话的端到端测试以及查找漏洞的对抗性测试。

Agentforce DX除了测试中心和直接的测试 API 之外,还为创建、部署和运行测试提供了高级工作流。本节演示使用 Agentforce DX 执行测试。

Agentforce DX：运行客服人员测试

使用 Agentforce DX 直接从命令行运行预定义的客服人员测试。这是将客服人员测试集成到现代 DevOps 流程的理想选择。

Agentforce Python SDK：模拟 E2E 和对抗性测试

在概念上,Python SDK 允许脚本对话来模拟端到端 (E2E) 测试和验证客服人员推理。

Agentforce Python SDK 和 Salesforce 测试 API

Python SDK 实施使用 Salesforce 测试 API 和 AiEvaluationDefinition 元数据的综合测试，创建具有主题序列、操作序列、字符串匹配和质量度量预期的结构化测试用例。系统会生成可部署到 Salesforce 的 XML 元数据定义，以进行自动客服人员测试和验证。

验证后，客服人员会部署到生产环境中。在这一阶段,Agentforce DX对于帮助在不同组织(例如 Sandbox 和生产)之间管理和移动客服人员元数据至关重要。客服人员部署会创建客服人员的新版本，客服人员只有在您明确激活后才能上线。这可让您完全控制何时发布新版本的客服人员。

Agentforce DX：部署客服人员元数据

标准 Salesforce DX 项目结构在 force-app 目录下组织客服人员元数据。使用标准 sf project deploy 命令将客服人员及其相关测试部署到目标组织。

在创建或部署客服人员后，您可以直接在 Agentforce Builder UI 中打开它，以通过以下运行来验证其配置：

验证客服人员已部署后，您可以将其激活。如果您遇到任何意外问题，请回滚到客服人员的上一个工作版本。

Agentforce Python SDK：部署客服人员部署

实施获取经过验证的客服人员规范，并将其部署到 Salesforce 组织，使客服人员可以使用。部署过程包括客服人员创建、元数据同步和验证成功部署。

ADLC 是一个连续的周期；部署不是结束。客服人员是实时系统，需要持续监控，以跟踪延迟、成本和成功率等指标。通过提示工程、工具优化和优化 Knowledge 库，从监控中获得的见解可用于调整和改善客服人员绩效。

Agentforce 平台提供全面的仪表板和分析来支持这一关键阶段,确保客服人员随着时间的推移不断发展和改进。

Agentforce Analytics

Agentforce Analytics 位于 Agentforce（默认）文件夹中，使用 Data 360 提供有关客服人员绩效的见解。可自定义仪表板和报表提供有关采用、反馈和使用的数据，帮助您优化主题和操作，以提高用户满意度。您可以通过单击图表或链接的报表深入了解结果。要自定义，复制现有报表并修改复制，以避免中断分析流程。

话语分析

话语分析显示 Agentforce（默认）用户如何使用客服人员、他们请求的内容以及客服人员是否能够处理这些请求。这些可自定义报表可以帮助您优化主题和操作，以便客服人员更有效、更准确地做出响应。

Agentforce Python SDK：使用 Data 360 集成进行监控

Agent SDK 实施使用高级监控和分析与 Data 360 Python 连接器，建立与 Salesforce Data 360 的连接，查询客服人员绩效指标，并创建全面的监控仪表板。
系统会跟踪响应时间、成功率、用户满意度和成本度量，以为客服人员优化提供可行的见解。

Agentforce DX：客服人员监控

实施使用标准 AFDX 命令和基于 CLI 的客服人员管理，使客服人员了解平台的最新变化，并纳入用户反馈，以实现持续改进。

有关使用 Agent SDK 和 AFDX 实施 ADLC 的信息，请参考这里的 GitHub 存储库。

掌握客服人员开发生命周期需要遵守一套核心原则，以确保效率、可靠性和战略一致性。以下指导原则将从 ADLC 每个阶段的关键经验教训综合到架构师和开发人员的战略框架中。

1.计划和构想

此初始阶段的重点是使客服人员的目的与业务目标保持一致，并确保建立在坚实的基础上。

• 优先考虑业务影响:首先将潜在用例直接映射到战略业务目标。使用优先级矩阵对潜在影响进行评分，并从单个重点用例开始，用例具有明确的 KPI。
• 尽早让利益相关者参与:收集痛点的见解，并确保保持一致。
• 利用数据见解:客服人员仅与其数据一样好。使用 Data 360 探索可用的结构化和非结构化数据，以告知客服人员上下文和功能。查看现有报表和仪表板，以确定当前趋势，为用例选择提供信息。
• 使用意见框架:应用结构化意见方法集思广益并优化潜在应用，例如设计思维或 SWOT 分析。

2.建筑代理

此阶段涵盖了构建高性能高效客服人员的最佳实践。

• 避免过多主题:限制主题数量，以减少创建可能混淆客服人员的相似或重叠主题的风险。
• 保持说明和提示简洁:使用直接、简单的语言，并提供示例话语，以有效指导客服人员。
• 利用变量和确定性操作:使用这些工具来指导客服人员的行为，并优化其性能，以获得更可预测的结果。
• 保持操作输出简洁:确保客服人员的回复简洁明了。较长的输出使用较多的上下文，生成速度较慢。
• 针对速度优化操作:设计流和 Apex 类，以返回最少的所需数据。尽可能通过预处理减少生成响应所需的操作。
• 定义明确范围:编写适当的描述、说明和操作范围，以防止客服人员调用 RAG（检索扩充生成）处理范围外的问题。
• 混合搜索:只有在绝对必要的情况下才使用混合搜索，因为它会对延迟产生负面影响。

3.测试、监控和调整

此迭代阶段对于提高客服人员的准确性和性能至关重要。

• 建立测试流:遵循一致的测试周期：
  1. 运行批处理测试:执行一组全面的测试。
  2. 查看分数/错误:分析性能度量并识别失败。
  3. 检查失败:检查每个故障行，以了解差异。
  4. 更新客服人员:对客服人员或其评估数据进行必要的调整。
• 审查会话跟踪信息:在发现问题或意外行为时，使用会话跟踪数据模型和 Agentforce 交互资源管理器执行根本原因分析。根据信息调整客服人员，并继续迭代客服人员。

客服人员开发生命周期代表了传统软件开发原则的关键演变，专为智能自主系统时代而设计。

• 进化而非替换:客服人员开发生命周期扩展和增强了传统的应用程序生命周期管理，无需替换。
• 作为一等公民的数据:数据在客服人员开发中扮演着更加动态的核心角色。
• 专用工具和技能:需要新的工具和更广泛的跨数据科学、ML 工程和客服人员开发的专业技能。
• 持续学习:客服人员开发增加了系统本身的持续学习和调整。
• 未来影响:客服人员 AI 有望进一步自动化和优化复杂的 IT 操作和软件开发工作流。