Patroner for agentpålitelighet
Lær mer om velbygd pålitelighet → Agentisk bedriftspålitelighet
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform-buffer | Plattformbuffer | ✅ Implementer kretsbrytere som sporer tilstanden til LLM-tjenesten i plattformbuffer for lav latens av sanntidsleser, støttet av tilpassede metadatatyper for terskler og konfigurasjon. Fordi plattformbuffer er best-effekt, beholdes den åpne/avbrutte tilstanden i en varig butikk (som et tilpasset objekt) i stedet for bufferen alene. Åpne kretsen på en avstemt feil terskel (for eksempel fem etterfølgende utledingsfeil) og rute til reservemønstre |
| Plattform-buffer | Plattformbuffer | ✅ Lagre validerte svarskjemaer i plattformbuffer som aktiverer rask validering av agentsvar mot forventet struktur |
| Agentforce | Ledetekstmal | ✅ Når svarvalidering mislykkes, prøver du på nytt med begrensede ledetekster, inkludert valideringsfeilen og et eksempel på riktig struktur (maksimalt 3-5 gjentakelser) |
| Agentforce | Øktsporing | ✅ Bruk Agentforce Session Tracking-sporingsporet til å inspisere agentens resonansbane og oppdage hallusinasjoner i utdataene |
| Data 360 | Vektorsøk | ✅ Krev at agenter siterer Data 360-vektorsøkekilder slik at krav kan kryssrefereres mot hentede kilder før handlingen utføres |
| Plattform | Proactive Monitoring | ✅ For kontoer som er berettiget til Signature Success, kan du bruke Proactive Monitoring, der Salesforce-ansatte overvåker organisasjonen for nye problemer. Det er ikke et varsel som kan konfigureres for selvbetjening |
| Plattform | Skaleringssenter | ✅ Bruk Skaleringssenter til å identifisere spesifikke agentoperasjoner som nærmer seg styringsgrenser |
| Agentforce | Handling | ✅ Implementer sideinndeling i agenthandlinger som henter store postsamlinger |
| Agentforce | Handling | ✅ Utform agenthandlinger med faste grenser (maksimalt 200 barn per overordnet), og implementer utvalgsstrategier når grenser overskrides |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Tilpassede metadatatyper | ⚡️ Tillat ubegrenset antall avledningsforsøk uten en kryssbryter, og opprette uendelige forsøksløyfer når LLM-tjenesten er redusert |
| Agentforce | Ledetekstmal | ⚡️ Prøve mislykkede agentsvar på nytt uten å inkludere valideringsfeilen og den forventede strukturen i meldingen om å prøve på nytt |
| Agentforce | Handling | ⚡️ Tillat at agenter ber om kontekst uten grenser (for eksempel “all historikk”) uten faste grenser for underordnede per overordnet post |
| Agentforce | Handling | ⚡️ Utforme agenthandlinger som henter store postsamlinger uten sideinndeling, noe som fører til økende styringsgrenser |
| Einstein | Trust | ⚡️ Klargjøre agentsvar uten kryssreferanse på krav mot datakilder for å gi hallusinasjoner mulighet til å utføre handlinger |
| Plattform | Organisasjon | ⚡️ Behandle tilgjengelighet av LLM-tjenester som identisk med tilgjengelighet av Salesforce-plattformen i stedet for å overvåke den som en separat avhengighet |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Agentforce | Agent-konfigurasjon | ✅ Utforme flere nivåer av reservekjeder: fullkontekstagent → redusertkontekstagent → deterministisk regelmotor → menneskelig overføring via Omnikanal |
| Agentforce | Agent-konfigurasjon | ✅ Konfigurer en sekundær agent ved å bruke kondensert kontekst (de siste 30 dagene kontra all historikk, topp 5 vektorsøkeresultater kontra topp 20) for å redusere sannsynligheten for feil |
| Plattform | Flyt | ✅ Implementer reservelogikk i orkestreringsflyt eller Apex utløst av plattformhendelser, logging av hvilket nivå som var vellykket for synlighet i feilmønstre |
| Plattform | Flyt | ✅ Bygg deterministisk flyt eller Apex som håndterer vanlige scenarier som reservesignal når agentenes resonnement mislykkes (for eksempel standard valideringsregler, regelbasert scoreberegning) |
| Agentforce | Omnikanal | ✅ Konfigurer kvalifikasjonsbasert ruting for menneskelig overføring for å sikre at eskaleringer når riktig ekspertise |
| Agentforce | Omnikanal | ✅ Overfør full samtalekontekst til køen inkludert forsøkte strategier, agentkonfidenscore og årsaker til feil |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Agentforce | Agent-konfigurasjon | ⚡️ Utforme agenter med en enkelt utførelsesbane som mislykkes fullstendig når en komponent degraderes |
| Agentforce | Agent-konfigurasjon | ⚡️ Bruke den samme fullkontekstagentkonfigurasjonen til reservasjonsforsøk i stedet for å forenkle kontekst gradvis |
| Agentforce | Omnikanal | ⚡️ Ruting til menneskelig overføring uten å overføre samtalekontekst, forsøkte strategier eller årsaker til feil, som tvinger agenten til å starte fra grunnen av |
| Plattform | Flyt | ⚡️ Ikke logge hvilket reservesjikt som var vellykket, tap av synlighet i feilmønstre og reservesjefektivitet |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Plattformhendelser | ✅ Publiser sjekkpunkthendelser etter hvert vellykkede trinn i flertrinns agentarbeidsflyter, lagrer korrelasjons-ID, fullførte trinn og nødvendig status for fortsettelse i hendelsesbelastningen |
| Plattform | Plattformhendelser | ✅ Utform agentarbeidsflyter som løst koblede hendelseskjeder der hver agent kan mislykkes og prøve på nytt uavhengig uten å blokkere hele arbeidsflyten |
| Plattform | Plattformhendelser | ✅ Implementer køer for ny forsøk med eksponentielle forsinkelser med tilbakekall (30s, 2min, 8min, 30min) ved bruk av plattformhendelser med antall nye forsøk i last |
| Plattform | Plattformhendelser | ✅ Rut til kø med død brev og varsleoperasjoner etter at maksimalt antall nye forsøk (vanligvis 5) er uttømt |
| Plattform | Plattformhendelser | ✅ Inkluder korrelasjons-ID i alle relaterte hendelser. Bruk API for gjentakelse av plattformhendelser til å rekonstruere full arbeidsflythistorikk for feilsøking |
| Plattform | Plattformhendelser | ✅ Dra nytte av det 72-timers gjentagelsesbevarelsesvinduet som er tilgjengelig for plattformhendelser med stor trafikk (hendelser med standardvolum beholdes i 24 timer) for å beholde køer for ny forsøk via organisasjonsvedlikeholdsvinduer eller nedetid for distribusjon |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Plattformhendelser | ⚡️ Bygge arbeidsflyter med flere trinn for agenter uten sjekk, som krever full gjenutføring når et mellomliggende trinn mislykkes |
| Plattform | Plattformhendelser | ⚡️ Prøve mislykkede agentforespørsler på nytt uten eksponentiell tilbakekalling, og opprette virkningene på gjenopprettingstjenester som skremmer flokken |
| Plattform | Plattformhendelser | ⚡️ Utforme tett koblede sekvensielle arbeidsflyter der en enkelt agentfeil blokkerer all nedstrøms behandling |
| Plattform | Plattformhendelser | ⚡️ Utelate korrelasjons-ID-er fra hendelser slik at det blir umulig å spore og feilsøke fullstendig utførelse av arbeidsflyt |
| Plattform | Plattformhendelser | ⚡️ Prøve på nytt på ubestemt tid uten et maksimalt antall forsøk på nytt eller død bokstavkø, forbruker plattformressurser på permanent mislykkede operasjoner |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Apex | ✅ Bruke Apex for agentoperasjoner som analyserer 1000+ poster, utnytter asynkrone styringsgrenser (200 SOQL-spørringer, 150 DML-operasjoner, 60s CPU per utførelse) |
| Plattform | Apex | ✅ Bruke købare Apex til arbeidsflyter for agenter med flere trinn som krever flere eksterne API-kall eller utvidet behandlingstid. Spor fremdrift i tilpassede objekter som aktiverer gjenopptagelse ved feil |
| Plattform | Apex | ✅ Bruk @future-metoder til enkle og glemte agentoperasjoner (varsler, ekstern logging, ikke-hurtigoppdateringer) der feil kan tolereres |
| Plattform | Apex | ✅ Overvåk kapasitet for asynkron behandling via siden Apex (Oppsett → Apex) og Apex: maksimalt 5 samtidige gruppejobber (tilleggsjobberkø i Flex-køen, opptil 100 i Holding-status), og den organisasjonsomfattende daglige grensen for asynkrone Apex-utførelser (DailyAsyncApexExecutions) – den største av 250 000 eller 200 x antall brukerlisenser per 24 timer – delt på tvers av batch, købar, fremtidig og planlagt Apex |
| Plattform | Organisasjon | ✅ Varsel når asynkront forbruk nærmer seg grenser som aktiverer proaktiv kapasitetsbehandling før agentbehandling blokkeres |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Apex | ⚡️ Behandle 1000+ poster i synkrone agenttransaksjoner i stedet for å flytte til batch Apex, og nå grensen på 100 SOQL-spørringer etter bare noen få poster |
| Plattform | Apex | ⚡️ Bruke købare kjeder uten å spore fremdrift i tilpassede objekter for å hindre gjenopptagelse ved feil |
| Plattform | Organisasjon | ⚡️ Ikke overvåking av grensen for 5 samtidige gruppejobber eller den delte daglige asynkrone Apex-utførelsesgrensen (DailyAsyncApexExecutions – større enn 250 000 eller 200 x brukerlisenser per 24 timer på tvers av gruppe, købar, fremtidig og planlagt Apex), noe som fører til at agentbehandling stille legger i kø eller mislykkes |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Organisasjon | ✅ Last inn testagentytelsen i Full Copy-Sandbox med datavolumer i produksjonsskala, simulere samtidige samtaler som samsvarer med høy etterspørsel |
| Plattform | Organisasjon | ✅ Måle p95- og p99-latens under belastning som identifiserer ytelsesforringelse under belastning, valider styringsgrenseforbruket forblir under terskler ved høy belastning |
| Agentforce | Agent-konfigurasjon | ✅ Utfør feilinnsetting: simulere LLM-utledningsfeil i tjenestelaget som kryssbryteren overvåker, injisere SOQL-unntak for feilhåndtering ved testing, korrupte svar for testing av valideringslogikk |
| Agentforce | Agent-konfigurasjon | ✅ Introdusere dataskift (kontoer med 10 000+ underordnede) under testing for å validere sideinndelingslogikk som håndterer verste scenarier |
| Plattform | Plattformhendelser | ✅ Utfør kaoseteknikk: tilfeldig deaktivere plattformhendelsesabonnenter for testing av gjentakelsesgjenoppretting, avslutte asynkrone jobber ved test av sjekkpunkt på nytt midt i utførelsen |
| Plattform | Organisasjon | ✅ Planlegg regelmessige kaosdager i oppstillingsmiljøer som opprettholder motstandskraften etter hvert som agenter utvikler seg |
| Plattform | Organisasjon | ✅ Utfør langvarig overvåking av stabilitetstester (72+ timer) for tidsavhengige feil: akkumulere feil og gradvis redusere ytelsen |
| Plattform | Organisasjon | ✅ Spor CPU-tidstrender og heap-forbruk over utvidede perioder for å oppdage gradvis nedgang i kontekstbehandling |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Organisasjon | ⚡️ Last inn testing i Delvis kopi-Sandbox med reduserte datavolumer, noe som gir villedende tillit fordi datavolum påvirker agentytelsen direkte |
| Agentforce | Agent-konfigurasjon | ⚡️ Teste bare tilfredse baner uten å med vilje introdusere feil for å validere kretsbrytere, prøve på nytt logikk og håndtere tidsavbrudd |
| Plattform | Organisasjon | ⚡️ Kjører bare kortvarige tester, mangler tidsavhengige feil (akkumulerende feil, gradvis forringelse) som vises bare under vedvarende drift på 72 timer eller mer |
| Plattform | Plattformhendelser | ⚡️ Test aldri gjenoppretting av plattformhendelse eller gjenstart av sjekkpunkt, slik at motstandsmekanismer ikke valideres |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Virksomhet | Dokumentasjon | ✅ Opprett enkeltavloggingsavtaler før byggeagenter, ikke etter produksjonsfeil. Definer mål for samtaleytelse (vanligvis 95-99 %) per agenttype |
| Plattform | Organisasjon | ✅ Spor suksessfrekvens for samtalen som primær måling av agentpålitelighet: Prosentandelen av samtaler som er fullført uten feil eller tidsavbrudd. Teller en god overlevering til et menneske som en suksess, fordi eskalering er det utformede siste reservesjiktet. Teller bare mislykkede eller utilsiktede eskaleringer mot målingen |
| Plattform | Organisasjon | ✅ Spor suksessraten separat etter agenttype og bruksområde fordi suksesskriterier varierer mellom agentformål |
| Plattform | Organisasjon | ✅ Beregne middeltid mellom feil (MTBF) per agenttype for å identifisere minst pålitelige agenter som krever optimaliseringsinvesteringer |
| Plattform | Organisasjon | ✅ Måling av middeltid til gjenoppretting (MTTR); automatiser gjenoppretting via gjentakelse av plattformhendelse og kretsbrytere for mye raskere og mindre feilsøkende gjenoppretting enn manuell intervensjon |
| Einstein | Trust | ✅ Eksempel på tilfeldige agentsvar som validerer krav mot Data 360-kilder for å måle nøyaktigheten av jording, undersøke når nøyaktigheten faller under 95 % |
| Plattform | Plattformhendelser | ✅ Overvåk gjentakelsesgap for plattformhendelser (hendelser som er manglet eller ikke er levert) via et loggingsmønster på abonnentsiden som registrerer hver hendelses replayId og korrelasjons-ID til et tilpasset objekt |
| Plattform | Organisasjon | ✅ Varsle operasjoner når en SLI faller under sin definerte SLO- terskel |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Virksomhet | Dokumentasjon | ⚡️ Bygge agenter uten å definere enkel avlogging først, bare etablere pålitelighetsmål etter at produksjonsfeil oppstår |
| Plattform | Organisasjon | ⚡️ Bruke en enkelt samlet suksessrate på tvers av alle agenttyper i stedet for å spore separat etter agenttype og bruksområde |
| Plattform | Organisasjon | ⚡️ Stole utelukkende på tradisjonell Salesforce-overvåking (trust.salesforce.com) uten å spore agentspesifikke SLI-er som samtalers suksessrate, MTBF, MTTR og nøyaktighet ved tilpassing |
| Plattform | Organisasjon | ⚡️ Krever manuell intervensjon for alle agentfeil i stedet for å automatisere gjenoppretting med plattformhendelsesgjenopptak og strømbrytere |
| Einstein | Trust | ⚡️ Aldri prøvetak agentsvar for validering av nøyaktighet for tilgrening, slik at hallusinasjoner ikke blir oppdaget i produksjonsorganisasjonen |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Agentforce | Agent-konfigurasjon | ✅ Utform prøvingsmønstre, reservekjeder og eskaleringsterskeler i agentarbeidsflyter fra den første utformingen, ikke som ettertanker |
| Agentforce | Handling | ✅ Masseutfør kontekstforberedelse og paginer store registreringssamlinger i agenthandlinger |
| Plattform-buffer | Plattformbuffer | ✅ Bufrer referansedata med hyppig tilgang i plattformbuffer som reduserer overflødige spørringer under klargjøring av agentkontekst |
| Plattform | Skaleringssenter | ✅ Bruk Skaleringssenter til å identifisere ressursintensive agentoperasjoner som krever optimalisering |
| Plattform | Plattformhendelser | ✅ Utform selvgjenopprettingsarbeidsflyter ved å bruke plattformhendelser som holdbare gjenprøvekøer med kretsbrytere som beskytter eksterne avhengigheter |
| Agentforce | Agent-konfigurasjon | ✅ Inkluder alltid menneskelig overføring som endelige reservasjoner i hver agents nedbrytingskjede |
| Plattform | Organisasjon | ✅ Overvåk agent-SLI-er som varsles kontinuerlig når målinger faller under SLO-er |
| Agentforce | Agent-konfigurasjon | ✅ Balansere autonom funksjonalitet med riktig overvåking: aktivere selvgjenoppretting fra midlertidige feil ved eskalering når konfidensfall eller kantsaker dukker opp |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Agentforce | Agent-konfigurasjon | ⚡️ Legge til pålitelighetsmekanismer (prøve på nytt, tilbakestilling, eskalering) som ettertanke i stedet for å utforme dem fra start av |
| Agentforce | Handling | ⚡️ Ikke masseutføre kontekstforberedelse, hvilket fører til feil i styringsgrensen i virkelige spørringsmønstre |
| Plattform | Organisasjon | ⚡️ Ikke overvåke API-forbruk og tildeling av plattformhendelser proaktivt, oppdage grenser bare når agenter mislykkes |
| Agentforce | Agent-konfigurasjon | ⚡️ Utforme agentkjeder uten en personlig overføring som endelige reservasjoner, og la ingen gjenopprettingsbane være igjen når alle automatiserte alternativer er uttømt |
| Agentforce | Agent-konfigurasjon | ⚡️ Gi agenter fullstendig autonom operasjon uten eskaleringsterskeler for situasjoner med lite konfidens eller kanttilfeller |