ADG001

课程介绍

好，我们这节课来聊聊怎么把你自己写的Apex代码，变成Agentforce里一个聪明的“动作”，让代理可以自动调用它。这个过程中最关键的一个注解，叫 `@InvocableMethod`，可以理解成：它就是给方法贴上一个“代理可调用”的标签。 你想想，代理得知道它能做什么对吧？所以我们在一个静态方法上面写上 `@InvocableMethod`，然后给这个方法起一个好懂的标签（label）和描述（description）。这个标签和描述特别重要——代理就是靠读这两样东西来理解：“哦，这个方法什么时候该用？它是干嘛的？” 举个例子，假设你要做一个“查询天气”的动作，你可以把标签写成“获取指定城市的天气”，描述里再写清楚“输入城市名，返回实时天气信息”。这样代理在处理用户请求时，一旦判断需要天气信息，就会自动调用你这个方法。 接下来，既然是给代理用的，就得告诉它输入是什么、输出是什么。你不能用随意的方法参数，而是要专门定义一些内部类，里面的每个字段都要加上 `@InvocableVariable` 注解。同样，每个字段也要有描述，这样代理才知道“这个字段是放城市名的”“那个字段是存放温度的”。 有一个小坑要特别留意：就算你的方法一次只处理一条记录，接收和返回的也必须是，列表类型，，比如 `List<String>` 或者 `List<MyOutput>`。这是平台的要求，别写单个对象，不然会报错。 总结一下：标签和描述是成败的关键，它们是让代理“看懂”你代码的唯一线索，写得越清晰，代理调用起来就越靠谱。如果你打算做生产级的 Apex 操作，一定要去看一下官方开发博客上关于最佳实践的文章，里面有很多避坑指南和性能优化技巧。 好了，现在你应该明白 `@InvocableMethod` 是怎么把 Apex 方法和代理连接起来的了。下次课我们会看一个完整的小案例，把整个过程串一遍。

课程章节

本课程共有 14 个章节

• 1

  Customize UI with Lightning Types

  第 230 页

  同学们，咱们这一页来看看 Agentforce 里的 Lightning Types。别被名字吓到，其实它很好理解。 简单说，Lightning Types 能让你自己打造的 Lightning 网页组件，去替换掉 Agentforce 里原本默认的那个操作界面。但它有个前提，只对那种用 Apex 类实现的操作管用。你想想，如果你想让用户跟你的智能体互动时，不光是看见干巴巴的文字，而是享受到你们品牌专属的体验，这就派上用场了。 来，我举个小例子你就明白了。比如原来一个航班的搜索结果，返回的可能是一堆杂乱无章的文本，用户得瞪大眼睛找半天。现在，你用 Lightning Types 就能把它摇身一变，做出一个清清爽爽的布局：最划算的票价直接高亮出来，再配上一个特别显眼的“立即预订”按钮。你看，这样子多棒，体验一下子就不一样了。 那怎么去实现它呢？这边给了好几条路，你挑最适合自己的。首先最简单的一条，你可以直接在设置 UI 里进行构建，拖拖拽拽就搞定。如果你想了解得更深一些，想摸清它底层是怎么跑的，那可以去钻研它的体系结构，获得更深入的知识。从技术路线上，你还能选基于 Apex 或者 JSON 模式的方法来定义类型。对了，更酷的是，你还可以在 Agentforce Vibes 里利用人工智能技能，通过自然语言让 AI 辅助你生成这种 Lightning 类型的技能。当然啦，如果你是程序员，喜欢代码掌控一切，那也能通过元数据 API，以编程的方式直接部署。 最后得提一下，无论你用哪种方法，最终都会落在一个叫做 LightningTypeBundle 的元数据类型上，就是它来定义你这个自定义的类型。好了，Lightning Types 的概念和路径，是不是就清晰多了？

  ▶ 播放视频 查看详情
