课程章节介绍
今天我们来看看在 Agentforce 里部署代理时，必须了解的三种主要表现模式。别被“表现模式”这个词吓到，其实就是三种不同的部署策略，每种都有自己的适用场景，我慢慢说给你听。
第一种叫全代理模式。它的思路很简单粗暴：对所有相关的内容都使用外卡来匹配。外卡大家应该知道，像星号那种，代表“全部”。这样做的好处是一次搞定所有东西，但问题也随之而来——如果你的组织很大，元数据非常多，这种全盘扫描就很容易导致超时。所以实际工作中我们不建议一直用全代理模式，更好的做法是明确列出你要部署的特定类型，这样不但稳定，速度也快得多。
第二种是单代理版本模式。当你需要把某一个确定版本地的代理部署到生产环境时，就要用这种模式了。在这个模式下，你会非常精确地指定出一个已提交的版本，并且把跟它关联的几个核心成员一起带上：BotVersion，也就是机器人本身的主体版本；GenAiPlannerBundle，它负责智能规划和决策；还有AiAuthingBundle，它管身份认证和授权。除了这三巨头，你还得把相关的支持元数据也一起声明出来，比如 Apex 类、Flow 流等等。这样一来，部署的内容就很聚焦，不会多也不会漏。
第三种叫版本不匹配模式。它的场景比较特殊：当你发现 AiAuthingBundle 的版本号跟 Bot 或 BotVersion 的版本号不一致时，就需要用这种模式来处理。举个例子，可能认证包不小心升了级，但机器人版本还没同步上去，这时部署就会遇到冲突。版本不匹配模式就是专门应对这种“不同步”情况的，它能帮你有针对性地处理好版本差异，保证部署顺利进行。
这里我还要特别强调一个命名惯例，大家一定要记清楚，因为很容易搞混。BotVersion，也就是机器人主版本，它的命名后缀是用点v加数字，比如 .v1、.v2。GenAiPlannerBundle 这个规划器包呢，它的后缀是下划线v加数字，像 _v1、_v2。而 AiAuthingBundle 认证包的后缀却只是下划线加数字，没有 v，比如 _1、_2。这三种不同的命名规则反映了它们各自的升级路径和依赖关系，千万不能写错，否则部署工具会识别不了。
最后，有一条黄金法则你要记住：无论你要部署哪个特定版本，都得先把完整代理部署上去，然后再去做版本的逐步更新。千万不要跳过“完整代理”这一步，直接去推送单个版本，那样很容易导致环境不一致或功能缺失。好，这三种模式和命名习惯你理解了吗？后续实操中再慢慢体会，这些原则会帮你在大型组织里避免很多麻烦。