Salesforce 管理員在 Agentforce 中配置自主代理（autonomous agents）時，需要在 Agentforce Builder 中建立結構化的營運領域、可執行的業務工具以及多層治理控制。與遵循確定性決策樹的傳統規則型聊天機器人不同，Agentforce 依託 Atlas Reasoning Engine 動態解讀使用者意圖、制定行動計畫並自主執行任務。為了確保這些自主代理在企業邊界內可靠、安全地運作，管理員必須配置三個基礎構建塊：用於對工作進行分類與劃定範圍的主題（topics）、用於執行業務邏輯的操作（actions），以及用於實施行為約束、資料隱私和人工呈報路徑的護欄（guardrails）。
架構基石：Atlas Reasoning Engine
為了有效配置自主代理，管理員必須了解 Agentforce 如何處理使用者互動。Agentforce 的核心是 Atlas Reasoning Engine，它透過持續的「推理-行動-觀察」（reason-act-observe）循環來協調代理行為：
- 意圖分類（Intent Classification）： 當終端使用者提交查詢時，Atlas 會對照分配給該代理的所有活動主題之分類描述來評估該訊息。
- 上下文裝配（Context Assembly）： 選定主題後，Atlas 會載入該主題的自然語言指示、可用操作、對話歷程記錄，以及透過 Salesforce CRM 或 Data Cloud 檢索到的相關客戶資料。
- 計畫制定（Plan Formulation）： 推理引擎評估滿足使用者請求需要哪些操作（若有），並確定需要從對話中擷取的必要參數。
- 操作執行與觀察（Action Execution and Observation）： 代理執行所選操作（例如查詢庫存記錄或更新支援服務案件狀態），並觀察傳回的輸出結果。如果需要後續步驟，引擎將繼續推理，直到達成目標或觸發呈報邊界。
由於 Atlas 是進行動態推理而非遵循指令碼化的對話樹，因此管理員無需構建靜態分支路徑。相反地，管理員需要定義邊界、工具和目標，讓引擎自主導航以找出解決問題的最佳路徑。
步驟 1：在 Agentforce Builder 中配置主題（Topics）
主題是代理的核心功能領域。它們對相關能力進行分組，提供上下文，並劃定代理獲准運作的邊界。
存取 Builder 並建立主題
- 在 Salesforce 設定（Setup） 中，使用「快速尋找」（Quick Find）方塊導覽至 Agentforce Agents（根據版本配置，可能顯示為 Einstein Agents）。
- 從清單中選取所需代理，然後點擊 Open in Builder。
- 在 Agentforce Builder 的左側導覽面板中，選取 Topics 索引標籤。
- 點擊 New Topic 從頭構建自訂主題，或從標準預先配置領域範本中進行選取（例如 Order Management、Billing Inquiries 或 Case Escalation）。
定義主題中繼資料與分類範圍
每個主題都需要三個關鍵配置欄位，它們直接影響 Atlas Reasoning Engine 如何路由傳入的提示詞：
- 主題名稱（Topic Name）： 識別業務功能的明確、描述性標籤（例如
Billing_and_Invoices或Appointment_Scheduling）。 - 分類描述（Classification Description）： 詳細的語意說明，闡明哪些使用者意圖、查詢和請求屬於該主題。Atlas 高度依賴此描述來計算意圖相似度。例如，不要只寫簡單的「帳單問題」，而應編寫：「處理有關客戶發票、帳單歷程、付款方式、收據請求、費用爭議和訂閱續訂費用的查詢。」
- 範圍（Scope）： 簡明扼要的摘要，概述代理在該領域內可以解決和不能解決的問題。這為模型開始推理提供了直接的上下文邊界。
編寫主題級指示
主題指示提供了代理在主題啟動後必須遵循的具體行為準則和操作步驟。管理員應使用明確、祈使語氣的自然語言起草指示：
- 循序指引（Sequential Guidance）： 概述標準操作順序（例如：「1. 詢問客戶的訂單編號（Order ID）。2. 驗證訂單編號是否與現有記錄相符。3. 檢索物流狀態並總結交付時程表。」）。
- 條件邏輯（Conditional Logic）： 定義特定情境的處理規則（例如：「如果訂單狀態為『已送達』，但客戶表示未收到包裹，則啟動遺失包裹呈報流程。」）。
- 風格與語氣指示（Style and Tone Directives）： 明確溝通偏好（例如：「提供簡明、專業的回答。在解釋發票明細時避免使用技術術語。」）。
管理員應追求聚焦的設計：每個代理通常配置 10 到 15 個獨立主題，確保分類描述之間的語意重疊降至最低，避免引擎產生猶豫或錯誤分類請求。
步驟 2：附加與配置操作（Actions）
操作是代理呼叫的功能工具，用於檢索資訊、建立或更新記錄以及執行外部業務邏輯。沒有操作，代理只能對話；有了操作，代理才能執行實際工作。
管理員可用的操作類型
管理員可以向主題附加多種類型的操作：
| 操作類型 | 實作機制 | 典型使用案例 |
|---|---|---|
| Flows | 在 Flow Builder 中配置的自動啟動流程（Autolaunched flows） | 更新 Salesforce 記錄、建立支援服務案件、觸發核准請求、查詢多物件資料。 |
| Apex 類別 | 帶有 @InvocableMethod 註解的可呼叫 Apex 方法 | 複雜計算、大批量批次查詢、密碼學驗證、遺留系統對接橋接。 |
| 提示詞範本（Prompt Templates） | 在 Prompt Builder 中建立的標準或自訂提示詞範本 | 起草個人化電子郵件、總結對話記錄、產生自訂產品推薦。 |
| 外部服務與 MuleSoft API | OpenAPI 規格或 MuleSoft Anypoint 端點 | 從第三方物流系統擷取即時出貨資料、檢查支付閘道餘額、在 ERP 中預留庫存。 |
配置操作參數與中繼資料
在向主題新增操作時，管理員必須透過精確的自然語言描述來配置參數定義：
- 選取操作： 在主題詳細資料檢視中，點擊 Add Action 並搜尋目標 Flow、Apex 方法、提示詞範本或外部服務。
- 定義操作描述： 明確說明該操作完成什麼任務以及應在何時呼叫。Atlas 會讀取此描述以判斷該操作是否符合其目前推理計畫的步驟。
- 對應輸入參數： 針對每個必需的輸入參數（例如
caseId、customerId或billingZipCode），指定代理應從目前對話上下文中擷取該值、直接向使用者索取，還是傳遞靜態系統變數。 - 定義輸出處理： 配置代理如何處理操作的傳回值。指定是將輸出作為綜合訊息直接傳回給使用者，還是作為後續操作的上下文傳回推理循環。
- 要求確認（狀態變更操作）： 對於敏感或不可逆的操作（例如處理付款、取消合約或刪除已排程的服務預約），管理員可以啟用確認要求，強制代理在執行操作前明確要求使用者進行確認。
步驟 3：實施多層護欄（Guardrails）
自主代理需要健全的治理機制，以防止幻覺、資料外洩、政策違規和未經授權的資料修改。管理員可在四個不同層面實施護欄：對話指示、確定性邏輯、存取權限以及平台信任控制。
1. 基於自然語言指示的對話護欄
第一道防線是在主題指示中明確宣告負向約束。管理員應將指示視為向員工提供的標準作業程序（SOP）：
- 明確禁止事項： 清晰闡明代理絕不能執行的操作（例如：「未經主管核准，切勿承諾超過 50 美元的財務額度或退款。」）。
- 隱私保護： 指導代理處理敏感客戶輸入（例如：「切勿向客戶索取完整的信用卡號、銀行帳戶資訊或政府身分證件號碼。如果客戶主動提供此類資訊，切勿在對話中重複該資訊。」）。
- 適度呈報觸發條件： 指定代理必須停止處理並透過 Omni-Channel 將客戶轉接給真人客服的精確標準（例如：「如果使用者提及採取法律行動、兩次要求與主管溝通或使用侮辱性語言，請立即呼叫 Transfer to Agent 操作。」）。
2. 確定性邏輯護欄
雖然大型語言模型擅長理解對話的細微差別，但關鍵計算和確定性業務規則絕不能交由生成式估算來處理。管理員應透過將關鍵邏輯遷移至確定性程式碼中來強化嚴格邊界：
- 使用 Flows 和 Apex 進行計算與驗證： 如果折扣必須根據客戶生命週期價值遵循嚴格的階梯規則，請將計算封裝在自動啟動流程（Autolaunched Flow）或 Apex 方法中。讓代理呼叫該操作，而不是生成式計算折扣。
- 輸出驗證： 在將記錄提交至資料庫之前，使用驗證規則和流程決策元素來拒絕無效的輸入參數。
3. 權限與存取控制護欄
Agentforce 代理在特定的執行上下文中執行操作。管理員必須在代理的身分上貫徹最低權限原則：
- 專用代理使用者與設定檔： 每個代理都在專用的 Salesforce 使用者記錄下運作。管理員應建立專門針對該代理營運範圍量身打造的 Profile 和 Permission Set。
- 物件層級與欄位層級安全性（FLS）： 確保代理的權限集僅針對其分配主題所需的特定標準和自訂物件授予
Read或Edit權限。切勿授予Modify All Data或廣泛的管理權限。 - 共用規則（Sharing Rules）： 驗證代理使用者是否遵循全組織預設值（OWD）以及以角色為基礎的共用規則，確保其無法檢索其授權領域或部門之外的客戶記錄。
4. 平台級護欄：Einstein 信任層（Einstein Trust Layer）
Agentforce 運作在 Salesforce 的 Einstein 信任層之上，提供無需太多管理配置的內建安全功能：
- 零資料保留（Zero-Data Retention）： Einstein 信任層保證第三方基礎模型不會保留提示詞中傳送的企業客戶資料，也不會用於模型訓練。
- 自動化資料遮蔽： 個人識別資訊（PII）——例如社會安全號碼、電子郵件地址和電話號碼——在提示詞離開 Salesforce 信任邊界前會被自動偵測並遮蔽。
- 有害內容與提示詞注入防禦： 傳入的使用者輸入和產生的模型輸出均會接受有害語言、仇恨言論以及試圖劫持代理指示的提示詞注入攻擊掃描。
- 稽核線索與可觀察性： 每次互動（包括檢索到的基礎資料、傳送的提示詞、模型的中間推理過程以及最終回應）都會記錄在 Data Cloud 稽核記錄中，以供合規與治理審查。
步驟 4：測試、可觀察性與最佳化
在將代理部署至實際上線的客戶或內部管道之前，管理員必須驗證其推理路徑並完善其指示。
使用對話預覽面板
Agentforce Builder 包含一個互動式 Preview 面板，允許管理員即時模擬對話：
- 測試「正常流程」（Happy Path）： 輸入標準使用者查詢，以驗證代理是否正確分類意圖、選取適當主題並呼叫相應操作。
- 檢查推理追蹤（Reasoning Traces）： 點擊預覽視窗中的推理摘要，審查代理的內部思考過程。檢查選取了哪個主題、哪些指示影響了回應，以及向呼叫的操作傳遞了哪些輸入參數。
- 測試極端案例與護欄： 故意提交超出範圍的查詢、模糊請求和對抗性提示詞（例如要求代理忽略其指示或洩漏內部系統配置）。確認代理保持在範圍內、適當地引用公司政策，或呈報給真人代表。
在生產環境中部署與監視
完成配置與沙箱測試後：
- 管道啟動： 啟動代理並將其分配給部署管道，例如 Salesforce Service Cloud Messaging、Experience Cloud 網站、行動應用程式或內部 Slack 工作區。
- Agentforce Command Center： 監視即時效能指標，包括分流率、主題分佈、操作成功率和呈報頻率。
- 持續提示詞微調： 審查代理過早呈報或錯誤分類意圖的工作階段記錄。完善主題分類描述，並新增釐清性的負向指示，以隨著時間推移消除歧義。
透過系統化地定義細粒度主題、為其配備健全的可呼叫操作，並輔以多層護欄進行防護，Salesforce 管理員能夠將生成式模型轉變為可靠、自主的數位工作夥伴，在維護企業標準的同時提升企業營運效率。