Explorar o design do Super-agent: rumo a um sistema de agentes mais autônomo

1. Super-agent

No último ano, os agentes de tarefa única — os coding agents à frente — provaram que modelos usam ferramentas para resolver problemas complexos, com cada vez menos monitoramento humano contínuo e intervenção passo a passo. Ao mesmo tempo, a capacidade de coordenar vários agentes cresce, tornando viável organizar e despachar entre sessões. Conforme a participação humana na execução cai, o papel da pessoa sobe para decisões e aceite de nível mais alto.

Esse salto de capacidade gerou novas formas de uso. Recentemente os agentes pessoais floresceram: plugados direto em mensagens, agenda, e-mail e plataformas de trabalho, observam o fluxo de informações e ajudam a despachar assuntos. Esse modo permanentemente online e orientado a eventos não se limita ao cenário pessoal — o assistente pessoal é só uma classe de aplicação; em cenários comerciais como desenvolvimento de software vale igualmente.

Os designs dominantes, porém, mal sustentam esse modo em escala de multitarefa e colaboração. O trabalho do agente ainda se organiza em torno da sessão única; sessões são independentes entre si. Quem puxa várias frentes em paralelo precisa trocar à mão e decorar o contexto de cada uma — e, pela observação da equipe, uma pessoa acompanha na prática de 3 a 5 sessões ativas. Nesse design, o teto da tarefa única é a capacidade do modelo; o da multitarefa, a atenção humana.

Estender um agente local monossessão com CLI, MCP ou conectores externos o faz receber mensagens, mas continua preso ao bloqueio síncrono da sessão única, ao contexto multitarefa embolado e à parada total quando o aparelho sai do ar — com muita manutenção manual.

Para romper esses limites é preciso desatar o agente do vínculo com a sessão manual única, fazendo dele uma entidade contínua que mantém contexto entre sessões e avança várias tarefas complexas em paralelo sem se atropelar. A equipe chama essa forma — e sua arquitetura — de Super-agent.

Na instância interna sobre DeepSeek Harness, uma mesma tarefa de desenvolvimento avança sem costura entre mensageria e GitHub; a instância também vigia os feedbacks dos grupos públicos e, sem ser mencionada, localiza a causa raiz e abre um pull request de correção.

Concretamente, o Super-agent tem quatro propriedades fundadoras:

• Contínuo: o usuário interage nas superfícies de sempre — chats, comentários no GitHub — e sente um único agente sempre presente, sem se perguntar «será que o dado Y estava no contexto da sessão X?». Pode propor o plano A no chat e trocar para o B num comentário de PR, que o agente entende e ajusta o rumbo.
• Eficiente: interação responsiva enquanto várias tarefas complexas correm em paralelo com qualidade; aceita a próxima instrução sem esperar a anterior acabar.
• Proativo: não espera instrução por instrução; observa os eventos do ambiente e adianta o que vale a pena, quieto quando não precisa intervir.
• Persistente: sempre online, plugado nos ambientes reais de trabalho, com auto-recuperação de anomalias na corrida longa.

Um único ReAct loop não sustenta as quatro de uma vez; é preciso arquitetura por baixo. Restrições parecidas levam a escolhas parecidas: assistente pessoal ou agente comercial de desenvolvimento, um sistema permanentemente online e concorrente sobre eventos converge em alicerces próximos. E muitos dos problemas aqui parecem muito com os clássicos dos sistemas distribuídos — o pensamento sistêmico clássico aplica direto.

A implementação tem variantes, mas cinco módulos formam o esqueleto: a arquitetura de dois níveis (§2) para continuidade e eficiência; a orientação a eventos (§3) para a proatividade; a interação voltada ao humano (§4) contínua e eficiente na própria interface; a separação de computação, estado e ambiente (§5) mais um Watchdog (§6) para persistência entre dispositivos e auto-cura.

2. A arquitetura de dois níveis

Para ter ao mesmo tempo interação contínua entre canais e concorrência multitarefa eficiente, a organização das sessões enfrenta um trade-off radical entre continuidade e vazão.

Tudo numa sessão: contexto no máximo de continuidade, mas a velocidade serial do ReAct loop põe teto — tempos longos, vazão baixa, e os detalhes intermediários de várias tarefas misturados pioram a qualidade.

