ADG001

课程介绍

同学们，我们来看这一节。这一节要讲的是构建代理时的一些常见模式。什么叫模式呢？就是一些固定套路，一些被反复验证过的好方法，让你做出来的代理更靠谱、更有效。 这些模式呢，我特意用代理脚本来展示。因为脚本视图里，代码结构清清楚楚，你直接复制粘贴就能用，非常方便。不过你也别担心，如果你更喜欢用Canvas视图拖拽搭建，这些思路同样适用，只是表现形式不一样而已。 简单说，就是给你一套拿来即用的技巧合集，学了就能让你的代理更聪明、更稳定。我们一个一个来看。

课程章节

本课程共有 30 个章节

• 1

  The 12 Available Patterns

  第 74 页

  同学们，今天我们来聊聊Agentforce里面非常核心的一个部分——12种可用模式。掌握了这些模式，你就能像搭积木一样，灵活地组装出各种智能代理的工作流程。别担心，我会一个一个解释清楚，保证听完你就能明白它们是干嘛的，什么时候该用。 首先，，动作链，。你可以把它想象成一条流水线，让多个动作按顺序一个接一个自动跑。比如先查订单，再发邮件，最后更新记录，一步接一步，不会乱。 然后是，代理路由器，。这个名字听起来有点抽象，其实它就是智能的交通指挥。当用户问不同的问题，路由器负责判断这个请求该交给哪个子代理去处理，确保对话走对方向。 ，条件句，就是经典的if/else逻辑。如果用户是VIP，走绿色通道；如果不是，走常规流程。它让代理能根据情况分支，做出不同的反应。 接下来这个很重要——，上下文工程，。它不是具体的一个动作，而是一种策略，告诉代理“在什么情况下该做什么”。比如根据对话历史、用户角色这些上下文信息，动态调整接下来的行为。简单说，就是让代理更懂你。 ，获取数据，，顾名思义，就是在推理和回答之前，先去把需要的信息拉回来。比如用户问“我的订单到哪了”，代理得先去后台查数据，有了结果再组织语言回复。 ，使用可用时间进行过滤，，这个比较有意思。它用来控制信息在什么时间段内是可见的。比如只展示本周的会议安排，过期的就自动隐藏掉，避免把用户淹没在旧信息里。 ，所需的子代理工作流程，，这里的“所需”是强制性的意思。它保证某个关键步骤一定会被完成。比如说，必须验证用户身份之后，才能查看账户信息，这个步骤跳不过去。 ，资源引用，，就是直接用@符号来调用特定资源。就像在聊天时@某个人一样，代理可以直接引用知识库里的文章、文档或者数据表，非常直接高效。 ，系统覆盖，，让你能够针对每个子代理去调整它的默认行为。比如A子代理说话风格可以设置得更正式，B子代理则可以轻松活泼一点，各自适配不同的场景。 ，转换，，负责在子代理之间无缝移动。当用户从退货问题突然转到问优惠券时，转换机制就会把上下文平滑地带到下一个子代理，保证对话不中断。 ，变量，，用来跨子代理存储状态和信息。比如用户一开始输入的手机号，在后面的验证、绑定等步骤里都能随时取用，因为这个变量值整个流程都记得。 最后是，列表变量，，它是专门给集合这类数据用的。当你要处理多个项目，比如一批订单号、多个收货地址，用列表变量就特别方便。 这12种模式就像是你的工具包，每个都有自己明确的职责。把它们组合起来，就能设计出既聪明又灵活的Agentforce代理。好了，记住它们不难，多动手配置几次就熟悉了。下节课我们再来看看怎么把这些模式真正用起来。

  ▶ 播放视频 查看详情
• 2

  General Guidance & Principles

  第 75 页

  同学们，咱们今天来聊聊在使用 Agent Script 构建代理时，一些非常实用的小贴士。你就想象一下，你正在教一个特别聪明但有时会有点迷糊的新同事干活，咱们得怎么一步步指导他呢？ 首先，咱们的推理指令要从最简单的开始。什么叫最简单的呢？就是只写当下最必要的那些要求，别一上来就洋洋洒洒一大篇。等你的代理跑一跑，测试一下，发现问题了，再一点一点往上加。这就好比带孩子写作业，你先讲最核心的步骤，看哪里卡住了，再补充解释，这样他学得才扎实，不至于一开始就犯晕。 接下来，给代理里所有的东西起名字和写描述，一定要用具体、独特，而且你的最终用户一听就明白的语言。千万别用那些只有技术部门才懂的缩写或者模模糊糊的词。比如，“客户关怀流程”就比“流程A”好得多；描述里写“当客户询问退货时，请收集订单号和退货原因”，就比“处理RMA请求”要清晰。因为清楚的名字和描述，能让代理真正理解你的意图，也能让将来维护这套系统的同事快速上手。 还有一点特别重要，就是语言风格一定要保持始终一致。如果你有时候说“查看订单状态”，有时候又说“检查单子到哪了”，有时候用疑问句，有时候用祈使句，那这个聪明的代理可能就糊涂了。它可能会觉得你在让它做不同的事情，最终导致它给出的回应或者执行的动作前后不一致。所以，咱要像练书法一样，统一好你的用语。 再往深一点说，咱们可以巧妙地平衡自然语言和业务逻辑的表达，给代理增加一点确定性。什么叫增加确定性呢？有时候光靠自然语言描述，可能会有歧义。比如，你可以这样说：“如果客户情绪激动，并且提到了‘投诉’或‘退款’，调用升级流程，同时安抚客户。”这里面，“调用升级流程”就是一个明确的逻辑动作，而“安抚客户”是自然语言的要求。把这两者结合起来，既给了代理人性化的引导，又用逻辑确保了它关键步骤不会跑偏。 最后，咱们还可以使用一个很厉害的工具，叫做“@ representations”。你可以把它理解成在指令里直接给大语言模型指路。比如，你在某个指令里写：“请参考@知识库中的退货政策，来回应客户。”这样，代理就会直接去那个指定的知识库里找准确的答案，而不是自己胡乱编一个。这就好比你跟新同事说：“这个问题你去问@财务部王姐”，他就能得到最准确的答复。所以，善用@ references 能让你的代理更精准地获得信息，给出靠谱的回复。 好，总结一下，从简单开始，起好名字，保持一致的语言，平衡自然与逻辑，并用@直接引用资源，这几点你掌握好了，构建出来的代理就会既聪明又稳当。那么这节课就先到这里，大家可以去试一试啦！

  ▶ 播放视频 查看详情
