DeepSeek abre protótipo do Super-agent: p95 do tempo de tarefa cai de 29,5 para 15,7 minutos

A DeepSeek publicou em código aberto o protótipo do Super-agent, um sistema multiagente que separa em sessões distintas a conversa com as pessoas e a execução do trabalho. Uma sessão roteadora recebe os pedidos e distribui as tarefas, e workers isolados as executam em paralelo, disparados por eventos do GitHub. No teste da própria DeepSeek, o p95 do tempo de execução de uma tarefa caiu de 29,5 para 15,7 minutos, em comparação com uma sessão única. O lançamento foi divulgado pelo analista de notícias de IA @kimmonismus, cujo post no X alcançou cerca de 91,6 mil visualizações.

Roteador de um lado, workers do outro

Quem já montou agentes para desenvolvimento conhece o desenho. Na configuração típica de sessão única, um só agente conversa com o usuário e também conduz o trabalho longo: lê o repositório, edita o código, roda as verificações. Enquanto ele está ocupado, os novos pedidos ou ficam esperando, ou se misturam ao contexto e atrapalham a tarefa em andamento.

No Super-agent, esses papéis são separados. O roteador continua sendo a "cara" do sistema: conversa com as pessoas, entende o que elas querem e repassa o trabalho. A execução fica com os workers. Cada um deles é isolado, ou seja, vive em um ambiente próprio, com contexto próprio, e não interfere nos vizinhos. O gatilho são eventos do GitHub: a criação de uma issue, um comentário, um pull request e sinais semelhantes. O agente não espera um comando no chat; ele reage ao que acontece no repositório.

Essa abordagem tem duas vantagens evidentes. As tarefas paralelas não ficam na mesma fila, e o erro ou a trava de um worker não corrompe o contexto dos demais nem bloqueia o diálogo com a pessoa.

O que a medição da DeepSeek mostrou

O único número público do anúncio é o p95 do tempo de execução. Ele indica o tempo dentro do qual 95% das tarefas terminam, ou seja, mede a "cauda longa", os casos mais lentos. É esse o indicador que importa no trabalho em equipe: a velocidade média diz pouco se uma em cada vinte tarefas fica pendurada por meia hora. Com a sessão única, o p95 foi de 29,5 minutos; com o sistema de roteador e workers, 15,7 minutos. Ou seja, a cauda de latência encolheu quase pela metade, cerca de 47%.

A explicação plausível é o paralelismo. Quando as tarefas chegam em lote, a sessão única as processa uma por vez, e as últimas esperam mais do que todas. Os workers as pegam ao mesmo tempo, e a fila não cresce. Essa explicação é deduzida da descrição da arquitetura, e não de dados publicados do teste.

O que falta no anúncio

Os números pedem leitura cautelosa. Primeiro, o teste foi conduzido pela própria DeepSeek, e ainda não há reproduções independentes. Segundo, o post não mostra a composição da carga: quantas tarefas foram executadas, qual era a complexidade delas e com que frequência chegavam ao mesmo tempo. Com pouco paralelismo, o ganho poderia ser bem mais modesto. Terceiro, o link para a solução de referência no post está cortado, então não está claro com qual configuração de sessão única a comparação foi feita.

Além disso, velocidade é só um eixo. O anúncio não diz nada sobre a qualidade do resultado: a proporção de pull requests aceitos, o número de erros, o consumo de tokens. Vários workers quase certamente consomem mais capacidade de processamento do que uma única sessão, e isso significa que o ganho de velocidade será pago em dinheiro.

O que fazer, para quem desenvolve

O lançamento vale uma olhada de quem constrói agentes em torno do GitHub e esbarra em filas. O protótipo permite ver como a DeepSeek organiza o roteador, o isolamento dos workers e o disparo por eventos, e comparar com o desenho que você já usa. O nome "protótipo" já diz tudo: ainda é cedo para tratá-lo como um produto pronto para produção.

Dá para verificar o ganho declarado com a sua própria carga: pegue um repositório com um fluxo de tarefas típicas, rode-as por um agente único e pelo esquema "roteador mais workers" e compare o p95, além do custo e da proporção de mudanças aceitas. Se a cauda de latência cair de forma comparável, a arquitetura se paga. Se não, os números da DeepSeek continuam sendo um bom resultado no conjunto de tarefas da própria empresa.