Omnigent: un meta-harness para varias CLI de agentes

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 (CLI) de los agentes 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 licencia Apache 2.0, y PyPI todavía clasifica el paquete como 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 única línea y el mismo agente se ejecutará con la CLI de otro proveedor. Nada más de su configuración cambia, porque Omnigent controla el bucle por encima de los agentes, no el bucle interno de cada uno.

¿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 cuesta una línea. La definición del agente contiene harness y model como 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 lee el diff generado por otro modelo de una empresa distinta. Dos modelos de la misma familia tienden a 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 umbrales de presupuesto 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 sobrevive a cualquier herramienta. Un único transcript 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 pasa a ser un error situado entre usted y un agente que antes funcionaba por sí solo. En alpha, este 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 posterior. El paquete publicado declara requires-python >= 3.12.
• tmux, porque los entornos de terminal se ejecutan dentro de él.
• Al menos una CLI del proveedor, ya instalada y con la sesión iniciada.
• Node.js 22 o posterior con npm, porque los entornos de Claude, Codex y Pi lo necesitan. El instalador comprueba si Node es la versión 22.10 o posterior y muestra una advertencia si no está disponible. Omnigent no necesita Node: el wheel de PyPI incluye los recursos web compilados, y Node sólo es un requisito obligatorio al compilar desde un checkout de git.

Instalar 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.0

La parte sh -s -- no es decorativa. Sin ella, sh interpreta --version como una opción propia y el instalador no se ejecuta. Cuando sh es Bash, muestra la versión de Bash y termina correctamente. Por tanto, no se instala nada ni se muestra ninguna advertencia. Con -s --, sh lee el script desde la tubería y pasa --version 0.7.0 al instalador. En un repositorio que introduce cambios incompatibles cada pocas semanas, esta diferencia separa un sistema reproducible de un resultado inesperado.

La versión 0.7.0 sigue publicada en PyPI a fecha de 29 October 2026, pero la versión más reciente es ahora la 0.21.0, publicada el 5 November 2026. La versión anterior 0.19.1 es un parche centrado en la seguridad y no añade funciones: actualiza las dependencias tras la vulneración de la autoridad de certificación intermedia de eMudhra, y el proyecto recomienda actualizar. Lo importante es la fijación, no el número: fije la versión que haya probado y lea los cambios incompatibles en las notas de la versión antes de cambiarla. Una versión fijada no justifica omitir una versión de seguridad. Actualícela cuando esté disponible.

El instalador usa uv, el gestor de paquetes de Python de Astral, y ofrece instalar uv primero si no está disponible. 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. El script también añade el extra databricks, salvo que pase --no-databricks, mientras que la línea anterior de uv instala el paquete sin ese extra. 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. Esa es la causa si el comando no se encuentra justo después de una instalación limpia. Compruebe el resultado:

omni upgrade --check

Esto 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 setup

El 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 debby

Es 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á en YAML. executor define el harness, 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-6

omnigent run path/to/my_agent.yaml

Esos 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 tenga configurados en su sistema. La especificación también incluye antigravity, copilot, kimi y qwen como valores de harness. La especificación actual de main también documenta acp:<slug> para cualquier servidor Agent Client Protocol, pero la especificación v0.7.0 no lo incluye. Confirme que funciona en la versión fijada antes de depender de esta opción. La especificación también admite pass_history: true en un subagente, lo que le entrega la conversación principal. Esto consume tokens en cada delegación. Déjelo desactivado en los subagentes que sólo necesiten la tarea que tienen asignada. Si prompt de un programador le indica que haga el cambio más pequeño que funcione, entregará al revisor un diff lo bastante corto para leerlo realmente. 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. Hay que planificar, delegar, esperar a que terminen trabajos paralelos en worktrees de Git, revisar y corregir. Cerrar la tapa del portátil termina 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 mientras no la supervisa.

omnigent server --background
omnigent server status

