mngr

Was ist mngr?

mngr ist ein Unix-ähnliches Kommandozeilen-Tool zum Verwalten von KI-Agents dort, wo sie laufen – lokal, auf Remote-Hosts oder in Containern/Sandboxen. Das Projekt beschreibt mngr als Möglichkeit, Agents zu erstellen, zu löschen, aufzulisten, zu klonen und zu verbinden, damit du mit ihnen chatten oder sie debuggen kannst, während die Agent-Infrastruktur zugänglich und skriptbar bleibt.

Das Repository stellt mngr als „git für Agents“ dar und betont, dass Agents programmgesteuert mit vertrauten Mitteln wie SSH, git und tmux verwaltet werden können. Es ist so konzipiert, dass du keinen Managed Service brauchst, um Agents zu betreiben; stattdessen steuerst du die Rechenleistung selbst und verbindest dich darüber mit Standardmechanismen.

Wichtige Funktionen

• Agents per CLI verwalten: Unterstützt Erstellen, Auflisten, Verbinden und Nachrichten an Agents aus dem Terminal, inklusive benannter Agent-Instanzen.
• Unix-ähnliches Prozessmanagement auf Basis von SSH, git und tmux: Das Repo gibt an, es basiert auf diesen Tools und richtet Agent-Lebenszyklus-Operationen an Standard-Infrastruktur-Workflows aus.
• Agents auf Remote-Hosts und in Containern/Sandboxen ausführen: Das README hebt Skalierung „über Remote-Hosts, Container und Sandboxen“ hervor, nicht nur lokal.
• Workflows komponieren, ohne an einen Provider/Interface gebunden zu sein: Du kannst eigene Workflows „auf Agents aufbauen“, ohne Kopplung an einen bestimmten Provider oder UI.
• Erweiterbar via Plugins: Das Projekt erwähnt pluginbasierte Erweiterbarkeit.

So nutzt du mngr

1. mngr installieren mit dem bereitgestellten Skript: curl -fsSL https://raw.githubusercontent.com/imbue-ai/mngr/main/scripts/install.sh | bash.
2. Einen Agent erstellen: z. B. mngr create startet einen Agent lokal mit Defaults (README-Beispiel: agent=claude, provider=local, project=aktuelles Verzeichnis).
3. Auf neuem Remote-Host starten: z. B. mngr create @.modal startet einen Agent auf Modal mit auto-generiertem Hostnamen (wie im README beschrieben).
4. Agents benennen und auswählen: Mit mngr create my-task und mngr create my-task codex einen anderen Agent-Typ mit gewähltem Namen ausführen.
5. Verbinden und erste Nachricht senden (optional): Das README erwähnt das Weiterleiten von Agent-Argumenten mit -- --model ... und --no-connect --message "...", um eine erste Nachricht ohne Wartezeit zu senden.

Anwendungsfälle

• Lokale Agent-Setup für Entwicklung: Einen Agent aus dem aktuellen Verzeichnis mit mngr create starten, dann per konsistentem Terminal-Workflow chatten oder debuggen.
• Skalierung von einem zu vielen Agents über Hosts: „100er Agents“ über Remote-Hosts, Container und Sandboxen betreiben, mit derselben CLI zum Auflisten und Verbinden.
• Klonen oder Snapshot von Agent-Zustand: Agent-Konfigurationen und -Zustände wie klon- und verwaldbare Objekte behandeln (README listet clone/snapshot/migrate-Aktionen).
• Provider-agnostische Workflows: Höherstufige Workflows aufbauen, die verschiedene Agent-Typen und Ausführungsorte orchestrieren, ohne Bindung an einen Provider oder Interface.
• Team-/Shared-Infrastruktur-Zugriffs patterns: SSH-basierte Konnektivität und Standardtools (tmux, git) nutzen, um Agent-Prozesse in bestehende Operationspraktiken einzubetten.

FAQ

Ist mngr ein Managed Service?
Nein. Das README stellt klar: „No managed service required“ – mngr ist eine CLI auf Basis von SSH, git und tmux, die mit deiner eigenen Rechenleistung funktioniert.

Wo können Agents laufen?
Laut README lokal sowie über Remote-Hosts, Container und Sandboxen.

Wie installiere ich mngr?
Das Repository zeigt einen Install-Befehl, der ein Skript von GitHub in bash piped.

Kann ich den Agent oder das Modell anpassen?
Das README zeigt, Argumente an den zugrunde liegenden Agent weiterzuleiten (z. B. -- --model opus) und Agent-Typen zu wählen (Beispiel: mngr create my-task codex).

Alternativen

• Allgemeines SSH-basiertes Remote-Prozessmanagement + Custom-Skripte: tmux-Sessions per SSH ausführen und verbinden, aber du müsstest eigenen Agent-Lebenszyklus, Auflistung und Messaging-Workflow bauen.
• Andere Agent-Orchestrierungs-Frameworks: API/UI-basierte Frameworks sind einfacher zum Starten, aber stärker an einen Provider/Interface gekoppelt als mngrs „SSH + git + tmux“-Ansatz.
• Nur Container-Workflows (Docker Compose/Kubernetes-Jobs) mit manuellem Attach: Runtime-Umgebungen standardisieren, aber mngrs „git für Agents“-Konzept für Klonen/Snapshots und terminal-firstes Management verlieren.
• Git-basierte Tools ohne Agent-Lebenszyklus-Management: Agent-Code und -Configs versionieren, aber separate Tools für Erstellen/Verbinden/Messaging laufender Agents benötigen.