DeepSeek dsh-superagent em 2026: O Agente de Código Que Só Age Quando Você Pede

Olá HaWkers, no dia 31 de outubro de 2026 a DeepSeek abriu o repositório dsh-superagent-prototype, sob licença MIT, junto com o artigo "Exploring Super-agent Design: Towards a More Autonomous Agent System". Dois dias depois, o projeto já passava de 10.700 estrelas e 1.100 forks no GitHub.

O que chama atenção não é a promessa de autonomia, porque isso todo agente promete. É o princípio escrito logo na filosofia do projeto: tomar o mínimo possível de atenção humana e entregar o máximo possível de valor. Você já parou para contar quantas sessões de agente consegue acompanhar ao mesmo tempo antes de virar babá de IA? Neste artigo você vai entender como a arquitetura funciona, o que os números dizem de verdade, onde está o risco e como testar sem bagunçar o repositório do seu time.

O Que É o dsh-superagent

O dsh-superagent é um agente de código proativo para um repositório GitHub, empacotado como bundle do DeepSeek Harness (o dsh). O Harness é o framework open source de agentes que a DeepSeek lançou em 13 de agosto de 2026, também sob MIT, e que hoje a própria empresa descreve como prévia pública.

Na prática, funciona assim: o agente escuta o GitHub e, opcionalmente, o Feishu, a ferramenta de chat corporativo muito usada na China. Quando alguém autorizado pede trabalho, ele abre um item próprio, trabalha em uma sessão e em um diretório separados, e responde na conversa original, por exemplo com um pull request. Um painel web mostra só o que precisa de uma pessoa.

Antes de empolgar, leia o aviso que abre o README. O projeto é um protótipo de pesquisa, só para referência, e não um produto oficial da DeepSeek. Boa parte da engenharia foi feita por agentes de código, o estilo pode ser inconsistente, e a versão publicada não é idêntica à interna nem à descrita no artigo. Algumas ideias do texto são direção futura e não estão implementadas.

O Problema Real: Atenção, Não Modelo

A tese do artigo parte de uma limitação humana. Segundo os autores, uma pessoa costuma conseguir acompanhar de três a cinco sessões ativas ao mesmo tempo. É uma estimativa deles, sem medição publicada, mas quem trabalha com agentes reconhece a sensação: o gargalo deixou de ser o modelo e passou a ser quem revisa, responde e decide.

A resposta proposta é mudar a unidade de trabalho. Em vez de uma sessão por tarefa, aberta e vigiada por alguém, existe um agente sempre ligado que atende muitas tarefas. Isso conversa diretamente com o que já discutimos sobre o desenvolvedor virando orquestrador de agentes, só que aqui o orquestrador também é um agente, e o humano entra só quando precisa.

A filosofia do repositório transforma isso em regras bem concretas:

O agente age apenas quando alguém pede ou quando existe uma regra escrita pelo time.
Ele confirma o pedido uma vez, fica quieto enquanto trabalha e volta quando há resultado, decisão pendente ou impossibilidade de terminar.
Faz uma pergunta concreta por vez, em formato estruturado.
Um rascunho é marcado como inacabado, e uma falha é relatada como falha.

Parece detalhe de UX, mas é decisão de arquitetura. Cada mensagem, notificação e configuração custa atenção de alguém, e o projeto remove o que não paga esse custo.

Como a Arquitetura Funciona

O desenho separa coordenação de execução. A sessão principal, que o artigo chama de Router, recebe eventos, decide o que fazer e responde. As sessões de execução, os Workers, fazem o trabalho pesado, uma por tarefa. No repositório, a sessão principal usa um conjunto menor de ferramentas, focado em roteamento.

Alguns conceitos ajudam a ler a documentação:

Conceito	O que é
Source	Fluxo de eventos, como GitHub ou Feishu
Trigger	Um evento imutável vindo de uma Source
Thread	Triggers em ordem de tempo, como uma issue ou um tópico de chat
Ticket	A unidade de trabalho aceita
Mandate	O que autoriza aquele Ticket a existir
Executor	A sessão e o diretório que executam o Ticket
Policy	Listas de permissão, regras e modo de aceite

