课程介绍
同学们，今天我们来聊聊Agentforce DX。你们可能已经听说过Salesforce DX，它是一套让我们在Salesforce平台上构建、测试和发布应用的工具。那Agentforce DX呢，就是专门为“代理”扩展出来的工具包，相当于给DX插上了代理的翅膀。 想象一下，平时你可以在Agentforce Builder里点一点、拖一拖，就能建一个代理出来，很方便。但是，在真正的现代开发流程里，尤其是DevOps团队，一切都要有版本控制，所有东西都得像代码一样存到Git仓库，确保可追溯、可回滚。代理也一样，它本身就是一种元数据，就像你自定义的字段、对象、Flow一样。 这时候Agentforce DX就派上用场了。它提供了一堆命令行工具（CLI）和VS Code插件，让你不用总窝在Agentforce Studio图形界面里，而是在你熟悉的终端或编辑器里，就能创建、预览、测试代理。更棒的是，你还可以用这些命令把代理的元数据从一个环境迁移到另一个环境，比如从开发环境推到UAT再上生产，全程都走版本化、自动化的流程。这样，代理的开发就完全融入你们团队已有的CI/CD流水线，靠谱又高效。 好啦，这就是Agentforce DX的核心价值——让代理开发从“点点做做”升级到专业DevOps模式。下节课我们来实际敲几个命令试试。有疑问随时提出来哦。
课程章节
本课程共有 25 个章节
-
1
What is Agentforce DX?
第 128 页来，同学们，咱们今天要聊的是 ，Agentforce DX，。 简单来说，它就是让 Salesforce DX 这套开发工具也能很好地和咱们的「代理」一起工作。 那最关键的一个点是什么呢？ 你记住一句话—— ，“代理”本质上就是元数据，。 就跟你自定义的字段、流程、Apex 类一样，都是可以管理的配置，所以 ，你完全能把代理放在版本控制里，，比如 Git，这样就能很好地追踪变更、协同开发了。 接下来你会发现一个特别灵活的地方： 你可以自由切换 ，低代码工具， 和 ，专业代码工具，。 比如，先在可视化界面里用 ，Agentforce Builder， 拖拖拽拽快速搭个原型，然后想精确调整的时候，就切到 VS Code 里改代码，或者用 Salesforce CLI 敲命令行。两者并不冲突，反而能互补。 那日常的开发节奏大概是怎样呢？ 你可以这样迭代—— 现在本地用你熟悉的代码工具创作好代理的元数据，然后发布到你的测试组织里； 接着，进到 Builder 这种可视化界面微调一下； 调完之后，别忘了把改动检索回本地，然后签入代码仓库。 就是这样循环往复，两端都能发挥最大优势。 测试这块也一样，你可以选纯代码方式的测试，也能用低代码的测试工具，看你习惯怎么来。 另外多说两句，如果你在使用过程中有想法或发现问题，官方可以通过 ，GitHub 仓库，接收反馈，所以有什么建议可以提上去。 还有就是，记得留意咱们的，每周发布说明，，CLI 更新很勤快，常会有针对 Agentforce 的命令增强，别错过新功能。 好，这块 Simon 讲得比较简洁，但核心你都 get 到了——代理就是元数据，可以和 DX 工具链无缝集成，灵活切换开发方式，迭代发布、测试，然后持续跟踪改进。 还有不清楚的，课下随时找我。
-
2
Set Up Your Development Environment
第 129 页同学们，今天咱们来聊聊怎么搭建 Agentforce 的开发环境，也就是咱们说的 DX 环境。其实啊，这个步骤跟普通的 Salesforce DX 环境搭建非常像，只不过多了几个专属于 Agentforce 的配置。别担心，很简单，我们一步步来。 首先，你需要在电脑上装好开发工具。就是咱们最常用的 VS Code，还有 Salesforce CLI 命令行工具，再加上 Salesforce 扩展包。这些都装好之后，你就能在 VS Code 里愉快地写代码了。 接下来，你要考虑用什么环境来开发。有两个选择：一个是 Sandbox 沙箱，另一个是 Scratch Org 临时开发组织。沙箱比较稳定，适合有现成数据或者要跟团队协作的时候用。Scratch Org 呢，干净、可重复创建，特别适合新功能开发和测试，用完就丢，不心疼。根据你的项目情况选一个就行。 然后，别忘了在你的 Salesforce 组织里开启必要的功能。你需要确保 Einstein 平台服务和 Agentforce 功能都已经启用。这个一般是在设置里的“Einstein 设置”和“Agentforce 设置”里打开，按提示操作就好。 环境准备好了，我们就在 VS Code 里创建一个 Salesforce DX 项目。创建好后，你要把项目关联到你刚才选的开发组织上，我们叫“授权组织”。用 CLI 命令 auth 一下就行，很方便。 最后，还有一些收尾的设置：需要给相关用户分配好系统权限，让用户能访问 Agentforce 的相关对象和功能。另外，最好创建一个默认的代理用户，这个用户就是你的 Agent 在运行时使用的身份，这样就能避免权限问题。 这么一圈走下来，你的 Agentforce DX 环境就搭建完成了，可以开始动手写第一个智能代理了。咱们休息一下，下节课继续深入。
-
3
Install Pro-Code Tools
第 130 页同学们，我们接着来看，做Agentforce开发，最亲近代码的工具其实就两个：，VS Code，和，Salesforce CLI，。 你可能会问，VS Code大家都知道，但光秃秃的可不够。我们要给它装上一个，Salesforce扩展包，，一下子功能就强大了。这个扩展包里装着很多东西，我来给你数一数： - 首先是，Agentforce DX扩展，，它把整个Agentforce的开发体验直接集成到编辑器里； - 然后是，代理脚本语言服务器，，专门给我们写的代理脚本提供语法支持，写错了马上能看出来； - 当然也少不了，Apex语言服务器，，Apex代码的补全、检查全靠它； - 还有一个很实用的，Apex Replay调试器，，它能帮你回放日志，一步一步排查问题； - 最重要的是，Agentforce Vibes，，这是一个AI辅助编码的功能，写代码的时候它会智能地给你建议，就像有个小助手在旁边。 另外，如果你不想在本地装环境，可以直接用，Agentforce Vibes IDE，，它其实就是一个基于Web的VS Code，所有东西都帮你预装好了，打开浏览器就能写，非常方便。 除了这些，你还可以用别的AI工具，比如，Cursor，或者，Claude Code，。只要安装好Salesforce CLI，再去，sf-skills，这个GitHub仓库下载Agentforce的“技能”就行。 注意这个“技能”啊，你可以把它理解成一个，存着指令的文件夹，，代理学会之后，就能自动发现并使用它来完成任务了。这样，不管你偏爱哪个AI工具，都能快速上手Agentforce的开发。 好，这一页的核心就是这些，先有个概念，我们接下来会带大家实际操作一遍。
-
4
Developer Environments
第 131 页嘿，朋友，咱们今天聊聊在做Agentforce开发的时候，到底选哪个环境更合适。关键就看一点——你的代理需不需要数据库里的真实数据。 先记住一个简单的原则：如果你的代理要用到企业已有的数据，去模拟、测试、优化它的行为，那选，沙箱，就对了。沙箱是什么？它就是生产环境的副本，带着你的元数据，数据也可以有。尤其是Developer沙箱和Developer Pro沙箱，这两个特别适合Agentforce DX的开发流程。因为它们里面有数据，你可以结合Data 360去训练代理，让代理更聪明，更贴近真实业务。这就是最成功的代理诞生之路。 那如果你只是做纯代码、配置的源码驱动开发，不依赖数据，只是想快速搭个东西验证想法，那，Scratch组织，很快很方便，几秒钟就建好一个空环境。但你要注意，Scratch组织没有数据库，是空的。所以做Agentforce如果要用到数据，它就不行了。 所以，总结一下：搞Agentforce DX，强烈建议你在沙箱里干活。当然咯，如果你只是想学一学、做个小实验，你还可以用一个免费的，Developer Edition组织，，只要它启用了Agentforce和Data 360，同样可以用来开发。这样你就不用担心没环境啦。 好了，这个选择其实很简单，记住：要数据，上沙箱；纯码农快速试错，Scratch也行。咱们就按这个来选环境吧。
-
5
Create DX Project, Authorize Org & Agent User
第 132 页同学们，我们翻开这一页，来看看实际动手搭建Agentforce之前，需要做哪些准备。这里面的步骤其实很顺，我们一个点一个点地讲。 首先，当你把命令行工具和VS Code扩展都安装好之后，第一件事就是在你的Salesforce组织里把Einstein和Agentforce的功能打开。这一步相当于拧开总开关，不开的话，后面所有跟代理相关的功能都用不了。 接下来，我们要创建一个新的DX项目。Salesforce贴心地提供了一个“代理模板”，你不用从零写配置文件，直接基于这个模板生成项目就行。这个模板里不仅包含了示例代理的元数据，还帮你配好了一个临时组织需要的所有设定，相当于拎包入住的样板间，我们可以马上在里面做实验。 然后就是身份验证。你得让本地项目能和你的沙箱或者开发者版组织安全地连上。这有两种方式：第一种最直接，就是在浏览器里跳出一个登录页面，你输入用户名密码授权一下就好。第二种是给自动化流程准备的，也就是基于JWT的CI/CD认证，适合放在持续集成流水线里，不需要人手动盯着。通常情况下，我们学习阶段直接用浏览器登录就可以。 接下来说说权限。如果你本身就是系统管理员，那么恭喜你，所有的权限都有，不需要额外配置。但如果你是用普通用户去开发或者测试，就得注意了：非管理员需要拿到特定的“发布”和“预览”权限，才能去构建和测试代理。没这些权限的话，可能连新建代理的按钮都看不到。 最后，我们要为代理创建一个默认的运行用户。这是一个很巧妙的命令，叫做`org create agent-user`。你只要在命令行里执行它，系统就会自动帮你创建一个新的用户，同时给它挂上正确的配置文件和权限集。你不用手动去翻几十个权限，一个一个打勾，直接一步到位就行。这个用户就是将来代理在跟客户对话时代表的那位“幕后同事”。 好，这几个准备工作做完，咱们就可以正式开始设计和配置我们的第一个Agentforce代理了。下一页我们来实实在在地跑一遍命令。
-
6
Author an Agent with Agentforce DX
第 133 页同学们，我们来看看这一页的内容，讲的是，创作代理，。这个听起来有点专业，但其实很好理解。 创作代理，简单说就是当我们想要在 Agentforce 里做一个代理时，需要先生成它的，代理脚本文件，，然后把这些文件发布到你的开发组织里。这就像给机器人写一份行动指南。 特别的是，这份代理脚本把，自然语言的灵活性，和，编程语言的可靠性，结合在了一起。也就是说，你可以用接近我们平常说话的方式来描述代理要做什么，但它背后又有代码一样的准确逻辑，不会模棱两可。 那么，这些脚本文件存在哪呢？它们都被放在一个叫 ，AiAuthingBundle， 的元数据组件里。你可以把这个 Bundle 想象成一个“创作包”，里面装好了代理所有的脚本和配置，是代理的完整蓝图。 那怎么拿到这个创作包呢？有两种方式： - 第一种，你可以在你的 ，DX 项目里从头开始生成，它，就像新建一个文件一样，自己一点点写。 - 第二种，你可以，先在组织里创建一个代理，，比如用设置界面搭好，然后再用检索命令把这个代理的创作包，拉取到本地项目中，，这样就能看到它背后的脚本了。 这页的核心其实就是告诉我们，代理的脚本是打包在 AiAuthingBundle 里的，而你可以选择先写代码再部署，或者先在界面上搭好、再回头研究它的脚本。两种路径都很灵活。 好了，这一页就讲这么多，大家记住“自然语言加代码”这个特点，还有 AiAuthingBundle 这个名字就行。
-
7
Workflow for Authoring a New Agent
第 134 页好，各位同学，咱们今天来看一下创建一个新代理的工作流程，其实没有你想象中那么复杂，拢共就五步。我慢慢讲，你仔细听。 --- ，第一步，从一份蓝图开始——YML文件。， 你先不用急着写代码。你要做的，是告诉系统“我想要一个什么样的代理”。这时候，系统会动用大语言模型，根据你的描述，自动帮你生成一个YML文件。这个YML文件就像是代理的灵魂清单，里面记录了这个代理长什么样、由哪些子代理组成、它擅长处理什么任务。所以第一步的核心，就是让AI帮你把想法先翻译成一份规范文件。 --- ，第二步，生成一个完整的创作包。， 有了YML这个蓝图，接下来系统会帮你打包——生成一个创作包。这个包里除了刚才那份YML，还包含了所有需要的脚本文件。你把它想象成一个旅行箱，走到哪，拎起来就能开工，不用东拼西凑找零件。 --- ，第三步，打开VS Code，真正动手写脚本。， 这个环节，我们会在VS Code里编程。好处是什么？它对你的脚本支持是完整的，语法高亮、智能提示、报错检查，一样不少。你在这里可以放心大胆地调代码，效率会高很多。 --- ，第四步，让代理演一遍看看——预览测试。， 写完一段脚本，你是不是就想知道它到底能不能用？这时候就可以预览。有两种模式：一种是模拟模式，就像彩排；一种是实时模式，等同于正式演出。你可以反复在这两种模式之间切换，一遍遍去测，去改，直到它表现得像你期待的那样。 --- ，第五步，发布，让它真正活起来。， 测试满意了，把这个创作包发布到你的组织里。系统就会自动帮你生成底层那些复杂的元数据，代理就正式上线服役了。 --- 这里还有一个小细节，你要记住：在整个过程中，系统会不断更新你的收件箱。你把它当成真相的唯一来源——每一步的状态、成功与否、错误信息，全都会清晰地推送到那里。所以养成习惯，随时瞟一眼收件箱，你就不会迷路。 --- 总结一下，这五步就是： 1. 让AI帮你生成YML蓝图。 2. 获得完整的创作包。 3. 在VS Code里好好写脚本。 4. 不断预览、测试、打磨。 5. 发布上线。 听起来是不是挺顺畅的？其实Agentforce就是希望把复杂度藏到背后，让你可以专注于设计代理本身。好，这一页我们就讲到这里，下一步咱们深入看看那个YML文件里面到底写了什么。
-
8
Workflow for Retrieving & Modifying an Existing Agent
第 135 页好，我们来聊聊，如果你先在图形化的 Agent Builder 里搭好了代理，再想把它搬到你的 DX 项目里继续开发，该怎么办。这个流程跟我们上一节讲的从零开始生成新代理，有一点点不一样，但别担心，很容易上手。 你可以这样想：Builder 是一个可视化的工作台，你在上面拖拖拽拽、配好对话、挂上动作，很快就能得到一个能说话的代理。但有时候，你希望对这个代理做一些更复杂的代码级定制，比如调整底层逻辑、加入一些动态判断，或者把它纳入完整的版本控制。这时候你就需要把 Builder 里的成果，原封不动地“搬运”到你的 DX 项目里。 怎么做呢？首先，你还是在 Builder 里面老老实实创建好代理。创建的时候，Builder 会悄悄帮你生成一套“代理脚本文件”——你可以把它理解成这个代理的原始蓝图。这些蓝图记录着代理的角色、指令、用到的工具等等所有配置。 接下来就是关键的一步：搬运。我们不用手动下载拷贝，直接用一条 Salesforce CLI 命令就能搞定。你打开终端，在项目目录下执行 sf project retrieve start，但要指定检索的元数据类型。重点需要拉取两种东西：一个是 AiAuthingBundle，也就是“AI创作捆绑包”，它里面装着你在 Builder 里编排好的整个代理逻辑；另一个是 Agent，这是代理本身的定义。只要把这两个元数据类型指出来，命令就会自动把你在 Builder 里做的所有工作，整齐地复制到你的本地 DX 项目里。 一旦搬运完成，你就可以打开项目文件夹，看到这些代理文件了。从这一刻起，后续的流程就跟你从头新建一个代理完全一样了。你可以用 VS Code 编辑代码，可以在本地跑预览和调试，没问题了再通过 CLI 发布到测试环境或者生产环境。整个编码、预览、发布的循环是一致的。 所以，这节课的核心区别就一句话：，起始点不一样，。我们之前讲的新建代理工作流，是直接在你的代码项目里把代理生成出来；而今天这个情况，是先在 Builder 里搭好，再检索拉回项目，然后继续开发。就像你先用草稿纸画好草图，再誊写到正式的设计稿里一样。 这个工作流特别适合那些既想快速原型化，又不想放弃代码灵活性的团队。业务人员可以在 Builder 里先做出一个能跑起来的版本，开发人员接过来直接深入优化，两边都不耽误。 好了，这个特殊的小变化你明白了吗？我们接下来看下一个知识点。
-
9
Generate an Agent Spec File
第 136 页今天我们来聊聊Agentforce的，代理规范，，听起来有点专业，其实它就像一份说明书，用来定义你的代理到底是谁、怎么工作。 首先，代理规范是一个YAPL格式的文件，你可以把它想成一份简单的配置单。它里面记录了代理的基本信息，比如它的角色是什么、代表哪家公司，还包括一个由大语言模型自动生成的子代理清单。虽然它不是必须创建的，但我非常推荐你使用它。为什么呢？因为一旦你提供了这份规范，系统最终生成的创作捆绑包里，代理脚本就会更加贴合你的需求，定制化程度更高，而不是千篇一律的通用版本。 这份规范的结构也很直观，分成上下两部分。上半部分是你自己填写的，用来定义代理的属性，比如给它一个合适的角色、写清楚公司相关信息；下半部分则是由大语言模型自动生成的，它会根据你的需求，帮你列出一系列子代理，这些子代理是专门处理不同任务的帮手。 简单来说，代理规范就是你和AI共同完成的一张“代理身份证”，花一点点时间填好它，后面你的代理就会更聪明、更懂你。
-
10
Agent Spec Generation & Iterative Refinement
第 137 页同学们，今天我们来聊聊怎么用 `sf agent generate agent-spec` 这个命令来生成代理的规范文件。这相当于给你的 Agent 起草一份详细的“简历”，告诉系统它是什么类型、代表哪家公司、扮演什么角色、说话用什么语气。 运行命令之后，它会跟你互动，一个个问你这些问题，你按提示回答就行。最终命令会帮你生成一个 YML 文件，这个文件分成两大部分：最上面是代理的基本属性，就是刚才你填的那些信息；下面呢，是大语言模型自动帮你列出来的“子代理”列表——相当于把大代理的任务拆分成更细的小代理。 不过，第一次生成的子代理有时不够精准。想要拿到最佳结果，一定要学会“调试迭代”。你可以加一个叫 `--spec` 的标志，然后指向你刚才存的 YML 文件，这样命令就会在现有文件的基础上继续优化，而不是从头再来。每次只重点微调上面的代理属性，描述得越清晰、越具体，下面 LLM 给出的子代理列表就越好。 还有个实用的小技巧：在子代理的描述里面，你可以用自然语言直接加上一些提示。比如告诉它“请使用某个特定操作”，这样大模型就知道按你的意图去组合动作了。相当于你在悄悄给它一些内部的指导。 最后，在整个迭代过程中，别只盯着命令窗口。你可以在 VS Code 里随时手动打开 YML 文件，直接编辑上面的属性、或者调整子代理的描述，保存后再用 `--spec` 跑一遍命令。这样一步一打磨，做出来的代理规范就会越来越贴合你的业务需求。好，这一页的关键点就这些，大家可以动手试一下。
-
11
Generate an Authoring Bundle
第 138 页同学们，咱们今天聊的这个概念，就像是你想造一辆车，得先有一张设计图纸。Agentforce里的“创作包”，就是代理的这张设计蓝图。 简单说，它有个专业名字叫，AiAuthingBundle，，是一种元数据类型。别被术语吓到，它其实就是个容器，里面装着代理的关键信息，比如一个叫，.Agent Script，的文件，这个脚本就像代理的大脑，告诉它怎么思考、怎么做事。 那这张蓝图从哪儿来呢？有两种方式： - 一种是用系统默认给你的“样板模板”，像乐高基础套装，拿来就能搭。 - 另一种更灵活，你可以自己写一份叫，代理规范YML文件，的东西，从里面生成创作包，这样就能做出更贴合你需求的定制化代理。 最后提个醒，你在文档或者工具里，可能会看到“代理”和“创作包”这两个词换来换去，不用担心，它们指的就是同一回事儿。记住，创作包就是代理的配方，掌握了它，你就知道怎么造一个听话的AI助手了。
-
12
VS Code & CLI Bundle Generation
第 139 页同学们，今天我们来看一眼，在Agentforce里怎么快速创建一个代理的“创作包”。这就像我们盖房子之前，先要画个蓝图一样。 首先，你可以从两个地方发出“创建代理”的命令，一个是在VS Code里面直接用那个“Create Agent”按钮，另一个是通过命令行，也就是CLI，输入`sf agent generate`之类的命令。不管用哪种方式，最终结果都一样，就是生成一套初始的文件。 系统会问你想怎么生成。如果你是新手，我强烈建议你就用默认的模板，它会给你一个最基本的骨架，里面有一些样板代码，你回头往里面填自己的逻辑就好。如果你已经比较熟悉了，想要一步到位把好几个子代理的结构也提前定好，那你可以准备一个代理规范的YAML文件，用那个来生成，这样出来的代码就直接包含了你指定的那些子代理。 生成的东西会跑到一个叫`aiAuthoringBundles`的目录下面。这个包里最核心的文件是一个以`.agent`结尾的代理脚本文件，这就是你以后主要写业务逻辑的地方。另外还有一个同名的`.agent-meta.xml`元数据文件，它保存着代理的一些配置信息。 简单来说呢，就是两条路选：新手走默认模板，老手用YAML规范，输出到固定目录，得到你的代理蓝图。有了这个以后，我们就可以在上面继续修改，让代理真正去干活了。 好，接下来我们就可以实际看看怎么用这些命令了。
-
13
Code Your Agent Using
第 140 页好，我们来看这一页讲的是什么。它说的是，你拿到一个代理创作捆绑包之后，要怎么去自定义它呢？答案是，通过写代理脚本文件。你可以直接在VS Code里面写代码，因为有完整的语言支持，很方便。或者，如果你不想手写代码，也可以用Agentforce Vibes，这玩意儿能理解自然语言，你给它提示，它就能帮你生成代码。所以Agent Script的优点在于，它把自然语言的灵活性和编程那种确定性、可靠的行为结合起来了。你既能用说话的方式来引导代理做什么，又能得到精确可控的执行结果，这就是它的魅力。
-
14
Agent Script Overview & Coding Workflow
第 141 页同学们，咱们今天来聊聊怎么写代理脚本文件，这可是 Agentforce 开发里的核心活儿。别担心，VSCode 已经给我们准备好了全套的语言支持。打开那个 .agent 文件，你会看到语法高亮，不同功能的代码用不同颜色标出来，一目了然。如果写错了，它马上能揪出错误，就像有个小助教在旁边盯着。而且右边还有大纲视图，能把脚本里的符号结构整成树状图，让你对代码的骨架门儿清。 那咱们的开发流程一般是这么走的：你先打开 .agent 文件，然后开始写代码——你可以手敲代码，也可以用我们说的“氛围编程”（vibe coding）。写的过程中得时不时验证一下，就像做数学题，每做完一步就检查一下。觉得差不多了，就用预览功能跑跑看，实际测试一下你的代理表现如何。 说到氛围编程，这个特别有意思。你只要启用三个 Agentforce 技能，然后用我们平时说话的自然语言，比如“嘿，帮我检查订单状态，然后给客户发封确认邮件”，它就能自动帮你生成代码。是不是很酷？ 刚开始设计代理的时候，别一上来就整得太复杂。哪怕那些具体的操作还没建好，你也可以先在脚本里直接引用它们，心里有数就行。关键是找准那个平衡点：哪些步骤让确定性逻辑来处理，稳稳当当；哪些地方留给大模型发挥，让它灵活应变。这就是确定性和大模型驱动行为的黄金分割线。 最后，如果你们想找实战参考，别忘了去 GitHub 上搜 Agent Script Recipes 这个仓库，里面有很多现成的例子，直接拿来学、拿来用，进步会更快。 好了，关于代理脚本编码的核心，今天就说到这儿。大家动手试试，别怕犯错，练着练着就会了。
-
15
Vibe Coding, Sample Prompts & Validation
第 142 页同学们，咱们今天聊聊 Agentforce Vibes，一个特别有意思的概念。你可以把它想象成一个帮你打造“智能代理”的魔法工具箱。它里面主要提供了三种技能，咱们一个一个来看。 第一种叫“开发代理力量技能”。听名字就知道了，它专门负责构建和修改你的代理。比如，你要新建一个代理，或者给已有的代理改个名字，添一个子代理，添加一些它能执行的操作，甚至优化一下它的提示指令——这些常见的任务，这个技能都能帮你轻松搞定。 第二种是“测试代理力量技能”。代理建好了，能不能按我们预想的工作呢？这就需要全面的测试能力了。这个技能就能让你很方便地去验证代理的行为是不是正确。 第三种是“观察代理力量技能”。代理上线了，我们还得盯着它，看它运行得怎么样，有没有出问题。这个技能就是用来处理监控的，让你对代理的运行状态一目了然。 说到具体的使用，你可能会遇到一些常见的提示，比如“帮我重命名这个代理”、“给它增加一个子代理”、“添加一个新操作”或者“改进一下现有的指令”等等。这些需求，通过 Agentforce Vibes 都能自然地提出来，它明白你的意思。 当然，任何开发都离不开验证。你写的代理配置到底对不对呢？我们可以用两种常见方式来检查：一种是在 VS Code 编辑器里直接验证，另一种是通过命令行工具（CLI）。如果配置有错误，它会很清楚地告诉你哪里写错了，比如语法错误的具体位置，还会附上描述，方便你快速定位和修改。 最后，还有一个很灵活的地方。Agentforce Vibes 不绑定特定的工具。你除了用 VS Code，也完全可以使用其他你熟悉的人工智能辅助工具，比如 Cursor 或者 Claude Code。只需要安装好 Salesforce CLI，并且从 GitHub 把相关的技能下载下来，这些工具也能一样调用这些技能，帮你开发代理。 简单总结一下，就是三个核心技能（开发、测试、观察），配合方便的指令和验证方式，还能灵活对接你喜欢的 AI 工具，这就是 Agentforce Vibes 带给我们的代理开发体验。好了，这部分内容就是这些，大家理解了吗？
-
16
Publish an Authoring Bundle
第 143 页各位同学，大家好。今天我们来聊聊 Agentforce 里面一个很实用的操作——发布创作捆绑包。 听起来名字有点技术范儿，但其实很简单。你可以想象一下，你花了很多心思写好了一个代理脚本文件，也就是 Agent Script，里面定义了你的智能助手该怎么对话、怎么做事。但是光有脚本不行，我们得把它“激活”，变成真正能在系统里跑起来的机器人，以及配套的 AI 元数据。这个转化的过程，就叫做发布创作捆绑包。 它其实就是在你写代码或者用工具的时候，一键把脚本编译成正式可用的版本。如果你用过 Agentforce 的可视化 Builder 界面，你一定见过那个叫 “Commit Version” 的按钮，点了它，就相当于把当前的设计保存成一个新版本。用发布创作捆绑包的方式，就是这条路的“亲代码”版，也就是你通过程序自动来做这件事。 那具体发布的时候发生了什么呢？首先系统会去检查你的代理脚本文件，看看有没有语法错误、逻辑漏洞，先验证一下。验证没问题了，接着就帮你编译，把所有内容打包发布到你所在的 Salesforce 组织里，最后生成相关联的各类元数据，比如 Bot 定义、GenAI 模型配置等等。这样一来，一个新代理就诞生了，或者你现有的代理多了一个新版本。 所以，你可以把发布创作捆绑包理解成从“剧本”到“正式开机”的那一步。有了它，你写的智能代理才能真正上岗干活。好，这部分知识点就这么多，大家只要记住一句话：发布创作捆绑包，就是把你写的代理脚本安全、合规地变成组织里可运行的智能机器人版本。
-
17
Publishing Workflow: What Happens & How
第 144 页好了，现在我们来讲讲怎么把做好的代理发布到Salesforce组织里去。你可以把它想象成：你把写好的一堆指令交上去，让系统去检查、编译，然后生成真正能跑的机器人。 具体过程是这样的——当你执行发布命令的时候，系统会先验证你的代理脚本文件，看看语法对不对、逻辑有没有问题。如果验证通过，它就会把这个脚本编译成平台能用的东西，并且在你的组织中创建一整套相关的元数据。这里面的东西包括我们说的Bot（就是机器人本身）、BotVersion（机器人的版本记录）、还有GenAiPlannerBundle这种智能规划器的配置包，等等。这些元数据一起构成了一个能在组织里正常工作的Agent。 发布成功之后，这些生成的元数据通常会被自动拉回到你本地的DX项目里，这样你就能在代码里看到发布出来的结构。当然，如果你不想让它们被拉回来，也可以选择跳过检索这一步。另外还有一个细节：发布过程中，项目里会生成或更新一个叫Deliverle-Meta.html的文件，它记录了代理的映射关系，方便你查看和维护。 这里有一个关键点你要记住：，你只能发布还在草稿状态的、没有版本号的捆绑包，。如果某个捆绑包已经被版本化了，也就是说后面附带了一个数字版本号，那就不能再次直接发布了。所以，正式发布之前，确保你用的是未打版本号的草稿版本。 在操作上，你有两种方式。如果你在VS Code里开发，很简单，直接在`.Agent`文件上右键，选择“AFDX：发布此代理”就行。如果你喜欢用命令行，那就运行`sf agent publish bundle`这个命令，然后会弹出一个列表让你选择要发布哪个包。 但别忘了发布前最重要的一步：，一定要先部署你本地所有的Apex代码和Flow修改，。因为代理可能会依赖这些底层逻辑，如果Apex类或者流还没有部署上去，发布就可能失败或者运行出错。所以顺序一定是先部署Apex和Flow，再发布代理。 这样一来，一个代理就正式在组织里上线了，你可以开始配置和测试了。有什么问题随时问我，我们继续推进。
-
18
Synchronize Your Development Org
第 145 页好，我们来看这一页。无论你用的是写代码的工具，还是拖拽的低代码工具，都一定要记住一件事：让你的开发组织跟本地的DX项目始终保持同步。 为什么可以这样做呢？因为Agentforce里的代理，本质上就是一堆元数据。既然是元数据，那我们就能用标准的Salesforce DX命令，还有VS Code里面的那些常用操作，去检索、部署甚至删除这些代理。 那具体要管理哪些元数据呢？这里有两类，需要你特别留心。 第一类，是咱们在创作阶段弄出来的打包配置，英文叫 ，AiAuthingBundle，，你可以把它理解成“创作捆绑包”。这里面记录了你设计代理时的所有细节。 第二类，是当你把这个代理正式发布出去之后，运行时真正起作用的元数据，我们管它叫，代理伪类型，，也就是代理的“成品”状态。 所以，简单来说，你既要管好创作时的泥胚子（AiAuthingBundle），也要管好出炉后的成品（代理伪类型），这样整个开发到发布的流程就都妥妥待在版本控制里了。清楚了吧？
-
19
Retrieve, Deploy & Delete Agent Metadata
第 146 页同学们，咱们现在来看一下怎么用 ，metalics， 这个工具来管理和验证捆绑包，尤其是里面会涉及到的元数据类型和代理。 假设你要创建一个叫 `AiAuthingBundle` 的捆绑包，那你可以在命令里这样写： `--metalics 验证 创建 捆绑包 AiAuthingBundle:<api-name>` 这里的 `<api-name>` 就是你实际的 API 名称，记得替换掉。 这个命令不光能创建，还能帮你把捆绑包从组织里卸载掉、重新部署回去，或者干脆删掉它。不过要注意，一旦删除了捆绑包，和它关联的 Bot、Bot 版本，还有 GenAiPlannerBundle 也会一起被删除，这都是联动的。 如果你想一下子处理所有的版本，那就可以用，外卡，，这样就不用一个版本一个版本地操作了，会很省事。 那对于已经发布出去的智能代理呢，咱们可以用一个“缩写”来表示，这就是 `Agent` 这个，伪元数据类型，。写法是： `Agent:Agent_API_Name` 把 `Agent_API_Name` 换成你代理的名字就行。 另外要留心，当你，检索，一个已发布的代理时，它会把代理用到的 Apex 类和 Flow 也一块儿拉下来；但如果你只是，部署，或者，删除，这个代理，这些操作，只会影响代理本身的元数据，，不会碰到底层的 Apex 类或者 Flow，这样设计也是怕不小心改坏了业务逻辑。 最后再提醒一点：如果你的组织是，非源跟踪，类型的，那你就不能依赖系统自动去跟踪变更了，而必须，显式地指定，你要操作哪些元数据。千万不能想当然，不然很容易漏东西。 好了，关于用 metalics 处理捆绑包和代理的这几个关键点，就是这些。咱们接着往下看。
-
20
Agent Metadata: A Shallow Dive
第 147 页同学们，咱们现在看的这一页，讲的是开发代理时非常重要的基础知识——元数据类型。掌握这些，你就能明白代理从设计到正式运行的整个过程了。 简单来说，代理相关的元数据分成两大类：一类是，创作捆绑包，，你可以把它当成代理的，蓝图，；另一类是，代理元数据，，也就是，真正发布出来的代理，。 先说创作捆绑包，也就是蓝图。这里面最核心的就是 ，.agent文件，，其实就是 Agent脚本文件，你用来自定义代理的逻辑、指令，都在这里头。这时候代理还只是个设计稿，没有真正跑起来。 当你把这个蓝图发布之后，系统就会自动生成一套，链接在一起的元数据组件，，形成一个能干活儿的代理。这套发布后的元数据包括哪些呢？我快速给你数一数： - ，Bot，，就是机器人本身； - ，BotVersion，，机器人的版本，方便你管理更新； - ，GenAiPlannerBundle，，可以叫规划器捆绑包，它负责帮代理思考怎么拆分任务； - ，GenAiPlugin，，这个又叫做，子代理，，用来承担特定的子任务； - 还有，GenAiFlow，，也就是，操作，，它是代理可以执行的具体动作流程。 所以整个过程就是：你在蓝图里写好脚本，发布出去，蓝图就变成了一组可运行的组件，像乐高一样拼出一个完整的智能代理。以后你要修改，也是先改蓝图再重新发布，这样理解起来是不是就清晰多啦？ 好，这一块就这么简单，咱们继续往下看。
-
21
Metadata Types: Bundle & Agent
第 148 页同学们，今天我们来看一张很有趣的slide，它其实在讲一个“配方”和“成品”之间的关系。就像你烤蛋糕，先有食谱，然后才烤出蛋糕来。在Agentforce里，这个食谱就叫，创作捆绑包元数据，。 你可以把它想象成是一个蓝图，它存放在一个特定的文件夹里，叫`aiAuthingBundles`。这个蓝图里有两样东西：一个是`.Agent`脚本文件，你可以理解为写满了指令；另一个是`.bundle-Meta.html`，它像是一个说明书。这两样合在一起，就是还没发布的原始配方。 重点来了——当我们把这个蓝图发布出去之后，它就会变成活生生的，代理元数据，。代理元数据可不是一个东西，它是由几块拼图组成的： - ，Bot， 是最顶层的聊天机器人，就像一个大外框。 - ，BotVersion， 是这个机器人的特定版本配置，比如今天用的是v1.0。 - 把Bot和BotVersion加起来，我们就有了一个，基本的聊天机器人，。它能对话，但还不够聪明。 怎么让它变聪明呢？就要加入一个叫，GenAiPlannerBundle，的东西，这是推理引擎，相当于给聊天机器人装上了“大脑”。有了它，这个机器人就升级成了，智能代理，——可以自己规划、推理，做更复杂的事。 除了大脑，代理还得有手和脚。，GenAiPlugin， 就代表子代理，可以理解为帮手，专门处理某一类任务。而 ，GenAiFlow， 代表具体的动作，比如查订单、发邮件。这些全都组合在一起，就成了一个完整的智能代理。 所以记住这个简单的公式： ，Bot + BotVersion = 基本聊天机器人， 再加上 ，GenAiPlannerBundle，，它就摇身一变，成了，智能代理，。 最后一点很重要：发布之后生成的这些代理元数据，就跟你熟悉的Salesforce其他元数据一样，安安稳稳地住在标准的包目录里，既规范又好管理。 好，这张slide其实就是在告诉你，蓝图如何一步步变成可用的智能代理。大家理解了吗？我们休息一下，回来再看下一部分。
-
22
Preview and Debug an Agent
第 149 页咱们来看这一页内容，讲的是开发代理过程中的一个关键习惯——，多跟你的代理对话，多预览，。 你想象一下，我们写代码，写完肯定要跑一跑，看输出对不对。那代理也是一样的，你设计了一个对话流程，你怎么知道它会不会理解错用户的意图？会不会突然说一些你根本没设计过的话？只有多测试、多和它聊天，你才能发现这些问题。 所以这张幻灯片就是提醒我们：，在开发过程中，一定要定期去和代理交谈，，亲自问问它，看它怎么响应。这一步，我们叫，预览，。 预览能给你什么呢？它会展示出代理工作的“幕后细节”，比如它经过了哪些步骤、触发了哪个主题、用到了哪条知识，甚至还能看到它是怎么推理的。这样，如果你看到某个响应和预期不符，你就能顺着这些细节，很快找到哪里出了问题。比如，它本应该回答“退货政策”，结果去问了“物流查询”的主题，那你一看流程跟踪就明白了，马上就能调整。 这里还讲了预览的两种方式，对应不同的开发阶段： 第一种，，从本地的代理脚本文件预览，。就是你还在本地写`.agent`文件，没部署到服务器上。这时候你想快速看看效果，可以用，模拟模式，或者，实时模式，。模拟模式就是纯用你本地定义好的数据和逻辑来跑，不真的去调外部系统；实时模式则会调用真实的API或数据源，更贴近实际运行效果。 第二种，，从已经激活并发布的代理预览，。就是说你的代理已经部署上去了，别人能用了，但你还可以再私下预览它，检查线上表现。 那么，具体用什么工具来做预览呢？幻灯片提到了两个： - ，VS Code里的Agentforce DX面板，，里面有一个，Agent Tracer，选项卡。你在VS Code里开发的话，可以直接点开这个面板，跟代理聊天，右侧会显示出每一步的追踪信息，非常直观。 - 还有，代理预览CLI命令，，就是命令行方式。如果你喜欢用终端，或者在做自动化测试，可以用命令来启动预览会话。 所以，简单总结就是：，多预览，勤调试，用Agent Tracer看轨迹，快速发现意外表现，。你在动手做实验的时候，记得每改完一版，就去跟代理说说话，这能帮你少走很多弯路。 大家现在可以打开你的VS Code，试着用Agent Tracer预览一下你之前建的那个简单代理，体会一下这个工具怎么帮你排查问题。有不清楚的地方随时问我。
-
23
Preview Types, Modes & Trace Messages
第 150 页我们现在来看一下如何预览和测试你搭建的Agent。这一步非常重要，就像我们出门前要照照镜子，看看衣服有没有穿好。 你可以在两种情况下进行预览：一种是从你本地的脚本文件进行预览，也就是还没正式发布出去的时候；另一种是代理已经发布出去了，从已发布的版本进行预览。 我们先说本地预览。本地预览有两种模式可以选择：模拟模式和实时模式。 模拟模式，听起来就很安全，对吧？它只是模拟操作，完全不会碰你组织里的真实数据，所以没有任何风险。什么时候用呢？就是当你的Apex类和流程还没完全准备好，只是想先看看代理的对话逻辑通不通顺时，用模拟模式非常合适。 另一种是实时模式，这个就是真刀真枪地运行了。它会实际执行操作，所以能得到最准确的测试结果。而且实时模式支持Apex重放调试器，叫Apex Replay Debugger，这对开发同学来说很有用，可以捕捉到执行时的细节。 在预览过程中，还有一个非常强大的工具叫“跟踪消息”。它允许你检查后台确切的JSON交换内容。也就是说，你能看到代理是怎么理解你说的那句话的，它选择了哪一个操作，以及最终是怎么生成回复的。这就像给了你一副透视眼镜，能看清代理脑子里的思考过程，调试起来特别方便。 不过要注意一点，预览功能不是万能的。它不支持连接端点配置的测试，也就是说，如果你要测试外部系统怎么连进来，或者要做升级测试，这些在预览里是做不了的。遇到这种情况，你就需要先把代理发布出去，然后通过实际的连接端点来端到端地测试。 总结一下：先利用好本地预览的模拟和实时模式，加上跟踪消息，把内部逻辑打磨好；到了涉及外部连接或升级的时候，就发布出去测真家伙。这样一步步来，你的代理就会又稳又准。
-
24
VS Code Interactive Preview
第 151 页同学们，咱们这节课来看看开发Agent的时候，怎么一边写一边测，快速看到效果。这页幻灯片讲的是两个特别好用的预览工具，一个在VS Code里，另一个在命令行里。它们能让你像真的用户一样跟Agent聊天，还能随时调试，非常方便。 先说VS Code里的这个交互预览。怎么打开呢？很简单，你找到Agentforce DX面板，点开它，然后从列表里选一个你正在开发的座席——也就是Agent。接下来你可以选择用“模拟模式”或者“实时模式”开始对话。模拟模式不会真正调用外部的API或者触发任何真实操作，很适合做快速的逻辑验证。实时模式就会真的去执行流程，跟最终上线的行为几乎一模一样。 在实时模式下发消息的时候，你还可以打开一个叫“收件箱模式”的开关。这有什么用呢？它允许你把Apex调试断点跟消息流结合，这样你就可以用“Apex Replay收件箱”了——简单说，你就能够一步一步回放之前执行过的Apex代码，检查变量值，排查问题，就跟调试普通的Apex类一样。 聊天的过程中，VS Code里还有一个“Agent Tracer”选项卡，它会清清楚楚地列出Agent跟底层系统之间交换的每一条JSON消息。这些消息就是你的Agent的“思考过程”，你可以看到它理解了什么、调用了哪些动作、返回了什么数据。如果觉得某次会话需要分享给同事或者后续分析，你还能直接把整个会话下载成一个文件，这太棒了对吧？ 那如果你更习惯用终端呢，没事，Salesforce也给你提供了一个命令行工具，叫sf agent preview，也就是“SF代理预览”。在命令行执行这个命令，你同样能进行交互式预览。它支持实时模式，你可以通过参数指定一个输出目录，把会话记录保存下来；还能用标志开启Apex调试，跟断点结合起来排查问题。 总之，不管你是在VS Code的图形界面里点点点，还是在黑乎乎的终端里敲命令，这两个工具都能让你在开发阶段就反复地去测试、去打磨你的Agent，直到它表现完美。记住，开发Agent不是一蹴而就的，正是有了这么方便的预览方式，咱们才能快速迭代，把每一个对话分支都做到位。 好，这节课的工具就介绍到这里，接下来我们动手试试看。
-
25
Programmatic Preview & Session Trace Files
第 152 页同学们，咱们今天来聊一聊 Agentforce 的编程预览功能。这个功能特别适合那些喜欢用命令行、或者想在自己的自动化管道里测试 Agent 的同学。 你只需要记住四个简单的 CLI 命令，就能像写脚本一样去跟 Agent 对话。 第一个命令，`预览开始`，它负责开启一个预览会话。想象一下，这就好比拨通了一个测试专线，接通之后，后面的对话才能传过去。 第二个命令，`预览发送话语`，这个就是用来把你写的测试语句发给 Agent 的。每发一句话，就相当于在聊天框里输入一次，Agent 会返回它的回复。 第三个命令，`预览会话`，它能帮你列出当前还在活跃的会话。这样万一你同时开了好几个测试，也能轻松找到哪一个还在，不用搞混。 第四个命令，`预览结束`，就是挂断这条测试专线，干净地关闭会话。 这四个命令其实是专门为咱们自动化测试设计的，无论是放在 CI/CD 管道里，还是做振动编码代理的回归测试，都能用程序的方式去反复验证 Agent 的表现。 聊完命令，咱们再看看对话都记在哪儿了。预览功能会生成两类跟踪文件，帮你事后分析。 第一个文件叫 `transcart.json`，里面是完整的对话记录，包括时间戳、会话 ID、说话的角色以及每一句话的内容。这就像一份逐字稿，方便你回头去看用户和 Agent 到底聊了什么。 第二个文件是一种“杨森文件”，它会记录更底层的细节，比如意图是怎么识别的、有没有调用子代理、执行了哪些计划，还有完整的 API 消息。这份文件对开发调试特别有用，你可以看清 Agent 每一步的思考过程。 最后要记住一点，这个预览功能内部其实就是调用了 Agent 的 API，所以你在预览里测到的行为，跟线上真实调用的逻辑是完全一致的。这样测出来的结果才可靠。 好，这一页的重点就这些。大家有什么问题吗？
📋 课程信息
- 所属目录：ADG001
- 课程名称：Agentforce DX 开发
- 章节数量：25 个