Uma sessão nova por evento: concorrência no máximo, mas se as tarefas não são totalmente independentes, a falta de contexto global esfarela os resultados, e várias sessões respondendo cada uma por si semeiam caos.

Para equilibrar, separa-se «manter a continuidade global» e «executar em alta concorrência» em dois níveis: um nível Router residente (2.1) que recebe toda interação humana e a coordenação global, e um nível Worker de contexto isolado (2.2) que executa tarefas em concorrência.

Com essa divisão, o sistema assume embaixo a gestão de contexto e a execução concorrente, esmaecendo a sessão diante do usuário, que tem sempre à frente um só Super-agent. Visto assim, fazer o usuário gerenciar sessões à mão é em grande parte inércia herdada da API do LLM; sessão é detalhe de implementação, não carga cognitiva.

«Dois níveis» é divisão lógica de responsabilidades; nenhum nível se reduz a uma sessão única e cada um pode ter estrutura interna própria. Seguem os níveis.

2.1 O nível Router

O Router é o nível residente de roteamento global que recebe toda interação humana em todos os pontos de entrada. Toda informação e decisão entre tarefas converge aqui: ponto de sequência global, ponto de coordenação e memória. Para não virar gargalo, o Router não executa tarefas — só interação e distribuição; pode até dispensar a ferramenta Bash.

Um despachante central sobre executores lembra na superfície um Agent Team, mas o foco difere. O Agent Team decompõe passos dentro de uma tarefa complexa; as subetapas andam acopladas, o lead precisa entender o detalhe, planejar e coordenar sem trégua — carga de raciocínio pesada. No Super-agent, o Router só trata dos vínculos de alto nível entre tarefas e da distribuição. Inversamente, restringir por prompt a sessão principal de um Agent Team a nunca executar — só interface externa e distribuição — também produz esta arquitetura. Na prática, as tarefas do Router costumam ser menos complexas do que se imagina, e um modelo leve equilibra velocidade e qualidade.

Nem lá dentro o Router precisa ser uma sessão única; partes da lógica talvez nem chamem LLM. A equipe escolheu o núcleo mais direto — uma sessão LLM residente — e achou que ela empaca bem menos do que parece: os eventos (os Trigger da §3) chegados durante uma rodada de inferência acumulam e são processados juntos na seguinte, formando o batching, de sobrecusto pequeno:

• Com o fluxo calmo, os Trigger entram um a um e a latência unitária fica baixa.
• Quando os eventos se avolumam e a sessão enfileira, os Trigger acumulados se fundem sozinhos e são injetados juntos na próxima chamada. Os passos do Router são tipicamente entrada longa, saída curta; fundir numa chamada paraleliza o prefill, e a latência por requisição cresce bem mais devagar que o lote. Numa faixa, quanto maior o represamento, menor o tempo de inferência por decisão — limitado pelo comprimento do contexto e por quantos Trigger o modelo processa com exatidão numa rodada.

A §7.2 quantifica esse batching. Somados assinatura/pass-through e cadeia de resgate (3.2, 3.3), uma única sessão Router residente dá conta na escala atual da equipe.

Além disso, o Router pode se estruturar em filtros de várias camadas ou sharding horizontal em várias sessões. O design interno do Router vira ele mesmo o trade-off continuidade/vazão: shards mais finos, mais concorrência, menos continuidade de memória entre fragmentos. Até resolver a memória global, o trade-off permanece.

2.2 O nível Worker

Os Worker são as sessões de execução: contexto mutuamente isolado, ferramentas completas, foco numa única tarefa. Como decidem resultado e qualidade do código, costumam querer o modelo mais capaz.

Os Worker não falam com humanos; raciocínio e chamadas de ferramenta não vazam para os canais externos. Reportam ao Router, que responde ao usuário de forma unificada — concorrência e qualidade sem o caos de respostas múltiplas.

Em multitarefa, os Worker avançam independentes e em geral não se falam. Conflitos nascem sobretudo em ambientes compartilhados, o mesmo PR por exemplo; enquanto ambos assinarem o mesmo Thread (3.2), recebem os mesmos eventos e podem descobrir e resolver o conflito sozinhos, com o Router retransmitindo as raras coordenações cruzadas.

