Ottimizzazione delle risorse e dei costi per l'azienda agente

Gli agenti autonomi consumano le risorse Salesforce in modo diverso rispetto all'automazione deterministica. I carichi di lavoro degli agenti sono imprevedibili e continui, anziché fissi e vincolati alle transazioni. La tesi value-per-cost del pilastro Ottimizzazione delle risorse e dei costi viene portata direttamente nell'organizzazione agente. Efficienza delle risorse significa utilizzare la capacità già pagata e ottimizzazione dei costi significa indirizzare deliberatamente la spesa verso le capacità autonome che fruttano un ritorno. Gli agenti modificano la forma di entrambi. Una progettazione efficiente degli agenti consente di tenere sotto controllo i consumi e la selezione del modello di prezzi, la modellazione del costo totale di proprietà (TCO) e la governance finanziaria consentono di mantenere la spesa allineata al valore. Questo documento considera l'efficienza delle risorse e l'ottimizzazione dei costi come una decisione, poiché per gli agenti sono due visualizzazioni dello stesso obiettivo.

Gli agenti modificano la prevedibilità del consumo. Un processo Apex tradizionale opera su un insieme di record noto con un costo di risorsa noto. Un agente opera conversazionalmente e una singola conversazione può eseguire decine di azioni mentre l'agente ragiona attraverso un'operazione. Ogni azione consuma i limiti del governor all'interno della propria transazione anziché accumularli nella conversazione. La preparazione del contesto per un turno può eseguire query su 200 record o 20.000, a seconda di ciò che l'utente chiede. Il consumo dell'API accelera perché gli agenti possono agire in autonomia e gli agenti proattivi, in uscita e pianificati agiscono in modo continuo anziché solo durante una transazione utente. Questa imprevedibilità è il motivo per cui la gestione delle risorse degli agenti deve essere difensiva fin dalla progettazione anziché ottimizzata dopo un picco di consumo.

Anche il lato costi cambia. Gli agenti autonomi introducono prezzi basati sul consumo che si comportano in modo diverso dalle licenze tradizionali per posto. Agentforce offre due modelli di prezzi basati sul consumo, Flex Credits e Per-Conversation. Ogni distribuzione agente seleziona uno dei seguenti modelli. Un'organizzazione utilizza un modello di consumo alla volta, ma un componente aggiuntivo Per utente, offerto per utente al mese per l'utilizzo senza contatori, può affiancare un modello di consumo in modo che gli agenti indirizzati ai clienti vengano eseguiti con crediti Flex o per conversazione mentre i dipendenti utilizzano licenze senza contatori. Data 360 supporta il radicamento degli agenti attraverso la ricerca e il recupero vettoriale e consuma capacità di elaborazione dati, mentre MuleSoft abilita le integrazioni degli agenti che consumano capacità API. Questi costi variabili vengono scalati con l'utilizzo degli agenti, creando uno schema di investimento che richiede una governance finanziaria basata sulla variabilità anziché su un abbonamento annuale fisso.

Le soluzioni progettate per il valore aziendale con costi ottimizzati in Agentic Enterprise mantengono efficiente il consumo degli agenti attraverso azioni che elaborano i record in blocco, finestre di contesto disciplinate e caching. Inoltre, indirizzano deliberatamente la spesa attraverso il modello di prezzo corretto, la modellazione completa del TCO e il monitoraggio continuo dei costi rispetto ai risultati aziendali. Senza questo allineamento, le distribuzioni degli agenti accumulano costi senza dimostrare il valore proporzionale e un agente che ragiona in un loop senza limiti può bruciare i crediti più velocemente di quanto possa fare la supervisione umana. Lo stesso lavoro di efficienza che mantiene un agente entro i limiti del governor lo mantiene entro il budget di credito, che è la tesi del pilastro espressa in termini agentici.

Questo documento descrive che cosa cambia quando gli agenti sono presenti. Per gli schemi di ottimizzazione di base delle risorse e dei costi validi per ogni soluzione Salesforce, inclusi l'ottimizzazione delle prestazioni, i limiti governor, l'analisi del TCO e la disciplina delle licenze, vedere il pilastro Ottimizzazione risorse e costi. La governance degli agenti e la supervisione umana si collegano ai pilastri Trust e Fairness, che coprono i componenti del programma che mantengono il comportamento autonomo sicuro e responsabile.

Il consumo delle risorse degli agenti segue la stessa meccanica della piattaforma di Flusso o Apex, ma la sua invocazione imprevedibile basata sulla conversazione rende il consumo più difficile da prevedere e richiede quindi schemi difensivi. Le responsabilità di ottimizzazione si estendono al budget limite del governor nelle catene di azioni, al consumo API, alla latenza di risposta, all'efficienza del radicamento in Data 360, alla gestione delle finestre contesto e al design componibile che consente agli agenti di scalare senza duplicazioni. Ogni responsabilità è una decisione basata sul valore per costo prima che tecnica, perché gli agenti ripetono le inefficienze in ogni conversazione.

Gli agenti invocano azioni che attivano Apex, flussi e integrazioni. Una singola conversazione può eseguire decine di azioni mentre l'agente ragiona in un'operazione complessa. La disciplina di base è la stessa di qualsiasi soluzione Salesforce, ma lo schema di invocazione imprevedibile alza la posta in gioco. Progettare azioni per accettare raccolte in modo che un agente che aggiorna 50 casi invochi una sola azione anziché 50 chiamate separate. Una singola azione che opera su una raccolta di record consuma molte meno query SOQL (Object Query Language) di Salesforce e operazioni DML (Data Manipulation Language) per lo stesso lavoro. Gestire deliberatamente il budget SOQL in tutte le catene di azioni, poiché un flusso di lavoro che invoca da 10 a 15 azioni può avvicinarsi o superare il limite di 100 query sincrone quando ogni azione esegue diverse query. Utilizzare le query di relazione per recuperare i dati controllanti e secondari in un'unica istruzione e fare riferimento ai dati memorizzati nella cache piattaforma nelle azioni all'interno della stessa conversazione. Queste due pratiche mantengono una catena multi-azione all'interno del budget.

