Na noite de 31 de outubro, a equipa do DeepSeek Harness publicou o longo artigo “Exploração de design do Super-agent: rumo a sistemas de agentes mais autónomos”, propondo uma arquitetura de agentes em duas camadas e tornando público no GitHub o protótipo dsh-superagent-prototype. No texto, a equipa deixa escrito que o protótipo serve para validar o caminho técnico e não é um produto oficial da DeepSeek.
O ponto de partida do artigo é uma observação bastante simples: para o modelo concluir sozinho uma tarefa, é preciso cada vez menos intervenção humana, e o que trava a produtividade passou a ser a atenção das pessoas. Segundo a equipa, uma pessoa só consegue normalmente acompanhar de 3 a 5 Sessions ativas em simultâneo; com mais tarefas, tem de alternar manualmente e guardar o contexto de cabeça.
A Session deve ser um detalhe de implementação do sistema, não um fardo cognitivo para o utilizador.
O Router cuida da conversa, o Worker do trabalho
A arquitetura tem duas camadas. A camada Router, sempre ativa, recebe as mensagens das pessoas, mantém o contexto global e distribui as tarefas; não tem ferramentas de execução como o Bash, por isso pode ser movida por um modelo leve. A camada Worker é composta por várias sessões com contextos isolados entre si, com o conjunto completo de ferramentas e o modelo mais potente, cada uma concentrada numa só coisa e a executar em paralelo. Os Workers não respondem diretamente ao utilizador: o estado e os resultados são primeiro comunicados ao Router, que fala para o exterior de forma unificada.
Outras peças do desenho giram em torno de “manter o agente sempre online”:
- Orientado a eventos: mensagens de grupos de conversa, e-mails, lembretes de agenda, comentários de revisão de código e resultados de CI contam todos como Trigger. Regras de programa filtram primeiro a maior parte do ruído, e só o restante vai ao modelo para decidir se se age. Para Threads já atribuídas, os eventos seguintes são entregues diretamente pelo programa ao Worker correspondente, sem passar de novo pelo Router.
- ReAct Loop assíncrono: as chamadas de ferramentas demoradas são divididas em start() e stop(). Uma tarefa em segundo plano devolve Started logo após arrancar, o primeiro plano continua a atender o utilizador, e o resultado regressa à sessão como um novo evento.
- Separação entre computação, estado e ambiente: o Agent Loop e o estado ficam na nuvem, o ambiente de execução pode permanecer na máquina do utilizador, onde corre apenas um daemon leve, com suporte a trazer a própria máquina (BYOM).
- Watchdog: uma sessão independente acorda periodicamente e, além de verificar se os processos estão vivos, pede ao modelo que avalie se cada Worker tem progresso substancial e se a direção não se desviou.
O texto dá ainda o exemplo da “execução especulativa”: se alguém no grupo reporta um bug, o agente tenta primeiro reproduzi-lo e corrigi-lo em segundo plano, e só fala depois de o resolver; se não conseguir, não incomoda ninguém.
Os números vêm apenas de carga sintética
A equipa fez uma experiência comparativa: cada ronda tinha cerca de 300 mensagens, das quais cerca de 20 eram pedidos de trabalho e as restantes conversa de circunstância e ruído; cada opção foi repetida 5 vezes. O tempo de conclusão das tarefas do Super-agent teve p50 de 12,4 minutos e p95 de 15,7 minutos; o grupo de controlo “sessão única com Subagent” registou, com prompt neutro, um p95 de 29,5 minutos. Sem o mecanismo de entrega direta de eventos, o número de decisões do Router aumentou cerca de 30% e os tokens lidos da cache cerca de 37%.
No teste de stress do Router, os Triggers subiram de cerca de 1 para cerca de 40 por minuto, o tamanho médio do lote passou de 1,0 para 2,8, o tempo por pedido aumentou de 2,5 para 3,9 segundos, enquanto o tempo de inferência repartido por cada decisão desceu de 6,4 para 1,6 segundos.
As limitações também são escritas sem rodeios: a experiência usou carga sintética e um ambiente simplificado, mede apenas o escalonamento e a colaboração, não a qualidade com que cada tarefa individual é feita; o consumo de tokens do Super-agent é superior ao da solução de sessão única, mas o total não foi divulgado. O protótipo de código aberto destina-se, por agora, a um único repositório do GitHub; o funcionamento entre dispositivos, a presença permanente na nuvem e o Watchdog não estão totalmente implementados.
Do dsh ao Super-agent
Juntando a cronologia, na frente dos agentes a DeepSeek começou por lançar o framework e só depois as ideias de escalonamento. Por volta de agosto deste ano, abriu o código do framework de agentes DeepSeek Harness (nome na linha de comandos: dsh) sob licença MIT, com sistema de ficheiros, Shell, adaptação de modelos, interface Web e subagentes feitos como plugins substituíveis; nos meses seguintes, modelos como o V4.1 Flash foram entrando no ar e ferramentas de programação de terceiros passaram também a usá-lo como modelo principal.
O novo artigo sobe mais um nível e discute como uma instância de agente pode acompanhar dezenas de coisas ao mesmo tempo. A equipa revela que o mecanismo de tarefas assíncronas descrito no texto já foi incorporado no DeepSeek Harness, apenas desativado por defeito; instâncias internas baseadas na mesma ideia têm estado em funcionamento, usadas para reproduzir e corrigir problemas, responder a revisões de código e também para iterar sobre o próprio Harness.
Entre os problemas por resolver que a equipa enumera estão a forma de escalar a camada Router com o volume de tarefas, a memória de longo prazo ao longo de meses e a comunicação entre várias instâncias de agentes. O ponto da segurança é o mais concreto: se o Agent Loop na nuvem sofrer uma injeção de prompt, os dispositivos locais ligados podem ser controlados, e as credenciais colocadas no contexto do modelo podem vazar durante a execução normal. Como prevenir estes riscos, o texto não apresenta uma solução completa.
Fontes: artigo técnico da equipa do DeepSeek Harness e descrição do repositório dsh-superagent-prototype, ITHome, CocoLoop, Ifeng Tech; os tempos da experiência e os dados do teste de stress seguem os resultados de carga sintética divulgados pela equipa.