Como o Router, um Worker pode não ser uma sessão única por dentro: numa tarefa complexa pode gerar subagentes ou ser ele mesmo um Agent Team, com transparência para cima. Serve à colaboração de código — reproduções, reviews e features em paralelo sem se bloquear — e ao assistente pessoal: uma só janela de chat que, com vários assuntos, mantém a continuidade na frente enquanto atrás atribui um Worker por assunto, avançando em paralelo e redigindo respostas.

3. Orientação a eventos

A proatividade começa mudando o que dirige o sistema. A entrada principal deixa de ser prompts digitados pelo humano em sessão e passa a ser eventos semiestruturados do ambiente. Mensagens de grupo, lembretes de e-mail e agenda, comentários de review, resultados de CI: tudo isso é Trigger. Ouvindo e respondendo Trigger, o agente não executa mais uma vez por ordem como no modo monossessão.

Ao longo do ciclo de vida de um evento, quatro perguntas progressivas: filtrar o ruído com política de dois níveis programa+modelo (3.1); rotear até os worker por assinatura e pass-through (3.2); injetar e resgatar contexto em alta densidade com Inline & Spill e cadeia de resgate (3.3); e adiantar-se com a execução especulativa (3.4).

3.1 Filtragem de eventos

Plugados em chats e plataformas reais, os fluxos são vistosamente «ruído alto, taxa de disparo baixa»: a imensa maioria das mensagens não exige o agente. Julgar cada evento com chamada fresca ao modelo arruína latência e custo. Do Fast Path / Slow Path dos sistemas: a inferência LLM é uma Slow Path flexível mas cara; fixar em código determinista os julgamentos claros, estáveis e frequentes forma uma Fast Path barata.

Primeiro passo após a entrada: filtrar — peneirar o ruído com política determinista antes de qualquer chamada, passando ao modelo só os candidatos que exigem semântica. Filtro de dois níveis:

• Política de programa (Fast Path): admissão determinista em código — origem, perímetro de grupo, allowlists de usuários/bots; por origem, p. ex., «responder só a pedidos explícitos», «candidato» ou «ignorar» — a maior parte do irrelevante cai antes do modelo.
• Política semântica (Slow Path): os candidatos aprovados vão ao LLM, que decide agir ou não conforme políticas escritas em prompt e contexto. A camada semântica é também o ponto de extensão em linguagem natural: ligar ou adicionar política é editar um prompt.

3.2 Roteamento de eventos

O Router sustenta a continuidade entre canais, mas se cada evento seguinte de tarefa já atribuída ainda passasse por ele, o nó global carregaria pesado e a latência subiria. Fast/Slow vale também para o roteamento: o Router só cuida do cold start de tarefas novas e da coordenação entre tarefas; os eventos seguintes de dono conhecido o programa manda direto para a sessão worker.

Nos fluxos reais, os eventos consecutivos sob um mesmo PR, um mesmo tópico de mensageria ou um mesmo fio de e-mail formam um fluxo — um Thread. Criada uma sessão worker para o evento inicial de um Thread, o worker assina o Thread diretamente, e o roteamento se bifurca:

• Assinado (Fast Path): os eventos seguintes do mesmo Thread vão direto ao worker assinante, sem reenvio pelo Router. Se um evento excede o escopo da tarefa, o worker pode cancelar a assinatura ou devolver ao Router.
• Não assinado (Slow Path): o Router continua observando tudo para a visão global, mas só julga e distribui o ainda sem assinatura.

A assinatura Thread-worker é muitos-para-muitos: um worker segue vários Threads relacionados; um Thread, vários worker. Quando vários worker se cruzam num mesmo ambiente, os novos eventos chegam a todos os assinantes, que ficam sabendo das ações alheias e resolvem conflitos sem mensagens ponto a ponto. Na saída, os worker elevam as conclusões ao Router, que responde unificado e atualiza a memória global.

3.3 Organização do contexto

