DEX801

课程介绍

同学们，我们来看这一页幻灯片，讲的是如何用编程的方式来定义Agentforce的测试。 你可能之前试过在界面上手工配置测试，但如果要批量创建或者版本管理，我们就需要更程序化的方法。Salesforce提供了一个元数据API类型，叫做AiEvaluationDefinition，用它就可以用代码来结构化地定义一套测试。 这个定义里，每个测试都包含两组东西：一组是输入，一组是期望的输出。 输入这边，很简单，就是你跟代理说的话，也就是“话语”，再加上当时可能用到的上下文变量，还有对话的历史记录。这样就能模拟一个真实用户和代理互动的完整场景。 期望这边呢，就是你要求代理应该怎么做。我们可以定义一些标准化的行为，比如代理应该调用哪个子代理，应该触发哪个动作，或者对它的回复做一个整体的评级。另外还有质量度量的期望，比如回复是不是前后一致、内容完不完整、是不是足够简洁、响应速度延不延迟等等。 这样一来，你就可以把所有这些测试用例写成一个结构化的定义文件，然后用元数据API部署到环境里，实现自动化测试和持续验证。是不是比一个个去点界面方便多了？ 好，这就是这页的重点，大家理解了吗？我们继续下一部分。

课程章节

本课程共有 9 个章节

• 1

  AiEvaluationDefinition: Structure & Inputs

  第 190 页

  同学们，我们来看这一页。这页讲的是Agentforce里一个叫AiEvolationDefinition的元数据类型。名字挺长，你不用纠结它怎么读，先把它理解成一个专门用来定义测试套件的配置文件就可以了。 那什么是测试套件呢？你可以把它想象成一份“考卷”，里面包含了一套用来检验智能代理的题目。这个AiEvolationDefinition就是这份考卷的标准格式。 我们看看它里面都包含什么。每个定义都必须要有一个名字，方便你找得着它。然后得指定一个主题代理，也就是你要测试的那个代理是谁。接下来有一个版本号，用来标记这份定义的版本。最重要的，它包含一个测试用例的数组，这就是一道道具体的测试题了。 每个测试用例的输入部分，有这几个关键点： 第一，主要话语，就是用户对代理说的话，相当于“用户提问”。 第二，可选的上下文变量。咱们用它来模拟生产环境里的各种情况，比如把语言设置成英文还是中文，这些都是通过上下文变量来控制的。这样可以测试代理在不同环境下的表现。 第三，可选的对话历史。这是用来做多轮测试的。比如说，前面已经互相说过几轮话了，然后在这个基础上再发个新消息。这样能让测试更贴近真实对话场景。 说到对话历史，里面的条目结构也得弄清楚。每条记录都要指定角色：到底是用户说的，还是代理说的。还要有消息文本，也就是说了什么内容。另外还有一个索引，用来表示顺序。如果是代理的消息，那还必须额外带一个信息，就是这个回复是由哪个主题子代理生成的。因为在实际的Agentforce里，主代理可能会根据用户意图把工单转给擅长不同话题的子代理，我们在测试时把这个子代理主题标出来，就能校验路由是不是正确了。 最后还有一条很重要的规则：在测试会话开始之后，大部分上下文变量就会变成只读的，不允许再改了。不过有一个例外，就是EnduserLanguage——终端用户语言。也就是说，如果你在对话中途想切换测试语言，这是可以的。比如一开始用英文，中间改成中文，以此来验证代理的语言适应能力。其他变量就没法中途修改了。 所以整体上，AiEvolationDefinition

  ▶ 播放视频 查看详情
