軟體的模式正在從直接操作轉為目標導向的委派。此轉換的最前沿是 AI 工作人員—能夠瞭解、推理及代表使用者採取動作的自主智慧實體。此白皮書提供 AI 工作人員主要類型的技術探索:對話、主動、環境、自發和協同合作。它定義每個類型、呈現特定的「客戶關係管理」(CRM) 使用個案,並提供在 Salesforce Agentforce Platform 上建立這些工作人員的結構藍圖,以及利用 Flow、Apex、Data 360、Agent2Agent (A2A) 通訊和模型內容通訊協定 (MCP) 互通性的技術範例。

AI 工作人員是一種系統,可認知其環境並採取行動以達成特定目標。雖然此概念並非新概念,但功能強大的大型語言模型 (LLM) 已強化其功能。我們可以根據工作人員的主要作業模式和互動來分類工作人員。

**定義:**對話工作人員是最常見的工作人員類型。它們以反應性的要求回應方式運作,主要透過自然語言介面 (文字或語音)。其核心功能是瞭解使用者的意圖並提供相關回應,無論是回答問題、提取資訊或執行簡單指令。

**重要性:**對話工作人員是組織的數位前門。他們在處理精確定義且重複性的工作方面表現出色,從而釋放人力資源。其成效的測量方式是能夠快速且準確地解決使用者意圖,並代表使用者採取行動。

**定義:**不同於等待提示的對話工作人員,主動工作人員會作為警覺的觀察者。它們是由系統內的特定事件、資料變更或預先定義的條件所觸發。觸發時,他們會執行工作或起始工作流程,而不需要直接使用者互動。

**重要性:**主動工作人員會將系統從被動式資料存放庫轉換為業務流程的主動參與者。它們會在機會和風險出現時識別,讓企業能夠即時對重要訊號採取行動。

**定義:**環境工作人員是主動工作人員的特定類型,會在使用者工作流程的背景中持續作業,而不需要明確指令。使用者通常會從其動作中獲益,而不會意識到其作業,因為其設計目的在於增強人力功能,同時維持較低的設定檔。

**重要性:**環境工作人員的目標是透過自動化日常的「工作相關工作」,來降低使用者的認知負擔。透過流暢整合至員工每日使用的工具,以自動收集和建構資訊,進而提升流程效率。

**定義:**獨立工作人員代表複雜性大幅上升。系統會為他們提供高階目標,並能夠獨立規劃並執行一系列步驟以達成該目標。他們可以思考、做出決策,甚至從動作中學習,以隨著時間改善績效。

**重要性:**這是與真正的數位員工最接近的地方。您可以將複雜的多步驟目標 (例如「本季在製造行業中產生 50 個新的合格商機」) 委派給自發工作人員,並信任其制定並執行計畫以達成目標。

**定義:**協同合作工作人員通常稱為「工作人員群集」,是專門工作人員的集合,這些工作人員共同解決的問題過於複雜,無法讓任何單一工作人員處理。「協調器」或「主要」工作人員通常會拆分大型工作、將子工作委派給適當的專門工作人員,然後將其輸出同步化。強大的 Agent2Agent (A2A) 通訊協定可達成此目標。

**重要性:**此方法反映人類的小組。透過細分複雜的問題,每個專門工作人員都可以運用其獨特的技能:一個專注於資料分析、另一個專注於客戶通訊,第三個專注於系統整合,進而提供更強大且全方位的解決方案。

探索 AI 工作人員的分類後,仍有一個關鍵問題:我們如何結合這些元素,以有效且可靠地解決實際的業務問題?本章透過提供常見工作人員設計模式的儲存庫來回答該問題。每個模式都是對循環挑戰的已驗證解決方案,針對從簡單、單一用途的工作人員到複雜、協同合作的工作人員群組提供的一切藍圖。

對話工作人員通常是組織 AI 功能的前門。其定義的能力是參與狀態豐富、多輪對話的能力,作為使用者執行工作及使用自然語言提取資訊的主要介面。此區段提供兩個建立對話工作人員的必要配方,每個配方都專為特定管道量身打造:一個用於傳訊用戶端的快速互動交換,另一個用於電子郵件的結構化非同步性質。

對話工作人員的智慧衍生自對話工作人員在正確時間存取正確資料並考量正確資料的能力。此模式依賴複雜的資料基礎,連線至客戶記錄、Knowledge 文章和業務分析。第 4 章提供這些整合的完整可重複使用配方:整合模式。

問題

客戶可跨許多數位管道參與**,並期望立即、內容相關且智慧回應。傳統聊天機器人是以指令檔或為資料盲目,**這會導致個人化不佳、早期升級至人類,以及高服務成本。

內容

• 您的組織具有多管道數位參與 (WhatsApp、SMS、Slack 和 Salesforce Experience Cloud)。
• 您組織的客戶會以多國語言與您的組織互動。
• 您的組織需要使用下列工作人員來擴大服務和銷售工作流程:
  • 從即時信任的客戶資料提取
  • 遵循護欄與規範要求
  • 僅在必要時升級至人力工作人員

關鍵元件

• **管道抽象:**Service Cloud 增強型聊天 (先前稱為「應用程式內和 Web 傳訊」) 可讓工作人員透過單一體驗跨多個管道通訊。
• **Agentforce 服務代理:**工作人員的行為與目標由下列元件定義。
  • **主題與指示:**定義直接使用者互動的工作人員角色和對話用途。這包括其核心任務 (例如「您是解決客戶支援問題的專家」)、維持同情和專業語氣的指示,以及有關授權處理的查詢範圍的清晰護欄。
  • **動作:**服務導向動作是工作人員用來即時診斷和解決客戶問題的工具。這些工具的設計目的為執行如檢查訂單狀態、搜尋 Knowledge 庫中的解決方案,或直接從對話介面建立新的支援個案等工作。
  • **護欄:**護欄會作為一組可設定的規則和執行階段檢查,以限制工作人員的行為。作為安全層,可攔截提示、驗證工作人員建議的動作,並篩選其最終回應,以防止有害內容、強制執行業務規則,並確保工作人員在其指定的範圍內作業。
  • **提示範本:**透過 Data 360 RAG Retrievers 的合併欄位或語意資料,動態填入即時 CRM 資料的可重複使用範本。這些範本可讓工作人員產生相關聯的品牌內容,而 Einstein Trust 層會在將指示傳送至 LLM 之前安全地遮蔽敏感資訊。
• Data 360
  • Data 360 元件 (包括 DLO、DMO、向量存放區和 RAG 提取器) 為工作人員提供所有相關企業資料的統一檢視,從結構化客戶記錄到非結構化 Knowledge 文章,以確保回應準確且以內容為基礎。
• Service Cloud
  • **CRM 資料:**將工作人員連線至完整的個案歷程記錄,提供帳戶詳細資料、連絡人記錄和權益的關鍵內容
  • **「Live Agent」(即時工作人員):**支援升級並路由至已插入完整對話內容的人工服務代表

互動

1. 您組織的客戶透過管道開始交談。
2. 訊息會路由至 **Agentforce,**這會決定範圍 (主題) 並套用護欄。
3. AI 會使用 提示範本撰寫回應,而流程或 Apex 可能會觸發後端邏輯。
4. 系統會透過 RAG retriever 從 Data 360 物件、向量存放區和 CRM 提取內容。
5. AI 會傳回內容相關回答。
6. 如果 AI 無法解決,則對話會升級至 Service Cloud 即時工作人員。

貿易

相關模式

Greeter 模式:簡易實作的模式,使用自然語言來瞭解使用者的意圖,然後將使用者路由至適當的服務代表

運算子模式:建立在「接待員」上,將要求路由至適當的專家 AI 工作人員或人力服務代表,視需要協商意圖

協調流程模式:管理 AI 工作人員群集。它會接收使用者要求、決定意圖、建立計畫、將必要資料傳遞給一或多個專家工作人員,然後彙總使用者的回應。不同於「運算子」,其仍是第一個連絡點。

問題

您的客戶大多使用電子郵件型非同步對話,這仍是拓展的最佳方法。您的組織需要透過電子郵件連絡這些客戶,但您的銷售開發代表無法在 SLA 內回覆輸入電子郵件,進而導致商機遺失。此外,您的人力會花時間處理不合格的商機。

內容

• 您的組織擁有電子郵件作為主要商機參與管道。
• 您的 SDR 容量有限,可讓大規模商機符合資格。
• 您的銷售流程在與 SDR 或業務開發代表 (BDR) 會面之前,先擁有多重接觸商機培養。
• 您的組織需要使用下列工作人員來提升服務和銷售量:
  • 從即時銷售啟用及銷售產品和行銷資料提取
  • 遵循護欄與規範
  • 根據商機資格條件排程會議

關鍵元件

• **電子郵件管道:**處理收集輸入訊息、剖析其內容和附件,以及維護討論串連性以啟用非同步對話。
• **Agentforce SDR 工作人員:**工作人員的行為與目標由下列元件定義。
  • **主題與指示:**定義工作人員透過交談來參與並使輸入商機合格的任務。這包括瞭解潛在客戶需求、收集關鍵資格資料 (例如預算、授權和時間表) 的指示,以及引導對話進行明確的後續步驟,例如排程與帳戶主管的會議。
  • **動作:**可讓工作人員管理商機生命週期的專用銷售動作。這些工具的設計目的為執行核心 SDR 工作,例如增強商機資料、傳送範本後續追蹤電子郵件,或與行事曆系統整合以預訂探索通話。
  • **護欄:**護欄會作為一組可設定的規則和執行階段檢查,以限制工作人員的行為。作為安全層,可攔截提示、驗證工作人員建議的動作,並篩選其最終回應,以防止有害內容、強制執行業務規則,並確保工作人員在其指定的範圍內作業。
  • **提示範本:**透過 Data 360 RAG Retrievers 的合併欄位或語意資料,動態填入即時 CRM 資料的可重複使用範本。這些範本可讓工作人員產生相關聯的品牌內容,而 Einstein Trust 層會在將指示傳送至 LLM 之前安全地遮蔽敏感資訊。
• Data 360
  • Data 360 元件 (包括 DLO、DMO、向量存放區和 RAG 提取器) 為工作人員提供所有相關企業資料的統一檢視,從結構化客戶記錄到非結構化 Knowledge 文章,以確保回應準確且以內容為基礎。
• Sales Cloud
  • **CRM 資料:**將工作人員連線至完整的個案歷程記錄,提供帳戶詳細資料、連絡人記錄和權益的關鍵內容
  • **排程客戶和 SDR 之間的會議:**SDR Live Agent 轉移可設定為使用「工作」和「會議排程」(後續動作) 設定即時會議。
  • **活動記錄:**由於 SDR 工作人員的互動,便可捕捉事件、工作和電子郵件活動,並將其與商機、帳戶和機會相關聯。

互動

1. 客戶透過管道傳送及接收電子郵件,該管道會路由至 Agentforce。
2. Agentforce 會套用主題、動作和護欄來剖析意圖。
3. Agentforce 使用增強 CRM 和 Data 360 內容的提示範本來撰寫內容回應草稿。
4. 多輪電子郵件對話會持續直到解決方案或原則指導方針為止。
5. 針對合格的商機,Agentforce 會排程會議並更新 CRM。
6. 如果意圖超過 AI 範圍,則 Agentforce 會針對人力服務代表回應升級至 Sales Cloud SDR。

貿易

相關模式

回答機器人模式:自助式服務的有效模式,使用生成式 AI 來瞭解自然語言以供 Knowledge 提取,而不只是關鍵字

雖然先前區段中的對話工作人員在回應使用者指令方面極為優秀,但主動工作人員代表一個範例排班:他們在未被要求的情況下採取動作。此區段提供建構工作人員的結構模式,這些工作人員可自行監視來自 Salesforce 外部和內部的資料和事件。

問題

您的組織會在 Salesforce 內部與外部產生重要業務事件。無法將其翻譯成及時的內容動作,因為其散佈在應用程式與部門之間。

內容

