決定工作人員與傳統工作流程自動化
透過 Agentforce,企業現在可以為無法輕鬆縮小為規則的自動化工作解鎖新的模式。這些新功能包括解決非結構化對話中的客戶意圖、協調跨系統的多方流程,以及即時回應營運條件。工作人員工作流程使用自動化,其設計目的為考量成果,而非執行預先定義的步驟。滿足此需求需要跨自動化複雜性的完整範圍作業的平台,以及顯示每個功能適合的架構。
Agentforce 將 Einstein Trust 圖層、推理引擎、工作人員指令檔、流程、Apex 和 Data 360 結合到一個統一的平台中。此組合可處理從簡單的記錄觸發自動化到複雜的語音、視覺、文件和即時遙測的多工作人員協調流程。MuleSoft 透過 MuleSoft 架構、管治和跨系統協調流程,擴充此平台,以連線跨企業的代理工作流程。Agentforce Operations (先前稱為 Agentforce Supply Chain) 將這些功能套用至營運和製造流程的特定需求。
本指南介紹「協調流程密度」架構與原則,以便在整個產品環境中做出明智的決策。此架構為結構設計師提供可重複的方法,使用 Salesforce Platform 上智慧自動化使用個案的密度層級來選取正確的工具和模式。
| 產品 | 描述 |
|---|---|
| Agentforce | Agentforce 是 Salesforce 建立及部署 AI 工作人員的平台。其使用 Atlas 引擎透過 Apex 和 Data 360 觸發即時動態奠基動作。 |
| 工作人員指令檔 | 工作人員指令檔是陳述性網域特定語言 (DSL),用於在 Agentforce Builder 中為工作人員定義工作流程、業務規則和對話邏輯 |
| Agentforce 網格 | Agentforce Grid 是 AI 原生、無程式碼的試算表類似介面,可快速大規模設計和操作 AI 工作流程。 |
| Agentforce 作業 | Agentforce Operations (先前稱為 Agentforce Supply Chain) 是 AI 技術支援的協同合作工作流程管理協調流程平台,專為簡化和自動化後端辦公室業務流程而設計。 |
| MuleSoft | MuleSoft 是一個全方位、統一且開放的企業整合與代理管理平台。透過 API 導向的連線和 MuleSoft Agent Fabric 和 Agent Broker,其可作為整合架構、管治層和跨系統協調流程基礎,以連接跨企業的代理工作流程 |
| 流程與 Apex | Salesforce 流程是一種功能強大的點選自動化工具,可在視覺上建立複雜的業務流程,而不需使用程式碼。Salesforce Apex 是 Salesforce 平台的專屬物件導向程式語言,類似於 Java。用於建立自訂業務邏輯、自動化流程,並將核心 CRM 功能延伸至陳述性工具之外。 |
Agentforce 代表從以規則為基礎的自動化到以推理為基礎的工作流程,在 Salesforce Platform 上工作完成方式的根本變更。為了發揮其潛力,結構設計師必須作出有意義且明智的決定,以瞭解工作人員的適合度、其組成方式,以及其協調的項目。下列原則為工作人員決策提供可重複的原則。
-
**針對正確工作使用正確的工具。**根據執行路徑、強制回應組合和目標複雜度使用協調流程密度,以決定最合適的解決方案。
-
將「流程」和 Apex 搭配「**傳統自動化」**使用於以規則為基礎的決定性工作,其中結果可以完全由一組規則範圍來定義。傳統自動化會產生靜態執行路徑,這可保證可預測和可重複的成果,且對於稽核性而言至關重要。針對需要嚴格合規和符合法律的工作選擇傳統自動化。
-
針對低至中協調流程複雜性的大量推斷使用個案,使用 Agentforce 網格。此模式使用單次生成性推理來分類、評分或摘要大量 CRM 記錄中的資料,以確保執行高輸出和立即稽核性。
-
針對具有未結束目標的工作使用 Agentforce with Agent Script,其中已知所需成果,但無法在設計時指定確切的執行路徑。將此模式套用至需要透過引導決定性推理的需求,以確保可預測且可追蹤的成果。
-
使用「Agentforce 作業」 透過為供應鏈工作流程啟用 AI 的管理,簡化和自動化協同合作業務流程。
-
-
避免將工作人員工作流程套用至低協調密度使用個案。針對功能與非功能需求,評估傳統自動化與代理自動化之間的權衡。傳統自動化可以為您的使用個案提供所需的規模、可靠性和效能。
-
採用工作人員自動化混合方法,此方法將 Agentforce 和傳統自動化與「流程」和 Apex 結合在一起,當此協同合作提供的價值高於使用單獨使用代理或傳統自動化時。
Salesforce sObject 傳統上是記錄自動化的主要進入點。系統會根據規則執行邏輯,從「資料操作語言」(DML) 事件 (例如 insert、update 或 delete) 之後立即開始。為了決定有效率的 記錄觸發自動化工具之間,我們引入了「自動化密度」,以測量系統的複雜度,並考慮自動化數量、記錄量和相依性擴展。傳統自動化受到將資料帶入結構化、結構描述相容且以規則為基礎的建構所需的廣泛預先工作限制。
工作人員自動化會使用使用者意圖或非結構化資料升級傳統自動化,作為輸入,可套用推理以達到所需成果。結構設計師必須決定何時為多重模式非結構化資料運用概率邏輯,以及何時強制執行引導式決定性工作流程,以降低無法預測成果的風險。
當需求從執行以規則為基礎的步驟轉移到推理結果時,結構設計師需要標準化架構來評估建議解決方案的推理深度和目標複雜性。
協調流程密度是工作人員工作流程內的複雜度度量。有三個因素決定協調流程密度:執行路徑、目標複雜性和強制回應組合。自動化密度會測量系統規則和體積的實體複雜度,而協調流程密度會測量工作人員前往目標路徑的推理複雜度。使用複合協調流程密度來評估您的設計需求,並對應至結構標準。
- 執行路徑:可在設計時完全定義及指定工作流程範圍的程度。完全指定的工作流程表示工作流程會定義每個分支和結果,進而產生預先決定的執行路徑。非可指定的工作流程有一個路徑,可在執行階段期間透過根據內容資料和指示進行推理來出現。
- 目標複雜性:工作流程在執行階段必須解決的不同成果、決策點和路徑變化數目。低複雜度工作流程會處理具有預先決定的成果的單一包含工作,而高複雜度目標會跨越多個階段,其中具有與設計時無法預期之邊緣個案的競爭或衝突目標。
- 強制回應組合:工作流程必須處理的輸入類型範圍,以及其必須產生的輸出表單。低強制回應組合會讀取標準 CRM 欄位並產生記錄更新。中型強制回應會耗用結構化 CRM 欄位與靜態、非結構化資料 (例如電子郵件內文或個案文字記錄) 的混合,以產生記錄更新。高強制回應組合會耗用動態即時串流,例如即時音訊或遠程測量,並在多個外部系統之間產生多重模式輸出。

