簡介

注意:「主題」已根據我們的最新產品命名慣例,在整篇文章中重新命名為「子工作人員」。

您可以建立在測試環境中表現良好的工作人員,只有在處理相同工作流程兩次時,才能讓工作人員遵循完全不同的路線。此基本限制顯示先前 Agentforce 模型處理執行的方式:每個決策都由 LLM 即時做出,從意圖解譯到動作選取,沒有保證的工作流程路徑。

LLM 可以產生不一致的成果來回應相同的輸入。內容、系統提示或權杖產生的細微變化足以將工作人員傳送至不同的路線。對於許多互動,此變異性是可以接受的。不過,對於需要可稽核、可複製性和可追溯性的多階段工作流程,則否。貸款批准、庫存運送或病患分級流程不可取決於工作人員,他們每次都以不同的方式推斷步驟。

新的 Agentforce Builder 與工作人員指令檔會透過將決定性執行與 LLM 邏輯分開來解決此問題。Agentforce 的混合式模型可確保工作人員針對每個工作流程執行遵循精確定義的結構,同時在真正需要判斷、瞭解自然語言或內容解譯時仍使用 LLM 推理。

在先前版本的 Agentforce 中,工作人員會以簡單反應性迴圈的方式作業。LLM 僅根據使用者最近的輸入,即時做出每個決策,從解譯意圖到選取下一個動作。沒有保證的執行路徑、沒有永久狀態,也沒有強制執行一系列步驟的機制。

無法保證執行路徑

由於每個決策都取決於 LLM 的即時推理,因此輸入、系統提示或模型版本中的小幅變化會針對相同要求產生不同的動作選取項目。這使得先前的模型難以嚴格測試:在暫存中通過的工作流程在生產環境中會有不同的行為,且沒有可靠的方式可以複製特定執行路徑以進行除錯或稽核。

每個互動都已支付完整的 LLM 費用

即使是簡單的對話情況,仍需要至少三個 LLM 週期:子工作人員選取、動作選取和最終回應產生。延長為五個或更多週期的多步驟工作。針對設計大量或敏感延遲工作流程的結構設計師,這不只是效能方面的考量。這表示您無法針對不需要判斷的步驟縮短推斷迴圈,因為結構沒有區分這兩個步驟的機制。

非決定性執行已建立稽核缺口

在受監管的產業中,稽核性表示能夠證明特定交易遵循特定流程的方式。純粹非決定性模型無法提供該保固。如果執行路徑在執行之間有所不同,則稽核追蹤也會有所不同,且「工作人員決定」並非合規審查中的可捍衛回答。

州/省無法繼續對話

依賴單次處理表示工作人員不會永久記住先前的步驟。如果對話甚至略有偏差,則工作人員可能會捨棄先前所取得的內容,並強制使用者重新啟動。針對多步驟交易工作流程,這會建立可靠性上限:流程中步驟愈多,完成前內容遺失的可能性愈高。

未記住完成的步驟

若沒有狀態管理,工作人員便無法記錄使用者已完成哪些必要步驟。這會產生無法預測的迴圈,以便工作人員返回使用者已完成的步驟。除了使用者體驗影響之外,這也建立了更深刻的結構問題:設計可靠的序列工作流程是無法的,因為工作人員無法強制執行序列。

新的 Agentforce (GA) 從 2026 年 2 月開始,將從純概率 LLM 推理轉為混合式模型。不會透過 LLM 路由每個決策,它會將決定性執行與 LLM 推理分開,並讓每個決策僅處理其適用的項目。為了支援此項,Agentforce 導入兩種編寫工具:適用於程式碼型開發的工作人員指令檔,以及 Agentforce Studio,無程式碼建立環境。

Agentforce 產生器

Agentforce Builder 是開發新工作人員的建議環境。其是在 Agentforce Studio 內主控,並取代舊版「設定」體驗,此體驗仍可供使用,但不再是主要的編寫路徑。在產生器中,您可在視覺畫布檢視中或直接在指令檔檢視中工作,編輯定義工作人員行為的工作人員指令檔。

工作人員指令檔

工作人員指令檔是陳述性、網域特定的語言 (DSL),可定義工作人員行為的所有內容:其組態、業務邏輯和提示。其建構為可跨多行或包含巢狀子內容的金鑰值配對,並設計為人類可讀取,而不需要基本圖表結構的 Knowledge。

