DeepSeek abre o código do protótipo Super-agent: p95 de tempo de execução de 15,7 min, contra 29,5

A equipe DeepSeek Harness publicou um artigo sobre a arquitetura do protótipo Super-agent e disponibilizou o código dele no repositório aberto dsh-superagent-prototype. Segundo o resumo feito no X, no experimento o p95 do tempo de execução da tarefa foi de 15,7 minutos no esquema com vários componentes e de 29,5 minutos na solução com uma única sessão. A diferença é de cerca de 47%: as execuções mais longas terminam quase duas vezes mais rápido. O texto do artigo em si não aparece no material a que tivemos acesso, então precisamos nos apoiar no resumo feito pelo autor do post.

O que se sabe a partir do post

A fonte é uma publicação curta no X de @JamesX_ai, com alcance muito pequeno, cerca de 22 visualizações. O autor escreve que sete blogueiros de IA da sua timeline estão comentando a notícia e data a publicação do artigo em 31 de outubro. Da arquitetura, ele chegou a nomear só um elemento: o Router, ou seja, um componente que, pelo nome, distribui o trabalho recebido. A descrição seguinte é cortada no texto, por isso a composição dos demais nós, o número de subagentes e a forma de passar contexto entre eles são desconhecidos.

Disso, pouca coisa pode ser afirmada com segurança. O protótipo foi publicado em código aberto. A equipe o comparou com uma variante em que todo o processo roda em uma única sessão. A comparação usou o p95 do tempo de conclusão. Todo o resto é suposição, e apresentá-la como fato seria um erro.

Por que o p95 importa aqui

A métrica p95 mostra o tempo dentro do qual 95% das execuções terminam. Ela captura a "cauda longa": casos raros, mas penosos, em que o agente fica andando em círculos, relê um contexto que não para de crescer ou espera uma etapa pesada. Em produtos com agentes, esse indicador costuma pesar mais que a média, porque o usuário não lembra da execução típica, e sim da mais demorada.

A sessão de thread único normalmente sofre justamente na cauda. O contexto cresce, cada passo seguinte fica mais caro e as subtarefas independentes são executadas estritamente uma após a outra. Se o Router do protótipo permite dividir o trabalho e rodar partes em paralelo, o ganho no p95 parece plausível. Mas isso é uma hipótese: o resumo não traz dados sobre como o ganho de velocidade é obtido.

O que falta no relato

Para avaliar o resultado, são necessárias informações que o post não fornece:

• quais tarefas foram usadas e quantas eram;
• qual modelo rodou nas duas configurações e se os orçamentos de tokens eram iguais;
• quantas execuções entraram no p95: em uma amostra pequena, a métrica de cauda é muito ruidosa;
• se foi comparada a qualidade do resultado, e não apenas a velocidade;
• quanto a aceleração custou: subagentes paralelos normalmente consomem mais tokens.

O último ponto é decisivo. Uma redução de quase metade no tempo pode ser comprada facilmente com uma conta maior de inferência ou com perda de precisão em tarefas difíceis. Enquanto a fonte não trouxer a taxa de tarefas resolvidas com sucesso nem o consumo de tokens, os 15,7 contra 29,5 minutos dizem apenas sobre velocidade.

O que fazer na prática

O repositório é aberto, então a afirmação pode ser verificada de forma independente. Para quem desenvolve sistemas de agentes, vale olhar como o código estrutura o Router e a transferência de estado, e rodar o protótipo nas próprias tarefas típicas. A comparação deve considerar três eixos ao mesmo tempo: p95 do tempo, taxa de execuções bem-sucedidas e custo em tokens.

Até a publicação do artigo completo e de medições independentes, a notícia deve ser tratada como a proposta de uma arquitetura interessante, e não como um resultado comprovado. O fato de a DeepSeek abrir o código, por si só, é relevante: dá à comunidade a chance de confirmar ou refutar esses números rapidamente.