工作人員可靠性模式

深入瞭解結構良好的可靠性 → 代理企業可靠性

模式

要尋找的位置良好的外觀
平台 | 平台快取✅ 實作可在平台快取中追蹤 LLM 服務健康狀態的電路中斷器,以取得低延遲即時讀取項目,並由自訂中繼資料類型支援達到值和組態;由於「平台快取」是最佳工作量,因此會在永久性商店 (例如自訂物件) 中保留未結束/已淘汰狀態,而非僅限快取。在已調校的失敗值 (例如,連續五個推斷失敗) 上開啟電路,並路由至回復模式
平台 | 平台快取✅ 將驗證的回應結構描述儲存在平台快取中,以根據預期的結構快速驗證工作人員回應
Agentforce | 提示範本✅ 回應驗證失敗時,請使用精簡提示重試,包括驗證錯誤和結構正確的範例 (最多 3-5 次重試)
Agentforce | 工作階段追蹤✅ 使用 Agentforce 工作階段追蹤推理追蹤來檢查工作人員的推理路徑,並在其輸出中偵測幻覺
Data 360 | 向量搜尋✅ 要求工作人員提及 Data 360 向量搜尋來源,以便在動作執行之前,可以對對照搜尋來源交叉參照索賠
平台 | Proactive Monitoring✅ 針對具有「簽章成功」權益的帳戶,請依賴 Proactive Monitoring,Salesforce 人員可在其中監視組織是否有新增問題;這不是自助式服務可設定的警示
平台 | 規模中心✅ 使用「刻度中心」識別接近管理員限制的特定工作人員作業
Agentforce | 動作✅ 在工作人員動作中實作分頁,以檢取大型記錄集合
Agentforce | 動作✅ 設計具有硬性限制的工作人員動作 (每個父系最多 200 個子系),並在超過限制時實作取樣策略

反模式

要尋找的位置看起來怎麼壞
平台 | 自訂中繼資料類型⚡️ 允許不含斷電器的無限推斷重試,在 LLM 服務降級時建立無限重試迴圈
Agentforce | 提示範本⚡️ 重試失敗的工作人員回應,而不在重試提示中包含驗證錯誤和預期結構
Agentforce | 動作⚡️ 允許工作人員要求不繫結的內容 (例如「所有歷程記錄」),而不限制每個父系記錄的子系數量
Agentforce | 動作⚡️ 設計工作人員動作,在不使用分頁的情況下,便會取用大型記錄集合,導致管理員限制高峰
Einstein | Trust 圖層⚡️ 信任工作人員的回應,而無須針對奠基資料來源交叉參照的宣告,以允許幻覺達到動作執行
平台 | 組織⚡️ 將 LLM 服務可用性視為與 Salesforce 平台可用性相同,而非監視為個別相依性

模式

要尋找的位置良好的外觀
Agentforce | 工作人員組態✅ 設計多階回復鏈:full-context agent → reduced-context agent → 決定性規則引擎 → 透過 Omni-Channel 人力轉移
Agentforce | 工作人員組態✅ 使用精簡內容設定次要工作人員 (過去 30 天與所有歷程記錄比較,前 5 個向量搜尋結果與前 20 個比較),以降低失敗可能性
平台 | 流程✅ 在由平台事件觸發的協調流程或 Apex 中實作回復邏輯,記錄哪些層級成功可看見失敗模式
平台 | 流程✅ 建立決定性流程或 Apex 邏輯,在工作人員推理失敗時處理常見案例作為回復 (例如標準驗證規則、以規則為基礎的評分計算)
Agentforce | Omni-Channel✅ 為人力轉移設定以技能為基礎的路由,確保升級達到適當的專長
Agentforce | Omni-Channel✅ 將完整的對話內容傳遞至人類的排隊,包括嘗試的策略、工作人員信賴分數和失敗原因

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 設計具有單一執行路徑的工作人員,在任何元件降級時完全失敗
Agentforce | 工作人員組態⚡️ 針對回復嘗試使用相同的完整內容工作人員組態,而非漸進式簡化內容
Agentforce | Omni-Channel⚡️ 路由至人力處理,而不傳遞交談內容、嘗試策略或失敗原因,強制工作人員從頭開始
平台 | 流程⚡️ 未記錄哪些回復層級成功,無法看見失敗模式和回復效率

模式

