DeepSeek lança protótipo Super-agent para tratar tarefas de programação em paralelo

Um agente de programação criado para gerir várias tarefas ao mesmo tempo

A equipa Harness da DeepSeek publicou o seu projeto Super-agent a 31 de outubro de 2026, juntamente com um protótipo de investigação, sob licença MIT, que transforma pedidos relativos a um repositório GitHub em sessões de programação separadas. O objetivo é permitir que várias tarefas avancem em simultâneo, enquanto os programadores passam menos tempo a alternar entre conversas e a verificar o progresso.

A experiência preliminar da equipa recorreu a cerca de 300 mensagens simuladas, contendo aproximadamente 20 pedidos de trabalho. O Super-agent concluiu metade das tarefas em 12,4 minutos e 95% em 15,7 minutos. Um sistema de comparação, que usava uma sessão principal com acesso a um agente auxiliar, demorou 29,5 minutos a atingir a marca dos 95%, com instruções neutras.

O repositório público do protótipo da DeepSeek, denominado dsh-superagent-prototype, apresenta um lançamento mais limitado e prático: um agente de programação proativo para um único repositório GitHub, disponibilizado num pacote para o DeepSeek Harness. O agente acompanha o GitHub e, opcionalmente, o Feishu; abre uma tarefa quando uma pessoa autorizada solicita trabalho e responde na conversa original, podendo apresentar um pedido de alteração (pull request) com propostas de alterações ao código.

O README inclui também um aviso claro. O código publicado difere do sistema interno e de partes do ensaio sobre o projeto. Algumas funcionalidades propostas ainda estão por desenvolver, e a DeepSeek descreve esta versão como código de investigação, não como um produto acabado.

A equipa DeepSeek Harness, responsável pela manutenção do protótipo, indica o seu estado no README:

Protótipo de investigação apenas para consulta, não é um produto oficial da DeepSeek.

Para os programadores, o lançamento disponibiliza código que podem analisar e adaptar. A experiência central explora a forma como um agente organiza o trabalho, se lembra de conversas relacionadas e decide quando é necessário intervir.

Porque quer a DeepSeek ocultar a gestão das sessões

O projeto da DeepSeek parte de uma observação feita pela própria equipa: em geral, uma pessoa só consegue acompanhar três a cinco sessões de agentes ativas em simultâneo. Cada sessão tem o seu próprio histórico de conversação, pelo que o programador tem de se lembrar de que tarefa pertence a cada sessão e que instruções recebeu cada agente.

Um harness é o software que envolve um modelo de IA e gere ferramentas, ficheiros, conversas e execução. O modelo raciocina sobre uma tarefa; o harness determina como a tarefa lhe é apresentada e como são executadas as suas ações. O Super-agent transfere para esse software envolvente uma parte maior da responsabilidade de coordenar várias tarefas.

A equipa define quatro objetivos: continuidade entre conversas, execução paralela eficiente, respostas proativas a eventos e funcionamento contínuo com recuperação de falhas. Um exemplo envolve programadores que escolhem um plano numa conversa e, mais tarde, o alteram num comentário no GitHub. O sistema deverá relacionar essas interações e ajustar a mesma tarefa.

Este lançamento surge na sequência da experiência da DeepSeek, a 3 de outubro, com a compatibilidade com extensões do Claude Code no Harness v0.2.1-alpha.1. Essa atualização testou uma ponte para extensões; o Super-agent explora a forma como o próprio harness pode coordenar trabalho em curso. Yujia Qiao é creditado pela implementação do sistema e pela redação do ensaio sobre o projeto; outras 15 pessoas são identificadas como participantes na revisão e discussão.

Um Router coordena, vários Workers executam

O Super-agent divide as responsabilidades entre um Router permanente e vários Workers independentes. O Router recebe interações humanas, mantém informações partilhadas entre tarefas e distribui o trabalho. Evita programar por conta própria, mantendo a função de coordenação disponível enquanto as outras sessões estão ocupadas.