Evento filtrado e roteado, resta quanto injetar na janela. A entrada passou de prompts humanos limitados a um fluxo infindável de eventos semiestruturados: o desenho da injeção e das chamadas pesa mais. Injetar demais enche a janela e dilui a atenção; de menos, multiplica idas e vindas de leitura. Desperdiçar a janela de contexto é desperdiçar a inteligência do modelo.

Gerencie-se a janela finita como cache. Da otimização de compiladores e dos sistemas, duas operações bastam: Inline põe na janela o que logo fará falta, poupando idas de ferramenta; Spill deixa fora da janela a informação completa acima do orçamento ou raramente usada, mantendo dentro só referência ou resumo para ler à demanda.

Com a localidade clássica:

1. Começar ao mínimo: só o ID do objeto e um resumo do conteúdo.
2. Inline por localidade: primeiro os IDs dos objetos estreitamente ligados, depois o contíguo no tempo e no espaço — os primeiros 50 caracteres, as mensagens vizinhas e a respondida, os comentários vizinhos da thread de review.
3. Spill acima do teto: teto pequeno de comprimento para o que não se inlina inteiro; o excedente sai da janela com um ponto de retomada que o modelo lerá com ferramenta.

Com tantos eventos passando direto aos worker e o sistema acumulando histórico na corrida longa, o Router não pode trazer todo o histórico de todas as tarefas para a sua janela, mas precisa recuperar o contexto quando o usuário retoma uma tarefa velha por outro canal. Aplicar Inline & Spill uniformemente aos objetos do sistema dá o resgate multihop à demanda — a cadeia de resgate —, que atenua a perda de informações distantes do Router.

Concretamente: Trigger, Thread e sessões worker ganham IDs únicos, e as injeções inlinam os IDs dos objetos estreitamente ligados, formando embaixo um grafo de referências. Como todo objeto resgatado por ferramenta segue ele próprio Inline & Spill, seu resultado traz resumo e ID do salto seguinte: da mensagem atual lê-se o Thread, do Thread segue-se até a sessão worker ligada, e daí ao outro Thread de review.

3.4 Adiantar-se

Com a execução especulativa dos sistemas, o agente pode tentar em segundo plano antes de saber se o resultado servirá: computação extra atrás dos panos para cortar espera e intervenção humanas. O que vale se entrega; o que não vale, descarta-se.

Assistente pessoal: chegado um convite ou um to-do, o agente confere em segundo plano conflitos de agenda, reúne antecedentes e prepara o rascunho de resposta — o usuário dá uma olhada e envia. Engenharia: no grupo interno de usuários do DeepSeek Harness roda a política «reproduzir e corrigir em silêncio» — quando alguém relata um problema ou discute uma mudança, o agente reproduz e procura a correção em segundo plano; entrega só com problema confirmado e correção simples; senão, cala do começo ao fim.

4. Interação voltada ao humano

O dois níveis garante continuidade no plano do contexto; para sê-lo também na experiência viva restam dois problemas: tirar o bloqueio de operações longas com um ReAct loop assíncrono (4.1) e adequar a saída à largura de banda e aos hábitos de cada canal (4.2).

4.1 Interação full-duplex

No ReAct clássico, uma chamada síncrona run() bloqueia o loop até a ferramenta devolver, e a sessão não responde a nada novo nesse meio-tempo. Tirar o bloqueio é passar do half-duplex pergunta-resposta ao full duplex.

A equipe tornou assíncronos os comandos e subtarefas longas com start() e stop() — o ReAct loop assíncrono. start() devolve na hora «Started» e o loop não espera; ao terminar a ferramenta, o sistema deposita o resultado na sessão como evento novo; e o modelo pode stop() comandos que se eternizam.

Diálogo em primeiro plano e execução ao fundo se desacoplam: o agente responde enquanto as tarefas longas correm. A entrada nova é tratada logo após o passo de inferência corrente, nunca atrás de uma ferramenta pendente. Implementado no DeepSeek Harness, ainda sem ativar por padrão.

4.2 Interação multicanal

Os canais diferem em densidade e hábitos; a saída deve corresponder. Transplantar a interação de terminal único para o grupo — raciocínio prolixo e rajadas de chamadas no cru — sobrecarrega a colaboração.

