工作人員將原因移至目標、從內容推斷參數,並動態選取動作。因此,工作人員接觸的每個整合都必須處理不明確情況、支援安全重複,並無法讓工作人員自行復原。

工作人員系統會使傳統整合設計認為已授與的數個假設失效。輸入並非一律格式正確。單一使用者動作可能會產生跨組織界限的工作人員鏈,每個工作人員都需要委派的權限才能採取動作。

此文件對應該實際後續的結構排班:新設計原則、工作人員模式,以及 Salesforce Platform 如何提供這些原則。

此文件中的每個模式皆遵循相同的結構:

名稱:表示模式中包含整合類型的模式識別碼。

內容:模式處理的整體整合情況。「內容」提供使用者嘗試達成之目標的相關資訊,以及應用程式對其需求的行為。

問題:模式設計要解決的挑戰 (以問題表示)。檢閱模式時,請閱讀此區段以快速瞭解模式是否適用於您的整合案例。

力量:造成難以解決問題的限制與狀況。

Salesforce 模式應用程式:將模式套用至案例的建議方式。

草稿:「統一建模語言」(UML) 序列圖表,顯示模式應用程式如何處理案例。

結果:模式如何解析與案例相關聯的力量。此區段也包含因套用模式而可能發生的新挑戰。

**設計考量事項:**正確套用解決方案的平台無誤指引,後面加上 Salesforce 特定的實作注意事項。這些考量事項涵蓋動作設計原則和平台特有的組態需求。

**錯誤處理與復原:**模式套用期間管理失敗的指引。此參數涵蓋四個區域:

• 動作如何透過結構化且可運作的錯誤回應將失敗傳達給工作人員,這些回應可提供足夠的內容供下游決策
• 工作人員如何決定是否要重試、自我修正或停止執行
• 補償動作如何處理部分成果和不相符的跨平台狀態
• 已淘汰寫入作業的識別電量需求

**安全性考量事項:**安全套用模式的安全性需求。這些考量事項涵蓋認證管理、整合使用者和連線應用程式的最低權限範圍、稽核工作人員叫用動作的記錄,以及來自使用者提供或 LLM 衍生內容之參數的輸入驗證需求等。

**範例:**描述設計模式在真實 Salesforce 案例中如何使用的端對端案例。範例說明目標以及如何套用模式以達成這些目標。

下表列出涵蓋的實作模式。

模式清單

此文件中的模式分為三個種類。此分類可協助結構設計師快速識別哪些模式與他們正在解決的整合挑戰相關,無論是設計工作人員呼叫的內容、觸發工作人員的內容,或是工作人員在動作前如何以 Knowledge 奠基。您可以直接瀏覽至符合您設計疑慮的種類,而不是閱讀每個模式。

動作叫用:

這些模式涵蓋工作人員如何在推理週期中呼叫外部系統以提取資料或執行作業。這些是工作人員是起始者的輸出模式。它們會處理順序 (當步驟互相依賴時)、平行 (當步驟不依賴時)、無效和部分失敗處理。設計工作人員要叫用以完成工作的工具時,請使用這些模式。

工作人員叫用:

這些模式可處理外部系統或事件如何讓工作人員採取行動。這些是外部系統觸發這些工作人員的輸入模式。觸發程序可能是透過程式設計進行通話並等待回應的人類面向應用程式,或是觸發工作人員的自發資料條件。設計工作人員觸發的方式與時間時,請使用這些模式。

使用企業資料奠基:

此種類中的模式涵蓋工作人員在原因或動作前如何以準確、最新且組織特有的 Knowledge 奠基。

選擇正確的策略並非不簡單。每個模式目標為特定問題:系統功能、資料量、失敗處理和交易性。

選取矩陣表格會列出模式及其關鍵層面,以協助您判斷最適合整合需求的模式。模式會使用這些維度進行分類。

此表格列出模式及其關鍵層面,以協助您在從 Salesforce 整合至其他系統時判斷最適合您需求的模式。

模式的每個區段都描述如何建立模式。每個模式都是工作人員結構中特定整合問題的可重複解決方案。它涵蓋何時使用模式、哪些因素會塑造決策,以及 Salesforce Platform 如何提供模式。

內容

許多業務工作流程本身都是依序的,每個步驟都需要先前的驗證結果,才能繼續進行。例如,在確認資格之前無法起始退款、在訂單記錄存在之前無法建立帳單帳戶,在檢查通過之前無法記錄合規性檢查。

在傳統自動化中,這些相依性會編碼為硬式編碼流程邏輯。在工作人員系統中,工作人員會評估每個動作的結果,並判斷是否符合下一個步驟的先決條件。

此模式描述基本輸出整合模型。在此,單一工作人員會在一個網域內作業並叫用序列,其中每個動作的輸出都會引導鏈結中下一個動作的叫用。協調工作人員會在整個鏈結中維護交易內容,並累積每個步驟傳回的識別碼、狀態代碼和資料。它會使用此內容來驅動後續的決策。

此模式是「整合模式」指南中描述單一同步呼叫之「遠端流程叫用 – 要求與回覆」的代理對應。工作人員模式會在單一推理週期內,將模式延伸至工作人員驅動的從屬通話鏈。

問題

當工作人員執行跨主機系統和一或多個遠端系統的多步驟工作流程時,必須解決四個挑戰:

• 序列 - 動作必須以正確的順序叫用,且每個步驟都會在前一個步驟的成功完成時進行。
• 資料傳播 - 每個步驟的回應資料必須作為輸入傳遞至下一個步驟。
• 失敗隔離 - 鏈結中任何一處的失敗不能在整個系統中產生部分或不一致的狀態。
• 完成驗證 - 工作人員必須確認所有步驟皆已成功完成,才能報告結果。

力

套用此模式時,請回答下列問題:

• 鏈結中的每個動作都取決於先前動作傳回的資料,還是這些相依性僅取決於成功或失敗狀態?

  資料相依性需要工作人員在步驟之間攜帶識別碼和屬性。

• 所有遠端端點是否能夠在工作人員的推理週期逾時內回應?

  鏈結中任何步驟的外部系統速度緩慢會封鎖整個序列。

• 鏈結是否需要完整的端對端成功,還是可接受部分完成?

• 如果需要完整端對端成功,請針對下游失敗發生時需要回復的步驟定義薪水策略。

• 鏈結中的任何寫入作業是否可以安全地重試?

  所有寫入動作都必須是同步的;由於「大型語言模型」(LLM) 重試或不明確的確認,工作人員的推斷迴圈可能會多次叫用相同的動作。

• 鏈結是否由使用者互動 (對話、低同時) 或自動觸發 (可能高同時) 叫用?

  這會決定同步封鎖是否可接受,或非同步模式是否必要。

Salesforce 模式應用程式

草稿

序列動作叫用的順序圖

結果

工作人員會以一致且受監督的順序執行跨系統工作流程,而非為難忘的指令檔。系統會在叫用下一個步驟之前評估每個步驟的結果,因此工作人員會儘早偵測到失敗,而不會在實情後發現部分完成。

主機系統 (Salesforce CRM) 只會在遠端作業確認狀態 (成功或失敗) 後更新。外部系統傳回的識別碼和狀態,例如帳單帳戶號碼、交易識別碼和確認碼,會在鏈結中移入並持續存在,進而建立工作流程成果的完整且可追蹤記錄。

工作人員負責推理結果並排序決策。每個動作僅負責自己的作業和傳回結構化結果。兩個圖層都不會對另一個圖層的邏輯進行編碼。

設計考量事項

平台無效指引

• 確定鏈結中的每個動作都包含以以意圖為基礎的語言撰寫的語意描述,而非作為技術方法簽名。工作人員會根據這些描述選取動作。說明「呼叫帳單 API」不如說明「在帳單系統中建立帳單帳戶並傳回新帳戶識別碼」的說明。
• 使鏈結中的所有寫入作業為無效。如果工作人員的推理迴圈收到不明確的回應,則可能會重試動作。動作必須在重複叫用時產生相同的結果。
• 在動作邊界中以防禦方式驗證所有 LLM 推斷輸入參數。請勿假設工作人員傳遞的參數已格式正確、在範圍內或為預期類型。
• 為單一責任設計每個動作。建立帳單帳戶並在同一通話中傳送確認電子郵件的動作較難重試、較難測試,且工作人員難以推斷超過兩個獨立動作。

Salesforce 實作注意事項

• 針對 Apex 動作,使用 @InvocableMethod(label=’…’ 註釋description=’…’)。工作人員會讀取「描述」,以決定何時叫用動作。使用描述性「標籤」和「描述」欄位,以 @InvocableVariable 宣告所有輸入和輸出變數。傳回具有明確成功/失敗指標和人類可讀取錯誤訊息的結構化結果物件。
• 針對「流程動作」,請僅使用「自動啟動的流程」,而自發工作人員內容不支援畫面流程。讓每個流程保持原子化;一個動作,一個責任。在每個外部呼叫元素上設定錯誤路徑,以抓住整合錯誤,並將可運作的錯誤訊息傳回給工作人員,而不讓未抓到的例外情況終止工作階段。
• 針對外部服務,匯入目標系統的 OpenAPI 規格,並在 Agentforce 主題中註冊產生的動作。在「已命名認證」中封裝產生的固體,以避免在動作定義中硬式編碼端點或認證。
• 針對所有外部呼叫,設定明確呼叫逾時。暫留且未逾時的呼叫會封鎖工作人員的推理週期,直到達到工作階段限制為止。超過逾時時,傳回具有描述性錯誤訊息的禮貌失敗。所有外部呼叫都有可設定的逾時,最多 120 秒。它們也受限於 Apex 同步交易管理員限制,因此請務必減少例項化每個執行超過五秒鐘的超過 50 個交易的風險。

錯誤處理與復原

• 工作人員會針對步驟前置項目的明確成功完成每個步驟。動作必須傳回包含明確成功或失敗指標的結構化結果。工作人員無法單獨從遺漏或空值回應中可靠地推斷失敗。
• 動作失敗時,工作人員會使用動作傳回的錯誤訊息來決定其下一個移動:提示使用者修正的輸入、嘗試使用調整的參數進行自我修復重試,或停止鏈結並記錄失敗以供人類檢閱。因此,錯誤訊息必須具體且可運作:「無效的日期範圍:endDate cannot precede startDate” 可供使用;僅 400 狀態代碼則無法使用。
• 針對部分完成建立狀態不一致的鏈結 (例如,已建立帳單帳戶但 CRM 記錄未更新),工作人員會在呈現失敗前叫用補償動作來回復或標記部分狀態。將薪水路徑設計為前置路徑旁的具名動作。
• 如果寫入動作可能成功,但傳回不明確的回應 (網路逾時、無確認),則重試必須使用與原始呼叫相同的無效金鑰或外部參照識別碼。請勿對非無效的寫入進行未選取的重試。

安全考量事項

