Omnigent: un meta-harness per più CLI di agenti

Che cos'è Omnigent

Omnigent è un meta-harness open source: un unico livello di orchestrazione che utilizza gli strumenti a riga di comando degli agenti (CLI) già installati. Non sostituisce Claude Code, Codex, Cursor, OpenCode, Hermes o Pi. Li avvia, assegna a ciascuno un'attività e supervisiona il risultato all'interno di una singola sessione, applicando un unico insieme di criteri. Databricks ha pubblicato il repository nel giugno 2026 con licenza Apache 2.0 e la pagina principale riporta ancora Status: alpha.

L'affermazione pratica è circoscritta ed è utile esprimerla chiaramente. Si descrive un agente una sola volta, in YAML, specificando l'harness che lo esegue. Modificando quella riga, lo stesso agente viene eseguito tramite la CLI di un altro fornitore. Il resto della configurazione non cambia, perché Omnigent gestisce il ciclo sopra gli agenti, non quello al loro interno.

Che cos'è un meta-harness e in cosa differisce da un framework?

Un harness è il programma che inserisce un modello in un ciclo operativo. Legge il prompt, chiama gli strumenti, modifica i file e restituisce il risultato. Claude Code è un harness. Codex è un harness. Lo installi, accedi e può lavorare autonomamente.

Un framework è una libreria per la quale scrivi il codice. La importi, definisci i passaggi in Python e il tuo programma diventa l'agente. In questo caso, cambiare vendor richiede di modificare il codice, perché il client del vendor è integrato nel programma.

Un meta-harness si colloca a un livello superiore rispetto a entrambi. È un supervisore che esegue gli harness come processi figlio. Omnigent avvia la CLI del vendor, le assegna il lavoro e legge il risultato. Mantieni la CLI che hai già installato e l'abbonamento o la chiave API (application programming interface) che già utilizzi per pagarla. Questa è l'unica differenza sostanziale e determina a chi è destinato lo strumento: persone che hanno già diverse CLI di agenti funzionanti e sono stanche di gestirle una alla volta da un terminale.

Quale problema risolve un unico livello di orchestrazione?

• Cambiare fornitore richiede una sola riga. La definizione dell'agente contiene harness e model come dati, quindi spostare un ruolo da un fornitore a un altro richiede una modifica al file YAML, non una riscrittura.
• La revisione può coinvolgere fornitori diversi. Un diff scritto da un modello viene letto da un modello di un'altra azienda. Due modelli della stessa famiglia tendono a condividere gli stessi punti ciechi, quindi un secondo parere dello stesso fornitore ha meno valore.
• La policy ha un'unica sede. I limiti di spesa e le richieste di approvazione sono dichiarati nel file dell'agente e si applicano a ogni sub-agent sottostante.
• La sessione non dipende da un singolo strumento. Un'unica trascrizione copre il lavoro svolto da più CLI, quindi puoi rileggere ciò che è accaduto senza ricomporre quattro cronologie di output.

Il costo è il livello stesso. Ogni bug in Omnigent diventa un bug che si interpone tra te e un agente che prima funzionava autonomamente. In fase alpha è un costo reale, non teorico.

Dove si colloca un harness multi-agente rispetto agli strumenti per un singolo agente

Se non hai ancora eseguito un agente su un server, inizia da lì. La nostra guida a eseguire un agente di programmazione su un VPS descrive il caso del singolo agente dall'inizio alla fine, ed è la configurazione che Omnigent presuppone tu abbia già. L'ambito più ampio degli agenti AI self-hosted è il punto in cui scegliere gli agenti, mentre capire come funzionano realmente gli agenti è il punto di partenza migliore se questa terminologia è nuova.

Omnigent opera inoltre su un asse diverso rispetto a un livello di connettori. Attività come dare agli agenti accesso alle proprie origini dati riguardano le risorse che un agente può raggiungere. Omnigent riguarda quale agente viene eseguito, in quale ordine e con quali limiti. Puoi avere bisogno di entrambe le soluzioni contemporaneamente, perché non si sovrappongono.

Prerequisiti per l'installazione