O dois níveis já isola boa parte: raciocínio e chamadas ficam dentro dos worker; só o Router fala para fora. Por cima, o sistema se conecta aos ambientes reais e calibra normas por canal via prompt:

• Mensageiros instantâneos: trato leve e pouco intrusivo — como o colega que só avisa para decidir ou aceitar, pergunta direto e responde curto. Regra dura simples e validada: no máximo 100 palavras por resposta.
• GitHub, e-mail, documentos (canais assíncronos): entregas estruturadas e densas — PRs escritos conforme a norma do projeto com contexto, descrição da mudança e verificação; para o assistente, rascunhos de e-mail e resumos estruturados.

5. Separar computação, estado e ambiente

Os agentes locais atam por padrão a um só aparelho a computação que empurra o loop, o estado de sessão a persistir, e o ambiente de execução — repositórios e toolchains. O aparelho dorme ou cai, o agente para, e os ambientes das outras máquinas ficam inalcançáveis. Para a permanência e o acesso flexível, toma-se a separação computação-armazenamento em dois passos: primeiro separar a computação do loop do estado persistente, libertando o agente do ciclo de vida da máquina única (5.1); depois separar o loop na nuvem do ambiente pesado, deixando os ambientes reais no lugar com acesso entre dispositivos (5.2).

5.1 Computação e estado

A computação do loop pode não ter estado; o que persiste é o estado de sessão. Primeira separação: computação em contêineres elásticos na nuvem sem estado, sessões em banco de dados. Os contêineres escalam, reiniciam e são trocados; o armazenamento persistente garante a continuidade — o agente escapa do ciclo de vida de uma máquina.

5.2 Computação e ambiente de execução

Loop e estado na nuvem, resta o acesso aos ambientes. Boa parte do contexto de que o modelo precisa chega por ferramentas de repositórios, arquivos locais e serviços — em sentido amplo, o próprio ambiente é contexto.

Dois caminhos comuns: sandbox na nuvem que baixa o código e tenta reconstruir e sincronizar o ambiente — caro e falho, porque ambientes reais carregam mudanças sem commit, credenciais privadas, dependências de intranet e hardware ou toolchains específicas; ou pedir ao usuário que abandone o local pela nuvem — migração cara demais para muitos.

Se o que não se copia é o próprio ambiente, que não suba para a nuvem. Segunda separação: o loop roda na nuvem, o ambiente pesado fica onde está, e no aparelho vive só um daemon leve, sem estado de sessão, que executa comandos e devolve resultados — o ambiente fora da nuvem, lido pelo agente à demanda.

Isso espelha o «desacoplar o cérebro das mãos» da Anthropic: harness sem estado, logs de sessão lá fora, ambientes plugados por interface unificada. Difere o cenário — aquele texto descreve serviços gerenciados, sandbox sob demanda e recursos no VPC do cliente; aqui o alvo primeiro são as máquinas pessoais do dia a dia, talvez intermitentemente online, com mudanças sem commit e credenciais locais. Daí o suporte ao BYOM (Bring Your Own Machine), além de máquinas gerenciadas e computação sob demanda.

O agente deixa de estar preso a uma máquina: escolhe o aparelho de execução por tarefa, manda executar onde preciso e de lá tira o contexto. Suporta até aparelhos intermitentes: quando a máquina pessoal volta, o agente na nuvem dispara e completa o que cabia rodar ali.

6. Watchdog

À separação soma-se a cura: um sistema de longa duração difícilmente se sustenta só com a lógica interna; é preciso um circuito de controle externo — o Control Loop.

E em sistemas de agentes sondas de processo e scripts de monitor não bastam: muitas anomalias não são crashes, mas loops inúteis ou desvios do modelo. Um agente de longa duração vigia a vida da infraestrutura e o avanço das tarefas.

Fora do sistema principal roda uma Watchdog Session independente, puxada por mensagens cronometradas. Trata falhas de infraestrutura — erros de API, recuperações falhas — e faz o modelo julgar se cada worker progride de fato e se o rumo segue fiel ao objetivo; intervém e repara ao detectar anomalia, e reexamina os falhos passageiros até passarem. Sendo ela própria uma sessão de agente com ferramentas completas, dá para perguntar a ela em linguagem natural por que algo quebrou, ou mandá-la retocar ao vivo o sistema principal — prompts somados ou tirados, regras de disparo ajustadas.