• 2

  Standard Expectations & Quality Metrics

  第 191 页

  好，同学们，咱们现在来看这一页内容，讲的是怎么去验证我们Agent的行为是否符合预期。听起来有点抽象？没关系，我一步步拆开说，你会觉得很简单。 我们有一个工具，叫“标准期望”，它是用来测Agent的特定行为的。比如你设计了Agent回答用户问题，但你怎么知道它按你想的做了？就得靠这些检查。 第一种检查叫 ，topic_order_match，，它查的是Agent有没有调用正确的子代理。如果你期望它某一步该用“客服子代理”，结果它跑去用“销售子代理”了，这个检查就会失败。 第二种 ，action_order_match，，是验证Agent调用了哪些具体操作。你想测它不应做任何操作时，就在这个检查里用 `[]` 空数组，代表“我预期没有任何操作”。如果它居然调了某个接口，就算失败。 第三种 ，bot_respect_rating，，是做语义比较的，不是死板比对文字，而是看回答的核心含义对不对。比如你问“怎么退货”，它回答“您需要先申请退货授权码”，只要意思到位，哪怕措辞不一样，这个检查也会通过。它不要求一字不差。 另外还有一些，质量指标，，它们不需要像前面那样填 `expectedValue` 字段。这些是什么呢？ - ，连贯性，（coherence）：看回答读起来顺不顺，有没有逻辑混乱。 - ，完整性，（completeness）：信息覆盖全不全，别漏了用户需要的关键点。 - ，简洁性，（conciseness）：越精简越好，不啰嗦。 - ，响应时间，（put_latency_mills）：纯粹测快慢，单位是毫秒。 - ，启动可及性，（initiation_accessibility）：评估Agent是不是严格按照子代理给的指令去回应，并且会给出高、低或不确定这样的评分。 所以你看到，我们既能测行为步骤对不对，也能测回答的质量好不好。把这些组合起来，就能很稳地保证Agent的表现。这块理解了吗？没问题的话我们接着往下走。

  ▶ 播放视频 查看详情
• 3

  Custom Evaluation Criteria

  第 192 页

  同学们，我们来看一下这一页，讲的是一个很有意思的功能：定制评估。定制评估它是什么呢？简单说，它就是把咱们的测试能力，从简单的“整个响应对不对”，给你扩展到了更深、更细的层面。你可以用它去专门验证代理返回的响应里头，某一个具体的字符串，或者某一个具体的数字，到底符不符合你的期望。 那它是怎么做到的呢？核心就是通过 JSONPath 表达式。你可能知道，代理返回的数据往往是 JSON 格式的，像个嵌套的盒子。你用 JSONPath 就能写一条路径，动态地从生成的响应里，精准地把那个你要检查的值给揪出来。比如说 $.response.order.amount ，就可以拿到订单金额。 我们支持两种测试类型：一种是针对文本值的，叫字符串_comparation，也就是字符串比较；另一种是针对数字值的，叫 numeric_comparation，数字比较。名字你可能会看到这种写法，明白它意思就行。 无论是哪种，每一个定制评估都定义了三样东西：第一个是“实际值”，就是用 JSONPath 指定你要取的那个动态数据的引用；第二个是“期望值”，就是你认为正确的结果，可以是一个数字，也可以是一段文字；第三个是“比较运算符”，比如等于、不等于、大于、小于，甚至包含等等。 这样组合起来就非常灵活。比如你有一个客服代理，它返回的回答里面有个状态码，你想确保每次都等于“success”，那就可以设一个字符串_comparation，实际值用 JSONPath 指向状态字段，期望值填“success”，运算符选等于。或者你要测试一笔金额是不是大于 100，那就用数字比较，简单明了。 所以说，定制评估让我们不再只是看整体输出像不像，而是可以深入到数据结构内部，去动态地、有逻辑地验证关键字段。这在做自动化的质量保障时，特别有用。好了，这一页的概念就先讲到这儿。

  ▶ 播放视频 查看详情
• 4

  Custom Evaluations: Types & JSONPath

  第 193 页

  咱们现在看点比较实用的内容——自定义评估。这其实就是让Agentforce能够根据你设定的规则来判断“到底算不算通过了”。 你只要记好它有三个参数就行，非常清晰。 第一个，运算符，也就是你想怎么比。如果比的是字符串，常用的有equals（等于）、contains（包含）、startswith（开头是）、endswith（结尾是）。注意，这些都是区分大小写的。那如果是数字呢，就用等于，或者各种大于、小于的标准变体。 第二个，实际值。这个参数是用来指向运行时产生的真实数据。写法上它用JSONPath，并且要把isReference设成true。你回想一下，咱们之前说过数据都放在generatedData对象里，JSONPath就是顺着这个结构去精确定位你需要的那个字段。 第三个，预期值。这个就是你自己定好的目标值，用来跟实际值做比较。 怎么检验它到底拿了什么数据来评估呢？你可以跑代理测试的时候加个--verbose标志，这样就能在输出里看到生成的完整JSON结构，定位起来就方便多了。 最后提一下，每个参数不能太长，最多100个字符。 就是这么一个简单的三段式结构：怎么比、跟谁的实际数据比、目标是什么。有了它，你就能让代理自己去做细粒度的质量检验了。

  ▶ 播放视频 查看详情
