DeepSeek abre o código do Super-agent: o agente de programação que trabalha em um repositório inteiro

DeepSeek abre o código do Super-agent: o agente de programação que trabalha em um repositório inteiro

A DeepSeek publicou em código aberto um protótipo de agente de programação que muda a forma como uma equipe pode trabalhar com inteligência artificial. Em vez de uma conversa isolada em que uma pessoa pede uma tarefa, espera a resposta e depois pede outra, o Super-agent foi desenhado para ficar ligado a um repositório do GitHub, receber pedidos autorizados, organizar o trabalho em tarefas e devolver resultados no mesmo lugar onde o pedido nasceu, muitas vezes na forma de um pull request.

O código foi publicado no GitHub em 31 de outubro de 2026, no repositório deepseek-ai/dsh-superagent-prototype, sob a licença MIT, que permite inspecionar, modificar e executar o código. A repercussão cresceu nos dias 1 e 2 de novembro de 2026, quando a publicação passou a ser comentada em coberturas de tecnologia e a circular entre desenvolvedores. É importante registrar essa diferença de datas: o repositório foi criado em 31 de outubro, e o que chegou ao radar em 2 de novembro foi a repercussão, não um segundo anúncio.

O próprio repositório faz questão de baixar as expectativas logo na primeira linha. O texto de abertura descreve o projeto como um protótipo de pesquisa, apenas para referência, e não como um produto oficial da DeepSeek. O mesmo aviso diz que o código não está pronto para produção, que pode conter erros e que parte dele foi escrita com a ajuda de agentes de programação. Quem quiser usar precisa revisar e adaptar antes de colocar em qualquer ambiente próprio.

O que é o Super-agent

O Super-agent é um agente de programação proativo para um único repositório do GitHub, empacotado como um bundle para o DeepSeek Harness. O Harness é a estrutura de agentes de código aberto da DeepSeek, lançada em 13 de agosto de 2026, também sob licença MIT. Em termos simples, o Harness é o motor: ele oferece modelo, ferramentas, sessões, sandbox, armazenamento e o ciclo de execução do agente. O Super-agent é o agente já montado em cima desse motor, com decisões que o framework deixa em aberto, como quem pode pedir trabalho, o que conta como uma tarefa concluída e o que aparece para uma pessoa revisar.

O escopo é estreito de propósito. Cada instalação cuida de um repositório, hospedado no github.com. O GitHub Enterprise Server não é suportado na versão publicada. Opcionalmente, o agente também pode escutar o Feishu, o aplicativo de chat corporativo da ByteDance, conhecido fora da China como Lark. A ideia não é um assistente genérico para qualquer pergunta, e sim um sistema que vive dentro do fluxo de trabalho de uma equipe de software.

O princípio que guia o projeto, segundo a própria documentação, é usar o mínimo possível da atenção humana e entregar o máximo possível de valor. Um agente que pode agir por uma equipe inteira também pode desperdiçar a atenção de uma equipe inteira, por isso ele só deve agir quando for chamado ou quando uma regra escrita pela equipe permitir, e só deve falar quando alguém precisar agir ou puder usar um resultado. Essa frase resume a aposta do projeto: autonomia com freio, e não autonomia sem controle.

Como funciona na prática

O fluxo básico é direto. Uma pessoa autorizada pede um trabalho no GitHub ou, quando configurado, no Feishu. O agente abre um item de trabalho, que o projeto chama de Ticket. Esse trabalho é executado em uma sessão própria de agente, em um diretório próprio, separada de outros trabalhos. Quando termina, o agente responde na conversa original, por exemplo com um pull request pronto para revisão. Um painel web mostra o que precisa de decisão humana, para que nada importante fique escondido dentro de uma conversa longa.

Na prática, isso significa que a equipe não precisa abrir uma nova sessão de chat para cada tarefa, nem acompanhar passo a passo tudo o que o agente faz. O pedido entra por um canal que a equipe já usa, o trabalho acontece em paralelo e o resultado volta para revisão. O modelo é diferente do assistente de terminal tradicional, em que uma pessoa conversa, espera, corrige e recomeça, sempre em uma única sessão.

Router e Worker

