Pålitlighet för Agentföretag

Autonoma agenter introducerar icke-deterministiska körmönster som är fundamentalt annorlunda än traditionell Salesforce-automatisering. Salesforce-flöden och Apex följer förutsägbara vägar som ger repeterbara resultat under kontrollerade förhållanden, men agenter resonerar dynamiskt igenom problem. Till exempel kan samma fråga som ställs två gånger ta olika körvägar, konsumera olika resurser och producera olika resultat. Denna icke-determinism skapar tillförlitlighetsutmaningar som traditionella test- och övervakningsmetoder inte hanterar.

Fellägen för agenters pålitlighet skiljer sig kategoriskt från fel i Salesforce-flöden eller Apex. Large Language Model (LLM)-slutledningstjänster representerar externa beroenden med tillgänglighetsegenskaper som är separata från Salesforce Platform. Agenter skapar svar som ibland bryter mot förväntad struktur trots uppmaningar. Agentsammanhangsförberedelse använder styrande gränser oförutsägbart. Obegränsad datahämtning påverkar agenter mer allvarligt eftersom agenter kan begära öppna sammanhang medan deterministiska sökfrågor har uttrycklig omfattningskontroll.

Tillförlitlig agentarkitektur kräver en reservkedja i flera nivåer som försämras graciöst—från sofistikerade agenter till enklare agenter med begränsat sammanhang, till deterministiska regelmotorer och slutligen till mänsklig överlämning via Omni-Channel. Plattformshändelser driver hållbara försöksköer med kontrollpunktsmönster, vilket låter misslyckade arbetsflöden återupptas från det senaste framgångsrika steget. Strömbrytare följer LLM-tjänstens hälsa i plattformscache för status i realtid, uppbackad av egna metadatatyper för trösklar och konfiguration, dirigering till grundmönster efter efterföljande fel. Övervakning kräver spårning av konversationsresultat, genomsnittlig tid mellan fel (MTBF), genomsnittlig tid till återhämtning (MTTR) och jordningsprecision. Agentforce Observability tillhandahåller sessionsspårningar, hälso- och latensmått och omflyttnings- och avledningshastigheter, men du måste fortfarande själv mäta pålitlighetsmått som MTBF, MTTR och jordningsprecision.

Detta dokument täcker vad som ändras när agenter är i bilden. För grundläggande pålitlighetsmönster som gäller för alla Salesforce-lösningar (design av servicenivåobjekt (SLO), feltolerans, skalning och övervakning), se pelaren Tillförlitlighet.

Agentforce agenter misslyckas på andra sätt än Salesforce-flöden eller Apex. Att förstå dessa fellägen är det som formar pålitlighetsarkitekturen.

