Multi-Agenten-System auf Claude Code: Bereitstellung

Von einem einzelnen AI-Agenten zu einem Multi-Agenten-System: Praxisimplementierung

Der Entwickler begann mit Claude Code, um Aufgaben auf einem Produktivserver zu automatisieren. Die Herausforderung? Ständige Berechtigungsanfragen für Datei- und Netzwerkoperationen. Der --dangerously-skip-permissions-Parameter half zwar, doch der Agent konnte Konfigurationen nicht autonom bearbeiten.

Autonomie wurde durch tmux erreicht, das Sitzungen beibehält, und systemd für den automatischen Start. Eine systemd-Service-Datei sorgte für Neustarts nach Fehlern und lud Kontext aus Dateien:

[Unit]
Description=Claude Code Agent
After=network.target

[Service]
Type=simple
User=ubuntu
ExecStart=/usr/local/bin/claude --dangerously-skip-permissions ...
Restart=always
RestartSec=5

Der Agent mit eingeschränkten Rechten erledigte Blog-Aufgaben, blieb aber isoliert.

Agenten-Kollaboration zur Überwindung von Beschränkungen

Zwei Instanzen von Claude Code lösten die Bestätigungsblockade: eine forderte Aktionen an, die zweite bestätigte sie über tmux. So entfiel die Abhängigkeit von menschlicher Zustimmung und API-Schlüsseln. Das Claude Max-Abonnement deckt Nutzungsgrenzen ab, ohne Tokens bei API-Aufrufen zu verbrauchen.

Die Integration mit Telegram brachte Konflikte: Der offizielle MCP-Server unterstützte keine proaktiven Nachrichten, und Telethon verursachte Polling-Probleme. Die Lösung? Ein tmux-basiertes Bus-System mit send-keys und direkten claude {text}-Befehlen zur Promptübermittlung.

Nachrichtenbus als Fundament für Skalierung

Ein Nachrichtenbus auf Basis von Bun + Hono + Redis Streams ermöglichte mindestens-einmal-Lieferung über Consumer-Gruppen. Jeder Agent hat seine eigene Gruppe, und Nachrichten bleiben erhalten, bis sie bestätigt wurden.

Sicherheit:

• Admin-Tokens für Verwaltung.
• Pro-Agent-Tokens für Operationen.
• Einladungstokens mit 1-Stunden-TTL, einzigverwendbar.

Routing:

• Direkt – an einen bestimmten Agenten.
• Broadcast – an alle Agenten.
• Rollenbasiert – nach Rolle.

Unterstützt SSE für Echtzeit-Updates, Pub/Sub über Thema-Kanäle und Anhänge über gemeinsame Speicher. Das Feld from wird automatisch aus dem Token ausgefüllt.

Rollenzuweisung mittels Naruto-Archetypen

Agenten wurden nach Figuren aus der Naruto-Legende benannt, um Rollen klar zu definieren und sie von menschlichen Operatoren zu unterscheiden:

• Naruto: Orchestrator, verteilt Aufgaben.
• Sasuke: Telegram-Nutzerkonto, überwacht Gruppen.
• Itachi: Console-basierter Claude Code unter WSL für komplexe Aufgaben.
• Shikamaru: Strategischer Berater im Claude Desktop Opus.

Infrastruktur-Agenten:

• Kakashi (Sonnet): Teamleiter.
• Gai: Bewältigt schnelle Aufgaben.
• Shino: QA-Leiter.
• Hinata: Testet.
• Ibiki: Sicherheitsaudits.
• Kiba + Akamaru: Überwachung.
• Mira: Zugriff auf externe Systeme.
• Jiraiya: Logs und Wissensbasis.

Integrationen: Yonote, Yandex Tracker, Yandex Kalender, Bitrix24.

Delegation im Multi-Agenten-Environment trainieren

Anfangs führten Agenten Aufgaben eigenständig aus und ignorierten Delegation. Durch iteratives Prompt-Engineering entwickelten sie Delegationsfähigkeiten:

• Naruto prüft Team-Bereitschaft vor Aufgabenzuweisung.
• Kakashi delegiert einfache Jobs an Gai.

Das Verhalten spiegelt menschliche Führung wider: Delegation erfordert explizites Training, da Selbstausführung für LLMs der Weg des geringsten Widerstands ist.

Endarchitektur und Grenzen

System: 12 Agenten, Web-Admin-Panel mit Protokollen, Warnungen, Nachrichtensuche, Erinnerungen. In einer Woche selbst gebaut, 67 Commits.

Nicht implementiert: Telefonate, Captcha-Überwindung, Avatare für Videocalls.

Wichtige Erkenntnisse:

• Multi-Agenten-Systeme wachsen organisch aus der Lösung echter Probleme.
• tmux + send-keys schlägt MCP-Protokolle.
• Wechselseitige Bestätigung zwischen Agenten beseitigt die Abhängigkeit vom Menschen.
• Das Claude Max-Abonnement senkt API-Kosten.
• Delegation braucht iteratives Training – genau wie beim Menschen.

— Editorial Team