DEX801

课程介绍

同学们好呀，这节课咱们不钻细节，先拉开距离，看看 Agentforce 整个 API 和 SDK 地图长什么样。你只要记住，所有工具都围着三件事转：构建代理、测试代理，还有跟代理聊天、使用代理。 咱们先说，构建代理，。如果你更习惯用低代码或者简单脚本，那 Agent Script 就是给你准备的，它能让你轻松定义代理该说什么、怎么回应。那专业开发者呢，就去看 Agentforce DX，一套命令行工具，方便你 debug、打包、协作。还有 Python 开发者，可以直接用 Python SDK，在 Python 环境里把代理的能力调用起来，很趁手。每一种工具都面向不同的角色。 接下来是，测试代理，。代理建好了，可不能直接放出去乱说话。咱们有测试 API，可以写代码自动跑回归测试；Agentforce DX 里也内置了测试功能，开发的时候随手就能验；另外还有个测试中心，界面友好，让不太写代码的业务同学也能看懂代理表现好不好。这样开发、测试、业务三方都能安心。 最后一块是，聊天使用代理，。要让代理真正工作，就要用 Agent API，你的应用能直接和代理对话。如果想深度嵌到自己公司的微信、App 或者网页里，就得靠自定义连接。移动端的同学，我们有专门的移动 SDK，在 iOS 和安卓上都能丝滑集成。还想让对话更炫一点儿，加点卡片、按钮什么的，增强聊天的能力也都在里面。 所以你看，整个生态不管你是管理员、Python 开发者、测试工程师，还是移动端开发，每个人都能找到自己趁手的家伙。这一页就想让你心里有个谱：哪个阶段该用哪个工具，它大概为谁设计的。有了这张全景图，后面咱们拆开讲每个工具的时候，你就不容易迷路了。好，我们先对这三大块儿有个印象，休息一下，接下来再一个个细聊。

课程章节

本课程共有 14 个章节

• 1

  Feature & API Overview

  第 175 页

  同学们，今天我们来看看Agentforce的API生态系统，这就像一整套工具包，让你既能打造智能代理，又能测试它，还能跟它对话。 首先，，构建代理，这一块，我们有三种方式。 如果你喜欢用自然语言直接编写逻辑，可以用，Agent Script，，它就像给代理写剧本。 如果你是开发者，习惯命令行或者VS Code，那就用，Agentforce DX，，它在代码环境下帮你快速搭建。 还有，Python SDK，，适合用程序化方式去管理和控制代理，灵活度很高。 接下来是，测试环节，，我们得确保代理靠谱。 你可以用，测试API，，很适合做编程化测试，甚至写自定义评估脚本。 也可以用，Agentforce DX，，在命令行里用YML配置测试，同样能加自定义评估。 如果不想写代码，直接用，测试中心，的界面操作，上传CSV文件就能测，不过这种简单方式不支持自定义评估。 最后是，和代理聊天，。 核心是，Agent API，，一个标准的REST接口，支持同步和流式两种模式，就像打电话和实时对讲。 如果你想做手机App，用，Mobile SDK，；做网页聊天，用，Enhanced Chat，。 还有一些辅助工具，比如，ADL API，用来操控代理逻辑，，会话跟踪输出，帮你把所有对话记录下来。 简单总结：构建、测试、聊天，三环相扣，工具各司其职，让你能快速把智能代理从想法变成现实。

  ▶ 播放视频 查看详情