• 3

  Pattern: Action Chaining and Sequencing

  第 76 页

  好，今天我们来聊聊在 Agentforce 里，怎么根据自己的需求去安排操作的执行方式。 你可以把它想象成安排一个助手去完成任务。有时候任务很简单，一件事接着一件事做就行，我们就叫它“顺序运行”。你只需要告诉助手：先做A，再做B，最后做C，它会自动按顺序完成，第一步的结果还可以无缝传给第二步。 再进一步，有时候你需要让助手根据上一步的结果去“思考”一下再行动，这就是“连锁推理”。也就是说，助手不会傻傻地跑完流程，而是能在中间判断一下，再决定接下来走哪条路。 更灵活的是，你还可以把“转换”和“条件”加进去。比如当某个数据是“是”的时候走向一条分支，是“否”的时候就拐到另一个分支。这就像在流程里放了几块指示牌，助手到了路口会根据情况自己选路。 最关键的一点是，动作排序让整个工作流变得非常牢靠。你不需要指望大语言模型自己去记住一长串指令，那样容易遗漏。你只要事先把“第一步完成后自动触发第二步”这种关系设定好，助手就会稳稳当当地执行。 所以记住，在 Agentforce 里实现操作的方式很灵活，顺序、推理、条件分支，再加上可靠的动作排序，就能让自动化流程既智能又稳定。 这些方法组合起来，你就能轻松构建出可靠的多步骤工作流了。

  ▶ 播放视频 查看详情
• 4

  Sequential Actions & Chained Reasoning Actions

  第 77 页

  那咱们今天看看这张幻灯片里讲的一个挺关键的概念——在Agentforce里，怎么安排动作的执行顺序。我尽量说得简单点，你听完就知道什么时候动作是“排着队跑”，什么时候是“像链子一样拴在一起跑”。 你先想象一下，我们让代理做事，有时候不是只做一件事，而是要先查天气，再把结果存下来，再传给另一个动作去安排行程。那就有两种不同节奏了。 第一种节奏，我叫它，“推理之前先把路铺好”，。 这对应的就是幻灯片里说的“在推理指令中一个接一个地调用动作”。意思是什么呢？就是在你把提示真正交给大语言模型去思考之前，这些动作已经跑完了，而且是确定性的——一个结束，下一个才开始，规规矩矩。比如说，你先用某个工具去数据库里把客户ID查出来，存到一个变量里；然后用这个变量去调第二个工具，把客户资料取出来。这些全都在模型开始“动脑子”之前就完成了。因为这时候模型还没介入，所以输入输出都得你手动绑定，就像你手把手把每一块积木搭好，再交给模型去用。 你可以这样记：，这些动作是你预先规划好的流程，不管模型怎么想，它都会先跑完，结果已经准备好了。， 第二种节奏呢，叫做，“模型一喊，后脚就跟上”，。 幻灯片里说的是“推理动作中的连锁动作”，也可以叫链式动作。这个就不一样了。它会先由大模型在推理的时候决定：“噢，我需要调这个主动作了。”主动作一被触发，代理立刻自动帮你把后面那个“连锁动作”也跑了，你不需要再手动去调度。比如，模型决定“我要给客户发一份报价单”，这个“发报价单”的主动作一执行，连锁动作就会自动把报价单的详情存到日志里，或者紧接着发一封确认邮件。这个过程，就是“主要动作被调用后，自动尾随一个后续动作。” 这个你也不用操心输入输出，因为都是设计好的——主动作的结果天然就丢给下一个链上的动作。 总结一下方便你区分： - ，推理前顺序调用，：提前规划，动作一个接一个跑完，再让模型思考。你得手动管变量。 - ，推理中连锁动作，：模型在思考时才决定调用主动作，然后自动带上一个“小尾巴”，一气呵成。 打个比方，第一种就像你去餐厅点餐前，厨师已经把前两道菜按固定流程做好了，只等你点；第二种像你点了主菜，服务员马上自动送上一份固定搭配的例汤。这样听着是不是好理解一点？ 你记住这两个场景，后面在设计代理的逻辑时会经常用到。有问题随时问我，咱们再拆细了讲。

  ▶ 播放视频 查看详情
• 5

  Action + Transition, Conditional Chain & Tips

  第 78 页

  同学，咱们接着看这张幻灯片，它讲的是Agentforce里怎么把多个操作串起来，而且根据情况不同还能走不同的分支，自动切换子代理。 你可以先想象一个场景：比如用户问了个问题，系统不是直接回答，而是先做一次验证，像检查账户状态。验证完了，再根据结果，把请求转给不同的子代理去处理。这就是所谓的“先验证后路由”模式，特别实用，能避免直接回答出错。 Agentforce里怎么实现呢？靠两种“链”。一个是顺序链：你把几个动作按固定先后顺序排好，每次都是先执行A，然后执行B，再执行C。这种就叫确定性流。比如先查天气，拿到了城市名，再查空气质量。动作之间要传数据怎么办？直接用变量把前一个动作的输出，当作后一个动作的输入就行了。 另一个是条件链，它更灵活。它能根据前面动作的结果，判断下一步走哪条路。比如先问用户要不要使用优惠券，如果回答“要”，就转到计算折扣的子代理；如果回答“不要”，就直接进支付流程。这就像在流程里画了个分叉路口，根据条件自动跳转。 关键提示：你只要记住，如果你的业务步骤是固定死的，就用顺序指令来搭一个确定性的流，用变量串联动作的输出。如果步骤可能根据结果变化，就引入条件链，做出分支多步骤工作流。 这样讲，是不是就清晰了？接下来我们看看具体怎么配置。

  ▶ 播放视频 查看详情
• 6

  Pattern: Agent Router Strategies

  第 79 页

  好，咱们今天聊一个特别重要的概念，叫“代理路由器”，英文里也叫 start_Agent。就这一个词，搞明白它，你后面驾驭整个 Agentforce 就顺多了。 你可以这么想，代理路由器，它就像是一个智能管家兼前台。每一次用户说话，不管是在网页聊天，还是打电话进来，消息第一个碰到的就是它。它会先打声招呼，问好，然后快速判断：“这人想干嘛？是想查订单，还是问产品，或者要转人工？”这个判断的过程就叫意图分类。 分类完了以后，它就会把请求“路由”到真正干活的子代理那里，比如订单查询代理、售后代理。更厉害的是，它还能根据用户当前的状态，决定哪些子代理可以接活。比如说，如果用户还没登录，可能就不会给他显示“我的账户”那一类服务。这样既安全，体验又顺。 所以，一个结构设计得特别好的代理路由器，就像一条精心修好的主干道，能让每个用户用最短的时间、最少的功夫，直接找到那个最能帮他的子代理，而不是在选项里迷路。 记住了，它就是你整个代理体系的起点和总调度。下次你动手设计的时候，第一个要打磨的，就是这个 start_Agent。

  ▶ 播放视频 查看详情
