Omnigent: un meta-harness para varias CLI de agentes
Descubre cómo Omnigent coordina las CLI de agentes instaladas, fija la version 0.7.0 y aisla cada subagente en un VPS mediante politicas comunes.
Qué es Omnigent
Omnigent es un meta-harness de código abierto: una capa de orquestación que controla las herramientas de línea de comandos de agentes (CLI) que ya tiene instaladas. No sustituye a Claude Code, Codex, Cursor, OpenCode, Hermes ni Pi. Los inicia, asigna una tarea a cada uno y supervisa el resultado dentro de una sola sesión con un único conjunto de políticas. Databricks publicó el repositorio en junio de 2026 con la licencia Apache 2.0, y la página principal todavía muestra Status: alpha.
La afirmación práctica es limitada y conviene expresarla con claridad. Describa un agente una sola vez en YAML e indique el harness que lo ejecuta. Cambie esa línea y el mismo agente se ejecutará con la CLI de otro proveedor. No cambia nada más de la configuración, porque Omnigent controla el bucle por encima de los agentes, no el bucle interno de estos.
¿Qué es un meta-harness y en qué se diferencia de un framework?
Un harness es el programa que ejecuta un modelo dentro de un bucle. Lee el prompt, llama a herramientas, edita archivos e informa del resultado. Claude Code es un harness. Codex es un harness. Se instala, se inicia sesión y funciona de forma autónoma.
Un framework es una biblioteca contra la que se escribe código. Se importa, se definen los pasos en Python y el programa se convierte en el agente. Cambiar de proveedor implica editar el código, porque el cliente del proveedor está integrado en el programa.
Un meta-harness se sitúa un nivel por encima de ambos. Es un supervisor que ejecuta harnesses como procesos secundarios. Omnigent inicia la CLI del proveedor, le asigna trabajo y lee la respuesta. Se conserva la CLI que ya está instalada y la suscripción o la clave API (interfaz de programación de aplicaciones) que ya la financia. Esa es toda la diferencia, y determina para quién está hecha la herramienta: personas que ya tienen varias CLI de agentes funcionando y están cansadas de manejarlas una terminal cada vez.
¿Qué problema resuelve una capa de orquestación?
- Cambiar de proveedor requiere editar una línea. La definición del agente contiene
harnessymodelcomo datos, por lo que trasladar un rol de un proveedor a otro consiste en editar el archivo YAML, no en reescribirlo. - La revisión puede cruzar proveedores. Un modelo de una empresa distinta puede leer un diff generado por otro modelo. Dos modelos de la misma familia suelen compartir los mismos puntos ciegos, por lo que una segunda opinión del mismo proveedor aporta menos.
- La política tiene un único lugar. Los límites de gasto y las solicitudes de aprobación se declaran en el archivo del agente y se aplican a todos los subagentes que dependen de él.
- La sesión no depende de una sola herramienta. Una única transcripción cubre el trabajo realizado con varias CLI, por lo que puede revisar lo ocurrido sin unir cuatro historiales de desplazamiento.
El coste es la propia capa. Cada error de Omnigent se convierte ahora en un error situado entre usted y un agente que antes funcionaba por sí solo. En la fase alpha, es un coste real, no teórico.
Dónde encaja un sistema multiagente junto a las herramientas para un solo agente
Si todavía no ha ejecutado un agente en un servidor, empiece por ahí. Nuestra guía sobre ejecutar un agente de programación en un VPS cubre el caso de un solo agente de principio a fin. Omnigent presupone que ya dispone de esa configuración. El campo más amplio de los agentes de IA autoalojados es el lugar donde se eligen los propios agentes. Si estos términos son nuevos para usted, aprender cómo funcionan realmente los agentes es un mejor punto de partida.
Omnigent también pertenece a un ámbito distinto del de una capa de conectores. Trabajos como dar a los agentes acceso a sus propias fuentes de datos tratan sobre los recursos a los que puede acceder un agente. Omnigent trata sobre qué agente se ejecuta, en qué orden y con qué límites. Puede necesitar ambas cosas a la vez, pero no se solapan.
Requisitos previos a la instalación
- Python 3.12 o una versión posterior. El paquete publicado declara
requires-python >= 3.12. tmux, porque los arneses de terminal se ejecutan dentro de él.- Al menos una CLI del proveedor, ya instalada y con la sesión iniciada.
- Node.js 22 sólo si compila desde un checkout de git. El wheel de PyPI incluye los recursos web compilados, por lo que la instalación normal no necesita Node.
Instale una versión fijada, no main
curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --version 0.7.0La parte sh -s -- no es decorativa. Sin ella, sh interpreta --version como una opción propia y el instalador nunca recibe la opción, por lo que obtiene la versión más reciente de ese día. En un repositorio que publica cambios incompatibles cada pocas semanas, esa diferencia separa un sistema reproducible de una sorpresa.
El instalador usa uv, el gestor de paquetes de Python de Astral, y ofrece instalar uv primero si no está presente. Si uv ya está instalado, omita el script:
uv tool install --force --python 3.12 "omnigent==0.7.0"Los extras siguen el mismo patrón y la opción se repite: --extra e2b --extra kubernetes en el script o "omnigent[e2b,kubernetes]" con uv. Tenga en cuenta que la etiqueta de git es v0.7.0, mientras que la versión del paquete en PyPI es 0.7.0.
uv coloca el binario en el directorio que indica uv tool dir --bin, normalmente ~/.local/bin, y el instalador ofrece añadirlo al perfil del shell. Si el comando no se encuentra justo después de una instalación limpia, esa es la causa. Compruebe qué versión se instaló:
omni upgrade --checkEsto compara la versión instalada con la última versión publicada e indica si existe una actualización, sin realizarla. omni y omnigent son el mismo programa con dos nombres.
Diríjalo a un proveedor de modelos
omni setupEl asistente busca las credenciales que ya están disponibles en su entorno y solicita las que faltan. Gestiona claves de API, suscripciones de proveedores, gateways como OpenRouter u Ollama y espacios de trabajo de Databricks. Si ya ejecuta un servidor de modelos local con Ollama en la misma máquina, configure un gateway para que lo use y el tráfico no saldrá del equipo.
Una ejecución multiagente mínima
Los agentes de ejemplo están en el repositorio, así que clone la misma etiqueta que instaló en lugar de main.
git clone --depth 1 --branch v0.7.0 https://github.com/omnigent-ai/omnigent.git
cd omnigent
omnigent run examples/polly/Polly es el orquestador de programación multiagente incluido en el repositorio. Su configuración declara subagentes llamados claude_code, codex, opencode, cursor, hermes y pi, además de una regla que hace que todo el ejercicio merezca la pena: la revisión siempre la realiza un proveedor distinto del implementador. Polly no escribe código. Planifica, divide el objetivo en elementos de trabajo, delega cada uno y envía cada diff a un revisor de otro proveedor.
Antes de delegar cualquier tarea, Polly ejecuta una comprobación preliminar para determinar qué CLI de subagentes existen realmente en el equipo. Si sólo hay instalada la CLI de un proveedor, no hay nadie a quien entregar el diff. Por tanto, instale al menos dos antes de evaluar el resultado. Debby, el otro ejemplo incluido, es un agente de debate con dos cabezas: una de Claude y otra de GPT:
omni debbyEs una forma breve de confirmar que hay dos proveedores configurados, porque necesita que ambos respondan.
Los subagentes se declaran como herramientas
El archivo del agente está escrito en YAML. executor define el arnés, el modelo y la autenticación. tools contiene servidores MCP (model context protocol), funciones de Python y subagentes. Un subagente es una herramienta con type: agent y su propio ejecutor. Este mecanismo sustenta todo lo anterior.
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-6omnigent run path/to/my_agent.yamlEsos identificadores de modelo proceden del ejemplo docs/AGENT_YAML_SPEC.md del propio proyecto y corresponden a nombres alojados en Databricks. Sustituya harness y model por los valores que omni setup haya configurado en su equipo. Otros valores de arnés de la especificación son antigravity, copilot, kimi, qwen y acp:<slug> para cualquier componente que use el protocolo genérico. La especificación también admite pass_history: true en un subagente. Esta opción le entrega la conversación principal. Consume tokens en cada delegación, así que déjela desactivada en los subagentes que sólo necesiten la tarea actual. Un programador cuyo prompt le indica que realice el cambio más pequeño que funcione entrega al revisor un diff lo bastante corto para leerlo de verdad. En este caso, eso importa más que el modelo elegido para cualquiera de los dos roles.
Por qué la orquestación de larga duración debe ejecutarse en un VPS
Una ejecución multiagente no es un comando de dos minutos. Debe planificar, delegar, esperar a que terminen los worktrees paralelos de Git, revisar y volver a ejecutar. Cerrar la tapa del portátil detiene todo el proceso. Un VPS (servidor privado virtual) permanece activo y conserva su conexión de red, por lo que la sesión continúa aunque no la esté supervisando.
omnigent server --background
omnigent server statusEl servidor aloja una interfaz web en el puerto 6767. omnigent server status indica si hay una en ejecución y omnigent stop la detiene. En las versiones anteriores a v0.7.0, esto era omni server start, pero se eliminó. Por tanto, los documentos y capturas de pantalla antiguos no coincidirán con lo que muestra el terminal.
No publique 6767 en una dirección pública. Hay dos configuraciones seguras. Mantenga el puerto cerrado en el firewall y reenvíelo mediante SSH con ssh -N -L 6767:localhost:6767 you@your-server. Después, abra la interfaz web en http://localhost:6767 desde su propio equipo. Otra opción es terminar TLS (seguridad de la capa de transporte) delante de la interfaz y activar la autenticación:
OMNIGENT_AUTH_ENABLED=1 omnigent server --backgroundLa parte del firewall es una tarea habitual, descrita en los conceptos básicos del firewall ufw para un VPS. Si el servidor ya ejecuta contenedores detrás de Traefik delante de varias aplicaciones Docker Compose, Omnigent es un servicio más dentro del mismo patrón.
Para desplegar un contenedor, el directorio deploy/ del repositorio contiene una configuración de Compose: ./bootstrap.sh genera los secretos en .env y, después, docker compose up -d inicia Omnigent y Postgres en el puerto 6767. DATABASE_URL selecciona Postgres o SQLite. Dentro de los contenedores, OMNIGENT_AUTH_ENABLED usa 1 de forma predeterminada, que es la opción adecuada para cualquier servicio accesible desde el exterior.
En cuanto al dimensionamiento, las notas de despliegue estiman que el conjunto de trabajo del servidor requiere entre 512 MB y 1 GB, y la configuración de Fly.io fija 1 GB. Esa cifra corresponde sólo al supervisor. Cada subagente es un proceso independiente que mantiene su propio checkout y su propio cliente de modelo, por lo que debe dimensionar el servidor para los agentes. Cuando el servidor esté activo, omnigent login https://your-host seguido de omnigent host https://your-host registra su portátil en él, y omnigent attach <session_id> permite reanudar una sesión en ejecución desde otro dispositivo.
Aísle todos los subagentes antes de retirarse
Omnigent distribuye un sandbox a nivel del sistema operativo llamado Omnibox. En Linux usa espacios de nombres de bubblewrap y seccomp, por lo que el kernel aplica el límite en lugar del prompt del agente. Un agente al que se le haya inyectado un prompt no puede eludir una regla del kernel mediante instrucciones. Instale primero la dependencia:
sudo apt install bubblewrapLa configuración se encuentra en os_env dentro del archivo del agente:
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: []El directorio de trabajo es de sólo lectura hasta que lo incluya en write_paths, por lo que un agente que falle no puede escribir fuera del espacio de trabajo. Los archivos ocultos permanecen ocultos a menos que se indiquen en cwd_allow_hidden, lo que impide que una concesión amplia de lectura exponga de forma inadvertida .ssh o .aws. Configure egress_rules para que todo el tráfico HTTP y HTTPS pase por un proxy que deniega por defecto, con cada regla escrita como "METHODS host/path-glob". credential_proxy va un paso más allá: el agente sólo conserva un marcador de posición y el proxy sustituye ese marcador por el secreto real cuando sale la petición, de modo que una transcripción filtrada no expone ningún valor utilizable. En una configuración con varios harnesses, cada subagente incluye su propio bloque de sandbox en su propio archivo de configuración bajo agents/, por lo que puede denegar la red al revisor mientras el implementador la mantiene.
La documentación especifica este límite, y es importante. El sandbox del sistema operativo se aplica a las llamadas de herramientas sys_os_* y a los terminales. No cubre los servidores MCP ni el propio proceso supervisor de Omnigent. Un servidor MCP que inicie se ejecuta fuera del sandbox con sus permisos. Por eso el patrón más seguro sigue siendo usar una máquina desechable por agente; este tema se trata en ejecutar agentes de código en una VM desechable. La otra parte del trabajo son las credenciales, y mantener los secretos fuera del alcance de un agente resulta más difícil, no más fácil, cuando seis subagentes comparten un host.
Los límites de gasto son políticas declaradas en el mismo archivo:
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]Una ejecución que planifica con un proveedor, implementa con un segundo y revisa con un tercero gasta en tres lugares a la vez. Por eso debe establecer el límite antes de la primera ejecución desatendida, no después de recibir la primera factura. Las opciones integradas también incluyen max_tool_calls_per_session y ask_on_os_tools, que solicitan aprobación antes de realizar operaciones con archivos y con el shell. Nuestras notas sobre controlar los costes de los agentes de IA en un VPS se aplican directamente aquí, y con mayor motivo, porque los subagentes paralelos multiplican el ritmo de gasto.
¿Con qué rapidez avanza este repositorio?
The data behind this chart
[
{
"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
}
]Estas son las fechas de publicación de la página de releases del propio proyecto, consultada el 3 de agosto de 2026. Se publicaron 7 releases etiquetadas entre 2026-06-19 y 2026-07-27, y el intervalo más largo entre dos releases fue de 11 días. v0.5.1 se publicó el mismo día que la release anterior. La primera release, 0.1.1 del 16 de junio de 2026, no aparece en el gráfico porque no existe una etiqueta anterior desde la que medirla.
Dos de esas releases rompieron comandos que las guías ya habían documentado. v0.7.0 eliminó omni server start en favor de omni server --background. v0.6.0 cambió el nombre del extra omnigent[memory] a omnigent[hindsight], por lo que una línea de instalación copiada de un artículo de junio falla en una build de julio. Este es el motivo para usar --version en el comando de instalación y una etiqueta en git clone; no es una preferencia de estilo.
Qué no le confiaría todavía
En agosto de 2026, el repositorio tiene unas 8.1k estrellas, 1.2k forks y aproximadamente 350 issues abiertos. Su primera versión pública tiene siete semanas. Las estrellas miden el interés, no la madurez. El proyecto indica que está en fase alpha, y el historial de versiones anterior confirma que se trata de una fase alpha.
- No lo ejecutaría en un host que almacene credenciales de producción, porque el sandbox no cubre los servidores MCP ni el supervisor.
- No dejaría una ejecución desatendida sin una política
cost_budget, porque tres proveedores pueden facturar en paralelo y nada más los detiene. - No expondría el servidor en una dirección IP pública sin configurar
OMNIGENT_AUTH_ENABLEDy colocar TLS delante. - Todavía no trataría el YAML del agente como estable entre versiones menores. Fije la versión y lea las notas de la versión antes de actualizar.
Hay otro aspecto que debe conocer para evitar sorpresas: v0.6.0 añadió telemetría de uso anonimizada, y el proyecto la documenta en una página específica de telemetría. Lea esa página y decida de forma consciente si la máquina gestiona trabajo de clientes.
Actualmente, Omnigent es realmente bueno en aquello para lo que se creó. Tiene tres o cuatro CLI de agentes, ya paga por ellos y quiere que uno escriba mientras otro revisa. Eso funciona hoy, en una sola máquina y con un sandbox real en Linux. Considere todo lo demás como prometedor y todavía incompleto.
FAQ
¿Omnigent es un agente o algo que ejecuta agentes?
Ejecuta agentes. Omnigent es un metaarnés: inicia las CLI de proveedores que ya haya instalado, como Claude Code, Codex u OpenCode, asigna trabajo a cada una y supervisa los resultados en una sola sesión. No incluye ningún modelo propio. Por eso se diferencia de un framework, en el que se escribe código Python contra una biblioteca y el programa propio se convierte en el agente.
¿Necesito instalar Claude Code y Codex antes de que Omnigent sea útil?
Necesita instalar y autenticar al menos una CLI de proveedor, porque Omnigent controla esos programas en lugar de sustituirlos. Para el ejemplo Polly incluido, necesita dos o más CLI de proveedores diferentes. La regla de Polly es que la revisión siempre la realiza un proveedor diferente del implementador. Con una sola CLI disponible, no hay un segundo proveedor al que enviar el diff.
¿Cómo instalo una versión específica de Omnigent en lugar de la más reciente?
Pase --version al script de instalación mediante sh -s --, como en sh -s -- --version 0.7.0. Sin -s --, el propio sh consume la opción y el script instala la versión más reciente. Si ya tiene uv instalado, uv tool install --force --python 3.12 "omnigent==0.7.0" realiza la misma tarea. La etiqueta de git es v0.7.0 y la cadena de versión de PyPI es 0.7.0.
¿El sandbox de Omnibox es suficiente para ejecutar agentes sin supervisión?
Es sólido para lo que cubre y deja claro lo que no cubre. En Linux usa bubblewrap y seccomp, por lo que el kernel aplica los límites de archivos y red, y el agente no puede omitirlos. La documentación indica que se aplica a las llamadas de herramientas sys_os_* y a los terminales, pero no a los servidores MCP ni al proceso supervisor de Omnigent. Por tanto, un servidor MCP se ejecuta con sus permisos normales. Por eso, para trabajo sin supervisión, una máquina virtual desechable por agente sigue ofreciendo un aislamiento más sólido.
¿Cuánta memoria necesita un servidor Omnigent en un VPS?
Las notas de despliegue del proyecto asignan al servidor un conjunto de trabajo aproximado de 512 MB a 1 GB, y su configuración de Fly.io fija 1 GB. Esto cubre únicamente el supervisor y la interfaz web en el puerto 6767. Cada subagente es un proceso independiente con su propia copia de trabajo y su propio cliente de modelo. Además, las ejecuciones al estilo de Polly usan worktrees de git en paralelo. Por tanto, dimensione la RAM y el disco según el número de agentes que tenga previsto ejecutar simultáneamente, no según el servidor.