Come gli Agenti AI Implementano le Skill: Confronto Completo tra Piattaforme

Introduzione

Ogni framework per agenti AI affronta la stessa domanda fondamentale: come si rende un LLM bravo in qualcosa di specifico? Il modello stesso ha ampie conoscenze generali, ma quando serve che esegua una revisione del codice, distribuisca un’infrastruttura o navighi in Minecraft, ha bisogno di istruzioni specializzate, accesso agli strumenti e contesto di dominio.

Questo e il problema dell’iniezione di skill. E ogni framework importante lo risolve in modo diverso.

Alcune piattaforme inseriscono tutto nel prompt di sistema fin dall’inizio. Altre usano il caricamento pigro, rivelando le capacita solo quando l’agente ne ha bisogno. Alcune utilizzano database vettoriali per recuperare le skill rilevanti in base alla similarita semantica. Le differenze non sono accademiche: influenzano direttamente i costi dei token, l’affidabilita dell’agente e quante skill un agente puo realisticamente gestire.

Abbiamo analizzato 11 importanti piattaforme per agenti AI per capire esattamente dove le skill si posizionano nel prompt, quando vengono caricate, quanto costano in token e come sopravvivono quando la finestra di contesto si riempie. Non si tratta di un confronto superficiale delle funzionalita. Abbiamo esaminato codice sorgente, documentazione e diagrammi architetturali per mappare i meccanismi precisi di iniezione di ogni piattaforma.

Tabella di Confronto Principale

Ecco la panoramica completa prima di entrare nei dettagli.

Meccanismi di Iniezione: Dove, Quando e Come

Persistenza, Costo dei Token e Comportamento Always-On

Pronto a far crescere il tuo business?

Inizia oggi la tua prova gratuita e vedi i risultati in pochi giorni.

Richiedi demo Accedi

Cosa Significa Realmente “Iniezione di Skill”

Prima di addentrarci nel confronto, definiamo lo spazio del problema. La finestra di contesto di un agente AI – il testo totale che l’LLM vede a ogni chiamata – ha una dimensione fissa. Ogni token di istruzione, cronologia della conversazione, definizione degli strumenti e dati recuperati compete per lo spazio in quella finestra.

Una “skill” nel contesto degli agenti e qualsiasi pacchetto strutturato di competenze che modifica il comportamento dell’agente. Questo puo essere:

• Istruzioni che dicono all’agente come approcciare un dominio specifico (linee guida per la revisione del codice, checklist di distribuzione)
• Definizioni degli strumenti che danno all’agente funzioni invocabili (integrazioni API, operazioni sui file)
• Esempi few-shot che mostrano all’agente com’e un buon output
• Conoscenze recuperate da database vettoriali o documenti esterni

Il meccanismo di iniezione – dove e quando questo contenuto entra nel contesto – determina tre proprieta critiche:

1. Efficienza dei token: Quanti token consuma la skill, e quel costo viene pagato anche quando la skill non e necessaria?
2. Affidabilita: L’agente utilizzera costantemente la skill quando rilevante, o potrebbe perdere il segnale?
3. Scalabilita: Quante skill puo gestire l’agente prima che il sovraccarico del contesto degradi le prestazioni?

Ogni framework fa compromessi diversi su queste tre dimensioni. Esaminiamoli uno per uno.

Lo Spettro dell’Iniezione: Da Always-On a Su Richiesta

Attraverso tutte le 11 piattaforme, gli approcci all’iniezione di skill si distribuiscono lungo uno spettro dal “tutto caricato in anticipo” al “nulla caricato fino a quando non e esplicitamente necessario.”

A un estremo, piattaforme come CrewAI, SuperAGI e CAMEL-AI iniettano il contenuto completo di ogni skill attivata in ogni chiamata LLM. L’agente ha sempre a disposizione la sua competenza completa. Semplice, affidabile, ma costoso in token.

All’altro estremo, Claude Code, LangChain Deep Agents e l’API Responses di OpenAI utilizzano la divulgazione progressiva – l’agente vede solo i nomi delle skill e brevi descrizioni all’avvio, e il contenuto completo viene caricato su richiesta. Efficiente, scalabile, ma richiede che l’agente riconosca quando ha bisogno di una skill.

Nel mezzo, AutoGen Teachability e Voyager utilizzano il recupero semantico per iniettare solo le skill piu rilevanti per turno, creando un pattern di iniezione dinamico e sensibile al contesto.

E poi ci sono approcci unici: DSPy compila esempi few-shot ottimizzati offline e li integra permanentemente nei prompt dei moduli. MetaGPT codifica le skill come template di azione che si attivano solo quando un ruolo specifico transita verso un’azione specifica.

