OpenCode / OpenHands (anteriormente OpenDevin)

1. Visão geral do conceito e problema sistêmico

O surgimento de "AI Software Engineers" autônomos comerciais (como o Devin) demonstrou um futuro para o desenvolvimento onde modelos fecham o backlog de tarefas por conta própria. No entanto, serviços proprietários trazem riscos significativos: alto custo (assinaturas a partir de $500/mês), opacidade dos algoritmos internos, impossibilidade total de ajustar o comportamento ao stack interno específico da empresa e risco de vazamento de segredos comerciais para as nuvens fechadas do fornecedor.

OpenHands (anteriormente OpenDevin) foi criado como uma alternativa livre, modular e segura. Trata-se de um framework agêntico completo, capaz de clonar repositórios autonomamente, analisar documentação, reproduzir bugs através da escrita de testes, modificar a base de código e enviar Pull Requests. A segurança é alcançada por meio de isolamento rigoroso: cada sessão do agente roda em seu próprio ambiente Docker efêmero (Sandboxing).

2. Taxonomia arquitetural e modelo mental

O modelo arquitetural do OpenHands baseia-se em um Event Stream e execução isolada:

┌─────────────────────────────────────────────────────────────┐
│                   ARQUITETURA OPENHANDS                     │
├─────────────────────────────────────────────────────────────┤
│ 1. Núcleo EventStream (EventController & AgentController)   │
│    Barramento central de comunicação de eventos Action ➔ Observation │
├─────────────────────────────────────────────────────────────┤
│ 2. Camada de Raciocínio do Agente (ReAct / CodeAct / Planner) │
│    Suporte para Claude 3.7 Sonnet, DeepSeek R1, OpenAI o1/o3 │
├─────────────────────────────────────────────────────────────┤
│ 3. Runtime Isolado em Sandbox (Docker / MicroVM / gVisor)   │
│    • Execução: Shell Bash com rastreamento de processos em segundo plano │
│    • Sistema de Arquivos: Editores baseados em AST e montagem de workspace │
│    • Navegador Headless: Chromium para testes de UI e documentação │
│    • Jupyter / IPython: REPL interativo para análise de dados │
├─────────────────────────────────────────────────────────────┤
│ 4. Integrações Git & CI/CD: GitHub App, Automação de PR     │
└─────────────────────────────────────────────────────────────┘

1. Event Stream Architecture:
   • Todas as comunicações no sistema são tipificadas como uma cadeia de "Action ➔ Observation" (Action ➔ Observation).
   • Qualquer passo do agente (execução de comando bash, modificação de arquivo, abertura de URL no navegador) é registrado como uma ação, enquanto a resposta do sistema (stdout, erro, screenshot) é registrada como uma observação.
2. Agent Framework:
   • Suporta a paradigma CodeAct — uma abordagem na qual o agente gera código Python ou Bash executável diretamente, em vez de estruturas JSON complexas, o que aumenta substancialmente a precisão em operações multi-etapas complexas.
3. Docker Sandboxing:
   • Garante o isolamento físico do código. O repositório do usuário é montado como um Volume, e todos os binários do sistema, dependências e servidores são iniciados dentro do container.

3. Pipeline técnico e mecânica interna

O ciclo de vida da resolução de uma tarefa de engenharia no OpenHands:

1. Inicialização e provisionamento do ambiente: A plataforma recebe a tarefa (por exemplo, um link para uma GitHub Issue). O OpenHands cria um novo container Docker com o ambiente do projeto pré-configurado (Node.js, Python, Rust) e clona a branch alvo do repositório.
2. Investigação e reprodução do defeito (Repro Test Phase):
   • O agente realiza busca semântica de arquivos utilizando ripgrep.
   • Antes de aplicar correções, o agente cria um arquivo de teste separado (Reproduction Script) que falha no bug existente.
3. CodeAct Loop:
   • O agente aplica mudanças à lógica de negócio.
   • Executa os testes no terminal do container.
   • Recebe o resultado: se o teste ainda falhar, analisa a stack trace e formula uma nova ação.
4. Inspeção via Browser (Optional UI Inspection): Se a tarefa envolver interface web, o agente sobe um servidor dev local, abre a página via Chromium headless e verifica a renderização visual.
5. Geração de PR e limpeza de recursos: Após passar em todos os testes, o agente faz um git commit, envia a nova branch para o GitHub, abre um Pull Request com descrição detalhada do trabalho realizado e para o container.

4. Cenários de engenharia prática em produção

01. Worker noturno automatizado de backlog (Automated Bug Triaging)

Integração do OpenHands ao repositório via GitHub Actions / Webhooks:

• Ao atribuir a label needs-ai-fix a um ticket, a plataforma provisiona um container e designa ao agente a resolução da tarefa.
• Até a manhã seguinte, a equipe recebe 5 Pull Requests prontos com testes passando, aguardando apenas revisão humana final.

02. Teste totalmente seguro de código externo não confiável

Auditoria de segurança de bibliotecas open-source de terceiros ou scripts suspeitos:

• O agente investiga o repositório, executa analisadores estáticos e testes de carga.
• Graças ao sandbox Docker, tentativas do código de terceiros de conectar-se ao host ou baixar malware são completamente bloqueadas.

03. Atualização em lote de microsserviços da empresa

Necessidade de atualizar configurações de Dockerfiles ou Helm charts em 40 microsserviços:

• O OpenHands sobe sequencialmente um ambiente isolado para cada microsserviço, aplica as mudanças, verifica o sucesso do build local do container e publica um PR no repositório correspondente.

5. Armadilhas, erros comuns e segurança

• Perigo de montar o socket do Docker do host: Ao implantar o OpenHands, é extremamente perigoso expor o socket /var/run/docker.sock para dentro do container sem proteções adicionais (Docker-out-of-Docker). Isso concede acesso root ao agente na máquina host e anula o sandbox.
• Requisitos de recursos computacionais: Executar múltiplos agentes em paralelo no Docker exige grande volume de memória RAM (de 16–32 GB) e um processador potente; caso contrário, o sistema pode sofrer crash devido a OOM (Out Of Memory).
• Consumo infinito de tokens em falhas de ambiente: Se o compilador do sistema estiver ausente no container ou a rede estiver quebrada, o agente pode gastar centenas de milhares de tokens em tentativas inúteis de instalar pacotes faltantes. Configure sempre timeouts de sessão.
• Containers "órfãos" deixados para trás: Em caso de parada abrupta do processo principal da plataforma, containers temporários e volumes criados podem permanecer no sistema, ocupando progressivamente o espaço em disco do servidor.