DeepSeek Super-Agent: o que é, como funciona e o que ainda falta23 min read

Abra três agentes de codificação de uma vez e você poderá sentir o problema. Um está aguardando uma decisão, outro terminou há vinte minutos e você já esqueceu qual deles tem a correção de autenticação. A equipe Harness do DeepSeek colocou um número nisso: em sua experiência, uma pessoa pode acompanhar apenas de três a cinco sessões de agente ativo por vez. Passado esse ponto, o modelo não é mais o gargalo. Você é.

Em 31 de outubro de 2026, a equipe publicou um artigo de design para o que chama de Superagente e abriu o código-fonte de um protótipo chamado dsh-superagent. É um agente de codificação proativo para um repositório GitHub. Uma sessão de roteador de longa duração conversa com as pessoas e distribui trabalho, e cada solicitação aceita recebe sua própria sessão de trabalho que termina em uma solicitação pull ou em uma pergunta. O repositório ultrapassou 12.000 estrelas em cerca de dois dias. Seu README é claro que este é um código de pesquisa e não um produto DeepSeek oficial.

Este guia é para engenheiros e líderes de equipe que desejam saber o que o protótipo faz, como funciona o design do roteador e do trabalhador, o que os números de benchmark provam ou não e o que verificar antes de apontá-lo para um repositório real.

Uma nota antes dos detalhes. A resposta de um trabalhador para “consertar esse bug” é uma solicitação pull, e GitHub é um ótimo lugar para isso. O resto do que os agentes produzem em torno do código é mais difícil de localizar: a descrição da causa raiz, o resumo do teste, a tabela de comparação solicitada por um revisor.AgentGrid.ioé um espaço de trabalho compartilhado onde pessoas e agentes de IA criam, editam e compartilham documentos, aplicativos e arquivos, com uma versão ao vivo, atribuição e histórico. Voltamos para onde cabe perto do fim.

O que é DeepSeek Super-Agent?

Duas coisas apareceram juntas. O primeiro é um longo artigo de design, “Explorando o design de superagentes: rumo a um sistema de agentes mais autônomo”. A equipe do Harness escreveu-o em chinês e publicou uma versão traduzida automaticamente em inglês no X em 1º de novembro. Ele foi visto mais de 2,2 milhões de vezes. O segundo é o código:deepseek-ai/dsh-superagent-protótipo, lançado sob a licença do MIT.

Explorando o design de superagentes: rumo a um sistema de agentes mais autônomo

https://t.co/gwwIHtyCRQ

– Arnês DeepSeek (@DeepSeekHarness)1º de novembro de 2026

Não é um modelo novo. dsh-superagent é um pacote paraArnês DeepSeek, o equipamento de agente de código aberto do DeepSeek, que a empresa descreve como uma versão prévia pública em todo o mundo. O pacote monitora um repositório GitHub e, se você ativá-lo, conversa com Feishu. Quando alguém em uma lista de permissões solicita trabalho ao agente, ele abre um item de trabalho, executa-o em sua própria sessão e diretório e responde na conversa original. Um painel web mostra apenas o que uma pessoa precisa.

O nome é mais fácil do que parece. Cui Tianyi, do departamento de produto do DeepSeek e um dos revisores finais do artigo, explicou em uma postagem do Zhihu que “super” significa sobrescrito versus subscrito. Um Superagente adiciona uma camada acima do agente que faz o trabalho, o oposto de um subagente, que adiciona uma abaixo dele. Não é uma reivindicação de inteligência superior.

O README abre com um aviso que vale a pena ler na íntegra: “Protótipo de pesquisa apenas para referência, não um produto DeepSeek oficial.” Acrescenta que grande parte da engenharia foi feita por agentes de codificação, que o código pode conter bugs e que alguns designs no artigo são orientações para trabalhos futuros e não foram implementados.

Outra queda de DeepSeek: dsh-superagent

Uma estrutura de agente que funciona por meio de problemas GitHub e PRs de um repositório com muitos agentes em paralelo, projetada para receber o mínimo de atenção humana possível e, ao mesmo tempo, entregar o máximo de valor possível.

pic.twitter.com/XR73mIvA0V

-Leandro von Werra (@lvwerra)31 de outubro de 2026

Por que DeepSeek diz que o gargalo é a atenção humana?