Spostare le operazioni degli agenti che superano i limiti sincroni in Area di attesa o Batch Apex, dove il contesto asincrono raddoppia approssimativamente lo spazio di testa SOQL e CPU disponibile per il lavoro. Le operazioni analitiche di grandi dimensioni, ad esempio il calcolo del punteggio di 1.000 lead o l'analisi del sentiment nei casi storici, appartengono all'elaborazione asincrona anziché bloccare una conversazione. Poiché l'inferenza del modello con linguaggio ampio si verifica all'esterno di Salesforce e consuma crediti flessibili anziché il tempo della CPU Apex, il budget CPU profilato viene consumato dalla logica delle azioni, dalle trasformazioni dei dati e dalle integrazioni attivate dall'agente. Gli scenari di distorsione dei dati in cui i record controllanti sono associati a migliaia di record controllati meritano particolare attenzione difensiva con gli agenti. Questa vulnerabilità si verifica perché un agente può richiedere "tutta la cronologia" per un account con decine di migliaia di record correlati in un modo in cui una query deterministica non lo farebbe mai. Progettare azioni con limiti di record controllati e paginazione e applicare il campionamento quando i volumi superano la soglia di deviazione dei dati. Questi limiti evitano che una richiesta imprevedibile si trasformi in una query illimitata. Il tracciamento sessione Agentforce identifica le azioni che consumano query eccessive a livello di sessione e Scale Center monitora le prestazioni complessive delle transazioni Apex e lo stato dell'organizzazione.

Le architetture degli agenti utilizzano le API più rapidamente dei flussi di lavoro gestiti dagli utenti, poiché gli agenti operano in modo autonomo e, per gli agenti proattivi o pianificati, in modo continuo. Il modo in cui un agente viene presentato determina in che modo riduce la capacità API. Gli agenti richiamati tramite l'API REST consumano una chiamata per turno di conversazione. Gli agenti incorporati nelle pagine Lightning tramite componenti standard non consumano una chiamata API per interazione, anche se il loro costo viene comunque misurato nei crediti o nelle conversazioni del modello di prezzi scelto. I componenti Web Lightning personalizzati che effettuano chiamate REST dirette consumano la capacità dell'API. I componenti creati sugli adattatori Lightning Data Service non lo fanno, perché Lightning Data Service serve da una cache condivisa lato client anziché eseguire una chiamata API. Monitorare il consumo in Monitoraggio evento durante un programma pilota per comprendere l'utilizzo effettivo prima di un'implementazione completa.

Gli schemi basati sugli eventi sono la leva più importante sul consumo sprecato dell'API degli agenti. La pubblicazione di un evento piattaforma quando una condizione richiede l'intervento dell'agente evita il polling pianificato che consuma le chiamate API indipendentemente dal fatto che ci sia o meno lavoro da fare e un agente che si abbona agli eventi di acquisizione dati modifica mantiene il contesto corrente senza le chiamate di polling giornaliere che un orchestratore esterno effettuerebbe altrimenti. La logica del valore per costo è diretta: Un sondaggio che non trova lavoro è la capacità spesa per nulla, e un evento che si attiva solo su un cambiamento reale è la capacità spesa solo sul lavoro reale. La generazione aumentata di recupero aggiunge il proprio consumo, poiché ogni ricerca vettoriale in Data 360 consuma elaborazione, quindi impostare i limiti di recupero in modo da restituire solo i risultati effettivamente utilizzati dall'agente.

La latenza per un turno agente è la somma del tempo di inferenza LLM, del tempo di esecuzione delle azioni, del tempo di esecuzione delle query in Data 360 e del tempo di integrazione quando queste fasi vengono eseguite in sequenza. In caso contrario, si tratta del ramo parallelo più lungo più eventuali passaggi sequenziali. La latenza è un problema di costi oltre che di esperienza, perché un'azione lenta mantiene le risorse aperte più a lungo e un utente frustrato avvia più conversazioni di quelle risolte. Poiché i prompt più brevi generano risposte più rapide, rimuovere istruzioni dettagliate, esempi ridondanti e contesto non necessario. Il contesto selettivo migliora sia la latenza che la qualità delle risposte, dove un dump di contesto completo aggiunge solo rumore. Mantenere le azioni rapide tramite SOQL selettivo su campi indicizzati, dati di riferimento in blocco e dati di riferimento memorizzati nella cache, poiché un'azione di 3 secondi diventa un collo di bottiglia indipendentemente dalla velocità dell'inferenza. Convalidare le query azioni con lo strumento Query Plan (Piano di esecuzione query) per identificare le analisi complete delle tabelle che aumentano la latenza delle azioni.

L'orchestrazione del Generatore di agenti può eseguire azioni in parallelo quando non esistono dipendenze tra di esse, ad esempio per recuperare i dettagli dell'account e le opportunità correlate contemporaneamente è necessario il tempo più lento dei due anziché la somma di entrambi. Per le chiamate che si estendono a più sistemi a valle, associare Agentforce a una piattaforma di integrazione come MuleSoft; l'agente invoca una singola azione, MuleSoft riceve la richiesta ed emette chiamate parallele ai sistemi di backend, quindi restituisce una risposta aggregata. La cache piattaforma rimuove l'inferenza e la latenza delle query per le richieste ripetute e l'elaborazione asincrona del lavoro non urgente, ad esempio un'analisi lunga dei documenti, consente all'agente di confermare immediatamente la richiesta e restituire il risultato quando è pronto anziché tenere aperta la conversazione.

