DeepSeek Harness: Quando tudo é realmente um plugin

Quando falamos de agentes de IA, quase sempre começamos pelo modelo. Qual modelo escreve código melhor? Qual deles compreende contextos mais longos? Qual resolve mais tarefas num benchmark? É compreensível, mas hoje isso já não chega. Um agente não é composto apenas por um modelo de linguagem. Precisa de ferramentas, armazenamento, sessões, permissões, um ambiente de execução, planeamento, registos e alguma interface através da qual as pessoas possam intervir.

É precisamente por isso que considero tão entusiasmante a Developer Preview do DeepSeek Harness. A DeepSeek resume a ideia numa frase extremamente clara: Everything is a plugin. Não são apenas as ferramentas adicionais que devem ser intercambiáveis. Modelos, skills, sessões, sandboxes, storage, ciclos de agentes, scheduling e até a interface de utilizador são tratados como plugins.

À primeira vista, isto parece uma decisão técnica de design para programadores. Na realidade, contém uma afirmação muito maior sobre a próxima fase da IA. Se a inteligência vem do modelo, mas a capacidade prática de trabalhar vem do harness, então esta segunda metade não pode transformar-se num bloco opaco pertencente a um único fornecedor.

O agente é mais do que o seu modelo

A própria DeepSeek descreve a fórmula de forma muito sucinta: agente é igual a modelo mais harness. O modelo processa linguagem e produz decisões. O harness liga-o ao ambiente real. Disponibiliza ficheiros, regista ferramentas, gere estados, inicia subagentes, executa comandos e decide que informações voltam ao contexto na chamada seguinte ao modelo.

Um harness não é, portanto, apenas uma embalagem à volta de um modelo. Determina aquilo em que uma resposta do modelo se pode transformar. O agente pode apenas produzir texto ou também alterar um ficheiro? Vê todo o repositório ou apenas uma pasta de trabalho? Um comando é executado diretamente no host, num contentor ou numa sandbox remota? Uma pessoa tem de aprovar uma ação? O estado persiste entre várias sessões? Nada disto são características do modelo, mas decisões da runtime que o rodeia.

De responder a agir

Num chat simples, esta separação quase não se nota. Entra uma pergunta e sai uma resposta. Mas assim que um agente trabalha num repositório, trata tickets, acede a sistemas internos ou assume tarefas prolongadas, o harness torna-se pelo menos tão importante como o modelo. Traduz uma intenção expressa em linguagem numa sequência de passos reais e devolve os respetivos resultados ao modelo como novo contexto.

É aí que se decide se uma tecnologia de demonstração impressionante se torna uma ferramenta fiável. Um modelo excelente com mau contexto, permissões demasiado amplas e uma gestão de sessões pouco fiável continua a ser um mau agente. Pode argumentar de forma brilhante e, ainda assim, editar o ficheiro errado, usar um estado desatualizado ou não conseguir retomar corretamente o trabalho depois de um erro. Pelo contrário, um modelo um pouco mais fraco pode ser surpreendentemente útil numa runtime bem construída, porque vê as ferramentas certas, tem limites claros e o seu trabalho continua rastreável.

A arquitetura passa a fazer parte do resultado

O DeepSeek Harness torna esta camada visível. O kernel Cordis monta plugins, resolve dependências e consegue remover novamente componentes. As capacidades são fornecidas como services. Um plugin pode, por exemplo, implementar uma shell, outro disponibiliza essa shell como ferramenta do modelo e um terceiro utiliza a ferramenta num workflow. A implementação concreta pode ser trocada através da configuração sem reconstruir todo o harness.

A DeepSeek vai mais longe do que muitas plataformas que apenas permitem acrescentar algumas ferramentas como extensões. A ligação ao modelo, o tool registry, o session log e o próprio ciclo do agente também são plugins. Segundo a arquitetura, não existe um núcleo privilegiado que tenha de ser remendado para cada extensão. O novo comportamento é montado ao lado dos componentes existentes e pode desfazer os seus registos de forma limpa quando é removido.

Não se trata de uma ideia totalmente nova. Sistemas operativos, navegadores, editores e plataformas vivem há décadas de componentes modulares. A novidade está na consistência com que a DeepSeek transfere este princípio para um agente de IA completo. A arquitetura do agente deixa assim de ser aceite como um produto fixo e passa a ser uma composição de decisões que um operador pode alterar.