7. Experimentos preliminares

Para avaliar o miolo do escalonamento e do roteamento, duas camadas de experimentos: ponta a ponta comparando dois níveis com assinatura/pass-through contra esquemas monossessão (7.1); e um estresse à parte do batching do Router (7.2). Cargas sintéticas e ambientes simplificados: resultados preliminares.

7.1 Ablação

Fluxos de chat de grupo e CI do GitHub dirigem quatro esquemas: ~300 mensagens por rodada, ~20 pedidos de trabalho, o resto prosa, follow-ups, cancelamentos e CI. O trabalho de código é trocado por uma ferramenta que só gasta tempo: mede-se escalonamento e coordenação, não a execução da tarefa única. Cinco rodadas por esquema.

Os quatro: o Super-agent; o Super-agent sem pass-through; e a sessão única + ferramenta subagent sob dois prompts. Neutro: "Use a subagent for a piece of work when appropriate...". Delegar-primeiro: "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..."

Tempos de término: p50 e p95 do Super-agent em 12,4 e 15,7 minutos, bem à frente da monossessão com subagent. Esta é muito sensível ao prompt: a sessão principal costuma executar ela mesma — tempos longos e instáveis. Com o neutro, nenhuma chamada ao subagent em 5 rodadas: tudo na principal, interrompido a toda hora, p95 em 29,5 minutos. Com delegar-primeiro delega em 4 de 5 — melhor, ainda abaixo do Super-agent — e na quinta julga o trabalho «pequeno», faz sozinha e forma a cauda roxa do gráfico. Em vez de deixar para a engenharia de prompt e para o tino do modelo decidir dividir ou não, o dois níveis resolve estruturalmente: o Router nunca executa; os worker só recebem as mensagens do Thread assinado.

Custos: manter várias sessões encarece os tokens de leitura em cache por rodada frente à monossessão — mais tokens por tempos mais curtos e estáveis. Sem o pass-through, os tempos ficam quase iguais, mas as decisões do Router sobem ~30% e os tokens de cache vão de 23,23M para 31,77M (+37%). Sob essa carga o pass-through não melhora qualidade nem velocidade: poupa ao Router tokens e inferência de monta.

7.2 Batching do Router

Para sondar o teto da sessão Router residente, estresse dedicado: modelo real no Router, mock nos worker, subindo a taxa de chegada dos Trigger a decidir de ~1 para ~40 por minuto, observando lote médio, latência por requisição e inferência por decisão.

De ~1 para ~40 por minuto, o lote médio vai de 1,0 a 2,8 enquanto a latência só sobe de 2,5s para 3,9s — mais devagar que o lote —, e a inferência por decisão desce de 6,4s para 1,6s. Diante de rajadas, o Router eleva o throughput efetivo fundindo o represado. Explica também por que em 7.1, sem pass-through e com o pico de carga no Router, o teto nunca foi tocado — logo, sem sharding precoce que sacrifique a continuidade do contexto global.

8. Questões abertas

As §2–6 formam a base; a §7 validou escalonamento e roteamento sob carga. O sistema segue simples graças a simplificações deliberadas. Além delas ficam abertas: escalar o dois níveis (8.1), colaborar depois das sessões (8.2), fronteiras de contexto e A2A (8.3), segurança e privacidade (8.4).

8.1 Escalar o dois níveis

«Um Router residente + pass-through + worker sem comunicação direta» cobre a maior parte do dia a dia a custo pequeno. Passado o umbral não há doutrina para o interior: quando shardar e com que grão; quando dar voz direta aos worker e com que topologia. O co-design sistema-modelo é outra veia: treinar sob medida a discriminação de eventos, o despacho em lote e o resgate de contexto do Router pode alçar throughput e qualidade de decisão.

E o Router residente com cadeia de resgate resolve sobretudo o resgatar do próximo. A meses de distância, a memória de longo prazo vira o gargalo da escalabilidade.

8.2 Colaborar depois das sessões

