Betrouwbaarheid voor de Agentic Enterprise

Autonome agenten introduceren niet-deterministische uitvoeringspatronen die fundamenteel verschillen van traditionele Salesforce-automatisering. Salesforce Flow en Apex volgen voorspelbare trajecten die onder gecontroleerde omstandigheden herhaalbare resultaten opleveren, maar agenten redeneren dynamisch door problemen heen. Zo kan dezelfde vraag die twee keer wordt gesteld, verschillende uitvoeringstrajecten doorlopen, verschillende resources verbruiken en verschillende resultaten opleveren. Dit non-determinisme creëert betrouwbaarheidsproblemen die traditionele test- en bewakingsmethoden niet oplossen.

Faalmodi voor agentbetrouwbaarheid zijn categorisch verschillend van Salesforce Flow- of Apex mislukkingen. Large Language Model (LLM)-inferentieservices vertegenwoordigen externe afhankelijkheden met beschikbaarheidskenmerken die los staan van het Salesforce-platform. Agenten genereren responsen die af en toe de verwachte structuur schenden, ondanks instructies. Agentcontextvoorbereiding verbruikt beheerlimieten onvoorspelbaar. Onbeperkt ophalen van gegevens heeft een grotere invloed op agenten, omdat agenten om open context kunnen verzoeken terwijl deterministische query’s expliciete controle over het bereik hebben.

Betrouwbare agentarchitectuur vereist een reserveketen van meerdere lagen die elegant wordt afgebroken—van geavanceerde agenten naar eenvoudiger agenten met beperkte context, naar deterministische regelengines en tenslotte naar menselijke overdracht via Omni-Channel. Platform-events ondersteunen wachtrijen voor duurzaam opnieuw proberen met controlepuntenpatronen, waardoor mislukte werkstromen kunnen worden hervat vanaf de laatste succesvolle stap. Stroomonderbrekers houden de status van de LLM-service bij in het platformcachegeheugen voor realtime status, ondersteund door typen aangepaste metagegevens voor drempelwaarden en configuratie, routering naar reservepatronen na opeenvolgende storingen. Bewaking vereist het bijhouden van gesprekssuccesscores, gemiddelde tijd tussen mislukkingen (MTBF), gemiddelde tijd tot herstel (MTTR) en aardingsnauwkeurigheid. Agentforce Observability biedt sessietraceringen, gezondheids- en latentiemeetgegevens, en escalatie- en omleidingsscores, maar u moet betrouwbaarheidsmeetgegevens zoals MTBF, MTTR en aardingsnauwkeurigheid nog steeds zelf bepalen.

Dit document behandelt wat er verandert wanneer agenten in beeld zijn. Zie de pijler Betrouwbaarheid voor fundamentele betrouwbaarheidspatronen die van toepassing zijn op alle Salesforce-oplossingen (ontwerp van serviceniveauobjecten, fouttolerantie, schalen en bewaken).

Agentforce agenten mislukken op andere manieren dan Salesforce Flow of Apex. Inzicht in deze foutmodi is wat de betrouwbaarheidsarchitectuur bepaalt.