Os Workers tratam das tarefas individuais. Cada um tem o seu próprio contexto de conversação e ferramentas de execução, permitindo que a investigação de um erro, uma resposta a uma revisão de código e uma alteração de funcionalidade avancem em simultâneo. Os Workers comunicam os resultados ao Router, que fala com as pessoas, em vez de deixar várias sessões responderem de forma independente.

A DeepSeek sugere que, muitas vezes, um modelo mais leve pode tratar do encaminhamento, enquanto modelos mais potentes executam o trabalho que determina a qualidade do código. Um Worker pode também criar agentes auxiliares para uma tarefa complexa. O Router gere as relações entre tarefas, em vez de planear cada passo da sua execução.

O protótipo atribui a cada tarefa uma sessão e um diretório próprios, e executa os lançamentos em simultâneo até ao limite configurado. Assim, os operadores controlam quanto trabalho começa ao mesmo tempo. Os históricos de conversação separados reduzem a possibilidade de os detalhes de uma tarefa se sobreporem aos de outra, enquanto o Router mantém uma visão partilhada.

Como as mensagens se transformam em tarefas sem interrupções constantes

As mensagens de chat, os comentários de revisão de código e os resultados de testes automatizados tornam-se eventos capazes de desencadear ações. O projeto mais amplo também contempla correio eletrónico e lembretes de calendário. A integração contínua, ou CI, refere-se a verificações automatizadas que compilam ou testam código após uma alteração, produzindo resultados aos quais um agente pode responder.

A DeepSeek filtra estes eventos em duas etapas. Primeiro, regras convencionais do programa verificam aspetos como a origem, o grupo e os utilizadores autorizados. Depois, um modelo avalia os eventos restantes com base no contexto e em políticas escritas. Isto evita chamadas ao modelo para mensagens rotineiras que não exigem qualquer ação.

Os eventos relacionados são agrupados numa Thread, como os comentários numa determinada proposta de alteração ou num tópico de chat. Quando um Worker assume a tarefa, subscreve essa Thread. Os comentários e resultados de testes posteriores podem ser-lhe enviados diretamente, sem pedir ao Router que os atribua novamente.

As subscrições podem sobrepor-se. Vários Workers que trabalham na mesma proposta de alteração podem receber as mesmas atualizações, o que lhes permite detetar alterações relevantes para o seu trabalho. Um Worker pode também acompanhar várias Threads relacionadas ou devolver um evento ao Router quando este não se enquadra na tarefa que lhe foi atribuída.

Agir cedo, mas falar apenas quando for útil

A DeepSeek afirma que um Super-agent interno já funciona continuamente: reproduz e corrige problemas, responde a revisões de código e ajuda a desenvolver o próprio Harness. Uma regra escrita permite-lhe investigar erros mencionados num chat de grupo, mesmo que ninguém identifique diretamente o agente.

A regra determina que a investigação inicial seja discreta. O agente tenta reproduzir o problema relatado e encontrar uma solução simples, apresentando depois um resultado útil. Num exemplo, os programadores discutiam um problema em que os tis apareciam como formatação de texto rasurado, enquanto o agente já tinha aberto uma proposta de alteração com uma solução sugerida.

A equipa Harness descreve o princípio de funcionamento no README:

exigir o mínimo de atenção humana possível e oferecer o máximo de valor possível.

O protótipo age quando uma pessoa autorizada o solicita ou quando uma regra escrita pela equipa o permite. O seu painel web apresenta as tarefas que requerem atenção humana. Deste modo, a interface centra-se em decisões e resultados úteis, em vez de mostrar cada chamada a uma ferramenta ou pensamento intermédio.

Manter acessíveis o contexto antigo e as instruções novas

O projeto da DeepSeek trata a janela de contexto de um modelo, isto é, a quantidade limitada de informação que consegue considerar de cada vez, como uma cache. O material frequentemente necessário fica à mão; o histórico mais longo ou menos relevante permanece fora da janela até ser pedido.

O ensaio chama Inline e Spill a estas operações. Inline coloca os detalhes úteis diretamente no contexto atual, como mensagens de chat próximas, identificadores ou uma breve pré-visualização. Spill mantém o conteúdo mais extenso noutro local, com uma referência que o modelo pode seguir para consultar mais informação.

