Pålitelighet for Agentic Enterprise

Autonome agenter introduserer ikke-deterministiske utførelsesmønstre som er fundamentalt forskjellige fra tradisjonell Salesforce-automatisering. Salesforce Flow og Apex følger forutsigbare baner som gir gjentagende resultater under kontrollerte forhold, men agenter forstår problemene dynamisk. Det samme spørsmålet som stilles to ganger, kan for eksempel ta forskjellige utførelsesbaner, bruke forskjellige ressurser og gi forskjellige resultater. Denne ikke-deterministismen skaper pålitelighetsutfordringer som tradisjonelle tilnærminger til testing og overvåking ikke løser.

Mislykket modus for agentpålitelighet er kategorisk forskjellig fra Salesforce-flyt- eller Apex. Utledingstjenester for store språkmodeller (LLM) representerer eksterne avhengigheter med tilgjengelighetsegenskaper atskilt fra Salesforce-plattformen. Agenter genererer svar som av og til bryter den forventede strukturen til tross for ledetekstinstruksjoner. Klargjøring av agentkontekst bruker styringsgrenser uforutsigbart. Henting av ubegrensede data påvirker agenter mer alvorlig fordi agenter kan be om åpen kontekst, mens deterministiske spørringer har eksplisitt omfangskontroll.

Pålitelig agentarkitektur krever en tilbakekoblingskjede med flere nivåer som degraderes på en elegant måte – fra sofistikerte agenter til enklere agenter med redusert kontekst, til deterministiske regelmotorer og til slutt til menneskelig overføring via Omnikanal. Plattformhendelser leverer holdbare køer for ny forsøk med sjekkpunktmønstre slik at mislykkede arbeidsflyter kan gjenopptas fra det siste vellykkede trinnet. Kretsbrytere sporer tilstanden til LLM-tjenesten i plattformbuffer for sanntidsstatus, støttet av tilpassede metadatatyper for terskler og konfigurasjon, ruting til reservemønstre etter etterfølgende feil. Overvåking krever sporing av samtalers suksessfrekvens, gjennomsnittstid mellom feil (MTBF), gjennomsnittstid til gjenoppretting (MTTR) og nøyaktighet av tilordningen. Agentforce Observability sørger for øktsporing, tilstands- og latensmålinger og eskalerings- og defleksjonsrater, men du må fremdeles instrumentere pålitelighetsmålinger som MTBF, MTTR og nøyaktighet for jording selv.

Dette dokumentet dekker hvilke endringer som skjer når agenter vises på bildet. Hvis du vil vite mer om grunnleggende pålitelighetsmønstre som gjelder for alle Salesforce-løsninger (Service Level Object (SLO)-design, feiltoleranse, skalering og overvåking), kan du se søylen Pålitelighet.

Agentforce mislykkes på andre måter enn Salesforce-flyt eller Apex. Forståelse av disse feilmodusene er det som former pålitelighetsarkitekturen.

