ADG001

课程介绍

好，我们来看这一页，讲的是测试 Agentforce 代理的两种方式，以及一个很重要的观念。 先说说老方法，咱们叫它遗留过程。打个比方，这就像你装软件时，会用到里面自带的、已经写好的测试工具。在 Agentforce 里，就是那个 Legacy Agentforce 测试中心，它提供了一套“预代码”——你可以理解成提前帮你准备好的测试代码片段。你要做的呢，就是透过这些预代码，向你的代理发一些话语，然后检查代理的回答和行为，是不是跟你预期的一样。 那新方式是什么呢？就是用 Agentforce DX 来做测试。这就相当于在你自己的开发组织里，打开测试中心的界面，不过这次用的是“亲代码”——意思是你得亲手去写测试逻辑，更加灵活，也能更贴近真实场景。不管是新方法还是老方法，核心动作都一样：发送话语，验证行为。 但是同学们要记住一点，不管用哪种方式，测试代理绝对不是一个一次性的事情。它就跟我们开发任何软件一样，是一个不断反复、不断打磨的迭代过程。你第一次测可能发现，哎，代理理解错了，那你回去调整一下代理的配置或提示词，再测，再调整，这样一圈一圈地转，直到代理表现得很靠谱为止。 所以简单总结：老路子用预代码测，新路子用亲代码测，但都要反复对话、反复验证，让代理在迭代里越变越聪明。

课程章节

本课程共有 9 个章节

• 1

  Flow of Pro-Code Agent Testing

  第 154 页

  好，我们来看一下亲代码代理的测试流程。你可以把它想象成给代理做一次全面的体检，只不过这个体检是你自己一步步设计和验证的。整个流程分为六个阶段，我们一个一个来说。 第一步，生成测试规范。我们用一条命令，也就是代理的 generate test-spec 命令，让系统自动给你生成一个 YML 文件。这个文件就像是测试的“草稿纸”，上面会有基础的结构。你不需要手写，跑个命令就有了。 第二步，定制这个规范。拿到草稿纸之后，你就可以在上面加料了。比如添加上下文变量，告诉代理“你要用哪些数据来测试”；设置一些衡量指标，成功还是失败，标准是什么；加入自定义评估，也就是你自己想额外检查的东西；甚至还可以放进一段对话历史，模拟之前跟用户聊过的天。这样测试场景就更真实了。 第三步，在开发环境里创建测试。用代理测试创建功能，它就会根据你定制好的规范，在你的开发组织中建好测试用例。如果心里没底，可以先预览一下，看看生成的测试大概长什么样，再正式创建。这样不会弄错。 第四步，运行测试。运行方式很灵活，可以直接在命令行用 CLI，也可以在 VS Code 的测试面板里点一点运行。它支持 JavaScript 语法来写测试逻辑，可以同步运行，还能输出不同格式的结果，方便你看。 第五步，分析结果。跑完测试后，无非两种结果：如果测试通过了，恭喜你，这个部分就完成啦，代理的行为符合预期。如果测试失败了呢？别着急，我们可以用 Agent Preview 来进行对话式调试。你可以在一个可视化的界面里跟代理对话，看看它到底哪句话答错了，哪步逻辑跑偏了，直接排查问题。 第六步，也是最后一步，把测试放进 CI 系统里持续验证。也就是你把这个测试加到你团队的自动集成流水线里，以后每次代码改动，都会自动跑一遍这些测试，确保你的代理不会因为某次修改就突然变笨了。 这样一整套下来，你的代理就能始终保持高质量，任何问题都能尽早发现、尽快修好。你可以把它记成一个六字诀：生成、定制、创建、运行、分析、集成。记住了吗？

  ▶ 播放视频 查看详情
• 2

  Customize the Agent Test Spec

  第 155 页

  同学们，我们接着看下一张幻灯片。刚才我们提到，运行代理生成的测试规范，这是一个很好的起点，但你可以让它变得更强大。因为这个测试规范文件是 YML 格式的，就像写便签一样，很方便手动修改。比如，你可以加入专为服务代理设计的上下文变量，打开内置的质量评估指标，还能用 JSONPath 表达式来定制自己的评估标准。甚至，如果你的代理需要多轮对话测试，也可以直接把对话历史写进去。这样一来，测试就不仅仅是跑一跑了，而是能真正衡量代理到底做得好不好。

  ▶ 播放视频 查看详情