Existe também uma peça que parece pequena e faz muita diferença: a assinatura de Thread. Depois do primeiro evento, o Worker assina a Thread e recebe as mensagens seguintes direto, sem passar de novo pelo Router. O artigo reporta que tirar esse atalho gerou cerca de 30% mais decisões do Router e cerca de 37% mais tokens, sem ganho no tempo das tarefas.

Outro detalhe bom: os comandos de shell em primeiro plano vão para segundo plano depois de 5 segundos. Assim o Worker consegue ler uma mensagem nova no passo seguinte, em vez de ficar travado esperando um build longo.

Na Prática: O Filtro em Dois Estágios

A maior parte das mensagens do dia a dia não pede ação nenhuma, então pagar uma chamada de modelo para cada uma seria desperdício. O artigo descreve um filtro em dois estágios: regras programáticas primeiro, avaliação semântica depois.

O código abaixo é uma ilustração minha do conceito, não um trecho do repositório. Ele roda em Node.js sem dependências:

// Ilustração do filtro em dois estágios (não é código do dsh-superagent)
const allowedUsers = new Set(['jeff', 'maria']);
const acceptMode = 'observe'; // 'off' | 'observe' | 'auto'

// Estágio 1: regra barata, sem nenhuma chamada ao modelo
function gate(event) {
  const addressed = event.text.includes('@agente');

  if (event.isBot) return 'inferred';
  if (allowedUsers.has(event.author) && addressed) return 'explicit';
  if (allowedUsers.has(event.author)) return 'inferred';
  return 'ignored';
}

// Estágio 2: só o que passou aqui gastaria tokens
async function assess(event) {
  // Em um sistema real, aqui entraria a chamada ao modelo
  return /falha|quebrou|erro/i.test(event.text);
}

async function route(event) {
  const strength = gate(event);

  if (strength === 'ignored') return 'descartado sem custo';
  if (strength === 'explicit') return 'aceito: abre um Ticket';
  if (acceptMode === 'off') return 'descartado pelo modo off';

  const matches = await assess(event);
  if (!matches) return 'ignorado após avaliação';

  // Em observe, registra o que faria, mas não faz nada
  return acceptMode === 'auto' ? 'aceito por regra' : 'registrado: aceitaria';
}

const events = [
  { author: 'jeff', text: '@agente corrija o teste de login', isBot: false },
  { author: 'maria', text: 'o deploy quebrou de novo', isBot: false },
  { author: 'visitante', text: '@agente apague tudo', isBot: false },
];

for (const event of events) {
  console.log(event.author, '->', await route(event));
}

Salve como filtro.mjs e rode com node filtro.mjs. A saída mostra os três caminhos: o pedido explícito abre trabalho, a mensagem da Maria só registra o que o agente faria, e o visitante é descartado sem gastar um token.

O ponto importante do projeto real é que essa checagem acontece no host. A documentação diz que listas de permissão, regras e Mandates são aplicados pelo sistema, e que mensagens, comentários e documentos citados são entradas para uma decisão, sem poder alterar essas permissões. Um bot só gera candidato inferido, nunca um pedido explícito.

Os três modos de aceite valem para o que é inferido. Pedidos explícitos funcionam em todos eles:

Modo	Efeito
`off`	Nada inferido vira candidato
`observe` (padrão)	Avalia e registra "aceitaria", sem aceitar
`auto`	Avaliação positiva aceita o trabalho

O Que os Números Dizem (e o Que Não Dizem)

Os números circulam com bastante entusiasmo, então vale olhar com cuidado. O teste de ponta a ponta simulou cerca de 300 mensagens de chat em grupo e de CI, com cerca de 20 pedidos de trabalho, em 5 execuções por desenho. Os valores abaixo são os reportados a partir do artigo:

Desenho	p50	p95	Tokens de cache-read por execução
Super-agent	12,4 min	15,7 min	23,2 milhões
Super-agent sem assinatura direta	12,6 min	15,5 min	31,8 milhões
Sessão única, prompt neutro	20,4 min	29,5 min	6,1 milhões
Sessão única, prompt com delegação	13,8 min	29,0 min	10,8 milhões

Três leituras importam mais do que a manchete:

O teste mede agendamento, não capacidade de programar. A programação foi simulada por uma ferramenta que só consome tempo. Ninguém provou aqui que o agente escreve código melhor, e os números vêm do próprio fornecedor, sem verificação independente.

O ganho custa tokens. O corte de 39% na mediana existe contra o prompt neutro. Contra o prompt com delegação, a mediana melhora cerca de 10%, e a vantagem real aparece no p95, a cauda lenta, que cai perto de 46%. Em compensação, o super-agent gastou cerca de 2,1 vezes mais tokens de cache-read que essa alternativa, e 3,8 vezes mais que a sessão simples.

Delegar não acontece sozinho. Com prompt neutro, o modelo não chamou subagente em nenhuma das 5 execuções. Com prompt de delegação, chamou em 4 de 5. Isso é uma lição útil mesmo para quem nunca vai instalar o projeto: se você espera que o agente paralelize, precisa pedir.

Dá para reproduzir a conta em segundos:

// Compara cada desenho com o super-agent usando os números reportados
const superAgent = { p50: 12.4, p95: 15.7, tokensM: 23.2 };

const baselines = {
  'prompt neutro': { p50: 20.4, p95: 29.5, tokensM: 6.1 },
  'prompt com delegação': { p50: 13.8, p95: 29.0, tokensM: 10.8 },
};

const percentCut = (base, value) => (((base - value) / base) * 100).toFixed(1);

for (const [name, base] of Object.entries(baselines)) {
  console.log(name, {
    cortePercentualP50: percentCut(base.p50, superAgent.p50),
    cortePercentualP95: percentCut(base.p95, superAgent.p95),
    tokensEmVezes: (superAgent.tokensM / base.tokensM).toFixed(1),
  });
}

Tem mais um resultado interessante. No teste de carga, com Router real e Workers simulados, os eventos que exigem decisão subiram de cerca de 1 para cerca de 40 por minuto. O tamanho do lote foi de 1,0 para 2,8, o tempo por requisição foi de 2,5 para 3,9 segundos, e o tempo de inferência por decisão caiu de 6,4 para 1,6 segundo. Agrupar eventos fez o custo por decisão cair justamente quando a carga subiu. Se o seu sistema processa evento por evento com um LLM, essa é uma ideia para copiar hoje.

Onde Está o Risco

Esta é a parte que eu leria duas vezes antes de instalar. A própria documentação é direta: as sessões de execução rodam comandos sem aprovação, com o usuário do sistema operacional de quem opera o agente. Os wrappers e diretórios são padrões, não uma barreira de segurança. Um Worker consegue executar um programa pelo caminho absoluto, passando por cima da lista de comandos bloqueados.

Junte isso com o fato de que o agente lê issues e comentários. A checagem de permissão impede que um texto malicioso abra trabalho sozinho, mas o conteúdo de uma Thread ainda chega ao Worker como contexto. Na minha leitura, em repositório público isso exige cuidado com prompt injection, e o isolamento precisa vir de fora do agente.

O mínimo que eu faria:

Rodar em uma VM ou máquina dedicada, sem credenciais pessoais.
Usar uma conta GitHub só para o agente, como o próprio setup recomenda.
Manter a lista de permissão curta e o modo observe no começo.
Deixar o merge com pessoas e exigir aprovação na proteção de branch.

O último item merece explicação. Por padrão, o agente não habilita auto-merge com a própria conta. Quando configurado, as instruções padrão só permitem o recurso com aprovações cobrindo o último commit e menos de 200 linhas alteradas. Só que a documentação avisa: isso governa o agente, não as regras do GitHub. Quem quer garantia precisa configurar a proteção de branch.