Data 360 fornisce la ricerca vettoriale che basa le risposte degli agenti sui dati correnti anziché sui soli dati di addestramento del modello e la sua efficienza determina sia la qualità del radicamento che l'elaborazione utilizzata per raggiungerla. Suddivisione, selezione dell'incorporamento, filtro dei metadati e limiti dei risultati sono le decisioni più utili. Suddividere Knowledge in segmenti semanticamente significativi, perché i blocchi troppo piccoli forzano molti recuperi per una domanda mentre i blocchi troppo grandi diluiscono la pertinenza con il contesto irrilevante e gonfiano il budget del token trasportato nell'inferenza. Scegliere un modello di incorporamento che corrisponda al modo in cui gli agenti eseguono effettivamente le query, poiché la somiglianza domanda-risposta si comporta in modo diverso dalla classificazione dei documenti, e convalidare la scelta in base alle query rappresentative. Combinare la somiglianza semantica con i filtri dei metadati in modo che i vincoli aziendali rimangano indipendentemente dalla somiglianza, ad esempio escludere i prodotti interrotti da un consiglio indipendentemente da quanto vicina sia la corrispondenza. Impostare i limiti superiori a k per restituire solo i risultati utilizzati dall'agente. Ad esempio, se 5 risultati informano una risposta, il recupero di 50 aggiunge 45 risultati non utilizzati al payload di radicamento e al budget del token.

I profili unificati sono efficienti in termini di risorse perché un agente che esegue query su un profilo unificato Data 360 recupera il contesto completo del cliente in una singola operazione anziché orchestrare query separate per Account, Referente, Opportunità, Caso e Campagna per ogni turno. Configurare le istanze di Data 360 nelle regioni richieste dai requisiti normativi in modo che gli agenti che elaborano i dati per una determinata giurisdizione interroghino l'istanza che contiene i dati personali.

Le finestre di contesto del modello a linguaggio ampio contengono un numero finito di token e la gestione di quel budget mantiene coerente una lunga conversazione senza esaurire la capacità o gonfiare il costo di ogni chiamata di inferenza. Assegnare una priorità deliberata anziché troncare arbitrariamente: la cronologia delle conversazioni recenti ha la massima priorità, i dati aziendali critici come lo stato dei record e le autorizzazioni correnti vengono aggiunti al secondo posto e la cronologia più datata viene inclusa solo quando lo spazio lo consente. Dopo i primi turni, riassumere la conversazione precedente in una panoramica concisa che conserva i fatti critici senza riportare la cronologia completa. Questo riepilogo mantiene la continuità senza aumentare il budget del token . Memorizzare il contesto esteso in Data 360 o in oggetti personalizzati come memoria esterna sottoposta a query su richiesta anziché riprodurre l'intera cronologia in ogni chiamata e restituire solo i campi essenziali di ogni azione, poiché una risposta che trasporta tutti i 50 campi di un record quando l'operazione ne richiede 8 spende il budget contesto meglio allocato per la conversazione o il radicamento nel contesto.

Gli agenti di costruzione da componenti riutilizzabili riducono i costi di sviluppo e manutenzione. Una funzionalità creata una volta e riutilizzata è molto più economica nel corso della sua vita rispetto alla stessa funzionalità reimplementata e gestita separatamente per ogni agente. Le librerie di azioni centralizzate che coprono le operazioni dei record, le approvazioni, le notifiche e la convalida consentono ai team piattaforma di mantenere un comportamento, una sicurezza e prestazioni coerenti per ogni agente che consuma e consentono di assemblare un nuovo agente da componenti di base collaudati in pochi giorni anziché creare azioni personalizzate nel corso di settimane. Gli agenti specializzati focalizzati con confini di dominio chiari mantengono un contesto più ristretto e un comportamento più chiaro rispetto a un singolo agente universale che tenta ogni scenario e l'orchestrazione di Agent Builder coordina gli specialisti quando un'operazione attraversa i domini. I modelli di prompt convalidati nel Generatore di prompt acquisiscono schemi collaudati per il radicamento, il ragionamento e la formattazione delle risposte, in modo che la qualità rimanga costante man mano che lo sviluppo accelera, e una Knowledge Base condivisa in Data 360 basa molti agenti da un'unica fonte, quindi un aggiornamento raggiunge ogni consumatore contemporaneamente anziché richiedere una modifica a ogni agente.

I team aziendali compongono sempre più agenti insieme anziché creare singoli agenti monolitici, con un agente orchestratore che scompone una richiesta e delega a subagenti specializzati o agenti specializzati che si passano l'un l'altro mentre una conversazione si sposta tra i domini. Questa composizione solleva questioni relative alle risorse e ai costi che vanno oltre ciò che un singolo agente deve affrontare, poiché l'overhead di orchestrazione, il trust tra agenti e il trasferimento di stato si combinano in una catena anziché rimanere contenuti in una sola azione. Mantenere stretti i prompt di orchestrazione, limitandosi a classificare gli intenti e l'instradamento, anziché chiedere all'orchestratore di ragionare anche sull'operazione sottostante, poiché tale ragionamento appartiene al subagente con il contesto pertinente e limita la profondità della catena a meno che un caso d'uso non richieda chiaramente una nidificazione più profonda da orchestratore a subagente. Considerare ogni risposta subagente come input non affidabile, come una risposta API esterna. Convalida la forma prevista e la conformità alle regole aziendali prima di agire. Applicare la protezione e la condivisione a livello di campo in modo indipendente per ogni azione agente.

Passare solo lo stato necessario all'agente destinatario, utilizzando un payload di handoff strutturato di ID record, riepilogo operazioni e campi pertinenti anziché inoltrare la cronologia delle conversazioni non elaborate, in modo che il budget del token nella catena rimanga controllato e lo stato della sessione tra agenti rimanga in Data 360 o in un oggetto personalizzato quando un handoff deve sopravvivere in transazioni separate. I limiti del governor si applicano per agente, non una volta per conversazione, quindi ogni agente di una catena estrae il proprio budget SOQL, DML e CPU. Una catena di un orchestratore e tre agenti secondari consuma ciascuno di questi limiti quattro volte di più e le catene più profonde moltiplicano ulteriormente il consumo. La stessa moltiplicazione determina il costo, il che rende la profondità della catena illimitata un rischio di costo più elevato rispetto a un limite governor.

Definire cosa fa l'orchestratore quando un subagente non riesce, scade o restituisce un risultato con scarsa confidenza, che si tratti di un tentativo limitato, di una risposta di fallback o di un inoltro al livello superiore a un essere umano, in modo che un singolo timeout subagente non si traduca in un errore dell'intera catena. Correlare una richiesta per ogni agente che contatta con un ID traccia condiviso propagato attraverso il payload di handoff, poiché diagnosticare quale agente in una catena ha causato un picco di latenza o un picco di costi richiede in altro modo la correlazione manuale dei registri in sessioni di agenti separate.