LLM-tjänstens otillgänglighet: Slutpunkter för LLM-slutpunkter upplever tillfälliga latenstoppar eller tillgänglighetsproblem. Agentforce listas som en bevakad produkt på trust.salesforce.com tillsammans med Analytics och andra Salesforce-tjänster. Detaljerad LLM-slutledningslatens och prestandamått per begäran visas dock inte där. Implementera brytare genom att använda plattformscache för realtidsläge med låg latens, uppbackat av egna metadatatyper för trösklar och konfiguration, för att följa LLM-tjänstens hälsa. Plattformscache gör sitt bästa – poster kan vräkas innan deras time-to-live (TTL)—så behåll det öppna/utlösta läget i en hållbar butik, som ett Eget objekt, istället för cacheminnet ensamt. Justera resevillkoret till slutpunkten: antal fel i följd (till exempel fem) eller en felfrekvens som passerar en tröskel över ett rullande fönster. När kretsen utlöses, öppna den och dirigera till grundmönster, som enklare uppmaningar, cachade svar eller mänsklig överlämning, tills en framgångsrik testbegäran indikerar återställning.
Fel vid svarsvalidering: Agenter skapar ibland svar som bryter mot förväntad struktur trots uppmaningar. En agent returnerar ibland JSON med felaktiga format, utelämnar obligatoriska fält eller inkluderar oväntade datatyper. Plattformscache kan lagra validerade svarsscheman, vilket möjliggör snabb validering. Om valideringen misslyckas, försök igen med preciserade uppmaningar, inklusive valideringsfelet och ett exempel på korrekt struktur. Ange ett maximalt antal försök (3—5) för att förhindra oändliga försöksloopar.
Hallucinationsdetektering: Om jordningsdata är ofullständiga producerar agenter rimlig men felaktig information. Till skillnad från deterministiska sökfrågor som returnerar “hittades inte” fyller agenter luckor med slutsatser. Granskningsloggen för Einstein Trust Layer loggar alla uppmaningar, maskerade uppmaningar, svar, resultat av upptäckt av toxicitet och användarfeedback för granskning av styrning efter stängning. Den samlar dock inte in spår av resonemang steg för steg. För insamling av resonemang steg för steg, använd Agentforce Sessionsspårning, som registrerar utföranden av resonemangsmotorer. Kräv att agenter citerar hämtningskällor för Data 360 (tidigare Data Cloud). Korshänvisa agentkrav mot hämtade källor för att fånga upp faktiska avvikelser innan åtgärden utförs. En direktkontroll ger lite latens eftersom den körs mot källor som redan finns i sammanhanget. En kontroll som behöver en separat tur och retur, till exempel ett andra modellsamtal eller en extern tjänst, kostar mer. Reservera dessa kontroller för skrivningar med hög påverkan, inklusive ekonomiska uppdateringar eller orderuppdateringar, och kör dem asynkront under en konversation i realtid.
Ökningar av guvernörsgränser: Agentsammanhangsförberedelse använder Salesforce-objektsökfrågespråk (SOQL), CPU-tid och heapminne oförutsägbart baserat på konversationsflödet. Proactive Monitoring är en rättighetstjänst för signaturframgång (tidigare signatursupport) i Salesforce Success Plan, där Salesforce proaktivt övervakar kundkonton. Proactive Monitoring är inte en konfigurerbar varning för självbetjäning tillgänglig för alla kunder. För övervakning av styrande begränsningar med självbetjäning, använd Scale Center för att identifiera resursintensiva agentoperationer som närmar sig gränser. Implementera paginering i agentåtgärder som hämtar stora postsamlingar. För ofta besökta referensdata, använd Plattformscache.
Dataförvrängning i agentsammanhang: Agenter som hämtar sammanhang för konton med fler än 10 000 säljprojekt, eller kundcase med jämförelsevis stor aktivitetshistorik, stöter på samma utmaningar vad gäller dataförvrängningar som Batch Apex. Till skillnad från deterministiska sökfrågor där du styr omfattningen kan agentresonemang begära “all historik” oförutsägbart. För att förhindra detta, utforma agentåtgärder med förnuftiga hårda gränser (till exempel ett tak på 200 underordnade per överordnad) och implementera provtagningsstrategier när gränser överskrids. Taket begränsar hur mycket data som hamnar i agentens sammanhang. Para ihop den med selektiva indexerade filter så att själva sökfrågan förblir billig, eftersom ett ej indexerat filter eller aggregering på en skev överordnad söker igenom hela den underordnade uppsättningen innan locket tillämpas.

Utforma reservkedjor i flera nivåer så att agenter kan fortsätta fungera med minskad kapacitet istället för att misslyckas helt.

