Self-Organizing Multi-Agent Systems for Continuous Software Development

1. Problema Identificado

O desenvolvimento de software real é um processo contínuo que evolui ao longo de semanas, meses e anos, envolvendo ciclos iterativos de planejamento, implementação, teste e revisão. Embora os sistemas baseados em Grandes Modelos de Linguagem (LLMs) e agentes multi-agentes (como ChatDev e MetaGPT) tenham mostrado sucesso na geração de código para tarefas pontuais, eles apresentam três lacunas críticas para o desenvolvimento de software de longo prazo:

1. Orquestração Persistente Limitada: A maioria dos sistemas opera em sessões isoladas. Eles não conseguem manter o contexto cumulativo do projeto, rastrear o progresso em direção a marcos (milestones) ou retomar o trabalho automaticamente após interrupções, dificultando projetos que exigem refinamento iterativo ao longo de dias ou semanas.
2. Composição de Equipe Estática: Os agentes em frameworks existentes possuem papéis predeterminados e fixos. Eles não adaptam a composição da equipe (contratar, especializar ou demitir agentes) em resposta às necessidades emergentes do projeto ou feedback de verificação, ao contrário das equipes de software humanas que evoluem dinamicamente.
3. Supervisão Humana Síncrona: Os sistemas atuais exigem interação humana síncrona (definição de requisitos antes da execução ou intervenção em tempo real). No entanto, a supervisão no mundo real é majoritariamente assíncrona (relatar problemas, ajustar prioridades), onde os desenvolvedores consomem essas diretrizes em pontos de transição naturais sem bloquear o trabalho em andamento.

2. Metodologia: TheBotCompany

Os autores apresentam TheBotCompany, um framework de orquestração open-source projetado para desenvolvimento contínuo e multi-agente. A arquitetura baseia-se em três inovações principais:

A. Ciclo de Vida de Marcos em Três Fases (State Machine)

O desenvolvimento é organizado em torno de "marcos" (unidades discretas de trabalho) que passam por um ciclo repetitivo de três fases, orquestrado por agentes gestores permanentes:

1. Estratégia (Athena): Avalia o estado do projeto, reconcilia novos requisitos com o plano existente e define o próximo marco com objetivos concretos e orçamento de ciclo.
2. Execução (Ares): Monta uma equipe de agentes trabalhadores (funcionários) para implementar o marco. O gestor Ares contrata, atribui tarefas e demite trabalhadores dinamicamente com base nas necessidades do marco.
3. Verificação (Apollo): Avalia independentemente o resultado. Se o trabalho for rejeitado, fornece feedback estruturado e o ciclo retorna à Execução com um orçamento reduzido (metade), forçando correções. Se aprovado, avança para o próximo marco.

B. Equipes Auto-Organizáveis

Diferente de frameworks com papéis fixos, o TheBotCompany utiliza um modelo onde apenas os três gestores são permanentes.

• Agentes Trabalhadores: São dinâmicos. Cada gestor cria, especializa e aposenta trabalhadores conforme a demanda.
• Arquivos de Habilidade (Skill Files): Os trabalhadores são definidos por arquivos de habilidade persistentes (Markdown/YAML) que especificam seu papel, modelo LLM e gerente. Isso permite que a força de trabalho se adapte sem reconfiguração do framework.
• Controle de Informação: Os gestores controlam o que os trabalhadores veem (Modo Completo, Focado ou Cego) para evitar viés ou poluição de contexto.

C. Supervisão Humana Assíncrona

O sistema oferece um painel de monitoramento web (PWA) onde os humanos podem:

• Inspecionar o progresso, logs e relatórios em tempo real.
• Arquivar problemas (issues) que os agentes gestores consomem assincronamente nos ciclos subsequentes.
• Intervir apenas em pontos de transição naturais (ex: redefinir o planejamento se o sistema entrar em um estado degenerado), sem interromper agentes ativos.

D. Infraestrutura Técnica

• Orquestrador: Escrito em JavaScript/Node.js, gerencia o estado persistente (SQLite), transições de fase, limites de tempo e orçamentos.
• Comunicação: Baseada em um rastreador de problemas interno (similar ao GitHub Issues) e arquivos de notas persistentes (note.md) para manter o conhecimento entre invocações de LLM (resolvendo o problema de "cold-start" de contexto).
• Gestão de Orçamento: Limites de gastos de 24 horas com intervalos de sono adaptativos para evitar excessos de custos em APIs comerciais.

