Agentforce 实战示例 | Salesforce CRM 中文站

1

Platform Overview: Guides & Tools

第 22 页

同学们，咱们今天来看这一页幻灯片，它讲的是Salesforce平台为Agentforce提供的各种指南和开发工具。你可能会问，我要构建一个智能代理，从哪里入手呢？其实平台早就帮你把资源准备好了。首先，有一份叫，Agentforce API和SDK指南，的文档。它教你怎么用各种API来和Agentforce打交道，让你能快速构建出强大的解决方案。也就是说，你不用从零开始造轮子，直接通过这些接口，就能让代理帮你完成复杂的任务。接着，是，Agentforce Action，的指南。这里的“Action”你可以理解为代理能执行的具体动作，比如查数据、发邮件。这份指南就专门教你怎么创建和增强这些行动，让代理变得更实用。在开发工具方面，平台给我们提供了一个专门的语言，叫，Agent Script，。它是用来构建代理行为的脚本语言。如果你想精细地控制代理的逻辑，用这个语言就很方便，写法也很直观。对于喜欢用专业开发工具的同学，还有，Agentforce DX，。它是一套面向开发者的亲代码工具，提供了命令行接口和VS Code的扩展。你可以在自己熟悉的IDE里写代码、调试，拥有完整的开发体验。另外，平台还提供了两个很关键的AI配置工具。一个是用来配置，大语言模型，的设置界面，另一个是，提示生成器，。你可以用提示生成器，像搭积木一样创建和管理提示模板，这样就能轻松引导AI生成你想要的回答，而不需要去写很复杂的底层代码。你看，从API文档、行动构建，到专属脚本语言和开发工具链，再到AI的配置和提示设计，Salesforce把一整套的东西都规整好了，就是想让你能更顺利地构建出强大的Agentforce代理。怎么样，是不是清晰多了？咱们继续看下一页。

查看详情

2

Apex Code Example:

第 23 页

今天我们来聊一个具体的例子，看看怎么用Agentforce从零到一搭建一个能处理复杂客户问题的智能代理。这个例子很实用，是一个客服场景：客户会提一些关于产品库存的复杂问题，比如“有没有红色的、中号的、棉质的T恤，而且要在我们北京仓库里有货？”这种问题可能有多个条件，我们需要把这些条件拆开，变成能让数据库理解的查询。那怎么做呢？我们会在Agentforce里创建一个自定义的Apex操作。Apex是Salesforce后台的编程语言，可以帮我们写一些复杂逻辑。这个操作一接收到客户的问题，就会把那些口语化的、杂乱的描述，自动转换成一条精确的SOQL查询语句。SOQL就是Salesforce自己的查询语言，类似SQL。你可能会想，为什么要自己做这个转换，不是有现成的吗？因为现成的搜索可能无法理解这种多条件、跨对象的复杂意图，所以我们就用Apex来精准控制。这个过程我们分成几个步骤，每一步我们都会单独配置，这样你就能看清楚每个组件是怎么拼到Agentforce方案里的，整个链路怎么走通的。掌握这个例子之后，你对Agentforce处理复杂逻辑的套路就心里有数了。我们一步一步来，别急，慢慢就全明白了。

查看详情

3

Scenario: Product Inventory Agent

第 24 页

同学们，今天咱们来看一个非常实用的例子——怎么从头到尾搭建一个能处理复杂产品库存查询的客户服务代理。想象一下，有个客户来问：“嘿，我想找某款产品，但我的需求有点复杂，比如我要特定颜色、特定尺寸，还在某个价格范围内，你们有库存吗？” 咱们的代理就得能听懂这种多条件的问题，然后快速准确地告诉他答案。咱们今天就是要实现这么一个代理。首先，我们得准备数据。在这个例子里，我们会用Salesforce命令行工具，也就是CLI，把已经准备好的产品和价格数据，从一个CSV文件里，批量导入到Salesforce的标准对象里——也就是“产品(Product2)”和“价格手册(Pricebook)”。这样，咱们的库存和价格就有了基础。这一步很简单，就是跑几条命令，数据就进去了，为后续动态查询打好地基。然后，重头戏来了：我们要写一个Apex自定义操作。这个操作呢，它的作用就很巧妙了——它能把客户用自然语言提出的、带有好几个条件的复杂问题，翻译成一条能在后台执行的SOQL查询语句。比如说，客户说：“我想要红色的、中号的T恤，价格在50到100块之间，现在有货吗？” 咱们写的Apex类就会把这些条件动态拼成一个SOQL，去产品对象里查，然后把结果返回来。这样，代理就不用傻傻地只会匹配固定词，而是真正“理解”了结构化的需求。最后一步，咱们就来搭建代理本身了。我们需要创建一个主代理，再根据情况可能创建子代理，然后把刚才做好的这个Apex类封装成一个操作，让代理在合适的时候调用它。当客户发起复杂问询时，代理就会触发这个操作，操作调用Apex，Apex返回结果，代理再把结果用友好的语气告诉客户。整个过程闭环就完成了。这个端到端的实现其实很典型，它展示了Agentforce如何通过“数据导入 + 自定义逻辑 + 代理编排”的套路，来灵活应对真实业务场景。后面咱们会一步一步带着大家做，现在大家先对这个整体思路有个印象就好。有任何疑问，随时提出来哦。

查看详情

4

Step 1: Set Up a Developer Edition Org

第 25 页

