Schemi di affidabilità agenti
Ulteriori informazioni su Affidabilità ben progettata → Affidabilità Enterprise Agente
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Platform | Cache piattaforma | ✅ Implementare interruttori che monitorano lo stato di integrità del servizio LLM nella cache piattaforma per letture in tempo reale a bassa latenza, supportate da tipi di metadati personalizzati per le soglie e la configurazione; poiché la cache piattaforma è il massimo sforzo, mantenere lo stato di apertura / attivazione in un punto vendita durevole (ad esempio un oggetto personalizzato) anziché nella sola cache. Aprire il circuito su una soglia di errore sintonizzato (ad esempio, cinque errori di inferenza consecutivi) e instradare agli schemi di fallback |
| Platform | Cache piattaforma | ✅ Memorizzazione degli schemi di risposta convalidati nella cache piattaforma che consente una convalida rapida delle risposte degli agenti rispetto alla struttura prevista |
| Agentforce | Modello di prompt | ✅ Quando la convalida della risposta non riesce, riprovare con prompt raffinati tra cui l’errore di convalida e un esempio di struttura corretta (massimo 3-5 tentativi) |
| Agentforce | Tracciamento delle sessioni | ✅ Utilizzare le tracce di ragionamento di tracciamento sessione Agentforce per ispezionare il percorso di ragionamento dell’agente e rilevare allucinazioni nei suoi output |
| Data 360 | Ricerca vettoriale | ✅ Richiedi agli agenti di citare le fonti di ricerca vettoriale di Data 360 in modo che le richieste possano essere confrontate con le fonti recuperate prima dell’esecuzione dell’azione |
| Piattaforma | Proactive Monitoring | ✅ Per gli account con diritto di firma riuscita, affidarsi a Proactive Monitoring, in cui il personale Salesforce monitora l’organizzazione alla ricerca di problemi emergenti; non è un avviso configurabile self-service |
| Piattaforma | Scale Center | ✅ Utilizzare Scale Center per identificare operazioni specifiche degli agenti che si avvicinano ai limiti del governor |
| Agentforce | Azione | ✅ Implementare la paginazione nelle azioni degli agenti recuperando raccolte di record di grandi dimensioni |
| Agentforce | Azione | ✅ Progettare azioni degli agenti con limiti rigidi (massimo 200 figli per genitore) e implementare strategie di campionamento quando vengono superati i limiti |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Tipi di metadati personalizzati | ⚠️ Consentire tentativi di inferenza illimitati senza un interruttore, creando loop di nuovo infiniti quando il servizio LLM è degradato |
| Agentforce | Modello di prompt | ⚠️ Riprovare le risposte dell’agente non riuscite senza includere l’errore di convalida e la struttura prevista nel prompt di riprova |
| Agentforce | Azione | ⚠️ Consentire agli agenti di richiedere un contesto senza limiti (ad esempio, “tutta la cronologia”) senza limiti specifici per record controllante |
| Agentforce | Azione | ⚠️ Progettare azioni degli agenti che recuperano raccolte di record di grandi dimensioni senza paginazione, causando picchi di limite governor |
| Einstein | Livello Trust | ⚠️ Affidarsi alle risposte degli agenti senza incrociare le richieste con le fonti di dati di base, consentendo alle allucinazioni di raggiungere l’esecuzione dell’azione |
| Piattaforma | Organizzazione | ⚠️ Considerare la disponibilità del servizio LLM identica alla disponibilità della piattaforma Salesforce anziché monitorarla come dipendenza separata |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Agentforce | Configurazione agente | ✅ Progettare catene di fallback a più livelli: agente full-context → agente ridotto-context → motore di regole deterministiche → passaggio umano tramite Omnicanale |
| Agentforce | Configurazione agente | ✅ Configurare un agente secondario utilizzando il contesto condensato (ultimi 30 giorni rispetto a tutta la cronologia, primi 5 risultati di ricerca vettoriale rispetto ai primi 20) per ridurre la probabilità di errore |
| Piattaforma | Flusso | ✅ Implementare la logica di fallback nel flusso di orchestrazione o Apex attivato da eventi piattaforma, registrando il livello riuscito per la visibilità sugli schemi di errore |
| Piattaforma | Flusso | ✅ Creare una logica deterministica di flusso o Apex che gestisca scenari comuni come fallback quando il ragionamento degli agenti non riesce (ad esempio, regole di convalida standard, calcolo del punteggio basato su regole) |
| Agentforce | Omnicanale | ✅ Configurare l’instradamento basato sulle competenze per la consegna umana assicurando che gli inoltri al livello superiore raggiungano le competenze appropriate |
| Agentforce | Omnicanale | ✅ Passare il contesto completo della conversazione all’area di attesa umana, inclusi i tentativi di strategie, i punteggi di confidenza degli agenti e i motivi dell’errore |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Agentforce | Configurazione agente | ⚠️ Progettare gli agenti con un unico percorso di esecuzione che fallisce completamente quando un componente si deteriora |
| Agentforce | Configurazione agente | ⚠️ Utilizzo della stessa configurazione agente full-context per i tentativi di fallback anziché semplificare progressivamente il contesto |
| Agentforce | Omnicanale | ⚠️ Instradamento alla consegna umana senza passare il contesto della conversazione, le strategie tentate o i motivi dell’errore, costringendo l’agente a ricominciare da zero |
| Piattaforma | Flusso | ⚠️ Non registrare il livello di fallback riuscito, perdendo visibilità sugli schemi di errore e l’efficacia del fallback |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Eventi piattaforma | ✅ Pubblicare gli eventi checkpoint dopo ogni fase riuscita nei flussi di lavoro degli agenti a più fasi, memorizzando l’ID correlazione, le fasi completate e lo stato necessario per la continuazione nel payload dell’evento |
| Piattaforma | Eventi piattaforma | ✅ Progettare i flussi di lavoro degli agenti come catene di eventi vagamente accoppiate in cui ogni agente può non riuscire e riprovare in modo indipendente senza bloccare l’intero flusso di lavoro |
| Piattaforma | Eventi piattaforma | ✅ Implementare nuove aree di attesa con ritardi di backoff esponenziali (30s, 2min, 8min, 30min) utilizzando Eventi piattaforma con conteggio dei tentativi nel payload |
| Piattaforma | Eventi piattaforma | ✅ Instradare all’area di attesa lettera morta e alle operazioni di avviso dopo che sono stati esauriti i tentativi massimi (in genere 5) |
| Piattaforma | Eventi piattaforma | ✅ Includere l’ID correlazione in tutti gli eventi correlati; utilizzare l’API Platform Event Replay per ricostruire la cronologia completa del flusso di lavoro per il debug |
| Piattaforma | Eventi piattaforma | ✅ Sfruttare la finestra di conservazione replay di 72 ore disponibile per gli eventi piattaforma a volume elevato (gli eventi a volume standard vengono conservati per 24 ore) per conservare le aree di attesa di nuovo tentativo attraverso le finestre di manutenzione dell’organizzazione o il tempo di inattività della distribuzione |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Eventi piattaforma | ⚠️ Creazione di flussi di lavoro a più fasi per gli agenti senza checkpoint, richiedendo una riesecuzione completa quando qualsiasi fase intermedia non riesce |
| Piattaforma | Eventi piattaforma | ⚠️ Riprovare le richieste degli agenti non riuscite senza backoff esponenziale, creando effetti di gregge tuonanti sul ripristino dei servizi |
| Piattaforma | Eventi piattaforma | ⚠️ Progettare flussi di lavoro sequenziali strettamente accoppiati in cui un errore di un singolo agente blocca tutta l’elaborazione a valle |
| Piattaforma | Eventi piattaforma | ⚠️ Omettere gli ID correlazione dagli eventi, rendendo impossibile tracciare ed eseguire il debug dell’esecuzione completa del flusso di lavoro |
| Piattaforma | Eventi piattaforma | ⚠️ Riprovare indefinitamente senza un numero massimo di tentativi o un’area di attesa senza risposta, consumando le risorse della piattaforma in operazioni con errori permanenti |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Apex | ✅ Utilizzare Batch Apex per le operazioni degli agenti che analizzano oltre 1.000 record, sfruttando i limiti del governor asincrono (200 query SOQL, 150 operazioni DML, 60s CPU per esecuzione) |
| Piattaforma | Apex | ✅ Utilizzare le catene Apex in area di attesa per i flussi di lavoro a più fasi degli agenti che richiedono più chiamate API esterne o un tempo di elaborazione prolungato; tenere traccia dell’avanzamento negli oggetti personalizzati abilitando la ripresa in caso di errore |
| Piattaforma | Apex | ✅ Utilizzare i metodi @future per le operazioni degli agenti antincendio leggeri (notifiche, registrazione esterna, aggiornamenti non urgenti) in cui l’errore è tollerabile |
| Piattaforma | Apex Jobs | ✅ Monitoraggio della capacità di elaborazione asincrona tramite la pagina Processi Apex (Imposta → Processi Apex) e l’Area di attesa Flex Apex: massimo 5 processi batch simultanei (processi aggiuntivi nell’Area di attesa Flex, fino a 100 in stato Attesa) e il limite giornaliero dell’organizzazione per le esecuzioni Apex asincrone (DailyAsyncApexExecutions) — il maggiore tra 250.000 o 200 × il numero di licenze utente per 24 ore — condiviso tra Apex batch, accodabile, future e pianificato |
| Piattaforma | Organizzazione | ✅ Avvisa quando il consumo asincrono si avvicina ai limiti abilitando la gestione proattiva della capacità prima che l’elaborazione degli agenti venga bloccata |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Apex | ⚠️ Elaborazione di oltre 1.000 record nelle transazioni degli agenti sincrone anziché passare ad Apex batch, raggiungendo il limite di 100 query SOQL solo dopo pochi record |
| Piattaforma | Apex | ⚠️ Utilizzo delle catene in area di attesa senza tenere traccia dell’avanzamento negli oggetti personalizzati, impedendo la funzionalità di ripresa in caso di errore |
| Piattaforma | Organizzazione | ⚠️ Non monitorare il limite di 5 processi batch simultanei o il limite di esecuzione Apex asincrona giornaliera condivisa (DailyAsyncApexExecutions — la maggiore tra 250.000 o 200 licenze utente × per 24 ore, in Batch, Area di attesa, Future e Apex pianificato), causando un’area di attesa silenziosa o un errore dell’elaborazione degli agenti |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Organizzazione | ✅ Caricare le prestazioni degli agenti di prova in Full Copy Sandbox con volumi di dati su scala di produzione; simulare conversazioni simultanee corrispondenti ai picchi di domanda |
| Piattaforma | Organizzazione | ✅ Misurare la latenza p95 e p99 sotto carico identificando il deterioramento delle prestazioni sotto stress; convalidare il consumo limite del governor rimane al di sotto delle soglie durante il carico di picco |
| Agentforce | Configurazione agente | ✅ Eseguire l’iniezione di errori: simulare gli errori di inferenza LLM nel livello di servizio monitorato dall’interruttore, iniettare eccezioni SOQL per testare la gestione degli errori, risposte danneggiate per testare la logica di convalida |
| Agentforce | Configurazione agente | ✅ Introdurre la distorsione dei dati (account con 10.000+ figli) durante i test per convalidare la logica di paginazione gestisce gli scenari peggiori |
| Piattaforma | Eventi piattaforma | ✅ Condurre l’ingegneria del caos: disabilitare in modo casuale gli abbonati agli eventi piattaforma che testano il ripristino replay, terminare i processi asincroni a metà esecuzione del riavvio del checkpoint di test |
| Piattaforma | Organizzazione | ✅ Pianificare giornate di caos regolari negli ambienti di gestione temporanea mantenendo la resilienza man mano che gli agenti evolvono |
| Piattaforma | Organizzazione | ✅ Eseguire test di stabilità di lunga durata (72+ ore) per monitorare eventuali errori dipendenti dal tempo: accumulazione di errori e graduale peggioramento delle prestazioni |
| Piattaforma | Organizzazione | ✅ Tenere traccia delle tendenze del tempo CPU e del consumo di heap per periodi estesi rilevando un deterioramento graduale nella gestione del contesto |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Organizzazione | ⚠️ Test di caricamento in Sandbox Copia parziale con volumi di dati ridotti, fornendo una confidenza fuorviante poiché il volume di dati influisce direttamente sulle prestazioni degli agenti |
| Agentforce | Configurazione agente | ⚠️ Testare solo i percorsi felici senza introdurre deliberatamente errori per convalidare gli interruttori, riprovare la logica e la gestione del timeout |
| Piattaforma | Organizzazione | ⚠️ Esecuzione solo di test di breve durata, errori dipendenti dal tempo mancanti (errori di accumulo, deterioramento graduale) che appaiono solo sotto un funzionamento sostenuto di 72+ ore |
| Piattaforma | Eventi piattaforma | ⚠️ Mai testare il ripristino del replay dell’evento piattaforma o il riavvio del checkpoint, lasciando i meccanismi di resilienza non convalidati |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Business | Documentazione | ✅ Stabilire gli SLO prima di creare gli agenti, non dopo gli errori di produzione; definire gli obiettivi di percentuale di successo della conversazione (in genere 95-99%) per tipo di agente |
| Piattaforma | Organizzazione | ✅ Tracciare la percentuale di successo della conversazione come metrica di affidabilità dell’agente principale: percentuale di conversazioni completate senza errori o timeout. Considerare un handoff grazioso a un essere umano come un successo, poiché l’inoltro al livello superiore è il livello di fallback finale progettato; conteggiare solo gli inoltri al livello superiore non riusciti o non intenzionali rispetto alla metrica |
| Piattaforma | Organizzazione | ✅ Tenere traccia della percentuale di successo separatamente per tipo di agente e caso d’uso poiché i criteri di successo variano a seconda degli scopi dell’agente |
| Piattaforma | Organizzazione | ✅ Calculate Mean Time Between Failures (MTBF) per tipo di agente per identificare gli agenti meno affidabili che richiedono investimenti di ottimizzazione |
| Piattaforma | Organizzazione | ✅ Measure Mean Time to Recovery (MTTR); automatizzare il ripristino tramite il replay Evento piattaforma e gli interruttori automatici per un ripristino molto più rapido e meno soggetto a errori rispetto all’intervento manuale |
| Einstein | Livello Trust | ✅ Esempi di risposte casuali degli agenti che convalidano le richieste rispetto alle fonti Data 360 per misurare l’accuratezza del radicamento nel contesto; analizzare quando l’accuratezza scende al di sotto del 95% |
| Piattaforma | Eventi piattaforma | ✅ Monitorare i gap di replay degli eventi piattaforma (eventi mancati o non consegnati) tramite uno schema di registrazione lato abbonato che registra il replayId e l’ID correlazione di ogni evento in un oggetto personalizzato |
| Piattaforma | Organizzazione | ✅ Avvisare le operazioni quando uno SLI scende al di sotto della soglia SLO definita |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Business | Documentazione | ⚠️ Agenti immobiliari senza definire prima gli SLO, stabilendo solo gli obiettivi di affidabilità dopo che si sono verificati errori di produzione |
| Piattaforma | Organizzazione | ⚠️ Utilizzo di una singola percentuale di successo aggregata in tutti i tipi di agenti anziché tenere traccia separatamente per tipo di agente e caso d’uso |
| Piattaforma | Organizzazione | ⚠️ Affidarsi esclusivamente al monitoraggio Salesforce tradizionale (Trust.salesforce.com) senza tenere traccia di SLI specifici dell’agente come la percentuale di successo della conversazione, MTBF, MTTR e la precisione del radicamento nel contesto |
| Piattaforma | Organizzazione | ⚠️ Richiedere un intervento manuale per tutti i guasti degli agenti anziché automatizzare il ripristino con il replay Evento piattaforma e gli interruttori |
| Einstein | Livello Trust | ⚠️ Non campionare mai le risposte degli agenti per la convalida della precisione di radicamento, consentendo allucinazioni non rilevate nella produzione |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Agentforce | Configurazione agente | ✅ Progettare schemi di tentativo, catene di fallback e soglie di inoltro al livello superiore nei flussi di lavoro degli agenti dalla progettazione iniziale, non come ripensamenti |
| Agentforce | Azione | ✅ Preparazione contesto in blocco e paginazione di raccolte di record di grandi dimensioni nelle azioni degli agenti |
| Platform | Cache piattaforma | ✅ Cache dati di riferimento consultati di frequente nella cache piattaforma che riduce le query ridondanti durante la preparazione del contesto degli agenti |
| Piattaforma | Scale Center | ✅ Utilizzare il Centro scala per identificare le operazioni degli agenti che richiedono un’ottimizzazione |
| Piattaforma | Eventi piattaforma | ✅ Progettare flussi di lavoro di auto-ripristino utilizzando Eventi piattaforma come aree di attesa di ritegno durevoli con interruttori che proteggono le dipendenze esterne |
| Agentforce | Configurazione agente | ✅ Includere sempre la consegna umana come fallback finale nella catena di degradazione di ogni agente |
| Piattaforma | Organizzazione | ✅ Monitorare gli SLI degli agenti avvisando continuamente quando le metriche scendono al di sotto degli SLO |
| Agentforce | Configurazione agente | ✅ Bilanciare la capacità autonoma con una supervisione appropriata: abilitare l’auto-ripristino da errori temporanei mentre si inoltra al livello superiore quando la confidenza diminuisce o emergono casi limite |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Agentforce | Configurazione agente | ⚠️ Aggiungere meccanismi di affidabilità (riprovare, fallback, inoltro al livello superiore) come ripensamenti anziché progettarli dall’inizio |
| Agentforce | Azione | ⚠️ Non ingrandire la preparazione del contesto, causando errori del limite governor in schemi di query reali |
| Piattaforma | Organizzazione | ⚠️ Non monitorare il consumo API e l’allocazione degli eventi piattaforma in modo proattivo, rilevando i limiti solo quando gli agenti non riescono |
| Agentforce | Configurazione agente | ⚠️ Progettare catene di agenti senza una consegna umana come fallback finale, senza lasciare alcun percorso di ripristino quando tutte le opzioni automatiche sono esaurite |
| Agentforce | Configurazione agente | ⚠️ Concedere agli agenti un funzionamento completamente autonomo senza soglie di inoltro al livello superiore per situazioni di scarsa confidenza o casi limite |