• 2

  Lightning Types in Agent Actions

  第 231 页

  来，我们一点一点看这个标准Lightning类型，它在Agentforce代理操作里是怎么工作的。你其实可以把它想象成一套自动化的翻译和组装流程——它帮我们把枯燥的Apex数据类型，直接变成用户可以看、可以用的界面组件。 整个过程分成五步，很简单，我带你走一遍： 第一步，先是做，映射，。你的Apex代码里定义的数据类型，比如字符串、日期、数字、列表之类的，Agentforce会自动识别，然后把它们对应到它内建的一套标准Lightning类型上。这一步你不用写界面代码，系统自己就认出来了。 第二步，每个类型都有一个，验证规则，。其实就是在类型背后绑定了一个校验模式，比如字符串可以限制长度，邮箱可以校验格式，日期可以校验范围。这样数据一进来，就自动经过一道检查，保证它符合要求，不用你额外写一大堆判断。 第三步，，自动生成UI组件，。这是最省事的地方——看到“长文本”，它就给你渲染成一个多行文本输入框；看到“日期”，就弹出一个日期选择器；看到“集合”或者“列表”，它就呈现为列表组件。全部是Salesforce自动完成的，你只要关心数据类型就行。 第四步，生成出来的这些组件要通过，渲染器，展示。渲染器负责把结构化数据安排好，让它们该长的长，该短的短，该弹出日期的弹出日期，该列表的就展示成条目。这样到了界面上就一目了然，而且表现得很自然。 第五步，所有这些开箱即用的组件，基本都能以，最小配置，覆盖大部分常见用例。也就是说，你不用写一行前端代码，就能满足绝大多数业务场景。这在项目里能节省大量时间。 我们来看两个具体例子，更容易理解： - ，“汇总记录”， 这个例子：它可能会把一组数据进行汇总展示，比如显示总金额、记录条数。Agentforce会根据数据类型自动选用数字、文本或货币组件来呈现，整个过程就套用了上面那五步。 - ，“按名称识别对象”，：比如你通过名称查出了一条记录，它就会自动把记录的关键字段渲染成规范的UI，姓名是文本，创建日期是日期选择器，相关列表也自动列出来。你看，标准类型的威力就在这里。 那么如果你要集成自己定制的Lightning类型，该怎么办呢？也很直接——你只需在代理操作里，去编辑它的，输入渲染参数，或，输出渲染参数，。就是把你想用的自定义组件，指定到对应的输入或输出上，替换掉默认的生成逻辑。这样既保留了自动化的便利，又给了你足够的灵活性。 简单总结：标准类型就像一个贴心的自动装修队，你告诉他数据类型，他帮你砌墙、拉电线、选好家具，最后你只要拎包入住。要改动某个地方，直接告诉工头改参数就行。 这样一来，是不是觉得这五步流程很清晰了？以后你在构建Agent action的时候，可以充分依赖这套机制，先让标准类型跑起来，遇到特殊需求再动一下渲染参数，既快又稳。

  ▶ 播放视频 查看详情
• 3

  Flight Booking Example:

  第 232 页

  同学们，今天我们来看一个非常实用的例子，就是怎么样用自定义的Lightning组件，来把我们Agentforce里自定义操作的界面，做得更漂亮、更符合需求。 很多时候，Agent默认生成的输入输出界面可能比较简单，比如就是一些基本字段。但你可以完全重写它！我们这里就拿一个“查找航班”的例子来说。 假设我们已经有了一个Apex类，叫FlightAgent，它里面有个方法能根据出发地、目的地、出行日期这些信息，返回可用的航班列表。那默认情况下，用户可能就要在几个输入框里干巴巴地填数字、填日期，输出也就是一段文字。体验不好。 那我们怎么做呢？我们会创建两种自定义的Lightning类型。 第一种，叫做flightResponse。它是用来美化输出结果的。你想啊，查出来的航班信息，如果只是文本多无聊。我们把它变成一个漂亮的卡片布局，上面有航班号、时间、价格，看起来就像你在旅游App里订票一样清晰。 第二种，叫做flight滤镜。听名字就知道，它是给输入界面用的。默认可能就是两个数字框让你填最高价格、最低折扣，但我们可以把它变成带有漂亮标签的表单字段，甚至加上滑动条、提示文字，让用户输入起来特别舒服。 这样，整个操作的用户体验就大大提升了。用户输入的时候，看到的是你精心设计的表单；看到的结果，是色彩丰富的航班卡片。这就是用自定义Lightning类型重写Agent动作界面的魅力。 那在Agentforce的配置里，你只要把这些自定义类型关联到对应的操作上，就能生效。大家下课后可以自己试一下，动手做一个简单的组件来替换默认界面，这对你们以后做项目特别有帮助。 好，关于这个例子就讲到这里。我们继续看下一个Slide。

  ▶ 播放视频 查看详情