• 2

  Build, Test, Chat & Mobile Integration

  第 176 页

  好，我们来看这一页，它把 Agentforce 开发中要用到的构建、测试、API 和移动端能力都串起来了，非常清晰。 咱们先从左边的“构建”说起。如果你想定义代理的行为逻辑，最基础的就是 Agent Script，它相当于一门专门给代理用的语言，简单直观。开发环境这边，Salesforce 提供了 DX 工具链，帮我们管理源码、打包部署，就像平常做 Salesforce 开发一样。如果你习惯用代码做更灵活的自动化，那 Python SDK 就能派上用场了，直接用 Python 脚本操控代理的配置和流程。 接着是“测试”。构建好代理之后，我们当然要保证它靠谱。这里你可以自动生成测试规范，再根据业务需要，用上下文变量和指标来定制这些测试，比如模拟不同用户信息、检查回答质量。所有测试都可以通过命令行来运行，输出格式也多种多样，比如 JUnit 报表，非常方便接入你的 CI/CD 流水线，每次部署前自动跑一遍，心里更有底。 再来看中间这块，代理 API，它提供了一套完整的 REST 接口。你可以用它启动一个会话，然后以同步方式发送消息，或者通过 SSE 流式地接收响应。流式传输里会有一系列实时事件，比如 ProgressIndicator 表示正在处理中，TextChunk 是逐块返回的文本，Inform 用来传递一些提示信息，EndOfTurn 则告诉你代理说完了一轮话。这个 API 还很聪明，支持内联元数据处理引用，也就是说回复里可以带上来源出处，还能传递变量、主动结束会话，甚至提交用户反馈，用来持续优化代理。 最后是移动 SDK，它让 iOS 和 Android App 可以直接集成代理能力，把智能对话无缝带到手机里，用户体验也更原生。 总的来说，这一页就是把构建、测试、API 和移动端的整个工具体系都点到了，无论你是用脚本、用代码，还是在手机 App 里调用，都有对应的支撑，这也是 Agentforce 开发上手快、扩展性强的重要原因。

  ▶ 播放视频 查看详情
• 3

  Get Started with the Agent API

  第 177 页

  同学们，我们这一页PPT讲的是怎么用代理API，也就是Agentforce提供的REST接口，直接和AI代理对话。 简单来说，你可以把这个API想象成一条电话专线，让你的外部程序能够拨通我们的AI代理。通过这条专线，你想什么时候开始聊天就什么时候开始，发一句消息，代理立刻给你回复，聊完了再礼貌地挂断。整个过程就是：启动会话、发送消息、接收响应、最后结束会话。 那怎么才能让自己程序具备这个能力呢？这就需要一个安全的身份验证，也就是咱们这页提到的“客户端凭据流”。意思是你的程序要先亮出合法的“身份证”，才能跟代理沟通。所以这里的设置步骤非常关键。 这一章的内容，我们会手把手地带你完成整个搭建。首先，你要在Salesforce里创建一个专属的应用程序，拿到专属的凭据；然后，用这些凭据去换取一个令牌，就像领一张临时通行证；最后，你就可以用这个令牌，对API发出第一次调用，亲手让自己的程序跟AI代理说上话。 整个过程听起来有点技术，但其实跟着步骤走，你会发现它非常有条理。接下来我们就会逐个环节，把每一个配置都拆开，确保大家都能看懂、做通。好，这一页的概述我们先到这儿，下一步咱们就实际动手建应用。

  ▶ 播放视频 查看详情
