Cuándo usar Task Flow
Modos de sincronización
Modo gestionado
Un flujo gestionado tiene un controlador: código de plugin que crea el flujo mediante la API de Task Flow del entorno de ejecución del plugin con un objetivo y un id. de controlador obligatorio y, a continuación, lo controla explícitamente.- Cada paso se ejecuta como una tarea en segundo plano creada dentro del flujo; la clave del propietario y el origen del solicitante del flujo se transfieren a las tareas secundarias.
- El controlador hace avanzar el flujo entre
running,waitingy los estados terminales, y almacena un estado de paso JSON arbitrario en el registro del flujo. - Cada mutación incluye la revisión esperada del flujo. Una escritura obsoleta se rechaza como conflicto de revisión en lugar de sobrescribir el estado más reciente.
- Una vez solicitada la cancelación, se rechazan las nuevas tareas secundarias y el flujo finaliza como
cancelledcuando no queda ninguna tarea secundaria activa.
Modo reflejado
OpenClaw crea automáticamente un flujo reflejado de una sola tarea cuando se inicia una ejecución independiente de ACP o de un subagente (tareas con ámbito de sesión y finalización entregable). El registro del flujo refleja su única tarea subyacente —estado, objetivo y tiempos— para que los inicios independientes dispongan de un identificador de flujo estable en las superficies de estado y reintento sin necesidad de un controlador. Los flujos reflejados muestran el modo de sincronizacióntask_mirrored en la CLI.
Estados de los flujos
Estado duradero y seguimiento de revisiones
Los registros de flujos persisten en la base de datos SQLite de estado compartido (tabla~/.openclaw/state/openclaw.sqlite, flow_runs) junto con los registros de tareas, por lo que el progreso sobrevive a los reinicios del Gateway. Cada escritura incrementa el revision del flujo; los escritores simultáneos que proporcionan una revisión esperada obsoleta reciben un conflicto y deben volver a leer. El crecimiento de WAL está limitado mediante los puntos de control automáticos de SQLite y puntos de control pasivos periódicos, con puntos de control de truncamiento durante el apagado. openclaw doctor importa el archivo auxiliar heredado flows/registry.sqlite de instalaciones anteriores.
Comportamiento de cancelación
openclaw tasks flow cancel establece una intención de cancelación persistente en el flujo, cancela sus tareas secundarias activas y rechaza nuevas tareas secundarias gestionadas. Cuando ya no queda ninguna tarea secundaria activa, el flujo finaliza como cancelled, de inmediato o mediante el barrido de mantenimiento si las tareas secundarias tardan más en resolverse. La intención se conserva, por lo que un flujo cancelado sigue cancelado aunque el Gateway se reinicie antes de que todas las tareas secundarias hayan terminado.
Comandos de la CLI
Los flujos también están cubiertos por
openclaw tasks audit (hallazgos de flujos obsoletos o dañados) y openclaw tasks maintenance (finaliza cancelaciones bloqueadas y elimina flujos terminales después de 7 días).
Patrón fiable de flujo de trabajo programado
Para flujos de trabajo recurrentes, como informes de inteligencia de mercado, las comprobaciones de programación, orquestación y fiabilidad deben tratarse como capas independientes:- Usar Tareas programadas para la temporización.
- Usar una sesión de Cron persistente cuando el flujo de trabajo deba aprovechar el contexto anterior.
- Usar Lobster para pasos deterministas, puertas de aprobación y tokens de reanudación.
- Usar Task Flow para realizar el seguimiento de la ejecución de varios pasos entre tareas secundarias, esperas, reintentos y reinicios del Gateway.
--session session:<id> en lugar de isolated cuando el flujo de trabajo recurrente necesite un historial deliberado, resúmenes de ejecuciones anteriores o contexto permanente. Usar isolated cuando cada ejecución deba comenzar desde cero y todo el estado necesario esté explícito en el flujo de trabajo.
Dentro del flujo de trabajo, colocar las comprobaciones de fiabilidad antes del paso de resumen del LLM:
- Disponibilidad del navegador y elección del perfil, por ejemplo,
openclawpara el estado gestionado ousercuando se requiera una sesión de Chrome con la sesión iniciada. Consultar Navegador. - Credenciales y cuota de la API para cada fuente.
- Accesibilidad de red de los endpoints necesarios.
- Herramientas necesarias habilitadas para el agente, como
lobster,browseryllm-task. - Destino de errores configurado para Cron de modo que los errores de las comprobaciones preliminares sean visibles. Consultar Tareas programadas.
sourceUrl, retrievedAt y asOf en su salida. Usar Tarea de LLM cuando se necesite un paso de modelo validado mediante un esquema dentro del flujo de trabajo.
Para flujos de trabajo reutilizables de equipos o comunidades, empaquetar la CLI, los archivos .lobster y las notas de configuración como una skill o un plugin y publicarlos mediante ClawHub. Mantener las protecciones específicas del flujo de trabajo en ese paquete, salvo que la API del plugin carezca de alguna capacidad genérica necesaria.
Relación entre los flujos y las tareas
Los flujos coordinan las tareas, no las sustituyen. Un único flujo puede controlar varias tareas en segundo plano a lo largo de su ciclo de vida. Usaropenclaw tasks para inspeccionar los registros de tareas individuales y openclaw tasks flow para inspeccionar el flujo de orquestación.
Temas relacionados
- Tareas en segundo plano - el registro de trabajo independiente que coordinan los flujos
- CLI: tareas - referencia de los comandos de la CLI para
openclaw tasks flow - Descripción general de la automatización - todos los mecanismos de automatización de un vistazo
- Trabajos de Cron - trabajos programados que pueden alimentar los flujos