LLM-tjeneste utilgjengelighet: LLM-utledningssluttpunkter opplever noen ganger høy latens eller tilgjengelighetsproblemer. Agentforce er oppført som et overvåket produkt på trust.salesforce.com sammen med Analytics og andre Salesforce-tjenester. Detaljerte LLM-utledningslatens og ytelsesmålinger per forespørsel vises imidlertid ikke der. Implementer kretsbrytere ved å bruke plattformbuffer for tilstand med lav latens i sanntid, som støttes av tilpassede metadatatyper for terskler og konfigurasjon, til å spore tilstanden til LLM-tjenesten. Plattformbuffer er best mulig – oppføringer kan fjernes før de er aktivert (TTL) – så behold statusen åpen/avbrutt i en varig butikk, som et tilpasset objekt, i stedet for bare bufferen. Juster reisetilstanden til sluttpunktet: et antall etterfølgende feil (for eksempel fem) eller en feilfrekvens som krysser en terskel over et rullerende vindu. Når kretsen går, åpner du den og ruter til reservemønstre, som enklere ledetekster, bufrede svar eller menneskelig overføring, til en vellykket testforespørsel indikerer gjenoppretting.
Svarvalideringsfeil: Agenter genererer av og til svar som bryter den forventede strukturen, til tross for ledetekstinstruksjoner. En agent returnerer noen ganger feil utformet JSON, utelater nødvendige felt eller inkluderer uventede datatyper. Plattformbuffer kan lagre validerte svarskjemaer for å aktivere rask validering. Når valideringen mislykkes, prøver du på nytt med forbedrede ledetekster, inkludert valideringsfeilen og et eksempel på riktig struktur. Angi et maksimalt antall nye forsøk (3–5) for å hindre uendelig antall forsøk på nytt.
Hallusinasjonsdeteksjon: Når landingsdata er ufullstendige, produserer agenter rimelig, men feil informasjon. Til forskjell fra deterministiske spørringer som returnerer "ikke funnet", fyller agenter hull med utledninger. Einstein Trust Layer Audit Trail logger alle ledetekster, maskerte ledetekster, svar, toksisitetsdeteksjonsresultat og tilbakemeldinger fra brukere for post-hoc-styringsgjennomgang. Det fanger imidlertid ikke opp trinnvise vurderingsspor. Til oppfanging av trinnvis resonans bruker du Agentforce, som registrerer utførelser av resonansmotoren. Krev at agenter refererer til hentekilder for RAG (Data 360) (tidligere Data Cloud). Kryssreferanseagentkrav mot hentede kilder for å fange opp faktiske avvik før handling utføres. En innebygd kontroll legger til lite latens fordi den kjører mot kilder som allerede er i kontekst. En sjekk som trenger en separat tur, som et andre modellkall eller en ekstern tjeneste, koster mer. Reserver disse sjekkene for skrivinger med stor innvirkning, inkludert økonomiske eller bestillingsoppdateringer, og kjør den asynkront under sanntidssamtale.
Styringsgrense: Agentkontekstforberedelse forbruker SOQL-spørringer (Salesforce object query language), CPU-tid og heap-hukommelse uforutsigbart basert på samtaleflyt. Proactive Monitoring er en Signature Success-berettigelsestjeneste (tidligere Signature Support) i Salesforce Success Plan, der Salesforce proaktivt overvåker kundekontoer. Proactive Monitoring er ikke et konfigurerbart varsel for selvbetjening som er tilgjengelig for alle kunder. Til selvbetjent styringsgrenseovervåking bruker du Scale Center til å identifisere ressursintensive agentoperasjoner som nærmer seg grenser. Implementer sideinndeling i agenthandlinger som henter store postsamlinger. Til referansedata som ofte åpnes, bruker du Plattformbuffer.
Data forskyvning i agentkontekst: Agenter som henter kontekst for kontoer med mer enn 10 000 salgsmuligheter, eller saker med sammenlignbart stor aktivitetshistorikk, støter på de samme dataskjevhetene som batch Apex. Til forskjell fra deterministiske spørringer der du bestemmer omfanget, kan agentrangering be om "all historikk" uforutsigbart. For å hindre dette utformer du agenthandlinger med fornuftige grenser (for eksempel en grense på 200 barn per overordnet) og implementerer utvalgsstrategier når grenser overskrides. Kappen avgrenser hvor mye data som legges inn i agentens kontekst. Par den med selektive, indekserte filtre slik at selve spørringen forblir billig fordi et ikke-indeksert filter eller en oppsummering på en skjev overordnet skanner det fullstendige underordnede settet før grensen brukes.

Utform flere nivåer av reservekjeder slik at agenter kan fortsette å fungere med redusert kapasitet i stedet for å mislykkes fullstendig.

Primær agent med full kontekst: Avansert agent med fullstendig Data 360-grunning, omfattende samtalehistorikk og komplekst resonnement. Høyeste kvalitet, men mest ressursintensive og høyeste feilrisiko.
Sekundær agent med redusert kontekst: Enklere agent ved bruk av kondensert kontekst (for eksempel siste 30 dager kontra all historikk, topp 5 vektorsøkeresultater kontra topp 20). Mindre kontekst betyr færre tokener, raskere utledning og lavere sjanse for feil, men bare hvis den reduserte konteksten fremdeles dekker dataene oppgaven trenger.
Deterministisk regelmotor: Tradisjonell Salesforce-flyt eller Apex som håndterer vanlige scenarier når agentenes vurderinger mislykkes. Regler kan ikke tilpasse seg nye situasjoner, men de håndterer pålitelig kjente mønstre. Bestillingsvalideringsagenten går tilbake til standard valideringsregler, mens salgsemnescoringsagenten går tilbake til regelbasert beregning av score.
Menneskelig overføring via Omnikanal: Rut til kø for person når automatiserte alternativer er uttømt. Konfigurer kvalifikasjonsbasert ruting for å forsikre deg om at eskaleringer når riktig ekspertise. Overfør hele samtalekonteksten – inkludert forsøkte strategier, eventuelle konfidensscore du beregner for agenten, og årsaker til feil – for å muliggjøre effektiv menneskelig intervensjon.