• 5

  Create Custom Scorers

  第 194 页

  我们来聊聊自定义评分器。你可以把它想象成给代理行为打分的“阅卷老师”。 这个老师很特别，因为它能完全根据你公司的业务要求，来定义评分规则。它可以在不同层面上检查代理表现，比如整个对话结束后的整体评分，也可以看某一次具体的互动，甚至能细到对话中的某个关键时刻。 那么它具体是怎么工作的呢？它靠的就是一个提示模板引擎。简单说，就是它会自动把代理的行为喂给一个大语言模型，让模型按照你设定好的标准去评估，然后输出结果。最后，评分器会把模型的判断映射成三种明确的结果：通过、失败，或者不适用。 这样一来，你就能很灵活地知道代理哪里做得好，哪里还需要改进，完全贴合你自己的业务场景。

  ▶ 播放视频 查看详情
• 6

  Custom Scorer Definition & Deployment

  第 195 页

  同学们，接下来我们来看一下自定义评分器这个知识点。这部分可能听起来有点技术性，但别担心，我会用最简单的方式帮你们理清思路。 想象一下，你做了一个Agent，你想测试它表现得好不好，这时候就需要一个“评分器”来打分。在Agentforce里，我们可以用自定义评分器来实现。这个评分器的元数据类型叫做 ，AiAgentScorerDefinition，，这就是定义它的那个官方名字。 那么，这个评分器长什么样呢？它有几个关键的概念。 首先，每个评分器都有一个，输入范围，，就是它要评“什么尺度”的表现。比如，你可以让它看完一整个会话后给出一个总体评价，这叫“完整评估的会话”；也可以让它看每一轮用户和Agent的对话来打分，也就是“每回合的交互”；甚至还可以细到看Agent每一个具体的动作，这叫“每动作的时刻”。所以，粒度是可以选的。 接下来，评分器还需要指定，数据类型，和，版本化的配置，。版本化配置的意思是，你可以不断优化你的评分规则，但旧版本会被保留，这样我们能回溯和改进，但不能删除版本，这点要注意。 然后，评分器内部有个“引擎”，目前这个引擎被限定为 ，Inbox 模板类型，。简单说，就是评分器要使用一个预定义的提示模板，这个模板通过它的API名称来引用。也就是说，你要先有一个写好的提示模板，评分器才知道按什么标准去评。 评分的结果是怎么呈现的呢？这里有，输出映射，，它会把引擎打出的原始分数，转换成我们容易看懂的结果，比如：，通过、失败、不适用，。这样就很清晰了。 另外，评分规范里面还可以定义一些数字限制，比如，最小值、最大值、步长限制，，还能设置一个可选的，阈值，。举个例子，你设定满分10分，6分以上算通过，那阈值就是6。 最后，部署这样一个自定义评分器，项目结构是有要求的。因为元数据API是，按顺序部署，的，所以你的`package.xml`文件里，必须把GenAi模板列在AiAgentScorerDefinition，之前，。顺序错了可就部署不上去，到时候记得检查一下。 好了，关于自定义评分器的核心点我们就讲完了。简单总结就是：用AiAgentScorerDefinition定义一个评分器，选好评分的粒度，绑定一个提示模板，输出成通过或失败，部署时注意顺序。大家先理解到这个程度就足够了。

  ▶ 播放视频 查看详情
• 7

  Run Tests in Connect API

  第 196 页

  同学们，咱们今天来看看Agentforce里Connect API提供的一个很实用的功能——用REST端点来跑测试。你可以把它想象成一套自动化测试工具，通过几个简单的网址就能控制和查看测试过程。 它给了我们三个端点，分工特别明确： 第一个是“开始测试”，调用它就能立刻启动一个同步执行的测试。什么叫同步呢？就是你一发出请求，测试就当场跑起来，不用等。 第二个是“获取测试状态”，这个相当于一个进度查询。测试可能比较耗时，你可以随时用这个端点去“投票”看看现在跑到哪儿了，是还在跑，还是已经完成了。 第三个是“获取测试结果”，等测试跑完了，通过它能拿到一份详细的报告，告诉你哪些用例过了，哪些失败了。 不过要使用这些端点，有个前提：你需要一个外部的客户端应用，并且这个应用必须启用了OAuth JWT这种认证方式，同时还要带上对应的权限范围，也就是scope，才能顺利访问Connect API。 简单说，就像是你要进一个高级实验室，得有特定的门禁卡（OAuth JWT+scope），进去之后，有三个操作台：一个启动实验，一个查进度，一个拿最终报告。这样讲，是不是清楚多啦？

  ▶ 播放视频 查看详情