LLM-service niet beschikbaar: LLM-inferentie-eindpunten ondervinden incidentele latentiepieken of beschikbaarheidsproblemen. Agentforce wordt vermeld als een bewaakt product op Trust.salesforce.com naast Analytics en andere Salesforce-services. Granulaire LLM-inferentielatentie en prestatiemeetgegevens per verzoek zijn daar echter niet zichtbaar. Implementeer stroomonderbrekers door middel van Platformcachegeheugen voor realtime status met lage latentie, ondersteund door Typen aangepaste metagegevens voor drempelwaarden en configuratie, om de status van LLM-services bij te houden. Platformcachegeheugen is een uitstekende manier om gegevens te verwijderen voordat ze live gaan. Houd de status open/uitgeschakeld dus in een duurzame store, zoals een aangepast object, in plaats van alleen het cachegeheugen. Stem de conditie van de reis af op het eindpunt: een telling van opeenvolgende mislukkingen (bijvoorbeeld vijf) of een foutenpercentage dat een drempel overschrijdt over een voortschrijdende periode. Wanneer het circuit uitschakelt, opent u het en routeert u het naar reservepatronen, zoals eenvoudigere aanwijzingen, cachereacties of menselijke overdracht, totdat een succesvol testverzoek herstel aangeeft.
Fouten bij validatie van antwoorden: Agenten genereren af en toe reacties die de verwachte structuur schenden, ondanks instructies. Een agent retourneert soms JSON met een verkeerde notatie, laat verplichte velden weg of neemt onverwachte gegevenstypen op. Platformcachegeheugen kan gevalideerde reactieschema’s opslaan, waardoor snelle validatie mogelijk is. Wanneer validatie mislukt, probeert u het opnieuw met verfijnde aanwijzingen, inclusief de validatiefout en een voorbeeld van de juiste structuur. Stel een maximaal aantal pogingen in (3—5) om oneindige herhalingslussen te voorkomen.
Hallucinatiedetectie: Wanneer aardingsgegevens onvolledig zijn, produceren agenten plausibele maar onjuiste informatie. In tegenstelling tot deterministische query’s die “niet gevonden” retourneren, vullen agenten hiaten op met gevolgtrekkingen. Het Einstein Trust Layer Audit Trail legt elke aanwijzing, gemaskerde aanwijzing, reactie, toxiciteitsdetectieresultaat en feedback van gebruikers vast voor beoordeling na de hoc-governance. Er worden echter geen stapsgewijze redeneringssporen vastgelegd. Gebruik voor het stapsgewijs vastleggen van redeneringen Agentforce Sessietracering, dat uitvoeringen van de redeneringsengine vastlegt. Verplicht agenten om bronnen te vermelden voor het ophalen van gegevens via RAG’s (Data 360, voorheen Data Cloud). Agentclaims vergelijken met opgehaalde bronnen om feitelijke afwijkingen te detecteren vóór de uitvoering van de actie. Een inline controle voegt weinig latentie toe, omdat deze wordt uitgevoerd op bronnen die al in context staan. Een controle die een afzonderlijke retour nodig heeft, zoals een tweede modelgesprek of een externe service, kost meer. Reserveer deze controles voor schrijven met grote impact, inclusief financiële updates of orderupdates, en voer deze asynchroon uit tijdens realtime gesprekken.
Pieken van limieten voor gouverneurs: Agentcontextvoorbereiding verbruikt Salesforce-querytaalquery’s (SOQL-query’s), CPU-tijd en heapgeheugen onvoorspelbaar op basis van gespreksstroom. Proactive Monitoring is een rechtenservice voor Signature Success (voorheen Signature Support) in het Salesforce Success Plan, waarbij Salesforce proactief klantaccounts bewaakt. Proactive Monitoring is geen selfservice configureerbare waarschuwing die voor alle klanten beschikbaar is. Gebruik voor selfservicebeheerlimietbewaking Scale Center om resource-intensieve agentbewerkingen te identificeren die limieten naderen. Implementeer paginering in agentacties die grote recordverzamelingen ophalen. Gebruik Platformcachegeheugen voor vaak geopende verwijzingsgegevens.
Gegevens scheef in agentcontext: Agenten die context ophalen voor accounts met meer dan 10.000 opportunities, of cases met een vergelijkbaar grote activiteithistorie, ondervinden dezelfde problemen met scheefgetrokken gegevens als Batch Apex. In tegenstelling tot deterministische query’s waarbij u het bereik bepaalt, kan redeneren door agenten “alle historie” onvoorspelbaar opvragen. Om dit te voorkomen ontwerpt u agentacties met verstandige harde limieten (bijvoorbeeld een limiet van ongeveer 200 kinderen per bovenliggend niveau) en implementeert u steekproefstrategieën wanneer limieten worden overschreden. De limiet bepaalt hoeveel gegevens de context van de agent binnenkomen. Combineer deze met selectieve, geïndexeerde filters zodat de query zelf goedkoop blijft, aangezien een niet-geïndexeerd filter of aggregatie op een vertekend bovenliggend niveau de volledige onderliggende set scant voordat de limiet wordt toegepast.

Ontwerp reserveketens met meerdere lagen, zodat agenten kunnen blijven functioneren met verminderde mogelijkheden in plaats van volledig te mislukken.