同学们好，我们现在开始动手搭建实验环境。这第一步，就是注册一个 Salesforce 的 Developer Edition 组织。你只需要进入 Salesforce 的开发者注册页面，填写信息，就能免费申请一个开发版的组织。但如果你已经有自己的 Salesforce 组织，想直接用它，那就要先检查一下它有没有提供我们需要的功能：第一，必须启用了 Einstein；第二，启用了 Agentforce；第三，你能在这个组织里正常添加案例。而且请一定注意，你的用户权限还有其他组织设置，可能会影响你完成后续所有的操作步骤，所以要尽量确保权限足够。成功登录组织以后，我们要在设置里面操作。操作很简单：在顶部的快速查找框中输入“Einstein 设置”，然后打开 Einstein 设置。接着，再在快速查找里搜索“Agentforce 代理”，找到这项后打开，进去就能看到开启 Agentforce 的选项，把它打开。这样一来，你的基础环境就准备好了。

查看详情

5

Step 2: Import Your Data

第 26 页

今天我们来聊聊，怎么把我们手头杂乱的数据，整理好、放进Salesforce里，让我们的Apex代码能用起来。想象一下，你刚从供应商那里拿到一份Excel表格，里面是100件家具的数据。每一行都有家具名称、颜色、重量这些信息。但Salesforce现在还没有存放这些数据的标准字段，直接导入也没意义，因为自定义的Apex类需要的是组织好的结构化数据。所以，我们得先准备好Salesforce这边的“家”。怎么做呢？我们先在“产品”对象，也就是Product2上面，创建两个自定义字段。一个是颜色，做成选择列表，比如红色、蓝色、木色，让用户以后只能从下拉菜单里选。另一个是重量，我们就用数字字段，单位是公斤。这样一来，我们的数据模型就清晰了。接下来要导入数据了。我们不用一个个手动输入，太慢了。我们用Salesforce的命令行工具，叫Salesforce CLI。第一步，你得先登录到你的Salesforce环境，用这条命令：`sf org login web`。它会弹出一个浏览器窗口，让你确认登录，很方便。登录成功后，我们就准备批量导入。针对产品数据，命令是：`sf data import bulk`，后面指定你要导入的CSV文件，还有对应的对象是Product2。这条命令会把你的100件家具连着颜色和重量，一起塞进产品对象里。但光有产品还不够，我们还得处理价格。每个产品在Salesforce里要卖出去，需要关联到一个标准价目表，也就是PricebookEntry。所以，我们得先找到系统里的标准价目表ID，这可以用查询命令拿到。然后，我们要再建一个导入用的CSV文件，里面每一行都对应一件家具，写上产品ID、标准价目表ID，还有价格等信息。接着再用一次`sf data import bulk`，把价格数据导入到PricebookEntry对象。全部搞定之后，怎么知道做没做对呢？很简单，打开Salesforce里的“产品”应用程序，看一看，是不是100件家具都在，而且每件的颜色和重量字段都正确填上了。这样，我们的数据就干干净净，整整齐齐，我们的Apex类就可以放心地去查询和处理它们了。

查看详情

6

Step 3: Create the Apex Class

第 27 页

好了，咱们来看这一页。现在我们要创建一个给代理用的自定义 Apex 类，名字叫 DataboryRetriever，你可以把它想象成代理的一个小工具，专门帮它去查家具库存。这个类里头呢，有三个很关键的组件，我把它们拆开讲。首先，第一个是叫 RetrieverInvestment 的内部类，它定义的是代理可以传进来的参数。有哪些呢？一个是类别，一个是颜色，还有一个是最高价格 Max Price。每个参数上面都有 @InvocableVariable 这个注解，并且配了描述文本，这就相当于告诉代理：“嘿，这个字段是干什么用的”，代理就能理解你要它填什么值了。第二个组件是 RetrieverExit，它定义了执行完操作以后返回给代理的东西—这里返回的是一个叫 productsum 的字符串，里面装着匹配到的家具产品信息。第三个是真正干活的入口。我们用一个叫 @InvocableMethod 的注解标记了一个方法，并且给它贴了个标签，叫“搜索家具库存”。代理看到这个标签，就知道怎么调用这个动作了。接着咱们看看里头的查询逻辑。它会先从 Product2 这个对象开始查，然后根据代理实际传进来的条件，比如说代理指定了类别、颜色，就动态地拼接出 WHERE 条件；接着，它会连到 PricebookEntry 去取价格，构建一个快速查找价格的地图；最后再用传进来的 MaxPrice 做过滤，把不符合预算的家具去掉。这样一套下来，返回给你的就是靠谱的结果了。而且这个代码注释写得特别清楚，很好懂，大家课后可以打开看看每一步的详细解释。这样，咱们就把这一页的重点过完了。

查看详情

7

Step 4: Configure Subagent and Actions

第 28 页