「工作人員指令檔」可讓您在同一個工作人員中表達兩種基本不同的指示類型:決定性邏輯指示與提示指示。決定性邏輯指示會定義以程式碼執行的條件和動作序列,而不會涉及 LLM。提示指示會定義 LLM 在執行階段解譯的自然語言指引。兩者之間的邊界是明確且有意的,並且瞭解放置該邊界的位置是您在使用新的 Agentforce 建立時要做的一個核心設計決策。

實際上決定性邏輯

當指示為決定性時,無論使用者如何描述其輸入,工作人員都會遵循定義的執行路徑。下列範例顯示載入客戶智慧顯示面板的子代理程式。它會檢查客戶識別碼、提取設定檔資料、訂單歷程記錄和支援票證,然後計算客戶的終身價值和流失風險。這些步驟都不需要 LLM 推理。

此邏輯會在每次符合特定條件時,以固定的順序呼叫動作。

提示指示並刻意處理 LLM

當決定性邏輯處理可作為程式碼表示的條件和序列時,提示指示會處理需要判斷、解譯或自然語言產生的所有內容。當 Atlas Reasoning Engine 遇到具有提示指示的節點時,它會觸發 LLM 呼叫。若未執行,則會決定性執行。

下列範例顯示產品和服務的子代理程式。指示是多行提示,可告知 LLM 如何回應、何時查詢資訊,以及如何處理不明確性。當可能的使用者輸入範圍太廣,無法以條件邏輯預期時,或當回應的品質取決於 LLM 解讀內容並產生自然回覆的能力時,這是正確的模式。

節點上的提示指示會觸發 LLM 呼叫。這並非偶發,這是工作人員指令檔可讓 LLM 邊界明確且可強制執行的機制,而非將其留給執行階段推斷。

此子代理程式會顯示決定性邏輯和運作中的 LLM 操作。

三階段的執行管道

Agentforce Builder 和工作人員指令檔是編寫圖層,但「工作人員圖表」和「Atlas 原因引擎」實際上會執行您的工作人員。依設計,您無法直接存取這些元件。將撰寫與執行分開,可讓平台獨立於撰寫指令檔的方式,強制執行決定性行為。

銷售管道會通過三個階段。

1. 編寫是您工作的位置。「工作人員指令檔」在「畫布」檢視或 Agentforce Builder 中的「指令檔」檢視中皆可人類閱讀並編輯。這是您唯一直接互動的圖層。
2. 編譯是 Salesforce 編譯器將「工作人員指令檔」轉換為「工作人員圖表」的位置,這是針對機器執行最佳化的序列化執行計畫,而非人類可讀性。您不會為此層進行除錯。編譯會產生執行階段可以有效地周遊的表示。
3. 「Atlas 原因引擎」會接管「執行階段執行」。它會讀取「工作人員圖表」,根據目前的工作階段狀態周遊,並在每個節點上決定是否要決定性執行或叫用 LLM。引擎在此明確強制執行保管子句和條件式路由,而非推斷。

工作人員圖表

「工作人員圖表」是位於您人類可讀指令檔與實際執行階段執行之間的中介表示。其結構已針對耗用其狀態機器最佳化,而非針對撰寫指令檔的結構設計師。瞭解其存在以及其代表的內容很重要,因為其是「原因引擎」用來強制執行指令檔所定義執行計畫的成品。

Atlas 推理引擎

Atlas Reasoning Engine 是州機器執行器。在每個輪數中,它會根據工作階段狀態周遊「工作人員圖表」,以程式碼執行決定性節點,並僅在出現提示指示時觸發 LLM 呼叫。它也會強制執行保護子句並處理條件式路由。「原因引擎」是實際實作混合式推理模型的位置;指令檔會定義邊界,引擎會遵循邊界。

「工作人員圖表」不是 LLM 包裝程式。這是一種混合式推理引擎,可將決定性執行與可能性性推理分開。管理規則很簡單:如果您可以將決策作為程式碼表示,則應寫成邏輯。如果決策需要判斷、解譯或產生自然語言,則 LLM 應處理。此設計決策是新 Agentforce 模型中最重要的結構選擇。LLM 邊界的下限會直接影響解決方案的成本、延遲、稽核性與可靠性。

「Atlas 原因引擎」會評估每個傳入使用者輪數,並將其路由至兩個路徑的其中一個。

路徑 A:決定性執行

