Un agente che chiama un’API cloud per ogni decisione “affitta” la propria intelligenza: serve una chiave, si accumula un costo per token e ogni richiesta esce dalla tua macchina prima di ottenere una risposta. Un agente costruito per girare in locale salta tutto questo, ma richiede uno strato di orchestrazione che sappia dialogare con un modello ospitato sul tuo hardware. Un articolo di KDnuggets raccoglie sette strumenti Python usati nel 2026 per costruire, coordinare ed eseguire agenti su infrastruttura locale, ordinati dal runtime che serve il modello ai framework che decidono cosa farne.
Il runtime e i mattoni di base
Alla base c’e’ Ollama, un runtime leggero per eseguire LLM open source sulla propria macchina, il piu’ vicino a un “Docker per i modelli linguistici”. Espone un’API compatibile con OpenAI, quindi si inserisce nella maggior parte dei framework senza adattatori custom; non e’ pensato per il throughput grezzo, e per carichi ad alta concorrenza i team spesso affiancano vLLM in produzione. Un livello piu’ in basso rispetto all’orchestrazione completa ci sono due strumenti con filosofie opposte: smolagents di Hugging Face, la cui logica sta in circa 1.000 righe e privilegia i CodeAgent che scrivono le azioni in codice eseguito in ambienti sandbox (ma le prestazioni degradano bruscamente sotto i 7B di parametri); e PydanticAI, costruito dal team di Pydantic per rendere type-safe input, output e chiamate ai tool, con validazione automatica dello schema e autocorrezione, particolarmente adatto a settori dove l’integrita’ dei dati conta.
Multi-agente e produzione
Quando servono piu’ agenti che collaborano, CrewAI e’ spesso il primo a cui si ricorre per la rapidita’ con cui si arriva a qualcosa di funzionante: evita dipendenze da LangChain, supporta i runtime locali via Ollama e il Model Context Protocol su stdio, SSE e HTTP. AgentScope nasce invece pensando alla produzione: la versione 2.0 offre workspace e sandbox, esecuzione isolata su locale, Docker ed E2B, oltre 27.300 stelle su GitHub e due paper peer-reviewed; la coordinazione avviene tramite un message hub con passaggio strutturato di messaggi, che mantiene le interazioni trasparenti e auditabili. LangGraph si colloca nel mezzo, come scelta di default per tutto cio’ che e’ stateful, ramificato o recuperabile: funzionando con qualsiasi backend compatibile con OpenAI, puntare un grafo a un’istanza Ollama locale e’ una modifica di una riga, e lo stesso checkpointing (pause-and-resume, time-travel debugging) funziona identico con un modello sulla tua GPU.
Governance enterprise
Per chi ha bisogno di governance e middleware da grande organizzazione senza rinunciare al locale, c’e’ il Microsoft Agent Framework, successore unificato di AutoGen e Semantic Kernel annunciato nell’ottobre 2025. Supporta out of the box Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, Amazon Bedrock, Google Gemini e Ollama, anche se i problemi segnalati dalla community si concentrano sugli adapter di provider diversi dal percorso Azure OpenAI. Come nota l’autore, i sette strumenti non competono per lo stesso compito: la scelta dipende meno da quale sia “il migliore” e piu’ dal vincolo che stai davvero risolvendo, che sia velocita’ di prototipazione, validazione dei dati, governance o stato long-running.
- Ollama e la compatibilita’ con l’API OpenAI sono il denominatore comune: quasi tutti i framework puntano a un modello locale con una modifica minima.
- Eseguire in locale non significa piu’ rinunciare alle capacita’: cambia il vincolo prioritario, non il livello di funzionalita’.
- Per il multi-agente in produzione contano audit trail e passaggio di messaggi strutturato, non solo la rapidita’ del prototipo.
Fonte: 7 Python Frameworks for Orchestrating Local AI Agents — https://www.kdnuggets.com/7-python-frameworks-for-orchestrating-local-ai-agents
Hai qualcosa da aggiungere? Unisciti alla discussione.