A DeepSeek publicou em 31 de outubro de 2026 o Dsh Superagent, um agente que cuida de um repositório do GitHub por conta própria: recebe pedidos de pessoas autorizadas, abre uma tarefa, trabalha em sessão e diretório próprios e responde na conversa em que o pedido nasceu, por exemplo com um pull request. Ele não é um harness novo. É um pacote que roda dentro do DeepSeek Harness, o framework que a empresa abriu em agosto de 2026, e existe para mostrar o que dá para montar em cima dele. O repositório somava 10.666 estrelas e 1.093 forks em 2 de novembro de 2026, dois dias depois de ir ao ar, sob licença MIT e com o aviso de que é protótipo de pesquisa, não produto oficial da DeepSeek.
O que é o Dsh Superagent
A diferença em relação ao harness é de camada. O harness entrega o motor: modelo, ferramentas, sessões, sandbox e loop de execução. O Dsh Superagent entrega o agente já montado, com as decisões que o framework deixa em aberto, como quem pode pedir trabalho, o que conta como tarefa concluída e o que aparece na tela para uma pessoa revisar. Ele se instala como bundle, o formato de plugin do harness, num perfil dedicado chamado superagent, e ganha aba própria na barra lateral da interface web.
O escopo é estreito de propósito: um repositório por instalação, hospedado no github.com, porque GitHub Enterprise não é suportado. O agente acompanha issues, pull requests, comentários e o resultado de CI do branch padrão. Opcionalmente, também atende pedidos por Feishu, o mensageiro corporativo usado por boa parte das empresas chinesas. Não é um assistente de conversa: o README insiste que ele só se manifesta quando alguém precisa agir ou pode usar um resultado.
Quem assina o trabalho é uma conta de usuário do GitHub com permissão de escrita, criada só para o agente e autenticada por um gh isolado. GitHub App não serve, porque o projeto lê as notificações da conta. Toda mensagem publicada por ele começa com a linha “This is by an automated agent, not a human”, para que ninguém no repositório confunda o robô com um colega.
Como funciona
O desenho é pequeno e cabe numa frase. Uma fonte, o Source, produz gatilhos (Triggers), que são eventos imutáveis como um comentário ou uma issue nova. Os gatilhos de um mesmo assunto formam uma thread, e a thread alimenta o Eval, a camada de julgamento que decide se aquilo vira trabalho. Quando aceita, o Eval cria um ticket com um mandato (Mandate), que registra a versão da política, o escopo e a força da autorização. O ticket vai para um executor, e o resultado volta à conversa de origem pelo canal.
A autorização é a parte mais elaborada. A política é versionada e define quem pode pedir o quê em cada fonte. Mensagem, comentário ou documento citado entram na decisão como dado, e não podem alterar permissão. Um bot fora da lista de bots da fonte pode, no máximo, gerar um candidato inferido, que o sistema registra sem executar. Quando a política muda, o Eval em andamento é descartado.
Cada ticket ganha uma sessão worker-<id> e um diretório próprio, criado a partir de um clone local, com um worktree por ticket quando a preparação está configurada. O executor roda comandos sem pedir aprovação, como o usuário do sistema operacional que iniciou o processo. Comandos de shell passam para segundo plano depois de 5 segundos, para que o agente receba mensagem nova no passo seguinte, e o trabalho em segundo plano tem no máximo 30 minutos depois do fim de cada turno.
Esse arranjo corresponde ao que o artigo de arquitetura chama de dois níveis: uma sessão principal que conversa com pessoas e distribui trabalho, e sessões isoladas que executam. O que muda é o grau de autonomia. O artigo descreve um agente que age sozinho quando uma regra escrita pela equipe permite; o protótipo implementa a fatia que cabe num repositório, com registro do que ele teria feito antes de deixar fazer.
Recursos já existentes
O pacote já traz o suficiente para operar, desde que o operador aceite a fase alfa do harness. O recurso mais visível é o painel Superagent, que abre na interface web do harness e responde três perguntas nesta ordem: algo precisa de mim agora, o sistema está saudável e qual foi o histórico de um trabalho.
- Painel com abas Overview, Source, Trigger, Eval, Execution e Settings, listando primeiro o que espera uma pessoa.
- Política de autorização com lista de permitidos, regras versionadas e mandato por ticket.
- Sessão e diretório próprios por ticket, com worktree separado para cada trabalho em andamento.
- Leitura de issues, pull requests, comentários e CI do branch padrão, com opção de receber tudo o que acontece no repositório.
- Feishu opcional, via
lark-cli, para pedidos feitos por chat em vez de pelo GitHub. - Prompts e skills editáveis pela equipe, com aviso de “Default updated” quando o texto padrão muda numa atualização.
O que está no artigo e não no código
O projeto saiu junto com “Exploring Super-agent Design: Towards a More Autonomous Agent System”, artigo publicado em 1º de novembro de 2026 pelo perfil DeepSeek Harness no X, em chinês, com tradução automática para o inglês. O texto define o super-agente por quatro características (contínuo, produtivo, proativo e persistente) e cinco módulos: arquitetura de dois níveis, gatilhos por evento, interação multi-canal, separação entre computação, estado e ambiente, e um watchdog externo que julga se cada worker está progredindo ou perdido.
O README avisa que o código foi adaptado para publicação, não é idêntico à versão interna do time e que parte do que o artigo descreve é direção futura, não implementação. O watchdog, a separação entre computação e estado e a escala da arquitetura de dois níveis aparecem como problema em aberto no próprio texto. O repositório tem um único commit, nenhuma release e a versão 0.1.0 no package.json, marcada como privada, ou seja, sem pacote publicado.
É um produto oficial da DeepSeek?
Não. O aviso está na primeira linha do README: protótipo de pesquisa, para referência, e não um produto oficial. A DeepSeek descreve o código como fruto do trabalho diário do time, com boa parte da engenharia feita por agentes de código, e pede que quem for usar revise e adapte antes de colocar no próprio ambiente. O artigo repete a ressalva no fim: o plugin serve para validar a abordagem técnica, não para ser adotado como produto.
Precisa do DeepSeek Harness para rodar?
Sim, e de uma versão específica. O package.json exige dsh ^0.2.1-alpha.2, e o harness ainda está em prévia. Além dele, a instalação pede Node.js 22.19 ou 24, pnpm, git 2.32, Python 3.8, tmux e GitHub CLI 2.48. É por isso que o projeto não é um aplicativo para baixar: o caminho previsto é pedir a um agente de código que leia o SETUP.md e conduza a configuração, uma pergunta por vez.
Para quem acompanha o harness desde agosto, o Dsh Superagent responde a pergunta que ficou no ar: se o framework sustentava um agente de verdade, com permissão, histórico e revisão, em vez de um chat que esquece o que fez. A resposta vem com data de validade. É um protótipo de pesquisa, feito para provar uma tese de arquitetura, e o próprio time avisa que ele pode conter bugs. Serve para estudar o desenho e testar a ideia num repositório de laboratório, não para entregar produção sem alguém olhando.
Fonte: DeepSeek Harness | GitHub
