CrewAI vs OpenAI Agents SDK: quanto pesa legarsi a un fornitore

Due modi di dividere il lavoro

I due framework rispondono alla stessa domanda, come far collaborare più agenti, con due filosofie opposte. Nell'SDK di OpenAI il controllo passa di mano durante l'esecuzione: un agente decide, mentre lavora, di delegare a un altro. In CrewAI la divisione del lavoro si decide prima: chi scrive il codice dichiara ruoli, compiti e ordine, e l'esecuzione riempie quella struttura.

Non è una differenza estetica. Determina cosa puoi prevedere (costi, durata, percorso) e cosa devi verificare a posteriori. Vale la pena guardare i due modelli da vicino prima di parlare del tema che dà il titolo a questa pagina.

Il modello a handoff

L'SDK, verificato sulla documentazione ufficiale, si fonda su poche primitive: gli agenti (un modello con istruzioni e strumenti), gli handoff(la delega da un agente all'altro), i guardrail (validazione di ingressi e uscite), le sessioni (memoria della conversazione) e il tracciamento. Il runner esegue gli agenti, gli handoff e le chiamate agli strumenti, in un ciclo che continua finché non c'è un output finale.

Il pattern tipico è il triage: un agente di smistamento riceve la richiesta e la passa allo specialista giusto.

import asyncio
from agents import Agent, Runner

storia = Agent(
    name="Tutor di storia",
    handoff_description="Specialista per le domande di storia",
    instructions="Rispondi in modo chiaro e sintetico.",
)
triage = Agent(
    name="Triage",
    instructions="Smista ogni domanda allo specialista giusto.",
    handoffs=[storia],       # la delega la decide il modello
)

async def main():
    esito = await Runner.run(triage, "Quando è caduta Roma?")
    print(esito.final_output)

asyncio.run(main())

Il punto di forza è la leggerezza: si impara in un pomeriggio, e la delega dinamica modella bene i casi in cui non sai in anticipo quale competenza servirà. Il punto debole è speculare: il grafo delle chiamate emerge a runtime, e per capire cosa è successo ti serve il tracciamento. Non a caso è integrato.

Il modello a crew

CrewAI parte dall'altra estremità. Ogni agente ha un ruolo, un obiettivo e una backstory; ogni compito ha una descrizione e un expected_output che fissa la forma del risultato; il processo, sequenziale o gerarchico, stabilisce l'ordine. Il contratto fra i passaggi è scritto nel codice, non negoziato a runtime. Per i percorsi che devono essere deterministici ci sono i Flows, con eventi, stato e persistenza. Se il framework è nuovo per te, la guida introduttiva copre i quattro oggetti in dettaglio.

Il costo di questa esplicitezza è più codice e più concetti. Il guadagno è che un'esecuzione fallita si legge come una pipeline: sai quale compito ha prodotto l'output sbagliato, e correggi quello.

Il legame con OpenAI, senza ideologia

"Vendor lock-in" è un'accusa facile e quasi sempre imprecisa. I fatti, verificati sulla documentazione dell'SDK, stanno così.

L'SDK non è chiuso sui modelli OpenAI. Accetta qualsiasi endpoint compatibile con l'API OpenAI, configurabile a livello globale, per esecuzione o per singolo agente. In più offre due adattatori dichiarati: LiteLLM (si installa con openai-agents[litellm] e si usa con i nomi modello litellm/...) e Any-LLM. Decine di fornitori sono quindi raggiungibili.

Ma la piattaforma resta il percorso privilegiato. La stessa documentazione elenca i punti di attrito quando esci dal perimetro OpenAI: il tracciamento predefinito esporta verso la piattaforma OpenAI e senza una chiave valida produce errori 401, da risolvere disattivandolo, fornendo una chiave dedicata o sostituendo l'esportatore; molti fornitori non supportano la Responses API e vanno riportati sull'API Chat Completions; alcuni non supportano gli output strutturati con schema JSON; gli agenti voce e realtime sono legati ai modelli OpenAI.

Il tracciamento integrato, il vantaggio vero

Il punto più forte dell'SDK merita di essere detto senza giri: il tracciamento è attivo di serie. Ogni esecuzione registra generazioni del modello, chiamate agli strumenti, handoff, guardrail e perfino eventi custom, e tutto finisce nella dashboard Traces della piattaforma OpenAI, dove le esecuzioni si ispezionano passo per passo. Per il debug di un sistema multi agente è esattamente lo strumento che serve, e averlo senza scrivere una riga di configurazione è un vantaggio concreto.

I limiti documentati: serve una chiave OpenAI per l'esportazione predefinita, il tracciamento non è disponibile per le organizzazioni con politica Zero Data Retention, e le tracce risiedono sulla piattaforma OpenAI, il che per dati sensibili è una scelta da valutare. Si può disattivare o ridirigere verso processori esterni: la documentazione elenca oltre trenta integrazioni.

CrewAI, sul lato open source, offre meno: l'oggetto restituito da kickoff() riporta il conteggio dei token dell'esecuzione, utile per i costi ma non per il debug passo per passo. Il tracciamento gestito con interfaccia visuale sta nella piattaforma commerciale di CrewAI Inc., con un piano gratuito limitato a 50 esecuzioni al mese. Su questo criterio la differenza è netta e va detta: vince l'SDK.

La portabilità dei modelli, il vantaggio di CrewAI

Il vantaggio simmetrico di CrewAI è che nessun fornitore è privilegiato. La documentazione ufficiale descrive integrazioni con SDK nativi per i fornitori principali, fra cui OpenAI, Anthropic, Google, Azure e AWS Bedrock, mentre tutti gli altri passano da LiteLLM: Ollama per i modelli locali, Groq, Mistral e decine di altri. Il modello si indica con la stessa stringa fornitore/modello ovunque, e cambiarlo significa cambiare quella stringa, non riscrivere l'orchestrazione.

Anche qui serve onestà: la portabilità della sintassi non è portabilità del comportamento. I modelli più piccoli sbagliano più spesso le chiamate agli strumenti, e un crew calibrato su un modello va riverificato quando lo cambi. Ma il framework non ti rema contro, e per chi deve tenere i dati in casa con Ollama e i modelli locali questa neutralità è spesso il criterio decisivo.

Dipendenze e superficie di API

L'ultima differenza strutturale è la taglia. L'SDK di OpenAI è volutamente piccolo: cinque primitive, poche astrazioni, e la sensazione di avere tutto in testa dopo un giorno di uso. Quello che non c'è, memoria a lungo termine, basi di conoscenza, orchestrazione deterministica, lo scrivi tu o lo prendi altrove.

CrewAI copre più terreno: crew, processi, Flows, memoria, knowledge, guardrail sui task e trigger. È più da imparare e più codice da installare, con l'instradamento LiteLLM incluso. La regola pratica: un framework più grande è un vantaggio solo se usi quello che pesa. Se il tuo sistema è un triage con tre specialisti, la superficie piccola dell'SDK è un pregio; se è una pipeline con memoria, documenti aziendali e passaggi deterministici, i pezzi in più di CrewAI sono lavoro che non devi scrivere.

Il confronto punto per punto

Rilevazione del 17 agosto 2026: CrewAI 1.15.16contro l'OpenAI Agents SDK per Python. Entrambi con licenza MIT.

Il verdetto

La domanda giusta non è quale framework sia migliore, è dove vuoi che viva il tuo sistema. Se la risposta è "sulla piattaforma OpenAI", l'SDK è coerente, minimale e osservabile. Se la risposta è "dove converrà di volta in volta", il piano inclinato dell'SDK diventa un costo ricorrente e la neutralità di CrewAI un investimento.