Le azioni non riuscite e le chiamate secondarie non riuscite non influiscono solo sull'affidabilità, poiché ogni nuovo tentativo può eseguire nuovamente il lavoro SOQL, DML e CPU già speso per il tentativo non riuscito e in una catena multi-agente questo costo si somma al numero di agenti a valle non riusciti. In prezzi basati sul consumo, gli stessi composti di errore vengono spesi oltre che calcolati: un'azione tentata consuma nuovamente i crediti in Crediti flessibili. Progettare una nuova logica per tenere conto sia dell'affidabilità che del costo. Distinguere gli errori temporanei, ad esempio un timeout di chiamata o una disputa di blocco, dagli errori logici, ad esempio un errore di convalida o un input in formato non corretto, prima di decidere come rispondere, poiché un errore temporaneo può valere la pena di ripetere un tentativo limitato mentre un errore logico non riesce in modo identico alla ripetizione e brucia solo il budget per un errore ripetuto garantito che dovrebbe invece essere inoltrato immediatamente al livello superiore.

Limitare i tentativi di nuovo tentativo per azione, a due o tre tentativi, e applicare un backoff esponenziale tra di essi anziché una richiamata immediata, poiché un nuovo tentativo senza limiti o a ciclo serrato su un'azione SOQL o DML può esaurire i limiti sincroni all'interno di una singola transazione o ridurre il budget cumulativo della catena e la spesa cumulativa per il credito in una conversazione tra più agenti. Progettare le azioni in modo che una chiamata provata produca lo stesso stato finale di una singola chiamata riuscita, utilizzando una chiave idempotency, ad esempio un ID richiesta o un ID esterno con logica di inserimento con aggiornamento anziché inserire, in modo che un nuovo tentativo aggiorni lo stesso record anziché creare un duplicato; un'azione priva di impotenza forza un tentativo di raddoppiare il consumo di risorse tramite record a valle duplicati o raddoppiare le azioni fatturate o le conversazioni per il lavoro già eseguito una volta.

Tenere traccia dello stato di completamento per agente in una catena, poiché l'azione di un agente può confermare DML correttamente prima che un agente a valle abbia un errore e un handler di errore che sa cosa è già riuscito può compensare o riprendere dal punto di errore anziché riavviare e fatturare nuovamente l'intera catena. Mostrare all'utente finale lo stato di un nuovo tentativo o di un nuovo tentativo in corso mentre è in corso un tentativo limitato, perché un utente che vede il silenzio e ripete la richiesta attiva una conversazione completamente nuova e una nuova serie di azioni, aggiungendo alla risorsa e al costo di fatturazione del tentativo originale un tentativo duplicato.

Gli schemi di ottimizzazione delle risorse descritti in questo documento sono utili solo se un architetto può vedere dove un agente sta effettivamente spendendo query SOQL, tempo CPU, righe DML e token quando viene eseguito in produzione. Senza visibilità per azione e per sessione, una violazione del limite o una regressione della latenza viene visualizzata come sintomo senza possibilità di risalire all'azione o all'agente nella catena che l'ha causata. Questa preoccupazione è distinta dalla visibilità della spesa offerta da Digital Wallet in Monitoraggio dei costi e governance finanziaria. Digital Wallet mostra il numero di crediti o conversazioni consumati da un agente, mentre lo strumento mostra il motivo per cui sono stati consumati, a livello della singola query, riga DML o azione che ha determinato tale consumo. Lo strumento giusto dipende da ciò che l'organizzazione e l'accordo di assistenza di un determinato cliente concedono effettivamente, non da quale strumento è teoricamente il migliore, quindi abbinare il consiglio alla licenza e al livello di accesso anziché utilizzare per impostazione predefinita lo strumento più efficace disponibile.

Qualsiasi architetto può creare eventi piattaforma personalizzati che vengono attivati all'inizio e alla fine di ogni azione e chiamata subagente. Questi eventi tracciano l'esecuzione in una conversazione utilizzando solo le funzionalità standard della piattaforma, abbinate alla registrazione a livello di azione in un oggetto personalizzato che acquisisce il conteggio delle query SOQL, il tempo CPU, il conteggio delle righe DML e l'utilizzo dell'heap quando viene eseguita ogni azione. Entrambi gli eventi sono interrogabili tramite rapporti o SOQL e offrono a ogni organizzazione una funzionalità diagnostica di base indipendentemente dalla versione o dalla licenza aggiuntiva. Monitoraggio evento, introdotto in precedenza per il tracciamento del consumo API durante le sessioni pilota, mette in evidenza anche schemi aggregati di utilizzo delle risorse nelle sessioni degli agenti a livello di organizzazione per i clienti la cui organizzazione include quel componente aggiuntivo, consentendo a un architetto di identificare i flussi di lavoro che tendono a rispettare i limiti del governor in molte conversazioni anziché diagnosticarne uno alla volta. Scale Center offre un tracciamento approfondito delle transazioni che si avvicinano ai limiti del governor, in genere accessibili tramite un coinvolgimento dell'Assistenza o disponibili direttamente ai livelli di account che lo concedono.

Il controllo delle versioni degli agenti rende possibile l'implementazione, il ritiro e il confronto controllati e protegge l'investimento in un agente che lavora mentre lo si migliora. Ove possibile, guidare il comportamento attraverso la configurazione, utilizzando Tipi di metadati personalizzati e Generatore di prompt in modo che gli amministratori regolino i modelli di prompt e la selezione delle azioni senza un ciclo di sviluppo. Utilizzare la funzionalità di test A/B pilota per instradare un piccolo sottoinsieme di utenti a una versione sperimentale. Confrontare qualità, soddisfazione e completamento delle operazioni prima di un'implementazione completa. Questo confronto convalida i miglioramenti con l'utilizzo reale e rileva le regressioni mentre l'esposizione è limitata. Definire contratti di interfaccia chiari tra i componenti, specificando input, output, errori e aspettative di prestazioni, in modo che un'implementazione possa essere sostituita senza modificare gli agenti che dipendono da essa.

