mngr

Che cos'è mngr?

mngr è uno strumento da riga di comando in stile Unix per gestire agent AI dove eseguono—localmente, su host remoti o all'interno di container/sandbox. Il progetto descrive mngr come un modo per creare, distruggere, elencare, clonare e connettersi agli agent in modo da poter chattare o debuggarli mantenendo l'infrastruttura degli agent accessibile e scriptable.

Il repository presenta mngr come “git per agent”, sottolineando che gli agent possono essere gestiti programmaticamente usando primitive familiari come SSH, git e tmux. È progettato in modo che non serva un servizio gestito per eseguire agent; invece, gestisci il compute e ti connetti tramite meccanismi standard.

Caratteristiche Principali

• Gestisci agent via CLI: supporta creazione, elenco, connessione e messaggistica agli agent dal terminale, incluse istanze nominate.
• Gestione processi in stile Unix basata su SSH, git e tmux: il repo indica che è costruito su questi tool, allineando le operazioni del ciclo di vita degli agent ai workflow infrastrutturali standard.
• Esegui agent su host remoti e in container/sandbox: il README evidenzia la scalabilità “su host remoti, container e sandbox”, non solo su setup locali singoli.
• Componi workflow senza lock-in a un singolo provider/interfaccia: puoi costruire workflow propri “sopra gli agent” evitando il coupling a un provider o UI specifica.
• Estensibile via plugin: il progetto nota l'estensibilità basata su plugin.

Come Usare mngr

1. Installa mngr usando lo script fornito: curl -fsSL https://raw.githubusercontent.com/imbue-ai/mngr/main/scripts/install.sh | bash.
2. Crea un agent: ad esempio, mngr create lancia un agent localmente con i default (l'esempio del README indica agent=claude, provider=local, project=directory corrente).
3. Lancia su un nuovo host remoto: ad esempio, mngr create @.modal avvia un agent su Modal con un nome host auto-generato (come descritto nel README).
4. Nomina agent e seleziona quale lanciare: usa mngr create my-task e mngr create my-task codex per eseguire un tipo di agent diverso con nome scelto.
5. Connettiti e invia un messaggio iniziale (opzionale): il README menziona il passaggio di argomenti all'agent sottostante con -- --model ... e l'uso di --no-connect --message "..." per inviare un messaggio iniziale senza aspettare.

Casi d'Uso

• Setup agent locale per sviluppo: avvia un agent dalla directory corrente con mngr create, poi chatta o debugga tramite un workflow terminale consistente.
• Scalabilità da un agent a molti su host: esegui “centinaia di agent” su host remoti, container e sandbox, usando la stessa CLI per elenco e connessione.
• Clonazione o snapshot dello stato agent: tratta configurazioni e stato degli agent come clonabili e gestibili (il README elenca azioni clone/snapshot/migrate).
• Workflow provider-agnostici: costruisci workflow di livello superiore che orchestrano tipi di agent e location di esecuzione senza legarli a un provider o interfaccia specifica.
• Pattern di accesso infrastruttura team/condivisa: usa connettività SSH-based e tool standard (tmux, git) per gestire processi agent in modo integrabile con pratiche operative esistenti.

FAQ

mngr è un servizio gestito?
No. Il README afferma esplicitamente “No managed service required”, descrivendo mngr come CLI basata su SSH, git e tmux che funziona con compute sotto il tuo controllo.

Dove possono eseguire gli agent?
Secondo il README, gli agent possono eseguire localmente oltre che su host remoti, container e sandbox.

Come installo mngr?
Il repository mostra un comando di install che pipe uno script da GitHub in bash.

Posso personalizzare agent o modello lanciato?
Il README indica che puoi passare argomenti all'agent sottostante (es. -- --model opus) e scegliere un tipo di agent (es. mngr create my-task codex).

Alternative

• Gestione processi remoti SSH-based generica + script custom: puoi eseguire sessioni tmux e connetterti via SSH, ma dovresti costruire il ciclo di vita agent, elenco e workflow di messaggistica da zero.
• Altri framework di orchestrazione agent: framework che gestiscono agent via API/UI possono essere più semplici da iniziare, ma potrebbero essere più strettamente coupled a un provider/interfaccia rispetto all'approccio “SSH + git + tmux” di mngr.
• Workflow solo container (Docker Compose/Kubernetes jobs) con attachment manuale: puoi standardizzare ambienti runtime, ma perdi il concetto “git per agent” di mngr per clonazione/snapshot e la sua interfaccia di gestione agent terminal-first.
• Tooling Git-based senza gestione ciclo di vita agent: puoi versionare codice e config agent, ma avresti bisogno di tool separati per creare/connettersi/inviare messaggi agli agent in esecuzione.