Primaire agent met volledige context: Geavanceerde agent met volledige Data 360-basis, uitgebreide gesprekshistorie en complexe redeneringen. Hoogste kwaliteit, maar meest resource-intensief en hoogste risico op storingen.
Secundaire agent met beperkte context: Eenvoudigere agent die een beknopte context gebruikt (bijvoorbeeld de afgelopen 30 dagen t.o.v. alle historie, top 5 vectorzoekresultaten t.o.v. top 20). Kleinere context betekent minder tokens, snellere gevolgtrekkingen en een lagere kans op mislukking, maar alleen als de gereduceerde context nog steeds de gegevens dekt die de taak nodig heeft.
Deterministische regelengine: Traditionele Salesforce Flow of Apex logica die veelvoorkomende scenario’s afhandelt wanneer redeneren door agenten mislukt. Regels kunnen zich niet aanpassen aan nieuwe situaties, maar gaan wel betrouwbaar om met bekende patronen. De ordervalidatieagent valt terug op standaardvalidatieregels, terwijl de leadscoreagent terugvalt op op regels gebaseerde scoreberekening.
Humane overdracht via Omni-Channel: Routeer naar menselijke wachtrij wanneer geautomatiseerde opties zijn uitgeput. Configureer op vaardigheden gebaseerde routering om ervoor te zorgen dat escalaties de juiste expertise bereiken. Geef de volledige gesprekscontext door—inclusief gepoogde strategieën, eventuele vertrouwensscores die u voor de agent berekent, en redenen voor mislukking—om efficiënt menselijk ingrijpen mogelijk te maken.

Implementeer reservelogica in doeltreffende combinatie Salesforce Flow of Apex geactiveerd door Platform-events. Elke laag legt vast welke strategie is geslaagd, waardoor zichtbaarheid in foutpatronen en terugvaleffectiviteit ontstaat.

Alle Platform-eventpatronen in deze sectie gaan uit van Platform-eventtypen met groot volume, die de bewaarperiode van 72 uur voor opnieuw afspelen bieden. Platformevents met standaardvolume worden slechts 24 uur bewaard. Gebruik eventtypen met groot volume voor alle agentbestendigheids-, wachtrij voor opnieuw proberen- en controlepuntpatronen waarbij duurzaamheid van opnieuw afspelen een betrouwbaarheidsvereiste is. Platform-events bieden duurzaam berichtenverkeer waardoor agentwerkstromen mislukkingen overleven en automatisch worden hersteld.

Voortgang van controlepuntagent: Agentwerkstromen met meerdere stappen publiceren controlepuntevents na elke succesvolle stap. Contractverwerkingsagent voltooit documentextractie, publiceert ContractParsed-event met geëxtraheerde gegevens en gaat vervolgens door met de analyse van clausules. Als clausuleanalyse mislukt, speelt u de event ContractParsed opnieuw af om te hervatten vanuit de geëxtraheerde gegevens zonder opnieuw te parseren. Dit werkt wanneer de payload van het controlepunt die gegevens bevat en de abonnee idempotent is, omdat opnieuw afspelen events levert in plaats van een werkstroom halverwege de stap te hervatten. Sla de status van het controlepunt op in de eventpayload, inclusief correlatie-ID, voltooide stappen en de status die nodig is voor voortzetting.
Wachtrij opnieuw proberen met exponentiële backoff: Mislukte agentverzoeken worden gepubliceerd naar de event AgentRetryRequested met telling van nieuwe pogingen in payload. Eventabonnee verwerkt pogingen met exponentiële backoff-vertragingen (bijvoorbeeld 30 sec, 2 min, 8 min, 30 min). Routeer na maximaal aantal pogingen (doorgaans 5) naar wachtrij voor dode letters en waarschuwingsbewerkingen. Platformevents met groot volume behouden een periode van 72 uur voor opnieuw afspelen. Gebruik eventtype met groot volume voor wachtrijen voor opnieuw proberen van agenten, zodat abonnees hun achterstand kunnen inhalen na onderhoudsperioden van de organisatie of uitval van de implementatie. Platformevents met standaardvolume worden slechts 24 uur bewaard.
Eventgestuurde doeltreffende combinatie: Ontwerp agentwerkstromen als los gekoppelde eventketens. Lead maken publiceert LeadCreated. Agent voor leadscores abonneert zich op, scoort en publiceert LeadScored. Leadrouteringsagent abonneert zich op LeadScored en wijst deze toe aan de juiste wachtrij. Elke agent kan mislukken en het onafhankelijk opnieuw proberen. Eén agentfout blokkeert niet de gehele werkstroom. Agenten verderop in de stroom verwerken wanneer afhankelijkheden zijn hersteld.
Correlatie-ID bijhouden: Neem een correlatie-ID op als aangepast veld in alle gerelateerde eventpayloads. Speel events opnieuw af met behulp van de Pub/Sub-API by replayId, een ondoorzichtige, niet-aaneengesloten identifier, om de werkstroomhistorie te reconstrueren binnen de bewaarperiode van 72 uur. Als u op correlatie-ID gebaseerde foutopsporing wilt inschakelen, implementeert u een patroon aan de abonneezijde dat inkomende events vastlegt met hun replayId en correlatie-ID naar een aangepast object, waardoor traceerbaarheid tussen events mogelijk wordt. Dit vastleggingspatroon is een aangepaste implementatie die u zelf samenstelt, niet een native platformquerymogelijkheid.

