Distribuição de Tarefas no Claude Code
Divida o trabalho no Claude Code em sub-agentes Task paralelos com um padrão de delegação de 7 slots. Regras de fronteiras, princípios de coordenação e erros a evitar.
Pare de configurar. Comece a construir.
Templates SaaS com orquestração de IA.
Problema: Projetos maiores no Claude Code ficam travados por execuções single-threaded. Você fica ali a ver o Claude a fazer uma coisa de cada vez, quando o mesmo trabalho podia estar a ser feito por vários agentes em paralelo. A velocidade de desenvolvimento cai para o ritmo da etapa serial mais lenta.
Solução rápida: Adicione este padrão de delegação ao seu CLAUDE.md e depois referencie-o quando pedir uma funcionalidade complexa:
# Feature Implementation Pattern
When implementing features, use 7-parallel-Task distribution:
1. **Component**: Create main component file
2. **Styles**: Create component CSS/styling
3. **Tests**: Create test files
4. **Types**: Create TypeScript definitions
5. **Hooks**: Create custom hooks/utilities
6. **Integration**: Update routing and imports
7. **Config**: Update docs and package.jsonPeça uma funcionalidade e o Claude lê a instrução no CLAUDE.md, depois cria vários agentes Task em paralelo em vez de os enfileirar um a um.
Como a Orquestração de Tasks Funciona de Facto
A ferramenta Task é o mecanismo por detrás da execução paralela no Claude Code. Chamar a ferramenta Task cria um sub-agente independente com a sua própria janela de contexto. O agente principal do Claude tem custos de interatividade. Ele espera por respostas humanas, alterna entre operações e mantém o estado da conversa ativo. Os sub-agentes Task eliminam esses custos ao executar trabalho especializado de forma independente.
Por defeito, o Claude trata de leituras de ficheiros, pesquisas e buscas de conteúdo através de ferramentas dedicadas (Read, Grep, Glob) na thread principal. A Task é reservada para criar sub-agentes. Sem instruções explícitas de delegação, o Claude raramente cria agentes paralelos e prefere execução sequencial. A instrução no CLAUDE.md muda esse comportamento padrão.
A Mentalidade Multi-Threaded
Pense como um programador a gerir threads. O Claude consegue coordenar vários agentes especializados ao mesmo tempo, mas só quando a delegação está claramente definida. Sem fronteiras de tarefas, o Claude volta ao trabalho serial toda as vezes.
Princípios fundamentais de coordenação:
- Definição de Fronteiras: Cada agente tem tipos de ficheiros ou operações específicos
- Evitar Conflitos: Dois agentes nunca escrevem no mesmo recurso
- Otimização de Contexto: Elimine detalhes desnecessários antes de delegar
- Agrupamento Lógico: Agrupe tarefas pequenas relacionadas para evitar fragmentação excessiva
Acertar no roteamento à mão para cada pedido é a parte difícil. Um classificador baseado em complexidade pode ordenar os trabalhos automaticamente: correções triviais vão diretamente para um especialista, tarefas moderadas recebem um único sub-agente, e trabalho complexo multi-fase passa por um pipeline de planeamento antes de os agentes paralelos serem despachados. Configure uma vez e o roteamento deixa de ser uma decisão manual.
Padrões de Distribuição Paralela
O Padrão de 7 Agentes para Funcionalidades
Adicione isto ao CLAUDE.md para ativar a distribuição paralela automática:
## Parallel Feature Implementation Workflow
When implementing features, spawn 7 parallel Task agents:
1. **Component**: Create main component file
2. **Styles**: Create component styles/CSS
3. **Tests**: Create test files
4. **Types**: Create type definitions
5. **Hooks**: Create custom hooks/utilities
6. **Integration**: Update routing, imports, exports
7. **Remaining**: Update package.json, docs, config files
### Context Optimization Rules
- Strip comments when reading code files for analysis
- Each Task handles ONLY specified files or file types
- Task 7 combines small config/doc updates to avoid over-fragmentationA construção de funcionalidades fica significativamente mais rápida porque os bloqueios seriais desaparecem. O Claude lê a instrução e distribui o trabalho pelos agentes Task sem você ter de dizer isso de cada vez.
Delegação Baseada em Papéis
Para revisão e análise de código, diga ao Claude para criar agentes Task especializados:
Analyze this codebase using parallel Task agents with these roles:
- Senior engineer: Architecture and performance
- Security expert: Vulnerability assessment
- QA tester: Edge cases and validation
- Frontend specialist: UI/UX optimization
- DevOps engineer: Deployment considerationsCada papel tende naturalmente para ferramentas e perspetivas diferentes, por isso o output combinado é mais completo do que qualquer execução de agente único conseguiria.
Distribuição por Domínio
Para trabalho de backend, use uma estrutura paralela explícita:
Implement user authentication system using parallel Task agents:
1. Database schema and migrations
2. Auth middleware and JWT handling
3. User model and validation
4. API routes and controllers
5. Integration tests
6. Documentation updatesVerificação de Sucesso: O Claude vai chamar a ferramenta Task várias vezes numa resposta, criando agentes que correm ao mesmo tempo. Funcionalidades que demoram no modo serial ficam prontas significativamente mais rápido quando o trabalho é paralelizado.
Regras de Coordenação
Custo de tokens vs. desempenho: Mais agentes Task nem sempre é melhor. Cada chamada Task paga um custo de configuração de contexto. Agrupar operações relacionadas costuma ser melhor do que criar um agente novo para cada trabalho pequeno.
Preservação de contexto: Quando o Claude delega, decide que contexto cada agente recebe. Escreva as suas instruções de forma que cada agente veja a informação específica do domínio de que precisa, sem que o resto do projeto venha junto.
Resolução de conflitos: Desenhe as fronteiras das tarefas para evitar colisões de escrita. Divida por ficheiro ou por funcionalidade, nunca por linhas individuais dentro de um ficheiro. Dois agentes a escrever no mesmo ficheiro cria conflitos de merge.
Integração de resultados: Os agentes Task devolvem os seus resultados à sessão principal. Planeie como os outputs vão ser integrados. Pense nas dependências entre tarefas paralelas durante a fase de orquestração, não depois.
Padrões Avançados de Distribuição
Estes padrões vão além do paralelismo simples. Resolvem problemas de coordenação que aparecem quando se começa a correr 5+ agentes em funcionalidades reais.
Cadeias de Validação
O padrão de qualidade mais comum separa construção de verificação. Os agentes de implementação correm em paralelo, você espera que todos terminem, depois os agentes de validação correm sequencialmente sobre o output combinado. A validação tem de ser sequencial porque os validadores precisam de ver o estado final de todos os ficheiros, não o fragmento em voo que lhes foi atribuído.
# Implementation phase (parallel Task agents)
Tasks 1-5: Core feature development
# Validation phase (sequential, after implementation)
Task 6: Integration testing
Task 7: Security review
Task 8: Performance verificationSem a estrutura de duas fases, os agentes de validação inspecionam ficheiros enquanto outros agentes ainda estão a escrever neles. Obtém falsos positivos e problemas não detetados. Para mais sobre como emparelhar especialistas com validadores, veja os padrões de design de sub-agentes.
Coordenação de Investigação
As tarefas de investigação paralelizam bem porque são só de leitura. Nenhum agente escreve em ficheiros partilhados, por isso o risco de conflito é zero. Isso torna a investigação a entrada mais segura para a distribuição de tarefas.
Research user dashboard implementations using parallel Tasks:
1. **Technical**: React dashboard libraries and patterns
2. **Design**: Modern dashboard UI/UX examples
3. **Performance**: Optimization strategies for data-heavy UIs
4. **Accessibility**: WCAG compliance for dashboard interfacesCada agente devolve um resumo estruturado. O orquestrador junta os quatro relatórios numa recomendação. Isto é mais rápido do que pedir a um agente para investigar as quatro dimensões do início ao fim, e os contextos isolados evitam que um thread de investigação influencie outro.
Projetos Entre Domínios
Funcionalidades full-stack tocam frontend, backend e infraestrutura ao mesmo tempo. A abordagem em cascata (construir backend primeiro, depois frontend, depois infra) é segura mas lenta. A distribuição paralela entre domínios é mais rápida, mas exige fronteiras de ficheiros estritas.
A regra: cada agente tem um diretório, nunca um único ficheiro partilhado com outro agente. O agente de backend tem o src/api/, o agente de frontend tem o src/components/, e o agente de infraestrutura tem o infra/. O contrato partilhado entre eles é um ficheiro de interface TypeScript ou esquema de API que um agente escreve primeiro (sequencialmente) antes de a fase paralela começar. Para uma análise mais detalhada sobre como estruturar este tipo de coordenação multi-domínio, veja os padrões de orquestração de equipas.
Erros Comuns de Distribuição
Fragmentação excessiva. Criar um agente Task novo para cada operação pequena consome tokens em configuração sem melhorar a velocidade. Prompts que criam 12 agentes para uma funcionalidade que toca 4 ficheiros são comuns. Cada agente precisa de contexto de inicialização (carregar o CLAUDE.md, perceber a tarefa), por isso 12 agentes pagam o overhead 12 vezes antes de qualquer trabalho real começar. A correção: agrupe micro-tarefas relacionadas. Um agente que trata de "tipos, interfaces e esquemas de validação" é mais barato e rápido do que três agentes a fazer um ficheiro cada.
Especificação insuficiente. Delegação vaga força os agentes a adivinhar o âmbito. Diga a um agente "trata do frontend" e ele pode reescrever o seu routing, refatorar componentes que nunca tocou e incluir bibliotecas que não pediu. O fluxo paralelo quebra porque os outros agentes esperavam a API de componentes existente. Uma boa delegação nomeia os ficheiros exatos a criar ou modificar, as assinaturas de função esperadas e o formato de output. "Crie src/components/Dashboard.tsx que exporta um componente Dashboard que aceita DashboardProps com uma prop data: TimeSeriesPoint[]" é o nível certo de especificidade.
Conflitos de recursos. Este é o erro mais destrutivo porque produz código que parece completo mas está silenciosamente partido. Dois agentes a escrever no mesmo ficheiro barrel index.ts sobrescrevem as exportações um do outro. O último a escrever ganha. As exportações do outro agente desaparecem. A build pode ainda passar se nada importar as exportações em falta ainda. Só descobre o problema mais tarde quando tenta usar a funcionalidade. Atribua a propriedade dos ficheiros ao nível do agente, nunca ao nível da função.
Duplicação de contexto. Um CLAUDE.md muito extenso é passado a todos os agentes criados. 400 linhas de CLAUDE.md em 7 agentes significa 7 cópias de 400 linhas carregadas em contextos separados. O orquestrador decide o que cada agente recebe, mas tende para a inclusão. Mantenha o CLAUDE.md focado em regras operacionais em vez de documentação enciclopédica do projeto, e deixe os agentes ler os ficheiros específicos de que precisam em vez de herdarem tudo à partida.
O Que Acontece Quando a Distribuição Corre Mal
Aqui está um modo de falha real. Um programador dividiu uma funcionalidade de definições de utilizador por 5 agentes: um para a migração da base de dados, um para a rota API, um para o componente de formulário React, um para testes e um para tipos TypeScript. Parece razoável. O problema: o agente de tipos e o agente de API precisavam de concordar na forma da interface UserSettings, mas correram em paralelo sem contrato partilhado.
O agente de tipos criou UserSettings com um campo preferences como objeto plano. O agente de API construiu a rota esperando preferences como uma estrutura aninhada com sub-objetos theme e notifications. O agente de formulário React assumiu ainda outra forma porque as suas instruções apenas diziam "construa um formulário de definições". Os três agentes terminaram com sucesso. A build falhou com 14 erros de tipo.
A correção era óbvia a posteriori: executar o agente de tipos primeiro (sequencialmente), depois expandir os agentes restantes em paralelo. Esse passo sequencial de 30 segundos teria evitado 20 minutos de debugging. A lição é que interfaces partilhadas são dependências, e dependências têm de correr antes das tarefas que as consomem. É por isso que o padrão de cadeia de validação acima existe.
Próximas Ações
Comece com o padrão de 7 agentes na próxima implementação complexa. Cole a configuração do CLAUDE.md e depois peça uma funcionalidade. Várias chamadas à ferramenta Task devem aparecer na resposta do Claude.
Fique confortável com a distribuição de tarefas paralelas praticando a par do guia de Design de Sub-Agentes, depois escale para coordenação avançada com os Fundamentos de Agentes.
Para decidir entre execução paralela, sequencial e em segundo plano, veja o guia de melhores práticas de sub-agentes.
Para padrões de implementação específicos, veja os Agentes Personalizados e crie distribuidores de tarefas especializados para o seu fluxo de trabalho.
Observe a velocidade de conclusão das suas tarefas. Uma execução devidamente distribuída deve entregar resultados notavelmente mais rápidos do que a execução serial. Acompanhe a métrica. Deixe que ela molde como dimensiona e divide a próxima ronda de trabalho.
Pare de configurar. Comece a construir.
Templates SaaS com orquestração de IA.
Design de Sub-Agentes no Claude Code
Divida uma revisão de código difícil entre sub-agentes especialistas. Arquitetura, segurança e desempenho correm cada um no seu próprio contexto, e os resultados convergem em minutos.
Equipas de Agentes Builder-Validator
Parea um agente builder com um validator de só leitura no Claude Code. A Tarefa 2 bloqueia na Tarefa 1 via addBlockedBy, para que cada output de sub-agente tenha um segundo par de olhos.