O Chain of Recall liga essas referências. Os eventos, as Threads e as sessões dos Workers recebem identificadores únicos, permitindo ao agente passar de uma mensagem atual para a discussão correspondente, daí para um Worker relacionado e depois para outra revisão de código. O objetivo é recuperar uma tarefa antiga entre diferentes canais sem voltar a carregar repetidamente todo o seu histórico.

A DeepSeek aborda também um problema mais imediato de interrupções: um comando longo pode impedir um agente convencional de responder. O mecanismo assíncrono inicia o trabalho em segundo plano e envia o resultado como um novo evento. Os utilizadores podem continuar a dar instruções, incluindo pedir ao agente que mude de direção ou pare.

A equipa diz que este mecanismo está implementado no DeepSeek Harness, mas não é ativado por predefinição. As regras de comunicação também variam consoante o canal: o projeto limita a 100 palavras uma resposta enviada de imediato por mensagens instantâneas, enquanto as propostas de alteração e os documentos incluem explicações mais estruturadas das alterações e respetiva verificação.

Coordenação na nuvem com trabalho num computador local

A DeepSeek separa a computação que executa o agente, o histórico de sessões armazenado e a máquina onde os comandos são executados. O ciclo de funcionamento proposto para o agente decorre em contentores na nuvem, o estado das sessões fica guardado numa base de dados e um serviço local leve executa comandos e devolve resultados.

Esta configuração permite a modalidade Bring Your Own Machine, ou BYOM. Um programador pode ligar um computador que já contenha o repositório, as ferramentas e as alterações ainda não concluídas, em vez de transferir tudo para um novo ambiente remoto. A coordenação na nuvem pode continuar disponível quando esse computador se desliga, enquanto as tarefas que dele dependem aguardam o seu regresso.

Uma sessão Watchdog independente verifica se há falhas ou trabalho bloqueado. O seu objetivo vai além de detetar mensagens de erro: recorre ao julgamento de um modelo para avaliar se os Workers estão a fazer progressos reais ou a afastar-se do objetivo, tentando depois recuperar quando necessário.

A DeepSeek apresenta estes elementos como parte da exploração mais ampla da sua arquitetura. O README avisa que o pacote público e a implementação interna são diferentes, pelo que os programadores devem verificar o código publicado antes de confiar numa determinada funcionalidade do projeto.

O que mediu a experiência

A DeepSeek repetiu cada configuração experimental cinco vezes, comparando o Super-agent com uma versão sem envio direto de eventos e duas configurações de uma única sessão equipada com um agente auxiliar. A carga de trabalho usou mensagens sintéticas e uma ferramenta que simulava tarefas de programação prolongadas. Os intervalos entre mensagens e a duração do trabalho foram reduzidos para um quarto.

A mediana de 12,4 minutos significa que metade das tarefas ficou concluída até esse momento. O percentil 95 de 15,7 minutos significa que 95% foram concluídas dentro desse prazo. Em comparação com o percentil 95 de 29,5 minutos da sessão única com instruções neutras, o Super-agent reduziu esse valor em 13,8 minutos, ou cerca de 47%.

O comportamento de delegação ajuda a explicar o resultado. Com instruções neutras, a sessão única nunca recorreu ao agente auxiliar em nenhuma das cinco execuções. Quando recebeu instruções para dar prioridade à delegação, delegou em quatro execuções e tratou do trabalho por conta própria na quinta. No Super-agent, a separação entre coordenação e execução é uma escolha estrutural.

Os testes avaliaram o escalonamento e a coordenação com execução simulada. A qualidade da programação em situações reais, medições independentes de desempenho e o número de utilizadores ativos não foram divulgados, e a equipa classifica os seus resultados como preliminares. A DeepSeek não indicou uma data para o lançamento de produção.

Uma coordenação mais rápida utiliza mais tokens em cache