要尋找的位置良好的外觀
平台 | 平台事件✅ 在多步驟工作人員工作流程中每個成功步驟後發佈檢查點事件,儲存關聯性識別碼、已完成的步驟,以及在事件裝載中繼續所需的狀態
平台 | 平台事件✅ 將工作人員工作流程設計為寬鬆連接的事件鏈,每個工作人員可在其中獨立失敗並重試,而不會封鎖整個工作流程
平台 | 平台事件✅ 使用在裝載中包含重試計數的平台事件,實作具有指數反向延遲 (30 秒、2 分鐘、8 分鐘和 30 分鐘) 的重試排行榜
平台 | 平台事件✅ 耗用重試次數上限 (通常為 5) 後路由至無效的信紙到達到該處和警示作業
平台 | 平台事件✅ 在所有相關事件中包含關聯性識別碼;使用平台事件重複執行 API 重建完整的工作流程歷程記錄以進行除錯
平台 | 平台事件✅ 利用可供大量平台事件使用的 72 小時重新執行保留時間範圍 (標準量事件保留 24 小時),藉由組織維護時間範圍或部署停機來保留重試排隊

反模式

要尋找的位置看起來怎麼壞
平台 | 平台事件⚡️ 建立不含檢查點的多步驟工作人員工作流程,在任何中間步驟失敗時需要完整重新執行
平台 | 平台事件⚡️ 重試失敗的工作人員要求,而無指數反向回應,從而對復原服務產生雜亂的羊群影響
平台 | 平台事件⚡️ 設計緊密連接的序列工作流程,其中單一工作人員失敗會封鎖所有下游處理
平台 | 平台事件⚡️ 從事件中省略關聯性識別碼,使其無法追蹤並除錯完成的工作流程執行
平台 | 平台事件⚡️ 無限期重試,不含重試計數上限或無效信號,在永久失敗的作業上耗用平台資源

模式

要尋找的位置良好的外觀
平台 | Apex✅ 針對分析 1,000 筆以上記錄的工作人員作業使用批次 Apex,利用非同步管理員限制 (200 個 SOQL 查詢、150 個 DML 作業、每個執行 60 個 CPU)
平台 | Apex✅ 針對需要多個外部 API 呼叫或延長處理時間的多步驟工作人員工作流程使用可排列的 Apex 鏈結;追蹤自訂物件的進度,以在失敗時啟用恢復
平台 | Apex✅ 將 @future 方法用於容忍失敗的輕量型 fire-and-forget 工作人員作業 (通知、外部記錄、非緊急更新)
平台 | Apex 工作✅ 透過「Apex 工作」頁面 (「設定」→「Apex 工作」) 和「Apex Flex Queue」監視非同步處理容量:最多 5 個同時批次工作 (「Flex Queue」中額外的工作排隊,狀態為「保留中」最多 100 個),以及組織範圍內非同步 Apex 執行 (DailyAsyncApexExecutions) 的每日限制 (大於每 24 小時 250,000 個或 200 倍的使用者授權數目),可在「批次」、「可排隊」、「未來」和「已排程 Apex」之間共用
平台 | 組織✅ 當非同步耗用達到啟用主動產能管理的限制時,在封鎖工作人員處理前進行警示

反模式

要尋找的位置看起來怎麼壞
平台 | Apex⚡️ 在同步工作人員交易中處理 1,000 筆以上的記錄,而非移至批次 Apex,僅幾筆記錄後達到 100 個 SOQL 查詢限制
平台 | Apex⚡️ 在不追蹤自訂物件的進度的情況下使用可排列的鏈結,以防止恢復失敗功能
平台 | 組織⚡️ 未監視 5 個同時批次工作限制或共用每日非同步 Apex 執行限制 (DailyAsyncApexExecutions — 每 24 小時大於 250,000 或 200 × 使用者授權的批次、可排隊、未來和已排程 Apex),導致工作人員處理會靜音排列或失敗

模式

要尋找的位置良好的外觀
平台 | 組織✅ 使用生產規模資料量在 Full Copy Sandbox 中載入測試工作人員效能;模擬符合峰值需求的同時對話
平台 | 組織✅ 在負載下測量 p95 和 p99 延遲,以識別在壓力下產生的效能降級;驗證管理員限制耗用會在高峰負載時保持低於上限
Agentforce | 工作人員組態✅ 執行錯誤插入:模擬您斷電器監視服務層中的 LLM 推斷失敗、注入 SOQL 例外測試錯誤處理、損毀回應測試驗證邏輯
Agentforce | 工作人員組態✅ 在測試期間導入資料誤差 (具有 10,000+ 個子系的帳戶),以驗證分頁邏輯處理最差案例
平台 | 平台事件✅ 執行混沌工程:隨機停用「平台事件」訂閱者測試重新執行復原、終止非同步工作執行中測試檢查點重新執行
平台 | 組織✅ 在暫存環境中排程固定混沌天數,隨著工作人員進化保持彈性
平台 | 組織✅ 執行長時間執行穩定性測試 (72+ 小時) 監視時間相依失敗:累積錯誤並逐漸降低效能
平台 | 組織✅ 追蹤延長期間內的 CPU 時間趨勢和堆疊耗用,偵測內容管理中的漸進式降級