此路徑沒有 LLM 曝光。其行為就像在執行階段編譯的程式碼。「原因引擎」會分類使用者的意圖,並判斷邏輯指示符合,完全略過 LLM。已編譯的工作人員指令檔會從上到下執行,if-else 規則會在每個輪班上無條件地執行。系統會使用決定性參數呼叫流程、Apex 或 API 動作,而不涉及提示組合或模型呼叫。透過完整稽核記錄,結果會傳回 Trust 圖層。

路徑 B:LLM 原因

當「原因引擎」無法僅使用邏輯指示來解決意圖時,便會採用此路徑。它會周遊「工作人員圖表」並評估每個節點。具有提示指示的節點會觸發 LLM 呼叫。沒有這些權限的節點會以決定性方式執行。提示指示的存在是觸發,其在指令檔中明確顯示,而不是在執行階段推斷。

觸發 LLM 呼叫的原因

執行生命週期中有八個點會叫用 LLM。子代理程式分類或決定哪個子代理程式符合使用者的要求是一種,但當分類不具歧義時,短碼路徑會略過完整的 LLM 呼叫。工作人員的推理,工作人員決定接下來要採取的動作,一律會通過 LLM。同樣也適用於回應產生,其中的最終回覆會從合併的提示進行組合。

剩餘的觸發較為操作性:奠基驗證會確認輸出是以所取的資料奠基;動作模擬會模擬「預覽」與「模擬」環境中的回應,而非即時執行;結構化輸出產生會處理回應需要符合定義結構描述的個案;本地化與進度指標產生會處理不存在預先撰寫預設值的格式化與暫時訊息。

決定因素

圖表周遊與狀態轉換絕不涉及 LLM。before_reasoning 和 after_reasoning 生命週期區塊會以決定性方式執行,只要這些區塊僅包含沒有提示指示的動作節點。數學、資料取用、驗證和條件邏輯都屬於程式碼中。任何直接執行流程、Apex 或 REST API 的動作都會保持在決定性路徑上。沒有提示指示的任何節點都會在沒有 LLM 呼叫的情況下執行。

對您的小組說明此邊界很重要。每個不必要的 LLM 呼叫都會增加延遲、成本和變異性。結構設計師應依預設推送決定性邏輯,將 LLM 保留給工作實際需要其推理能力的個案。

設計指引:依預設推送邏輯至程式碼

當撰寫會作為條件、變數指派或動作篩選條件表示的提示指示時,請使用工作人員指令檔邏輯指示。每個不必要的 LLM 呼叫都會增加延遲、成本和變異性。

預設位置應為決定性。隔離可作為規則編碼的工作人員行為,並將其移至「工作人員指令檔」。需要自然語言合成、內容判斷或複雜轉譯的剩餘工作屬於承載提示節點。這不是限制;這是預期運作的邊界。LLM 會處理最適合的項目,而其他一切都會以程式碼執行。

「工作人員指令檔」中的主要執行單位不是使用者輪數。這是剖析:透過子工作人員三個生命週期區塊的單一完整週期。「Atlas 原因引擎」會在每次子工作人員需要處理某些內容時起始剖析,這會在三種情況中發生:在第一次進入子代理程式時,在動作完成並傳回結果時每次工具呼叫後,以及在每次新使用者在相同子代理程式內切換時。

瞭解剖析邊界很重要,因為其會決定每個區段執行的次數,因此您可以依賴且不能依賴指定邏輯的執行一次。

每個子工作人員都會定義三個執行區域:

before_reasoning 與 after_reasoning 皆為完全決定性。他們會執行動作、設定變數,並套用條件邏輯,而不涉及 LLM。這會使其成為指令檔中可靠且低成本的區塊。

使用 before_reasoning 的時機

before_reasoning 會在每個剖析開始時執行,但不會例外。它會在第一次進入子代理程式時執行,然後在每次工具呼叫或新使用者在該子代理程式開啟後再次執行。before_reasoning 中的 run @actions.X 為 code。不同於提示區塊內的指示 (LLM 可能遵循或不遵循),before_reasoning 會無條件地執行。

將此區塊用於初始化工作階段:提取內容記錄,從 Apex 或流程設定工作階段變數。這也是驗證和權益檢查所屬的位置,因為您想要在 LLM 看到任何工具之前先驗證這些檢查。內容 hydration 也適用於此處:呼叫資料提取動作,讓 LLM 接收預先填入的變數,而不需要要求變數。必須在每個剖析上增量的任何計數器或稽核變數都應在此處設定,因為在 before_reasoning 中,會以管道指示的不同方式來保證 set 指示詞。

