在不斷發展的多工作人員環境中,指派特定細微工作時,工作人員最有效。這需要多元化的可重複使用的專門工作人員網路。然而,核心挑戰是協調這些來自各種來源的眾多異質工作人員,以有效地針對共同業務目標協同合作。若沒有統一的平台,此複雜性會導致工作人員分散,並導致嚴重缺乏管治。

這些 AI 工作人員正在快速增長、內嵌在 SaaS 平台、內部開發或封裝受歡迎的 LLM。此乘法會導致中斷連線的組織孤島。雖然工作人員可最佳化其原生應用程式中的工作,但通常缺乏整體的企業檢視。此缺少可視性會讓工作人員無法有效協調、保護和管理不同網域和系統的動作。

MuleSoft Agent Fabric 應對管理「工作人員擴展」並啟用各種工作人員的流暢協調流程的挑戰,無論其來源為何。其會建立結構最佳作法,並提供建立「工作人員網路」所需的工具。「工作人員網路」是指 AI 工作人員、工具和資源的協調集合,其可共同執行複雜的多步驟��務流程。

MuleSoft Agent Fabric 是一個統一平台,可讓每個企業輕鬆探索、協調、管理和觀察任何工作人員,無論其建立的位置為何。

探索:「工作人員登錄」提供整個組織中所有 AI 工作人員與工具的集中型目錄。其可啟用內部建立、內嵌 SaaS 和外部資產的探索與重複使用。透過為所有工作人員資產提供單一事實來源,「工作人員登錄」可消除冗餘,並確保開發人員可以大規模利用現有功能。

**協調流程:**MuleSoft Agent Broker 是一種智慧路由解決方案,可動態將工作與最合適的工作人員或工具進行比對。由您選擇的 LLM 提供支援,其可協調工作人員和工具,以確保複雜的多步驟要求和業務流程以高度可靠性和可追蹤成果執行。

政府:MuleSoft Agent Governance 利用「Flex Gateway」及其對 模型內容通訊協定 (MCP) 和 Agent2Agent (A2A) 通訊協定的支援。透過 Flex Gateway,企業可以對每個工作人員-工作人員和工作人員-工具互動強制執行安全性和合規性原則。

觀察:「工作人員視覺化工具」透過動態互動式工作人員互動地圖提供即時可觀察性。它會追蹤決策、監視系統健康狀況,以便持續最佳化並可靠監視整個工作人員生態系統。

工作人員 Fabric 擁有規格優先 (YAML) 方法,使用者可透過中繼資料描述元 (「YAML 檔案」) 定義工作人員網路。此 YAML 檔案對 MuleSoft 不明確,且會將工作人員網路的定義與其執行分離。

每個工作人員網路 (YAML) 都會使用其代理資產定義特定功能區域,包括其作業規則與原則。YAML 用於啟用四個「工作人員紡織」支柱:

1. 探索:使用現有的「工作人員資產」填入「工作人員登錄」,例如:
   1. 跨各種平台部署的工作人員 (MuleSoft 或其他平台)
   2. MCP 伺服器
   3. LLM 提供者
2. 協調流程:建立協調工作人員經紀人
3. 控管:在資產上套用安全性與管治原則
4. 注意:定義並重複使用已定義資產的連線。此外,可觀察性和監視功能也可供工作人員網路使用。

使用者旅程會在 Anypoint Code Builder 中開始。使用名為「MuleSoft:「建立工作人員網路專案」以建立新專案。此指令會建立包含兩個檔案的新專案 (「工作人員網路」)。

• **agent-network.yaml:**此檔案定義多工作人員系統的組態,以透過外部工具 (透過 MCP) 與工作人員 (透過 A2A 通訊協定) 來協調 AI 工作人員。此格式提供用來定義工作人員功能、相依性和整合的陳述方式。

• **exchange.json:**所有工作人員網路專案也擁有 exchange.json 檔案。發佈工作人員網路資產後,此檔案包含 Anypoint Exchange 中可用的資產中繼資料。

您工作人員網路的開發遵循包含四個主要階段的標準軟體開發生命週期 (SDLC):

