工作人員企業的可靠性

工作人員企業的可靠性

自動工作人員會導入與傳統 Salesforce 自動化基本不同的非決定性執行模式。當 Salesforce 流程與 Apex 遵循可預測的路徑,在受控制的條件下產生可重複的結果時,工作人員會動態地思考問題。例如,相同問題詢問兩次可能會採用不同的執行路徑、耗用不同的資源,並產生不同的結果。此非決定主義會建立可靠性挑戰,而傳統測試與監視方法不會解決這些挑戰。

工作人員可靠性失敗模式與 Salesforce 流程或 Apex 失敗不同。大型語言模型 (LLM) 推斷服務代表與 Salesforce 平台分開具有可用性特性的外部相依性。儘管出現提示指示,工作人員仍會產生反應,這有時會違反預期的結構。工作人員內容準備無法預期地耗用管理員限制。未繫結的資料檢索會對工作人員造成更嚴重的影響,因為工作人員可以要求開放式內容,而決定性查詢具有明確的範圍控制。

可靠的工作人員結構需要多層式回復鏈,其可順暢地降級—從複雜的工作人員、縮短內容的更簡單工作人員、決定性規則引擎,最後透過 Omni-Channel 轉移至人類處理。「平台事件」可使用檢查點模式強化可持續重試排列,讓失敗的工作流程能夠從上一個成功步驟繼續進行。斷路器會在「平台快取」中追蹤即時狀態的 LLM 服務健康狀態,並在連續失敗後由「自訂中繼資料類型」所支援,以用於達到值和組態,並路由至回復模式。監視需要追蹤對話成功率、失敗的平均間隔時間 (MTBF)、復原的平均時間 (MTTR) 和奠基準確度。Agentforce 觀察性提供工作階段追蹤、健康與延遲度量,以及升級和偏差率,但您仍需要自行儀表可靠度度量,例如 MTBF、MTTR 和定位準確度。

此文件涵蓋當工作人員出現在圖中時的變更。如需適用於所有 Salesforce 解決方案的基本可靠性模式 (服務層級物件 (SLO) 設計、錯誤容忍度、規模和監視),請參閱「可靠性」支柱。

Agentforce 工作人員失敗的方式與 Salesforce 流程或 Apex 不同。瞭解這些失敗模式是可靠性結構的基礎。

  • **LLM 服務無法使用:**LLM 推斷端點有時會遇到延遲高峰或可用性問題。Agentforce 會與 Analytics 和其他 Salesforce 服務一起在 trust.salesforce.com 上列為監視的產品。不過,細微的 LLM 推斷延遲和每要求效能度量不會在此處顯示。透過使用低延遲即時狀態的平台快取 (由自訂中繼資料類型支援以追蹤 LLM 服務狀況),來實作斷路器。最佳作法是「平台快取」:項目可以在其上線時間 (TTL) 之前遭到淘汰,因此在永久性商店 (例如「自訂物件」) 中會保留開啟/已淘汰狀態,而非僅限快取。將行程條件調整為端點:連續失敗計數 (例如,五個) 或超過滾動式時段時的錯誤率。當電路旅程時,請開啟電路並路由至回復模式,例如更簡單的提示、快取回應或人力轉移,直到成功的測試要求指示復原為止。
  • **回應驗證失敗:**儘管有提示指示,但工作人員有時會產生違反預期結構的回應。工作人員有時會傳回格式錯誤的 JSON、省略必要欄位,或包含非預期的資料類型。平台快取可以儲存經過驗證的回應結構描述,以啟用快速驗證。驗證失敗時,請使用精簡的提示進行重試,包括驗證錯誤和結構正確的範例。設定重試次數上限 (3–5) 以避免無限重試迴圈。
  • **幻燈偵測:**當奠基資料不完整時,工作人員會產生可信但不正確的資訊。不同於傳回「找不到」的決定性查詢,工作人員會使用推斷填補間隙。Einstein Trust 層稽核追蹤會記錄每個提示、遮罩的提示、回應、毒性偵測結果,以及使用者回饋意見以進行暫時治理審查。不過,它並不會捕捉逐步的推理追蹤。如需逐步的推理捕捉,請使用 Agentforce 工作階段追蹤,其會記錄推理引擎執行。要求工作人員提及 Data 360 (先前稱為 Data Cloud) 提取增強型產生 (RAG) 提取來源。交叉參照工作人員會針對採取的來源提出索賠,以便在動作執行前找出實際差。內嵌檢查會增加一點延遲,因為它會針對已經在內容中的來源執行。需要個別來回行程的檢查 (例如第二次模型通話或外部服務) 成本較高。將這些檢查保留給高度影響的寫入,包括財務或訂單更新,並在即時對話期間以非同步方式執行。
  • **管理員限制高峰:**工作人員內容準備會根據對話流程,無法預期地耗用 Salesforce 物件查詢語言 (SOQL) 查詢、CPU 時間和堆疊記憶體。Proactive Monitoring 是 Salesforce Success Plan 中「簽章成功」(先前稱為「簽章支援」) 的權益服務,Salesforce 會主動監視客戶帳戶。Proactive Monitoring 並非可供所有客戶使用的自助式服務可設定的警示。針對自助式服務管理員限制監視,請使用「級度中心」來識別即將達到限制的資源密集型工作人員作業。在工作人員動作中實作分頁,以檢取大型記錄集合。針對經常存取的參考資料,請使用平台快取。
  • **工作人員內容中的資料誤差:**針對擁有超過 10,000 個機會的帳戶或擁有比較大活動歷程記錄的個案,工作人員會遇到與批次 Apex 相同的資料誤差挑戰。不同於您控制範圍的決定性查詢,工作人員推理可能會以無法預測的方式要求「所有歷程記錄」。若要避免這種情況,請設計具有合理硬性限制的工作人員動作 (例如,每個父系有 200 個子系的上限),並在超過限制時實作取樣策略。此上限會限制輸入工作人員內容的資料量。將其與選用的索引篩選條件配對,讓查詢本身保持廉價,因為未編制索引的父系篩選條件或彙總會先掃描完整子系集,再套用上限。