Implementer reservelogikk i orkestreringsflyt i Salesforce eller Apex utløst av plattformhendelser. Hvert sjikt logger hvilken strategi som var vellykket, og gir synlighet til feilmønstre og tilbakestillingseffektivitet.

Alle plattformhendelsesmønstre i denne delen forutsetter plattformhendelsestyper med stor trafikk, som gir oppbevaringsvinduet for gjentakelse på 72 timer. Plattformhendelser med standardvolum beholdes i bare 24 timer. Bruk hendelsestyper med stor trafikk for alle agentenes fleksibilitet, gjenprøvekø og sjekkpunktmønstre der gjentakelsesholdighet er et pålitelighetskrav. Plattformhendelser sørger for varige meldinger som gir agentarbeidsflyter mulighet til å overleve feil og gjenopprette automatisk.

Sjekkpunktagentfremdrift: Flertrinns agentarbeidsflyter publiserer sjekkpunkthendelser etter hvert vellykket trinn. Kontraktbehandlingsagenten fullfører dokumentuttrekkingen, publiserer ContractParsed-hendelsen med uttrukne data, og fortsetter deretter til setningsanalyse. Hvis setningsanalyse mislykkes, spiller du ContractParsed-hendelsen på nytt for å gjenoppta fra de uttrukne dataene uten å analysere på nytt. Dette fungerer når sjekkpunktbelastningen bærer disse dataene og abonnenten er idempotent fordi avspilling leverer hendelser på nytt i stedet for å gjenoppta en arbeidsflyt midt i trinnet. Lagre sjekkpunktstatus i hendelsesbelastning, inkludert korrelasjons-ID, fullførte trinn og stat som er nødvendig for fortsettelse.
Tilbakestillingskø med eksponentiell tilbakekobling: Mislykkede agentforespørsler publiseres til AgentRetryRequested-hendelse med antall nye forsøk i last. Hendelsesabonnenten behandler nye forsøk med eksponentielle forsinkelser (for eksempel 30 sek, 2 minutter, 8 minutter, 30 minutter). Etter maksimalt antall nye forsøk (vanligvis 5) ruter du til kø og varseloperasjoner med død bokstav. High-volume Platform Events beholder et 72-timers gjentakelsesvindu. Bruk hendelsestypen for stor trafikk for gjenprøvingskøer for agenter slik at abonnenter kan ta tak i organisasjonsvedlikeholdsvinduer eller nedetid for distribusjon. Plattformhendelser med standardvolum beholdes i bare 24 timer.
Event-drevet orkestrering: Utform agentarbeidsflyter som løst koblede hendelseskjeder. Salgsemneoppretting publiserer LeadCreated. Salgsemnescorerepresentanten abonnerer på, gir score og publiserer LeadScored. Rutingsagenten for salgsemner abonnerer på LeadScored og tildeler den til den riktige køen. Hver agent kan mislykkes og prøve på nytt uavhengig. En enkelt agentfeil blokkerer ikke hele arbeidsflyten – nedstrøms agenter behandler når avhengigheter gjenopprettes.
Sporing av korrelasjons-ID: Inkluder en korrelasjons-ID som et tilpasset felt i alle relaterte hendelsesbelastninger. Spill av hendelser ved å bruke Pub/Sub API by replayId, en ugjennomsiktig, ikke-tilstøtende identifikator, til å rekonstruere arbeidsflythistorikken i det 72-timers oppbevaringsvinduet. For å aktivere korrelasjons-ID-basert feilsøking implementerer du et mønster på abonnentsiden som logger innkommende hendelser med deres replayId og korrelasjons-ID til et tilpasset objekt, og aktiverer sporing på tvers av hendelser. Dette loggingsmønsteret er en tilpasset implementering du bygger selv, ikke en innebygd plattformspørringsfunksjon.

