Comment dompter le zoo d'agents IA avec Nasiko
Quand vous exécutez un seul agent Python pour les tests, tout fonctionne de manière prévisible. Ajoutez un deuxième en TypeScript, un troisième en Go, et les ennuis commencent. Les agents commencent à s'appeler directement, les clés API des modèles se dispersent dans les configs et les logs, et quand un dialogue boucle, les tokens s'envolent par milliers en quelques minutes.
L'équipe Nasiko-Labs a abordé ce problème comme les ingénieurs réseau traitent les microservices. Le projet Nasiko sert de plan de contrôle unifié pour les agents, gérant le routage, l'autorisation, la protection contre les boucles infinies et la collecte de télémétrie. Les agents eux-mêmes sont isolés du monde extérieur et communiquent strictement via la spécification A2A (Agent-to-Agent v1.0).
Ce que cette plateforme peut faire
L'ensemble du système est conçu autour de l'idée d'un point d'entrée unique. Les agents n'acceptent physiquement pas de connexions entrantes depuis l'extérieur. Chaque requête inter-agents passe par le serveur, où les règles d'accès sont vérifiées et les limites déduites.
Routage intelligent des appels
Le client ou l'agent appelant n'a pas besoin de connaître l'ID spécifique du service cible. Dans Nasiko, un pipeline en trois étapes sélectionne l'exécuteur. D'abord, le système filtre les candidats par similarité vectorielle des descriptions, puis les re-classe en fonction du contexte du dialogue actuel, et un LLM léger séparé fait le choix final.
Gestion sécurisée des clés et routeur LLM
Au lieu de coder en dur OPENAI_API_KEY dans les variables d'environnement de chaque conteneur, les agents se voient attribuer une adresse interne OPENAI_BASE_URL et un token à courte durée de vie. Le routeur proxy interne substitue la clé du fournisseur correct à la volée. Les secrets ne se retrouvent jamais dans les logs ni dans le code des conteneurs.
Protection contre les boucles infinies et les cascades
Si deux agents décider de se ping-ponguer indéfiniment, le solde de tokens tombe rapidement à zéro. Nasiko garde des compteurs dans Redis pour la profondeur du graphe d'appels, les limites de branchement, les timeouts et les budgets de tokens par session. Dès que la profondeur de la chaîne dépasse le seuil défini, le serveur interrompt l'exécution.
Passerelle d'outils MCP
Pour connecter des outils externes, il existe une passerelle MCP intégrée. Elle agrège les connecteurs (par exemple, Composio ou les serveurs MCP personnalisés) et fournit aux agents une URL unique pour les appels de fonctions avec contrôle d'accès par agent.
Architecture et stack
Le backend est écrit en Rust et se compile en un binaire unique utilisant le framework Axum. Des composants éprouvés sont utilisés pour le stockage d'état :
- PostgreSQL stocke les utilisateurs, les configurations d'agents et les secrets chiffrés (AES-256-GCM).
- Redis gère les compteurs d'appels et la protection contre les cycles.
- Le registre OCI intégré stocke les images de conteneurs dans un stockage compatible S3.
- La stack OpenTelemetry, Tempo et Loki collecte les traces distribuées et les logs pour chaque étape.
Toute requête entre agents devient un span OTel. Le tableau de bord affiche immédiatement combien de tokens sont allés à une étape spécifique et combien a coûté l'appel en centimes.
Démarrage rapide avec Docker
Pour faire tourner l'ensemble de la stack, aucune connaissance de Rust n'est requise. Vous avez seulement besoin de Docker Engine avec le plugin Compose V2.
D'abord, clonez le dépôt et créez le fichier d'environnement :
git clone https://github.com/Nasiko-Labs/nasiko.git
cd nasiko
cp .env.example .env
Dans .env, vous devez spécifier votre clé OpenAI et le mot de passe admin :
OPENAI_API_KEY=sk-...
ADMIN_PASSWORD=strong_password_here
Après cela, lancez l'infrastructure :
docker compose up -d
Le premier démarrage prendra quelques minutes, car le serveur Rust se compile à l'intérieur du conteneur. Le panneau de contrôle sera disponible à http://localhost:8080.
Travailler via CLI
Pour les développeurs, il existe un utilitaire console nasiko. Il s'installe via Cargo :
cargo install --path cli/
Créer et lancer un nouvel agent ne prend que quatre commandes :
# Подключаемся к локальному кластеру
nasiko connect http://localhost:8080
nasiko auth login
# Создаем проект из шаблона
nasiko new openai assistant-bot
cd assistant-bot
# Собираем и деплоим
nasiko deploy .
# Проверяем работу в чате
nasiko chat --agent assistant-bot "Привет, чем ты можешь помочь?"
La commande deploy construit automatiquement le conteneur, le pousse vers le registre intégré de Nasiko et enregistre l'agent auprès du routeur.
Où cela s'avère utile
Le projet est destiné aux équipes qui ont dépassé les scripts LangChain simples et qui construisent des systèmes de production à partir de dizaines d'agents spécialisés.
Voici les scénarios typiques où Nasiko fait gagner du temps :
- Les pipelines multi-agents où les agents sont écrits par différentes équipes dans différents langages (Python, Node.js, Go).
- Les systèmes avec des exigences de sécurité strictes où les clés API de production ne peuvent pas être distribuées aux environnements d'exécution externes.
- La surveillance des coûts LLM par tâches et utilisateurs spécifiques sans analyse manuelle des logs.
En conclusion
Nasiko ressemble à une tentative mature d'emballer la couche réseau et l'observabilité des systèmes multi-agents dans un seul outil compact. Il n'y a pas de tentative d'imposer un DSL personnalisé pour écrire les prompts : vous êtes libre d'écrire la logique dans n'importe quel framework, tant que vous supportez la spécification A2A v1.0.
Si vous en avez assez de câbler manuellement les microservices d'agents et de compter les tokens à travers les tableaux de bord fragmentés d'OpenAI et d'Anthropic, le projet mérite définitivement d'être exécuté localement et testé. Pour la production, gardez à l'esprit le couplage serré au runtime Docker dans la version open-source, mais pour le développement local et les environnements de staging internes, c'est déjà une option viable.
Projets similaires