• 4

  Setup: Create App, Get Credentials, Token

  第 178 页

  同学们，我们接着来看怎么设置代理API。这一步其实就是在Salesforce里建一个专用的“钥匙”，让咱们的代理程序能安全地跟Salesforce对话。 首先，你需要创建一个“外部客户端应用程序”。别被名字吓到，它只是个配置项，告诉Salesforce“我这个程序要来访问API了”。创建的时候，要勾选一组合适的OAuth范围，至少要包括这四个：api、refresh_token、chatbot_api、sfap_api。api是基本的API访问能力，refresh_token能让令牌自动续期，后面两个是Agentforce专门要用的。勾上这些，咱们的代理才能正常工作。 接下来，要在这个应用程序里启用两种认证方式：客户端凭据流和基于JWT的访问令牌。客户端凭据流简单说就是，程序自己拿凭证去换令牌，不需要用户交互，特别适合后台自动运行的代理。而JWT令牌呢，就是用它来签发更安全的访问凭证。 还有一点，一定要指定一个“运行方式用户”。这个用户只用来跑后台任务，权限最小化就行，所以给他一个“仅API访问”的权限就够了。这样就算凭证泄露，别人也干不了太多坏事。 创建完后，你就会拿到两个重要的字符串：消费者密钥和消费者机密。把它们复制下来保存好，相当于这个应用程序的账号密码。 那怎么拿到第一个访问令牌呢？用一条curl命令，往Salesforce的OAuth令牌端点发个请求。端点地址要写成“我的域名”那种格式，比如 `https://你的域名.my.salesforce.com/services/oauth2/token`。注意，千万别把浏览器地址栏里那个 `lightning.force.com` 的URL直接拿来用，那个是用户界面的地址，API认证要走“我的域名”这个专用入口。 curl命令发出去后，返回的响应里会有一个叫 `access_token` 的字段，这就是基于JWT的访问令牌。之后所有代理API的调用，都要在请求头里带上这个token，Salesforce才认你是一个合法的代理程序。 简单总结一下：创建应用→选对范围→启用正确的认证方式→配好最小权限用户→记下密钥→用我的域名去换token。这样代理API的身份基础就搭好了。大家跟着操作一遍，就不会觉得复杂了。

  ▶ 播放视频 查看详情
• 5

  Call the API: Start a Session

  第 179 页

  我们今天来看看怎么开启一个和Agentforce代理的对话会话。这就像你给代理打个电话，建立连接，后面才能聊天。 首先，你需要准备几个东西：第一个是，代理ID，，就是你要对话的那个代理的身份标识；第二个是，访问令牌，，相当于你的身份认证；然后还需要一个，随机的UID，，用来唯一标记这次会话，方便跟踪；最后就是你的，“我的域”URL，，比如像 mydomain.my.salesforce.com 这种格式。 这里有个小技巧，把 ，bypassUser 设置为 true，，这样在客户端凭据流里，代理会用分配给它的那个用户来执行操作，不用再额外指定。 当你发起请求后，系统会返回一个 ，sessionId，，这个很重要，你之后每一条发给代理的消息，都要带着它，就像握着一把通话的钥匙。同时，你还会收到代理的一句，初始欢迎消息，，感觉就像它跟你打了个招呼。 另外要特别注意，如果你是政府云的用户，接口地址要用 ，api.gov.salesforce.com，，而不是普通的 api.salesforce.com。还有，不管哪种情况，始终用你自己的“我的域”URL，千万别用 lightning.force.com 那种旧的地址。 这样，一个会话就平稳建立好了，接下来就可以愉快地跟代理对话了。

  ▶ 播放视频 查看详情
• 6

  Get the Agent ID

  第 180 页

  好，我们来看一下这个知识点——怎么找到你的代理ID。这个看似简单，但实际上呢，取决于你是用哪一种构建器来创建和管理代理的，因为两种构建器的入口和查看方式不一样。 先说说传统的构建器，也就是我们常说的“Legacy Builder”。在这种方式下，获取代理ID非常简单。你只要进入到“代理概述”页面，直接把目光移到浏览器的地址栏，那个URL里面就会直接显示代理ID。一般是一串字母数字的组合，就在URL的末尾部分，一眼就能看到，直接复制出来用就行。 另一种是新的构建器，也就是“New Builder”。这个构建器是通过Agentforce Studio来访问的，界面更现代，有画布视图和脚本视图等等。在新构建器里，代理ID并不直接显示在界面上，你必须通过SOQL查询才能拿到。具体做法是，使用代理的开发人员名称——也就是API名称——去查询一个标准对象，这个对象叫Botify。查询的时候，找到这条记录的Id字段，那个就是你的代理ID了。所以，新构建器需要你写一点点SOQL，比如`SELECT Id FROM Botify WHERE DeveloperName = '你的代理API名称'`，这样就能取到。 那为什么会存在这两个不同的构建器呢？简单区分一下：传统的Legacy Builder，它是通过“设置”（Setup）菜单进入的，里面提供了一个可视化的子代理编辑器，整个配置体验比较接近于以往的Salesforce配置方式。而新的构建器，是完全在Agentforce Studio里操作，它提供了更强大的画布拖拽和脚本编辑能力，设计理念更灵活、更适合复杂场景。 总结一下，如果你是用Legacy Builder，直接看浏览器地址栏就能得到代理ID；如果你是用New Builder，那就得用SOQL查一下Botify对象。这个小小的差异，在实际开发和管理中经常会遇到，所以记下来对你会很有帮助。

  ▶ 播放视频 查看详情