• 4

  Apex Classes for Flight Agent Action

  第 233 页

  好，我们来看这一页的内容，它讲的是一个叫做FlightAgent的类，这个类用到了一个非常实用的注解，叫@InvocableMethod。这个注解的作用就是把这个类里的一个方法公开成一个可以被调用的“操作”，这里操作的名字叫“Find Flights”，就是查找航班。 简单来说，当你把这个类部署到Salesforce之后，在流程生成器、Flow或者审批流程这些地方，就能直接调用这个查找航班的功能，不需要再写额外的代码。 那这个方法需要什么输入呢？它需要一个叫FlightDemand的对象，里面包含了出发城市、目的地城市、旅行日期，还有一些可选的过滤条件，比如你能接受的价格范围和折扣百分比，这样你就可以灵活筛选。 那它返回什么呢？它会返回一个叫FlightResponse的包装对象，里面又包了一个叫DeliverableFlight的对象，这个DeliverableFlight里有一个航班记录的列表。每一个航班记录里都有航班ID、中途停留次数、宠物政策、价格、折扣百分比和飞行时长这些信息。 这个演示里面，为了让你马上能看到效果，它直接在代码里硬编码了四个航班的数据——也就是说，没有真的去调用外部系统，只是用一些假数据来展示功能。但在真实的生产环境里，这些数据肯定要从外部服务获取，比如调用航空公司的接口。 那最后还提到了一个FlightDelivest滤镜，它允许用户按照价格和折扣百分比去筛选结果。这个名字听起来可能有点模糊，其实它就是输入参数里那个可选过滤器的一个体现，让你在调用这个操作的时候能灵活地只看符合预算的航班。 所以这一页就是在告诉你：怎么用@InvocableMethod把一个查找航班的功能包成一个可复用的操作，定义了清晰的输入输出结构，再用几个示例数据展示效果。这样，不管是在自动化的流程里，还是在别的地方，都能方便地使用这个航班搜索能力。 好了，这一页的重点就是这样，有问题可以随时问我。

  ▶ 播放视频 查看详情
• 5

  Create Agent Action & Default UI Issues

  第 234 页

  好，同学们，我们来看这个幻灯片讲的一个常见问题。你刚用FlightAgent类创建了一个代理操作，对不对？但是默认的界面非常糟糕。输入那边，只显示了基本字段，那些可选的过滤参数，像价格和折扣百分比，都被藏起来了，用户根本没办法筛选航班。输出那边就更头疼了，直接给你显示原始的SON数据，什么格式都没有，没有标签、没有视觉结构、没有卡片、也没有样式。这体验，用户一看就懵了。 那我们的目标是什么？就是要创建两种自定义的Lightning类型，来彻底改变这个情况。一种类型用来处理输出，让航班信息显示在漂亮的卡片布局里，清晰又美观。另一种类型用来处理输入，让价格和折扣百分比这些字段明明白白地标出来，用户一眼就能看到并填进去。 这样，我们就能把用户体验从那种令人困惑的原始数据，变成一个精致、专业的界面。这就是我们要做的，很简单吧？

  ▶ 播放视频 查看详情