• 7

  Basic Router Structure & Effective Descriptions

  第 80 页

  同学们，咱们来聊聊Agentforce里的子代理，特别是这个“start_agent”子代理。 你可能会想，“start_agent”是不是有什么特殊的机关，跟别的子代理不一样？其实啊，它的结构跟其他子代理是一模一样的，你该怎么建就怎么建。但咱们用它的目的，通常是为了实现更有效、更高效的子代理路由。 那什么是子代理路由呢？简单说，就是你有一个主代理，当用户问它问题时，主代理得决定：“这个问题，应该丢给哪个子代理去处理？”这就是路由选择的过程。 为了让主代理能选得好、选得准，你就得把子代理的，描述，写好。好的描述就像给子代理贴的标签，主代理一看就明白它该干什么。 这儿给你几个小贴士： 第一，，要具体，。别光写“处理客户问题”，要细说：“这个子代理专门处理订单退款和退货申请，包括查询退款状态和发起退货流程。”够具体吧？主代理一看就知道，用户问退款的事儿，就找它。 第二，，要清晰、详细、独特，。如果你的系统里有好几个相似的子代理，比如一个管“国内订单”，一个管“国际订单”，那描述就更要下功夫了。你得让主代理能从描述中分辨出细微差别，比如：“本子代理处理中国境内订单的物流查询，国际订单请交给国际订单子代理。”这样就不会搞混。 第三，如果有些子代理你不想让用户直接接触，只希望其他子代理在处理过程中能调用它，那怎么办？很简单，，别在其他地方引用它，。比如，不要在主代理的描述里提它的名字，也不要把它加到起始话题里，这样用户就不会直接跳进去，只能通过其他子代理的转换来访问它。 总结一下：start_agent就是普通子代理，关键把描述写好，让主代理能聪明地选择它。描述具体一点，独特一点，需要隔离的就藏起来。这样你的代理团队才能配合得天衣无缝。 好，咱们接着看下一部分。

  ▶ 播放视频 查看详情
• 8

  Subagent Gating, Deterministic Routing & Tips

  第 81 页

  大家好，今天咱们来聊聊 Agentforce 里一个特别实用的技巧——子代理门控，也就是怎么精准地控制“该让哪个小助手出来接活儿”。 你可以把子代理想象成你团队里身怀不同绝技的专家，有负责售前的，有管售后的，还有处理投诉的。那问题来了，用户抛一个问题，怎么才能让对的专家接过话筒，而不是让 AI 胡乱猜呢？ 首先，请记住一个核心原则：，用“可见条件过滤器”来把门，。英文叫 `availableWhen` 过滤器。比如你建了一个专门处理“退货”的子代理，就可以给它加一条规则：只有当用户的问题里包含“退货”、“换货”这些词时，这个子代理才“可用”。这样一来，AI 在选人的时候，其他不相关的子代理压根儿就不会出现，大大降低了选错的概率。 接着，，关键的路线决策千万不要交给大语言模型去“猜”，。你需要在主代理的指令里，用明确的条件转换（也就是 if-then 逻辑）来做路由。比如说，你直接在指令里写：“如果用户想退货，就转到退货子代理”。这是确定的程序判断，比让模型自己做选择题要可靠一百倍。 那怎么实现这种“条件转换”呢？这里有个好习惯：当你添加跳转子代理的操作时，把操作名称统一设为 ，`go_to_precept`，。这就像是给每条“转接电话”的线路贴上唯一标签，后期维护一目了然。同时，一定要给你的子代理和转换动作写上，详细、唯一的描述，，让别人（包括未来的自己）一眼就能看懂这条分支是干什么的。 此外，系统默认可能有个“代理路由器”负责分配任务。你完全可以换掉它，指定另一个子代理作为起始，甚至如果嫌它碍事，直接删除掉，把路由逻辑全收回到自己的指令里，用条件判断全权掌控。 最后，给大家一个稳妥的推进策略：，从最必要的几个子代理起步，逐步添加，。别一口气弄一堆。设置路由时，记得把条件判断放在最前面，保证路由逻辑在其他处理之前先执行，这样就不会因为顺序问题让程序跑偏了。 简单总结一下：用条件开关锁好门，用确定逻辑指对路，统一命名，描述清晰，再循序渐进地扩展。这样，你的 Agentforce 代理团队就能像一支训练有素的精兵，指哪儿打哪儿，再也不会乱调人了。 好了，这个技巧你学会了吗？下节我们来看个实战例子。

  ▶ 播放视频 查看详情
• 9

  Pattern: Using Conditionals

  第 82 页

  好，今天我们来聊一个可以让你的Agent变得更聪明、更可靠的小技巧，叫做“条件句”。 你可能会想，Agent不是靠大语言模型来理解用户、再决定做什么吗？没错，但在某些情况下，有些判断其实是非常确定的。比如，这位用户是金牌会员还是白金会员，这在系统里早就记录得一清二楚了。这种时候，我们完全可以不等模型去“猜”，而是提前就帮它把路选好。 条件句就做这件事：它在提示扔给大模型之前，就根据我们设定好的规则，做出确定性的决定。比如，系统一看这位是金牌会员，好，那我就运行这一段提示，告诉他“感谢您的支持，您的积分余额是多少多少”。如果检测到是白金VIP会员呢？那就切换到另一段提示，给他一个独家的欢迎语，再加上一些额外福利的介绍。 这样做有两个好处：第一，快，因为它不需要经过模型解释这一步；第二，稳，因为只要是同一个身份，每次都会走同一条路径，不会因为模型一时的“发挥”而产生不一样的回答。 所以在设计Agent的时候，我们可以把那些“非黑即白”的、有明确业务规则的判断，放在条件句里，让流程更可控，也让用户体验更一致。 好，我们下一个小节继续。

  ▶ 播放视频 查看详情
• 10

  Conditional Instructions, Actions & Transitions

  第 83 页

  我们来看一下Agentforce里面的条件指令。 简单来说，条件指令就是给大语言模型的提示里面，只放那些跟当前情况相关的指令。比如说用户问的是订单状态，那我们就不用把退货流程的提示也塞进去，这样大模型收到的指令更精准，回复也就更快、更准。 然后是条件动作，它只在满足条件的时候才会运行，能明显改善响应时间，也减少不必要的系统消耗。比如只有当用户说“我要退钱”的时候，才去调用退款接口，而不是每句话都去检查一遍。 最后是条件转换，它更直接，在大模型处理任何指令之前，就直接根据条件把用户路由到不同的子代理。比如用户一开口说“我需要技术支持”，系统立刻把他转到技术支持代理那边，完全不经过其他指令处理，反应速度非常快。 总结一下，条件指令让提示更精准，条件动作让执行更高效，条件转换让路由更即时，这三者搭配起来，就能让Agent变得既聪明又轻快。

  ▶ 播放视频 查看详情