1. **環境設定:**設定執行階段環境與門戶
2. 專案建立與設計:建立工作人員網路專案規格
3. **建立與發佈:**建立並發佈資產至工作人員登錄
4. **部署:**將工作人員網路部署或升級至指定的環境

建立專案並產生所需的 MuleSoft 應用程式和資產後,請使其可在 Exchange 中使用。在 Anypoint 程式碼產生器中,使用 “MuleSoft:可透過指令調色盤使用「發佈工作人員經紀人專案至換貨」 指令。

發佈步驟會將 YAML 檔案中的每個工作人員資產轉換為 A2A、MCP 或 LLM 規格,並將其發佈至 Exchange。

此外,系統會使用新的工作人員網路資產類型,將 YAML 發佈至 Exchange。您可以在「工作人員登錄使用者介面」中檢視此資產,並透過 Exchange API 進行搜尋。

請參閱為企業定義工作人員網路的「工作人員網路」檔案。此工作人員網路會啟用在 Salesforce、Stripe 之間的訂單履行網路,以及另一個訂單履行工作人員和庫存 MCP 伺服器,並透過單一保單管理的體驗。

• 探索
  將現有工作人員和工具 (例如 Salesforce、Stripe、訂單履行和庫存) 發佈為 Exchange 資產以供重複使用。此外還有一個版本化且可共用的訂單履行定義 (YAML),可針對角色、區域或子公司快速調整,而無須重新建立流程。
• 協調流程
  工作人員經紀人使用 LLM 將訂單履行流程拆分成一系列工作,例如驗證客戶詳細資料、配置庫存和計算運費。接著透過呼叫 MCP 和 A2A 工作人員來執行此工作流程,以確保在需要時要求人類即時批准。
• 政府
  Anypoint Flex Gateway 會強制執行驗證、最低權限存取權和護欄。API 管理員原則可確保在所有通話和資料交換之間的一致控制。
• 觀察
  監視和追蹤可讓您端對端瞭解進度、失敗和延遲。視覺效果會顯示哪些工作人員互動,以及發生瓶頸的位置。
• 信任與合規性
  集中認證、稽核追蹤和原則繼承支援安全性、隱私權和法規需求 (PII 處理、批准和職責分隔)。

此圖顯示在 YAML 中定義之工作人員網路 (中繼資料) 的不同節點。

• 目的:換貨是工作人員、工具和其他資產的目錄。其主要目標是透過提供單一、受管理的目錄,以探索、精密設計和管理異質工作人員的生命週期來解決「工作人員擴展」。其可讓開發人員尋找並重複使用工作人員、平台擁有者維持可視性,並讓協調流程者探索功能。
• 依設計不同 Exchange 現在支援三個新資產:工作人員、MCP 和 LLM。Exchange 設計為通用型目錄,可註冊和管理任何類型的工作人員。其支援來自任何來源 (包括第三方、Agentforce 和自訂 MuleSoft 代理程式) 的 A2A 相容工作人員、MCP 伺服器和 LLM 提供者。
• 核心中繼資料:每個註冊的資產都有固定的中繼資料基準集,包括「唯一名稱和版本」、「擁有權」和「發行者」。也會追蹤生命週期狀態 (開發、暫存、生產、已淘汰)。
• 探索:
  • 設計時間:開發人員可以透過現有 Exchange UI 或使用 Anypoint 程式碼產生器中的 Vibes 進行自然語言搜尋來探索註冊的工作人員。
• 標記與分類:您可以使用基本金鑰值標記系統,依類型 (工作人員、MCP、LLM、經紀人) 和網域 (例如 HR、天氣) 分類資產,以啟用動態連結、搜尋和選擇原則。
• 目錄:儲存庫支援在組織內共用工作人員的私人與內部目錄模型。
• 視覺效果:提供視覺工具來支援網路檢視,顯示單一資產的連線或整個組織中節點和連結的整個地圖,以及篩選功能。

工作人員網路中的經紀人可以參照儲存在 Anypoint Exchange 中的已註冊工作人員、MCP 伺服器和 LLM 提供者。但如果尚未註冊,則可在「工作人員網路」(YAML) 的中繼資料中宣告,並自動註冊。在此範例中,有多個工作人員、MCP 伺服器和 LLM 提供者會在 Anypoint Exchange 中宣告和註冊。