• 6

  Customize Output UI: flightResponse CLT

  第 235 页

  同学你好，今天我们来继续聊聊 Agentforce 中一个非常实用的小技巧——如何把后台返回的航班数据，用我们自己设计的精美卡片展示出来。也就是定制那个 flightResponse 的输出渲染。别担心，我一步步用最直白的话讲给你听。 首先，我们要明白，Agentforce 对话结束时返回的数据，默认就是一个干巴巴的文本。比如你问“我下周一从伦敦飞东京有哪些航班”，它返回的数据可能就是一堆 JSON。用户看了肯定头疼。所以我们需要做一层“美颜”，把原始航班数据变成一个漂亮的卡片，有折扣、时间轴、宠物政策这些信息，让用户一眼就能看清。 这个过程靠什么实现的呢？就是通过一个自定义的 Lightning Web 组件（我们叫 LWC）来“接管”这个数据的渲染。这个组件名叫 flightDetails。 我们分三步来走通整个流程： 第一步，让系统知道我们要输出一个叫 flightResponse 的自定义类型。在 Salesforce 里，我们要建一个 schema.json 文件，里面引用一个 Apex 类的类型。你可以把它理解为：给这个“航班回复”的消息结构下个定义，告诉系统它长什么样。这样 Agent 的动作输出就可以声明为 flightResponse 类型。 第二步，在 Lightning Desk 的 GenPi 通道文件夹里，我们再放一个 renderer.json 文件。这个文件很关键，它就像是一个“指路牌”，说：“嘿，当遇到 flightResponse 这种输出时，别用默认的渲染，要用我指定的那个 LWC 组件，它叫 c/flightDetails。” 这里的 c 是默认命名空间，flightDetails 就是我们自己写的组件名。 第三步，就是写那个 flightDetails 组件本身。这个组件是针对 lightning__AgentforceExit 这个目标去设计的，意思是它会嵌在 Agentforce 对话结束的那个区域里。这个组件拿到后台传过来的原始航班数据 JSON，然后做几件贴心的事： - 它会用 JavaScript 把持续时间格式化，比如把分钟数算成“2小时30分”，并且根据起飞时间加上持续时间，算出预估到达时间。 - 它把这一堆原始数据变成一张视觉上很舒服的卡片布局，上面会有：航班 ID、折扣百分比、价格、飞行的总时长、出发和到达的时间轴（就是那种起点终点连线的样式）、中转停留次数，还有这趟航班允不允许带宠物。 - 最后用漂亮的 CSS 样式展现出来，让用户一眼就抓住重点。 那么，我们怎么把这一整套集成到 Agent 的动作里呢？很简单，你找到你 Agent 里那个叫 aFlight 的字段，在它的动作输出渲染参数里，编辑一下，选择 flightResponse 作为输出类型。这样，动作一执行，Agent 就知道：“哦，返回的数据是 flightResponse 类型，我要按照之前 renderer.json 的指引，用 flightDetails 这个组件去渲染它。” 这里还有一点小小的注意事项：你在配置的时候可能会看到一个黄色的警告，写着“不支持的数据类型”。很多同学一看到警告就紧张，但这个其实是纸老虎。它是因为你在引用自定义类型（比如我们定义的 flightResponse，它底层是基于 Apex 类的），平台在编译时暂时没有识别到具体的定义，所以打一个无害的警告。它完全不影响功能，你只管忽略它，继续保存就行。我们的组件和渲染都能正常工作。 所以总结一下：想给 Agentforce 回答加个个性化的卡片，你要做的事情就是：定义类型（schema.json）→ 指定渲染组件（renderer.json）→ 写好那个负责美化数据的 LWC 组件 → 最后在 Agent 的动作输出里挑选这个类型。一步不少，但一步也不难。 好了，今天这个 custom output renderer 的小课堂就到这里。有什么不明白的，随时来问。我们下次再见！

  ▶ 播放视频 查看详情