L'economia degli agenti inizia con il costo totale di proprietà confrontato con il valore aziendale, ma i prezzi basati sul consumo degli agenti autonomi fanno sì che il lato dei costi si comporti in modo diverso dalle licenze tradizionali. Il modello di calcolo dei prezzi selezionato è una decisione architetturale fondamentale, poiché determina per cosa si ottimizza l'intero ciclo di vita dell'agente. Questa sezione stabilisce i modelli di prezzi, il quadro completo del TCO per l'implementazione di un agente e la decisione build-versus-buy per le funzionalità degli agenti.

Agentforce offre due modelli di prezzi basati sul consumo e un'organizzazione seleziona uno dei due per una determinata distribuzione agente. Flex Credits price per agent action (Prezzo Flex Credits per azione agente), che rende l'efficienza dell'azione la leva per il controllo dei costi. I prezzi per conversazione addebitano una tariffa unica per conversazione indipendentemente dalla lunghezza o dalla complessità, il che rende il contenimento della conversazione la leva. Gli abbonamenti per utente forniscono un utilizzo non misurato degli agenti come componente aggiuntivo rivolto ai dipendenti anziché come terzo modello di consumo e spostano l'attenzione sull'ottimizzazione dall'efficienza dei consumi all'adozione, poiché il valore deriva dal coinvolgimento attivo degli utenti con licenza anziché dalla riduzione al minimo di ogni interazione. I due modelli di consumo non sono combinati per la stessa organizzazione, ma un componente aggiuntivo Per utente, offerto per utente al mese per l'utilizzo senza contatori, può affiancarsi a un modello di consumo in modo che gli agenti indirizzati ai clienti vengano eseguiti con crediti Flex o per conversazione mentre i dipendenti utilizzano licenze senza contatori.

In Crediti flessibili, i costi delle azioni sono fissi per azione fino a un limite massimo di token definito. A differenza dei prezzi di inferenza basati su token, il costo del credito non varia con la lunghezza del prompt o la complessità del modello, quindi una risposta a una frase e una risposta a più paragrafi hanno lo stesso costo. Un'interazione multi-azione consuma crediti per ogni azione, quindi un'interazione che recupera dati, motivi e aggiorna un record consuma i crediti di tre azioni e la generazione aumentata di recupero aggiunge ulteriori azioni tramite la ricerca vettoriale e il recupero di documenti prima del ragionamento. La comprensione del numero medio di azioni per transazione aziendale è quindi il prerequisito per la modellazione dei costi in Flex Credits.

In Prezzi per conversazione, viene applicata una tariffa unica per conversazione e più turni in una sessione vengono conteggiati come una singola conversazione, quindi il controllo dei costi deriva dalla risoluzione di un problema in una conversazione e dalla definizione di confini chiari della sessione anziché dall'eliminazione di singole azioni. Il radicamento in Data 360 e l'integrazione con MuleSoft consumano la propria capacità insieme al modello scelto, poiché la generazione di incorporamento e la ricerca di similarità riducono la capacità di elaborazione dei dati per ogni query basata e ogni azione esterna consuma la capacità API sia nel sistema di origine che in quello di destinazione.

Il costo totale di proprietà (TCO) per l'implementazione di un agente copre sei categorie e la modellazione di tutte e sei trasforma una stima del credito in una decisione di investimento informata. I costi di sviluppo coprono la progettazione degli agenti, la progettazione rapida, lo sviluppo dell'integrazione e i test e vanno da un semplice agente monouso a un sistema multiagente con un'orchestrazione complessa. I costi di inferenza dipendono dal modello di prezzi selezionato e richiedono la modellazione dei volumi di azioni previsti in Crediti flessibili, dei volumi di conversazioni in Per conversazione o dei conteggi degli utenti con licenza in Per utente. Per gli agenti basati su Knowledge Base di grandi dimensioni, l'infrastruttura Data 360 che supporta il radicamento nel contesto può competere o superare il costo di inferenza. I costi dell'infrastruttura coprono le licenze Data 360 e MuleSoft, i Sandbox aggiuntivi e l'infrastruttura di monitoraggio e sono prevalentemente fissi o con funzioni step basate sui livelli di capacità. I costi operativi coprono le operazioni di monitoraggio, il rapido perfezionamento, la risposta agli incidenti e l'assistenza agli utenti, e per i programmi per agenti maturi in genere corrispondono a una frazione significativa dei costi di sviluppo annuali, in linea con i benchmark generali del settore per gli agenti AI anziché a una cifra specifica di Salesforce. I costi di governance coprono la revisione della sicurezza, la supervisione umana, la registrazione dei controlli e la convalida della conformità che aumentano con l'autonomia e il rischio degli agenti, mentre il pilastro Equità copre i componenti essenziali del programma. I costi di modifica coprono la formazione degli utenti, l'adattamento dei processi aziendali e la gestione del cambiamento organizzativo e sono le categorie che i team più spesso sottovalutano.

Creare modelli TCO per fogli di calcolo che proiettano i costi da 3 a 5 anni. Documentare i presupposti per i volumi di interazioni, i conteggi delle azioni e la crescita. Eseguire un'analisi della sensibilità per identificare le ipotesi che influiscono maggiormente sul totale, quindi concentrare la convalida su tali ipotesi. Modellare tutte e tre le strutture di costo, Flex Credits, Per-Conversation e Per-User, rispetto all'utilizzo previsto prima di confermare, poiché la struttura ottimale dipende dallo schema di utilizzo e la scelta sbagliata è costosa da sbrogliare una volta che un agente è in produzione.