• 7

  Agent API Session Lifecycle

  第 181 页

  同学们，咱们今天来聊聊Agent API里一个很基础但特别重要的东西——会话的生命周期。 你可以把一次会话想象成你跟客服聊天，从你打开聊天窗口那一刻，到最后你说完“谢谢，再见”关掉窗口，这整个过程就是一次会话。 在Agent API里，会话的生命周期非常简单，总共就三步： ，第一步，创建会话。， 就像你点开聊天窗口开始了一次新对话，系统会给你一个会话ID，后面所有消息都关联这个ID。 ，第二步，发送消息。， 你会把想问的问题发给代理，代理接收后给出回答。这里可以实时交互多轮，就像正常聊天一样。 ，第三步，结束会话。， 当任务完成，你就可以告诉系统“会话结束”，代理就不会再保留这个会话的上下文了。 在整个过程中，代理会自动帮你跟踪上下文。也就是说，你上一句问“深圳天气怎么样”，下一句说“那上海呢”，代理就知道你还在问天气，因为它是连着上下文理解的，不会把你当新问题处理。 消息的发送方式有两种，这个根据你的需求来选。 - ，同步发送：， 就像发完一条信息，等着对方完整回复完毕，一次性给你整个响应。适合简单、快速问答。 - ，流式传输：， 用的是SSE协议，响应会一块一块地实时推送过来，像我们现在看到ChatGPT一个字一个字跳出来那样。这样用户能马上看到反馈，体验更自然。 另外，这个API还有一些很实用的扩展功能： 你可以，提交反馈，，比如告诉代理它的回答有没有用，这能帮助优化未来的回复。 你还可以，传递代理变量，，比如用户的身份、偏好设置等，让代理的回复更个性化，就好像它认识你一样。 总之，会话生命周期的核心就是：建会话、聊消息、结束，过程中由代理维持上下文；选择同步或流式来满足不同的交互体验；必要时加上反馈和变量，让整个对话更智能。 好了，这一块就是这样，很简单对吧？大家有什么问题，我们后面可以展开聊。

  ▶ 播放视频 查看详情
• 8

  Session Lifecycle & Message Types

  第 182 页

  同学们，咱们来看看 Agentforce 的会话生命周期，它其实就像一段完整的对话流程，分成四个阶段，我们一步步来理解。 首先，一个会话从哪里开始呢？当然是从“创建会话”开始。就像你拨通客服电话，系统会给你分配一个通话编号，这里我们也会拿到一个唯一的，会话ID，，后面的所有交互都得靠它来标记。 接下来就是第二阶段——，发送消息，。这里有两条路可以走，根据场景选。一种叫，同步发送，，你发一句，系统在一个 JSON 包里把完整答案一口气给你。这就像写信，一次性读完，简单高效，适合不着急、信息量不大的情况。另一种更酷，是，通过流来传输，，用的是 SSE 协议。这就好比即时聊天，消息是一点点推到你面前的，特别适合实时对话。 如果选了流式传输，那第三阶段系统会按顺序给你发送一串事件，每个事件都有不同的作用： - 先来一个 ，ProgressIndicator，，它就像进度环，告诉你“代理正在工作，别急”。 - 接着 ，TextChunk， 事件一个个过来，每一块都带着增量的文本，文字就噼里啪啦往外蹦，跟你聊天一样实时显示。 - 等文字部分差不多了，会收到 ，Inform， 事件，它给你一份完整的消息，还附带上引用来源和反馈 ID，方便你回头确认或评价。 - 最后，当这一轮该说的都说完了，会有一个 ，EndOfTurn， 事件，表示“好了，我说完了，轮到你了”。 这里还有个特别要注意的情况：如果流里突然插进来一个 ，GuardationUtilureChunk， 事件，你得立刻丢弃之前已经渲染的所有文本块，只展示这个事件之后新推送的流内容。你可以把这理解成：系统发现自己之前说的可能触发了某种安全护栏，需要马上替换掉，你就得毫无保留地刷新成新的回复。 第四阶段就是，结束会话，。当你和代理聊完了，可以通过收件箱请求结束整个会话，完事儿还可以选择提交反馈，帮系统做得更好。 记住这四步：，创建会话拿 ID → 选择同步还是流发送消息 → 流式接收各个事件并处理特殊情况 → 结束会话提交反馈，。这样，你就掌握了 Agentforce 对话的整个脉搏了。

  ▶ 播放视频 查看详情