Esaminiamo ciascuno nel dettaglio.

Iscriviti alla nostra newsletter

Ricevi gratuitamente gli ultimi consigli, tendenze e offerte.

Indirizzo email

Iscriviti

Claude Code: Divulgazione Progressiva a Tre Livelli

Claude Code implementa una delle architetture di iniezione di skill piu sofisticate, utilizzando un sistema di divulgazione progressiva a tre livelli che bilancia consapevolezza ed efficienza dei token.

Livello 1: Sempre nel Contesto

All’avvio della sessione, il nome e la descrizione di ogni skill disponibile vengono iniettati in un messaggio system-reminder – un blocco di metadati che il modello vede sempre. Questo costa circa 250 caratteri per skill, consumando circa l'1% del budget della finestra di contesto per tutte le descrizioni delle skill combinate (circa 8K caratteri come budget di riserva, modificabile tramite la variabile d’ambiente SLASH_COMMAND_TOOL_CHAR_BUDGET).

Allo stesso modo, gli strumenti differiti – strumenti il cui schema JSON completo non e ancora stato caricato – appaiono come lista di soli nomi nei blocchi system-reminder. A partire da Claude Code v2.1.69, anche gli strumenti di sistema integrati come Bash, Read, Edit, Write, Glob e Grep sono differiti dietro ToolSearch, riducendo il contesto degli strumenti di sistema da circa 14-16K token a circa 968 token.

L’agente vede abbastanza per sapere cosa e disponibile senza pagare il costo in token delle definizioni complete.

Livello 2: All’Attivazione

Quando un utente digita un comando slash (ad es. /commit) o il modello fa l’auto-match di una skill in base alla sua descrizione, il corpo completo del SKILL.md viene caricato come messaggio di conversazione tramite lo strumento Skill. Questo corpo contiene le istruzioni complete – a volte migliaia di token di guida dettagliata.

Dettaglio chiave: il preprocessing della shell viene eseguito per primo (qualsiasi direttiva !command nel file della skill viene eseguita e il suo output sostituisce la direttiva), e una volta caricato, il corpo della skill resta nella conversazione per il resto della sessione.

Livello 3: Su Richiesta

Risorse aggiuntive – documenti di riferimento, script, file di asset – vengono lette solo quando il modello decide esplicitamente di utilizzare lo strumento Read per accedervi. Queste non si caricano mai automaticamente.

Comportamento alla Compattazione del Contesto

Quando la conversazione si avvicina al limite del contesto e si attiva la compattazione, Claude Code riattacca le skill invocate piu di recente con un budget di 5K token per skill e un massimo combinato di 25K. Le skill invocate piu di recente hanno la priorita. Le skill piu vecchie possono essere eliminate completamente.

Questa architettura a tre livelli significa che un agente con 20+ skill disponibili paga un costo iniziale minimo ma puo accedere alla competenza completa di qualsiasi di esse in un singolo turno.

CrewAI: Iniezione Completa in Ogni Prompt del Task

CrewAI adotta l’approccio opposto alla divulgazione progressiva. Quando una skill e attivata per un agente, il suo contenuto completo viene iniettato in ogni prompt del task che l’agente esegue.

Come Funziona

Le skill in CrewAI sono directory autonome, ciascuna con un file SKILL.md contenente frontmatter YAML (nome, descrizione, licenza, compatibilita, strumenti consentiti) e un corpo markdown. Il sistema delle skill distingue tra skill e strumenti: le skill iniettano istruzioni e contesto che modellano il modo in cui l’agente pensa, mentre gli strumenti forniscono funzioni invocabili per le azioni.

Durante l’inizializzazione dell’agente, Agent.set_skills() chiama discover_skills() per scansionare le directory delle skill a livello di metadati, poi activate_skill() per leggere i corpi completi delle skill. Al momento dell’esecuzione del task, _finalize_task_prompt() chiama format_skill_context() per ogni skill attivata e aggiunge tutto il contenuto formattato delle skill al prompt del task.

L’LLM riceve: [messaggio di sistema] + [prompt del task + TUTTI i corpi delle skill]

Implicazioni sui Token

CrewAI impone un avviso soft a 50.000 caratteri per skill ma nessun limite rigido. La documentazione raccomanda di mantenere le skill focalizzate e concise perche grandi iniezioni nel prompt diluiscono l’attenzione del modello – una preoccupazione reale data la ricerca sulla degradazione del contesto.

Il compromesso e diretto: l’agente ha sempre la competenza completa disponibile (alta affidabilita), ma il costo dei token scala linearmente con il numero di skill per task (bassa efficienza). Per agenti con 1-2 skill focalizzate, funziona bene. Per agenti che necessitano di set di capacita ampi, diventa costoso rapidamente.