Primär agent med fullständigt sammanhang: Sofistikerad agent med fullständig Data 360-grundning, omfattande konversationshistorik och komplexa resonemang. Högsta kvalitet men mest resurskrävande och högsta felrisk.
Sekundär agent med begränsat sammanhang: Enklare agenter som använder kondenserat sammanhang (till exempel de senaste 30 dagarna jämfört med all historik, topp 5 vektorsökresultat jämfört med topp 20). Mindre sammanhang innebär färre tokens, snabbare härledning och lägre risk för misslyckande, men endast om det minskade sammanhanget fortfarande täcker de data uppgiften behöver.
Deterministisk regelmotor: Traditionellt Salesforce-flöde eller Apex som hanterar vanliga scenarion om agentresonemang misslyckas. Regler kan inte anpassas till nya situationer, men de hanterar kända mönster på ett tillförlitligt sätt. Agenten för ordervalidering återgår till standardvalideringsregler, medan agenten för leadbetyg återgår till regelbaserad betygsberäkning.
Human överlämning via Omni-Channel: Dirigera till mänsklig kö när automatiserade alternativ har uttömts. Konfigurera kompetensbaserad dirigering för att säkerställa att omflyttningar når rätt expertis. Godkänn fullständigt konversationssammanhang—inklusive försök till strategier, eventuella förtroendebetyg som du beräknar för agenten och orsaker till misslyckande—för att möjliggöra effektiv mänsklig inblandning.

Implementera grundlogik i orkestrering av Salesforce-flöden eller Apex utlösta av plattformshändelser. Varje nivå loggar vilken strategi som lyckats, vilket skapar synlighet i felmönster och reserveffektivitet.

Alla plattformshändelsemönster i denna sektion antar plattformshändelsetyper med hög volym, vilket ger lagringsfönstret på 72 timmar. Plattformshändelser med standardvolym behålls endast i 24 timmar. Använd händelsetyper med hög volym för alla agenters motståndskraft, köer för återförsök och kontrollpunktsmönster där reprisens varaktighet är ett krav på pålitlighet. Plattformshändelser ger hållbara meddelanden som låter agentflöden överleva fel och återställas automatiskt.

Förlopp för kontrollpunktsagent: Agentflöden med flera steg publicerar kontrollpunktshändelser efter varje framgångsrikt steg. Kontraktbearbetningsagent slutför dokumentextrahering, publicerar händelsen ContractParsed med extraherade data och fortsätter sedan till klausulanalys. Om klausulanalys misslyckas, spela upp händelsen ContractParsed igen för att återuppta från extraherade data utan att tolka igen. Detta fungerar när kontrollpunktens belastning bär dessa data och prenumeranten är idempotent, eftersom repris hämtar händelser istället för att återuppta ett arbetsflöde mitt i steget. Lagra kontrollpunktsstatus i händelsebelastning inklusive korrelations-ID, utförda steg och status som behövs för fortsättning.
Kö för försök igen med exponentiell backoff: Misslyckade agentbegäranden publiceras till händelsen AgentRetryRequested med antal försök igen i payload. Händelseprenumerantens processer försöker med exponentiella backoff-fördröjningar (till exempel 30 sekunder, 2 minuter, 8 minuter, 30 minuter). Efter maximalt antal försök (vanligtvis 5), dirigera till köer och varningar med döda bokstäver. Plattformshändelser med hög volym bevarar ett 72-timmars reprisfönster. Använd händelsetyp med hög volym för agenters återförsöksköer så att prenumeranter kan komma ikapp efter underhållsfönster eller nedtid för distribution. Plattformshändelser med standardvolym behålls endast i 24 timmar.
Händelsedriven orkestrering: Utforma agentflöden som löst kopplade händelsekedjor. Leadskapande publicerar LeadCreated. Leadbetygagent prenumererar, betygsätter och publicerar LeadScored. Leaddirigeringsagent prenumererar på LeadScored och tilldelar till lämplig kö. Varje agent kan misslyckas och försöka igen oberoende. Ett enskilt agentfel blockerar inte hela arbetsflödet—agenter längre ner bearbetar när beroenden återställs.
Spårning av korrelations-ID: Inkludera ett korrelations-ID som ett eget fält i alla relaterade händelsebelastningar. Reprisera händelser genom att använda Pub/Sub API by replayId, en ogenomskinlig, icke-kontinuerlig identifierare, för att rekonstruera arbetsflödeshistorik inom lagringsfönstret på 72 timmar. För att aktivera korrelations-ID-baserad felsökning, implementera ett prenumerantmönster som loggar inkommande händelser med sitt replayId och korrelations-ID till ett eget objekt, vilket aktiverar spårbarhet för korshändelser. Detta loggningsmönster är en egen implementering som du bygger själv, inte en inbyggd plattformsfrågekapacitet.