• 7

  Customize Input UI: flightFilter CLT

  第 236 页

  好，我们来看这一页——它讲的是怎么用自定义的 Lightning 组件来覆盖 Agentforce 里“flight 滤镜”默认的输入界面，从而让用户能更精确地输入价格和折扣百分比，同时还能把数据实时传回背后的规划器。 咱们一步步拆开讲。 首先，在 Salesforce 里，Agentforce 的“flight 滤镜”原本可能只是一个简单的文本输入框，用户在里面打字。但既然是“滤镜”，我们更希望它是一个结构化的表单，比如有两个数字输入框：一个让你填价格，一个让你填折扣。这就需要用到“自定义 Lightning 类型覆盖”。 所以这个地方就用了一个 ，editor.json， 文件，把 `c/flightDeliverFilter` 这个 Lightnig Web Component（LWC）指定为滤镜的编辑器组件。意思是：“Agentforce，当你要显示航班过滤条件的时候，不要用默认的文本框，而是用我这个专门的 LWC 组件。” 这个 LWC 组件名字叫 `flightDeliverFilter`，它被绑定到 `lightning__AgentforceInvestment` 这个对象上，并且提供了两个带标签的数字输入框： - ，Price（价格），：可输入范围 1000 到 20000 - ，Discount Percentage（折扣百分比），：可输入范围 0 到 100 那最关键的部分是什么呢？是 ，数据怎么实时交互，。这里用了一个很重要的模式：，`DeliverInputChange()` 方法，。 每当用户在输入框里改动数值，这个方法就会被触发。它会做两件事： 1. 更新组件内部的状态，让它及时反映最新的输入。 2. 更关键的是——它会`dispatch`一个自定义事件，叫做 `valueChange`，也就是“值发生了变化”。 这个事件会被“父规划器组件”监听到。所谓父规划器，可以理解成 Agentforce 后台那个负责接收过滤条件、做出计划和推荐的智能体。父规划器一旦收到这个事件，就能马上拿到最新的价格和折扣值，不需要等用户额外点“提交”按钮。这就实现了，实时数据绑定，，交互体验会更流畅。 最后一步，也是容易被忽略的一点：，集成完成后，一定要记得更新子代理的指令（Subagent Instructions），。因为原来 LLM（大语言模型）可能被教导成“当用户说要筛选航班时，就收集一段文本描述作为过滤条件”，但现在过滤条件是通过 UI 表单输入的，是结构化的数字。所以必须告诉 LLM：现在要“使用表单里填好的价格和折扣来过滤”，不要再让用户用自然语言说一遍“我要价格在 5000 以内、折扣 20%”了，否则它会搞不懂为什么还要问一次，甚至可能和表单数据冲突。 简单总结一下这页的内容：我们通过 `editor.json` 指定一个自定义 LWC 作为 flight 滤镜的 UI，用数字输入代替文本框，并在 LWC 内部通过 `DeliverInputChange()` 方法触发 `valueChange` 事件，实时把数据传给后台规划器。最后再调整一下子代理的提示词，让 AI 真正理解怎么用这个新 UI 工作。 这样讲，是不是就清晰多了？如果哪儿还不清楚，随时打断我。

  ▶ 播放视频 查看详情
