ADG001

课程介绍

同学们，我们来看看Agentforce里一个特别重要的概念——批处理模式。你可能会想，这和平时用的批处理有什么不同？其实它的设计很巧妙，所有操作都必须在同一个Apex事务里一气呵成。 具体怎么做呢？咱们慢慢聊，它分三步走。第一步，先创建一条父记录，叫AiJobRun。就像是给这次任务建了个总指挥。它的JobType字段要指定为“Prompt Template”，这说明了我们要处理的是提示模板。然后Target字段呢，要指向你那个提示模板的operName，这种命名方式对组织间的可移植性特别友好，推荐大家用。这时候，这条记录的状态是“新建”，就像一个还没启动的任务单。 第二步，我们要为这一次运行里的每一条输入记录，创建一个子记录，叫AiJobRunItem。它的Input字段稍微讲究一点——它是一个JSON字符串，但必须遵循一个前缀约定：要以“Input:”打头，然后紧跟实际的JSON数据，最后还要附上一个记录的ID作为指针，这样系统才知道要处理哪条数据。所有的AiJobRunItem刚创建出来的状态都是“Ready”，静候启动。 紧接着就是第三步，也是最关键的一步：把第一步创建的那个父记录AiJobRun的状态，从“新建”翻转成“ReadyToStart”。这一翻，就等于正式把任务移交给了平台编排器，它就会去调度、执行那些子项。但有个铁规则你必须记住：一旦翻转，不变性原则就被锁死了，你不能再对这批记录做任何更改。所以，前两步一定要小心，确保万无一失。 另外，还有一个实战中的小提醒：如果你一次运行要处理的数据量接近1万个项目的上限，最好提前在数据库里做好打包，避免撞到瓶颈。而且别忘了，这种批处理模式有新的州长限制，设计的时候要留意。好了，批处理模式的三个步骤就是这样，尽量在这个事务里把事情做对，然后放手让平台去跑。

课程章节

本课程共有 2 个章节

• 1

  Job Monitoring & Platform Events

  第 269 页

  那我们今天来讲讲如何用平台事件，也就是AiJobRunStatusEvents，来监控一个作业是不是完成了。你可能要问，为什么需要监控作业完成？其实很多时候，AI作业是异步运行的，你不能傻傻地在那儿等着，得有个自动化的方式，知道它什么时候处理好了，然后去拿结果，对吧？ 我们要用的这个事件叫AiJobRunStatusEvents。它很聪明，每次作业的状态发生变化时，比如从“处理中”变成“已完成”或者“失败”，它就会自动触发一条事件消息。那我们怎么抓住这个事件呢？用Apex触发器来订阅它。不过要小心，这个事件可能会因为状态转换被触发多次，所以我们只需要处理那些真正“已完成”的事件。所以在触发器里，第一步就得过滤，只处理状态是“已完成”的。 一旦确认作业真的完成了，触发器里就要去查找对应的AiJobRunProject记录，这个记录里包含了完整的作业信息和最终的响应。接下来，我们要从请求输入里提取原始记录的ID。这里有个约定俗成的做法：在发起AI作业时，把源记录的ID放在输入的某个字段中，遵循“前置惯例”，也就是提前商量好的那套规矩。然后我们就能从这个输入里拿到当初是哪个记录发起的这个作业。 接着看作业的响应结果。响应内容通常被包装在一个叫“Inbox Response”的键里面，就像个信封。我们需要从这个信封里把LLM（大语言模型）生成的文本内容解出来。这样我们就拿到了最终要写回的结果。 比如，我们可能要把这个AI生成的文本作为一个CaseComment，加到对应的案例记录上。所以最后一步就是把提取出来的文本内容写回Salesforce的记录里去。 在做整个流程时，还有几个生产环境必须考虑的事情，非常关键。首先，平台事件是会重传的，网络波动或者其他原因，同一个事件可能被投递多次。如果没有做重复数据消除，就可能给同一个案例重复添加评论。所以一定要根据作业的唯一标识做去重检查。 其次，不仅要处理成功完成的项目，还要处理失败的项目。作业有可能执行出错，如果你只盯着“已完成”，那失败的就没人管了，可能就一直晾在那儿。所以要同时处理失败状态，记录日志或者做补救措施。 还有，写回操作如果量比较大，不要直接在触发器里做，这会影响性能。最好把它卸载到一个异步的、批量处理的地方，比如Express处理（这里可能指Queueable或未来的框架），这样主流程不会被拖慢。 最后，也是最重要的一点：所有的代码一定要捕获异常。因为未捕获的异常会导致事件订阅被禁用。Salesforce平台有个规则，如果在9次尝试中都有未处理的错误，它就会把这个订阅关掉，之后的事件就再也不会触发了，这样会造成监控完全失效。所以，用try-catch包装好，把错误记录下来，不要让它抛出去。 总结一下，就是用AiJobRunStatusEvents监听作业完成，过滤“已完成”事件，找到作业记录，从输入里拿源记录ID，从响应信封里解析出LLM文本，再写回目标记录。同时，一定要记得去重、处理失败、异步卸载写回、捕获所有异常。这几个生产考虑，少了哪一个都可能在线上出问题，一定要记牢。

  ▶ 播放视频 查看详情
• 2

  MCP Solutions for Developers

  第 270 页

  好，我们来看一下这个 Model Context Protocol，我直接叫它 MCP 好了。在咱们 Agentforce 课程里，它可是一个非常重要的开放标准。 先想一个问题：以前你如果想把一个 AI 应用跟 Salesforce，或者 Heroku、MuleSoft 这些企业平台连起来，是不是特别麻烦？你得为每一个场景、每一个用例，去写一套自定制的代码去对接，每次都得重新研究那个平台特有的接口、命令行工具，还有各种认证方式，又费时间又容易出错。 而 MCP 就是来把这种复杂性给你拿掉的。它就像一个通用插头，你不需要自己再造轮子了，直接用现成的 MCP 服务器，就能把 AI 应用跟这些平台瞬间接通。你想连 Salesforce，用对应的 MCP 服务器；想连 Heroku 或 MuleSoft，也是换对应的现成服务器就行，几乎是即插即用。 这意味着什么呢？就是开发人员再也不用去啃那些厚厚平台文档，不用学五花八门的 API、CLI 命令，也不用搞一堆认证的配置流程了。一切都通过这个标准化的协议去处理，省下来大把时间，你可以专心在业务逻辑和 AI 能力上。 所以你可以这样理解：MCP 让开发模式发生了一个很大的转变，从以前需要为每个集成去写定制代码，变成了用一个统一的标准来快速访问。这正好也是咱们 Agentforce 能够灵活连接各种企业数据、流程的关键所在。好，这部分内容就先聊到这里。

  ▶ 播放视频 查看详情