Wie man den KI-Agenten-Zoo mit Nasiko zähmt
Wenn Sie einen einzelnen Python-Agenten zum Testen ausführen, funktioniert alles vorhersehbar. Fügen Sie einen zweiten in TypeScript, einen dritten in Go hinzu, und die Kopfschmerzen beginnen. Agenten beginnen, sich direkt gegenseitig aufzurufen, API-Schlüssel für Modelle verteilen sich über Konfigurationen und Logs, und wenn ein Dialog eine Schleife bildet, fliegen die Tokens zu Tausenden in ein paar Minuten davon.
Das Nasiko-Labs-Team hat dies genauso angepackt wie Netzwerkingenieure bei Microservices. Das Nasiko-Projekt dient als einheitliche Control-Plane für Agenten und übernimmt Routing, Autorisierung, Schutz vor unendlichen Schleifen und Telemetrie-Sammlung. Die Agenten selbst sind von der Außenwelt isoliert und kommunizieren strikt über die A2A-Spezifikation (Agent-to-Agent v1.0).
Was diese Plattform kann
Das gesamte System ist um die Idee eines einzelnen Einstiegspunkts herum konzipiert. Agenten akzeptieren physisch keine eingehenden Verbindungen von außen. Jede Inter-Agenten-Anfrage passiert den Server, wo Zugriffsregeln überprüft und Limits abgezogen werden.
Intelligentes Anruf-Routing
Der Client oder der aufrufende Agent muss nicht die spezifische ID des Zieldienstes kennen. Innerhalb von Nasiko wählt eine dreistufige Pipeline den Executor aus. Zuerst filtert das System Kandidaten durch Vektorähnlichkeit von Beschreibungen, dann wird neu gerankt basierend auf dem aktuellen Dialogkontext, und ein separates leichtgewichtiges LLM trifft die endgültige Auswahl.
Sichere Schlüsselverwaltung und LLM-Router
Statt OPENAI_API_KEY in Umgebungsvariablen jedes Containers fest zu verdrahten, erhalten Agenten eine interne Adresse OPENAI_BASE_URL und ein kurzlebiges Token. Der interne Proxy-Router ersetzt den korrekten Provider-Schlüssel dynamisch. Secrets landen niemals in Logs oder Container-Code.
Schutz vor unendlichen Schleifen und Kaskaden
Wenn zwei Agenten beschließen, sich endlos gegenseitig zu pingen, sinkt der Token-Saldo schnell auf Null. Nasiko verwaltet Zähler in Redis für Aufrufgraph-Tiefe, Verzweigungslimits, Timeouts und Token-Budgets pro Sitzung. Sobald die Ketten-Tiefe den festgelegten Schwellenwert überschreitet, bricht der Server die Ausführung ab.
MCP-Protokoll-Tool-Gateway
Für die Verbindung externer Tools gibt es ein eingebautes MCP-Gateway. Es aggregiert Konnektoren (zum Beispiel Composio oder benutzerdefinierte MCP-Server) und bietet Agenten eine einzelne URL für Funktionsaufrufe mit Zugriffskontrolle pro Agent.
Architektur und Stack
Das Backend ist in Rust geschrieben und kompiliert zu einer einzelnen Binärdatei unter Verwendung des Axum-Frameworks. Bewährte Komponenten werden für die Zustandsspeicherung verwendet:
- PostgreSQL speichert Benutzer, Agent-Konfigurationen und verschlüsselte Secrets (AES-256-GCM).
- Redis verwaltet Aufrufzähler und Zyklusschutz.
- Das eingebaute OCI-Registry speichert Container-Images in S3-kompatiblem Speicher.
- Der OpenTelemetry-, Tempo- und Loki-Stack sammelt verteilte Traces und Logs für jeden Schritt.
Jede Anfrage zwischen Agenten wird zu einem OTel-Span. Das Dashboard zeigt sofort, wie viele Tokens an einen bestimmten Schritt gegangen sind und wie viel der Aufruf in Cent gekostet hat.
Schneller Start mit Docker
Um den gesamten Stack zu starten, ist kein Rust-Wissen erforderlich. Sie benötigen nur die Docker Engine mit dem Compose V2-Plugin.
Klonen Sie zuerst das Repository und erstellen Sie die Umgebungsdatei:
git clone https://github.com/Nasiko-Labs/nasiko.git
cd nasiko
cp .env.example .env
In .env müssen Sie Ihren OpenAI-Schlüssel und das Admin-Passwort angeben:
OPENAI_API_KEY=sk-...
ADMIN_PASSWORD=strong_password_here
Danach starten Sie die Infrastruktur:
docker compose up -d
Der erste Start dauert ein paar Minuten, da der Rust-Server innerhalb des Containers kompiliert. Das Control Panel wird unter http://localhost:8080 verfügbar sein.
Arbeit über die CLI
Für Entwickler gibt es ein Konsolen-Tool nasiko. Es wird über Cargo installiert:
cargo install --path cli/
Das Erstellen und Starten eines neuen Agenten dauert vier Befehle:
# Подключаемся к локальному кластеру
nasiko connect http://localhost:8080
nasiko auth login
# Создаем проект из шаблона
nasiko new openai assistant-bot
cd assistant-bot
# Собираем и деплоим
nasiko deploy .
# Проверяем работу в чате
nasiko chat --agent assistant-bot "Привет, чем ты можешь помочь?"
Der Befehl deploy baut automatisch den Container, pusht ihn in Nasikos eingebautes Registry und registriert den Agenten beim Router.
Wo dies nützlich ist
Das Projekt richtet sich an Teams, die über einfache LangChain-Scripts hinausgewachsen sind und Produktionssysteme aus Dutzenden spezialisierter Agenten aufbauen.
Hier sind typische Szenarien, in denen Nasiko Zeit spart:
- Multi-Agenten-Pipelines, bei denen Agenten von verschiedenen Teams in verschiedenen Sprachen geschrieben werden (Python, Node.js, Go).
- Systeme mit strengen Sicherheitsanforderungen, bei denen Produktions-API-Schlüssel nicht an externe Ausführungsumgebungen weitergegeben werden können.
- Überwachung der LLM-Kosten pro spezifische Aufgaben und Benutzer ohne manuelle Log-Analyse.
Fazit
Nasiko sieht aus wie ein ausgereifter Versuch, die Netzwerkschicht und Observability von Multi-Agenten-Systemen in ein kompaktes Tool zu verpacken. Es wird nicht versucht, eine benutzerdefinierte DSL zum Schreiben von Prompts zu erzwingen: Sie können Logik in einem beliebigen Framework schreiben, solange Sie die A2A v1.0-Spezifikation unterstützen.
Wenn Sie es leid sind, Agent-Microservices manuell zu verdrahten und Tokens über fragmentierte OpenAI- und Anthropic-Dashboards zu zählen, ist das Projekt definitiv lokal ausprobieren wert. Für die Produktion beachten Sie die enge Kopplung an die Docker-Runtime in der Open-Source-Version, aber für lokale Entwicklung und interne Staging-Umgebungen ist es bereits eine praktikable Option.
Ähnliche Projekte