DEX801

课程介绍

同学们，大家好，我们接着来看今天这一页幻灯片，它讲的是 Enhanced Chat v2，也就是增强型聊天第二版。 咱们可以先把它理解成 Service Cloud 上面向客户的一个全新的聊天界面版本。原来我们也有 Enhanced Web Chat，就是增强网页聊天，而现在这个 v2，是在之前基础上的一个重大升级。它们俩有一个共同的目的，就是允许你把服务代理，比如真人客服，或者是咱们现在大力推广的 Agentforce 智能代理，连接并部署到外部的聊天渠道上。比如你的企业网站、移动 App，只要对方能接收聊天，就能把 Salesforce 里的客服能力搬过去。 那 Enhanced Chat v2 具体新在哪里呢？幻灯片里提到三点特别实用的能力。 第一，它支持使用自定义的 Lightning Types。这是什么意思呢？Lightning Types 可以理解成聊天窗口里的各种“零件”，比如按钮、输入框、头像这些组件。以前我们要修改聊天窗口的样子，挺受限制的，现在 v2 允许你自由地替换这些零件，用自己写的 Lightning 组件来定制界面，你想把聊天窗口打扮成什么样都行，更贴合品牌形象，也更灵活。 第二，它支持利用 utilAPI 里的 setSessionContent 方法，来发送上下文事件。听起来有点绕，其实很简单。很多时候，客户从你的商品页面点开聊天，你肯定希望客服或 Agentforce 马上知道他正在看哪款产品、甚至他之前有没有下过单。这个 utilAPI 就是一套工具方法，setSessionContent 可以在对话开始之前，把像“客户在浏览的商品ID、页面标题”这样的上下文信息，悄悄地传给聊天会话。这样一来，代理一接入就能看到客户在干嘛，不用再问“请问您看的是哪款产品”，省时又贴心。这就是所说的“上下文事件”，就是带着背景信息来触发聊天。 第三，内联模式的 UI 定制。原来的聊天窗口，多半是弹出一个浮动的气泡，或者一个新网页。而内联模式呢，能让你把聊天客户端直接嵌入到网页上某一个具体的元素里面，比如你专门设计了一个“联系我们”的版块，聊天框就像一张图片一样，嵌在那个格子里，跟页面融为一体。这就给前端设计师更大的发挥空间，让聊天体验更自然，不突兀。 所以总结一下，Enhanced Chat v2 就是让我们把服务代理部署到网站时，界面更可定制、传递客户信息更聪明、嵌入方式更灵活。无论是给人工客服用，还是给我们 Agentforce 智能代理来接待客户，它都能提供一个更加顺滑、个性化的体验。 好了，这一页就讲到这里。大家如果觉得这些能力在你们的场景里有帮助，下一节我们会聊聊具体的配置示例。

课程章节

本课程共有 9 个章节

• 1

  Context Events, Inline Mode & Lightning Types

  第 200 页

  来，我们看看这张幻灯片讲的是增强聊天v2的几个独特功能，这个版本相比之前，多了很多灵活的控制，能让你把聊天体验做得更贴合自己的业务场景。 先说第一个功能，是关于传递上下文事件的。你现在可以通过 utilAPI 里的一个新方法，叫 setSessionContent，把一些业务上下文传给聊天会话。比如用户正在看哪个订单、哪个客户，这些信息你都能实时传过去，这样 AI 在回答问题时就能直接引用，不用用户自己重复说。 第二个是内联模式。以前聊天窗口要么是一个浮动按钮弹出来的，要么是整个页面，现在你可以直接把聊天客户端嵌入到页面的某个元素里，就像嵌一个小组件一样。怎么实现呢？很简单，只要把显示模式设成 "inline"，再提供一个目标元素的引用，聊天界面就会在那个元素里渲染出来。这对于一些需要把聊天放在正文旁边、右侧栏，或者某个卡片里的场景特别有用。 这里有个小坑要注意：如果你打开控制台，看到一些配置相关的警告，就要检查一下。如果是内联模式，你得确保你提供了自定义的 targetElement；但如果你用的是浮动模式，就别多余地给它设 targetElement，否则会报错。简单说，就是不同模式对目标元素的处理不一样，别搞混了。 最后，还支持自定义 Lightning 类型，这让你可以用 Lightning Web Components 来完全定制聊天的外观。不再是千篇一律的白色聊天气泡，你可以根据自己的品牌风格，做出个性化的聊天界面，让用户体验更统一。 总结一下，增强聊天 v2 的核心就是更灵活——能传上下文、能嵌入页面、还能深度定制界面。这样一来，你就能把聊天功能无缝地融入你的应用里，不再像一块补丁。是不是一下子感觉开放了很多可能性？我们接下来再看看具体怎么用。

  ▶ 播放视频 查看详情
• 2

  Custom Connections

  第 201 页

  我们现在来看这一页，我尽量用大白话给你讲清楚。 你看，刚才我们说到 Agentforce 的代理，它可以跟用户对话。但是，如果这个对话不是发生在 Salesforce 自己的聊天窗口里，而是发生在我们自己公司做的 App、网页，或者一个定制的聊天界面里，那该怎么办呢？这个时候，就要用“自定义连接”。 简单说，自定义连接就是一座桥，专门让外部的 Web 客户端——也就是你自己的网站、手机 App 或者任何能联网的东西——跟 Agentforce 代理安全、顺畅地对话。 那具体是怎么做到的呢？关键是，我们要提前定义一种“基于元数据的连接”。别被“元数据”这三个字吓到。你只要把它理解成一份说明书就行。这份说明书告诉代理：“嘿，我这个客户端认识下面这几种结构化的回复格式。” 举例子，比如你的客户端能展示一个“旋转木马”卡片，或者一种叫“拾取器”的选项列表，又或者是一张表格。你就在说明书里把这些格式定义好。然后呢，代理在回答用户的时候，就会专门生成符合这些格式的 JSON 数据。JSON 就是一种轻量级的数据交换格式，你可以把它想成是给机器看的、结构清晰的文字。这样你的客户端拿到 JSON 后，就能直接用本地的原生 UI 组件把内容渲染出来，比如真的画出一个漂亮的卡片、一个轮播图，而不是只出现一段干巴巴的文字。 这样做的好处非常明显——完全掌控客户端的体验。你想把聊天窗口做成什么样子，就做成什么样子；你想让回复以什么形式呈现，只要你的客户端支持，你都可以提前定义好。 那什么时候该用自定义连接呢？我总结一下，就是当你想要： 第一，在自己的服务器或基础设施上托管这个聊天界面； 第二，想让 Agentforce 的回复变成你 App 里的原生 UI 组件，比如卡片、表格、选择器，而不仅仅是文本泡泡； 第三，完全掌控用户在这个交互过程中的每一处视觉和体验。 这些情况下，自定义连接就是你的最佳选择。它把代理的智能对话能力，和你在自己产品里能做到的丰富界面表现力，完美地结合了起来。 好，关于这一页的内容，我就讲这么多，是不是挺清楚的？

  ▶ 播放视频 查看详情
• 3

  How Custom Connections Work

  第 202 页

  好，我们来看看在Agentforce里做自定义连接的时候，你会碰到两种用来描述输出的元数据类型，它们就像两张不同的说明书，告诉代理该怎么把结果整理好给你。 第一种叫AiSurface。它用自然语言的高级指令，再加一个对响应格式的引用，来定义整个连接。你可以理解成，你只是用说话的方式，说“我要一个这样的结构，里面包含名字、金额和日期”，然后它就去做了。 第二种叫AiResponseForm。这个就更具体了，它是用SON（也就是一个结构化的格式定义），把输出的模式非常明确地写出来，像个严格的模板。 那代理在回复的时候，到底选哪一种格式呢？这里有个有意思的点：代理的决定是不确定的。它不是按固定规则去选的，而是根据你给它的描述和指令，用自然语言理解之后，自己判断“这个情况用AiSurface更合适，那个情况用AiResponseForm更合适”。你可能会设一个sortOrder，觉得把它排前面就先选它，但sortOrder只是一个影响但不强制的优先级，所以你不能完全依赖它的顺序。 这带来的一个重点就是——你永远要处理后备情况。万一代理没选某种格式，你得有准备。在客户端代码里，你发起一个Agent API会话调用时，要传一个叫做surfaceSwitch的东西。拿到响应以后，你要去看它的结果数组，试着提取result[0].Value，然后把它当成JNON来解析。如果这个解析成功了，说明代理用了一种格式化的输出；如果不存在，或者解析不了，那你就安稳地退回到普通的纯文本消息字段，用那个当后备。 简单总结就是：两种卡片让你自定义输出结构，但代理会自己挑，你不能硬性控制，所以写代码的时候，先试着读结构化数据，读不到就拿纯文本兜底。这样你的应用就稳了。

  ▶ 播放视频 查看详情
• 4

  Set Up a Custom Connection

  第 203 页

  同学们，今天咱们来聊聊怎么给 Agentforce 设置自定义连接。这就像你要让咱们的 AI 代理能跟外部的系统说上话，比如连上你公司自己的后台，或者一个第三方的聊天工具。要做到这个，咱们得先创建三个“元数据零件”，缺一不可。 第一个零件叫 ，AiSurface，，你可以把它想成是连接配置的容器，里面定义了代理要跟哪个外部服务打交道，比如那个服务的网址、认证方式这些信息。它就像一座桥的桥墩，把两头给固定住。 第二个呢，叫 ，AiResponseForm，。当外部系统返回数据的时候，数据可能有各种格式，有的是简单的一段文字，有的是一串清单。这个 AiResponseForm 就是用来告诉代理：“嘿，对方回给你的数据是这个结构，你得按这个规矩去读，然后再整理成用户能看懂的样子。” 每一种不同格式的输出，你都得单独定义一个 AiResponseForm。它好比是我们提前给代理准备好的翻译说明书。 第三个零件是 ，GenAiPlannerBundle，。这个名字听起来有点复杂，其实就是把前面那两个零件给捆在一起，再指派给具体的代理。这样一来，代理就知道自己现在具备了这个新连接的能力，遇到相关问题时，会自动去调用那个外部服务。它就是让代理跟连接真正产生关联的“牵线人”。 有了这三个零件，桥才算搭好了。但在动手搭之前，咱们得确认几个前提条件，就像盖房得先打好地基一样： 第一，你的 Agentforce 环境必须已经开通了 ，代理 API 的连接能力，。也就是说，得确保代理能往外发请求，而不会被困在 Salesforce 里头。 第二，你那边得有一个实实在在在运行的 ，外部客户端应用程序，。桥的另一头得真的有个服务在等着，对吧？哪怕是个简单的测试接口都可以。 第三，开发的时候要注意，你使用的 ，元数据 API 版本必须是 66.0 或者更高，。因为只有从那个版本开始，Agentforce 才能识别并正确处理咱们刚说的那三种新元数据类型。版本太老的话，部署的时候会直接报错。 简单总结一下：要自定义一个连接，咱们得按顺序准备好 AiSurface、AiResponseForm 和 GenAiPlannerBundle 这三个元数据，同时确保环境、外部应用和 API 版本都满足要求。这样，代理才能安全、聪明地跟外部世界互动起来。 好了，这些就是今天这页内容的要点，大家先消化一下。有疑问随时提出来。

  ▶ 播放视频 查看详情
• 5

  Metadata Structure & Directory Layout

  第 204 页

  同学们，我们来讲讲怎么在标准的未打包目录结构里，把我们的生成式AI相关的元数据组织好，然后部署到Salesforce里。 首先，你可能会看到一些元数据文件名后面跟着一个奇怪的{suffix}，也就是后缀。这个后缀是干啥用的呢？它是用来唯一标识你的连接，还有连接的格式。你可以自己随便起一个后缀，只要唯一就行，或者更简单的是，在你用元数据输出功能生成文件的时候，它会自动帮你生成一个后缀，你直接拿来用就行了。 接下来，我们要在Package.xml这个清单文件里声明哪些元数据要部署。这里面你要写上三种类型：AiSurface、AiResponseForm，还有可选的GenAiPlannerBundle。记住，后两个名字可能有点长：AiResponseForm是响应格式，GenAiPlannerBundle是生成式AI规划器的捆绑包，它是可选的，如果你不用就可以不声明。 那部署的时候有个非常重要的顺序，你千万不能弄错：永远要先部署AiResponseForm，然后再部署AiSurface。为什么？因为AiSurface会引用响应格式，如果AiResponseForm还没部署上去，AiSurface跑起来就会找不到它，就像你先穿鞋再穿袜子，别搞反了。 当你把所有文件都准备好、放到正确的目录里，在项目根目录下运行那个命令： sf project deploy start ，它就会一股脑把整个包里的东西全部署上去。 如果以后你想更新某个定义，比如改了AiSurface的提示词或者AiResponseForm的格式，你不需要删除再重建，直接用相同的开发者名称（Developer Name）重新部署一遍就行。Salesforce会自动用新的定义把旧的替换掉，就像你保存一个新版本的文件，覆盖旧的。 好了，简单回顾一下：后缀自己选或用自动生成的；Package.xml里声明AiSurface、AiResponseForm，可选GenAiPlannerBundle；部署先部署响应格式再部署表面；更新就重新部署相同名称。清楚了吗？我们继续下一部分。

  ▶ 播放视频 查看详情
• 6

  AiSurface & AiResponseFormat Reference

  第 205 页

  好，我们来看这一页内容。它讲的是 Agentforce 里面的 AiSurface，你可以把它理解成“对话界面”的定义方式，专门用来和大模型做交互的。 首先，AiSurface 通过一些高级指令来决定整个对话的风格和行为，比如语调该是什么样的、回复的长度有没有限制、什么时候该跳过某些格式化的输出。每个指令都有一个 sortOrder 值，数字越小越先被送给大模型。这个顺序会影响大模型的倾向，但并不是硬性规定，更多是做个引导。 接着是 responseHandler，它通过开发者名称去引用一个叫 AiResponseForm 的实体。要注意，只有这个实体的启用标志打开时，引用才会生效。那 AiResponseForm 是什么呢？它里面有一个描述字段，这个描述不是给你我这样的人类看的，而是让代理自己去判断，在什么场景下应该选用这种响应格式。所以写的时候，你要像写选择逻辑一样去思考，而不是用大白话说明。 AiResponseForm 还带一个输入字段，那里放的是一个 JSON 模式，用来定义期望的数据结构。不过平台不会严格强制你的输出必须完全匹配这个模式，这就给了我们一些弹性。 最后，怎么把 AiSurface 这个连接跟你的代理关联起来呢？你需要在代理的 GenAiPlannerBundle 里添加一个 plannerSurface 条目，把表面名称填好，并且把表面类型设为“自定义”。这样就绑定好了。 所以这一页的关键就是：AiSurface 管连接、管指令；AiResponseForm 管什么时候用什么格式；最后在规划器里把它跟代理挂上。好，我们记住这几点就行。

  ▶ 播放视频 查看详情
• 7

  Use, Parse & Test Custom Connections

  第 206 页

  同学们，我们来看一下这个自定义连接怎么用。别被那些术语吓到，其实很简单。 想象一下，你在Agentforce里调用外部服务，返回的数据格式五花八门。如果我们想让AI理解，就需要告诉它该用什么“格式”去解析。这个“格式”就是所谓的，表面类型，，这里我们要用的是定制类型，也就是`custom`。 具体怎么做呢？在你的代理API初始化时，配置项里要加上这种表面配置。当你收到响应后，代码会去结果数组里找数据。如果存在结果数组，就读取每个结果的`type`字段。注意，这个字段的值通常带有`SURFACE_`前缀，比如`SURFACE_json`，你把它前面的`SURFACE_`去掉，剩下的就是格式名称，比如`json`。接着，把结果的`value`字段解析成SON对象——别担心拼写，其实指的就是JSON。这JSON字符串必须正确转义，不能有未处理的引号或反斜杠，否则解析会失败。 有个很重要的点要记住：平台不会强迫你严格遵循某个模式，所以，你必须自己在结构化输出客户端做验证，。也就是说，你不能完全依赖平台来保证返回数据的格式完美，得自己检查一下。 测试的时候，最好用沙盒或临时组织（Scratch Org）来试。主要验证两个路径：一是格式成功应用，AI正常处理了数据；二是如果用户没选格式，或者输出格式错误，你的后备逻辑要能顶上去，给出合理的响应，而不是直接报错。 这样讲是不是清楚多了？我们一步一步来，先配置，然后解析时去除前缀，再验证，最后做好测试。有问题随时问！

  ▶ 播放视频 查看详情
• 8

  Response Format Examples

  第 207 页

  好，我们来看这页Slide，它提到了响应格式设计的三个典型示例，还有设计技巧和故障排除的参考。你可以把它们当成一个模板库，在你创建自己的AiResponseForm时，随时拿来做起点。 这三个示例分别是：文本选择、图像选择，还有时间选择器。换句话说，就是用户在和Agentforce交互时，可以用点选文字的方式做决定，或者挑一张图片来确认信息，又或者通过一个很方便的时间控件来选日期时间。这些不只是静态的展示，而是可以交互的表单组件。 Slide还强调，当你自己去设计响应格式的时候，别从零开始凭空琢磨。直接参考这几个现成示例，看看人家的结构、字段怎么设置，快速起步。如果过程中遇到问题，后面还贴心地给出了故障排除的参考，帮你少走弯路。 所以，这页其实就是给你一把钥匙，告诉你：设计交互式响应，不用怕，已经有经典的范例了，拿过来改一改，就能适配你的业务场景。

  ▶ 播放视频 查看详情
• 9

  Example Response Formats & Design Tips

  第 208 页

  咱们今天来看一下Agentforce里常用的三种响应格式模式。简单说，就是你可以让助手用三种方式来跟用户互动，让体验更顺手。 第一种，是，简单菜单的文本选择，。就是给用户2到7个选项，比如“你想查什么？1. 订单状态 2. 退换货 3. 人工客服”，用户只要输入数字或点一下就行。这个特别适合选项不多、不需要花哨界面的场景。 第二种，是，带图像的选择，。比如产品列表、虚拟形象选择，给每个选项配一张小图，用户一眼就能认出来。这适合视觉任务，像挑衣服款式、选头像，比纯文字直观多了。 第三种，是，时间选择器，。它遵循 Slack Block Kit 的语法，让你直接弹出一个日历控件，用户选日期时间很方便，不会因为格式输错来回扯皮。 设计的时候记住几点技巧： - 每个连接的选项，别超过7个，，太多容易选错，也显得乱。 - 写选项描述时，要专门，从助手的逻辑出发，，而不是写给人看的通用介绍。比如写“识别订单状态查询的意图”而不是“这里可以查订单”，这样LLM更能准确理解。 - 如果你需要特定的输出结构，可以直接用LLM帮你，生成JSON schema，，省得自己手写还容易出错。 最后，我们整理了一个故障排除表，聚焦最常见的五个坑： 1. ，无效的JSON，——格式写错了，解析失败。 2. ，缺少引用，——某个元素没被正确关联，报了错。 3. ，部署顺序，——东西没按顺序上线，导致依赖找不到。 4. ，类型不匹配，——比如该给数字的地方给了字符串。 5. ，会话调用中缺少表面配置，——在对话界面调用组件时，没配置显示规格。 遇到问题先对着这五个查，大部分都能快速定位。好，这个知识点就讲到这里，下一步我们看看怎么把这些模式用到实际对话流里。

  ▶ 播放视频 查看详情