Orquestração e agents paralelos
Um agent é um pair programmer. Vários agents são uma equipe pequena, e uma equipe precisa de isolamento, de uma forma de ver quem está fazendo o quê e de um humano que revise os merges.
Por que rodar agents em paralelo
Muitas tarefas são independentes: uma correção de bug, um preenchimento de testes, uma revisão da documentação, uma atualização de dependência. Executá-las ao mesmo tempo transforma espera em vazão. Os limites não são computação, e sim atenção e conflitos: você precisa revisar cada resultado, e dois agents editando os mesmos arquivos vão colidir.
Isolamento com git worktrees
Um dá a cada agent o seu próprio diretório de trabalho e branch do mesmo repositório, de modo que não podem sobrescrever os arquivos um do outro e cada resultado chega como uma branch que você pode revisar e fazer merge.
# a partir do checkout principal
git worktree add ../app-fix-login -b agent/fix-login
git worktree add ../app-add-tests -b agent/add-tests
git worktree add ../app-upgrade-dep -b agent/upgrade-dep
# inicie um agent em cada diretório (qualquer harness) e depois revise cada branch
git -C ../app-fix-login diff main --stat
# limpe depois do merge
git worktree remove ../app-fix-loginVendo e gerenciando muitas sessões
- Um multiplexador de terminal como o tmux mantém as sessões vivas e permite alternar entre elas.
- herdr é um multiplexador feito para agents: painéis de terminal reais para cada agent em um workspace persistente, uma barra lateral que mostra quais agents estão trabalhando, bloqueados esperando você ou concluídos, detach e reattach, e uso via SSH. Ele organiza os agents; não os substitui.
- Alguns harnesses têm subagents embutidos: o agent principal delega um trabalho focado a um ajudante com contexto próprio e recebe de volta um resumo.
- Plugins de orquestração como o (OMO) sobre o OpenCode adicionam papéis predefinidos (um coordenador, um planejador, executores, pesquisadores) e um modo em que a equipe resolve uma tarefa com pouca supervisão.
Padrões que funcionam
- Planejador, implementador, revisor: um agent planeja, outro implementa, um terceiro revisa, idealmente em um modelo diferente para ter uma visão independente.
- Fan-out: divida uma grande mudança mecânica por diretório ou módulo e execute um agent por fatia.
- Pesquisa em paralelo: vários agents somente leitura investigam perguntas diferentes e reportam; nenhum deles edita.
- Sempre termine com um merge humano: os agents abrem pull requests, o CI roda, uma pessoa decide.
Riscos e limites
- Dívida de revisão: dez agents geram dez diffs. Se você não consegue revisá-los, está apenas criando código não lido.
- Custo: modos paralelos e autônomos queimam tokens rapidamente. Defina orçamentos e acompanhe o uso.
- Recursos compartilhados: bancos de dados, portas e APIs externas não são isolados por um worktree.
- : um agent com permissões amplas rodando sem supervisão pode causar um dano amplo. Use uma sandbox ou container, credenciais com escopo e nenhum acesso à produção.
- Mais camadas, mais confiança: todo plugin e ferramenta de orquestração roda com as suas permissões. Fixe versões e leia o que instala.
conexões no mapa
- Context engineering para agents de códigoescala paraOrquestração e agents paralelos
- Orquestração e agents paralelosproduz trabalho paraO loop de verificação
atualizado em 14/10/2026 · fontes para aprofundar · reportar erro
em outros domínios
- Hardening de CI/CDsecengagentes autônomos exigem a mesma disciplina de runners e credenciais
Estude antes
teste o que entendeu
Carregando perguntas…