Nessuna Persistenza Cross-Task

Ogni task riceve un’iniezione fresca. Non c’e accumulo di contenuto delle skill tra i task – il che e in realta una caratteristica, non un difetto. Significa che ogni task inizia con un contesto pulito, evitando i problemi di obsolescenza che la persistenza basata su sessione puo creare.

LangChain Deep Agents: Caricamento Controllato dall’Agente tramite SkillsMiddleware

LangChain Deep Agents implementa un sofisticato sistema di skill basato su middleware in cui l’agente stesso decide quando caricare il contenuto completo delle skill – un vero modello di divulgazione progressiva in cui l’agente controlla l’attivazione.

I Tre Livelli

Livello 1 (Indice): SkillsMiddleware analizza tutto il frontmatter dei SKILL.md all’avvio e inietta un indice leggero nel prompt di sistema. Questo indice contiene solo nomi e descrizioni, costando circa 278 token per skill contro 3.302 token per il contenuto completo.

Livello 2 (Contenuto Completo): Quando l’agente determina che una skill e rilevante, chiama read_file() sul percorso del SKILL.md della skill. Questa e una normale chiamata di strumento – il framework non inietta il corpo; l’agente prende una decisione deliberata di caricarlo. Il contenuto completo entra nella cronologia della conversazione come risultato dello strumento.

Livello 3 (Approfondimento): Materiali di supporto, documenti di riferimento e script vengono acceduti solo quando l’agente li legge esplicitamente.

Efficienza dei Token nella Pratica

Con 12 skill, la divulgazione progressiva riduce il contesto da circa 30.000 token (tutto caricato) a circa 600 token (solo indice), espandendosi a 2.000-5.000 quando le skill rilevanti vengono caricate per un task specifico. Si tratta di una potenziale riduzione dell'83-98% nel consumo di token legato alle skill.

Piu sorgenti di skill possono essere stratificate, e quando i nomi collidono, l’ultima sorgente prevale. I file superiori a 10 MB vengono automaticamente saltati.

La Differenza Chiave da Claude Code

Mentre Claude Code utilizza uno strumento Skill dedicato per attivare il caricamento, Deep Agents riutilizza lo strumento read_file esistente dell’agente. Questo significa che il meccanismo di caricamento e trasparente – l’agente legge i file delle skill nello stesso modo in cui legge qualsiasi altro file. Lo svantaggio e che non c’e un comportamento speciale di compattazione: il contenuto delle skill che entra nella cronologia della conversazione e soggetto al trimming standard dei messaggi di LangChain, senza trattamento prioritario.

OpenAI Responses API e Agents SDK: Caricamento Differito Gestito dalla Piattaforma

OpenAI implementa l’iniezione di skill attraverso due meccanismi distinti ma filosoficamente allineati: il tipo di strumento tool_search dell’API Responses e il ToolSearchTool dell’Agents SDK.

Responses API: tool_search

Il tipo di strumento tool_search (disponibile su GPT-5.4+) consente agli sviluppatori di differire grandi superfici di strumenti fino al runtime. Sono disponibili tre strategie di differimento:

• Differimento di funzione individuale: @function_tool(defer_loading=True) – il modello vede il nome e la descrizione della funzione ma lo schema dei parametri e differito. Risparmia token a livello di parametri.
• Differimento di namespace: tool_namespace(name=..., description=..., tools=[...]) – raggruppa le funzioni sotto un singolo namespace. Il modello vede solo il nome e la descrizione del namespace, risparmiando significativamente piu token.
• Differimento del server MCP: HostedMCPTool(tool_config={..., "defer_loading": True}) – differisce intere superfici di strumenti del server MCP.

Quando il modello determina di aver bisogno di uno strumento specifico, emette una chiamata tool_search. L’API restituisce 3-5 definizioni di strumenti rilevanti, iniettate alla fine della finestra di contesto per preservare il caching del prompt.

Agents SDK: ToolSearchTool

L’Agents SDK fornisce un equivalente programmatico. I namespace degli strumenti vengono registrati ma non caricati:

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

A runtime, l’agente vede solo i nomi dei namespace. Chiama ToolSearchTool("crm") per scoprire e caricare gli schemi completi, poi puo chiamare i singoli strumenti all’interno di quel namespace.

Nessuna Persistenza Cross-Richiesta

Ogni richiesta API e indipendente. Gli strumenti scoperti non persistono tra le chiamate. Questo e l’approccio piu stateless nel nostro confronto – pulito, prevedibile, ma richiede la ri-scoperta a ogni richiesta se gli strumenti cambiano.

AutoGen Teachability: Recupero Semantico Per Turno

