Agentes paralelos no Gemini CLI: como executar várias tarefas do Gemini simultaneamente

Uma sessão do Gemini CLI é um único agente trabalhando em um único diretório. No momento em que você quer uma segunda tarefa andando ao mesmo tempo — a correção de um bug enquanto um refactor roda, testes sendo escritos enquanto uma feature entra em produção —, você abre outro terminal. Depois um terceiro. Em uma hora você tem quatro abas, quatro diretórios de trabalho e nenhuma resposta clara para uma pergunta simples: qual agente está fazendo o quê, e qual deles acabou de mexer no arquivo que você estava prestes a editar.

Rodar várias tarefas do Gemini lado a lado não é difícil de começar. Difícil é não se perder. Cada instância é rápida por conta própria; o custo está na coordenação, e coordenação é justamente o que o terminal nunca te dá.

Este artigo percorre a configuração manual para agentes do Gemini CLI em paralelo, aponta o modo de falha que espera em cada etapa e mostra onde um quadro de tarefas assume o controle. Esse quadro de tarefas é o Sharkly, uma plataforma tudo-em-um de comando e gestão de Agentes. O Sharkly não substitui o Gemini CLI. Ele adiciona a camada compartilhada de tarefas, Computers, contexto e revisão em torno dos runtimes que sua equipe já usa, para que execuções paralelas continuem atribuíveis e rastreáveis em vez de espalhadas por abas.

O que “agentes em paralelo” significa no Gemini CLI

O Gemini CLI executa um agente por processo. Ele lê o diretório atual, carrega qualquer arquivo de contexto GEMINI.md e trabalha o seu prompt naquela única árvore de trabalho. Não existe um dispatcher nativo que distribua um objetivo entre vários subagentes e junte o trabalho deles de volta para você.

Então, na prática, “agentes Gemini em paralelo” significa uma coisa: vários processos gemini rodando ao mesmo tempo, cada um em seu próprio ambiente isolado, cada um com sua própria tarefa. O Gemini CLI é open source e pode ser usado gratuitamente com uma conta pessoal do Google, e é exatamente por isso que as pessoas sobem quatro de uma vez. O gargalo nunca foi iniciá-los. É evitar que quatro execuções independentes colidam no mesmo repositório e saber, uma hora depois, o que cada uma produziu.

É o mesmo problema de coordenação que você enfrenta com o Claude Code ou o Codex. O runtime muda; o caos, não.

A configuração manual, passo a passo

Aqui está a versão mínima que funciona de Gemini CLI em paralelo, junto com o que quebra em cada etapa.

Passo 1: Dê a cada agente sua própria árvore de trabalho. Não rode dois agentes na mesma pasta. Use um git worktree por tarefa, para que cada checkout seja fisicamente separado:

git worktree add ../repo-auth   feature/auth
git worktree add ../repo-tests  chore/tests
git worktree add ../repo-bugfix fix/login-redirect

Modo de falha se você pular isso: dois agentes editando o mesmo checkout se sobrescrevem no meio da execução. Um reformata um arquivo que o outro está no meio de editar, e os dois deixam a árvore num estado que nenhum dos dois queria. Worktrees dão a cada agente um branch limpo e um diretório limpo. Aprofundamos esse assunto em git worktrees para agentes de código com IA.

Passo 2: Inicie um Gemini CLI por worktree. Abra um terminal em cada diretório e inicie uma sessão:

cd ../repo-auth && gemini

Para execuções sem supervisão, use o modo não interativo, assim o agente recebe um único prompt e sai:

cd ../repo-tests && gemini -p "Add unit tests for the session module. Run the suite before finishing."

Modo de falha: uma sessão interativa para no primeiro pedido de permissão e fica esperando. Você volta vinte minutos depois e encontra um agente que não fez nada porque precisava de um "sim". Decida desde o início quais execuções são interativas e quais são headless, e dê às headless um prompt que inclua a própria etapa de verificação.

Passo 3: Isole o contexto por tarefa. Cada worktree pode ter seu próprio GEMINI.md com as regras daquela tarefa: o que mexer, o que deixar em paz, como rodar os testes.

Modo de falha: um único arquivo de contexto compartilhado por todos os agentes faz uma instrução destinada à tarefa de auth vazar para a tarefa de testes. Limite o contexto à árvore à qual ele pertence.

Passo 4: Fique de olho na cota. Toda instância em execução consome dos mesmos limites da conta. Quatro agentes torrando um refactor grande batem nos limites de taxa mais rápido do que um, e um agente estrangulado falha silenciosamente numa aba que você não está olhando.

Modo de falha: uma execução trava por erro de cota e você só percebe quando olha aquela aba. Não existe uma visão compartilhada que te avise que um agente parou. Se você está combinando tarefas mais pesadas com o modelo certo, qual modelo para qual tarefa de programação cobre esse trade-off.