El servidor aloja una interfaz web en el puerto 6767. omnigent server status indica si el servidor (la interfaz web) está en ejecución, y omnigent stop lo apaga. v0.7.0 eliminó omni server start en favor de omni server --background; v0.9.0 lo restauró como alias obsoleto.

No publique el puerto 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 ella y activar la autenticación:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

La parte del firewall es una tarea habitual, explicada en los conceptos básicos del firewall ufw para un VPS, y si el equipo 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 un despliegue en contenedores, el directorio deploy/docker/ 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, con el servidor en el puerto 8000 en lugar del 6767. OMNIGENT_PORT cambia ese puerto del host. Compose calcula DATABASE_URL automáticamente (en otros destinos de despliegue, la misma variable selecciona Postgres o SQLite), y OMNIGENT_AUTH_ENABLED toma 1 como valor predeterminado dentro de los contenedores, que es el valor correcto para cualquier servicio accesible desde el exterior.

En cuanto al dimensionamiento, las notas de despliegue sitúan el uso de memoria inactiva del servidor en aproximadamente 275 MB RSS, y la configuración de Fly.io fija una máquina de 1 GB. La medición en estado inactivo corresponde sólo al supervisor; 1 GB es la memoria asignada a la máquina. Los subagentes pueden compartir el directorio de trabajo y el entorno del proceso principal, incluido su sandbox mediante os_env: inherit. Los worktrees de Git independientes son una decisión de orquestación, por lo que debe dimensionar el equipo según los harnesses y agentes que ejecute de forma simultánea. Una vez que 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> recupera una sesión en ejecución desde otro dispositivo.

Aísle cada subagente antes de cerrar la sesión

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 haya inyectado un prompt no puede convencer al kernel para eludir una regla. Instale primero la dependencia:

sudo apt install bubblewrap

La 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 solo 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 de nivel superior del directorio de trabajo y cada raíz de read_paths permanecen ocultos salvo que se indiquen en cwd_allow_hidden. Así, una concesión de lectura amplia no expone de forma inadvertida los directorios de nivel superior .ssh o .aws. Los archivos ocultos anidados permanecen visibles de forma predeterminada; establezca cwd_hidden_scan_recursive: true para ocultarlos en todo el árbol. Establezca egress_rules y todo el tráfico HTTP y HTTPS pasará 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 el secreto real cuando la solicitud sale. Por tanto, una transcripción filtrada no revela ningún secreto utilizable. En una configuración con varios entornos de ejecución, cada subagente incluye su propio bloque de sandbox en su propio archivo de configuración, dentro de agents/. Así, puede denegar la red al revisor mientras el implementador la conserva.

El límite está indicado en la documentación y es importante. El sandbox del sistema operativo se aplica a las llamadas a 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. Esta limitación explica por qué el patrón más seguro sigue siendo usar una máquina temporal por agente, como se explica en ejecutar agentes de programación 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 umbrales de gasto son políticas que se declaran 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]

La política cost_budget solicita aprobación en los umbrales blandos y bloquea todos los modelos en max_cost_usd de forma predeterminada. Si establece una lista expensive_models no vacía, el límite se convierte en una condición de degradación: los modelos que no estén en esa lista pueden seguir gastando. 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, establezca los umbrales antes de la primera ejecución sin supervisión y no después de 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 las operaciones con archivos y del shell. Nuestras notas sobre mantener bajo control los costes de los agentes de IA en un VPS se aplican directamente aquí, y con más motivo, porque los subagentes paralelos multiplican la tasa de gasto.

¿A qué velocidad evoluciona este repositorio?