La capacita Teachability di AutoGen adotta un approccio fondamentalmente diverso da ogni altro framework in questo confronto. Invece di iniettare contenuto statico delle skill, recupera dinamicamente “memo” rilevanti da un database vettoriale ChromaDB a ogni singolo turno.

Il Ciclo di Recupero Per Turno

Teachability registra un hook su process_last_received_message che intercetta ogni messaggio utente in arrivo prima che l’agente lo elabori:

1. Un TextAnalyzerAgent estrae i concetti chiave dal messaggio in arrivo
2. Questi concetti vengono usati per interrogare ChromaDB (utilizzando embeddings Sentence Transformer per impostazione predefinita)
3. I memo top-K piu rilevanti vengono recuperati (configurabile tramite max_num_retrievals, default 10)
4. I memo recuperati vengono aggiunti al testo del messaggio prima che l’agente lo veda

Aspetto critico: il messaggio modificato non si propaga nella cronologia della conversazione memorizzata – solo il messaggio originale viene memorizzato. Questo impedisce al contenuto dei memo di accumularsi tra i turni.

Ciclo di Apprendimento

Dopo che l’LLM risponde, un secondo hook analizza la risposta alla ricerca di nuovi apprendimenti:

1. Il TextAnalyzerAgent identifica nuove conoscenze nella risposta
2. Nuovi memo vengono estratti come coppie chiave-valore (testo di input -> testo di output)
3. Questi memo vengono memorizzati in ChromaDB, disponibili per turni e sessioni future

Questo crea un vero ciclo di apprendimento in cui l’agente accumula competenze nel tempo.

Persistenza Cross-Sessione

AutoGen Teachability e una delle sole tre piattaforme nel nostro confronto (insieme a Voyager e DSPy) che persiste le skill tra le sessioni. Il database ChromaDB risiede su disco, il che significa che un agente puo imparare dalle interazioni di lunedi e applicare quella conoscenza venerdi.

Il parametro recall_threshold (default 1.5) controlla quanto un messaggio deve essere simile a un memo memorizzato per il recupero, e reset_db puo cancellare l’intera memoria quando necessario.

Efficienza dei Token

Poiche vengono iniettati solo i memo rilevanti per turno (tipicamente 3-5), il costo dei token e naturalmente limitato indipendentemente da quanto cresce il database dei memo. Un agente con 10.000 memo memorizzati paga comunque solo per i pochi piu rilevanti per il turno corrente.

Semantic Kernel: Schemi dei Plugin come Definizioni di Strumenti Sempre Presenti

Semantic Kernel di Microsoft adotta un approccio diretto: i plugin sono collezioni di oggetti KernelFunction registrati con il Kernel, e i loro schemi vengono esposti all’LLM come definizioni di strumenti function-calling.

Due Percorsi di Iniezione

Function Calling: Quando ToolCallBehavior.AutoInvokeKernelFunctions e impostato, tutte le funzioni registrate vengono inviate all’LLM come strumenti disponibili in ogni richiesta API. L’LLM decide quali chiamare; Semantic Kernel gestisce l’invocazione e il routing dei risultati.

Template del Prompt: La sintassi dei template di Semantic Kernel ({{plugin.function}}, Handlebars o Liquid) consente di chiamare le funzioni inline durante il rendering del prompt. I risultati vengono incorporati direttamente nel testo del prompt prima che raggiunga l’LLM – una forma di valutazione anticipata piuttosto che chiamata pigra degli strumenti.

Nessuna Divulgazione Progressiva

Lo schema di ogni plugin registrato e incluso in ogni chiamata API. Non c’e caricamento differito integrato, raggruppamento per namespace o attivazione su richiesta. La documentazione raccomanda esplicitamente di importare solo i plugin necessari per uno scenario specifico per ridurre il consumo di token e le chiamate errate.

Questo rende Semantic Kernel una delle piattaforme piu prevedibili – sai sempre esattamente a cosa ha accesso l’agente – ma limita la scalabilita. Un agente con 50 funzioni registrate paga il costo completo dello schema a ogni singola chiamata.

Persistenza

La registrazione dei plugin e per istanza del Kernel e in memoria. Non esiste un meccanismo integrato per la persistenza delle skill cross-sessione.

MetaGPT: Template di Azione all’Interno di SOP Basate sui Ruoli

MetaGPT codifica le skill non come pacchetti autonomi ma come template di azione incorporati all’interno di Procedure Operative Standard (SOP) che governano il comportamento dei ruoli.

Architettura di Ruoli e Azioni

Ogni Role in MetaGPT ha un prefisso di persona iniettato nei prompt e un set di classi Action. Ogni Action contiene un proxy LLM invocato tramite aask(), che utilizza template di prompt in linguaggio naturale per strutturare la chiamata LLM.