Verplaats agentbewerkingen die synchrone limieten overschrijden naar een asynchrone context, waardoor hogere beheerlimieten en langere time-outs mogelijk zijn.

Batch Apex voor bulkagentbewerkingen: Een agent die meer dan 1000 records analyseert, profiteert van Batch Apex met 200 SOQL-query’s, 150 DML-instructies (maximaal 10.000 DML-rijen) en 60.000 milliseconden (60 seconden) CPU-tijd per uitvoeringsmethode. Agent voor leadscores die ‘s nachts leadimports verwerkt. Casegevoelsanalyse voor alle historische cases. Opportunityprognoses die complete pijplijnen analyseren.
Wachtrijketens voor werkstromen met meerdere stappen: Complexe agentwerkstromen die meerdere externe API-aanroepen, grote gegevenssetanalyses of langere verwerkingstijd vereisen, gebruiken Apex ketens die in wachtrijen staan. Elke wachtrijtaak krijgt 60 CPU-tijd en 12 MB heap. Keten naar volgende Wachtrijbaar voor werkstromen die limieten voor één taak overschrijden. Houd de voortgang bij in Aangepaste objecten zodat een mislukte taak kan worden hervat vanaf de laatste voltooide stap.
@future voor eenvoudige asynchrone overdrachten: Lichtgewicht agentbewerkingen, zoals het verzenden van kennisgevingen, vastleggen bij externe systemen of niet-urgente updates, gebruiken @future-methoden. Het “fire-and-forget”-patroon past wanneer een werkstroom geen resultaten nodig heeft en mislukkingen kan tolereren.

Bewaak asynchrone verwerkingscapaciteit via de pagina Apex Taken (Set-up → Apex Taken) en de Apex Flex-wachtrij. Een maximum van 5 gelijktijdige batchtaken beperkt de verwerking van parallelle agenten; extra taken in de Apex Flex-wachtrij, die maximaal 100 taken in wachtstand bevat. Alle asynchrone Apex typen, Batch, Future, Queueable en Scheduled Apex, delen dezelfde organisatiebrede dagelijkse limiet (DailyAsyncApexExecutions) voor asynchrone Apex uitvoeringen: de grootste van 250.000 of 200 keer het aantal gebruikerslicenties. Wanneer u polling door agenten met hoge frequentie uitvoert of abonneewachtrijen opnieuw probeert, kan Queueables deze quota snel uitputten. Als u dit wilt voorkomen, batcht of verstikt u deze wachtrijen om binnen de limiet te blijven—die voor de hele organisatie geldt voor alle asynchrone Apex typen, niet als een afzonderlijke toewijzing voor alleen Wachtrijbaar. Waarschuw wanneer het verbruik deze limieten nadert, zodat teams capaciteit proactief kunnen beheren.

Valideer de veerkracht van agenten vóór productie door middel van teststrategieën die niet-deterministisch gedrag aanpakken.

Testen laden in Full Copy Sandbox: Test agentprestaties onder belasting op productieschaal door volledige gegevensvolumes te gebruiken. Simuleer gelijktijdige gesprekken die overeenkomen met piekvraag. Meet de latentie p95 en p99 en identificeer prestatievermindering onder stress. Verbruik van beheerlimiet valideren blijft onder drempelwaarden bij piekbelasting. Testen laden in een Partial Copy-sandbox met gereduceerde gegevens biedt misleidend vertrouwen, omdat het gegevensvolume rechtstreeks van invloed is op de prestaties van agenten. Voordat u deze tests uitvoert, moet u goedkeuring krijgen van Salesforce (ten minste een week eerder voor verzoeken om prestatietests). Niet-goedgekeurde tests kunnen worden afgeknepen of geblokkeerd.
Foutinjectie: Opzettelijk fouten introduceren om herstelmechanismen te valideren. Simuleer storingen in de LLM-inferentie in de servicelaag die uw stroomonderbreker bewaakt, om te controleren of de stroomonderbreker wordt geactiveerd. Injecteer SOQL-uitzonderingen om foutafhandeling te testen. Corrupte reacties van agenten om validatielogica te testen. Introduceer scheefgetrokken gegevens (accounts met meer dan 10.000 onderliggende waarden) om pagineringslogica te testen. Stel agressieve time-outs in om time-outafhandeling en strategieën voor opnieuw proberen te testen.
Chaosengineering: Schakel Platform-eventabonnees willekeurig uit om herstel van opnieuw afspelen te testen. Beëindig asynchrone taken halverwege de uitvoering om het controlepunt opnieuw te starten. Introduceer variabele latentie in externe systemen om progressieve time-outstrategieën te testen. Chaosexperimenten valideren veerkracht in realistische foutcombinaties. Plan regelmatig chaosdagen in faseringsomgevingen, waarbij u veerkracht behoudt terwijl agenten zich ontwikkelen.
Langlopende stabiliteitstests: Agentwerkbelastingen continu uitvoeren gedurende meer dan 72 uur, met bewaking op tijdafhankelijke storingen. Fouten die zich opstapelen en de prestaties geleidelijk verminderen, komen alleen onder langdurig gebruik aan de oppervlakte. Houd CPU-tijdtrends bij om geleidelijke degradatie tijdens de uitvoering te identificeren.