同学们，我们终于来到了动手实践的环节。现在我们要一起构建一个真正的代理，还要给它配上自定义的子代理和操作。大家打起精神，我们一步步来。首先，打开 Agentforce Studio 应用程序。看到那些模板了吧？我们就从模板开始，创建一个 Agentforce 服务代理，名字就叫“Furniture Helper Agent”——家具助手代理。点几下，这个主代理就搭起来了，但现在的它还是个空壳，什么都不太会。接下来，我们要教会它处理特定的事情。那就是创建一个子代理，名字叫“搜索库存”。这个子代理就像主代理手下的一个专家，专门应对某类问题。在它的“描述”一栏里，我们要写得特别清楚：这个子代理负责处理所有和产品库存相关的问题。但光写“处理库存问题”是不够的，你要在描述里，明确写出推理指令，，直接告诉代理：当用户问到库存时，你必须调用某某操作，不要自己瞎猜。举个例子，可以这样写：“处理所有家具产品的库存查询。当用户询问某个家具是否有货时，直接调用‘Search Furniture Inventory’操作，并返回查询结果。” 如果不这么明确指示，代理很可能会自作主张，随便说“我不知道”，或者干脆忽略掉你精心准备的那个查询动作。所以推理指令一定要明确，别让代理偷懒。搞定了子代理，我们就来赋予它一个真正的“手”——创建一个新操作。在操作类型里，选择“Apex 引用操作”，然后选“Invocable Method”类别。这时候，你会看到我们之前发好的那个 Apex 动作：“Search Furniture Inventory”。选中它，这个操作就和子代理关联起来了。但是别急，还有一个特别关键的步骤：写，动作描述，。这个描述不是写给开发人员看的，是写给代理的大脑看的。代理会根据这个描述来决定，当下该不该执行这个动作。所以描述要精准，比如：“根据产品名称或 SKU 搜索家具库存，返回可用数量。” 你写得越清晰，代理就越清楚什么时候该调用它，而不是乱猜乱用。动作描述的好坏，直接决定了你的代理是聪明还是蠢笨，所以一定不能马虎。好，回顾一下：我们先从模板建了一个“Furniture Helper Agent”，然后给它加了个专家子代理“搜索库存”，在描述里明明白白告诉它要调用操作。最后创建了一个 Apex 操作，并配上精确的动作描述。这几步做完，你的代理就从一个空壳，变得真正能帮用户查库存了。下一讲，我们来测试一下它干活是不是真的利索。现在大家动手试试看吧。

查看详情

8

Step 5: Grant Agent User Permissions

第 29 页

我们来看这一页的内容，主要是讲怎么给咱们的Agentforce代理赋予权限，让它能正常访问数据，还能调用我们写好的Apex代码。你想象一下，这个代理就像一个刚入职的员工，什么都不懂，你让它去查产品库存，它说“我没有权限”；让它运行一个自定义的程序，它又说“我做不到”。这不是它笨，是咱们没给它开门。所以，权限配置这一步，就是给它发门禁卡。首先，我们要打开一个叫“Agentforce代理权限集”的东西。这个权限集里，我们需要增加对产品和价格相关对象的访问。具体来说，要启用三个对象：Products 2（也就是产品对象）、Pricebookentry（价格手册条目）和Pricebook2（价格手册对象）。不仅要打开对象本身的查看权限，还要把它们所有的字段权限也都打开。这样代理才能完整地看到产品的各种信息，比如名称、价格、库存状态等等。操作路径就是：进入Agentforce代理权限集，找到“对象设置”，然后依次找到这三个对象，把权限都勾上。接着，第二步是授权它可以调用我们自定义的Apex类。有时候我们需要代理去执行一些复杂的业务逻辑，这些逻辑我们写在了Apex类里。默认情况下，它没有权限运行这些类。你需要导航到“Apex类安全设置”，在那边你会看到一个列表，找到那个“Einstein Agent用户配置文件”，把它添加到已启用的配置文件列表中。这样，代理背后的用户身份就有了执行特定Apex类的权力，它就能调用这些代码了。简单总结一下：两步走，一是给对象和字段权限，让代理看得见数据；二是给Apex类权限，让代理会动脑子办事。这样就搞定了。好，这一页的重点就是这些，我们继续看下一页。

查看详情

9

Step 6: Test Your Agent

第 30 页

好，同学，咱们今天这节课啊，重点讲一个特别关键的事儿——测试。你在把做好的智能代理交给客户之前，一定要像检查作业一样，仔仔细细地测一遍，不然客户一用就出错，那可就尴尬了。你看，Agentforce Builder 自带的测试功能非常高级，它不光是看你的代理能不能回答，还会帮你检查它的行为是不是一贯靠谱、负责任，是不是真的能帮到客户。具体怎么做呢？回到你正在编辑的代理页面，找到右上角那个“预览”按钮，点进去。这时候要注意，把模拟模式切换成“实时测试模式”。别小瞧这一步，实时模式才是真正模拟上线后的环境，等于实战演习。切换到实时模式之后，你就可以像客户一样跟它对话了。比如说，你问问它：“你们有哪些400美元以下的白色或灰色椅子？”这个问题就很有意思，因为它不止一个条件，既要价格范围，又要颜色，还得是椅子。正好能测出代理能不能准确地理解复合问题。问题问出去之后，不要光看它最后给的答案。你往旁边看，有一个叫“交互摘要”的栏目，这里面显示的是代理的整个推理过程——它怎么拆解你的问题、调用了哪些数据、一步一步得出结果的。这就像看一个学生解题的草稿，你能知道它到底哪里强、哪里可能有点小毛病。如果你看了推理过程，觉得逻辑很清晰，给出的结果也符合预期，那就可以放心地激活这个代理了。记住，多测几次，多换几种问法，确保万无一失。好了，这就是关于测试的核心要点，下一个小节我们讲怎么正式发布。有什么问题随时问。

查看详情

10

Step 7: Save, Commit & Activate

第 31 页

咱们现在来聊聊，当你的 Agent 代理已经调试好，准备正式上线的时候，该怎么做。你可能会觉得，直接保存就行了吧？其实不是，这里有一个非常重要的概念，叫做“版本”。就像我们写文档，会保存重要的版本一样。首先呢，你找到并点击“提交版本”这个按钮。这个动作，就像是给你的代理拍一张快照，把当前所有的设置都“咔嚓”一下锁定起来，形成一个正式的、完整的版本。一旦锁定，这个版本就不能再改了。为什么要这么做呢？因为它要保证，如果将来你又做了新的改动，结果出了问题，你随时可以退回到这个稳定可靠的旧版本，什么都不影响。提交完版本之后，紧接着，你还需要点击“激活”按钮。只有激活了，你的代理才会真正开始工作，出现在它被连接的渠道上。比如网站上的聊天窗口、或者消息应用里。现在，你的代理就正式上线了，准备用它内部配置好的自定义 Apex 动作，来回答客户关于家具库存的各种问题了。比如说，客户问“这款沙发还有货吗？”，代理就会自动调用后台程序查询库存，然后给出答案。好了，就这么两步：提交版本，然后激活，你的代理就崭新上线啦。

