Pålidelighed for agentvirksomheden

Autonome agenter introducerer ikke-deterministiske kørselsmønstre, der er fundamentalt forskellige fra traditionel Salesforce-automatisering. Mens Salesforce Flow og Apex følger forudsigelige stier, der producerer gentagne resultater under kontrollerede forhold, forstår agenterne problemer dynamisk. Det samme spørgsmål, der stilles to gange, kan f.eks. tage forskellige kørselsstier, forbruge forskellige ressourcer og oprette forskellige resultater. Denne ikke-determinisme skaber pålidelighedsudfordringer, som traditionelle test- og overvågningsmetoder ikke håndterer.

Fejltilstande for agentsikkerhed er kategorisk forskellige fra Salesforce-forløbs- eller Apex. Stor sprogmodel (LLM)-afledningstjenester repræsenterer eksterne afhængigheder med tilgængelighedskarakteristika adskilt fra Salesforce-platformen. Agenter genererer svar, der lejlighedsvis overtræder den forventede struktur på trods af meddelelsesinstruktioner. Forberedelse af agentkontekst forbruger styringsbegrænsninger uforudsigeligt. Ikke-begrænset hentning af data påvirker agenter mere alvorligt, fordi agenter kan anmode om åben kontekst, mens deterministiske forespørgsler har eksplicit omfangskontrol.

Pålidelige agentarkitekturer kræver en tilbagerulningskæde på flere niveauer, der nedbrydes på en god måde – fra sofistikerede agenter til enklere agenter med reduceret kontekst, til deterministiske regelsystemer og til sidst til menneskelig håndtering via Omni-Channel. Platformsbegivenheder styrker holdbare prøvekøer med kontrolpunktmønstre, så mislykkede arbejdsflows kan genoptages fra det sidste vellykkede trin. Afbrydere sporer LLM-servicetilstand i platformscache for status i realtid, understøttet af tilpassede metadatatyper for tærskler og konfiguration, distribuerer til tilbagerulningsmønstre efter på hinanden følgende fejl. Overvågning kræver sporing af samtalesuccesfrekvenser, gennemsnitstid mellem fejl (MTBF), gennemsnitstid til gendannelse (MTTR) og nøjagtighed for grundlægning. Agentforce Observability leverer sessionsspor, tilstands- og forsinkelsesmetrikker og eskalerings- og afledningsfrekvenser, men du skal stadig selv instrumentere pålidelighedsmetrikker som MTBF, MTTR og jordnøjagtighed.

Dette dokument dækker, hvad der ændres, når agenter er på billedet. Hvis du ønsker grundlæggende pålidelighedsmønstre, der gælder for alle Salesforce-løsninger (SLO-design, fejltolerance, skalering og overvågning), kan du se søjlen Pålidelighed.

Agentforce mislykkes på andre måder end Salesforce-forløb eller Apex. Forståelse af disse fejltilstande er det, der udformer pålidelighedsarkitekturen.