A concorrência do Super-agent implicou um maior uso de tokens de entrada em cache. Leu 23,23 milhões de tokens em cache, em comparação com 6,05 milhões e 10,82 milhões nas duas configurações de sessão única. Os tokens são pequenas unidades de texto processadas por um modelo; as leituras em cache reutilizam dados de entrada conservados de pedidos anteriores.

A remoção do envio direto de eventos aumentou as leituras em cache de 23,23 milhões para 31,77 milhões, cerca de 37%, e elevou em aproximadamente 30% o número de decisões do Router. Assim, enviar diretamente as mensagens seguintes ao Worker responsável poupou trabalho de coordenação no sistema paralelo.

O agrupamento por lotes ajudou o Router a gerir um volume maior de tráfego. À medida que a chegada de eventos aumentou de cerca de um para 40 acionamentos por minuto, a dimensão média dos lotes subiu de 1,0 para 2,8 e a duração dos pedidos passou de 2,5 para 3,9 segundos. O tempo de inferência comunicado para cada decisão do Router caiu de 6,4 para 1,6 segundos.

Na prática, há uma troca entre reduzir a espera das pessoas e aumentar o processamento dos modelos em várias sessões separadas. Os valores de tokens não indicam o custo monetário; as equipas que ponderem a implementação terão de ter em conta os preços dos modelos, as definições de concorrência e a carga de trabalho real.

As permissões locais tornam a segurança uma preocupação central

A documentação de execução do protótipo indica que os comandos dos Workers são executados sem aprovação, com a conta do sistema operativo do operador. Após cinco segundos, os comandos de linha de comandos em primeiro plano passam para execução em segundo plano, que pode durar até 30 minutos por turno. Estas definições tornam as permissões da conta do operador uma preocupação concreta na implementação.

Um computador ligado pode conter credenciais, código privado e ficheiros sensíveis. A injeção de instruções, em que conteúdo malicioso tenta desviar um agente através de material que este lê, torna-se especialmente preocupante quando mensagens recebidas ou conteúdo do repositório podem influenciar comandos executados nessa máquina.

A DeepSeek identifica a segurança e a privacidade, o escalonamento do Router, a memória a longo prazo e a comunicação entre instâncias de agentes como áreas ainda por concluir. O README pede aos utilizadores que revejam e adaptem o código, avisando que podem subsistir erros e práticas de engenharia inconsistentes. Grande parte do próprio trabalho de engenharia foi realizada por agentes de programação.

O lançamento suscitou rapidamente atenção, incluindo uma publicação de Leandro von Werra, responsável pela investigação na Hugging Face. A sequência mostra a rapidez com que o protótipo se difundiu:

• 31 de outubro de 2026, às 09:32 UTC: foi criado o repositório GitHub.
• 31 de outubro: a equipa Harness publicou o ensaio sobre o projeto; às 22:10 UTC, o repositório tinha 2.046 estrelas e 172 forks.
• 1 de novembro, às 04:20 UTC: o repositório atingiu 3.433 estrelas.

Para as equipas de engenharia, a decisão imediata é saber se vale a pena analisar e adaptar um sistema experimental de coordenação. A sua atratividade reside na possibilidade de tratar mais tarefas com menos interrupções; a sua utilização exige analisar o código, definir permissões e decidir que ações requerem intervenção humana.

Principais pontos

• A DeepSeek lançou um protótipo de investigação sob licença MIT para tarefas de programação num único repositório GitHub, com integração opcional com o Feishu.
• Um Router trata da coordenação, enquanto Workers separados executam tarefas em simultâneo.
• O sistema interno pode investigar erros relatados ao abrigo de regras escritas, mesmo sem ser identificado diretamente.
• Em testes sintéticos, o tempo mediano de conclusão foi de 12,4 minutos e o percentil 95 de 15,7 minutos, com maior utilização de tokens em cache do que nas alternativas de sessão única.
• Os Workers executam comandos com a conta do operador e sem aprovação, pelo que as permissões e credenciais são preocupações centrais.
• O código público difere do sistema interno e continua a ser um protótipo de investigação, não um produto oficial da DeepSeek.