Definieer serviceniveau-indicatoren (SLI’s) die objectieve betrouwbaarheidsmetingen mogelijk maken. Stel SLO’s op vóór het samenstellen van agenten, niet na productiefouten.

Slaagpercentage van gesprek: Percentage agentgesprekken dat is voltooid zonder fouten of time-outs. Reken een gracieuze overdracht aan een mens als een succes, niet als een mislukking – escalatie is de laatste reservelaag door het ontwerp. Telling mislukte of onbedoelde escalaties ten opzichte van het meetgegeven—het is een nuttig betrouwbaarheidssignaal, maar een onvolmaakte proxy voor de gebruikerservaring, aangezien een beleefde afmelding een onopgelost probleem kan maskeren. Houd dit afzonderlijk bij op type agent en gebruikscase, aangezien succescriteria voor leadscores verschillen van contractbeoordeling. Waarschuw wanneer het succespercentage onder SLO zakt (doorgaans 95-99%).
Gemiddelde tijd tussen mislukkingen (MTBF): Gemiddelde operationele tijd tussen storingen van agenten. Een hogere MTBF duidt op minder storingen en een betere betrouwbaarheid. Berekenen als totale aantal bedrijfsuren van agenten gedeeld door aantal mislukkingen. Houd bij per type agent om minst betrouwbare agenten te identificeren die investeringen in optimalisering vereisen.
Gemiddelde tijd tot herstel (MTTR): Gemiddelde tijd tussen foutdetectie en serviceherstel. Geautomatiseerd herstel via opnieuw afspelen van Platform-events en stroomonderbrekers herstelt de service veel sneller en met minder handmatige fouten dan hands-on interventie. Lagere MTTR reduceert de impact op het bedrijf per incident.
Grondingsnauwkeurigheid: Percentage feitelijk correcte responsen van agenten op basis van brongegevensvalidatie. Voorbeeldreacties van willekeurige agenten voor het valideren van claims op basis van Data 360-bronnen. Een aardingsnauwkeurigheid van minder dan 95% duidt op hallucinatieproblemen die snelle verfijning of beter ophalen van context vereisen.
Gaten voor opnieuw afspelen van Platform-event: Aantal gemiste of niet geleverde events, bijvoorbeeld een abonnee offline buiten de bewaarperiode. Zero gaps is een positief signaal van een gezonde event-gestuurde architectuur. Hiaten duiden op problemen met abonnees, mislukkingen bij het publiceren van events of capaciteitsbeperkingen. Houd deze hiaten bij met het hierboven beschreven registratiepatroon aan de abonneezijde en leg de replayId en correlatie-ID van elke event vast voor een aangepast object.

Betrouwbare agenten ontstaan door vooraf te ontwerpen voor mislukking—het definiëren van SLI’s/SLO’s, beheer-limiet-bewuste contextafhandeling en reserveketens met meerdere lagen voordat ze worden samengesteld, niet om ze daarna vast te schroeven. Laagbeveiligingsschakelaars en op Platform-events gebaseerde logica voor opnieuw proberen en controleren, zodat werkstromen automatisch worden hersteld, met menselijke overdracht als laatste redmiddel. Valideer dat ontwerp door middel van systematische belastings-, foutinjectie- en chaostests, en blijf vervolgens dezelfde SLI’s in productie bewaken om te controleren of het in de loop van de tijd standhoudt.

De richtlijnen voor betrouwbaarheid in de hoofdpijler Betrouwbaarheid zijn van toepassing op agenten met platformspecifieke overwegingen die hier worden behandeld. Succesvolle agentarchitecturen combineren autonome mogelijkheden met passend overzicht, waardoor zelfherstel van tijdelijke storingen mogelijk is terwijl het escaleert wanneer het vertrouwen daalt of er randcases ontstaan.

Deel uw feedback over het Goed Architectuurde Framework.