📐 Sequencial vs Paralelo: estudo comparativo

O opencode-swarm e um dos projetos multiagentes mais bem documentados do ecossistema, com 828+ commits e um pipeline sequencial rigoroso de 8 subagentes. Cada agente opera em uma etapa especifica e so pode passar para a proxima apos completar a sua com aprovacao. O fluxo e: Explorer (escaneia o codebase) → SME (especialista no dominio) → Architect (desenha a solucao) → Critic (avalia o plano) → Coder (implementa) → Reviewer (revisa) → Test (testa) → Docs (documenta).

A filosofia por tras dessa abordagem e que a confiabilidade supera a velocidade. Em vez de tentar fazer tudo ao mesmo tempo e lidar com conflitos, o pipeline sequencial garante que cada etapa recebe o resultado validado da etapa anterior. A maquina de estados (state machine) governa as transicoes — nao e possivel pular etapas ou executar fora de ordem. O resultado e previsivel, auditavel e depuravel, porque voce pode examinar exatamente o que cada agente recebeu e produziu.

Em contraste direto com o pipeline sequencial, o oh-my-openagent (OMO) adota o paradigma paralelo. O orquestrador Sisyphus — nomeado em homenagem ao personagem mitico que nunca desiste — recebe a tarefa, decompoe em subtarefas independentes e dispara multiplos agentes simultaneamente. Enquanto o agente de backend implementa a API, o agente de frontend constroi os componentes visuais e o agente de testes prepara os casos de teste — tudo ao mesmo tempo.

O desafio do modelo paralelo e a coordenacao. Quando multiplos agentes editam o projeto simultaneamente, conflitos sao inevitaveis sem mecanismos de protecao. O OMO resolve isso com zonas seguras (cada agente trabalha em arquivos/diretorios exclusivos), hash checking (deteccao automatica de conflitos quando agentes tocam regioes proximas) e merge coordenado pelo Sisyphus (o orquestrador integra os resultados de todos os agentes ao final, resolvendo conflitos remanescentes).

A pergunta que todo arquiteto de swarms faz e: "Qual abordagem e melhor?". A resposta honesta e: depende do que voce otimiza. Dados reais mostram que a abordagem paralela e significativamente mais rapida, mas a abordagem sequencial produz resultados mais confiaveis. O dado mais impressionante vem do impacto do hash checking em swarms paralelos: sem ele, a taxa de sucesso em tarefas complexas era de apenas 6%. Com hash checking habilitado, essa taxa saltou para 68.3%.

Esse salto de 6% para 68.3% demonstra algo fundamental: o paralelismo sem mecanismos de protecao e quase inutil. Agentes que editam o mesmo codebase simultaneamente sem deteccao de conflitos produzem resultados corrompidos na vasta maioria das vezes. Mas com os mecanismos certos (hash checking, zonas seguras, merge coordenado), o paralelismo se torna viavel e imensamente mais rapido. A abordagem sequencial, por outro lado, comeca com taxa de sucesso mais alta (~75-85%) mas leva 3-5x mais tempo para completar.

O opencode-swarm nao e apenas um projeto — e um laboratorio de aprendizado com 18 decisoes de design documentadas em seu arquivo design-rationale.md. Cada decisao tem uma justificativa clara, alternativas consideradas e razoes para a escolha. Estudar essas decisoes e como ter acesso ao caderno de notas de um arquiteto experiente que ja enfrentou (e resolveu) os problemas que voce vai encontrar.

Tres decisoes merecem destaque especial por serem contra-intuitivas: "serial over parallel" (escolher serial quando paralelo parece mais eficiente), "persistent memory" (manter estado em disco em vez de em memoria) e "heterogeneous models" (usar modelos diferentes deliberadamente em vez de padronizar). Cada uma dessas decisoes vai contra o instinto inicial de um engenheiro, mas tem justificativas solidas baseadas em experiencia real com 828+ commits.

O opencode-swarm implementa 6 gates de qualidade automatizados que cada tarefa deve passar antes de ser aceita. Esses gates nao sao verificacoes subjetivas feitas por LLMs — sao checagens programaticas, deterministicas e reproduziveis. Se um gate falha, o agente responsavel recebe feedback especifico e deve corrigir o problema antes de tentar novamente. Nenhum codigo chega ao final do pipeline sem passar por todos os 6 gates.

Esta abordagem resolve um problema fundamental dos swarms: como garantir qualidade quando quem produz e quem verifica sao ambos LLMs? A resposta e nao depender apenas de LLMs para verificacao. Os gates usam ferramentas tradicionais de engenharia de software — linters, analisadores estaticos, compiladores, test runners — que produzem resultados objetivos e incontestáveis. O LLM escreve o codigo; a ferramenta automatica verifica se o codigo e valido.

Um dos conceitos mais inovadores do opencode-swarm e o sistema Curator — um mecanismo de monitoramento quantitativo que mede continuamente o desvio (drift) entre o plano original e a implementacao real. Em qualquer projeto complexo, a implementacao tende a se afastar do plano: o Coder faz escolhas diferentes das planejadas pelo Architect, ou descobre obstaculos que exigem mudancas de rota. O Curator detecta essas divergencias e alerta antes que se tornem problemas.

O drift e quantificado em uma escala de 0.0 a 1.0, com quatro categorias: ALIGNED (0.0-0.2, implementacao segue o plano fielmente), MINOR (0.2-0.5, desvios pequenos e aceitaveis), MAJOR (0.5-0.8, desvios significativos que exigem revisao do plano) e OFF_SPEC (0.8-1.0, implementacao diverge tanto do plano que precisa ser refeita). Quando o drift atinge MAJOR, o Curator notifica o orquestrador, que pode pausar a execucao, revisar o plano e realinhar a equipe.