Salesforce Agentforce 正在将企业级 AI 从被动的文本对话演进为具备自主决策能力的智能体（Autonomous Agents）。面对真实的业务场景，智能体不仅需要回答知识库中的问题，更需要主动理解客户意图、选择企业内部的专业工具、执行事务处理，并根据执行结果推进后续任务。
Agentforce 开箱即用的标准操作（Standard Actions）主要覆盖草拟邮件、汇总记录等通用 CRM 任务。然而，企业级应用不可避免地需要触达专有业务规则、复杂的跨系统事务和实时第三方数据。Salesforce 后端开发人员与企业架构师需要通过构建**自定义操作（Custom Actions）**来扩展智能体的能力边界，其技术实现依托于三大核心支柱：
- Invocable Apex 方法：适用于复杂计算、严苛校验、高级 SOQL 查询以及需要确定性执行的代码逻辑。
- 无头自动化流程（Autolaunched Flow）：适用于由管理员或低代码开发人员维护的标准 CRM 增删改查、审批路由与既有业务流程。
- 基于 External Services 与 API Catalog 的 MuleSoft API：连接底层 ERP（如 SAP、Oracle）、支付网关以及企业分布式微服务的系统桥梁。
本文将深入解析这三种操作模式的底层运行机制、代码实现规范、上下文工程（Context Engineering）配置要点以及企业级安全治理策略。
1. 核心架构：Atlas 推理引擎如何理解并调用操作
要构建出高可用、不易产生幻觉的操作，首先必须理解 Agentforce 的核心大脑——**Atlas 推理引擎（Atlas Reasoning Engine）**的工作方式。
[ 用户交互 / 全渠道接入 Omni-Channel ]
│
▼
[ Atlas 推理引擎 ]
(ReAct: 推理 - 行动 - 观察)
│
┌──────────────┼──────────────┐
▼ ▼ ▼
[ 主题分类识别 ] │ [ 业务护栏与上下文过滤 ]
│ │
└──────┬───────┘
▼
[ 动作 / 工具选择 ]
│
┌──────┼──────┐
▼ ▼ ▼
[ Apex ] [Flow] [MuleSoft / API]
│ │ │
└──────┼──────┘
▼
[ 执行输出返回至 Atlas ]
│
▼
[ 组织最终答复或触发后续动作 ]
ReAct 运行机制与上下文工程
Atlas 引擎采用经典的 Reason-Act-Observe（推理-行动-观察） 循环机制：
- Reason（推理）：当用户输入需求或外部事件触发时，引擎根据已配置的**主题（Topics）**限定业务范围，并评估哪个动作能够满足当前意图。
- Act（行动）：引擎从对话上下文提取关键参数，组装输入数据并触发对应动作。
- Observe（观察）：动作执行完毕后，引擎接收结构化输出，判断任务是否已达成，并决定是直接生成自然语言反馈给用户，还是继续调用下一个动作。
在传统的程序开发中，模块间依赖于强类型签名与直接调用；而在自主智能体体系中，元数据即 Prompt。大语言模型无法直接审视 Apex 的内部代码逻辑，它完全依赖操作的 label、description、输入参数注解以及自然语言指令（Action Instructions）来做决策。模糊的描述会导致工具误用或参数抽取失败，而精确语义化的描述则是确保高确定性执行的关键。
2. 将 Invocable Apex 构建并发布为自定义操作
对于逻辑分支复杂、数据结构特殊、或有严格性能与安全要求的业务场景，Invocable Apex 是最灵活可控的选择。
步骤一：编写 Invocable Apex 类
Agentforce 依赖 @InvocableMethod 注解暴露代码。该方法必须声明为 public 或 global 的静态方法，接收输入包装类的 List，并返回输出包装类的 List。
以下是一个企业订单取消操作的标准实现范例：
public with sharing class OrderCancellationService {
// 输入参数包装类：向智能体声明所需的输入项
public class OrderCancellationRequest {
@InvocableVariable(
label = 'Order Number'
description = '客户需取消的订单编号，格式如 ORD-10023。'
required = true
)
public String orderNumber;
@InvocableVariable(
label = 'Cancellation Reason'
description = '客户说明的取消订单原因。'
required = false
)
public String reason;
}
// 输出参数包装类：向 Atlas 引擎返回结构化执行结果
public class OrderCancellationResult {
@InvocableVariable(
label = 'Is Success'
description = '布尔标识，指示订单是否已成功标记为已取消。'
)
public Boolean isSuccess;
@InvocableVariable(
label = 'Cancellation Reference Code'
description = '确认取消后生成的审计凭据编号。'
)
public String referenceCode;
@InvocableVariable(
label = 'Status Message'
description = '操作结果说明或明确的失败原因描述。'
)
public String message;
}
@InvocableMethod(
label = 'Cancel Customer Order'
description = '取消处于待处理状态的客户订单并生成审计编号。仅当订单状态为 Pending 或 Processing 且客户明确要求取消时方可触发。'
category = 'Order Management'
)
public static List<OrderCancellationResult> cancelOrders(List<OrderCancellationRequest> requests) {
List<OrderCancellationResult> results = new List<OrderCancellationResult>();
for (OrderCancellationRequest req : requests) {
OrderCancellationResult res = new OrderCancellationResult();
try {
// 启用用户模式安全校验
List<Order> orders = [
SELECT Id, Status, TotalAmount
FROM Order
WHERE OrderNumber = :req.orderNumber
WITH USER_MODE
LIMIT 1
];
if (orders.isEmpty()) {
res.isSuccess = false;
res.message = '未找到匹配的有效订单编号：' + req.orderNumber;
results.add(res);
continue;
}
Order targetOrder = orders[0];
if (targetOrder.Status == 'Activated' || targetOrder.Status == 'Completed') {
res.isSuccess = false;
res.message = '订单 ' + req.orderNumber + ' 已进入发货或完成状态，无法通过自助通道直接取消。';
results.add(res);
continue;
}
targetOrder.Status = 'Cancelled';
targetOrder.Description = '通过 Agentforce 自动取消。原因：' + (req.reason != null ? req.reason : '未说明');
Database.SaveResult sr = Database.update(targetOrder, AccessLevel.USER_MODE);
if (sr.isSuccess()) {
res.isSuccess = true;
res.referenceCode = 'CAN-' + System.currentTimeMillis();
res.message = '订单取消成功。';
} else {
res.isSuccess = false;
res.message = '数据库记录更新失败。';
}
} catch (Exception ex) {
res.isSuccess = false;
res.message = '处理订单取消时发生系统内部异常：' + ex.getMessage();
}
results.add(res);
}
return results;
}
}
Apex 开发的关键准则
- 避免多合一庞大类（God Classes）：切忌让一个操作执行查询、计算、扣款、发货等多步跨界业务。应保持操作单一职责，让 Atlas 引擎自主组织步骤，这样推理过程清晰且易于故障回溯。
- 返回结构化错误而不是抛出未捕获异常：如果方法直接抛出未捕获的运行时异常，智能体往往会陷入断层或直接报错。应当捕获异常并返回带有友好原因的
message，让智能体据此向用户合理解释或发起二次追问。 - 严格遵循用户模式安全：始终使用
WITH USER_MODE或在 DML 时声明AccessLevel.USER_MODE，确保智能体严格遵守 Agent User 运行配置的字段级与对象级安全边界。
步骤二：在后台注册为 Agent 操作
- 进入 Salesforce Setup（设置），在快速查找框中输入
Agent，选择 Agentforce Assets（或 Agent Actions）。 - 点击 New Agent Action（新建操作）。
- 在 Reference Action Type（引用操作类型） 中选择 Apex。
- 选中已部署的类
OrderCancellationService及其方法Cancel Customer Order。 - 系统会自动基于代码注解预填充标签与参数说明。请在 Action Instructions（操作说明） 中补充业务规则（例如：“仅在已认证客户明确要求取消订单时调用。若客户未提供订单号，必须先行追问订单号。”）。
- 点击完成保存。
3. 将无头 Flow 构建并发布为自定义操作
对于典型的 CRM 记录增删改查、既有审批流调用以及业务规则相对简单的场景，Autolaunched Flow 提供了更高效的声明式交付手段。
流程类型限制
Agentforce 仅支持调用无触发器的自动启动流（Autolaunched Flow - No Trigger）。Screen Flow（屏幕流）需要浏览器人机界面交互，而 Record-Triggered Flow（记录触发流）由数据库底层事件驱动，两者均无法直接作为智能体的动作调用。无头流程的请求-响应模式契合智能体的执行生命周期。
[ 用户意图："将我的收货地址变更为科技园南区 101 号" ]
│
▼
[ Agentforce 动作规划器 ]
│
(抽取参数: orderId, streetAddress, city)
│
▼
[ Autolaunched Flow: 更新订单发货地址 ]
┌─────────────────────────┐
│ Get Records: 查询目标订单 │
├─────────────────────────┤
│ Decision: 是否已实际发货 │
├─────────────────────────┤
│ Update Records: 更新地址 │
└─────────────────────────┘
│
(输出变量: isUpdated = True, confirmationMsg)
│
▼
[ Atlas 组织自然语言答复 ]
流程配置步骤
- 新建流程：打开 Flow Builder，选择 Autolaunched Flow (No Trigger)。
- 定义输入变量：
- 创建文本型变量
var_orderId，勾选 Available for input（可用于输入）。 - 填写详尽的 Description（说明）：“目标订单记录的 18 位 Salesforce Record ID。”
- 同样创建
var_streetAddress等输入变量，并补充描述。
- 创建文本型变量
- 定义输出变量：
- 创建布尔变量
var_isUpdated，勾选 Available for output（可用于输出）。说明注明：“地址更新成功落库时返回 True。” - 创建文本变量
var_statusMessage，勾选 Available for output，用于承载反馈信息。
- 创建布尔变量
- 编排逻辑：
- 添加 Get Records（获取记录） 查询订单。
- 添加 Decision（决策） 判断订单当前物流状态。
- 若符合修改条件，添加 Update Records（更新记录） 更新配送信息。
- 添加 Assignment（分配） 赋值输出变量。
- 保存并激活：保存命名为
Agent_Update_Order_Address并执行激活。
步骤三：在后台注册为流程操作
- 访问 Setup > Agentforce Assets > New Agent Action。
- 选择 Reference Action Type = Flow。
- 选择刚才激活的流程
Agent_Update_Order_Address。 - 系统将识别所有开放输入与输出的变量，逐一确认各变量的自然语言描述是否充分准确。
- 配置操作调用说明并保存。
4. 通过 External Services 与 API Catalog 发布 MuleSoft API
智能体执行企业任务时，往往需要跨越 Salesforce 边界访问核心 ERP（SAP、Oracle）、外部库存中心或金融结算接口。MuleSoft 承担着跨系统数据编排与治理重任，而 Salesforce 则通过 External Services（外部服务） 与 API Catalog（API 目录） 将其无缝映射为智能体可调用的操作。
两种发布路径对比
| 实施方案 | 实现路径 | 适用场景 |
|---|---|---|
| MuleSoft for Agentforce: Topic Center 与 API Catalog 联动 | 在 Anypoint Platform 中通过 Topic Center 治理规格并直接同步到 Salesforce API Catalog | 已具备完善 Anypoint Platform 资产、由中央集成团队统一发布 API 的大型企业。 |
| External Services for MuleSoft 导入 | 依托 Named Credentials，直接导入 OpenAPI 3.0/2.0 规格文件生成操作 | 点对点集成、快速连接指定外部接口或仅需向特定 Flow 与智能体提供能力的场景。 |
[ 底层企业系统 ERP / SAP / 核心数据库 ]
│
▼
[ MuleSoft Anypoint Platform ]
(System, Process, Experience APIs)
│
(Topic Center 治理 / OAS 3.0 规范)
│
▼
[ Salesforce Anypoint 关联与同步 ]
│
┌────────────┴────────────┐
▼ ▼
[ Named Credentials ] [ Salesforce API Catalog ]
(凭据管理与鉴权) (企业 API 统一发现)
│ │
└────────────┬────────────┘
▼
[ External Services ]
(自动生成 Invocable 操作)
│
▼
[ Agentforce 自定义操作资产库 ]
步骤一：设计适配 AI 识别的 OpenAPI 规范
Atlas 推理引擎需要解析 OpenAPI 规格书以确定路径参数与请求体。编写适配智能体的 API 时需遵循以下规范：
- 属性字段说明不可缺省：所有 Query 参数、Path 变量及 JSON 字段均需具备语义清晰的
description。 - 避免多态与深度嵌套：尽量避免使用复杂的多态联合类型（
oneOf、anyOf）或过多层级的深层数组，扁平明晰的数据结构能够大幅降低大模型的入参提取错误率。 - 标准 HTTP 状态与错误实体：不仅返回 200，还要针对 400、404、500 返回包含具体错误原因的 JSON 响应。
仓库实时库存查询 API 规范样例（OpenAPI 3.0）：
openapi: 3.0.3
info:
title: Enterprise Warehouse API
version: 1.0.0
description: 跨仓库存查询与即时发货可用性服务。
paths:
/inventory/{sku}:
get:
summary: 根据商品 SKU 查询仓库可用库存
description: 传入标准商品编码，返回各配送中心的实物库存量、发货可行性以及缺货补货周期。
operationId: getInventoryBySku
parameters:
- name: sku
in: path
required: true
description: 商品唯一标识编码，格式如 PROD-WIDGET-99。
schema:
type: string
responses:
'200':
description: 成功获取库存信息
content:
application/json:
schema:
type: object
properties:
sku:
type: string
description: 被查询的商品编码。
quantityOnHand:
type: integer
description: 仓库实体现有库存件数。
isAvailableToShip:
type: boolean
description: 是否满足立即打包出库条件。
warehouseRegion:
type: string
description: 负责承运该商品的主物流中心区域。
'404':
description: 商品编码在物料主数据中不存在
步骤二：在 Salesforce 中同步并生成操作
- 建立 Anypoint 信任连接：在 Salesforce 设置中进入 Anypoint Platform Setup，填入 Anypoint 组织凭据与连接密钥。
- API 目录同步：在 MuleSoft Topic Center 或 Exchange 中对 API 资产打上
sf-api-catalog标签；回到 Salesforce 的 API Catalog 界面，找到已同步的 API 并激活所需端点。 - 配置 Named Credentials（指定凭据）：绑定对应的 OAuth 2.0 凭据以确保外部 HTTP Callout 鉴权安全。
- 生成 Agent 操作：在 Agentforce Assets 中创建新操作，类型选择 External Service，绑定该 API 操作并确认入参描述。
5. 在 Agentforce Builder 中完成主题装配与操作编排
自定义操作注册到资产库后，必须装配到**主题（Topics）**中才能被智能体识别和调用。主题是 Atlas 引擎划分业务领域和划定操作边界的基本单元。
[ 自主智能体：客户服务专属智能体 ]
│
┌─────────────┴─────────────┐
▼ ▼
[ 主题：订单履约与变更 ] [ 主题：退换货与售后 ]
(业务范围与路由分类) (业务范围与路由分类)
│
├───────────────────────────┐
▼ ▼
[ 动作：订单查询 ] [ 动作：取消客户订单 ]
(Autolaunched Flow) (Invocable Apex)
步骤与配置要点
- 打开 Agentforce Builder，选择目标智能体（如 Service Agent）进入编辑视图。
- 选择既有主题或点击 New Topic（例如创建 Order Logistics and Changes）。
- 撰写 Topic Classification Description（主题分类描述）：明确说明该主题负责的业务范围（如涵盖订单状态追踪、地址修改、发货加急及撤单办理）。
- 在主题的 Actions 标签页中点击 Add Action，勾选此前发布的 Apex、Flow 或 MuleSoft 操作。
编写高质量主题与操作指令
指令（Instructions）是引导智能体决策的自然语言护栏：
### 主题指令：Order Logistics and Changes
- 协助客户进行订单状态查询、物流跟踪、地址修改和订单取消。
- 在执行订单取消前，必须先复核订单状态并向用户确认其取消意图。
- 若订单已发货导致取消失败，应安抚客户并解释退换货政策。
### 操作指令：Cancel Customer Order
- 仅在用户明确提供订单编号并同意取消确认后方可触发此操作。
- 若用户未提供订单编号，请回复追问："请问您需要取消的订单编号是多少？"
- 执行成功后，务必将返回的审计凭证编号（referenceCode）告知客户。
关键动作的人工确认（Human-in-the-Loop）
对于涉及记录变更、资金往来或业务取消的高敏感操作，建议在操作配置中勾选 Require Confirmation（要求确认）。启用后，智能体在真正执行底层代码或接口调用前，会主动向客户弹出确认询问（例如：“您确认要取消订单 ORD-10023 吗？取消后将无法撤回。”），待客户明确回复肯定后方才发起调用。
6. 技术选型决策矩阵
在实际项目架构中，合理权衡三种操作构建方式能够兼顾开发效率、维护成本与系统吞吐量。
| 架构评估维度 | Invocable Apex | Autolaunched Flow | MuleSoft External Services |
|---|---|---|---|
| 主要技术栈要求 | Salesforce 专业开发人员（Apex） | 系统管理员 / 低代码配置人员 | 集成架构师 / MuleSoft 工程师 |
| 执行运行环境 | Salesforce 核心底层环境 | Salesforce 核心底层环境 | 外部企业系统与微服务集群 |
| 最佳适用场景 | 复杂运算、多对象关联、批量事务、自定义鉴权与加密逻辑 | 标品 CRUD、标准业务审批、已有自动化复用、直观业务流分支 | SAP/ERP 订单同步、跨云结算中心、外部库存中心、遗留系统对接 |
| 执行时延与限制 | Apex 同步 CPU 上限（10 秒）、常规 SOQL/DML 限制 | 受 Flow 节点执行计数与遍历限制 | 取决于外部网络延迟，支持长达 120 秒超时 |
| 版本维护模式 | Git、SFDX 与元数据打包规范 | Flow Builder 声明式版本启停 | Anypoint Exchange 契约管理与 API 治理 |
| 异常处理形态 | 强类型 try-catch 捕获与自定义包装类返回 | 故障分支（Fault Connector）与赋值节点 | 标准 HTTP 状态码（2xx/4xx/5xx）与 JSON 错误实体 |
7. 测试验证、权限治理与上线策略
1. Agent User 运行上下文与权限排查
智能体在执行自定义操作时，使用的是后台配置的 Agent User 身份。常见的新功能上线失效通常是因为该运行用户缺少必要授权：
- Apex 类安全设置：确保 Agent User 关联的 Profile 或 Permission Set 具有目标 Apex 类的执行权限。
- 流程运行权限：确认 Agent User 拥有 Run Flows 系统权限，并在对应 Flow 的高级设置中开放访问权限。
- 指定凭据与对象权限：调用 MuleSoft 接口需开放 Named Credential 的使用权限；涉及的 Salesforce 业务对象及关键字段需开通 FLS 读写权限。
2. 多层级测试与质量保障
- 底层代码单元测试：为 Invocable Apex 编写完备的测试类（代码覆盖率建议达到 85% 以上），重点覆盖空入参、越权异常和边界场景。
- Agentforce Builder 实时交互测试：利用右侧预览对话窗口触发业务提问，在 Reasoning 追踪面板中实时观察 Atlas 引擎是否准确匹配到了正确的主题，是否抽齐了输入参数，以及是否顺利接收了返回值。
- Agentforce Testing Center 批量回归：使用测试中心构建多轮测试集，针对数百种常见用户问法进行批量评估，量化验证意图识别率、工具选择准确度及幻觉发生率。
通过将 Invocable Apex 的确定性执行力、Autolaunched Flow 的低代码敏捷度，以及 MuleSoft API 的企业级互联能力深度融合，开发团队能够为 Agentforce 打造出兼具灵活性、稳健性与高合规性的自定义操作架构。
参考资料
- Agent Customization with Apex | Salesforce Trailhead
- Learn How to Make Agent-Ready Flows | Salesforce Trailhead
- How to Write Effective Natural Language Instructions for Agentforce | Salesforce Developers Blog
- A Developer’s Guide to Context Engineering with Agentforce | Salesforce Developers Blog
- Salesforce Agentforce Specialist Certification Guide & Tips | Salesforce Ben
- External Services | Salesforce Help