• 8

  Before & After: Custom Lightning Type UI

  第 237 页

  同学你好，今天这一页我们讲的是定制Agentforce界面时的“戏剧性转变”。你来感受一下这个对比，就能明白为什么我们要花时间学这些模式。 想象一下，如果我们不做任何定制，Agentforce默认显示出来的内容，比如一个航班查询结果，是什么样的？它可能是一大段原始的JSON，密密麻麻的代码，用户根本看不懂，也操作不了。比如，航班信息、折扣、价格这些都堆在一起，没有重点。而输入那边的筛选条件呢，默认也是完全隐藏的，用户根本不知道能怎么查。 但是一旦我们用今天讲的方法定制之后，整个体验就完全不一样了。输出的航班结果会变成一张张漂亮的卡片——有清晰的标签，比如“出发”、“到达”，折扣会用一个醒目的折扣标签展示出来，价格用粗体突出，甚至还有一个小时间轴，直观显示出发和到达的时间流动。用户看一眼就知道这趟航班划不划算。输入侧也不再空白，而是出现一个规整的表格，里面标好了“价格”和“折扣百分比”这样的输入框，框上还有合适的约束，比如只能填数字、范围限制等。这就是我们说的“戏剧性转变”。 好，为了让这样的转变发生，你得记住背后几个关键的模式。我把它们串起来讲，帮助你记忆。 第一，关于Schema.json文件。我们要引用Apex里定义的类型，写法有一个特殊的前缀：`@apexClassType/c__ClassName`，这里的`ClassName`就是你Apex里那个类的名字。这样Agentforce就知道你的数据长什么样。 第二，Renderer.json文件。这是控制怎么“画”出界面的。记住使用`componentOverrides`对象，然后在里面用`$`作为根重写键。`$`代表根级别，表示你要替换掉整个默认的渲染组件，换成你自己写的那个。你的自定义LWC组件就是挂在这里的。 第三，Editor.json文件。它遵循跟Renderer类似的输入模式，也是用`componentOverrides`和`$`这个根键，只不过它是控制输入表单的展示。所以当你想自定义输入的表格时，也是遵循这个模式。 第四，最重要的一个易错点——LWC组件的meta文件。你一定要在`target`里正确声明。如果你自定义的是出口组件（就是显示结果的组件），Target要用`lightning__AgentforceExit`；如果是入口组件（用来输入的），要用`lightning__AgentforceInvestment`。而且必须对应好`sourceType`和`targetType`，让它们匹配才能绑定成功。很多同学在这里会搞混，导致组件不生效，一定要细心。 简单总结一下，想让你的Agentforce“换装”成功，就记住：Schema里用`@apexClassType/`引用类型；Renderer和Editor用`componentOverrides`加`$`根键去替换；LWC meta里认准AgentforceExit和AgentforceInvestment这两个目标，别写错也别混用。 这样你就能把原本生硬原始的数据，变成用户一眼就爱上的交互卡片了。接下来我们动手试试看，你准备好了吗？

  ▶ 播放视频 查看详情
• 9

  Hotel Booking Example:

  第 238 页

  来，咱们今天聊一个很实用的模式，叫“顶级集合渲染器覆盖”。先别被名字吓到，其实它的作用特别直观：当你在 Agentforce 里调用一个代理操作，返回的是一串东西，比如酒店列表，默认显示可能就是一行行的文字，没什么设计感。那这个模式就是让你可以自定义这个列表的整体外观，一次性重写整个集合的渲染方式。 相比咱们之前看的飞行示例，那个是给单个项目的编辑器和渲染器分别重写。而这次不同，我们直接对整个列表下手，一次性把它整成带样式的卡片形式。 具体怎么做呢？咱们先假设有一个叫 HotelReservation 的 Apex 类，它能查到可用的酒店数据。然后，我们再建一个自定义的 Lightning 类型，名字可以是 hotelResponse。在这个自定义类型里，我们把拿到的酒店列表，用漂亮的卡片样式渲染出来。结果就是，用户在聊天界面里看到的，不再是一堆枯燥的文字，而是一张张清晰美观的酒店卡片，比如有图片、价格、评分，一目了然。 总结一下，顶级集合渲染器覆盖，就是当你想改一整个列表的输出形式时，直接重写整个集合的渲染逻辑，用自定义的 Lightning 组件来实现。这样既高效，又能让输出界面更友好。好，这部分就讲到这里，有问题随时提。

  ▶ 播放视频 查看详情