此處不屬於邏輯,該邏輯每個工作階段只能執行一次,因為 before_reasoning 會在每次剖析上執行,而不只是在第一個項目上執行。依據目前輪數使用者輸入的任何內容也不屬於此處,因為該輸入尚未處理。轉換絕不應在 before_reasoning: 中此處的 transition to 指示會在每次剖析上無條件地觸發並建立迴圈。

如果您需要每次工作階段初始化一次,請明確保護:

一個使用者輪數可以觸發多個剖析:進入一次,然後在每次工具呼叫後再次進行。該功能有三個實際後果:before_reasoning 中的初始化動作會針對每個使用者執行多次轉換為多動作流程,在此增加的計數器變數將反映剖析計數,而非輪數,且具有副作用的動作,外部 API 呼叫或記錄寫入,除非每個剖析的重新執行是明確可接受的,否則不會存在於 before_reasoning 中。

before_reasoning 不是建構函式。這是每次剖析時執行的飛行前檢查。相應設計。

使用 after_reasoning 的時機

當邏輯迴圈完成後,即會執行 after_reasoning,即是在 LLM 回應且採取動作輸出後執行。這是動作後決定性檢查所屬的位置:根據結果評估動作輸出和分支。決定性轉換,或根據變數狀態而非 LLM 判斷移至下一個子代理程式,請坐在此處。當您需要在沒有 LLM 路由決策的情況下,以可預測順序將子工作人員鏈結時,也會進行變數清除,並進行協調流程順序。

將 after_reasoning 視為護欄層。這是您在 LLM 完成工作後強制執行業務規則和狀態管理的地方,以確保重要程序流程保持可預測,無論 LLM 產生的項目為何。

謹慎使用 is_displayable: True

設計協調流程的每個結構設計師都需要瞭解此平台行為。在動作上設定 is_displayable: True 時,只要 LLM 決定呈現該輸出,平台就會結束推斷迴圈。該結束會立即發生,這表示 after_reasoning 一律不會執行。

這是已知的平台行為,但對協調流程有直接的後果:當可顯示動作是流程的一部分時,系統會略過您放置在 after_reasoning 中的任何邏輯。

答案很簡單。將必須執行的邏輯移至後續子代理程式的 before_reasoning 區塊,而非目前的 after_reasoning 區塊。

設計指引:放置初始化邏輯的位置

設計子代理程式時,決定要放置邏輯的位置至關重要。此架構涵蓋最常見的情況:

基礎原則很簡單。當您撰寫提示指示,告訴 LLM「一律執行動作」時,這就是建議。LLM 可能會或可能不會依據內容加以遵循。當您將 run 指示詞放在 before_reasoning 中時,其為 code。它會在沒有例外的情況下對每個剖析執行。

條件化動作可用性是工作人員指令檔根據執行階段變數狀態向 LLM 顯示或隱藏動作的機制。當 available when 條件評估為 false 時,動作會完全從呈現給 LLM 的工具清單中移除。任何錯誤值 (包含 None、False、0 或空白字串) 都會抑制動作。

這不是提示指示,告訴 LLM「不要再這樣呼叫」,這是硬式平台級門。LLM 無法呼叫其無法存取的動作。

在此範例中,在 validation_passed 評估為 true 之前,LLM 不會看見 execute_transfer。門會由平台強制執行,而非由指示執行。

設計指引:請勿讓 LLM 設定門數變數

在執行相關聯動作之前,為 available when 子句中的每個變數提供可設定變數的決定性程式碼路徑。在 reasoning 中使用 before_reasoning 或決定性 run 和 set 區塊,將變數保持在已知狀態。如果您依賴 LLM 來設定門變數,則表示您已重新導入門設計為防止的變數。視對話而定,LLM 可能會或不會設定對話,這表示門可能會或不會開啟。

動作迴圈問題

當 LLM 重複呼叫相同的動作而未達到極限狀態時,會發生動作迴圈。這會在兩個條件同時為 true 時發生:動作執行後,available when 條件仍保持滿足,且推理指示不會明確告訴 LLM 停止呼叫動作。

呼叫動作後,平台不會自動抑制動作。如果入口網頁保持開啟,且邏輯指示不明確,則 LLM 會無限期呼叫每個剖析的相同動作。