Escondida a gestão multissessão, a sessão deixou de ser a primeira questão de produto; mas quando as sessões de execução já não correspondem às conversas visíveis, como apresentar tarefas e oferecer interação e gestão naturais é a pergunta nova. A centralidade da janela de chat é em parte dependência de caminho. A interação pode migrar para superfícies especializadas — como nos exemplos do texto, o Super-agent trabalhando direto em issues e pull requests. A sessão pode ficar por hábito, mas uma conversa vista não equivale lá embaixo a uma única sessão.

E o texto tratou do humano no início e no aceite; na transição, muitas tarefas ainda pedem participação no meio — entrar, assumir ou colaborar ao vivo com a execução ao fundo: tudo a explorar. A forma final de gestão e interação será provavelmente muito sob medida do domínio e do estilo; a arquitetura aberta do DeepSeek Harness facilita.

8.3 Fronteiras de contexto e A2A

O texto versou sobre uma instância, supondo que tudo do seu perímetro conflui num contexto global. Do indivíduo à organização maior, decidir quantas instâncias ter é traçar as fronteiras de compartilhamento e isolamento do contexto: quem compartilha, compartilha instância; quem isola, instância própria.

E com várias instâncias isoladas — os assistentes pessoais junto ao Super-agent da equipe —, a cooperação de fronteira passa a comunicação entre agentes (A2A, sem protocolo fixo). Uma A2A segura e confiável entre partes que não compartilham contexto e representam permissões distintas segue em aberto.

8.4 Segurança e privacidade

A orientação a eventos amplia quem pode dirigir o agente — e a exposição a entradas não confiáveis. Sem boas respostas de segurança e privacidade, o Super-agent só funciona num círculo pequeno e confiável.

A §5 — loop na nuvem, daemons leves nos aparelhos — pressupõe confiança mútua. Mas um loop que engole eventos externos sem parar, pendurado em máquinas com código privado, dados sensíveis e credenciais locais, introduz riscos reais: uma invasão do lado do servidor ou uma injeção de prompt no loop poria em xeque o controle de todos os aparelhos conectados.

E mesmo sem invasão, enquanto credenciais entrarem no contexto do modelo, o vazamento ronda a operação normal; são precisos mecanismos para usar credenciais sem jamais tocá-las. Para um alcance amplo, a arquitetura deve resgatar contexto de ambientes diversos e resolver junto esses problemas.

9. Conclusão

Em retrospecto, a equipe não propôs teoria nova: aplicou a engenharia clássica de sistemas à construção de agentes. As implementações evoluirão; o pensamento de design conservará valor de referência. A instância interna erguida sobre essas ideias e o DeepSeek Harness segue rodando, participando todo dia de reproduzir e corrigir, responder reviews e iterar o próprio Harness.

Como dito na abertura: à medida que o modelo exige menos intervenção por tarefa, o gargalo da produtividade migra para a atenção humana. Com o dois níveis, a orientação a eventos, a interação assíncrona multicanal, a separação computação-armazenamento e o Watchdog externo, o sistema assume embaixo o tedioso gerenciamento de sessões e a sincronização de contextos, e o humano sobe para decidir e aceitar.

Nessa forma, o agente não é mais a janela que espera ordens, mas um colaborador autônomo permanentemente online no ambiente digital: para as pessoas, um assistente entre dispositivos; para as equipes, um integrante do fluxo de desenvolvimento que toma e empurra tarefas concretas. Com a capacidade dos modelos e a arquitetura avançando juntas, esse modo de trabalho mais autônomo pode virar a norma da colaboração humano-máquina.

Como o original: parte do design vive em dsh-superagent-prototype; o plugin é um protótipo de validação de rota, não um produto oficial da DeepSeek. Autoria e agradecimentos: o texto nasce da prática compartilhada da equipe DeepSeek Harness; Yujia Qiao realizou o sistema e o texto, com Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, Hanxiang Xu, C.C. Yu, Ziya Zhang e F. Zhou na revisão e no debate.

Fontes

• DeepSeek 产品部 (WeChat oficial) — o texto original chinês, 1 nov 2026
• deepseek-ai/dsh-superagent-prototype — o protótipo MIT (README, docs 000–008)
• Referências internas: tradução inglesa integral · original chinês · cobertura do dsh-superagent