Dirigir workers en segundo plano

Esta guía te muestra cómo llevar una conversación como director en lugar de como worker: la sesión lee y verifica, y los agentes en segundo plano se encargan de editar.

Qué cambia cuando escribes /vibe

Dos cosas, y solo la primera la impone el mecanismo:

1. Las herramientas de la propia sesión pasan a ser de solo lectura, más cinco verbos de worker. La única forma que tiene de afectar al repositorio es a través de un worker, y la única forma de saber qué ha pasado es leer los archivos que ha tocado un worker.
2. Se le indica que verifique leyendo, no creyendo. El informe de un worker es una afirmación sobre lo que hizo, no una prueba de que funcionara.

El primero es el decisivo. Un director que todavía puede usar grep y editar hará el trabajo por su cuenta cuando haya presión, que es justo el modo de fallo que esto existe para evitar.

/vibe migrate the auth module to the new session API

Los workers empiezan en blanco

Un worker nunca ha visto tu conversación ni la verá. El encargo es todo su contexto.

Eso es lo que hace que el patrón salga barato —veinte workers que conservaran cada uno el historial del director costarían veinte veces el contexto del director— y también es lo único que hace que los encargos sean difíciles de redactar. «Ahora haz también el otro» suena a instrucción completa para el director y a nada en absoluto para una sesión nueva.

Un buen encargo nombra archivos, comandos y la definición de terminado:

En lib/features/auth/, sustituye todas las llamadas a SessionStore.read(key) por SessionStore.get(key). El método nuevo devuelve Future<String?>, mientras que el antiguo devolvía String?, así que quien lo llame necesita await. Ejecuta fvm flutter analyze lib/features/auth cuando termines e informa de los errores que no hayas podido corregir.

Los cinco verbos

Verbo	Qué hace
vibe_spawn	Inicia un worker con un encargo. Devuelve el control de inmediato.
vibe_list	Nivel, estado, tiempo transcurrido y último resultado de todos
vibe_send	Un turno de seguimiento para un worker que ha terminado
vibe_wait	Se bloquea hasta que un worker finaliza
vibe_kill	Detiene uno

Lanzar un worker es asíncrono por diseño. Un director que se bloquea en cada lanzamiento está ejecutando los workers de uno en uno, que es una forma más lenta de hacer lo que ya hacía él mismo. Usa vibe_wait solo cuando de verdad no puedas continuar sin una respuesta concreta.

Dos niveles

Nivel	Para
fast	Trabajo mecánico con una especificación clara: ediciones, renombrados, borradores y ejecución de comandos
good	Diseño, criterio o revisión de lo que ha producido un worker fast

Un patrón habitual es repartir workers fast entre archivos independientes y luego lanzar un worker good que revise lo que han hecho en conjunto.

Verificación

Esta es la parte que decide si el patrón vale para algo.

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

Después, lee los archivos que ha indicado. El director dispone de read, search, lsp y ast_grep; esa es precisamente la razón de conservarlas. Un director que se cree el informe a pies juntillas es un resumidor del optimismo de otros agentes.

lsp(action: "diagnostics", file: "*") después de una ronda de workers suele ser la comprobación individual más rápida.

Cuando un worker pierde el hilo

Mátalo y vuelve a redactar el encargo. Un encargo nuevo y corregido es más barato que una discusión, y vibe_send solo funciona con un worker que ya ha terminado su turno.

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

Límites

• Ocho workers simultáneos. Un tope de gasto, no un límite técnico: cada uno es una sesión de modelo completa, y un director que despliega veinte ha dejado de seguir lo que están haciendo.
• Ningún worker sobrevive al modo. Cuando termina la ejecución, todos se detienen y la transcripción indica cuántos. Un agente en segundo plano que sigue editando archivos cuando la conversación ya ha seguido adelante es el único fallo que esto no puede permitirse.
• Por debajo, los workers son subagentes normales. El mismo límite de profundidad, la misma política de barandillas, el mismo hijo en el registro de ejecución. Vibe cambia quién los dirige, no lo que pueden hacer, así que los avisos de aprobación siguen apareciendo para las llamadas de escritura y de ejecución de un worker.

Cuándo no usarlo

El modo vibe es para trabajo que se descompone en encargos independientes. Si el siguiente paso depende de la salida del anterior, lo que estás describiendo es un pipeline o una orquestación, y ambos expresan las dependencias como es debido en lugar de obligar al director a simularlas con vibe_wait.

Véase también

• Ejecutar agentes en paralelo: las otras formas de repartir el trabajo
• Orquestación: cuando el trabajo tiene forma
• Herramientas de agente integradas: los verbos y sus argumentos