查看详情

11

Agent Script Example:

第 32 页

我们来看看第二个示例，这个示例演示了如何用代理脚本来构建一个客户支持代理。这个代理的主要任务就是帮客户查订单信息。你可以把它想象成一个虚拟客服，它能自动回答客户“我的订单到哪了？”“什么时候发货？”这类问题。为了实现这个功能，这个代理里包含了三个“子代理”，每个子代理各司其职。第一个是“代理路由器”，它相当于前台接待。当客户进来时，路由器会先给个欢迎语，然后根据客户的需求，把对话引导到合适的子代理那里去。它本身不处理复杂业务，只是提供说明，并让客户可以选择跳转到身份验证或者订单管理。第二个是“身份子代理”，它负责安全验证，通过邮件给客户发验证码，确认客户真的是订单的主人，防止信息泄露。这就像你打电话给客服时，对方先要核实你的身份一样。第三个是“订单管理子代理”，当客户通过身份验证后，这个子代理就会接手，帮客户查具体的订单详情，比如订单状态、物流信息等等。所以整个流程就是：客户联系支持代理，路由器接待并告知可以做什么；客户选择查订单，路由器就转到身份子代理去验证；一旦身份确认，路由器再把对话交给订单管理子代理，最后客户就能拿到自己的订单信息了。这样一层层分工，让整个代理既清晰又安全。

查看详情

12

Customer Support Agent Architecture

第 33 页

同学们，我们来看这张Slide，它展示的是一个客户支持代理非常干净的体系结构。这个代理整体由三个子代理组成，分工特别清晰。首先，最上面有一个叫“Agent_Router”的子代理，它是整个客户对话的入口点。也就是说，每次客户发来消息，不管说什么，都会先经过Agent_Router。它就像前台接待一样，分析用户说话的内容，然后决定接下来该把你带到哪儿去。为了做这个判断，Agent_Router手里握着两个工具：一个叫“go_to_identification”，专门给还没验证身份的客户用；另一个叫“go_to_order”，给已经验证过的客户用。这样一区分，逻辑就非常清爽。接下来，我们再看看另外两个子代理。如果客户还没验证身份，就会被路由到“Identity”子代理。它的工作很直接，就是通过一个Flow操作，往客户的电子邮箱里发送一个验证码，然后等着客户把收到的验证码再提供出来，最后验证这个码是否正确。整个过程依赖的都是确定性的流操作，没有花哨的地方，非常可靠。另一位子代理叫“Order_Management”，负责处理已认证客户的订单相关请求。它可以展示客户当前的订单摘要，也能根据订单ID去查找过去的订单。同样，它里面也是完全通过基于流的操作来完成任务。而且需要特别记住的是，这些子代理里的动作，都不是随便触发的，都是从代理脚本确定性地调用过来的。也就是说，业务流程提前已经定义好了，什么时候验证、什么时候查订单，都是脚本严格控制的，不会出现随机行为。这样一套设计，好处就是结构干净、维护容易。入口负责路由，身份负责验证，订单负责业务，各司其职。大家把这张图看懂了，对Agentforce里如何搭建一个规范的服务代理就心里有数了。我们接着看下一页。

查看详情

13

Agent Script Structure & Key Patterns

第 34 页

好，咱们今天来看看Agentforce里的代理脚本是怎么组织的。你可以把它想象成一个剧本，有固定的写作格式，让代理能清楚知道自己是谁、要做什么、怎么做。首先，这个剧本分成几大块。最上面是“系统块”，用来定义代理的性格和说话方式——就像给演员定人设。接下来是“配置块”，写清楚这个代理的开发名称、默认用户和一段描述，好比演员的基本档案。然后，你会看到“变量”，就像剧本里留的空，得有类型、说明和默认值，后面才能灵活使用。整部戏的入口是“start_Agent”，它相当于主角上场，带着总的推理指令和可执行的动作清单。如果剧情复杂，还可以分出“子代理”，每个子代理也有自己的描述、推理和专门的动作。动作部分怎么写呢？如果是基于流的动作，就要定义输入、输出，以及指向哪个自动化流程。另外，剧本里还有几个重要技巧：用“@utils.transition”来控制从一个子代理跳到另一个子代理，像切换场景；用“available when”分句来设置动作在什么条件下才能出现，就像演员看时机才出手；还有后台处理的“Flow目标”，让任务悄悄在后台跑，不打扰前台对话。简单来说，这个结构就是：先定人设，再设参数，然后从入口开始，主角带着一群能分工的子代理，按条件和规则执行各种动作。你按这个模式来写，代理就能既聪明又有条理地跟你配合了。

查看详情

14

Agent Script Example:

第 35 页

