Agentiska pålitlighetsmönster
Få reda på mer om välarkitekturerad tillförlitlighet → Agentic Enterprise Reliability
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Plattformscache | ✅ Implementera brytare som följer LLM-tjänstens hälsostatus i plattformscache för realtidsläsningar med låg latens, uppbackade av egna metadatatyper för trösklar och konfiguration; eftersom plattformscache är bäst, behåll det öppna/utlösta läget i en hållbar butik (till exempel ett eget objekt) snarare än cacheminnet ensamt. Öppna kretsen på en justerad feltröskel (till exempel fem efterföljande slutledningsfel) och dirigera till reservmönster |
| Plattform | Plattformscache | ✅ Lagra validerade svarsscheman i plattformscache vilket möjliggör snabb validering av agentsvar mot förväntad struktur |
| Agentforce | Uppmaningsmall | ✅ Om svarsvalidering misslyckas, försök igen med förfinade uppmaningar inklusive valideringsfelet och ett exempel på korrekt struktur (maximalt 3-5 försök) |
| Agentforce | Sessionsspårning | ✅ Använd Agentforce sessionsspårning för att inspektera agentens resonemang och upptäcka hallucinationer i dess utdata |
| Data 360 | Vektorsökning | ✅ Kräv att agenter citerar Data 360-vektorsökkällor så att anspråk kan korsrefereras mot hämtade källor innan åtgärd utförs |
| Plattform | Proactive Monitoring | ✅ För konton med rättigheten Signaturframgång, förlita dig på Proactive Monitoring, där Salesforce-personal övervakar organisationen för nya problem; det är inte en konfigurerbar varning för självbetjäning |
| Plattform | Skalcenter | ✅ Använd Scale Center för att identifiera specifika agentoperationer som närmar sig styrande gränser |
| Agentforce | Åtgärd | ✅ Implementera paginering i agentåtgärder som hämtar stora postsamlingar |
| Agentforce | Åtgärd | ✅ Utforma agentåtgärder med hårda gränser (högst 200 underordnade per överordnad) och implementera provtagningsstrategier när gränser överskrids |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Egna metadatatyper | ⚠️ Tillåta obegränsade inferensförsök utan en brytare, vilket skapar oändliga försöksloopar när LLM-tjänsten försämras |
| Agentforce | Uppmaningsmall | ⚠️ Försöka igen misslyckade agentsvar utan att inkludera valideringsfelet och den förväntade strukturen i uppmaningen om att försöka igen |
| Agentforce | Åtgärd | ⚠️ Låt agenter begära obegränsade sammanhang (t.ex. “all historik”) utan hårda gränser för underordnade per överordnad post |
| Agentforce | Åtgärd | ⚠️ Utforma agentåtgärder som hämtar stora postsamlingar utan paginering, vilket orsakar ökningar av styrande gränser |
| Einstein | Trust | ⚠️ Förtroendefulla agentsvar utan att korsreferera anspråk mot jordade datakällor, vilket låter hallucinationer nå åtgärdsutförande |
| Plattform | Organisation | ⚠️ Behandla tillgänglighet för LLM-tjänster som identisk med Salesforce Platform-tillgänglighet istället för att bevaka den som ett separat beroende |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Agentforce | Agentkonfiguration | ✅ Utforma flera nivåer reservkedjor: agent med fullständigt sammanhang → agent med reducerat sammanhang → deterministisk regelmotor → mänsklig överlämning via Omni-Channel |
| Agentforce | Agentkonfiguration | ✅ Konfigurera en sekundär agent med kondenserad sammanhang (senaste 30 dagar vs all historia, topp 5 vektor sökresultat vs topp 20) för att minska sannolikheten för fel |
| Plattform | Flöde | ✅ Implementera grundlogik i orkestreringsflöde eller Apex utlöst av plattformshändelser, logga vilken nivå som lyckades för synlighet i felmönster |
| Plattform | Flöde | ✅ Bygg deterministiska flöden eller Apex logik som hanterar vanliga scenarion som reserv när agentresonemang misslyckas (t.ex. standardvalideringsregler, regelbaserad betygsberäkning) |
| Agentforce | Omni-Channel | ✅ Konfigurera kompetensbaserad dirigering för mänsklig överlämning säkerställer omflyttningar når lämplig expertis |
| Agentforce | Omni-Channel | ✅ Skicka fullständig konversation sammanhang till mänsklig kö inklusive försök till strategier, agent förtroende betyg och misslyckande orsaker |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Agentforce | Agentkonfiguration | ⚠️ Utforma agenter med en enskild utförandeväg som misslyckas helt när någon komponent försämras |
| Agentforce | Agentkonfiguration | ⚠️ Använda samma agentkonfiguration med fullständigt sammanhang för reservförsök istället för att gradvis förenkla sammanhanget |
| Agentforce | Omni-Channel | ⚠️ Dirigera till mänsklig överlämning utan att passera konversationssammanhang, försök till strategier eller felorsaker, vilket tvingar agenten att börja från grunden |
| Plattform | Flöde | ⚠️ Inte logga vilken reservnivå som lyckades, förlora synlighet i felmönster och reserveffektivitet |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Plattformshändelser | ✅ Publicera kontrollpunktshändelser efter varje framgångsrikt steg i agentflöden i flera steg, lagra korrelations-ID, utförda steg och status som behövs för fortsättning i händelsebelastningen |
| Plattform | Plattformshändelser | ✅ Utforma agentflöden som löst kopplade händelsekedjor där varje agent kan misslyckas och försöka igen oberoende utan att blockera hela arbetsflödet |
| Plattform | Plattformshändelser | ✅ Implementera återförsöksköer med exponentiella backoff-fördröjningar (30s, 2min, 8min, 30min) med hjälp av plattformshändelser med återförsöksräkning i payload |
| Plattform | Plattformshändelser | ✅ Dirigera till död bokstav kö och varning operationer efter maximalt antal försök (vanligtvis 5) är uttömda |
| Plattform | Plattformshändelser | ✅ Inkludera korrelations-ID i alla relaterade händelser; använd Platform Event Replay API för att rekonstruera fullständig arbetsflödeshistorik för felsökning |
| Plattform | Plattformshändelser | ✅ Utnyttja 72-timmars reprislagringsfönstret som är tillgängligt för plattformshändelser med hög volym (händelser med standardvolym behålls i 24 timmar) för att bevara köer för återförsök genom underhållsfönster eller distributionsnedtid |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Plattformshändelser | ⚠️ Bygga agentflöden i flera steg utan kontrollpunkter, som kräver fullständig omkörning om något mellansteg misslyckas |
| Plattform | Plattformshändelser | ⚠️ Försöker igen misslyckade agentförfrågningar utan exponentiell backoff, vilket skapar dundrande flockeffekter på att återställa tjänster |
| Plattform | Plattformshändelser | ⚠️ Utforma tätt kopplade sekventiella arbetsflöden där ett enskilt agentfel blockerar all bearbetning längre ner |
| Plattform | Plattformshändelser | ⚠️ Utelämna korrelations-ID:n från händelser, vilket gör det omöjligt att spåra och felsöka slutföra arbetsflödeskörning |
| Plattform | Plattformshändelser | ⚠️ Försöker igen på obestämd tid utan ett maximalt antal försök igen eller död bokstavskö, vilket konsumerar plattformsresurser på permanent misslyckade operationer |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Apex | ✅ Använd Batch Apex för agentoperationer som analyserar 1 000 + poster, använder asynkrona styrande gränser (200 SOQL-frågor, 150 DML-operationer, 60s CPU per utförande) |
| Plattform | Apex | ✅ Använd köbara Apex kedjor för agentflöden i flera steg som kräver flera externa API-anrop eller utökad bearbetningstid; följ förloppet i egna objekt för att aktivera återuppta vid fel |
| Plattform | Apex | ✅ Använd @framtida metoder för lätta brand-och-glöm agentoperationer (notiser, extern loggning, icke-brådskande uppdateringar) där fel kan tolereras |
| Plattform | Apex Jobb | ✅ Övervaka asynkron bearbetningskapacitet via sidan Apex jobb (Inställningar → Apex jobb) och Apex Flex-kön: högst 5 samtidiga batchjobb (ytterligare jobb i kön Flex, upp till 100 i status Väntar) och den organisationsomfattande dagliga gränsen för asynkrona Apex-körningar (DailyAsyncApexExecutions) – det största av 250 000 eller 200 × antalet användarlicenser per 24 timmar – som delas mellan batch, köbar, framtida och schemalagd Apex |
| Plattform | Organisation | ✅ Varna när asynkron användning närmar sig gränser vilket möjliggör proaktiv kapacitetshantering innan agentbearbetning blockeras |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Apex | ⚠️ Bearbetar över 1 000 poster i synkrona agenttransaktioner istället för att flytta till Apex i sats och uppnår gränsen på 100 SOQL-frågor efter endast några få poster |
| Plattform | Apex | ⚠️ Använda köbara kedjor utan att följa förloppet i egna objekt, vilket förhindrar kapacitet att återuppta vid fel |
| Plattform | Organisation | ⚠️ Att inte bevaka gränsen på 5 samtidiga batchjobb eller den delade dagliga asynkrona Apex-körningsgränsen (DailyAsyncApexExecutions — den största av 250 000 eller 200 × användarlicenser per 24 timmar, över batch, köbar, framtida och schemalagd Apex), vilket gör att agentbearbetning tyst placeras i kö eller misslyckas |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Organisation | ✅ Ladda testagentprestanda i Full Copy Sandbox med datavolymer i produktionsskala; simulera samtidiga konversationer som matchar toppefterfrågan |
| Plattform | Organisation | ✅ Mät p95 och p99 latens under belastning som identifierar prestandaförsämring under stress; validera styrande gräns för förbrukning som ligger under tröskelvärden vid toppbelastning |
| Agentforce | Agentkonfiguration | ✅ Utför felinjektion: simulera LLM-slutledningsfel i servicelagret som din brytare bevakar, injicera SOQL-undantag som testar felhantering, korrupta svar som testar valideringslogik |
| Agentforce | Agentkonfiguration | ✅ Introducera dataförvrängning (konton med 10 000 + underordnade) under tester för att validera pagineringslogik hanterar värsta-scenarion |
| Plattform | Plattformshändelser | ✅ Utför kaos teknik: slumpmässigt inaktivera plattformshändelseprenumeranter som testar reprisåterställning, avsluta asynkrona jobb mitt i körningen testar omstart av kontrollpunkt |
| Plattform | Organisation | ✅ Schemalägg regelbundna kaosdagar i fasningsmiljöer som upprätthåller motståndskraften när agenter utvecklas |
| Plattform | Organisation | ✅ Kör långvariga stabilitetstester (72 + timmar) övervakning för tidsberoende fel: ackumulera fel och gradvis försämra prestandan |
| Plattform | Organisation | ✅ Följ CPU tidstrender och heap konsumtion över långa perioder upptäcka gradvis försämring i sammanhangshantering |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Organisation | ⚠️ Belastningstest i Partial Copy Sandbox med minskade datavolymer, vilket ger missvisande förtroende eftersom datavolym direkt påverkar agenters prestanda |
| Agentforce | Agentkonfiguration | ⚠️ Testa endast lyckliga vägar utan att avsiktligt introducera fel för att validera brytare, försöka logik igen och timeouthantering |
| Plattform | Organisation | ⚠️ Kör endast kortvariga tester, saknar tidsberoende fel (ackumulerande fel, gradvis försämring) som endast visas under långvarig 72+ timmars drift |
| Plattform | Plattformshändelser | ⚠️ Testa aldrig reprisåterställning för plattformshändelser eller omstart av kontrollpunkter, vilket lämnar motståndskraftsmekanismer ovaliderade |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Företag | Dokumentation | ✅ Etablera SLOs innan du bygger agenter, inte efter produktionsfel; definiera mål för konversationsresultat (vanligtvis 95-99%) per agenttyp |
| Plattform | Organisation | ✅ Följ konversationsresultat som primär agent tillförlitlighetsmått: procentandel konversationer som slutförs utan fel eller timeout. Räkna en graciös överlämning till en människa som en framgång, eftersom omflyttning är den utformade slutgiltiga grundnivån; räkna endast misslyckade eller oavsiktliga omflyttningar mot måttet |
| Plattform | Organisation | ✅ Följ framgångsresultat separat efter agenttyp och användningsfall eftersom framgångskriterier skiljer sig åt mellan agentsyften |
| Plattform | Organisation | ✅ Beräkna genomsnittlig tid mellan misslyckanden (MTBF) per agenttyp för att identifiera minst pålitliga agenter som kräver optimering investering |
| Plattform | Organisation | ✅ Mät genomsnittlig tid till återhämtning (MTTR); automatisera återställning via plattformshändelserepris och brytare för mycket snabbare, mindre felbenägen återställning än manuellt ingripande |
| Einstein | Trust | ✅ Exempel på slumpmässiga agentsvar som validerar anspråk mot Data 360-källor för att mäta jordningsprecision; undersök när precisionen sjunker under 95% |
| Plattform | Plattformshändelser | ✅ Övervaka plattformshändelse reprisluckor (händelser missade eller olevererade) via ett loggningsmönster på prenumerantsidan som registrerar varje händelses replayId och korrelations-ID till ett eget objekt |
| Plattform | Organisation | ✅ Varna operationer när någon SLI faller under sin definierade SLO-tröskel |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Företag | Dokumentation | ⚠️ Bygga agenter utan att definiera SLO först, endast fastställa tillförlitlighetsmål efter produktionsfel |
| Plattform | Organisation | ⚠️ Använda ett enskilt aggregerat resultat för alla agenttyper istället för att spåra separat efter agenttyp och användningsfall |
| Plattform | Organisation | ⚠️ Förlita sig endast på traditionell Salesforce-övervakning (trust.salesforce.com) utan att spåra agentspecifika SLI:er som konversationsresultat, MTBF, MTTR och jordningsprecision |
| Plattform | Organisation | ⚠️ Kräver manuella ingripanden för alla agentfel istället för att automatisera återställning med plattformshändelserepris och brytare |
| Einstein | Trust | ⚠️ Provta aldrig agentsvar för validering av jordningsnoggrannhet, vilket gör att hallucinationer kan förbli oupptäckta i produktion |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Agentforce | Agentkonfiguration | ✅ Utforma försöksmönster, grundkedjor och omflyttningströsklar till agentflöden från inledande design, inte som eftertankar |
| Agentforce | Åtgärd | ✅ Bulkify sammanhangsförberedelse och paginera stora postsamlingar i agentåtgärder |
| Plattform | Plattformscache | ✅ Cacha ofta använda referensdata i plattformscache vilket minskar överflödiga sökfrågor under förberedelse av agentsammanhang |
| Plattform | Skalcenter | ✅ Använd Skalcenter för att identifiera resursintensiva agentoperationer som kräver optimering |
| Plattform | Plattformshändelser | ✅ Utforma självåterställande arbetsflöden med hjälp av plattformshändelser som hållbara försöksköer med brytare som skyddar externa beroenden |
| Agentforce | Agentkonfiguration | ✅ Inkludera alltid mänsklig överlämning som slutlig reserv i varje agents nedbrytningskedja |
| Plattform | Organisation | ✅ Övervaka agent SLIs kontinuerligt varnar när mått faller under SLOs |
| Agentforce | Agentkonfiguration | ✅ Balansera autonom kapacitet med lämplig tillsyn: aktivera självåterställning från tillfälliga fel vid omflyttning när förtroendet minskar eller kundcase uppstår |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Agentforce | Agentkonfiguration | ⚠️ Lägga till tillförlitlighetsmekanismer (återförsök, reserv, omflyttning) som eftertankar istället för att utforma dem från början |
| Agentforce | Åtgärd | ⚠️ Inte bunta sammanhangsförberedelser, vilket orsakar styrande begränsningsfel under verkliga sökfrågemönster |
| Plattform | Organisation | ⚠️ Inte övervaka API-användning och allokering av plattformshändelse proaktivt, upptäcka gränser endast när agenter misslyckas |
| Agentforce | Agentkonfiguration | ⚠️ Utforma agentkedjor utan en mänsklig överlämning som slutgiltig reserv, lämnar ingen återställningsväg när alla automatiserade alternativ är uttömda. |
| Agentforce | Agentkonfiguration | ⚠️ Ge agenter fullständig autonom drift utan omflyttningströsklar för situationer med lågt förtroende eller kundcase med låg marginal |