• 9

  Send Messages, End Session & Feedback

  第 183 页

  我们来看这一页幻灯片，内容是关于在使用Agentforce消息API时，如何处理消息发送、流式响应、会话结束和反馈。我会用最口语化的方式，像上课一样给你讲明白。 首先想象一下，你现在是在跟Agentforce做一个对话，就像聊天一样。作为开发者，我们需要通过API来发送消息、接收回复，还要管理这个对话的生命周期。这里有几个关键点，我会一个一个说。 第一个，如果你想发一条消息，并且是同步地等回复，也就是发完就等对方立刻回一句，那你要用这个端点：`/messages`。注意是复数 messages。发的时候，你要在请求里带一个叫“序列ID”的东西，比如第一条消息序列ID是1，第二条是2，第三条是3，这样递增。为什么需要这个？因为万一网络抖了一下，消息重复发了，Agentforce 靠这个递增的序列号就能知道哪条是新的，不会搞乱顺序，也不会重复处理。所以，记住，每次发消息都要带上一个比上一条大的序列ID。 第二个，如果你不想同步等，而是想要实时的、一个字一个字往外蹦的流式响应，那就要换一种方式。你要发请求到 `/message/stream`，并且在请求头里写上 `Accept: text/event-stream`。这样Agentforce就会以流的形式把结果推给你，用户就能看到打字机的效果，体验会好很多。 第三个，关于怎么结束一个会话。在Agentforce的世界里，会话是放在一个叫“收件箱”的概念里的。要正常结束一个会话，你需要发送一个特殊的请求，在响应头里用上 `x-section-end-reason`，这个头就是告诉系统结束会话的原因，比如是用户主动结束，还是超时之类。加上这个头，系统就知道会话完结了，该把对话归档到收件箱里了。 第四个，反馈功能。用户有时候会评价回复好不好，比如点个赞或者点个踩。Agentforce 的消息体里有一个叫 `Inform` 的消息类型，这种消息里会带一个 `feedbackId`，这个就是用来提交反馈的标识。你拿到这个 `feedbackId` 之后，再发一个请求，带上评分，比如“好”或者“坏”。如果提交成功，服务器会返回 HTTP 201，意思是已创建，反馈就记录下来了。 最后说一下引文。有时候Agentforce给出的回复是基于某些知识库文章的，它会在 `Inform` 消息里带一个 `citedReferences` 数组，里面就是引用的来源。而且里面还可以有一个 `inlineMeta` 字段，这个字段包含了声明文本和字符位置的偏移量。这些偏移量是干什么用的？就是告诉你，回复的那句话里，从第几个字到第几个字是依据这个来源的，你可以在UI上把那段文字变成可点击的链接，或者加个小数字角标，这就实现了内联的来源展示，看起来非常专业。 总结一下，这页内容就是教你：用 `/messages` 发同步消息要递增序列ID；想要流式就用 `/message/stream` 加 `Accept: text/event-stream`；结束会话设一个 `x-section-end-reason` 头；用 `Inform` 里的 `feedbackId` 提交评价，成功就是201；引文数据在 `citedReferences`，配合 `inlineMeta` 的偏移量可以在界面上直接标出来源。 这样讲是不是就清晰多了？记住这些，你在调用API的时候就知道每一步该做什么了。我们下页继续。

  ▶ 播放视频 查看详情