• Python 3.12 o versione successiva. Il pacchetto pubblicato dichiara requires-python >= 3.12.
• tmux, perché gli harness del terminale vengono eseguiti al suo interno.
• Almeno una CLI del fornitore, già installata e con accesso già effettuato.
• Node.js 22 solo se esegui la build da un checkout git. Il wheel su PyPI include gli asset web già compilati, quindi l'installazione standard non richiede Node.

Installare una release fissata, non main

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --version 0.7.0

La parte sh -s -- non è decorativa. Senza di essa, sh interpreta --version come una propria opzione e l'installer non riceve mai il flag; di conseguenza installa la versione più recente disponibile quel giorno. In un repository che introduce modifiche incompatibili ogni poche settimane, questa è la differenza tra un sistema riproducibile e una sorpresa.

L'installer usa uv, il gestore di pacchetti Python di Astral, e propone di installare prima uv se non è presente. Se uv è già installato, salta lo script:

uv tool install --force --python 3.12 "omnigent==0.7.0"

Gli extra seguono lo stesso schema e il flag viene ripetuto: --extra e2b --extra kubernetes nello script oppure "omnigent[e2b,kubernetes]" con uv. Nota che il tag git è v0.7.0, mentre la versione del pacchetto su PyPI è 0.7.0.

uv inserisce il binario nella directory indicata da uv tool dir --bin, in genere ~/.local/bin, e l'installer propone di aggiungerla al profilo della shell. Se il comando non viene trovato subito dopo un'installazione pulita, questa è la causa. Verifica il risultato:

omni upgrade --check

Questo confronta la versione installata con l'ultima versione pubblicata e indica se è disponibile un aggiornamento, senza eseguirlo. omni e omnigent sono lo stesso programma con due nomi diversi.

Indicalo a un provider di modelli

omni setup

La procedura guidata cerca le credenziali già presenti nell'ambiente e richiede quelle mancanti. Gestisce chiavi API, sottoscrizioni dei vendor, gateway come OpenRouter o Ollama e workspace Databricks. Se sulla stessa macchina esegui già un server di modelli locali con Ollama, configura il gateway in modo che punti a quel server: il traffico non lascia mai la macchina.

Una sessione multi-agent minima

Gli agent di esempio si trovano nel repository. Clona quindi lo stesso tag che hai installato invece di main.

git clone --depth 1 --branch v0.7.0 https://github.com/omnigent-ai/omnigent.git
cd omnigent
omnigent run examples/polly/

Polly è l'orchestratore per la programmazione multi-agent incluso nel repository. La relativa configurazione dichiara i sub-agent denominati claude_code, codex, opencode, cursor, hermes e pi. Contiene inoltre una regola che rende utile eseguire l'intero esercizio: la revisione deve essere sempre eseguita da un vendor diverso da quello che ha implementato la modifica. Polly non scrive direttamente il codice. Pianifica il lavoro, suddivide l'obiettivo in attività, delega ciascuna attività e assegna ogni diff a un revisore di un altro vendor.

Prima di delegare qualsiasi attività, Polly esegue un controllo preliminare per verificare quali CLI dei sub-agent siano effettivamente presenti sulla macchina. Se è installata la CLI di un solo vendor, non è disponibile alcun altro vendor a cui assegnare il diff. Installa quindi almeno due CLI prima di valutare l'output. Debby, l'altro esempio incluso, è un agent di dibattito con due teste: una Claude e una GPT:

omni debby

È un modo rapido per verificare che due provider siano configurati, perché per produrre qualsiasi output deve poter utilizzare entrambi.

Gli agenti secondari sono dichiarati come strumenti

Il file dell’agente è in formato YAML. executor definisce l’harness, il modello e l’autenticazione. tools contiene i server MCP (model context protocol), le funzioni Python e gli agenti secondari. Un agente secondario è uno strumento con type: agent e un proprio executor, che è il meccanismo alla base di tutti gli elementi precedenti.

name: orchestrator
prompt: |
  You coordinate coding and review tasks.

executor:
  harness: claude-sdk
  model: databricks-claude-sonnet-4-6

tools:
  coder:
    type: agent
    prompt: Write and test code.
    executor:
      harness: claude-sdk
      model: databricks-claude-opus-4-7
  reviewer:
    type: agent
    prompt: Review proposed changes.
    executor:
      harness: claude-sdk
      model: databricks-claude-sonnet-4-6