工作人員經紀人是智慧路由工作人員,可協調跨企業專門工作人員的工作委派。其由其用來完成工作的工作人員和 MCP 伺服器所定義。

經紀人是專門的工作人員,在發佈工作人員網路資產並由其他經紀人重複使用後顯示在 Anypoint Exchange 中。

經紀人是在 YAML 的 _經紀人_區段中定義的。定義的經紀人會以透明的方式「編譯」至應用程式,而不需要任何先前的 Mule Knowledge。此產生的應用程式會部署至 CloudHub 2.0 (CH2),並利用強大的 CH2 基礎結構。

這表示「工作人員經紀人」受益於 CloudHub 2.0 的已建立效能特性,包括其記錄和度量功能。作業層面,例如「營運成本」和「監視/警示/工具」,與任何其他工作量相同。

針對需要人力介入 (循環中的人) 的案例,系統會使用 MuleSoft 物件存放區來維護每個互動的狀態,此分散式解決方案專為在高度同時環境中有效管理狀態而設計。

經紀人定義由兩個區段組成:卡片與規格。

卡片區段遵循「工作人員對工作人員 (A2A)」規格。其中包括描述經紀工作人員的契約、技能和能力。卡片 URL 會自動填入值 ${ingressgw.url}/broker-name。部署時,${ingressgw.url} 預留位置會自動取代為前置工作人員進入要求的 Anypoint Flex Gateway url。

規格區段會設定經紀人的「來源程式碼」。在此,開發人員可以指定要使用的 LLM、指示、可用的工具、錯誤處理,以及最重要的是,可供此經紀人使用的各種工作人員和 MCP 工具。

LLM 提供者

此區段是每個經紀人的規格的一部分。這是服務區段中定義的其中一個 LLM 參照。我們可以選擇是否要在所有經紀人之間共用一個 LLM,或視需要讓不同的經紀人使用更適合其工作的 LLM。

經紀人可以指向 LLM 提供者。我們可以根據需求選擇這些提供者的模型。

指示

此區段是選擇性的,您可以用來指定此經紀人工作人員特有的指示。這些指示通常專注於特定業務導向的疑慮。例如,想像一下客戶服務代理來協調客戶報告事件的管理:

請注意,不需要提供明確的指示,例如**「將提示分割為工作」或「選取最佳工具」**,因為經紀人會自行處理。這些指示僅在描述特定業務流程時才需要。

工具組態

工具可提供工作人員外部功能。只要經紀人需要存取外部系統 (不是其他工作人員,例如現有 API 或 SaaS 服務),便會連絡 MCP (模型內容通訊協定) 伺服器:

MCP 伺服器會以交換資產的名稱參照。其連線詳細資料可在服務區段中指定。

依預設,經紀人可存取 MCP 伺服器中所有可用的工具。根據我們的觀察,最新的 LLM 只能處理每個內容的約 20 - 25 個工具,然後才能開始產生不準確情況 (或遺失內容)。因此,將可用的工具限制在所需的最低值通常是最佳作法。您可以透過允許的清單套用該篩選條件。

工作人員連結

此區段是整個定義中最重要的部分。連結區段可啟用工作人員之間的通訊和協調流程。這表示此經紀人依賴在此處連結的工作人員來執行適當的動作以完成使用者的目標。

實際上,此區段定義協同合作的工作人員-網路。

「工作人員管理」是「工作人員紡織」的重要支柱,是建立信任工作人員網路並確保安全性和合規性的基礎。

針對管治,您的私人空間中總共需要兩個「Flex Gateways」(1 個進入和 1 個出口)。

監管會建立必要的結構、控制項與證據,以安全地調整整個工作人員開發週期 (ADLC) 的規模。具體而言,管治會實作重要流程,例如工作人員認證、目錄、生命週期決策和執行階段原則的強制執行。

• 目錄:
  • 更換:支援記錄工作人員目的、擁有者、環境,以及資料與分類邊界。它也會向版本註冊功能、工具、資源、提示和外部相依性。
