Saltar al contenido principal
Task Flow es la capa de orquestación sobre las tareas en segundo plano. Un flujo es un registro duradero de trabajo de varios pasos con su propio estado, estado JSON, contador de revisión y registros de tareas vinculados. Los flujos sobreviven a los reinicios del gateway; las tareas individuales siguen siendo la unidad de trabajo desacoplado.

Cuándo usar Task Flow

EscenarioUso
Trabajo único en segundo planoTarea simple
Pipeline de varios pasos impulsado por código de pluginTask Flow (administrado)
Creación de ACP desacoplado o subagenteTask Flow (reflejado, creado automáticamente)
Recordatorio de una sola ejecuciónTrabajo Cron

Modos de sincronización

Modo administrado

Un flujo administrado tiene un controlador: código de plugin que crea el flujo mediante la API de Task Flow del runtime del plugin con un objetivo y un id de controlador obligatorio, y luego lo impulsa explícitamente.
  • Cada paso se ejecuta como una tarea en segundo plano creada bajo el flujo; la clave de propietario del flujo y el origen del solicitante se transfieren a las tareas hijas.
  • El controlador avanza el flujo entre running, waiting y estados terminales, y almacena estado de paso JSON arbitrario en el registro del flujo.
  • Cada mutación pasa la revisión esperada del flujo. Una escritura obsoleta se rechaza como conflicto de revisión en lugar de sobrescribir un estado más nuevo.
  • Una vez solicitada la cancelación, se rechazan nuevas tareas hijas, y el flujo finaliza como cancelled cuando ninguna tarea hija permanece activa.
Ejemplo: un flujo de informe semanal que (1) recopila datos, (2) genera el informe y (3) lo entrega, con una tarea en segundo plano por paso:
Flow: weekly-report
  Step 1: gather-data     → task created → succeeded
  Step 2: generate-report → task created → succeeded
  Step 3: deliver         → task created → running

Modo reflejado

OpenClaw crea automáticamente un flujo reflejado de una tarea cuando se inicia una ejecución desacoplada de ACP o subagente (tareas con alcance de sesión y finalización entregable). El registro del flujo refleja su única tarea subyacente - estado, objetivo y tiempos - para que las creaciones desacopladas obtengan un identificador de flujo estable para superficies de estado y reintento sin controlador. Los flujos reflejados muestran el modo de sincronización task_mirrored en la CLI.

Estados de flujo

EstadoSignificado
queuedCreado, aún sin progresar
runningEl flujo está progresando activamente
waitingEl flujo administrado está estacionado en metadatos de espera (temporizador, evento externo)
blockedUn paso terminó sin un resultado utilizable; blockedTaskId/resumen indican cuál
succeededCompletado correctamente
failedCompletado con un error
cancelledCancelación solicitada y todas las tareas hijas resueltas
lostEl flujo perdió su estado subyacente autoritativo

Estado duradero y seguimiento de revisiones

Los registros de flujo persisten en la base de datos de estado SQLite compartida (~/.openclaw/state/openclaw.sqlite, tabla flow_runs) junto con los registros de tareas, por lo que el progreso sobrevive a los reinicios del gateway. Cada escritura incrementa la revision del flujo; los escritores concurrentes que pasan una revisión esperada obsoleta reciben un conflicto y deben volver a leer. El crecimiento de WAL está limitado por el autocheckpointing de SQLite más checkpoints pasivos periódicos, con checkpoints de truncado al apagar. El sidecar heredado flows/registry.sqlite de instalaciones anteriores se importa mediante openclaw doctor.

Comportamiento de cancelación

openclaw tasks flow cancel establece una intención de cancelación persistente en el flujo, cancela sus tareas hijas activas y rechaza nuevas tareas hijas administradas. Una vez que ninguna tarea hija permanece activa, el flujo finaliza como cancelled: de inmediato o mediante el barrido de mantenimiento si las hijas tardan más en resolverse. La intención se conserva, por lo que un flujo cancelado permanece cancelado incluso si el gateway se reinicia antes de que todas las tareas hijas hayan terminado.

Comandos de CLI

# List active and recent flows
openclaw tasks flow list [--status <status>] [--json]