決定適當的協調流程密度層級需要依序評估執行路徑、目標複雜性和強制回應組合。請先檢查執行路徑。如果路徑完全可指定,請從傳統自動化開始。僅使用工作人員解決方案來協調並執行決定性路徑,而不需要任何推理是反模式。這會導致工作人員展開 (過度、未受管理的 AI 工作人員擴充) 和工作人員斜線 (品質不佳、不必要的 AI 產生的輸出),導致值傳回不佳。
針對部分或不可指定路徑,請繼續評估目標複雜性。如果目標複雜性已正確定義,但路徑的特定節點需要可能性評估,請考慮從流程或 Apex 呼叫工作人員以符合特定本地化需求。相反地,如果執行路徑中的步驟在大型記錄集中需要一或多個 AI 驅動的需求,請考慮 Agentforce 網格。網格透過多個 AI 或工作人員欄支援多步驟、以工作表為基礎的工作流程。最適合大量以列為導向的執行。此方法可確保工作流程保持高效能且可稽核,僅在無法預先定義路徑時叫用概率推理。
當目標的複雜性隨著競爭的維度 (例如判斷保險索賠支出以及詐騙偵測、保單合規性和客戶滿意度) 和無法指定執行路徑而增加時,請考慮使用 Agentforce with Agent Script 來取得自動化中的引導決定性。針對涉及 Salesforce 和第三方系統的跨企業使用個案,請使用 MuleSoft Fabric 和工作人員經紀人。
最後,評估強制回應組合以識別必要的技術功能,例如多重模式連線或專門整合。強制回應組合功能為功能選取器,而非密度計算器。這有助於決定處理解決方案輸入與輸出形式所需的基礎結構,而不變更其基本協調流程邏輯。
使用此矩陣可決定工作人員自動化的結構標準。透過選取解決自動化問題的方法來平衡傳統與代理自動化。
- **傳統自動化 (低協調流程密度):**當流程由記錄變更觸發、資料結構化、邏輯以規則為基礎且預先決定,且成果必須可預測 (例如標準價格計算或自動工作建立) 時,請使用傳統自動化。
- **Agentforce 網格 (低至中協調流程密度):**當必須處理現有記錄之間的大量 AI 工作時,請使用 Agentforce 網格 (例如,摘要此清單中每個帳戶的最後 50 個個案、計算情感分數,並將分數保留在個案欄位中)。
- **混合協調流程 (高階增強型自動化):**當自動化複雜端對端業務流程 (例如,索賠處理或上線) 時,請使用混合式協調流程,這需要 AI 的規劃能力,但需要 Flow 和 Apex 的交易完整性。
- **Agentforce Agent Script (高意圖複雜性):**當進入點非結構化 (例如聊天、電子郵件和語音),且解決方案需要交談或能夠處理不明確的使用者要求時,請使用工作人員指令檔。
| 密度層級 | 執行路徑 | 目標複雜性 | 強制回應組合 | 結構標準 |
|---|---|---|---|---|
| 低 | 完全指定 | **低:**具有預先定義成果的單一包含工作。 | **單一強制回應:**讀取與寫入結構化 Salesforce 物件記錄。 | 記錄觸發自動化。如果使用個案有至少一個推理工作,請在工作流程中使用「工作人員動作」。 |
| 低 - 中 | 完全或部分指定 | **低:**包含預先定義成果的一系列步驟。 | **混合強制回應:**輸入或輸出可以混合結構化與非結構化資料。 | 透過工作人員動作,針對跨現有記錄的大量工作使用 Agentforce 網格批次推斷。 |
| 中型 | 可完全或部分指定。執行路徑是預先定義的,但中間步驟需要推理。 | **中等:**含變數成果的一系列以 Apex 或流程為基礎的步驟。 | **混合強制回應:**輸入或輸出可以混合少量結構化與非結構化資料。 | 混合式 (Agentforce + Apex/Flow):使用 Agentforce 進行高密度的推理和規劃、使用工作人員指令檔進行引導式決定,以及使用 Apex/Flow 進行協調流程。 |
| 高 | 部分或不可指定。目標是預先定義的,但中介步驟需要執行階段內容和使用者意圖。 | **高:**具有嚴重推理需求的多個競爭目標需要決定性成果。 | **混合強制回應:**輸入或輸出可以混合大量即時傳送的結構化與非結構化資料。 | 使用工作人員指令檔以平衡決定性控制與推理。針對複雜的多重工作人員協同合作,針對第三方 MCP 或 A2A 使用 MuleSoft Agent Fabric。 |
| 能力 | 傳統自動化 (流程/Apex) | Agentforce 網格 | Agentforce | Agentforce 與工作人員指令檔 |
|---|---|---|---|---|
| 邏輯類型與決定性 | **決定性:**使用固定 if-then-else 邏輯。根據記錄狀態,執行路徑為 100% 可預測。 | **混合:**透過結構化步驟決定性,而個別 AI 步驟可以是可能性性。 | **可能性:**使用多回合推理來決定達成目標的最佳路徑。 | **引導式決定性:**使用邏輯規劃路徑,並允許對決定性節點路徑執行。 |
| 遞送速度 | **建議 (流程):**視覺工具可在無程式碼的情況下快速建立記錄觸發邏輯。 | **建議重複 AI 自動化:**在不建立新流程的情況下,將 AI 邏輯套用至現有記錄集的最快方式。 | **建議:**用於針對特定網域或問題設定「子工作人員」(先前稱為主題)、指示和技能對應。 | **建議:**適用於以州為基礎之圖表和邊緣邏輯的進階對應。 |
| 輸入模式 | **建議僅限結構化:**限制為 CRM 欄位和相關記錄集合。 | **建議使用半結構化:**從記錄欄位處理大量文字 (描述、文字記錄)。 | **多強制回應的建議:**處理自然語言、語音和視覺 (非結構化資料)。 | **建議使用高密度:**使用即時系統狀態資料來同步化多重模式輸入。 |
| 推理深度 (規劃) | **不可用:**邏輯是必要的,不能動態地「思考」或規劃步驟。但是,資料可以傳送給工作人員。 | **低:**套用於記錄集的單一步驟推斷 (批次 AI)。 | **中/高:**使用推斷迴圈 (Reason-Act-Observe) 來解決複雜的意圖。 | **受管理:**原因僅限於瀏覽預先定義的業務狀態圖表。 |
| 模組化與可重複使用性 | **建議:**預設為透過子流程和 Apex 類別模組化。 | **限制:**邏輯通常與特定網格列繫結。資料欄設定與範本工作流程可在整個資料列集中重複使用。 | **可用:**技能 (流程/Apex) 可在不同的子工作人員 (先前稱為「主題」) 和連線的工作人員之間重複使用。 | 建議:「工作人員圖表」中的節點是離散且可重複使用的功能單位。 |
| 交易與 DML 控制 | **建議 (Apex):**完全控制 Savepoints、結轉和大量處理。 | **可用:**系統會獨立處理每一列,因此執行範圍為每個記錄。 | **限制:**動作會在工作階段中以個別的分離步驟執行。 | **建議:**使用流程/Apex 節點作為所有 DML 的決定點。跨工作人員的分散式交易控制支援受到限制。 |
| 不明確處理 | **不可用:**需要預先定義的路徑。非預期輸入會導致失敗或靜態錯誤。 | **限制:**輸出品質取決於提示基礎。工作流程無法以互動方式要求說明。 | **建議:**詢問問題或選取替代技能來處理「未知」狀態。 | **可用:**使用「回復節點」管理推斷失敗或流程逾時。 |
| 可視性與管治 | **建議:**流程觸發探索器提供所有記錄觸發邏輯的視覺化地圖。 | **可用:**網格型 UI 可讓您清楚瞭解列層級結果,並支援輸出的稽核性。 | 可用:「監視記錄」可提供工作人員決策方式的透明度。 | **需要專長:**需要監視「圖表」周遊和 LLM 推斷記錄。 |
| 效能與規模 | 建議 針對大量同步記錄處理最佳化。 | 建議可有效率地處理大型資料量之間的大量 AI 工作。 | 與推斷時間相依;不適用於高密度大量更新。**** | 中度適用於複雜的長範圍工作,但額外負擔較高。 |
此表格提供適用於各種使用個案的一般最佳建議。
| 使用個案 | 描述 | 最適合 | 理由 |
|---|---|---|---|
| 記錄處理 | 由結構化 Salesforce 物件上的 DML 事件觸發的自動化,其中的每個分支和成果都可以在設計時完全定義。 | 使用記錄觸發流程。這是低密度的傳統自動化。 | 低協調流程密度。單一強制回應 (結構化 CRM 欄位) 和單一包含目標,並具有可預測且可稽核的執行路徑。 |
| 具有複雜邏輯的交易控制 | 需要儲存點、回復、部分認可或跨高記錄量大量安全資料操作的自動化。 | 使用 Apex 進行傳統低密度決定性自動化。 | 低協調流程密度。Apex 提供交易完整性的完整控制權、超重耗費的運算和平台層級快取 - 流程中無法使用的功能。 |
| 結構化程序內的中度複雜邏輯 | 自動化,其中整體流程以規則為基礎,但個別步驟需要超出陳述性功能的計算或資料操作。 | 將流程與可叫用 Apex 搭配使用,以取得低密度決定性邏輯。 | 低協調流程密度。流程會作為協調流程層;可叫用 Apex 會將高複雜度的作業壓縮為可重複使用且安全的元件。 |
| 排程和暫時處理 | 與記錄事件相關的動態計算未來日期必須執行的自動化。 | 針對低密度決定性處理,使用傳統自動化 (記錄觸發流程)。 | 低協調流程密度。如果記錄資料變更,流程排程路徑會提供自動排程、取消和重新排程 - 原生無法在 Apex 觸發中使用。 |
| 大量記錄推斷 | 將單一 AI 推理步驟統一套用至一組大型現有記錄,以產生分類、摘要或分數。 | 使用 Agentforce 網格進行批次推斷,並大規模使用重複的工作人員功能。 | 中等協調流程密度。使用單一強制回應大規模的批次推斷:工作人員會讀取結構化記錄欄位,並將統一輸出寫回每個記錄。具有單一重複推斷模式的低目標複雜度。 |
| 非結構化輸入解析度 | 自動化,其中進入點是必須透過推理解譯、分類和解決的自然語言要求、電子郵件或對話。 | 使用 Agentforce 進行中密度、以意圖為導向、非結構化輸入解析。 | 中等協調流程密度。混合強制回應:工作人員會耗用非結構化對話輸入,然後產生文字回應或結構化記錄更新。目標需要解決跨界限成果集的使用者意圖。 |
| 可能性流程內的中度複雜邏輯 | 自動化,其中整體流程以規則為基礎,但個別步驟需要 AI 功能,例如摘要或 RAG 提取。 | 針對需要 AI 功能的低密度決定性流程,使用包含可叫用 Apex 和提示範本的流程。 | 中等協調流程密度。流程會作為協調流程層,而「提示範本」、Agentforce 服務代理程式和 Agentforce 員工代理程式會顯示為「可叫用」動作。 |
| 引導式流程協調流程 | 跨多步驟工作流程的自動化,其中一個動作的完成會觸發其他動作 | 針對需要引導式流程協調流程的高密度非指定執行路徑,使用「工作人員指令檔與動作」。 | 高協調流程密度 - 輸入與輸出之間的混合模式。無法在設計時完全預期的競爭成果和邊緣個案。「工作人員指令檔」提供引導式決定性。 |
| 跨系統流程協調流程 | 在多個後端系統之間協調多步驟業務流程的自動化,其中沒有單一系統擁有端對端流程 | 將 MuleSoft 流程 API 與工作人員經紀人搭配使用,以進行中至高密度的跨系統流程協調流程。 | 高協調流程密度 - 流程 API 會壓縮複雜的多步驟業務邏輯,因此工作人員不需要瞭解訂單處理或庫存檢查等作業背後的協調流程。工作人員經紀人會動態地從單一自然語言目標中排列並叫用必要的工作人員和工具。 |
| 後端系統抽象 | 工作人員必須與舊版系統、資料庫或缺乏原生 Agentforce 連線的第三方 SaaS 平台互動的協調流程。 | 將 MuleSoft 與 MCP 連接器搭配使用,以包覆舊版系統並提供模型內容。 | 中等協調流程密度。系統 API 為記錄系統提供安全的抽象介面,確保工作人員工作流程與後端複雜性分離。MCP 連接器會將 MuleSoft 應用程式轉換為 MCP 相容的伺服器,以供立即探索和叫用。 |
| 大量文件處理與例外處理 | 將輸入結構化和半結構化文件與現有記錄進行大規模讀取、解譯和協調的自動化 - 透過適當的手動介入處理差異、部分相符項目和例外狀況。 | 使用 Agentforce 作業來處理中密度、以意圖為導向的大量文件。 | 具有半結構化輸入強制回應的中型協調流程密度。由每份文件比對規則、例外狀況路徑和批准值所驅動的目標複雜度。需要每個記錄的推理,而非統一單向推斷。 |
| 跨廠商的多工作人員協調流程 | 自動化需要在不同平台或廠商上建立的專門工作人員之間協同合作。 | 將 MuleSoft 與「A2A 連接器」和「工作人員紡織」搭配使用,以跨不同系統進行多工作人員協調流程。 | 中至高協調流程密度。無論每個工作人員的建立或託管位置為何,A2A 連接器都能讓企業層級的管理與可靠性實現點對點多工作人員工作流程。 |
| 非結構化文件轉換為工作流程 | 自動化,在非結構化來源 (SOP、供應商規則文件或流程圖) 中定義的作業流程必須轉換為可執行的工作流程,而無須手動編碼。 | 使用 Agentforce 作業來轉換高密度、新增非結構化文件至工作流程。 | 輸入高強度混合的高密度。取用 PDF、Word 文件和以影像為基礎的圖表。所選流程的範圍和分支所決定的目標複雜度。無法在設計時指定執行路徑。 |
| 多方協調流程 | 跨越外部協調上線的自動化 - 收集必要資料、驗證合規性、管理批准,以及更新許多同時上線追蹤的記錄系統。 | 針對中至高密度、意圖驅動的新增多方協調流程,使用 Agentforce 作業。 | 多個相互相依的驗證與批准步驟必須先依序解決,上線才能完成。強制回應組合包含結構化記錄、非結構化文件和外部對象通訊。 |
| 預測資產介入 | 自動化,其中預測引擎會採取即時距離測量以識別即將發生失敗的條件,並觸發協調的多步驟後端辦公室回應。 | 使用 Agentforce Operations 和 Agentforce for Manufacturing 進行高密度預測資產介入。 | Data Cloud 處理高模式 IoT 距離測試和異常偵測。Agentforce Operations 接著會協調中型模式後端辦公室工作流程—管理現場服務記錄、庫存資料和客戶通訊—解決流程端對端。 |
| 大規模供應商通訊管理 | 自動化管理跨大型供應商基礎的持續結構化和半結構化通訊,包括訂單確認、遞送日期變更和例外通知。 | 將 Agentforce 作業用於批次推斷用於中密度供應商通訊管理。 | 若通訊在供應商之間是統一的,請使用 Agentforce 網格進行批次處理。若回應需要各供應商關係的內容考量,請使用 Agentforce 作業升級至中度密度。 |
| 商機管理 (高速智慧路由) | 此自動化功能會採取即時行銷回應、使用 AI 評分和 Data Cloud 增強來進行資格,並使用流程來以智慧方式將高品質的商機指派給適當的銷售小組。 | 使用傳統自動化 (流程) + Data Cloud 和 AI 進行中密度高速智慧商機路由。 | 根據 AI 商機評分、工作層級和活動歷程記錄,需要高速 (商機速度 < 1 分鐘) 和複雜且資料驅動的路由。使用「流程」進行快速決定性指派邏輯,並透過可能性 AI 與 Data Cloud 進行擴充以進行商機資格和增強。 |
| 商機培養 | 培養低評分商機,直到這些商機準備好進行銷售對話為止。 | 針對中至高密度的自動化,使用「商機培養工作人員」鎖定和改善低品質的商機。 | 傳送以商機資料和客戶成功案例為基礎的個人化多點式電子郵件。它會處理電子郵件回應,並使用「流程」進行轉寄。 |
| 輸入商機資格 | 自行資格並培養評分較高的輸入商機。 | 使用「商機培養工作人員」來合格和參與商機。 | 執行多重接觸電子郵件輸出、會議預訂、產品問與答和反對處理。其可在「以銷售人員身分傳送」模式中作業,透過指派的商機擁有者傳送電子郵件。 |

