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 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 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. Describe un agente una sola vez, en YAML, y especifica el harness que lo ejecuta. Cambie esa única línea y el mismo agente se ejecutará mediante la CLI de otro proveedor. No cambia nada más de su configuración, 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 por sí solo.

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 en este caso 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 entrega trabajo y lee la respuesta. Se conserva la CLI ya instalada y la suscripción o la clave de API (interfaz de programación de aplicaciones) que ya la financia. Esa es toda la diferencia. También determina a quién va dirigida la herramienta: personas que ya tienen varias CLI de agentes operativas y están cansadas de manejarlas una por una desde el terminal.

¿Qué problema resuelve una capa de orquestación?

• Cambiar de proveedor requiere una sola 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 diferente lee un diff generado por otro modelo. 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 valor.
• La política tiene un único lugar de definición. 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. Un único registro contiene el trabajo realizado por 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 estar 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 arnés 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, y Omnigent presupone que ya dispone de esa configuración. El campo más amplio de los agentes de IA autoalojados es donde se eligen los propios agentes, y aprender cómo funcionan realmente los agentes es un mejor punto de partida si esta terminología es nueva para usted.

Omnigent también pertenece a un eje distinto del de una capa de conectores. Un trabajo como dar a los agentes acceso a sus propias fuentes de datos trata sobre los recursos que puede alcanzar un agente. Omnigent trata sobre qué agente se ejecuta, en qué orden y con qué límites. Puede necesitar ambas cosas al mismo tiempo, pero no se solapan.

Qué necesita antes de instalar

• Python 3.12 o 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.

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 nunca recibe el indicador. Por tanto, se instala la versión más reciente disponible ese día. En un repositorio que introduce 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á 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 el indicador tambié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 ha instalado:

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.

Configúrelo para un proveedor de modelos

omni setup

El asistente busca las credenciales ya disponibles en el entorno y solicita las que faltan. Admite claves de API, suscripciones de proveedores, puertas de enlace como OpenRouter u Ollama y espacios de trabajo de Databricks. Si ya ejecuta un servidor de modelos local con Ollama en el mismo equipo, dirija una puerta de enlace a ese servidor para que el tráfico no salga 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 codificació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 justifica toda la ejecución: 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 previa para identificar qué CLI de subagentes existen realmente en el equipo. Si sólo hay instalada la CLI de un proveedor, no habrá 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 participantes: uno Claude y otro GPT:

omni debby

Es una forma rápida de confirmar que hay dos proveedores configurados, porque necesita que ambos respondan para producir cualquier resultado.

Los subagentes se declaran como herramientas

El archivo del agente está en YAML. executor identifica 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, que es el mecanismo en el que se basa 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 haya configurado omni setup en su equipo. La especificación también incluye 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 necesitan la tarea que tienen asignada.

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 los worktrees de Git paralelos, revisar y corregir. Al cerrar la tapa del portátil, todo se detiene. Un VPS (servidor privado virtual) permanece activo y mantiene su red, por lo que la sesión continúa aunque no la esté supervisando.

omnigent server --background
omnigent server status

El servidor aloja una interfaz web en el puerto 6767. omnigent server status indica si hay una instancia 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 artículos y las 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 --background

La 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 de Docker Compose, Omnigent es un servicio más dentro del mismo patrón.

Para un despliegue en contenedor, el directorio deploy/ del repositorio contiene una configuración de Compose: ./bootstrap.sh genera los secretos en .env y docker compose up -d inicia Omnigent y Postgres en el puerto 6767. DATABASE_URL selecciona Postgres o SQLite, y OMNIGENT_AUTH_ENABLED usa 1 de forma predeterminada dentro de los contenedores. Esta es la configuración adecuada para cualquier servicio accesible desde el exterior.

En cuanto al dimensionamiento, las notas de despliegue sitúan el conjunto de trabajo del servidor entre 512 MB y 1 GB aproximadamente, y la configuración de Fly.io fija 1 GB. Esa cifra corresponde únicamente al supervisor. Cada subagente es un proceso independiente que mantiene su propio checkout y su propio cliente del modelo. Por tanto, dimensione 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> recupera una sesión en ejecución desde otro dispositivo.

