企業代理程式結構與設計模式為多代理程式結構的可能性帶來結構,識別並醒目提示 AI 代理程式的新功能如何結合在一起,以提供可靠、可重複、可調整且可管理的代理程式解決方案。我們從「物件導向」程式設計的「設計模式」中獲取靈感,並列出可結合和擴充的模式,以解決在代理技術之前置於以傳統決定性技術為基礎的業務系統範圍之外的許多令人興奮的挑戰。

在討論多重工作人員結構的邏輯後,我們介紹了許多代理模式,從利用自然語言處理來判斷使用者意圖的簡單模式,到提供工作人員之間關注分隔的多重代理模式,到 UX Agent 模式,這些模式可將代理理由帶入呈現方式和與系統、資訊和內容的互動。

首先,您將得到工作人員的新思維方式 - 工作人員作為元件、工作人員作為編輯者、工作人員作為執行動作的使用者、工作人員作為協作者,最重要的是,在更大結構內的使用者以意圖並在其個別的關注範圍內採取行動。

您將取得所需的指標,以構思豐富的工作人員解決方案,這些解決方案可跨越使用者旅程,並提供有意義的工作人員體驗,這是前所未有的體驗。

此文件的初始區段提供 muti-agent 結構的理由。請參閱以下內容以進一步瞭解多工作人員結構所帶來的挑戰和機會。

以下是工作人員模式的定義和描述,從簡單到複雜,涵蓋支援互動的模式、專科工作人員的模式、背景作業的模式,以及長時間執行模式。每個模式都包含實作模式的主要元件圖表,以及使用狀況與代表使用個案的建議。

最後,附錄包含這些模式結合為支援更大代理體驗的整體代理解決方案的範例,例如支援「客戶服務」或「經紀人銷售」。請參閱此區段以瞭解豐富的工作人員體驗如何利用工作人員和動作層級的疑慮分解和分隔,以在互動層級推動重複使用,其中共用工作人員支援內部和外部部部門成員,同時使用輔助模式和自動模式。

企業結構設計師將生成式 AI 整合至其生態系統時,必須解決一組常見的設計問題:

• 需要多少工作人員?
• 工作人員如何互動?
• 工作人員與人類之間的人工分工為何?
• 這些元件如何組合成一致的系統?

此文件提供設計和建立工作人員解決方案的模式方法。

單一型工作人員是大多數代理解決方案的起點。工作人員 (更具體地說,Agentforce 工作人員) 是跨各種主題的成員。針對常見使用個案,從單一工作人員開始。

隨著您的組織成長,多工作人員結構是偏好的方法。相較於單一工作人員系統,多工作人員結構可提供更大的規模、控制和彈性。

多工作人員結構提供以下主要優點:

• 效能與複雜性解析提高:由多個專門工作人員組成的系統提供增強的功能,並簡化指示符合度。
• 模組化與擴充性:可更輕鬆地新增、取代、修改和測試個別工作人員,進而提升靈活性。
• 彈性與錯誤容忍度:單一元件失敗不會影響整個系統,進而提升整體彈性。
• 去中心化管理:疑難排解與管理可與特定工作人員及其對應的應用程式分隔,進而簡化維護與監督。

將多重工作人員結構合理化從將核心結構原則投影到工作人員的功能和結構上開始。產生的多重工作人員結構便是核心系統設計和系統結構原則的表達,並與 AI 技術的獨特「粒紋」保持一致。

驅動此結構的關鍵原則包括:

• 透過拆分管理複雜性
• 透過分離提升彈性並減少脆弱性
• 透過程式碼重複使用改善可靠性和效率
• 透過限制任何一個工作人員的關注範圍來提升工作人員的可靠性
• 透過模組化和擴充性改善系統維護和進化
• 透過專長簡化工作人員管理與當責

不同於更原始的工作人員結構 (例如,專注於以 LLM 作為核心結構建構的結構),Agentforce 從一開始就針對多工作人員協調流程而設計。多工作人員協調流程以 Atlas Reasoning 引擎和代理程式推理為基礎,可在代理程式回應內建立動態且有效的程式設計路徑,以大幅擴大為使用者體驗 (UX) 提供廣泛且深度代理程式擴充的能力。

在 Agentforce 中,這些金鑰開放、可互通的通訊協定和 Salesforce 產品可啟用此類型的協調:

• Agentforce 提供「工作人員」子系統,可壓縮工作人員的所有關鍵元素:主題、指示、動作、護欄、內容、叫用、輸出、執行詳細資料、記錄等。
• 動作:提供存取資料、通話流程、叫用外部系統和呼叫其他工作人員的勾點。
• Data 360:提供資料虛擬化層,以將特定、個人化內容帶給工作人員 (利用 Data 360 的統一設定檔和金鑰鏈,從整個企業中提取特定資訊)。

針對跨企業的工作人員,或存取工作人員或資源,我們支援:

• 模型內容通訊協定 (MCP): 是安全通訊層,可將工作人員與企業工具、資料和 Knowledge 連線,以確保內容準確性。
• 工作人員對工作人員 (A2A) 通訊協定:是一種標準化工作人員之間委派的協定,可在系統、組織和廠商之間啟用安全且受管理的協調。

這些原則提供建立可調整、可管理協調式情報系統的基礎。

強大的代理解決方案需要對非功能需求的明確方法,以實現有效的技術傳遞:

• 安全性與管治 (身分與存取管理、資料隱私權、資料安全性和威脅建模)。
• 可觀察性和監視 (散佈式追蹤、集中化記錄、度量和顯示面板)。
• 作業與生命週期管理 (規格、測試個案產生、測試、回饋意見、持續學習、淘汰)。

這些是建立「企業代理程式」解決方案的關鍵結構考量事項,並未涵蓋在此白皮書中;不過,這些考量事項將會在未來的發佈中處理。

若要管理企業範圍內的工作人員環境,結構設計師必須透過兩個互補的透鏡來分類工作人員:技術功能與業務影響。

此分類會分類工作人員在結構內可能採用的功能角色。

• Channel/UX 角色:定義互動模式 (例如「無周邊」、「提示」、「聊天與訊息」或「AI 受管理工作區」)。
• 專家角色:壓縮深度網域 Knowledge (例如,網域專家、Knowledge 主管、助理或計畫者)。
• 公用程式服務角色:執行離散的交易工作 (例如產生、摘要、轉換或組態)。
• 維護與主動服務角色:專注於資料健康與品質 (例如精密設計、合規性、資料品質或資料豐富)。
• 長時間執行角色:管理一段時間內的流程 (例如服務台、專案經理、護理人員或監視者/警示員)。

為了協助清楚設計和溝通,「工作人員地圖」 是描述工作人員解決方案的標準範本。它會定義特定設計模式內的關鍵實體、系統和互動。

以下是工作人員地圖範本元件:

• 使用者層級定義系統中的人力執行動作的使用者 (例如客戶、已驗證員工 (SF-Users) 和未經驗證員工)。
• 工作人員層級描述必要的工作人員、顯示的模式、彼此之間的關係,以及用於實現特定模式的指示。
• 內容/動作是工作人員管理或存取的資源、功能或動作。
• 來源是工作人員連線的基礎資料、應用程式、Knowledge 庫和其他系統。

附錄 A 和 B 會在「工作人員地圖範本」中示範其組成,以說明系統層級的工作人員模式。

在 Salesforce,我們使用工作人員模式的文件庫來組織並提供可靠且可預測的工作人員解決方案。這些模式是解決常見結構問題的藍圖。

它們分為四個主要種類:

• 互動模式:專注於工作人員參與和使用者體驗 (UX)。
• 專家/工作人員模式:壓縮特定網域內的深度 Knowledge 或特定技能。
• 公用事業與資料管理模式:執行支援其他工作人員或流程的特定且經常可重複的工作。
• 長時間執行模式:管理在延長期間內發生的流程和工作流程,包含多個步驟。

下列區段詳細說明每個種類的主要模式。每個模式描述皆提供「概觀」、「輸出類型」、「模式使用指南」、「代表使用個案」和「解決方案圖表」,以及對應至「Salesforce 工作人員成熟度標題」。

互動模式是重點在工作人員參與和使用者體驗的基礎��計。

• 概觀:Greeter 模式是一種簡單且易於實作的模式,使用自然語言來決定使用者的意圖。接著會將使用者路由至適當的人工工作人員。

• 輸出類型:轉移/升級至下一個資源。

• 業務價值:協助客戶順暢且有效率地開始連絡,同時為服務提供者最大化意圖解析和內容收集。