Quando Role._act() si attiva, supporta tre modalita di reazione:

• "react": L’LLM seleziona dinamicamente le azioni in cicli pensa-agisci
• "by_order": Le azioni vengono eseguite sequenzialmente in un ordine predeterminato
• "plan_and_act": L’agente pianifica prima, poi esegue le azioni secondo il piano

Finestra di Iniezione Ristretta

Solo il template del prompt dell’Azione corrente e attivo in qualsiasi momento. L’agente non vede i template per altre azioni – vede solo il suo prefisso di ruolo piu il contesto dell’azione specifica. Questa e la finestra di iniezione piu ristretta di qualsiasi framework che abbiamo esaminato.

Le funzioni di parsing del contesto all’interno delle classi Action estraggono informazioni rilevanti dagli input, cosi ogni azione riceve un sottoinsieme curato del contesto disponibile piuttosto che l’intera cronologia della conversazione.

Persistenza a Singolo Turno

Il template viene renderizzato ex novo per ogni esecuzione dell’azione. Non c’e accumulo o persistenza cross-sessione. Questo mantiene ogni azione focalizzata ma significa che l’agente non puo costruire sul contenuto delle skill precedentemente caricato all’interno di un singolo workflow.

Voyager: Recupero di Skill Basato su Embedding per l’Apprendimento Continuo

Voyager, l’agente di esplorazione Minecraft di NVIDIA e Caltech, implementa una delle architetture di iniezione di skill piu eleganti: una libreria crescente di programmi verificati recuperati per similarita di embedding.

La Libreria delle Skill

Quando Voyager scrive codice che supera l’auto-verifica (il JavaScript Mineflayer generato funziona effettivamente nel gioco), il codice e la sua stringa di documentazione vengono memorizzati in un database vettoriale. L’embedding del docstring diventa la chiave di recupero.

Recupero Per Task

Per ogni nuovo task proposto dal curriculum automatico:

1. La descrizione del task e il feedback dell’ambiente vengono convertiti in embedding
2. Ricerca per similarita coseno contro tutti gli embedding delle skill memorizzate
3. Le 5 skill piu rilevanti vengono recuperate
4. Il codice delle skill recuperate viene incluso nel prompt dell’agente di azione come esempi few-shot

Il prompt si presenta cosi:

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

Il codice generato puo chiamare le skill recuperate per nome, abilitando la costruzione composizionale delle skill – comportamenti complessi costruiti da primitive piu semplici e verificate.

Persistenza a Vita

La libreria delle skill e il meccanismo principale di “apprendimento continuo”. Cresce durante l’intera vita dell’agente, e le nuove skill si costruiscono su quelle vecchie. A differenza della maggior parte dei framework dove le skill sono create dagli umani, le skill di Voyager vengono generate, verificate e memorizzate dall’agente stesso.

Il costo dei token e naturalmente limitato: indipendentemente dal fatto che la libreria contenga 50 o 5.000 skill, ogni task paga solo per i 5 recuperi piu rilevanti.

DSPy: Esempi Few-Shot Compilati come Skill Congelate

DSPy adotta un approccio radicalmente diverso da ogni altro framework. Invece di iniettare skill a runtime, DSPy compila dimostrazioni few-shot ottimali offline e le integra permanentemente nei prompt dei moduli.

Il Processo di Compilazione

Due ottimizzatori principali gestiscono la compilazione:

BootstrapFewShot: Utilizza un modulo insegnante per generare tracce attraverso il programma. Le tracce che superano una metrica definita dall’utente vengono mantenute come dimostrazioni. Ogni modulo dspy.Predict all’interno del programma ottiene il proprio set curato di dimostrazioni.

MIPROv2 (Multi-prompt Instruction Proposal Optimizer v2): Un processo a tre fasi:

1. Bootstrap: Generare set di dimostrazioni candidate
2. Proposta: Generare testi di istruzione candidati che sono consapevoli sia della distribuzione dei dati che delle dimostrazioni
3. Ricerca: Ottimizzazione bayesiana sullo spazio combinato di istruzioni x dimostrazioni attraverso tutti i moduli

Parametri come max_bootstrapped_demos (esempi generati) e max_labeled_demos (dai dati di addestramento) controllano quanti esempi finiscono nel prompt di ogni modulo.

Fisso Dopo la Compilazione

Una volta compilate, le dimostrazioni vengono memorizzate nell’attributo demos di ogni modulo Predict e formattate nel prompt a ogni chiamata LLM. Non cambiano a runtime – la “skill” e congelata.