Flytta agentoperationer som överskrider synkrona gränser till ett asynkront sammanhang, vilket tillåter högre styrande gränser och längre timeout.

Batch-Apex för massagentoperationer: En agent som analyserar över 1 000 poster drar nytta av att Batch Apex tillhandahåller 200 SOQL-frågor, 150 DML-uttryck (upp till 10 000 DML-rader) och 60 000 millisekunder (60 sekunder) CPU-tid per körningsmetod. Leadbetygsagent som bearbetar import av leads varje natt. Analys av kundcasesentiment i historiska kundcase. Säljprojektprognoser som analyserar fullständiga pipelines.
Kökedjor för arbetsflöden i flera steg: Komplexa agentflöden som kräver flera externa API-anrop, analys av stora datauppsättningar eller förlängd bearbetningstid använder köbara Apex kedjor. Varje köjobb får 60 CPU-tid och 12 MB heap. Kedja till nästa Köbar för arbetsflöden som överskrider gränserna för ett enskilt jobb. Följ förloppet i Egna objekt så att ett misslyckat jobb kan återupptas från det senaste slutförda steget.
@future för enkla asynkrona överlämningar: Lättviktiga agentoperationer, som att skicka notiser, logga till externa system eller icke-brådskande uppdateringar, använder @future-metoder. Eld-och-glöm-mönstret passar när ett arbetsflöde inte behöver resultaten tillbaka och kan tolerera misslyckanden.

Bevaka asynkron bearbetningskapacitet via sidan Apex jobb (Inställningar → Apex jobb) och Apex flexkö. Högst 5 samtidiga batchjobb begränsar parallell agentbearbetning; ytterligare jobbkö i Apex Flex-kön, som håller upp till 100 jobb i status Väntande. Alla asynkrona Apex typer, Batch, Future, Queueable och Scheduled Apex, delar samma organisationsomfattande dagliga gräns (DailyAsyncApexExecutions) för asynkrona Apex-körningar: det större av 250 000 eller 200 gånger antalet användarlicenser. När du kör agentomröstningar med hög frekvens eller försöker prenumerantköer igen kan köer snabbt förbruka detta säljmål. För att undvika detta, batcha eller begränsa dessa köer för att hålla sig inom gränsen—som gäller över hela organisationen för alla asynkrona Apex typer, inte som en separat allokering för endast Köbar. Varna när förbrukningen närmar sig dessa gränser så att team kan hantera kapacitet proaktivt.

Validera agenters motståndskraft innan produktion genom att testa strategier som hanterar icke-deterministiskt beteende.

Belastningstest i Full Copy Sandbox: Testa agenters prestanda under inläsning i produktionsskala genom att använda fullständiga datavolymer. Simulera samtidiga konversationer som matchar toppefterfrågan. Mät p95- och p99-latens, identifiera prestandaförsämring under stress. Validera styrande begränsningar för användning som ligger under tröskelvärden vid hög belastning. Belastningstest i en Partial Copy-sandbox med reducerade data ger missvisande förtroende, eftersom datavolym direkt påverkar agenters prestanda. Innan du kör dessa tester, få godkännande från Salesforce (minst en vecka innan för begäranden om prestandatest). Ej godkända tester kan strypas eller blockeras.
Felinjektion: Introducera avsiktligt misslyckanden med att validera återställningsmekanismer. Simulera LLM-slutledningsfel i servicelagret som din brytare bevakar, för att verifiera att brytaren aktiverar.. Injicera SOQL-undantag för att testa felhantering. Korrupta agentsvar för att testa valideringslogik. Introducera dataförvrängning (konton med över 10 000 underordnade) för att testa sidnumreringslogik. Ange aggressiva timeouter för att testa strategier för timeouthantering och försök igen.
Kaosteknik: Inaktivera slumpmässigt prenumeranter på plattformshändelser för att testa reprisåterställning. Avsluta asynkrona jobb mitt i körningen för att testa omstart av kontrollpunkt. Introducera variabellatens till externa system för att testa progressiva timeoutstrategier. Kaosexperiment validerar motståndskraft i realistiska felkombinationer. Schemalägg regelbundna kaosdagar i fasningsmiljöer och upprätthåll motståndskraften när agenter utvecklas.
Långvariga stabilitetstester: Utför agenters arbetsbelastningar kontinuerligt i 72+ timmar och bevaka tidsberoende fel. Ackumulerade fel och gradvis försämrande prestanda visas endast under långvarig drift. Följ CPU-tidstrender för att identifiera gradvis försämring under körningen.

