Saltar al contenido principal
Un runtime de agente es el componente que posee un bucle de modelo preparado: recibe el prompt, impulsa la salida del modelo, maneja las llamadas nativas a herramientas y devuelve el turno finalizado a OpenClaw. Es fácil confundir los runtimes con los proveedores porque ambos aparecen cerca de la configuración del modelo. Son capas diferentes:
CapaEjemplosQué significa
Proveedoropenai, anthropic, openai-codexCómo OpenClaw autentica, descubre modelos y nombra referencias de modelo.
Modelogpt-5.5, claude-opus-4-6El modelo seleccionado para el turno del agente.
Runtime de agentepi, codex, runtimes respaldados por ACPEl bucle de bajo nivel que ejecuta el turno preparado.
CanalTelegram, Discord, Slack, WhatsAppDónde entran y salen los mensajes de OpenClaw.
También verás la palabra harness en el código y la configuración. Un harness es la implementación que proporciona un runtime de agente. Por ejemplo, el harness Codex incluido implementa el runtime codex. La clave de configuración sigue llamándose embeddedHarness por compatibilidad, pero la documentación orientada al usuario y la salida de estado generalmente deberían decir runtime. La configuración común de Codex usa el proveedor openai con el runtime codex: 
{
  agents: {
    defaults: {
      model: "openai/gpt-5.5",
      embeddedHarness: {
        runtime: "codex",
      },
    },
  },
}
Eso significa que OpenClaw selecciona una referencia de modelo de OpenAI y luego pide al runtime app-server de Codex que ejecute el turno del agente embebido. No significa que el canal, el catálogo del proveedor de modelos ni el almacén de sesiones de OpenClaw pasen a ser Codex. Para la división de prefijos de la familia OpenAI, consulta OpenAI y Proveedores de modelos. Para el contrato de compatibilidad del runtime Codex, consulta Codex harness.

​
Propiedad del runtime

Diferentes runtimes poseen distintas partes del bucle.
SuperficiePI embebido de OpenClawApp-server de Codex
Propietario del bucle de modeloOpenClaw a través del runner PI embebidoApp-server de Codex
Estado canónico del hiloTranscripción de OpenClawHilo de Codex, más espejo de la transcripción de OpenClaw
Herramientas dinámicas de OpenClawBucle nativo de herramientas de OpenClawConectadas mediante el adaptador de Codex
Herramientas nativas de shell y archivosRuta PI/OpenClawHerramientas nativas de Codex, conectadas mediante hooks nativos cuando son compatibles
Motor de contextoEnsamblado nativo de contexto de OpenClawContexto ensamblado por proyectos de OpenClaw dentro del turno de Codex
CompactionOpenClaw o el motor de contexto seleccionadoCompaction nativa de Codex, con notificaciones de OpenClaw y mantenimiento del espejo
Entrega del canalOpenClawOpenClaw
Esta división de propiedad es la regla principal de diseño:
  • Si OpenClaw posee la superficie, OpenClaw puede proporcionar el comportamiento normal de hooks de plugins.
  • Si el runtime nativo posee la superficie, OpenClaw necesita eventos del runtime o hooks nativos.
  • Si el runtime nativo posee el estado canónico del hilo, OpenClaw debe reflejar y proyectar contexto, no reescribir elementos internos no compatibles.

​
Selección de runtime

OpenClaw elige un runtime embebido después de resolver el proveedor y el modelo:
  1. El runtime registrado de una sesión tiene prioridad. Los cambios de configuración no cambian en caliente una transcripción existente a un sistema de hilos nativo diferente.
  2. OPENCLAW_AGENT_RUNTIME=<id> fuerza ese runtime para sesiones nuevas o reiniciadas.
  3. agents.defaults.embeddedHarness.runtime o agents.list[].embeddedHarness.runtime pueden establecer auto, pi o un id de runtime registrado como codex.
  4. En modo auto, los runtimes de plugins registrados pueden reclamar pares proveedor/modelo compatibles.
  5. Si ningún runtime reclama un turno en modo auto y está establecido fallback: "pi" (el valor predeterminado), OpenClaw usa PI como fallback de compatibilidad. Establece fallback: "none" para hacer que la selección no coincidente en modo auto falle en su lugar.
Los runtimes de plugins explícitos fallan de forma cerrada por defecto. Por ejemplo, runtime: "codex" significa Codex o un error claro de selección, a menos que establezcas fallback: "pi" en el mismo ámbito de sobrescritura. Una sobrescritura de runtime no hereda una configuración de fallback más amplia, por lo que un runtime: "codex" a nivel de agente no se redirige silenciosamente de vuelta a PI solo porque los valores predeterminados usaran fallback: "pi".

​
Contrato de compatibilidad

Cuando un runtime no es PI, debe documentar qué superficies de OpenClaw admite. Usa esta forma para la documentación de runtimes:
PreguntaPor qué importa
¿Quién posee el bucle del modelo?Determina dónde ocurren los reintentos, la continuación de herramientas y las decisiones de respuesta final.
¿Quién posee el historial canónico del hilo?Determina si OpenClaw puede editar el historial o solo reflejarlo.
¿Funcionan las herramientas dinámicas de OpenClaw?Los mensajes, las sesiones, Cron y las herramientas propiedad de OpenClaw dependen de esto.
¿Funcionan los hooks de herramientas dinámicas?Los plugins esperan before_tool_call, after_tool_call y middleware alrededor de herramientas propiedad de OpenClaw.
¿Funcionan los hooks de herramientas nativas?Shell, patch y herramientas propiedad del runtime necesitan compatibilidad con hooks nativos para política y observación.
¿Se ejecuta el ciclo de vida del motor de contexto?Los plugins de memoria y contexto dependen del ensamblado, ingestión, after-turn y ciclo de vida de Compaction.
¿Qué datos de Compaction se exponen?Algunos plugins solo necesitan notificaciones, mientras que otros necesitan metadatos de conservación/descartes.
¿Qué no es compatible intencionalmente?Los usuarios no deberían asumir equivalencia con PI cuando el runtime nativo posee más estado.
El contrato de compatibilidad del runtime Codex está documentado en Codex harness.

​
Etiquetas de estado

La salida de estado puede mostrar tanto las etiquetas Execution como Runtime. Léelas como diagnóstico, no como nombres de proveedores.
  • Una referencia de modelo como openai/gpt-5.5 te indica el proveedor/modelo seleccionado.
  • Un id de runtime como codex te indica qué bucle está ejecutando el turno.
  • Una etiqueta de canal como Telegram o Discord te indica dónde está ocurriendo la conversación.
Si una sesión sigue mostrando PI después de cambiar la configuración del runtime, inicia una nueva sesión con /new o limpia la actual con /reset. Las sesiones existentes conservan su runtime registrado para que una transcripción no se reproduzca a través de dos sistemas de sesión nativos incompatibles.

​
Relacionado