Questo significa che le skill DSPy sono le piu prevedibili nel nostro confronto: il costo dei token e noto dopo la compilazione, non c’e varianza tra i turni, e l’agente vede sempre le stesse dimostrazioni. Lo svantaggio e l’inflessibilita – per cambiare le skill, bisogna ricompilare.

Persistenza

I programmi compilati vengono serializzati in JSON, includendo tutte le dimostrazioni. Sono completamente persistenti e caricabili tra le sessioni, rendendo DSPy uno dei meccanismi di memorizzazione delle skill piu durevoli.

SuperAGI: Registrazione Anticipata Basata su Toolkit

SuperAGI utilizza un pattern tradizionale di toolkit in cui tutti gli strumenti vengono registrati all’inizializzazione dell’agente.

Ogni toolkit estende BaseToolkit con:

• Attributi name e description
• Metodo get_tools() che restituisce una lista di istanze BaseTool
• get_env_keys() per le variabili d’ambiente richieste

I toolkit vengono installati da repository GitHub tramite il tool manager di SuperAGI. All’inizializzazione dell’agente, BaseToolkit.get_tools() restituisce tutti gli strumenti, e i loro schemi completi vengono esposti all’LLM come definizioni function-calling.

Non c’e caricamento differito, nessuna divulgazione progressiva e nessun filtraggio per turno. Lo schema di ogni strumento registrato e presente in ogni chiamata. Questo e il modello di iniezione piu semplice e funziona bene per agenti con set di strumenti focalizzati e piccoli, ma non scala per agenti che necessitano di decine di capacita.

CAMEL-AI: Registrazione degli Strumenti in ChatAgent

CAMEL-AI segue un pattern simile di registrazione anticipata. Gli strumenti provenienti da vari toolkit (ad es. MathToolkit, SearchToolkit) vengono passati come lista a ChatAgent(tools=[...]) all’inizializzazione.

Il framework sottolinea che le funzioni personalizzate necessitano di nomi di argomenti chiari e docstring complete affinche il modello possa comprenderne l’utilizzo – lo schema dello strumento e l’unico contenuto di “skill” che il modello vede. Non esiste un meccanismo separato di iniezione delle istruzioni.

Le aggiunte recenti includono il supporto MCP (Model Context Protocol) tramite MCPToolkit, che consente a ChatAgent di connettersi a server MCP e registrare strumenti esterni. Questo espande la superficie degli strumenti disponibili ma non cambia il modello di iniezione – tutti gli strumenti MCP scoperti vengono comunque registrati in anticipo.

Confronto Cross-Piattaforma

Quando Vengono Iniettate le Skill

Modelli di Persistenza

Sopravvivenza alla Compattazione del Contesto

Il Pattern della Divulgazione Progressiva

La tendenza architetturale piu significativa attraverso queste piattaforme e l’adozione della divulgazione progressiva – un concetto mutuato dal design UI in cui le informazioni vengono rivelate in modo incrementale in base alla necessita.

Perche la Divulgazione Progressiva e Importante

Un approccio ingenuo all’iniezione di skill – caricare tutto in anticipo – crea due problemi:

1. Spreco di token: La maggior parte delle skill non e rilevante per la maggior parte dei turni. Caricare 20 corpi completi di skill quando solo 1-2 sono necessari per turno spreca il 90%+ dei token legati alle skill.
2. Diluizione dell’attenzione: La ricerca sulla degradazione del contesto mostra che gli LLM performano peggio quando il loro contesto contiene grandi quantita di informazioni irrilevanti. Piu skill nel contesto possono effettivamente ridurre la qualita dell’applicazione delle skill.

La divulgazione progressiva risolve entrambi i problemi mantenendo un indice leggero delle skill disponibili mentre carica il contenuto completo solo quando necessario.

Variazioni di Implementazione

Claude Code utilizza un sistema dedicato: metadati delle skill nei messaggi system-reminder, uno strumento Skill per l’attivazione e ToolSearch per gli schemi differiti degli strumenti. Il framework gestisce l’iniezione automaticamente con compattazione basata su priorita.

LangChain Deep Agents utilizza la capacita di lettura file esistente dell’agente: SkillsMiddleware inietta l’indice e l’agente carica il contenuto completo tramite read_file(). Questo e piu trasparente ma offre meno ottimizzazione a livello di framework.

OpenAI Responses API utilizza il raggruppamento basato su namespace con ricerca gestita dalla piattaforma: i namespace degli strumenti forniscono descrizioni di alto livello e tool_search restituisce gli schemi rilevanti. La piattaforma gestisce interamente la logica di ricerca.

Risparmio di Token nella Pratica

I numeri sono convincenti. Con 12 skill:

• Iniezione always-on (stile CrewAI/SuperAGI): ~30.000 token
• Solo indice divulgazione progressiva: ~600 token
• Indice + 2 skill attivate: ~2.000-5.000 token

Si tratta di una riduzione dell'83-98% nel consumo di token legato alle skill per turno. In una lunga sessione con centinaia di turni, i risparmi si accumulano drasticamente.

Pattern Architetturali e Compromessi

Esaminando tutte le 11 piattaforme, emergono quattro pattern architetturali distinti:

Pattern 1: Iniezione Always-On

Utilizzato da: CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

Come funziona: Il contenuto completo delle skill o gli schemi degli strumenti sono presenti in ogni chiamata LLM.

Pro:

• Massima affidabilita – l’agente ha sempre la competenza completa disponibile
• Implementazione piu semplice – nessuna logica di attivazione necessaria
• Costi dei token prevedibili – gli stessi a ogni turno

Contro:

• Il costo dei token scala linearmente con il numero di skill
• Diluizione dell’attenzione con molte skill
• Non scala oltre ~5-10 skill per agente

Ideale per: Agenti focalizzati con 1-3 skill principali che sono sempre rilevanti.

Pattern 2: Divulgazione Progressiva

Utilizzato da: Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

Come funziona: Metadati leggeri sempre presenti; contenuto completo caricato su richiesta.

Pro:

• Scala a decine o centinaia di skill disponibili
• Costo minimo dei token quando le skill non sono necessarie
• Preserva la cache del prompt quando gli schemi completi vengono aggiunti alla fine

Contro:

• L’agente potrebbe non cogliere il segnale per attivare una skill rilevante
• Latenza aggiuntiva dal passaggio di attivazione
• Implementazione del framework piu complessa

Ideale per: Agenti generici che necessitano di accesso a molte capacita ma ne usano solo poche per task.

Pattern 3: Recupero Semantico

Utilizzato da: AutoGen Teachability, Voyager

Come funziona: Le query al database vettoriale fanno emergere skill/conoscenze rilevanti in base alla similarita semantica con il contesto corrente.

Pro:

• Costo dei token naturalmente limitato indipendentemente dalla dimensione della libreria
• La rilevanza del contenuto migliora nel tempo man mano che la libreria cresce
• Apprendimento e accumulo cross-sessione
• Nessuna attivazione esplicita necessaria – la rilevanza viene calcolata automaticamente

Contro:

• La qualita del recupero dipende dalla qualita del modello di embedding
• Rischio di recuperare informazioni obsolete o sottilmente errate
• Richiede infrastruttura di database vettoriale
• Meno prevedibile – turni diversi caricano contenuti diversi

Ideale per: Agenti che imparano dall’esperienza e devono accumulare conoscenze di dominio nel tempo.

Pattern 4: Iniezione Compilata/Statica

Utilizzato da: DSPy, MetaGPT

Come funziona: Le skill vengono compilate in contenuto fisso del prompt (DSPy) o attivate tramite template di azione rigidi (MetaGPT).

Pro:

• Comportamento piu prevedibile – stesso contenuto ogni volta
• L’ottimizzazione puo essere fatta offline (compilazione di DSPy)
• Nessun overhead a runtime per la selezione delle skill
• Comprovata efficacia per task ben definiti e ripetibili

Contro:

• Inflessibile – cambiare le skill richiede ricompilazione (DSPy) o modifiche al codice (MetaGPT)
• Non puo adattarsi a situazioni nuove al di fuori degli esempi compilati
• Il processo di compilazione di DSPy stesso richiede molte chiamate LLM

Ideale per: Pipeline di produzione con task ben definiti dove l’affidabilita prevale sulla flessibilita.

Implicazioni Pratiche per i Costruttori di Agenti

Scegliere il Pattern Giusto

La giusta architettura di iniezione delle skill dipende dal profilo del tuo agente:

Se il tuo agente ha un ruolo ristretto e ben definito (ad es. un bot per la revisione del codice, un agente di supporto clienti per un singolo prodotto), l’iniezione always-on (pattern CrewAI/SuperAGI) e la piu semplice e affidabile. Il costo dei token di 2-3 skill sempre presenti e gestibile, e si evita la complessita della logica di attivazione.

Se il tuo agente necessita di ampie capacita ma ne usa solo poche per interazione (ad es. un assistente per sviluppatori, un agente di automazione generico), la divulgazione progressiva (pattern Claude Code/Deep Agents) e il vincitore chiaro. I risparmi dell'83-98% sui token su larga scala sono troppo significativi per essere ignorati.

