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 Class）。保持動作精簡專注，讓 Atlas 自主組合多個動作，邏輯更透明且便於維護。
- 以結構化訊息替代未攔截例外：若方法直接拋出未捕捉的 Exception，代理人會中斷對話或給出錯誤提示。應在 catch 區塊中將
isSuccess = false與具體原因封裝於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（記錄觸發流程）是由資料庫底層異動事件驅動，兩者皆無法直接作為代理人的單元動作。無周邊流程具備清晰的請求-回應結構，完美配合代理人的調用生命週期。
[ 使用者意圖：「請將我的收貨地址改為新竹科學園區創新一路 1 號」 ]
│
▼
[ 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並點擊啟用。
步驟三：於後台註冊為 Flow 動作
- 進入 Setup > Agentforce Assets > New Agent Action。
- 選擇 Reference Action Type = Flow。
- 選取剛啟用的
Agent_Update_Order_Address。 - 檢查所有開放輸入與輸出的變數，確認各變數描述能被大語言模型清楚理解。
- 設定動作指令，評估是否開啟確認提示後儲存。
4. 透過 External Services 與 API Catalog 發布 MuleSoft API
當代理人需要即時連線至外部 ERP（如 SAP、Oracle）、金流處理中心或第三方物流時，MuleSoft 扮演著系統整合核心的角色。Salesforce 藉由 External Services（外部服務） 與 API Catalog（API 目錄），將 MuleSoft 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 規格產生動作 | 點對點連線、快速整合指定外部系統或僅需支援特定流程的場景。 |
[ 底層核心系統 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 規格以決定呼叫端點、路徑變數與請求內容。面向 AI 代理人的 API 設計需遵守以下規範：
- 欄位語意完整說明：所有的 Query 參數、Path 變數及 JSON 物件屬性皆必須具備詳盡的
description。 - 避免過度多態與巢狀結構：避免使用複雜的
oneOf、anyOf或層級過深的陣列結構。扁平清晰的 JSON 綱要能大幅降低參數解析錯誤。 - 標準化錯誤代碼與訊息：除了 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 中找到該項目並啟用對應端點。 - 配置指定認證（Named Credentials）：設定 OAuth 2.0 連線機制，確保代理人對外發起 HTTP Callout 時的憑證安全。
- 生成 Agent 動作：在 Agentforce Assets 建立新動作，選取 External Service 類型，關聯目標 API 並微調輸入參數指示。
5. 於 Agentforce Builder 中完成主題裝配與操作編排
自訂動作建置完成後，必須配置於**主題（Topics）**下才能在執行階段被代理人辨識與調用。主題是 Atlas 引擎划分業務邊界與管理工具群組的核心單元。
[ 自主代理人：客戶服務專屬代理人 ]
│
┌─────────────┴─────────────┐
▼ ▼
[ 主題：訂單履行與變更 ] [ 主題：退換貨與售後 ]
(業務範圍與路由分類) (業務範圍與路由分類)
│
├───────────────────────────┐
▼ ▼
[ 動作：查詢訂單狀態 ] [ 動作：取消客戶訂單 ]
(Autolaunched Flow) (Invocable Apex)
步驟與配置重點
- 進入 Agentforce Builder，開啟目標代理人進入編輯模式。
- 選取既有主題或點選 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（需要確認）。啟用後，代理人在真正呼叫後端程式碼或 API 前，會主動向使用者發起確認提示（例如：「您確定要取消訂單 ORD-10023 嗎？此操作將無法復原。」），待獲得明確肯定答覆後方會執行底層交易。
6. 技術選型決策矩陣
在系統架構規劃中，合理評估並選用這三種動作建置途徑，能在開發效率、系統維護性與運算效能間取得最佳平衡。
| 架構評估面向 | Invocable Apex | Autolaunched Flow | MuleSoft External Services |
|---|---|---|---|
| 主要技術要求 | Salesforce 專業開發者（Apex） | 系統管理員 / 低程式碼開發者 | 系統架構師 / MuleSoft 整合顧問 |
| 執行運作環境 | Salesforce 原生底層架構 | Salesforce 原生底層架構 | 企業外部系統與微服務環境 |
| 最佳適用場景 | 複雜資料演算、跨物件關聯、批量處理、專屬授權驗證 | 標準 CRM 資料 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 系統權限，且該流程未設定阻止存取的安全限制。
- 指定認證與欄位安全：呼叫外部 API 需確認對應 Named Credential 的存取權限；相關 Salesforce 物件及欄位需開放 FLS 讀寫授權。
2. 多層級測試與品質評估策略
- 單元測試（Unit Test）：為 Invocable Apex 撰寫完整的測試類別（建議達到 85% 以上覆蓋率），涵蓋邊界值、null 輸入與使用者權限檢驗。
- 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