A DeepSeek publicou dsh-superagent, um protótipo de pesquisa sob licença MIT, apresentado como um agente de programação proativo destinado a um único repositório GitHub. Empacotado para o DeepSeek Harness, ele escuta o GitHub e, opcionalmente, o Feishu, transformando depois os pedidos autorizados em tarefas paralelas, cada uma na sua própria sessão de agente.
- A DeepSeek publica o dsh-superagent, um protótipo de pesquisa sob licença MIT.
- O agente atende pedidos autorizados vindos do GitHub ou do Feishu.
- Cada pedido corre numa sessão isolada, graças a uma arquitetura Router-Worker.
- Nas simulações, o p95 cai para 15,7 minutos, contra 29,5 minutos, mas a qualidade do código não foi medida.
Um agente que espera ser solicitado
O funcionamento baseia-se na noção de Ticket, uma unidade de trabalho aberta quando uma pessoa autorizada se dirige ao agente. Cada Ticket executa-se na sua própria sessão e diretório, e os resultados regressam à conversa original, frequentemente sob a forma de uma pull request, ou seja, uma proposta de alteração de código submetida para revisão. Uma interface web local lista apenas os elementos que necessitam da intervenção de uma pessoa.
O README do projeto estabelece uma regra simples: reduzir ao mínimo a atenção humana enquanto se traz o máximo de valor. De acordo com o documento de filosofia do projeto, o agente pede confirmação apenas uma vez, mantém-se silencioso durante o seu trabalho e só volta a falar com um resultado, uma pergunta ou uma falha.
Uma arquitetura Router-Worker
Segundo a equipa, os agentes comuns consideram a sessão como unidade básica. De acordo com o relatório citado pelo ifeng, uma pessoa só pode acompanhar ativamente 3 a 5 sessões de cada vez, pelo que a atenção humana, e não a capacidade do modelo, se torna o fator limitante do trabalho em paralelo. A arquitetura proposta tem duas camadas: um Router de longa duração gere as trocas e a distribuição de tarefas, enquanto sessões Worker isoladas realizam o trabalho real.
O modelo de domínio descreve uma sequência precisa: o GitHub ou o Feishu produzem eventos, chamados Triggers; uma etapa de avaliação decide se um lote de Triggers chama um novo trabalho; cada Ticket transporta um Mandate imutável que enuncia por que pode ser executado; por fim, os comentários subsequentes numa pull request são encaminhados para o Worker correto sem nova menção. Os comandos shell passam para segundo plano ao fim de 5 segundos, para que os Workers continuem a receber mensagens. O trabalho proativo é enquadrado por três modos: off, observe (predefinido) e auto. No modo observe, o agente limita-se a registar o que teria aceitado.
Resultados provenientes de uma simulação
A DeepSeek testou o sistema em fluxos simulados de discussão de grupo e CI do GitHub, com cerca de 300 mensagens por tentativa, das quais aproximadamente 20 pedidos de trabalho reais, tendo cada configuração sido executada 5 vezes. O super-agente apresenta um p50 de 12,4 minutos e um p95 de 15,7 minutos, contra um p95 de 29,5 minutos para uma sessão única com subagentes e prompt neutro, para a qual não foi comunicado qualquer p50. Nesta configuração de referência, o subagente não foi chamado nenhuma vez em 5 tentativas.
De acordo com esses mesmos dados, quando o número de chegadas passou de cerca de 1 para 40 por minuto, o tamanho dos lotes passou de 1,0 para 2,8 e a latência por pedido de 2,5 para 3,9 segundos. Estes números são autodeclarados pela DeepSeek e provêm de relatórios secundários do relatório. O projeto esclarece ainda que só foi testado em mensagens sintéticas e ferramentas simuladas, e que a qualidade real do código produzido não foi medida.
Para a instalação, o protótipo necessita de Node.js 22.19+ ou 24+, git 2.32+, Python 3.8+, tmux e GitHub CLI 2.48+. O repositório indica ainda que o agente é executado com todos os direitos do utilizador do sistema operativo, o que obriga a isolá-lo antes de qualquer utilização.
