Workflows do Claude Code: O Que São e Quando Realmente Precisa de Um
Atualize para o Claude Code v2.1.154 e encontrará uma nova linha em /config com a etiqueta Dynamic workflows. Ative-a e o Claude passa a poder escrever um script JavaScript que distribui trabalho por até 16 agents em execução simultânea. É esta a funcionalidade de que todos falam em surdina. A documentação oficial diz-lhe o que faz. O que não lhe diz é aquilo que realmente quer saber: precisa dela, ou os subagents que já tem chegam?
É esta a lacuna. Os workflows do Claude Code foram lançados como research preview, e a documentação lê-se como material de referência, não como conselho. Por isso, corremos o único workflow incluído, o /deep-research, dentro da nossa própria pipeline de conteúdo, registámos os números reais e escrevemos o veredicto honesto. Versão curta: se ainda consegue acompanhar os seus agents à mão, ainda não precisa de um workflow. Alguns de vocês precisam absolutamente. Vamos descobrir em que grupo se encontra.
Principais conclusões:
- Um workflow do Claude Code é um script JavaScript que o Claude escreve para orquestrar subagents em escala (research preview, v2.1.154+, todos os planos pagos).
- Só precisa de um quando uma tarefa exige mais agents do que uma conversa consegue coordenar. Caso contrário, os subagents chegam.
- Existe hoje um único workflow:
/deep-research. Corre em segundo plano enquanto a sua sessão se mantém responsiva. - Os workflows consomem muitos tokens. Medimos uma execução real antes de recomendar um (números abaixo).
O Que É Um Workflow do Claude Code?
Um workflow do Claude Code é um script JavaScript que orquestra subagents em escala. Descreve a tarefa, o Claude escreve o script, e um runtime executa-o em segundo plano enquanto a sua sessão de chat se mantém responsiva. É uma funcionalidade em research preview no Claude Code, requer o Claude Code v2.1.154+ e corre em todos os planos pagos (Pro, Max, Team, Enterprise, além da API e Bedrock/Vertex/Foundry).
Aqui está a versão do dia a dia. Imagine que se aproxima de um balcão de cozinha e descreve o prato que quer. O chef escreve uma receita, entrega-a a uma cozinha cheia de cozinheiros, e eles põem mãos à obra enquanto continua à conversa ao balcão. Não está a microgerir cada cozinheiro. A receita está. Essa receita é o workflow, os cozinheiros são os subagents, e a cozinha a funcionar lá atrás é o runtime.
Um workflow não é mais um agent. É o script que diz aos seus agents o que fazer, em que ordem, e o que fazer com os resultados. Essa distinção importa mais do que qualquer outra coisa neste artigo, e vamos torná-la concreta na próxima secção.
Uma confusão rápida a esclarecer. Pesquise "claude code workflows" e encontrará repositórios no GitHub, plugins e um
marketplacecheio de ferramentas de swarm da comunidade como o Ruflo, o claude-flow e owshobson/agents. São orquestradores de terceiros. Os Dynamic workflows oficiais da Anthropic são uma funcionalidade integrada diferente. Se não estiver em/configna v2.1.154+, não é a oficial.
Isto junta-se a outros lançamentos em research preview da Anthropic, como o recente fast mode research preview: lançado cedo, atrás de um toggle, e ainda com arestas por limar. Trate-o como um preview, porque é isso mesmo. A especificação completa está na documentação oficial de workflows.
Workflows vs Subagents vs Skills: Quem Detém o Plano?
A forma mais limpa de distinguir estes três é fazer uma pergunta: quem detém o plano? Uma skill é um conjunto empacotado de instruções e conhecimento que o Claude carrega a pedido. Um subagent é um contexto separado que executa uma tarefa delegada. Um workflow é o script de orquestração que coordena subagents em escala, até 16 em simultâneo. A mesma caixa de ferramentas, três trabalhos diferentes.
Aqui está a comparação que a documentação oficial implica mas nunca apresenta lado a lado:
| Skill | Subagent | Workflow | |
|---|---|---|---|
| Quem detém o plano? | Você/Claude no contexto principal | Um contexto delegado separado | O script do workflow (runtime) |
| O que é | Instruções/conhecimento empacotado, carregado a pedido | Uma tarefa isolada no seu próprio contexto | Script JavaScript que orquestra subagents (≤16 em simultâneo) |
| Escala | n/a | Um punhado, coordenados por conversa | Até 16 em simultâneo / 1.000 por execução |
| Reexecutável como código? | Não | Não | Sim (guardar como /command) |
| Ideal para | Conhecimento/instruções reutilizáveis | Uma tarefa delegada | Mais agents do que uma conversa consegue acompanhar |
Se uma conversa do Claude ainda consegue manter o plano todo na cabeça, quer um subagent, não um workflow. No momento em que está a gerar mais agents do que você, o humano, consegue acompanhar em termos de quem faz o quê e em que ordem, o plano ultrapassou a conversa. É essa a linha que um workflow cruza.
Quer aprofundar a primeira parte? O nosso tutorial de skills cobre o empacotamento de conhecimento que o Claude carrega a pedido. E se está a ponderar se deve recorrer a um framework de agents completo em vez da orquestração nativa, essa comparação também ajuda. A nossa opinião honesta: os primitivos nativos vão mais longe do que pensa antes de um framework justificar o seu lugar.
Quando Precisa Realmente de Um Workflow do Claude Code?
Precisa de um workflow do Claude Code quando (a) a tarefa exige mais agents do que uma conversa consegue coordenar, (b) quer a orquestração guardada como código reexecutável em vez de um prompt pontual, ou (c) precisa de revisão adversarial ou cruzada em que múltiplos agents verificam o trabalho uns dos outros. Se nenhuma destas condições se verifica, os subagents chegam. Seja honesto consigo mesmo aqui.
Esta é a parte que a documentação não diz em voz alta, por isso dizemo-la nós: provavelmente ainda não precisa de um workflow. Um punhado de subagents, coordenados numa conversa normal, dá conta do trabalho do dia a dia. Os workflows não são uma melhoria para a qual se sobe de nível. São uma ferramenta para um formato específico de problema: mais agents do que um cérebro consegue acompanhar.
Passe por esta checklist. Provavelmente precisa de um workflow se responder sim a pelo menos uma:
- A tarefa precisa de mais agents do que uma conversa consegue acompanhar.
- Quer a orquestração como código reexecutável, não um prompt pontual que volta a escrever.
- Precisa de revisão adversarial ou cruzada (múltiplos agents a verificarem-se mutuamente).
- Vai executar a mesma tarefa multi-agent repetidamente, como uma auditoria recorrente à base de código ou uma migração de 500 ficheiros.
Respondeu não a todas as quatro? Fique com os subagents. Poupa tokens, mantém as coisas depuráveis e não perde nada. Quem segue a abordagem orientada a especificações reconhecerá este padrão das boas práticas de CLAUDE.md: escreva o plano uma vez, torne-o reexecutável, pare de o reescrever. Um workflow é essa ideia levada ao ponto em que o próprio plano precisa de um runtime para ser executado.
O Único Workflow Que Já Tem: /deep-research
O /deep-research é o único workflow incluído no preview. Invoque-o com uma pergunta e ele distribui subagents para pesquisar o tópico em paralelo, cruza as descobertas uns contra os outros e devolve uma resposta sintetizada ao seu contexto, tudo enquanto corre em segundo plano para que a sua sessão se mantenha utilizável.
/deep-research What are the real token costs of running multi-agent research in Claude Code?É esta toda a interface. Por baixo, avança por fases: divide a sua pergunta em linhas de pesquisa, gera agents para perseguir cada uma, corre uma fase de cruzamento ou revisão para que os agents apanhem as afirmações fracas uns dos outros, e depois sintetiza uma resposta final de volta no seu chat. Não o conduz a meio da execução. Pergunta, ele trabalha, ele reporta.
Isto é genuinamente útil para aquelas perguntas de pesquisa complicadas em que, de outra forma, abriria dez separadores e perderia a tarde. Se já está a montar ferramentas de pesquisa, o nosso resumo dos melhores servidores MCP combina bem com este tipo de pesquisa distribuída. Mas "útil" e "vale a fatura de tokens" não são a mesma coisa, que é exatamente o que nos propusemos medir.
O Que Aconteceu Quando Corremos Um Workflow Na Nossa Própria Pipeline
A nossa execução do /deep-research gerou 9 subagents em 4 fases, consumiu pouco mais de 1 milhão de tokens e terminou em cerca de 8 minutos de tempo real. Valeu a pena? Para uma pergunta rápida, de forma alguma. Para uma tarefa de pesquisa que, de outra forma, coordenaríamos à mão entre meia dúzia de agents, pagou-se a si mesma. Aqui está a análise honesta.
Na nossa pipeline, este artigo que está a ler foi ele próprio produzido por um sistema multi-agent: pesquisa, brief, escrita, validação, tradução e publicação correm cada um como subagents separados. Por isso já vivemos no mundo de "demasiados agents para uma conversa" da checklist acima. Isso fez de nós o caso de teste certo, não um forçado.
Corremos o /deep-research sobre uma palavra-chave ativa que já estávamos a pesquisar e registámos a execução completa:
| Métrica | A nossa execução do /deep-research |
|---|---|
| Subagents gerados | 9 |
| Fases | 4 (decompor → distribuir → cruzar → sintetizar) |
| Total de tokens | ~1,05M |
| Tempo real | ~8 minutos |
| Veredicto | Exagero para perguntas pontuais; compensa para pesquisa multi-fonte real |
O que mais nos surpreendeu foi a fase de cruzamento. Umas quantas afirmações iniciais que um agent produziu foram silenciosamente corrigidas depois de outro agent as questionar, que é o tipo de coisa que uma conversa única tende a deixar passar. Esse passo adversarial é o valor real, mais do que o paralelismo bruto. O custo em tokens é elevado, porém, e esses agents correm em modelos de nível Opus (veja o que há de novo no Opus 4.8 para perceber por que isso importa na fatura). Um milhão de tokens para uma pergunta a que poderia ter respondido em dois prompts é um mau negócio. Para uma pergunta que genuinamente precisa de seis fontes reconciliadas, é uma pechincha em tempo.
É este o tipo de orquestração que construímos para clientes na Techsy, por isso já tínhamos uma ideia forte de onde compensa e onde apenas queima orçamento. A nossa opinião: corra-o nas perguntas difíceis, salte-o nas fáceis.
Como Escrever e Guardar o Seu Próprio Workflow
Para criar o seu próprio workflow, descreva a tarefa ao Claude em linguagem simples usando a palavra-chave workflow, reveja e aprove o script que ele gera, e depois guarde esse script como um /command reutilizável. Para maior esforço, defina /effort ultracode e o Claude planeia um workflow por conta própria. Não precisa de JavaScript da sua parte; o Claude escreve o script, você aprova-o.
Aqui está o ciclo completo, que também serve de passos se estiver a acompanhar:
-
Ative os Dynamic workflows. No Pro, abra
/confige ative a linha Dynamic workflows. (Está na v2.1.154+, certo?)bash/config # then enable the "Dynamic workflows" row -
Descreva a tarefa com a palavra-chave
workflow. Inclua a palavraworkflowem qualquer parte do seu prompt, por exemplo: "Corre um workflow para auditar todos os ficheiros de rota neste repositório à procura de verificações de autenticação em falta." O Claude Code destaca a palavra e escreve um script em vez de trabalhar turno a turno. Quer que o Claude decida por si? Defina/effort ultracode, que combina raciocínioxhighcom orquestração automática de workflows para cada tarefa substancial (e consome mais tokens, por isso volte ao/effort highpara trabalho de rotina). -
Reveja e aprove o script gerado. O Claude mostra-lhe a orquestração JavaScript antes de executar qualquer coisa. Leia-a. É a sua oportunidade de apanhar uma distribuição mais ampla do que deseja.
-
Guarde-o como
/commandpara reutilização. Assim que funcionar, guarde o workflow como um slash command personalizado para que a auditoria do próximo trimestre seja um único toque de tecla.
A reutilização é a vitória silenciosa. Um /deep-research pontual é prático, mas um workflow guardado para "auditar autenticação em todas as rotas" ou "migrar este diretório para a nova API" transforma um trabalho de coordenação de várias horas num único comando repetível. É aí que o custo em tokens começa a amortizar-se entre execuções em vez de doer uma só vez.
Limites, Custos e Como Desativar os Workflows
Os workflows correm até 16 agents em simultâneo com um limite rígido de 1.000 agents por execução, não aceitam input a meio da execução e só são retomáveis dentro da mesma sessão. Consomem muitos tokens por design, uma vez que cada agent consome contexto. Pode desativar a funcionalidade por completo com disableWorkflows na configuração ou com a variável de ambiente CLAUDE_CODE_DISABLE_WORKFLOWS.
Cada um desses limites significa algo para a sua tarefa. Sem input a meio da execução significa que não pode corrigir o rumo depois de começar, por isso um prompt vago desperdiça tokens de uma execução inteira. Retomável apenas na mesma sessão significa que se fechar o terminal, a execução desaparece. 1.000 agents por execução parece enorme, mas uma distribuição ampla a preços de nível Opus é dinheiro real, por isso trate o padrão de 16 em simultâneo como uma funcionalidade, não como um teto a empurrar.
Para desativar:
export CLAUDE_CODE_DISABLE_WORKFLOWS=1
# or set "disableWorkflows": true in your configA armadilha da versão apanha as pessoas: se o /config não mostrar uma linha Dynamic workflows, está abaixo da v2.1.154. Atualize primeiro. E se está a construir pipelines de agents como esta para trabalho real e quer que realmente compensem, nós construímos pipelines de agents para equipas B2B. Obtenha uma consulta gratuita → se a orquestração se está a tornar um estrangulamento.
Conclusão
Aqui está o artigo todo em cinco linhas. Um workflow do Claude Code é um script JavaScript que o Claude escreve para orquestrar subagents em escala, lançado como research preview na v2.1.154. O que existe hoje é o /deep-research. Só precisa de um workflow quando uma tarefa ultrapassa o que uma conversa consegue coordenar, quando quer orquestração reexecutável, ou quando precisa que os agents se verifiquem mutuamente. A nossa execução real custou ~1M tokens para 9 agents em 8 minutos, o que é exagero para perguntas fáceis e compensa para pesquisa difícil. Provavelmente ainda não precisa de um, e não faz mal.
Sobre o Autor
Mert Batur Gurbuz é Co-Fundador da Techsy.io, onde a equipa entrega agents de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Estuda na University of Birmingham e escreve sobre a stack de ferramentas LLM que a equipa da Techsy realmente usa em produção.
Co-Fundador, Techsy.io, University of Birmingham · LinkedIn
Perguntas Frequentes
O que é um workflow do Claude Code?
Um workflow do Claude Code é um script JavaScript que orquestra subagents em escala. Descreve a tarefa, o Claude escreve o script, e um runtime executa-o em segundo plano enquanto a sua sessão se mantém responsiva. É uma funcionalidade em research preview no Claude Code v2.1.154+, disponível em todos os planos pagos.
Qual é a diferença entre um workflow e um subagent?
Um subagent é uma única tarefa delegada a correr no seu próprio contexto separado, coordenada por si em conversa. Um workflow é o script de orquestração que coordena subagents em simultâneo, até 16. Se uma conversa ainda consegue manter o plano todo, use um subagent. Se o plano precisa de um runtime para acompanhar os agents, use um workflow.
Quanto custa um workflow do Claude Code em tokens?
Na nossa execução medida do /deep-research, 9 subagents em 4 fases consumiram aproximadamente 1,05 milhões de tokens em cerca de 8 minutos. Os workflows consomem muitos tokens por design porque cada agent consome o seu próprio contexto, e esses agents correm em modelos de nível Opus. Para perguntas simples é desperdício; para pesquisa multi-fonte genuína justifica o custo.
Preciso de um plano pago para usar workflows do Claude Code?
Sim. Os Dynamic workflows correm em todos os planos pagos do Claude (Pro, Max, Team, Enterprise) além da API e Bedrock/Vertex/Foundry. Não existe acesso no plano gratuito. No Pro, ativa a funcionalidade ligando a linha Dynamic workflows em /config depois de atualizar para o Claude Code v2.1.154 ou posterior.
O que é o /deep-research no Claude Code?
O /deep-research é o único workflow incluído no research preview. Dá-lhe uma pergunta e ele distribui subagents para pesquisar o tópico em paralelo, corre uma fase de cruzamento em que os agents verificam as descobertas uns dos outros, e depois sintetiza uma resposta de volta ao seu contexto, tudo enquanto corre em segundo plano.
Como guardo um workflow como slash command?
Descreva a tarefa ao Claude usando a palavra-chave workflow, reveja e aprove o script JavaScript que ele gera, e depois guarde esse script aprovado como um /command personalizado. Depois disso, toda a tarefa multi-agent corre com um único toque de tecla, que é onde os workflows começam a amortizar o seu custo em tokens entre execuções repetidas.
Quantos agents pode um workflow correr em simultâneo?
Um workflow corre até 16 agents em simultâneo, com um limite rígido de 1.000 agents por execução. O padrão de 16 em simultâneo existe por boa razão: uma distribuição ampla a preços de nível Opus fica cara rapidamente. Trate os limites como proteções e não como metas, e mantenha a sua distribuição tão estreita quanto a tarefa permitir.
Como desativo os Dynamic workflows?
Defina disableWorkflows como true na sua configuração, ou exporte a variável de ambiente CLAUDE_CODE_DISABLE_WORKFLOWS=1 antes de iniciar o Claude Code. Qualquer uma desativa a funcionalidade por completo. Se simplesmente não vir uma linha Dynamic workflows em /config, provavelmente está abaixo da v2.1.154 necessária e precisa de atualizar primeiro.
Precisa realmente de workflows do Claude Code, ou os subagents chegam?
Os subagents chegam até uma tarefa ultrapassar uma conversa. Um punhado de subagents coordenados numa conversa normal cobre o trabalho do dia a dia sem o custo em tokens. Só precisa genuinamente de um workflow quando uma tarefa gera mais agents do que uma conversa consegue acompanhar, quando quer orquestração reexecutável como código, ou quando precisa que os agents se verifiquem mutuamente de forma adversarial.