O DeepSeek Harness está a evoluir de uma aplicação de agentes convencional para um ambiente de execução componível, no qual modelos, ferramentas, competências, sessões, sandboxes, armazenamento, ciclos, agendamento e interface são extensões. O projeto continua em pré-visualização para programadores, mas a linha 0.1.7 alpha torna esta arquitetura mais operacional: as dependências são resolvidas em execução, o Plugin Manager suporta remoção de extensões durante a execução e o modo Creator passa a usar o mesmo mecanismo para instalar extensões persistentes.
A mudança é relevante porque o harness começa a comportar-se como um verdadeiro ambiente de execução do agente. A flexibilidade aumenta, mas compatibilidade, proveniência e ciclo de vida das extensões passam a fazer parte do plano de controlo.
«Tudo é uma extensão» ganha consequências práticas
A DeepSeek descreve o Harness como um runtime assente no Cordis. As capacidades principais vivem em extensões. O modo Standard inclui o conjunto completo de ferramentas. O modo Code expõe operações através de um SDK para permitir que o modelo combine vários passos. O modo Minimal reduz o ambiente para benchmarks. O modo Creator serve para inspecionar a execução e construir novas composições.
Na série 0.1.7 alpha, as dependências passam a usar resolução em runtime e o Plugin Manager pode descarregar extensões. O modo Creator deixa os antigos mecanismos de definição dinâmica e instala extensões persistentes através do Plugin Manager. A CLI também consegue iniciar diretamente um profile identificado.
Isto aproxima o Harness de uma plataforma configurável e afasta-o de um agente empacotado de forma estática.
A composição dinâmica altera os modos de falha
Num pacote estático, o contrato de arranque é simples: as dependências carregam ou a aplicação falha. Num runtime componível existem mais estados. Uma extensão pode estar instalada mas inativa, ser carregada posteriormente ou ser removida enquanto outro serviço depende dela.
A análise da Aipolix é que as equipas devem tratar o grafo de extensões como estado de produção. Convém registar as extensões e versões ativas em cada execução, testar alterações de dependências antes de rollout e tornar visíveis os eventos de carregamento e remoção. Caso contrário, duas sessões com o mesmo modelo e instrução podem comportar-se de forma diferente apenas porque a composição do harness mudou.
Isto é especialmente importante para reprodutibilidade. A DeepSeek afirma que o que o modelo vê, chamadas de ferramentas, agendamento de subagentes e injeções de contexto ficam registados num session log apenas de anexação. A trace só é completa se a configuração que a produziu também puder ser recuperada.
Mudanças de sessão mostram que a plataforma ainda está em movimento
A mesma família de versões altera formatos de sessão, comportamento de subagentes e APIs de extensões. O projeto documenta migrações para novos formatos e define limites por defeito para o número de filhos ativos e profundidade de delegação em cadeias de subagentes continuáveis.
São mudanças normais numa pré-visualização para programadores, mas demonstram que a superfície de extensão ainda não está estabilizada. Quando sessões persistidas, profiles, presets e APIs mudam a ritmos diferentes, operar um ecossistema de extensões torna-se mais difícil.
Por isso, é prudente fixar versões e testar atualizações com sessões reais e extensões próprias antes de alterar ambientes partilhados. Uma versão alpha é adequada para explorar arquitetura, não para assumir compatibilidade entre versões.
Separar o modelo do harness é a ideia mais valiosa
A arquitetura separa a capacidade do modelo da infraestrutura que lhe permite agir. Ferramentas, sandbox, estado de sessão, agendamento e orquestração não ficam presos a uma implementação específica do modelo.
Esta separação facilita comparar modelos no mesmo ambiente e trocar componentes de infraestrutura. Também cria um ponto mais claro para aplicar políticas de permissões, armazenamento, rede e acesso a ferramentas.
A contrapartida é que o harness passa a ocupar uma parte maior da base de confiança. Uma extensão que altera ferramentas, armazenamento ou agendamento pode mudar a autoridade do agente. A proveniência da extensão e os limites das suas permissões passam a ser tão importantes como a escolha do modelo.
0.1.7 continua a ser pre-release
O GitHub assinala a linha 0.1.7 como pre-release. A alpha mais recente inclui correções de descoberta de modelos e reconexão Web, enquanto a versão anterior introduz alterações mais estruturais no runtime e nos plugins.
Este estado deve ser levado a sério. Harness é interessante para avaliar um runtime componível, criar extensões experimentais e estudar traces de sessão, mas não significa que API e migrações estejam congeladas.
O que deve ser testado
Uma avaliação pode começar com um profile pequeno e fixo, contendo modelo, ferramentas e armazenamento conhecidos. Depois, deve comparar traces antes e depois de uma mudança controlada de extensão e testar carregamento, remoção, recuperação após reinício, migração de sessões e fronteiras de permissões.
O DeepSeek Harness 0.1.7 é relevante porque torna o próprio harness mais programável. A oportunidade é experimentar arquiteturas de agentes mais rapidamente; a exigência de engenharia é aplicar à composição dinâmica a mesma disciplina de versões, observabilidade e controlo de mudanças usada nas dependências normais de software.