Flytt agentoperasjoner som overskrider synkrone grenser, til en asynkron kontekst, som tillater høyere styringsgrenser og lengre tidsavbrudd.

Batch Apex for masseagentoperasjoner: En agent som analyserer over 1000 poster, drar nytte av Apex som gir 200 SOQL-spørringer, 150 DML-setninger (opptil 10 000 DML-rader) og 60 000 millisekunder (60 sekunder) CPU-tid per utføringsmetode. Salgsemnescoringsagent som behandler salgsemneimporter hver natt. Sakssentimentanalyse på tvers av historiske saker. Salgsmulighetsprognoser som analyserer fullstendige under arbeid.
Kjøbare kjeder for arbeidsflyter med flere trinn: Komplekse agentarbeidsflyter som krever flere eksterne API-kall, stor datasettanalyse eller utvidet behandlingstid, bruker Apex som kan legges i kø. Hver Købar-jobb får 60 CPU-tid og 12 MB heap. Kjed til neste Købar for arbeidsflyter som overskrider grensene for enkeltjobber. Spor fremdrift i Tilpassede objekter slik at en mislykket jobb kan gjenoppta fra det siste fullførte trinnet.
@future for enkle asynkrone håndteringer: Lette agentoperasjoner, som å sende varsler, logge på eksterne systemer eller ikke-hurtige oppdateringer, bruker @future-metoder. Mønsteret fire-og-glemmer passer når en arbeidsflyt ikke trenger resultater tilbake og kan tolerere feil.

Overvåk kapasiteten for asynkron behandling via siden Apex (Oppsett → Apex) og Apex. Maksimalt 5 samtidige gruppejobber begrenser parallell agentbehandling. Ytterligere jobbkø i Apex Flex-køen, som har opptil 100 jobber i Holding-status. Alle asynkrone Apex-typer, Batch, Future, Queueable og Scheduled Apex, deler den samme organisasjonsomfattende daglige grensen (DailyAsyncApexExecutions) for asynkrone Apex-utførelser: det største av 250 000 eller 200 ganger antall brukerlisenser. Når du kjører agentavstemninger med høy frekvens eller prøver abonnentkøer på nytt, kan Køer raskt bruke denne kvoten. For å unngå dette må du gruppere eller redusere antall av disse køene for å holde seg innenfor grensen – som gjelder for hele organisasjonen på tvers av alle asynkrone Apex, ikke som en separat tildeling bare for Købar. Varsle når forbruket nærmer seg disse grensene slik at team kan administrere kapasitet proaktivt.

Valider agentenes fleksibilitet før produksjon ved å teste strategier som håndterer ikke-deterministisk virkemåte.

Laste inn testing i Full kopi-Sandbox: Test agentytelsen under belastning i produksjonsskala ved å bruke fulle datavolumer. Simulere samtidige samtaler som samsvarer med høy etterspørsel. Mål p95- og p99-latens for å identifisere ytelsesreduksjon under stress. Valider styringsgrensen for forbruk holdes under terskler ved høy belastning. Innlasting av testing i en Delvis kopi-Sandbox-organisasjon med reduserte data gir villedende konfidens fordi datavolumet direkte påvirker agentytelsen. Før du kjører disse testene må du få godkjenning fra Salesforce (minst én uke før forespørsler om ytelsestester). Ikke-godkjente tester kan bli begrenset eller blokkert.
Feilinjeksjon: Innfør med vilje feil for å validere gjenopprettingsmekanismer. Simulere LLM-utledningsfeil i tjenestelaget som kretsbryteren overvåker, for å kontrollere at bryteren aktiveres. Injiser SOQL-unntak for å teste feilhåndtering. Korrupte agentsvar for å teste valideringslogikk. Introduser dataskift (kontoer med 10 000+ underordnede) for å teste pagineringslogikk. Angi aggressive tidsavbrudd for å teste tidsavbruddsbehandling og prøve på nytt-strategier.
Kaosteknikk: Deaktiver tilfeldig plattformhendelsesabonnenter for å teste gjentagelsesgjenoppretting. Avslutt asynkrone jobber midt i utførelsen for å teste gjenstart av sjekkpunkt. Introduser variabel latens i eksterne systemer for å teste progressive tidsavbruddsstrategier. Kaoseksperimenter validerer fleksibilitet i realistiske feilkombinasjoner. Planlegg regelmessige kaosdager i oppstillingsmiljøer, og behold motstandskraften etter hvert som agenter utvikler seg.
Langvarige stabilitetstester: Utfør agentarbeidsbelastninger kontinuerlig i mer enn 72 timer, og overvåk tidsavhengige feil. Akkumulere feil og gradvis redusere ytelsen bare under vedvarende drift. Spor CPU-tidstrender for å identifisere gradvis nedgang i løpet av kjøringen.