• 將所有外部呼叫包含在已命名認證中。請勿在 Apex 程式碼或流程組態中硬式編碼端點或認證。這些必須透過平台的安全認證存放區來管理,且在不變更程式碼的情況下輪替。
• 將最低權限原則套用至每個動作所使用的整合使用者或連線應用程式。僅讀取訂單資料的動作不應保留帳單系統的寫入權限。將認證範圍定義至動作所需的最小作業。
• 記錄鏈結中每個動作的叫用,以及其工作階段識別碼、輸入參數 (已精簡敏感值) 和成果。如果結果有爭議,則此稽核追蹤是重建工作人員執行指定動作序列原因的主要機制。
• 在將源自使用者提供文字的所有輸入參數傳送至外部系統前,先將其消毒。透過工作人員傳遞至外部 API 呼叫的使用者輸入是潛在的插入向量。建立呼叫之前,驗證動作邊界的類型、格式和範圍。

範例

處理退款要求的客戶服務代理執行四個步驟的連續鏈結:

1. GetOrderDetails (Apex 動作) 會使用使用者提供的訂單識別碼,從「訂單管理系統」提取訂單記錄。它會傳回訂單狀態、條列項目、購買日期和付款方式。工作人員在繼續之前評估訂單是否處於可退款狀態。
2. ValidateRefundEligibility (自動啟動流程) 會套用退款資格的業務規則,包括退貨時段、產品種類限制和先前退款歷程記錄。它會傳回「符合資格」布林值,如果不符合資格,則會傳回工作人員可以向使用者顯示的純文字原因。
3. InitiateRefund (Apex 動作) 會呼叫含有訂單識別碼和退款金額的外部付款管道 API。成功時傳回「refundTransactionId」。此動作為 idempotent。如果以相同訂單識別碼第二次呼叫,則會傳回現有的交易識別碼,而非建立重複的退款。
4. UpdateCaseStatus (自動啟動流程) 會以退款交易識別碼更新 CRM 個案記錄,將個案狀態設定為「已解決的退款已發出」,並為帳戶擁有者建立追蹤工作。此步驟只會在「InitiateRefund」傳回確認的交易識別碼後執行。

如果 InitiateRefund 逾時或傳回錯誤,工作人員會停止鏈結、不叫用 UpdateCaseStatus,並向使用者呈現可採取動作的訊息。個案保持開啟且未解決,並在 CRM 中保持準確狀態。

內容

當執行步驟彼此相依時,序列動作鏈有效率。一個步驟會帶領下一步。但許多工作流程都包含一組沒有相互相依性的步驟。例如,所有步驟都可能會同時發生,這些步驟中包含取回產品庫存、提取客戶權益和檢查貨運估計值,因為沒有任何步驟的輸入需要另一個步驟的輸出。依序執行這些步驟會浪費與步驟數量相比例的時間。

在並列叫用模式中,工作人員會識別動作集是獨立的,並且會同時叫用動作,而非依序。整體工作流程時間與最慢的個別動作繫結,而非所有動作時間的總和。傳回所有結果後,工作人員會將結果彙總為單一一致的回應,或將結果一起使用,作為下一個考量階段的投入。

關鍵的結構挑戰並非並列叫用本身。這是管理平台同時限制內的客戶排除,並確保彙總步驟順利處理部分失敗,而不會捨棄成功的結果。

問題

工作人員如何有效協調多個獨立功能的同時執行,並將個別結果彙總為使用者或後續步驟的單一共融回應?

力

套用此模式時,請回答下列問題:

• 關於執行緒安全性和共用可變狀態的動作考量事項為何?
• 解決方案如何在單一交易中管理並避免達到並列 Apex 呼叫的 Salesforce 管理員限制?
• 是否需要使用非同步模式 (例如 Queueable Apex 或 Platform Events) 來避免管理員限制?
• 工作人員是否需要同步彙總結果才能繼續進行?

Salesforce 模式應用程式

草稿

平行動作叫用的順序圖

結果

當並列執行獨立動作時,端對端工作流程時間會與最慢的個別動作繫結,而非所有動作的總和。針對每個具有平均 300 毫秒三個獨立呼叫的工作流程,並行執行會在 ~300 毫秒內完成;序列執行會花費 ~900 毫秒。大規模而言,此差異會在每個同時執行的工作人員工作階段之間形成。

設計考量事項

平台無效指引

• 並列化之前,請確認獨立性。只有在兩個動作未讀取另一個動作所撰寫的狀態,且兩個動作的失敗不應取消另一個動作時,才能安全地並行執行動作。如果存在相依性 (即使是軟性相依性),請改用序列鏈結。
• 明確設計彙總步驟。提前定義完整結果集的外觀、部分結果集對於下游推理的意義,以及工作人員是否應等待所有結果,或在傳回值 (例如總計 7 個呼叫中的 5 個) 之後繼續。
• 所有並列寫入作業必須為 idempotent。每個作業都會以獨立的方式執行,而不含共用交易邊界,因此重試任何個別的分支不會造成副作用重複。

Salesforce 實作注意事項

• **針對可排列的 Apex:**在單一交易中提交所有工作,以最大化同時執行的可能性。請注意,可用的並行時段可在整個組織中共用;請假設時段可能不一定可用,並在時段無法使用時建立連續執行的回復。
• **針對平台事件:**將每個作業的結果寫入至專屬暫存記錄 (由共用關聯性識別碼為金鑰),而非直接更新目標記錄。最後彙總流程或 Apex 觸發會在達到預期計數後讀取所有暫存記錄,然後以原子方式套用合併的更新。
• **針對中介軟體 Fan-Out:**在單一呼叫上設定明確逾時,其超過最慢後端預期的最差個案回應時間,但仍在 Salesforce 呼叫逾時限制內。中介程式會傳回部分結果,並清楚指出哪些後端失敗,而非逾時整個回應。

錯誤處理與復原

• 將部分成功視為一流成果。如果三個或四個並列作業成功,則工作人員會使用三個成功的結果,並明確地向使用者呈現失敗,記錄重試,或叫用補償動作,而不是捨棄所有結果或繼續,就如同未發生失敗一樣。
• 針對「可排列」與「平台事件」模式,請使用關聯性識別碼 (在開啟時產生),以將所有並列分支連結回原始工作人員工作階段。需要此識別碼才能重新組合結果,並在記錄中追蹤失敗的來源。
• 如果並列分支失敗,且作業可以安全地重試,請僅使用原始關聯性識別碼和 IDempotency 金鑰將失敗的分支重新排列。請勿重新叫用所有分支。
• 定義彙總步驟的逾時值。如果並非所有結果都到達到到達到期值,請繼續使用可用的結果,並標記未完成的集合,而非無限期等待。

安全考量事項

• 每個並列執行內容,無論是可排列工作、平台事件觸發或中介軟體呼叫,都必須套用與連續呼叫相同的存取控制項。平行方式不會放寬資料存取規則。每個分支必須以相同的最低權限認證作業,如同單獨叫用。
• 針對中介軟體扇出,中介軟體層不會從彙總視窗以外的個別後端快取或記錄回應裝載。每個後端的回應都可能包含不應保留在立即作業範圍之外的敏感資料。
• 確保用於平台事件彙總的暫存記錄無法由工作人員的一般使用者讀取。這些記錄可能包含尚不適合耗用的中繼、部分格式資料。

範例

服務代理人回答複雜的履行問題:「您可否在週五之前將此訂單寄送給我?」回答需要同時從所有獨立系統取得資料,如下所述:

1. 工作人員識別了三個獨立的資料需求:目前庫存層級、客戶的有效權益,以及客戶位置的通訊業者估計遞送時段。
2. 系統會並列叫用三個動作:GetInventoryStatus (透過中介軟體從外部庫存系統)、GetCustomerEntitlements (從 Salesforce CRM) 和 GetDeliveryEstimate (透過中介軟體從通訊業者 API)。
3. 每個動作都會獨立傳回。工作人員會等待直到收到全部三個回應 (或到達彙總逾時)。
4. 有了全部三個結果,工作人員會根據合併資料的原因評估庫存是否足夠,客戶的權益涵蓋快速寄送,且通訊業者確認客戶的郵遞區號週五可行。
5. 工作人員會在三個通話中最慢的時間回應時,從三個系統中繪製的單一已奠基回答傳回給使用者。

內容

某些工作人員起始的作業不會產生工作人員繼續目前推理週期所需的結果。傳送通知、觸發下游批次流程、將事件發佈至訊息排隊,或提交長時間執行的工作都是工作人員義務在分派時結束的作業;下游系統會獨立擁有並完成工作。

在傳統自動化中,系統會將這些項目建模為難忘呼叫或平台事件發佈。在工作人員系統中,工作人員在推斷作業為非封鎖期間決定作業、分派作業、記錄分派確認,並繼續或結束輪數,而不等待下游結果。

此模式是「整合模式」指南中「遠端流程叫用 – 觸發與忘記」的代理對應。工作人員模式透過讓分派決策成為工作人員推理的一部分,並確保即使未傳回回應給工作人員,仍可追蹤分派。

問題

當工作人員需要起始在工作人員工作階段或推理週期以外執行的下游作業時,必須解決三個挑戰:

• **非封鎖叫用:**工作人員必須觸發作業並確認傳送,而不讓推理週期等待結果。
• **遞送確認:**工作人員必須區分成功分派 (已接受訊息) 和成功成果 (下游流程已完成)。它只能判斷前者。
• **可追溯性:**由於工作人員不會收到任何結果,因此作業必須可透過記錄、事件記錄或平台監視來觀察,而非工作人員工作階段。

力

套用此模式時,請回答下列問題:

• 工作人員是否需要此作業的結果才能完成其目前輪數? 如果是,則這不是正確的模式。請改用「序列動作叫用」。

• 下游系統是否能夠在沒有同步確認的情況下接收及可靠地處理分派的訊息或事件? 目標系統必須是永久的。如果訊息暫時無法使用,則其無法遺失訊息。

• 作業是否無法執行,還是需要保護重複的分派? 網路層級重試和工作人員考量重試會造成多次嘗試相同分派。如果下游作業並非 idempotent,則動作必須帶有重複金鑰。

• 使用者或下游流程是否需要知道作業何時完成? 工作人員只能確認分派。如果需要完成狀態,請設計個別的通知或追蹤機制。平台事件、個案更新或回呼 - 在此推理週期之外。

Salesforce 模式應用程式

草稿

非同步動作叫用的順序圖

結果

工作人員會叫用下游作業,而不會封鎖其對成果的推理週期。輪數會完成為確認作業已接受,而非確認作業已完成。下游系統會取得執行的完整擁有權。分派的作業可透過在分派時在 CRM 中記錄的平台事件訂閱者、工作識別碼,或外部排隊確認識別碼進行追蹤。如果下游作業失敗,則會透過下游系統自己的監視呈現該失敗,而非透過起始該失敗的工作人員工作階段。

設計考量事項