• 模式使用指南:將工作人員設定為品牌管道的主要參與資源。根據使用者意圖提供與路由指示配對的品牌、產品和服務指示。工作人員會收集並摘要提供熱門轉送的意圖。

• 代表使用個案:想像一下使用聊天機器人來呈現選項功能表的網頁,使用者必須先按一下所有選項,才能路由至人類。為了改善後端辦公室的生產力與效率,聊天機器人通常會使用複雜且複雜的工作路徑與互動。這會導致客戶的「填入、選擇和按一下」疲勞情境,如果客戶的內容位於可用功能表選項之外,這通常會導致挫折。將傳統聊天機器人取代為使用自然語言互動的 Agent Front Door,可減輕負擔並提供類似人類的互動。

• Agentforce 配方:

  • Agentforce 服務代理:建立服務代理程式
    • 封裝的服務代理有支援轉移的可設定的轉移功能:
      • 人力工作人員
      • AI 工作人員
      • 外部工作人員
  • 包含程式碼範例的產業特定模式

• 圖表:

• Salesforce 工作人員成熟度:層級 1 (或層級 0 (如果您使用具有內建轉移和升級的立即可用服務代理程式)

• 概觀:運算子模式會透過將要求路由至適當的專家工作人員或人類,並在需要時進行協商,以建立在 Greeter 模式上。

• 輸出類型:轉移/轉移至下一個資源。

• 模式使用指南:將品牌和服務特定指示與根據意圖傳送使用者的位置指示配對。定義升級資源,可能是人類或其他工作人員。

• 代表使用個案:針對人類或 AI 代表高度專長的案例,使用「工作人員前門」。

• 圖表:

• Salesforce 工作人員成熟度:層級 2

• 概觀:Orchestrator 模式會管理 AI 工作人員「群集」。接收使用者要求時,會將說話方式傳遞給一或多個專家工作人員,然後彙總使用者的回應。不同於「運算子」模式,其仍是第一個接觸點 (POC)。

• 輸出類型:整理並準備來自工作人員的工作回應。

• 模式使用指南:設定為主要參與者。為每個支援工作人員工作人員 (例如,優先順序者或網域 SME) 提供指示,讓協調員能夠將說話方式轉送給他們。

• 代表使用個案:使用「協調流程模式」作為工作人員的前門,協助可能需要在每個對話中討論多個主題的客戶,這需要多位工作人員的解決方案和一致的互動。在多系統結構中,請考量「*協調流程模式」,*以協調跨系統的回應,並透過外部工作人員的協同合作。

• 圖表:

• Salesforce 工作人員成熟度:層級 3

• 概觀:聆聽者/摘要模式會在交談流程期間呈現內容與洞察。聆聽者會在每次交談輪數期間觸發,以尋找並顯示員工的相關資訊。

• 輸出類型:根據對話提供相關內容,其可進行格式化以取得效果 (例如,進行比較或醒目提示關鍵點)。

• 模式使用指南:將「接聽者」附加至以輪數為基礎的管道 (例如聊天、語音或 SMS)。定義每個主題區域的主題。工作人員會耗用文字記錄、識別主題,並叫用動作以搜尋並將相關內容張貼至員工的執行摘要。

• 代表使用個案:使用 Universal Assistant 協助「客戶服務」或「銷售代表」。

• 圖表:

• Salesforce 工作人員成熟度:層級 3

• 概觀:工作區 (Radar O’Reilly) 模式會在交談流程中管理回應式單一玻璃 UX。其會處理每種說話方式,以使用相關內容更新 UX 的部分。

• 輸出類型:提供位於大單一玻璃窗檢視內 Portlet 中的相關內容。

• 模式使用指南:協調流程工作人員會將說話方式傳遞給一套「*主題」*工作人員。每個「主題」工作人員都會評估陳述式,以判定是否需要 UX 更新。如果是,則會將動態更新推送至對應的 LWC。

• 代表使用個案:此功能類似進階工作人員門。

• 圖表:

• Salesforce 工作人員成熟度:層級 3

專家模式會壓縮特定領域中的深度 Knowledge 或技能,且通常由 互動模式協調。

• 概觀:Answerbot 模式是自助式服務的有效模式,使用 GenAI 來判斷自然語言以供 Knowledge 提取,而不只是關鍵字。

• 輸出類型:對支援資料的摘要 Knowledge 與參照/引號。

• 模式使用指南:組織並取用可靠的來源資料 (例如 Knowledge 存放區或常見問題) 來設定工作人員。在公司網站或內部入口網頁中放置工作人員。監視問題以識別和處理 Knowledge 缺口。

• 代表使用個案:在公司網站上協助自然語言搜尋、與 HR 優惠機器人互動,並為所有部門成員提供自助式元件。

• 圖表:

• Salesforce 工作人員成熟度:層級 1

• 概觀:網域 SME 模式是一種基礎模式,可為業務領域 (例如「訂單」或「索賠」) 提供自然語言前端。

• 輸出類型:提供與網域相關的內容、主題、資料和格式資訊。

• 模式使用指南:使用此模式壓縮主題或業務網域。設定具有執行適當 CRUD 作業能力的工作人員。透過「互動」模式提供這些工作人員 (例如 - 協調流程或聆聽者)。

• 代表使用個案:保留業務資料網域、提供「訂單工作人員」或「庫存工作人員」,以及為業務網域提供代理介面。

• 圖表:

• Salesforce 工作人員成熟度:層級 2

• 概觀:查詢者模式是 SME 工作人員,可針對主題進行查詢,以組合來自多個來源的內容以回答問題。利用的關鍵工作人員功能是透過人類在閱讀和內建內容後所使用的方式,在內容內文中提取內容並連線概念的能力。此模式可減輕「捲動椅整合」的需求。

• 輸出類型:提供問題的回答。

• 模式使用指南:它通常設定為主控台小工具,連線至使用者的目前內容,讓他們可以直接提出問題。也會與 Knowledge 資源搭配使用,例如常見問題、原則和產品目錄。將「查詢器」模式與標準提示配對,以將常見的回答調整為常見問題。

• 代表使用個案:作為契約助理工作人員使用;受益查詢助理或多工作人員模式 (例如「接聽者」或「工作區」) 的專家工作人員工作人員。

• 圖表:

• Salesforce 工作人員成熟度:層級 2

• 概觀:優先順序規格模式用於根據定義的目標排序一組工作或工作物件。其利用 GenAI 進行質性分析、非結構化資料分析或跨多個資料網域的整合分析。

• 輸出類型:提供生成洞察。

• 模式使用指南:使用自然語言描述排定優先順序所需的品質。使用一組可選取的選項將工作人員奠基。與「聆聽者」模式結合,以在工作流程中建立回應式「Next Best Action」。

• 代表使用個案:作為長時間執行或多工作人員模式中的 Next Best Action 產生器或專門工作人員工作人員使用。

• 圖表:

• Salesforce 工作人員成熟度:層級 2

公用程式模式會執行支援其他工作人員或流程的特定可重複工作。

• 概觀:產生器模式是從現有輸入和標準建立新內容 (例如個案摘要或電子郵件草稿) 的基本模式。它通常會作為提示進行實作,並可能內嵌在其他工作人員內。

• 輸出類型:提供符合要求格式和意圖的產生內容。

• 模式使用指南:產生器模式可在大多數其他模式內或作為獨立模式使用。內容可透過要求、執行期間的加水或其他增強步驟提供。

• 代表使用個案:提供個案摘要、電子郵件草稿、Knowledge 文章或 QBR 的建議/回應。

• 圖表:

• Salesforce 工作人員成熟度:層級 1

• 概觀:資料管理員模式是自發的背景模式,會將工作人員步驟導入資料作業,以確保一致的資料品質、合規性和增強。

• 輸出類型:儲存前提供更新的記錄和資料欄位。

• 模式使用指南:透過在儲存資料前新增記錄觸發流程的資料管理員,以在建立資料時內嵌資料品質。協助確保一致地套用分類、摘要和州/省資料。

• 代表使用個案:確保一致的「披薩追蹤器」樣式更新、豐富帳戶資料,並消除不相符的郵遞區號和地址。

• 圖表:

• Salesforce 工作人員成熟度:層級 2

• 概觀:Zen Data Gardener 模式是一種已排程的背景模式,用於整理和標準化資料,利用低成本的推理來驗證、增強和對應其他未連線資料網域的資料。

• 輸出類型:提供更新的記錄和/或資料管理工作。

• 模式使用指南:使用模式來啟用定期的資料檢閱和驗證。針對變慢的資料,請以緩慢的步調排程工作人員 (例如,每月)。與 資料管理員模式結合,以提供潛在和追溯的資料品質作業。

• 代表使用個案:確保已銷售的福利與索賠系統之間的對齊方式,以及根據國家登錄定期驗證經紀人授權。

• 圖表:

• Salesforce 工作人員成熟度:層級 4

• 概觀:Configurer 模式會從自然語言需求產生組態成品 (例如 SQL/SOQL、JSON 和 CSV)。也可以反向執行,以根據需求驗證現有組態。

• 輸出類型:提供更新的記錄、資料管理工作,或建立問題/錯誤以進行修正。

• 模式使用指南:使用特定標準、原則或範例將工作人員奠基。使用如契約或產品規格等來源來設定建立需求。將 Configurer 模式連線至目標系統以推送產生的組態。

• 代表使用個案:產生健康保險產品的產品組態記錄,並驗證健康提供者的契約/付款條款。

• 圖表:

• Salesforce 工作人員成熟度:層級 4

• 概觀:法官與陪審員模式的設計目的為使用「陪審員」工作人員集合,以及評估回應的一致性,以確保回應在實質上一致且有基礎。

  • *「組合方式」*內嵌在 Agentforce 和 Atlas Reasoning 引擎中,以解決回應的真實性和相關性。當高準確度至關重要時,評判與評審模式會建立此功能。
  • 資料奠基 (例如「在這些記錄/文件中尋找您的答案」) 和 提示工程 (例如「只有在這些記錄中找到答案時才傳回」或「根據此外部來源驗證您的答案」) 是最小化幻覺的有效方法。

• 輸出類型:提供生成洞察。

• 模式使用指南:強烈需要一致且奠基的生成性輸出時使用。法官工作人員會編譯基礎提示,並將其傳遞給兩個以上的 陪審工作人員,然後法官會評估回應。為獲得最佳結果,請針對每個「Juror」工作人員使用不同的模型 (例如,一個來自 OpenAI,另一個來自 Anthropic)。

• 代表使用個案:提供高度忠實且以實情為基礎的回應,以儘量減少幻覺。

• 圖表:

• Salesforce 工作人員成熟度:層級 2

• 概觀:模型模式模式利用多個專家工作人員來產生廣泛的觀點,然後便會取得共識。不同於 Judge 與 Jury 模式,此模式包含多個觀點以增強豐富性。

  • 當具有不同檢視點 (POV) 的專家模型時,此模式也稱為「專家面板」模式,且點選時會很有幫助。
  • 不同於「判斷者和陪審員」模式,其意圖是確保工作人員回應在常見的「事實」上融合,模型模式模式透過利用工作人員環境中的多元性來擴大回應的範圍。
  • 此模式假設有其他工作人員具有不同的 POV。例如,在多組織、多工��人員環境或跨技術堆疊具有多個廠商提供工作人員的環境中,模型模式模式提供整合多個 POV 的結構。
  • 考慮此模式時,也請考慮其他通常較輕量型方法:
    • 請指定多個提示,讓系統運作為提示集合,而不是定義多個專家工作人員。
    • 透過存取內容上適當資料的動作來利用「奠基」。

• 輸出類型:提供生成洞察。

• 模式使用指南:彙總器工作人員的角色是根據模型工作人員傳回的重要概念,建立並傳回豐富的 POV。「模型工作人員」會根據其唯一的 POV 決定回應。

• 代表使用個案:在可能受益於合併不同觀點以增加回應品質的情況下使用。 例如,多系統代理程式環境,其中特權工作人員 (例如,ERP 工作人員) 可能具有有價值且無法存取的 POV。

• 圖表:

• Salesforce 工作人員成熟度:層級 2

長時間執行流程模式可管理在長時間內發生的流程,且涉及多個步驟和執行動作的使用者。

• 概觀:Project Manager 模式是監督長期執行專案的複雜模式。它會協調活動、追蹤完成狀況、通知使用者,並向利害關係人呈現專案狀態。

• 輸出類型:有多個輸出 (例如個案、工作、狀態更新和通知)。

• 模式使用指南:作為傘模式來支援定期、重複的多步驟活動。Project Manager 模式會取得專案的輸入範本/大綱 (包括工作、角色和相依性),然後例項化個案和活動,並將其指派給使用者。

• 代表使用個案:用於帳戶安裝管理和企業銷售參與。

• 圖表:

• Salesforce 工作人員成熟度:層級 4

模式描述工作人員的角色,而 協調結構類型會定義工作人員車隊協同合作方式的系統層級藍圖。這些原型可說明 Agentforce 作為協調流程腦的角色,以及 MuleSoft 作為通用連接器與轉接器的角色。

結構類型 1 (單一組織、多位工作人員)

• 定義:多個工作人員可在使用共用管理與資料的 Salesforce 組織內進行協同合作。
• 結構流程:在 Agentforce 中,上司工作人員會作為單一前門,將要求路由至組織內的 專家工作人員。針對外部功能,工作人員使用具有 MuleSoft 的 Agentforce MCP Client 作為非 MCP 啟用 API 的 MCP 包裝程式。
• 重要考量事項:此模式會在 Salesforce 中集中協調流程邏輯 (類似於 CRM 內容和 Data 360),以保留統一的管治、身分、權限和可觀察性。

結構類型 2 (多組織、多位工作人員)

• 定義:工作人員可跨多個 Salesforce 組織協同合作,這需要跨資料與權限界限安全協調。
• 結構流程:一個組織中的「*上司工作人員」*透過標準化 工作人員對工作人員 (A2A) 通訊協定,將工作委派給另一個組織中的工作人員。此接觸可確保組織層級 Trust、使用者身分驗證流程和共用對話內容。
• 重要考量事項:此模式可保留組織自主性,同時啟用企業範圍的工作流程,為複雜的多組織主體中一致的工作提供基礎。

序列類型 3:多廠商 A2A (Salesforce 主導的協調流程)

• 定義 中的「*上司工作人員」*會透過 A2A 通訊協定,協調 Salesforce 原生工作人員與來自其他廠商 (例如 Google/Vertex 或 LangGraph) 的工作。
• 結構流程:上司工作人員會處理要求並協調計畫,透過 A2A 通訊協定叫用內部和外部廠商工作人員。針對不適用於 A2A 的外部系統,MuleSoft 可以公開「輕量型工作人員面向」,其會包覆現有工具並與 A2A 通訊。
• 重要考量事項:此階層類型透過使用 A2A 來產生清潔且可管理的組成,無需個別的協調流程層級,讓協調流程大腦保持靠近 CRM 和 Data 360。

序列類型 4:多廠商 A2A (MuleSoft 導向的協調流程)

• 定義:協調流程是從非 Salesforce 進入點起始,這需要中立外部協調流程者來執行推理和路由。
• 結構流程:外部系統中的 UI 工作人員會將要求轉送至協調流程服務 (概念化為 MuleSoft Conductor),該服務會解讀意圖並規劃工作。接著,司機會使用 A2A 將通話路由至廠商工作人員,包括適用於 CRM 或服務動作的 Agentforce 工作人員。
• 重要考量事項:此模式適用於在結構上偏好中立協調流程的非 Salesforce 進入點。它會將 UX 保持在網域系統中,同時將推理、管治、原則和可觀察性集中在 MuleSoft 中。

這些個別模式和協調流程結構類型是設計為可組成端對端解決方案的結構建構區塊。「工作人員解決方案地圖」用於視覺化這些元件如何連接。

• 適用於醫療照護提供者的「成員服務解決方案」 是 SOMA 結構類型的標準實作。其使用適用於匿名使用者的 Answerbot、已驗證成員的 Orchestrator,以及多個 網域 SME 工作人員 (例如「個案」、「索賠」和「福利」) 來處理特定要求。
• B2C 經紀人入口網頁是一種複雜的組成,使用入口網頁 協調流程工作人員為 RFP 流程叫用長時間執行的 專案管理員工作人員,進而使用 無周邊、資料管理員和 詢問者工作人員進行後端辦公室資料作業。

工作人員設計模式方法提供建立強大、可調整且可維護的企業 AI 系統所需的結構規律。透過細分複雜性並促進模組化,這些模式可讓結構設計師提供可靠且可預測的工作人員解決方案。

協調流程結構類型的選擇是根據使用者工作的位置、內容所在位置,以及企業如何管理人類、工作人員和系統之間的互動而做的策略性決定。透過瞭解建立工作人員之間的區別並協調工作人員,以及利用如 MCP 和 A2A 等開放式通訊協定,結構設計師可以從建立獨立機器人以外,改為設計一個凝聚式、受管理且分散式的企業推理系統。此方法提供共用語言和一組可重複使用的藍圖,以建立永續的代理架構。

此附錄提供工作人員模式如何組成為系統層級解決方案的具體範例。

此圖說明如何將五個基本模式連接在一起,以建立常見的客戶服務工作流程。

1. Answerbot:匿名使用者提出問題,由 Knowledge 型工作人員處理。
2. 操作員:員工的問題由「運算子」分級,該運算子會欄位交談,並將其傳送給更專業的工作人員。
3. 協調流程:器已驗證的使用者 (SF 使用者) 會與協調器互動,協調多個工作人員以處理潛在的多面向查詢。
4. 網域 SME:專家工作人員 (例如「HR 工作人員」或「福利工作人員」) 會由協調流程器叫用,以執行主題事項更新並檢取特定資料。
5. 發電機:公用程式工作人員用於在互動完成後摘要帳戶詳細資料或總結個案。

此解決方案對應詳細說明「成員服務」使用個案的代理結構,示範多個模式的組成。

• 使用者設定檔:解決方案提供三種不同的使用者類型:匿名使用者、已驗證成員和 SF 使用者 (例如,人類 CSR)。
• 互動模式:Answerbot 會處理匿名「尋找文件」查詢,而 Orchestrator (工作人員前門) 會管理已驗證的使用者查詢。聆聽者/摘要模式可協助 SF 使用者。
• 網域工作人員重複使用:專用 網域 SME 工作人��� (例如「個案工作人員」、「索賠工作人員」或「福利工作人員」) 可在不同的互動流程中重複使用。
• 自動與輔助:系統結合了 獨立工作人員 (以導向使用者互動) 和 輔助工作人員 (以增加人體 CSR)。
• 資料來源:此結構整合了公用和企業資料來源的混合,並廣泛使用 Data 360 和 MuleSoft 來進行連線。

此圖說明「連絡中心」中「輔助 AI」解決方案的邏輯結構,並組織成功能層。

• 協調流程工作人員:管理不同角色 (例如匿名、外部成員或 CSR) 的使用者體驗,並協調整體互動流程。
• 工作人員:多個 SME 工作人員專注於核心業務領域,例如 Knowledge、個案/索賠/福利和提供者目錄。Next Best Action 工作人員也包含在內。
• 公用程式工作人員:執行特定可重複使用的工作,例如翻譯、個案總結和通話摘要。 整合與核心系統:整個代理程式系統透過跨平台整合層連線至非結構化資料資源、結構化資料資源和核心企業系統。
• 監管:監管層提供工作人員所使用 LLM/SLM 的可觀察性、評估和管理。

此解決方案對應詳細說明 B2B 健康保險經紀人入口網頁的複雜且長期執行中工作人員互動。此模型包含一個 入口網頁代理程式 (協調程式),可協助經紀人完成多個步驟的旅程 (例如提交 RFP 並接收提案)。此協調流程會叫用一個 專案管理員工作人員,該工作人員接著會針對後端辦公室資料品質和轉換協調數個無周邊工作人員,例如 RFP Extractor、普查轉換和資料管理員。

此圖表顯示 B2C Broker 解決方案的邏輯結構,其示範與「連絡中心」類似的分層方法。其中包含不同使用者角色的 協調流程工作人員、可重複使用的關鍵網域 (例如 Knowledge、成員服務或佣金) 的 Worker 工作人員,以及翻譯和摘要等特定功能的 公用程式工作人員。

此圖顯示「提供者契約」解決方案的邏輯結構。協調流程工作人員管理完整的互動、工作人員在網域內管理特定的意圖 (例如,承包中 SME 工作人員),以及 公用事業工作人員執行離散的工作,例如比較契約或產生洞察。

下表摘要列出數個關鍵互動模式、一般使用者體驗和主要結構目的。

David Harshbarger 是一位成功的企業家和技術領導者,曾為許多領先的軟體公司工作,為架構解決方案,使架構的粒子與業務的粒子保持一致,讓技術人員使用,而不是反對,其啟用技術。現在,David 是 Salesforce 的首席企業結構設計師,支援「健康與生命科學」。

Chacha Choudhury 是一位績效優良且富有願景的 IT CTO/首席結構設計師,擁有數十年經驗,目前擔任領導 Salesforce 結構設計計畫和全球結構設計師社群的首席企業結構設計師。他因在設定企業範圍技術策略、推動架構現代化,以及引領創新解決方案 (包括生成式 AI 和代理人 AI 應用程式) 方面的專業知識而獲得認可。