Affidabilità per l'azienda agente

Gli agenti autonomi introducono schemi di esecuzione non deterministici fondamentalmente diversi dall'automazione Salesforce tradizionale. Mentre Flusso Salesforce e Apex seguono percorsi prevedibili che producono risultati ripetibili in condizioni controllate, gli agenti ragionano dinamicamente sui problemi. Ad esempio, la stessa domanda posta due volte può seguire percorsi di esecuzione diversi, consumare risorse diverse e produrre risultati diversi. Questo non determinismo crea sfide di affidabilità che gli approcci di test e monitoraggio tradizionali non affrontano.

Le modalità di errore dell'affidabilità degli agenti sono categoricamente diverse dagli errori di flusso Salesforce o Apex. I servizi di inferenza LLM (Large Language Model) rappresentano dipendenze esterne con caratteristiche di disponibilità separate dalla piattaforma Salesforce. Gli agenti generano risposte che occasionalmente violano la struttura prevista nonostante le istruzioni rapide. La preparazione del contesto degli agenti consuma i limiti del governor in modo imprevedibile. Il recupero senza limiti dei dati influisce più gravemente sugli agenti perché gli agenti possono richiedere un contesto aperto mentre le query deterministiche hanno un controllo esplicito dell'ambito.

Un'architettura degli agenti affidabile richiede una catena di fallback a più livelli che si degrada in modo fluido: dagli agenti sofisticati, agli agenti più semplici con contesto ridotto, ai motori di regole deterministiche e infine al passaggio umano tramite Omnicanale. Gli eventi piattaforma alimentano le aree di attesa di nuovi tentativi durevoli con schemi di checkpoint, consentendo la ripresa dei flussi di lavoro non riusciti dall'ultima fase riuscita. Gli interruttori automatici monitorano lo stato del servizio LLM nella cache piattaforma per lo stato in tempo reale, supportato da tipi di metadati personalizzati per le soglie e la configurazione, instradando agli schemi di fallback dopo errori consecutivi. Il monitoraggio richiede il tracciamento delle percentuali di successo delle conversazioni, del tempo medio tra gli errori (MTBF), del tempo medio di ripristino (MTTR) e della precisione di radicamento nel contesto. L'Osservabilità Agentforce fornisce le tracce della sessione, le metriche di salute e latenza e le percentuali di inoltro al livello superiore e di deviazione, ma è comunque necessario eseguire autonomamente lo strumento di metriche di affidabilità come MTBF, MTTR e precisione di radicamento.

Questo documento descrive che cosa cambia quando gli agenti sono presenti. Per schemi di affidabilità di base validi per tutte le soluzioni Salesforce (progettazione degli oggetti livello di servizio, tolleranza dei guasti, scalabilità e monitoraggio), vedere il pilastro Affidabilità.

Gli agenti Agentforce non riescono in modi diversi da Flusso Salesforce o Apex. La comprensione di queste modalità di errore è ciò che determina l'architettura dell'affidabilità.