• LLM service utilgængelighed: LLM-afslutningsslutpunkter oplever lejlighedsvis spids af forsinkelse eller tilgængelighedsproblemer. Agentforce er angivet som et overvåget produkt på Trust.salesforce.com sammen med Analytics og andre Salesforce-tjenester. Men detaljerede LLM-understregningsforsinkelser og præstationsmetrikker pr. anmodning vises ikke der. Implementer afbrydere ved at bruge Platformscache til tilstanden med lav forsinkelse i realtid, understøttet af tilpassede metadatatyper for tærskler og konfiguration, til at spore LLM-servicetilstanden. Platformscache er det bedste – poster kan udvises før deres tid til live (TTL) – så bevar tilstanden Åben/udløst i en holdbar butik, f.eks. et tilpasset objekt, snarere end kun cachen. Indstil rejsebetingelsen til slutpunktet: en optælling af på hinanden følgende fejl (f.eks. fem) eller en fejlfrekvens, der krydser en tærskel over et rullende vindue. Når kredsløbet kører, skal du åbne det og distribuere det til tilbagerulningsmønstre, f.eks. enklere meddelelser, cachelagrede svar eller menneskelig overførsel, indtil en vellykket testanmodning angiver gendannelse.
• Svarvalideringsfejl: Agenter genererer lejlighedsvis svar, der overtræder den forventede struktur, på trods af meddelelsesinstruktioner. En agent returnerer nogle gange forkert udformet JSON, udelader påkrævede felter eller inkluderer uventede datatyper. Platformscache kan lagre validerede svarskemaer og aktivere hurtig validering. Når valideringen mislykkes, kan du prøve igen med justerede meddelelser, herunder valideringsfejlen og et eksempel på korrekt struktur. Angiv et maksimalt antal forsøg (3-5) for at forhindre uendelige forsøgsløkker.
• Hallucinationsregistrering: Når landestandardsdata er ufuldstændige, opretter agenter sandsynlige, men ukorrekte oplysninger. I modsætning til deterministiske forespørgsler, der returnerer “ikke fundet”, udfylder agenter huller med konklusion. Einstein Trust Layer Audit Trail logfører hver meddelelse, maskeret meddelelse, svar, toksicitetsregistreringsresultat og brugerfeedback til efterfølgende styringsgennemgang. Men det registrerer ikke trinvise argumentationsspor. For trinvis registrering af årsag skal du bruge Agentforce, som registrerer kørsler af årsagssystem. Kræv, at agenter skal anføre RAG- hentningskilder for Data 360 (tidligere Data Cloud). Krydsreferenceagentkrav mod hentede kilder for at fange faktiske afvigelser før handlingskørsel. En indbygget kontrol tilføjer lidt forsinkelse, da den kører mod kilder, der allerede er i kontekst. En kontrol, der kræver en separat rundtur, f.eks. et andet modelopkald eller en ekstern tjeneste, koster mere. Reserver disse kontroller for højt påvirkende skrivninger, herunder finansielle eller bestillingsopdateringer, og kør dem asynkront under en samtale i realtid.
• Governor limit spikes: Agentkontekstforberedelse forbruger SOQL-forespørgsler (Salesforce object query language), CPU-tid og heap-hukommelse uforudsigeligt baseret på samtaleforløb. Proactive Monitoring er en Signature Success-berettigelsestjeneste (tidligere Signature Support) i Salesforce Success Plan, hvor Salesforce proaktivt overvåger kundekonti. Proactive Monitoring er ikke en selvbetjening konfigurerbar alarm tilgængelig for alle kunder. For overvågning af grænser for selvbetjeningsstyring skal du bruge Skalacenter til at identificere ressourceintensive agenthandlinger, der nærmer sig grænser. Implementer sideinddeling i agenthandlinger, der henter store registreringssamlinger. For hyppigt åbnede referencedata skal du bruge Platformscache.
• Data skæve i agentkontekst: Agenter, der henter kontekst for konti med mere end 10.000 salgsmuligheder, eller sager med sammenligneligt stor aktivitetshistorik, støder på de samme dataforskydningsudfordringer som Batch Apex. I modsætning til deterministiske forespørgsler, hvor du kontrollerer omfanget, kan agentarrangering anmode om “hele historikken” uforudsigeligt. For at forhindre dette skal du designe agenthandlinger med fornuftige hårde grænser (f.eks. et hæfte på rækkefølgen af 200 underordnede pr. overordnet) og implementere prøveudtagningsstrategier, når grænserne overskrides. Lukket afgrænser, hvor mange data der indsættes i agentens kontekst. Par den med selektive, indekserede filtre, så selve forespørgslen forbliver billig, da et ikke-indekseret filter eller en aggregering på en skæve overordnet scanner det fulde underordnede sæt, før overgangen anvendes.

Design tilbagerulningskæder på flere niveauer, så agenter kan fortsætte med at fungere med reduceret kapacitet i stedet for at mislykkes fuldstændigt.