• 10

  Apex Classes for Hotel Agent Action

  第 239 页

  好，咱们来看这个酒店预订的例子。 在 Salesforce 里，我们用一个叫 `HotelReservation` 的类，通过 `@InvocableMethod` 注解，向外公开了一个叫“查找酒店”的操作。这个操作使用起来特别简单——你只需要告诉它三个信息：城市、入住日期和离开日期。 那它会返回什么呢？会返回一个 `HotelResponse` 对象，里面包含一个酒店列表。每个酒店都有自己的名称、地址、星级，以及一个“可用房间”的列表。而每个房间对象又详细描述了房间类型、还剩多少间可用、有没有折扣、具体价格，以及允不允许带宠物。 为了演示方便，代码里硬编码了两家酒店的数据，这样我们就能马上看到效果，不用真的去连外部系统。 这里要提醒大家注意一个和前面航班示例不同的关键点：在这个酒店的例子中，返回的结果是一个，酒店列表，，而不像之前航班示例那样只是单个结果。既然是一次返回多条酒店记录，如果我们想让每条酒店都按照自己想要的样式来显示——比如展示星级、把房间列表折叠展开——就需要用到 ，集合渲染器覆盖， 。 集合渲染器覆盖的作用，就是允许我们完全控制列表里每一项的渲染方式，不再使用 Salesforce 默认的列表外观。我们可以设计一个自定义的布局，让每个酒店项目都清晰地展示出名称、星级图标、可用房间的详情，甚至给折扣高的房间加上醒目标识。 这样一来，用户面对一个多酒店的搜索结果，就能一目了然地比较各个选项，做出更好的选择。 这就是酒店这个 Action 的设计思路，以及它与单结果场景最大的结构差异。大家理解了吗？

  ▶ 播放视频 查看详情
• 11

  Default UI & Result Data

  第 240 页

  咱们接着来聊酒店查找这个例子。你看，它的默认代理操作界面和之前的航班示例一样，有一个老毛病——输出的原始JSON没有格式化。返回的结果里面，是一个叫 hotels 的数组，每个 hotel 对象里又嵌套着 rooms 数组。这样一层套一层的数据，默认的界面直接就甩出来一长串没结构的JSON，用户根本没办法快速扫一眼、对比不同酒店和房型。 那我们的目标就是像航班示例那样，做一个自定义的 Lightning 类型来美化显示。不过有一点区别要留意：航班那里我们用的是“顶级渲染器”，把整个输出换了个展示方式。而酒店这里，因为输出的主体是一个列表，我们其实更想控制的是列表中每一项的显示模板，而不是把整个列表再包装一次。这就用到集合渲染器了——它让我们可以覆盖列表中每个项目的 UI，但是整体的列表框架还是保留的。 你可以这样理解：顶级渲染器像是把整道菜换了个盘子，而集合渲染器更像是只调整了每块肉怎么切、怎么摆盘，但盛菜的碗还是那个碗。这样用户看到的就不再是乱糟糟的JSON，而是一张张排列整齐的酒店卡片，每个卡片的房间信息都一目了然，方便比较。 好，这一页的重点就是：看到问题，知道要用集合渲染器而不是顶级渲染器，因为我们要改造的是列表里每一个条目的样子。

  ▶ 播放视频 查看详情
• 12

  Customize Output: hotelResponse CLT

  第 241 页

  好，同学，我们来看这一页Slide，它讲的是一个叫 ，hotelResponse， 的自定义Lightning类型，而且它用到了，COLLECTION渲染器，。这个可以说是和我们之前介绍过的“飞行示例”最大的一个区别。 先回忆一下，之前的飞行示例，组件通常是把整个输出当成一个整体来渲染。但在这个酒店的场景里，我们需要展示的是，一个酒店列表，，里面有很多家酒店，对吧？那每个酒店都应该是一张独立的卡片。这时候，COLLECTION渲染器就派上用场了。 看这边，，renderer.json，文件里，它把组件的Overrides配置包在了一个叫 `"collection"` 的键里面。这行配置就是在告诉系统：“嘿，不要把我的LWC组件当成一个整体去渲染，而是要把我，作用在列表里的每一个单独项目上，”。简单说，就是列表里的每一项，都会单独调用一次我们的LWC组件来显示。 那再来看，schema.json，，这个文件里引用的类型，是一个针对，单个酒店，的Apex类。也就是说，它定义了每个酒店项目的数据结构是什么，比如酒店名称、星级、价格这些字段都来自这个Apex类。 接着，在，LWC的meta.html，里，我们会把源类型设置为 `lightning__listType`，这表示这个组件天生就是用来处理列表数据的。同时，`itemTypeName` 这个属性指向我们刚才说的那一个自定义Lightning类型，这样组件就知道列表里每一项对应的是什么了。 然后到了，HTML模板，里，大家看，模板就是在`value`这个数组上做了一次迭代。每一次循环，就生成一张酒店卡片。卡片上呢，我们放了位置图标、星级评分、房间的详细信息，还有房价和折扣的百分比，整体看起来很直观也很美观。 最后，，JavaScript文件，就非常精简了。组件只是通过 `@api value` 这个属性接收外部传进来的数据，一点都不复杂，因为逻辑主要都在标记里展示数据，不需要再去额外处理什么。 所以，总结一下这个小要点：，hotelResponse， 通过COLLECTION渲染器，告诉平台要对列表里每一项分别用LWC组件渲染，而不是把它当成一个整体。这样就能轻松实现列表里每一个酒店都有独立卡片的显示效果。这和飞行示例直接渲染单个记录的方式，区别就在这里了。 好，这一块内容就讲完了，下一张Slide我们再继续深入。

  ▶ 播放视频 查看详情