• 3

  Context Variables & Quality Metrics

  第 156 页

  同学们，我们来看这一页。在Agentforce里，服务代理可以拿到一个叫MessagingSession的标准对象，里面放着一些上下文变量，比如用户的语言偏好。有了这些，咱们就可以做出更贴心的个性化对话，用户说西班牙语，咱就用西班牙语回复，不用再绕弯子。 那怎么测试这些上下文变量呢？很简单。你在写测试用例的时候，往里头加一个`contextVariables`部分，里头写“名称-值”对就行。举个例，咱们想测试当用户语言是西班牙语时，代理的表现，那就把`EndUserLanguage`设成`"Spanish"`。这些变量的API名称，你都能在Agent Builder界面里的“上下文”选项卡里直接找到，复制过来就行，不用背。 测试规范呢，系统会自动帮你把上下文这部分加到生成的测试规范文件里，省得你手动去配。接着，每个测试都会跑四个内置的指标，你不用自己定义： - ，连贯性，，看回复读起来顺不顺，语法对不对； - ，完整性，，看基本的信息有没有都覆盖到； - ，简洁性，，看回复是不是啰嗦，够不够精炼； - ，延迟，，就是响应时间，单位是毫秒，越快越好。 跑完测试，结果里会显出每个指标的具体分数和阈值，还会打上“通过”还是“不通过”，一眼就能看清哪里达标、哪里掉链子。如果你觉得某个指标对你场景不重要，比如有些时候不需要那么简洁，那你直接把测试规范那个YAML文件打开，删掉对应的那一段就行，很灵活。 好，这一页就讲这些。记住，用上下文变量做个性化，测试起来就这么几步，有问题随时提。

  ▶ 播放视频 查看详情
• 4

  Custom Evaluations & Conversation History

  第 157 页

  同学们，我们来看一下自定义评估这个功能。简单说，它就是让我们能够精确地检查Agent生成的测试输出里的某个具体值，看看是不是符合预期。 怎么做到呢？首先你运行测试的时候，加一个--verbose参数，这样系统就会把生成的数据详细打印出来。拿到数据后，你就能看到里面的结构，然后写一个JSONPath表达式，这个表达式就像是一个路径，能直接定位到你关心的那个数据点。 接着，你就可以用比较运算符，比如“等于”或者“不等于”，来判断这个值是不是正确的。 这里还有一个很重要的能力——它支持多轮对话的测试。也就是说，我们不是只测一句孤立的问答，而是可以把整个对话上下文带进去测试。测试用例里可以包含角色的消息对，而且我们还能让代理消息指定它使用的是哪个子代理，也就是哪个主题或技能。这对那些依赖上下文的复杂对话流程来说，真的特别关键。 这样一来，我们就能更真实地模拟用户和Agent的交互，确保对话逻辑走得通。好，这部分就是自定义评估的核心要点。

  ▶ 播放视频 查看详情
• 5

  Create an Agent Test

  第 158 页

  今天我们来看一下，当你已经准备好了一份满意的测试规范文件之后，接下来该怎么操作。 首先，你要在你的开发组织里真正地去创建这个测试。但是注意啊，在动手创建测试之前，有一个步骤一定不能忘——你必须先把你的代理发布到当前这个组织里去。也就是说，代理得先存在，然后测试才能绑上去。 那在正式部署之前，你还可以做一件事，就是预览。你可以先预览一下这个测试，看看它底层对应的元数据长什么样子。这样心里有数，知道一旦创建，会往组织里写入哪些东西。 等你确认没问题了，再点击创建。这时候，系统就会正式地更新你的组织，把测试部署进去。同时，它还会自动把这些新增的元数据同步回你的DX项目里，让代码仓库始终跟组织保持一致，这样团队协作就不会乱。 总之一句话：先发布代理，再预览看元数据，最后创建测试，搞定同步。很简单，对吧？

  ▶ 播放视频 查看详情
• 6

  Preview & Create Agent Tests

  第 159 页

  我们来看看这块内容，它讲的是怎么用命令行来创建代理的测试。 你可以把它想象成预览一件衣服——在做最终修改之前，先看看效果。创建测试时，只要在命令里加上 `--preview` 这个标志，系统就会先生成一个预览文件。这个预览文件不会真的改动你的组织，只是让你能先检查一下配置对不对，有没有写错的地方。这一步非常重要，就像考试前先检查一遍答案，避免后面出错。 等你确认预览文件没问题了，就可以把 `--preview` 去掉，重新执行同一个命令。这时候，它会正式帮你做三件事：第一，在本地项目里生成必要的元数据；第二，把这些元数据部署到你的 Salesforce 组织里；第三，再把一种叫 `AiEvaluationDefinition` 的元数据同步回你的本地 DX 项目，让本地项目也保持最新状态。 测试创建好之后，你可能会想看看它长什么样子。很简单，只要打开你的组织，直接导航到“测试中心”首页，就能在界面上看到刚刚部署好的测试了。 最后提醒两个关键点：第一，一定要先发布你的代理，代理没发布是没法创建测试的；第二，你给测试起的 API 名字，在整个组织里必须是独一无二的，不能和别的测试重名。记住了吗？这两个点如果不注意，命令很可能会报错哦。

  ▶ 播放视频 查看详情