• 11

  If/Else Logic, Multiple Conditions & Tips

  第 84 页

  同学们，我们来看这一页内容，重点讲的是在Agentforce里写条件判断的时候，怎么让逻辑更清晰、更少出错。别看只是几个小习惯，但用在复杂的自动化决策里，效果差别特别大。 先说第一点：，对相互排斥的条件，一定要用 if/else 逻辑，。 啥意思呢？比如你要判断一个订单是“待付款”还是“已付款”，它不可能同时是两种状态，这种就是互斥的。你应该写：如果状态等于待付款，就做A；否则如果等于已付款，就做B。别写成两个独立的 if 分别判断，那样后面万一加了一个“已退款”，就容易漏掉，逻辑也会越来越乱。用 if/else 链条，所有情况一目了然，一个入口，一个出口。 接着，，用“和”与“或”运算符来组合多个条件，。Agentforce里当然支持类似“AND”和“OR”的写法，帮你在一条规则里同时检验几件事。比如“如果客户是VIP并且订单金额大于1000”，就触发特殊流程。这两个条件必须同时成立，就用“和”连起来；如果是“只要满足其中一个”，就用“或”。但多个“和”、“或”混在一起的时候，意思就容易糊。 所以一定要记住：，用括号把你想先评估的条件显式地分组，。 哪怕语言本身有优先顺序，你加上括号，别人读起来也立刻明白你的本意。比如这个表达式：“（客户等级是VIP 或 客户是员工） 且 订单有折扣”。你把“或”的部分用括号括起来，就清楚表示先判断身份，再和“有折扣”组合。不加括号，Agentforce也可能按自己的顺序算，但你的同事和将来的你，肯定得猜半天。让条件可读、可维护，这在真实项目里太重要了。 然后我特别要强调一个容易踩坑的地方：，初始化变量时给个默认值，。 很多条件里会用到变量，比如一个叫“折扣率”的数值变量。如果你没给它初始值，它可能就是空的。在判断“折扣率大于0.1”的时候，空值比大小很容易直接出错，或者给出意想不到的结果。养成习惯，一上来就先把折扣率设为0，或者设为字符串的空值，保证任何条件检查都能正确进行，不会因为变量没准备好就胡乱跳分支。 还有一个Agentforce里的细节，需要大家特别注意：，用“is No”来做空检查，这和检查空字符串是不一样的，。 很多时候我们碰到的不是简单的文字为空，而是这个字段根本没有值，或者是一个布尔字段的“否”状态。在Agentforce的逻辑里，“is No”专门用来判断某个值是否为空或者是否为假，这跟判断它等于一对双引号的空字符串是两回事。例如，判断一个客户备注是不是没有内容，如果你写“备注等于 '' ”，可能只在它有字符串时生效，当备注字段完全没被填过、数据库里是null的时候，就匹配不上。而使用“is No”，能更安全地覆盖“什么都没有”的情况，避免条件漏掉。一定要养成习惯，做空判断优先考虑“is No”。 最后再总结一下，复杂条件里，括号就是控制计算顺序的指挥棒，。把它们用好，你的条件逻辑不管多绕，都能被 Agent 稳定执行，也让后面维护的人轻松看懂。 好，这页的核心就是这几条，大家可以把它们当作写条件的清单：用if/else处理互斥、运算符组合、括号分组、变量给初值、空检查用“is No”。这些做法会让你的Agent行为更加精确，也更加可靠。下一张Slide我们继续看怎么把这些条件应用到实际对话流程里。

  ▶ 播放视频 查看详情
• 12

  Pattern: Fetch Data Before Reasoning

  第 85 页

  同学们，今天我们要聊一个在 Agentforce 里非常实用的小技巧，就是“把动作调用放在推理指令的顶部”。 这句话听起来可能有点绕，我来给你打个比方。假设你是一个销售代理，客户来找你聊天，如果你等到客户开口问了“我订单到哪了？”，才手忙脚乱地去系统里查，那这个对话就会很卡顿，体验也很差。但如果你在客户开口之前，就已经把他们的订单信息提前调出来了，那你就能很自然地主动打招呼，说：“王先生您好，您上周定的那批货已经在路上了，预计明天就到。”这样是不是就顺畅又贴心？ 在 Agentforce 里也是一样的。我们希望大语言模型，也就是 LLM，在生成那句回答之前，手里就已经握住了最新、最准的数据。所以我们要把“查询订单”这个动作，写在推理指令最前面的位置上。这样，当提示还没真正送到模型那边之前，系统就会先偷偷地去执行这个动作，把数据拉回来，塞进提示里。然后模型再根据这些真实的数据去推理，生成出来的回答才不会胡编乱造。 你看这个例子里，哪怕对话才刚刚开始，我们也可以先让代理自动去查一下这个用户的当前订单。这样一来，代理开口第一句话就能给出订单状态，甚至做个个性化推荐，而不是干巴巴地等着用户来问。这就是所谓的“将动作放在推理指令顶部，在构建提示之前获取数据”。 这个做法就是我们常说的，让模型手里有粮，心里不慌。先取数据，再动脑子。这样一来，你的代理每次说话，都是靠得住的。 好，这个小技巧就讲到这里，大家以后设计 Agentforce 的时候，记得把关键的数据抓取动作放到最上面去。

  ▶ 播放视频 查看详情
• 13

  Basic Fetch Pattern & Fetch and Validate

  第 86 页

  同学们，咱们接着看这张片子，讲的是Agent里面获取数据的基本模式，还有更灵活的获取验证模式。很好理解，大家跟着我想象一个场景，比如咱们的Agent需要去帮用户查一下最近的订单状态。 首先看这个基本获取模式，它就像一套标准的操作流程，总共四步。 第一步：检查。先看看我们是不是已经拿到过这个用户的订单数据了。比如之前对话里已经查过了，就别重复劳动。 第二步：如果发现没有，才真正去运行那个查找操作，比如去数据库里捞数据。 第三步：把捞出来的结果，存到一个变量里，像放进一个小盒子一样，以后随用随取。 第四步：在给用户的回复提示里，直接引用这个变量，这样就能把订单号、日期这些信息自然地嵌进去，展示给用户。 这就是最基础的获取数据方法，简单直接。 然后，我们再看获取和验证模式，它其实是对基本模式的一个加强。它的聪明之处在于，数据一拿到手，马上就做一个检查判断，根据数据的内容来决定接下来给用户呈现哪些选项。 举个例子，Agent查完订单，发现状态是“已发货”，那它就可以在回复里加上“查询物流”的选项；要是状态是“未发货”，那就可以提供“修改地址”或“取消订单”的选项。这样一来，不用再额外多轮问用户，体验就流畅多了。 这里还有一个特别关键的提醒，大家一定要记住：在你真正要去调用查找操作之前，永远先做那一次数据存在性的检查。这个习惯能帮我们避免很多不必要的操作，节省时间，也减轻系统负担，还能让Agent反应更快。千万不能每次都傻傻地重新查一查，那样效率就低了。 好，这个基本的获取模式、获取验证模式，还有那个“先检查再查数”的口诀，大家都明白了吧？接下来咱们可以看看具体的配置方法。

  ▶ 播放视频 查看详情