Definer tjenestenivåindikatorer (SLI-er) som aktiverer måling av objektiv pålitelighet. Opprett enkeltavlogginger før byggeagenter, ikke etter produksjonsfeil.

Samtale vellykket: Prosentandelen av agentdiskusjoner som er fullført uten feil eller tidsavbrudd. Teller en god overlevering til et menneske som en suksess, ikke en feil – eskalering er det endelige tilbakeslagsnivået etter utforming. Teller mislykkede eller utilsiktede eskaleringer mot målingen – det er et nyttig pålitelighetssignal, men en ufullkommen proxysignal for brukeropplevelsen, fordi en høflig avlogging kan maskere et uløst problem. Spor separat etter agenttype og bruksområde fordi kriterier for vellykket scoring av salgsemner er forskjellige fra kontraktgjennomgang. Varsle når suksessfrekvensen faller under SLO (vanligvis 95–99 %).
Midtime between failures (MTBF): Gjennomsnittlig åpningstid mellom agentfeil. Høyere MTBF angir færre feil og bedre pålitelighet. Beregne som totalt antall agentenes åpningstider dividert med antall feil. Spor per agenttype for å identifisere minst pålitelige agenter som krever optimaliseringsinvesteringer.
Middeltid til gjenoppretting (MTTR): Gjennomsnittstiden fra feildeteksjon til gjenoppretting av service. Automatisk gjenoppretting via plattformhendelsesgjenopptak og kryssbrytere gjenoppretter service mye raskere og med færre manuelle feil enn praktisk intervensjon. Lavere MTTR reduserer forretningseffekten per hendelse.
Grunnleggingsnøyaktighet: Prosentandelen av agentsvar er faktisk riktige basert på validering av kildedata. Eksempler på tilfeldige agentsvar for å validere krav mot Data 360-kilder. Nøyaktighet under 95 % angir hallusinasjonsproblemer som krever rask forbedring eller bedre kontekstgjennomgang.
Gap i repetisjon av plattformhendelse: Antall manglende eller ikke-leverte hendelser, for eksempel en abonnent offline utenfor oppbevaringsvinduet. Null gap er et positivt signal om en sunn hendelsesdrevet arkitektur. Luker angir abonnentproblemer, feil i publiseringen av hendelser eller kapasitetsbegrensninger. Spor disse gapene med loggingsmønsteret på abonnentsiden som er beskrevet ovenfor, og registrer hver hendelses replayId og korrelasjons-ID til et tilpasset objekt.

Pålitelige agenter kommer fra å utforme for feil på forhånd – definere SLI-er/enkeltavlogginger, styringsgrensebevisst konteksthåndtering og flere nivåer av reservekjeder før bygging, og ikke overføre dem etterpå. Lagkretsbrytere og plattformhendelsesbasert ny prøve- og sjekkpunktlogikk slik at arbeidsflyter gjenopprettes automatisk, med personlig overføring som siste utvei. Valider denne utformingen gjennom systematisk innlasting, feilinnsprøving og kaosstesting, og følg deretter med å overvåke de samme SLI-ene i produksjonsorganisasjonen for å bekrefte at de holder på over tid.

Retningslinjene for pålitelighet i hovedpilen Pålitelighet gjelder for agenter med plattformspesifikke vurderinger som dekkes her. Vellykkede agentarkitekturer balanserer autonom funksjonalitet med riktig overvåking, og aktiverer selvgjenoppretting fra midlertidige feil samtidig som de eskaleres når tillit faller eller kanttilfeller dukker opp.

Dele tilbakemeldingene dine om det velbygde rammeverket.