DeepSeek Harness: o que muda na prática quando “tudo é um plugin”?

Fala aí, beleza? A DeepSeek AI soltou um harness de agente onde nada é sagrado: o loop do agente, a sessão, o sandbox e até a interface são plugins que tu monta e desmonta 😀

O DeepSeek Harness é um projeto open source lançado em 13 de agosto de 2026, na versão 0.1, ainda em developer preview

A tese cabe em uma linha: toda capacidade do agente é entregue por plugin

Parece papo de arquiteto de software, mas isso muda bastante coisa pra quem monta o próprio fluxo de agente, porque peça trocável e bloco fechado são vidas MUITO diferentes… bora destrinchar?

O lançamento: developer preview, licença MIT e uma adoção fora da curva

A data do anúncio é 13 de agosto de 2026, com a versão 0.1 saindo já rotulada como developer preview

E developer preview aqui não é modéstia: o próprio README no repositório oficial no GitHub avisa de forma explícita que vão existir mudanças que quebram compatibilidade

Ou seja: API instável, contrato que pode mudar embaixo do teu plugin

A licença é MIT, então do lado jurídico é o cenário confortável de sempre pra quem quer fuçar, forkar e usar dentro de projeto próprio

Na esteira do lançamento saiu a tag dsh-v0.1.0-rc.12, publicada em 16 de agosto de 2026, o que dá bem o tom do ritmo do projeto: release candidate atrás de release candidate

E a adoção foi insana: 95.386 stars e 8.826 forks em cerca de dois dias depois da publicação

Só tome cuidado com a leitura desse número, ele é uma foto do começo e não o estado de hoje

O que exatamente vira plugin no DeepSeek Harness

Aqui é onde a conversa fica interessante, porque a lista é maior do que a gente espera

São plugins:

• adaptador de modelo
• registro de ferramentas
• skills
• sessões
• log de sessão
• sandbox
• storage
• loops
• agendamento
• o loop do agente
• a própria UI

Se liga nisso: o loop do agente, as sessões, o sandbox e a interface, peças que em outros harnesses costumam ser núcleo fechado, aqui entram como plugin igual a qualquer outra coisa

E o princípio que sustenta isso é o que realmente muda o dia a dia: não existe um core privilegiado a ser modificado

Extensão aqui não é dar patch no miolo, é montar um plugin ao lado dos outros

Se tu já mexeu com plugin de bundler, a ideia de aproximação é parecida, só que sem aquele pedaço intocável embaixo de tudo

Cordis: o framework que segura a arquitetura por baixo

O framework de plugins que sustenta o dsh se chama Cordis

O desenho é o de um contexto compartilhado: cada plugin contribui serviços, eventos tipados e efeitos reversíveis pra esse contexto

"Efeito reversível?" É o pulo do gato aqui

Os registros que tu faz pelas APIs do Cordis viram efeitos, e efeito é desfeito quando o plugin dono é descarregado

Quer dizer: o que tu registrou some junto com o plugin, sem deixar sujeira pendurada no contexto

Agora o pega: isso vale pro que passa pelas APIs do Cordis

Recurso adquirido por fora precisa ser embrulhado, e a documentação é bem direta nisso: adquira dentro de ctx.effect() retornando um disposer, que é chamado no unload e também no hot reload

Esquecer esse embrulho é o erro clássico de quem chega achando que é só exportar uma função e sair feliz

Como você monta seu próprio fluxo: profiles, bundles e ordem das camadas

A composição do dsh é organizada em perfis, os profiles, guardados na Harness home

Um profile é uma composição nomeada: ele lista os bundles que empilha, guarda os plugins out-of-tree instalados e guarda o cordis.patch.yml daquele profile, que é exatamente o mesmo arquivo que aparece como camada 2 na tabela ali embaixo

No boot, a árvore de plugins é montada por camadas ordenadas, e essa ordem importa:

Ou seja: o patch do profile é um arquivo, o de home é outro, e eles não se confundem

Os bundles nomeados em dsh.profile.bundles resolvem primeiro na instalação do dsh e só depois no node_modules do próprio profile

Entre os bundles oficiais citados estão @deepseek-ai/dsh-base, @deepseek-ai/dsh-web-app e @deepseek-ai/dsh-headless

Plugin out-of-tree, aquele que não vem no projeto, é instalado pelo pnpm dentro do node_modules do profile

E o comando de plugins do dsh opera sempre em cima de um profile, encaminhando pro pnpm no diretório dele:

dsh plugin --profile <nome> add @deepseek-ai/dsh-subagent-codex

O comando também aceita remove, why, update e os demais verbos do pnpm, e ele inicializa o profile caso ele ainda não exista

Agora a parte que eu acho mais massa pra depuração: dá pra olhar a árvore composta sem subir a aplicação

dsh --dump-config
dsh --dump-default-config

Antes de sair caçando fantasma, vale a ressalva: um dump não roda os provedores de linha de comando do app e rejeita invocação que carregue argumentos do app

Então o dump é foto da composição, não é a aplicação rodando

Quando essa arquitetura compensa de verdade