La decisione build-VS-buy per gli agenti segue la stessa logica di qualsiasi funzionalità di Salesforce, ponderando il time to value immediato di una soluzione pronta all'uso rispetto all'adattamento preciso di una build personalizzata in un orizzonte di TCO di 3-5 anni. I flussi di lavoro delle materie prime favoriscono l'acquisto, mentre le funzionalità principali che favoriscono la differenziazione proprietaria giustificano la creazione. Agentic Enterprise offre uno spettro di opzioni anziché una scelta binaria. Gli agenti Agentforce predefiniti, ad esempio un agente dell'assistenza o un sales development representative, offrono funzionalità collaudate con distribuzione rapida e aggiornamenti gestiti dalla piattaforma. Consumano crediti nel modello di prezzi selezionato. Gli agenti disponibili in commercio della comunità ISV (Independent Software Vendor) di Salesforce sono offerti tramite AgentExchange, dove è possibile trovare una soluzione che soddisfa già un requisito anziché crearla. Gli agenti personalizzati creati con Agent Builder offrono un adattamento preciso e una differenziazione competitiva al costo di uno sviluppo iniziale oltre a un rapido perfezionamento e manutenzione continui. Personalizzare un agente predefinito tramite il Generatore di prompt e la configurazione delle azioni offre una via di mezzo che costa meno dello sviluppo personalizzato completo pur adattando l'agente all'organizzazione. Oltre al costo, valutare i requisiti di time-to-value, la capacità di sviluppo interno, la differenziazione strategica e la tolleranza della dipendenza fornitore e registrare la decisione in un record decisione architettura in modo che possa essere rivalutata al variare dei requisiti.

Gli agenti implementatori con una chiara comprensione della struttura dei costi sottostante rendono la capacità autonoma scalabile in modo sostenibile anziché esaurire un pool di budget. La leva di ottimizzazione dipende dal modello di calcolo dei prezzi, poiché ciò che si ottimizza per controllare il costo è diverso tra il pagamento per azione, il pagamento per conversazione e il pagamento per utente. Il principio è costante in tutti e tre: sintonizzare il consumo sul valore effettivamente consegnato, in modo che un agente capace non bruci silenziosamente il budget più velocemente di quanto restituisca il risultato aziendale.

In Flex Credits, ottimizzare significa ridurre al minimo le azioni per risultato aziendale preservando la qualità. Risolvere le richieste semplici in una singola azione anziché in un flusso di lavoro a più fasi, in modo che rispondere a una domanda frequente o eseguire una ricerca di routine non consumi i crediti di una catena di tre azioni. Consolidare le operazioni in un'unica azione dove è più opportuno, combinando recupero, analisi e risposta anziché pagare per ognuna separatamente quando una sola azione sarebbe utile. Inserisci nella cache le risposte per le richieste ripetute in modo che le domande frequenti servano dalla cache anziché consumare nuove azioni su ogni query identica, che è la leva di efficienza più grande sotto questo modello quando una quota significativa di query viene ripetuta.

In Prezzi per conversazione, ottimizzazione significa risolvere i problemi in una singola conversazione anziché in più conversazioni. Progettare i confini e i timeout delle sessioni in modo che una conversazione venga mantenuta in modo appropriato senza terminare prematuramente e forzare una nuova conversazione fatturabile. Concentrare la capacità degli agenti sulla risoluzione della prima conversazione in modo che un'operazione venga completata entro la conversazione iniziale anziché richiedere un follow-up. Tenere traccia della percentuale di risoluzione della prima conversazione come metrica di efficienza dei costi e scoraggiare l'espansione dell'ambito in cui un utente apre conversazioni separate per problemi correlati che il contesto della conversazione esistente avrebbe potuto gestire.

Negli abbonamenti Per utente, ottimizzazione significa massimizzare il valore restituito da ogni utente con licenza, poiché il consumo non è misurato e il costo è fisso per posto. Concentrarsi sull'adozione in modo che gli utenti con licenza interagiscano attivamente con l'agente, tengano traccia dell'utilizzo per identificare gli utenti con basso utilizzo per una formazione mirata o una riassegnazione delle licenze e colleghino le interazioni degli agenti ai risultati aziendali in base alla popolazione di utenti in modo che i casi d'uso di valore elevato giustifichino l'investimento, mentre l'utilizzo di valore basso segnali la necessità di ottimizzare o di utilizzare un modello di prezzi diverso. Esaminare le popolazioni di utenti con cadenza in modo che le licenze rimangano allineate all'utilizzo effettivo.

Indipendentemente dal modello di calcolo dei prezzi, l'architettura influisce sul costo. Implementare agenti di triage che gestiscono l'instradamento iniziale con una logica semplice e indirizzano gli utenti a un agente specializzato solo quando la complessità lo richiede, in modo che le chiamate complesse costose si verifichino solo quando sono giustificate. Ritornare all'automazione tradizionale per gli scenari deterministici in cui è sufficiente una logica basata su regole, consentendo ai flussi di gestire i percorsi deterministici a costi inferiori mentre gli agenti gestiscono le situazioni ambigue che richiedono davvero un ragionamento. Recuperare i dati di base in modo selettivo, invocando la ricerca vettoriale e il recupero dei documenti solo quando il ragionamento dell'agente lo richiede anziché su ogni interazione, in modo che il consumo di Data 360 tenga traccia delle esigenze effettive. Questi schemi mantengono il costo di ragionamento e consumo dell'architettura proporzionale alla difficoltà del lavoro.

Il monitoraggio dei costi per gli agenti autonomi è più difficile rispetto ai carichi di lavoro tradizionali, poiché gli agenti non seguono uno schema di richiesta-risposta prevedibile. Un agente può ripetere il ragionamento in più fasi, invocare strumenti in modo adattivo in base alle condizioni di runtime e coordinare altri agenti, il che produce un consumo di credito altamente variabile e difficile da prevedere. Senza monitoraggio, un agente che esegue un lavoro iterativo profondo può consumare un volume elevato di crediti prima che qualcuno intervenga e la progettazione rapida inefficiente o i loop di ragionamento ridondanti possono tranquillamente svuotare i budget di un intero parco agenti. Una governance efficace richiede quindi visibilità in tempo reale sui consumi per agente e per operazione, avvisi automatici e controlli che impediscano costi eccessivi pur mantenendo l'autonomia che rende utili gli agenti. Anche la governance finanziaria degli agenti necessita di una proprietà chiara e di un'approvazione a livelli creata per il consumo variabile anziché per i costi di calcolo statici.

