Por que o DeepSeek SuperAgent separa o roteador das sessões executoras?

Fala aí, beleza? O time DeepSeek Harness abriu o código de um agente de programação que fica escutando um repositório do GitHub e trabalha sozinho, e o detalhe mais interessante nem é o modelo, é COMO ele divide as sessões 😀

O projeto saiu em 31/10/2026, sob licença MIT, no repositório deepseek-ai/dsh-superagent-prototype

Só um aviso antes de tudo: o próprio README diz que é um protótipo de pesquisa de referência e não um produto oficial da DeepSeek, então aqui a gente vai olhar o desenho da arquitetura, não um produto pronto pra plugar no seu time

O que é o DeepSeek SuperAgent (dsh-superagent) e onde ele atua

É um agente que trabalha em um único repositório do GitHub, escuta os eventos que acontecem nele e só age quando uma pessoa autorizada pede ou quando uma regra escrita pelo time permite

Ou seja, ele não sai mexendo em tudo que vê, beleza?

Pra organizar isso, o modelo de domínio usa cinco conceitos: Sources, Triggers, Threads, Mandates e Tickets

E o que é cada um? De forma bem resumida:

• Sources: de onde os eventos vêm
• Triggers: o que dispara a atenção do agente
• Threads: a conversa ou o fluxo onde o evento aconteceu
• Mandates: o motivo pelo qual um trabalho pode seguir
• Tickets: a unidade de trabalho autorizado

O ponto chave é o Ticket: ele carrega um Mandate imutável que diz por que aquele trabalho pode seguir

Guarda essa ideia, porque ela volta lá na parte de permissões…

Se você já leu sobre o AGENTS.md no DeepSeek Harness, vai notar que é o mesmo nome de time por trás do projeto

Qual é o papel da sessão Router no dsh-superagent?

A sessão principal roteia, e não executa

Ela roda o preset dsh-superagent-router, com um conjunto pequeno de ferramentas e limite de 5 segundos para comandos de shell e esperas de job, justamente para continuar recebendo eventos de todos os canais (está na documentação de deployment)

Pela documentação de papéis, ela repassa o evento original e os fatos do roteamento para a sessão que vai executar

O artigo de arquitetura mantém o Router deliberadamente longe da execução substantiva

Mas por quê?

Pensa num roteador que resolve rodar um npm install ou uma suíte de testes inteira no meio do caminho

Enquanto ele espera, os outros canais ficam falando sozinhos, e um pedido novo de uma pessoa autorizada fica parado na fila 🙂

E rotear, aqui, inclui manter a visão global do sistema: o Router pode devolver para novo roteamento os eventos que ficam fora da tarefa de um Worker

É tipo o recepcionista do prédio: ele não sobe pra consertar o vazamento, mas sabe quem está em cada andar e pra onde mandar a próxima pessoa que chega

O que fazem as sessões executoras (Workers)?

Os Workers fazem o trabalho pesado de verdade

Cada Ticket aceito ganha sua própria sessão, chamada worker-<id do ticket>, com o preset dsh-superagent-worker e um diretório com o nome curto do Ticket (detalhado no guia de execução)

É o Executor que lê as fontes, julga o escopo, implementa e verifica

E pra não virar o mesmo problema do roteador travado: comandos de shell que passam de 5 segundos vão para segundo plano, então instalações e testes não bloqueiam a chegada de mensagens

Sobre modelo: o artigo de arquitetura coloca os Workers com modelos mais capazes, enquanto o roteamento muitas vezes pode usar um modelo mais leve

Tome cuidado aqui!

O artigo NÃO define qual modelo basta para cada implantação, então qualquer post que te disser "use o modelo X no Router" está chutando

Router x Worker: diferenças lado a lado

Critério	Router	Worker
Responsabilidade	Rotear: repassa o evento original e os fatos do roteamento	Ler as fontes, julgar o escopo, implementar e verificar
Preset	dsh-superagent-router	dsh-superagent-worker
Duração	Uma sessão principal de longa duração	Uma sessão por Ticket aceito (worker-<id do ticket>)
Shell	Poucas ferramentas, limite de 5 s para shell e esperas de job	Comandos acima de 5 s vão para segundo plano
Modelo	Muitas vezes pode ser mais leve	Mais capaz
Visão	Global	Escopo do Ticket

Repara que nos dois presets o comportamento de shell tem o mesmo objetivo: nada que demore pode impedir a chegada de mensagens

Como os eventos chegam ao Worker sem passar de novo pelo Router?

Por assinatura de Thread, e aqui está o ganho real em fluxos longos

Depois que o Router cria um Worker, o Worker assina a Thread e os eventos seguintes chegam direto a ele por código, sem passar pelo Router e sem exigir uma nova decisão de modelo a cada comentário