• 14

  Pattern: Enforce Business Rules with Filters

  第 87 页

  好，我们来聊一个特别实用的小技巧，叫做“可用时间（Availability Time）”。你可以把它想象成给大语言模型戴上一块手表，告诉它：“嘿，只有在特定时间段里，某些工具或子代理才对你可见。” 为什么需要这个？ 因为大语言模型很聪明，但也容易“上当”。比如，一位客户故意聊着聊着，试图让模型调用一个本不该现在用的信用卡退款子代理。如果没有时间这道闸门，模型可能会被说服，打开了不该开的功能。 另一种情况更隐蔽：在复杂的工作流里，上下文越堆越多，就像嘈杂的房间里聊天，模型可能会自己犯迷糊，把之前聊过的某个操作误以为现在还能执行，导致推理出错。 有了“可用时间”，这些麻烦就能被挡在外面。 你只要设定好条件：比如，某子代理只在工作时间、或者客户进到第二阶段的流程后，才向模型开放。不满足条件，模型压根就看不到这个选项，更别说去调用它了。 这就好比一个餐厅，菜单上的某些菜只有晚餐时段才亮出来，中午的顾客就算再怎么跟服务员磨，服务员也拿不出这道菜，因为系统里直接就锁住了。 所以，“可用时间”本质上是一个安全过滤层，既能防止客户钻空子，又能帮模型排除干扰，避免上下文里飘来飘去的噪音让它走错路。 在Agentforce里用好它，你的智能助手就会既灵活又守规矩。

  ▶ 播放视频 查看详情
• 15

  Filter Subagents & Filter Actions

  第 88 页

  好，我们来看这一页，它讲的是过滤子代理。这个概念就像给你的智能助手设置一扇门，只有符合条件的人或情况，才能使用门后面的功能。 想象一下，你有个客服机器人。所有用户都能问一般问题，比如“你们几点营业？”。但查订单、退换货，那就得先验证用户身份，登录后才能用。要是涉及升级投诉，那就更严格了——不仅要登录，还得是在工作时间，不然就得排队等人工。 这套过滤机制就是干这个的：让子代理只在满足业务规则时才被允许调用。重点来了，大语言模型其实可以调用任何它能看到的推理动作，即使你在提示里没明说“别用这个”。所以光靠提示语约束是不够的，客户可能会故意绕过去，乱用功能。我们得从权限层面直接过滤掉那些敏感的子代理，这样最安全。 如果条件复杂，比如同时需要A和B，或者A满足就行、但C也得满足，记得用括号把条件包起来，这样逻辑才清晰，不会乱。 一句话总结：用过滤把敏感功能关在门后，别光靠嘴皮子叮嘱，那样不牢靠。

  ▶ 播放视频 查看详情
• 16

  Pattern: Enforce Required Workflows

  第 89 页

  [AI生成失败] 在指令顶部使用条件转换来强制用户完成所需的步骤。与具有可用时间的过滤不同，这些转换立即执行并保证路由行为。对于身份验证等关键流，指令中的条件转换比单独过滤时更可靠-虽然过滤限制了选项，但它不会强制执行工作流程。

  ▶ 播放视频 查看详情
• 17

  Choosing the Right Enforcement Approach

  第 90 页

  好，我们来看这一页——执行规则，说白了就是怎么决定Agentforce下一步该做什么。这里有三个方法，选对方法特别重要，我来给你拆解一下。 第一种叫，“可用”，。这个怎么理解呢？就是你提前给出一组推理动作，好比给了Agent一个菜单，但具体点哪道菜，让大语言模型自己琢磨、自己选。适合那种——你希望Agent有选择余地、能灵活应对的场景。 第二种是，“条件转换”，。这个就截然不同了，它不给模型任何选择的机会。只要条件一满足，立刻、马上执行下一步，中间不经任何思考。你想要一个步骤必须最先完成，比如用户必须先登录才能干别的，那用条件转换就对了。它比单纯的过滤更可靠，尤其像身份验证这种关键流程，一步都不能错。 第三种叫，“多回合步骤变量”，。这个适用于更复杂的对话流，比如你有一串子代理，下一个派哪个出去，得看顾客刚才的回应是什么。这时候用多回合步骤变量，可以按条件分支，分步骤排序。 简单总结一下：想让模型自己挑动作，用“可用”；强制必须先完成某一步，用“条件转换”；需要根据对话来回动态排步骤，用“多回合步骤变量”。记住，关键流程千万别图省事，条件转换往往比让模型自己过滤更保险。 好，这一页就这样，掌握这三种方法的选择，你就知道怎么让Agent走得既灵活又稳当了。

  ▶ 播放视频 查看详情
• 18

  Required Flow Examples & Tips

  第 91 页

  同学们，今天咱们来聊一个特别实用的小技巧，能帮你的 Agentforce 代理设计得更高效。 假如你希望所有子代理在被调用之前，都必须先跑完一个特定的流程，比如身份验证，那该怎么办呢？方法其实很简单：在代理路由器的指令里，把那个“条件转换”放在所有东西的最前面。 这个条件会检查一个变量，比方说叫“是否已验证”。一开始这个变量是 False，所以用户请求一进来，立刻就会触发这个转换，然后执行你设计的验证流。验证流跑完之后，把那个变量改成 True，然后流程会重新开始。这次因为变量已经满足条件了，就不会再走验证，而是正常进入到后续的其他子代理处理逻辑。这样一来，你就轻松实现了“每次请求必须先验证”这个硬性要求。 同样的模式，如果你只是想让某个单独的代理先满足先决条件，也完全适用，只要把该流的条件转换放在指令顶部就好。 一定要记住一个关键点：把这些前置流放在最上面，在任何其他指令之前执行。因为如果代理在真正推理之前就已经发生了转换，那它根本不会去看底下那些指令，不仅浪费了处理时间，还可能产生不必要的成本。所以，放在顶部，干净利落，既保证逻辑又节省资源。 好了，这个小妙招你学会了吗？动手试试吧。

  ▶ 播放视频 查看详情
• 19

  Pattern: Required Workflows Through

  第 92 页

  好，咱们来看这一页内容，讲的是怎么让Agent更聪明地追问用户，把该问的问题都问到，而且顺序不乱，还能根据用户刚才的回答灵活调整下一个问题。 你可以想象这样一个场景：你让Agent去处理一个比较复杂的任务，比如帮用户申请贷款。它必须问完一长串必需的信息，比如收入多少、工作几年、有没有负债……而且下一个问题常常要取决于上一个答案。比如用户说“我是自由职业者”，那下一个问题就不能再问“公司名称”，而要改问“主要收入来源是什么”。有时，Agent在一个子任务里可能要跟用户来回好几轮，才能把某个信息问清楚。 传统做法可能会把追问逻辑写死在同一个对话流程里，但这样很难维护。我们这里介绍一种更灵活的模式：，用步骤变量来控制路由，让主代理（Router）知道接下来该把用户分派给哪个子代理，。 具体怎么做呢？你可以在对话过程中设置一个变量，比如叫`nextStep`，它会告诉主代理：下一步应该激活哪个子代理。比如“问收入”子代理处理完后，它根据用户的回答，去修改这个`nextStep`变量，变成“问负债情况”或者“上传证明文件”等。然后主代理一看到这个变量，就自动把用户路由到对应的子代理。 这样一来，整个追问的顺序就不是硬编码的，而是由子代理在处理过程中动态决定的。子代理不但负责问问题，还要负责评估用户给的答案是否足够，如果答案模糊，它可以在自己的子代理里继续追问澄清，直到答案能用为止，最后它再把`nextStep`指向下一个该去的地方。 什么时候特别适合用这种模式呢？就是当你的Agent必须提出，一长串必需的问题，，而且问题的顺序有很强的，依赖关系，，或者，单一的澄清过程可能就需要好几轮交互，的时候。用步骤变量做路由控制，就能让整个对话既结构化又灵活，不会乱套。 好，这一页的核心就是这个意思。你可以把它理解成：用一个小本本（步骤变量）随时记下“该轮到谁干活了”，每个子代理干完活，在本本上写清楚接班人的名字，主调度员一看本本就马上把活儿分过去。

  ▶ 播放视频 查看详情