延遲
同步記錄觸發流程會在平台交易中執行,並在毫秒內完成。Agentforce 推斷時間取決於「Atlas 原因引擎」,並依據推斷深度和強制回應複雜度進行調整。Agentforce 不適用於大量同步記錄處理,其中延遲是主要限制。
成本
工作人員工作流程的推理成本必須根據成果的業務價值進行推理。針對存在決定性路徑的大量、低協調密度工作,傳統自動化或 Agentforce Grid 可能比端對端代理程式工作流更為經濟。確保設計包含正確的重試模式,並包含明確的重試上限與中斷器。此護欄會限制與大量處理相關聯的複雜成本超額風險。
管理員限制
根據非同步執行的每日平台限制來評估大量工作人員工作流程。Agentforce 網格批次作業遵循標準平台交易限制。針對涉及 Salesforce 物件的自動化,請考慮 DML 作業的每日總數,因為 Salesforce 會在多租戶環境中強制執行共用資源管理,並強制執行 管理員限制,以防止流失自動化獨占共用資源。
稽核與合規性
傳統自動化透過流程觸發探索器和 Apex 記錄產生可完全稽核的執行追蹤。以 Agentforce 為基礎的端對端或混合式模式會產生推理記錄,以提供工作人員決策的透明度,但其需要專業知識才能解譯。透過「工作人員指令檔」的引導式決定性是受監管產業的建議模式,其中完整執行稽核性是合規性需求。
升級
在高密度運作的工作流程應納入明確的人類批准或升級門,以處理具有無法復原後果的動作,例如財務交易、監管提交或供應商承諾。「工作人員指令檔」條件控制項提供在其他工作人員工作流程中決定性強制執行這些門的機制。
在協調流程設計中排定簡化優先順序。從可達成目標的最小協調流程層級開始、在實際載入中進行驗證,然後重複進行。鏈接中每個額外的工作人員、轉移或相依性都會呈現新的外觀,這可能會產生不一致的行為。
在您可指定的執行路徑中,在需要推理的節點上,開始內嵌工作人員。遵循在 Agentforce 中建立工作人員的最佳作法。請避免包裝大量的子工作人員 (先前稱為「主題」),且切勿膨脹指示。在自動化使用個案中部署的工作人員可以放心使用,因為這些工作人員並非唯一的介面。選擇適合連鎖的原始詞。協調流程 (委派) 模式具有更嚴格的執行順序控制權,並可將子工作委派給專家。避免使用 koreographed (handoff) 模式。如果您必須實作運送設計,請為接收的工作人員提供目標、內容和狀態,讓其能夠在全域最佳化,而非在本機最佳化目標。
避免動作或工具展開。動作是實現工作人員邏輯的地方,其設計會決定其是否產生可靠成果或失敗。每個動作都必須傳回結構化且可觀察的回應,以便 AI 工作人員用來計畫下一輪交談。
擁有多個動作 (以及不同的輸出建構) 來執行相同工作會降低工作人員為工作解釋或選擇正確工具的能力。這可能會造成工作人員遺漏細微差別。重疊動作定義會造成分類錯誤的風險。確定您的動作文件庫已稽核、編譯版本並符合「子工作人員」(先前稱為「主題」) 範圍。
**定義可觀察的目標。**將目標定義為可觀察的成果,而不只是程序。模糊的目標會邀請工作人員漂移。使用可指定的執行路徑增強。使用具有混合式推理的「工作人員圖表」將目標建模為具有明確狀態的圖表節點。執行階段會在工作流程中追蹤工作人員目前的位置,並在 tangential 輸入後將其還原;當工作人員在內容視窗中收到其他資訊時,它不會失去目標。
測試和評估。實作強大的測試和評估架構,以驗證可能性節點的推理和工作人員自動化的輸出。根據預期的結果路徑驗證執行路徑,以確保模型到達正確的結果。透過判斷執行步驟中的結果,避免工作人員不實報告成功或進入無限或不可復原迴圈時發生無訊息失敗。使用 工作階段追蹤來檢查逐一互動、推斷引擎執行、動作、提示和門戶輸入/輸出、錯誤訊息和最終回應。
| Agentforce | 傳統自動化 | 整合 |
|---|---|---|
關於作者
Arvind Palaniswamy 是首席結構設計師小組辦公室的軟體工程結構設計師。他喜歡使用第一個原則,以最簡單的形式為複雜系統建立框架。他透過數十年經驗和 MS/MBA(Kellogg) 教育,瞭解工程、營運和業務。