# Show details for a specific flow
openclaw tasks flow show <lookup> [--json]

# Cancel a running flow and its active tasks
openclaw tasks flow cancel <lookup>
ComandoDescripción
openclaw tasks flow listFlujos rastreados con modo de sincronización, estado, revisión, controlador y conteos de tareas
openclaw tasks flow show <id>Inspecciona un flujo por id de flujo o clave de propietario, incluidas las tareas vinculadas
openclaw tasks flow cancel <id>Cancela un flujo en ejecución y sus tareas activas
Los flujos también están cubiertos por openclaw tasks audit (hallazgos de flujos obsoletos o rotos) y openclaw tasks maintenance (finaliza cancelaciones atascadas, elimina flujos terminales después de 7 días).

Patrón de workflow programado confiable

Para workflows recurrentes como informes de inteligencia de mercado, trata la programación, la orquestación y las comprobaciones de confiabilidad como capas separadas:
  1. Usa Tareas programadas para la temporización.
  2. Usa una sesión cron persistente cuando el workflow deba basarse en contexto previo.
  3. Usa Lobster para pasos deterministas, puertas de aprobación y tokens de reanudación.
  4. Usa Task Flow para rastrear la ejecución de varios pasos a través de tareas hijas, esperas, reintentos y reinicios del gateway.
Ejemplo de forma cron:
openclaw cron add \
  --name "Market intelligence brief" \
  --cron "0 7 * * 1-5" \
  --tz "America/New_York" \
  --session session:market-intel \
  --message "Run the market-intel Lobster workflow. Verify source freshness before summarizing." \
  --announce \
  --channel slack \
  --to "channel:C1234567890"
Usa --session session:<id> en lugar de isolated cuando el workflow recurrente necesite historial deliberado, resúmenes de ejecuciones anteriores o contexto permanente. Usa isolated cuando cada ejecución deba empezar desde cero y todo el estado requerido sea explícito en el workflow. Dentro del workflow, coloca las comprobaciones de confiabilidad antes del paso de resumen del LLM:
name: market-intel-brief
steps:
  - id: preflight
    command: market-intel check --json
  - id: collect
    command: market-intel collect --json
    stdin: $preflight.json
  - id: summarize
    command: market-intel summarize --json
    stdin: $collect.json
  - id: approve
    command: market-intel deliver --preview
    stdin: $summarize.json
    approval: required
  - id: deliver
    command: market-intel deliver --execute
    stdin: $summarize.json
    condition: $approve.approved
Comprobaciones de preflight recomendadas:
  • Disponibilidad del navegador y elección de perfil, por ejemplo openclaw para estado administrado o user cuando se requiere una sesión de Chrome iniciada. Consulta Navegador.
  • Credenciales de API y cuota para cada fuente.
  • Accesibilidad de red para los endpoints requeridos.
  • Herramientas requeridas habilitadas para el agente, como lobster, browser y llm-task.
  • Destino de fallo configurado para cron para que los fallos de preflight sean visibles. Consulta Tareas programadas.
Campos de procedencia de datos recomendados para cada elemento recopilado:
{
  "sourceUrl": "https://example.com/report",
  "retrievedAt": "2026-04-24T12:00:00Z",
  "asOf": "2026-04-24",
  "title": "Example report",
  "content": "..."
}
Haz que el workflow rechace o marque elementos obsoletos antes de la síntesis. El paso de LLM debe recibir solo JSON estructurado y se le debe pedir que preserve sourceUrl, retrievedAt y asOf en su salida. Usa LLM Task cuando necesites un paso de modelo validado por esquema dentro del workflow. Para workflows reutilizables de equipo o comunidad, empaqueta la CLI, los archivos .lobster y cualquier nota de configuración como una skill o plugin, y publícalo mediante ClawHub. Mantén las barandillas específicas del workflow en ese paquete a menos que a la API del plugin le falte una capacidad genérica necesaria.

Cómo se relacionan los flujos con las tareas

Los flujos coordinan tareas, no las reemplazan. Un solo flujo puede impulsar varias tareas en segundo plano durante su vida útil. Usa openclaw tasks para inspeccionar registros de tareas individuales y openclaw tasks flow para inspeccionar el flujo orquestador.

Relacionado