平台無效指引

• 以以意圖為基礎的語言撰寫動作描述。例如,「將續約通知提交至傳訊信箱並傳回分派參考識別碼」對工作人員而言比「呼叫通知端點」更有用。
• 請勿將分派動作描述為「傳送並確認傳送」。工作人員只能確認接受。下游傳送與處理超出工作人員可觀察的範圍。

Salesforce 實作注意事項

• 從每個叫用動作傳回參照識別碼,例如「平台事件」ReplayId、可排列的工作識別碼、Pub/Sub API PublishResult replayId 或外部確認權杖。在叫用時將其記錄在 CRM 記錄中。這是工作人員工作階段會產生的唯一稽核追蹤。
• 針對 Pub/Sub API,工作人員會叫用 Apex 動作,以對 Pub/Sub API ‘/Publish’ 端點執行 gRPC 呼叫。動作必須處理結構描述註冊步驟 - 事件必須根據註冊的結構描述以 Avro 格式進行序列化。將 PublishResult ‘replayId’ 傳回給工作人員作為分派參考。
• 針對「平台事件」,請先在 Apex 動作內呼叫 EventBus.publish(),並檢查 SaveResult 是否有錯誤,再將成功指標傳回給工作人員。請勿假設發佈成功;請驗證。
• 針對「可排列工作」,實作「可排列」介面,並從動作內呼叫 System.enqueueJob()。將產生的 AsyncApexJob 識別碼傳回給工作人員。
• 針對外部非同步端點,目標端點必須立即傳回含參照識別碼的確認 (HTTP 202 已接受)。如果端點封鎖直到處理完成為止,則其為同步,且此模式不適用。

錯誤處理與復原

• 叫用動作必須區分分派失敗 (訊息未接受) 和處理失敗 (訊息已接受但後續的下游作業失敗)。工作人員只能處理前置項目。
• 如果叫用失敗,則動作必須傳回有明確原因的結構化失敗。工作人員可以重試分派、升級為人類或記錄失敗的分派記錄,但無法在相同工作階段內復原下游處理失敗。
• 針對最終必須呈現下游失敗的作業,請設計個別的回饋意見迴圈,例如下游流程發佈的平台事件、檢查工作狀態的排程流程,或位於工作人員工作階段之外的追蹤個案。

安全考量事項

• 在已命名認證中封裝所有外部非同步呼叫。叫用動作不會將端點 URL 或認證內嵌在程式碼中。
• 在將所有參數內嵌在事件裝載或訊息內文中之前,驗證並消毒傳送至叫用動作的所有參數。傳遞至非同步訊息的使用者提供文字是下游消費者中的潛在插入向量。
• 記錄分派時具有工作階段識別碼、參考識別碼和消毒裝載的每個分派。由於沒有回應傳回給工作人員,因此此記錄是重建工作人員起始內容的主要機制。
• 將最低權限套用至整合使用者或連線的應用程式。分派動作發佈至通知列不應保留允許在非相關系統上讀取或寫入的認證。

範例

處理即將到期的契約的續約管理工作人員會判定客戶符合自動續約通知的資格。工作人員不需要在結束排班前確認電子郵件已傳送。

1. CheckRenewalEligibility (自動啟動流程) 會評估契約條款、客戶層級和選擇退出狀態。傳回「符合資格」布林值和偏好的通知管道。
2. DispatchRenewalNotification (Apex 動作) 會發佈包含契約識別碼、客戶識別碼、通知管道,以及產生的無效金鑰的 RenewalNotification\_\_e 平台事件。傳回確認平台已接受事件的 ReplayId。
3. UpdateContractRecord (自動啟動流程) 會將 ReplayId 和分派時間戳記寫入「契約」記錄,並設定「已分派通知」狀態標記。

內容

外部應用程式 (例如客戶入口網頁、行動應用程式、第三方 SaaS 平台和合作夥伴系統) 必須以程式設計的方式叫用工作人員,以處理服務要求、起始工作流程,或在自己的介面內呈現 AI 驅動的回應。工作人員會作為智慧型後端服務。外部系統會提供內容、工作人員原因和動作,而來電者會取用回應。

呼叫者越來越多地是 AI 工作人員或協調員,而不是面向人的應用程式。在這些 AI 到 AI 模式中,協調工作人員將推理步驟、CRM 對應或動作委派給 Agentforce 作為離散工具呼叫。我們需要公開「模型內容通訊協定」(MCP) 伺服器才能支援此模式。

問題

當外部系統或 AI 工作人員需要依需求利用 Agentforce 工作人員的功能時,其如何進行驗證、建立工作人員工作階段、傳遞必要的對話與內容資料,以及可靠地接收工作人員的結構化回應,以推動其自己的下游邏輯?

力

套用此模式時,請回答下列問題:

• 外部來電者是否預期同步、低延遲回應,或非同步回呼是否可接受?
• 如何建立來電者身分,並將其移入工作人員的執行內容以存取和個人化資料?
• 同時 API 觸發工作階段的預期數量為何,以及其如何與 Salesforce API 比率和同時限制互動?
• 外部系統是否需要在多個輪數 (多輪對話) 之間維護工作階段連續性,或者每個要求都沒有狀態?
• 工作人員的回應應該如何結構化,如此呼叫系統才能以程式設計的方式剖析並採取動作?
• 呼叫者是需要直接 REST 整合的人類面向應用程式,還是可透過標準通訊協定 (例如 MCP) 叫用 Agentforce 作為工具的 AI 工作人員或協調員?

Salesforce 模式應用程式

草稿

隨選工作人員叫用的順序圖

結果

此模式會將 Agentforce 顯示為可呼叫的 AI 服務。外部系統可存取工作人員的邏輯、工具和 CRM 內容,而無須複製該邏輯。來電者仍負責工作階段生命週期管理和呈現回應。工作人員仍負責所有推理、工具選取和回應的合併。

當來電者是 AI 工作人員或協調員時,Agentforce 透過 MCP 機制 (透過 Salesforce Headless 360 立即可用) 會完全移除自訂 REST 整合的需求。MCP 伺服器代表通話工作人員處理工作階段生命週期,讓 Agentforce 能夠以一流的工具參與多工作人員工作流程,而不需要額外的管道處理。

設計考量事項

平台無效指引

• 避免在時效性 UI 流程中使外部 API 呼叫同步化或封鎖。採用投票或 Webhook 回呼模式,其中工作人員回應時間非稀有,以將使用者體驗與工作人員的處理時間分離。
• 根據來電者的性質 (而非可用性) 選取來電機制。人類面向應用程式與系統整合應直接使用工作人員 API。支援 MCP 的工具應使用 Agentforce MCP 伺服器。針對相同的來電者類型混合機制會增加不必要的複雜度,而不會產生結構效益。

Salesforce 實作注意事項

• 在工作階段建立 POST 要求 (而非第一個使用者訊息) 中插入工作階段內容。當外部系統建立工作階段時,它有機會直接將結構化內容變數 (帳戶識別碼、權益資料、先前互動摘要) 作為已命名工作階段參數傳遞。在處理單一輪數之前,工作人員可以使用這些變數,因此工作人員會從基本狀態開始推理,而無須發出對應呼叫以確定客戶是誰或其權益為何。將相同的資料傳送至訊息內文中,則會強制工作人員剖析非結構化文字,以將其可能接收為已輸入變數的實情解壓,進而增加延遲、導入解壓錯誤,並耗用不增加業務價值的推斷步驟。
• 設計工作人員回應為結構化且機器可讀取。使用輸出變數慣例和提示指示,引導工作人員在呼叫者是系統而非人類時傳回 JSON 易用或清楚分隔的回應。
• 明確管理工作階段生命週期。在將 DELETE /einstein/ai-agent/v1/sessions/{sessionId} 用於免費並行時段後立即結束工作階段,並避免在不相關的互動中持續存在過時的內容。
• Salesforce 同時工作階段限制的帳戶。針對高輸送量情況,請在通話系統中實作工作階段集區或排列層,以防止在高負載期間拒絕要求。
• 透過 MCP 叫用 Agentforce 時,傳遞內容作為工具輸入參數,而非作為工作階段變數。MCP 伺服器會以透明的方式管理工作階段生命週期,因此通話工作人員無法在建立時直接設定已命名工作階段參數。確保工具通話裝載中包含所有必要內容 (記錄識別碼、使用者身分、權益資料),讓工作人員從基本狀態開始推理。
• 將 MCP 伺服器的透明工作階段管理視為便利,而非同時略過。每個工具叫用仍會耗用 Salesforce 工作人員工作階段。透過 MCP 大規模呼叫 Agentforce 的高頻協調流程必須考慮適用於直接工作人員 API 呼叫者的相同同時工作階段限制。

錯誤處理與復原

• 工作人員 API 會傳回標準 HTTP 錯誤代碼。呼叫系統必須處理具有指數反向的「429 Too Many Requests」(比率限制),並使用重試邏輯處理「503 服務無法使用」。
• 當工作人員自己遇到無法解決的工具失敗時,會在回應內文中傳回絕佳的自然語言錯誤。呼叫系統會偵測到這些警示器回應 (例如,檢查回應中的「錯誤」狀態欄位),並透過重試其他內容、呈現回復體驗或將其路由至人類來進行。
• 透過 MCP 叫用時,錯誤會出現在兩個不同的層:MCP 傳輸錯誤 (格式錯誤的工具呼叫、伺服器無法使用) 和 Agentforce 推理失敗 (工具執行錯誤、無法解決的動作)。協調工作人員必須獨立處理這兩個層級。MCP 傳輸錯誤應在通訊協定層級觸發重試;在工具回應中傳回的 Agentforce 推理失敗應由協調員自己的回復或升級邏輯處理。

安全考量事項

