Dirigir workers em segundo plano

Este guia mostra-lhe como conduzir uma conversa como diretor em vez de como trabalhador: a sessão lê e verifica, e os agentes em segundo plano fazem as edições.

O que muda quando escreve /vibe

Duas coisas, e só a primeira é imposta pela máquina:

1. As ferramentas da própria sessão passam a ser só de leitura, mais cinco verbos de worker. A única forma de afetar o repositório é através de um worker, e a única forma de saber o que aconteceu é lendo os ficheiros que um worker tocou.
2. É instruída a verificar lendo, não a acreditar. O relatório de um worker é uma alegação sobre o que fez, não uma prova de que resultou.

A primeira é a que sustenta tudo. Um diretor que ainda consegue fazer grep e editar fará o trabalho sozinho sob pressão, que é exatamente o modo de falha que isto existe para evitar.

/vibe migrate the auth module to the new session API

Os workers começam em branco

Um worker nunca viu a sua conversa e nunca a verá. O briefing é todo o seu contexto.

É isso que mantém o padrão barato — vinte workers a carregar cada um o histórico do diretor custariam vinte vezes o contexto do diretor — e é também a única coisa que torna os briefings difíceis de escrever. «Agora faz também o outro» lê-se como uma instrução completa para o diretor e como absolutamente nada para uma sessão nova.

Um bom briefing indica ficheiros, comandos e a definição de concluído:

Em lib/features/auth/, substitua todas as chamadas a SessionStore.read(key) por SessionStore.get(key). O novo método devolve Future<String?> onde o antigo devolvia String?, por isso os chamadores precisam de await. Execute fvm flutter analyze lib/features/auth quando terminar e reporte os erros que não conseguiu corrigir.

Os cinco verbos

Verbo	O que faz
vibe_spawn	Inicia um worker com um briefing. Devolve imediatamente.
vibe_list	Nível, estado, tempo decorrido e último resultado de cada um
vibe_send	Um turno de seguimento para um worker que já terminou
vibe_wait	Bloqueia até um worker terminar
vibe_kill	Para um worker

A criação é assíncrona por conceção. Um diretor que bloqueia em cada criação está a executar workers um de cada vez, o que é uma forma mais lenta de fazer o que já fazia por si. Use vibe_wait apenas quando não puder mesmo avançar sem uma resposta específica.

Dois níveis

Nível	Para
fast	Trabalho mecânico com uma especificação clara — edições, renomeações, rascunhos, executar comandos
good	Conceção, discernimento ou revisão do que um worker fast produziu

Uma forma comum é distribuir workers fast por ficheiros independentes e depois lançar um worker good para rever o que eles fizeram em conjunto.

Verificar

Esta é a parte que decide se o padrão vale alguma coisa.

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

Depois leia os ficheiros que ele indicou. O diretor tem read, search, lsp e ast_grep; é precisamente por isso que os mantém. Um diretor que aceita o relatório à letra é um resumidor do otimismo dos outros agentes.

lsp(action: "diagnostics", file: "*") depois de uma ronda de workers é normalmente a verificação única mais rápida.

Quando um worker perde o fio à meada

Mate-o e faça um novo briefing. Um briefing novo e corrigido é mais barato do que uma discussão, e o vibe_send só funciona num worker que já terminou o seu turno.

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

Limites

• Oito workers em simultâneo. Um teto de despesa, não um limite técnico: cada um é uma sessão de modelo completa, e um diretor que distribui vinte deixou de acompanhar o que todos andam a fazer.
• Nenhum worker sobrevive ao modo. Quando a execução termina, todos eles são parados e a transcrição indica quantos. Um agente em segundo plano que continua a editar ficheiros depois de a conversa ter seguido em frente é a única falha que isto não pode ter.
• Os workers são subagentes normais por baixo. O mesmo limite de profundidade, a mesma política de barreiras, o mesmo registo de execução filho. O vibe muda quem os conduz, não o que lhes é permitido fazer — por isso os pedidos de aprovação continuam a aparecer nas chamadas de escrita e de execução de um worker.

Quando não o usar

O modo vibe serve para trabalho que se decompõe em briefings independentes. Se o passo seguinte depende do resultado do passo anterior, está a descrever um pipeline ou uma orquestração, e ambos expressam as dependências como deve ser, em vez de obrigarem o diretor a simulá-las com vibe_wait.

Relacionado

• Executar agentes em paralelo — as outras formas de distribuir
• Orquestração — quando o trabalho tem forma
• Ferramentas de agente integradas — os verbos e os seus argumentos