• 10

  Send Agent Variables

  第 184 页

  同学们，我们来看这一页内容，讲的是 Agentforce 里怎么在发起对话或者发送消息的时候，顺带把一些信息带进去——也就是“变量”。这个特性非常实用，因为它可以让你的机器人一开始就知道用户是谁、想用什么语言、之前聊过什么，就像你拿起电话，对方上来就亲切地喊出你的名字一样。 我先帮大家把概念理一理。变量总的分两类。第一类是，上下文变量，，它的特点就是名字前面有个固定的 ，`$Context`， 前缀。这类变量，绝大多数在会话开始之后就“锁死”了，变成只读的，不能随便改动。不过有一个例外，就是 ，EndUserLanguage，，它可以动态变化，用来实时调整给用户看的语言，比如用户中途切换语言，机器人马上就能跟着改。 第二类是，自定义变量，，你可以根据自己的业务需要来创建，而且为了简化，Salesforce 在 Agentforce 里去掉了我们平时在字段上常看到的 `__c` 后缀，看起来更清爽。 接下来，如果你希望外面其他系统能通过 API 来往里塞值，或者读出值，那就需要把这个变量“开放”出去。怎么开放呢？有两种方法。第一种，直接在 Agentforce 的 Builder 界面里，找到那个变量，勾上“，允许 API 设置值，”的选项。第二种，用元数据 API，把对应变量（就是那个 ConversationVariable 的记录）里的“，可见性，”字段设置成“，外部，”。这两种方式效果是一样的，都是告诉系统：这个变量不只自己在内部用，允许外部来访问。 说到元数据，设计一个变量的时候，有几个关键的属性一定得弄清楚。我挑重要的跟你说： - ，dataType，：数据类型，这个好理解，是文本、数字还是布尔值，决定了变量能存什么。 - ，描述，：就是对这个变量写一段注释，方便你自己和同事以后知道它干嘛用的。 - ，developerName，：开发名称，是系统里的唯一标识，一旦创建就不要随便改它。 - ，includeInPrompt，：这个特别重要。它是用来控制这个变量的值要不要放进大语言模型的提示词里。如果勾上了，模型就能“看到”这个变量的内容，并据此调整它的回答；如果不勾，那这个变量就只在流程中流转，模型是不知道的。比如，你可以把用户的会员等级放进变量，勾上这个，机器人就会自动用更尊贵的语气说话。 - ，可见性，：我们刚提过，选“内部”呢，就只在你自己的对话操作里用；选“外部”，就代表允许 API 来进行读写。 所以简单总结一下，你要在对话启动的时候把信息塞进来，就用上下文变量或者自定义变量；要能通过 API 调，就记得把可见性打开或勾选允许设置值；而 includeInPrompt 的开关，则决定了你的机器人是不是能“感知”到这条信息。把这些点掌握了，你就可以让 Agent 的对话变得非常灵活、智能。 你先把这几个点消化一下，下一个小节我们会实际操作演示一遍，看看在 Builder 里怎么配置这些变量。有任何不清楚的，随时打断我。

  ▶ 播放视频 查看详情