好，我们接着看今天课程的第三个例子。这个例子特别实用，讲的是怎么让你的Agent跟上公司里那些不断变化的新词儿、行话，或者产品的新名字，而且你完全不用去翻新底层那些厚重的资料库。想象一下，有一家叫Aura & Ash的护肤品公司。他们用了一个服务Agent，这个Agent的知识基础是产品说明书。听起来不错对吧？但问题来了，护肤品公司嘛，经常推新品，名字也是一会儿一个样，比如今天叫“水光精华露”，明天可能升级成“水光焕颜精华”。如果每次产品换名，你都要去更新源文件、重建索引，那可太折腾了。这时候，Salesforce Knowledge就能派上大用场。你不需要动那些厚重的产品说明文档，只需要在里面建一个非常轻量的“术语图”，你可以理解成一张小小的翻译对照表。比如：“旧产品A”也叫“新产品B”，或者团队里老说的“小蓝瓶”指的就是那款明星精华液。Agent在回答问题前，会先偷偷看一眼这张小抄，这样它就能听懂客户说的新词、公司内的黑话，直接匹配到原来的知识。整个过程，又轻巧又灵活，特别省事。这就像你给Agent配了一个实时更新的俚语词典，让它永远跟得上公司的说话方式，对吧？好，这就是第三种聪明的做法。

查看详情

15

The Problem & The Solution

第 36 页

同学们，咱们这节课讲的是一个很常见，但又非常巧妙的问题解决方案。想象一下，你的公司里有一个知识库，里面存着成千上万篇产品文档，Agentforce会去查这些文章来回答客户问题。但是这里有个问题：这些文章用的都是产品的官方正式名称，而你的客户在提问的时候，说的往往是俗称、缩写，或者是内部流通的行话。比如说，客户会问“那个小蓝瓶怎么用”，但知识库里这篇文章的标题是“高效保湿精华液（型号X-200）”。这就导致了Agent可能根本找不到对应的信息。有人会说，那把知识库里的文章都加上这些别名重新索引一下不就行了？可问题是，如果你有几千篇文章，每个产品都有好几个外号，这个维护成本太高了，而且要等很久才能更新完。那我们的解决方案是什么呢？非常优雅。我们不要动那些沉重的知识文档，而是在检索之前，做一层轻量级的翻译。具体做法是：我们在Salesforce Knowledge里，或者干脆新建一个自定义对象，专门维护一个“术语映射表”。每一行就是一个对应关系，左边是客户可能会说的非正式叫法，右边是系统能识别的正确术语。这个表很小，维护起来很快。然后，Agentforce在每次会话开始的时候，一次性把这个映射表的信息拿到手，再把它“注入”到提示词里，用轻描淡写的方式告诉大模型：“如果用户提到了小蓝瓶，你就翻译成高效保湿精华液去查资料”。这样一来，Agent在真正搜索知识库之前，就已经把用户的问题翻译成了正式语言。最妙的是，这个映射表完全可以交给业务人员去更新，他们最懂客户怎么叫这些产品，根本不需要IT人员插手。更新一个术语，几秒钟就生效了，完全不用重新索引那些庞大的文章。所以，整个逻辑就是：建立一个业务人员可维护的术语字典，在提问前先翻译，再搜索。轻巧、快速，还特别管用。这就是我们今天讲的接地代理中处理行话和别名的优雅方案。

查看详情

16

When to Use (and Not Use) This Pattern

第 37 页

同学们，我们来看这节课的一个关键知识点。假设你的知识库内容本身没问题，但用户老爱用不同的词来问问题——比如用户说“笔记本”，而你索引里存的是“笔记本电脑”——这时候，如果产品的名称还经常变来变去，而我们手头需要整理的这些近义词、俗称、别称的表单又不是特别大的话，那么当前这种“术语映射”模式就特别合适。不过反过来，要是你那个术语对照表变得非常庞大，有几千条，这会严重拖慢代理的反应速度。或者呢，你的信息源本身改动容易，直接更新内容重新建索引更快，那就不适合用这个模式了。这里还有一个特别重要的技巧，大家注意听。在你准备为某个新术语去画映射之前，先别急着加，直接把那个用语拿去问代理。看看代理是不是已经通过它自己公开的大模型训练数据，学到了这个词。只有当代理真的回答不出来，出现了失败案例，我们才来建这条映射。为什么这么做？因为你先确认了失败，然后有了映射后又解决了，这样才能清清楚楚地验证你的方案确确实实有效。好，这一页的要点就是这些，有什么不明白的可以随时问我。

查看详情

17

Setup: Org, Agent & Data Library

第 38 页

同学们，我们来看一下Agentforce的设置流程，一共就几个步骤，跟着做就能跑起来。首先，我们得有一个启用了Agentforce和Data Cloud的开发者组织。Data Cloud一定要确认已经设置好，因为它是Einstein生成式AI和Agentforce很多基础功能的前提，比如信任层、代理的事件日志，还有使用量计费，都依赖它。然后，我们要在设置里先启用Einstein生成式AI，接着再启用Agentforce。顺序别乱，先AI后Agentforce。接下来，我们用标准模板创建一个默认的服务代理，名字就叫“Aura & Ash Service Agent”，很直白。再下一步，我们需要给这个代理配上知识库。怎么建知识库呢？上传Aura & Ash的产品说明PDF就行。上传后等状态变成“Ready”，就把它分配给刚才建好的那个代理。最后是测试。我们用两个产品名来试：一个是旧的产品名，它能正常出结果；另一个是新的产品名，这个会失败，但别担心，这是预期内的——正好帮你理解检索的工作原理。这样，整个基本设置就跑通了，你也看到了一个能工作的Agentforce代理雏形。

查看详情

18

Create a Terminology Map with Knowledge

第 39 页