• Primær agent med fuld kontekst: Sofistikeret agent med komplet Data 360-basis, omfattende samtalehistorik og kompleks argumentation. Højeste kvalitet, men mest ressourceintensive og højeste fejlrisiko.
• Sekundær agent med reduceret kontekst: Enklere agent ved brug af kondenseret kontekst (f.eks. de sidste 30 dage i forhold til al historik, top 5 vektorsøgeresultater i forhold til top 20). Mindre kontekst betyder færre tokener, hurtigere afledning og en lavere chance for fejl, men kun hvis den reducerede kontekst stadig dækker de data, som opgaven har brug for.
• Deterministisk regelsystem: Traditionelt Salesforce-forløb eller Apex, der håndterer almindelige scenarier, når agentarrangering mislykkes. Regler kan ikke tilpasse sig nye situationer, men de håndterer kendte mønstre på en pålidelig måde. Bestillingsvalideringsagenten falder tilbage til standardvalideringsregler, mens emnescoringsagenten falder tilbage til regelbaseret resultatberegning.
• Human handoff via Omni-Channel: Distribuer til den menneskelige kø, når automatiserede indstillinger er udtømte. Konfigurer færdighedsbaseret distribution for at sikre, at eskaleringer når den relevante ekspertise. Overfør fuld samtalekontekst – herunder forsøgte strategier, eventuelle konfidensscores, du beregner for agenten, og fejlårsager – for at aktivere effektiv menneskelig intervention.

Implementer tilbagerulningslogik i orkestrering af Salesforce-forløb eller Apex udløst af platformsbegivenheder. Hvert niveau logfører, hvilken strategi der lykkedes, og skaber synlighed i fejlmønstre og tilbagerulningseffektivitet.

Alle mønstre for platformsbegivenhed i dette afsnit forudsætter højvolumen platformsbegivenhedstyper, som giver det 72-timers genafspilningsvedligeholdelsesvindue. Standardvolumen platformsbegivenheder bevares kun i 24 timer. Brug højvolumen begivenhedstyper til alle agentresiliens, forsøgskø og kontrolpunktmønstre, hvor afspilning af holdbarhed er et pålidelighedskrav. Platformsbegivenheder leverer holdbare meddelelser, der aktiverer agentarbejdsflows til at overleve fejl og gendanne automatisk.

• Kontrolpunkts agentstatus: Agentarbejdsflows med flere trin udgiver kontrolpunktbegivenheder efter hvert vellykket trin. Kontraktbehandlingsagent fuldfører dokumentudtrækning, udgiver ContractParsed-begivenheden med udtrukne data og fortsætter derefter til sætningsanalyse. Hvis en sætningsanalyse mislykkes, kan du afspille ContractParsed-begivenheden igen for at genoptage fra de udtrukne data uden at parse igen. Dette fungerer, når kontrolpunktets data bærer data, og abonnenten er idempotent, fordi genafspilning leverer begivenheder snarere end genoptagelse af et arbejdsflow midt i trinnet. Gem kontrolpunktstilstand i begivenhedsdata, herunder korrelations-id, fuldførte trin og tilstand, der er nødvendig for fortsættelse.
• Gentagelseskø med eksponentiel tilbagerulning: Mislykkede agentanmodninger udgives til AgentRetryRequested-begivenhed med optælling af forsøg i data. Begivenhedsabonnent behandler forsøg med eksponentielle tilbagerulningsforsinkelser (f.eks. 30 sek, 2 min, 8 min, 30 min). Efter maksimale forsøg (typisk 5), skal du distribuere til død-bogstav-kø og advarselshandlinger. Højvolumen platformsbegivenheder bevarer et 72-timers genafspilningsvindue. Brug begivenhedstypen Højvolumen for agentforsøgskøer, så abonnenter kan komme i gang efter organisationsvedligeholdelsesvinduer eller implementeringsnedetid. Standardvolumen platformsbegivenheder bevares kun i 24 timer.
• Begivenhedsstyret orkestrering: Design agentarbejdsflows som løst sammenkoblede begivenhedskæder. Emneoprettelse udgiver LeadCreated. Emnescoringsagenter abonnerer, scorer og udgiver LeadScored. Emnedistributionsagent abonnerer på LeadScored og tildeler til den relevante kø. Hver agent kan mislykkes og forsøge igen uafhængigt. En enkelt agentfejl blokerer ikke hele arbejdsflowet – downstream-agenter behandler, når afhængighederne gendannes.
• Sporing af korrelations-id: Inkluder et korrelations-id som et tilpasset felt i alle relaterede begivenhedsdata. Genafspil begivenheder ved at bruge Pub/Sub API by replayId, en uigennemsigtig, ikke-sammenhængende identifikator, til at rekonstruere arbejdsflowhistorikken i det 72-timers bevarelsesvindue. Hvis du vil aktivere korrelations-id-baseret fejlfinding, skal du implementere et mønster på abonnentsiden, der logfører indgående begivenheder med deres replayId og korrelations-id til et tilpasset objekt og aktiverer sporbarhed af krydsbegivenheder. Dette logføringsmønster er en tilpasset implementering, som du selv opbygger, ikke en indbygget platformsforespørgselsfunktion.