• 11

  API Considerations

  第 185 页

  好，现在我们来看最后一章，这一章会重点讲Agentforce API的一些关键注意事项。这些内容在实际开发中非常重要，能帮你避开很多坑。 首先，我们要弄清楚支持的代理类型。不是所有代理都能通过API调用的，你得确认你用的是哪种，比如服务代理、销售代理，它们的功能和限制可能不一样。所以开发前一定要核对文档，选对代理类型。 接下来是使用计费，这个很容易被忽略。每次调用Agent API，都可能影响你的用量配额或者产生费用。比如，有些调用按会话计费，有些按请求次数算。所以你得了解清楚计费模型，做好规划，避免账单超预期。 还有超时设置。API调用不是无限等待的，会有超时限制。如果你处理复杂任务，响应时间比较长，就要考虑设置合理的超时时间，或者在代码里做好重试和异常处理。否则，请求可能被中断，影响用户体验。 再说政府云端点。如果你的组织部署在政府云环境，比如FedRAMP合规的实例，那API端点地址和普通商业版是不一样的。一定要使用正确的政府云专用端点，不然连接会失败。检查一下你的My Domain设置和端点URL，确保匹配。 最后，这一章还准备了一个全面的故障排除参考，就是常见的HTTP错误代码。你可能遇到过400、401、403、429、500这些错误。这里会解释每个错误的含义和解决办法。比如，429是请求过多被限流了，你需要实现退避重试机制；401是认证失败，得检查token或权限。把这些错误弄明白，能大大提升你的调试效率。 总之，这一章就是为了让你在集成Agent API的时候，少走弯路，从容应对各种情况。把这些注意事项掌握好，你的开发工作会更顺畅。

  ▶ 播放视频 查看详情
• 12

  API Considerations & HTTP Error Reference

  第 186 页

  同学们，今天我们来看看使用Agentforce API时，一定要留意的几个关键点，还有一些常见的HTTP错误和解决方法。这些细节很容易被忽略，但一不注意就可能让你的调用失败，或者产生不必要的消费。 首先，要记住Agentforce API目前，不支持，“Agentforce（默认）”类型的代理。也就是说，如果你在后台建了那个默认的代理，API是调不起来的，必须使用自定义类型的代理。另外，调用API是会计入信用消费的，每一次请求都会消耗你的Agentforce信用额度，所以要规划好用量。还有一个硬性限制——每个请求有，120秒的超时，，如果你的逻辑特别复杂，超过了这个时间，连接就会被掐断。特别提醒一下，如果是政府云组织，端点不一样，一定要用 `api.gov.salesforce.com`，而不是普通的商业版域名。 接下来，了解一下最常见的HTTP错误码，这样遇到报错时，你能快速定位问题。 * ，400错误，：通常意味着你传的，代理ID，不对。检查下是不是复制错了，或者这个代理根本不存在。 * ，401错误，：授权问题。多半是访问令牌无效、过期，或者没有正确设置认证头。再确认一下你的会话ID或OAuth流程。 * ，404错误，：这个很常见。可能是你的，令牌错误，或者，端点URL，错了。记住，一定要用“我的域”URL作为基础，千万，不要，使用 `lightning.force.com` 这样的旧版域名。路径里代理ID拼错也会报404。 * ，423错误，：这表示有并发请求。Agentforce API同一时间只允许，一个请求，在处理，如果前一个还没完成你又发一个，就会返回423。你需要排队或者等上一个完成再发。 * ，500错误，：服务器内部错误。别慌，这往往是我们自己的请求格式有问题。最常见的是缺少，Content-Type头，，记得设成 `application/json`。另外可能是使用了错误的域URL，比如误用了 `lightning.force.com`，或者代理ID压根不存在。所以遇到500，马上去检查：域名是不是我的域？请求头带没带Content-Type？代理ID对不对？ 最后，给你一个简单排查清单： 1. 确保端点URL使用的是我的域，格式类似 `https://你的域名.my.salesforce.com/...`（政府云用 `.gov.salesforce.com`）。 2. 检查请求头，必须包含合法的认证信息和 `Content-Type: application/json`。 3. 确认代理ID有效，而且不是“默认”类型。 4. 留意超时和并发限制，避免重试风暴反而加重问题。 把这些基础打牢，调用Agentforce API就会顺畅很多。下节课我们会动手写一个完整的调用示例，现在有任何疑问吗？没有的话就先休息一下。

  ▶ 播放视频 查看详情