omnigent run path/to/my_agent.yaml

Questi ID dei modelli provengono dall’esempio docs/AGENT_YAML_SPEC.md del progetto e corrispondono a nomi di modelli ospitati su Databricks. Sostituisci harness e model con i valori configurati da omni setup sul tuo sistema. Altri valori dell’harness previsti dalla specifica includono antigravity, copilot, kimi, qwen e acp:<slug> per qualsiasi componente che utilizzi il protocollo generico. La specifica supporta anche pass_history: true su un agente secondario; questa opzione gli passa la conversazione principale. Ogni delega consuma token aggiuntivi, quindi non abilitarla per gli agenti secondari che devono solo eseguire il compito assegnato. Se prompt di un coder gli indica di applicare la modifica minima necessaria, il reviewer riceve un diff abbastanza breve da poter essere letto davvero. In questo caso, ciò è più importante del modello scelto per ciascuno dei due ruoli.

Perché l'orchestrazione di lunga durata va eseguita su un VPS

Un'esecuzione multi-agent non è un comando di due minuti. Richiede pianificazione, delega, attesa del lavoro parallelo nei worktree Git, revisione e nuove modifiche. Chiudere il coperchio del laptop interrompe tutte queste attività. Un VPS (virtual private server) rimane attivo e mantiene la connessione di rete, quindi la sessione continua anche quando non la si controlla.

omnigent server --background
omnigent server status

Il server ospita un'interfaccia web sulla porta 6767. omnigent server status indica se è in esecuzione una sessione, mentre omnigent stop la arresta. Nelle release precedenti alla v0.7.0 il comando era omni server start, che è stato rimosso. Le guide e le schermate meno recenti quindi non corrisponderanno a ciò che viene visualizzato nel terminale.

Non pubblicare la porta 6767 su un indirizzo pubblico. Esistono due configurazioni sicure. Mantieni la porta chiusa nel firewall e inoltrala tramite SSH con ssh -N -L 6767:localhost:6767 you@your-server, quindi apri l'interfaccia web all'indirizzo http://localhost:6767 sul tuo computer. In alternativa, termina TLS (transport layer security) davanti al servizio e abilita l'autenticazione:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

La parte relativa al firewall è una normale attività di amministrazione, descritta in le nozioni di base sul firewall ufw per un VPS. Se il server esegue già container dietro Traefik davanti a diverse applicazioni Docker Compose, Omnigent è semplicemente un altro servizio nello stesso schema.

Per una distribuzione tramite container, la directory deploy/ del repository contiene una configurazione Compose: ./bootstrap.sh genera i secret in .env, quindi docker compose up -d avvia Omnigent e Postgres sulla porta 6767. DATABASE_URL seleziona Postgres o SQLite, mentre OMNIGENT_AUTH_ENABLED è impostato per impostazione predefinita su 1 all'interno dei container. È l'impostazione corretta per qualsiasi servizio raggiungibile dall'esterno.

Per quanto riguarda il dimensionamento, le note sulla distribuzione stimano il working set del server tra 512 MB e 1 GB, mentre la configurazione Fly.io fissa il valore a 1 GB. Questa stima riguarda soltanto il supervisore. Ogni sub-agent è un processo separato, con il proprio checkout e il proprio client del modello. Dimensiona quindi il server in base agli agenti. Quando il server è attivo, omnigent login https://your-host seguito da omnigent host https://your-host registra il laptop sul server, mentre omnigent attach <session_id> riprende una sessione in esecuzione da un altro dispositivo.

Esegui il sandboxing di ogni sub-agent prima di terminare

Omnigent distribuisce un sandbox a livello di sistema operativo chiamato Omnibox. Su Linux usa i namespace di bubblewrap insieme a seccomp, quindi è il kernel a imporre il perimetro, non il prompt dell'agent. Un agent il cui prompt è stato manipolato non può aggirare una regola del kernel con le sole istruzioni. Installa prima la dipendenza:

sudo apt install bubblewrap

La configurazione si trova in os_env nel file dell'agent:

os_env:
  type: caller_process
  cwd: .
  sandbox:
    type: linux_bwrap
    write_paths: [.]
    write_files: []
    read_paths: []
    allow_network: true
    cwd_allow_hidden: [.venv]
    env_passthrough: []
    egress_rules: []
    credential_proxy: []