O artigo parte de uma simples observação. No ano passado, os agentes de codificação ficaram bons o suficiente para que uma única tarefa fosse limitada pelo modelo. Mas depois que você executa várias tarefas ao mesmo tempo, o limite passa para você. Cada sessão é isolada, então você alterna entre elas manualmente e acompanha o que cada uma sabe. Aparafusar uma CLI, MCP ou um conector de bate-papo em uma sessão local permite que ele ouça sobre novos eventos, mas ainda bloqueia comandos longos, mistura contextos de diferentes tarefas e para quando seu laptop dorme.

A resposta do DeepSeek é parar de tratar a sessão como a unidade que você gerencia. Ele lista quatro características que um superagente deve ter:

• Contínuo.Você conversa com ele onde já trabalha, como chat ou comentários GitHub, e ele se comporta como um agente. Se você solicitar o plano A no chat e mudar para o plano B em um comentário de pull request, o resultado será o seguinte.
• Produtivo.Ele executa várias tarefas complexas em paralelo e executa a próxima instrução antes que a última termine.
• Proativo.Ele observa os acontecimentos, age de acordo com o que vale a pena lidar e, caso contrário, fica quieto.
• Persistente.Ele permanece online e se recupera de falhas sem que você o reinicie.

Os autores argumentam que nenhum loop ReAct pode fornecer todos os quatro, portanto as qualidades devem vir da arquitetura em torno do modelo. Esse é o verdadeiro assunto do artigo, e o explicador visual abaixo, compartilhado por Hesam, é uma maneira rápida de ver todo o design em uma página.

aqui está um explicador visual do artigo de DeepSeek sobre o Superagente:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP

– ℏεsam (@Hesamation)1º de novembro de 2026

Como funciona o design do roteador e do trabalhador?

Pense em um bom gerente de engenharia que nunca escreve código durante a preparação. Oroteadoré uma sessão de longa duração que recebe todas as mensagens de todos os canais. Não executa tarefas. Ele decide o que uma mensagem pede, entrega um novo trabalho a um trabalhador e escreve todas as respostas às pessoas envolvidas. O artigo diz que ele pode ser executado sem nenhuma ferramenta de shell e que um modelo mais leve e mais rápido geralmente é suficiente para isso.

Umtrabalhadoré uma sessão separada com um contexto isolado e um conjunto completo de ferramentas, dedicada a uma tarefa. Os trabalhadores nunca falam diretamente com as pessoas. Eles relatam o status ao roteador, que mantém as respostas em uma só voz. No protótipo, cada ticket recebe sua própria sessão e seu próprio diretório, normalmente uma árvore de trabalho git, e a contagem de trabalhadores é limitada. O padrão é três de cada vez, ajustável de 1 a 16, com um slot extra mantido livre para que a mensagem de uma pessoa possa sempre ser transmitida.

Dois detalhes tornam isso mais do que uma fila de tarefas.

Os acompanhamentos ignoram o roteador.Depois que um trabalhador possui uma solicitação pull ou um tópico de bate-papo, ele se inscreve nesse tópico. Os comentários posteriores vão direto ao assunto, sem nenhuma chamada extra de modelo no roteador. Se um comentário for sobre outra coisa, o trabalhador o devolve.

As explosões são agrupadas.Os gatilhos que chegam durante um modelo entram na fila e são injetados juntos na próxima chamada. Os autores mediram o efeito e analisamos os números abaixo.

Mais um ponto de contraste. O artigo distingue isso de uma equipe de agentes. Em uma equipe de agentes, um líder divide uma tarefa complexa em etapas e coordena as funções que trabalham nela, o que representa uma carga pesada de raciocínio. O roteador Superagente apenas despacha tarefas independentes e rastreia como elas se relacionam em alto nível. Não decompõe a obra em si.

O que acontece quando ninguém pergunta?

É aqui que a filosofia do projeto se torna prática. O primeiro documento no repositório declara o princípio em uma linha: receba o mínimo de atenção humana possível e dê o máximo de valor possível. Cada mensagem que o agente envia custa a atenção de um colega, por isso ele fala apenas quando uma pessoa deve agir ou pode usar um resultado, e age apenas quando solicitado ou quando uma regra escrita pela equipe permite.

A porta que impõe isso é um código simples, não um modelo. Ele verifica quem está solicitando na lista de permitidos da equipe e registra a força da solicitação:

Esse modo de observação é a parte que mais gosto. O agente começa registrando o que teria feito, para que a equipe possa ler esses registros na aba Avaliação e ampliar suas permissões somente quando parecerem corretos. Mensagens, comentários e documentos citados são tratados como entradas para uma decisão. Eles não podem alterar o que o agente está autorizado a fazer.

O artigo de design mostra como é o trabalho proativo na prática. No grupo interno de usuários do Harness DeepSeek, a equipe configurou uma política de “reproduzir e corrigir silenciosamente”. Quando alguém relata um problema ou discute uma mudança proposta, o agente tenta reproduzi-lo e encontrar uma solução em segundo plano, e entrega um resultado somente depois de confirmar o problema e encontrar uma solução simples. Caso contrário, fica quieto. O artigo também fornece uma regra direta para canais de bate-papo que os autores dizem ter verificado: limitar cada resposta a 100 palavras. Em GitHub, por outro lado, as solicitações pull devem ser densas, com o histórico do problema, a descrição da alteração e os resultados da verificação.

Por padrão, cada mensagem GitHub que o agente publica começa com a linha “Isso é feito por um agente automatizado, não por um humano”. As equipes podem editar isso, junto com o restante dos prompts.

Os números de referência se sustentam?

O artigo inclui um pequeno experimento, e os autores têm o cuidado de chamá-lo apenas de indicativo. Quatro projetos foram executados lado a lado em um fluxo de mensagens de CI e bate-papo em grupo: cerca de 300 mensagens por execução, cerca de 20 delas solicitações de trabalho reais, cinco execuções cada. O trabalho de codificação foi simulado por uma ferramenta que simplesmente consome tempo, de modo que o teste mede o agendamento e a coordenação, e não a qualidade do código de qualquer pessoa.

Leia a tabela duas vezes, porque o título não é toda a história. O design do roteador reduziu o tempo de conclusão do p95 para cerca de metade do tempo de uma única sessão, mas usou cerca de duas a quatro vezes os tokens de leitura de cache. E a linha mais interessante é a segunda: remover o atalho de passagem não fez com que as tarefas terminassem mais rápido ou mais devagar, apenas fez com que o roteador tomasse cerca de 30% mais decisões e queimasse 37% mais tokens.

Minha leitura é que a verdadeira descoberta está nas linhas de sessão única. Com um prompt neutro, o modelo nunca chamou um subagente em nenhuma das cinco execuções. Ele fez o trabalho sozinho, novas mensagens o interromperam e as tarefas mais lentas levaram 29,5 minutos. Com um aviso que lhe dizia para delegar, ele delegou em quatro das cinco execuções e, nas execuções restantes, o modelo julgou o trabalho “pequeno” e o fez sozinho. Uma única sessão depende do humor da modelo. Um roteador que não tem permissão para executar código não pode cometer esse erro.

Um teste de estresse separado apenas no roteador aumentou a taxa de chegada de eventos dignos de decisão de cerca de 1 para cerca de 40 por minuto. O lote médio cresceu de 1,0 para 2,8 eventos, o tempo por solicitação subiu apenas de 2,5 para 3,9 segundos e o tempo amortizado por decisão caiu de 6,4 para 1,6 segundos. Quanto mais eventos se acumulam, mais barato cada um fica, até um limite que os autores dizem que depende da extensão do contexto e de quantos eventos um modelo pode lidar com precisão de uma só vez.

DeepSeek acaba de abrir o código-fonte de seu protótipo de superagente. Uma sessão do roteador conversa com as pessoas e distribui trabalho, e trabalhadores isolados executam tarefas em paralelo nos eventos GitHub. Em seu próprio teste, o tempo de conclusão do p95 caiu de 29,5 para 15,7 minutos em comparação com uma única sessão usando subagentes.

A baleia abriu o código novamente.pic.twitter.com/mS4sRbHmyx

– Gordinho (@kimmonismus)1º de novembro de 2026

Estes são resultados auto-relatados em trabalho sintético. Eles mostram que a ideia de agendamento é boa. Eles não mostram que o protótipo corrige seus bugs mais rapidamente.

O que dizem as pessoas próximas ao projeto sobre seus limites?