Se il tuo agente deve imparare e migliorare dalle interazioni (ad es. un assistente personale, un esperto di dominio che accumula conoscenze), il recupero semantico (pattern AutoGen Teachability) fornisce il ciclo di apprendimento che altri pattern non hanno. Basta assicurarsi di avere controlli di qualita su cio che entra nella base di conoscenza.

Se il tuo agente esegue pipeline ben definite (ad es. elaborazione dati, generazione di report, workflow standardizzati), l’iniezione compilata (pattern DSPy) offre il comportamento piu prevedibile e ottimizzato.

L’Approccio Ibrido

Per team di agenti in produzione dove gli agenti devono funzionare immediatamente, raccomandiamo un approccio ibrido:

Skill principali (1-2 per agente, che definiscono la loro competenza di dominio primaria): sempre iniettate nel prompt di sistema, in stile CrewAI. Queste sono capacita non negoziabili di cui l’agente ha bisogno a ogni turno.

Skill estese (capacita aggiuntive di cui l’agente potrebbe aver bisogno): solo metadati nel prompt di sistema, caricate tramite un meccanismo di ricerca/caricamento quando necessario, in stile Deep Agents. Queste espandono il set di capacita dell’agente senza pagare il costo dei token quando non sono rilevanti.

Conoscenze apprese (competenze di dominio accumulate): memorizzate in un database vettoriale e recuperate semanticamente per turno, in stile AutoGen. Questo consente all’agente di migliorare nel tempo senza la creazione manuale delle skill.

Questa architettura stratificata si mappa naturalmente su come viene costruito un prompt di sistema: data -> persona -> istruzioni di sistema -> skill principali -> indice delle skill -> contesto del ruolo/team. Le skill principali e l’indice aggiungono un costo dei token prevedibile e gestibile, mentre i corpi completi delle skill appaiono solo quando necessario.

Best Practice per il Budget dei Token Attraverso i Framework

Indipendentemente dal pattern di iniezione utilizzato, queste strategie di gestione dei token si applicano universalmente:

Ordinamento Cache-Friendly

Posiziona il contesto immutabile (istruzioni di sistema, schemi degli strumenti) all’inizio del prompt. Sui provider che supportano il caching del prompt, i token nella cache costano il 75% in meno. Sia Claude Code che OpenAI iniettano gli schemi degli strumenti scoperti alla fine del contesto specificamente per preservare i cache hit sul prefisso statico.

Offloading

Riassumi le risposte degli strumenti invece di mantenere i risultati completi nel contesto. Memorizza i dati completi in riferimenti esterni che l’agente puo leggere su richiesta. Questo e particolarmente importante per agenti che effettuano molte chiamate di strumenti per sessione.

Riduzione

Compatta la cronologia della conversazione tramite riassunti. Estrai fatti chiave da lunghi scambi in rappresentazioni condensate. Ogni framework con persistenza basata su sessione beneficia di una gestione aggressiva della cronologia.

Recupero Invece del Pre-Caricamento

Recupera dinamicamente le informazioni rilevanti a runtime piuttosto che caricare tutto in anticipo. Questo si applica a skill, basi di conoscenza e persino alla cronologia della conversazione. Gli studi mostrano che questo puo ridurre le dimensioni del prompt fino al 70%.

Isolamento

Usa sotto-agenti per task specifici in modo che il contesto di ogni agente rimanga focalizzato. Piuttosto che dare a un agente 20 skill, crea un team di 5 agenti con 4 skill ciascuno. Ogni agente mantiene una finestra di contesto snella, e il team copre collettivamente l’intero set di capacita.

Conclusione

Il modo in cui i framework per agenti AI iniettano le skill nel contesto e una delle decisioni architetturali piu consequenziali nel design degli agenti – eppure raramente viene discusso a questo livello di dettaglio.

Il settore sta chiaramente convergendo sulla divulgazione progressiva come pattern preferito per agenti generici, con Claude Code, LangChain Deep Agents e OpenAI che arrivano indipendentemente ad architetture a tre livelli simili. Nel frattempo, pattern specializzati come il recupero semantico (AutoGen, Voyager) e l’iniezione compilata (DSPy) servono nicchie importanti che la sola divulgazione progressiva non affronta.

Per i professionisti che costruiscono sistemi di agenti oggi, l’intuizione chiave e che l’iniezione di skill non e un problema con una soluzione universale. L’approccio giusto dipende dal ruolo dell’agente, dal numero di skill di cui ha bisogno, dal fatto che debba imparare nel tempo, e dalla tolleranza verso i compromessi tra costi dei token e affidabilita.

I sistemi di produzione piu robusti probabilmente combineranno piu pattern – always-on per le capacita principali, divulgazione progressiva per le skill estese e recupero semantico per le conoscenze accumulate – creando agenti che sono al contempo efficienti ed esperti.