• 您的業務流程涵蓋數個 CRM、付款處理、寄送、行銷自動化、遠端測量和 CDP 的系統。
• 您的組織事件會在 24/7 進行,但您的人力可用性在營業時間之外受到限制。系統一律開啟,但人類則不會。
• 事件缺乏內容認知,因為它們缺少 Salesforce 中可用的客戶內容,強制執行資訊的多步驟整合。今天,實作會以離散式複雜自動化形式存在,或手動執行。
• 人類會作為編譯器來收集資料 (不同格式),並以智慧的方式回應中斷的事件。
• 您的目標動作會套用至多個系統。

關鍵元件

• 事件來源
  • 「資料動作」會在將外部資料提取至 Data 360 後觸發事件
  • 可透過 Salesforce Pub/Sub API 將事件傳送至 Salesforce 的第三方或 Salesforce Heroku MCP 伺服器
  • 可透過 Salesforce Pub/Sub API 傳送事件通知的外部應用程式
• **選擇性中介:**轉換的 MuleSoft 或 Data 360
• **Agentforce 工作人員:**工作人員的行為與目標由下列元件定義。
  • **主題與指示:**指定工作人員的核心任務及其觸發,包括定義其主要目標 (例如「監視所有高優先順序個案並防止 SLA 缺口」)。包含工作人員應傾聽以起始工作的特定事件或資料條件
  • **動作:**為回應外部事件而設計的事件觸發和排程動作。雖然這些動作會針對例行工作自主執行,但通常會包含協調涉及人類介入的工作流程的功能,並將其升級至使用者以供檢閱、批准或處理需要人類判斷的情境。
  • **護欄:**護欄會作為一組可設定的規則和執行階段檢查,以限制工作人員的行為。作為安全層,可攔截提示、驗證工作人員建議的動作,並篩選其最終回應,以防止有害內容、強制執行業務規則,並確保工作人員在其指定的範圍內作業。
  • **提示範本:**透過 Data 360 RAG Retrievers 的合併欄位或語意資料,動態填入即時 CRM 資料的可重複使用範本。這些範本可讓工作人員產生相關聯的品牌內容,而 Einstein Trust 層會在將指示傳送至 LLM 之前安全地遮蔽敏感資訊。
• Data 360
  • Data 360 元件 (包括 **DLO 和 DMO),**可儲存事件資料,由外部系統產生並傳送至 salesforce,以轉換和建立串流或即時洞察
  • 已計算、串流和即時洞察可提供工作人員與客戶相關的立即資料。這可啟用預防性問題解決方案,緩解升級。資料圖主動呈現來自不同資料來源的關係和洞察,以便及早偵測與客戶參與、活動和設定檔相關的模式或異常。
  • Data 360 向量存放區和 RAG 提取器為工作人員提供所有相關企業資料和非結構化 Knowledge 文章的統一檢視,確保回應準確且以內容為基礎。
• 事件目標
  • 主動通知員工或連絡客戶
  • 可延伸至工作人員 (請參閱 環境工作人員和自動工作人員模式)

互動

1. 外部系統發生明顯的變更。
2. 外部系統會透過 API (建立平台事件) 或 Pub/Sub API 來發送事件並將其發佈至 Salesforce Event Bus,或將事件資料串流至 Data 360。
3. 觸發事件的訂閱者。觸發流程。
4. 流程會呼叫具有事件資料的「工作人員動作」。工作人員決定正確的動作方式並執行。
5. 結果是觸發的通知或工作流程。通知會在協同合作工具 (例如 Slack) 中傳送給使用者。也會產生工作或事件。此外,動作會呼叫外部系統。因此,事件不會遺失,但會主動執行、訊號和動作,從而移除人類的負擔或複雜的自動化來探索。

貿易

相關模式

評審和評審模式:可與此模式搭配使用,藉由利用多個「陪審員」工作人員和「陪審員」工作人員來評估一致性,以確保 AI 技術提供的決策準確性和可靠性

模型模式模式:此模式會採用來自多個專家工作人員的各種觀點,以產生更豐富的洞察,以補充主動式 AI 的智慧回應。

問題

您組織的 Salesforce 生態系統會產生持續的訊號串流,但無法將其轉換為及時的內容動作,因為它們需要業務邏輯、管治和人類來分級並採取行動。許多情況下,訊號會遺失,沒有任何導致機會遺失的動作。

內容

• 您的組織使用一或多個 Salesforce Cloud:銷售、服務、行銷、商務、健康、製造等。
• 除了簡單路由或以規則為基礎的分級以外,您還需要智慧型分級。您的組織維護數百個複雜的業務規則。
• 您需要事件的即時或近乎即時回應。
• 有時,您最有權限的管理員會因為看不到訊號而成為鏈結中的最弱連結。

關鍵元件

• 事件來源層
  • 來自低層級平台活動的 CRM 資料、平台事件、變更 資料擷取 (CDC) 資料和即時事件監視 (RTEM) 資料
• Data 360
  • Data 360 元件 (包括 **DLO 和 DMO),**可儲存事件資料,由 CRM 或平台事件產生、轉換和建立串流或即時洞察
  • 已計算、串流和即時洞察可提供工作人員與系統中客戶、員工活動或中繼資料變更相關的立即相關資料。這可啟用預防性問題解決方案,緩解升級。此即時情況感知可讓工作人員針對管治與合規性作業輸出提供及時介入。
  • 資料圖會主動呈現來自不同資料來源的關係和洞察,以便及早偵測與客戶參與、活動和設定檔相關的模式或異常。
  • Data 360 向量存放區和 RAG 提取器為工作人員提供所有相關企業資料和非結構化 Knowledge 文章的統一檢視,確保回應準確且以內容為基礎。
• **Agentforce 工作人員:**工作人員的行為與目標由下列元件定義。
  • **主題與指示:**指定工作人員根據 Salesforce 內的資料變更,強制執行業務規則和自動化流程的任務。它會定義工作人員的目標 (例如「在到達協商階段之前,請確保所有機會都透過主要連絡人更新」),以及該工作人員觸發的特定記錄建立、欄位更新等等。
  • **動作:**為回應內部 Salesforce 事件而設計的事件觸發和排程動作。雖然這些動作會針對例行工作自主執行,但通常會包含協調涉及人類介入的工作流程的功能,並將其升級至使用者以供檢閱、批准或處理需要人類判斷的情境。
  • **護欄:**護欄會作為一組可設定的規則和執行階段檢查,以限制工作人員的行為。作為安全層,可攔截提示、驗證工作人員建議的動作,並篩選其最終回應,以防止有害內容、強制執行業務規則,並確保工作人員在其指定的範圍內作業。
  • **提示範本:**透過 Data 360 RAG Retrievers 的合併欄位或語意資料,動態填入即時 CRM 資料的可重複使用範本。這些範本可讓工作人員產生相關聯的品牌內容,而 Einstein Trust 層會在將指示傳送至 LLM 之前安全地遮蔽敏感資訊。
• 事件目標
  • 主動通知員工或連絡客戶。
  • 可擴充以呼叫其他工作人員 (請參閱 環境 AI 和 自動 AI 模式)

互動

1. 在內部系統內發生明顯變更,例如 CRM 記錄更新、中繼資料修改,或從 Data 360 觸發的資料動作。
2. 內部系統會透過 API (建立平台事件) 或 Pub/Sub API 來發送事件並將其發佈至 Salesforce Event Bus,或將事件資料串流至 Data 360。
3. 事件的訂閱者會觸發並啟用流程或 Apex。
4. 已啟用的流程或 Apex 會呼叫「工作人員動作」。
5. 結果是觸發的通知或工作流程。通知會在協同合作工具 (例如 Slack) 中傳送給使用者。也會產生工作或事件。此外,動作會呼叫外部系統。
6. 因此,事件不會遺失,但會主動執行、訊號和動作,從而移除人類的負擔或複雜的自動化來探索。

貿易

相關模式

接聽者/摘要模式:可與「聆聽者」模式結合,以根據內部 Salesforce 事件觸發主動動作

資料主管模式:主動式 AI 可以利用資料管理員在回應內部事件時確保資料品質與一致性

Zen Data Gardener 模式:適用於由內部事件或定期觸發的已排程、主動資料精簡和標準化

我們從在對話管道中以互動方式回應的工作人員開始,然後轉為回應特定事件的工作人員。超出主動工作人員的事件驅動模型,環境工作人員代表從直接互動到主動背景協助的範例轉換。這些是觀察背景中數位環境的無周邊工作人員。他們會作為系統的「眼睛和耳朵」,從使用者活動或資料串流中感知內容,然後與其他工作人員或人類協調完成工作、呈現洞察或提供指引。

問題

您組織的業務活動會產生持續的寶貴資訊串流 (通話、會議、聊天、感應器資料等),但此資料會即時消失,而無須進行捕捉或分析。當人類手動記錄這些互動時,重要洞察會遺失,且及時介入的時機已經過。組織缺少大多數即時需要的可運作情報,並埋藏在短暫的串流中,進而造成間隙、遺失訓練機會,以及在沒有完整內容的情況下做出決策。

內容

• 您的業務活動會從各種來源產生連續串流,包括語音和視訊會議、即時聊天、感應器距離測量、畫面活動和交易資料。
• 您需要即時或近乎即時洞察 (在秒或分鐘內,而非小時或天內),才能有效回應這些串流並採取行動。
• 手動文件流程失敗,其特徵為合規性與重新整理率低、員工的認知負擔高,以及對重要資訊的未完美捕捉。
• 您需要多重模式的瞭解,結合音訊、視訊、螢幕共用、聊天和其他中繼資料的資料,以建立完整且準確的互動與事件內容。
• 您需要立即分析進行即時訓練和警示,以及歷程記錄分析以進行互動後摘要和長期趨勢識別。
• 時間內容 (事件記憶) 對於您的分析而言至關重要,包括瞭解資料串流中各種時間範圍的順序、時間、轉換和模式。

關鍵元件

• 串流來源
  • 聲音與影片:視訊會議工具 (例如 Slack Huddle、Zoom、Google Meet 和 Microsoft Teams) 和電話系統
  • 協同合作工具、Teams 及其他
• 串流捕捉連接器
  • 本地 SDK:廠商提供的 SDK,其可協助從支援即時串流區段或文字稿的文字記錄或訊息中取得訊息
• (選擇性) 串流處理層
  • 針對音訊串流,如果文字記錄無法即時使用,則為將音訊翻譯為文字的「語音轉文字」功能。您也可以使用受管理的提供者,例如 Amazon Transcribe。
  • 針對其他資料串流,可選擇性使用串流處理引擎,例如 Data 360 或 Apache Flink
• Data 360
  • Data 360 元件 (包括 DLO 和 DMO), 可儲存事件資料、轉換和建立 串流或即時洞察
  • 已計算、串流和即時洞察可提供工作人員與客戶、其活動和重要洞察的立即相關資料。這可啟用預防性問題解決方案,緩解升級。此即時情況感知可讓工作人員提供員工及時介入和個人化支援,進而最佳化客戶滿意度和營運輸出。
  • Data 360 元件 (包括儲存客戶資料、轉換和建立即時洞察的 DLO 和 DMO)
  • Data 360 向量存放區和 RAG 提取器為工作人員提供所有相關企業資料和非結構化 Knowledge 文章的統一檢視,確保回應準確且以內容為基礎。
• **Agentforce 工作人員。**此模式著重於觀察連續資料串流的環境工作人員,例如即時通話文字記錄或影片摘要。它會作為即時接聽者,依情況解譯非結構化資料。例如,聆聽即時通話的工作人員可能會叫用 Data Discovery 工作人員,以根據交談中共用的新內容來增強商機的記錄。以下是此類無周邊工作人員的範例:
  • **回饋意見工作人員。**工作人員的行為與目標由下列元件定義。
    • **主題與指示:**定義工作人員的主要任務,以分析對話串流,並解壓縮結構化回饋意見和效能度量。這包括監視客戶情感的指示、識別關鍵產品或競爭者的提及,以及評估人力工作人員是否遵循公司最佳作法或銷售手冊。
    • **動作:**將非結構化對話資料轉換為可運作業務情報的動作。這些動作可讓工作人員建立「回饋意見摘要」記錄、記錄產品功能要求、將有負面情感的通話標記為經理審查,以及更新顯示面板,以根據主要度量追蹤工作人員的整體績效。
    • **護欄:**護欄會作為一組可設定的規則和執行階段檢查,以限制工作人員的行為。作為安全層,可攔截提示、驗證工作人員建議的動作,並篩選其最終回應,以防止有害內容、強制執行業務規則,並確保工作人員在其指定的範圍內作業。
    • **提示範本:**結構化、範本化 LLM 指示,可接收輸入並提供 LLM 產生的輸出