Logo após o lançamento, Cui Tianyi, do departamento de produto do DeepSeek e um dos revisores finais do artigo de design, escreveu como vê o design. Seu enquadramento é útil porque é modesto. Ele nomeia o compromisso central como continuidade entre tarefas versus produtividade de tarefas.

Nos limites, a revisão é direta. O protótipo implementa apenas parte do design proposto. Na sua análise, o DeepSeek Harness não tinha memória de longo prazo integrada entre as sessões. E o sistema foi validado apenas em um ambiente pequeno e confiável dentro da empresa. A própria seção de problemas abertos do artigo lista o dimensionamento do roteador, a memória ao longo de meses, o trabalho sem sessões, os limites de contexto entre os agentes e como os agentes isolados devem se comunicar entre si e a segurança.

O que você deve verificar antes de executá-lo?

A documentação é mais sincera do que a maioria das postagens de lançamento e vale a pena tratar seus avisos como requisitos.

• Os trabalhadores têm amplo acesso.Ambas as predefinições de permissão, para o roteador e para os trabalhadores, são executadas comdanger-full-accesscomo usuário do sistema operacional da operadora. Os wrappers de conta escolhem quais credenciais GitHub o agente usa, mas os documentos dizem que são padrões e não um limite de segurança, porque um trabalhador ainda pode executar um programa por caminho absoluto ou ler seu diretório inicial. A recomendação é uma conta de sistema operacional dedicada que contenha apenas as credenciais do agente.
• A entrada não confiável é a questão de segurança em aberto.O artigo alerta que se uma injeção imediata ou intrusão no servidor comprometer o loop do agente em nuvem, todos os dispositivos conectados poderão ser alcançados e as credenciais que entrarem no contexto do modelo poderão vazar.
• Os humanos se fundem por padrão.O agente nunca permite a mesclagem automática em sua própria conta. A mesclagem automática precisa de uma CLI de uma segunda conta nomeada no prompt de requisitos de entrega, e as instruções padrão permitem isso apenas para solicitações pull pequenas e aprovadas com menos de 200 linhas alteradas.
• Ele é construído em torno de um repositório.Cada configuração monitora um único repositório GitHub, e Feishu, uma ferramenta de bate-papo no local de trabalho comum na China, é a outra fonte de primeira classe.
• Você precisa do chicote DeepSeek e de um fornecedor de modelo.A configuração lista Node.js 22.19 ou mais recente, pnpm, git 2.32 ou mais recente, tmux, Python 3.8 ou mais recente e GitHub CLI 2.48 ou mais recente. Configurar um provedor de modelo é uma etapa do operador.
• O ruído é um custo.O documento de filosofia diz para não usar o agente para produzir volume. Solicitações pull em massa e mensagens de transmissão custam mais à sua equipe do que dão.

Como você tentaria sem arriscar seu repositório principal?

A configuração tem muitas etapas, então o projeto pede que você deixe um agente de codificação fazer isso com você. De acordo com o README, o agente faz uma pergunta curta por vez, mostra o plano completo uma vez e depois instala e configura tudo. Uma primeira execução cautelosa é assim:

1. Escolha um repositório descartávele um usuário de máquina dedicado ou conta de sistema operacional. Não use seu próprio login.
2. Crie uma conta GitHub separada para o agente.Tudo o que escreve aparece com esse nome.
3. Abra o repositório em seu agente de codificação e cole o prompt abaixo.Responda às perguntas uma de cada vez.
4. Mantenha a lista permitida para vocêe deixe o modo de aceitação em observação.
5. Solicite algo pequeno.De uma conta permitida, comente@<agent login> <request>sobre um assunto. Um ticket deverá aparecer na Visão Geral do painel em cerca de um minuto.
6. Leia a guia Eval por uma semana.Amplie a lista ou mude para automático somente quando os registros “aceitariam” parecerem corretos.

Read SETUP.md in this repository and set up dsh-superagent with me.

O documento de filosofia do projeto dá aos operadores quatro regras que valem a pena repetir: comece de forma restrita, ajuste para menos ruído, não use o agente para produzir volume e seja dono do que está escrito em seu nome.

Para onde deve ir o resto do trabalho do agente?

Suponha que um trabalhador gaste uma hora em um teste de integração instável. A solicitação pull é a solução. Mas a investigação por trás disso, quais testes falharam, quais hipóteses foram descartadas, o que a tabela de tempo mostrou, não pertence a uma descrição de relações públicas e é exatamente o que o revisor quer contestar. Se isso persistir apenas em uma resposta de chat, o próximo agente ou colega de equipe começará do zero.

