Ressource- og omkostningsoptimering for agentvirksomheden
Autonome agenter forbruger Salesforce-ressourcer anderledes end deterministisk automatisering. Agentarbejdsbelastninger er uforudsigelige og kontinuerlige i stedet for faste og transaktionsbundne. Værdi-pr.-omkostning-afhandlingen i søjlen Ressourceoptimering og Omkostningsoptimering fører direkte ind i agentvirksomheden. Ressourceeffektivitet betyder brug af den kapacitet, du allerede betaler for, og omkostningsoptimering betyder at dirigere forbrug med vilje mod de autonome funktioner, der tjener en fortjeneste. Agenter ændrer formen på begge. Effektivt agentdesign holder forbruget under kontrol, og valg af prissætningsmodel, TCO-modellering og økonomisk styring holder forbruget i overensstemmelse med værdien. Dette dokument behandler ressourceeffektivitet og omkostningsoptimering som en beslutning, fordi de for agenter er to visninger af det samme mål.
Agenter ændrer forudsigeligheden af forbrug. En traditionel Apex kører på et kendt registreringssæt med en kendt ressourceomkostning. En agent fungerer samtalemæssigt, og en enkelt samtale kan udføre dusinvis af handlinger som agentårsager gennem en opgave. Hver handling forbruger styringsbegrænsninger i sin egen transaktion i stedet for at akkumulere dem på tværs af samtalen. Kontekstforberedelse for en drejning kan forespørge på 200 registreringer eller 20.000, afhængigt af hvad brugeren beder om. API-forbruget accelererer, fordi agenter kan reagere autonomt og proaktive, udgående og planlagte agenter handler kontinuerligt snarere end kun under en brugertransaktion. Denne uforudsigelighed er grunden til, at agentressourceadministration skal være defensiv efter design snarere end justeret, efter der forekommer et forbrugsspike.
Omkostningssiden ændres lige så meget. Autonome agenter introducerer forbrugsbaseret prissætning, der fungerer anderledes end traditionel pr. plads-licens. Agentforce tilbyder to forbrugsbaserede prissætningsmodeller, Flex Credits og Per-Conversation. Hver agentimplementering vælger en af disse modeller. En organisation bruger en forbrugsmodel ad gangen, men et Pr. bruger-tilføjelsesprogram, der tilbydes pr. bruger pr. måned for ikke-målt brug, kan lagres sammen med en forbrugsmodel, så kundeorienterede agenter kører på Flex Credits eller Pr. samtale, mens medarbejdere bruger ikke-målte licenser. Data 360 styrker agentgrundlægning gennem vektorsøgning og hentning og forbruger databehandlingskapacitet, mens MuleSoft aktiverer agentintegrationer, der forbruger API-kapacitet. Disse variabelomkostninger skaleres med agentanvendelse, hvilket opretter et investeringsmønster, der har brug for finansiel styring, der er bygget til variation snarere end et fast årligt abonnement.
Løsninger, der er designet til forretningsværdi med optimerede omkostninger i agentvirksomheden, holder agentforbruget effektivt gennem handlinger, der behandler registreringer i grupper, disciplinerede kontekstvinduer og cachelagring. De dirigerer også med vilje forbrug gennem den rigtige prissætningsmodel, fuldstændig TCO-modellering og kontinuerlig omkostningsovervågning op mod forretningsresultater. Uden denne justering akkumulerer agentimplementeringer omkostninger uden at demonstrere proportional værdi, og en agent, der har årsager i en ubegrænset løkke, kan brænde kreditter hurtigere, end menneskelig tilsyn kan gribe ind. Det samme effektivitetsarbejde, der bevarer en agent inden for dens styringsbegrænsninger, bevarer den inden for dets kreditbudget, hvilket er den søjleafhandling, der udtrykkes i agentiske termer.
Dette dokument dækker, hvad der ændres, når agenter er på billedet. Hvis du vil se de grundlæggende mønstre for optimering af ressourcer og omkostninger, der gælder for hver Salesforce-løsning, herunder optimering af ydeevne, styringsbegrænsninger, TCO-analyse og licensdisciplin, kan du se søjlen Resource- og omkostningsoptimering. Agentstyring og menneskelig tilsyn er forbundet med søjlerne Trust og Fairness, som dækker de programkomponenter, der holder autonom adfærd sikker og ansvarlig.
Agentressourceforbrug følger den samme platformsmekanik som forløb eller Apex, men dets uforudsigelige samtalebaserede kald gør forbruget sværere at forudsige og kræver derfor defensive mønstre. Dine optimeringsansvar omfatter styringsbegrænset budgettering på tværs af handlingskæder, API-forbrug, svarforsinkelse, Data 360-landingseffektivitet, kontekstvinduesstyring og det sammensatte design, der gør det muligt for agenter at skalere uden duplikering. Hvert ansvar er en værdi-pr.-omkostningsbeslutning, før det er en teknisk, fordi agenter gentager ineffektiviteter på tværs af hver samtale.
Agenter kalder handlinger, der udløser Apex, forløb og integrationer. En enkelt samtale kan udføre dusinvis af handlinger som agentårsager gennem en kompleks opgave. Grundlæggende disciplin er den samme som for enhver Salesforce-løsning, men det uforudsigelige kaldmønster øger indsatsen. Design handlinger til at acceptere samlinger, så en agent, der opdaterer 50 sager, kalder en handling i stedet for 50 separate opkald. En enkelt handling, der kører på en samling af registreringer, forbruger langt færre SOQL-forespørgsler (Salesforce Object Query Language) og DML-handlinger (Data Manipulation Language) for det samme arbejde. Administrer SOQL-budgettet på tværs af handlingskæder med vilje, da et arbejdsflow, der kalder 10 til 15 handlinger, kan nærme sig eller overstige den 100-forespørgselssynkrone grænse, når hver handling kører flere forespørgsler efter sig selv. Brug relationsforespørgsler til at hente overordnede og underordnede data i en enkelt erklæring, og referer til data, der er sat i cache i platformscache på tværs af handlinger i den samme samtale. Disse to fremgangsmåder bevarer en kæde med flere handlinger inden for dets budget.
Flyt agenthandlinger, der overskrider synkrone grænser, til Apex i kø eller batch, hvor den asynkrone kontekst stort set fordobler det SOQL- og CPU-sideområde, der er tilgængeligt for arbejdet. Store analytiske handlinger, f.eks. scoring af 1.000 emner eller analyse af sentiment på tværs af historiske sager, hører til asynkron behandling i stedet for at blokere en samtale. Selv storsprogmodel inference sker uden for Salesforce og forbruger Flex Credits snarere end Apex CPU tid, så det CPU budget, du profilerer, forbruges af handlingslogik, data transformationer og de integrationer, agenten udløser. Dataskydsscenarier, hvor overordnede registreringer er tilknyttet tusindvis af underordnede registreringer, fortjener særlig defensiv opmærksomhed hos agenter. Denne sårbarhed opstår, fordi en agent kan anmode om “hele historikken” for en konto med tusindvis af relaterede registreringer på en måde, som en deterministisk forespørgsel aldrig ville. Design handlinger med grænser for hard underordnede registreringer og sideinddeling, og anvend prøvevisning, når mængderne overskrider dataskudstærsklen. Disse begrænsninger forhindrer en uforudsigelig anmodning i at blive til en ubegrænset forespørgsel. Agentforce identificerer, hvilke handlinger der forbruger overdreven forespørgsler på sessionsniveau, og Skaleringscenter overvåger den generelle Apex og organisationens tilstand.
Agentarkitekturer forbruger API’er hurtigere end brugerstyrede arbejdsflows, fordi agenter fungerer autonomt og, for proaktive eller planlagte agenter, kontinuerligt. Hvordan en agent vises bestemmer, hvordan den nedtrækker API-kapacitet. Agenter, der kaldes gennem REST API, forbruger et opkald pr. samtaleskift. Agenter, der er integreret i Lightning gennem standardkomponenter, forbruger ikke et API-kald pr. interaktion, selvom deres omkostninger stadig måles i kreditter eller samtaler for den valgte prissætningsmodel. Tilpassede Lightning, der foretager direkte REST-kald, forbruger API-kapacitet. Komponenter, der er bygget på Lightning Data Service-wireadaptere, gør ikke, da Lightning Data Service fungerer fra en delt cache på klientsiden i stedet for at udstede et API-kald. Overvåg forbrug i Begivenhedsovervågning under et pilotprogram, så du forstår den faktiske anvendelse før en fuld udrulning.
Begivenhedsstyrede mønstre er det største håndtag på forbrug af forbrugt agent-API. Udgivelse af en platformsbegivenhed, når en betingelse kræver agentintervention, undgår den planlagte afstemning, der forbruger API-kald, uanset om der er arbejde at gøre, og en agent, der abonnerer på dataregistrering, bevarer den aktuelle kontekst uden de daglige afstemningskald, som en ekstern orkester ellers ville foretage. Værdi-pr.-omkostningslogikken er direkte: En afstemning, der finder ingen arbejde, er kapacitet, der bruges til ingenting, og en begivenhed, der kun udløses på en reel ændring, er kapacitet, der kun bruges på reelt arbejde. Hentningsforøget generering tilføjer sin egen forbrug, fordi hver vektorsøgning mod Data 360 forbruger beregning, så angiv hentningsgrænser til kun at returnere de resultater, som agenten faktisk bruger.
Forsinkelse for en agentskift er summen af LLM-udledningstid, handlingsudførelsestid, Data 360-forespørgselstid og integrationstid, når disse trin køres i rækkefølge. Når de ikke gør det, er det den længste parallelle forgrening plus eventuelle sekventielle trin. Forsinkelse er en omkostningsforpligtelse såvel som en oplevelsesforpligtelse, fordi en langsom handling holder ressourcer åbne længere, og en frustreret bruger starter flere samtaler, end en løst ville. Kortere meddelelser genererer hurtigere svar, så fjern overflødige instruktioner, overflødige eksempler og unødvendig kontekst. Selektiv kontekst forbedrer både forsinkelse og svarkvalitet, hvor et udtømmende kontekstdump kun tilføjer støj. Hold handlinger hurtige gennem selektiv SOQL på indekserede felter, massebehandling og cachelagrede referencedata, fordi en handling på 3 sekunder bliver en flaskehals, uanset hvor hurtig en konklusion er. Valider handlingsforespørgsler med forespørgselsplanværktøjet for at identificere fulde tabelscanninger, der øger handlingsforsinkelse.
Orkestrering i Agentkonstruktør kan udføre handlinger parallelt, når der ikke findes nogen afhængigheder mellem dem, f.eks. at hente kontodetaljer og relaterede salgsmuligheder på samme tid tager lige så lang tid, som den langsommere af de to snarere end summen af begge. For opkald, der søger ud til flere downstream-systemer, skal du parre Agentforce med en integrationsplatform som MuleSoft. Agenten kalder en enkelt handling, MuleSoft modtager anmodningen og udsteder parallelle opkald til backendsystemer og returnerer derefter et aggregeret svar. Platformscache fjerner konklusion og forespørgselsforsinkelse for gentagne anmodninger, og behandling af ikke-nødvendigt arbejde asynkront, f.eks. en lang dokumentanalyse, giver agenten mulighed for straks at bekræfte anmodningen og returnere resultatet, når det er klar i stedet for at holde samtalen åben.
Data 360 leverer den vektorsøgning, der baserer agentsvar i aktuelle data snarere end i modellens træningsdata alene, og dens effektivitet styrer både baseringskvalitet og den beregning, du bruger for at opnå den. Opdeling, integrering af valg, metadatafiltrering og resultatgrænser er de mest værdifulde beslutninger. Opdel Knowledge i semantisk meningsfulde segmenter, fordi segmenter, der er for små, tvinger mange hentninger for et spørgsmål, mens segmenter, der er for store, fortynder relevans med irrelevant kontekst og opblæser tokenbudgettet, der føres til konklusion. Vælg en integreringsmodel, der matcher den måde, dine agenter faktisk forespørger på, da lighed mellem spørgsmål og svar fungerer anderledes end dokumentklassificering, og valider valget op mod repræsentative forespørgsler. Kombiner semantisk lighed med metadatafiltre, så forretningsbegrænsninger gælder, uanset lighed, f.eks. udeladelse af afbrudte produkter fra en anbefaling, uanset hvor tæt matchet er. Angiv top-k-grænser for kun at returnere de resultater, som agenten bruger. Hvis f.eks. 5 resultater giver et svar, vil hentning af 50 føje 45 ikke-anvendte resultater til basisdataene og tokenbudgettet.
Forenede profiler er ressourceeffektive, fordi en agent, der forespørger på en forenet Data 360-profil, henter fuld kundekontekst i en enkelt handling i stedet for at orkestrere separate forespørgsler mod Konto, Kontakt, Salgsmulighed, Sag og Kampagne for hver drejning. Konfigurer Data 360-forekomster i de områder, som bestemmelseskrav kræver, så agenter, der behandler data for en angivet jurisdiktion, forespørger på den forekomst, der bevarer personlige data i den.
Kontekstvinduer med store sprogmodeller indeholder et begrænset antal tokener, og administration af dette budget bevarer en lang samtale sammenhængende uden at opbruge kapaciteten eller øge omkostningerne for hvert konklusionskald. Prioriter med vilje i stedet for at afskære vilkårligt: seneste samtalehistorik har den højeste prioritet, kritiske forretningsdata, f.eks. aktuel registreringstilstand og tilladelser, kommer i anden række, og ældre historik inkluderes kun, når plads tillader det. Efter de første par omgange kan du opsummere tidligere samtale til en præcis oversigt, der bevarer vigtige fakta uden at medtage fuld ordret historik. Dette sammendrag bevarer kontinuitet uden at øge tokenbudgettet. Gem udvidet kontekst i Data 360 eller tilpassede objekter som ekstern hukommelse, der forespørges på efterspørgsel i stedet for at afspille den fulde historik i hvert kald, og returner kun de vigtige felter fra hver handling, fordi et svar, der bærer alle 50 felter i en registrering, når opgaven har brug for 8, bruger kontekstbudgetten bedre tildelt til samtale eller jordning.
Opbygning af agenter fra genanvendelige komponenter reducerer udviklings- og vedligeholdelsesomkostninger. En funktion, der er bygget en gang og genbrugt, er meget billigere i løbet af dens levetid end den samme funktion, der er genimplementeret og vedligeholdt separat for hver agent. Centraliserede handlingsbiblioteker, der dækker registreringshandlinger, godkendelser, adviseringer og validering, giver platformsteams mulighed for at vedligeholde ensartet adfærd, sikkerhed og ydeevne på tværs af hver forbrugeragent, og de giver en ny agent mulighed for at blive samlet fra gennemprøvede byggeblokke på dage i stedet for bygget fra tilpassede handlinger over uger. Fokuserede specialagenter med tydelige domænebegrænsninger bevarer en smalere kontekst og tydeligere adfærd end en enkelt universel agent, der forsøger alle scenarier, og orkestrering i Agentkonstruktør koordinerer specialister, når en opgave krydser domæner. Validerede meddelelsesskabeloner i Promptkonstruktør registrerer gennemprøvede mønstre for grundlægning, argumentering og svarformatering, så kvaliteten forbliver ensartet, efterhånden som udviklingen accelererer, og en delt Knowledge i Data 360 grundlægger mange agenter fra en kilde, så en opdatering når alle forbrugere på en gang i stedet for at kræve en ændring af hver agent.
Virksomhedsteams opretter i stigende grad flere agenter sammen i stedet for at opbygge enkelte monolithiske agenter, med en orkestreringsagent, der opdelegerer en anmodning og uddelegerer til specialunderagenter, eller specialagenter, der videregiver til hinanden, når en samtale flyttes på tværs af domæner. Denne sammensætning rejser ressource- og omkostningsspørgsmål ud over, hvad en enkelt agent står over for, fordi orkestrering overhead, inter-agent Trust, og staten handoff alle sammensatte på tværs af en kæde i stedet for at blive begrænset til en handling. Hold orkestreringsmeddelelser smalle, begrænset til at klassificere hensigt og distribution, snarere end at bede orkestrereren om også at begrunde den underliggende opgave, da denne begrundelse hører til underagenten med den relevante kontekst og hættekædedybden, medmindre en anvendelsessituation tydeligt kræver dybere indlejring end orkestrator-til-underagent. Behandl hvert underagentsvar som usikret input på samme måde som et eksternt API-svar. Valider dens forventede form og overholdelse af forretningsregler, før du reagerer på den. Håndhæv sikkerhed på feltniveau og deling uafhængigt for hver agenthandling.
Videregiv kun den tilstand, som den modtagende agent har brug for, ved brug af en struktureret overførselsdataadgang af registrerings-id’er, opgavesammendrag og relevante felter i stedet for at videresende rå samtalehistorik, så tokenbudgetten på tværs af kæden forbliver kontrolleret og bevarer krydsagent-sessionstilstand i Data 360 eller et tilpasset objekt, når en overførsel skal overleve på tværs af separate transaktioner. Styringsbegrænsninger gælder pr. agent, ikke en gang pr. samtale, så hver agent i en kæde trækker sit eget SOQL-, DML- og CPU-budget. En kæde af en orkestrator og tre underagenter forbruger hver af disse grænser fire gange, og dybere kæder gange forbruget yderligere. Den samme gang styrer omkostninger, hvilket gør ubegrænset kædedybde mere til en omkostningsrisiko end en styringsbegrænsning.
Definer, hvad orkestrator skal gøre, når en underagent mislykkes, udløber eller returnerer et lavt konfidensresultat, uanset om det er et begrænset forsøg, et tilbagerulningssvar eller eskalering til et menneske, så en enkelt underagenttimeout ikke overlapper hele kæden. Korreler en anmodning på tværs af hver agent, den rører ved, med et delt sporings-id, der udbredes gennem overførselsdataene, da diagnose af, hvilken agent i en kæde der forårsagede en forsinkelsespik eller en omkostningspik, ellers kræver manuel korrelation af logfiler på tværs af separate agentsessioner.
Mislykkede handlinger og mislykkede underordnede agentkald påvirker ikke kun pålideligheden, fordi hvert forsøg kan genkøre det SOQL-, DML- og CPU-arbejde, der allerede er brugt på det mislykkede forsøg, og i en kæde med flere agenter sammenføjes denne omkostning med antallet af mislykkede downstream-agenter. Under forbrugsbaseret prissætning bruges de samme fejlforbindelser samt beregnes: en genprøvet handling forbruger kreditter under Flex Credits. Design forsøgslogik for at tage højde for både pålidelighed og omkostninger. Adskil midlertidige fejl, f.eks. et udkaldstimeout eller en låseafstemning, fra logiske fejl, f.eks. en valideringsfejl eller et forkert udformet input, før du beslutter, hvordan du skal reagere, da en midlertidig fejl kan være værd et begrænset forsøg, mens en logisk fejl mislykkes identisk ved gentagelse og kun brænder budget for en garanteret gentaget fejl, der i stedet skal eskalere med det samme.
Cap forsøger igen pr. handling ved to eller tre forsøg og anvender eksponentiel tilbagekaldelse mellem dem i stedet for øjeblikkelig genkaldelse, fordi en ubegrænset eller tætkoblet forsøg på en SOQL- eller DML-hård handling kan udtømme synkrone grænser i en enkelt transaktion eller brænde gennem akkumuleret kædebudget og akkumuleret kreditforbrug på tværs af en samtale med flere agenter. Design handlinger, så et genforsøgt opkald producerer den samme sluttilstand som et enkelt vellykket opkald ved brug af en idempotensnøgle, f.eks. et anmodnings-id eller et eksternt id med upsert-logik i stedet for indsættelse, så et genforsøg opdaterer den samme registrering i stedet for at oprette en dublet. En handling, der mangler idempotens, tvinger et genforsøg til enten at fordoble ressourceforbruget gennem dublet downstream-registreringer eller at fordoble de fakturerede handlinger eller samtaler for arbejde, der allerede er sket en gang.
Spor fuldførelsestilstand pr. agent i en kæde, da en agents handling kan bekræfte DML, før en downstream-agent mislykkes, og en fejlhåndtering, der ved, hvad der allerede er lykkedes, kan kompensere eller genoptage fra fejlpunktet i stedet for at genstarte og genfakturere hele kæden. Vis slutbrugeren statussen på forsøg eller igangværende status, mens et begrænset forsøg er i gang, fordi en bruger, der ser stilhed og gentager sin anmodning, udløser en helt ny samtale og et nyt sæt handlinger, hvilket forværrer ressource- og faktureringsomkostningerne for det oprindelige forsøg med et dubletforsøg.
De ressourceoptimeringsmønstre, der er beskrevet i dette dokument, hjælper kun, hvis en arkitekt kan se, hvor en agent faktisk bruger SOQL-forespørgsler, CPU-tid, DML-rækker og tokener, når den kører i produktion. Uden synlighed pr. handling og pr. session vises et grænseafbrydelse eller en forsinkelsesregression som et symptom uden nogen måde at spore den tilbage til handlingen eller agenten i den kæde, der forårsagede den. Denne bekymring adskiller sig fra den synlighed af udgifter, som Digital Wallet giver under Cost Monitoring and Financial Governance. Digital Wallet viser, hvor mange kreditter eller samtaler en agent brugte, mens værktøjerne viser, hvorfor de blev forbrugt, på niveauet af den individuelle forespørgsel, DML-række eller handling, der drev dette forbrug. Det rigtige værktøj afhænger af, hvad en given kundes organisation og supportaftale faktisk tildeler, ikke på, hvilket værktøj der teoretisk er bedst, så match anbefalingen til din licens og adgangsniveau i stedet for som standard til det mest tilgængelige værktøj.
Enhver arkitekt kan opbygge tilpassede platformsbegivenheder, der udløses ved starten og slutningen af hver handling og underagentkald. Disse begivenheder sporer kørsel på tværs af en samtale ved brug af intet andet end standardplatformsfunktioner, parret med logføring på handlingsniveau til et tilpasset objekt, der registrerer SOQL-forespørgselsantal, CPU-tid, DML-rækkeantal og heap-anvendelse, når hver handling udføres. Begge begivenheder kan forespørges på via rapporter eller SOQL og giver hver organisation en basisdiagnosefunktion, uanset version eller tilføjelsesprogramlicens. Begivenhedsovervågning, der blev introduceret tidligere til sporing af API-forbrug under pilotprogrammer, viser også aggregerede ressourceanvendelsesmønstre på tværs af agentsessioner i hele organisationen for kunder, hvis organisation inkluderer dette tilføjelsesprogram, hvilket giver en arkitekt mulighed for at identificere, hvilke arbejdsflows der udvikler tendenser mod styringsbegrænsninger på tværs af mange samtaler i stedet for at diagnosticere en ad gangen. Skaleringscenter tilbyder dybtsporing af transaktioner, der nærmer sig styringsbegrænsninger, der typisk åbnes via et supportengagement eller er tilgængeligt direkte på kontoniveauer, der tildeler det.
Versionering af agenter uafhængigt gør kontrolleret udrulning, tilbagerulning og sammenligning mulig, og det beskytter investeringen i en arbejdsagent, mens du forbedrer den. Styr adfærden gennem konfigurationen, hvor det er muligt, ved hjælp af Tilpassede metadatatyper og Promptkonstruktør, så administratorer justerer meddelelsesskabeloner og handlingsvalg uden en udviklingscyklus. Brug pilotfunktionen A/B-test til at distribuere et lille undersæt af brugere til en eksperimentel version. Sammenlign kvalitet, tilfredshed og opgavefuldførelse før en fuld udrulning. Denne sammenligning validerer forbedringer med reel anvendelse og registrerer regressioner, mens eksponeringen er begrænset. Definer tydelige grænsefladekontrakter mellem komponenter, der angiver input, output, fejl og ydeevneforventninger, så en implementering kan erstattes uden at redigere de agenter, der er afhængige af den.
Agentøkonomi starter med den samlede ejeromkostning målt i forhold til forretningsværdien, men forbrugsbaseret prissætning for autonome agenter får omkostningssiden til at optræde på en måde, som traditionel licensering ikke gør. Den prissætningsmodel, du vælger, er en grundlæggende arkitektonisk beslutning, fordi den bestemmer, hvad du optimerer for på tværs af hele agentlivscyklussen. Dette afsnit etablerer prissætningsmodellerne, det fulde TCO-billede for en agentimplementering og beslutningen om at bygge kontra købe for agentfunktioner.
Agentforce tilbyder to forbrugsbaserede prissætningsmodeller, og en organisation vælger en af de to til en given agentimplementering. Flex Credits-pris pr. agent-handling, hvilket gør handlingseffektivitet til spidsen for omkostningskontrol. Prissætning pr. samtale opkræver et fladt gebyr pr. samtale, uanset længde eller kompleksitet, hvilket gør samtalebegrænsning til håndtaget. Pr. bruger-abonnementer leverer ikke-målt agentanvendelse som et medarbejderorienteret tilføjelsesprogram i stedet for en tredje forbrugsmodel, og de skifter optimeringsfokus fra forbrugseffektivitet til ibrugtagning, fordi værdien kommer fra licenserede brugere, der aktivt engagerer agenten i stedet for fra at minimere hver interaktion. De to forbrugsmodeller er ikke blandede for den samme organisation, men et Pr. bruger-tilføjelsesprogram, der tilbydes pr. bruger pr. måned for ikke-målt brug, kan lagres sammen med en forbrugsmodel, så kundeorienterede agenter kører på Flex Credits eller Pr. samtale, mens medarbejdere bruger ikke-målte licenser.
Under Flex Credits (Flekskreditter) er handlingsomkostninger faste pr. handling op til et defineret tokenloft. I modsætning til tokenbaseret inference-prissætning varierer kreditomkostningerne ikke med meddelelseslængde eller modelkompleksitet, så et svar med en sætning og et svar med flere afsnit koster det samme. En flerhandlingsinteraktion forbruger kreditter for hver handling, så en interaktion, der henter data, årsager og opdaterer en registrering, forbruger kreditterne for tre handlinger, og hentningsforøgede generering tilføjer yderligere handlinger gennem vektorsøgning og dokument hentning før argumentation. Forståelse af det gennemsnitlige antal handlinger pr. forretningstransaktion er derfor forudsætningen for omkostningsmodellering under Flex Credits.
Under Prissætning pr. samtale gælder et fladt gebyr pr. samtale, og flere vagter i en session tæller som en enkelt samtale, så omkostningskontrol kommer fra at løse et problem i en samtale og definere tydelige sessionsgrænser i stedet for fra at beskære individuelle handlinger. Data 360-landestandard og MuleSoft-integration forbruger deres egen kapacitet sammen med den valgte model, da integrering af generering og lighedssøgning nedtrækker databehandlingskapacitet for hver landestandardforespørgsel, og hver ekstern handling forbruger API-kapacitet i både kilde- og målsystemer.
Samlet omkostning for ejerskab (TCO) for en agentimplementering strækker sig over seks kategorier, og modellering af alle seks omdanner et kreditestimat til en informeret investeringsbeslutning. Udviklingsomkostningerne dækker agentdesign, prompt engineering, integrationsudvikling og test, og de spænder bredt fra en enkel enkelt-formål agent til et multi-agent system med kompleks orkestrering. Indledningsomkostninger afhænger af den valgte prissætningsmodel og kræver modellering af forventede handlingsmængder under Flex-kreditter, samtalemængder under Pr. samtale eller licenserede brugerantal under Pr. bruger. For agenter, der er baseret på store Knowledge, kan den Data 360-infrastruktur, der styrker basering, konkurrere med eller overstige udledningsomkostningerne. Infrastrukturomkostninger dækker Data 360- og MuleSoft-licensen, yderligere sandboxes og overvågningsinfrastruktur, og de er overvejende faste eller trinvise baseret på kapacitetsniveauer. Driftsomkostningerne dækker overvågningsoperationer, hurtig justering, hændelsessvar og brugersupport, og for modne agentprogrammer svarer de sædvanligvis til en betydelig del af udviklingsomkostningerne årligt, hvilket er i overensstemmelse med de generelle branchemæssige benchmarks for AI-agenter snarere end et Salesforce-specifikt tal. Forvaltningsomkostningerne dækker sikkerhedsgennemgang, menneskelig tilsyn, revisionsregistrering og validering af overensstemmelse, som vokser med agentens selvstændighed og risiko. Ændringsomkostninger dækker brugeruddannelse, tilpasning af forretningsprocesser og organisationsændringsstyring, og de er de kategoriteams, der oftest undervurderes.
Opbyg regnearks-TCO-modeller, der projicerer 3-5 års omkostninger. Dokumentforudsætninger for interaktionsvolumen, handlingsantal og vækst. Kør følsomhedsanalyser for at identificere de antagelser, der påvirker totalen mest, og fokuser derefter validering på disse antagelser. Model alle tre omkostningsstrukturer, Flex Credits, Pr. samtale og Pr. bruger, op mod projiceret anvendelse, før bekræftelse, fordi den optimale struktur afhænger af anvendelsesmønsteret, og det forkerte valg er dyrt at frigøre, når en agent er i produktion.
Beslutningen om at bygge kontra købe for agenter følger den samme logik som for enhver Salesforce-funktionalitet og vejer den øjeblikkelige tid til værdi af en klargjort løsning op mod den præcise tilpasning af en tilpasset bygning over en 3-5-årig TCO-horisont. Arbejdsflows for råvarer foretrækker køb, mens de kernefunktioner, der styrer beskyttet differentiering, retfærdiggør opbygning. Agent Enterprise tilbyder en række muligheder frem for et binært valg. Forhåndsbyggede Agentforce, f.eks. en serviceagent eller en salgsudviklingsrepræsentant, leverer gennemprøvet funktionalitet med hurtig implementering og platformsvedligeholdte opdateringer. De forbruger kreditter under den valgte prismodel. Kommersielt tilgængelige agenter fra Salesforce ISV-fællesskabet (Independent Software Vendor) tilbydes gennem AgentExchange, hvor du kan finde en løsning, der allerede opfylder et krav i stedet for at opbygge det. Tilpassede agenter, der er opbygget med Agentkonstruktør, giver præcis tilpasning og konkurrencedygtig differentiering på bekostning af forhåndsudvikling plus igangværende hurtig justering og vedligeholdelse. Tilpasning af en agent, der er bygget på forhånd, gennem Promptkonstruktør og handlingskonfiguration giver en midtvej, der koster mindre end fuld tilpasset udvikling, mens du stadig tilpasser agenten til din organisation. Udover omkostninger kan du veje tid-til-værdi-krav, intern udviklingsfunktionalitet, strategisk differentiering og leverandørafhængighedstolerance og registrere beslutningen i en arkitektonisk beslutningsregistrering, så den kan genevalueres, når kravene ændres.
Implementering af agenter med en tydelig forståelse af den underliggende omkostningsstruktur gør autonom kapacitetsskala bæredygtig i stedet for at udnytte en budgetpulje. Optimeringshæmmen afhænger af prissætningsmodellen, fordi det, du justerer for at kontrollere omkostninger, er forskelligt mellem betaling pr. handling, betaling pr. samtale og betaling pr. bruger. Princippet er konstant på tværs af alle tre: justere forbruget i forhold til den faktisk leverede værdi, så en kompetent agent ikke i stilhed brænder sit budget hurtigere, end det returnerer forretningsresultatet.
Under Flex Credits (Flekskreditter) betyder optimering, at du minimerer handlingerne pr. forretningsresultat, mens du bevarer kvaliteten. Løs enkle anmodninger i en enkelt handling i stedet for et arbejdsflow med flere trin, så besvarelse af et ofte stillet spørgsmål eller udførelse af et rutinemæssigt opslag ikke forbruger kreditterne i en kæde med tre handlinger. Konsolider handlinger i en enkelt handling, hvor det giver mening, ved at kombinere hentning, analyse og svar i stedet for at betale for hver separat, når der skal bruges en handling. Sæt svar i cache for gentagne anmodninger, så ofte stillede spørgsmål vises fra cache i stedet for at forbruge nye handlinger på hver identisk forespørgsel, hvilket er den eneste største effektivitetshæftning under denne model, når en meningsfuld del af forespørgsler gentages.
Under Prissætning pr. samtale betyder optimering at løse problemer i en enkelt samtale snarere end på tværs af flere. Design sessionsgrænser og timeouts, så en samtale fortsætter korrekt uden at afslutte for tidligt og tvinge en ny samtale, der kan faktureres. Fokuser agentfunktionalitet på løsning af første samtale, så en opgave fuldføres i den indledende samtale i stedet for at kræve en opfølgning. Spor hastigheden for løsning af første samtale som en omkostningseffektiv metrik, og undgå udvidelse af omfanget, hvor en bruger åbner separate samtaler for relaterede problemer, som den eksisterende samtalekontekst kunne have håndteret.
Under Pr. bruger-abonnementer betyder optimering maksimering af den værdi, som hver licenseret bruger returnerer, fordi forbruget ikke måles, og omkostningerne er faste pr. plads. Fokuser på ibrugtagning, så licenserede brugere aktivt engagerer agenten, sporer anvendelse for at identificere brugere med lav anvendelse til målrettet uddannelse eller omtildeling af licenser og tilslutter agentinteraktioner til forretningsresultater efter brugerpopulation, så anvendelsessituationer med høj værdi justerer investeringen, mens anvendelse med lav værdi signalerer et behov for optimering eller en anden prissætningsmodel. Gennemse brugerudfyldninger på en kadence, så licenser forbliver i overensstemmelse med faktisk anvendelse.
Uanset prissætningsmodellen påvirker arkitektur omkostninger. Implementer sorteringsagenter, der håndterer indledende distribution med enkel logik og dirigerer kun brugere til en specialiseret agent, når kompleksiteten kræver det, så dyre komplekse kald kun sker, når de er berettiget. Vend tilbage til traditionel automatisering for deterministiske scenarier, hvor regelbaseret logik er tilstrækkelig, og lad forløb håndtere deterministiske stier til en lavere pris, mens agenter håndterer tvetydige situationer, der virkelig har brug for begrundelse. Hent landingsdata selektivt ved kun at kalde vektorsøgning og dokument hentning, når agentens argumentation kræver det, snarere end på hver interaktion, så Data 360-forbrug sporer reelt behov. Disse mønstre bevarer argumenterings- og forbrugsomkostningerne for arkitekturen i forhold til arbejdets sværhedsgrad.
Overvågning af omkostninger for autonome agenter er vanskeligere end for traditionelle arbejdsbelastninger, da agenter ikke følger et forudsigeligt anmodnings-svarmønster. En agent kan gentage gennem flertrinsjustering, adaptivt kalde værktøjer baseret på kørselsbetingelser og koordinere andre agenter, hvilket producerer meget variabel kreditforbrug, der er vanskeligt at prognosticere. Uden overvågning kan en agent, der udfører dybt iterativt arbejde, forbruge en stor mængde kreditter, før nogen griber ind, og ineffektivt meddelelsesdesign eller overflødige ræsonnementsløkker kan roligt aflede budgetter på tværs af en hel agentflåde. Effektiv styring kræver derfor synlighed i realtid i forbrug pr. agent og pr. handling, automatiseret advarsel og kontrolelementer, der forhindrer løbende omkostninger, mens de bevarer den autonomi, der gør agenter nyttige. Økonomisk styring for agenter skal også have tydelig ejerskab og niveaugodkendelse, der er bygget til variabelforbrug snarere end til statiske beregningsomkostninger.
Salesforce Digital Wallet er det indbyggede værktøj til overvågning af forbrugsbaserede produkter, herunder Agentforce Flex Credits, og organisationer, der bruger Flex Credits, bør etablere det som den primære omkostningsovervågningsmekanisme i stedet for at opbygge tilpassede dashboards til at kopiere det, det leverer. Digital Wallet leverer forbrugsdata i næsten realtid med indsigt i brug på handlingsniveau, en opdeling pr. agent, der viser, hvilke agenter der forbruger mest, proaktive forbrugsalarmer og historiske tendenser for mønsteranalyse og prognosticering. Match overvågningen med prismodellen. Under Flex Credits kan du spore forbrug efter agent, brugerpopulation, tidsperiode og handlingstype og supplere Digital Wallet med tilpassede dashboards, der forbinder kreditforbrug med forretningstransaktioner. Under Prissætning pr. samtale kan du overvåge samtalemængder, gennemsnitlig længde og fuldførelsesfrekvenser. Under Pr. bruger-abonnementer skal du overvåge anvendelse i stedet for forbrug, spore aktive brugere og forretningsværdi pr. bruger, så licensinvesteringen vises til at levere proportionel værdi.
Pr. interaktionsomkostningstilskrivning forbinder forbruget med forretningstransaktioner og afslører omkostningerne pr. løst sag, pr. kvalificeret emne eller pr. behandlet bestilling, hvilket aktiverer beregning af investeringsafkast og sammenligning af krydssager. Budgetadvarsel udløser advisering, når forbruget nærmer sig definerede tærskler ved tærskler som 70 % og 85 % af budgettet, så optimering sker, før en grænse nås. Konfigurer advarsler pr. agent og pr. anvendelsessituation i stedet for kun for hele organisationen for at lokalisere et problem til dets kilde. Afvigelsesregistrering viser den pludselige forbrugsspids, der signalerer et uventet anvendelsesmønster eller en grundlæggende løkke, der skal undersøges. Del omkostningsdashboards med forretningsinteressenter og tekniske team, så gennemsigtighed styrer omkostningsbevidst agentanvendelse.
Anvend økonomisk styring, før du forpligter dig til at bruge på en agentarkitektur. Kræv en forretningssituation for en agentinvestering, der dækker projekteret TCO over 3-5 år under den valgte prissætningsmodel, de forventede forretningsresultater med en målemetode, en sammenligning med alternativer, herunder manuelle processer og traditionel automatisering, og en risikovurdering, der dækker kvalitet, sikkerhed og driftsmæssig risiko. Definer godkendelsestærskler, der adskiller de investeringer, som en afdeling kan godkende, fra dem, der kræver ledelsesgodkendelse, så en agent med høj investering eller høj risiko modtager proportionel gennemgang. Bestill pilotimplementeringer, der validerer antagelser før fuld produktion, fordi et pilotprogram afslører det faktiske forbrug, kvalitet og ibrugtagning, der informerer både produktionsinvesteringsbeslutningen og valg af prissætningsmodel.
Administrer agentens ejendom som en portefølje snarere end agent efter agent, fordi en porteføljevisning afslører optimeringssalgsmuligheder, som en enkelt agent-gennemgang går glip af. Gennemse alle agenter sammen, sammenlign omkostninger, anvendelse, forretningsværdi og strategisk justering, og definer solnedgangskriterier, der trækker agenter tilbage med lav indføring, dårlig investeringsafkast, overskredet funktionalitet eller overdreven omkostninger, så agenter med lav værdi ikke akkumulerer og forbruger budget uendeligt. Gentildel investeringer fra agenter med lav effektivitet til salgsmuligheder med høj værdi som en kontinuerlig fremgangsmåde, der justerer forbruget med udviklende prioriteter i stedet for en engangsoprydning.
Tildeling af omkostninger skaber ansvarlighed for agentforbrug, og organisationer implementerer det gennem de samme to modeller, der gælder for resten af platformen. Visningsrapporter om agentomkostninger efter forretningsenhed uden et internt gebyr, hvilket skaber omkostningsbevidsthed og informerer optimeringsdiskussion uden tvisten om intern fakturering. Chargeback tildeler faktiske agentomkostninger til de forbrugende forretningsenheder, hvilket styrker optimeringsadfærden, fordi omkostningerne påvirker et afdelingsbudget direkte, men det kræver en nøjagtig tildelingsmetode for at undgå tvister. En hybrid tilgang anvender tilbagebetaling til højvolumen produktionsagenter, mens den bruger tilbagevenden til eksperimentelle eller lavvolumen agenter, hvilket afbalancerer ansvarlighed for større investeringer mod fleksibilitet for innovation.
Agentarkitekturer introducerer deres egne bæredygtighedsovervejelser, fordi afledning af store sprogmodeller er beregningsintensiv, og nogle agenter kører kontinuerligt snarere end kun i diskrete brugerudløste transaktioner. Proaktive, udgående og planlagte agenter fungerer uden en bruger i løkken, samtaleagenter akkumulerer forbrug på tværs af mange vagter, og vektorsøgning, kontekstforberedelse og handlingskørsel føjer alle til infrastrukturindlæsningen. Bæredygtigt agentdesign minimerer beregningsspild, mens oplevelsen bliver responsiv. Som i søjlen Ressource- og omkostningsoptimering er relationen mellem en løsning og datacenteremissioner indirekte. En enkelt lejers effektivitet reducerer ikke direkte emissioner. Men effektivitetsforøgelser på tværs af alle lejere hjælper Salesforce med at køre sin infrastruktur ved højere anvendelse og udsætte kapacitetsudvidelse. og de grundlæggende bæredygtighedspraksisser fra søjlen Ressourceoptimering og Omkostningsoptimering gælder for agenter, og de effektivitetsstrategier, der følger, håndterer begge, hvad der er specifikt for samtalestyrede systemer med store sprogmodeller. Hver af dem reducerer også omkostninger, hvilket er grunden til, at bæredygtighed og værdi-pr.-omkostning er den samme disciplin målt op mod forskellige resultater.
Indledning er den mest ressourceintensive komponent i en agentarkitektur, så effektivitet betaler sig med meddelelseslængde, kontekstanvendelse og cachelagring. Optimer meddelelser for at videregive hensigter i færre tokener ved at fjerne uklare instruktioner og overflødige eksempler, fordi en kortere meddelelse reducerer beregningen af forhåndsudfyldning proportionelt, selvom det ikke ændrer beregningen af generering af svaret. Administrer kontekstvinduet ved at opsummere samtalehistorikken efter de første flere omgange og kun returnere vigtige felter fra hver handling, så det tokenbudget, der overføres til hver afslutning, forbliver begrænset i stedet for at vokse med samtalen.
Vektorsøgning og forenede profilforespørgsler forbruger beregningsressourcer, så den samme resultatgrænse og filtreringsdisciplin, der kontrollerer landestandardomkostninger, reducerer også infrastrukturbelastningen ved landestandard. Angiv top-k-grænser til kun at returnere de resultater, som agenten bruger, fordi hentning af 50, når 5 informerer svaret, medfører 45 ubrugte resultater, der forbruger jordstokenbudget uden nogen fordel, og bruger metadatafiltre til at indsnævre søgningen før lighedssangering. Forespørg på forenede profiler for at samle fuldstændig kontekst i en handling i stedet for at udstede separate forespørgsler mod flere objekter for hver drejning og cachelagre profiler for agenter med høj brugerafhængighed, f.eks. en salgsagent, der arbejder med et fast sæt af konti, så gentaget kontekstsamling ikke gentager forespørgslen.
Agenthandlinger forbruger SOQL-forespørgsler, DML-handlinger og CPU-tid, så massebehandling, cachelagring og asynkron disciplin i søjlen Ressource- og omkostningsoptimering gælder direkte for agenthandlinger. Design handlinger til at acceptere samlinger, så opdatering af mange registreringer er en handling snarere end mange, brug relationsforespørgsler til at hente overordnede og underordnede data i en enkelt erklæring, cachelagre referencedata i platformscache og batch DML på tværs af en samling i stedet for pr. registrering. Flyt handlinger, der overskrider synkrone grænser, til Kø- eller Batch Apex, behandl ikke-urgent arbejde som massescoring eller historisk berigelse asynkront, og planlæg agentudløste batchjob for vinduer uden for spidsbelastning, hvor det er muligt, så belastningen spredes på tværs af tiden i stedet for at koncentrere sig i arbejdstiden. Overvåg asynkron kørsel, så en køforsinkelse signalerer et behov for kapacitetsplanlægning, før det bliver en fejl.
Agentforbrugsmønstre udvikles, efterhånden som anvendelsen vokser, så bæredygtighed kræver løbende overvågning snarere end et engangsgennemgang. Spor de gennemsnitlige tokener pr. afledning gennem den tilgængelige anvendelsestelemetri, så en stigende meddelelsesstørrelse viser en optimeringsmulighed, overvåg samtale-længdefordeling, så ubegrænsede samtaler afslører et opgavegrænseproblem, og analyser handlingsudførelsesfrekvens i Begivenhedsovervågning, så en højfrekvent handling bliver en optimeringsprioritet. Gennemse Data 360-forespørgselsmønstre for at finde almindelige forespørgsler, der er værd at cachelagre eller forberede, spor den semantiske cachelagringshitfrekvens, så en lav hastighed udløser tærskeljustering, og mål forsinkelsespercentiler, så haleforsinkelse viser eventuelle flaskehalse. Gennemse agentanvendelse regelmæssigt for omfangsforskydning. Undersøg f.eks. en agent, hvis gennemsnitlige samtalelængde vokser fra en håndfuld omgange til mange over flere måneder. Juster agentens grænser, så forbruget vender tilbage til planen. Nogle af disse overvågningsoverflader viser brug i aggregerede dashboards i stedet for som en særskilt pr. afledning-log, så bekræft den nøjagtige telemetri, der er tilgængelig for din konfiguration, når du designer overvågningen.
Ressourceoptimering bestemmer, om agentarkitekturer skaleres, efterhånden som populationer vokser og anvendelsessituationer udvides, og omkostningsoptimering bestemmer, om denne skalering returnerer proportionel forretningsværdi. Disse to beslutninger udgør en enkelt mandat:
- Architektonisk effektivitet: designe handlinger med massebehandling, budgettere SOQL på tværs af handlingskæder, flytte tung behandling til asynkronisering, optimere API-forbrug gennem sammensatte og begivenhedsstyrede mønstre, administrere kontekstvinduer gennem prioritering og opsummering og opbygge sammensatte arkitekturer fra genanvendelige komponenter.
- Økonomisk vejledning: vælg prismodellen med vilje, model fuldfør TCO, før du bekræfter, overvåg forbrug op mod forretningsresultater og styr investeringer gennem niveaugodkendelse og porteføljegennemgang.
Organisationer, der overholder disse mønstre, leverer responsive agentoplevelser inden for platformsbegrænsninger, mens de holder forbruget i overensstemmelse med den værdi, som agenterne returnerer.
Vejledningen for grundlæggende ressource- og omkostningsoptimering for alle Salesforce-løsninger, herunder optimering af ydeevne, styringsbegrænsninger, TCO-analyse, licensdisciplin og omkostningsstyring, findes i søjlen Ressource- og omkostningsoptimering. Komponenterne agentstyring, menneskelig tilsyn og sikkerhedsprogram er forbundet med søjlerne Trust og Fairness. Den detaljerede vejledning til agentimplementering i dette dokument, der strækker sig over ressourceeffektivitet, økonomi, handlingsoptimering, styring og bæredygtighed, indsamles i agentmønsterbiblioteket.