• 針對外部用戶端應用程式使用最窄的 OAuth 範圍。僅需要叫用工作人員的整合不應包含超出工作人員本身所需的資料存取範圍。
• 先驗證並消毒外部系統中的所有輸入,再將其注入為工作階段變數。外部輸入是提示插入的攻擊表面。例如,惡意來電者可以建立「customerQuery」欄位,其設計目的是覆寫工作人員指示。
• 在外部用戶端應用程式上套用 IP 允許清單,以限制哪些外部系統可以驗證並呼叫工作人員 API。
• 記錄具有來電者身分、工作階段識別碼和要求/回應中繼資料的所有輸入 API 觸發工作階段,以供稽核和安全性之用。
• 透過 MCP 叫用 Agentforce 時,MCP 伺服器會代表呼叫使用者向 Salesforce 進行驗證。確定 MCP 伺服器的連線應用程式認證範圍已限定為最低必要權限,且一般使用者身分 (使用 MCP 工具 (例如 Claude) - 身分會透過工具輸入參數明確地移入至工作階段內容。

範例

金融服務入口網頁會觸發 Agentforce 工作人員處理抵押貸款查詢。

1. 入口網頁會使用「用戶端認證 OAuth」流程進行驗證,並取得承載者權杖。
2. 它會呼叫「POST / Einstein/ai-agent/v1/sessions」,且工作階段變數為「{ “accountId”: “001xx…”, “productType”: “mortgage”, “loanAmount”: 450000 }」。
3. 使用者提交其問題:「我需要哪些文件才能完成申請?」
4. 入口網頁會呼叫具有使用者文字的「POST / Einstein/ai-agent/v1/sessions/{sessionId}/messages」。
5. Agentforce 工作人員會叫用「GetDocumentChecklist」流程動作、「取得貸款類型」特定需求,並傳回結構化清單。
6. 入口網頁會內嵌呈現工作人員的回應,並在使用者結束時關閉工作階段。

內容

並非所有工作人員工作流程皆源自於人類要求。業務關鍵訊號 (例如產品用量度量突然下降、高價值手推車遭到捨棄,或付款失敗超過風險值) 經常出現在營運資料中。當這些訊號需要智慧型、多步驟的回應時,等待人類注意並採取行動會導致延遲,這會合併為實際的業務成本。

此模式描述即時事件如何作為工作人員的獨立進入點。工作人員由資料條件 (而非使用者)、事件內容上的原因叫用,並且執行回應工作流程,完全不需要人工起始。

問題

當 Data 360 或 Salesforce 平台中發生即時業務事件時,該事件如何能自動例項化工作人員工作階段、將事件裝載作為奠基內容,並在沒有人類起始或引導互動的情況下,驅動非對話動作工作流程完成?

力

套用此模式時,請回答下列問題:

• 事件觸發時是否需要立即回應,還是近乎即時的處理 (秒到分鐘) 可接受?
• 事件裝載是否包含足夠的內容讓工作人員奠基,或者工作人員是否需要執行額外的對應,才能有效推理?
• 預期事件量與頻率為何?高流量事件串流需要比率管理,以避免耗用工作人員同時限制。
• 同一個事件是否可針對同一個業務實體觸發多次 (至少傳送一次)?如果是,動作必須為 idempotent。
• 如果工作人員無法自行解決事件,是否會有人力升級路徑?
• 如何呈現失敗的事件處理?使用無效字母,警示或個案建立?

Salesforce 模式應用程式

草稿

事件驅動工作人員執行的 序列圖

結果

工作人員會成為即時業務作業的反應性參與者,而非人類要求的被動回應者。事件觸發的工作人員可以以資料的速度執行復原、分級和升級工作流程,而非人類注意的速度。

觸發系統 (Data 360 或平台事件) 仍負責事件偵測和裝載產生。工作人員仍負責考量該裝載並選取正確的動作鏈。無須對話輪數;事件裝載是完整輸入。

設計考量事項

平台無效指引

• 設計非對話叫用的所有動作。沒有使用者輪數;工作人員必須僅從初始奠基內容達成解決方案。動作應傳回結構化、決定性的輸出,而非提示進行說明。
• 建立工作人員工作階段之前,請確保事件裝載帶有足夠的奠基內容。強制工作人員在原因前進行多個對應呼叫的精簡裝載會增加延遲和同時耗用。
• 讓所有由事件驅動的工作人員觸發的寫入作業都無法使用。事件傳送系統通常會至少提供一次保固。重複事件處理不能產生重複的副作用。

Salesforce 實作注意事項

• 在 Data 360 觸發流程中,在工作階段建立時,將事件裝載屬性 (例如「accountId」、「eventType」、「metricValue」、「productIds」) 直接對應至已命名工作階段變數。這會讓工作人員從第一個推理步驟開始,而不需要採取取動作。
• 針對平台事件觸發,請使用「自動啟動流程」,而非畫面流程。非對話式的自發環境不支援畫面流程。
• 針對事件觸發的工作階段設定明確的工作階段逾時。不同於對話工作階段,沒有使用者可以延伸互動;停滯在失敗動作的工作階段不應無限期保留同時時段。
• 使用流程錯誤路徑來處理工作人員工作階段建立失敗。如果無法建立工作階段,則錯誤路徑應發佈補償事件或為人類追蹤建立個案,而非靜音捨棄事件。

錯誤處理與復原

• 由於並行限制、工作階段建立錯誤或裝載驗證失敗而導致無法成功觸發工作人員工作階段的事件,應路由至建立個案、觸發警示或將事件發佈至無效字母排列的錯誤路徑,以供重新處理。
• 工作人員在執行期間失敗 (例如必要動作逾時) 應以原始事件識別碼記錄。由於觸發為非同步且沒有等待呼叫者,因此錯誤表面完全以可觀察性為基礎:記錄、顯示面板和警示值。
• 實作重試限制。如果事件可靠地導致工作人員失敗,則未繫結的重試會耗盡同時限制。在可設定的嘗試次數上限後,將事件路由至已附加完整內容的人類檢閱排隊。
• 透過完整的工作人員工作階段生命週期追蹤事件識別碼。此追蹤會啟用來源資料訊號與所有用於稽核與除錯的下游動作之間的關聯。

安全考量事項

• 先驗證並消毒所有事件裝載屬性,再將其注入為工作人員工作階段變數。Data 360 或外部發行者的事件裝載是提示插入的攻擊面。例如,建立的裝載欄位可以設計為覆寫工作人員指示。
• 在專屬、最低權限整合使用者之下執行事件觸發的工作人員工作階段,而非在高權限管理員身分。工作人員僅擁有執行其所定義動作集所需的權限。
• 記錄具有原始事件識別碼、事件類型和建立時所插入工作階段變數的所有事件觸發工作階段。此稽核追蹤是必要的,才能重新建構工作人員在結果有爭議時採取特定動作的原因。

範例

零售公司使用 Data 360 追蹤即時手推車行為。當捨棄的手推車值高於定義的值時:

1. Data 360 偵測到捨棄訊號並觸發具有事件裝載的觸發流程:“customerId”、“cartValue”、“productIds” 和 “abandonmentTimestamp”。
2. 流程會將這些屬性對應至 Agentforce 工作階段變數,並建立新的工作人員工作階段。不需要使用者互動。
3. 工作人員使用其可用的尋找動作評估客戶的購買歷程記錄、目前權益和手推車組成。
4. 工作人員會叫用一個 SelectRecoveryOffer 動作,其會根據客戶區段套用適當的折扣層級,以及透過客戶偏好的管道提供優惠的 SendProactiveNotification 動作。
5. 工作人員會叫用 CreateFollowUpTask 以在 CRM 中記錄互動,以取得帳戶擁有者的可視性。
6. 動作鏈完成後,工作階段會自動關閉。為了可追溯性,原始事件識別碼會保留在工作階段記錄中。

內容

LLM 已針對公用資料進行訓練。他們對您組織的產品、原則、個案歷程記錄或契約沒有 Knowledge,除非在推斷時明確提供該資訊。若沒有奠基,則工作人員詢問客戶的服務權益或特定契約的條款會讓回答有幻覺,或承認不知道。企業環境中都無法接受結果。

取得增強型產生 (RAG) 會透過從企業 Knowledge 存放庫中提取相關文件,並在產生回應前將其注入工作人員的內容視窗中來解決此問題。工作人員會針對如 Knowledge 文章、過去的個案解決方案、產品規格等已提取內容推理,就如同直接提供該資訊一樣。LLM 會提供邏輯;提取層會提供實情。

例如,處理複雜保固索賠的服務代理不需要在其指示中內嵌保固原則條款。相反地,當客戶描述其問題時,工作人員會根據保固文件的向量索引,執行語意搜尋或混合式搜尋 (關鍵字搜尋 + 語意搜尋),並取回適用的字詞,並使用這些字詞來判斷資格和後續步驟。答案以目前的授權原則文件為基礎,而非模型的訓練資料。

問題

工作人員需要回答取決於專屬組織 Knowledge 的問題或做出決策,例如原則、契約、產品文件或未屬於 LLM 訓練資料的歷史個案資料。工作人員要如何在推理的時刻,以最相關的內容取得、確保已提取的內容為最新且具權威性的內容,並以足夠的精確度將其注入內容以避免雜訊?

力

套用此模式時,請回答下列問題

• Knowledge 內容是否為靜態且不常更新 (例如產品手冊),還是持續變更 (例如個案解決方案、庫存描述)?更新頻率會決定取用管道設計。
• 內容的大小為何?一個小型 Knowledge 庫可以精確地提取;一個大型 Knowledge 庫需要切分、內嵌和語意索引才能傳回最相關的段落。
• 查詢是否受益於單一的專注式提取,或將來自多個 Knowledge 來源的結果 (例如,文件和過去的個案) 同時結合,會產生更明確的回答?後者需要集合提取。
• 在語意排名之前,是否需要先依中繼資料篩選所取的內容,例如,將結果限制為與客戶產品層級或地理位置相關的文件?
• Knowledge 內容的敏感度為何?系統會將檢取的內容注入至 LLM 內容視窗,並影響工作人員的回應;不應呈現給特定使用者的內容必須受管理,而非由 LLM 篩選。

Salesforce 模式應用程式

草稿

企業內容 Knowledge 基礎的順序圖

結果

工作人員的回應會固定在組織目前的權威 Knowledge,而非 LLM 的訓練資料。對於實際問題 (例如保單條款、產品規格、權益詳細資料) 的虛擬風險會減少,因為模型會考量所取得的證據,而非從記憶體產生。

Knowledge 內容仍可獨立維護。更新原則文件或將新個案解決方案新增至索引會立即對所有後續的工作人員互動生效,而無須重新訓練或重新部署模型。

提取也提供隱含稽核追蹤。由於工作人員的回答是衍生自特定的採取文件,因此可以將來源內容與回應一起記錄,以便追蹤工作人員提供特定回答的原因。

設計考量事項

平台無效指引

• 以正確的細微度切分與內嵌 Knowledge 內容。太大的區塊會使相關性變化。太小的區塊會失去 LLM 需要正確推理的周圍內容。針對大多數的企業文件類型,段落層級切分與重疊的內容視窗會產生最佳尋找品質。
• 請將提取精確率視為一流的設計考量。將低相關性內容注入工作人員的內容視窗並非中立。它會產生降低回應品質的雜訊。針對每個 Knowledge 網域,調校取回值與精確度之間的平衡。
• 接收延遲是作業 SLA。若原則文件已更新,但向量索引尚未重新整理,則工作人員會取用過時資訊並採取動作。針對每種類型的內容定義可接受的延遲容忍度,並相應地設計取用管道。

Salesforce 實作注意事項

• 透過適當的內容更新頻率,填入 Data 360 向量索引。針對靜態文件使用批次匯入,針對持續變更的記錄使用串流或變更資料擷取 (CDC)。
• 針對 Ensemble Retrievers,設定每個來源的相關性排名加權。已解決個案索引可能需要最近偏差;原則文件索引可能不需要。根據工作人員預期處理的查詢類型調整加權。
• 在執行語意搜尋之前,請在自訂 Apex 或流程提取器中使用中繼資料篩選條件,以縮小範圍。在排名前依產品線、區域或文件類型篩選,可減少雜訊並改善插入內容的精確度。
• 請勿在 LLM 內容中注入完整的已提取文件。僅傳遞相關的區塊或摘要。大型內容插入會耗用權杖預算、增加延遲,並降低工作人員推理可用的內容視窗比例。

錯誤處理與復原

• 如果沒有傳回任何結果,請傳回明確的「找不到結果」狀態,而非繼續進行不依據。工作人員可以擴大查詢範圍、要求使用者說明,或將其升級為人類。
• 每個傳回的區塊都包含相關性分數。根據使用個案而定,應設定某個信賴/相關性值,工作人員應將該值視為信任,否則該值應回復至說明或升級。
• 如果向量索引或提取服務暫時無法使用,則提取器動作或 Apex 呼叫應傳回具有描述原因的結構化錯誤。使用工作階段識別碼和查詢記錄失敗,以便識別取用間隙,並監視索引或服務的可用性。
• 針對具有時效性的 Knowledge 網域,請實作重新整理檢查,以取得回應。如果最近的比對文件上次更新超過定義的延遲性值,請將其標記給工作人員,以使其符合其驗證回應或提示的資格。

安全考量事項

• 搜尋必須遵循工作人員代表其採取動作之使用者的資料存取權限。在面對客戶互動的情況下執行的工作人員工作階段,不可以提取內部作業文件、定價策略注意事項,或一般使用者無法存取的記錄。將欄位級和記錄級安全性套用至檢索層。請勿依賴 LLM 來保留敏感的搜尋內容。
• 系統會將取得的內容注入至 LLM 內容視窗,且可能會影響或顯示在工作人員的回應中。視一般使用者可能可看見,並視需要管理內容成員資格。
• 並列記錄工作階段識別碼的所有取用查詢和所取用區塊的文件識別碼。此稽核追蹤可讓工作人員在回應時重建使用的證據,這可能需要合規性、爭議解決或可解釋性義務。

範例

財務服務工作人員處理客戶對固定期貨產品的提早兌換懲罰查詢:

1. 客戶詢問:「如果我提前六個月提款,我會受到什麼懲罰?」
2. 工作人員會根據產品條款和條件文件的向量索引,叫用設定為「個人取得者動作」。
3. 檢索器會使用查詢內容 (例如產品類型和客戶帳戶) 以及特定問題來執行語意搜尋,並傳回三個最相關的文件區塊 - 早期兌換子句、罰款計算表格,以及適用於困難個案的例外情況。
4. 系統會在客戶的問題旁,在工作人員的內容視窗中注入所取用的區塊。
5. 工作人員因原因超出所取用條款、識別客戶產品層級和兌換時間表的適用罰款率,並傳回精確且以原則為基礎的回答,其中引用其使用的條款生效日期。
6. 系統會使用工作階段記錄記錄來驗證所取用的區塊文件識別碼。

內容

LLM 依本質為概率。當要求客戶說明特定客戶的理由時,他們會推斷、估計或假設未明確提供的事實。工作人員叫用定價動作但不知道客戶是偏好層級的高價值企業帳戶,可能會套用錯誤的折扣邏輯。工作人員在未瞭解客戶流失風險分數的情況下升級支援個案時,可能會使離開的帳戶失去優先順序。

「已驗證的客戶內容插入」會在工作人員叫用動作之前,透過使用統一設定檔的已驗證結構化屬性,來預先填入動作輸入參數來解決此問題。工作人員不會推斷客戶的區段、終身價值或客戶滿意度 (CSAT) 趨勢。它會接收這些實情作為基礎輸入,以及這些實情的原因。此模式可降低客戶特定決策的幻燈風險,並在推理週期內消除冗餘的對應呼叫。

例如,在定價工作人員叫用「GenerateQuote」動作之前,子工作人員組態會自動從其統一設定檔中注入客戶的區段、層級和存留時間值。動作會收到已驗證的實情,而非 LLM 推出的約略,且報價會固定至客戶的實際商業關係。

這不是「Knowledge Grounding from Enterprise Content」模式的替代方式。設計良好的工作人員可以同時使用:「企業內容的 Knowledge 基礎」提供以文件為基礎的 Knowledge,而「已驗證的客戶內容插入」會建立客戶身分。

問題

您如何在工作人員採取行動之前,確保工作人員具有準確且客戶特定的事實,例如區段、層級、終身價值、流失風險或其他設定檔屬性,而不必自行猜測這些事實?

力

套用此模式時,請回答下列問題:

• 哪些動作輸入參數代表客戶特有的實情,如果推斷而非取得來源,則會產生不正確或不一致的成果?
• 必要設定檔屬性是否可作為標準 Data 360 統一設定檔欄位使用,或是否需要從原始行為與交易資料衍生的已計算洞察?
• 相關設定檔屬性的變更頻率為何?如流失風險分數或 CSAT 趨勢等屬性需要更新保證;過時的設定檔資料會導致與虛擬資料相同的錯誤結果。
• 設定檔屬性是否應在工作階段建立時間 (工作階段持續時間的一常數) 時注入,或在動作叫用時重新提取 (以反映工作階段中狀態變更)?
• 工作人員是否需要直接考量設定檔屬性,或者這些屬性僅由動作所耗用,且與工作人員的推理迴圈不相符?

Salesforce 模式應用程式

草稿

已驗證客戶內容插入的順序圖

結果

動作會收到經過驗證的結構化客戶實情,而非由 LLM 推出的約略。工作人員的推理會固定在客戶的實際設定檔狀態,減少對實際準確性決定成果品質 (例如定價、權益檢查、升級路由、保留優惠) 之決策的虛擬風險。

設定檔奠基也會減少推理延遲。當工作人員不需要發出對應呼叫來建立基本客戶內容時,推理週期會變短,並耗用較少輪數的同時數。

Data 360 統一設定檔仍是客戶實情的權威來源。子代理程式組態或連線流程是整合整合。工作人員負責考量這些事實並選取動作,而非自行取得事實。

設計考量事項

平台無效指引

• 識別所有具有幻覺風險的動作輸入,其中 LLM 推斷可能會產生錯誤的成果而非已驗證值。具有幻覺風險的輸入是設定檔基礎的候選項目。並非每個輸入都需要奠基;過度插入設定檔資料會對工作人員的內容視窗增加雜訊。
• 將設定檔重新整理視為設計決策,而非後續考慮。定義每個已奠基屬性的可接受延遲容忍度,並相應地選擇插入機制:針對穩定屬性的工作階段層級對應,針對波動屬性的流程式重新整理。
• 「已計算洞察」應編碼業務邏輯,而非原始度量。工作人員推理 0.87 的「churnRiskScore」比工作人員推理 14 個原始行為訊號更有效。在 Data 360 中計算轉譯;將結果傳遞給工作人員。

Salesforce 實作注意事項

• 設定檔奠基僅與其背後的統一相同。例如,「統一設定檔」的值完全取決於身分解析上游的品質。如果客戶在尚未統一的來源系統之間有分割的身分,則工作人員接收的設定檔屬性將不完整,或僅代表部分檢視 (例如,使用來自一個管道而非另一個管道的資料計算的「存留時間值」)。
• 針對 Data 360 連線的流程,請使用「取得記錄」元素,並在目前工作階段的「recordId」或「accountId」上使用篩選條件,以僅取用相關的設定檔記錄。僅傳回下游動作所需的屬性;請勿傳回完整設定檔物件。
• 「已計算洞察」必須透過 Data 360 採取管道保持在最新狀態。針對在時間敏感性決策中使用的洞察設定串流或近乎即時重新整理 (例如,保留工作流程中的流失風險)。批次重新整理的洞察適用於變慢的屬性 (例如年度契約值層級)。
• 動作叫用之前,驗證對應的設定檔屬性為非空值。傳遞至定價動作的空值「customerTier」會像虛擬值一樣有害。使用流程決策元素來偵測遺漏的設定檔資料,並路由至傳回,此傳回會提取預設值或提示進行說明。
• 在子代理程式組態中,使用描述性且在語意上清楚的變數名稱 (例如「customerTier」、「lifetimeValueUSD」、「churnRiskScore」),將設定檔屬性對應至動作輸入參數。LLM 會在選取和撰寫動作時讀取這些名稱;不明確的名稱會降低選取的準確度。

錯誤處理與復原

• 如果動作叫用時必要的設定檔屬性為空值或無法使用,則工作人員不應繼續使用可能不正確的預設值。動作應傳回表示遺漏屬性的結構化錯誤,且工作人員應提示使用者進行說明,如果非對話,則應升級為人類。
• 如果 Data 360 連線的流程找不到設定檔資料 (例如,由於 Data 360 服務中斷),則流程的錯誤路徑應傳回具有特定失敗原因的結構化錯誤給工作人員。工作人員接著可以決定是否要重試、繼續使用降級的體驗,或將失敗呈現給使用者。
• 記錄在工作階段建立或動作叫用時並列於工作階段識別碼旁的所有設定檔屬性值。如此可確保任何有爭議的工作人員決策都可使用工作人員在該時間提供的確切客戶實情來重建。

安全考量事項

• 注入工作人員內容的設定檔屬性會受到與任何 CRM 記錄相同的資料存取控制。確定用於解析設定檔屬性的整合使用者或連線應用程式僅擁有所呈現屬性的必要欄位級權限,而不擁有更廣泛的設定檔讀取存取權。
• 編碼敏感衍生的度量 (例如,預測健康分數、財務風險等級) 的「已計算洞察」應視為敏感欄位,且由與基本資料相同的存取控制項所管理。若要向在面向客戶的情況下作業的工作人員呈現高流失風險分數,則需要仔細考量工作人員可能傳達的內容。
• 請勿呈現動作不需要的設定檔屬性。工作人員內容視窗中的每個其他屬性都是可在工作人員回應中複製的其他資料元素。將最低必要原則套用至設定檔基礎。
• 稽核已將「已計算洞察」或敏感設定檔屬性作為輸入的所有工作階段。這些工作階段代表根據衍生的客戶智慧做出決策,且可能受限於特定產業的可說明性或法規需求。

範例

一家電信公司使用 Agentforce 處理已起始取消要求的客戶保留對話。

• 開啟取消個案時,會以客戶的「accountId」作為內容建立工作人員工作階段。
• 子工作人員組態會在建立時將三個「Data 360 統一設定檔」屬性對應至工作階段變數:“customerTier” (Enterprise)、“lifetimeValueUSD” (42,000) 和 “contractRenewalDate” (60 天)。
• 如「churnRiskScore」等「已計算洞察」(0.91 計算自用量下降、支援票證頻率和 NPS 趨勢) 會透過叫用為第一個動作步驟的 Data 360 連線流程,對應為額外的工作階段變數。
• 工作人員現在以已驗證的客戶實情為基礎,並叫用「SelectRetentionOffer」動作。由於輸入包含「customerTier = Enterprise」、「lifetimeValueUSD = 42000」和「churnRiskScore = 0.91」,因此動作會傳回最大層級保留優惠,而非標準保留優惠。
• 工作人員會叫用「PresentOffer」以在交談中提供優惠,並叫用「LogRetentionAttempt」以記錄 CRM 中所有已保留以供稽核之基礎屬性的互動。

內容

企業資料會分割。工作人員僅能針對 Salesforce 平台內存在的內容採取動作,僅限於其有效推理所需的部分資訊。回答服務問題可能需要在 Service Cloud 中閱讀客戶的未結束票證。準備提案可能需要從 Google 雲端雲端雲端雲端雲端雲端雲端雲端雲端雲端雲端雲端。分析產品用量可能需要查詢資料倉庫。每個系統都有自己的 API、自己的驗證模型和自己的資料結構描述,以及為每個系統撰寫量身打造整合程式碼的成本,這在歷史上已經讓工作人員與系統的連線變得昂貴且脆弱。

MCP 是直接解決此問題的開放標準。它會定義統一介面,讓工作人員可透過此介面探索並叫用任何 MCP 相容伺服器公開的工具,無論基礎系統為何。每個 MCP 伺服器都會作為轉接器:它會將目標系統的原生介面包含在標準化、以工具為中心的介面中,讓工作人員可以查詢、叫用和撰寫,而無須瞭解系統特定通訊協定或結構描述的任何資訊。

從工作人員的角度來看,連線至 Slack、結構化查詢語言 (SQL) 資料庫和文件管理系統看起來相同,三個 MCP 伺服器,每個伺服器都會顯示一組描述的可呼叫工具。工作人員會根據其語意描述和嘗試達成的目標,選取並將其排序。

問題

當工作人員需要在多個外部系統 (每個外部系統都有不同的 API、驗證和結構描述) 之間提取資訊或觸發動作時,工作人員如何可以探索、叫用和撰寫其功能,而無須為每個系統量身打造整合程式碼或與任何系統實作緊密連接?

力

套用此模式時,請回答下列問題:

• 工作人員是否需要存取 Salesforce 平台外的系統,例如文件存放區、協同合作工具、資料庫、第三方 SaaS,其 API 未以 Agentforce 動作原生表示?
• 是否需要動態工具探索,以便工作人員根據目前要求在考量時識別正確的整合端點,而非在其組態中硬式編碼整合?
• 整合狀況是否經常變更;新增系統、更新現有系統,以及其他變更可能需要量身打造的每個系統方法是否會造成不可持續的維護負擔?
• 是否需要將工作人員的推理層與下游系統的實作詳細資料分開,讓目標系統 API 中的變更不需要變更工作人員的指示或子工作人員組態?
• 目標系統是否由不同的小組或廠商所擁有,每個廠商負責公開自己的能力,使提供者端 MCP Server 模型比每個工作人員的消費者端整合更實用?

Salesforce 模式應用程式

草稿

已驗證客戶內容插入的順序圖

結果

工作人員可接觸的面積會展開,而不會增加其整合複雜度。新增外部系統表示要為其部署或設定 MCP 伺服器,而不是為每位工作人員撰寫量身打造的 Apex 呼叫或流程整合。工作人員的推理層保持不變,其會僅根據其語意描述來探索並叫用新工具。

MCP 標準也會建立完整的擁有權分隔:負責系統的小組將其功能公開為 MCP 伺服器;工作人員小組會取用這些功能,而不需要瞭解系統的內部。此邊界會隨著整合系統數目增加,減少協調負擔。

工具可組合性是直接結果。由於所有工具皆共用相同的叫用介面,因此工作人員可以將不同系統的工具鏈結、從 Google Drive 提取檔案、從其中提取資料,並將結果寫入 CRM 記錄,就像在一個系統內的鏈結動作一樣。

設計考量事項

平台無效指引

• 工具描述是工作人員決定是否以及如何叫用工具的唯一基礎。以明確且以意圖為基礎的語言撰寫描述,說明工具的功能、套用時間,以及傳回的內容。說明「查詢 CRM 資料庫」的說明,不如說明「針對指定帳戶識別碼,依優先順序排序的收取帳戶未結束個案」。 描述不佳會導致工具選取不佳。
• 將每個 MCP 工具範圍設定為單一原子功能。此工具會使工作人員難以思考、難以在失敗時重試,且難以保護兩個獨立工具時,也會將摘要寫回來源系統。一個工具,一個責任。
• 設計工具,使輸出為可組合的輸入。要以自然地對應至通常跟隨其動作工具之輸入參數的方式,來結構取用工具的結果,以減少工作人員在步驟之間必須執行的轉換工作。
• 遠端主控 MCP 伺服器。本機二進位安裝會建立隨著工作人員環境數量而增加的部署和版本化複雜性。遠端主控的伺服器可以獨立於取用伺服器的工作人員更新。

Salesforce 實作注意事項

• 如果您想要在所有輸出 MCP 呼叫之間進行一致的 MCP 驗證、比率限制、裝載驗證,請先使用 AI Gateway,例如 MuleSoft Omni Gateway 支援 MCP 伺服器,並在向工作人員公開任何 MCP 伺服器之前進行設定。
• 針對 MCP Server 連線所需的所有認證,使用 OAuth 2.0 認證。認證不能顯示在工具參數、動作組態或 Apex 程式碼中。
• 根據業務使用個案 (例如基金轉移),某些 MCP 工具可能需要一般使用者認證才能採取某些動作。若要移入一般使用者身分權杖,請使用目前 MuleSoft Omni Gateway 支援的 OAuth 2.0 On behalf Of Credentials Injection 原則。
• 針對自訂 MuleSoft MCP 伺服器:在 MuleSoft 的 API 規格中定義 MCP 工具結構描述,並在 Agentforce 工具目錄中註冊伺服器端點。根據代表工作人員查詢測試工具描述,以在部署至生產環境前確認工作人員為正確工作選取正確的工具。

錯誤處理與復原

• 當 MCP 工具呼叫傳回錯誤時,工作人員會檢查機器可讀的錯誤代碼,以決定適當的復原動作:向使用者要求遺漏的參數、使用更正的輸入重試,或升級至人類。它永遠不會靜音取用錯誤,或繼續思考,如同工具呼叫成功一樣。
• 工作人員會直接針對暫時失敗實作重試邏輯。
• 使用工具名稱、精簡的輸入參數和成果,記錄來自用戶端的每個 MCP 工具叫用。此用戶端追蹤結合伺服器端記錄,是診斷工作人員在工作流程未產生預期結果時採取特定動作路徑的原因的主要機制。

安全考量事項

• 所有輸出 MCP 伺服器連線皆會通過該門戶。管道會強制執行驗證、限制比率以防止工具濫用,以及裝載檢查以偵測工具參數中的提示插入嘗試。工作人員與 MCP 伺服器的直接、未媒介連線會略過這些控制項,且不允許。
• 將每個工作人員的 MCP 伺服器連線範圍僅限於工作人員實際需要其工具的伺服器。設定具有所有可用 MCP 伺服器存取權的工作人員,其攻擊面積大於僅連線至其所定義工作所需工具的工作人員。
• 將工具輸入參數傳遞至工具前,請先驗證和精密化這些參數,特別是當參數值衍生自使用者提供的文字或 LLM 產生的內容時。請勿將未驗證的 LLM 輸出直接傳遞為工具參數;影響工作人員推理的攻擊者可以使用該路徑將惡意值注入下游系統呼叫。
• 將工作人員的已連線 MCP 伺服器清單及其工具庫存視為敏感組態。攻擊者知道工作人員有哪些可用的工具,以及他們接受哪些參數,其擁有用於建立提示插入裝載的地圖,其設計目的為濫用這些工具。

範例

銷售工作人員在高價值的客戶通話前準備全方位的帳戶簡介:

1. 工作人員收到下列要求:「在明天續約討論之前準備有關 Acme Corp 的簡報。」
2. 工作人員查詢 MCP 工具目錄,並識別兩個 MCP 伺服器中的三個相關工具:GetRecentEmails、GetOpenOpportunities 和 GetSupportTicketSummary。
3. 工作人員會並列叫用所有三個工具。每個 MCP 伺服器都會將呼叫翻譯為其目標系統的原生 API 、提取相關資料,並傳回結構化結果。
4. 工作人員會收到三個結果。最近的電子郵件討論串、含交易大小和階段的未結束續約機會,以及依優先順序的未結束支援票證摘要,並將其合併為結構化帳戶簡介。
5. 工作人員會叫用 CreateAccountNote 將簡報儲存至帳戶記錄,並將摘要傳回給要求使用者。
6. 所有四個 MCP 工具叫用皆會使用工作階段稽核記錄的工具名稱、伺服器身分和成果,來記錄。

內容

輸出 MCP 模式描述 Agentforce 工作人員從外部 MCP 伺服器中取用工具。輸入模式會反轉。Salesforce Platform 功能 (例如 CRM 記錄、流程、Apex 邏輯和 Data 360 洞察) 會顯示為外部工作人員在任何 LLM 架構上執行的 MCP 工具,這些工具可以探索和叫用。

此模式很重要,因為企業 AI 部署極少是單一廠商。合作夥伴的工作人員建立在不同的架構上,可能需要在 Salesforce 中查詢客戶的帳戶狀態。執行 Python 型工作人員的內部資料科學小組可能需要觸發 Salesforce 流程以開始批准流程。若沒有標準化曝光機制,每個外部消費者都需要量身打造的整合。將 Salesforce 功能公開為 MCP 伺服器,無論呼叫工作人員的建立方式為何,都能為每個 MCP 相容的工作人員提供平台工具的統一且可探索的介面。

例如,合作夥伴的採購工作人員建立在第三方架構上,必須先在 Salesforce 中驗證供應商的契約狀態,才能批准採購訂單。它在 Salesforce MCP Server 上叫用 GetContractStatus 工具,而不是建立直接 REST 整合。此工具會強制執行與任何原生 Salesforce 作業相同的存取控制;呼叫工作人員只會看到結果。

問題

當在不同架構上建立、由合作夥伴擁有或在 Salesforce 平台外執行的外部工作人員需要叫用 Salesforce 功能作為自己的工作流程的一部分時,這些功能如何以標準化、可探索且安全管理的方式公開,而不需要針對每個外部消費者量身打造的整合?

力

套用此模式時,請回答下列問題:

• 需要取用 Salesforce 功能的外部工作人員是否以支援 MCP 標準的架構為基礎?若否,則 REST API 或 Webhook 方法可能比 MCP 更適合。
• 需要顯示哪些 Salesforce 功能 - 唯讀資料提取、寫入作業、流程叫用或組合?公開範圍會直接決定必須管理的安全性面積區域。
• 如何驗證外部通話工作人員的身分,以及其叫用應在哪些 Salesforce 權限下執行?工作人員對平台的通話不能繼承比特定作業所需更廣泛的權限。
• Salesforce MCP Server 是否適用於內部消費者 (相同組織中其他小組的工作人員) 或外部消費者 (合作夥伴和客戶工作人員)?這些受眾之間的 Trust 模型與驗證需求會顯著不同。
• 一組公開工具隨著時間有何變化?新增至 MCP 伺服器的新 Salesforce 功能會立即可供所有連線的工作人員發現;非預期的工具曝光必須透過有意的發佈流程來管理。

Salesforce 模式應用程式

草稿

業務功能作為可呼叫工具的順序圖

結果

Salesforce 會成為多廠商工作人員生態系統的一流參與者。外部工作人員可以探索和取用平台功能,而不需要每個消費者或每個使用個案的自訂 REST 整合。如果整合維護超額不按比例增加,則消費者數量會增加。

透過「無周邊 360」,Salesforce 權限模型會管理每個輸入工具叫用。外部 MCP 用戶端不會略過現有的資料存取控制;它們會在其中作業。這表示透過 MCP 公開功能的安全性狀態等同於透過任何其他已驗證 API 介面公開功能。

工具可探索性是複合優點。當新的 Salesforce 功能新增至 MCP Server 的工具目錄時,這些功能會立即可供所有已連線的外部工作人員使用,而不需要這些工作人員更新其組態。

設計考量事項

平台無效指引

• 僅發佈外部工作人員需要的內容。每個新增至 MCP 伺服器目錄的工具都會擴大攻擊面積和監管負擔。刻意稽核工具庫存。定義已批准用於外部耗用的功能,並將未批准的曝光視為組態缺口,而非預設值。
• 為外部消費者撰寫工具描述。外部工作人員的運算子對您的內部資料模型或命名慣例沒有 Knowledge。將描述保持獨立:工具執行的動作、每個參數的意義、結果代表的內容,以及呼叫者必須滿足的任何限制或先決條件。
• 輸入或輸出結構描述變更時明確版本工具。如果結構描述沒有通知,依賴工具目前結構描述的外部工作人員將會無聲中斷。使用與對公用 REST API 進行中斷變更相同的規範來處理 MCP 工具介面的中斷變更。

Salesforce 實作注意事項

• 在一般使用者下,執行每個輸入 Salesforce 立即可用 (OOTB) MCP (Headless 360) 工具叫用,其權限僅限於公開工具所需的作業範圍。請勿在高權限管理員身分下執行輸入工作人員通話。
• 若要在所有 MCP 工具中一致套用驗證、比率限制、結構描述驗證和個人可識別資訊 (PII) 偵測,請使用 AI Gateway,例如 MuleSoft Omni Gateway。
• 針對 MuleSoft MCP 面向,請在 MuleSoft 中獨立定義基本 Salesforce API 結構描述的 MCP 工具結構描述。MCP 介面應反映來電工作人員的概念需求,而不是支援的 Salesforce 物件形式。此分離可讓 Salesforce 實作在不中斷外部工具契約的情況下進行演進。

錯誤處理與復原

• 工具叫用失敗時,必須傳回具有機器可讀程式碼和純文字描述的結構化 MCP 錯誤回應。呼叫外部工作人員無法看見 Salesforce 平台的內部,例如錯誤訊息必須獨立且可運作,而不需要 Salesforce 特定錯誤代碼或物件模型的 Knowledge。
• 必須立即傳回比率限制錯誤和驗證失敗,並提供足夠的資訊,外部工作人員的運算子才能診斷及修復已達到哪個比率限制,或已拒絕哪個認證,而不公開內部組態詳細資料。
• 在 Omni Gateway 中記錄所有輸入 MCP 工具叫用,其中包含來電工作人員的身分、叫用的工具、輸入參數 (已精簡敏感值) 和結果。此記錄是診斷外部消費者回報失敗的主要證據追蹤,用於稽核外部工作人員存取的項目。

安全考量事項

• 必須先驗證每個輸入 MCP 連線,才能到達任何工具。請勿允許未經驗證的發現工具目錄;公開功能清單本身就是敏感資訊。
• 除了連線層級驗證以外,請套用工具層級授權。註冊的外部工作人員只能叫用其已明確授予其存取權的特定工具,而無法叫用完整目錄。強制執行此動作,不要在應用程式層。
• 先驗證並精密化所有輸入工具參數,然後再將其傳送至 Salesforce Platform 作業。外部工作人員的參數是不受信任的輸入表面,因為惡意建立的參數可能會嘗試覆寫查詢篩選條件、插入 Salesforce 物件查詢語言 (SOQL) 片段,或影響流程變數。在 MCP Server 或多面向化邊界驗證類型、格式和範圍。
• 對已註冊外部消費者執行定期存取審查。針對不再啟用或其存取範圍已變更的工作人員撤銷認證。停用的合作夥伴整合其靜態但有效的認證是不必要的固定風險。
• 透過將輸入 MCP 訊息限制為速率,防止違反平台限制。使用以 SLA 為基礎的層級原則,在載入時減少非重要工作人員的流量。

範例

由物流合作夥伴營運的採購工作人員必須先驗證供應商的契約和信用狀態,才能批准高價值的採購訂單:

1. 合作夥伴的工作人員會使用其已註冊的 OAuth 2.0 用戶端認證來驗證至該門戶,並接收範圍的存取權杖。
2. 工作人員查詢 Salesforce MCP Server 的工具目錄,並識別兩個相關工具:GetSupplierContractStatus 和 GetAccountCreditSummary。
3. 工作人員使用供應商的識別碼叫用 GetSupplierContractStatus。MCP Server 會將此項目翻譯為 Salesforce 記錄查詢、套用整合使用者的欄位級安全性,並傳回契約的目前狀態、到期日期,以及任何已標記合規性保留。
4. 工作人員會叫用 GetAccountCreditSummary,其會透過 MuleSoft MCP 多面向路由。面向會彙總來自兩個 Salesforce 物件的供應商未償還發票餘額和付款歷程記錄,並傳回單一的複合信用額度摘要。
5. 使用這兩個結果時,合作夥伴的工作人員會判定契約已啟用且信用狀況在可接受的限制內,並在自己的系統中批准採購訂單。
6. 系統會使用合作夥伴工作人員的身分、叫用的工具和結果,來記錄兩個工具叫用,並建立可稽核記錄,以瞭解授與的外部存取權以及傳回的資料。

內容

企業系統現在依賴協同合作的工作人員群組或網路,其中複雜的要求會分解並委派給跨不同網域或廠商平台的專門工作人員。這些工作人員,每個工作人員都有自己的角色、功能和工具,需要標準化、安全的通訊方法,以協調達成共用目標,而不需要在每個步驟上的人工介入。

問題

呼叫 AI 工作人員如何可以動態探索、安全地與其互動,並將複雜或網域特定的工作委派給遠端對等工作人員,這些工作人員可以建立在不同的架構上,或由不同的廠商操作,並接收結構化結果,以完成較大的企業工作流程?

力

套用此模式時,請回答下列問題:

• 使用各種架構開發或跨隔離式應用程式主控台作業的工作人員如何互通?
• 工作人員如何協同合作和委派工作,而無須公開其內部邏輯、記憶體或專屬工具?
• 工作人員如何支援複雜且長時間執行的工作,同時提供即時狀態更新、串流和推送通知?
• 工作人員如何針對跨工作人員通訊強制執行企業級安全性 (驗證、授權) 和原則符合度?
• 工作人員如何處理超出簡單 API 呼叫的結構化工作工作流程 (起始、進度、完成)?

Salesforce 模式應用程式

A2A 通訊協定是一種開放標準,可讓工作人員以對等的方式探索、委派給其他工作人員,並與其協同合作。其為工作人員提供通用語言,可在不同平台和廠商之間安全地交換資訊並協調動作。A2A 著重於點對點通訊,補充 MCP,其著重於將工作人員連線至工具和 API。

草稿

此結構涉及來電工作人員起始通訊,由工作人員目錄/註冊處協助探索:

跨工作人員委派的順序圖

對等工作人員使用其網域特定邏輯、記憶體和工具處理要求,然後將結構化結果傳回給呼叫工作人員。

結果

A2A 委派會將網域擁有權與工作流程協調分開。通話工作人員不需要知道對等工作人員的建立方式、其執行的平台或其在內部使用的工具;它會委派工作並接收結構化成品。此邊界表示專家工作人員 (背景驗證、財務風險評分、物流路由) 可獨立於叫用該工作流程的工作流程進行開發、部署和改善。

通訊協定的工作生命週期模型 (已提交、正在運作、已完成、失敗) 支援
原生長時間執行作業。通話工作人員可以註冊狀態更新,而不是
比起保留封鎖連線,這表示 A2A 工作會橫跨幾分鐘或數小時
無需要求協調工作人員在整個時間保持啟用。

設計考量事項

平台無效指引

• 在複雜的情況下,工作人員經紀人可以作為智慧路由服務或「智慧切換台」來協調跨專門工作人員的工作委派,並管理多步驟流程。
• 由於 A2A 支援長時間執行的工作,因此通訊必須以工作完成為導向,為工作物件定義生命週期,並提供即時狀態更新和通知。
• 通訊協定的設計目的為支援各種內容類型,包括文字、檔案、結構化資料、音訊和影片串流。
• 工作人員及其功能之間的關係和相依性會在組態檔案中以宣告的方式定義 (例如「agent-network.yaml」),並發佈至工作人員登錄。

Salesforce 實作注意事項

• 如需有效的 SOMA 協調流程,請將連線的子工作人員保持在 7 以下,以保留路由品質。
• 目前僅支援單一委派層 (superagent → subagent);較深層的鏈結會將延遲推送至「無法持續的率」。目前,子工作人員無法委派給其他已連線的子工作人員。
• 只有協調程式層級支援人工轉移;子工作人員無法升級。
• 在 SOMA 中,當以 LLM 為基礎的路由在決定性路由的不明確輸入上產生錯誤路由時,請使用「工作人員指令檔」。「工作人員指令檔」可啟用工作人員之間精密設計的共用內容。

錯誤處理與復原

A2A 通訊協定定義全方位錯誤代碼,以協助強大的除錯和錯誤管理。

• **復原邏輯:**工作人員應納入重試原則 (重試原則)、將錯誤切換邏輯納入其他有能力的工作人員,以及明確逾時。
• **工作狀態追蹤:**工作管理工作流程可確保工作人員能夠與工作的最新狀態保持同步,進而在發生中斷時協助復原。
• **觀察性:**記錄互動詳細資料 (例如延遲、成功率和錯誤頻率) 對於監視品質和疑難排解而言至關重要。

安全考量事項

• **企業級驗證:**A2A 的設計目的為符合企業級驗證和授權標準,例如 OAuth 2.0 和 JWT,通常由外部平台管理,例如 Okta。
• **保護 A2A 的入口網頁:**門戶 (例如 MuleSoft Omni Gateway) 對於對所有 A2A 通訊強制執行原則而言至關重要,同時作為入院與輸出門戶,可保護工作人員,並控制外部工作人員和服務的輸出流量。
• 保單強制執行:「工作人員卡片重寫」、「結構驗證」、「尖峰控制」、「PII 偵測器」和其他原則應套用至 A2A 伺服器和資料保護。

範例

候選來源工作流程

雇用經理會要求其中央協調員工作人員尋找符合工作清單與技能集的候選項目。

1. **探索:**協調程式工作人員查詢工作人員註冊表,並發現專門的招募工作人員和背景檢查工作人員 (兩者皆為對等工作人員)。
2. **委派 (A2A):**協調流程工作人員會將結構化工作要求 (A2A 訊息) 傳送給招募工作人員以取得候選項目。
3. **對等處理:**招募工作人員會執行自己的工作流程 (例如,透過 MCP 呼叫外部 LinkedIn 工具)。
4. **成品傳回 (A2A):**招募工作人員傳回建議候選項目 (成品) 清單。
5. **序列委派:**協調程式工作人員接著將另一個工作 (A2A) 委派給首要候選項目的背景檢查工作人員。此工作人員會執行檢查並傳回結果,完成整體工作。

內容

複雜的企業工作流程通常需要在外部平台或合作夥伴系統上主控的專業工作人員來起始工作、委派查詢,或將更新提供給內部工作人員 (例如 Salesforce 平台上的工作人員)。此模式會解決內部 Agentforce 工作人員如何安全且可靠地接收及處理遠端對等工作人員執行網域特定功能的要求。

問題

內部專業 AI 工作人員 (例如 Agentforce 上的背景檢查工作人員) 如何安全地向外部對等工作人員顯示其網域特定功能、處理傳入的結構化 A2A 要求,以及管理工作生命週期 (包括即時狀態更新),以將結構化成品傳回至遠端呼叫工作人員?

力

套用此模式時,請回答下列問題:

• 如何安全地將內部工作人員功能公開給外部工作人員,而不影響內部邏輯或工具?
• 您如何在處理要求前強制執行企業級安全性原則,以驗證來電工作人員的身分和委派的權限?
• 如何處理長時間執行的輸入工作,同時提供結構化非同步狀態更新?
• 您如何確保與以多元外部架構建立的工作人員順暢互動?

Salesforce 模式應用程式

A2A 通訊協定提供安全、點對點委派和協同合作的開放標準。內部工作人員會作為對等工作人員,透過「工作人員目錄/登錄」廣告其功能,並透過安全管道 (HTTPS/SSE) 使用 A2A 接收和回應結構化要求。

草稿

作為可呼叫服務之工作人員的順序圖

結果

此模式會將內部工作人員顯示為多工作人員網路內的專門服務。外部工作人員可以安全地將工作委派給內部功能,同時組織可維持控制、稽核性和保單強制執行。

設計考量事項

平台無效指引

• 若要在所有傳入的 A2A 要求上強制執行原則 (包括比率限制、驗證和裝載驗證),必須將門戶 (例如 MuleSoft Omni Gateway) 放置為進入點。
• 內部工作人員必須從外部起始到完成管理工作物件的狀態,以確保遠端通話工作人員收到一致且可驗證的狀態更新。
• 確定工作人員卡片中工作人員已發佈的功能清楚、以意圖為基礎,並包含委派的必要安全性範圍。

錯誤處理與復原

• **結構化錯誤代碼:**失敗時,內部工作人員必須將符合 A2A 的結構化錯誤訊息傳回給呼叫工作人員,才能啟用遠端重試邏輯或替代故障轉換機制。
• **Idempotency:**工作人員必須確認由外部工作人員的重新嘗試 A2A 要求觸發的任何副作用 (由於網路中斷或復原) 均為無效。

安全考量事項

• 強制執行輸入原則:通道必須強制執行允許清單/封鎖外部工作人員的原則,並驗證 JWT/OAuth 2.0 權杖,以驗證 _呼叫工作人員_的身分和委派授權。
• **輸入消毒:**驗證並消毒所有傳入要求裝載,以緩解潛在提示插入或惡意資料攻擊。
• **身分傳播:**在對內部系統執行動作之前,安全地將外部工作人員的身分及其委派的授權機構對應至內部安全性內容 (例如 Salesforce 使用者設定檔)。

範例

外部系統查詢

1. **要求:**合作夥伴系統上的「招募工作人員」會將 A2A 工作要求傳送至 Agentforce 上的內部「員工驗證工作人員」(對等工作人員),以確認新候選項目的就業狀態。
2. 處理:「員工驗證工作人員」會接收要求,並且透過管道驗證合作夥伴工作人員的認證、執行其內部工作流程 (例如呼叫內部 HR 系統),並設定回應的格式。
3. 回應:「對等工作人員」會將結構化 A2A 成品 (例如就業開始日期和職稱) 傳回給遠端「招募工作人員」,然後將繼續其外部工作流程。

1. 保護 MCP、A2As 和 API 的門戶

   所有工作人員對系統和系統對工作人員流程的單一強制執行點都需要門戶。

• 安全連線:管道可確保只有已驗證且已授權的工作人員能夠透過限制存取權,與 MCP、A2A 和 API 端點互動。

• **強制執行的 SLA:**管道可以強制執行比率限制,協助組織符合效能需求,並防止 MCP 和 A2A 伺服器過載。

• **簡化管理:**門戶提供所有伺服器互動的集中可視性和控制,簡化工作人員活動管理與監視。

• **資料一致性與保護:**如結構描述驗證、強制執行資料一致性和 PII 偵測等原則可以保護敏感資訊。

MueleSoft Omni Gateway

2. 身分傳播鏈

隨著企業採用工作人員範例,隨即出現新的安全性挑戰:一般使用者身分如何在自主 AI 工作人員的網路中流動?在傳統 API 結構中,使用者驗證一次,且應用程式代表使用者呼叫後端服務。身分鏈簡短、瞭解良好,通常是在單一 Trust 網域內管理。

然而,工作人員結構具有較長的鏈結,其中單一要求會在各種工作人員、服務和 MCP 伺服器之間出現,每個都可能會跨越服務邊界、 Trust 網域甚至是組織邊界。若未針對身分傳播進行刻意的策略,企業將在安全性與功能之間面臨選擇,這是一個無法由結構設計師解決的困境。

MuleSoft 透過其 信任的工作人員身分功能來解決身分傳播的複雜性。此解決方案使用以原則為基礎且由通道管理的策略,以確保在各種互動類型中維護一般使用者身分,包括 A2A 通訊協定、MCP 工具呼叫和 REST API 要求。透過透過 輸出驗證原則在 Omni Gateway 圖層集中身分管理,企業可以保護其整個工作人員網路,而無須修改後端服務或工作人員。如需詳細資料,請參閱代理企業的 信任工作人員身分。

3. Data 360 中的 RAG 安全性

Data 360 透過「資料管理原則」設定,在物件、欄位和列層級支援以屬性為基礎的存取控制 (ABAC)。這是控制誰可以看見哪些資料的主要方法,包括在 RAG 搜尋索引中。針對結構化資料,使用者存取條件會使用使用者屬性和權限集來實作。針對非結構化資料,中繼資料篩選 (搜尋索引的預先篩選) 可能會限制所取用的項目。

LLM 的通訊會透過 Einstein Trust 圖層進行,此圖層會先遮蔽機密/PII 資訊,再到達保護資料隱私權的模型,不僅在搜尋期間,還在產生之前。

若要避免 RAG 毒害,請確保在資料可供向量搜尋使用之前套用嚴格的資料管理和驗證規則。Einstein Trust 圖層也可以強制執行提示遮蔽/毒性檢查。您可以在「工作人員使用者」設定檔上套用嚴格的「權限集」。

4. 新增已命名認證模型 Salesforce 透過導入雙層「已命名認證」模型,以清晰區分連線與身分之間的疑慮,來重新整理其驗證結構。只要透過 Apex 進行呼叫,請使用此功能,避免建立您自己的驗證通訊協定。此模型也提供擴充性和增強型安全性。 外部認證是此模型的基礎。它們儲存實際驗證詳細資料,並支援一組豐富的通訊協定,包括 OAuth 2.0 用戶端認證、JWT Bearer 和 AWS Signature V4,同時定義主體的對應方式:作為單一「已命名主體」(在所有使用者之間共用) 或作為「每位使用者主體」(每位使用者在其中使用自己的身分進行驗證)。 「已命名認證」接著會作為端點層。它們會定義呼叫 URL 並參照「外部認證」以處理驗證動作,讓端點組態與認證管理完全分離。 若要啟用每位使用者驗證流程,管理員會將「權限集」對應至適當的「外部認證」主體,如此一來,只有具有正確「權限集」指派的使用者才能以自己的身分叫用呼叫。此雙層式設計不僅可簡化安全呼叫組態,還可讓結構設計師更有彈性地控制整合如何在 Salesforce 連線的系統之間進行驗證。如需詳細資料,請參閱「已命名認證」文件。

本節將結構的資料處理模式對應至在受監管企業部署中最常見的合規義務。

**存取控制:**整合模式中所描述的最低權限整合使用者模型 (已定義範圍的已命名認證、每個工作人員的 OAuth 2.0 範圍,以及通道允許清單) 會直接對應至邏輯存取控制。維護每個工作人員認證範圍已檢閱和批准的證據。

**稽核記錄:**各模式稽核記錄需求 (工作階段識別碼、工具叫用、敏感值的輸入參數,以及成果) 可滿足監視與記錄控制項。請確保記錄可被篡改、保留所需期間,且安全性小組可以存取,而不需要存取生產系統。

**變更管理:**影響消費者的 MCP 工具結構描述變更和 A2A 工作人員卡片更新會構成介面變更,且應受限於變更管理控制。明確版本工具 (在 MCP 輸入模式中提及),並將斷轉變更視為需要批准的組態事件。

**可用性:**工作人員同時限制、事件觸發模式的重試上限,以及失敗事件的無效字母路由,都構成可用性控制。作為可用性證據封裝的一部分,記錄每個部署模式的預期輸送量信封和失敗行為。

備註:此清單並非確保工作人員解決方案合規性的完整指南。必須符合所有適用的法規需求。

• 開始使用工作人員 API
• 使用 Data 360 啟用信任的工作人員
• MuleSoft Omni Gateway 概觀
• OAuth 2.0 代表認證插入原則
• 代理企業的信任工作人員身分

Gulal Kumar 是 Salesforce 的軟體工程結構設計師,擁有超過 20 年的經驗。他的專業知識涵蓋了 AI、整合、API 和企業結構,專注於透過安全、彈性的創新 AI 解決方案推動業務轉型。在 LinkedIn 上與他聯繫。