• 20

  Step Variable Pattern & Interview Example

  第 93 页

  嗨，同学，咱们来看这个幻灯片里提到的设计模式，其实特别实用，也很容易理解。 想象一下，我们有一个总控代理，它就像一个贴心的接待员。它手里有一张流程表，上面写着当前进展到哪一步了——这个就叫“currentInterviewStep”（当前访谈步骤）。总控代理不看别的，就盯着这个步骤变量的值，来决定接下来该把对话交给哪个“子代理”去处理。 每个子代理呢，就只负责一件具体的事儿，比如有个子代理专门问“您有权限吗？”它和客户聊完，会根据回答，自己来更新这个“currentInterviewStep”。如果客户说“有权限”，它就悄悄把步骤改成“Eligible”（符合资格）；如果“没权限”，就改成“End”（结束）。然后，总控代理看到步骤变了，自然就知道该把客户引向下一个子代理，或者结束对话了。 这里有一个很巧妙的小语法，你可能注意到了，就是那个省略号“...”。这个叫“插槽填充”机制。意思是，子代理在问问题时，可以直接用“...”告诉语言模型：“喂，这个问题你帮我推理一下，把相应变量填上。”这样一来，语言模型就能发挥它的推理能力，从客户的回答里提取信息，自动设置好变量值。整个过程很流畅，不需要写死一堆复杂的判断规则。 关键点在于，每个子代理只扛一件事儿，步骤名称也起得特别清楚，比如“权限检查”“资格确认”这些。而且，每个子代理都把自己该做的收尾逻辑管好——它自己知道什么时候算问完，什么时候该把步骤变量改成什么，好让总控代理继续往下走。 这样一来，整个对话流程就像搭积木一样，清晰、好维护，而且特别擅长处理分支复杂的访谈场景。你只要记住：总控看步骤分派任务，子代理专注提问并更新步骤，再用上“...”插槽填充，对话就变得又灵活又可控。 好，这个模式我们就讲到这儿，有什么不明白的随时提出来呀。

  ▶ 播放视频 查看详情
• 21

  Pattern: Reference Resources

  第 94 页

  嗨，同学们，咱们今天讲一个小技巧，能让你的Agent更聪明、更听话。你在给Agent写推理指令的时候，如果只是用自然语言说“去查订单”、“发个邮件”，有时候Agent可能会发懵，不知道该调用哪个操作或者哪个变量。那怎么办呢？很简单，你在指令里直接点出来，用特定的语法引用它。 比如，你要是想让Agent调用一个叫做“订单查询”的子代理，就直接在指令里写 @订单查询，用这个@符号来点名。要是想引用变量，比如客户的邮箱，就把它放在花括号里，写成 {客户邮箱}。对于推理操作也是一样，像发送确认邮件这个操作，你就可以写 @发送确认邮件。这样做，相当于给了大语言模型一个非常强烈的信号：“看好了，就是这个，别搞错了！”模型一下子就能明白你要用的是哪个工具、哪个数据，出错的几率就小多了。 举个例子，你可以这样写指令：“请先调用 @订单查询子代理 查一下最新状态，然后把结果交给 @发邮件操作，收件人填 {下单人的邮箱}。”这样Agent每一步都清清楚楚，不会乱猜。 所以记住啦，在你的提示文本里，多用@直接提到子代理和操作，多用花括号把变量亮出来，你的Agent就会像被点了名一样，反应快还准确。这一招很简单，但特别管用，回去试试吧。

  ▶ 播放视频 查看详情
• 22

  Reference Syntax & Combined Examples

  第 95 页

  同学们，咱们今天来看的这个知识点特别实用，它讲的是一种在Agentforce里精确指挥AI的方式，叫做“引用语法”。你听这名字可能有点技术，但其实非常好理解，就像你给助手发消息时，用@符号直接点名该找谁、该用什么信息。 来，咱们一个一个说。在Agentforce里，如果你想告诉大语言模型：“你去用这个子代理来做这件事”，那你就用 ，{!@ subagents.name}，，这个名字就是你提前建好的子代理的名字。比如，你要是建了一个专门处理订单查询的子代理叫“OrderHelper”，你就在提示语里这样写：{!@ subagents.OrderHelper}，AI一看就明白，哦，这是要我去调用订单助手。 然后，如果你想让它执行某个具体的操作，比如发邮件、查数据库，那你就用 ，{!@ actions.name}，。假设你建了个操作叫“SendEmail”，你写 {!@ actions.SendEmail}，AI就会去调这个工具。这就像你告诉助手：“用发邮件这个动作”。 第三个，变量，就是 ，{!@ variables.name}，。比如当前对话里的用户姓名、订单号，你直接把这个变量名圈出来，AI就会在回复的时候把真实的数据填进去。好比你说：“亲爱的{!@ variables.userName}，您的订单{!@ variables.orderId}已发货。” 出来的效果就是“亲爱的张三，您的订单12345已发货。” 更妙的是，这些引用能混着用。你完全可以组合成一个完整指令，比如：“如果客户要退款，你就让{!@ subagents.RefundAgent}用{!@ actions.ProcessRefund}处理订单{!@ variables.orderId}。” 这样，AI就没得含糊，每一步都清清楚楚。 还有一个很重要的叫“条件提示”，你可以在“如果什么什么”的语境里也塞进引用，比如：“只有当{!@ variables.priority}等于‘高’的时候，才去调{!@ actions.EscalateCase}。” 这样AI就能根据情况自动决定要不要用。 记住一个关键技巧：当AI可能犯迷糊，不知道该选哪个资源的时候，，你一定要直接引用，。直接写 {!@ ...} 会比含糊的描述强很多，这等于给了大模型一个明确的信号，它就更可能选对工具、拿到对的数据。所以，想让AI听话，就把引用当成你的指挥棒，点到哪儿，它打到哪儿。 好了，这个知识点记住了吗？简单说就是：子代理、操作、变量都用大括号加感叹号加艾特符号来点名，干脆利落，AI才不会瞎猜。

  ▶ 播放视频 查看详情
