31 de outubro de 2026, a DeepSeek Harness team publicou no GitHub o dsh-superagent, um agente de código open source sob licença MIT que promete uma coisa concreta: transformar 20 tarefas de código em 20 sessões paralelas, sem que ninguém precise acompanhar cada uma. No teste da própria empresa, com 300 mensagens simuladas e 20 pedidos de trabalho reais, o Super-agent fechou as tarefas em 15,7 minutos no p95. Um agente tradicional de sessão única com subagentes, no mesmo teste, levou 29,5 minutos. São 1,9x mais rápido, e o número mais importante não é esse.
O mais importante é que o dsh-superagent roda na sua máquina, conversa com GitHub por polling a cada 60 segundos, aceita comandos de trabalho no Feishu e te avisa só quando precisa de você. Não é produto. Não tem preço, nem endpoint, nem plano. É um repositório com 111 arquivos de código, 65 de teste, 9 documentos de arquitetura e 15 prompts versionados, publicado em um único commit e já com 12.752 estrelas em cerca de 35 horas. O repositório de base, o DeepSeek Harness, tem 269 mil estrelas.
O que foi lançado, de verdade
O dsh-superagent é um bundle para o DeepSeek Harness, o runtime de agentes open source da empresa (o mesmo que já tem 269 mil estrelas e 32 mil forks no GitHub). Ele é distribuído como plugin, com um processo de setup que o próprio agente de código executa lendo um arquivo SETUP.md. O README é honesto sobre o status: “research prototype for reference only, not an official DeepSeek product”.
| Item | Detalhe |
|---|---|
| Licença | MIT |
| Linguagem | TypeScript, bundle para o DeepSeek Harness |
| Histórico do repositório | 1 commit, criado em 31/10/2026 às 09:32 UTC |
| Estrelas e forks | 12.752 estrelas e 1.318 forks em cerca de 35 horas |
| Tamanho da base | 111 arquivos em src/, 65 em tests/, 216 arquivos no total |
| Documentação | 9 documentos numerados, de 000 (filosofia) a 008 (cookbook para adicionar um Source) |
| Prompts | 15 arquivos Markdown versionados, com histórico e rollback |
| Escopo | 1 repositório do GitHub por vez, Feishu opcional |
| Requer na máquina | Node.js 22.19+ ou 24+, pnpm, git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+ |
O problema que a DeepSeek resolveu: sua atenção é o gargalo
Esse é o argumento central do artigo de design Exploring Super-agent Design, publicado no dia 31 no WeChat oficial da DeepSeek e escrito por Yujia Qiao. Modelos já executam tarefas inteiras sem supervisão, então o gargalo mudou de lugar. Ele está na capacidade humana de acompanhar trabalho em paralelo.
Segundo a equipe, uma pessoa consegue acompanhar ativamente entre 3 e 5 sessões ao mesmo tempo. Todo agente mainstream que existe hoje usa a sessão como unidade básica, com cada sessão isolada da outra. Quando você abre cinco tarefas, você vira o processador: alterna, lembra o contexto de cada uma, sincroniza o estado na mão. O Super-agent tira esse trabalho de rotina da sua cabeça.
A arquitetura se resume em quatro qualidades: contínuo (mesmo agente em IM e em Pull Request), eficiente (tarefas complexas em paralelo), ativo (observa eventos do ambiente e avança sozinho) e persistente (sempre online, se recupera de falha).
A arquitetura Router-Worker
Tudo se apoia em duas camadas. O Router é a sessão principal, de vida longa, que atende a interação humana e despacha trabalho. Os Workers são sessões isoladas que fazem a execução de verdade, cada uma com seu próprio diretório e seu próprio contexto. O Worker nunca fala com você. Ele reporta para o Router, e o Router fala com você.
Na prática, o protótipo usa presets separados: a sessão principal roda com o preset dsh-superagent-router e um conjunto menor de ferramentas, cada Worker roda com dsh-superagent-worker. Um detalhe de engenharia que faz toda a diferença para paralelismo: comandos de shell em foreground são jogados para background depois de 5 segundos. Assim o Worker para de esperar um comando longo e volta a receber mensagens no próximo passo, em vez de travar a fila.
Cada Ticket tem seu slot de worker, e existe um limite de concorrência configurável, com uma vaga extra reservada para quando é uma pessoa que está falando. Ou seja: trabalho novo nunca impede uma pessoa de continuar o que já está em andamento. Trabalho de background tem 30 minutos de prazo por turno, depois disso os jobs são mortos e o Ticket é reportado como esperando.
O modelo de domínio: Trigger, Eval, Ticket e Mandate
O documento de modelo de domínio da equipe é o texto mais bem escrito do repositório e vale a leitura inteira. O trabalho flui assim: um Source (GitHub ou Feishu) produz Triggers imutáveis. Triggers de um mesmo assunto formam uma Thread. A Eval olha um lote de Triggers e decide se aquilo abre trabalho novo. Quando aceita, cria um Ticket com um Mandate imutável, que registra por que o trabalho pode existir e até onde ele pode ir. Um Assignment liga o Ticket a um Executor, e o resultado volta para o Source pelo Channel.
| Conceito | O que faz | Regra que ele carrega |
|---|---|---|
| Source | Fluxo de eventos (GitHub, Feishu) | Drops as próprias mensagens e o que está fora do escopo escutado |
| Trigger | Evento imutável | Unidade de auditoria e de idempotência |
| Thread | Triggers em ordem temporal | No máximo uma Eval ativa por vez |
| Eval | Julgamento em duas camadas | Não guarda estado, só produz Decision |
| Mandate | Permissão do trabalho aceito | Imutável, escopo maior exige Ticket novo |
| Ticket | Unidade de trabalho autorizada | Só a Eval cria, com escopo e canais próprios |
| Assignment | Vínculo do Ticket com um Executor | Tem ciclo de vida próprio, independente do Ticket |
| Subscription | Relação entre Ticket e Thread | Entrega contexto sem conceder autoridade nova |
| Policy | Regras versionadas de avaliação | Mudar a versão descarta as Evals em andamento |
O detalhe mais elegante do modelo é o Mandate: ele é imutável e carrega a versão da Policy que autorizou o trabalho. Se as regras mudam depois, a mudança é registrada e entregue ao Ticket, mas não revoga o Mandate e não cancela trabalho pela metade. Segundo o documento de domínio, o time rejeitou explicitamente a ideia de cancelar Tickets vivos em uma mudança de Policy.
Quem pode pedir trabalho, e quando o agente age sozinho
Essa é a parte que separa um agente de código de um robô de spam no seu repositório. O host aplica listas de permissões, regras e Mandates. Mensagens, comentários e documentos citados são entradas de decisão, nunca podem mudar as permissões. A Eval tem duas camadas: um gate determinístico que decide quem pode pedir o quê, e só depois o assessment do modelo.
Existem três modos de aceitação, definidos na Policy:
| Modo | Efeito |
|---|---|
off |
Nada inferido vira candidato |
observe (padrão) |
Candidatos são avaliados e registrados como “eu teria aceitado”, mas nada acontece |
auto |
Uma avaliação positiva de candidato inferido aceita o trabalho |
O modo observe é o padrão e é a sacada mais importante do produto. Você liga o agente, ele fica analisando o que faria, e nada acontece sem você mandar. Só depois de ler as Decisions registradas você muda para auto. Pedidos explícitos de pessoas autorizadas funcionam em qualquer modo. Isso inverte a ordem normal de um agente autônomo: primeiro você vê a intenção, depois você libera a ação.
A força do pedido também é classificada em três níveis: explicit (pessoa na lista mandando direto), inferred (pessoa fora da lista continuando uma Thread que já tem Ticket, ou bot da lista de bots) e not admitted. Bot nunca para um Ticket, nunca pede trabalho explícito. Revisores automatizados que usam conta comum contam como pessoa para o host, o que é uma brecha de pesquisa que a equipe documenta.
Os números: 15,7 minutos contra 29,5
Esse é o único benchmark publicado, e ele vem com as próprias ressalvas da empresa. O teste simula um stream de chat de grupo e de CI do GitHub. Cada rodada tinha cerca de 300 mensagens, das quais cerca de 20 eram pedidos de trabalho reais. Cada esquema rodou 5 vezes. A DeepSeek descreve o objetivo como medir orquestração e colaboração, não a qualidade de execução de cada tarefa.
| Esquema | p50 | p95 | Observação |
|---|---|---|---|
| Super-agent | 12,4 min | 15,7 min | Referência do teste |
| Sessão única com subagentes, prompt neutro | Não informado | 29,5 min | Chamou subagente 0 vezes em 5 rodadas |
| Super-agent sem encaminhamento direto de evento | Não informado | Não informado | Ablação, ver abaixo |
Traduzindo para o mundo real: 15,7 minutos é o tempo que você espera no pior caso, e 12,4 no caso típico, para um lote de 20 tarefas rodando em paralelo enquanto você faz outra coisa. A comparação contra a sessão única é justa no sentido de que mede o mesmo problema, mas o resultado do baseline é frágil: o prompt neutro daquele esquema simplesmente não acionou subagentes em nenhuma das 5 rodadas. Ou seja, a vantagem de 1,9x é real contra um baseline que não estaba usando o paralelismo. Ela não é a medida da qualidade do código gerado, que não foi medida.
O Router sob pressão
O segundo experimento mede o Router como uma fila de verdade. Quando a taxa de chegada de Triggers sobe de cerca de 1 para cerca de 40 por minuto, três coisas acontecem ao mesmo tempo:
| Métrica do Router | 1 Trigger/min | 40 Triggers/min |
|---|---|---|
| Tamanho médio do lote | 1,0 | 2,8 |
| Latência por requisição | 2,5 s | 3,9 s |
| Tempo de inferência por decisão | 6,4 s | 1,6 s |
Esse resultado é o mais interessante do artigo. A latência por requisição sobe só 1,6 vezes enquanto o volume sobe 40 vezes, e o tempo de inferência por decisão cai de 6,4 para 1,6 segundos. A razão é o batching: quando chegam muitos Triggers juntos, o Router processa em lote e cada decisão individual fica mais barata. Isso é a diferença entre um agente que aguenta rajada e um agente que trava no primeiro pico de CI.
A ablação: o que custa desligar o encaminhamento direto de evento
No mecanismo normal, um Trigger que chega em uma Thread já assinada por um Ticket vai direto para o Worker, sem passar pelo Router. A ablação desliga esse caminho e mede o estrago: decisões do Router sobem cerca de 30% e os tokens lidos de cache sobem cerca de 37%, de 23,23 milhões para 31,77 milhões.
Traduzindo: cada comentário novo em um Pull Request que o agente já está tocando teria que voltar ao Router para ser julgado de novo, e todo o histórico do Worker teria que ser re-lido do cache. É a diferença entre um sistema que escala e um que fatura caro no pior dia.
Comparação com os agentes de GitHub que você já conhece
| Recurso | dsh-superagent | Copilot cloud agent | Claude Code Action | Codex |
|---|---|---|---|---|
| Como o trabalho começa | Menção de pessoa autorizada, ou regra escrita | Issue, chat, API, Slack | Menção, Issue, prompt de workflow | Menção no Slack, tarefas cloud |
| Trabalho não pedido | Sim, com regra e observe por padrão | Sim, via automations | Sim, via eventos de workflow | Não divulgado |
| Sessões paralelas isoladas | Sim, uma por Ticket | Não divulgado | Não divulgado | Não divulgado |
| Onde roda | Sua máquina, num profile do Harness | GitHub, em background | Seu runner do GitHub Actions | Nuvem do Codex |
| Canal de chat | Feishu | Slack, Teams | Não divulgado | Slack |
| Licença do agente | MIT | Não divulgada | MIT | Não divulgada |
| Preço | Grátis, você paga só o modelo | Todos os planos pagos do Copilot | Sua chave de API | ChatGPT Plus ou acima |
A linha que importa aqui é a de preço. O dsh-superagent é o único da lista em que a camada de orquestração é grátis e open source. Você paga apenas as chamadas de modelo do provedor que configurar, e pode apontar para qualquer endpoint compatível. A OpenAI e a Anthropic vendem o agente empacotado com a assinatura. A DeepSeek te dá a arquitetura e deixa a escolha do modelo com você.
O que o protótipo não é
Vale ser preciso, porque o README e os documentos são honestos e o marketing chinês não é:
- Não é o código interno. O README diz que o código publicado foi adaptado para publicação e não é idêntico ao que a equipe usa por dentro nem ao que o artigo de design descreve. Vários designs do artigo são direção futura, não implementação.
- Não mediu qualidade de código. O benchmark é sintético, com ferramentas simuladas. Nenhum número de acerto, nenhum número de PR aceito, nenhuma comparação de defeito.
- Não é multi-repositório. Um Source do GitHub por vez, por desenho. É o que torna autorização e revisão tratáveis, mas também limita.
- Não tem o Watchdog implementado. A sessão Watchdog que vigia os Workers é uma das ideias do artigo e não está no protótipo.
- Não é seguro por padrão. Os Workers rodam comandos sem aprovação, com o usuário do sistema operacional de quem instalou. A documentação diz, em letras garrafais no documento de execução, que os wrappers e diretórios “estabelecem padrões, não uma fronteira de segurança”. Um Worker ainda consegue executar um programa por caminho absoluto. Isole antes de usar.
E tem um detalhe operacional que ninguém vai achar na página de marketing: o auto-merge é desligado por padrão e não pode ser ativado pela conta do agente, porque o GitHub atribui o merge a quem o habilitou. A instrução padrão só permite auto-merge quando o Pull Request foi aberto pelo Ticket, está pronto, tem as aprovações exigidas cobrindo o commit da cabeça, e o total de linhas adicionadas e removidas fica abaixo de 200. Qualquer coisa fora disso, gente mergeia.
Como rodar na sua máquina
O processo de setup foi desenhado para ser feito por um agente de código, não por você. Você pede ao seu coding agent: “leia o SETUP.md deste repositório e configure o dsh-superagent comigo”. Ele faz uma pergunta por vez, mostra o plano completo uma vez, e só executa depois do seu ok. Cada mensagem com menos de 300 palavras, sempre com uma resposta recomendada que você aceita com uma palavra. Segredos nunca são pedidos no chat: as etapas que exigem conta nova ou login de CLI saem como comandos para você rodar no seu terminal.
Os defaults do setup são: profile superagent, separado do profile em que você trabalha, na porta 3082, com diretório de estado em ~/.dsh/state/superagent, prefixo de branch agent/ e modo observe. Uma conta do GitHub dedicada ao agente é obrigatória, e o README é enfático: tudo que o agente escreve aparece naquele nome.
O painel é o outro diferencial. Ele vive na barra lateral do DeepSeek Harness Web, em uma aba chamada Superagent, e tem seis abas: Overview, Source, Trigger, Eval, Execution e Settings. A regra de design do painel é a mesma da filosofia do agente: mostrar só o que precisa de uma pessoa. Estado saudável não ocupa espaço. Cada número que aparece muda uma decisão do supervisor, e as ações destrutivas exigem confirmação.
O que a DeepSeek já roda por dentro
O artigo de design não é teoria. Segundo a Yicai, uma instância interna do Super-agent já roda de forma contínua na empresa, participando de reprodução de bugs, resposta a code review e da própria iteração do DeepSeek Harness. Quando alguém do time reporta um problema de software no chat do grupo, mesmo sem mencionar a IA, ela consegue identificar um defeito potencial, tentar reproduzir em background e achar a correção.
Tudo isso roda sobre um conjunto de mecanismos que valem a lista, mesmo que ainda não estejam todos no código publicado: Inline e Spill, que mantém no contexto o que provavelmente será usado e deixa o resto do lado para leitura sob demanda; Chain of Recall, que usa as referências entre Trigger, Thread e Worker Session para o modelo remontar o histórico; execução especulativa, que age em background antes de você pedir, como conferir conflito de agenda antes de aceitar convite ou tentar reproduzir a falha enquanto o grupo ainda discute; loop ReAct assíncrono, com start e stop em vez de chamada bloqueante, que já existe no DeepSeek Harness mas não vem ligado por padrão; separação de compute, estado e ambiente, com o loop na nuvem e a execução na sua máquina, que dá suporte a BYOM (Bring Your Own Machine); e o Watchdog, uma sessão externa que monitora se os Workers estão realmente avançando.
A própria equipe lista o que ainda não está resolvido: como o Router escala com o tamanho da carga, memória de longo prazo atravessando meses, colaboração humano-máquina depois que a sessão acaba, comunicação A2A entre instâncias de agente, e segurança. Esse último ponto é o mais urgente: quando o agente na nuvem conecta na sua máquina local, prompt injection, vazamento de credencial no dispositivo e risco de permissão entre dispositivos passam a ser problemas de verdade.
O que isso significa
- A disputa saiu do modelo e foi para a orquestração. A OpenAI, a Anthropic e a Google vendem modelos que codificam melhor. A DeepSeek vendeu a arquitetura que faz 20 tarefas rodarem em paralelo sem transformar você em um humano de despacho. O gargalo do próximo ano é atenção, não inteligência.
- O modo observe é a feature mais defensável do projeto. Todo mundo está vendendo agente autônomo que age. O dsh-superagent nasce em modo de não agir, grava o que faria e espera você revisar. Isso inverte a curva de confiança, que é exatamente o que impede um agente de equipe de ser adotado de verdade.
- MIT com 12.752 estrelas em 35 horas é um sinal de carência. Todo mundo quer um Claude Code open source, todo mundo quer rodar no próprio hardware, todo mundo quer BYOM. A comunidade respondendo em um dia é o mesmo tipo de sinal que apareceu no Kimi K3 e no GLM-5.
- Não confunda throughput com qualidade. O p95 de 15,7 minutos é bonito, mas veio de simulação, com ferramentas simuladas, contra um baseline que não acionou subagentes. Ninguém mediu se o PR gerado é bom. Se você for avaliar isso, faça com o repositório de verdade e um conjunto de tarefas seu.
- A segurança é o preço desse paralelismo. Um Worker com acesso total do seu usuário do sistema operacional, rodando em background, com auto-merge desligado porque a própria equipe sabe do risco, não é um detalhe de configuração. Rode num usuário dedicado, num container, com branch protection e revisão humana obrigatória no começo.
- É o melhor material de estudo sobre agentes da semana. Nove documentos, 15 prompts versionados com histórico e rollback, 65 arquivos de teste e um exemplo concreto de como modelar autorização, estado e recuperação. Muita documentação de agent open source é Readme bonito. Esta é engenharia de verdade.
- O super-agent não é um produto que você assina, é um padrão que você implementa. Se você está construindo infraestrutura de agentes para uma equipe, o Router-Worker, o Mandate imutável e o encaminhamento direto de evento são padrões que valem copiar, independentemente de você usar ou não o código da DeepSeek.
Referências
- Repositório do protótipo: github.com/deepseek-ai/dsh-superagent-prototype
- Documentação (9 documentos): github.com/deepseek-ai/dsh-superagent-prototype/tree/main/docs
- Guia de setup: SETUP.md no repositório
- Modelo de domínio: docs/001-domain.md
- Autorização e modos de aceitação: docs/002-authorization.md
- Execução, slots e auto-merge: docs/003-execution.md
- Filosofia do projeto: docs/000-philosophy.md
- DeepSeek Harness (base do runtime): deepseek.com/en/harness
- Artigo de design original (WeChat, 31/10/2026): yicai.com/news/103419784.html
- Cobertura em português dos gráficos e benchmarks: tech.ifeng.com/c/8xg9tbvWnnf
- Cobertura em inglês: marktechpost.com
- Repositório do DeepSeek Harness: github.com/deepseek-ai/deepseek-harness
Perguntas frequentes
O dsh-superagent é um produto da DeepSeek?
Não. O README o define como “research prototype for reference only, not an official DeepSeek product”. Não há página de produto, endpoint, plano nem preço. O código publicado foi adaptado para publicação e não é idêntico à versão interna da empresa nem ao que o artigo de design descreve.
Quanto custa usar o dsh-superagent?
A camada de orquestração é gratuita e open source sob MIT. Você paga apenas o provedor de modelo que configurar no profile do DeepSeek Harness, e o protótipo usa o modelo que estiver configurado ali, sem prender o modelo da DeepSeek. Não existe preço oficial porque não existe produto.
O agente consegue fazer merge de Pull Request sozinho?
Por padrão, não. A conta do agente não pode habilitar auto-merge, porque o GitHub atribui o merge a quem habilitou. A instrução padrão só permite auto-merge em Pull Request aberto pelo próprio Ticket, pronto, com aprovações exigidas cobrindo o commit da cabeça e menos de 200 linhas adicionadas e removidas. Fora desse caso, o merge é manual.
É seguro rodar o protótipo na minha máquina de trabalho?
Não sem isolamento. Os Workers executam comandos sem aprovação, com o usuário do sistema operacional de quem instalou, e a documentação avisa que os wrappers e diretórios são padrões, não fronteiras de segurança. Rode com uma conta do GitHub dedicada, um usuário do sistema operacional dedicado, branch protection e revisão humana obrigatória no começo.
O que é o modo observe e por que importa?
É o modo de aceitação padrão. Ele avalia os candidatos a trabalho proativo e registra a decisão como “teria aceitado”, sem executar nada. Você revisa essas decisões no painel e só depois muda o modo para auto. Pedidos explícitos de pessoas autorizadas funcionam em qualquer modo.
Aviso metodológico: os números de tempo de conclusão, batch, latência e tokens citados neste post vêm do artigo de design da própria DeepSeek e das reportagens que o reproduziram, com os gráficos originais extraídos do texto oficial. São self-report, com carga sintética e ferramentas simuladas, e não medem qualidade de código. As estrelas e forks foram lidos da API do GitHub em 2 de novembro de 2026, às 20h UTC, e os arquivos do repositório foram lidos diretamente no código-fonte publicado.