反模式

要尋找的位置看起來怎麼壞
平台 | 組織⚡️ 在少量資料的 Partial Copy Sandbox 中載入測試,提供誤導式信心,因為資料量會直接影響工作人員績效
Agentforce | 工作人員組態⚡️ 僅測試 Happy 路徑,而無須刻意導入失敗,以驗證斷電器、重試邏輯和逾時處理
平台 | 組織⚡️ 僅執行短時間測試、缺少時間相依失敗 (累積錯誤、漸進式降級),僅在持續 72 小時以上的作業中顯示
平台 | 平台事件⚡️ 切勿測試平台事件重新執行復原或檢查點重新啟動,因此無法驗證彈性機制

模式

要尋找的位置良好的外觀
業務 | 文件✅ 在建立工作人員之前建立 SLO,而非在生產失敗後建立;為工作人員類型定義交談成功率目標 (通常為 95-99%)
平台 | 組織✅ 追蹤對話成功率作為主要工作人員可靠度度量:完成且沒有錯誤或逾時的交談百分比。將對人類的禮貌處理視為成功,因為升級是設計的最終回復層級;僅針對度量計算失敗或非預期的升級
平台 | 組織✅ 依工作人員類型與使用個案分別追蹤成功率,因為工作人員用途之間的成功條件不同
平台 | 組織✅ 計算每個工作人員類型的平均失敗間隔時間 (MTBF),以識別需要最佳化投資的最不可靠工作人員
平台 | 組織✅ 測量平均復原時間 (MTTR);透過平台事件重新執行和斷電器自動復原,以取得比手動介入更快且容易錯誤的復原
Einstein | Trust 圖層✅ 針對 Data 360 來源驗證索賠的範例隨機工作人員回應,以測量奠基準確度;當準確性下降到 95% 時調查
平台 | 平台事件✅ 透過訂閱者端記錄模式監視平台事件重新執行間隙 (錯過或未傳送的事件),此模式會將每個事件的 replayId 和關聯性識別碼記錄至自訂物件
平台 | 組織✅ 當任何 SLI 低於其定義的 SLO 上限時警示作業

反模式

要尋找的位置看起來怎麼壞
業務 | 文件⚡️ 建立工作人員而不先定義 SLO,僅在發生生產失敗後建立可靠性目標
平台 | 組織⚡️ 在所有工作人員類型之間使用單一彙總成功率,而非依工作人員類型與使用個案分開追蹤
平台 | 組織⚡️ 僅依賴傳統 Salesforce 監視 (Trust.salesforce.com),而不追蹤工作人員特定的 SLI,例如交談成功率、MTBF、MTTR 和定位準確度
平台 | 組織⚡️ 針對所有工作人員失敗要求手動介入,而非透過平台事件重新執行與斷電器自動化復原
Einstein | Trust 圖層⚡️ 絕不取樣工作人員回應以進行基礎準確性驗證,讓幻覺在生產環境中無法偵測到

模式

要尋找的位置良好的外觀
Agentforce | 工作人員組態✅ 從初始設計設計設計重試模式、回復鏈和升級值至工作人員工作流程,而不是作為後續考量
Agentforce | 動作✅ 大量處理工作人員動作中的內容準備和分頁大型記錄集合
平台 | 平台快取✅ 快取平台快取中經常存取的參照資料,在工作人員內容準備期間減少冗餘查詢
平台 | 規模中心✅ 使用「刻度中心」識別需要最佳化的資源密集工作人員作業
平台 | 平台事件✅ 使用「平台事件」設計自我復原工作流程,作為具有保護外部相依性之斷路器的永久重試排列
Agentforce | 工作人員組態✅ 一律包含人工轉移作為每個工作人員降級鏈中的最後回復
平台 | 組織✅ 當度量低於 SLO 時,監視工作人員 SLI 持續警示
Agentforce | 工作人員組態✅ 使用適當的監督平衡自發功能:啟用暫時失敗的自我復原,同時在信賴下降或邊緣個案出現時升級

反模式

要尋找的位置看起來怎麼壞
Agentforce | 工作人員組態⚡️ 將可靠性機制 (重試、回復、升級) 新增為後續考量,而非從一開始設計
Agentforce | 動作⚡️ 不大量處理內容準備,導致實際世界查詢模式下的管理員限制失敗
平台 | 組織⚡️ 未主動監視 API 耗用與平台事件配置,僅在工作人員失敗時發現限制
Agentforce | 工作人員組態⚡️ 設計工作人員鏈,而不使用人力處理方式作為最終回復,在所有自動化選項都用盡時不會保留復原路徑
Agentforce | 工作人員組態⚡️ 針對低信賴狀況或邊緣個案,授與工作人員完全獨立的作業,而不包含升級門值