同学们，我们接着来看。如果想让咱们的 Agent 能听懂客户说的“别名”或者“土话”，就需要做一个术语图，把不同说法统一指向标准名称。这就要用到 Salesforce 知识库，让 Agent 能去文章里查对应关系。第一步，先给操作用户分配“知识用户”许可证。然后到知识设置里，把“Salesforce Lightning 知识”这一项启用起来，这样知识功能才能真正跑起来。第二步，要在知识对象上创建一个自定义字段。对象名叫 Knowledge__kav，你直接在它上面新建一个“长文本区”字段，命名为“替代产品名称”，专门用来存某个产品曾经被叫过的各种名字。创建完后，别忘了在字段安全性里，让 Einstein Agent 那个用户能看得见这个字段。第三步，处理代理用户的权限。找到给 Agent 用的那个权限集，进去授予两个关键权限：一个是对象权限，在 Knowledge__kav 对象上勾选“读取”和“查看所有字段”，这样 Agent 才能读到文章内容；另一个是应用程序权限，把“允许查看知识”勾上，让 Agent 能打开知识库这个功能本身。第四步，回到知识库，创建一个新的知识文章。在标题或者合适的地方写清楚产品名称，然后把那个“替代产品名称”字段里，填上过去的老叫法或者简称。比如主产品名叫“超能清洁液”，你就在替代名称里写下“万能去污剂”、“神奇清洁水”这些客户常说的词。一个文章里可以填多个别名，用分号或者换行隔开都行。填好后直接把文章发布，发布后会生成一个文章编号，把这个编号记下来，后面配置术语图时要用到。这样，我们就把术语映射存进了知识文章里。Agent 遇到客户说老名称，就会自动去搜索这篇文章，找到对应的标准产品名，再也不怕听不懂“行话”了。简单吧？

查看详情

19

Create a Flow to Fetch the Knowledge Article

第 40 页

好，我们接下来创建一个自动启动的流，专门用来通过文章编号快速获取一篇知识文章。这个流将来主要给 Einstein 服务代理使用，所以设计上要简洁、可调用。首先，从“设置”里进入“流”，点击“新建流”，选择“自动启动流”。自动启动流没有界面，它会静静地等在后台，随时被别的自动化或代理调用。接着，往里添加一个“获取记录”元素，这个元素相当于一条 SOQL 查询。我们把对象设成 Knowledge__kav，也就是知识文章的对象。然后我们先指定过滤条件，让查询按照 ArticleNumber 字段来筛选。条件那里设成“ArticleNumber 等于”一个叫 articleNumber 的输入变量——这个变量稍后会在流的外部被传入，比如从代理对话中拿到客户提到的文章编号。值匹配成功后，我们还要获取文章里的一个自定义字段。在“获取记录”元素里，找到“存储字段值”那部分，选择 Alternate_Products_c 字段，把它映射到一个新建的输出变量上，我们叫它 alternateProductName。这样调用方就能直接拿到这个替代产品的名称，不用再二次查询。流搭好后别急着激活。我们先来调试一下。因为以后主要用 Einstein 服务代理的用户身份来运行，所以点击“调试”，把运行用户切换成 EinsteinServicAgent。如果这个代理用户权限足够，流应该运行成功，并返回正确的字段值。但要是调试时抛出了错误，比如没有访问对象或字段的权限，也别慌。先把运行用户临时换成自己（系统管理员），再跑一次。如果管理员身份能正常跑通，那就说明流本身逻辑没问题，问题出在代理用户的权限上。这时就去检查一下 EinsteinServicAgent 用户的权限集或简档，确保它对 Knowledge__kav 对象和 Alternate_Products_c 字段至少有读取权限。必要时调整一下。权限补齐后再切回代理用户调试，直到完全通过。确认无误后，点击“激活”，这个流就准备好了。将来 Einstein 服务代理在对话中需要查找知识文章的替代产品时，就会自动调用它，又快又准。

查看详情

20

Update Your Agent: Variables, Actions & Instructions

第 41 页

我们来看这一页的重点——怎样分四步来更新你的 Agent，让它变得更聪明。第一步，我们先创建一个文本变量，名字叫 Old2NewProductName，然后给它一个默认值 “NotRun”。你可以把它理解成一个小标签，用来标记我们有没有查过产品名称的对照关系。第二步，我们在 General 常见问题解答子代理下面，创建一个新的操作，名字叫 GetNewProductName。这个操作会调用一个叫 Alternative Products Name 的流程，通过输入商品编号 articleNumber，就能拿到对应的替代产品名称 alternateProductName。第三步，我们要切换到脚本模式，加一条确定性的指令。这条指令的意思是：只运行一次这个操作。怎么做呢？先检查那个 Old2NewProductName 是不是还等于初始值 “NotRun”。如果是，说明我们还没查过，那就用当前对话里拿到的知识文章号去执行这个操作，把新的产品名字取回来。第四步，我们要更新一下 Agent 的整体说明。告诉它：如果在知识库里没找到提到的那种产品，就去看看 Old2NewProductName 这个变量。一旦里面有了映射过来的旧产品名称，就直接用这个旧名字去重新搜索知识库，这样就能给客户找到正确的结果了。你看，通过这四步，Agent 就学会了先自己查对照表，实在没有才去知识库找，而且不会重复查，效率也更高了。

查看详情

21

Test & Verify the Terminology Solution

第 42 页