• 13

  Testing API Overview

  第 187 页

  同学们，咱们这一页要讲的是，怎么把Agentforce代理测试得又稳妥又可信。你先记住一句话——想让用户真正信赖你的代理，光靠感觉绝对不行，必须经过严格而彻底的测试。 那问题来了，怎么测呢？你肯定用过Agentforce Builder对吧，里面可以直接跟代理对话，一条一条手测，非常直观。但如果你有几百上千条对话场景要验证，纯手动可就太慢了，真的会测到手软。所以，咱们就需要一种更高效的方式——测试API。 你可以把测试API理解成一个“自动化测试中心”。它不是让你对着界面打字，而是让你能写脚本，批量丢进去一大堆请求，让系统自动评估代理的回复，很快就能跑完海量测试用例。那具体怎么搭这套自动化呢？这里用到的工具要稍微记一下：构建测试套件用的是“元数据API”，就像搭一个测试框架，把你要测的各种对话问题、预期结果都放进去；而真正执行测试、跑结果的，用的是“Connect API”，它负责把测试提交运行并把评估反馈拿回来。这一搭一跑，整个批量验证就实现了。 这儿有两个特别重要的限制，你一定要牢记：第一，所有这些代理测试，都只能在沙箱环境里进行，生产环境可不让跑，这是为了保证线上安全。第二，只要你跑测试，就会消耗“Einstein Delivers积分”。所以你设计用例时要尽量精准，别在沙箱里无节制地反复跑，把积分白白浪费掉。 整体看下来，Builder适合开发和调试时快速试一轮，但一旦到了需要回归验证、确保可靠性的阶段，就得靠测试API来做程序化批量测试，又快又能自动化评估。只有这样的组合，才能让你的代理在正式亮相前，变得真正值得信赖。 好了，这一页的核心就这些。你只要记住：手动靠Builder，批量靠API；元数据API来搭建，Connect API来执行；只限沙箱，耗用积分。有了这套思路，测试就不再是体力活了。

  ▶ 播放视频 查看详情
• 14

  Testing Methods & Workflow

  第 188 页

  同学们，我们来看这一页——如何为你的Agentforce智能体选择测试方法，以及整个测试流程是怎么走的。 首先，你有三种方式可以选。第一种是测试中心，它给你一个网页上的界面，可以上传CSV文件来批量跑测试。优点是很直观，点点鼠标就行，但局限是没有办法写自定义的评估逻辑，你只能用系统默认通过或不通过的判断。 第二种是Agentforce DX，这套工具是用命令行操作的。你需要写YAML格式的配置文件来定义测试，好处是它支持自定义评估，你可以自己写指标和判断条件，非常灵活，适合开发人员。 第三种是测试API，它给了你完整的编程控制。你可以通过元数据API（用的是HTML格式）或者Connect API（REST格式）来操作，适合你要把测试集成到自己自动化流水线里的情况。 不管用哪种方法，整个流程都分成三个阶段。第一个阶段，创建测试定义——也就是你告诉系统你要测什么、用什么数据、怎么判断成功；第二个阶段，把这个定义部署到一个沙箱环境里；第三个阶段，在沙箱里实际运行这些测试，然后拿到结果。 最后，还有几个很重要的限制需要记住。第一，测试只能在沙箱里跑，不能在生产环境执行。第二，运行测试是会消耗积分的，这个积分制度你平常用Agentforce就已经熟悉了。第三，每个测试定义同时最多只能跑10个并发运行，而且一个定义里面最多放1000条测试用例。第四，因为服务本身在不断改进，同一组测试，今天和下次再跑，结果可能会有一点细微的变化，这一点要有心理准备。 好，这页的内容就是这样，结合你自己的使用场景，你就可以选最合适的测试方式了。接下来我们看下一页。

  ▶ 播放视频 查看详情