Definiera servicenivåindikatorer (SLI) som möjliggör mätning av objektiv pålitlighet. Upprätta SLO innan du bygger agenter, inte efter produktionsfel.

Resultat för konversation: Procentandel agentkonversationer slutförda utan fel eller timeout. Räkna en graciös överlämning till en människa som en framgång, inte ett misslyckande—omflyttning är den slutgiltiga grundnivån. Räkna misslyckade eller oavsiktliga omflyttningar mot måttet—det är en användbar tillförlitlighetssignal, men en ofullständig proxy för användarupplevelse, eftersom en artig inloggning kan maskera ett olöst problem. Följ separat efter agenttyp och användningsfall eftersom framgångskriterier för leadbetyg skiljer sig från kontraktgranskning. Varna om framgångsresultatet sjunker under SLO (vanligtvis 95—99%).
Genomsnittlig tid mellan fel (MTBF): Genomsnittlig operativ tid mellan agentfel. Högre MTBF indikerar färre fel och bättre pålitlighet. Beräkna som totala agenters arbetstider delat med antal fel. Följ per agenttyp för att identifiera minst pålitliga agenter som kräver optimeringsinvesteringar.
Genomsnittlig tid till återhämtning (MTTR): Genomsnittlig tid från upptäckt av fel till återställande av service. Automatiserad återställning via plattformshändelserepris och brytare återställer servicen mycket snabbare och med mindre manuella fel än praktiskt ingripande. Lägre MTTR minskar verksamhetspåverkan per incident.
Jordnoggrannhet: Procentandel av agentsvar som är korrekt baserat på validering av källdata. Exempel på slumpmässiga agentsvar för att validera anspråk mot Data 360-källor. Jordningsprecision under 95 % indikerar hallucinationsproblem som kräver snabb förfining eller bättre sammanhangshämtning.
Reprisluckor för plattformshändelse: Antal händelser som missats eller inte levererats, till exempel en prenumerant offline efter lagringsfönstret. Noll luckor är en positiv signal för en hälsosam händelsedriven arkitektur. Luckor indikerar prenumerantproblem, fel i händelsepublicering eller kapacitetsbegränsningar. Följ dessa luckor med loggningsmönstret på prenumerantsidan som beskrivs ovan och registrera varje händelses replayId och korrelations-ID till ett eget objekt.

Pålitliga agenter kommer från att designa för fel direkt—definiera SLI/SLO, sammanhangshantering som är medveten om styrande begränsningar och reservkedjor i flera nivåer innan de bygger, inte skruva på dem efteråt. Lagerbrytare och plattformshändelsebaserad återförsöks- och kontrollpunktslogik så att arbetsflöden återställs automatiskt, med mänsklig överlämning som sista utväg. Validera denna design genom systematisk belastning, felinjektion och kaostester och fortsätt sedan övervaka samma SLI i produktion för att bekräfta att den håller över tid.

Vägledningen om pålitlighet i den huvudsakliga pelaren Tillförlitlighet gäller för agenter med plattformsspecifika överväganden som tas upp här. Framgångsrika agentarkitekturer balanserar autonom kapacitet med lämplig tillsyn, vilket möjliggör självåterställning från tillfälliga fel medan omflyttning sker när förtroendet minskar eller kundcase uppstår.

Dela din feedback om det välarkitektoniska ramverket.