Aplique un sandbox a 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 aislamiento en lugar del prompt del agente. Un agente cuyo prompt haya sido objeto de una inyección no puede eludir una regla del kernel mediante instrucciones. 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. Así, un agente que funcione de forma incorrecta no puede escribir fuera del espacio de trabajo. Los archivos ocultos permanecen ocultos salvo que se indiquen en cwd_allow_hidden. Esto evita que una concesión de lectura amplia exponga de forma inadvertida .ssh o .aws. Configure egress_rules y todo el tráfico HTTP y HTTPS pasará por un proxy que deniega el acceso de forma predeterminada, 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 la solicitud sale. Por tanto, una transcripción filtrada no expone 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 a un revisor mientras el implementador la mantiene habilitada.

La documentación indica esta limitación, que es importante. El sandbox del sistema operativo se aplica a las llamadas a herramientas sys_os_* y a los terminales. No se aplica a los servidores MCP ni al 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 programación en una máquina virtual desechable. La otra parte del problema son las credenciales. mantener los secretos fuera del alcance de un agente resulta más difícil, no más sencillo, cuando seis subagentes comparten un mismo host.

Los límites 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]

Una ejecución que planifica con un proveedor, implementa con un segundo y revisa con un tercero genera gastos en tres lugares a la vez. Por eso, establezca el límite antes de la primera ejecución desatendida, 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 realizar operaciones con archivos y con el shell. Nuestras indicaciones 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 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
  }
]

Esas son las fechas de publicación que aparecen en la página de versiones del propio proyecto, consultada el 3 de agosto de 2026. Se publicaron 7 versiones etiquetadas entre 2026-06-19 y 2026-07-27, y el intervalo más largo entre dos versiones fue de 11 días. v0.5.1 se publicó el mismo día que la versión anterior. La primera versión, 0.1.1 del 16 de junio de 2026, no aparece en el gráfico porque no existe una etiqueta anterior desde la que medir el intervalo.

Dos de esas versiones rompieron comandos que las guías ya habían documentado. La versión v0.7.0 eliminó omni server start en favor de omni server --background. La versión 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 compilación de julio. Por eso debe incluir --version en el comando de instalación y una etiqueta en git clone; no es una preferencia de estilo.

Lo que todavía no le confiaría

En agosto de 2026, el repositorio tiene aproximadamente 8.1k estrellas, 1.2k forks y unas 350 incidencias abiertas, y su primera versión pública tiene siete semanas. Las estrellas miden interés, no madurez. El proyecto se declara alpha, y el historial de versiones anterior demuestra que debe interpretarse literalmente.

• 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 y no hay ningún otro mecanismo que los detenga.
• No expondría el servidor en una dirección IP pública sin configurar OMNIGENT_AUTH_ENABLED y 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 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 CLI de agentes, ya paga por ellos y quiere que uno escriba mientras otro revisa. Esto funciona ahora, en una máquina y con un aislamiento 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 meta-entorno: inicia las CLI de proveedores que ya ha 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 sea útil?

Necesita instalar e iniciar sesión en 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 que implementó los cambios. 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 mediante el script de instalación con sh -s --, como en sh -s -- --version 0.7.0. Sin -s --, sh consume la opción y el script instala la versión más reciente. Si ya tiene uv, 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, 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 y terminales de sys_os_*, pero no a los servidores MCP ni al proceso supervisor de Omnigent. Por tanto, un servidor MCP se ejecuta con sus permisos normales. Por este motivo, una máquina virtual desechable por agente sigue proporcionando un aislamiento más sólido para el trabajo sin supervisión.

¿Cuánta memoria necesita un servidor de 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 de tipo Polly usan worktrees de git en paralelo. Por tanto, dimensione la RAM y el disco según el número de agentes que vaya a ejecutar simultáneamente, no según el servidor.