請將 available when @variables.interest != "" 視為範例。如果動作執行,但興趣變數不是空白,則門會在下次剖析時保持開啟。LLM 會將動作視為可用,沒有指示告訴動作停止,然後再次呼叫動作。

有兩種可靠的方法可以打破迴圈。第一個動作是在動作的執行後邏輯中將門變數設定為已結束狀態,讓 available when 在下次剖析時評估為 false。第二個為使用個別 has_run 的布林值,該值會在第一次執行後關閉門。這兩種方法都會為入口網頁提供決定性的已結束狀態,這是平台抑制動作所需的條件。

銀行轉帳是瞭解這些模式在實際運作方式的實用透鏡。工作流程從外部看起來很簡單:將資金從一個帳戶移至另一個帳戶。實作需要多個複雜的步驟。轉移執行前,工作人員必須收集帳戶詳細資料、驗證金額、檢查轉移限制、確認可用餘額,然後才公開轉移動作。每個步驟都取決於先前的步驟。不應將任何項目留給 LLM 判斷。

收集和驗證輸入

第一個子工作人員會收集來源帳戶、目的地帳戶和使用者的轉移金額。在全部三個項目皆存在且有效之前,不會繼續進行。「工作人員指令檔」會依序檢查每個欄位:如果來源帳戶遺失,則會詢問。如果目的地遺失,則會詢問。如果金額為零或負數,則會詢問。只有在所有檢查皆清除後,validation_passed 變數才會設定為 true。

下列指令檔在實際上顯示這一點。請注意,每個失敗點的 validation_passed 都會明確設定為 false,且會指示 LLM 不要繼續。決定性檢查會無條件地執行,提示指示則會處理使用者面向的回應。

強制執行業務規則

工作人員驗證輸入後,會檢查轉移金額是否超過設定的轉移限制。這是業務規則成為代碼而非指示的位置。此限制並非由 LLM 考量;它是指令檔中定義的實值,並在每個剖析上以決定性方式檢查。

如果金額超過限制,則 validation_passed 會設定回 false,且 LLM 會向使用者提供三個選項:轉移允許的最大金額、分割為多個轉移,或連絡支援以取得更高的限制。工作人員無法繼續,直到使用者解決例外狀況為止。請注意,此處的提示指示如何確實執行適合的 LLM 推理:交談方式呈現選項並處理使用者的回應。業務規則本身是決定性的,但相關的對話並非如此。

下列指令檔顯示限制檢查的運作方式。決定性條件會根據限制變數評估轉移金額、將 validation_passed 設定為「false」 (如果超過了值),並委派給提示指示來處理面向使用者的回應。

套用保護子句

完成金額和限制檢查後,工作人員會提取來源帳戶餘額,並確認有足夠的可用基金。未符合先決條件時,保護子句會防止工作人員嘗試作業。不同於提示指示告訴 LLM 檢查餘額,工作人員指令檔中的保護子句會使檢查無條件。LLM 不會決定是否執行。

如果餘額不足,工作人員會計算短缺,並向使用者提供具體的替代方案。validation_passed 會設定為 false,直到此檢查通過為止,這表示轉移動作會保持已關閉。

下列指令檔顯示取用餘額的決定性動作呼叫,接著是評估餘額的條件式檢查。只有在還原的餘額尚未獲取時才會執行提取,進而避免在後續剖析時進行冗餘的 API 呼叫。

清楚表面錯誤

保護子句設定狀態。錯誤訊息會傳達。當 validation_passed 為 false 時,工作人員需要為使用者提供足夠的資訊來解決問題,而無須重新啟動。模糊的錯誤訊息會造成摩擦;結構化錯誤訊息會更快地結束迴圈。

下列指令檔顯示實際上資金不足的錯誤訊息。這不只是告訴使用者轉移失敗。它會顯示可用的餘額、要求的金額、計算的短缺,並提供具體的後續步驟,所有這些都會由工作階段變數組合而非由 LLM 產生。

短缺計算會在指令檔中進行,而不會在 LLM 中進行。建議的替代項目會轉移可用餘額,以決定性方式衍生自工作階段狀態。LLM 在此所扮演的角色完全為簡介:它會傳遞指令檔已建構的訊息。

取得轉移動作

