Come addomesticare lo zoo degli agenti AI con Nasiko
Quando esegui un singolo agente Python per i test, tutto funziona in modo prevedibile. Aggiungi un secondo in TypeScript, un terzo in Go, e iniziano i problemi. Gli agenti iniziano a chiamarsi direttamente, le API key dei modelli si spargono tra configurazioni e log, e quando un dialogo entra in loop, i token volano via a migliaia in un paio di minuti.
Il team di Nasiko-Labs ha affrontato questo problema nel modo in cui gli ingegneri di rete affrontano i microservizi. Il progetto Nasiko funge da control-plane unificato per gli agenti, gestendo routing, autorizzazione, protezione dai loop infiniti e raccolta di telemetria. Gli agenti stessi sono isolati dal mondo esterno e comunicano esclusivamente attraverso la specifica A2A (Agent-to-Agent v1.0).
Cosa può fare questa piattaforma
L'intero sistema è progettato attorno all'idea di un singolo punto di ingresso. Gli agenti fisicamente non accettano connessioni in entrata dall'esterno. Ogni richiesta tra agenti passa attraverso il server, dove vengono verificate le regole di accesso e sottratti i limiti.
Routing intelligente delle chiamate
Il client o l'agente chiamante non ha bisogno di conoscere l'ID specifico del servizio target. All'interno di Nasiko, una pipeline a tre stadi seleziona l'esecutore. Prima, il sistema filtra i candidati per similarità vettoriale delle descrizioni, poi li riordina in base al contesto del dialogo corrente, e un LLM leggero separato effettua la scelta finale.
Gestione sicura delle chiavi e LLM Router
Invece di hardcodare le chiavi API nelle variabili d'ambiente di ogni container, agli agenti viene assegnato un indirizzo interno e un token di breve durata. Il router proxy interno sostituisce la chiave del provider corretta al volo. I segreti non finiscono mai nei log o nel codice dei container.
Protezione dai loop infiniti e dalle cascate
Se due agenti decidono di ping-pongare all'infinito l'un l'altro, il saldo dei token si esaurisce rapidamente. Nasiko mantiene contatori in Redis per la profondità del grafo delle chiamate, i limiti di ramificazione, i timeout e i budget dei token per sessione. Non appena la profondità della catena supera la soglia impostata, il server interrompe l'esecuzione.
Gateway degli strumenti MCP
Per la connessione di strumenti esterni, c'è un gateway MCP integrato. Aggrega connettori (ad esempio Composio o server MCP personalizzati) e fornisce agli agenti un URL singolo per le chiamate di funzione con controllo di accesso per singolo agente.
Architettura e stack
Il backend è scritto in Rust e si compila in un singolo binario usando il framework Axum. Per la memorizzazione dello stato vengono utilizzati componenti collaudati:
- PostgreSQL memorizza utenti, configurazioni degli agenti e segreti crittografati (AES-256-GCM).
- Redis gestisce i contatori delle chiamate e la protezione dai cicli.
- Il registro OCI integrato memorizza le immagini dei container in storage compatibile con S3.
- Lo stack OpenTelemetry, Tempo e Loki raccoglie trace distribuite e log per ogni passaggio.
Ogni richiesta tra agenti diventa uno span OTel. La dashboard mostra immediatamente quanti token sono andati a un passaggio specifico e quanto è costata la chiamata in centesimi.
Avvio rapido con Docker
Per avviare l'intero stack, non è richiesta alcuna conoscenza di Rust. È necessario solo Docker Engine con il plugin Compose V2.
Prima, clona il repository e crea il file delle variabili d'ambiente:
Nel file .env, devi specificare la tua chiave OpenAI e la password dell'amministratore:
Dopo di che, avvia l'infrastruttura:
Il primo avvio richiederà qualche minuto, poiché il server Rust viene compilato all'interno del container. Il pannello di controllo sarà disponibile all'indirizzo http://localhost:8080.
Utilizzo tramite CLI
Per gli sviluppatori, c'è un'utilità console nas. Viene installata tramite Cargo:
Creare e lanciare un nuovo agente richiede quattro comandi:
Il comando deploy costruisce automaticamente il container, lo invia al registro integrato di Nasiko e registra l'agente con il router.
Dove può essere utile
Il progetto è rivolto a team che hanno superato i semplici script LangChain e stanno costruendo sistemi di produzione con decine di agenti specializzati.
Ecco alcuni scenari tipici in cui Nasiko fa risparmiare tempo:
- Pipeline multi-agente in cui gli agenti sono scritti da team diversi in linguaggi diversi (Python, Node.js, Go).
- Sistemi con requisiti di sicurezza rigorosi in cui le chiavi API di produzione non possono essere fornite a ambienti di esecuzione esterni.
- Monitoraggio dei costi LLM per attività e utenti specifici senza analisi manuale dei log.
In sintesi
Nasiko sembra un tentativo maturo di confezionare il livello di rete e l'osservabilità dei sistemi multi-agente in un unico strumento compatto. Non c'è nessun tentativo di imporre un DSL personalizzato per scrivere prompt: sei libero di scrivere la logica in qualsiasi framework, purché supporti la specifica A2A v1.0.
Se sei stanco di cablare manualmente microservizi di agenti e contare token attraverso dashboard frammentate di OpenAI e Anthropic, il progetto vale sicuramente la pena di essere eseguito localmente e provato. Per la produzione, tieni presente l'accoppiamento stretto al runtime Docker nella versione open-source, ma per lo sviluppo locale e ambienti staging interni, è già un'opzione praticabile.
Progetti correlati