Um modelo de linguagem pode ser excelente em raciocínio e geração de código, mas ele não abre arquivos, executa comandos ou altera um projeto sozinho. Entre o modelo e o computador existe uma camada operacional. É nessa parte menos visível que o DeepSeek Harness tenta mudar a maneira como agentes de IA realizam tarefas complexas.
O DeepSeek Harness, também identificado pelo comando dsh, é um projeto de código aberto desenvolvido pela DeepSeek. Seu objetivo não é apresentar apenas mais um modelo de inteligência artificial, mas oferecer a infraestrutura necessária para transformar diferentes modelos em agentes capazes de trabalhar com arquivos, terminal, pesquisas, ferramentas, habilidades, fluxos e subagentes.
Essa distinção parece pequena, mas é fundamental.
O modelo produz decisões em forma de tokens. O harness transforma essas decisões em ações reais. Ele apresenta as ferramentas disponíveis, recebe as chamadas geradas pelo modelo, controla a execução, devolve resultados, administra a sessão e registra aquilo que aconteceu.
Claude e Claude Code ajudam a entender a diferença. Claude é uma família de modelos. Claude Code é um ambiente de agente que conecta esses modelos ao terminal, ao sistema de arquivos e a ferramentas de desenvolvimento.
A mesma lógica aparece no ecossistema DeepSeek. Um modelo como DeepSeek V4 pode ser o “cérebro”, enquanto o DeepSeek Harness oferece o corpo operacional. O projeto, porém, foi construído para separar essas partes e permitir que componentes sejam trocados.
A proposta mais interessante aparece no chamado Code Mode, atualmente também apresentado como PTC — Programmatic Tool Calling. Em vez de obrigar o modelo a conversar com cada ferramenta individualmente, ele pode escrever um pequeno programa que organiza várias ações e executá-las em conjunto.
Menos conversa entre modelo e ferramentas. Mais execução.
Afinal, o que é um harness de IA?
A palavra harness pode ser traduzida como arreio, estrutura de conexão ou mecanismo de controle. No campo dos agentes de inteligência artificial, ela representa a camada que envolve o modelo e permite que ele interaja com sistemas externos.
Um modelo isolado recebe uma entrada e gera uma saída. Ele não possui, por natureza, acesso ao seu projeto, aos arquivos do computador, ao Git, ao terminal ou a uma API corporativa.
O harness acrescenta essas capacidades.
Quando pedimos a um agente para corrigir um erro em um programa, várias operações podem acontecer:
- o agente procura arquivos relevantes;
- lê o código;
- localiza símbolos ou referências;
- consulta instruções do projeto;
- elabora uma hipótese;
- altera um ou mais arquivos;
- executa testes;
- analisa os resultados;
- ajusta a implementação;
- apresenta um resumo.
O modelo participa das decisões, mas quem oferece acesso ao sistema de arquivos, executa os comandos, controla permissões e registra a trajetória é o harness.
Essa camada também define quanto contexto será enviado ao modelo. Um resultado enorme de terminal pode ser inserido integralmente na conversa ou filtrado antes. Uma ferramenta pode aparecer como uma função direta ou como parte de um SDK. A execução pode ocorrer no sistema principal, em um processo restrito, em um contêiner ou em outro ambiente isolado.
Dois agentes utilizando o mesmo modelo podem se comportar de maneira bastante diferente porque seus harnesses organizam ferramentas, contexto e execução de formas distintas.
O modelo importa muito. A estrutura em volta dele também.
“Tudo é um plugin”
A arquitetura do DeepSeek Harness parte de uma ideia explícita: praticamente todas as capacidades devem ser tratadas como plugins.
Modelo, ferramentas, skills, sessões, armazenamento, interface, sandbox, planejamento, subagentes e fluxos podem ser adicionados por componentes separados. O projeto utiliza o sistema de plugins Cordis para fornecer serviços e permitir que módulos colaborem sem transformar toda a aplicação em uma estrutura única e rígida.
Segundo a página oficial do DeepSeek Harness, a ferramenta oferece quatro configurações principais:
- Standard Mode: agente de programação completo, com edição de arquivos, shell, busca local e na web, skills, planejamento, objetivos, subagentes e workflows;
- Code Mode ou PTC Mode: mantém as capacidades do modo padrão, mas apresenta as ferramentas por meio de um SDK para que o modelo componha operações em um programa;
- Minimal Mode: ambiente reduzido, com shell persistente e editor, pensado principalmente para testes de modelos;
- Creator Mode: configuração destinada à inspeção do runtime, experimentação com plugins e criação de novos presets de agente.
A configuração do agente deixa de ser um bloco fechado no programa principal. Ela passa a ser uma composição de peças.
Isso permite imaginar agentes especializados. Uma equipe pode criar um preset apenas para revisão de código, outro para documentação, um para análise de logs e outro para manutenção de infraestrutura. Cada um recebe somente os componentes necessários.
A promessa de flexibilidade vem acompanhada de complexidade. Quanto mais extensível é um sistema, maior a necessidade de entender quais plugins estão ativos, quais permissões possuem e como interagem.
O projeto ainda está em developer preview. O repositório oficial no GitHub avisa que a ferramenta passa por evolução rápida e que haverá mudanças capazes de quebrar compatibilidade.
Não é um detalhe escondido. É o estado atual do software.
Como agentes trabalham no modo nativo
No funcionamento tradicional, o modelo recebe uma lista de ferramentas. Cada ferramenta possui nome, descrição e esquema de argumentos.
Suponha que o agente precise encontrar todos os arquivos de log, extrair mensagens de erro, agrupá-las por categoria e produzir um relatório.
No modo nativo, o fluxo pode ser parecido com isto:
- o modelo chama a ferramenta de listagem;
- o harness executa a chamada;
- o resultado volta para o contexto;
- o modelo lê a lista e escolhe um arquivo;
- chama a ferramenta de leitura;
- o conteúdo retorna para o modelo;
- o modelo decide ler o próximo arquivo;
- outra chamada é realizada;
- novos resultados entram no contexto;
- o modelo finalmente organiza os dados.
Cada etapa pode exigir uma nova interação com a API do modelo. O histórico cresce porque chamadas e respostas intermediárias precisam ser preservadas para que o agente saiba o que aconteceu.
Esse funcionamento possui uma vantagem: cada passo fica bastante explícito. O usuário ou o sistema de permissões pode inspecionar uma operação antes de executá-la. Também é adequado para tarefas curtas em que o resultado de uma ferramenta modifica completamente a decisão seguinte.
O custo aparece em trabalhos mecânicos e repetitivos.
Se houver cem arquivos, o agente talvez realize muitas chamadas quase iguais. O modelo recebe informações que poderiam ser filtradas por um programa comum. Tokens são consumidos para transportar listas, trechos e respostas que servem apenas como ponte entre uma ferramenta e outra.
O modelo acaba fazendo o trabalho de um laço de programação, só que por meio de várias rodadas de inferência.
Code Mode: o modelo escreve o procedimento
O Code Mode muda a representação das ferramentas.
Em vez de expor todas elas apenas como funções que o modelo chama uma por vez, o DeepSeek Harness gera uma interface tipada. O modelo escreve um programa, normalmente em TypeScript, usando esse SDK.
O programa pode:
- listar arquivos;
- percorrer resultados com um laço;
- realizar leituras independentes em paralelo;
- filtrar linhas;
- agrupar ocorrências;
- calcular totais;
- tratar erros;
- devolver apenas um resumo.
O harness executa esse programa e apresenta ao modelo o resultado relevante. Dados intermediários não precisam atravessar repetidamente a janela de contexto.
Em um exemplo simplificado, o modelo poderia produzir uma lógica parecida com esta:
const arquivos = await tools.buscarArquivos({
padrao: "**/*.log"
});
const conteudos = await Promise.all(
arquivos.map((arquivo) =>
tools.lerArquivo({ caminho: arquivo })
)
);
const erros = conteudos
.flatMap((conteudo) => extrairErros(conteudo))
.reduce(agruparPorTipo, {});
return erros;Os nomes reais das ferramentas e os tipos dependem da configuração do harness. O que importa é o fluxo: uma única produção de código descreve o procedimento completo.
A ideia de apresentar ferramentas como uma API programável não surgiu exclusivamente com o DeepSeek Harness. A própria documentação técnica do projeto menciona o trabalho anterior da Cloudflare.
Em setembro de 2025, a Cloudflare publicou a proposta Code Mode: the better way to use MCP. A empresa argumentava que modelos possuem muito mais exposição a código real durante o treinamento do que a formatos artificiais de chamadas de ferramentas.
Em vez de pedir ao modelo que emitisse dezenas de estruturas JSON especiais, as ferramentas seriam transformadas em uma API TypeScript. O modelo escreveria código para combiná-las.
O DeepSeek Harness incorporou essa lógica como parte de sua arquitetura modular.
Por que programar pode economizar tokens?
Uma chamada de ferramenta tradicional exige uma sequência de mensagens.
O modelo escolhe a ferramenta e produz os argumentos. O harness executa. O resultado volta ao contexto. O modelo processa esse conteúdo e decide a etapa seguinte.
Se a operação gerar vinte mil linhas, esse material pode ocupar uma parte significativa da janela, mesmo quando o modelo precisa apenas contar quantas vezes determinado erro aparece.
Com o Code Mode, o programa executa o processamento fora do contexto principal. Ele pode ler vinte mil linhas, descartar o conteúdo irrelevante e devolver algo pequeno:
Falhas de autenticação: 138
Erros de conexão: 42
Timeouts: 17O modelo recebe o resultado final, não toda a matéria-prima.
Essa diferença pode reduzir:
- tokens de entrada;
- número de chamadas ao modelo;
- tempo acumulado de rede;
- pressão sobre a janela de contexto;
- repetição de instruções e esquemas;
- exposição desnecessária de resultados intermediários ao modelo.
Também permite paralelismo. Leituras independentes podem ser enviadas em conjunto com Promise.all, em vez de depender de várias decisões sequenciais.
Só que a economia não é automática.
O SDK tipado precisa ser apresentado ao modelo. Se a interface for enorme, sua descrição também consome contexto. A documentação do próprio DeepSeek Harness reconhece que as declarações TypeScript podem ficar grandes e, no modo que expõe simultaneamente ferramentas nativas e Code Mode, as duas representações ocupam espaço.
Tarefas pequenas talvez não ganhem nada. Se o agente precisa chamar uma única ferramenta, escrever, interpretar e executar um programa pode acrescentar trabalho.
O benefício tende a aparecer quando existe composição: múltiplos arquivos, várias APIs, filtragem, laços, operações independentes ou grande volume de dados intermediários.
Velocidade não serve se o resultado estiver errado
Um agente mais rápido não é automaticamente melhor.
O programa gerado pode interpretar incorretamente o formato dos logs, ignorar arquivos, usar uma expressão regular inadequada ou agrupar erros diferentes na mesma categoria. Como várias ações são executadas em uma única etapa, um erro inicial pode se propagar por todo o processamento.
No modo nativo, o modelo observa resultados intermediários e pode corrigir o caminho. No Code Mode, ele tenta antecipar a sequência.
Isso cria uma troca.
Para operações determinísticas, repetitivas e bem estruturadas, o programa pode ser muito mais eficiente. Em tarefas ambíguas, exploratórias ou dependentes de interpretação contínua, interagir passo a passo talvez seja mais confiável.
Também é necessário avaliar a qualidade final do relatório. Se uma configuração demora 36 segundos, mas perde metade dos erros, ela não venceu a comparação.
Um teste completo deveria observar:
- tempo total;
- tokens de entrada e saída;
- custo monetário;
- cobertura dos arquivos;
- precisão dos agrupamentos;
- estabilidade entre execuções;
- quantidade de intervenção humana;
- erros de ferramenta;
- facilidade de auditar a trajetória.
Agentes são sistemas, não cronômetros.
Programmatic Tool Calling não significa uma única ação interna
Dizer que o Code Mode realiza tudo “de uma vez” pode gerar uma interpretação errada.
As ferramentas continuam sendo chamadas. Arquivos continuam sendo lidos. Comandos continuam sendo executados. APIs ainda recebem requisições.
O que muda é quem organiza a sequência.
No modo nativo, o ciclo do agente alterna repetidamente entre modelo e ferramenta. No modo programático, o modelo escreve um procedimento, e o runtime organiza várias chamadas dentro daquela execução.
As operações internas podem continuar percorrendo o pipeline de ferramentas, incluindo validações, registros e políticas. O documento de implementação do Code Mode descreve subchamadas identificadas e registradas individualmente.
Isso é importante para observabilidade. Se o programa chama cinco ferramentas, a plataforma ainda precisa saber qual delas falhou, quais argumentos foram usados e o que aconteceu antes do resultado final.
Agrupar a coordenação não deveria apagar a trajetória.
Um harness que pode modificar o próprio harness
O Creator Mode representa a parte mais experimental da proposta.
Nesse modo, o agente pode inspecionar os serviços, plugins, eventos e ferramentas disponíveis no runtime. Também consegue montar plugins temporários e testar novas composições em memória.
A intenção é permitir que o desenvolvedor descreva uma capacidade e utilize a própria IA para ajudar a construir o módulo correspondente.
Podemos imaginar um pedido como:
Crie uma ferramenta que leia arquivos CSV do projeto, valide colunas obrigatórias e devolva um resumo dos registros inconsistentes.
O agente inspeciona as interfaces disponíveis, escreve o código do plugin, monta o componente temporariamente e testa seu comportamento.
Há um limite importante. Os plugins criados dinamicamente em memória não são necessariamente persistidos como parte definitiva da instalação. Para transformar um experimento em componente mantido, o código precisa ser revisado, salvo, testado e incorporado de maneira controlada.
A possibilidade de um agente modificar sua própria composição é poderosa. Também amplia o risco de uma configuração incorreta introduzir ferramentas excessivamente permissivas.
Extensibilidade sem governança vira superfície de ataque.
Compatibilidade com outros modelos
A separação entre modelo e harness permite trabalhar com provedores diferentes. A arquitetura atual transporta a seleção como uma combinação de provedor e modelo, em vez de presumir que toda sessão utilizará obrigatoriamente um único serviço.
Isso não significa que qualquer modelo funcionará igualmente bem.
O modo nativo exige competência em tool calling. O modelo precisa selecionar ferramentas, gerar argumentos válidos, interpretar resultados e manter o estado do trabalho.
O Code Mode exige outra combinação:
- boa geração de TypeScript ou da linguagem configurada;
- capacidade de compreender tipos;
- planejamento de múltiplas etapas;
- tratamento de erros;
- respeito às instruções do SDK;
- seleção adequada do que deve retornar ao contexto.
Um modelo pode conversar muito bem e ainda falhar na composição programática. Outro pode escrever código correto, mas gerar argumentos inadequados para ferramentas específicas.
Plugins comunitários já oferecem rotas para APIs compatíveis com os formatos OpenAI, Anthropic e outros provedores. O ecossistema ainda está mudando rapidamente, e compatibilidade de protocolo não garante equivalência de comportamento.
Conectar um endpoint é a parte fácil. Fazer o modelo utilizar corretamente todas as capacidades exige testes.
O custo da API não depende apenas do preço por token
A DeepSeek cobra sua API pelo volume de tokens processados. Entrada com cache, entrada sem cache e saída podem possuir preços diferentes.
Na tabela oficial consultada em agosto de 2026, o DeepSeek V4 Flash aparece com preços de 0,02 yuan por milhão de tokens de entrada com cache, 1 yuan para entrada sem cache e 2 yuan por milhão de tokens de saída. O V4 Pro aparece com 0,025 yuan para entrada com cache, 3 yuan para entrada sem cache e 6 yuan por milhão de tokens de saída.
Esses valores podem mudar. A própria documentação de preços da API DeepSeek recomenda acompanhar a página atualizada.
O custo real de um agente não é calculado apenas multiplicando o tamanho da pergunta pelo preço do modelo.
Cada nova rodada pode reenviar partes consideráveis do histórico. Definições de ferramentas, instruções, resultados anteriores e conteúdo de arquivos ocupam tokens. Em uma tarefa com muitas chamadas, o material acumulado pode superar em muito o prompt original.
O cache do provedor ajuda quando o prefixo permanece estável. Alterações na lista de ferramentas, no prompt de sistema ou na estrutura da sessão podem diminuir esse aproveitamento.
O Code Mode tenta reduzir principalmente a quantidade de resultados intermediários que retornam ao modelo. Se o programa lê cinquenta arquivos e devolve apenas uma tabela pequena, a economia pode ser expressiva.
Mas existe um custo inicial: gerar o programa e apresentar o SDK. Se a tarefa exige apenas uma leitura simples, o modo nativo pode utilizar menos tokens.
O modo de operação, portanto, faz parte da economia da API.
O risco de executar código escrito pelo modelo
O Code Mode não oferece apenas a capacidade de escolher ferramentas. Ele executa um programa produzido pelo modelo.
Isso exige uma discussão de segurança mais séria.
A implementação atual utiliza uma nova worker thread do Node.js para cada execução. O ambiente de variáveis é esvaziado, e existem limites configuráveis de memória, tempo e saída. Um laço síncrono descontrolado pode ser interrompido sem bloquear o processo principal.
Esses controles são úteis. Não equivalem a um sandbox de segurança contra código hostil.
A própria documentação do projeto afirma que o runtime baseado em worker thread oferece contenção operacional, mas não uma fronteira forte de segurança. O código pode alcançar APIs do Node, e uma thread compartilha o mesmo usuário e o mesmo sistema operacional do processo principal.
Em agosto de 2026, uma discussão no repositório do DeepSeek Harness detalhou a preocupação de que o caminho run_code possa acessar arquivos e criar processos fora das restrições esperadas em determinadas configurações. Trata-se de uma discussão técnica no GitHub, não de uma declaração conclusiva de que toda instalação foi comprometida, mas o cenário merece atenção.
Quem pretende experimentar o Code Mode deve preferir:
- uma máquina virtual descartável;
- um contêiner bem restrito;
- workspace separado;
- credenciais de curta duração;
- ausência de chaves SSH ou tokens pessoais;
- acesso mínimo à rede;
- permissões limitadas;
- revisão das operações;
- versão fixada do software;
- acompanhamento das correções do projeto.
Um limite de tempo impede que o programa rode indefinidamente. Ele não impede, sozinho, a leitura de um arquivo sensível durante o primeiro segundo.
Não confunda contenção de recursos com isolamento de segurança.
Code Mode não substitui o modo nativo
A arquitetura mais interessante provavelmente não será aquela que obriga todas as tarefas a usar um único modo.
Chamadas diretas continuam adequadas quando:
- existe apenas uma ferramenta;
- o usuário precisa aprovar cada ação;
- a próxima decisão depende de uma interpretação cuidadosa;
- os resultados intermediários são pequenos;
- a transparência passo a passo é prioridade.
A execução programática tende a funcionar melhor quando:
- há muitos arquivos;
- várias ferramentas precisam ser combinadas;
- resultados devem ser filtrados;
- existem laços ou condições;
- chamadas independentes podem ocorrer em paralelo;
- dados intermediários são grandes;
- a tarefa possui um procedimento relativamente claro.
O próprio DeepSeek Harness aceita configurações nativa, programática ou combinada. Isso sugere que a escolha pode ser tratada como decisão de engenharia, não como disputa ideológica.
Em uma tarefa real, o agente talvez investigue inicialmente no modo nativo, compreenda o problema e depois escreva um programa para processar o restante em escala.
Pensar primeiro. Automatizar depois.
O que o DeepSeek Harness realmente está propondo
O aspecto mais relevante do projeto não é apenas ser uma alternativa ao Claude Code.
O DeepSeek Harness apresenta uma visão na qual o agente não é um produto indivisível. Modelo, ferramentas, sessões, armazenamento, interface, execução e políticas são componentes que podem ser inspecionados e recombinados.
Essa abertura pode ajudar pesquisadores, desenvolvedores de ferramentas e equipes que desejam experimentar diferentes modelos sem reconstruir toda a infraestrutura de agente.
Também transfere mais responsabilidade para quem monta o ambiente. Em uma solução fechada, parte da complexidade é decidida pelo fornecedor. Em uma plataforma modular, o operador precisa entender plugins, permissões, compatibilidade, persistência e limites de segurança.
O Code Mode reforça essa mudança. Ele trata o modelo não apenas como um decisor que chama funções, mas como um gerador de pequenos programas operacionais.
É uma ideia coerente com aquilo que os modelos aprenderam a fazer bem: escrever código, compor APIs e transformar procedimentos em estruturas executáveis.
Talvez a próxima geração de agentes não seja definida somente por modelos maiores. Pode ser definida por harnesses capazes de decidir quando conversar, quando chamar uma ferramenta e quando escrever um programa para terminar o trabalho.
O cérebro continua importante. Só que um cérebro sem uma boa estrutura operacional passa boa parte do tempo esperando, repetindo e movimentando informações que nem precisaria ler.
0 comments:
Postar um comentário