A arquitetura central do Super-agent tem duas camadas, chamadas de Router e Worker. O Router é a camada persistente, sempre ligada, que recebe eventos, conversa com as pessoas, mantém o contexto compartilhado e decide o que vira trabalho. O Worker é a camada de execução: cada tarefa ganha uma sessão isolada, com seu próprio contexto, suas próprias ferramentas e seu próprio diretório, e pode rodar em paralelo com outras tarefas.

Essa separação resolve um problema comum dos agentes de uma única sessão. Em um agente tradicional, uma tarefa longa, uma ferramenta travada ou uma conversa cheia de mensagens misturadas pode atrasar tudo o resto. No desenho do Super-agent, o Router continua ouvindo novos pedidos mesmo enquanto vários Workers trabalham, e um Worker travado não precisa paralisar o sistema inteiro. O Router usa um conjunto de ferramentas deliberadamente pequeno e não executa a tarefa de programação em si. Os Workers usam o conjunto completo de ferramentas para programar, testar e abrir o pull request.

O projeto também prevê um painel de gestão que mostra o estado de cada item, como em andamento, aguardando, bloqueado, com falha ou pronto, além de regras de recuperação, repetição de tentativas e fusão de resultados. A documentação descreve ainda um cuidado com mandatos estreitos: aceitar um Ticket não amplia a autoridade do agente depois, e o trabalho proativo só começa em modo de observação, a menos que uma regra escrita pela equipe autorize a ação.

O que o artigo de design propõe

Junto com o código, a equipe do DeepSeek Harness publicou o artigo Exploring Super-agent Design: Towards a More Autonomous Agent System, em 1 de novembro de 2026. O artigo define o super-agente por quatro características: contínuo, produtivo, proativo e persistente. Ou seja, um agente que não começa do zero a cada conversa, que consegue produzir trabalho útil, que age quando faz sentido e que mantém o contexto ao longo do tempo.

O artigo organiza a proposta em cinco módulos: a arquitetura de dois níveis, Router e Worker; gatilhos por evento, em vez de um ciclo autônomo sem limites; interação por vários canais; separação entre computação, estado e ambiente; e um Watchdog externo, uma sessão de supervisão que avaliaria se cada Worker está progredindo ou se perdeu o caminho. Esses módulos descrevem a direção completa do projeto, e não apenas o que já está no código publicado.

O que já está no código e o que ainda não está

Aqui está o ponto que mais exige leitura cuidadosa. O README do repositório avisa que o código foi adaptado para publicação, que não é idêntico à versão interna da DeepSeek e que parte do que o artigo descreve é direção futura, não implementação. Em outras palavras, o artigo mostra para onde o projeto quer ir, e o repositório mostra uma parte do caminho já percorrida.

Segundo o artigo, a DeepSeek já usa internamente uma versão do Super-agent para reproduzir e corrigir erros, responder a revisões de código e ajudar a desenvolver o próprio DeepSeek Harness. A versão pública é mais estreita: um agente para um repositório, com escuta do GitHub e, opcionalmente, do Feishu, e com o fluxo de Ticket, sessão isolada e resposta na conversa original. O Watchdog externo, por exemplo, aparece no artigo como parte do desenho, mas o README alerta que nem tudo o que o artigo discute está implementado no protótipo. Por isso, quem for estudar o projeto deve separar com clareza o que é desenho, o que é código publicado e o que é uso interno da DeepSeek.

Os números divulgados também precisam dessa mesma leitura. Em uma simulação própria, com mensagens sintéticas e ferramentas simuladas, a DeepSeek relatou que o desenho Router e Worker concluiu tarefas com mediana de 12,4 minutos e percentil 95 de 15,7 minutos, contra 29,5 minutos no percentil 95 de um agente de sessão única. A simulação usou cerca de 300 mensagens, das quais cerca de 20 eram pedidos reais de trabalho, com cinco repetições por esquema. A própria cobertura do lançamento ressalta o limite central desse resultado: a qualidade do código real não foi medida. É um sinal de que a arquitetura pode ser mais rápida sob carga, e não uma prova de que o código gerado seja melhor.