• 環境目標
  • 在工作人員與使用者所在的表面上通知使用者,例如在視訊通話或桌面應用程式中

互動

1. 啟用串流時 (例如當使用者加入視訊通話時),工作人員會將自己附加為觀察者。
2. 工作人員會開始接收串流資料、逐步偵測意圖、做出決策和呼叫動作。
3. 工作人員會根據意圖進行內容處理,並取用其他資料 (結構化或非結構化)。
4. 工作人員在沒有使用者提示的情況下提供即時即時回應:其可偵測銷售通話中的反對,並提供處理反對的重要資訊。
5. 工作人員可以編譯合併摘要和動作,並與其他工作人員和使用者共用。

貿易

相關模式

接聽者/摘要模式:可與「接聽者」模式結合,以處理對話與使用者互動資料的即時串流,並呈現相關內容與洞察

查詢模式:可以與此模式一起使用,從串流內的多個來源組合內容,並回答問題

問題

您的員工每天會透過電子郵件、行事曆、通話和應用程式執行數百個關鍵業務活動,但在手動記錄這些活動之前,組織系統仍無法看見這些活動,這很少發生。此活動失明表示 CRM 資料不完整、AI 模型缺少智慧建議所需的訊號,且經理沒有客戶參與的即時可視性。手動活動記錄會建立生產力稅額,但仍會遺漏大部分的實際工作。

內容

如同串流觀察者,此為資料和內容觀察者,可提供可採取動作的工作,或代表使用者執行動作。

關鍵元件

• 資料層
  • CRM 資料:在 CRM 中提供給工作人員內容的客戶資料 (例如,當使用者位於「機會」頁面上時,工作人員可以從 CRM 提取機會和相關聯帳戶的相關資訊)。
  • Data 360 元件 (包括 DLO 和 DMO) 可儲存從不同來源採取的相關客戶資料
  • 已計算、串流和即時洞察可提供工作人員與客戶、其活動和重要洞察的立即相關資料。這可啟用預防性問題解決方案,緩解升級。
  • Data 360 向量存放區和 RAG 提取器為工作人員提供所有相關企業資料和非結構化 Knowledge 的統一檢視。
• **Agentforce 工作人員:**此模式著重於監視使用者直接在 UI 內動作的環境工作人員。它會作為即時助理,瞭解使用者工作流程的內容以提供指引。例如,工作人員可以監視服務代表填寫個案記錄,並主動呈現相關的 Knowledge 文章。以下是此類無周邊工作人員的範例:
  • **回饋意見工作人員。**工作人員的行為與目標由下列元件定義。
    • **主題與指示:**定義工作人員的任務,以監視使用者在 UI 中的動作,並提供內容相關的協助。這包括其目標 (例如「引導服務代表完成個案解決流程」),以及其應關注的特定 UI 事件或資料輸入模式,以主動提供協助。
    • **動作:**使用 Apex 或流程建立的動作,可直接在使用者的工作流程中呈現相關資訊和 Next Best Action。這些動作可讓工作人員提取並顯示相關 Knowledge 文章、在程序中建議有效的後續步驟,或標記可能違反業務規則的資料輸入欄位,這一切都是對使用者即時活動的回應。
    • **護欄:**護欄會作為一組可設定的規則和執行階段檢查,以限制工作人員的行為。作為安全層,可攔截提示、驗證工作人員建議的動作,並篩選其最終回應,以防止有害內容、強制執行業務規則,並確保工作人員在其指定的範圍內作業。
    • **提示範本:**透過 Data 360 RAG Retrievers 的合併欄位或語意資料,動態填入即時 CRM 資料的可重複使用範本。這些範本可讓工作人員產生相關聯的品牌內容,而 Einstein Trust 層會在將指示傳送至 LLM 之前安全地遮蔽敏感資訊。
• 環境目標
  • 在工作人員與使用者的位置 (例如網頁或管理頁面) 上通知使用者

互動

1. 當使用者造訪頁面或應用程式時,工作人員會將自己附加為觀察者。
2. 工作人員會開始檢查資料與動作、逐步偵測意圖、做出決策和呼叫動作。
3. 工作人員會根據意圖進行內容處理,並取用其他資料 (結構化或非結構化)。
4. 工作人員會在沒有使用者提示的情況下提供即時即時回應,並可建議 Next Best 動作或代表使用者提出執行這些動作的提議。
5. 工作人員可以與其他工作人員和使用者順暢共用此頁面。

貿易

相關模式

接聽者/摘要模式:可與「聆聽者」模式結合,以根據觀察的活動觸發主動動動作

資料主管模式:活動攔截 AI 可利用資料管理員在記錄已攔截活動時確保資料品質與一致性。

發電機模式:可用於根據攔截的活動自動產生活動摘要或追蹤工作

本節詳細說明協同合作工作人員的模式,其中一或多個工作人員會與人類使用者協同合作以達成共用目標。這些配方著重於建立流暢的合作關係:工作人員處理複雜的資料收集和工作執行,同時讓人類掌握決策、批准和策略指引。

在此模型中,工作人員會處理工作流程的可自動化部分。流程會變成動態回饋意見迴圈。

• 人類可能會透過「對話工作人員」起始工作,這會觸發主動工作人員以管理後端步驟。
• 同時,環境工作人員可能會觀察其動作,以提供即時指引。

此流程會建立人力與數位人工的流暢合併。此模式顯示 Agentforce 如何協助多位工作人員的人工系統處理單獨無法管理的複雜工作。

問題

您的業務流程需要來自不同組織 (內部與外部) 的員工進行協同合作,每個工作皆有不同的工作需要完成,其中涉及不同的技能和優先順序。流程瓶頸可能隨時隨地發生,因為資源容量、技能限制或交換的資訊量。

內容

• 流程涵蓋各小組,且需要多個小組成員來協同合作,才能取得成功的成果。
• 工作人員助理已在對話、主動和環境工作人員的情境中協助您的人力。
• 流程會在業務流程的適當區段中使用工作人員。然而,流程也需要人類工作人員協同合作。此協同合作可能涉及人與人,並由工作人員協助,或涉及人—工作人員—人類協同合作。
• 技能缺口由工作人員填補。
• 工作人員可減少追蹤工作的人力效力,並交換重要資訊來協助決策。
• 工作人員也可以根據原則和指導方針進行協同合作和委派。

關鍵元件

• 協同合作面板
  工作人員協同合作需要一個共用空間,所有參與者 (人類與工作人員) 皆可在其中互動。這些協同合作面板不再是靜態且僅限人類使用的環境。而是可邀請工作人員加入、提供貢獻,甚至開始對話的管道,從根本上改變小組工作的性質。例如,工作人員可以在 Slack 中建立和起始個案群集,邀請人類主題專家和其他工作人員針對個案進行協同合作。

• Agentforce 工作人員
  此模式會超出個別工作人員模式,以示範其如何在「協同合作工作人員」模型中協調複雜流程,以智慧方式增強人力能力。上述模式 (對話 (2.1)、主動 (2.2) 和環境 (2.3) 會定義 Agentforce Agent components.c 方向。對話工作人員會作為主要介面,並與人類合作,並作為人類與所有參與協同合作的工作人員之間的介面。當工作過於多面向時,對話工作人員會起始協同合作工作階段,將人類使用者和必要無周邊工作人員組合在一起,以同時處理問題。 流程會變成動態回饋意見迴圈,其中人類可能會起始工作,然後觸發 主動工作人員管理後端步驟,而 環境工作人員可能會觀察以提供即時指引,從而建立人力與數位人工的順暢合併。

• 資料層
  在協同合作工作人員模型中,資料層的角色比提供資訊更為動態;資料層會成為整個人類工作人員小組的永久記憶體和共用工作區。雖然每個涉及的工作人員都有自己的特定資料需求,如其個別模式中所定義,但其在複雜工作上的協同合作取決於追蹤整體工作狀態的共用資料基礎。

  此共用狀態十分重要。當從對話工作人員將工作交給主動工作人員,然後將工作交給人類進行批准時,資料層必須追蹤每個步驟的進度、內容和決策。這可確保每個參與者均具有一致且最新的專案檢視。

互動

1. 人類會與其他人類和工作人員開始協同合作工作階段。
2. 系統會定義內容、目標、工作和成果。
3. 工作人員會帶入其他資訊,並主動規劃完成工作所需的步驟,以及人類或工作人員的擁有者,藉此增強內容。
4. 系統會觀察進度、更新內容,並執行動作。
5. 工作人員執行工作的位置,工作人員會提供詳細資訊,以協助人類專案關係人瞭解推理、提供回饋意見,並允許攔截。
6. 工作人員以完全的透明度與合規性完成工作。

貿易

相關模式

運算子模式:協同合作工作人員通常會作為運算子,將要求路由至適當的專業 AI 工作人員或人力服務代表,並協商意圖。

協調流程模式:在涉及協同合作的情況下,協調工作人員會管理 AI 工作人員的群集,彙總其回應以獲得流暢的使用者體驗。

工作區 (Radar O'Reilly) 模式:協同合作工作人員會使用此模式來管理回應式的單一玻璃 UX,並在對話流程中即時更新相關內容。

與協助使用者的協同合作模式不同,自動工作人員的設計目的為完整委派。此區段提供可獨立規劃及執行複雜、多步驟工作的工作人員的結構藍圖,以達成高階目標,而不需要人力介入。此處的重點是建立一個系統,您可以使用目標來任務,並 Trust 從開始到結束執行。

問題

您的組織透過一組高度複雜的流程來實現價值,每個流程都有不同的原則驅動工作、手冊和執行所需的特定技能。這些通常是需要大量時間和資源投資的計畫。

設定新計畫具有高負擔,可能需要數月才會實現價值。實作回饋意見和改善方式通常需要額外的時間和精力。複雜性主要是由您組織的結構所驅動,其中散佈的應用程式和程序會造成需要人類管理程式的相依性。

內容

• 工作人員可從開始到結束獨立作業。工作人員已設計和設定,以預先建立目標、計畫和策略。
• 工作人員可在不需要人類批准的情況下做出所有決定。提供給工作人員原則與合規性指導方針。
• 工作人員可以存取所需的必要內容和資料,並且可以執行必要動作,而無須使用人力。
• 人類會收到通知,但並非「在迴圈中」。

關鍵元件

• 目標與策略定義層級
  • **流程手冊:**包含工作人員必須遵循之決定性規則的自發執行詳細描述
  • **自動決策條件:**可讓工作人員在不需要人類批准的情況下做出決策的規則
  • **回復規則:**工作人員主要流程失敗時處理預設或例外情況的預先定義動作
  • **範圍:**清楚定義的邊界,概述工作人員可以和不能執行的動作,包括必須如何處理超出範圍的情況
  • **已完成的成功條件和定義:**決定工作人員何時成功完成工作的度量和條件
• Agentforce 工作人員
  • **工作人員協調流程或作法師:**擁有目標、原因和計畫執行的主體工作人員
    • 主題與指示:一旦定義目標後,協調員或作法師工作人員會領導將該整體目標拆分為較小的可管理工作或子工作。它會制定全方位計畫,概述工作的順序,並識別每個步驟所需的特定工作人員或工具。最後,協調程式工作人員可確保計畫順暢執行、監視進度、管理相依性,並視需要進行調整,以有效率地達成目標。在作法編寫工作人員的個案中,它會將內容和狀態傳遞給下游工作人員,以完成工作。
    • **動作:**動作會呼叫工具來執行某個函數,或將資料或委派給其他無周邊工作人員,以啟用更廣泛的功能和更複雜的工作流程。
    • **護欄:**護欄會作為一組可設定的規則和執行階段檢查,以限制工作人員的行為。作為安全層,可攔截提示、驗證工作人員建議的動作,並篩選其最終回應,以防止有害內容、強制執行業務規則,並確保工作人員在其指定的範圍內作業。
• 資料層
  • **CRM 資料:**可在 CRM 中使用的客戶資料,可將內容提供給一或多個工作人員
  • Data 360 元件 (包括 DLO 和 DMO) 可儲存從不同來源採取的相關客戶資料
  • 已計算、串流和即時洞察可提供工作人員與客戶、其活動和重要洞察的立即相關資料。這可啟用預防性問題解決方案 (例如處理電子郵件拒絕),緩解升級。
  • Data 360 向量存放區和 RAG 提取器提供工作人員所有相關企業資料和非結構化 Knowledge 的統一檢視
  • 提供對話內容的個案歷程記錄和對話工作人員歷程記錄等Slack 頻道訊息或對話資料
• 監視與監督
  • **工作人員目標進度監視:**追蹤自動工作人員工作階段的進度,以測量成果並確保符合目標
  • **工作人員作業監視:**追蹤自發工作人員的即時狀態以進行介入和疑難排解,以確保順利運作
  • **工作人員監管:**追蹤追蹤和稽核記錄,以確保自主工作人員遵循預先定義的目標、目標和道德指導方針

互動

1. 此工作是以明確的成果來定義。
2. 工作會透過下列其中一種方法起始:
   • 工作人員受到指派。
   • 工作人員會主動根據資格挑選工作。
   • 工作人員在背景中執行工作。
3. 工作人員可以清楚地建立期望並通知人類,並詳細說明目標、計畫和策略。計畫詳細說明逐步程序、使用的工作人員、使用的資料、範圍、工作人員評估計畫,以及監視進度、作業和管治的人類檢查點。
4. 工作人員開始執行。在每個里程碑上,它會更新狀態與進度。人類可以視需要提供回饋意見或攔截工作人員。
5. 工作人員完成工作。結果與結果可在監視顯示面板中找到。

貿易

相關模式

Project Manager 模式:自動工作人員經常體現此模式,在最少的人工介入的情況下,監督從起始到完成的長時間執行多步驟流程。

設定程式模式:自動工作人員可以使用此模式,根據自然語言需求或預先定義的原則自動產生和驗證組態,以確保合規性和準確無須手動監督。

Zen Data Gardener 模式:此模式可供自發工作人員用於排程、背景資料精簡和標準化,確保資料品質和隨時間的一致性,以支援工作人員準確的決策。

現在,我們將透過探索如何在 Salesforce Platform 上實作工作人員分類和工作人員模式,讓工作人員分類和模式更生動。對於不熟悉 Agentforce 核心元件的使用者,附錄提供有助於重新整理本章和下一章參照的關鍵技術。

本節介紹工作人員的分類,並說明每個工作人員的常見使用個案,以顯示其在實際世界應用程式中如何使用。

客戶 Jane 造訪公司的網站以檢查最近訂單的狀態。

• **互動:**Jane 開啟聊天視窗 (Agentforce 聊天用戶端)。
• **工作人員動作:**對話工作人員問候她,詢問她如何提供協助。Jane 問:「我的最新訂單在哪裡?」
• 流程:
  1. 工作人員以 Salesforce 中 Jane 的客戶資訊為基礎,可識別她最近的訂單。
  2. 它會查詢寄送系統 (透過 MuleSoft 連接器) 取得最新的追蹤資訊,並為 Jane 提供即時更新和追蹤連結。
  3. 接著會查詢原則並自動升級為加速寄送。
  4. 當 Jane 提出工作人員無法處理的複雜問題時,其會將聊天順暢升級至人力服務代理,提供內容的完整文字記錄。

配方

使用的模式:對話式 AI 模式,將 交易資料整合至工作人員

設計時間

1. 設定對話工作人員。

   設定增強型聊天	→	建立服務代理程式	→	定義支援訂單主題	→	建立「取得訂單」動作
   						↓
   新增輸出升級 Omni-Channel 流程	←	建立升級主題	←	新增動作至主題	←	建立「取得狀態」動作
   ↓
   發佈工作人員

2. 設定增強型聊天作為 Jane 的聊天進入點,讓 Jane 可以在網頁中開啟 Agentforce 視窗。
3. 啟用 Agentforce 並在 Agentforce Builder 中建立服務代理,以處理對話並觸發自訂動作。
4. 使用描述和 指示定義「支援訂單」主題,讓工作人員能自然辨識「我的最新訂單在哪裡?」。
   1. 建立自訂工作人員動作:
      1. 「取得連絡人最新的訂單」動作,以取回 Jane 的最新訂單
      2. 依訂單識別碼取得貨運狀態動作,以透過 MuleSoft 提取追蹤資訊
      3. 您可以選擇性地在「流程」中協調這兩個動作 - 提取最新訂單和呼叫 MuleSoft - 使用外部服務動作。
      4. 將這兩個動作新增至 產生器中的服務代理程式,並將其連結至「訂單與追蹤」主題,然後發佈。
5. 定義具有描述的「升級」主題,以升級為服務代表。
   • 建立並啟用輸出 Omni-Channel 流程。
   • 將它新增至產生器中的「連線」索引標籤,以使用升級訊息進行升級。
6. 設定 Omni-Channel。

   設定 Omni-Channel

   →

   在指示中定義升級規則

   →

   設定優先順序與容量

   →

   測試和驗證

7. 當 AI 工作人員無法解決查詢時,啟用流暢升級至人力服務工作人員。設定 Omni-Channel 路由以將聊天指派給服務代表,並針對內容轉移完整文字記錄。
8. 將升級邏輯整合至 Agentforce 指示和升級動作,讓工作人員知道何時轉移複雜個案。透過 Omni Supervisor 管理路由優先順序與容量。
9. 測試完整體驗:Jane 會開啟聊天,工作人員會問候她、識別她的訂單、提取寄送資料,並在需要人力介入時順暢升級 (另請參閱啟用增強型事件記錄)。
10. 設定資料整合。

    對應內容資料

    →

    建立 MuleSoft API 認證

    →

    註冊 MuleSoft 外部服務

11. 透過已驗證的聊天或聊天前表單,透過 Jane 的 Salesforce 內容來讓工作人員對應其連絡人和訂單記錄。
12. 使用外部認證和已命名認證將 Salesforce 安全連線至 MuleSoft 寄送 API 以進行驗證。
13. 如果 MuleSoft 公開 OpenAPI 規格,請將其 註冊為外部服務,讓 Flow 和工作人員能夠以宣告的方式呼叫。
14. 設定非結構化資料整合。
    1. 從「設定」中建立新資料庫。將其命名為「訂單與寄送原則」。
    2. 新增包含寄送原則例外的保單文件 PDF。
    3. 文件會在背景自動切分、編製索引,並準備好可供使用。

工作人員執行階段流程

設定並部署工作人員後,會在執行階段執行下列步驟序列。

1. **聊天啟動:**Jane 開啟 Agentforce 聊天 (內嵌服務)。Jane 登入後會載入工作階段和連絡人內容。

2. **問候與意圖:**工作人員問候 Jane。Jane 要求訂單的狀態,意圖偵測會將「最新訂單」對應至「訂單與追蹤」主題。

3. **CRM 對應:**工作人員會觸發「取得最新訂單」動作,並在 Salesforce (訂單摘要/訂單) 中查詢 Jane 的最近記錄。

4. **寄送查詢:**工作人員透過已命名認證呼叫 MuleSoft API,然後 /shipping/status/{orderId} 傳回即時狀態與追蹤 URL。

5. **回應組成:**Agentforce 會合併結果並撰寫回應:「您的訂單 [OrderID] 透過 [運送人] 出貨,明天抵達 — [追蹤這裡]。」

6. **回復:**如果沒有相符項目或 API 失敗,工作人員會道歉並建議嘗試修正任何資料問題。

7. **升級:**複雜或情感的查詢會透過 Omni-Channel 自動轉移給人類,進而傳遞完整的聊天與內容。

8. **登入:**所有意圖、動作和成果皆儲存在互動記錄中。在 Anypoint Monitoring 中監視 API 延遲。

9. **持續改善:**升級會提供 Agentforce 重新訓練的摘要;在後續版本中會精簡一般流程。

一位高價值的客戶 John 將價值超過 $1,000 的產品新增至其線上手推車,但在 60 分鐘內未完成購買。

• **觸發:**從電子商務系統觸發 Salesforce Platform 事件 Cart_Abandoned__e,其中包含 John 的連絡人識別碼和手推車值。
• **工作人員動作:**訂閱此事件的主動工作人員會立即開始運作。
• 流程:
  1. 工作人員檢查 John 在 Salesforce 中的記錄,發現他是 VIP 客戶。
  2. 這會為 John 的帳戶管理員 Sarah 建立高優先順序的工作,其中包含捨棄手推車的所有詳細資料。
  3. 它會透過 Slack 傳送通知給 Sarah,敦促她追蹤後續事項。
  4. 同時,它會將 John 註冊為目標 Marketing Cloud 旅程,此旅程會傳送一封含有限時 10% 折扣代碼的提醒電子郵件,以鼓勵他完成購買。

配方

此 recipe 詳細說明在 Salesforce Platform 上實作主動式 AI 工作人員,以解決 VIP 客戶捨棄高價值手推車的問題。解決方案利用 Salesforce Platform Events、Data 360 for Knowledge retrieve 和 Agentforce 協調及時且智慧的後續動作,進而將被動資料轉換為主動業務參與。

設計時間

1. 設定捨棄的手推車事件,以在 VIP 客戶 John 捨棄手推車時觸發。

   建立自訂「連絡人」欄位

   →

   定義新平台事件

   1. 建立包含「連絡人識別碼」、「手推車值」、「手推車上次更新日期時間」和「手推車詳細資料」之 欄位的 Cart_Abandoned__e 平台事件。
   2. 設定捨棄事件:使用 Commerce Cloud,針對 Checkout 事件通知建立平台事件。當手推車Checkout工作階段狀態處於中介狀態,且工作階段逾時於值之後,便會偵測到捨棄。或者,如果您的電子商務是外部系統,請使用下列 任何方法將事件發佈至 Salesforce:流程、Apex、Salesforce API 或 Pub/Sub API。
   3. 在「連絡人」物件中,建立新欄位 Customer_Tier__c,其中包含選項清單值 標準、頂級和 VIP。
2. 在 Data 360 中設定非結構化資料取用: 透過 Amazon S3 將來自文件存放庫的折扣原則文件新增至 Data 360。

   建立 AWS S3 認證	→	建立新的 S3 資料串流	→	設定與部署串流	→	建立搜尋索引
   						↓
   				Test retrieve 函數	←	設定與部署索引

   1. 建立外部認證以存取 S3:針對 IAM 使用者建立新的存取金鑰和密碼集,或針對 IdP 建立新的 IAM 亞馬遜資源名稱 (ARN)。
   2. 建立新的 S3 資料串流:在「資料串流」索引標籤上,建立資料串流「原則文件串流」,選取 S3 來源、選擇 PDF 檔案類型、設定重新整理頻率、對應中繼資料欄位 (檔案名稱與大小),然後部署。
   3. 資料串流完成後,建立搜尋索引:針對切分、E5-large-v2 內嵌模型和混合式搜尋類型,使用通訊通行徑,然後部署索引。
   4. 測試建立的取用函數。
3. 設定「VIP 手推車復原」工作人員。

   從範本建立工作人員	→	新增復原 VIP 手推車主題	→	新增主題指示	→	建立 Slack 警示動作
   						↓
   新增動作至主題	←	建立旅程註冊動作	←	建立折扣優惠動作	←	建立手推車復原工作

   1. 從 Agentforce 員工工作人員範本建立工作人員。
   2. 新增新主題「復原 VIP 手推車」,其中描述此工作人員為 VIP 客戶處理高價值手推車捨棄。
   3. 新增主題指示以驗證 VIP 狀態、使手推車符合資格、通知 Slack 中的帳戶管理員、建議折扣優惠,並在手推車復原電子郵件旅程中註冊客戶。
   4. 建立動作與工作。
      • 警示帳戶管理員動作:傳送主動 Slack 通知
      • 復原捨棄的手推車工作,指派給包含手推車詳細資料的經理
      • 「取得折扣優惠」動作:分析原則與先前購買歷程記錄。建立具有奠基的提示範本、參照提示範本中的取用函數,然後使用資料。
      • 註冊「復原旅程」動作:透過 API 註冊 Marketing Cloud 復原旅程,並收集所有訂閱者資料和從工作人員產生的折扣優惠電子郵件訊息。
   5. 將動作新增至主題。
   6. 使用 Marketing Cloud 中的範本 建立 VIP 客戶手推車復原旅程,或 建立新的旅程。
4. 連線平台事件以呼叫工作人員。

   建立事件觸發流程

   →

   訂閱平台事件

   →

   新增工作人員可叫用動作

   →

   將事件資料傳送給工作人員

   1. 建立新的平台事件觸發流程,VIP Cart Abandonment Recovery。
   2. 選取流程應訂閱的「手推車已捨棄」事件。
   3. 在 Flow Builder 中設定自訂工作人員可叫用動作,然後選取「VIP 手推車復原」工作人員。傳送要求來為客戶起始 VIP 捨棄手推車復原,並傳送平台事件裝載。

工作人員執行階段流程

設定並部署工作人員後,會在執行階段執行下列步驟序列。

1. **手推車捨棄偵測:**John 將 $1,200 新增至手推車,且 60 分鐘後沒有 Checkout 或階段進度會觸發捨棄。
2. **平台事件發佈:**Commerce Cloud 會發佈具有 John 連絡人識別碼、手推車價值 $1,200、手推車修改日期和其他詳細資料的 Cart_Abandoned__e 事件。
3. **流程初始化:**平台事件會觸發「VIP 手推車捨棄復原流程」。
4. **員工工作人員啟用:**執行流程時,系統會叫用「VIP 手推車復原」工作人員。
5. **主題執行:**工作人員會解析「復原 VIP 手推車」主題並執行指示。
6. **通知建立:**工作人員在 Slack 中警示 John 的帳戶管理員 Sarah。
7. **工作建立:**工作人員為 Sarah 建立工作,並向她建議其將執行的後續動作。
8. **折扣分析:**工作人員會呼叫 Data 360 retriever 函數,以根據手推車值、客戶層級和購買歷程記錄要求「允許的最大折扣」。在此情況下,此函數建議 10% 的折扣優惠。
9. **電子郵件準備和旅程註冊:**工作人員準備折扣優惠電子郵件,並使用新的手推車價格,將 John 註冊至 Marketing Cloud 旅程 VIP 客戶手推車復原。
10. **記錄與歸屬:**John 兌換優惠,這會建立記錄歸屬與轉換度量。
11. **回饋意見分析:**系統會分析成果以進一步決定優惠、復原時間和其他最佳化因素。

銷售代表 David 與新潛在客戶進行探索通話。智慧工作人員會即時主動監視通話,透過回答潛在客戶的問題,為 David 提供立即支援。

**範例:**如果潛在客戶詢問特定產品規格,則工作人員會自動提取相關詳細資料,並透過 Slack 或私人訊息將其傳送給 David。

• **觸發:**潛在客戶在與銷售代表 (David) 進行探索通話期間提出需要特定產品資訊的問題。
• **工作人員動作:**環境工作人員會持續分析通話記錄和訊息,以智慧方式識別並提取必要資訊。
• 流程:
  1. 工作人員會即時剖析通話文字記錄。
  2. 它會自動識別關鍵動作項目,並取回相關資訊。
  3. 在此例項中,工作人員會直接從 Salesforce 提取產品資訊。
  4. 接著,系統會透過 Slack 或私人訊息自動向 David 呈現取得的資訊。

配方

此配方中有一些先決條件需要即時語音轉文字功能,我們假設這些功能可透過您的通訊提供者取得。例如,以下是整合 Zoom 通話的配方。

**先決條件:**Zoom 通話的即時文字記錄範例:

• 在 Zoom 開發人員平台中建立具有讀取錄音、webhook 傳送和會議串流所需範圍的 Zoom 應用程式。啟用必要產品功能,例如即時媒體串流 (RTMS)。
• 設定一個中介訊號伺服器 (Zoom RTMS 範例),該伺服器會接收音訊串流、將其轉送至 Amazon Transcribe 服務,並取得已撰寫文字。文字記錄接著會作為平台事件發佈至 Salesforce。

設計時間

1. 設定「銷售通話即時回應」工作人員。

   從範本建立工作人員	→	新增協助通話主題	→	新增主題指示	→	建立文字稿分析動作
   						↓
   		新增動作至主題	←	建立 Slack 洞察動作	←	建立產品規格動作

   1. 從 Agentforce 員工工作人員範本建立工作人員。
   2. 新增新主題「協助通話」,其中包含此工作人員傾聽即時文字記錄、瞭解意圖,並協助處理產品資料的描述。
   3. 新增主題指示以剖析文字記錄、提取產品規格,以及傳送 Slack 訊息。
   4. 建立動作。
      • 分析通話文字記錄動作:分析即時接收的通話文字記錄資料,並解壓縮關鍵問題或動作
      • 「取得產品規格」動作:查詢產品 Knowledge 文章
      • 將 Slack 洞察傳送給「內部」使用者
   5. 將動作新增至主題。
2. 設定「產品 Knowledge」資料庫。

   建立新資料庫

   →

   新增Knowledge文章

   →

   系統區塊與索引

   →

   生效中的陸地程式庫

   1. 從「設定」中建立新資料庫。將其命名為「Product Knowledge」。
   2. 新增包含產品資訊的Knowledge文章。
   3. 文件會在背景自動切分、編製索引,並準備好可供使用。
   4. 在「取得產品規格」動作中使用奠基。
3. 透過 Pub/Sub API 將即時文字稿發佈至 Salesforce。

   伺服器接收音訊文字稿

   →

   伺服器發佈平台事件

   1. 建立平台事件 Transcript_Segment__e,其中包含欄位 呼叫識別碼、序列、發言者、區段開始時間、區段結束時間、持續時間和 文字記錄資料。
   2. 在您的訊號伺服器中 (請參閱先決條件區段),當您從音訊接收文字記錄後,請透過 Transcript_Segment__e 事件立即發佈資料。您可以使用下列 任何方法將事件發佈至 Salesforce:流程、Apex、Salesforce API 或 Pub/Sub API。
4. 訂閱已發佈 Transcript_Segment__e 事件的 Wire 流程。

   建立事件觸發流程	→	訂閱文字稿事件	→	新增工作人員可叫用動作	→	將裝載傳送給工作人員
   						↓
   						工作人員傳送 Slack DM

   1. 建立新的平台事件觸發流程「探索通話洞察」。
   2. 選取流程應訂閱的 Transcript_Segment__e 事件。
   3. 在 Flow Builder 中設定自訂工作人員可叫用動作,然後選取「銷售通話即時回應」工作人員。傳送事件裝載以路由至「協助通話」主題。從主題衍生問題後,問題會傳送至「取得產品規格」動作以取得回答。
   4. 系統會編譯最後的回答,並透過 Slack DM 立即傳送給使用者。

工作人員執行階段流程

設定並部署工作人員後,會在執行階段執行下列步驟序列。

1. **通話起始:**David 在 Zoom 通話中與潛在客戶開始探索通話。Zoom RTMS 會將即時音訊串流至訊號伺服器文字記錄端點。
2. **即時文字記錄:**訊號伺服器會接收音訊、將音訊寫入文字,並在 Salesforce Platform 中發佈「文字稿區段」平台事件。
3. **工作人員聆聽與內容分類:**Salesforce 接收平台事件並觸發「探索通話洞察流程」。
4. 流程會起始接收區段的「銷售通話即時回應」工作人員、識別問題 (例如「Toster 2XP 是否與行動裝置整合?」),並將其分類在「協助通話」主題下。
5. **Knowledge retrieve:**工作人員會觸發「取得產品規格」動作,並查詢 Knowledge 資料以取得相符的回答。
6. **傳送私人 Slack DM:**工作人員執行「傳送 Slack 洞察」,張貼至 David 的 Slack DM:「Product Toaster 2XP 可與 Apple 與 Android 裝置整合,並可透過藍牙連線。安裝應用程式後,只要透過藍牙連線並操作烘焙機即可。以下是手冊的連結。」
7. **即時繼續:**工作人員會繼續接收文字記錄文字;如果出現多個洞察,則會執行緒內容式 Slack 回覆,而不會中斷通話流程。
8. **通話後摘要:**在工作階段結束時,工作人員會自動編譯摘要:重要問題、已採取的動作和參照的產品。
9. **持續改善:**Agentforce Analytics 會評估文字記錄回應延遲、產品比對準確度,以及銷售成果,以隨著時間精簡主題指示。

銷售經理 Bob 會為獨立工作人員指派一個目標:「在未來 60 天內,將加州製造業的銷售管道增加 5 百萬美元。」

• **觸發:**經理透過 Slack 中的指令指派目標。
• **工作人員動作:**自動工作人員會開始其規劃和執行迴圈。
• 流程:
  1. **研究:**工作人員會查詢 Salesforce Data 360 和外部資料來源 (透過 MuleSoft),以識別加州製造行業中非目前客戶的公司。
  2. **資格:**它會分析這些公司,尋找購買訊號,例如最近的資金輪數、新的主管員工或相關的工作貼文。它會評分前 20 個潛在客戶並排定其優先順序。
  3. **識別連絡人:**它會尋找這些公司的重要連絡人 (例如營運副總裁和工廠經理)。
  4. **拓展:**其會為每個連絡人撰寫個人化的拓展電子郵件草稿,參照特定的公司新聞或難題。系統會排程在下週傳送這些電子郵件。
  5. **後續追蹤:**它會追蹤電子郵件開啟與回覆。潛在客戶的正向回覆會觸發其行事曆的分析,以建議會議時間,並在確認時自動產生 Salesforce 事件和新的機會。
  6. **報告:**其會向 Slack 中的銷售經理提供每週進度報告。

配方

這是一種多工作人員案例,每個工作人員都會執行特定工作,並將內容、資料和控制傳送給下一個工作人員。我們將使用一些自訂無周邊工作人員進行研究和合格,以及立即可用的銷售開發代表 (SDR) 工作人員進行潛在客戶拓展和監視。我們也會假設 Bob 的公司使用 ZoomInfo 進行市場研究。公司也會收到資料庫中存在的供應商網路資料,其中包含與其合作的公司有關的重要資訊。

設計時間

1. 設定多工作人員結構。

   研究工作人員收集情報

   →

   資格工作人員評分商機

   →

   SDR 工作人員開始拓展

   1. 研究工作人員:透過 MuleSoft 查詢 Data 360 與外部來源
   2. 資格工作人員:排定優先順序、評分和增強商機
   3. SDR 工作人員:取得商機指派、執行拓展、追蹤和排程會議。使用 Agentforce Analytics for SDR 工作人員監視 SDR 工作人員的活動和進度。
2. 探索並取用新的公司資料。

   建立新資料空間

   →

   採取 Salesforce CRM 資料

   →

   Ingest ZoomInfo data

   →

   採取供應商資料庫資料

   1. 設定名為「Sales and Marketing」的新「資料空間」。此新的資料空間將容納獨立工作人員所需的所有資料。
   2. 使用 Salesforce 連接器將「商機」、「帳戶」、「連絡人」和「機會 CRM」資料流入至資料空間。
   3. 設定 ZoomInfo 的 Data 360 連接器。將資料流入至 Data 360 Sales 和 Marketing 資料空間。
   4. 設定 Anypoint Salesforce Data 360 連接器以連線至供應商資料庫,並將資料提取至 Data 360。
3. 設定平台事件以起始無周邊「研究」和「資格」工作人員。

   建立新平台事件

   1. 建立一個新的 AgentGoal__e 平台事件,其中的欄位目標會捕捉人類使用者的概況目標。
4. 設定「目標協調流程」工作人員,這是對話式 AI 工作人員,會接收使用者的目標並將其協調至其他工作人員。

   從範本建立工作人員	→	新增剖析目標主題	→	新增主題指示	→	建立目標事件動作
   						↓
   						新增動作至主題

   1. 從 Agentforce 員工工作人員範本建立工作人員。
   2. 新增新主題「剖析目標」,說明此工作人員瞭解目標意圖,且可以視需要呼叫其他工作人員。
      • 新增主題指示來剖析目標,並將事件觸發給其他工作人員。
   3. 建立「目標」事件,AgentGoal__e。
5. 設定由協調工作人員觸發的「商機研究和資格」工作人員。

   建立「研究」主題	→	建立重複動作	→	建立商機增強動作	→	建立商機評分動作
   						↓
   				新增動作至主題	←	建立商機資格動作

   1. 建立具有描述「在區域或州中研究新商機」的潛在客戶研究主題。
   2. 建立動作。
      • 複製商機 Apex 動作:對照現有客戶檢查和驗證新商機
      • 增強商機 Apex 動作,其使用提示範本:查看非結構化行銷洞察和供應商資料庫資料,以增強商機資料
      • 「評分商機」動作:使用更新的商機資料主動為商機評分
      • 使商機符合工作人員資格動作:根據評分指派使商機符合 SDR 工作人員資格的參數
6. 設定 Agentforce SDR 工作人員以執行拓展、商機培養和會議排程。

   從範本建立 SDR 工作人員	→	設定工作人員Knowledge庫	→	設定工作人員電子郵件設定	→	設定商機指派規則
   						↓
   						定義合格商機條件

   1. 使用預先設定的 Lead Nurture Agent 範本,從「設定」頁面建立新的 SDR 工作人員。設定電子郵件設定和商機指派規則,選取「商機」物件或「連絡人」物件,並定義指派規則的合格條件 (量度商機分數和新商機)。
   2. 透過設定工作人員、指派權限,以及設定步調和指派規則,設定 Agentforce 商機培養。
   3. 為 SDR 工作人員設定必要 Knowledge,以回答問題。
7. 設定新流程以訂閱已發佈的 AgentGoal__e 事件。

   建立事件觸發流程

   →

   訂閱工作人員目標事件

   →

   新增工作人員可叫用動作

   1. 建立名為「將目標路由至工作人員」的新平台事件觸發流程。
   2. 選取流程應訂閱的工作人員目標事件。
   3. 在 Flow Builder 中設定自訂工作人員可叫用動作,然後選取「商機研究和資格」工作人員。

工作人員執行階段流程

設定並部署工作人員後,會在執行階段執行下列步驟序列。

• **目標指派:**Bob 要求獨立工作人員「在 60 天內將加州製造的銷售管道增加 5 百萬美元」。
• **目標協調流程:**自動目標協調流程工作人員會接收目標、剖析意圖,並建立平台事件 AgentGoal__e。「目標協調流程」工作人員的設計目的為持續擴充其功能,以處理多個目標。您可以展開以新增其他協調流程功能,或要求使用者提供說明,以進一步瞭解意圖並起始目標。
• 路由:「流程路由目標至工作人員」會觸發,並呼叫「商機研究和資格」工作人員。
• 研究:「商機研究和資格」工作人員會查詢 Data 360 的新商機資訊、針對現有客戶進行重複、從 Data 360 提取額外的市場研究資料,並增強商機。它會進一步為商機評分、識別重要連絡人並使商機合格。
• **拓展:**商機合格後,商機會透過商機指派規則成為 SDR 工作人員的資格。SDR 工作人員會進行初始拓展,並透過回答與產品相關的問題,與連絡人維持對話。
• **後續追蹤:**在步調結束時或根據商機的要求,如果商機符合服務代表參與資格,則工作人員會提示進行會議排程。接著會排程會議並結束流程。
• Agent Analytics:SDR Agent Analytics 顯示面板提供工作人員執行效率的洞察。

一位長期客戶遇到多面向的問題:他們已過度計費、收到的更換零件不正確,且服務已中斷連線。

• **觸發:**客戶開始聊天,而初始對話工作人員快速發現複雜性並升級至工作人員群集。
• **工作人員動作:**協調程式工作人員負責。
• 流程:
  1. **協調流程:**維持與客戶的對話,提供更新
  2. **協調員委派:**透過使用 A2A 通訊協定實作,協調流程工具會發現具有必要功能的「相關工作人員」(帳單、物流和佈建) 並分派工作。
     • 收帳單工作人員:「調查客戶 X 的發票 #INV-7890。是否有任何不一致?」
     • 對 物流工作人員:「檢查客戶 X 的追蹤編號 #TN-12345。確認已出貨的零件編號以及正確零件的目前庫存。」
     • 若要 佈建工作人員:「檢查帳戶 #ACC-5678 的服務狀態。如果中斷連線,原因代碼為何?」
  3. **專門工作人員執行:**每個工作人員都會收到 A2A 要求、查詢其各自的系統,並撰寫回應。
  4. **合成:**工作人員會透過 A2A 回應向協調流程報告其發現結果。「協調流程器」會同步化資訊:「客戶實際上已超額計費 $50。由於倉庫錯誤而寄出錯誤的組件。由於帳單問題,因此服務自動中斷連線。」
  5. 確認:「協調流程工具」會通知客戶有關問題,並提供將問題升級給人力服務代表,並提供關於後續步驟的明確指引。
  6. **解決方法:**接著將完整的解決方案提議給服務代表以供批准。服務代表加入對話。服務代表快速查看與問題相關的所有資料,包括工作人員建議的解決方案:「透過加速運送,為右側部分建立新的運送訂單。起始錯誤組件的退貨。批准新訂單的 10% 折扣,並追加銷售具有最新改善版本的組件。更新付款資訊和優惠以設定循環帳單安排。」

配方

此配方概述了針對涉及多面向的複雜客戶服務問題所設計的協同合作工作人員系統實作。透過使用協調員工作人員透過 A2A 通訊協定將工作委派給專門工作人員 (帳單、物流和佈建),然後合併其發現結果,系統可提供全方位的解決方案,並順暢整合服務代表以進行最終批准和客戶互動。

設計時間

1. 設定增強型聊天作為客戶的聊天進入點,讓他們可以在網頁中開啟 Agentforce 視窗。
2. 設定 Agentforce 帳單工作人員,這是無周邊專門工作人員,可接受訂單或發票並執行帳單查詢。

   從範本建立工作人員

   →

   定義帳單查詢主題

   →

   建立自訂流程動作

   →

   新增動作至主題

   1. 啟用 Agentforce 並從 Agentforce 員工代理程式範本建立「員工代理程式」。
   2. 定義主題「帳單查詢」,其描述為「調查發票不一致、付款問題和帳單錯誤」。
      1. 新增自訂流程動作「檢查發票不一致」,輸入「發票號碼」、「客戶識別碼」和「日期範圍」,以及輸出「不一致金額」、「根本原因」和「受影響的交易」。
3. 設定 Agentforce Logistics Agent,無周邊專門工作人員可驗證出貨、追蹤出貨和檢查庫存。

   從範本建立工作人員

   →

   定義「寄送驗證」主題

   →

   建立自訂流程動作

   →

   新增動作至主題

   1. 啟用 Agentforce 並從 Agentforce 員工代理程式範本建立「員工代理程式」。
   2. 定義主題:「寄送驗證」,其中包含驗證發票寄送的描述。
      1. 新增自訂流程動作「驗證寄送詳細資料」,輸入「發票號碼」、「客戶識別碼」和「日期範圍」,以及輸出「已寄送零件」、「日期」和「庫存狀態」。
4. 設定 Agentforce 佈建工作人員,這是可驗證佈建和服務狀態的無周邊專門工作人員。

   從範本建立工作人員

   →

   定義服務檢查主題

   →

   建立自訂流程動作

   →

   新增動作至主題

   1. 啟用 Agentforce 並從 Agentforce 員工代理程式範本建立「員工代理程式」。
   2. 定義主題「服務檢查」與描述以驗證服務連線和帳戶狀態。
      1. 新增自訂「流程」動作「驗證服務」,輸入「客戶識別碼」和「資產識別碼」,以及輸出「服務狀態」和「服務例外原因」。
5. 將「帳單」、「物流」和「佈建」工作人員公開為 A2A 伺服器,並在「工作人員註冊」中予以註冊。

   透過 MuleSoft 公開工作人員

   →

   在註冊表中註冊工作人員

   1. 若 Agentforce 工作人員沒有直接 A2A 支援,則 MuleSoft 連接器可用來將 工作人員 API 公開為 A2A 伺服器。
   2. 在 工作人員登錄中註冊這些 A2A 伺服器。
   3. 使用 Anypoint Agent Fabric 協調工作人員。
      1. MuleSoft Agent Broker 可協助根據工作人員卡中提及的工作人員功能,協調跨平台的任何工作人員。
6. 設定 Agentforce 說明工作人員,此對話式 AI 工作人員會與客戶互動、評估複雜度,並與多個專門工作人員協調以解決問題。

   建立服務代理程式	→	定義「調查」主題	→	建立通知動作	→	定義協調流程主題
   						↓
   定義升級主題	←	「建立」 「建立個案」動作	←	建立 Call Agent 動作	←	建立工作人員協調流程
   ↓
   建立 Omni-Channel 流程	→	升級的連線流程

   1. 啟用 Agentforce 並在 Agentforce Builder 中建立服務代理,以處理對話並觸發自訂動作。
   2. 定義主題「服務調查」,其中包含描述和指示,讓工作人員能自然識別具有多個同時問題的複雜主題。
      1. 建立自訂工作人員動作。
         • 「狀態通知」動作可確認問題並提供進度更新
   3. 定義可透過動作呼叫其他工作人員的協調流程主題。
      1. 建立呼叫「流程」動作的「通話工作人員」動作。「流程」動作有數個工作人員動作,並可起始每個無周邊工作人員:帳單工作人員、物流工作人員和佈建工作人員。
      2. 建立建立個案、新增詳細資料和設定狀態的「建立個案」動作。
   4. 定義具有描述的「升級」主題,以升級為服務代表。
   5. 建立並啟用輸出 Omni-Channel 流程。
      • 將它新增至「工作人員」中的「連線」索引標籤,以使用升級訊息進行升級。

工作人員協調流程流程

Anypoint 程式碼產生器現在支援建立工作人員經紀人。工作人員經紀人是智慧路由和協調流程層,可連接跨網域的工作人員,並吸引最適合的工作人員和工具。MuleSoft Dev Agent 會產生程式碼來為經紀人設定基礎。

根據先前在「工作人員登錄」中註冊的工作人員卡片 (A2A 伺服器) 中提及的工作人員功能,Anypoint 程式碼產生器會自動進行進一步的設定。最後,我們可以將此工作人員經紀人部署至雲端。

在工作人員經紀人可供耗用後,這些要求會路由至適當的工作人員。經紀人會收到提示,並使用 LLM 將其拆分為工作,並決定要先呼叫哪位工作人員。在每個反覆迴圈中,它會判斷是否已成功處理原始提示,或是否需要與其他工作人員合作以完成工作。

工作人員執行階段流程

設定並部署工作人員後,會在執行階段執行下列步驟序列。

1. **聊天啟動:**客戶開啟 Agentforce 聊天 (內嵌服務)。工作階段和連絡人內容會在客戶登入後載入。
2. **問候與意圖:**工作人員問候客戶。客戶明顯感到沮喪時,會通知有關超額收費、錯誤的零件和中斷連線的服務。
3. **CRM 對應:**工作人員會觸發「取得最新訂單」動作,並在 Salesforce (訂單摘要/訂單) 中查詢客戶最近的記錄。接著工作人員會在內容中確認訂單,並通知客戶將進行調查。其會進一步查詢發票識別碼、與發票相關聯的追蹤編號,以及與服務相關的資產識別碼。
4. **協調流程啟用:**協調程式工作人員會收到升級和訂單識別碼,然後建立個案。它會將內容資料傳遞給三個工作人員,並與其通訊:帳單工作人員、物流工作人員和佈建工作人員。
5. 帳單工作人員回應:「帳單工作人員」會傳回並提供零件、單位成本和總成本的詳細資料。它也會注意到訂單中的部分與發票中的部分之間發生不一致。「帳單工作人員」會查詢訂單中零件的價格,以及超額收費的原因。
6. 物流工作人員回應:「物流工作人員」會傳回並提供已出貨組件的詳細資料,以及物流系統建立的例外備註,其中指出可能因為標記問題而傳送的組件錯誤。「物流工作人員」也會確認問題已修正,且正確的組件適用於原始和更新版本。
7. **佈建工作人員回應:**佈建工作人員會傳回並提供服務中斷連線的詳細資料,以及有關已到期付款資訊的問題。它也會提供傳送的通知,以建議客戶更新付款資訊。
8. **協調流程合成:**協調程式工作人員會同步化來自所有工作人員的回應,並透過查看每個問題的 Knowledge 文章來撰寫解決方案。首先,會查詢錯誤零件的資訊並起始退貨。其次,根據解決方案原則文件為問題提供折扣,並建議將其升級為客戶可以購買的較新版本 (但價格有所差異)。第三,它需要客戶的新付款資訊,因此會升級至服務存放庫以傳達解決方案。
9. **升級:**協調程式工作人員會升級至服務代表,提供所有必要的內容、調查備註和解決方案建議以及必要的批准,並將服務代表帶入通話。
10. **迴圈中的人:**服務代表感謝客戶的耐心等候、對問題表示歉意並解釋問題。接著,服務代表為零件提供 10% 折扣作為薪水,並通知客戶新的已升級零件及其優點。最後,他們會說明中斷連線、取得新的付款資訊,並更新系統。
11. **主動還原:**AI 工作人員會監視交談,並主動採取動作來還原服務、訂購升級組件,以及建立含折扣與調整價格的新發票。
12. **個案結束:**最後,它會編譯摘要、更新個案並結束個案。

若要使工作人員有效,工作人員必須能夠與廣泛的企業資料與工具整合。這會提供工作人員執行其設定的目標所需的基本內容。Agentforce 架構提供複雜的整合結構,可整合 Salesforce 和 Salesforce 外部的資料 (內部)。

本節探索將工作人員連線至這些資源的模式。這些模式以兩種基本整合方法為基礎。

• **內部整合 (資料存取與工具存取):**針對 Salesforce 生態系統中的資源,工作人員有兩種操作方式。
  • **資料存取權:**Agentforce 核心執行階段與 Data 360 深度整合,可讓其直接查詢內部資料服務。它可以根據 資料圖原生方式編譯和執行查詢,以取得客戶的全方位檢視、透過 RAG 執行語意搜尋以瞭解非結構化 Knowledge,以及使用 **Data 360 查詢 API 存取大量資訊。**此直接路徑已針對資料提取的速度和彈性最佳化。
  • **工具存取權:**當工作涉及複雜的業務邏輯或多步驟流程,或需要嚴格的管治時,其功能會壓縮為「動作」。這些動作使用 Apex 或流程建立,可提供安全且可重複使用的介面,讓工作人員能夠執行所建立業務流程的任何作業,而不只是讀取資料。
• **外部整合 (MCP/A2A):**當工作人員需要 Salesforce 外部的資訊 (例如從外部應用程式、微型服務或其他工作人員) 時,會使用 **模型內容通訊協定 (MCP)。**此開放標準提供通用的互通語言。您可以從 AgentExchange 新增 MCP 伺服器,或者管理員可以在「工作人員登錄」中新增或將 Apex 呼叫新增至 MCP 伺服器。接著動作會起始對外部 MCP 伺服器的要求,以結構化方式來橋接內部與外部世界。同樣地,當工作人員需要與其他工作人員通訊時,Agent2Agent (A2A) 通訊協定可協助進行此互動。這可建立複雜的多工作人員系統,專門工作人員可在其中協同合作以解決複雜的問題,進而促進模組化性和可重複使用性。

下列模式會根據工作人員需要的特定資料整合主題進行組織。我們將示範如何套用這些模式來解決不同的資料挑戰,從使用 MCP 連線至外部應用程式,到使用 Data 360 中直接存取和正式動作的強大組合存取 Data 360 中的 大量資料、即時交易記錄,以及使用 Data 360 中的 非結構化內容。

問題

工作人員的成效取決於其操作外部工具的能力。然而,這些工具 (從舊版 ERP 到現代 SaaS 應用程式) 缺少共用的語言。每個項目都有唯一的 API、驗證模型和資料格式。這會迫使開發人員進入一個脆弱且無法調整的週期,為工作人員需要使用的每個新工具建立和維護自訂點對點整合。

內容

請考慮任務解決損毀出貨個案的工作人員。若要成功,它必須與三個不同的外部系統互動:它需要查詢供應商的 API來檢查替代庫存、呼叫物流合作夥伴服務來安排新的交付,以及存取財務系統來處理貸項。若沒有通用通訊協定,工作人員將需要三個個別的自訂整合,每個整合皆可能導致失敗。MCP 提供標準化通訊層,讓這些互動順暢且可靠。

以下是您如何將透過 MCP 公開的外部服務整合至工作人員的配方。

**配方 1:****使用 MCP 啟用外部工具**

問題

組織在混合舊版 ERP 和現代 SaaS 上執行,但與工作人員整合這些組織很困難,因為沒有共同的通訊協定—每個工具都有自己的 API、驗證和資料模型。開發人員最終會為每個工具建立和維護自訂點對點連接器,進而產生脆弱、無法調整且成本高昂的整合。

模式

工作人員透過結構化動作叫用外部工具 (透過 MCP 公開),讓其能夠使用 Salesforce 平台以外的專用工具。

內容

• 工作人員會作為 Salesforce 平台外存在的一組工具的 Proxy。
• 這些外部工具可能有不同的 API、驗證機制和資料格式。
• 需要標準化通訊協定,才能讓工作人員與這些外部工具之間順暢地互動。
• 重複使用性是關鍵考量因素,因為多個工作人員可能會將相同的外部工具用於不同的用途。

互動

1. **觸發:**使用者要求或 Agentforce 內部的內部事件需要使用外部工具。
2. **意圖採取動作:**Agentforce Agent 會識別意圖,並判定需要外部 MCP 型工具。
3. **計畫者 (內部):**Agentforce 工作人員的計畫者會根據設定的指示和可用的工具選取適當的 MCP 工具或動作。
4. **執行:**Agentforce Agent 會將 MCP 相容要求傳送至外部 MCP 伺服器 (例如,透過 Apex 呼叫傳送至 MuleSoft 端點,接著路由至外部 MCP 伺服器)。
5. **外部處理:**外部 MCP 伺服器會處理要求、與基本外部應用程式互動,並準備 MCP 相容的回應。
6. 結果:外部 MCP 伺服器會將回應傳回給 Agentforce Agent。
7. **後續追蹤:**Agentforce Agent 會處理回應、更新其內部狀態,然後繼續工作或提供回饋意見給使用者。

貿易

工作人員的決策邏輯與其基本資料相同。若要讓工作人員聰明地採取行動,其必須對周圍世界有豐富的即時瞭解。若沒有定義的資料取用結構,則工作人員無法存取或處理其運作所需的大量即時資訊。

將交易資料與工作人員整合

問題

工作人員經常需要對位於記錄系統中的個別記錄執行低延遲讀/寫作業 (例如,更新個案或提取訂單狀態)。這些動作需要資料完整性和可靠性,以確保基本資料模型的一致性。核心結構挑戰是在不建立脆弱點對點整合的情況下,為此交易資料存取提供安全、即時且可調整的模式。

內容

成功將工作人員連線至這些記錄需要由數個核心元件所組成的強大結構。

• **交易系統:**這些是資料的權威來源,例如記錄系統,例如 Salesforce、Workday 或 **SAP,**或在如 AWS 等平台上主控的服務。
• **整合層:**強大的整合層,通常由 MuleSoft 處理,對於安全連線至這些不同的系統、轉換資料,以及將資料公開至 Agentforce 平台而言至關重要。
• **MCP 伺服器:**為了確保互通性,工作人員會使用 MCP 標準與這些外部系統通訊。整合層可以連線至主控外部服務或工作人員的各種 MuleSoft、Heroku 或第三方 MCP 伺服器。
• **工作人員交換:**此元件會作為目錄或切換簿運作,允許 Salesforce 工作人員探索並安全連線至正確的外部服務或工作人員以完成其工作。

recipe 1:透過 MCP 進行直接記錄作業

模式

工作人員使用 MCP 連線至交易資料系統,並對具有立即一致性需求的特定識別記錄執行狀態 CRUD 作業。

內容

• 對話、協同合作的工作人員必須在工作流程中交易記錄系統資料。
• 記錄系統是外部系統。
• 交易必須為 identempotent。

關鍵元件

• **Agentforce 工作人員:**包含可進行交易更新的主題與指示。動作會呼叫外部 MCP 伺服器或 Agentforce Exchange 註冊的 MCP 伺服器。
• **MCP 伺服器:**公開交易資料與函數的 MCP 伺服器 (例如,含輸入資料的 tool=billing.update_record)
• **記錄的外部系統:**發生狀態變更的系統

互動

1. **觸發:**指令或事件會在記錄上需要進行交易。
2. **意圖採取動作:**Agentforce Agent 識別狀態變更意圖。
3. **計畫者 (內部):**計畫者選擇 MCP 工具。
4. **執行:**此工具會在原則、記錄和欄位級存取檢查通過後執行。
5. **結果:**MCP 伺服器傳回回應
6. **後續追蹤:**Agentforce Agent 處理回應。

貿易

配方 2:透過 Mulesoft API 進行複雜協調流程

模式

工作人員利用 Mulesoft API 進行複雜、多步驟、跨系統的原子交易。這可提供單一受管理端點,確保端對端處理可靠,並避免與直接呼叫個別系統相關聯的一致性、可靠性、延遲和資料問題。

內容

• 對話和獨立工作人員通常需要可靠地執行數個作業。
• 交易中有多個交易系統和作業。
• 工作流程需要交易/回復、重試和強制執行原則。
• 交易需求為即時、可見、可觀察及符合。

互動

1. **觸發:**指令或事件會發生,需要完成複雜的交易。
2. **意圖採取動作:**Agentforce Agent 識別意圖。
3. **計畫者 (內部):**計畫者選擇 API 或 API 動作的可叫用動作。
4. **執行:**執行 API 並傳回回應。
5. **後續追蹤:**Agentforce Agent 處理回應。

貿易

將分析資料與工作人員整合

問題

組織已大量投資於分析基礎結構—資料倉庫和湖、即時分析系統和業務情報平台—但 AI 工作人員仍保持與這些系統中斷連線。這會在工作人員取得豐富內容的能力中產生間隙 (例如,客戶在上一季度已退貨組件三次),以協助做出更好的決策 (在此個案中為升級)。

內容

工作人員的作業情報衍生自其從根本上不同的資料格式和來源中合併資訊的能力。因此,此結構模式並非針對單一使用個案而設計,而是作為基本的資料取用架構。有效的工作人員必須準備好處理結構化來源,才能執行邏輯資料驅動的分析;工作人員需要大量結構化摘要的存取權。這包括與企業資料湖整合 (透過與 Data 360 的零複製整合)、處理 中間軟體轉換的資料串流,或提取批次檔案,例如 CSV。

recipe 1:透過 Data 360 Zero-Copy 整合的資料湖

問題

使用傳統資料銷售管道複製、管理和轉換儲存在資料湖中的分析資料時,組織會遇到高成本 (例如 Snowflake)。在過去,分析已大部分離線,導致錯過及時採取動作的機會。

模式

工作人員會查詢 Data 360 中可用的零複製資料 (和已計算洞察),而非查詢外部資料倉庫以取得重要洞察。這可協助工作人員將交易與分析資料奠基於更好的決策。

內容

• 您的組織會將客戶和營運資料儲存在資料倉庫和湖中。
• 您的工作人員需要彙總度量、歷程記錄趨勢和分析洞察的存取權。
• 您的工作人員內容需要交易與分析資料 (請考量研究工作人員對歷程記錄趨勢資料的需求)。

互動

1. **觸發:**工作人員會收到與需要分析資料或已計算洞察存取權的洞察相關的查詢。
2. **執行:**工作人員會執行透過查詢 API 呼叫「Data 360 已計算洞察」的動作,並傳回已計算洞察。
3. **後續追蹤:**Agentforce Agent 處理回應。

貿易

配方 2:從資料串流觸發動作

問題

組織會持續從業務活動產生寶貴資訊,例如網站造訪、通話、會議、聊天和感測器資料。然而,在這些互動變為可用或從資料倉庫提取時,重要洞察會遺失,且及時介入的機會已經過。因此,組織會遺漏大量即時所需的可運作情報,這些情報通常埋藏在這些暫時的串流中。這會造成間隙、錯過的指導機會,以及在沒有完整內容的情況下做出的決策。

模式

工作人員會透過資料動作從 Data 360 的 串流洞察或 即時洞察接收即時或近乎即時洞察,或者工作人員會透過查詢與即時處理引擎 (例如 Apache Flink) 介面的 MCP 伺服器來即時存取串流洞察。

內容

• 如平台事件、Pub/Sub API 和 RTEM 等串流系統會產生大量串流資料。
• 如 Data 360 和 Apache Flink 等串流處理系統會在到達時處理這些個別事件。
• Agentforce 需要查詢串流系統 (例如,即時會議的最新 30 秒文字記錄與其他內容),或由資料動作觸發 (例如,詐騙偵測)。
• 需要近乎即時的低延遲動作。

互動

1. **串流發出:**來源系統會發出連續的資料串流。
2. **串流處理:**串流處理引擎 (例如 Data 360 或 Apache Flink) 會處理資訊。
3. **轉換:**洞察會在中介軟體 (適用於複雜轉換) 或 Data 360 中彙總、轉換和同步化至認知工作人員的資料。
4. **串流洞察事件:**系統會針對已同步化的資料觸發 Data 360 資料動作 (例如 30 秒音訊串流的文字記錄)。
5. **增強:**工作人員新增內容並偵測意圖。
6. **執行:**工作人員執行動作。
7. **後續追蹤:**工作人員正在等待下一個串流洞察。

貿易

將語意資料與工作人員整合

組織擁有不同格式和形狀的業務成品—目錄、手冊、原則、Knowledge 圖表、關係地圖。若要超越簡單的工作執行並參與複雜的推理,工作人員必須能夠瞭解儲存大多數人類 Knowledge 的此資料。

recipe 1:RAG:為工作人員開放非結構化資料的功能

問題

組織經常擁有無法搜尋的資訊,這會阻礙工作人員有信心存取這些資訊。此短缺通常會導致來自工作人員的回應不完整,缺乏建立 Trust 所需的內容深度和可驗證引號。因此,有明顯需要標準化方法,讓工作人員能夠持續檢索語意相關且準確的內容。

模式

此模式提供讓工作人員能夠從內部文件到公用 Web 內容,從各式各樣的非結構化資訊中取用和解譯的結構。授與工作人員此資料的存取權,是發佈如市場情感分析、文件摘要和競爭者研究等進階功能的關鍵。

內容

• Knowledge 位於不同格式與形式的檔案中。
• 冗餘內容在這些文件中很常見。
• 工作人員需要可引用的準確資訊。
• Knowledge 會經常變更,因此檔案需要重新整理和重新編製索引。

互動

工作人員無法將內容依原狀所選取或使用。內容必須先被切分、內嵌、儲存在向量資料庫中,並編製索引,工作人員才能夠從中提取和使用。

吸入並準備

1. **編目與取用來源:**來源可透過兩種方式識別:手動識別 (例如上載 PDF 檔案),或透過其位置識別 (例如 AWS S3)。
2. **切分:**系統會分成較小的可管理區塊來協助有效率地處理和提取所得的內容。這是 RAG 的關鍵步驟,因為其可確保只有最相關的部分資訊,而非整個文件。
3. **內嵌:**接著,系統會使用專用語言模型,將每個區塊轉換為稱為「內嵌」的數值表示。這些內嵌會捕捉文字的語意意義,允許以相似度為基礎的搜尋。
4. **向量儲存空間:**內嵌會儲存在 Data 360 向量存放區中,這是針對高效能相似度搜尋最佳化的專用資料庫。這可讓工作人員快速找到相關內容。
5. **索引:**內容及其內嵌會在向量存放區內編製索引,使其可供立即搜尋以供尋找。

Data 360 retriever 函數

• **取得內容:**此函數會取得查詢作為輸入,並針對 Data 360 向量存放區執行語意搜尋,以尋找最相關的內容區塊。
• **篩選內容:**此函數可讓您根據中繼資料 (例如文件類型、作者或日期) 來篩選檢取的內容,以進一步限定結果。
• **排名內容:**此函數會根據其相似度分數 (向量搜尋)、關鍵字分數,或兩者的組合 (混合式搜尋) 來排名所取的內容區塊。

取得與產生

• **查詢:**當工作人員需要資訊時,其會撰寫也內嵌在向量中的查詢。
• **語意搜尋:**工作人員對 Data 360 向量存放區執行語意搜尋,將查詢的內嵌與已儲存內容區塊的內嵌比較。這會根據向量分數或混合式分數 (向量與關鍵字合併) 來取用語意中最相關的區塊。
• **取得增量產生 (RAG):**接著,系統會將取用的內容區塊連同原始查詢一起提供給 Agentforce 工作人員作為內容。LLM 使用此內容產生精確、準確且可引用的回答。
• **回應與引號:**工作人員會呈現產生的回答,通常會加上原始來源文件或網路連結的引用,以建立 Trust 並允許驗證。

貿易

配方 2:資料圖:工作人員適用的預先設計結構化圖表資料

問題

組織經常擁有隔離的關係資料,進而阻礙工作人員能夠予以提取。此問題通常會導致工作人員提供不完整的回應,這些回應缺乏足夠的內容詳細資料,無法建立不同實體如何連線的 Trust,或導致工作人員必須從多個資料庫提取資訊時發生延遲。

模式

此模式提供架構,讓工作人員能夠從內部 CRM 資料到外部 Knowledge 圖表,從各式各樣的結構化與半結構化關係資訊中,加以取用和解譯。授與工作人員此資料的存取權,是發佈如 Customer 360 檢視、複雜相依性分析和動態內容建立等進階功能的關鍵。

內容

1. 關係資料會跨各種系統和格式散佈。
2. 工作人員需要瞭解實體之間的連線 (例如客戶、其個案、訂單和相關產品)。
3. Knowledge 圖形與連線的資料模型對於瞭解複雜關係至關重要。
4. 工作人員需要可引用的實體關係準確資訊。

互動

關聯性資料必須在圖表結構中進行協調並表示,工作人員才能有效地查詢與使用。

吸入並準備

1. **ク雷蘭群取用來源:**系統會識別資料來源 (例如 CRM 系統、ERP、外部 API 和 CSV),並將這些來源接收至 Data 360。
2. **資料調和:**原始資料會對應至 Data 360 內的「資料模型物件」(DMO),將其結構標準化並建立統一檢視。
3. **身分解析:**系統會合併重複的客戶設定檔,並連結相關記錄,以建立每個客戶的單一精確檢視。
4. **資料圖表建立:**DMO 會連線以形成資料圖表,代表不同實體之間的關係 (例如,客戶 DMO 連線至個案 DMO,該 DMO 連線至產品 DMO)。此圖表允許有效地周遊關係。
5. **已計算洞察:**系統會計算彙總度量和衍生的屬性 (例如客戶的購買歷程記錄總數),並將其新增至資料圖形以取得更豐富的內容。

取得與產生

1. **查詢:**當工作人員需要涉及實體關係的資訊時,其會根據資料圖表制定查詢 (例如「此客戶的所有未結束個案為何,以及與其相關聯的產品?」)。
2. **圖表周遊與查詢 API:**工作人員使用 Data 360 查詢 API 來周遊資料圖表,並根據查詢來檢取連線的記錄、已計算洞察和相關屬性。
3. **內容產生:**接著,系統會以內容形式與原始查詢一併提供所取用關係認知資料給 Agentforce 工作人員。LLM 使用此豐富的內容產生精確、準確且可引用的回答,以反映資料的互連性。
4. **回應與引號:**工作人員會呈現產生的回答,通常會參照通知回應的資料圖表內特定記錄或關係,以建立 Trust 並允許驗證。

貿易

企業處於由 AI 工作人員領導的自動化與情報新時代的邊緣。從處理簡單的客戶查詢到自主執行複雜的業務策略,工作人員承諾重新定義生產力與客戶參與度。Salesforce Agentforce 平台為此轉換提供重要的信任基礎。Agentforce 擁有可靠的陳述式和專業程式碼工具套件、統一的資料平台,以及透過 A2A 和 MCP 開放標準的承諾,為建立每種類型工作人員提供全面且值得信賴的基礎。此結構可讓組織部署智慧型、目標導向的工作人員,這些工作人員會作為連線合作夥伴 (而非獨立地),以促進可測量的業務成功。

Salesforce 提供一組強大的整合工具,由 Agentforce 平台統一,作為建立複雜工作人員的基礎。此文件中的配方與範例假設您熟悉 Agentforce 平台的功能以及工作人員的互動方式。此區段提供您需要瞭解的關鍵元件重新整理,以充分利用此文件中的配方和模式。

本節概述結構設計師和開發人員在 Agentforce 上建立工作人員所需的基礎平台功能。

• **Salesforce 流程:**用於定義工作人員邏輯的主要工具。其陳述性、視覺化介面非常適合用於協調工作人員將採取的步驟。
• **Apex:**提供複雜自訂邏輯、自動工作人員的狀態管理和複雜整合的功能
• **平台事件:**主動與協同合作工作人員的神經系統,作為 A2A 通訊協定的運輸層。
• **Data 360:**工作人員統一的長期記憶體。其提供智慧動作所需的內容,且是取得增量產生 (RAG) 的基礎。
• **MuleSoft:**工作人員與外部世界的橋樑,透過 MCP 啟用系統整合和跨平台工作人員通訊。
• **Slack:**人與工作人員互動的主要面板,包括工作、通知和批准
• **Agentforce 聊天用戶端:**客戶面向對話工作人員的可自訂、可內嵌前端

為了使工作人員真正有效,他們不能存在於單機。Agentforce 採用兩種核心的互通性模式:

• **Agent2Agent (A2A) 通訊:**此通訊協定管理 Salesforce 生態系統內工作人員彼此通訊的方式。Agentforce 平台會作為 **A2A 用戶端和伺服器,**分別提出和聆聽要求,這對於協同合作的工作人員群集而言至關重要。工作人員可與 相關工作人員一起設定,以探索並叫用具有特定技能的其他工作人員,建立動態且可擴充的系統。平台事件可作為這些 A2A 訊息的永久非同步傳輸機制。

• **模型內容通訊協定 (MCP):**此 標準可確保工作人員不會鎖定在單一平台中。MCP 定義通用訊息格式,允許在不同架構上建立的工作人員通訊。在此模型中,**Agentforce 會作為 MCP 用戶端。**例如,Salesforce 工作人員可以透過傳送 MCP 相容要求,來查詢專門處理複雜物流計算的外部工作人員。MuleSoft 可作為門戶,將內部 A2A 要求轉換為外部 MCP 格式 API 呼叫,以確保企業之間的流暢互通性。