同学们，我们这节课来讲测试你的智能体。好，在完成所有的设置之后，你肯定想看看，它到底能不能运行，对吧？所以这一步叫做测试你的代理。具体怎么做呢？很简单。你可以找到界面上那个预览按钮，点一下。有的时候可能需要刷新一下。然后，在你和代理对话的那个文本框里，输入一个带有新产品名称的提示。还记得吗？举个例子，你可以问它：“告诉我有关Iron Grip Rescue Fuel的信息”。这时候，关键点来了。你期望看到什么？你的代理不应该愣住，也不应该去网上瞎找。它应该回复你在知识库里准备好的，关于那个旧产品——也就是“手部和角质层护理油”的信息。你为什么会这么自信？因为我们在创建指示里做了转换，这是它应该完成的逻辑，把新名字映射到我们已有的旧知识上。那么，怎么确保它真的懂了，而且没有浪费资源呢？你可以在交互摘要里验证一下。去仔细看看执行过程，你会发现那个关键的 GetNewProductName 操作，在整个对话流程中，只运行了一次。这就对了，非常高效。这个小小的测试范例，其实向我们展示了几种非常关键的代理脚本设计模式。大家一定要记住：第一种模式，叫做“在推理之前获取数据”。你看，代理在张嘴回答你之前，它先悄悄地跑去查了一下这个产品的新名字到底是什么，对吧？拿到准确事实，再说话。第二种模式，是“使用条件，让操作只运行一次”。通过条件判断，我们确保了翻译这步工作只做一次，而不是一个提问里面反复查询，避免了重复操作。第三种，是“高效地使用带有默认值的变量”。万一查询失败，或者新名字为空，怎么办？我们有兜底的默认值，这就保证了程序的健壮性。最后一种，也是常被忽略的一种，就是“用已知的失败案例去验证”。我们故意用一个新的、大模型不知道的名字去测试，就是要确保你的解决方案是真的在起作用，而不仅仅是因为大语言模型凭借着它的公共知识猜到了答案。你得证明，是你的逻辑链条在驱动它，而不是外面的通用知识。好了，同学们，记住这几种模式，以后你们设计任何复杂的代理时，一定会用到。我们接着看下一个部分。

查看详情

22

Agent Script Example:

第 43 页

我们来看看最后一个例子，这个例子很巧妙地展示了怎么让你的代理严格地按照一个定义好的流程来走，特别是在那种多回合的对话里，一步一步引导用户完成整个对话。想象一下，你的代理要做的事情是有先后顺序的，必须先完成第一步，才能进入第二步，不能跳步，也不能乱序。那怎么保证代理能这样守规矩呢？这就用到了我们今天要讲的“步骤变量”。在这个模式里，我们会设定一个变量，专门用来记录当前的步骤状态，比如第一步、第二步、第三步……我们就叫它步骤变量。然后，代理里的一个路由器——就是负责分发任务的组件——会不断地检查这个步骤变量的值，根据当前的步骤值来决定把对话交给哪个子代理去处理。到了子代理里面，大语言模型会去评估用户刚才的回答，判断这一步是不是已经完成了。一旦完成，子代理就会更新那个步骤变量的值，把它改成下一步。比如说，完成第一步后，把步骤变量从“第一步”改成“第二步”；完成第二步后，再改成“第三步”，就是这样循环下去。这种做法的好处非常明显，特别适合那些必须按严格顺序执行的任务。你想，有些业务流程是一环扣一环的，只有在前一环节彻底完成、信息收集齐全之后，才能安全地进入下一环节。用步骤变量来驱动，就能完美地实现这种控制。而且这个方法处理长时间、多回合的对话也很得力。因为变量状态一直跟着对话走，代理不会忘记自己走到了哪一步，即使对话中间用户岔开话题，回来的时候代理依然知道该干什么。它只会在当前任务真正完成的那一刻，才会把控制权传递给下一个子代理，绝不会提前转场，导致流程错乱。所以你看，这个模式非常清晰：路由器根据步骤变量的值来选择子代理，子代理内由LLM评估并设置下一步的值，这样我们就构建了一个严格按照定义顺序推进、能够处理复杂对话流程的可靠代理。简单、稳定，而且非常容易理解和维护。

查看详情

23

When to Use This Pattern

第 44 页

同学们，我们这一页要讲的是一个非常有用的对话模式，专门用在需要一步步引导客户、按顺序收集信息的场景里。你可以这么理解：当你的Agent必须按照一个固定的流程，一个接一个地问问题，而且下一个问题问什么，可能完全取决于客户上一个回答的内容，这时候就要用上这个模式了。它特别适合那种又长、又有好几轮的对话，因为你需要反复检查客户每次给的信息是不是完整、是不是有效。如果客户回答得不清楚，或者缺少关键信息，Agent还能再回到同一个子代理那里，换个说法再追问一次。咱们来看一个面试Agent的例子。假设我们做了一个Agent来初步筛选求职者，它会按特定顺序问一系列必问的问题，比如“你有没有某某证书？”“你有几年的相关经验？”每个问题就像一个关卡。如果求职者回答“我还没有那个证书”，那可能直接就不符合要求了，面试就当场终止了。后面那些经验、技能的问题就都不用再问了——这就是“导致解雇”的意思。在技术实现上，每个问题都由一个独立的子代理来负责。比如第一个子代理专门问证书问题，第二个专门问工作经验，第三个问薪资期望……它们各司其职。而且，这些子代理在完成自己的任务后，会设置一个叫 currentInterviewStep 的变量，来告诉系统下一步该跳到哪个子代理，比如“下一步该问技能问题了”，或者“面试结束”。这样整个流程就很清晰，也容易调整顺序，一旦前面的回答改变了后面的路径，只需要改变这个变量的值就行了。所以总结一下，这个模式的核心思想，就是把一个长流程拆成多个独立的小步骤，每个步骤由一个子代理负责，通过变量控制流程走向，同时还能随时回到上一步去追问澄清。这样既能保证对话的自然流畅，又能严格把控数据收集的质量。好了，这一页的内容我们就讲到这里。大家记住这个“面试模式”，以后遇到需要按逻辑链条收集信息的场景，优先想到它。