Um relato sobre um teste de estresse do Router aponta na mesma direção: ao elevar a taxa de chegada de gatilhos de um por minuto para cerca de 40 por minuto, o tamanho médio do lote subiu de 1,0 para 2,8, enquanto o tempo de um único pedido cresceu apenas de 2,5 segundos para 3,9 segundos. É um dado interessante sobre a camada de triagem, mas também é um teste controlado, e não uma medida de uso real em produção.

Por que isso importa

O lançamento importa por três motivos. O primeiro é técnico: ele desloca o agente de programação da conversa isolada para um sistema persistente, orientado por eventos, que vive dentro do repositório e do chat da equipe. Se essa arquitetura funcionar bem, o trabalho de uma equipe pode ficar menos dependente de uma pessoa ficar o tempo todo pedindo, esperando e corrigindo.

O segundo motivo é de mercado. Coberturas do lançamento enquadraram o Super-agent como um desafio direto ao Claude Code, da Anthropic, uma das ferramentas de programação com IA mais usadas por desenvolvedores. A DeepSeek não vende o protótipo como produto, mas publica a arquitetura em código aberto, o que permite que outros times estudem, adaptem e construam em cima dela, sem depender de um único fornecedor.

O terceiro motivo é de modelo de negócio. O Harness e o Super-agent são distribuídos sob licença MIT e podem ser executados localmente, com o modelo configurado pelo próprio usuário. Isso separa a ferramenta da API de modelos da DeepSeek e reforça uma tendência que já aparece em outros lançamentos: o valor migra, em parte, do modelo em si para a estrutura que organiza o trabalho do agente, as permissões, o contexto e a revisão humana.

Para quem serve

O público imediato do protótipo não é o usuário comum, e sim desenvolvedores e equipes de software que já trabalham com GitHub e querem estudar ou testar uma arquitetura de agente persistente. Também serve a pesquisadores e a quem constrói ferramentas de programação com IA, porque o código mostra, na prática, como separar triagem e execução, como isolar sessões e como expor apenas o que precisa de decisão humana.

Equipes pequenas podem se beneficiar da ideia de um agente que acompanha o repositório e devolve pull requests prontos para revisão, mas só depois de entender os requisitos e os riscos. Empresas que precisam de conformidade, auditoria e controle rígido de acesso devem tratar o protótipo como material de estudo, e não como uma ferramenta pronta para colocar em um repositório de produção.

Como testar com segurança

A instalação do protótipo não é um simples download de aplicativo. O caminho previsto é pedir a um agente de código que leia o arquivo SETUP.md do repositório e conduza a configuração, uma pergunta por vez. Os requisitos relatados incluem um perfil dedicado do DeepSeek Harness, uma conta do GitHub dedicada ao agente, um provedor de modelo configurado, Node.js 22.19 ou superior, ou Node.js 24, além de pnpm, git, tmux, Python 3.8 e GitHub CLI 2.48 ou superior. O projeto depende de uma versão alpha do Harness, o que já indica que o ambiente ainda está em prévia.

A segurança é o ponto mais sensível. As sessões do agente executam comandos com acesso completo do usuário do sistema operacional, e a própria DeepSeek recomenda isolamento, como o uso de uma conta separada do sistema operacional. O Harness é descrito como software experimental em prévia, sem garantia de isolamento por parte de seus controles de sandbox e aprovação. Na prática, isso significa testar em uma máquina separada, em um repositório de testes, sem credenciais importantes e sem acesso a dados sensíveis, e nunca ligar o modo automático em um repositório real sem antes entender as regras de autorização.

O protótipo trabalha com níveis de permissão, incluindo desligado, observação e automático. No modo de observação, o agente registra o que faria, sem executar a ação. Esse é o modo recomendado para começar, porque permite ver o comportamento do sistema antes de dar a ele permissão para agir. Qualquer trabalho proativo que ninguém pediu ainda precisa de uma regra escrita pela equipe, e não deve ser ativado por padrão.

Limitações e riscos

A lista de limitações é longa, e a própria DeepSeek a reconhece em parte. O protótipo atende um único repositório por instalação, não suporta GitHub Enterprise Server, depende de uma versão alpha do Harness e pode conter erros, já que parte da engenharia foi feita por agentes de código. O código publicado não é idêntico à versão interna, o que significa que os resultados internos da DeepSeek não podem ser reproduzidos automaticamente a partir do repositório público.