3. Contribuições Principais

1. TheBotCompany: Um framework de orquestração open-source que introduz desenvolvimento orientado a marcos persistentes e um modelo de supervisão humana assíncrona.
2. Modelo de Equipe Auto-Organizável: Substitui equipes de papéis fixos por uma composição de força de trabalho adaptativa, onde gestores dinamicamente montam e desmontam equipes de trabalhadores.
3. Avaliação Empírica de Longo Prazo: Uma avaliação em quatro projetos do mundo real operando continuamente por dias, fornecendo lições práticas sobre adaptação de equipe, melhoria de qualidade orientada à verificação e recuperação de falhas.

4. Resultados da Avaliação

Os autores avaliaram o sistema em quatro projetos reais (Simulador de CPU M2, Banco de Dados Relacional, Compilador LaTeX e Interpretador Python) e no benchmark ProjDevBench.

• Eficácia no Desenvolvimento Contínuo (RQ1): O sistema completou 164 marcos e 616 ciclos em 137 horas de tempo de parede, sem intervenção humana além da configuração inicial. Não houve comportamento degenerado (loops sem progresso).
• Comparação com Agentes Únicos (RQ2): No benchmark ProjDevBench (tarefas difíceis de ponta a ponta), o TheBotCompany (usando Claude Sonnet 4.5) superou todas as bases de agentes únicos, incluindo o próprio Claude Code.
  • Ganhou +9.6 pontos na pontuação de execução e +10.7 pontos na pontuação geral em comparação com o mesmo modelo em modo de agente único.
  • A vantagem foi mais pronunciada em problemas complexos que exigem refinamento iterativo, enquanto em problemas com soluções compactas, a sobrecarga multi-agente reduziu a eficiência.
• Comportamento da Fase de Verificação (RQ3): A fase de verificação (Apollo) capturou defeitos substanciais.
  • Em projetos com critérios de aceitação iterativos (ex: similaridade de pixels em um compilador), a taxa de rejeição foi alta (18.6%), mas esses feedbacks foram cruciais para acumular "anti-padrões" e evitar exploração inútil futura.
  • Em projetos com critérios determinísticos, a verificação atuou como confirmação (0% de rejeição).
• Análise de Custos (RQ4):
  • Os agentes trabalhadores consumiram 70,6% do custo total de tokens, indicando que a maior parte do orçamento é alocada para trabalho de engenharia real, não para orquestração.
  • O custo por marco permaneceu estável à medida que os projetos cresciam.
  • O TheBotCompany consumiu 1,65x mais tokens por tentativa de submissão em comparação com agentes únicos, mas isso foi justificado pela maior qualidade e capacidade de resolver problemas complexos.
• Modos de Falha e Recuperação (RQ5): A maioria das falhas foi específica do domínio (ex: regressão de precisão), não de orquestração. Os mecanismos de recuperação (como reinicialização de agentes e redefinição de marcos) foram eficazes, com desperdício de ciclos muito baixo (exceto em casos de otimização iterativa extrema).

5. Significado e Conclusão

O artigo demonstra que a separação estrutural de fases (Planejamento, Execução, Verificação) e a persistência de estado são complementos essenciais à capacidade do modelo para o desenvolvimento de software de longo horizonte.

• Verificação Independente: A fase de verificação adversarial é crucial para projetos com critérios de qualidade contínuos, evitando que defeitos persistam.
• Adaptabilidade: A capacidade de auto-organização permite que o sistema escale sem reconfiguração manual, concentrando custos em tarefas de implementação.
• Viabilidade Prática: O sistema é viável para operação não supervisionada por dias, com supervisão humana assíncrona eficaz.

Em suma, o TheBotCompany prova que sistemas multi-agentes podem ir além de tarefas pontuais para gerenciar ciclos de vida completos de desenvolvimento de software, superando agentes únicos em tarefas complexas que exigem iteração e correção contínua, desde que o custo de coordenação seja justificado pela complexidade do problema.