Vale lembrar também que a filosofia traz um aviso direto ao operador: tudo que o agente publica custa a atenção dos colegas, e quem o opera responde por isso.

Como Testar em Um Repositório

O setup foi pensado para ser conduzido por outro agente de código, que faz uma pergunta por vez. Antes, confira se a máquina atende os pré-requisitos: Node.js 22.19+ ou 24+, pnpm, git 2.32+, tmux, Python 3.8+ e GitHub CLI 2.48+. GitHub Enterprise Server não é suportado.

# Confere os pré-requisitos, sem instalar nada
node -v; pnpm -v; git --version; tmux -V; python3 --version
gh --version | head -1

# Baixa o protótipo para ler antes de rodar
git clone https://github.com/deepseek-ai/dsh-superagent-prototype
cd dsh-superagent-prototype

Depois, peça ao seu agente: "Read SETUP.md in this repository and set up dsh-superagent with me." O arquivo manda coletar as respostas, mostrar o plano inteiro e só executar depois da sua confirmação.

Cada Ticket pode ganhar um checkout isolado por um comando de preparação. A documentação cita git worktree como caso típico, e as variáveis abaixo existem de verdade no projeto. O caminho do clone é um exemplo:

# Comando de preparação: cria um worktree por Ticket
# DSH_SUPERAGENT_DIR e DSH_SUPERAGENT_NAME são definidas pelo Executor
git -C "$HOME/src/meu-repo" fetch origin
git -C "$HOME/src/meu-repo" worktree add \
  -b "agent/$DSH_SUPERAGENT_NAME" \
  "$DSH_SUPERAGENT_DIR" origin/main

Com tudo no ar, o teste é um comentário em uma issue, vindo de uma conta da lista de permissão:

@minha-conta-agente adicione um teste para o caso de lista vazia em parseItems

Segundo o setup, o Ticket aparece no painel em cerca de um minuto. Comece com uma tarefa pequena e revise o PR como revisaria o de alguém novo no time.

Vale a Pena Para o Seu Time?

Para produção, hoje, não. É protótipo de pesquisa, o Harness segue em prévia, a documentação fixa uma versão release candidate do dsh, e o suporte a chat cobre só o Feishu. Quem usa Slack ou Teams teria que escrever uma nova Source, e existe um documento de cookbook justamente para isso.

Para estudar, vale muito. Mesmo sem rodar nada, os documentos numerados de docs/ são uma aula sobre decisões que quase todo projeto de agente enfrenta: quem pode pedir trabalho, o que fazer quando uma pessoa muda de ideia no meio, como retomar após reinício e quando interromper alguém. Eles foram escritos para serem lidos em ordem, e a seção de conceitos rejeitados é especialmente boa.

Se você já acompanha a DeepSeek pelo lado dos modelos, como no nosso post sobre o DeepSeek V4.1 Flash e seus preços, este lançamento mostra a outra metade da estratégia. A fórmula que a empresa divulga é "Model + Harness = Agent", e a comunidade já reage: o projeto dsh-Go, que leva o Harness para o celular, apareceu com mais de 5 mil estrelas.

Perspectivas Para os Próximos Meses

A disputa entre agentes de código está saindo do "qual modelo escreve melhor" e indo para "como esse trabalho encaixa no time sem gerar ruído". Router, filas, assinaturas, políticas e painéis são problemas clássicos de sistemas distribuídos, e isso é uma boa notícia para quem já sabe engenharia de software.

O que eu vou acompanhar é simples: alguém independente vai repetir esse teste com código real? Até lá, o valor do dsh-superagent está menos nos números e mais nas ideias, principalmente a de tratar atenção humana como o recurso mais caro do sistema. Essa ideia você consegue aplicar hoje, com qualquer ferramenta.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Aí?

Este artigo cobriu o dsh-superagent da DeepSeek, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue Lá

👉 Seguir @jeffbruchado no X

💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso