Um novo hábito se espalhou pelas ferramentas para desenvolvedores: deixar uma tarefa em algum lugar — uma Issue, uma menção em um chat, uma caixa de prompt —, fechar o laptop e voltar para encontrar uma branch ou um pull request criado por um agente enquanto você estava fora. GitHub, Cursor, OpenAI, Anthropic, Cognition e xAI agora oferecem alguma versão disso, com nomes como agente na nuvem, agente em segundo plano, sessão na nuvem ou engenheiro de software autônomo. Este artigo explica a categoria: o que esses produtos realmente fazem, como funciona o ciclo, a que você renuncia e onde o protótipo de código aberto Super-agent, da DeepSeek, se encaixa.
O que é considerado um agente de programação na nuvem
O rótulo é abrangente, então vale a pena identificar os três elementos compartilhados por todos os produtos dessa categoria:
- Um gatilho que não exige um editor aberto. O trabalho chega como uma atribuição de Issue, uma @menção no Slack ou no Feishu, um prompt em um aplicativo web, uma chamada de API ou uma transferência pela CLI.
- Um ambiente fora da sua máquina. O agente clona o repositório, instala o que precisa e trabalha em um sandbox ou espaço de trabalho gerenciado pelo fornecedor ou pela sua organização.
- Um resultado que pode ser revisado. O processo termina com uma branch, um diff, um PR em rascunho ou um comentário — algo que uma pessoa possa revisar e usar.
Isso diferencia a categoria de duas alternativas próximas. Um agente de IDE local é executado no seu laptop enquanto você acompanha; um assistente de chat responde a perguntas sem tocar no repositório. Um agente de programação na nuvem fica entre os dois: tem ferramentas reais e um checkout real, mas a ideia é que a pessoa possa se ausentar.
A palavra bot descreve o formato da mesma ideia, nativo de chat. Em vez de atribuir uma Issue, você menciona o agente no Slack, no Teams ou no Feishu. O gatilho muda; o ambiente remoto, não. A saída pode ser um PR, um diff ou um conjunto de arquivos concluídos.
O panorama dos produtos
Seis produtos, descritos conforme seus fornecedores os apresentam:
| Produto | É iniciado por | É executado em | Retorna |
|---|---|---|---|
| Agente na nuvem do GitHub Copilot | Issue, @, painel Agents | Sandbox na nuvem ou Actions | Branch ou PR |
| Cursor Cloud Agents | Desktop, web, Slack, Linear | VM isolada na nuvem | PR |
| OpenAI Codex Cloud | ChatGPT na web, desktop, dispositivos móveis | Espaço de trabalho na nuvem | Alterações ou PR |
| Sessões na nuvem do Claude Code | Navegador, dispositivos móveis, desktop, terminal | VM gerenciada pela Anthropic ou ambiente auto-hospedado | Branch ou PR |
| Devin | Slack, Teams, web, CLI, API | Espaço de trabalho com terminal, editor e navegador | PR em rascunho |
| Grok Bot | Chat no desktop/dispositivo móvel, @bot no X | Máquina na nuvem (hospedada pela Cursor) | Arquivos ou rascunhos |
Grok Bot é a opção mais abrangente: a xAI o descreve como um colega de equipe de IA persistente, iniciado pelo chat no desktop ou em dispositivos móveis, ou pela menção a @bot no X quando as contas estão vinculadas. Ele é executado em uma máquina na nuvem vinculada à conta, hospedada pela Cursor, com acesso ao navegador, armazenamento e linha de comando. A documentação fala de arquivos concluídos e rascunhos, não de um fluxo de trabalho com repositórios; a criação de branches e PRs não está documentada. Isso o coloca no extremo dos bots do espectro.
Quatro diferenças são mais importantes do que a tabela:
Onde fica o gatilho. O agente na nuvem do GitHub Copilot e o OpenAI Codex Cloud foram concebidos para tarefas que já estão no GitHub ou no aplicativo ChatGPT. O Cursor Cloud Agents e o Devin privilegiam o chat: uma conversa no Slack ou no Teams é o ponto de entrada. As sessões na nuvem do Claude Code aceitam gatilhos pelo navegador, pelo celular, pelo aplicativo para desktop ou por claude --cloud no terminal, e também podem ser executadas em um agendamento.
Quanto o fornecedor revela. O Claude Code documenta o isolamento em detalhes: em ambientes hospedados pela Anthropic, cada sessão é executada em uma VM isolada, o acesso à rede é limitado por padrão e as credenciais do git ficam fora do sandbox, enquanto um proxy autentica em nome da sessão. As organizações podem direcionar as sessões para um ambiente auto-hospedado, caso em que são responsáveis pelo isolamento. As sessões na nuvem compartilham os limites de requisições do seu plano, sem cobrança separada pela VM; exigem uma conta conectada ao claude.ai e não estão disponíveis quando o Claude Code está configurado para Amazon Bedrock, Agent Platform do Google Cloud ou outro provedor terceirizado. Os outros fornecedores divulgam menos detalhes internos; “sandbox” ou “VM” costuma ser o fim da descrição pública.
A que o agente tem permissão para acessar. Alguns produtos se limitam a um único repositório; outros anunciam trabalho em toda a organização ou em vários repositórios. Essa é a primeira coisa a verificar em relação à sua própria configuração, porque um agente capaz com o escopo de repositório errado é inútil ou perigoso.
Para que tipo de trabalho serve. A maioria dos produtos desta lista se dedica à programação em repositórios específicos. Grok Bot é um colega de equipe geral na nuvem: sua documentação fala de arquivos e rascunhos, não de um fluxo de trabalho com repositórios. Entenda “agente na nuvem” como um espectro, não como um único formato de produto.
Como o ciclo funciona na prática
Deixando o marketing de lado, o ciclo é parecido em todos os produtos:
- Entrada. Chega um gatilho. O produto decide se é uma tarefa de verdade, às vezes faz uma pergunta para esclarecer e coloca uma sessão na fila.
- Ambiente. O agente clona o repositório na branch adequada, executa um script de configuração ou uma imagem e instala o conjunto de ferramentas. O acesso à rede e as credenciais são configurados aqui, não depois.
- Execução. O agente lê o código, edita arquivos, executa testes e comandos e, ocasionalmente, abre um navegador. Tarefas longas continuam mesmo depois que o laptop entra em suspensão.
- Saída. O agente envia uma branch e abre um PR, ou deixa um diff e um resumo por escrito. Alguns produtos retornam PRs em rascunho porque se espera que o agente pare antes da mesclagem.
- Revisão. Uma pessoa lê o diff, comenta e então mescla, pede alterações ou retoma o trabalho em uma sessão local. Alguns produtos também podem acompanhar o PR e enviar correções quando o CI falha.
As diferenças que causam problemas estão nas etapas 2 e 5. Um script de configuração demorado, um repositório que o agente não consegue clonar, uma política de rede que bloqueia um registro de pacotes ou uma credencial inacessível ao sandbox podem interromper uma tarefa que parecia simples. E “saída que pode ser revisada” ainda significa que uma pessoa precisa revisá-la: nenhum desses produtos elimina a etapa de revisão; eles apenas transferem a digitação.
Por que essa onda está acontecendo agora
Três condições precisavam se alinhar. Os modelos se tornaram confiáveis o bastante para executar longos ciclos de uso de ferramentas sem supervisão constante. Os sandboxes e os scripts de configuração ficaram baratos o suficiente para que cada tarefa tivesse seu próprio ambiente. E o pull request se tornou a interface padrão entre um agente e quem revisa, o que significa que as equipes não precisaram inventar um novo processo de revisão.
Há também um argumento relacionado à atenção. O ensaio de design complementar da DeepSeek afirma isso explicitamente: uma única tarefa é limitada pelo modelo, mas a produtividade de uma pessoa em várias tarefas é limitada pela atenção. Um agente na nuvem transfere para longe da pessoa o gerenciamento de sessões, a alternância de contexto e a espera. Essa afirmação vem do ensaio da DeepSeek, não de um estudo independente, mas descreve por que essa categoria parece útil.
A que você renuncia
Todo produto hospedado troca controle por conveniência:
- Limite de confiança. Seu código e, às vezes, suas credenciais saem da sua máquina. Os fornecedores publicam níveis diferentes de detalhes sobre isolamento, retenção e acesso à rede; consulte cada produto individualmente, em vez de presumir que a categoria é uniforme.
- Isolamento. Uma VM gerenciada é projetada para conter o agente, mas ainda é o ambiente do fornecedor. “Sandbox” pode significar qualquer coisa, de uma VM reforçada a um contêiner com amplo acesso à rede.
- Personalização. Agentes hospedados oferecem configurações, não código-fonte. Se seu fluxo de trabalho precisa de outro gatilho, outra regra de revisão ou outro modelo, você fica limitado ao que o produto oferece.
- Modelo de custo. A maioria desses produtos cobra por assinatura ou plano com limites de uso; o tempo do agente não é um item de custo que você controla diretamente. Faça o orçamento com base no plano, não nos tokens.
- Escopo e dependência do fornecedor. O suporte a vários repositórios, as integrações de chat e os controles empresariais variam conforme o fornecedor, e migrar um fluxo de trabalho de um produto para outro não é gratuito.
A opção auto-hospedada: Super-agent, da DeepSeek
O lançamento da DeepSeek é interessante porque pergunta como seria o mesmo ciclo se o plano de controle permanecesse com você. O repositório é um plugin TypeScript sob licença MIT para DeepSeek Harness (DSH), versão 0.1.0, publicado como protótipo de pesquisa. O README deixa claro que foi adaptado para publicação, não é idêntico à versão interna da DeepSeek e não implementa todas as ideias do ensaio de design.
Sua estrutura é composta por uma sessão Router de longa duração e uma sessão Worker para cada chamado. Os eventos percorrem Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor. Uma equipe autoriza o trabalho por meio de uma política; @menções explícitas de pessoas autorizadas são aceitas, enquanto o trabalho proativo começa no modo observe, que registra o que o agente teria feito sem abrir chamados. Cada Ticket recebe sua própria sessão e pasta; um comando de preparação pode criar uma árvore de trabalho do git para cada ticket.
O modelo operacional é o oposto de um sandbox de fornecedor. Ele monitora um repositório no github.com (sem GitHub Enterprise Server) e, opcionalmente, o Feishu. As predefinições do Router e do Worker são executadas com danger-full-access como o usuário do sistema operacional que opera o agente; os wrappers de conta escolhem as credenciais do agente, mas não isolam o processo. O guia de implantação recomenda uma conta dedicada do sistema operacional que contenha somente as credenciais do agente. O estado fica em SQLite, no stateDir configurado. A filosofia é expressa como um objetivo: exigir o mínimo possível de atenção humana e oferecer o máximo de valor possível.
O ensaio apresenta números de agendamento de uma carga de trabalho sintética — cerca de 300 mensagens e 20 solicitações de trabalho, ferramentas simuladas, cinco execuções —, com p50/p95 de aproximadamente 12.4 / 15.7 minutos, contra cerca de 29.5 minutos p95 para uma linha de base de sessão única que não fazia chamadas a subagentes. Essas são medições do próprio ensaio, com ferramentas simuladas, não um benchmark independente de qualidade de programação.
O que o protótipo demonstra é mais limitado e mais útil do que o lançamento de um produto: o agente de programação acionado por eventos e revisado no fim não está preso à nuvem de um fornecedor. Você pode controlar o orquestrador, o estado e a escolha do modelo. O que ele também demonstra é o custo desse controle: você executa o processo, protege a conta e aceita que o protótipo não tenha um ambiente isolado por padrão.
Quem deve escolher cada opção
Continue com um agente de nuvem hospedado se você busca zero operações, um ambiente isolado gerenciado pelo fornecedor, recursos para vários repositórios ou organizações e um acionador no GitHub, Slack, Teams ou em um app web. O fornecedor cuida do isolamento e do tempo de atividade.
Considere o protótipo auto-hospedado se o código não puder sair da sua infraestrutura, você precisar modificar a orquestração ou quiser escolher o modelo para cada função. Reserve orçamento para uma máquina dedicada ou uma conta de sistema operacional e trate o código como software de pesquisa.
Uma combinação prática: agentes hospedados para o trabalho rotineiro nos repositórios e um agente auto-hospedado apenas para os repositórios em que a fronteira dos dados é importante. A etapa de revisão é igual nos dois casos.
Uma observação sobre os modelos
O protótipo não fixa um modelo no código. Ele usa o modelo padrão do perfil do Harness, a menos que Eval ou Execution o substituam, para que uma equipe possa usar um modelo mais leve no Router e outro mais potente nos Workers. O AIHubMix conecta o DeepSeek Harness por meio de um endpoint compatível com OpenAI em https://aihubmix.com/v1; o exemplo no guia do DeepSeek Harness usa o provedor aihubmix e o modelo auto. O guia aborda a conexão básica com o DSH, não o plugin Super-agent, e os produtos hospedados acima gerenciam a própria seleção de modelos.
Perguntas frequentes
O que é um agente de programação na nuvem?
Um software que recebe uma tarefa de programação por meio de um Issue, uma menção em um chat ou uma chamada de API, a executa em um ambiente fora da sua máquina e retorna uma branch, um diff ou um pull request para revisão.
É a mesma coisa que um agente de programação local?
Não. Um agente local é executado no seu terminal ou IDE enquanto você acompanha. Um agente de nuvem continua trabalhando depois que você fecha o laptop e foi feito para ser revisado mais tarde.
Ainda é preciso revisar o código?
Sim. Todos os produtos aqui terminam com um diff ou PR para uma pessoa revisar. O agente assume a digitação, não a aprovação.
Onde o seu código é executado?
No ambiente do fornecedor. Os detalhes variam: o Copilot descreve um ambiente isolado na nuvem ou um ambiente do Actions; o Cursor, VMs isoladas; o Codex, um espaço de trabalho na nuvem; o Claude Code, uma VM isolada gerenciada pela Anthropic ou um ambiente auto-hospedado da organização; e o Devin, um espaço de trabalho com terminal, editor e navegador. Leia a documentação de segurança de cada fornecedor antes de confiar a ele código privado.
O que é um bot de programação?
A versão nativa de chat da mesma ideia: você menciona o agente no Slack, Teams ou Feishu em vez de atribuir um Issue. Ele ainda trabalha em um ambiente remoto; o resultado pode ser um PR ou diff ou, no caso de um colega de equipe de uso geral como o Grok Bot, arquivos finalizados e rascunhos.
O que o Super-agent da DeepSeek acrescenta?
Uma implementação auto-hospedada e licenciada sob MIT do mesmo fluxo, com um design Router–Worker, um modelo de políticas e tickets e suporte opcional ao Feishu. É um protótipo de pesquisa, não um produto hospedado.
Está pronto para produção?
Não. O README o descreve como código de pesquisa, as predefinições são executadas com danger-full-access e não há um ambiente isolado por padrão. Se decidir testá-lo, use uma conta dedicada do sistema operacional e uma conta dedicada do agente no GitHub.
Fontes
- deepseek-ai/dsh-superagent-prototype — README, o ensaio de design citado e docs/000–008
- Conecte o DeepSeek Harness ao AIHubMix — AIHubMix
- Agente de nuvem do GitHub Copilot — GitHub Docs
- Agentes de nuvem do Cursor — Cursor Docs
- Codex Cloud — ChatGPT Learn / OpenAI
- Claude Code na nuvem — Anthropic
- Documentação do Devin — Cognition
- Documentação do Grok Bot — xAI