查看详情

24

How Routing & Step Variables Work

第 45 页

我们来看看这个幻灯片的核心——Agent是如何像一个聪明的面试官一样，一步步引导对话的。想象一下，我们正在构建一个招聘面试的自动对话流程。整个流程需要经过很多个环节：先看候选人有没有许可证，再查资格条件，然后是看他的空闲时间、工作能力、薪资期望、个人信息……最后结束面试。如果每一步都写死在一个大程序里，那会非常僵化。而在Agentforce中，我们用一种更灵活的方式——，子代理路由器，。这里的关键是一个叫做 `currentInterviewStep` 的变量，我们可以把它理解成一个“路标”。它告诉系统：当前这个用户正在面试的哪个阶段。这个路标可能的值，就是我们刚才说的那七个步骤：许可、资格、可用性、能力、薪资、人员，以及结束。那么，谁是看路标并决定往哪走的人呢？就是我们设置的一个，起始代理，，它就像一个总调度，或者说路由器。它只做一件事：检查 `currentInterviewStep` 这个变量的当前值，然后直接跳转到对应的子代理。比如，路标上写着“资格”，它就把对话交给“资格”子代理去处理。一旦进入具体的子代理，事情就变聪明了。在这个子代理里，Agent并不是死板地执行完就跳到固定下一步，它会根据你给它的回答，动态地修改路标。它是怎么改的呢？通过调用一个工具，叫 `@utils.setVariables`，去更新 `currentInterviewStep` 这个变量的值。举个例子，假设我们进到了“资格”子代理。Agent会问你：“您有相关专业的大专以上学历吗？” - 如果你支支吾吾，给了一个模糊的答案，Agent可以判断：这个问题还没回答清楚。于是它，不改变，路标，下次继续留在“资格”这个步骤，再问一遍。 - 如果你清清楚楚地回答了“有”，并且通过了验证，Agent就会把路标改成“可用性”，于是下一次调度时，路由器就把对话带到“可用性”子代理，去问您什么时间可以上班。 - 但如果你回答“没有”，很遗憾，不符合资格，Agent就直接把路标改成“结束”，让对话走向结束环节，礼貌地结束面试。所以你看，整个面试流程并不是一条直线，而是一棵可以根据回答灵活跳转的树。这个路由器机制让对话特别自然，像是真人在控制节奏——用户答完了就推进下一步，答不全就原地等待，不合格就及时终止。记住，这里每个子代理都只负责自己那一小块事情，它们不关心整体的流程图。而起始代理这个路由器，则像总指挥，根据变化的路标，把对话交给合适的专家。这种设计让我们的对话机器人既清晰好维护，又极其灵活。这就是Agent子代理充当路由器的精髓。用简单的变量，加上动态修改它的能力，让多步骤对话变得有条不紊。

查看详情

25

Try It Yourself & Related Patterns

第 46 页

我们来看看这一页的内容，它其实是一个动手小练习，帮大家快速感受一下 Agentforce 里怎么去编排一个面试流程。首先，你需要去下载一个叫做 InterviewAgent.Agent 的示例文件。下载好之后，打开你的 Agent Script 界面，里面有一个按钮叫 “New from Script”，点击它，然后把示例代码粘贴进去。这样，一个面试代理的骨架就出来了。接着你可以预览这个代理，在对话里直接跟它说一句，比如 “我想申请这个职位”。它就会按照脚本里设定的流程，开始问你问题，收集你的回答。这个示例很好地展示了 “步骤变量” 是怎么使用的——你可以把用户每一步的回答存进变量里，后面再用这些变量去做判断或总结。不过要提醒一句：这个代理主要是为了演示功能，不是可以直接上线的生产版本。当成一个学习模板就好。学完这个基础示例之后，如果你想做得更深入，可以沿着这几个方向去探索：第一，怎么在多次对话里，用子代理来强制引导用户走完必需的工作流程——比如一定要先投简历才能进入面试，不能跳过。第二，子代理之间怎么顺畅地转换，让整个对话显得不割裂。第三，在真正开始推理决策之前，怎么从外部获取数据，比如拉取职位详情或候选人信息。第四，怎么在脚本里用条件语句，根据不同的回答走不同的分支。最后，就是灵活地定义和使用各种变量，让整个代理的逻辑更清晰、更可维护。这些模式掌握了之后，你就能搭建出真正实用、而且体验流畅的面试代理了。现在，你可以去试试动手跑一下这个示例，有什么感觉或者问题，随时可以来讨论。

查看详情

ADG001

课程介绍

课程章节

Platform Overview: Guides & Tools

Apex Code Example:

Scenario: Product Inventory Agent

Step 1: Set Up a Developer Edition Org

Step 2: Import Your Data

Step 3: Create the Apex Class

Step 4: Configure Subagent and Actions

Step 5: Grant Agent User Permissions

Step 6: Test Your Agent

Step 7: Save, Commit & Activate

Agent Script Example:

Customer Support Agent Architecture

Agent Script Structure & Key Patterns

Agent Script Example:

The Problem & The Solution

When to Use (and Not Use) This Pattern

Setup: Org, Agent & Data Library

Create a Terminology Map with Knowledge

Create a Flow to Fetch the Knowledge Article

Update Your Agent: Variables, Actions & Instructions

Test & Verify the Terminology Solution

Agent Script Example:

When to Use This Pattern

How Routing & Step Variables Work

Try It Yourself & Related Patterns

📋 课程信息

🔗 相关链接