Flyt agenthandlinger, der overskrider synkrone grænser, til en asynkron kontekst, hvilket tillader højere styringsbegrænsninger og længere timeouts.

• Batch Apex for masseagenthandlinger: En agent, der analyserer 1.000+ registreringer, drager fordel af Batch Apex, der leverer 200 SOQL-forespørgsler, 150 DML-erklæringer (op til 10.000 DML-rækker) og 60.000 millisekunder (60 sekunder) CPU-tid pr. udførelsesmetode. Emnescoringsagent, der behandler natlige emneimporter. Sessentialanalyse på tværs af historiske sager. Salgsmulighedsprognoser, der analyserer komplette pipelines.
• Kæder i kø til flertrinsarbejdsflows: Komplekse agentarbejdsflows, der kræver flere eksterne API-kald, analyse af store datasæt eller udvidet behandlingstid, bruger Apex, der kan sættes i kø. Hvert job, der kan sættes i kø, får 60 CPU-tid og 12 MB hukommelse. Kæde til næste Kan sættes i kø for arbejdsflows, der overskrider grænserne for enkelt job. Spor status i tilpassede objekter, så et mislykket job kan genoptages fra det sidste fuldførte trin.
• @future for simple asynkrone håndteringer: Lightweight-agenthandlinger, f.eks. afsendelse af adviseringer, logning på eksterne systemer eller ikke-nødvendige opdateringer, bruger @future-metoder. Fire-og-glem-mønsteret passer, når et arbejdsflow ikke har brug for resultater tilbage og kan tolerere fejl.

Overvåg asynkron behandlingskapacitet via siden Apex (Opsætning → Apex) og Apex Flex-køen. Et maksimum på 5 samtidige batchjob begrænser parallel agentbehandling. Yderligere job kø i Apex Flex-køen, som indeholder op til 100 job i statussen Holding. Alle asynkrone Apex-typer, Batch, Future, Queueable og Scheduled Apex, deler den samme daglige grænse for hele organisationen (DailyAsyncApexExecutions) på asynkrone Apex-kørsler: Det er større end 250.000 eller 200 gange antallet af brugerlicenser. Når du kører agentpolling med høj frekvens eller forsøger abonnentkøer igen, kan Køer hurtigt opbruge denne kvote. Hvis du vil undgå dette, skal du batche eller dæmpe disse køer for at forblive inden for grænsen – hvilket gælder for hele organisationen på tværs af alle asynkrone Apex, ikke som en separat tildeling for Kun kø. Advar, når forbruget nærmer sig disse grænser, så teams kan administrere kapacitet proaktivt.

Valider agentresiliens før produktion gennem teststrategier, der håndterer ikke-deterministisk adfærd.

• Indlæsningstest i fuld kopi-sandbox: Test agentydeevne under produktionsskalaindlæsning ved brug af fulde datamængder. Simuler samtidige samtaler, der matcher spidsefterspørgsel. Mål p95 og p99-forsinkelse, der identificerer ydeevnedegradering under stress. Valider styringsbegrænsning for forbrug forbliver under tærskler ved spidsbelastning. Indlæsningstest i en Delvis kopi-sandbox med reducerede data giver vildledende tillid, da datamængden direkte påvirker agentydeevnen. Før du kører disse test, skal du få godkendelse fra Salesforce (mindst en uge før for anmodninger om ydeevnetest). Ikke-godkendt test kan begrænses eller blokeres.
• Fejlindsprøjtning: Introducer forsætligt fejl for at validere gendannelsesmekanismer. Simuler fejl ved LLM-afledning i det servicelag, som din afbryder overvåger, for at bekræfte, at afbryderen aktiveres. Indsæt SOQL-undtagelser for at teste fejlhåndtering. Korrupt agentsvar for at teste valideringslogik. Introducer dataskydning (konti med 10.000+ underordnede) for at teste sideinddelingslogik. Angiv aggressive timeouts for at teste timeouthåndtering og prøve strategier igen.
• Chaos engineering: Inaktiver tilfældigt abonnenter på platformsbegivenhed for at teste gendannelse af afspilning. Afslut asynkrone job midt i kørsel for at teste genstart af kontrolpunkt. Introducer variabel forsinkelse til eksterne systemer for at teste progressive timeoutstrategier. Chaoseksperimenter validerer modstandsdygtighed i realistiske kombinationer af fejl. Planlæg regelmæssige kaosdage i faseinddelte miljøer, og bevar modstandsdygtigheden, efterhånden som agenter udvikler sig.
• Langvarig stabilitetstest: Udfør agentarbejdsbelastninger kontinuerligt i over 72 timer, og overvåg for tidsafhængige fejl. Akkumulerede fejl og gradvis nedsættelse af ydeevne, kun under vedvarende drift. Spor CPU-tidstendenser for at identificere gradvis nedbrydning over kørslen.