設計多階回復鏈,讓工作人員能夠以較少的功能繼續運作,而不是完全失敗。

  • **具有完整內容的主要工作人員:**具有完整 Data 360 基礎、廣泛對話歷程記錄和複雜邏輯的精密工作人員。最高品質,但資源密集性最高且失敗風險最高。
  • **含簡短內容的次要工作人員:**使用精簡內容讓工作人員更簡單 (例如,過去 30 天與所有歷程記錄比較,前 5 個向量搜尋結果與前 20 天比較)。較小的內容表示權杖愈少、推斷愈快,失敗的可能性愈低,但只有在減少的內容仍涵蓋工作所需的資料時。
  • **決定性規則引擎:**傳統 Salesforce 流程或 Apex 邏輯,可在工作人員推理失敗時處理常見情況。規則無法適應新的狀況,但可靠地處理已知模式。訂單驗證工作人員返回標準驗證規則,而商機評分工作人員返回以規則為基礎的評分計算。
  • **透過 Omni-Channel 人力處理:**當自動化選項耗用時,路由至人力列表。設定以技能為基礎的路由,以確保升級到達適當的專長。傳遞完整的對話內容,包括嘗試的策略、您針對工作人員計算的任何信賴分數,以及失敗原因,以啟用有效的人工介入。

在協調流程 Salesforce 流程或由平台事件觸發的 Apex 中實作回復邏輯。每個層級都會記錄成功的策略,以便瞭解失敗模式和回復效率。

