工作人員企業的資源和成本最佳化
自動工作人員使用 Salesforce 資源的方式與決定性自動化不同。工作人員的工作量無法預測且持續,而非固定且繫結於交易。「資源和成本最佳化」支柱的「每成本的價值」討論會直接帶入工作人員企業。資源效率表示使用您已付費的容量,而成本最佳化表示刻意將支出引導至獲得回報的自發功能。工作人員會變更兩者的形式。有效的工作人員設計可控制耗用,並讓定價模型選取、擁有總成本 (TCO) 建模和財務管理使支出與價值保持一致。此文件將資源效率和成本最佳化視為一項決策,因為對於工作人員而言,這兩項是同一個目標的兩個觀點。
工作人員會變更耗用的可預測性。傳統 Apex 程序會在已知記錄集上運作,且具有已知資源成本。工作人員會以對話方式作業,且單一對話可以執行數十個動作,以作為工作人員原因完成工作。每個動作都會在其自己的交易中耗用管理員限制,而非在整個對話中加以累積。一輪內容準備可能會查詢 200 筆或 20,000 筆記錄,視使用者提出的要求而定。API 耗用會加速,因為工作人員可以自主採取動作,而主動、輸出和排程的工作人員會持續採取動作,而不只是在使用者交易期間。此無法預測的原因是工作人員資源管理必須依設計進行防禦,而非在耗用量高峰發生後進行調整。
成本端也同樣地改變。自動工作人員導入以耗用量為基礎的定價,其行為與傳統的每個座位授權不同。Agentforce 提供兩種以耗用量為基礎的定價模型:「彈性信用」與「對話」。每個工作人員部署都會選取下列其中一個模型。組織一次使用一個耗用模式,但「每位使用者」附加元件 (每月提供給每位使用者以取得未測量使用量) 可以與耗用模式並排,讓面向客戶的工作人員在「彈性信用」或「每對話」上執行,而員工則使用未測量授權。Data 360 可透過向量搜尋和提取來強化工作人員奠基,並耗用資料處理容量,而 MuleSoft 可啟用耗用 API 容量的工作人員整合。這些變數成本會依工作人員用量分級,這會建立需要針對變數而非針對固定年度訂閱所建立財務管理的投資模式。
在 Agent Enterprise 中針對業務價值而設計且成本最佳化的解決方案,可透過大量處理記錄的動作、嚴謹的內容視窗和快取來確保工作人員耗用效率。他們也會透過正確的定價模型、完成 TCO 建模,以及根據業務成果持續監控成本,來刻意導向支出。若沒有對齊方式,則工作人員部署會累積成本,而不會顯示比例值,且工作人員在未繫結迴圈中的原因會比人力監督介入更快地燃燒信用額。保持工作人員在其管理員限制內的相同效率工作會使其在其信用預算中保持,這是以代理詞彙表示的支柱論文。
此文件涵蓋當工作人員出現在圖中時的變更。如需適用於每個 Salesforce 解決方案的基礎資源和成本最佳化模式,包括效能最佳化、管理員限制、TCO 分析和授權規範,請參閱「資源和成本最佳化」支柱。工作人員管理與人力監督連接至「Trust」與「 Fairness」支柱,這些支柱涵蓋可確保自主行為安全且負責的計畫元件。
工作人員資源耗用會遵循與「流程」或 Apex 相同的平台機制,但其無法預測的對話驅動叫用會使耗用難以預測,因此需要防禦模式。您的最佳化責任跨動作鏈、API 耗用、回應延遲、Data 360 奠基效率、內容視窗管理,以及可組合設計,讓工作人員無須重複進行調整。每個責任都是每個成本的價值決策,而不是技術性決策,因為工作人員在每個交談中重複出現效率不佳。
工作人員會叫用觸發 Apex、流程和整合的動作。單一對話可透過複雜工作,以工作人員原因執行數十個動作。基礎的規則與任何 Salesforce 解決方案相同,但無法預測的叫用模式會提高興趣。設計動作以接受集合,讓更新 50 個個案的工作人員叫用一個動作,而非 50 個個別通話。在記錄集合上作業的單一動作會為相同工作耗用較少的 Salesforce 物件查詢語言 (SOQL) 查詢和資料操作語言 (DML) 作業。請刻意管理動作鏈間的 SOQL 預算,因為當每個動作執行自己的數個查詢時,叫用 10 到 15 個動作的工作流程會接近或超過 100 個查詢的同步限制。使用關係查詢以在單一陳述式中的父系和子系資料,並參照在相同對話內跨動作在平台快取中快取的資料。這兩種作法可讓多動作鏈保持在其預算內。
將超過同步限制的工作人員作業移至「可排列」或「批次 Apex」,其中非同步內容大致會將工作可用的 SOQL 和 CPU 主機空間倍增。大型分析作業 (例如評分 1,000 個商機或分析跨歷程記錄個案的情感) 屬於非同步處理,而非封鎖對話。大型語言模型推斷本身會在 Salesforce 外部發生,並耗用「彈性信用」,而非 Apex CPU 時間,因此您設定檔的 CPU 預算會被動作邏輯、資料轉換和工作人員觸發的整合所耗用。父系記錄與數千個子系記錄相關聯的資料誤差情況,應特別注意工作人員的防禦性。此漏洞是因為工作人員可能會針對具有數萬筆相關記錄的帳戶要求「所有歷程記錄」,而決定性查詢從未如此。使用實子系記錄限制和分頁來設計動作,並在數量超過資料排除的值時套用取樣。這些限制可防止無法預測的要求轉變為未繫結的查詢。Agentforce 工作階段追蹤會識別哪些動作會在工作階段層級耗用過多查詢,而「規模中心」會監視整體 Apex 交易績效和組織狀況。
工作人員結構會使用 API 比使用者驅動的工作流程更快,因為工作人員會以獨立的方式作業,針對主動或排程的工作人員則會持續進行作業。工作人員呈現的方式決定其減少 API 產能的方式。透過 REST API 叫用的工作人員會在每個交談輪數中耗用一個通話。透過標準元件內嵌在 Lightning 頁面的工作人員不會耗用每個互動的 API 呼叫,雖然其成本仍會以所選定價格模型的信用額或對話來測量。讓直接 REST 呼叫耗用 API 容量的自訂 Lightning Web 元件。建立在 Lightning Data Service 電線轉接器上的元件不會,因為 Lightning Data Service 從共用的用戶端快取提供服務,而非發出 API 呼叫。在試用版期間監視「事件監視」中的耗用,以便您在完整首展之前瞭解實際使用量。
以事件為導向的模式是浪費工作人員 API 耗用的最大杠杆。當條件需要工作人員介入時,發佈平台事件可避免排程輪詢,這會消耗 API 呼叫,無論是否有工作要進行,且訂閱「變更資料擷取」事件的工作人員會維持目前內容,而不需要外部協調員以其他方式進行的每日輪詢呼叫。每個成本的價值邏輯是直接的:找不到任何工作的投票是無需花費的容量,而只在實際變更上觸發的事件是僅在實際工作上花費的容量。透過增強檢視的產生會增加其本身的耗用量,因為針對 Data 360 的每個向量搜尋都會耗用運算,因此請針對僅傳回工作人員實際使用的結果,來設定取用限制。
工作人員輪數的延遲是 LLM 推斷時間、動作執行時間、Data 360 查詢時間,以及這些步驟依序執行時的整合時間總和。若未執行,則為最長的並列分支加上任何連續步驟。延遲是一種成本考量事項,也是一種體驗考量事項,因為緩慢的動作會使資源保持開啟的時間較長,而挫折的使用者會開始比已解決的對話更多的對話。較短的提示會產生更快的回應,因此請移除粗略的指示、冗餘的範例和不必要的內容。選擇性內容會改善延遲與回答品質,其中詳細的內容存放只會增加雜訊。透過針對索引欄位、大量處理和快取參考資料的選擇性 SOQL 讓動作保持快速,因為 3 秒的動作會變成瓶頸,無論推斷的速度為何。使用「查詢計畫」工具驗證動作查詢,以識別可增加動作延遲的完整表格掃描。
當工作人員產生器之間沒有相依性時,工作人員產生器協調流程可以並行執行動作,例如,當兩者之間的相依性較慢,而不是兩者之間的總和,則同時需要多長時間才會提取帳戶詳細資料和相關機會。針對查詢多個下游系統的通話,請將 Agentforce 與如 MuleSoft 等整合平台配對;工作人員叫用單一動作,MuleSoft 接收要求並向後端系統發出並行呼叫,然後傳回一個彙總回應。平台快取會移除重複要求的推斷與查詢延遲,並非同步處理非緊急工作 (例如長文件分析),可讓工作人員立即確認要求,並在結果準備就緒時傳回結果,而非保持對話開啟。
Data 360 提供向量搜尋,以目前資料為工作人員回應的基礎,而非僅以模型的訓練資料為基礎,其效率會管理奠基品質和您用於達成的運算。切分、內嵌選取項目、中繼資料篩選和結果限制是最有價值的決定。將 Knowledge 切片為語意上有意義的區段,因為太小的區段會強制針對一個問題的多個提取,而太大的區塊會用不相關的內容來減少相關性,並使引入推斷的權杖預算膨脹。選擇與您工作人員實際查詢方式相符的內嵌模型,因為問題-回答的類似度與文件分類的行為不同,並根據代表查詢驗證選擇。將語意相似度與中繼資料篩選條件結合在一起,讓業務限制會持續不論相似度為何,例如從建議中排除已停用的產品,無論比對程度為何。設定 top-k 限制以僅傳回工作人員使用的結果。例如,如果有 5 個結果告知回答,則會將 45 個未使用的結果新增至奠基裝載和權杖預算。
統一設定檔具有高資源效益,因為查詢一個 Data 360 統一設定檔的工作人員會在單一作業中提取完整的客戶內容,而不是針對每個輪數針對「帳戶」、「連絡人」、「機會」、「個案」和「行銷活動」協調個別的查詢。在法規需求的區域中設定 Data 360 例項,讓處理指定管轄範圍資料的工作人員查詢保留其內部個人資料的例項。
大型語言模型內容視窗會保留有限數量的權杖,管理該預算可讓長時間的對話保持一致,而不會耗盡容量或放大每個推斷呼叫的成本。刻意排定優先順序,而非任意截斷:最近對話歷程記錄的優先順序最高,重要業務資料 (例如目前記錄狀態和權限) 優先順序第二,而舊歷程記錄只會在空間允許時包含在內。在前幾個輪數之後,將先前的交談摘要整理為簡要概觀,該概觀會保留重要事實,而不包含完整的文字記錄。此摘要可保留連續性,而不會增加權杖預算。在 Data 360 或自訂物件中將延伸的內容儲存為依需求查詢的外部記憶體,而不是在每個呼叫中重新播放完整的歷程記錄,並僅傳回每個動作中的必要欄位,因為當工作需要 8 時,帶有記錄的所有 50 個欄位的回應會花費更適合交談或奠基的內容預算。
從可重複使用的元件建立工作人員可降低開發和維護成本。一次建立且重複使用的功能在其生命週期中比針對每個工作人員重新實作並分開維護的相同功能便宜得多。涵蓋記錄作業、批准、通知和驗證的集中化動作文件庫可讓平台小組在每個耗用工作人員之間維持一致的行為、安全性和效能,並讓新工作人員能在幾天內由經過驗證的建構區塊組成,而非透過數週的自訂動作建立。具有明確網域界限的專注專家工作人員會維持比單一通用工作人員嘗試每個案例更窄的內容和更明確的行為,而工作人員產生器會在工作跨網域時協調專家。提示詞產生器中經過驗證的提示提示範本會針對奠基、推理和回應格式化的驗證模式,以便隨著開發加速,品質保持一致,而 Data 360 中的共用 Knowledge 庫會從單一來源奠基許多工作人員,因此更新會立即接觸到每個消費者,而不需要對每個工作人員進行變更。
企業小組越來越多地共同撰寫多個工作人員,而非建立單一單一的工作人員,其中協調程式工作人員會拆分要求並委派給專家子工作人員,或專家工作人員會在交談跨網域時彼此交付。此組成會提出超出單一工作人員所面對的資源和成本問題,因為協調流程負擔、工作人員之間的 Trust 和狀態轉移會整個鏈結中產生複雜的問題,而不是僅限於一個動作。將協調流程提示保持狹窄,僅限於分類意圖和路由,而不是要求協調流程器也考量基本工作,因為該考量屬於含有相關內容的子代理程式,並且涵蓋鏈深度,除非使用個案明顯需要比協調流程器對子代理程式更深入的巢狀。將每個子工作人員回應視為不受信任的輸入,就如同外部 API 回應一般。在對其採取行動之前,請先驗證其預期狀態與業務規則合規性。針對每個工作人員動作強制執行欄位級安全性和獨立共用。
僅傳遞接收工作人員所需的狀態,使用記錄識別碼、工作摘要和相關欄位的結構化運送裝載,而非轉送原始對話歷程記錄,因此在整個鏈結中權杖預算會保持控制,並在 Data 360 或自訂物件中持續存在跨工作人員工作階段狀態 (當運送必須跨個別交易生存)。管理員限制適用於每個工作人員,而非每個對話一次,因此鏈結中的每個工作人員都會提取自己的 SOQL、DML 和 CPU 預算。一個協調器與三個子工作人員的鏈結會耗用每個限制超過四倍,而更深層的鏈結會進一步將耗用量乘以。相同的乘法會提高成本,這會使未繫結鏈深度的成本風險比管理員限制的成本風險更高。
定義當子工作人員失敗、逾時或傳回低信賴結果時,協調程式會執行的動作,無論是限制重試、回復回應或升級至人類,讓單一子工作人員逾時不會串聯至整個鏈結失敗。將每個接觸的工作人員之間的要求與透過運送裝載移入的共用追蹤識別碼相關聯,因為若要診斷鏈結中的哪些工作人員造成延遲高峰或成本高峰,則需要在不同工作人員工作階段之間手動建立記錄的關聯。
失敗的動作和失敗的子系工作人員呼叫不僅會影響可靠性,因為每次重試都可能會重新執行已在失敗嘗試上花費的 SOQL、DML 和 CPU 工作,且在多工作人員鏈中,此成本會與失敗的下游工作人員數量相結合。在以耗用量為基礎的定價下,相同的失敗複合會耗用並計算:「彈性信用」下的重試動作會重新耗用信用額。設計重試邏輯以考慮可靠性和成本。在決定如何回應之前,請先區分暫時失敗 (例如呼叫逾時或鎖定爭用) 和邏輯失敗 (例如驗證錯誤或格式錯誤輸入),因為暫時失敗可能值得一次限制重試,而邏輯失敗在重複時會完全相同,且只會為應立即升級的保證重複失敗耗盡預算。
針對每個動作重試兩次或三次嘗試,並在兩次嘗試之間套用指數反向,而非立即重新叫用,因為對 SOQL 或 DML 繁重動作進行的未繫結或窄迴重試可能會耗盡單一交易內的同步限制,或在多個工作人員對話中燃燒累積鏈預算和累積信用支出。設計動作,讓重試通話產生與單一成功通話相同的端狀態,使用如要求識別碼或具有更新插入邏輯的外部識別碼等無效金鑰而非插入,讓重試更新相同的記錄而非建立重複的記錄;缺乏無效的動作會強制重試透過重複的下游記錄重複資源耗用,或針對已發生一次的工作重複帳單動作或交談。
追蹤鏈結中每個工作人員的完成狀態,因為一個工作人員的動作可以在下游工作人員失敗之前成功認可 DML,而知道已成功的失敗處理常式可以從失敗點補償或恢復,而不是重新啟動和重新帳單整個鏈結。當已限制的重試正在進行時,請向一般使用者呈現重試或進行中狀態,因為看到靜音並重複其要求的使用者會觸發全新的交談和新的動作集,並將原始嘗試的資源和帳單成本加以複製。
此文件中所述的資源最佳化模式只有在結構設計師能夠瞭解工作人員在生產環境中執行時,實際花費 SOQL 查詢、CPU 時間、DML 列和權杖的時間,才有幫助。若沒有每個動作與每個工作階段的可視性,則限制缺口或延遲迴歸會顯示為症狀,而無法將其追蹤回造成的動作或鏈結中的工作人員。此疑慮與 Digital Wallet 在「成本監視與財務管理」下提供的支出可視性不同。Digital Wallet 會顯示工作人員耗用的信用額或對話數量,而工具則會顯示為何耗用該信用額或對話,在驅動該耗用的個人查詢、DML 列或動作層級。正確的工具取決於指定客戶的組織和支援協議實際授與的內容,而非理論上最適合的工具,因此請將建議與您的授權和存取層級比對,而不是預設為可用的最強大工具。
任何結構設計師都可以建立在每個動作和子工作人員叫用開始和結束時觸發的「自訂平台事件」。這些事件只會使用標準平台功能來追蹤對話的執行,並將動作層級記錄與自訂物件配對,這些物件會在每個動作執行動作時捕捉 SOQL 查詢計數、CPU 時間、DML 列數和堆疊用量。無論版本或附加元件授權為何,這兩種事件都可以透過報告或 SOQL 查詢,並為每個組織提供基準診斷功能。「事件監視」早前針對在試用版期間追蹤 API 耗用量所導入,也會針對組織包含該附加元件的客戶,在組織範圍內呈現工作人員工作階段的彙總資源使用模式,讓結構設計師識別哪些工作流程在許多交談之間趨勢為管理員限制,而非一次診斷一個工作流程。「刻度中心」提供即將達管理員限制的交易深入追蹤,通常透過「支援」參與存取,或直接在授與交易的帳戶層級可供存取。
獨立版本化工作人員可讓您控制首展、回復和比較,進而保護在您改善工作人員的投資。盡可能使用「自訂中繼資料類型」和提示詞產生器來推動組態中的行為,讓管理員無須開發週期即可調整提示範本和動作選取項目。使用試用版 A/B 測試功能將小型使用者子集路由至試驗版本。完整首展前比較品質、滿意度和工作完成度。此比較會驗證實際使用情況的改善方式,並在限制曝光時偵測迴歸。定義元件之間的明確介面契約,指定輸入、輸出、錯誤和效能預期,以便在不修改依賴該實作的工作人員的情況下取代實作。
工作人員經濟性從根據業務價值測量的總擁有成本開始,但以自發工作人員的耗用量為基礎的定價可使成本端以傳統授權所未有的方式運作。您選取的定價模型是基礎結構決策,因為它會決定您在整個工作人員生命週期中最佳化的項目。此區段會建立定價模型、工作人員實作的完整 TCO 圖片,以及工作人員功能的建立與購買決策。
Agentforce 提供兩種以耗用量為基礎的定價模型,且組織為指定工作人員部署選取其中一個。每個工作人員動作的「彈性信用」價格,可讓行動效率成為成本控制的杠杆。無論對話的長度或複雜度為何,每個對話的「每對話」定價都會收取固定費用,這會使對話容納率成為支柱。「每位使用者」訂閱會以員工面向的附加元件 (而非第三個耗用模式) 提供未測量的工作人員用量,並將最佳化焦點從耗用效率移至採用,因為價值來自授權使用者主動參與工作人員,而非最小化每個互動。兩個耗用模式並非針對同一個組織混合,但「每位使用者」附加元件 (每月提供給每位使用者以取得未測量使用量) 可以與耗用模式並排,讓面向客戶的工作人員在員工使用未測量授權時在「Flex Credits」或「Per-Conversation」上執行。
在「彈性信用」下,每個動作的動作成本會固定至定義的權杖上限。不同於以權杖為基礎的推斷定價,信用額度不會隨提示長度或模型複雜度而有所不同,因此一個句子回答與多段落回答的成本相同。多動作互動會耗用每個動作的信用額,因此會在取用資料、原因和更新記錄的互動會耗用三個動作的信用額,並在推理之前透過向量搜尋和文件提取新增進一步的動作。因此,瞭解每個業務交易的平均動作數是「彈性信用」下的成本建模先決條件。
在「每個交談」定價下,每個交談會套用固定費用,且一個工作階段內的多個輪數會計為單一交談,因此成本控制來自於在一個交談中解決問題並定義明確的工作階段邊界,而非裁切個別動作。Data 360 奠基與 MuleSoft 整合會與所選的模型一起耗用自己的容量,因為內嵌產生與相似度搜尋會降低每個奠基查詢的資料處理容量,而每個外部動作會耗用來源與目標系統的 API 容量。
工作人員實作的總擁有成本 (TCO) 涵蓋六個種類,並且將全部六個種類建模,可將信用評估轉換為明智的投資決策。開發成本涵蓋工作人員設計、提示工程、整合開發和測試,從簡單的單一用途工作人員到具有複雜協調流程的多重工作人員系統,範圍廣泛。推斷成本取決於選取的定價模型,且需要在「彈性信用」下建模預期的動作量、在「每對話」下建模對話量,或在「每位使用者」下建模授權的使用者計數。針對在大型 Knowledge 庫中奠基的工作人員,提供奠基功能的 Data 360 基礎結構可能會與推斷成本有競爭,或高於推斷成本。基礎結構成本涵蓋 Data 360 和 MuleSoft 授權、額外的 Sandbox 和監視基礎結構,且其主要是以容量層級為基礎的固定或逐步功能。營運成本涵蓋監視作業、提示精簡、事件回應和使用者支援,對於成熟的工作人員計畫,這些成本通常等於每年有意義的開發成本部分,這符合 AI 工作人員的一般產業基準,而非 Salesforce 特定的數字。管治成本涵蓋安全審查、人力監督、稽核記錄和合規性驗證,這會隨著工作人員的自主性和風險而增加,而「公平」支柱涵蓋重要的計畫元件。變更成本涵蓋使用者訓練、業務流程適應和組織變更管理,且這些是種類小組最常被低估的種類。
建立預測 3-5 年成本的試算表 TCO 模型。記錄互動量、動作計數和成長的假設。執行敏感性分析以識別最影響總計的假設,然後將驗證著重於這些假設。請先將所有三個成本結構 (「彈性信用」、「每對話」與「每使用者」) 根據預測使用量建立模型,再認可,因為最佳結構取決於使用模式,且當工作人員在生產環境中時,錯誤的選擇會花費大量的費用來放置。
工作人員的建立與購買決策會遵循與任何 Salesforce 功能相同的邏輯,將現成解決方案的立即價值時間對照 3–5 年 TCO 跨度自訂組建的精確合適進行加權。商品工作流程偏好購買,而推動專屬區分的核心功能則是建立的理由。「代理企業」提供多種選項,而非二元選項。預先建置的 Agentforce 工作人員 (例如服務代理或銷售開發代表) 透過快速部署和平台維護的更新,提供已驗證的功能。他們在所選定價模型下耗用信用額。來自 Salesforce 獨立軟體廠商 (ISV) 社群的商業可用工作人員會透過 AgentExchange 提供,您可以在其中找到已符合需求的解決方案,而非建立解決方案。使用「工作人員產生器」建立的自訂工作人員可提供精確的適配性和具競爭力的差異,而不需要事先開發,再加上持續的提示精簡和維護。透過提示詞產生器和動作組態自訂預先建立的工作人員,提供的中間價格低於完整自訂開發,同時仍可使工作人員適合您的組織。除了成本之外,請將時間對值需求、內部開發能力、策略差異和廠商相依性容忍權加權,並在結構決策記錄中記錄決定,以便在需求變更時重新評估。
若實作工作人員清楚瞭解基本成本結構,則可讓自發能力以永續方式擴充,而非耗用預算集區。最佳化杠杆取決於定價模型,因為您調整來控制成本的項目會在每個動作付款、每個交談付款和每個使用者付款之間有所不同。原則在這三者之間都是常數:根據實際交付的值調整耗用,讓有能力的工作人員不會安靜地燃燒其預算的速度比其傳回業務成果的速度快。
在「彈性信用」下,最佳化表示將每個業務成果的動作最小化,同時保留品質。透過單一動作解決簡單的要求,而非透過多步驟工作流程,讓回答常見問題或執行例行對應不會耗用三個動作鏈的信用額。將作業合併到一個有意義的單一動作中,結合搜尋、分析和回應,而不是分別為每個動作付款。快取重複要求的回應,讓經常詢問的問題由快取提供,而不是在每個相同查詢上取用新動作,這是此模型中當有意義的查詢比例重複時的最大效率杠杆。
在「每對話」定價下,最佳化表示在單一對話內解決問題,而非跨多個對話。設計工作階段邊界和逾時,讓交談持續適當,而不會過早終止並強制進行新的可計費交談。將工作人員功能專注在第一個對話解決方案上,讓工作在初始對話內完成,而不需要追蹤。追蹤第一個對話的解決率作為成本效率度量,並不鼓勵使用者針對現有對話內容可能已處理的相關問題開啟個別對話的範圍擴充。
在「每位使用者」訂閱下,最佳化表示最大化每個授權使用者傳回的值,因為耗用量是未測量的,且每個座位的成本是固定的。專注於採用,讓授權使用者主動與工作人員互動、追蹤利用率以識別低用量使用者以用於鎖定目標的訓練或授權重新配置,並依使用者族群將工作人員互動連結至業務成果,讓高價值使用個案正確投資,而低價值使用量表示需要最佳化或不同的定價模型。請依步調檢閱使用者族群,讓授權與實際用量保持一致。
無論定價模型為何,結構都會影響成本。實作以簡單邏輯處理初始路由的分級工作人員,並僅在複雜性需要時將使用者導向至專門工作人員,如此一來,只有在獲得保證時才會發生昂貴的複雜叫用。針對以規則為基礎的邏輯足夠的決定性案例,請返回傳統自動化,讓「流程」以更低的成本處理決定性路徑,同時工作人員處理真正需要推理的模糊情況。選擇性地取用奠基資料,只有在工作人員的推理需要時才叫用向量搜尋和文件提取,而不是在每次互動時,如此 Data 360 耗用才會追蹤實際需求。這些模式會使結構的推理與耗用成本與工作難度保持相對。
自動工作人員的成本監視比傳統工作量更困難,因為工作人員不會遵循可預測的要求回應模式。工作人員可以迭代多步驟推理、根據執行階段條件自適應地叫用工具,並協調其他工作人員,這會產生難以預測的高變數信用額度耗用。若無監視,執行深度反覆工作的工作人員在任何人介入前可能會耗用大量的信用額,而無效的提示設計或冗餘的推理迴圈可能會悄悄地耗用整個工作人員車隊的預算。因此,有效的管治需要對每個工作人員和每個作業的耗用量進行即時可見性、自動化警示,以及防止流失成本的控制,同時保留使工作人員有用的自主權。工作人員的財務管理也需要明確的擁有權和針對變數耗用而建立的分層批准,而不是針對靜態運算成本。
Salesforce Digital Wallet 是監視以耗用為基礎之產品 (包括 Agentforce 彈性信用) 的內建工具,使用「彈性信用」的組織應將其建立為主要成本監控機制,而非建立自訂顯示面板以複製其提供的內容。Digital Wallet 提供近乎即時的耗用資料,其中包含動作層級用量洞察、每個工作人員的細目,顯示哪些工作人員耗用最多、主動耗用警示,以及模式分析和預測的歷程記錄趨勢。將監視與定價模型進行比對。在「彈性信用」下,依工作人員、使用者族群、期間和動作類型追蹤耗用,並使用自訂顯示面板來補充 Digital Wallet,以將信用耗用與業務交易連線。在「每對話價格」下,監視對話量、平均長度和完成率。在「每位使用者」訂閱下,監視利用率而非耗用情況,追蹤每位使用者的作用中使用者和業務價值,以顯示授權投資以提供比例值。
每個互動成本歸屬會將耗用與業務交易連線,並顯示每個已解決個案、每個合格商機或每個已處理訂單的成本,這可啟用 ROI 計算和跨使用個案比較。預算警示會在耗用達到預算的 70% 和 85% 之間,隨著接近定義邊界時觸發通知,以便在達到限制之前進行最佳化。設定每個工作人員和每個使用個案的警示,而不只是組織範圍的警示,以將問題本地化為其來源。異常偵測會呈現突然耗用高峰,表示非預期的使用模式或需要調查的推理迴圈。與業務專案關係人和技術小組共用成本顯示面板,以便透明度推動感知成本的工作人員用量。
請先套用財務管理,再將費用認可至工作人員結構。針對在所選定價模型下涵蓋 3–5 年內預測 TCO 的工作人員投資,需要業務個案、含度方法的預期業務成果、與包括手動流程和傳統自動化等替代方案的比較,以及涵蓋品質、安全性和營運風險的風險評估。定義可將部門可授權的投資與需要執行批准的投資分開的批准值,以便高投資或高風險工作人員得到比例的檢查。要求在完整生產之前驗證假設的試用部署,因為試用版會顯示實際耗用、品質和採用,這會告知生產投資決策和定價模型選取。
以產品組合管理工作人員財產,而非依工作人員管理,因為產品組合檢視會顯示單一工作人員檢閱忽略的最佳化機會。檢閱所有工作人員,比較成本、使用情況、業務價值和策略對齊方式,並定義落後條件,以退休採用率較低、投資報酬率較差、功能過多或成本過高的工作人員,讓低價值工作人員不會無限期累積和耗用預算。將投資從績效不佳的工作人員重新分配至高價值的機會作為持續作法,可使支出與不斷變化的優先順序保持一致,而非一次性清理。
成本分配會建立工作人員耗用責任,組織會透過套用至其他平台的相同兩個模型來實作。回顯示會依業務單位報告工作人員的成本,不含內部費用,這會建立成本認知並通知最佳化討論,而無須爭用內部帳單。Chargeback 會將實際的工作人員成本分配給耗用業務單位,這會促進更強大的最佳化行為,因為成本會直接影響部門預算,但需要準確的配置方法來避免爭議。混合式方法會將負責回報套用至大量生產工作人員,同時針對實驗或少量工作人員使用顯示回報,這會將重大投資的責任與創新彈性的平衡。
工作人員結構會引入自己的永續性考量事項,因為大型語言模型推斷在運算上是密集的,而某些工作人員會連續執行,而不只是在離散的使用者觸發交易中執行。主動、輸出和排程的工作人員會在迴圈中沒有使用者的情況下運作,對話工作人員會在許多輪數之間累積耗用,而向量搜尋、內容準備和動作執行都會增加基礎結構負載。永續工作人員設計可將運算浪費降到最低,同時讓體驗保持反應性。如同「資源和成本最佳化」支柱,一個解決方案與資料中心排放的關係是間接的。單一租戶的效率不會直接降低排放量。不過,所有租戶的效率提升可協助 Salesforce 以更高的利用率執行其基礎結構,並延後產能擴充。以及「資源和成本最佳化」支柱中的基礎永續性作法適用於工作人員,以及後續的效率策略,這兩者都會解決大型語言模型支援對話系統特有的問題。每個項目都會降低成本,這就是為什麼根據不同成果測量的永續性與成本價值都是相同的規範。
推斷是工作人員結構中最具資源密集性的元件,因此透過提示長度、內容用量和快取來提高效率。透過移除粗略指示和冗餘範例,最佳化提示以以較少的權杖傳達意圖,因為較短的提示會減少預先填入計算的比例,即使它不會變更產生回應的計算。透過在前幾個輪數後摘要對話歷程記錄,並僅傳回每個動作中的必要欄位來管理內容視窗,如此一來,帶入每個推斷的權杖預算會保持繫結,而不會隨對話成長。
向量搜尋與統一設定檔查詢會耗用計算資源,因此控制奠基成本的相同結果限制與篩選規範也會減少奠基的基礎結構負載。設定 top-k 限制以僅傳回工作人員所使用的結果,因為當 5 通知回答時,會取得 50 個未使用的結果,這些結果不會耗用奠基權杖預算,並使用中繼資料篩選條件縮小搜尋的相似度排名。查詢統一設定檔以在一個作業中組合完整的內容,而非針對每個輪數的多個物件發出個別查詢,並針對具有高使用者親和性的工作人員 (例如處理一組固定帳戶的銷售工作人員) 快取設定檔,讓重複的內容組合不會重複查詢。
工作人員動作會耗用 SOQL 查詢、DML 作業和 CPU 時間,因此「資源和成本最佳化」支柱的大量處理、快取和非同步規範會直接套用至工作人員動作。設計動作以接受集合,讓更新多個記錄是一次作業而非多個作業;使用關係查詢以在單一陳述式中檢索父系和子系資料;在平台快取中快取參照資料,並在整個集合中批次 DML,而非每個記錄。將超過同步限制的作業移至「可排列」或「批次 Apex」,以非同步方式處理非緊急工作,例如大量評分或歷程記錄增強,並在可能的情況下為離峰時段排程工作人員觸發的批次工作,以便負載在整個時間散佈,而非在營業時間內集中。監視非同步執行,使待處理項目表示產能規劃需求,然後才會失敗。
工作人員耗用模式會隨著使用量成長而演進,因此永續性需要持續監視,而非一次性通過。透過可用的用量距離測量追蹤每個推斷的平均權杖,讓遞增的提示大小呈現最佳化機會、監視交談長度分佈,讓未繫結的交談顯示工作邊界問題,並在「事件監視」中分析動作執行頻率,讓高頻率動作成為最佳化優先順序。檢閱 Data 360 查詢模式以尋找值得快取或預先計算的常見查詢、追蹤語意快取的達成率,以便低速率觸發口值調整,以及測量延遲百分位數,以便尾端延遲顯示任何瓶頸。定期檢閱工作人員的範圍漂移用量。例如,調查工作人員,其平均對話長度從少數輪數增加到多數輪數幾個月。限定工作人員的邊界,讓耗用回復計畫。某些監視面板會在彙總顯示面板中顯示使用情況,而非作為個別的每個推斷記錄,因此請在設計監視時確認您組態的確切距離測量。
資源最佳化會決定工作人員結構是否會隨人口成長和使用個案擴展而調整規模,而成本最佳化會決定該級度是否會傳回比例業務值。這兩個決策會形成單一要求:
- 結構效率:使用大量處理、跨動作鏈預算 SOQL 的設計動作、將繁重處理移至非同步、透過複合與以事件為導向的模式最佳化 API 耗用、透過優先順序與摘要管理內容視窗,以及從可重複使用的元件建立可組成的結構。
- 財務指引:刻意選取定價模型、在認可前先模型化完成 TCO、根據業務成果監視耗用,並透過分層批准和產品組合檢閱來管理投資。
掌握這些模式的組織會在平台限制內提供回應式的工作人員體驗,同時讓支出與工作人員傳回的值保持一致。
所有 Salesforce 解決方案的基礎資源和成本最佳化指南 (包括效能最佳化、管理員限制、TCO 分析、授權規範和成本管理) 都位於「資源和成本最佳化」支柱中。工作人員管理、人力監督和安全計畫元件連接至 Trust 和 Fairness 支柱。此文件中的詳細工作人員實作指引,涵蓋資源效率、經濟、動作最佳化、管治和永續性,會收集在工作人員模式庫中。