Definer serviceniveaumærker (SLI’er), der aktiverer måling af objektiv pålidelighed. Opret SLO’er før opbygning af agenter, ikke efter produktionsfejl.

• Samtalesuccesfrekvens: Procentdel af agentsamtaler, der er fuldført uden fejl eller timeouts. Tæller en venlig afvisning til et menneske som en succes, ikke en fejl – eskalering er det endelige tilbagerulningsniveau efter design. Tæl mislykkede eller utilsigtede eskaleringer op mod metrikken – det er et nyttigt pålidelighedssignal, men et ufuldstændigt proxy for brugeroplevelsen, da en høflig sign-off kan maskere et uløst problem. Spor separat efter agenttype og anvendelsessituation, da succeskriterier for emnescoring er forskellige fra kontraktgennemgang. Advar, når succesfrekvensen falder under SLO (typisk 95-99 %).
• Middeltid mellem fejl (MTBF): Gennemsnitlig arbejdstid mellem agentfejl. Højere MTBF angiver færre fejl og bedre pålidelighed. Beregn som samlet agentarbejdstid divideret med fejlantal. Spor pr. agenttype for at identificere de mindst pålidelige agenter, der kræver optimeringsinvestering.
• Gennemsnitlig tid til opsving (MTTR): Gennemsnitlig tid fra fejlregistrering til servicegendannelse. Automatiseret gendannelse via afspilning af platformsbegivenhed og afbrydere gendanner service meget hurtigere og med mindre manuel fejl end praktisk intervention. Lavere MTTR reducerer forretningspåvirkning pr. hændelse.
• Jordsnøjagtighed: Procentdel af agentsvar er faktisk korrekte baseret på kildedatavvalidering. Eksempel på vilkårlige agentsvar for at validere skader mod Data 360-kilder. Jordsnøjagtighed under 95 % angiver hallucinationsproblemer, der kræver hurtig justering eller bedre kontekst hentning.
• Fortrydelsesmangler for platformsbegivenhed: Antal manglende eller ikke-leverede begivenheder, f.eks. en abonnent offline ud over bevarelsesvinduet. Nulmangler er et positivt signal om en sund begivenhedsstyret arkitektur. Mangler angiver abonnentproblemer, fejl ved begivenhedsudgivelse eller kapacitetsbegrænsninger. Spor disse huller med logføringsmønsteret på abonnentsiden, som beskrevet ovenfor, og registrer hver begivenheds replayId og korrelations-id til et tilpasset objekt.

Pålidelige agenter kommer fra at designe til fejl på forhånd – definere SLI’er/SLO’er, styringsbegrænsningsbevidst konteksthåndtering og tilbagerulningskæder på flere niveauer før opbygning, ikke skrue dem op efterfølgende. Lagcirkulationsafbrydere og platformsbegivenhedsbaseret forsøgs- og kontrolpunktlogik, så arbejdsflows gendannes automatisk med menneskelig overførsel som sidste udvej. Valider dette design gennem systematisk indlæsning, fejlindsprøjtning og kaostest, og fortsæt derefter med at overvåge de samme SLI’er i produktion for at bekræfte, at de holder op over tid.

Pålidelighedsvejledningen i hovedpilen Pålidelighed gælder for agenter med platformsspecifikke overvejelser, der er omfattet her. Succesfulde agentarkitekturer afbalancerer autonom funktionalitet med relevant overvågning, så de aktiverer selvgendannelse fra midlertidige fejl, mens de eskalerer, når tilliden falder eller der opstår kanttilfælde.

Del din feedback om den veludformede ramme.