此區段中的所有「平台事件」模式都假設大量「平台事件」類型,其提供 72 小時的重新執行保留期間。標準量平台事件僅保留 24 小時。針對重新執行持續性為可靠性需求的所有工作人員彈性、重試排列和檢查點模式,使用大量事件類型。「平台事件」提供可持續傳訊功能,讓工作人員的工作流程能夠自動生存並復原失敗。

  • **檢查點工作人員進度:**多步驟工作人員工作流程會在每個成功步驟之後發佈檢查點事件。契約處理工作人員會完成文件解壓縮、發佈「ContractParsed」事件以及已解壓縮的資料,然後繼續進行子句分析。若子句分析失敗,請重新執行 ContractParsed 事件,以從解壓縮的資料繼續進行,而無須重新剖析。當檢查點裝載帶有該資料且訂閱者為專用時,這會運作,因為重新執行會重新傳送事件,而非恢復工作流程的步驟中。在事件裝載中儲存檢查點狀態,包括關聯性識別碼、已完成的步驟,以及繼續所需的狀態。
  • **具有指數反斜線的重複排入:**失敗的工作人員要求會發佈至具有裝載中重試計數的 AgentRetryRequested 事件。事件訂閱者會處理具有指數反向延遲的重試 (例如 30 秒、2 分鐘、8 分鐘、30 分鐘)。重試次數上限 (通常為 5) 之後,路由至無效字母的到達排隊和警示作業。大量平台事件會保留 72 小時的重新執行期間。將大量事件類型用於工作人員重新嘗試排列,讓訂閱者能夠在組織維護期間或部署停機後接觸。「標準量平台事件」僅保留 24 小時。
  • **事件驅動的協調流程:**將工作人員工作流程設計為寬鬆連接的事件鏈。商機建立會發佈 LeadCreated。商機評分工作人員訂閱、評分和發佈 LeadScored。商機路由工作人員會訂閱 LeadScored,並指派給適當的人列。每個工作人員都可以獨立失敗並重試。單一工作人員失敗不會封鎖整個工作流程—下游工作人員在相依性復原時會處理。
  • **關聯性識別碼追蹤:**在所有相關事件裝載中包含關聯性識別碼作為自訂欄位。使用 Pub/Sub API by replayId (不透明且非連續的識別碼) 來重建 72 小時保留期間內的工作流程歷程記錄,以重新執行事件。若要啟用以關聯性識別碼為基礎的除錯,請實作訂閱者端模式,將具有其 replayId 和關聯性識別碼的傳入事件記錄至自訂物件,以啟用跨事件追蹤性。此記錄模式是您自己建立的自訂實作,不是原生平台查詢功能。

將超過同步限制的工作人員作業移至非同步內容,這允許管理員限制較高且逾時較長。

  • **大量工作人員作業的批次 Apex:**分析 1,000 筆以上記錄的工作人員會從批次 Apex 受益,其提供 200 個 SOQL 查詢、150 個 DML 陳述式 (最多 10,000 個 DML 列),以及每個執行方法 60,000 毫秒 (60 秒) 的 CPU 時間。處理每晚商機匯入的商機評分工作人員。跨歷程記錄個案的個案情感分析。分析完整銷售管道的機會預測。
  • **多步驟工作流程的可排列鏈結:**需要多個外部 API 呼叫、大量資料集分析或延長處理時間的複雜工作人員工作流程會使用可排列的 Apex 鏈結。每個「可排隊」工作會得到 60 個 CPU 時間和 12 MB 堆疊。將超過單一工作限制的工作流程鏈結到下一個「可排入排列」中。在「自訂物件」中追蹤進度,以便失敗的工作可從上一個完成的步驟繼續。
  • **簡單非同步處理的 @future:**輕量型工作人員作業 (例如傳送通知、登入外部系統或非緊急更新) 會使用 @future 方法。當工作流程不需要回傳結果,且可以容忍失敗時,便適合觸發忘記模式。

透過「Apex 工作」頁面 (「設定」→「Apex 工作」) 和「Apex Flex Queue」監視非同步處理容量。最多 5 個同時批次工作會限制並列工作人員的處理;Apex 彈性指南中可保留狀態為「保留」之最多 100 個工作的額外工作指南。所有非同步 Apex 類型,包括批次、未來、可排列和排程的 Apex,在非同步 Apex 執行上共用相同的組織範圍每日限制 (DailyAsyncApexExecutions):大於使用者授權數量的 250,000 或 200 倍。當您執行高頻率的工作人員輪詢或重試訂閱者到達到達時,Queueables 會快速耗盡此配額。若要避免這種情況,請批次或排序這些排入,以保持在限制之內—這在組織範圍中適用於所有非同步 Apex 類型,而不是僅作為 Queueable 的個別配置。當耗用達到這些限制時警示,讓小組可以主動管理產能。

