Como o DeepSeek SuperAgent transforma um pedido em item de trabalho e isola cada tarefa em uma Git worktree

Fala aí, beleza? A DeepSeek colocou no GitHub um agente que fica de olho num repositório, recebe pedido e vai trabalhando até a entrega cair como pull request 😀

Aqui o foco é um pedaço específico do projeto: o modelo de isolamento, ou seja, como cada pedido vira uma unidade de trabalho com sessão e diretório próprios, tudo a partir do que o repositório oficial documenta

E já calibrando a expectativa: o próprio README chama o projeto de protótipo de pesquisa, que serve só como referência e não é produto oficial da DeepSeek

O que é o DeepSeek SuperAgent (dsh-superagent) e qual é o status do projeto

O dsh-superagent é um agente de código proativo que atende um único repositório GitHub, distribuído como bundle do DeepSeek Harness

Proativo como? Ele não fica esperando você abrir um terminal e mandar prompt: escuta eventos e age quando chega um pedido válido

O código está em deepseek-ai/dsh-superagent-prototype, com a descrição "Towards a More Autonomous Agent System"

A equipe do Harness da DeepSeek publicou o repositório em 31 de outubro de 2026, sob licença MIT, segundo a i-scoop

Sobre o status, o README não enrola: protótipo de pesquisa, apenas referência, não é produto oficial

Ele ainda conta que o código nasceu do trabalho diário da equipe e que boa parte da engenharia foi feita por agentes de código (agente construindo agente, o futuro chegou haha)

De onde vêm os pedidos: GitHub obrigatório, Feishu opcional

O agente tem duas fontes de eventos: o GitHub, que é obrigatória, e o Feishu, que é opcional

Mas não é qualquer mensagem que vira trabalho, beleza? Só pedido de pessoa autorizada entra no fluxo

Quando o pedido nasce no Feishu, duas variáveis guardam a origem: DSH_SUPERAGENT_FEISHU_BOT e DSH_SUPERAGENT_FEISHU_CHAT identificam o bot e o chat que iniciaram o Ticket

Faz sentido existir essa marcação, já que o fluxo descrito no README prevê responder na conversa de onde o pedido saiu

Arquitetura Router-Worker: quem decide e quem executa

Resposta curta: o Router decide, o Worker executa, e cada pedido aprovado vira um Ticket com Worker próprio

Segundo o documento de execução, existe uma sessão Router de longa duração que recebe os eventos, decide o que é trabalho autorizado e despacha Tickets

Essa sessão principal usa dsh-superagent-router, com limite de 5 segundos para shell e para espera de jobs, e com um conjunto menor de ferramentas, voltado a roteamento

E por que separar decisão de execução?

Pensa na recepção de um restaurante: se o recepcionista largar a porta pra ir fritar batata na cozinha, a fila trava inteira

O limite de 5 segundos é exatamente esse guardrail (limite): o Router não consegue se prender a trabalho longo, então continua livre pra receber o próximo evento

O trabalho pesado fica com o Worker, e cada Ticket ganha sua própria sessão Worker isolada

Por que cada tarefa ganha seu próprio diretório (git worktree por Ticket)

Cada Ticket recebe um diretório de trabalho próprio, normalmente preparado como uma git worktree isolada dentro da raiz de execução, conforme o documento de implantação

Que worktree? É um diretório de trabalho extra ligado ao mesmo repositório Git, então dá pra ter várias pastas de trabalho sem clonar tudo de novo a cada tarefa

No dsh-superagent, a implantação mantém um clone local, e é a partir dele que o comando de preparação (prepare) adiciona as worktrees de cada Ticket

O ganho é bem prático: tarefas em paralelo não disputam o mesmo checkout

Se você já tentou rodar dois agentes no mesmo diretório, sabe o caos: um troca de branch, o outro edita arquivo que nem era dele e por aí vai…

Com um diretório por Ticket, o que um Worker mexe fica no canto dele

Como o resultado volta como pull request e quando o Ticket termina

O vínculo entre PR e Ticket é feito pelo nome da branch: um pull request pertence ao Ticket quando o último segmento do caminho da branch é igual ao nome curto do Ticket

O Ticket acompanha o pull request de onde partiu a partir do momento em que o Executor informa esse PR

Também acompanha cada pull request aberto a partir da sua branch, seja informado pelo Executor, seja encontrado pela GitHub Source

E quando acaba? O Ticket fica concluído quando nenhum dos pull requests que ele abriu continua aberto

Isso deixa a automação rastreável: toda entrega tem PR, todo PR aponta pra um Ticket, e dá pra saber se o trabalho ainda está vivo só olhando o estado dos PRs

Trabalho em segundo plano, subagentes e permissões

Se um turno termina com jobs de shell ou subagentes ainda rodando, o Ticket mantém o worker slot e segue em andamento, sem ser reportado como waiting

Quando o job ou subagente termina, ele acorda o Executor no mesmo slot

Se o turno termina sem nada em segundo plano, aí sim o Executor reporta waiting normalmente

Na prática, isso evita que um Ticket com build rodando pareça parado e perca o lugar no meio do caminho

Os subagentes do Worker, inclusive os aninhados, usam o preset padrão do DeepSeek Harness com as permissões do worker

Ou seja, ficam só com as ferramentas de trabalho que o worker pode usar, e perdem essas ferramentas quando o Ticket termina

É o mesmo raciocínio do diretório isolado, só que aplicado a permissão: nenhum subagente ganha mais poder que o Ticket que o criou, e nada sobra ativo depois que a tarefa fecha

Para quem esse modelo de isolamento é útil de estudar

O desenho do DeepSeek SuperAgent é uma boa referência pra alguns perfis bem concretos:

• Quem projeta agentes que atendem vários pedidos em paralelo no mesmo repositório e precisa evitar que um atropele o outro
• Quem já automatiza tarefas de cliente com Claude e quer que cada entrega vire um PR rastreável, ligado a um pedido específico
• Quem avalia controle de permissões de subagentes e quer um exemplo de herança limitada que expira junto com a tarefa
• Quem quer separar a camada que decide (rápida, com poucas ferramentas) da camada que executa (lenta, com ferramentas de trabalho)

Só não confunda as coisas: é referência de arquitetura, não ferramenta pronta pra produção

O próprio README deixa claro que é protótipo, então o valor está em copiar ideias, não em plugar no seu repositório amanhã

DeepSeek na prática com agentes de IA

Se você quer ver modelos DeepSeek sendo usados em outro contexto de desenvolvimento, o vídeo abaixo é um conteúdo complementar do canal: "Engenharia Reversa com IA gastando centavos! (DeepSeek + REA)"

E se ainda está escolhendo qual modelo usar em cada situação, vale entender a diferença entre o DeepSeek R1 e o V3

Próximo passo: ler o README e o fluxo no repositório oficial

Abre o repositório deepseek-ai/dsh-superagent-prototype e segue o caminho na ordem: pedido, Ticket, worktree, PR

Começa pelo README pra ver o fluxo geral, depois vai em docs/003-execution.md pra entender Router, Worker e o ciclo de vida do Ticket, e fecha com docs/006-deployment.md pra ver como as worktrees são preparadas

Uma checagem simples pra saber se pegou a ideia: tenta explicar, sem olhar, por que o Router tem limite de 5 segundos e quando um Ticket é dado como concluído

Se conseguir responder as duas, você já tem o modelo de isolamento na cabeça pra aplicar nos seus próprios agentes =)

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.