• 13

  Integration & Final Result

  第 242 页

  好，让我们来聊聊这个很有意思的对比。之前我们做了一个整合，效果简直是天壤之别。你看默认的输出，它就是一坨非结构化的JSON，读起来都费劲。 但是定制完之后呢？输出一下子变成了专业级的卡片布局。每一个酒店，都被包装成带名字、地址、星级还有房间详情的精美框框，连卢比价格和折扣百分比都给你标得清清楚楚。 这里面的关键架构差异是什么？就是渲染器的玩法。第一个示例，是对着整个输出搞一个顶级渲染器，它照顾的是整体。而第二个示例更聪明，它用了一种叫“集合渲染器”的东西。这玩意儿会把一个LWC组件，像盖章一样，应用到列表里的每一个单独项上。 所以啊，集合渲染器天生就是为那种“列表型输出”准备的，你要让每个项目都套上统一的卡片风格，用它就对了。而且这个LWC怎么拿到数据呢？很简单，通过 `@api` 标记的 `value` 属性，一次只接收一个项目，清清楚楚，干干净净。这样去讲，学生应该很容易想象出那种一个个卡片排列出来的效果。

  ▶ 播放视频 查看详情
• 14

  Global Copy: Enhanced Usability

  第 243 页

  同学们，今天我们来聊一个在Agentforce里面挺贴心的小功能，叫做“全局复制”。你想想看，以前咱们在Agentforce的聊天界面里，看到那些显示记录列表或者复杂的消息内容的时候，如果想把这些信息复制下来，是不是得自己动手，一个字一个字地选中、复制，特别麻烦？而且有时候格式还会乱掉。 现在，Agentforce给了一个统一的解决办法——全局复制功能。它会在那些UI组件旁边，自动加一个复制按钮。用户轻轻一点，就能把整个组件里的信息都复制到剪贴板里，体验一下子就顺滑多了。 那么，作为开发者，如果我们自己用Lightning Web Components，也就是LWC，来构建一些自定义的组件，怎么让自己写的组件也支持这个一键复制呢？很简单，你只需要在你的LWC组件里，实现一个公共的API方法，名字叫 `getExpectedValue()`。对，就是这个方法，拼写注意，是g-e-t-E-x-p-e-c-t-e-d-V-a-l-u-e。 当用户在界面上点击那个复制按钮的时候，Agentforce框架就会自动去调用你这个组件里的 `getExpectedValue()` 方法。然后，这个方法需要返回一个字符串，这个字符串就是最终要被复制到剪贴板的内容。这样一来，作为开发人员，你就完全掌控了要复制什么内容，以及它是什么格式。比如你可以返回纯文本，也可以返回格式化的文字，甚至是一些特定的结构化信息，都随你决定。 所以，记住这个关键点：让你自定义的LWC支持一键复制，只要暴露一个 `@api getExpectedValue()` 方法，剩下的，Agentforce帮你搞定。是不是很简单？这就是让用户复制体验更加一致和便捷的秘诀。

  ▶ 播放视频 查看详情