Salesforce Digital Wallet è lo strumento integrato per monitorare i prodotti basati sul consumo, inclusi i crediti Flex Agentforce, e le organizzazioni che utilizzano i crediti Flex dovrebbero impostarlo come meccanismo principale di monitoraggio dei costi anziché creare cruscotti digitali personalizzati per replicare ciò che offre. Digital Wallet offre dati sui consumi quasi in tempo reale con approfondimenti sull'utilizzo a livello di azione, una suddivisione per agente che mostra quali agenti consumano di più, avvisi sui consumi proattivi e tendenze storiche per l'analisi e la previsione degli schemi. Abbinare il monitoraggio al modello di prezzi. In Crediti flessibili, tenere traccia del consumo per agente, popolazione di utenti, periodo di tempo e tipo di azione e integrare Digital Wallet con cruscotti digitali personalizzati che collegano il consumo di credito alle transazioni aziendali. In Prezzi per conversazione, monitorare i volumi delle conversazioni, la durata media e le percentuali di completamento. In Abbonamenti per utente, monitorare l'utilizzo anziché il consumo, monitorando gli utenti attivi e il valore aziendale per utente in modo che l'investimento nella licenza offra un valore proporzionale.

L'attribuzione dei costi per interazione collega il consumo alle transazioni aziendali e rivela il costo per caso risolto, lead qualificato o ordine elaborato, consentendo il calcolo del ROI e il confronto tra casi d'uso. L'avviso budget attiva una notifica quando il consumo si avvicina a soglie definite, ad esempio il 70% e l'85% del budget, in modo che l'ottimizzazione avvenga prima che venga raggiunto un limite. Configurare gli avvisi per agente e per caso d'uso anziché solo a livello di organizzazione per localizzare un problema alla sua origine. Il rilevamento dell'anomalia evidenzia l'improvviso picco di consumo che segnala uno schema di utilizzo imprevisto o un loop di ragionamento che richiede un'analisi. Condividere i cruscotti digitali dei costi con gli stakeholder aziendali e i team tecnici in modo che la trasparenza favorisca un utilizzo degli agenti consapevole dei costi.

Applicare la governance finanziaria prima di impegnare la spesa in un'architettura agente. Richiedere un caso aziendale per un investimento degli agenti che copra il TCO previsto in 3-5 anni nel modello di prezzi selezionato, i risultati aziendali previsti con un metodo di misurazione, un confronto con alternative che includono processi manuali e automazione tradizionale e una valutazione del rischio che copra qualità, sicurezza e rischio operativo. Definire soglie di approvazione che separino gli investimenti che un reparto può autorizzare da quelli che richiedono l'approvazione esecutiva, in modo che un agente ad alto investimento o ad alto rischio riceva un esame proporzionato. Obbligare le distribuzioni pilota che convalidano le ipotesi prima della produzione completa, poiché un pilota rivela il consumo effettivo, la qualità e l'adozione che influenzano sia la decisione di investimento in produzione che la selezione del modello di prezzi.

Gestire la proprietà dell'agente come portafoglio anziché come agente per agente, poiché una visualizzazione portafoglio rivela le opportunità di ottimizzazione che una revisione per un singolo agente non consente. Esaminare tutti gli agenti insieme, confrontando costi, utilizzo, valore aziendale e allineamento strategico, e definire criteri di ritiro che ritirino gli agenti con bassa adozione, scarso ROI, funzionalità sostituite o costi eccessivi, in modo che gli agenti di basso valore non accumulino e consumino budget a tempo indeterminato. Riallocare gli investimenti dagli agenti con basse prestazioni alle opportunità di valore elevato come una pratica continua che riallinea la spesa alle priorità in evoluzione anziché una ripulitura singola.

L'allocazione dei costi crea responsabilità per il consumo degli agenti e le organizzazioni la implementano tramite gli stessi due modelli validi per il resto della piattaforma. Showback riporta i costi degli agenti per unità operativa senza alcun addebito interno, creando consapevolezza dei costi e informando le discussioni sull'ottimizzazione senza contestare la fatturazione interna. Il chargeback alloca i costi effettivi degli agenti alle unità operative consumatrici, il che favorisce un comportamento di ottimizzazione più forte poiché il costo influisce direttamente su un budget dipartimentale, ma richiede un metodo di allocazione preciso per evitare controversie. Un approccio ibrido applica il chargeback agli agenti di produzione a volume elevato, mentre utilizza lo showback per gli agenti sperimentali o a volume ridotto, bilanciando la responsabilità per gli investimenti importanti e la flessibilità per l'innovazione.

Le architetture degli agenti introducono considerazioni sulla sostenibilità, poiché l'inferenza del modello con linguaggio ampio è computazionalmente intensiva e alcuni agenti vengono eseguiti in modo continuo anziché solo in transazioni attivate da utenti discreti. Gli agenti proattivi, in uscita e pianificati operano senza un utente aggiornato, gli agenti conversazionali accumulano il consumo in molti turni e la ricerca vettoriale, la preparazione del contesto e l'esecuzione delle azioni aumentano il carico dell'infrastruttura. La progettazione sostenibile degli agenti riduce al minimo gli sprechi computazionali mantenendo l'esperienza reattiva. Come nel pilastro Ottimizzazione delle risorse e dei costi, la relazione tra una soluzione e le emissioni del data center è indiretta. L'efficienza di un singolo tenant non riduce direttamente le emissioni. Tuttavia, gli incrementi di efficienza in tutti i tenant aiutano Salesforce a eseguire l'infrastruttura a un utilizzo più elevato e a rinviare l'espansione della capacità. Inoltre, le procedure di sostenibilità di base del pilastro Ottimizzazione delle risorse e dei costi si applicano agli agenti e le strategie di efficienza che seguono riguardano entrambi gli aspetti specifici dei sistemi conversazionali basati su modelli di linguaggio di grandi dimensioni. Ognuna di esse riduce anche i costi, motivo per cui sostenibilità e rapporto qualità-prezzo sono la stessa disciplina misurata in base a risultati diversi.