上述步驟中的每個驗證檢查都會設定或清除相同的變數:validation_passed.該變數現在正在執行其最重要的工作。execute_transfer 動作條件式可用,這表示只有在 validation_passed 為 true 時,它才會顯示在 LLM 的工具清單中。在每個前述檢查皆通過並設定該變數之前,動作不存在於 LLM 的觀點。

這是套用至生產工作流程之較早門區段的模式。提示指示不會隱藏轉移動作。其會由平台隱藏。沒有多少對話壓力或不明確的用詞可能會導致 LLM 在符合先決條件之前叫用它。

下列指令檔顯示門的設定方式。available when 子句會直接參照 validation_passed,且動作參數會繫結至在上一個步驟中收集並驗證的工作階段變數。

所有三個參數 (from_account、to_account 和 amount) 皆會從工作階段變數決定性傳遞。當此動作可用時,每個值都已經過驗證。LLM 不會從交談內容組合參數;它會從狀態讀取參數。

追蹤整個工作流程的狀態

上述區段中的模式僅能運作,因為工作階段狀態會持續在整個工作流程中。在第 4 個步驟中可使用在第一個步驟中共用的帳戶號碼。在另一個檢查門動作中設定驗證結果。對話可能偏離,使用者可以詢問追蹤問題,而工作人員仍會確實知道其在流程中的位置。

下方的變數區塊會顯示此工作流程的完整工作階段狀態。每個變數都有定義的類型、預設值和描述。有兩個變數處理大多數的協調流程工作:validation_passed 會控制每個門的動作可用性,而 validation_information 會帶有檢查失敗原因的可人讀內容,LLM 可以向使用者顯示此內容,而無須考慮基本狀態。

每個變數都會以已知的預設狀態開始。字串預設為空白、數字為零,而 validation_passed 布林值為 false。這表示門預設為關閉。工作流程必須主動取得在每個步驟中繼續的權利,而非從開啟門開始並依賴檢查將其關閉。

銀行轉帳範例說明決定性邏輯是正確的工具,但並非永遠是最佳選擇。瞭解邊界與瞭解模式一樣重要。

當工作流程需要保證的執行順序、錯誤具有重大後果、流程需要產生可重複的稽核追蹤,或業務規則定義足以表達為條件和值時,決定性邏輯是正確的選擇。財務、醫療照護和保險工作流程通常屬於此種類。

當互動的價值在於彈性而非精確度時,純粹的 LLM 推理不含嚴格的決定性限制更有意義。開放式客戶支援、早期階段的產品,其中業務流程仍在演進中,以及低率的資訊查詢,都是 LLM 推理的變異性是一項功能,而不是問題。

在實際上,大多數生產工作人員都需要兩者。邊界落在何處的決定不是決定性與可能性之間的二進位選擇;這是您在節點層級為工作人員工作流程中每個部分所做的設計決策。

邊界是設計決策

銀行轉帳範例是設計哲學的插圖:確定性執行與 LLM 推理之間的邊界是您在建立生產工作人員時所做的最具影響力的結構決定。

請放置過於嚴格的邊界,而您會發現工作人員嚴格、維護成本昂貴,且無法處理實際對話的自然變化。以相反的方向取得錯誤的邊界會建立一個有彈性但無法預測的工作人員、在測試中表現良好但在生產環境中行為不同,且無法產生可靠的稽核追蹤,或無法信任高利潤交易。

新的 Agentforce 模型為您提供工具以刻意放置該邊界。「工作人員指令檔」可讓您在相同的檔案中表達決定性邏輯和提示指示,並使用明確的語法讓邊界可見。「Atlas 原因引擎」會在執行階段強制執行邏輯和提示。before_reasoning 和 after_reasoning 區塊可讓您在 LLM 呼叫的兩側擁有保證執行區。條件式動作可用性可確保 LLM 只能在符合先決條件時執行。

這些功能都不會隔離。他們會共同合作,為企業可透過任務關鍵工作流程 Trust 的建立工作人員建立一致的結構。混合式推理模型會識別決定性與彈性皆在您的結構中扮演角色;這是結構設計師的工作,才能確切決定每個項目適用的位置。

工作人員指令檔配方

Agentforce 開發人員指南

Agentforce 的工作人員圖表:透過混合原因導向決定主義

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

Miriam McCabe 是 Architect Evangelism 小組的資深主管和主管。她的工作著重於讓全球 Salesforce 結構設計師社群能夠透過深度技術內容、即時程式設計和社群參與,在代理階段領導。在 LinkedIn 上跟隨她。