La directory di lavoro è in sola lettura finché non la inserisci in write_paths, quindi un agent che si comporta in modo anomalo non può scrivere fuori dal workspace. I dotfile restano nascosti finché non vengono indicati in cwd_allow_hidden; un'autorizzazione di lettura ampia non espone quindi indirettamente .ssh o .aws. Imposta egress_rules e tutto il traffico HTTP e HTTPS passerà attraverso un proxy con criterio predefinito di negazione, con ogni regola scritta come "METHODS host/path-glob". credential_proxy offre un livello ulteriore: l'agent conserva soltanto un placeholder e il proxy sostituisce il secret reale quando la richiesta esce, quindi un transcript esposto non contiene nulla di utilizzabile. In una configurazione con più harness, ogni sub-agent ha il proprio blocco sandbox nel proprio file di configurazione in agents/; in questo modo puoi negare l'accesso alla rete a un reviewer, lasciandolo invece all'implementer.

La documentazione indica questo limite, che è importante. Il sandbox del sistema operativo si applica alle chiamate agli strumenti sys_os_* e ai terminali. Non copre i server MCP e non copre il processo supervisor di Omnigent. Un server MCP avviato da te viene eseguito fuori dal sandbox con i tuoi permessi. Per questo il modello più sicuro resta una macchina usa e getta per ogni agent, argomento trattato in eseguire coding agent in una VM usa e getta. L'altra parte del problema riguarda le credenziali; tenere i secret fuori dalla portata di un agent diventa più difficile, non più semplice, quando sei sub-agent condividono lo stesso host.

I limiti di spesa sono policy dichiarate nello stesso file:

policies:
  budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.00
      ask_thresholds_usd: [1.00, 3.00]

Un'esecuzione che pianifica con un vendor, implementa con un secondo e revisiona con un terzo sostiene costi in tre punti contemporaneamente. Imposta quindi il limite prima della prima esecuzione senza supervisione, non dopo la prima fattura. I componenti integrati includono anche max_tool_calls_per_session e ask_on_os_tools, che richiede l'approvazione prima delle operazioni sui file e nella shell. Le nostre indicazioni su tenere sotto controllo i costi degli agent AI su un VPS si applicano direttamente anche qui, e in misura maggiore, perché i sub-agent paralleli moltiplicano la velocità di consumo.

Quanto velocemente evolve questo repository?

[
  {
    "version": "v0.2.0",
    "released": "2026-06-19",
    "interval": 3
  },
  {
    "version": "v0.3.0",
    "released": "2026-06-27",
    "interval": 8
  },
  {
    "version": "v0.4.0",
    "released": "2026-07-03",
    "interval": 6
  },
  {
    "version": "v0.5.0",
    "released": "2026-07-10",
    "interval": 7
  },
  {
    "version": "v0.5.1",
    "released": "2026-07-10",
    "interval": 0
  },
  {
    "version": "v0.6.0",
    "released": "2026-07-21",
    "interval": 11
  },
  {
    "version": "v0.7.0",
    "released": "2026-07-27",
    "interval": 6
  }
]

Queste sono le date di rilascio pubblicate nella pagina delle release del progetto, consultata il 3 agosto 2026. Tra 2026-06-19 e 2026-07-27 sono state pubblicate 7 release contrassegnate, e l'intervallo più lungo tra due release qualsiasi è stato di 11 giorni. v0.5.1 è stata pubblicata lo stesso giorno della release precedente. La prima release, 0.1.1 del 16 giugno 2026, è esclusa dal grafico perché non esiste un tag precedente da usare come riferimento.

Due di queste release hanno reso non validi comandi già documentati nelle guide. La v0.7.0 ha rimosso omni server start in favore di omni server --background. La v0.6.0 ha rinominato l'extra omnigent[memory] in omnigent[hindsight], quindi una riga di installazione copiata da una guida di giugno non funziona su una build di luglio. Questo dimostra perché è necessario usare --version nel comando di installazione e specificare un tag nel tuo git clone, non per una semplice preferenza di stile.

Cosa non gli affiderei ancora