Poiché l'inferenza è il componente che richiede più risorse in un'architettura agente, l'efficienza viene ripagata con una lunghezza rapida, l'utilizzo del contesto e il caching. Ottimizzare i prompt per trasmettere l'intento in un minor numero di token rimuovendo istruzioni dettagliate ed esempi ridondanti, poiché un prompt più breve riduce il calcolo del precompilazione in modo proporzionale anche se non modifica il calcolo della generazione della risposta. Gestire la finestra contesto riepilogando la cronologia delle conversazioni dopo i primi turni e restituendo solo i campi essenziali di ogni azione, in modo che il budget del token inserito in ogni inferenza rimanga limitato anziché crescere con la conversazione.

La ricerca vettoriale e le query a profilo unificato consumano risorse di calcolo, quindi la stessa disciplina di limitazione dei risultati e di filtro che controlla i costi di radicamento riduce anche il carico di infrastruttura del radicamento. Impostare i primi k limiti per restituire solo i risultati utilizzati dall'agente, poiché il recupero di 50 quando 5 informa la risposta genera 45 risultati non utilizzati che consumano il budget del token di base senza alcun vantaggio e utilizzare i filtri dei metadati per restringere la ricerca prima della classificazione delle similarità. Eseguire query sui profili unificati per assemblare il contesto completo in un'unica operazione anziché eseguire query separate su più oggetti per ogni turno e memorizzare nella cache i profili per gli agenti con elevata affinità con gli utenti, ad esempio un agente di vendita che lavora con un insieme fisso di account, in modo che l'assemblaggio contesto ripetuto non ripeta la query.

Poiché le azioni degli agenti consumano query SOQL, operazioni DML e tempo CPU, la disciplina di in blocco, caching e asincrona del pilastro Ottimizzazione delle risorse e dei costi si applica direttamente alle azioni degli agenti. Progettare le azioni per accettare le raccolte in modo che l'aggiornamento di molti record sia un'operazione anziché molte, utilizzare le query di relazione per recuperare i dati controllanti e controllati in un'unica istruzione, memorizzare nella cache della piattaforma i dati di riferimento e il DML batch in una raccolta anziché per record. Ove possibile, spostare le operazioni che superano i limiti sincroni in Area di attesa o Batch Apex, elaborare in modo asincrono il lavoro non urgente, ad esempio il calcolo del punteggio in blocco o l'arricchimento storico, e pianificare processi batch attivati dall'agente per le finestre di attività ridotta, in modo che il carico si distribuisca nel tempo anziché concentrarsi durante l'orario di ufficio. Monitorare l'esecuzione asincrona in modo che un backlog dell'area di attesa segnali un'esigenza di pianificazione della capacità prima che diventi un errore.

Poiché gli schemi di consumo degli agenti evolvono man mano che l'utilizzo aumenta, la sostenibilità richiede un monitoraggio continuo anziché un passaggio singolo. Tenere traccia dei token medi per inferenza attraverso la telemetria di utilizzo disponibile in modo che una dimensione del prompt crescente evidenzi un'opportunità di ottimizzazione, monitorare la distribuzione della lunghezza della conversazione in modo che le conversazioni illimitate rivelino un problema di confine dell'operazione e analizzare la frequenza di esecuzione delle azioni in Monitoraggio evento in modo che un'azione ad alta frequenza diventi una priorità di ottimizzazione. Esaminare gli schemi di query di Data 360 per trovare query comuni che meritano il caching o il precalcolo, tenere traccia del tasso di hit della cache semantica in modo che un tasso basso attivi la regolazione della soglia e misurare i percentili di latenza in modo che la latenza della coda evidenzi eventuali colli di bottiglia. Esaminare regolarmente l'utilizzo degli agenti per verificare la fluttuazione dell'ambito. Ad esempio, analizzare un agente la cui durata media della conversazione passa da una manciata di turni a molti in diversi mesi. Perfezionare i confini dell'agente in modo che il consumo torni al livello previsto. Alcune di queste superfici di monitoraggio espongono l'utilizzo nei cruscotti digitali aggregati anziché come registro per inferenza discreto, pertanto verificare l'esatta telemetria disponibile per la configurazione quando si progetta il monitoraggio.

L'ottimizzazione delle risorse determina se le architetture degli agenti si estendono man mano che la popolazione cresce e i casi d'uso si espandono, mentre l'ottimizzazione dei costi determina se tale scala restituisce un valore aziendale proporzionale. Queste due decisioni costituiscono un unico mandato:

• Efficienza architetturale: progettare le azioni con l'esecuzione in blocco, l'SOQL del budget nelle catene di azioni, spostare l'elaborazione pesante in modalità asincrona, ottimizzare il consumo dell'API tramite schemi compositi e basati sugli eventi, gestire le finestre di contesto tramite la definizione delle priorità e il riepilogo e creare architetture componibili da componenti riutilizzabili.
• Indicazioni finanziarie: selezionare deliberatamente il modello di calcolo dei prezzi, modellare il TCO completo prima di impegnarsi, monitorare il consumo rispetto ai risultati aziendali e governare l'investimento tramite l'approvazione a livelli e la revisione del portafoglio.

Le organizzazioni che padroneggiano questi schemi offrono esperienze reattive agli agenti entro i limiti della piattaforma mantenendo la spesa allineata al valore restituito dagli agenti.

La guida di base all'ottimizzazione delle risorse e dei costi per tutte le soluzioni Salesforce, inclusi l'ottimizzazione delle prestazioni, i limiti governor, l'analisi del TCO, la disciplina delle licenze e la governance dei costi, si trova nel pilastro Ottimizzazione delle risorse e dei costi. I componenti del programma di governance degli agenti, supervisione umana e sicurezza sono collegati ai pilastri Trust ed Fairness. Le istruzioni dettagliate sull'implementazione degli agenti in questo documento, che riguardano efficienza delle risorse, economia, ottimizzazione delle azioni, governance e sostenibilità, sono raccolte nella libreria degli schemi agenti.

Condividere i propri commenti sul framework ben progettato.