Ressurs- og kostnadsoptimalisering for Agentic Enterprise
Autonome agenter bruker Salesforce-ressurser annerledes enn deterministisk automatisering. Agentarbeidsbelastninger er uforutsigbare og kontinuerlige i stedet for faste og transaksjonsbundne. Verdi-for-kostnad-oppgaven i pilaren Resource and Cost Optimization (Ressurs- og kostnadsoptimalisering) går direkte til Agent Enterprise. Ressurseffektivitet betyr å bruke kapasiteten du allerede betaler for, og kostnadsoptimalisering betyr å omdirigere bruken med vilje mot de autonome funksjonene som gir en avkastning. Agenter endrer formen på begge. Effektiv agentutforming sørger for at forbruket kontrolleres, og valg av prismodell, modellering av total eierkostnad (TCO) og økonomisk styring sørger for at forbruket er i samsvar med verdien. Dette dokumentet behandler ressurseffektivitet og kostnadsoptimalisering som én beslutning fordi det for agenter er to visninger av det samme målet.
Agenter endrer forutsigbarheten av forbruk. En tradisjonell Apex opererer på et kjent postsett med en kjent ressurskostnad. En agent opererer samtalebasert, og en enkelt samtale kan utføre dusinvis av handlinger som agentens årsaker gjennom en oppgave. Hver handling bruker styringsgrenser i sin egen transaksjon i stedet for å akkumulere dem på tvers av samtalen. Kontekstforberedelse for en omgang kan spørre 200 registreringer eller 20 000 afhængigt af, hvad brugeren spør. API-forbruket øker fordi agenter kan handle autonomt, og proaktive, utgående og planlagte agenter handler kontinuerlig i stedet for bare under en brukertransaksjon. Denne uforutsigbarheten er årsaken til at agentressursbehandling må være defensiv etter utforming i stedet for justert etter at det oppstår en forbruksspike.
Kostnadssiden endres like mye. Autonome agenter introduserer forbruksbasert pris som fungerer annerledes enn tradisjonell lisens per sete. Agentforce tilbyr to forbruksbaserte prismodeller, Flex Credits og Per-Conversation. Hver agentdistribusjon velger en av disse modellene. En organisasjon bruker én forbruksmodell om gangen. , men et tillegg Per bruker, som tilbys per bruker per måned for ikke-målt bruk, kan lages ved siden av en forbruksmodell slik at kunderettede agenter kjører på Flex Credits eller Per-Conversation mens ansatte bruker ikke-målte lisenser. Data 360 leverer agentplassering via vektorsøk og -henting og bruker databehandlingskapasitet, mens MuleSoft aktiverer agentintegrasjoner som bruker API-kapasitet. Disse variabelkostnadene skaleres med agentbruk, noe som oppretter et investeringsmønster som krever økonomisk styring som er bygd for variabilitet i stedet for et fast årlig abonnement.
Løsninger som er utformet for forretningsverdi med optimalisert kostnad i Agentic Enterprise, sørger for effektiv agentforbruk gjennom handlinger som behandler poster samlet, disiplinerte kontekstvinduer og bufring. De omdirigerer også med vilje forbruk gjennom den riktige prismodellen, fullstendig TCO-modellering og kontinuerlig kostnadsovervåking mot forretningsutfall. Uten denne justeringen akkumulerer agentdistribusjoner kostnader uten å demonstrere proporsjonal verdi, og en agent som har årsaker i en ubegrenset sløyfe, kan brenne kreditter raskere enn menneskelig oversikt kan gripe inn. Det samme effektivitetsarbeidet som holder en agent innenfor styringsgrensene, holder den innenfor kredittbudsjettet, som er pilaroppgaven som uttrykkes i agentiske termer.
Dette dokumentet dekker hvilke endringer som skjer når agenter vises på bildet. Hvis du vil se de grunnleggende ressurs- og kostnadsoptimaliseringsmønstrene som gjelder for hver Salesforce-løsning, inkludert ytelsesoptimalisering, styringsgrenser, TCO-analyse og lisensieringsdisiplin, kan du se søylen Ressurs- og kostnadsoptimalisering. Agentstyring og menneskelig tilsyn er knyttet til pilarene Trust and Fairness, som dekker programmekomponentene som sørger for at selvstendig oppførsel holdes trygg og ansvarlig.
Agent ressursforbruk følger samme plattformmekanikk som Flyt eller Apex, men dens uforutsigbare, samtaledrevne kall gjør forbruk vanskeligere å forutsi og krever derfor defensive mønstre. Optimaliseringsansvaret ditt spenner over styringsbudsjett på tvers av handlingskjeder, API-forbruk, responslatens, Data 360-landingseffektivitet, kontekstvindubehandling og den sammensettbare utformingen som lar agenter skalere uten duplikater. Hvert ansvar er en verdikostnadsbeslutning før det er en teknisk, fordi agenter gjentar ineffektivitet på tvers av hver samtale.
Agenter kaller opp handlinger som utløser Apex, flyter og integrasjoner. En enkelt samtale kan utføre dusinvis av handlinger som agentårsaker gjennom en kompleks oppgave. Grunnleggende disiplin er den samme som for alle Salesforce-løsninger, men det uforutsigbare oppkallsmønsteret øker innsatsen. Utform handlinger for å godta samlinger slik at en agent som oppdaterer 50 saker, kaller opp én handling i stedet for 50 separate samtaler. En enkelt handling som opererer på en samling poster, bruker langt færre SOQL-spørringer (Salesforce Object Query Language) og DML-operasjoner (Data Manipulation Language) for det samme arbeidet. Behandle SOQL-budsjettet på tvers av handlingskjeder med vilje fordi en arbeidsflyt som kaller opp 10 til 15 handlinger, kan nærme seg eller overskride grensen for synkronisering med 100 spørringer når hver handling kjører flere egne spørringer. Bruk relasjonsspørringer til å hente overordnede og underordnede data i en enkelt setning, og referer til data som er bufret i plattformbuffer på tvers av handlinger i samme samtale. Disse to fremgangsmåtene holder en flerhandlingskjede innenfor budsjettet.
Flytt agentoperasjoner som overskrider synkrone grenser, til Apex i kø eller gruppe, der den asynkrone konteksten omtrent dobler SOQL- og CPU-hoderommet som er tilgjengelig for arbeidet. Store analytiske operasjoner, som å score 1000 salgsemner eller analysere stemninger på tvers av historiske saker, hører til asynkron behandling i stedet for å blokkere en samtale. Utleding av store språkmodeller skjer utenfor Salesforce og bruker Flex Credits i stedet for Apex CPU-tid, så CPU-budsjettet du profilerer, forbrukes av handlingslogikken, datatransformasjonene og integrasjonene som agenten utløser. Dataskjevhetsscenarier der overordnede poster er knyttet til tusenvis av underordnede poster, fortjener spesiell defensiv oppmerksomhet med agenter. Denne sårbarheten oppstår fordi en agent kan be om "all historikk" for en konto med titusenvis av relaterte poster på en måte som en deterministisk spørring aldri ville gjort. Utform handlinger med grenser for permanente underordnede poster og sideinndeling, og bruk utvalg når volumer overskrider terskelen for dataskift. Disse grensene hindrer at en uforutsigbar forespørsel blir til en ubegrenset spørring. Agentforce identifiserer hvilke handlinger som bruker for store spørringer på øktnivå, og Skaleringssenter overvåker den generelle Apex og organisasjonens tilstand.
Agentarkitekturer bruker API-er raskere enn brukerdrevne arbeidsflyter fordi agenter opererer automatisk og, for proaktive eller planlagte agenter, kontinuerlig. Hvordan en agent presenteres, bestemmer hvordan den trekker ned API-kapasiteten. Agenter som kalles opp via REST API, bruker én samtale per samtale. Agenter som er innebygd i Lightning via standardkomponenter, bruker ikke et API-kall per interaksjon, selv om deres kostnad fremdeles måles i kreditten eller samtalene for den valgte prismodellen. Tilpassede Lightning som utfører direkte REST-kall, bruker API-kapasitet. Komponenter som er bygd på Lightning Data Service-trådadaptere, gjør ikke det, fordi Lightning Data Service fungerer fra en delt buffer på klientsiden i stedet for å utføre et API-kall. Overvåk forbruket i Hendelsesovervåking under en pilot, slik at du forstår faktisk bruk før en full utrulling.
Hendelsesdrevne mønstre er det største spaken i forbruket av sløsing med agent-API. Publisering av en plattformhendelse når en betingelse krever agentintervensjon, unngår den planlagte avspørringen som forbruker API-kall uansett om det er arbeid å gjøre eller ikke, og en agent som abonnerer på Endre datafangst, beholder gjeldende kontekst uten de daglige avspørringskallene en ekstern orkestrator ellers ville utført. Logikken for verdi per kostnad er direkte: En avstemning som ikke finner noe arbeid, er kapasitet som brukes for ingenting, og en hendelse som utløses bare på grunn av en reell endring, er kapasitet som brukes bare på reelt arbeid. Hentningsforbedret generering legger til sitt eget forbruk fordi hvert vektorsøk mot Data 360 forbruker databehandling, så angi hentingsgrenser for å returnere bare resultatene som agenten faktisk bruker.
Latency for en agent turn er summen av LLM-utledningstid, handlingsutførelsestid, Data 360-spørringstid og integrasjonstid når disse trinnene kjøres i rekkefølge. Når de ikke gjør det, er det den lengste parallelle grenen pluss eventuelle sekvensielle trinn. Forsinkelse er både et kostnadsproblem og et opplevelsesproblem fordi en treg handling holder ressurser åpne lenger, og en frustrert bruker starter flere samtaler enn en løst ville. Kortere ledetekster genererer raskere svar, så fjern uforståelige instruksjoner, overflødige eksempler og unødvendig kontekst. Selektiv kontekst forbedrer både latens og svarkvalitet, der en omfattende kontekstdump bare legger til støy. Hold handlinger raske gjennom selektiv SOQL i indekserte felt, masseutførelse og bufrede referansedata, fordi en 3-sekunders handling blir en flaskehals uansett hvor rask utledningen er. Valider handlingsspørringer med Spørringsplan-verktøyet for å identifisere fullstendige tabellskanninger som øker handlingslatens.
Agentbyggerorkestrering kan utføre handlinger parallelt når det ikke finnes noen avhengigheter mellom dem, for eksempel tar henting av kontodetaljer og relaterte salgsmuligheter samtidig så lang tid som den tregere av de to i stedet for summen av begge. For samtaler som går til flere nedstrømsystemer, parer du Agentforce med en integrasjonsplattform som MuleSoft. Agenten kaller opp en enkelt handling, MuleSoft mottar forespørselen og sender parallelle samtaler til serverdelsystemer, og returnerer deretter ett samlet svar. Plattformbuffer fjerner utlednings- og spørringslatens for gjentatte forespørsler, og behandling av ikke-hurtig arbeid asynkront, som en lang dokumentanalyse, lar agenten bekrefte forespørselen umiddelbart og returnere resultatet når den er klar i stedet for å holde samtalen åpen.
Data 360 leverer vektorsøket som baserer agentsvar i gjeldende data i stedet for i modellens opplæringsdata alene, og dens effektivitet styrer både landingskvalitet og databehandlingen du bruker for å oppnå det. Fordeling, innbygging av valg, metadatafiltrering og resultatrenser er de mest verdifulle beslutningene. Del Knowledge i semantisk meningsfylte segmenter, fordi biter som er for små, tvinger mange henting for ett spørsmål, mens biter som er for store, fortynner relevans med irrelevant kontekst og oppblåser tokenbudsjettet som føres til utledningen. Velg en innbyggingsmodell som samsvarer med måten agentene faktisk spør på, fordi likhet mellom spørsmål og svar fungerer forskjellig fra dokumentklassifisering, og valider valget mot representative spørringer. Kombiner semantisk likhet med metadatafiltre slik at forretningsbegrensninger beholdes uavhengig av likhet, som å ekskludere avsluttede produkter fra en anbefaling uansett hvor nær samsvaret er. Angi top-k-grenser for å returnere bare resultatene som agenten bruker. Hvis for eksempel 5 resultater gir svar, legger henting av 50 til 45 ubrukte resultater i landingsbelastningen og tokenbudsjettet.
Forente profiler er ressurseffektive fordi en agent som spør en Data 360 forent profil, henter fullstendig kundekontekst i én enkelt operasjon i stedet for å orkestrerer separate spørringer mot Konto, Kontakt, Salgsmulighet, Sak og Kampanje for hver sving. Konfigurer Data 360-forekomster i regionene som lovpålagte krav krever, slik at agenter som behandler data for en gitt jurisdiksjon, spør forekomsten som beholder personlige data i den.
Kontekstvinduer med store språkmodeller inneholder et begrenset antall tokener, og behandling av dette budsjettet holder en lang samtale konsistent uten å utmattes kapasitet eller oppblåse kostnaden for hvert utledingskall. Prioriter med vilje i stedet for å forkorte vilkårlig: Siste samtalehistorikk tar høyeste prioritet, kritiske forretningsdata som gjeldende posttilstand og tillatelser kommer i andre rekke, og eldre historikk inkluderes bare når plass tillater det. Etter de første flere omgangene oppsummerer du tidligere diskusjoner til en presis oversikt som beholder viktige fakta uten å bære med deg full litteral historikk. Dette sammendraget beholder kontinuitet uten å øke tokenbudsjettet. Lagre utvidet kontekst i Data 360-objekter eller tilpassede objekter som eksternt minne som spørres på forespørsel i stedet for å spille av hele historikken på nytt i alle samtaler, og returner bare de vesentlige feltene fra hver handling, fordi et svar som bærer alle 50 feltene i en post når oppgaven trenger 8, bruker kontekstbudsjettet bedre tildelt til samtale eller jording.
Bygging av agenter fra gjenbrukbare komponenter reduserer utvikling og vedlikeholdskostnader. En funksjon som er bygd én gang og gjenbrukt, er mye billigere i løpet av levetiden enn den samme funksjonen som gjenimplementeres og vedlikeholdes separat for hver agent. Sentraliserte handlingsbiblioteker som dekker postoperasjoner, godkjenninger, varsler og validering, lar plattformteam opprettholde konsistent virkemåte, sikkerhet og ytelse på tvers av hver forbrukeragent, og de lar en ny agent settes sammen fra dokumenterte byggeblokker i løpet av dager i stedet for å bygges fra tilpassede handlinger over uker. Fokuserte spesialistagenter med tydelige domenegrenser opprettholder smalere kontekst og tydeligere virkemåte enn en enkelt universell agent som forsøker alle scenarier, og Agent Builder-orkestrering koordinerer spesialister når en oppgave krysser domener. Validerte ledetekstmaler i Ledetekstbygger fanger opp bevist mønstre for grunnlegging, resonans og svarformatering slik at kvaliteten forblir konsistent etter hvert som utviklingen akselereres, og en delt Knowledge i Data 360 grunnlegger mange agenter fra én kilde, slik at en oppdatering når alle forbrukere samtidig i stedet for å kreve en endring for hver agent.
Firmateam komponerer i økende grad flere agenter sammen i stedet for å bygge enkeltmonolittiske agenter, med en orkestreringsagent som dekomponerer en forespørsel og delegerer til spesialiserte underagenter, eller spesialiserte agenter som overfører til hverandre når en samtale beveger seg på tvers av domener. Denne sammensetningen reiser ressurs- og kostnadsspørsmål utover det en enkelt agent står overfor, fordi orkestreringsoverhead, inter-agent Trust og statshandover alle sammensettes på tvers av en kjede i stedet for å bli begrenset til én handling. Hold orkestreringsmeldingene smale, begrenset til å klassifisere hensikt og ruting, i stedet for å be orkestrereren om også å begrunnelse for den underliggende oppgaven, siden denne begrunnelsen tilhører underagenten med den relevante konteksten, og dekkkjeddybden med mindre et bruksområde tydelig krever dypere nesting enn orkestrator-til-underagent. Behandle hvert underagentrespons som ikke-klarerte inndata på samme måte som et eksternt API-svar. Valider dens forventede form og overholdelse av forretningsregler før du handler på den. Håndhev feltnivåsikkerhet og deling uavhengig for hver agenthandling.
Overfør bare tilstanden som mottakeragenten trenger, ved å bruke en strukturert overføringsbelastning med post-IDer, oppgavesammendrag og relevante felt i stedet for å videresende rå samtalehistorikk, så tokenbudsjettet på tvers av kjeden beholdes kontrollert, og behold øktstatusen på tvers av agenter i Data 360 eller et tilpasset objekt når en overføring må overleve på tvers av separate transaksjoner. Styringsgrenser gjelder per agent, ikke én gang per samtale, så hver agent i en kjede trekker sitt eget SOQL-, DML- og CPU-budsjett. En kjede av en orkestrator og tre underagenter bruker hver av disse grensene fire ganger over, og dypere kjeder multipliserer forbruket ytterligere. Den samme multiplikasjonen fører til kostnader, noe som gjør ubegrenset kjededybde til en mer kostnadsrisiko enn en styringsgrense.
Definer hva orkestreringen skal gjøre når en underagent mislykkes, tidsavbrytes eller returnerer et resultat med lite konfidens, enten det er et begrenset nytt forsøk, et reservesvar eller eskalering til et menneske, slik at et enkelt underagenttidsavbrudd ikke fører til at hele kjeden mislykkes. Korreler en forespørsel på tvers av hver agent den berører, med en delt sporings-ID som overføres via overføringsbelastningen, fordi diagnose av hvilken agent i en kjede som forårsaket en spike i latens eller en spike i kostnader, ellers krever manuell korrelasjon av logger på tvers av separate agentøkter.
Mislykkede handlinger og mislykkede underordnede agentkall påvirker ikke bare påliteligheten, fordi alle nye forsøk kan kjøre SOQL-, DML- og CPU-arbeid som allerede er brukt på det mislykkede forsøk, på nytt, og i en fleragentkjede kombineres denne kostnaden med antall mislykkede nedstrøms agenter. Under forbruksbasert prissætning bruger de samme fejlforbindelser såvel som beregner: en handlingen som prøves på nytt, bruker på nytt kreditter under Flex Credits. Utform logikk for å prøve på nytt for å ta hensyn til både pålitelighet og kostnad. Skill midlertidige feil, som en oppkalltidsavbrudd eller låsekonflikt, fra logiske feil, som en valideringsfeil eller en feilutformet inndata, før du bestemmer deg for hvordan du skal svare, fordi en midlertidig feil kan være verdt ett begrenset forsøk, mens en logisk feil mislykkes identisk ved gjentakelse og bare brenner budsjett for en garantert gjentagende feil som skal eskaleres umiddelbart i stedet.
Cap forsøker på nytt per handling, ved to eller tre forsøk, og bruker eksponentiell tilbakekall mellom dem i stedet for umiddelbar gjenoppkall, fordi et ubegrenset eller tett sløyfeforsøk på en SOQL- eller DML-tunge handling kan uttømme synkrone grenser i en enkelt transaksjon eller brenne gjennom kumulativt kjedebudsjett og kumulative kredittforbruk på tvers av en samtale med flere agenter. Utform handlinger slik at en prøvet samtale på nytt produserer samme slutttilstand som en enkelt vellykket samtale, ved å bruke en idempotency-nøkkel som en forespørsel-ID eller en ekstern ID med upsert-logikk i stedet for sett inn, slik at et nytt forsøk oppdaterer den samme posten i stedet for å opprette en duplikat. En handling som mangler idempotency, tvinger et nytt forsøk til enten å doble ressursforbruket gjennom duplikat nedstrøms poster eller doble de fakturerte handlingene eller samtalene for arbeid som allerede har skjedd én gang.
Spor fullføringsstatus per agent i en kjede fordi én agents handling kan bekrefte DML før en nedstrøms agent mislykkes, og en feilhåndtering som vet hva som allerede var vellykket, kan kompensere eller gjenoppta fra feilpunktet i stedet for å starte og fakturere hele kjeden på nytt. Visningsstatus for ny forsøk eller pågående til sluttbrukeren mens en begrenset ny forsøk pågår, fordi en bruker som ser stillhet og gjentar forespørselen, utløser en helt ny samtale og et nytt sett handlinger, og sammensetter ressurs- og faktureringskostnaden for det opprinnelige forsøk med et duplikat.
Ressursoptimaliseringsmønstrene som beskrives i dette dokumentet, hjelper bare hvis en arkitekt kan se hvor en agent faktisk bruker SOQL-spørringer, CPU-tid, DML-rader og tokener når den kjører i produksjonsorganisasjonen. Uten synlighet per handling og per økt vises et grenseavbrudd eller en latensregresjon som et symptom uten noen måte å spore den tilbake til handlingen eller agenten i kjeden som forårsaket den. Denne bekymringen skiller seg fra synligheten av utgifter som Digital Wallet gir under Kostnadsovervåking og økonomisk styring. Digital Wallet viser hvor mange kreditter eller samtaler en agent brukte, mens verktøyet viser hvorfor de ble brukt, på nivået til den individuelle spørringen, DML-raden eller handlingen som drev forbruket. Det riktige verktøyet avhenger av hva en gitt kundes organisasjon og kundestøtteavtale faktisk gir, ikke på hvilket verktøy som er teoretisk best, så samsvar anbefalingen med lisens- og tilgangsnivået i stedet for å bruke det mest tilgjengelige verktøyet som standard.
Alle arkitekter kan bygge tilpassede plattformhendelser som utløses på begynnelsen og slutten av hver handling og underagentoppkall. Disse hendelsene sporer utførelse på tvers av en samtale ved bruk av ingenting annet enn standard plattformfunksjonalitet, sammen med logging på handlingsnivå til et tilpasset objekt som fanger opp antall SOQL-spørringer, CPU-tid, antall DML-rader og bruk av heap når hver handling utføres. Begge hendelsene kan spørres via rapporter eller SOQL og gir hver organisasjon en grunnleggende diagnostisk funksjonalitet uavhengig av versjon eller tilleggslisens. Hendelsesovervåking, som ble introdusert tidligere for å spore API-forbruk under pilot, viser også aggregerte ressursbruksmønstre på tvers av agentøkter i hele organisasjonen for kunder der organisasjonen inkluderer tillegget, slik at en arkitekt kan identifisere hvilke arbeidsflyter som har en trend mot styringsgrenser på tvers av mange samtaler i stedet for å diagnostisere én om gangen. Skaleringssenter tilbyr dyp sporing av transaksjoner som nærmer seg styringsgrenser, vanligvis tilgjengelig via et kundestøtteengasjement eller tilgjengelig direkte på kontonivåer som gir den.
Versjonsbehandling av agenter uavhengig gjør kontrollert utrulling, tilbakekalling og sammenligning mulig, og det beskytter investeringen i en arbeidsagent mens du forbedrer den. Fremdrive virkemåten gjennom konfigurasjon der det er mulig, ved å bruke Tilpassede metadatatyper og Ledetekstbygger slik at administratorer justerer ledetekstmaler og handlingsvalg uten en utviklingssyklus. Bruk den pilotfunksjonen for A/B-testing til å rute et lite delsett av brukere til en eksperimentell versjon. Sammenlign kvalitet, tilfredshet og fullføring av oppgaver før en full utrulling. Denne sammenligningen validerer forbedringer med faktisk bruk og oppdager regresjoner mens eksponeringen er begrenset. Definer tydelige grensesnittkontrakter mellom komponenter, og angi inndata, utdata, feil og forventninger til ytelse, slik at en implementering kan erstattes uten å endre agentene som avhenger av den.
Agentøkonomi starter med total kostnad for eierskap målt mot forretningsverdi, men den forbruksbaserte prisingen av autonome agenter får kostnadssiden til å oppføre seg på en måte som tradisjonell lisensiering ikke gjør. Prismodellen du velger, er en grunnleggende arkitektonisk beslutning fordi den bestemmer hva du optimaliserer for på tvers av hele agentlivssyklusen. Denne delen etablerer prismodellene, det fullstendige TCO-bildet for en agentimplementering og bygg-mot-kjøp-beslutningen for agentfunksjoner.
Agentforce tilbyr to forbruksbaserte prismodeller, og en organisasjon velger en av de to for en gitt agentdistribusjon. Handlingen Flex Credits price per agent (Fleksibel kredit prissætning pr. agent), som gør handlingseffektivitet til leveransen for kostnadskontroll. Priser per samtale belaster en flat avgift per samtale uavhengig av lengde eller kompleksitet, noe som gjør samtalebeholdning til det viktigste. Abonnementer per bruker gir ikke-målt agentbruk som et ansattvendt tillegg i stedet for en tredje forbruksmodell, og de flytter optimaliseringsfokuset fra forbrukseffektivitet til tilpassing fordi verdi kommer fra lisensierte brukere som aktivt engasjerer agenten i stedet for å minimere hver interaksjon. De to forbruksmodellene er ikke blandet for samme organisasjon, men et tillegg Per bruker, som tilbys per bruker per måned for ikke-målert bruk, kan lages ved siden av en forbruksmodell slik at kunderettede agenter kjører på Flex Credits eller Per-Conversation mens ansatte bruker ikke-målte lisenser.
Handlingskostnader er faste per handling opp til et definert tokentak under Flex Credits. Til forskjell fra tokenbasert utledningsprising varierer ikke kreditkostnaden med ledetekstens lengde eller modellens kompleksitet, så et svar med én setning og et svar med flere avsnitt koster det samme. En interaksjon med flere handlinger forbruker kreditter for hver handling, så en interaksjon som henter data, årsaker og oppdaterer en post, forbruker kreditter for tre handlinger, og generering med utvidet henting legger til flere handlinger via vektorsøk og dokumenthenting før resonnement. Forståelse av gjennomsnittlig antall handlinger per forretningstransaksjon er derfor forutsetningen for kostnadsmodellering under Flex Credits.
Under Prissætning pr. samtale gælder et fladt gebyr pr. samtale, og flere omgange inden for en session tæller som en enkelt samtale, så omkostningskontrolle kommer fra at løse et problem inden for en samtale og definere tydelige sessionsgrænser i stedet for fra at afskære individuelle handlinger. Data 360-landing og MuleSoft-integrering bruker sin egen kapasitet sammen med den valgte modellen, siden innebygde genererings- og likhetssøk reduserer databehandlingskapasiteten for hver landede spørring, og hver eksterne handling forbruker API-kapasitet i både kildesystemer og målsystemer.
Total Cost of Ownership (TCO) for en agentimplementering spenner over seks kategorier, og modellering av alle seks gjør en kredittvurdering til en informert investeringsbeslutning. Utviklingskostnadene dekker agentutforming, prompt engineering, integrasjonsutvikling og testing, og de spenner fra en enkel enkelt agent til et fleragentsystem med kompleks orkestrering. Innledningsomkostninger avhenger av den valgte prismodellen og krever modellering av forventede handlingsvolumer under Flex-kreditter, samtalevolumer under Per-samtale eller antall lisensierte brukere under Per-bruker. For agenter som er jordet i store Knowledge, kan Data 360-infrastrukturen som leverer jording, konkurrere med eller overskride utledingskostnaden. Infrastrukturkostnader dekker Data 360- og MuleSoft-lisensene, ekstra Sandbox-enheter og overvåkingsinfrastruktur, og de er hovedsakelig faste eller trinnvise basert på kapasitetslag. Driftskostnader dekker overvåkingsoperasjoner, hurtigforbedring, hendelsessvar og brukerstøtte, og for modne agentprogrammer tilsvarer de vanligvis en betydelig andel av utviklingskostnadene årlig, i samsvar med generelle bransje-referanser for AI-agenter i stedet for en Salesforce-spesifikk tall. Forvaltningskostnader dekker sikkerhetskontroll, menneskelig tilsyn, revisjonslogging og samsvarsvalidering som øker med agentens autonomi og risiko, og Fairness-pilen dekker de viktigste programmekomponentene. Endringskostnader dekker brukeropplæring, tilpassing av forretningsprosesser og organisasjonsendringsledelse, og disse er kategoriteamene som oftest undervurderes.
Bygg regneark-TCO-modeller som projiserer kostnader i 3-5 år. Dokumenter antagelser for interaksjonsvolumer, handlingsantall og vekst. Kjør sensitivitetsanalyse for å identifisere forutsetningene som påvirker summen mest, og fokuser deretter valideringen på disse forutsetningene. Modeller alle tre kostnadsstrukturer, Flex Credits, Per-Conversation og Per-User, mot projisert bruk før bekreftelse, fordi den optimale strukturen avhenger av bruksmønsteret, og det feilvalg er dyrt å løsne når en agent er i produksjon.
Beslutningen om å bygge mot å kjøpe for agenter følger samme logikk som for hvilken som helst Salesforce-funksjonalitet, og veier den umiddelbare tiden til verdi for en ferdig løsning mot den nøyaktige tilpassingen av en tilpasset bygg over en TCO-horisont på 3-5 år. Commodity-arbeidsflyter favoriserer kjøp, mens kjernefunksjonaliteten som fremmer egenskapelig differensiering, berettiger bygging. Agentic Enterprise tilbyr et spekter av alternativer i stedet for et binært valg. Forhåndsbygde Agentforce, som en tjenesteagent eller en Sales Development Representative (SDR), gir bevist funksjonalitet med rask distribusjon og plattformvedlikeholdte oppdateringer. De forbruker kreditter under den valgte prismodellen. Kommersielt tilgjengelige agenter fra Salesforce Independent Software Vendor (ISV)-fellesskapet tilbys via AgentExchange, der du kan finne en løsning som allerede oppfyller et krav i stedet for å bygge den. Tilpassede agenter som er bygd med Agent Builder, gir presis tilpassing og konkurransedyktig differensiering på bekostning av forhåndsutvikling pluss kontinuerlig forbedring og vedlikehold av ledetekster. Tilpassing av en forhåndsbygd agent gjennom Ledetekstbygger og handlingskonfigurasjon gir et mellomliggende grunnlag som koster mindre enn full tilpasset utvikling, samtidig som du tilpasser agenten til organisasjonen. Ut over kostnader veier du tid-til-verdi-krav, intern utviklingsfunksjonalitet, strategisk differensiering og toleranse for leverandøravhengighet, og registrerer beslutningen i en Beslutningspost for arkitektur slik at den kan vurderes på nytt etter hvert som kravene endres.
Implementeringsagenter som har en klar forståelse av den underliggende kostnadsstrukturen, gjør at autonom funksjonalitet skaleres bærekraftig i stedet for å utnytte et budsjett. Optimaliseringsspaken avhenger av prismodellen fordi det du justerer for å kontrollere kostnader, er forskjellig mellom å betale per handling, å betale per samtale og å betale per bruker. Prinsippet er konstant på tvers av alle tre: justere forbruk mot verdien som faktisk er levert, slik at en kvalifikert agent ikke stille brenner budsjettet sitt raskere enn det returnerer forretningsutfallet.
Under Flex Credits betyr optimalisering å minimere handlingene per forretningsutfall samtidig som kvaliteten beholdes. Løs enkle forespørsler i én enkelt handling i stedet for en arbeidsflyt med flere trinn, slik at svar på vanlige spørsmål eller å utføre et rutinemessig oppslag ikke bruker kreditter fra en kjede med tre handlinger. Konsolider operasjoner i én enkelt handling der det er fornuftig, ved å kombinere henting, analyse og svar i stedet for å betale for hver enkelt handling separat når én handling skal brukes. Bufrer svar for gjentatte forespørsler slik at vanlige spørsmål tjener fra bufferen i stedet for å forbruke nye handlinger på hver identiske spørring, som er den største effektivitetsspaken under denne modellen når en meningsfull andel av spørringer gjentas.
Under Prissætning pr. samtale betyder optimering, at løse problemer i en enkelt samtale i stedet for på tværs af flere. Utform øktgrenser og tidsavbrudd slik at en samtale vedvarer riktig uten å avslutte for tidlig og tvinge en ny fakturerbar samtale. Fokuser agentfunksjonalitet på første samtaleløsning slik at en oppgave fullføres i den første samtalen i stedet for å kreve oppfølging. Spor løsningsgraden for første samtale som en kostnadseffektiv måling, og avvis omfangsutvidelse der en bruker åpner separate samtaler for relaterte problemer som den eksisterende samtalekonteksten kunne ha håndtert.
Under Abonnementer per bruker betyr optimalisering maksimering av verdien hver lisensiert bruker returnerer, fordi forbruket ikke måles og kostnaden er fast per plass. Fokuser på tilpassing slik at lisensierte brukere aktivt engasjerer agenten, spor utnyttelse for å identifisere brukere med lite bruk for målrettet opplæring eller lisensomordning, og koble agentinteraksjoner til forretningsutfall etter brukerpopulasjon slik at brukstilfeller med høy verdi berettiger investeringen, mens bruk med lav verdi signalerer et behov for optimalisering eller en annen prismodell. Se gjennom brukerpopulasjoner etter en kadens slik at lisenser holdes på linje med faktisk bruk.
Uavhengig av prismodellen påvirker arkitektur kostnaden. Implementer sorteringsagenter som håndterer første ruting med enkel logikk, og dirigere brukere til en spesialisert agent bare når kompleksiteten krever det, slik at dyre komplekse kall bare skjer når de er berettiget. Gå tilbake til tradisjonell automatisering for deterministiske scenarier der regelbasert logikk er tilstrekkelig, slik at flyter håndterer deterministiske baner til en lavere kostnad, mens agenter håndterer tvetydige situasjoner som virkelig krever resonnement. Hent landingsdata selektivt ved å kalle opp vektorsøk og dokumenthenting bare når agentens resonnement krever det, i stedet for hver interaksjon, slik at Data 360-forbruk sporer reelt behov. Disse mønstrene holder kostnaden for resonans og forbruk for arkitekturen proporsjonal med vanskeligheten i arbeidet.
Overvåking av kostnader for autonome agenter er vanskeligere enn for tradisjonelle arbeidsbelastninger fordi agenter ikke følger et forutsigbart mønster for forespørsel-svar. En agent kan gjenta gjennom flertrinns resonans, kalle opp verktøy på en adaptiv måte basert på kjøretidsbetingelser og koordinere andre agenter, noe som gir svært varierende kredittforbruk som er vanskelig å forutsi. Uten overvåking kan en agent som utfører dypt gjentagende arbeid, forbruke et stort antall kreditter før noen griper inn, og ineffektiv ledetekstutforming eller overflødige vurderingssløyfer kan stille tømme budsjetter på tvers av en hel agentflåte. Effektiv styring krever derfor sanntids synlighet av forbruk per agent og per operasjon, automatisert varsling og kontroller som hindrer løpskostnader, samtidig som man beholder autonomi som gjør agenter nyttige. Økonomisk styring for agenter trenger også tydelig eierskap og gradert godkjenning som er bygd for variabelt forbruk i stedet for for statisk beregningskostnad.
Salesforce Digital Wallet er det innebygde verktøyet for å overvåke forbruksbaserte produkter, inkludert Agentforce Flex Credits, og organisasjoner som bruker Flex Credits, bør etablere det som den primære kostnadsovervåkingsmekanismen i stedet for å bygge tilpassede kontrollpaneler for å replikere det den tilbyr. Digital Wallet leverer nær sanntids forbruksdata med innsikt i bruk på handlingsnivå, en oppdeling per agent som viser hvilke agenter som forbruker mest, proaktive forbruksvarsler og historiske trender for mønsteranalyse og prognoser. Samsvare overvåkingen med prismodellen. Under Flex Credits kan du spore forbruk etter agent, brukerpopulasjon, tidsperiode og handlingstype, og supplere Digital Wallet med tilpassede kontrollpaneler som knytter kredittforbruk til forretningstransaksjoner. Under Prissætning pr. samtale skal du overvåge samtalevolumer, gennemsnitsvarighed og fuldførelsesfrekvenser. Under Abonnementer per bruker overvåker du utnyttelse i stedet for forbruk, og sporer aktive brukere og forretningsverdi per bruker slik at lisensinvesteringen vises for å levere proporsjonal verdi.
Kostnadstildeling per interaksjon knytter forbruk til forretningstransaksjoner og viser kostnaden per løst sak, per kvalifisert salgsemne eller per behandlet bestilling, noe som muliggjør beregning av avkastning på investeringer og sammenligning på tvers av brukstilfeller. Budsjettvarsel utløser varsler etter hvert som forbruket nærmer seg definerte terskler, ved terskler som 70 % og 85 % av budsjettet, slik at optimalisering skjer før en grense nås. Konfigurer varsler per agent og per bruksområde i stedet for bare organisasjonsomfattende for å lokalisere et problem til kilden. Avvikdeteksjon viser den plutselige forbruksspissen som signaliserer et uventet bruksmønster eller en resonanssløyfe som trenger undersøkelse. Del kostnadskontrollpaneler med forretningsinteressenter og tekniske team slik at gjennomsiktighet fører til kostnadsbevisst agentbruk.
Bruk økonomisk styring før du bekrefter utgifter til en agentarkitektur. Krev en forretningssak for en agentinvestering som dekker projisert TCO over 3–5 år under den valgte prismodellen, forventede forretningsutfall med en målingsmetode, en sammenligning med alternativer, inkludert manuelle prosesser og tradisjonell automatisering, og en risikovurdering som dekker kvalitet, sikkerhet og driftsrisiko. Definer godkjenningsterskeler som skiller investeringene en avdeling kan godkjenne fra de som krever godkjenning fra ledere, slik at en agent med høy investering eller høy risiko får proporsjonal gjennomgang. Mandater pilotdistribusjoner som validerer forutsigelser før full produksjon, fordi en pilot avdekker faktisk forbruk, kvalitet og tilpassing som informerer både produksjonsinvesteringsbeslutningen og valg av prismodell.
Behandle agentfasiliteten som en portefølje i stedet for agent etter agent fordi en porteføljevisning viser optimaliseringsmuligheter som en enkeltagentgjennomgang mangler. Se gjennom alle agenter sammen, sammenlign kostnad, bruk, forretningsverdi og strategisk justering, og definer solnedgangskriterier som avslutter agenter med lav tilpassing, dårlig avkastning på investeringer, overdreven funksjonalitet eller overdreven kostnad, slik at agenter med lav verdi ikke akkumulerer og forbruker budsjett på ubestemt tid. Tildel investeringer på nytt fra agenter med lav ytelse til salgsmuligheter med høy verdi som en kontinuerlig fremgangsmåte som justerer utgifter med utviklende prioriteringer i stedet for en engangs opprydding.
Kostnadstildeling oppretter ansvar for agentforbruk, og organisasjoner implementerer den gjennom de samme to modellene som gjelder for resten av plattformen. Showback-rapporterer agentkostnader etter forretningsenhet uten en intern kostnad, noe som skaper kostnadsbevissthet og informerer optimaliseringsdiskusjonen uten diskusjonen om intern fakturering. Tilbakekalling tildeler faktiske agentkostnader til de forbrukende forretningsenhetene, noe som fører til sterkere optimaliseringsvirkemåte fordi kostnaden påvirker et avdelingsbudsjett direkte, men krever en nøyaktig tildelingsmetode for å unngå tvister. En hybridtilnærming bruker tilbakekostnad for produksjonsagenter med stor trafikk mens du bruker tilbakekostnad for eksperimentelle eller agenter med lav trafikk, som balanserer ansvarlighet for store investeringer mot fleksibilitet for innovasjon.
Agentarkitekturer introduserer sine egne bærekraftsvurderinger fordi utleding av store språkmodeller er beregningsintensiv, og noen agenter kjører kontinuerlig i stedet for bare i diskrete brukerutløste transaksjoner. Proaktive, utgående og planlagte agenter opererer uten en bruker i sløyfen, samtaleagenter akkumulerer forbruk på tvers av mange svinger, og vektorsøk, kontekstforberedelse og utføring av handlinger bidrar alle til infrastrukturbelastningen. Bærekraftig agentutforming minimerer beregningsavfall samtidig som opplevelsen holdes responsiv. Som i søylen Ressurs- og kostnadsoptimalisering er relasjonen mellom én løsning og datasenterutslipp indirekte. En enkelt leietageres effektivitet reduserer ikke utslipp direkte. Effektivitetsforbedringer på tvers av alle leietagere hjelper imidlertid Salesforce med å kjøre sin infrastruktur med høyere utnyttelse og utsette kapasitetsutvidelse. og de grunnleggende fremgangsmåtene for bærekraft fra søylen Resource and Cost Optimization (Ressurs- og kostnadsoptimalisering) gjelder for agenter, og effektivitetsstrategiene som følger, tar begge opp det som er spesifikt for samtalesystemer som leveres med storspråklige modeller. Hver av dem reduserer også kostnader, og det er derfor bærekraft og verdi per kostnad er den samme disiplinen målt mot forskjellige utfall.
Utleding er den mest ressursintensive komponenten i en agentisk arkitektur, så effektivitet lønner seg med ledetekstlengde, kontekstbruk og bufring. Optimaliser ledetekster for å overføre hensikt i færre tokener ved å fjerne overflødige instruksjoner og eksempler, fordi en kortere ledetekst reduserer beregningen av forhåndsutfylling proporsjonalt selv om den ikke endrer beregningen for generering av svaret. Behandle kontekstvinduet ved å oppsummere samtalehistorikk etter de første flere omgangene og returnere bare viktige felt fra hver handling, slik at tokenbudsjettet som bæres inn i hver utledning, forblir begrenset i stedet for å vokse med samtalen.
Vektorsøk og forente profilspørringer forbruker beregningsressurser, så den samme resultatgrensen og filtreringsdisiplinen som styrer kostnadene ved jording, reduserer også infrastrukturbelastningen ved jording. Angi top-k-grenser for å returnere bare resultatene som agenten bruker, fordi henting av 50 når 5 informerer svaret, fører med seg 45 ubrukte resultater som forbruker jordingstokenbudsjettet uten nytte, og bruke metadatafiltre til å avgrense søket før likhetsrangeringen. Spørre forente profiler for å sette sammen fullstendig kontekst i én operasjon i stedet for å utstede separate spørringer mot flere objekter for hver omgang, og bufre profiler for agenter med høy brukertilknytning, som en salgsagent som arbeider med et fast sett av kontoer, slik at gjentatte kontekstsammendrag ikke gjentar spørringen.
Agenthandlinger bruker SOQL-spørringer, DML-operasjoner og CPU-tid, så masseutførelse, bufring og asynkron disiplin for pilaren Ressurs- og kostnadsoptimalisering gjelder direkte for agenthandlinger. Utform handlinger for å godta samlinger slik at oppdatering av mange poster er én operasjon i stedet for mange, bruk relasjonsspørringer til å hente overordnede og underordnede data i en enkelt setning, bufre referansedata i plattformbuffer og batch DML på tvers av en samling i stedet for per post. Flytt operasjoner som overskrider synkrone grenser, til Apex i kø eller gruppe, behandle ikke-hurtig arbeid som massescoring eller historisk anriking asynkront, og planlegg agentutløste gruppejobber for vinduer utenfor toppnivåer der det er mulig, slik at belastningen spres over tid i stedet for å konsentrere seg i åpningstidene. Overvåk asynkron utførelse slik at en køetterslep signalerer et kapasitetsplanleggingsbehov før det blir en feil.
Agentforbruksmønstre utvikles etter hvert som bruken øker, så bærekraft krever kontinuerlig overvåking i stedet for en engangs overføring. Spor de gjennomsnittlige tokenene per utledning gjennom den tilgjengelige telemetrien for bruk slik at en stigende ledetekstststørrelse viser en optimaliseringsmulighet, overvåk samtalelengdefordeling slik at ikke-begrensede samtaler avslører et oppgavegrenseproblem, og analyser handlingsutførelsesfrekvensen i Hendelsesovervåking slik at en høyfrekvent handling blir en optimaliseringsprioritet. Se gjennom Data 360-spørringsmønstre for å finne vanlige spørringer som er verdt bufring eller forhåndsberegning, spor trafikkfrekvensen for semantisk bufring slik at en lav frekvens utløser terskeljustering, og måle latensprosentiler slik at halelatens viser eventuelle flaskehalser. Se regelmessig gjennom agentbruken for omfangsavvik. Undersøk for eksempel en agent med en gjennomsnittlig samtalevarighet som øker fra en håndfull svinger til mange over flere måneder. Begrens agentens grenser slik at forbruket går tilbake til planen. Noen av disse overvåkingsflatene viser bruk i aggregerte kontrollpaneler i stedet for som en separat logg per utfall, så kontroller nøyaktig hvilken telemetri som er tilgjengelig for konfigurasjonen når du utformer overvåkingen.
Ressursoptimalisering bestemmer om agentarkitekturer skaleres etter hvert som populasjoner vokser og brukstilfeller utvides, og kostnadsoptimalisering bestemmer om denne skalaen returnerer proporsjonal forretningsverdi. Disse to beslutningene danner ett mandat:
- Arkitektonisk effektivitet: utforme handlinger med masseutførelse, budsjettere SOQL på tvers av handlingskjeder, flytte tung behandling til asynkron, optimalisere API-forbruk gjennom sammensatte og hendelsesdrevne mønstre, behandle kontekstvinduer gjennom prioritering og oppsummering og bygge komponerbare arkitekturer fra gjenbrukbare komponenter.
- Økonomisk veiledning: Velg prismodellen med vilje, modeller fullført TCO før du forplikter deg, overvåk forbruk mot forretningsutfall og styr investeringer gjennom gradert godkjenning og porteføljegjennomgang.
Organisasjoner som overvåker disse mønstrene, leverer responsive agentopplevelser innenfor plattformbegrensninger samtidig som de holder utgiftene i samsvar med verdien agentene returnerer.
Veiledningen for grunnleggende ressurs- og kostnadsoptimalisering for alle Salesforce-løsninger, inkludert ytelsesoptimalisering, styringsgrenser, TCO-analyse, lisensieringsdisiplin og kostnadsstyring, finnes i søylen Ressurs- og kostnadsoptimalisering. Agentstyring-, personovervåking- og sikkerhetsprogramkomponentene kobles til stolpene Trust og Fairness. Den detaljerte veiledningen for agentimplementering i dette dokumentet, som spenner over ressurseffektivitet, økonomi, handlingsoptimalisering, styring og bærekraft, samles inn i mønsterbiblioteket for agenter.