• 23

  Pattern: Avoid Conflicting Instructions

  第 96 页

  来，同学，我们看看这一页讲的是什么。 简单来说，Agentforce里的子代理，它们默认会用主代理那里定义好的“系统提示”——也就是那种角色设定、语气、行为准则之类的东西。就像家族遗传一样，主代理怎么说话，子代理就怎么说话。 但有时候，你希望某个子代理在特定场景下，表现得不太一样。比如，平时客服代理语气很正式，但碰到投诉的子代理，你可能想让它更严肃，或者更安抚。这时候，你不需要改动主代理，只要在那个子代理里，单独加一个“系统块”。 这个“系统块”里的指令，就会直接把原来继承过来的那部分给盖掉——我们叫“覆盖”。比方说，主代理设定“你要热情活泼”，但你在这个子代理里写“你要冷静专业”，那么它就在这个子代理里生效，其他地方还是保持热情活泼。 这么做的好处是，你不用把代理拆得乱七八糟。同一个代理体系下，各个子代理可以在不同上下文里，展示出不同的个性、语气或行为，而且互不干扰。指令冲突的时候，子代理自己加的这部分说了算。 所以记住：默认继承，但可以按需覆盖。这样子代理就能在需要的时候扮演不同的角色，处理不同的任务了。 好，这一页就讲到这里，有没有什么不清楚的？

  ▶ 播放视频 查看详情
• 24

  Instruction Hierarchy & Creating Multiple Personas

  第 97 页

  好，同学们，我们来看这一页的内容。 咱们上一节讲了代理能做什么，那这一页咱们聊聊代理脚本的执行顺序，也就是它的“指令层次结构”，简单说就是谁说了算。 假设你给代理写了一堆指令，它到底先听谁的呢？这里有一个明确的规则：，子代理级的系统指令，优先级最高，。什么意思呢？就是如果你把一个代理拆成多个小代理，每个小代理有自己的任务指令，那这些小代理的指令是老大，优先级最高。 那代理级的指令呢？它就充当一个“后备”角色。当子代理没有明确说该怎么做的时候，代理才会回过头去看自己本级的指令。这就像你给团队定了个大方向，但每个组员具体做事的时候，如果有他们自己的操作手册，他们优先按手册办；手册没写到的，再用你的大方向兜底。 但是，问题来了——如果代理级的系统指令和子代理的推理指令互相矛盾了，怎么办？比如你告诉子代理“解决问题的用词要严谨专业”，而代理级又说“整体风格要热情活泼”，它就懵了。代理会努力去解决这个冲突，但结果可能不按你的预期来，出现一些意想不到的行为。这就叫，意外行为，。 为了避免这种尴尬，Salesforce提供了一个工具叫，系统重写，。它的原理很简单粗暴：当发生冲突时，不纠结了，直接用新的指令显式替换掉旧的，让优先级更明确。这样就能确保代理不会左右为难。 另外，我们还可以灵活地给代理创建，多个角色，。举个例子，你同一个代理，既可以扮演“技术支持专家”——用精确的水语、诊断步骤去回答技术问题；也可以切换成“创意集思广益伙伴”——用热情、富有想象力的语言来帮你头脑风暴。 那什么时候用，覆盖，功能呢？就是当子代理之间有冲突，或者不同场景需要完全不同的语气时。比如两个子代理一个要严谨，一个要活泼，你就可以通过覆盖，强制在某个环节把语调换成你想要的样子，避免代理自己乱选。 总结一下：记忆这个层次——子代理指令权重最高，代理级兜底，冲突就用系统重写，多种风格靠角色切换和覆盖来精准控制。这样你的代理就不会精神分裂啦。 好了，这一页就这么多。有什么问题随时打断我。

  ▶ 播放视频 查看详情
• 25

  Pattern: Subagent Transitions

  第 98 页

  好，我们来看一下这张幻灯片的内容，主要讲的是Agentforce里“转换”这个概念。咱们用大白话把它讲清楚。 你可以把“转换”理解成，在Agentforce里把任务从一个子代理（也就是一个处理特定问题的专家）手里，转交给另一个子代理。就像你打电话给客服中心，前台客服听完你的问题后说：“这个事情需要转给技术部门的同事来处理。”然后电话就转过去了。这里的“转交”动作，就是Agentforce里的转换。 那怎么触发这种转换呢？有三种常见的方式。 第一种，把它变成一个“推理操作”，让大语言模型自己来判断。比如，用户在对话里提到了退款，模型一想，这事儿得财务代理来管，它就自动触发转换，把对话交给财务代理。 第二种，设置“条件”来确定性地执行。这个更直接，比如你写了一条规则：如果用户的输入里出现了“重置密码”这个词，就强制转到账户支持代理。这时候不看模型判断，完全按条件来。 第三种，是在一个操作完成后“链接”过去。比如订单查询代理查完了订单状态，然后自动把对话转去满意度调查代理，让用户打分。 要记住一个关键点：转换是单向的。一旦触发转换，Agentforce会扔掉当前子代理脑子里记着的所有临时对话记忆（也就是提示信息），切换到新的子代理，就好像接力赛里把棒子交给下一个人，交完之后，之前那个选手就退场了，不再参与后面的对话。这样新子代理就能全身心处理它自己的任务，不受之前上下文干扰。 这样讲，转换的概念是不是就清晰多了？它就是Agentforce里让不同专家代理无缝衔接、协同工作的桥梁。

  ▶ 播放视频 查看详情
• 26

  Reasoning vs Deterministic Transitions

  第 99 页

  同学们，我们来看一下今天的这个Slide，讲的是两种不同的“过渡”方式。大家先别被名字吓到，过渡其实就是让代理从一个任务切换到另一个任务的跳转方法，在Agentforce里非常重要。 我们把过渡分成两大类：，推理转换，和，确定性转换，。 先说推理转换，它就像一个“可选工具”，完全由大语言模型来决定要不要用。你在系统里会看到它用 `@utils.transfer_to` 这个标记来公开。它可以被“可用时间”过滤，就是说只有规定时间段内，模型才能选择它。而且在提示语里，你要清楚地告诉模型什么时候该调用这个转换。说白了，这是给LLM的自主权，让它根据上下文去判断，像调用一个函数一样去跳转。 另一种是确定性转换，它不依赖模型选择，而是根据预先写好的规则直接执行。你在指令里不会看到 `@utils`，它更像一个写死的路由。最常见的一种是，基于状态的条件转换路由，，当某个状态条件满足时，自动转到下一个节点。还有一种是，连锁转换，，它会在某个动作执行完成后自动触发，不用再额外判断。 这里有几个关键提示大家一定要记住： 第一，尽量使用 `go_to_predict`，这是一种安全、规范的跳转方式，会帮你避免很多混乱。 第二，谨慎使用确定性转换。因为它不经过模型权衡，一旦条件设错了，就会直接跑下去，不给你挽回的余地。 第三，，转换的顺序非常关键，，一定要把转换条件放在前面，避免系统先执行一堆无用的处理，浪费资源。 第四，也是最重要的一点：，绝对不要在子代理之间搞出无限循环的转换，。比如A转到B，B又转回A，条件还没设好，就会死循环，这可是Agentforce的大忌。 总结一下，推理转换让模型自己选工具，确定性转换靠规则直达；你得安排好他们的顺序，用好 `go_to_predict`，躲开循环陷阱。这样你的代理流就能既聪明又高效了。 好了，这个Slide就讲到这儿，有问题的同学随时打断我。

  ▶ 播放视频 查看详情