Indisponibilità del servizio LLM: Gli endpoint di inferenza LLM riscontrano picchi di latenza occasionali o problemi di disponibilità. Agentforce è elencato come prodotto monitorato su Trust.salesforce.com insieme ad Analytics e ad altri servizi Salesforce. Tuttavia, la latenza di inferenza LLM granulare e le metriche delle prestazioni per richiesta non sono esposte. Implementare gli interruttori automatici utilizzando Cache piattaforma per lo stato in tempo reale a bassa latenza, supportato da Tipi di metadati personalizzati per le soglie e la configurazione, per monitorare lo stato del servizio LLM. Poiché la cache piattaforma è la soluzione migliore (le voci possono essere sfrattate prima del loro time-to-live, TTL), mantenere lo stato di apertura/attivazione in un punto vendita durevole, ad esempio un oggetto personalizzato, anziché nella sola cache. Sintonizzare la condizione del viaggio sull'endpoint: un conteggio degli errori consecutivi (ad esempio, cinque) o un tasso di errore che supera una soglia su una finestra mobile. Quando il circuito si attiva, aprirlo e instradarlo a schemi di fallback, ad esempio prompt più semplici, risposte memorizzate nella cache o handoff umano, fino a quando una richiesta di test riuscita indica il ripristino.
Errori di convalida della risposta: Gli agenti occasionalmente generano risposte che violano la struttura prevista nonostante le istruzioni rapide. Un agente a volte restituisce JSON in formato non corretto, omette i campi obbligatori o include tipi di dati imprevisti. La cache piattaforma può memorizzare schemi di risposta convalidati, consentendo una convalida rapida. Quando la convalida non riesce, riprovare con prompt raffinati, incluso l'errore di convalida e un esempio di struttura corretta. Impostare un numero massimo di tentativi (3—5) per evitare loop di tentativi infiniti.
Rilevamento allucinazioni: Quando i dati di base sono incompleti, gli agenti generano informazioni plausibili ma non corrette. A differenza delle query deterministiche che restituiscono "non trovato", gli agenti colmano le lacune con l'inferenza. L'itinerario di controllo Einstein Trust Layer registra ogni prompt, prompt mascherato, risposta, risultato del rilevamento della tossicità e feedback degli utenti per una revisione post-hoc della governance. Tuttavia, non acquisisce tracce di ragionamento passo per passo. Per acquisire i ragionamenti passo per passo, utilizzare Tracciamento sessione Agentforce, che registra le esecuzioni del motore di ragionamento. Richiedere agli agenti di citare le fonti di recupero RAG (Data 360, in precedenza Data Cloud). Confrontare le richieste degli agenti con le fonti recuperate per individuare le deviazioni effettive prima dell'esecuzione dell'azione. Un controllo in linea aggiunge poca latenza, poiché viene eseguito con fonti già nel contesto. Un controllo che richiede un'andata e ritorno separata, ad esempio una seconda chiamata modello o un servizio esterno, costa di più. Riservare questi controlli alle scritture di grande impatto, inclusi gli aggiornamenti finanziari o degli ordini, ed eseguirli in modo asincrono durante la conversazione in tempo reale.
Picchi di limite del governatore: La preparazione del contesto dell'agente consuma le query SOQL (Object Query Language) di Salesforce, il tempo CPU e la memoria heap in modo imprevedibile in base al flusso di conversazione. Proactive Monitoring è un servizio diritti Signature Success (precedentemente Signature Support) nel Salesforce Success Plan, in cui Salesforce monitora in modo proattivo gli account dei clienti. Proactive Monitoring non è un avviso configurabile self-service disponibile per tutti i clienti. Per il monitoraggio dei limiti del governor self-service, utilizzare Scale Center per identificare le operazioni degli agenti che richiedono molte risorse e si avvicinano ai limiti. Implementare la paginazione nelle azioni degli agenti che recuperano raccolte di record di grandi dimensioni. Per i dati di riferimento a cui si accede di frequente, utilizzare Cache piattaforma.
Disorientamento dei dati nel contesto dell'agente: Gli agenti che recuperano il contesto per gli account con più di 10.000 opportunità o i casi con cronologie attività relativamente ampie incontrano le stesse difficoltà di distorsione dei dati di Batch Apex. A differenza delle query deterministiche in cui si controlla l'ambito, il ragionamento degli agenti può richiedere "tutta la cronologia" in modo imprevedibile. Per evitare questo, progettare azioni degli agenti con limiti rigidi ragionevoli (ad esempio, un limite massimo dell'ordine di 200 figli per controllante) e implementare strategie di campionamento quando vengono superati i limiti. Il limite limita la quantità di dati che entrano nel contesto dell'agente. Abbinarlo a filtri selettivi indicizzati in modo che la query rimanga economica, poiché un filtro non indicizzato o un'aggregazione su un controllante non indicizzato analizza l'insieme controllato completo prima dell'applicazione del limite massimo.

Progettare catene di fallback a più livelli per consentire agli agenti di continuare a funzionare con funzionalità ridotte anziché fallire completamente.

Agente principale con contesto completo: Agente sofisticato con basi complete su Data 360, cronologia delle conversazioni completa e ragionamento complesso. Massima qualità ma con il maggior dispendio di risorse e il più alto rischio di errore.
Agente secondario con contesto ridotto: Agente più semplice che utilizza il contesto condensato (ad esempio, ultimi 30 giorni rispetto a tutta la cronologia, primi 5 risultati di ricerca vettoriale rispetto ai primi 20). Contesto più piccolo significa meno token, inferenza più rapida e minore probabilità di errore, ma solo se il contesto ridotto copre ancora i dati necessari all'operazione.
Motore di regole deterministiche: Flusso Salesforce tradizionale o logica Apex che gestisce scenari comuni quando il ragionamento degli agenti non riesce. Le regole non possono adattarsi a nuove situazioni, ma gestiscono in modo affidabile schemi noti. L'agente di convalida dell'ordine torna alle regole di convalida standard, mentre l'agente del punteggio dei lead torna al calcolo del punteggio basato su regole.
Consegna umana tramite Omnicanale: Instrada all'area di attesa umana quando le opzioni automatiche sono esaurite. Configurare l'instradamento basato sulle competenze per assicurarsi che gli inoltri al livello superiore raggiungano le competenze appropriate. Passare il contesto completo della conversazione, incluse le strategie tentate, gli eventuali punteggi di confidenza calcolati per l'agente e i motivi dell'errore, per consentire un intervento umano efficiente.

Implementare la logica di fallback nell'orchestrazione Flusso Salesforce o Apex attivato da Eventi piattaforma. Ogni livello registra la strategia riuscita, creando visibilità sugli schemi di errore e sull'efficacia del fallback.

Tutti gli schemi Evento piattaforma di questa sezione presumono tipi di Evento piattaforma a volume elevato, che forniscono la finestra di conservazione del replay di 72 ore. Gli eventi piattaforma a volume standard vengono conservati solo per 24 ore. Utilizzare i tipi di eventi a volume elevato per tutti gli schemi di resilienza degli agenti, area di attesa di nuovo tentativo e checkpoint in cui la durata del replay è un requisito di affidabilità. Gli eventi piattaforma offrono una messaggistica durevole che consente ai flussi di lavoro degli agenti di sopravvivere agli errori e di ripristinare automaticamente.

Avanzamento dell'agente checkpoint: I flussi di lavoro a più fasi degli agenti pubblicano gli eventi checkpoint dopo ogni fase riuscita. L'agente dell'elaborazione contratti completa l'estrazione del documento, pubblica l'evento ContractParsed con i dati estratti e quindi passa all'analisi delle clausole. Se l'analisi delle clausole non riesce, riprodurre l'evento ContractParsed per riprendere dai dati estratti senza ripetere l'analisi. Funziona quando il payload del checkpoint trasporta i dati e l'abbonato è idempotente, perché replay restituisce gli eventi anziché riprendere un flusso di lavoro a metà fase. Memorizza lo stato del checkpoint nel payload dell'evento, inclusi ID correlazione, fasi completate e stato necessario per la continuazione.
Area di attesa Riprova con backoff esponenziale: Le richieste degli agenti non riuscite vengono pubblicate nell'evento AgentRetryRequested con il conteggio dei tentativi nel payload. L'abbonato evento elabora i tentativi con ritardi di backoff esponenziali (ad esempio, 30 sec, 2 min, 8 min, 30 min). Dopo il massimo numero di tentativi (in genere 5), instradare alle operazioni di area di attesa e avviso a lettera morta. Gli eventi piattaforma a volume elevato mantengono un periodo di riproduzione di 72 ore. Utilizzare il tipo di evento a volume elevato per le aree di attesa di nuovo degli agenti in modo che gli abbonati possano recuperare dopo le finestre di manutenzione dell'organizzazione o i tempi di inattività della distribuzione. Gli eventi piattaforma a volume standard vengono conservati solo per 24 ore.
Orchestrazione basata sugli eventi: Progettare i flussi di lavoro degli agenti come catene di eventi vagamente accoppiate. La creazione del lead pubblica LeadCreated. L'agente del punteggio lead si abbona, calcola il punteggio e pubblica LeadScored. L'agente di instradamento lead si abbona a LeadScored e lo assegna all'area di attesa appropriata. Ogni agente può non riuscire e riprovare in modo indipendente. Un errore di un singolo agente non blocca l'intero flusso di lavoro: gli agenti a valle elaborano quando le dipendenze vengono ripristinate.
Tracciamento ID correlazione: Includere un ID correlazione come campo personalizzato in tutti i payload degli eventi correlati. Replay degli eventi utilizzando l'API Pub/Sub by replayId, un identificatore opaco non contiguo, per ricostruire la cronologia del flusso di lavoro entro il periodo di conservazione di 72 ore. Per abilitare il debug basato sull'ID correlazione, implementare uno schema lato abbonato che registra gli eventi in entrata con il relativo replayId e ID correlazione in un oggetto personalizzato, abilitando la tracciabilità incrociata degli eventi. Questo schema di registrazione è un'implementazione personalizzata creata dall'utente, non una funzionalità di query nativa della piattaforma.

Spostare le operazioni degli agenti che superano i limiti sincroni in un contesto asincrono, che consente limiti governor più elevati e timeout più lunghi.

Batch Apex per le operazioni degli agenti in blocco: Un agente che analizza oltre 1.000 record trae vantaggio da Batch Apex che fornisce 200 query SOQL, 150 istruzioni DML (fino a 10.000 righe DML) e 60.000 millisecondi (60 secondi) di tempo CPU per metodo di esecuzione. Agente del calcolo del punteggio lead che elabora le importazioni di lead notturne. Analisi del sentiment dei casi nei casi storici. Previsioni opportunità che analizzano le opportunità in corso di realizzazione completate.
Catene in area di attesa per flussi di lavoro a più fasi: I flussi di lavoro complessi degli agenti che richiedono più chiamate API esterne, analisi di serie di dati di grandi dimensioni o un tempo di elaborazione prolungato utilizzano le catene Apex in area di attesa. Ogni processo Area di attesa ottiene 60 CPU time e 12 MB heap. In coda per i flussi di lavoro che superano i limiti di processi singoli. Monitorare l'avanzamento negli oggetti personalizzati in modo che un processo non riuscito possa riprendere dall'ultima fase completata.
@future per i semplici handoff asincroni: Le operazioni più semplici degli agenti, come l'invio di notifiche, l'accesso a sistemi esterni o aggiornamenti non urgenti, utilizzano i metodi @future. Lo schema fire-and-forget si adatta quando un flusso di lavoro non necessita di risultati e può tollerare errori.

Monitorare la capacità di elaborazione asincrona tramite la pagina Processi Apex (Imposta → Processi Apex) e l'Area di attesa Apex Flex. Un massimo di 5 processi batch simultanei limita l'elaborazione parallela degli agenti; ulteriori processi nell'area di attesa Flex Apex, che contiene fino a 100 processi in stato In attesa. Tutti i tipi Apex asincroni, Batch, Future, Queueable e Scheduled Apex, condividono lo stesso limite giornaliero dell'organizzazione (DailyAsyncApexExecutions) per le esecuzioni Apex asincrone: il maggiore tra 250.000 o 200 volte il numero di licenze utente. Quando si esegue il polling degli agenti ad alta frequenza o si ritentano le aree di attesa degli abbonati, Area di attesa può esaurire rapidamente questa quota. Per evitare questo problema, raggruppare in batch o limitare queste aree di attesa per rimanere entro il limite, che si applica a tutta l'organizzazione in tutti i tipi Apex asincroni, non come allocazione separata solo per Area di attesa. Avvisare quando il consumo si avvicina a questi limiti in modo che i team possano gestire la capacità in modo proattivo.

Convalidare la resilienza degli agenti prima della produzione attraverso strategie di test che risolvono il comportamento non deterministico.

Test di caricamento in Full Copy Sandbox: Testare le prestazioni degli agenti sotto carico su scala di produzione utilizzando volumi di dati completi. Simula conversazioni simultanee corrispondenti ai picchi di domanda. Misurare la latenza p95 e p99, identificando il deterioramento delle prestazioni sotto stress. Convalida che il consumo limite del governor rimanga al di sotto delle soglie durante i picchi di carico. I test di caricamento in un Sandbox Copia parziale con dati ridotti offrono una confidenza fuorviante, poiché il volume di dati influisce direttamente sulle prestazioni degli agenti. Prima di eseguire questi test, richiedere l'approvazione di Salesforce (almeno una settimana prima per le richieste di test delle prestazioni). I test non approvati possono essere limitati o bloccati.
Iniezione guasto: Introdurre deliberatamente errori di convalida dei meccanismi di ripristino. Simulare errori di inferenza LLM nel livello di servizio monitorato dall'interruttore per verificare che l'interruttore si attivi. Inserire eccezioni SOQL per testare la gestione degli errori. Risposte degli agenti danneggiate alla logica di convalida dei test. Introdurre la distorsione dei dati (account con oltre 10.000 figli) per testare la logica di paginazione. Impostare timeout aggressivi per testare la gestione dei timeout e riprovare le strategie.
Tecnica del caos: Disabilitare in modo casuale gli abbonati agli eventi piattaforma per testare il ripristino dei replay. Terminare i processi asincroni a metà esecuzione per testare il riavvio del checkpoint. Introdurre la latenza variabile nei sistemi esterni per testare le strategie di timeout progressivo. Gli esperimenti del caos convalidano la resilienza in combinazioni di errori realistiche. Pianificare giornate di caos regolari negli ambienti di gestione temporanea, mantenendo la resilienza man mano che gli agenti evolvono.
Test di stabilità di lunga durata: Eseguire carichi di lavoro degli agenti in modo continuo per oltre 72 ore, monitorando eventuali errori dipendenti dal tempo. Gli errori accumulati e le prestazioni che peggiorano gradualmente emergono solo sotto un funzionamento sostenuto. Tenere traccia delle tendenze temporali della CPU per identificare il deterioramento graduale nel corso dell'esecuzione.

Definire indicatori del livello di servizio (SLI) che abilitano la misurazione oggettiva dell'affidabilità. Stabilire gli SLO prima di costruire gli agenti, non dopo gli errori di produzione.

Percentuale di successo della conversazione: Percentuale di conversazioni degli agenti completate senza errori o timeout. Considerare una consegna graziosa a un essere umano come un successo, non un fallimento: l'inoltro al livello superiore è l'ultimo livello di fallback per progettazione. Conteggiare gli inoltri non riusciti o non intenzionali al livello superiore rispetto alla metrica: è un utile segnale di affidabilità, ma un proxy imperfetto per l'esperienza utente, poiché un'approvazione educata può mascherare un problema irrisolto. Tenere traccia separatamente per tipo di agente e caso d'uso poiché i criteri di esito positivo del calcolo del punteggio dei lead sono diversi dalla revisione del contratto. Avvisa quando la percentuale di successo scende al di sotto di SLO (in genere 95-99%).
Tempo medio tra i guasti (MTBF): Tempo operativo medio tra gli errori degli agenti. Una MTBF più alta indica un minor numero di errori e una migliore affidabilità. Calcolare come ore operative totali degli agenti diviso il conteggio degli errori. Monitorare per tipo di agente per identificare gli agenti meno affidabili che richiedono investimenti in ottimizzazione.
Tempo medio di recupero (MTTR): Tempo medio dal rilevamento dell'errore al ripristino del servizio. Il ripristino automatico tramite replay evento piattaforma e interruttori automatici ripristina il servizio molto più velocemente e con meno errori manuali rispetto all'intervento pratico. Un MTTR più basso riduce l'impatto aziendale per incidente.
Precisione di messa a terra: Percentuale di risposte degli agenti corrette in base alla convalida dei dati di origine. Esempi di risposte casuali degli agenti per convalidare le richieste rispetto alle fonti Data 360. Una precisione di radicamento inferiore al 95% indica problemi di allucinazioni che richiedono un rapido perfezionamento o un migliore recupero del contesto.
Lacune di replay degli eventi piattaforma: Conteggio degli eventi mancati o non consegnati, ad esempio un abbonato offline oltre la finestra di conservazione. Zero gap è un segnale positivo di una sana architettura basata sugli eventi. I gap indicano problemi degli abbonati, errori di pubblicazione degli eventi o limiti di capacità. Tenere traccia di questi gap con lo schema di registrazione lato abbonato descritto sopra e registrare il replayId e l'ID correlazione di ogni evento in un oggetto personalizzato.

Gli agenti affidabili provengono dalla progettazione preventiva dei guasti: definizione di SLI/SLO, gestione del contesto con governor-limit-aware e catene di fallback multi-livello prima della creazione, senza bloccarli in seguito. Interruttori automatici a livelli e logica dei ripetuti tentativi e checkpoint basata sugli eventi piattaforma per ripristinare automaticamente i flussi di lavoro, con passaggio di consegne umano come ultima risorsa. Convalidare la progettazione mediante test sistematici di carico, iniezione di guasti e caos, quindi continuare a monitorare gli stessi SLI in produzione per verificare che reggano nel tempo.

La guida all'affidabilità nel pilastro principale Affidabilità si applica agli agenti con considerazioni specifiche della piattaforma trattate qui. Le architetture degli agenti di successo bilanciano la capacità autonoma con la supervisione appropriata, consentendo l'auto-ripristino da errori temporanei e l'inoltro al livello superiore quando la confidenza diminuisce o emergono casi limite.

Condividere i propri commenti sul framework ben progettato.