Porque é tão apelativo dizer que “tudo é um plugin”

A ideia dos plugins desloca o poder de um produto acabado para uma runtime componível. Posso substituir um fornecedor de modelos sem reconstruir toda a minha forma de trabalhar. Posso trocar uma shell local por uma variante mais isolada. Posso usar outro armazenamento, outra lógica de sessões ou uma interface própria. Além do acesso ao seu próprio modelo, a DeepSeek documenta outros fornecedores e endpoints personalizados compatíveis com OpenAI.

Mudar de modelo sem recomeçar do zero

Um agente torna-se assim uma infraestrutura que configuro de acordo com o meu ambiente. Uma pequena equipa de desenvolvimento talvez precise apenas de acesso a ficheiros, Git e testes. Uma equipa de security quererá também consultas de rede, sandboxes isoladas, aprovações mais rigorosas e registos imutáveis. Uma empresa pode usar o seu próprio model gateway, enquanto um laboratório privado recorre a um modelo open-weight local.

Isto é estrategicamente importante porque os modelos mudam muito depressa. Hoje um fornecedor convence no coding, amanhã outro destaca-se em contextos longos ou no uso de ferramentas. Num produto fechado, mudar de modelo significa frequentemente mudar também de plataforma. Sessões, regras, permissões, integrações e formas de trabalhar têm de ser reconstruídas. Numa runtime modular, o modelo pode continuar a ser um componente substituível por outro fornecedor ou por um endpoint operado internamente.

Essa mudança não é totalmente fluida. Os modelos diferem nos formatos de roles, reasoning, chamadas de ferramentas, suporte de imagens e comportamento em caso de erro. Estas diferenças têm de ser tratadas corretamente nos respetivos adaptadores. Mas é precisamente aqui que se vê o valor de uma fronteira clara: as particularidades de um fornecedor não se espalham de forma descontrolada por todo o produto.

Infraestrutura intercambiável em vez de botões intercambiáveis

É particularmente interessante a separação entre a definição, o fornecedor e o utilizador de uma capacidade. Uma interface Bash descreve aquilo que a capacidade consegue fazer. Um provider decide onde e como os comandos são efetivamente executados. Só outro plugin transforma isso numa ferramenta que o modelo pode chamar. Estas fronteiras são importantes porque permitem aplicar controlo num ponto claro. É aí que se podem introduzir limites de tempo, isolamento, aprovações e registos sem reprogramar cada ciclo de agente.

O potencial torna-se evidente quando várias capacidades partilham o mesmo mundo de execução. Se o sistema de ficheiros e os processos forem transferidos de um ambiente local para uma sandbox remota, a shell, o terminal e a navegação pelo código podem acompanhá-los. Para o utilizador, a capacidade permanece semelhante, enquanto o enquadramento de segurança e operação muda radicalmente por baixo. Este tipo de intercambialidade é mais valioso do que mais um interruptor numa interface.

Os diferentes modos de runtime também mostram aquilo que a DeepSeek pretende. O modo padrão inclui o agente de coding completo. No Code Mode, o modelo pode orquestrar várias chamadas de ferramentas através de código TypeScript gerado. O Minimal Mode reduz o ambiente a shell e editor para benchmarks. No Creator Mode, é possível examinar plugins e presets próprios. Assim, nem todos os casos de utilização têm de carregar a mesma caixa de ferramentas gigantesca.

Profiles e bundles fazem disto mais do que uma coleção solta de extensões. Um profile pode formar uma runtime de agente definida para uma finalidade específica. É possível imaginar um profile leve para desenvolvimento local, um profile mais limitado para sistemas de produção e um profile forense que regista muito mais informação. As capacidades continuam a ser compostas pelos mesmos blocos, mas a combinação e os limites adaptam-se ao risco em causa.

Onde nasce o potencial na prática

A arquitetura é interessante, mas o seu valor só aparece em situações concretas. Um sistema de plugins não é um fim em si mesmo. Tem de permitir adaptar um agente mais rapidamente a requisitos reais sem construir uma plataforma nova para cada caso de utilização.

De ferramenta pessoal a plataforma empresarial

Um único programador pode começar com uma shell local, um editor de ficheiros e um modelo. Assim que isso se transforma numa ferramenta de equipa, surgem outros requisitos: identidades centrais, workspaces separados, aprovações para ações críticas, um model gateway, controlo de custos, sessões persistentes e um audit trail exportável. Numa aplicação monolítica, o fabricante decide se e quando estas funções chegam.

Numa runtime modular, as empresas podem acrescentar elas próprias os elementos em falta ou substituir os providers existentes. O agente não tem de ser reinventado. A mesma interface e a mesma lógica de agente podem utilizar outros modelos por trás de um gateway empresarial, executar comandos numa sandbox interna e guardar sessões num storage próprio. É esta a diferença entre uma ferramenta prática e uma plataforma controlável.

Zonas de confiança diferentes com os mesmos blocos

Nem todas as tarefas merecem os mesmos direitos. Um agente que resume documentação não precisa de acesso à produção. Um agente de incident response talvez necessite de dados de logs e consultas de rede, mas não pode alterar configurações. Um agente de deployment pode executar alterações, mas deve ter aprovações mais restritas, tokens com menor duração e registos particularmente claros.

Com services e profiles claramente separados, esta diferenciação pode ser expressa na runtime. O modelo não tem de compreender todos os detalhes de segurança e cumpri-los voluntariamente. O ambiente decide tecnicamente que capacidades sequer estão disponíveis. Para security, este é um ponto central: uma capacidade que não foi montada nem sequer está à disposição do modelo como ferramenta direta.

Um ecossistema para especialistas

Nenhum fornecedor irá construir simultaneamente a melhor sandbox, o melhor session store, todos os sistemas empresariais e todos os adaptadores de modelos. Um modelo aberto de plugins permite aos especialistas resolverem muito bem uma única camada. Um fornecedor de security poderia disponibilizar um ambiente de execução reforçado. Um projeto de storage poderia fornecer sessões preparadas para auditoria. Uma equipa interna de plataforma poderia ligar aprovações e identidades à sua própria organização.

Quando estes componentes funcionam em conjunto através de interfaces estáveis, nasce um ecossistema em vez de uma aplicação individual cada vez maior. Este é provavelmente o maior potencial do DeepSeek Harness. A DeepSeek não tem de vencer todos os casos de utilização. Basta que a arquitetura se torne o lugar onde outros oferecem e combinam as suas capacidades.

A rastreabilidade não é um pormenor

A segunda grande ideia, além dos plugins, é o append-only session log. Segundo a DeepSeek, tudo aquilo que o modelo vê é registado como um evento. Isto inclui instruções de sistema, chamadas de ferramentas e resultados, injeções de contexto e o planeamento de subagentes. Continuar, criar ramificações, pesquisar e repetir baseiam-se no mesmo fluxo de eventos.

Para os programadores, isto é prático porque permite reconstruir uma execução defeituosa. Para security e operações, é ainda mais importante. Quando um agente altera um ficheiro, inicia um comando ou envia dados para um serviço, preciso de mais do que a última mensagem do chat. Tenho de conseguir perceber que contexto estava presente, que ferramenta esteve envolvida e em que ponto uma decisão passou a ação.

Nas aplicações clássicas, é frequente conseguir atribuir um erro a uma entrada e a um percurso de código determinístico. Nos agentes, isso é mais difícil. A partir da mesma tarefa geral, um modelo pode deduzir passos intermédios diferentes, usar ferramentas noutra ordem e reagir a resultados inesperados. Sem um histórico completo, resta apenas a afirmação de que o agente decidiu alguma coisa. Isso não chega nem para debugging nem para um incidente de segurança.

A decisão de transformar o fluxo de eventos na source of truth cria uma segunda possibilidade: experiências mais comparáveis. Uma sessão pode ser ramificada num ponto específico e continuada com outro modelo, um prompt alterado ou capacidades diferentes. Assim, não se compara apenas qual modelo escreve a resposta mais bonita. É possível investigar como uma alteração concreta afeta o mesmo estado real do trabalho.

Para as empresas, isto poderia evoluir a longo prazo para uma espécie de registo de alterações e incidentes para agentes. Quem deu a ordem? Que política estava ativa? Que dados recebeu o modelo? Que ação foi aprovada? Que resultado regressou? Estas perguntas tornam-se importantes quando os agentes deixam de se limitar a aconselhar e passam a provocar alterações em sistemas reais.

No entanto, um log ainda não é um audit trail acabado. Retenção, proteção de acesso, integridade, conteúdos sensíveis e exportação continuam a exigir soluções rigorosas. Um registo completo pode tornar-se um risco se contiver prompts, código-fonte, resultados de ferramentas ou credenciais. Mesmo assim, gosto da decisão fundamental: as informações visíveis para o modelo não devem chegar por alguma entrada lateral escondida, mas através de um fluxo de eventos que possa ser reconstruído.

O open source torna-se uma arma estratégica

O facto de este projeto vir da China torna tudo ainda mais interessante. A DeepSeek não publica apenas pesos de modelos, mas trabalha agora de forma visível em várias camadas da stack. O DeepSeek V4 está disponível com pesos e código sob a licença MIT. Agora, o Harness, também sob licença MIT, acrescenta uma runtime aberta para trabalho com agentes. Por baixo, o Cordis oferece até um modelo próprio de plugins e composição.

Isto corresponde a uma evolução que já descrevi no meu artigo sobre IA, segurança e a luta pela stack completa. A China não quer apenas consumir aplicações de IA. As empresas chinesas estão a construir modelos, software de inferência, caminhos de hardware e agora também a infraestrutura de agentes acima disso. A DeepSeek demonstra uma velocidade que no Ocidente já não pode ser explicada pela velha imagem de uma mera indústria de cópias.

Nesta corrida, o open source não é apenas idealismo. É distribuição, confiança através da possibilidade de inspeção e um acelerador para um ecossistema. Quem abre pesos, código e interfaces convida programadores de todo o mundo a encontrar erros, construir integrações e transformar o seu design num padrão de facto. Um harness aberto pode ser estrategicamente mais valioso para a DeepSeek do que outra interface de chat fechada, porque continua relevante mesmo quando nele são executados modelos de outros fornecedores.

Este é um ponto notável. A DeepSeek está a construir uma plataforma onde a própria DeepSeek permanece intercambiável. A curto prazo, isso parece quase contraditório. Porque haveria um fornecedor de modelos de facilitar a mudança para um concorrente? A longo prazo, essa pode ser precisamente a posição mais forte. Se os programadores construírem os seus agentes, plugins, regras de segurança e sessões nesta runtime, o Harness torna-se uma infraestrutura comum. A DeepSeek pode perder algumas chamadas individuais ao modelo, mas ganha influência sobre a arquitetura de todo o ecossistema.

A abertura também acelera a aprendizagem. Num produto fechado, a evolução da arquitetura central permanece em grande parte com o fabricante. Um projeto aberto é utilizado em ambientes que a equipa original nunca poderia prever por completo. Daí resultam relatórios de erros, novos adaptadores, backends alternativos e conhecimento operacional. Sobretudo num campo jovem como o software de agentes, este feedback pode ser mais importante do que uma primeira versão perfeita.

É precisamente aqui que reside a inteligência da abordagem por plugins. A DeepSeek não tem de construir todos os tipos de armazenamento, todas as sandboxes e todos os sistemas empresariais. Fornece uma arquitetura na qual outros podem inserir essas capacidades. Quando o ecossistema cresce, o núcleo beneficia de cada nova integração.

A China não constrói apenas um modelo, mas todo um caminho à sua volta

Por isso, a importância geopolítica não reside apenas nos resultados de benchmarks. Um país ou espaço económico não se torna tecnologicamente soberano só porque um modelo potente foi treinado algures. Precisa de hardware, software de inferência, ferramentas de desenvolvimento, interfaces, experiência operacional e programadores que construam produtos sobre essa base. O DeepSeek Harness é mais um elemento precisamente nessa cadeia.

A narrativa ocidental sobre a tecnologia chinesa fica muitas vezes atrás desta evolução. Quem continua a ver a China sobretudo como um fabricante de cópias baratas ignora a velocidade com que ali são publicadas arquiteturas próprias e atraídos programadores globais. Para isso, a DeepSeek não precisa de liderar permanentemente em todas as categorias. Basta manter a distância curta, iterar rapidamente e abrir o seu trabalho para que outros possam continuar a construir sobre ele.

A distância para os melhores modelos fechados está a diminuir

Durante muito tempo, os modelos open-weight foram considerados uma alternativa interessante para laboratórios e casos especiais, enquanto as capacidades realmente fortes pertenciam a poucos fornecedores fechados. Esta visão é cada vez menos sustentável. A diferença não desapareceu em todas as disciplinas, mas está a fechar-se mais depressa do que muitos esperavam.

Nas suas próprias avaliações, a DeepSeek coloca os modelos V4 diretamente ao lado dos atuais modelos fechados de topo. Dependendo do benchmark, o V4 Pro aproxima-se deles, atinge valores comparáveis ou permanece visivelmente atrás. Não há um resultado uniforme em software engineering, utilização de ferramentas, conhecimento factual e tarefas de reasoning muito difíceis. É precisamente por isso que não se deve declarar um “vencedor” com base numa única tabela.

O ponto mais importante é a distância temporal. Capacidades que há pouco tempo eram consideradas uma vantagem exclusiva dos maiores laboratórios dos EUA aparecem hoje, poucos meses depois, em modelos cujos pesos podem ser descarregados, executados internamente e analisados. “Apenas alguns meses atrás dos melhores modelos” não é uma constante cientificamente mensurável. Ainda assim, descreve bastante bem quão breve pode parecer atualmente a vantagem dos sistemas fechados.

Isto também altera o significado económico de uma vantagem. Se um modelo fechado for dez por cento melhor numa tarefa específica, isso pode ser decisivo. Mas se um modelo aberto for suficientemente bom, funcionar em infraestrutura própria e puder ser integrado na própria zona de segurança, o cálculo global pode continuar a favorecer o modelo aberto. Controlo, localização dos dados, custos previsíveis e possibilidade de adaptação própria fazem parte do desempenho, mesmo que não apareçam num benchmark.

Não se pode esquecer o hardware. Pesos disponíveis abertamente não significam automaticamente que um modelo de 1,6 biliões de parâmetros funciona confortavelmente num armário de servidores. O DeepSeek V4 Pro é um enorme modelo Mixture-of-Experts. Mesmo que apenas uma parte dos parâmetros esteja ativa por token, a memória, os custos de inferência e a operação continuam exigentes. A abertura elimina a barreira de acesso ao código e aos pesos, não a realidade física dos grandes modelos.

Apesar disso, a simples existência destes pesos já muda o mercado. Investigadores podem analisar o modelo. Fornecedores podem disponibilizá-lo na sua própria infraestrutura. As comunidades podem desenvolver quantizações e otimizações de runtime. As empresas ganham pelo menos uma alternativa à dependência total de uma única API.

A concorrência desloca-se assim. O conhecimento bruto do modelo continua importante, mas o valor duradouro reside cada vez mais também em data pipelines, avaliações, runtime, segurança, distribuição e integração em processos reais. Um harness aberto encaixa precisamente nesta mudança. Se os modelos se tornam mais facilmente intercambiáveis, ganha a plataforma que lhes fornece contexto, ferramentas e limites de forma fiável.

Aberto não significa automaticamente fiável

Apesar de todo o entusiasmo, seria ingénuo equiparar automaticamente “open source da China” a soberania. Quem utiliza o serviço alojado da DeepSeek continua a enviar dados para um fornecedor externo. Só um endpoint de modelo operado internamente e um harness controlado alteram realmente a soberania dos dados. Mesmo assim, a origem, o processo de build, as dependências e as atualizações continuam a fazer parte da supply chain.

Os plugins aumentam esta responsabilidade. Um plugin não é um tema inofensivo. Pode registar ferramentas, aceder a services e executar código no sistema. Nas instalações a partir de repositórios Git, a documentação da DeepSeek avisa expressamente que os build scripts autorizados podem ser executados no host, fora da sandbox do agente. Recomenda permitir apenas fontes de confiança e fixar as dependências num commit específico.

É exatamente o aviso correto. Uma plataforma aberta de plugins cria intercambialidade, mas também uma nova supply chain. Cada fornecedor adicional pode obter acesso a prompts, ficheiros, credenciais ou ferramentas executáveis. Um plugin comprometido não precisa de um espetacular jailbreak do modelo se já for uma parte legítima da runtime.

Poder consultar o código-fonte é uma vantagem, mas ainda não constitui uma auditoria de segurança. Alguém tem de analisar realmente o código, compreender os builds, fixar versões e controlar atualizações. Num ecossistema de plugins em crescimento, a proveniência torna-se quase tão importante como a função. Um plugin útil de origem desconhecida pode representar um risco maior do que uma função em falta.

Por isso, numa operação séria, utilizaria apenas alguns plugins verificados. As versões devem ser fixadas, as permissões separadas, os secrets geridos fora da configuração e as ligações de saída controladas. As sandboxes têm de isolar realmente e não apenas chamar-se assim. O session log deve ser protegido e verificado quanto a dados sensíveis. Acima de tudo, a afirmação “tudo é um plugin” não pode acabar em “todos os plugins podem fazer tudo”.

O potencial a longo prazo também depende, portanto, da governance. Uma boa plataforma precisa de comprovativos de origem compreensíveis, artefactos assinados, builds reproduzíveis, dependências claras e uma forma de limitar capacidades por profile. Se a DeepSeek e a comunidade levarem a sério estes fundamentos pouco entusiasmantes, a abertura pode conduzir a controlo real. Caso contrário, a promessa dos plugins transforma-se apenas numa superfície de ataque muito grande.

O que quero ver no DeepSeek Harness

A DeepSeek chama deliberadamente Developer Preview ao projeto e anuncia alterações incompatíveis. É um bom momento para ler, experimentar e testar com dados não críticos. Ainda não é motivo para tornar processos centrais de produção dependentes dele.

Será interessante ver se esta arquitetura limpa dá origem a um ecossistema robusto. Para isso são necessários lançamentos assinados, proveniência rastreável dos plugins, modelos de permissões claros, builds reproduzíveis e um processo de atualização que não exija um novo salto de confiança em cada mudança. Igualmente importante é saber até que ponto plugins de diferentes fornecedores podem realmente ser combinados quando o projeto evolui rapidamente.

Também quero ver se a intercambialidade prometida resiste ao quotidiano. No papel, é fácil trocar um adaptador de modelo. Na prática, os modelos diferem nas chamadas de ferramentas, no reasoning, nos formatos de contexto, no suporte de imagens e nos modos de falha. Uma interface aberta reduz estas diferenças, mas não as faz desaparecer.

Apesar destas reservas, o DeepSeek Harness é para mim um dos projetos de IA mais interessantes deste ano. Não porque já tenha de ser o melhor agente de coding. O que entusiasma é uma empresa chinesa de IA abrir a camada acima do modelo e transformá-la num sistema modular. Enquanto outros fornecedores integram os seus agentes cada vez mais profundamente em plataformas fechadas, a DeepSeek aposta numa arquitetura em que até o seu próprio modelo é apenas um plugin intercambiável.

A minha impressão e o ritmo incrível

A Developer Preview já me mostra muito potencial. A interface torna tangível o princípio dos plugins e a vista de trajetória demonstra que a rastreabilidade não deve ser acrescentada apenas mais tarde. O projeto ainda é jovem e muita coisa está em movimento, mas é precisamente esta arquitetura aberta que parece uma base sobre a qual algo grande pode surgir muito rapidamente.

Neste momento, acontece tanta coisa no mundo da IA que até uma diferença de poucas semanas pode parecer antiga. Quem se surpreende quando só a Alphabet prevê despesas de capital de 175 a 185 mil milhões de dólares para 2026 e a Meta mais 115 a 135 mil milhões, em ambos os casos fortemente influenciadas pela infraestrutura de IA? Centenas de milhares de milhões fluem subitamente para a mesma ideia, a mesma competição e o mesmo futuro.

Este capital não garante bons produtos. Mas explica porque os modelos, os centros de dados e as plataformas de agentes avançam a uma velocidade que parecia impossível há poucos anos. Os modelos tornam-se mais intercambiáveis, os pesos abertos recuperam rapidamente e a diferenciação decisiva desloca-se para o harness. A DeepSeek está visivelmente a acelerar nos três temas. Quem constrói infraestrutura de IA não deve interpretar isto apenas como uma história de concorrência chinesa, mas como um convite para reavaliar a sua própria dependência de stacks fechadas.

Até à próxima,
Joe