Peça trocável custa caro em complexidade, então a pergunta honesta é: quando ela paga a conta?

Trocar o provedor de modelo sem reescrever o fluxo. O harness é agnóstico de modelo e traz suporte de fábrica a DeepSeek, Anthropic, OpenAI, Amazon Bedrock, Google Vertex, Azure e qualquer endpoint compatível com OpenAI

Esse último item é o que costuma resolver a vida de quem já tem código em pé, na mesma lógica de trocar só a base URL pra apontar pra outro provedor

Alternar entre web e headless. Como a UI é plugin e a composição é feita por bundles, sair de uma montagem com interface pra uma montagem headless é questão de qual bundle o profile empilha

Auditoria e retomada de execução. Cada execução é gravada em um log de sessão append-only, com suporte a resume, fork e replay

Pra quem precisa entender depois o que o agente fez (e refazer aquele caminho a partir de um ponto), isso vale mais que qualquer recurso brilhante de UI

Adicionar capacidade sem forkar o projeto. Como não tem core privilegiado, capacidade nova entra como plugin out-of-tree montado ao lado, e não como um fork que tu vai ter que rebasar pra sempre

Esse último ponto é o que menos aparece em demo e o que mais dói na vida real

O custo da flexibilidade: curva de aprendizado e a acusação de over-engineering

Nada disso é de graça, e o projeto não finge que é

O projeto separa fronteiras cedo, e o trade-off declarado é esse: curva de aprendizado mais íngreme em troca de cirurgia menos dolorosa depois

E tem crítica pública em cima disso, o que é saudável

Uma análise publicada em 15 de agosto de 2026 argumenta que a arquitetura pode ser over-engineering pro caso de uso comum

O raciocínio dela: trocar componente sem parar o runtime é real, mas raro na prática

Serviço de busca só precisa de interação breve

Reiniciar um servidor MCP leva 2 a 3 segundos

E skill é texto puro, não exige hot reload no nível do framework

É um argumento bom, e ele mira no lugar certo: se tudo que tu faz é rodar um agente com ferramentas padrão e algumas skills, tu vai pagar a curva sem colher o benefício

Agora, se tu monta fluxo próprio, troca provedor conforme o cliente, mantém capacidade interna que hoje vive num fork remendado, aí a conta muda de sinal

A pergunta não é "a arquitetura é elegante?"

A pergunta é: tu troca peça com que frequência?

Como testar o DeepSeek Harness hoje sem se comprometer

O nome de comando da ferramenta é dsh, e dá pra experimentar sem casar com nada

1. Confira o Node.js. O projeto declara Node.js 22.19+ ou 24+, com a CI cobrindo 22.19, 24 e 26

O erro comum aqui é tentar em um Node antigo que tu tem na máquina há dois anos e culpar a ferramenta pelo tombo

2. Deixe o pnpm e o Git na régua. O pnpm vem via Corepack, com [email protected] fixado no package.json, e o Git pedido é 2.26 ou superior

O erro comum é rodar com um pnpm global qualquer, diferente do que está fixado no projeto

3. Suba rápido pela via do npx, sem clonar nada:

npx @deepseek-ai/dsh web

A Web UI é servida em http://127.0.0.1:3080 por padrão, então é nesse endereço local que tu abre o navegador

4. Ou rode a partir do código-fonte, se tu quer fuçar o monorepo:

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

O erro comum deste passo é pular o pnpm run build e ir direto pro pnpm dsh web

5. Olhe a árvore composta antes de sair mexendo, com --dump-config ou --dump-default-config

Lembrando da ressalva: dump não roda os provedores de linha de comando do app e rejeita invocação com argumentos do app junto

6. Trate tudo isso como ambiente descartável. É developer preview com aviso de mudança que quebra compatibilidade, então repositório de teste, máquina de teste, expectativa de teste

Vídeo: agentes e skills na prática

Pra começar do zero com a ideia de agente e skill fazendo trabalho de verdade, esse vídeo do canal mostra uma skill que faz a IA ler o teu código e desenhar a arquitetura sozinha, usando o Archify

Vale adotar agora?

Minha leitura é direta: como arquitetura, o DeepSeek Harness é dos projetos mais interessantes pra quem monta fluxo de agente próprio

A lista de peças que viram plugin é longa, o princípio de não ter core privilegiado é coerente do começo ao fim e o Cordis dá um ciclo de vida com efeitos reversíveis que sustenta a promessa

Como base de produção hoje, é outra história

Enquanto for developer preview com quebra de compatibilidade anunciada no próprio README, tu está construindo em cima de contrato que vai mudar

Se o que tu precisa é estabilidade pra colocar coisa no ar, a conversa é sobre a versão GA do V4 Pro, não sobre um harness 0.1

Próximo passo concreto pra tirar a limpo: sobe a Web UI local com o npx @deepseek-ai/dsh web, roda o dump pra ver a árvore composta com os teus olhos e compara com o harness que tu já usa hoje

Depois disso tu responde sozinho se peça trocável resolve o TEU problema ou se é complexidade bonita que tu não vai usar

faça o teste e me conta 🙂

até o próximo post!