Ad agosto 2026 il repository conta circa 8.1k stelle, 1.2k fork e circa 350 issue aperte; la prima release pubblica risale a sette settimane fa. Le stelle misurano l’interesse, non la maturità. Il progetto si definisce alpha e la cronologia delle release riportata sopra conferma che si tratta effettivamente di una versione alpha.

• Non lo eseguirei su un host che contiene credenziali di produzione, perché la sandbox non copre i server MCP né il supervisor.
• Non lascerei un’esecuzione senza supervisione in assenza di una policy cost_budget, perché tre vendor possono addebitare costi in parallelo e non c’è nessun altro meccanismo che lo impedisca.
• Non esporrei il server su un indirizzo IP pubblico senza avere impostato OMNIGENT_AUTH_ENABLED e senza TLS davanti al server.
• Non considererei ancora stabile la configurazione YAML dell’agent tra versioni minor, quindi fisserei la versione e leggerei le release note prima di eseguire l’upgrade.

C’è un altro aspetto da conoscere per evitare sorprese: v0.6.0 ha aggiunto la telemetria di utilizzo anonimizzata e il progetto la documenta in una pagina dedicata alla telemetria. Leggi quella pagina e valuta consapevolmente la scelta se la macchina gestisce attività dei clienti.

Oggi Omnigent è realmente efficace per il caso d’uso per cui è stato progettato. Hai tre o quattro CLI per agent, paghi già i relativi servizi e vuoi che una scriva mentre un’altra esegue la revisione. Oggi questo funziona, su una sola macchina, con una sandbox reale su Linux. Considera tutto ciò che va oltre questo scenario come promettente ma ancora incompleto.

FAQ

Omnigent è un agent oppure un componente che esegue agent?

Esegue agent. Omnigent è un meta-harness: avvia le CLI dei vendor già installate, come Claude Code, Codex o OpenCode, assegna attività a ciascuna e supervisiona i risultati in un'unica sessione. Non include un proprio modello. Per questo è diverso da un framework, in cui si scrive codice Python usando una libreria e il proprio programma diventa l'agent.

Devo installare Claude Code e Codex prima che Omnigent sia utile?

È necessario installare e autenticare almeno una CLI di un vendor, perché Omnigent controlla questi programmi invece di sostituirli. Per l'esempio Polly incluso è consigliabile averne almeno due di vendor diversi. La regola di Polly prevede che la revisione sia sempre eseguita da un vendor diverso da quello che ha implementato la modifica. Se è presente una sola CLI, non c'è quindi un secondo vendor a cui inviare il diff.

Come installo una versione specifica di Omnigent invece dell'ultima?

Passa --version allo script di installazione usando sh -s --, come in sh -s -- --version 0.7.0. Senza -s --, il flag viene interpretato da sh stesso e lo script installa la release più recente. Se uv è già presente, uv tool install --force --python 3.12 "omnigent==0.7.0" svolge la stessa funzione. Il tag git è v0.7.0, mentre la stringa della versione PyPI è 0.7.0.

Il sandbox Omnibox è sufficiente per eseguire agent senza supervisione?

È efficace per gli aspetti che copre ed è chiaro sui limiti. Su Linux usa bubblewrap e seccomp, quindi il kernel applica i limiti a file e rete e l'agent non può disabilitarli. La documentazione specifica che il sandbox si applica alle chiamate agli strumenti sys_os_* e ai terminali, ma non ai server MCP né al processo supervisor di Omnigent. Un server MCP viene quindi eseguito con i normali permessi dell'utente. Per questo, per le attività senza supervisione, una macchina virtuale temporanea per ogni agent offre ancora un isolamento più forte.

Quanta memoria richiede un server Omnigent su un VPS?

Le note di deploy del progetto indicano per il server un working set di circa 512 MB-1 GB, mentre la configurazione Fly.io assegna 1 GB. Questa dotazione copre il supervisor e l'interfaccia web, accessibile soltanto sulla porta 6767. Ogni sub-agent è un processo separato con una propria copia di lavoro e un proprio client del modello. Inoltre, le esecuzioni in stile Polly usano worktree git paralleli. È quindi necessario dimensionare RAM e disco in base al numero di agent da eseguire contemporaneamente, non in base al solo server.