[
  {
    "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 las releases del propio proyecto, consultadas 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. Las dos primeras releases de PyPI, 0.1.0 del 13 de junio de 2026 y 0.1.1 del 16 de junio de 2026, no tienen una entrada en la página de releases de GitHub y quedan fuera del gráfico; los tres días que se muestran para v0.2.0 se cuentan desde 0.1.1.

Dos de esas releases cambiaron 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], pero mantuvo memory como alias de compatibilidad, que siguió funcionando hasta 0.10.0. Desde 0.11.0, publicada el 25 de agosto de 2026, el alias ya no existe, por lo que una línea de instalación copiada de un artículo de junio ya no instala el cliente de Hindsight. Este es el motivo para usar --version en el comando de instalación y fijar una etiqueta en git clone; no es una preferencia de estilo.

El ritmo no se ha reducido desde esa consulta. El 29 de octubre de 2026, PyPI muestra la versión 0.20.0, publicada el 28 de octubre, trece releases menores después de 0.7.0, y las notas de release del proyecto señalan cambios incompatibles en varias de ellas. Dos afectan a cualquier contenido copiado de esta página: v0.12.0 hizo que un omni sin argumentos iniciara el host en segundo plano en lugar del agente de Polly (omni run inicia ahora el agente predeterminado), y v0.13.0 requiere tmux 3.3 o posterior para los terminales administrados.

Lo que todavía no le confiaría

A fecha de 27 October 2026, el repositorio tiene aproximadamente 11k stars, 1.8k forks y unas 910 incidencias abiertas. La primera versión pública se publicó hace poco más de cuatro meses. Las stars miden el interés, no la madurez. El proyecto se describe como alpha, y el historial de versiones anterior demuestra que se refiere realmente a una 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 sin supervisión sin una política cost_budget, porque tres proveedores pueden facturar en paralelo. Con una lista expensive_models no vacía, el gasto puede continuar en modelos más baratos.
• No expondría el servidor en una dirección IP pública sin configurar OMNIGENT_AUTH_ENABLED y poner TLS delante.
• Todavía no consideraría estable el YAML del agente 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. El README indica que se recopila de forma predeterminada. El proyecto documenta esta recopilación, incluido el procedimiento para desactivarla, en una página específica sobre telemetría. Lea esa página y decida de forma consciente si la máquina procesa trabajo de clientes.

Lo que Omnigent hace realmente bien hoy es aquello para lo que se diseñó. Tiene tres o cuatro CLIs de agentes, ya paga por ellos y quiere que uno escriba mientras otro revisa. Esto funciona ahora, en una sola máquina, con sandboxing real en Linux. Considere todo lo demás prometedor, pero todavía incompleto.

FAQ

¿Omnigent es un agente o algo que ejecuta agentes?

Ejecuta agentes. Omnigent es un metaarnés: inicia las CLI de los 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 propio programa se convierte en el agente.

¿Necesito instalar Claude Code y Codex antes de que Omnigent resulte útil?

Necesita instalar y autenticar al menos una CLI de proveedor, porque Omnigent controla esos programas en lugar de reemplazarlos. Para el ejemplo de Polly incluido, necesita dos o más CLI de proveedores diferentes. La regla de Polly establece que la revisión siempre debe realizarla un proveedor distinto del que implementó el cambio. Por tanto, si sólo hay una CLI disponible, no existe 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 se muestra en sh -s -- --version 0.7.0. Sin -s --, sh interpreta --version como una opción propia y el instalador nunca se ejecuta: Bash, por ejemplo, muestra su propia versión y termina. Si ya tiene uv instalado, uv tool install --force --python 3.12 "omnigent==0.7.0" realiza la misma función. La etiqueta de git es v0.7.0, mientras que la cadena de versión de PyPI es 0.7.0.

¿Es suficiente el sandbox de Omnibox 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, de modo 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 a 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 trabajos sin supervisión, sigue siendo más seguro usar una máquina virtual desechable por agente.

¿Cuánta memoria necesita un servidor de Omnigent en un VPS?

Las notas de despliegue del proyecto indican aproximadamente 275 MB de RSS en reposo, y su configuración de Fly.io asigna una máquina de 1 GB. La medición en reposo sólo incluye el servidor, no sus subagentes. Los subagentes pueden compartir el directorio de trabajo y el entorno del proceso principal, incluido su sandbox mediante os_env: inherit; no se garantizan copias de trabajo independientes. Las ejecuciones con el 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 planea ejecutar simultáneamente, no según el servidor.