• 版本化與生命週期:
  • 在完成「工作人員開發生命週期」期間,記錄並管理工作人員、工具和資產的語意版本化。
  • 版本化有助於管理工作人員淘汰時間表,並支援雙重執行 (若可能),以確保順利移轉。
• 保單強制執行:
  • 工作人員 AI 結構會擴大攻擊的表面 (對話介面、提示和如 MCP 等新通訊協定)。對任何元件的任何入侵都可能會導致多個提供如通訊協定、提示、API 或工具等元件的系統產生串聯式影響。
  • 保護企業代理 AI 部署的安全性需要專門的方法,因為這些獨立且無法預測的環境本身會透過工作人員對工作人員的互動擴大攻擊範圍。儘管靜態系統的現有安全性工具十分重要,但它們本身已不再足夠。企業必須主動規劃和實作四個特定安全性解決方案,每個解決方案都會直接處理與工作人員 AI 相關聯的關鍵業務風險。
  • Flex Gateway:所有 A2A 和 MCP 流量都會透過「Flex Gateway」進行路由,即使目標系統未受到保護,以確保原則會套用至每個端點。此路由對於保護工作人員通訊的安全性和與授權伺服器的整合而言至關重要。
  • 原則搭售方案:使用者可以在執行之前定義預先定義原則的配套,並將其套用至工作流程,強制執行一組一致的安全性和作業原則。
  • 保單類型:平台支援各種輸入與輸出原則,包括:
    • A2A 原則:工作人員卡、PII 偵測器、提示裝飾者、結構描述驗證。
    • MCP 原則:以屬性為基礎的存取控制、結構描述驗證、MCP 支援。
    • LLM/AI 原則 提示裝飾器、AI 提示保護器 (篩選有害內容)、AI 提示範本 (套用預先定義的範本)、AI 基本權杖比率限制。
    • 遠端測試原則 和 MCP 遠端測試,可擴充記錄資料收集和匯出的「開放式遠端測試」解決方案。
• 記錄:由於自動追蹤,工作人員網路的記錄可追蹤每個工作人員互動,說明行為並建立 Trust。

此範例描述訊息記錄的原則,此原則是使用工作人員網路中繼資料設定的。Orderfullfillment 經紀人是指稱為 Salesforce 工作人員的現有工作人員,且傳訊的原則是使用中繼資料來進行設定。請注意,工作人員 Fabric 會自動設定在「Flex Gateway」上「規格」區段下提及的所有原則。您不需要額外的步驟。

由於 LLM 工作人員與多重工作人員部署的非決定性性質與複雜性,因此可觀察性和監視十分重要。

• 基本記錄與追蹤:透過記錄提供原因與工具執行追蹤。工作流程執行的記錄和追蹤可在執行階段管理員中檢視執行後。
• 度量:在初始階段中,平台會發佈 a2a_total_calls 和 mcp_total_calls 作為具有標籤 (例如路徑、狀態、方法、工具) 的計數器,以判斷通話總數、成功和失敗。這些度量會使用「傳送者」(Flex Gateway) 的原生統計資料介面,最好透過現有原則 (例如 mcp_support_policy 和 a2a_agent_card_policy) 來從原則程式碼發佈。
• 增強型可觀察性 (未來):計畫包括在未來版本中使用「開放式遠端測量」來散佈追蹤。更進階的可觀察性包括:
  • 詳細要求追蹤:取得對要求的端對端可視性、包含提示、計畫者流程、叫用動作,以及與子工作人員的互動。
  • 工作人員健康監視:監視工作人員執行時間、回應延遲、輸送量、錯誤率,以及基本資源利用率 (CPU、記憶體、網路、GPU)。
  • 多工作人員協調監視:偵測工作人員對工作人員互動的成功和失敗率、偵測循環叫用模式 (迴圈),以及追蹤工作人員的度量,例如工作完成和叫用計數。
  • 成本追蹤:透過顯示面板和警示追蹤每個 LLM 呼叫的權杖用量和相關聯的成本,最好是每個工作人員。
  • 認知追蹤:收集並顯示工作人員工作階段的詳細追蹤,包括內部思考流程和所有工具呼叫,作為固定的稽核追蹤。
  • 工作人員工作階段播放:此 UI 允許以視覺方式逐步「重新執行」工作人員的認知追蹤,以進行深入除錯。
  • DAG 視覺效果:針對複雜的多工作人員互動,提供工作人員工作流程執行的導向非循環圖 (DAG) 視覺效果。