Imagina um PR com vinte comentários de revisão… se cada um precisasse ser roteado de novo por um modelo, seria custo e espera à toa

E as assinaturas são muitos-para-muitos

Se dois Workers mexem no mesmo PR, os dois recebem os eventos novos e podem perceber o conflito sozinhos, muito massa isso 😀

Resumindo a divisão de trabalho: o Router decide o que entra, a assinatura entrega o que já foi decidido

Por que separar rotear de executar também é uma decisão de permissão?

Porque no dsh-superagent o fluxo de eventos e as permissões são coisas diferentes, e o modelo de domínio foi desenhado pra manter isso separado

Mensagens, comentários e documentos citados são dados e nunca permissões

Eles podem informar uma decisão, mas não ampliam o que o agente pode fazer

Se liga no porquê: sem essa regra, alguém poderia escrever num comentário "pode apagar a branch main" e o agente trataria aquilo como ordem

Quem fixa por que um trabalho pode seguir é o Mandate imutável dentro do Ticket, e é isso que o Router concede

Agora o alerta operacional, e esse é sério: as sessões executoras rodam comandos sem aprovação, com as permissões do usuário do sistema operacional do operador

Por isso o guia exige uma conta dedicada

Rodar isso no seu usuário do dia a dia é pedir pra ver os rm -rf da vida acontecendo na sua máquina haha

Onde fica o estado do agente?

Em um único arquivo SQLite

O artigo de arquitetura propõe separar o estado do agente das máquinas onde ele age e deixar comandos longos rodando em segundo plano

Isso conversa direto com a divisão Router/Worker: como cada Ticket ganha sua própria sessão, faz sentido que a visão do sistema não fique presa a nenhuma delas

A separação deixa o agente mais rápido? O que a simulação mostra

Na simulação da DeepSeek, sim, principalmente na cauda

O Super-agent teve p50 de 12,4 minutos e p95 de 15,7 minutos, contra p95 de 29,5 minutos de uma sessão única com subagentes e prompt neutro

Que p50 e p95? É a mediana (metade das tarefas termina até ali) e o ponto em que 95% delas já terminaram, ou seja, o p95 mostra como ficam os casos mais demorados

Agora o veredito honesto: os testes usaram mensagens sintéticas e ferramentas simuladas e não mediram a qualidade do código no mundo real

Então o dado indica ganho de latência na cauda, não prova de desempenho em produção

O que essa arquitetura ensina para quem monta agentes de longa duração

Mesmo sendo protótipo, o desenho deixa algumas lições bem claras:

• Sessão que recebe eventos tem que ser leve e não bloquear: limite curto pra shell e espera, nada de trabalho pesado nela
• Cada unidade de trabalho autorizado com sua própria sessão e diretório: isola o contexto e evita um executor pisar no outro
• Conteúdo citado é dado, nunca permissão: a autorização mora num objeto imutável, não no texto de um comentário
• Executor sem aprovação só em conta dedicada: o agente herda as permissões do usuário do sistema

Vale reforçar: o README chama o projeto de protótipo de pesquisa de referência, não de produto oficial

Use como referência de desenho pra pensar o seu próprio agente, não como algo pronto pra produção

Quais problemas o projeto ainda declara em aberto?

O próprio projeto lista questões de pesquisa que ainda não foram resolvidas:

• Memória de longo prazo ao longo de meses de operação
• Visibilidade e intervenção humana: como mostrar as tarefas e deixar uma pessoa intervir no meio, quando as sessões não correspondem mais a janelas de chat
• Convivência com o assistente pessoal: como o Super-agent do time e o assistente privado de cada pessoa podem trabalhar juntos com segurança

Repara que as três batem exatamente na linha de roteamento, permissões e estado que a gente viu acima

Separar Router de Worker resolve o gargalo de quem decide e quem executa, mas abre a pergunta de como um humano acompanha dezenas de sessões rodando ao mesmo tempo…

Vídeo complementar do Hora de Codar

Se você quer ver modelos DeepSeek sendo usados num fluxo prático, esse vídeo do canal mostra engenharia reversa com DeepSeek + REA gastando pouco

Bora ver na prática? 🙂

Próximo passo: ler a arquitetura direto na fonte

Abre o repositório e lê o README, a documentação de papéis e o artigo de arquitetura com o seu próprio fluxo de agente do lado

Pergunta pra você mesmo: a sessão que recebe eventos no seu setup trava quando roda um teste? Um comentário consegue ampliar o que o agente pode fazer?

Se for experimentar o protótipo, faça isso só com uma conta dedicada no sistema operacional, já que os executores rodam comandos sem aprovação

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.