A DeepSeek fez dois anúncios em um único dia. No início da manhã de hoje, lançou o modelo flagship DeepSeek V4 Pro; ao meio-dia, o preview para desenvolvedores do DeepSeek Harness chegou ao GitHub. O modelo ficou com as manchetes, mas o harness é a história que vai envelhecer melhor.
O DeepSeek Harness não é mais um modelo e nem mais um cliente de API. É um SDK e framework de aplicações para construir, executar e estender agentes de IA. O repositório já tem mais de 230 membros de workspace, com código distribuído entre packages/, apps/, examples/, python/, native/ e vendor/. Acesso ao sistema de arquivos, terminais, subprocessos, PTYs, servidores de linguagem, navegação web, skills, subagentes, workflows, modos de planejamento, persistência de sessão, credenciais e telemetria — quase toda capacidade tem seu próprio pacote.
A declaração de design mais marcante é o slogan central do projeto: tudo é um plugin. Até o próprio loop do agente é um plugin.
Uma protoboard, não um computador pronto
Se um projeto de agente típico é um computador pré-montado, o DeepSeek Harness é uma protoboard excepcionalmente grande. Modelos, ferramentas, interfaces, armazenamento, políticas de segurança e gerenciamento de contexto podem todos ser conectados — e desconectados.
O projeto se apoia no microkernel Cordis. Uma instância do Harness em execução é essencialmente um Context do Cordis: os pacotes registram serviços, eventos e capacidades, e um arquivo de config os monta em um agente funcional.
O packages/core/ cuida do básico — o que é uma sessão, como os system prompts são montados, como as ferramentas se registram e são chamadas, como um agente é criado e como um turno flui da entrada do usuário até a requisição ao modelo, da execução de ferramentas à resposta final. Ao redor do núcleo ficam os pacotes de capacidades: packages/llm/ para adaptadores de modelo e streaming, packages/shell/, subprocess/ e terminal/ para comandos e árvores de processos, packages/fs/ para operações de arquivos, packages/lsp/ para navegação semântica de código, packages/web/ para busca e fetch, packages/skill/ para skills reutilizáveis, e packages/subagent/ mais packages/workflow/ para estender um único agente em um sistema multiagente.
A arquitetura tem uma divisão deliberada em três camadas: interface, implementação e consumidor. Tomemos o Bash como exemplo. A interface define o que significa “executar um comando”; a implementação local realmente cria processos; o toolkit voltado ao modelo transforma essa capacidade em um schema e resultados que o modelo consegue entender. Se mais tarde um shell local precisar virar um container remoto, um sandbox na nuvem ou uma plataforma corporativa de execução, você troca a camada de implementação — sem reescrever as ferramentas do modelo nem o loop do agente.
Isso é pensamento de framework. Faz o repositório inicial parecer inchado, mas também significa que o objetivo da DeepSeek não é um produto acabado que só a própria equipe consegue manter. Diferentes deployments podem trocar modelos, armazenamento, políticas de segurança, ferramentas — até o próprio loop do agente.
cordis.yml: uma base de código, muitos agentes
A arquitetura de plugins chega aos desenvolvedores por meio do cordis.yml. O arquivo de config lista nomes de plugins, IDs estáveis e parâmetros, e decide quais capacidades um agente realmente tem.
O mesmo código se monta em formas de produto completamente diferentes. Adicione o adaptador LLM da DeepSeek, o sistema de arquivos, o Bash e uma TUI, e você tem um agente de programação no terminal. Troque a interface pelo plugin Web e ele vira um app de navegador. Use o entry point headless e ele recebe uma tarefa, roda rodadas de modelo-e-ferramenta, imprime uma resposta e encerra. Aponte uma porta de entrada ACP ou JSON-RPC para ele, e ele se torna um serviço de automação que outros programas podem acionar.
As configs também suportam overlays. A TUI e a Web UI podem compartilhar uma config base e sobrepor seus próprios plugins de interface e parâmetros, com a config pessoal no último nível. Quem faz deploy não copia a árvore de config inteira — aplica patches em plugins específicos. Uma ressalva que vale destacar: um patch de config substitui a config inteira do plugin alvo em vez de fazer um deep-merge. Adicionar um campo novo pode fazer chaves de API ou base URLs existentes desaparecerem silenciosamente. É explícito, mas não é intuitivo no primeiro uso. Para uma análise mais profunda do que o movimento do harness da DeepSeek significa, veja nossa análise anterior sobre por que a DeepSeek deixou de ser uma empresa só de modelos.
O loop do agente como regras de trânsito
Muitos projetos iniciais de agentes se resumem a poucas linhas: enviar mensagens ao modelo, executar as chamadas de ferramenta quando voltam, retornar resultados, repetir até o modelo emitir texto. O DeepSeek Harness também faz isso, mas divide o processo em um ciclo de vida rigoroso.
Uma entrada do usuário abre um Turn; um Turn contém múltiplos Steps, cada um correspondendo a uma requisição ao modelo mais sua execução de ferramentas. Antes de uma requisição, o sistema monta um system prompt estável, o ambiente de runtime atual, os schemas das ferramentas e as mensagens da sessão. Depois dela, chunks de streaming, mensagens completas, chamadas e resultados de ferramentas e razões de término vão todos para um fluxo de eventos.
As ferramentas não são invocadas no momento em que um nome é retornado. Elas passam por pré-políticas, salvaguardas de segurança para ações irreversíveis, execução de fato, pós-processamento, limpeza de conteúdo e notificação de resultado. Permissão ou negação, timeout, retry, métricas e contexto extra podem se enganchar em diferentes estágios do pipeline. Uma ferramenta pode declarar-se segura para concorrência em certas formas de parâmetros, e o scheduler executa em paralelo tarefas consecutivas somente de leitura; ao encontrar uma chamada que muta estado ou é incerta, ele a trata como uma barreira e a executa com exclusividade após o término das tarefas anteriores.
Isso parece instalar controle de tráfego aéreo numa estrada rural — até o momento em que um agente está buscando em dez arquivos ao mesmo tempo, rodando testes, aceitando comandos do usuário no meio da execução e permitindo cancelamento a qualquer instante. Aí essas regras passam de engenharia excessiva para aquilo que você gostaria de ter tido ao escrever o postmortem.
O projeto também leva a sério as mensagens no meio da execução. Conteúdo novo de um usuário enquanto o agente trabalha pode ser uma tarefa enfileirada ou uma instrução de direcionamento. O sistema distingue mensagens enfileiradas, contexto injetado e steering, e confirma se uma instrução de steering realmente chegou a uma requisição do modelo. Não se importa apenas que a mensagem foi recebida; importa em qual etapa do raciocínio do modelo ela foi vista.
Session Log: a única fonte da verdade
Outro design que merece destaque: tudo que o modelo vê deve ser reconstrutível a partir do log. Mensagens do usuário, contexto de runtime, informações da requisição ao modelo, saída em streaming, chamadas e resultados de ferramentas, eventos de compressão, mudanças de permissão e razões de cancelamento — tudo entra em um stream de sessão append-only na forma de eventos. A UI, a persistência, o resume, o fork, a telemetria e o replay não devem manter cada um uma cópia “aproximadamente correta” do estado — eles derivam de uma única fonte de eventos.
Isso resolve um problema genuinamente doloroso em sistemas de agentes: quando uma tarefa dá errado, dá para saber de fato o que o modelo viu naquele momento? Se você só guarda o texto final do chat, perde o que importa — o estado do workspace injetado antes da requisição, resultados de ferramentas truncados, uma troca automática de roteamento de modelo, um usuário mudando de rumo no meio do streaming. O Harness salva o suficiente nas fronteiras das requisições para reconstruir as mensagens, e mantém os chunks brutos de streaming para que a UI e o replay permaneçam consistentes.
A persistência de sessão é ela mesma um plugin, com backends JSONL e SQLite. O Resume continua uma sessão no lugar; o Fork deriva uma nova sessão a partir de um limite definido do histórico. Para desenvolvedores, isso oferece uma base unificada para debugging, avaliação, auditoria e automação.
De um agente a uma multidão
O Harness vem com capacidades de subagente e workflow embutidas. Um agente principal pode delegar a subagentes — instâncias recém-criadas, forks a partir de um limite já concluído de uma sessão existente, ou subprocessos externos conectados via ACP. O design de escopo importa aqui: cada agente tem sua própria camada de contexto e enxerga ferramentas, prompts e comandos específicos. Um subagente pode ser restrito a busca e análise, enquanto outro tem permissão para modificar arquivos.
A demo da equipe do 36Kr é um dado útil. Eles pediram a um Harness configurado com V4-Flash que construísse um shooter de zumbis em primeira pessoa com um único prompt e nenhuma intervenção no meio da execução; uns 30 minutos depois tinham um jogo jogável — se tosco. A mesma equipe rodou o mesmo estilo de prompt no Codex com GPT-5.6 sol-xhigh para uma tarefa de animação 3D e obteve resultados visivelmente piores, apesar do modelo maior. Foi o harness, não o modelo, que carregou o trabalho.
Por que isso importa
O harness está se tornando o novo campo de batalha da infraestrutura de IA. Codex, Claude Code, OpenClaw e agora o DeepSeek Harness lutam nessa camada, mas travam batalhas diferentes. A maioria são produtos fechados otimizados para uma única experiência; a DeepSeek escolheu abrir o próprio método de montagem. Essa é a mudança estrutural: agentes deixam de ser aplicações que você compra e passam a ser montagens que você compõe — com um microkernel aberto, implementações substituíveis e um log de eventos auditável como fundação. Rastreamos os primeiros sinais disso em por que o harness é o novo campo de batalha da IA, e este artigo aprofunda na arquitetura.
A aposta open source também tem uma vantagem estratégica. Se a camada de harness se tornar a interface entre modelos de fronteira e trabalho real, quem controlar a montagem padrão fica com a distribuição — de modelos, ferramentas e computação na nuvem. Ao abrir o código no mesmo dia do lançamento do V4 Pro, a DeepSeek está dizendo que o modelo é só metade do produto — a mesma decisão estratégica que a MiniMax tomou quando argumentou que empresas de modelos precisam construir seu próprio harness.
O que fazer a respeito
Desenvolvedores devem clonar o repositório e rodar uma sessão — mesmo o entry point headless basta para sentir a diferença entre um agente e um agente montado. Quem avalia infraestrutura de agentes para deploy deve testar a divisão em três camadas: dá para trocar armazenamento, política de segurança ou backend de execução sem tocar no loop? Times de segurança e auditoria devem olhar o princípio do Session Log — uma fonte de eventos append-only é exatamente o que a compliance quer. E quem constrói sobre frameworks de agentes deve tratar “tudo é um plugin” como a nova expectativa padrão, porque a era dos agentes como aplicativos fechados acabou de ganhar um prazo de validade.