• 8

  Connect API Setup & Endpoints

  第 197 页

  同学，我们来看一下这一页讲的是什么。它其实在说，如果你想通过程序来调用Agentforce的测试服务，你需要先配置一个外部的客户端应用，让它能安全地连接到Salesforce。 首先，这个客户端应用必须具备特定的OAuth权限范围，特别是`chatter_api`这个范围。因为Agentforce的Connect REST API就是依托在Chatter API上的，有了这个权限，你的程序才能调用那些测试端点。 接下来，你要启用两种身份验证方式：一个是客户端凭据流，另一个是JWT令牌流。这两种方式都能让你的后端服务无需用户交互就能获取访问令牌。你拿到客户端密钥和消费者密钥之后，就可以用它们去换取一个有效的令牌了。 有了令牌之后，你就能访问三个主要的接口端点。想想看，第一个是开始测试，你发起一个请求后，它会立即返回一个`runId`，这就像是测试运行的编号，后面全靠它来跟踪。第二个是获取测试状态，你可以拿着这个`runId`不断轮询，看测试跑完了没有。第三个是获取测试结果，当测试完成后，访问这个端点就能拿到一份详细的报告。 这份报告里内容很丰富，包含一个`generatedData`部分，里面记录了这次测试执行的操作序列、每一步的结果，还有用了哪些子代理。另外还有一个`testResults`数组，每个测试用例都会有一个结果，并且会给出预期的指标分数，简单来说就是“通过”还是会出现一些常见问题，它会标出来。 最后，如果你觉得通过代码去处理这些OAuth和API调用有点麻烦，也可以用Agentforce DX命令行工具，它把这些操作都封装好了，敲几行命令就能完成同样的工作，对刚入门的同学来说会更友好。 这样看起来，整个过程是不是就清晰多了？我们一步一步来，后面还会有更多实践。

  ▶ 播放视频 查看详情
• 9

  Understanding Test Results

  第 198 页

  好，同学，咱们现在打开这个测试结果的页面，我带你看看每个部分到底在说什么，这样你以后自己跑测试的时候，一眼就能看得懂。 首先，你跑完一轮测试用例，系统会给你返回很详细的信息，不会只告诉你“通过”或“失败”就完事了。这里有一个叫 `generatedData` 的区域，它就像一份“代理的行动记录”，它记录了代理在测试过程中，实际做了什么，。比如，它调用了哪些动作，给了用户什么样的回复文本，甚至它内部调用了哪个子代理来处理任务，都一目了然。你就可以像看回放一样，知道代理是怎么一步步完成那个测试请求的。 接着，我们再往下看，每个 `testReport` 条目对应一个你设计的测试用例。它里面会明确写出测试的名称，还有你预设的“预期值”和代理跑出来的“实际值”，最后给你算出一个 `metricScore` 分数，告诉你这个用例通过得怎么样。 这里有个特别值得注意的测试类型，叫做 `bot_respect_rating`，它是用来验证代理有没有保持礼貌和尊重的。这个测试很聪明，它做的不是死板的字符串比对，而是，语义比较，。也就是说，即使代理回复的措辞和你预期的完全不一样，但只要核心意思符合“尊重客户”这个含义，它依然能给你通过。你不用担心要写到一字不差，这给了测试很大的灵活性。 另外，你还会看到一些质量指标类的测试，比如检查回复的“一致性”或者“完整性”。这类测试不需要你填写 `expectedValue`，因为系统自己有一套标准去判断：结构是否完整、上下文是否连贯，它会直接给你打分。 当然，如果看到测试结果是红色的失败，也别慌。这时候你就打开代理生成器的预览面板，它是一种对话式的调试工具。你可以在这里一条条查看失败用例的错误消息，去看看代理当时的思考过程，检查一下是不是你给代理的指令描述得不够清晰，或者操作定义有问题，甚至是子代理的逻辑出了岔子。先定位问题，再回头调整，很快就能把测试修绿了。 这样一讲，你对测试结果的理解是不是就清晰多了？后面你就可以自己动手试试，有问题我们随时讨论。

  ▶ 播放视频 查看详情