Há também desafios abertos apontados pela equipe. Um deles é escalar a arquitetura de dois níveis quando um único Router não der mais conta do volume. Outro é colaborar com um agente que não vive mais dentro de uma janela de chat, e sim como um sistema em segundo plano. Um terceiro é desenhar os limites de contexto à medida que a organização cresce, para que o agente não misture informações de projetos diferentes. O quarto é a segurança de agentes na nuvem que alcançam as máquinas dos usuários, um risco que cresce junto com a autonomia.

Além disso, a popularidade inicial não deve ser lida como prova de qualidade. Na consulta feita para esta notícia, em 2 de novembro de 2026, a página do GitHub mostrava 11.507 estrelas e 1.187 forks, números que mudam o tempo todo e que refletem interesse, e não validação independente. Relatos do primeiro dia citaram cerca de 4 mil estrelas em poucas horas, o que confirma o interesse rápido, mas não substitui testes próprios.

O que ainda não se sabe

Várias perguntas seguem sem resposta. Não se sabe quando, ou se, o Super-agent vai virar um produto oficial da DeepSeek, nem quais partes do artigo de design serão de fato implementadas no código público. Não há um benchmark independente de qualidade de código, nem uma avaliação pública de segurança do Harness em versão final. Também não está claro como o projeto vai lidar, em escala, com repositórios grandes, equipes com muitos repositórios e regras de autorização mais complexas.

Outra incógnita é o modelo de evolução do ecossistema. Como o código é aberto e o Harness é um framework, outros desenvolvedores podem criar suas próprias variações, o que é bom para inovação, mas também fragmenta o projeto. O que vai prevalecer, a versão da DeepSeek, uma variação da comunidade ou uma integração em outra ferramenta, ainda é uma questão em aberto.

Para o leitor que acompanha o tema de agentes de programação, o recado mais honesto é este: o Super-agent não é um produto pronto para substituir um programador, e nem pretende ser, nesta versão. Ele é um desenho ambicioso, publicado em código aberto, com uma arquitetura que merece atenção, um protótipo que merece teste cuidadoso e uma lista de ressalvas que merece ser levada a sério. Se a arquitetura de Router e Worker se mostrar robusta fora da simulação, ela pode influenciar como as próximas ferramentas de programação com IA serão construídas. Se não se mostrar, ainda assim terá deixado um mapa público de uma direção que muitos times estão tentando seguir.

Glossário

Agente de programação: programa de inteligência artificial que ajuda a escrever, revisar, corrigir e organizar código, em vez de apenas responder perguntas.

Bundle: pacote de plugin do DeepSeek Harness, que instala um agente já montado em cima do framework.

Feishu: aplicativo de chat corporativo da ByteDance, conhecido fora da China como Lark.

GitHub: plataforma para hospedar e colaborar em código, onde equipes controlam versões, revisam mudanças e gerenciam projetos.

Harness: estrutura de agentes de código aberto da DeepSeek, que oferece modelo, ferramentas, sessões, sandbox e ciclo de execução para agentes.

Licença MIT: licença de código aberto permissiva, que permite usar, copiar, modificar e distribuir o código, com poucas restrições.

Percentil 95: medida estatística que indica o valor abaixo do qual estão 95 por cento das observações, usada aqui para descrever o tempo das tarefas mais lentas.

Pull request: pedido de revisão e incorporação de mudanças de código em um repositório, feito para que outras pessoas analisem antes de aceitar.

Repositório: espaço onde ficam o código, o histórico de mudanças e os arquivos de um projeto.

Router: camada persistente do Super-agent que recebe eventos, conversa com as pessoas, mantém o contexto e decide o que vira trabalho.

Sandbox: ambiente isolado usado para executar código ou comandos com menos risco para o resto do sistema.

Ticket: item de trabalho aberto pelo Super-agent a partir de um pedido autorizado, executado em sessão e diretório próprios.

Watchdog: sessão de supervisão descrita no artigo de design, que avaliaria se cada Worker está progredindo ou se perdeu o caminho.

Worker: sessão isolada de execução do Super-agent, que realiza uma tarefa específica, como programar, testar e abrir um pull request.