课程章节介绍
同学们，咱们今天来说一说，怎么把 Agentforce 从开发环境搬到生产环境，也就是部署的前四个步骤。你记住，这几个步骤就像打包搬家，第一步先把钥匙配好，第二步把家当清单列出来，第三步把东西核对清楚，第四步是万一清单有出入时的补救办法。
第一步，咱们要用 Salesforce CLI 把本地环境搭起来。很简单，打开命令行，先用 `sf org login` 连上你的源组织，也就是开发用的沙盒，然后再同样用 `sf org login` 连上目标组织，比如生产环境。这样两个地方的“钥匙”就都有了，后面才能互相传东西。
第二步，创建一个标准的 Salesforce DX 项目。核心就是一个清单文件，我们管它叫 manifest。你可以直接用命令 `sf project generate` 或者手动建一个 `package.xml`，这个清单就相当于你准备搬走哪些东西的列表。
第三步，就来写这个 `package.xml` 清单。针对 Agentforce，最常见的写法有三种。第一种是“全搬”模式，用通配符星号把所有代理都列进去，但是提醒你，要是组织特别大，代理特别多，用通配符可能会拖慢部署，悠着点用。第二种是“精准搬运”，只搬一个具体的代理版本，这时候你要在清单里指定三个关键成员：`BotVersion`、`GenAiPlannerBundle` 和 `AiAuthingBundle`，一个都不能少。第三种情况是“版本对不上号”——比方说你在开发时保存了好几次，但提交发布的次数跟保存次数不一样，就叫不匹配的版本。这时候你的清单就得针对这种不匹配的版本来写，不能按常规方式来。
第四步是可选的，但很救命。当真的遇到版本不匹配的时候，你需要找出正确的映射关系。怎么做呢？去查一个叫 `guardle-meta.html` 的文件，它藏在你的项目里，打开后找目标元素，它会告诉你到底哪个保存版本对应哪个提交版本，你就照着它给出的映射去修正清单，这样部署才不会报错。
好了，前四步讲完，其实就是“连上两头、建好清单、按三种类型去定义、出错了查映射”。你先把这四步弄熟，后面部署就稳了。