• 27

  Pattern: Using Variables Effectively

  第 100 页

  同学们好，咱们今天来聊聊 Agentforce 里一个看似基础，但用好了能让你的代理特别聪明的概念——变量。 你可以把变量想象成代理的一个“小记事本”。它专门用来记东西，记什么呢？记代理当前的状态。而且这个状态非常重要，它可以在你和代理对话的每一轮之间传递，甚至当代理去调用另一个更专业的“子代理”帮忙时，这份记忆也能带过去。这样，代理就不会聊着聊着就忘了之前说过什么。 那我们要在这个小记事本上记多少东西呢？这里有个技巧：要战略性使用，只记重要的信息。千万别什么都往上写，比如把用户说的每一句话都存下来，那就像给代理戴上了镣铐，反而把它限制死了，让它的回应变得死板。所以要学会精简，只跟踪关键内容。 那么，具体哪些东西值得记呢？通常有这么三种情况： 第一种，是需要反复用的值。比如用户一上来说了自己的名字，你把名字存进变量里，后面每次跟用户互动都可以直接叫出名字，显得自然又贴心。 第二种，是存储动作的输出。代理执行了一个操作，像查了一下账户余额，这个查出来的数字，你就随手记在变量里，后面做判断或者报价的时候，随手就能用。 第三种，就是用在“when”条款里。你可以拿变量里的值来设条件，比如“当余额大于 1000 时，自动触发某个流程”。这样代理的行为就能根据当前状态灵活变化了。 简单总结一下，变量就是代理的随身记忆，用它来记关键状态，省着点儿用，你会让代理变得更聪明、也更灵活。好，关于变量这一页的内容，咱们就先说到这儿。

  ▶ 播放视频 查看详情
• 28

  Variable Patterns: Init, Store, Share & Slot Fill

  第 101 页

  同学们，我们今天聊一个在Agentforce里写自动化流程时特别实用的小技巧——关于变量怎么初始化、怎么存结果、怎么在不同步骤之间传递信息。 咱们打个比方，你写条件判断的时候，如果变量压根没给过值，就容易出错。所以最好是先给个合理的默认值——比如后面要从接口拿数据，你就先用空字符串；标记状态的开关，默认设成假。但有一点要记住，那种必须由用户提供的关键值，别急着初始化，就让它空着，这样系统能明确知道这个值还没被填上。 接下来，当你运行了一个动作，并且它的输出以后还会用到，不管是拿来做条件判断还是给其他动作当输入参数，都要养成习惯——把输出结果存到一个变量里。这样你后面引用起来才清晰，也不会重复调用浪费资源。 还有一个跨代理传数据的场景，比如说主代理调用了子代理，希望子代理返回的结果能被其他地方继续使用。这时候就可以在子代理里运行一个动作，把输出存到一个全局变量里，这样一来，其他代理也能读取到，信息就共享开了。 最后讲一个特别巧妙的“槽填充”技巧。有时候你希望让大语言模型自己去推理填充变量的值，而不是写死逻辑，那就可以直接在变量值的位置填三个点——省略号。系统见到省略号，就会调用LLM的推理能力去动态决定这个值。但要留心，这个功能只对LLM调用的顶层动作的输入生效，如果是确定性执行的那一串动作链，里面的输入是不能用省略号的，得自己提前逻辑控制好。 总结一下：合理默认值、及时存结果、全局变量共享、以及用省略号激发推理，这四个点能让你的Agentforce流程又稳又灵活。好，这个小节明白了的话，咱们翻下一页。

  ▶ 播放视频 查看详情
• 29

  Pattern: Using List Variables

  第 102 页

  好，我们来看一下 Agentforce 里的列表变量，也叫集合变量。你可以把它想象成一个购物清单或者待办事项列表，只不过这个列表是给代理用的，用来存放一组数据。 这个列表能装什么类型的东西呢？它很灵活，可以装文本、布尔值、数字，甚至是复杂的对象，只要在 Agentforce 里支持的变量类型，都可以放进列表里。 那怎么用呢？其实在任何你能用普通变量的地方，都可以使用这个列表里的某一项。需要注意的是，列表的索引是从 0 开始的，也就是说第一项的编号是 0。所以如果你想拿列表里的第一个值，写法就是 @variables.YourVariable[0] — 在变量名后面直接跟上方括号和索引号。 这样代理就能轻松地存储和遍历一批数据了。下次练习的时候，可以试着给列表添加几个不同数据类型的值，然后用索引把它们取出来，你会发现它非常顺手。

  ▶ 播放视频 查看详情
• 30

  Declare, Reference & Iterate Through Lists

  第 103 页

  同学们，咱们来聊聊Agentforce里一个很实用的概念——列表变量。你把它想象成一个购物清单，里面可以存好多东西，用起来特别灵活。 那怎么创建一个列表呢？很简单，用`list[样式]`的写法。比如 `list[text]` 就是文本列表，`list[number]` 就是数字列表。你还可以给它初始化，用`= []`表示一个空的列表，就是一张白纸，等着往里面加东西；或者你直接给一些默认值，比如`= [“苹果”, “香蕉”]`，这样一上来就有东西了。 想从列表里拿某个具体的项目怎么办？我们用括号符号，记得前面加个@来表示这是一个变量。比如你的列表叫`ShoppingList`，想要第一项就写`@ShoppingList[0]`。注意啊，计算机里的计数是从0开始的，所以`[0]`拿的是第一个，`[1]`拿的是第二个，以此类推。 更厉害的是，这个索引值还能用变量来动态决定。比如你有个变量`@Index`，值是2，那`@ShoppingList[@Index]`就是拿第三项，这样程序就很灵活，可以随着情况变化去取不同的东西。 拿到列表项后，你就可以像用普通变量一样，把它放到条件判断里。比如判断`@ShoppingList[@Index]`是不是等于“苹果”，如果是，就触发某个动作。 那怎么知道列表里有多少件东西呢？用`len(@Variables.MyList)`，这个函数会告诉你长度，比如有5个东西就返回5。这个长度在写提示语、过滤条件或者做判断的时候特别有用，比如你可以检查`len(@List) > 0`看看列表是不是空的。 最后说一个重点：Agentforce的脚本里没有传统的for循环，不能自动遍历列表。那我们要逐个处理列表项目怎么办？我们手动模拟循环：你可以设定一个索引变量，比如叫`Index`，初始值0。每次处理完当前项，就把`Index`加1。然后通过条件判断，只要`Index`小于列表长度，就继续处理。这样每次循环就手动增加索引，一个接一个地处理，直到完成。 所以记住这个好习惯：当你想要逐个处理列表项目时，一定要把列表和一个索引变量配对使用。这样就能在Agentforce里实现类似循环的效果了。 好了，这部分就是列表变量的重点用法。大家试着在脑海里构建一个购物清单的例子，想想怎么创建、读数据、判断和逐个处理，马上就能掌握啦！

  ▶ 播放视频 查看详情