DeepSeek SuperAgent: o que é o painel web que mostra só o trabalho que precisa de um humano

Fala aí, beleza? A DeepSeek soltou um agente que não tenta te tirar do loop, ele organiza a fila do que depende de você 😀

O DeepSeek SuperAgent saiu em 31 de outubro de 2026 como protótipo de pesquisa no repositório oficial deepseek-ai/dsh-superagent-prototype, descrito como "Towards a More Autonomous Agent System" e com licença MIT

Quem fez foi o time do DeepSeek Harness (o dsh), e ele é distribuído como bundle/plugin pro dsh

Na prática é um agente de código proativo para UM repositório GitHub, com um painel web local que mostra primeiro o que precisa de uma pessoa

Aqui o foco é esse painel, a fila de revisão e os limites de concorrência, pra tu avaliar se o teu time tem rotina pra dar conta disso

Como o DeepSeek SuperAgent decide começar um trabalho

O agente não sai mexendo no repo por conta própria: o trabalho só começa com um pedido autorizado ou com uma regra que o time escreveu

O fluxo fica assim:

• Uma pessoa da lista de permitidos pede algo numa issue ou PR, ou uma regra escrita pelo time permite a ação
• Isso vira um Ticket, a unidade de trabalho autorizado
• O Ticket carrega um Mandate imutável, que diz POR QUE aquele trabalho pode seguir
• O trabalho roda em sessão e diretório próprios
• A resposta volta na conversa original, por exemplo com um pull request para revisão humana

E quem faz o quê?

A arquitetura separa dois papéis: o Router fica com a conversa e o Worker (a sessão executora) fica com o Ticket

Pensa num atendente que conversa com o cliente e repassa a tarefa pra alguém da equipe técnica, que trabalha isolado na própria bancada

Além do GitHub, ele pode escutar chats do Feishu, mas isso é opcional: pra usar, é preciso habilitar também a entrada dsh-superagent-feishu

O que o painel web mostra e por que ele esconde o resto

O painel lista só os itens que precisam de um humano, e depois disso mostra a saúde do sistema e o histórico

Ou seja, a ordem de prioridade é essa:

1. Itens que precisam de uma pessoa
2. Saúde do sistema
3. Histórico

O motivo é simples: se tudo aparece com o mesmo peso, o que pede decisão se perde no meio do log haha

As abas, conforme a documentação do painel:

• Overview: tickets que precisam de ação e problemas do sistema
• Source: problemas de configuração
• Trigger: threads filtradas
• Eval: decisões
• Execution: estado do executor e status dos tickets
• Settings: fontes, avaliação, execução, prompts e deploy

O painel é acessível de fora?

Não, ele é local

O bundle serve o painel em 127.0.0.1, e o host precisa ser 127.0.0.1:<porta> ou localhost:<porta>

Tome cuidado: isso significa que quem vai olhar a fila precisa estar na máquina onde o bundle roda

Revisão humana como parte do fluxo, não como exceção

O projeto parte de uma ideia bem clara: gastar o mínimo de atenção humana e entregar o máximo de valor

O README explica o porquê: o gargalo é a atenção de quem acompanha, já que uma pessoa normalmente dá conta de só 3 a 5 sessões de agente ativas

Então em vez de fingir que o humano não existe, o desenho todo gira em torno de economizar o tempo dele

Se liga como isso aparece em cada peça:

• O Mandate justifica o trabalho antes dele começar
• O resultado chega como PR para revisão, não como merge direto
• O painel filtra só o que pede decisão

Aprovar não é um freio de emergência, é uma etapa normal do caminho do Ticket

Limite de concorrência e o slot extra para humanos

Os Workers rodam em paralelo até o limite de concorrência que tu configura, e pedidos humanos ganham 1 slot adicional fora desse limite

Esse slot extra vale pra mensagens de pessoas e pedidos de status

A ideia é que tickets já existentes continuem respondendo mesmo com todos os slots normais ocupados

O slot extra garante resposta na hora?

Não garante

Ele evita que a intervenção humana fique bloqueada, mas não promete resposta imediata em todos os casos

E tem um detalhe que pega muita gente: quando um comando vai pra segundo plano, o slot de concorrência do worker NÃO é liberado

Ou seja, comando em background continua contando como slot ocupado

O que o Watchdog faz quando um Worker trava

O Watchdog é uma sessão separada, rodando em timer, que verifica se cada Worker está progredindo de verdade e corrige falhas

Os sinais de problema citados são:

• Timeout
• Chamadas de ferramenta idênticas repetidas (o famoso agente em loop)
• Ausência de heartbeat

E dá pra perguntar a ele em linguagem natural o que deu errado, o que é muito massa na hora de investigar

Isso conversa direto com o painel: se tem alguém vigiando travamento, o humano não precisa ficar de babá das sessões e pode focar na fila de decisão

Seu time tem rotina para atender essa fila?

Antes de pensar em instalar, a pergunta real é essa: tem alguém com tempo reservado pra responder o que o agente deixa esperando?

Se ninguém olha a fila, o agente vai acumulando trabalho parado aguardando decisão

Algumas perguntas pra fazer no time:

• Quem está na lista de permitidos pra pedir trabalho em issues e PRs?
• Quem revisa os PRs que o agente abre, e com que frequência?
• Quem vai abrir o Overview no dia a dia?
• O time já escreve regras de quando o agente pode agir sozinho?

E os limites pra adoção que já estão na mesa:

• É um protótipo de pesquisa, não um produto
• O escopo é UM repositório GitHub
• O painel é só local

Como ele roda em cima do dsh, vale também entender o status do DeepSeek Harness antes de colocar algo assim perto do trabalho real

Vídeo: mais DeepSeek aqui no Hora de Codar

Se tu quer ver DeepSeek na prática, esse vídeo mostra engenharia reversa com IA usando DeepSeek gastando pouco

Por onde começar a avaliar o SuperAgent

O próximo passo é ler o README e o SETUP.md do repositório oficial, que têm os detalhes completos

Pelo README, a instalação segue estes passos:

1. Instalar o dsh exatamente na versão pedida:

npm install -g @deepseek-ai/[email protected]

2. Clonar o repositório com o nome dsh-superagent:

git clone https://github.com/deepseek-ai/dsh-superagent-prototype dsh-superagent

3. Dentro da pasta clonada, instalar e buildar:

pnpm install && pnpm build

4. Adicionar o plugin ao perfil do dsh:

dsh plugin --profile superagent add <caminho do repositório>

Se tu nunca mexeu no dsh, vale dar uma olhada em como rodar o DeepSeek Harness antes

Mas a dica mais importante nem é técnica: antes de rodar o primeiro comando, defina quem vai responder à fila do painel 🙂

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.