透過解決非決定性行為的測試策略,驗證工作人員生產前的彈性。

  • **在 Full Copy Sandbox 中載入測試:**使用完整資料量測試工作人員在生產規模負載下的效能。模擬符合高峰需求的同時對話。測量 p95 和 p99 延遲,識別壓力下的效能降級。驗證管理員限制耗用會在載入量高峰時保持在下限。在少量資料的 Partial Copy Sandbox 中載入測試可提供誤導的信心,因為資料量會直接影響工作人員績效。執行這些測試之前,請先向 Salesforce 取得批准 (至少在效能測試要求提前一週)。無法批准的測試會遭到節流或封鎖。
  • **插入錯誤:**刻意導入驗證復原機制的失敗。在您的斷電器監視的服務層中模擬 LLM 推斷失敗,以確認斷電器已啟用。插入 SOQL 例外以測試錯誤處理。損毀工作人員回應以測試驗證邏輯。導入資料誤差 (具有 10,000+ 個子系帳戶) 以測試分頁邏輯。設定積極逾時以測試逾時處理和重試策略。
  • **混沌工程:**隨機停用「平台事件」訂閱者以測試重新執行復原。在執行期間終止非同步工作,以測試檢查點重新啟動。為外部系統導入變數延遲,以測試漸進式逾時策略。混沌實驗會驗證實際失敗組合的彈性。在暫存環境中排程固定混沌天數,隨著工作人員進化保持彈性。
  • **長時間執行穩定性測試:**連續執行工作人員的工作量超過 72 小時,以監視時間相依失敗。只有在持續營運時,才會累積錯誤並逐漸降低效能。追蹤 CPU 時間趨勢,以識別執行期間漸進式降級。

定義服務層級指標 (SLI),以啟用目標可靠性測量。在建立工作人員之前建立 SLO,而非在生產失敗後建立。

  • **對話成功率:**未發生錯誤或逾時的工作人員對話已完成百分比。將人類的禮遇視為成功,而非失敗—升級是設計上最後的回復層級。根據度量計算失敗或非預期的升級—這是一個有用的可靠性訊號,但對於使用者體驗而言是不完美的 Proxy,因為禮貌的註冊可以遮罩未解決的問題。請依工作人員類型與使用個案分開追蹤,因為商機評分成功條件與契約審查不同。當成功率下降至低於 SLO (通常是 95—99%) 時警示。
  • **失敗間平均時間 (MTBF):**工作人員失敗之間的平均營業時間。較高的 MTBF 表示失敗愈少,可靠性愈高。計算工作人員營業時間總數除以失敗計數。追蹤每個工作人員類型,以識別需要最佳化投資的最不可靠工作人員。
  • **平均復原時間 (MTTR):**從失敗偵測到服務還原的平均時間。透過平台事件重複執行和斷電器自動復原可更快恢復服務,且手動錯誤較實作介入更少。較低的 MTTR 可減少每個事件的業務影響。
  • **奠基準確度:**根據來源資料驗證,工作人員回應實際正確的百分比。針對 Data 360 來源驗證索賠的範例隨機工作人員回應。奠基準確率低於 95% 表示需要提示精簡或更完善的內容尋找的虛擬問題。
  • **平台事件重新執行間隙:**遺漏或未傳送的事件計數,例如超出保留時段的離線訂閱者。零間隙是健康事件驅動結構的正向訊號。缺口表示訂閱者問題、事件發佈失敗或容量限制。使用上述訂閱者端記錄模式追蹤這些間隙,並將每個事件的 replayId 和關聯性識別碼記錄至自訂物件。

可靠的工作人員來自一開始為失敗設計—在建立前定義 SLI/SLO、管理員認知限制內容處理,以及多層回復鏈,而不是在之後開啟。圖層斷路器和以平台事件為基礎的重試與檢查點邏輯,以便工作流程自動復原,以人力轉移為最後手段。透過系統式載入、錯誤插入和混沌測試來驗證該設計,然後在生產環境中持續監視相同的 SLI,以確認隨著時間保持不變。

主要「可靠性」 支柱中的可靠性指引適用於此處涵蓋平台特定考量事項的工作人員。成功的工作人員結構會將自助式功能與適當的監督平衡,在信賴下降或邊緣個案出現時啟用暫時失敗的自我復原,同時升級。

分享您對良好架構的回饋意見。