Com três ou quatro tarefas, isso funciona. Branches de verdade, isolamento de verdade, paralelismo de verdade, sem ferramentas extras.

Onde a configuração faça-você-mesmo para de escalar

A configuração manual não quebra na execução, mas em tudo o que está em volta dela. Veja o que acontece conforme o número de tarefas sobe.

Você perde o mapa. Com quatro terminais, dá para manter tudo na cabeça. Com oito, em dois repositórios, não dá. Qual aba é o agente de auth? A execução dos testes terminou ou morreu com erro de cota? Monitorar agentes de código rodando em paralelo é um trabalho para o qual o terminal nunca foi feito.

Os resultados se espalham. Cada agente deixa seu trabalho como um diff num branch e uma parede de scrollback numa aba que você vai fechar. Não há um registro compartilhado do que cada execução mudou, por quê, ou se passou nos próprios testes. Quando um colega pergunta o que a correção do login fez, a resposta mora num terminal que já não existe.

A revisão não tem onde morar. Agentes em paralelo produzem diffs em paralelo, e cada um deles ainda precisa de um humano para aceitá-lo. Ler quatro branches sem resumo, sem resultados de verificação e sem contexto é mais lento do que os agentes foram rápidos. A velocidade que você ganhou na execução, você devolve na revisão.

Aqui está o par de decisões honesto. Se você roda três ou quatro tarefas do Gemini de vez em quando, fique com a configuração de worktrees acima; ela é simples e funciona, e um quadro de tarefas seria uma sobrecarga que você não precisa. Recorra a um quando execuções paralelas se tornarem rotina: vários agentes, mais de um repositório, mais de uma pessoa precisando acompanhar o progresso e uma revisão que precise ser rastreável, não apenas lembrada. Comparar as ferramentas que gerenciam agentes paralelos vale a pena nesse momento.

O que um quadro de tarefas acrescenta

Um quadro de tarefas muda a unidade de trabalho de “uma aba de terminal” para “uma Tarefa”. É exatamente essa mudança que falta na configuração manual.

Com o Sharkly, você atribui uma Tarefa a um Agente baseado no Gemini CLI. O Agente assume a Tarefa, trabalha em um worktree isolado, e a execução, os bloqueios, os resultados e a discussão de acompanhamento voltam para a linha do tempo da Tarefa, em vez de sumirem em terminais privados. Rode vários ao mesmo tempo e cada um é uma linha que você enxerga, não uma aba que você precisa procurar. O Gemini CLI continua fazendo a codificação; o Sharkly gerencia a atribuição, os Computers conectados, o contexto e a revisão de cada execução.

A divisão do trabalho permanece clara. Os agentes pesquisam, executam, testam e reportam. As pessoas definem a direção, concedem autoridade e aceitam o resultado. A automação para onde o julgamento da equipe é necessário, e cada execução volta com um resumo das mudanças e seus próprios resultados de verificação, de modo que aceitar ou rejeitar um diff leva um olhar, não uma escavação arqueológica. Contexto, progresso, bloqueios, resultados e revisão humana permanecem visíveis da solicitação até a entrega.

Você mantém o que já tem. O Sharkly não pede que você abandone o Gemini CLI nem que se comprometa com um único runtime. Como é neutro em relação a provedores, o mesmo quadro de tarefas roda agentes do Claude Code e do Codex ao lado dos seus agentes Gemini, então seu fluxo de trabalho sobrevive a qualquer que seja o próximo melhor agente. Essa neutralidade é o ponto: você gerencia seus agentes em um só lugar, em vez de trocar de ecossistema toda vez que surge um novo.

A checklist que você pode aplicar hoje

Confira isto antes do seu próximo lote de tarefas do Gemini em paralelo:

[ ] Um git worktree por tarefa; nunca dois agentes no mesmo checkout.
[ ] Um GEMINI.md delimitado para cada tarefa, não um arquivo compartilhado por todas.
[ ] Execuções headless usam gemini -p com uma etapa de verificação embutida, para não travarem em um prompt.
[ ] Um teto conhecido de instâncias simultâneas, para que a cota compartilhada não estrangule uma execução que você não consegue ver.
[ ] Um único lugar que responda “qual agente está com o quê, e o que terminou”, sem abrir todas as abas.
[ ] Toda execução concluída deixa um resumo das mudanças e resultados de teste que um humano possa revisar, não apenas um diff num branch.

Os quatro primeiros você consegue fazer com worktrees e terminais hoje à noite. Os dois últimos são onde a configuração manual chega ao limite. Se você já roda vários agentes do Gemini CLI ao mesmo tempo, o Sharkly te dá um único lugar para atribuir suas tarefas, acompanhar o progresso e revisar os resultados. Você pode construir a camada de coordenação por conta própria, ou rodar seus agentes de código atuais pelo Sharkly e ir direto para a parte que escala.