• 7

  Run Agent Tests

  第 160 页

  同学们，我们接着来看这一页。当我们已经在开发组织中把代理的测试写好之后，接下来就是要运行这些测试并查看结果了。这里呢，有几种现成的运行方式可以选择。 首先，如果你的环境是无头CI，也就是没有图形界面的持续集成环境，那就可以直接使用CLI命令来跑测试，非常直接，也很容易集成到流水线里。 其次，在平时开发过程中，你可以打开VS Code，里面有专门的一个Test视图，在里边运行测试几乎能立刻看到结果，特别适合边写边测，提高效率。 另外，如果你需要更灵活的程序化控制，还可以使用Testing API，通过代码来触发测试，这样你就可以按照自己的逻辑来处理测试运行和结果。 最后，要是你更喜欢用鼠标点一点解决问题，我们还有一个低代码的测试中心界面，直接通过UI就能执行测试，查看成功与否，对习惯点击操作的用户特别友好。 简单来说，就是用CLI适合自动化流水线，用VS Code适合即时开发，用API适合编程定制，用测试中心UI适合快速点击验证。你可以根据手头的场景，挑选最顺手的方式。

  ▶ 播放视频 查看详情
• 8

  CLI Commands to Run Agent Tests

  第 161 页

  大家好，今天我们来聊聊怎么用代理测试运行，来验证你的Agent功能是否正常。 你可以把它想象成一个小小的自动化考官，帮你快速检查Agent的回答和行为。首先，你需要在命令行里指定测试的API名称来启动一次运行。默认情况下，测试是同步执行的，也就是说，命令会等着测试跑完，然后返回一个作业ID。这个ID你可以记下来，后面如果想复查结果，就用它来取回数据。 不过，如果你想自己控制等待时间呢？很简单，加上一个`--wait`标志，后面跟一个数字，单位是分钟，比如`--wait 5`，命令就会最多等5分钟，超时就不再等了。这样你就不怕测试卡住太久。 测试跑完，结果可以输出成不同格式。你用`--result-form`标志来选择，可以是人类容易读的普通文本，也可以是JSON、RAP或者JUnit格式，方便你集成到别的工具里。比如你想把结果丢到持续集成系统，就可以选JUnit。 那怎么知道有哪些测试可以跑呢？用`agent test list`命令就能列出所有可用的测试，一目了然。想看某个已经跑完的测试结果，用`agent test results`就行。 如果你更喜欢图形界面，不想敲命令行，那用VS Code里的测试面板也很方便。你只要点击左边那个烧杯图标（就是看起来像实验室烧瓶的图标），展开代理测试一栏，就能直接看到所有测试，点击运行按钮，图形化地启动和查看结果，非常直观。 不过要注意，第一次使用VS Code测试面板之前，你需要先把AI评估相关的元数据同步到你的DX项目里。这就像先要把试卷拿到手，才能开始考试一样。 好，今天的代理测试运行就讲到这里，大家可以动手试试看，有任何问题随时问我。

  ▶ 播放视频 查看详情
• 9

  Understanding CLI Agent Test Results

  第 162 页

  好，我们现在来看一下Agentforce里的CLI测试结果是怎么呈现的。 当你运行完一个测试，它会给你一个很清晰的报告，分成四个主要部分，方便你快速定位问题。 第一部分是，总体状态，，它会直接告诉你，这次测试里有多少个通过了，多少个没通过。就像考试的总分，一眼就能看到整体表现。 第二部分是，测试案例的详细信息，，这里把它分解成了三个更小的检查点。 第一个是SubAgent测试，它会检查你的Agent在运行的时候，是不是调用了正确的子Agent。比如你让它去查订单，它就不应该跑去问知识库，这就是正确性的一个验证。 第二个是Action测试，它会确认预期的动作是不是真的被触发了。比如你期望它调用一个“创建工单”的动作，那这里就会验证，它有没有真的去做这件事。 第三个比较特别，叫Outcome测试。它是用自然语言来评估最终回复的。有趣的地方在于，它不要求字字句句都一模一样，而是去抓取回复的“要点”。也就是说，哪怕AI用自己的话重新组织了语言，只要核心意思对了，这个测试就能通过。比如你说“请给我推荐一款适合运动的耳机”，它回复“这款防水防汗的耳机很适合跑步使用”，虽然用词不同，但意思达到了，就算通过。这比精确文本匹配要灵活太多了。 第三部分是，收件箱，，它会给你几个维度的质量评分。 连贯性：看回复是不是前后一致、逻辑通顺。 完整性：看是不是把用户要的信息都给全了，没有遗漏。 简洁性：看回复是不是啰嗦，有没有不必要的废话。 延迟性：看整个响应时间是不是足够快。 这几个分数帮你从体验的角度，判断这个Agent回答得怎么样。 最后是，摘要，，它汇总了整体通过率，还显示整个测试花了多长时间。这样你就能快速评估，这次改动是不是让Agent变得更好了，还是不小心引入了新的问题。 整体上，这个报告能让你非常直观地看到Agent在功能正确性和对话质量上的表现，帮你快速迭代和优化。

  ▶ 播放视频 查看详情