AgentGrid.ioé construído para essa transferência. Humanos e agentes de IA trabalham nos mesmos documentos, aplicativos e arquivos ativos, com um endereço estável, acesso controlado e um histórico de versões. Os documentos do AgentGrid.io descrevem a conexão de um agente com capacidade de comando executandonpx @animaapp/cli@latest login. Um ser humano aprova o nome do agente, a equipe e o que ele pode fazer: ler, escrever, compartilhar ou publicar. Depois disso, as alterações do agente aparecem no histórico com seu próprio nome. O protótipo não tem integração interna com AgentGrid.io, então trate isso como um padrão para testar com seus trabalhadores, não como um recurso documentado.

Na prática, o trabalhador escreve sua investigação como um arquivo Markdown, o revisor comenta em uma linha da tabela, outro assistente estreita o resumo e a solicitação pull vincula-se a uma versão atual em vez de três cópias coladas.

Para outra abordagem sobre várias pessoas compartilhando um agente, consulte nosso guia paraBots da equipe Grok Bot. E se você quer saber o que é executado em um agente hospedado, nosso guia paraClaude Managed Agentsanalisa a versão de Anthropic da mesma divisão de cérebro e mãos, que o artigo de DeepSeek cita.

Quando você deve usar dsh-superagent e quando outra coisa?

• Usar dsh-superagentaprender com um projeto sério e documentado, executar um experimento contido em um repositório de baixo risco ou pegar emprestado suas ideias: um roteador que nunca executa código, tickets com escopo declarado, modo de observação antes do modo automático.
• Use um único agente de codificação interativoquando você trabalha uma tarefa de cada vez e deseja orientar passo a passo. O Superagente foi criado para a situação oposta.
• Usar AgentGrid.ioquando a saída é um documento, relatório ou aplicativo que várias pessoas e agentes precisam revisar, editar e publicar, seja qual for o agente que o produziu.

Perguntas frequentes

O que é DeepSeek Super-Agent?

É um protótipo de pesquisa denominado dsh-superagent, lançado pela equipe Harness do DeepSeek em 31 de outubro de 2026 sob a licença do MIT. É um agente de codificação proativo para um repositório GitHub. Uma sessão de roteador de longa duração recebe solicitações e atribui cada uma aceita à sua própria sessão de trabalho, que responde na conversa original, geralmente com uma solicitação pull.

O DeepSeek Super-Agent é um produto DeepSeek oficial?

Não. O README o chama de protótipo de pesquisa apenas para referência e não de produto DeepSeek oficial, e diz para revisá-lo e adaptá-lo antes de usá-lo em seu próprio ambiente. Também não é idêntico à versão interna ou à implementação descrita no artigo de design.

Qual a diferença entre um superagente e um subagente?

Um subagente adiciona uma camada abaixo do agente ativo. Um Superagente adiciona uma camada acima dele. Neste design, o roteador fica acima de muitos trabalhadores, conversa com as pessoas e despacha tarefas, enquanto cada trabalhador realiza uma tarefa isoladamente. O nome tem a ver com posição, não com reivindicação de maior inteligência.

Precisa de Feishu ou apenas GitHub?

Somente GitHub é suficiente. Feishu é uma segunda fonte opcional e a documentação diz que uma falha de configuração do Feishu desativa apenas a fonte Feishu.

É seguro rodar em um repositório da empresa?

Não como está. Os documentos dizem que os trabalhadores são executados com acesso total como usuário do sistema operacional da operadora e que as contas do wrapper não são um limite de isolamento. Eles recomendam uma conta de sistema operacional dedicada, uma conta de agente dedicada em GitHub, uma pequena lista de permitidos e modo de observação enquanto você aprende como o agente se comporta.

É mais rápido que uma única sessão de agente de codificação?

No teste simulado dos próprios autores, o projeto do roteador concluiu as tarefas mais lentas em 15,7 minutos, contra 29,5 minutos para uma única sessão com uma ferramenta de subagente, usando mais tokens. O teste usou trabalho de codificação simulado e cinco execuções por design, portanto mostra benefícios de agendamento, não qualidade do código.