Resurs- och kostnadsoptimering för agentföretaget
Autonoma agenter använder Salesforce-resurser annorlunda än deterministisk automatisering. Agenters arbetsbelastningar är oförutsägbara och kontinuerliga, snarare än fasta och transaktionsbundna. Avhandlingen om värde per kostnad för pelaren Resurs- och kostnadsoptimering förs direkt till Agentföretaget. Resurseffektivitet innebär att använda den kapacitet du redan betalar för, och kostnadsoptimering innebär att medvetet styra utgifter mot de autonoma kapaciteter som ger avkastning. Agenter ändrar formen på båda. Effektiv agentdesign håller konsumtionen i schack, och val av prissättningsmodell, modeller för total ägandekostnad (TCO) och ekonomisk styrning håller utgifterna i linje med värdet. Detta dokument behandlar resurseffektivitet och kostnadsoptimering som ett beslut, eftersom agenter har två vyer av samma mål.
Agenter ändrar förutsägbarheten för konsumtion. En traditionell Apex process fungerar på en känd postuppsättning med en känd resurskostnad. En agent arbetar konversationsvis och en enskild konversation kan utföra dussintals åtgärder som agenten resonerar igenom en uppgift. Varje åtgärd konsumerar styrande begränsningar i sin egen transaktion istället för att ackumulera dem i hela konversationen. Sammanhangsförberedelse för ett varv kan fråga 200 poster eller 20 000, beroende på vad användaren frågar. API-användning accelererar eftersom agenter kan agera autonomt och proaktiva, utgående och schemalagda agenter agerar kontinuerligt istället för endast under en användartransaktion. Denna oförutsägbarhet är anledningen till att agentresurshantering måste vara defensiv genom design snarare än finjusterad efter att en konsumtionsökning inträffar.
Kostnadssidan ändras lika mycket. Autonoma agenter introducerar konsumtionsbaserad prissättning som beter sig annorlunda än traditionell licensiering per plats. Agentforce erbjuder två konsumtionsbaserade prissättningsmodeller, Flexkrediter och Per konversation. Varje agentdistribuering väljer en av dessa modeller. En organisation använder en användningsmodell åt gången. , men ett tillägg per användare, som erbjuds per användare per månad för obegränsad användning, kan läggas i lager bredvid en användningsmodell så att agenter som står inför kunder kör Flexkrediter eller Per konversation medan anställda använder licenser utan mätare. Data 360 driver agenters jordning genom vektorsökning och hämtning, och konsumerar databearbetningskapacitet, medan MuleSoft aktiverar agentintegreringar som konsumerar API-kapacitet. Dessa rörliga kostnader skalar med agentanvändning, vilket skapar ett investeringsmönster som behöver ekonomisk styrning byggd för variation snarare än för en fast årlig prenumeration.
Lösningar utformade för verksamhetsvärde med optimerade kostnader i Agentic Enterprise håller agentkonsumtion effektiv genom åtgärder som bearbetar poster i bunt, disciplinerade sammanhangsfönster och cachning. De styr också medvetet utgifterna genom rätt prissättningsmodell, fullständig TCO-modellering och kontinuerlig kostnadsövervakning mot verksamhetsresultaten. Utan denna anpassning ackumulerar agentdistribueringar kostnader utan att visa proportionellt värde, och en agent som resonerar i en obegränsad loop kan bränna krediter snabbare än mänsklig tillsyn kan ingripa. Samma effektivitetsarbete som håller en agent inom sina styrande gränser håller den inom sin kreditbudget, vilket är grundtesen uttryckt i agenttermer.
Detta dokument täcker vad som ändras när agenter är i bilden. För de grundläggande mönster för resurs- och kostnadsoptimering som gäller för varje Salesforce-lösning, inklusive prestandaoptimering, styrande gränser, TCO-analys och licensdisciplin, se pelaren Resurs- och kostnadsoptimering. Agentstyrning och mänsklig tillsyn ansluter till pelarna Trust och Rättvisa, som täcker programkomponenter som håller autonomt beteende säkert och ansvarigt.
Agentresursanvändning följer samma plattformsmekanism som flöde eller Apex, men dess oförutsägbara, konversationsdrivna åberopning gör användning svårare att prognostisera och kräver därför defensiva mönster. Dina optimeringsansvar sträcker sig över styrande budgetering över åtgärdskedjor, API-användning, svarslatens, Data 360-jordningseffektivitet, hantering av sammanhangsfönster och den sammansatta designen som låter agenter skala upp utan dubbletter. Varje ansvar är ett värde per kostnad-beslut innan det är tekniskt, eftersom agenter upprepar ineffektivitet i varje konversation.
Agenter åberopar åtgärder som utlöser Apex, flöden och integreringar. En enskild konversation kan utföra dussintals åtgärder som agenten resonerar kring genom en komplex uppgift. Den grundläggande disciplinen är densamma som för alla Salesforce-lösningar, men det oförutsägbara åberopningsmönstret ökar insatserna. Utforma åtgärder för att acceptera samlingar så att en agent som uppdaterar 50 kundcase åberopar en åtgärd istället för 50 separata samtal. En enskild åtgärd som arbetar med en samling poster konsumerar mycket färre SOQL-frågor (Salesforce Object Query Language) och DML-operationer (Data Manipulation Language) för samma arbete. Hantera SOQL-budgeten över åtgärdskedjor medvetet, eftersom ett arbetsflöde som åberopar 10 till 15 åtgärder kan närma sig eller överskrida den synkrona gränsen på 100 frågor när varje åtgärd kör flera egna frågor. Använd relationsfrågor för att hämta överordnade och underordnade data i ett enskilt uttalande, och referera till data cachade i plattformscache mellan åtgärder i samma konversation. Dessa två metoder håller en fleråtgärdskedja inom sin budget.
Flytta agentoperationer som överskrider synkrona gränser till Apex i kö eller batch, där det asynkrona sammanhanget ungefär fördubblar det SOQL- och CPU-utrymme som är tillgängligt för arbetet. Stora analytiska åtgärder, som att betygsätta 1 000 leads eller analysera känslor över historiska kundcase, hör hemma i asynkron bearbetning istället för att blockera en konversation. Själva härledningen till en stor språkmodell sker utanför Salesforce och konsumerar Flex Credits istället för Apex CPU-tid, så den CPU-budget du profilerar konsumeras av åtgärdslogiken, datatransformationer och de integreringar agenten utlöser. Dataförvrängningar där överordnade poster är associerade med tusentals underordnade poster förtjänar särskild defensiv uppmärksamhet med agenter. Denna sårbarhet uppstår eftersom en agent kan begära “all historik” för ett konto med tiotusentals relaterade poster på ett sätt som en deterministisk fråga aldrig skulle göra. Utforma åtgärder med hårda underordnade postgränser och paginering, och tillämpa sampling när volymer överskrider datatröskeln. Dessa gränser förhindrar att en oförutsägbar begäran förvandlas till en obegränsad sökfråga. Agentforce sessionsspårning identifierar vilka åtgärder som konsumerar överflödiga sökfrågor på sessionsnivå, och Skalcenter övervakar övergripande Apex transaktionsprestanda och organisationshälsa.
Agentarkitekturer konsumerar API snabbare än användardrivna arbetsflöden, eftersom agenter arbetar autonomt och, för proaktiva eller schemalagda agenter, kontinuerligt. Hur en agent visas avgör hur den drar ner API-kapacitet. Agenter som åberopas genom REST API konsumerar ett anrop per konversationsomgång. Agenter inbäddade i Lightning genom standardkomponenter konsumerar inte ett API-anrop per interaktion, men deras kostnad mäts fortfarande i krediterna eller konversationerna i den valda prissättningsmodellen. Egna Lightning som gör direkta REST-anrop konsumerar API-kapacitet. Komponenter byggda på Lightning Data Service-kabeladapters gör det inte, eftersom Lightning Data Service servar från en delad cache på klientsidan istället för att utfärda ett API-anrop. Övervaka användningen i händelseövervakning under en pilot så att du förstår den faktiska användningen innan en fullständig lansering.
Händelsedrivna mönster är den största hävstången för slösaktig agent-API-användning. Att publicera en plattformshändelse när ett villkor kräver agentingripande undviker den schemalagda omröstning som konsumerar API-anrop oavsett om det finns arbete att göra eller inte, och en agent som prenumererar på händelser för datainsamling behåller det aktuella sammanhanget utan de dagliga omröstningsanrop en extern orkestrerare annars skulle göra. Logiken värde per kostnad är direkt: En omröstning som inte hittar något arbete är kapacitet spenderad för ingenting, och en händelse som endast aktiveras för en verklig förändring är kapacitet spenderad endast på verkligt arbete. Skapande med utökad hämtning lägger till sin egen användning, eftersom varje vektorsökning mot Data 360 konsumerar beräkning, så ange hämtningsgränser för att endast returnera de resultat agenten faktiskt använder.
Latens för en agentvändning är summan av LLM-slutledningstid, åtgärdsutförandetid, Data 360-sökfrågetid och integreringstid när dessa steg körs i sekvens. Om de inte gör det är det den längsta parallella grenen plus eventuella sekventiella steg. Latens är både ett kostnadsproblem och ett upplevelseproblem, eftersom en långsam åtgärd håller resurser öppna längre och en frustrerad användare startar fler konversationer än en löst skulle. Kortare uppmaningar skapar snabbare svar, så ta bort ordagranna instruktioner, överflödiga exempel och onödigt sammanhang. Valfritt sammanhang förbättrar både latens och svarskvalitet, där en uttömmande sammanhangsdump endast lägger till brus. Håll åtgärder snabba genom selektiv SOQL för indexerade fält, buntning och cachade referensdata, eftersom en 3-sekundersåtgärd blir en flaskhals oavsett hur snabb härledning är. Validera åtgärdsfrågor med verktyget Frågeplan för att identifiera fullständiga tabellskanningar som ökar åtgärdslatensen.
Agentbyggarens orkestrering kan utföra åtgärder parallellt om det inte finns några beroenden mellan dem, till exempel att hämta kontodetaljer och relaterade säljprojekt samtidigt tar lika lång tid som den långsammare av de två istället för summan av båda. För samtal till flera system längre ner, para Agentforce med en integreringsplattform som MuleSoft. Agenten åberopar en enskild åtgärd, MuleSoft tar emot begäran och utfärdar parallella anrop till backendsystem och returnerar sedan ett aggregerat svar. Plattformscache tar bort slutsatser och sökfrågelatens för upprepade begäranden, och bearbetning av icke-brådskande arbete asynkront, som en lång dokumentanalys, låter agenten bekräfta begäran omedelbart och returnera resultatet när den är redo istället för att hålla konversationen öppen.
Data 360 tillhandahåller den vektorsökning som grundar agentsvar i aktuella data istället för i modellens utbildningsdata, och dess effektivitet styr både jordningskvaliteten och den beräkning du använder för att uppnå den. Uppdelning, inbäddat urval, metadatafiltrering och resultatgränser är de mest värdefulla besluten. Dela upp Knowledge i semantiskt meningsfulla segment, eftersom delar som är för små tvingar många hämtningar för en fråga medan delar som är för stora försvagar relevansen med irrelevant sammanhang och blåser upp tokenbudgeten. Välj en inbäddningsmodell som matchar hur dina agenter faktiskt frågar, eftersom likhet mellan fråga och svar beter sig annorlunda än dokumentklassificering, och validera valet mot representativa frågor. Kombinera semantisk likhet med metadatafilter så att verksamhetsbegränsningar gäller oavsett likhet, till exempel att utesluta produkter som upphört att gälla från en rekommendation oavsett hur nära matchningen är. Ange top-k-gränser för att endast returnera de resultat agenten använder. Till exempel, om 5 resultat informerar ett svar, lägger hämtning av 50 till 45 oanvända resultat i grundbelastningen och tokenbudgeten.
Sammanslagna profiler är resurseffektiva eftersom en agent som frågar en enhetlig Data 360-profil hämtar fullständigt kundsammanhang i en enda operation istället för att orkestrera separata frågor mot Konto, Kontakt, Säljprojekt, Kundcase och Kampanj för varje tur. Konfigurera Data 360-instanser i de regioner som lagstadgade krav kräver så att agenter som bearbetar data för en viss jurisdiktion frågar vilken instans som håller personuppgifter i den.
Sammanhangsfönster med stora språkmodeller håller ett begränsat antal tokens, och att hantera denna budget håller en lång konversation sammanhängande utan att uttömma kapaciteten eller öka kostnaden för varje inferenssamtal. Prioritera avsiktligt istället för att avkorta godtyckligt: senaste konversationshistorik tar högsta prioritet, viktiga verksamhetsdata som aktuell poststatus och behörigheter kommer i andra hand, och äldre historik inkluderas endast när utrymmet tillåter. Efter de första svängarna, sammanfatta tidigare konversationer i en koncis översikt som bevarar viktiga fakta utan att ha fullständig ordagrann historik. Denna sammanfattning bevarar kontinuiteten utan att öka tokenbudgeten. Lagra utökat sammanhang i Data 360 eller egna objekt som externt minne som frågas på begäran istället för att spela upp hela historiken i varje samtal och returnera endast de viktigaste fälten från varje åtgärd, eftersom ett svar som innehåller alla 50 fält i en post när uppgiften behöver 8 spenderar sammanhangsbudgeten bättre allokerad till konversation eller jordning.
Att bygga agenter från återanvändbara komponenter minskar utvecklings- och underhållskostnader. En kapacitet som byggts en gång och återanvänts är mycket billigare under sin livstid än samma kapacitet som återimplementerats och underhålls separat för varje agent. Centraliserade åtgärdsbibliotek som täcker postoperationer, godkännanden, notiser och validering låter plattformsteam upprätthålla ett enhetligt beteende, säkerhet och prestanda för varje konsumerande agent, och de låter en ny agent samlas från beprövade byggstenar på några dagar istället för att byggas från egna åtgärder under veckor. Fokuserade specialistagenter med tydliga domängränser upprätthåller smalare sammanhang och tydligare beteende än en enskild universalagent som försöker sig på varje scenario, och Agentbyggarens orkestrering koordinerar specialister när en uppgift korsar domäner. Validerade uppmaningsmallar i Promptbyggare samlar in beprövade mönster för grundning, resonemang och svarsformatering så att kvaliteten förblir enhetlig medan utvecklingen accelererar, och en delad Knowledge i Data 360 grundar många agenter från en källa, så att en uppdatering når varje konsument samtidigt istället för att kräva en ändring av varje agent.
Enterprise-team skapar i allt högre grad flera agenter tillsammans istället för att bygga enskilda monolitiska agenter, där en orkestreringsagent delar upp en begäran och delegerar till specialiserade underagenter, eller specialiserade agenter som lämnar över till varandra när en konversation rör sig över domäner. Denna sammansättning skapar frågor om resurser och kostnader utöver vad en enskild agent står inför, eftersom orkestrering, inter-agent Trust och överlämning av delstater är sammansatta i en kedja istället för att hållas inom en åtgärd. Håll orkestreringsuppmaningar smala, begränsade till att klassificera syfte och dirigering, istället för att be orkestreraren att även resonera kring den underliggande uppgiften, eftersom detta resonemang hör hemma i underagenten med relevant sammanhang, och kapsla kedjedjup om inte ett användningsfall tydligt kräver djupare kapsling än orkestrering-till-underagent. Behandla varje underagentsvar som opålitlig indata, som ett externt API-svar. Validera dess förväntade form och efterlevnad av verksamhetsregler innan du agerar efter den. Tillämpa fältnivåsäkerhet och delning oberoende för varje agentåtgärd.
Skicka endast det läge som den mottagande agenten behöver, med hjälp av en strukturerad överlämningsbelastning av post-ID:n, uppgiftssammanfattning och relevanta fält istället för att vidarebefordra rå konversationshistorik, så att tokenbudget över hela kedjan förblir kontrollerad och kvarstår som korsagentsession i Data 360 eller ett eget objekt när en överlämning måste överleva över separata transaktioner. Styrande gränser gäller per agent, inte en gång per konversation, så varje agent i en kedja drar sin egen SOQL-, DML- och CPU-budget. En kedja av en orkestrerare och tre underagenter konsumerar var och en av dessa gränser fyra gånger om, och djupare kedjor multiplicerar förbrukningen ytterligare. Samma multiplikation driver kostnaden, vilket gör obegränsat kedjedjup till en kostnadsrisk mer än en styrande gräns.
Definiera vad orkestreraren gör när en underagent misslyckas, löper ut eller returnerar ett resultat med låg förtroende, oavsett om det är ett begränsat återförsök, ett reservsvar eller omflyttning till en människa, så att en enskild underagenttimeout inte kasar till att misslyckas i hela kedjan. Korrelera en begäran över varje agent den berör med ett delat spårnings-ID som propageras genom överföringsbelastningen, eftersom diagnosen vilken agent i en kedja som orsakade en latensökning eller en kostnadsökning annars kräver manuell korrelering av loggar över separata agentsessioner.
Misslyckade åtgärder och misslyckade underordnade agentanrop påverkar inte bara pålitligheten, eftersom varje försök kan köra SOQL-, DML- och CPU-arbete som redan lagts på det misslyckade försöket igen, och i en kedja med flera agenter förvärras denna kostnad med antalet misslyckade agenter längre ner. Under konsumtionsbaserad prissättning spenderar och beräknar samma felföreningar: en prövad åtgärd återanvänder krediter under Flexkrediter. Utforma logik för att ta hänsyn till både pålitlighet och kostnad. Skilj mellan tillfälliga fel, som en timeout eller låskonflikt, och logiska fel, som ett valideringsfel eller en felaktig inmatning, innan du bestämmer hur du ska svara, eftersom ett tillfälligt fel kan vara värt ett begränsat försök igen medan ett logiskt fel misslyckas identiskt vid upprepning och endast bränner budgeten för ett garanterat upprepat fel som ska flyttas om direkt istället.
Begränsa försök till återförsök per åtgärd, till två eller tre försök, och tillämpa exponentiell backoff mellan dem istället för omedelbar återkallelse, eftersom ett obegränsat eller tätt återförsök på en SOQL- eller DML-tung åtgärd kan uttömma synkrona gränser inom en enskild transaktion eller bränna igenom kumulativ kedjebudget och kumulativa kreditutgifter över en konversation med flera agenter. Utforma åtgärder så att ett försökt samtal producerar samma slutläge som ett enskilt framgångsrikt samtal, med hjälp av en idempotensnyckel som ett begärande-ID eller externt ID med infoga logik istället för att infoga, så att ett nytt försök uppdaterar samma post istället för att skapa en dubblett. En åtgärd som inte är idempotens tvingar ett nytt försök att antingen fördubbla resursförbrukningen genom dubbletter av poster längre ner eller fördubbla de fakturerade åtgärderna eller konversationerna för arbete som redan skett en gång.
Följ slutförandestatus per agent i en kedja, eftersom en agents åtgärd kan utföra DML framgångsrikt innan en agent längre ner misslyckas, och en felhanterare som vet vad som redan lyckats kan kompensera eller återuppta från felpunkten istället för att starta om och återfakturera hela kedjan. Visa återförsök eller pågående status för slutanvändaren medan ett begränsat återförsök pågår, eftersom en användare som ser tystnad och upprepar sin begäran utlöser en helt ny konversation och en ny uppsättning åtgärder, vilket slår samman resurs- och faktureringskostnaden för det ursprungliga försöket med en dubblett.
De resursoptimeringsmönster som beskrivs i detta dokument hjälper endast om en arkitekt kan se var en agent faktiskt spenderar SOQL-frågor, CPU-tid, DML-rader och tokens när den körs i produktion. Utan synlighet per åtgärd och per session visas ett gränsbrott eller en latensregression som ett symptom utan något sätt att spåra det tillbaka till åtgärden eller agenten i kedjan som orsakade det. Denna oro skiljer sig från den utgiftssynlighet som Digital Wallet ger under Kostnadsövervakning och ekonomisk styrning. Digital Wallet visar hur många krediter eller konversationer en agent har använt, medan verktyget visar varför de användes, på nivån för den individuella sökfrågan, DML-raden eller åtgärden som drev denna användning. Vilket verktyg som är rätt beror på vad en kunds organisation och supportavtal faktiskt beviljar, inte på vilket verktyg som teoretiskt sett är bäst, så matcha rekommendationen till din licens och åtkomstnivå istället för att använda det mest kapabla verktyget som standard.
Alla arkitekter kan bygga egna plattformshändelser som aktiveras i början och slutet av varje åtgärd och underagentåberopning. Dessa händelser följer utförandet över en konversation med hjälp av endast standardplattformskapacitet, tillsammans med loggning på åtgärdsnivå till ett eget objekt som registrerar antal SOQL-frågor, CPU-tid, DML-radantal och heapanvändning när varje åtgärd utförs. Båda händelserna går att fråga via rapporter eller SOQL och ger varje organisation en grundläggande diagnostisk kapacitet oavsett version eller tilläggslicens. Händelseövervakning, som introducerades tidigare för att följa API-användning under piloter, lyfter även fram aggregerade resursanvändningsmönster över agentsessioner i hela organisationen för kunder vars organisation inkluderar detta tillägg, vilket låter en arkitekt identifiera vilka arbetsflöden som trendar mot styrande gränser i många konversationer istället för att diagnostisera ett åt gången. Skalcenter erbjuder djup spårning av transaktioner som närmar sig styrande gränser, vanligtvis tillgängliga genom ett supportengagemang eller direkt på kontonivåer som beviljar det.
Versionshantering av agenter oberoende gör kontrollerad lansering, återlansering och jämförelse möjlig, och det skyddar investeringen i en arbetande agent medan du förbättrar den. Driv beteendet genom konfigurationen där det är möjligt, med egna metadatatyper och Promptbyggaren så att administratörer kan justera uppmaningsmallar och åtgärdsval utan en utvecklingscykel. Använd pilotkapaciteten för A/B-test för att dirigera en liten undergrupp användare till en experimentell version. Jämför kvalitet, nöjdhet och uppgiftens slutförande innan en fullständig lansering. Denna jämförelse validerar förbättringar med verklig användning och upptäcker regressioner medan exponeringen är begränsad. Definiera tydliga gränssnittkontrakt mellan komponenter, specificera indata, utdata, fel och prestandaförväntningar, så att en implementering kan ersättas utan att ändra de agenter som är beroende av den.
Agentekonomi börjar med total ägandekostnad mätt mot verksamhetsvärde, men den konsumtionsbaserade prissättningen av autonoma agenter gör att kostnadssidan beter sig på ett sätt som traditionell licensiering inte gör. Den prissättningsmodell du väljer är ett grundläggande arkitektoniskt beslut, eftersom den avgör vad du optimerar för under agentens hela livscykel. Denna sektion etablerar prissättningsmodellerna, den fullständiga TCO-bilden för en agentimplementering och bygg-kontra-köp-beslutet för agentkapacitet.
Agentforce erbjuder två konsumtionsbaserade prissättningsmodeller och en organisation väljer en av de två för en given agentdistribuering. Flexkrediter pris per agentåtgärd, vilket gör åtgärdseffektivitet till en hävstång för kostnadskontroll. Prissättning per konversation tar ut en fast avgift per konversation oavsett längd eller komplexitet, vilket gör att konversationsbegränsning är en hävstång. Prenumerationer per användare ger obegränsad agentanvändning som ett tillägg för anställda istället för en tredje konsumtionsmodell, och de flyttar optimeringsfokus från konsumtionseffektivitet till användning, eftersom värdet kommer från licensierade användare som aktivt engagerar agenten istället för att minimera varje interaktion. De två konsumtionsmodellerna blandas inte för samma organisation, men ett tillägg per användare, som erbjuds per användare per månad för obegränsad användning, kan läggas i lager bredvid en konsumtionsmodell så att agenter som möter kunder kör Flexkrediter eller Per konversation medan anställda använder licenser utan mätare.
Under Flexkrediter är åtgärdskostnader fasta per åtgärd upp till ett definierat tokentak. Till skillnad från tokenbaserad slutledningsprissättning varierar inte kreditkostnaden beroende på uppmaningslängd eller modellkomplexitet, så ett svar med en mening och ett svar med flera stycken kostar lika mycket. En interaktion med flera åtgärder konsumerar krediter för varje åtgärd, så en interaktion som hämtar data, orsaker och uppdaterar en post konsumerar krediterna för tre åtgärder, och skapande med utökad hämtning lägger till ytterligare åtgärder genom vektorsökning och dokumenthämtning innan resonemang. Att förstå det genomsnittliga antalet åtgärder per affärstransaktion är därför en förutsättning för kostnadsmodellering under Flexkrediter.
Under prissättning per konversation gäller en fast avgift per konversation och flera omgångar inom en session räknas som en enskild konversation, så kostnadskontroll kommer från att lösa ett problem inom en konversation och definiera tydliga sessionsgränser istället för att trimma enskilda åtgärder. Data 360-jordning och MuleSoft-integrering konsumerar sin egen kapacitet tillsammans med den valda modellen, eftersom inbäddningsskapande och likhetssökning hämtar databearbetningskapacitet för varje jordad fråga och varje extern åtgärd konsumerar API-kapacitet i både käll- och målsystemen.
Total ägandekostnad (TCO) för en agentimplementering sträcker sig över sex kategorier, och modellering av alla sex förvandlar en kredituppskattning till ett välgrundat investeringsbeslut. Utvecklingskostnaderna täcker agentdesign, prompt engineering, integreringsutveckling och tester, och de sträcker sig från en enkel agent till ett system med flera agenter och komplex orkestrering. Slutsatsskostnader beror på den valda prismodellen och kräver modellering av förväntade åtgärdsvolymer under Flexkrediter, konversationsvolymer under Per konversation eller licensierade användarantal under Per användare. För agenter som är jordade i stora Knowledge kan Data 360-infrastrukturen som driver jordning konkurrera med eller överstiga slutledningskostnaden. Infrastrukturkostnaderna täcker licenserna Data 360 och MuleSoft, ytterligare sandboxar och övervakningsinfrastruktur, och de är huvudsakligen fasta eller stegvisa baserade på kapacitetsnivåer. Driftskostnaderna täcker övervakningsåtgärder, snabb förfining, incidenthantering och användarsupport, och för mogna agentprogram motsvarar de vanligtvis en meningsfull del av utvecklingskostnaden årligen, vilket överensstämmer med allmänna branschriktmärken för AI-agenter snarare än en Salesforce-specifik siffra. Styrningskostnaderna täcker säkerhetsgranskning, mänsklig tillsyn, granskningsloggning och validering av efterlevnad som växer med agenters självständighet och risk, och pelaren Rättvisa täcker de viktigaste programkomponenterna. Ändringskostnader täcker användarutbildning, anpassning av verksamhetsprocesser och hantering av organisatoriska förändringar, och de är den kategori team oftast underskattar.
Bygg kalkylblads-TCO-modeller som beräknar kostnader på 3-5 år. Dokumentera antaganden för interaktionsvolymer, åtgärdsantal och tillväxt. Kör känslighetsanalys för att identifiera de antaganden som påverkar totalsumman mest och fokusera sedan valideringen på dessa antaganden. Modellera alla tre kostnadsstrukturerna, Flexkrediter, Per konversation och Per användare, mot beräknad användning innan du åtar dig, eftersom den optimala strukturen beror på användningsmönstret och fel val är dyrt att varva ner när en agent är i produktion.
Beslutet att bygga mot att köpa för agenter följer samma logik som för alla Salesforce-kapaciteter och väger den omedelbara tiden till värde för en färdig lösning mot den exakta anpassningen av en egen byggnad över en 3–5-årig TCO-horisont. Varuflöden gynnar köp medan kärnkapaciteten som driver egen differentiering motiverar byggande. Agentföretag erbjuder ett spektrum av alternativ istället för ett binärt val. Färdigbyggda Agentforce, som en serviceagent eller en säljutvecklingsrepresentant, tillhandahåller beprövad funktionalitet med snabb distribuering och plattformsunderhållna uppdateringar. De använder krediter under den valda prissättningsmodellen. Kommersiellt tillgängliga agenter från Salesforce Independent Software Vendor-diskussionsgruppen (ISV) erbjuds via AgentExchange, där du kan hitta en lösning som redan uppfyller ett krav istället för att bygga den. Egna agenter byggda med Agent Builder ger exakt passform och konkurrenskraftig differentiering på bekostnad av utveckling i förväg plus kontinuerlig snabb förfining och underhåll. Att anpassa en färdigbyggd agent genom Promptbyggaren och åtgärdskonfiguration ger ett mellanting som kostar mindre än fullständig egen utveckling samtidigt som agenten fortfarande anpassas till din organisation. Utöver kostnad, väg tid till värde-krav, intern utvecklingskapacitet, strategisk differentiering och leverantörsberoendetolerans, och registrera beslutet i en beslutspost för arkitektur så att det kan omvärderas när kraven ändras.
Att implementera agenter med en tydlig förståelse av den underliggande kostnadsstrukturen gör att autonom kapacitet skalas upp hållbart istället för att ta slut på en budgetpool. Optimeringsspaken beror på prissättningsmodellen, eftersom det du justerar för att styra kostnaden skiljer sig åt mellan att betala per åtgärd, betala per konversation och betala per användare. Principen är konstant över alla tre: avstäm förbrukningen mot det faktiskt levererade värdet så att en kompetent agent inte bränner sin budget snabbare än den returnerar verksamhetsresultatet.
Under Flexkrediter innebär optimering att minimera åtgärderna per verksamhetsresultat samtidigt som kvaliteten bibehålls. Lös enkla begäranden i en enskild åtgärd istället för ett arbetsflöde i flera steg, så att svar på vanliga frågor eller utföra en rutinsökning inte konsumerar krediterna i en treåtgärdskedja. Slå samman operationer i en enda åtgärd där det är logiskt, kombinera hämtning, analys och svar istället för att betala för var och en separat när en åtgärd skulle fungera. Cachesvar för upprepade begäranden så att vanliga frågor används från cache istället för att konsumera nya åtgärder för varje identisk fråga, vilket är den enskilt största effektiviteten under denna modell när en meningsfull andel av sökfrågorna upprepas.
Under prissättning per konversation innebär optimering att lösa problem inom en enskild konversation istället för mellan flera. Utforma sessionsgränser och timeouter så att en konversation fortsätter korrekt utan att avbrytas i förtid och tvinga fram en ny faktureringsbar konversation. Fokusera agenters kapacitet på lösning för första konversationen så att en uppgift slutförs inom den inledande konversationen istället för att kräva en uppföljning. Följ lösningsresultatet för den första konversationen som ett kostnadseffektivitetsmått och avråd från att utöka omfattningen där en användare öppnar separata konversationer för relaterade problem som det befintliga konversationssammanhanget kunde ha hanterat.
Under Per användare-prenumerationer innebär optimering att maximera värdet som varje licensierad användare returnerar, eftersom förbrukningen är obegränsad och kostnaden är fast per plats. Fokusera på användning så att licensierade användare aktivt engagerar agenten, följ användning för att identifiera användare med låg användning för riktad utbildning eller licensomallokering, och anslut agentinteraktioner till verksamhetsresultat efter användarpopulation så att användningsfall med högt värde motiverar investeringen medan användning med lågt värde signalerar ett behov av optimering eller en annan prissättningsmodell. Granska användarpopulationer i en kadens så att licenser fortsätter vara i linje med den faktiska användningen.
Oavsett prissättningsmodell påverkar arkitektur kostnaden. Implementera triageagenter som hanterar inledande dirigering med enkel logik och dirigera användare till en specialiserad agent endast när komplexiteten kräver det, så att dyra komplexa åberopningar endast inträffar när de är motiverade. Gå tillbaka till traditionell automatisering för deterministiska scenarion där regelbaserad logik räcker, vilket låter flöden hantera de deterministiska vägarna till lägre kostnad medan agenter hanterar de tvetydiga situationer som verkligen behöver resoneras. Hämta jordningsdata selektivt och åberopa vektorsökning och dokumenthämtning endast när agentens resonemang kräver det istället för i varje interaktion, så att Data 360-användning följer det verkliga behovet. Dessa mönster håller arkitekturens kostnad för resonemang och konsumtion proportionell till arbetets svårighetsgrad.
Kostnadsövervakning för autonoma agenter är svårare än för traditionella arbetsbelastningar, eftersom agenter inte följer ett förutsägbart mönster för begäran-svar. En agent kan upprepa genom flerstegsresonemang, adaptivt åberopa verktyg baserade på körförhållanden och koordinera andra agenter, vilket ger mycket varierande kreditkonsumtion som är svår att prognostisera. Utan övervakning kan en agent som utför djupt iterativt arbete konsumera en stor mängd krediter innan någon ingriper, och ineffektiv promptdesign eller överflödiga resonemangsloopar kan tyst tömma budgetar över en hel agentflotta. Effektiv styrning kräver därför insyn i realtid i konsumtion per agent och per operation, automatiserade varningar och kontroller som förhindrar onödiga kostnader samtidigt som den autonomi som gör agenter användbara bibehålls. Ekonomisk styrning för agenter behöver också tydligt ägarskap och stegvisa godkännanden byggda för variabel konsumtion snarare än för statisk beräkningskostnad.
Salesforce Digital Wallet är det inbyggda verktyget för att bevaka konsumtionsbaserade produkter, inklusive Agentforce Flex Credits, och organisationer som använder Flex Credits bör etablera det som den primära kostnadsövervakningsmekanismen istället för att bygga egna instrumentpaneler för att replikera vad det tillhandahåller. Digital Wallet levererar konsumtionsdata nästan i realtid med användningsinsikter på åtgärdsnivå, en översikt per agent som visar vilka agenter som konsumerar mest, proaktiva konsumtionsvarningar och historiska trender för mönsteranalys och prognoser. Matcha övervakningen med prissättningsmodellen. Under Flexkrediter, följ konsumtion efter agent, användarpopulation, tidsperiod och åtgärdstyp, och komplettera Digital Wallet med egna instrumentpaneler som ansluter kreditkonsumtion till affärstransaktioner. Under prissättning per konversation, övervaka konversationsvolymer, genomsnittlig längd och slutföranderesultat. Under Prenumerationer per användare kan du övervaka användning istället för konsumtion, spåra aktiva användare och verksamhetsvärde per användare så att licensinvesteringen visas leverera proportionellt värde.
Attribuering av kostnader per interaktion ansluter konsumtion till affärstransaktioner och avslöjar kostnaden per löst kundcase, per kvalificerat lead eller per bearbetad order, vilket möjliggör ROI-beräkning och jämförelse av korsanvändningsfall. Budgetvarning utlöser notiser när förbrukningen närmar sig definierade tröskelvärden, vid tröskelvärden som 70 % och 85 % av budgeten, så att optimering sker innan en gräns uppnås. Konfigurera varningar per agent och per användningsfall istället för endast organisationsomfattande för att lokalisera ett problem till dess källa. Upptäckt av avvikelser lyfter fram den plötsliga konsumtionsökningen som signalerar ett oväntat användningsmönster eller en resonemangsloop som behöver undersökas. Dela kostnadsinstrumentpaneler med affärsintressenter och tekniska team så att transparens driver kostnadsmedveten agentanvändning.
Tillämpa ekonomisk styrning innan du spenderar till en agentarkitektur.. Kräv ett verksamhetsfall för en agentinvestering som täcker beräknad total ägandekostnad över 3–5 år enligt den valda prissättningsmodellen, de förväntade verksamhetsresultaten med en mätmetod, en jämförelse mot alternativ inklusive manuella processer och traditionell automatisering, och en riskbedömning som täcker kvalitet, säkerhet och operativ risk. Definiera godkännandetrösklar som separerar de investeringar en avdelning kan auktorisera från de som kräver chefsgodkännande, så att en agent med hög investering eller hög risk får proportionell granskning. Ge mandat till pilotdistribueringar som validerar antaganden innan fullständig produktion, eftersom en pilot avslöjar faktisk användning, kvalitet och användning som ligger till grund för både investeringsbeslutet för produktion och valet av prissättningsmodell.
Hantera agentegenskapen som en portfölj istället för agent efter agent, eftersom en portföljvy avslöjar optimeringsmöjligheter som en enskild agentgranskning missar. Granska alla agenter tillsammans och jämför kostnader, användning, affärsvärde och strategisk anpassning, och definiera kriterier som gör att agenter med låg användning, låg ROI, överflödig funktionalitet eller överdrivna kostnader dras tillbaka, så att agenter med lågt värde inte ackumuleras och konsumerar budget i all oändlighet. Omallokera investeringar från agenter med låg prestanda till säljprojekt med högt värde som en kontinuerlig metod som omfördelas med växande prioriteter istället för en engångsrensning.
Kostnadsallokering skapar ansvarighet för agentanvändning och organisationer implementerar den genom samma två modeller som gäller för resten av plattformen. Showback rapporterar agentkostnader efter affärsenhet utan en intern kostnad, vilket skapar kostnadsmedvetenhet och informerar optimeringsdiskussioner utan att behöva göra några interna faktureringar. Chargeback allokerar faktiska agentkostnader till de konsumerande affärsenheterna, vilket driver ett starkare optimeringsbeteende eftersom kostnaden påverkar en avdelningsbudget direkt, men det kräver en korrekt allokeringsmetod för att undvika tvister. En hybridmetod tillämpar chargeback för produktionsagenter med hög volym samtidigt som den använder showback för experimentella agenter eller agenter med låg volym, vilket balanserar ansvarighet för större investeringar mot flexibilitet för innovation.
Agentarkitekturer introducerar egna hållbarhetsöverväganden, eftersom härledning av storskaliga språkmodeller är beräkningsintensiv och vissa agenter kör kontinuerligt istället för endast i diskreta användarutlösta transaktioner. Proaktiva, utgående och schemalagda agenter arbetar utan en användare i loopen, konversationsagenter ackumulerar konsumtion över många varv, och vektorsökning, sammanhangsförberedelse och åtgärdsutförande ökar alla infrastrukturbelastningen. Hållbar agentdesign minimerar beräkningsslöseri samtidigt som upplevelsen förblir responsiv. Precis som i pelaren Resurs- och kostnadsoptimering är relationen mellan en lösning och datacenterutsläpp indirekt. En enskild arrendators effektivitet minskar inte direkt utsläppen. Effektivitetsvinster för alla arrendatorer hjälper dock Salesforce köra sin infrastruktur med högre nyttjande och skjuter upp kapacitetsökningen. och de grundläggande hållbarhetsrutinerna från pelaren Resurs- och kostnadsoptimering gäller för agenter, och de effektivitetsstrategier som följer tar båda upp vad som är specifikt för konversationssystem med stor språkmodell. Var och en sänker även kostnaden, vilket är anledningen till att hållbarhet och värde per kostnad är samma disciplin som mäts mot olika resultat.
Slutsatser är den mest resurskrävande komponenten i en agentarkitektur, så effektivitet lönar sig med uppmaningslängd, sammanhangsanvändning och cachning. Optimera uppmaningar för att förmedla syfte med färre tokens genom att ta bort ordagranna instruktioner och överflödiga exempel, eftersom en kortare uppmaning minskar beräkningen i förväg proportionellt även om den inte ändrar beräkningen av hur svaret skapas. Hantera sammanhangsfönstret genom att sammanfatta konversationshistoriken efter de första svängarna och endast returnera viktiga fält från varje åtgärd, så att tokenbudgeten som förs in i varje slutsats förblir begränsad istället för att växa med konversationen.
Vektorsökning och sammanslagna profilfrågor konsumerar beräkningsresurser, så samma resultatgräns och filtreringsdisciplin som styr jordningskostnaden minskar även infrastrukturbelastningen för jordning. Ställ in topp-k-gränser för att endast returnera de resultat agenten använder, eftersom hämtning av 50 när 5 informerar svaret medför 45 oanvända resultat som inte förbrukar grundtokenbudgeten för någon nytta, och använd metadatafilter för att begränsa sökningen innan likhetsrangordning. Fråga sammanslagna profiler för att sammanställa fullständigt sammanhang i en operation istället för att utfärda separata sökfrågor mot flera objekt för varje tur, och cacha profiler för agenter med hög användaraffinitet, till exempel en säljare som arbetar med en fast uppsättning konton, så att upprepad sammanhangssammanställning inte upprepar sökfrågan.
Agentåtgärder konsumerar SOQL-frågor, DML-operationer och CPU-tid, så buntning, cachning och asynkron disciplin för pelaren Resurs- och kostnadsoptimering gäller direkt för agentåtgärder. Utforma åtgärder för att acceptera samlingar så att uppdatering av många poster är en operation istället för många, använd relationsfrågor för att hämta överordnade och underordnade data i ett enskilt uttryck, cacha referensdata i plattformscache och batch-DML över en samling istället för per post. Flytta operationer som överskrider synkrona gränser till Apex i kö eller batch, bearbeta icke-brådskande arbete som massbetyg eller historisk berikning asynkront och schemalägg agentutlösta batchjobb för fönster utanför rusningstid där så är möjligt så att belastning sprids över tid istället för att koncentreras under arbetstid. Övervaka asynkron körning så att en eftersläpning i kön signalerar ett kapacitetsplaneringsbehov innan det blir ett fel.
Agenters konsumtionsmönster utvecklas i takt med att användningen ökar, så hållbarhet kräver kontinuerlig övervakning istället för en engångsbetalning. Följ de genomsnittliga tokens per slutsats genom den tillgängliga användningstelemetrin så att en stigande uppmaningsstorlek lyfter fram ett optimeringssäljprojekt, bevaka distribution av konversationslängd så att obegränsade konversationer avslöjar ett problem med uppgiftsgränsen och analysera åtgärdskörningsfrekvensen i Händelseövervakning så att en åtgärd med hög frekvens blir en optimeringsprioritet. Gå igenom Data 360-sökfrågemönster för att hitta vanliga sökfrågor som är värda att cacha eller förberäkna, spåra träffresultatet för semantisk cache så att ett lågt resultat utlöser tröskeljustering och mät latenspercentiler så att svanslatens exponerar flaskhalsar. Granska agentanvändning regelbundet för omfattningsdrift. Undersök till exempel en agent vars genomsnittliga konversationslängd växer från några få varv till många under flera månader. Förfina agentens gränser så att konsumtionen återgår till plan. Vissa av dessa övervakningsytor exponerar användning i aggregerade instrumentpaneler istället för som en diskret per-slutpunkt-logg, så bekräfta den exakta telemetri som är tillgänglig för din konfiguration när du utformar övervakningen.
Resursoptimering avgör om agentarkitekturer skalas upp i takt med att populationer växer och användningsfall utökas, och kostnadsoptimering avgör om denna skala returnerar proportionellt affärsvärde. Dessa två beslut utgör ett enda mandat:
- Arkitektonisk effektivitet: utforma åtgärder med buntning, budgetera SOQL över åtgärdskedjor, flytta tung bearbetning till asynkron, optimera API-användning genom sammansatta och händelsedrivna mönster, hantera sammanhangsfönster genom prioritering och sammanfattning, och bygg sammansatta arkitekturer från återanvändbara komponenter.
- Ekonomisk vägledning: välj prissättningsmodellen avsiktligt, modellera färdig TCO innan du åtar dig, övervaka konsumtionen jämfört med verksamhetsresultaten och styr investeringar genom stegvist godkännande och portföljgranskning.
Organisationer som behärskar dessa mönster levererar responsiva agentupplevelser inom plattformsbegränsningar samtidigt som de håller utgifterna i linje med det värde agenterna returnerar.
Den grundläggande vägledningen för resurs- och kostnadsoptimering för alla Salesforce-lösningar, inklusive prestandaoptimering, styrande gränser, TCO-analys, licensdisciplin och kostnadsstyrning, finns i pelaren Resurs- och kostnadsoptimering. Komponenterna agentstyrning, mänsklig tillsyn och säkerhetsprogram ansluter till pelarna Trust och Rättvisa. Den detaljerade vägledningen för agentimplementering i detta dokument, som omfattar resurseffektivitet, ekonomi, åtgärdsoptimering, styrning och hållbarhet, samlas i biblioteket med agentmönster.