「工作人員視覺化工具」用於識別工作人員網路的部分,並查看這些部分如何一起運作。

• 區分節點類型 (工作人員與 MCP 伺服器)。
• 檢視邊緣以查看已宣告與執行階段的互動。
• 使用圖層將檢視專注在特定環境上
• 開啟詳細資料卡以檢查節點的中繼資料和度量,以及存取記錄和追蹤
• 檢閱監管指標,例如「彈性門戶」保護和套用的原則。

在此找到有關「工作人員視覺化程式」元件的詳細資料。

透過這四個支柱,MuleSoft Agent Fabric 可將安全性和控制延伸至具有內建管治的任何工作人員。其可利用新的通訊協定 (例如 A2A (工作人員對工作人員) 和 MCP (模型內容通訊協定) 來建立和擴充業務流程,讓工作人員隨時隨地採取行動。我們會將所有項目 (應用程式、資料和系統) 連接在一起,以在工作人員在整個業務中執行動作時賦予其能力和管理。智慧工具透過原生使用 AI 或帶入第三方 AI 工具來支援業務流程或 API 的建立和擴充。

不需要同時使用全部四個支柱,但建議使用。您可以視需要獨立選擇支柱。例如,您可以利用「工作人員紡織」進行註冊與管治,而無須使用協調流程層。同樣地,您可以使用經紀人協調透過其他平台管理的工作人員。

此圖顯示這四個元件之間的互動方式:

1. 在 Anypoint 程式碼產生器中的工作人員網路 YAML 中定義工作人員網路 (經紀人、工作人員、MCP 伺服器) 後,將工作人員資產發佈至 Anypoint Exchange 以供探索和重複使用。
2. 將工作人員資產部署至 CloudHub 2.0 (在執行階段管理員中管理)。
3. 使用進入 Flex Gateway (位於經紀人和 API 端點前方) 對網路的傳入流量強制執行原則。
4. 使用輸出 Flex Gateway 強制執行原則、管理連線和發出遠端測量資料。這是從經紀人和工作人員到外部服務的輸出路徑。
5. 在 Anypoint Monitoring 中從「Flex Gateway」和執行階段收集記錄、度量和追蹤。

在平面且不受限制的結構中讓每個專門工作人員立即可供存取,並透過單一協調流程器來處理任何工作,藉此擁有每個可用 AI 資產的存取權。不過,此方法很快就會對整體系統的效率和可靠性產生負面影響。與套用至過多個別工具的原則一樣,許多工作人員選項對於中央經紀人工作人員 (或協調員) 帶來顯著的雜訊和複雜性。此增加的複雜性直接導致經紀人決策的準確度 (為工作選取正確的工作人員) 和系統回應的決定性 (類似查詢的可預測一致成果) 都明顯下降。經紀人工作人員有效地遭受了選項瘫痪,導致路由速度變慢且較不可靠。

我們強烈主張建立「工作人員網路」結構的多層階層方法,而不是平面結構。此組織原則提供許多重要優點。首先,其本身有利於可追蹤性和管理。階層結構會反映已建立的組織最佳作法,讓您更容易稽核要求的流程、透過找出失敗層來除錯問題,以及管理特定工作人員或子網路的部署和淘汰。

其次,在強化這些工作人員的大型語言模型 (LLM) 內容中,階層對於控制內容大小而言非常有幫助。透過區隔工作人員橫向,任何指定層級的經紀工作人員只會考量位於其下方的有限工作人員組或子經紀人。此結構可防止主要協調流程將 _每個工作人員_的描述、功能和歷程記錄內容載入其工作記憶體,從而避免快速超過 LLM 的內容視窗限制,並且導致成本和延遲。

工作人員網路可透過多種方式實作。其中有兩個:

1. Conway 的法則 - 對應至真實世界階層結構的直覺方式。
2. 網域驅動的設計 - 更專注於業務網域

選項 1:使用真實世界階層結構對應

在階層組織中,通訊流程會垂直 (從經理到下屬) 且決策通常會集中。根據 Conway 法:

• 此類組織建立的系統或軟體結構也會有層級與階層。
• 每個小組都會傾向於設計反映其自身邊界與權限的子系統。
• 系統之間的介面會反映部門之間的通訊管道。

工作人員網路也可以根據 Conway 法則,以直覺的方式對應到大型企業的真實世界階層結構。

• **概念模型:**正如同公司具有不同的分部、部門和管理層級 (例如,C 套件、VP、董事、經理),在特定領域內運作的工作人員網路可以建模為平行組織圖表。
• **節點與頁面:**在此階層中:
  • 樹狀結構的 葉子是 專家工作人員或 MCP。他們是執行實際工作的功能單位 (例如,「資料庫查詢工作人員」、「客戶驗證工作人員」、「情感分析工作人員」)。他們代表組織的個別參與者或工作單位。
  • 階層中的 所有其他節點 (包括根層和中間層) 是 經紀人代理程式 (或子協調流程)。這些工作人員不會執行最終工作,但負責其特定網域或層級內的路由、委派、彙總和衝突解決。高層級經紀人將工作委派給「銷售網域經紀人」,這會將工作委派給「機會管理經紀人」,這會透過「機會狀態更新工作人員」(表格) 執行工作。

此結構可確保在本機管理複雜性、包含內容,且系統可預測且可靠地調整規模。您可以將新的專科工作人員導入組織樹狀結構的特定適當分支。

請考慮數位人工的組織圖類似度。每個 YAML 檔案皆代表每個內部組織 (「員工成功」、「安全性」、「財務」等等)。在每個組織 (工作人員網路) 內,您可能擁有階層結構,工作人員可透過此結構協同合作、將工作分割成工作並指派。在上述圖表中,通訊流程從上到下。且假日並非僅限於一組經紀工作人員的耗用。

根據人體組織圖表建模工作人員網路,可能需要經常重新架構,特別是在經常進行重新組織的公司中。替代方法是依功能領域組織工作人員。此分組可能需要跨越傳統的人類組織界限。例如,新員工上線涉及硬體和使用者提供的 IT 作業,而銷售動作需要作業和行銷。

Nikhil Aggarwal 是 Salesforce 的主要結構設計師,負責 MuleSoft 和 Salesforce Automation Cloud 的結構設計。Nikhil 在提供大規模產品方面擁有超過 18 年的經驗,並對可調整結構、直覺式開發人員體驗和建立績效優良的小組有熱忱。在 Salesforce 之前,他曾在 Microsoft Power Platform、Dataverse 和 Office 365 中從概念到啟動領導多個計畫。他的工作持續構思現代企業在 AI 初期時代如何連線系統、自動化工作流程,以及發揮業務價值。

Mariano Gonzalez 於 2011 年開始加入 MuleSoft,專注於關鍵任務的分散式系統、整合、PaaS 和雲端運算。今天,Mariano 專注於推進 AI 平台,特別關注監管、協調流程、探索和可觀察性。Mariano 在 IT 產業工作超過 20 年,擔任軟體架構師和團隊領導者,在整個農業、能源、政府、IT、電信和內容管理行業中設計和提供 BPM、ERP 和整合解決方案。

Pedro Colunga 是 Salesforce 的軟體工程師結構設計師,專門處理 API 和中繼資料結構。專注於完整平台生命週期,Pedro 在定義組織如何與系統情報、語意和中繼資料驅動解決方案互動時扮演關鍵角色。Pedro 的 20 年職涯,其中包括企業經驗,涵蓋 Fuego、BEA Systems、Oracle 和 TekGenesis 等公司,此公司後來被 MuleSoft 收購,他一直在其中推動平台式架構,提供如 BPM、RAD 和整合等領域的深度專業知識。

Gulal Kumar 是 Salesforce 的「軟體工程結構設計師」,專注於資料與整合結構。他在整合和 API、現代化計畫、安全性和 AIML 計畫方面擁有超過 20 年的經驗,提供豐富的專業知識。Gulal 一直致力於推進業務轉型計畫、增強安全性和彈性、促進傑出結構,並領導跨各種網域的 AIML 計畫。