5 plugins do DeepSeek Harness que valem instalar

Quais plugins do DeepSeek Harness vale a pena instalar

Os plugins do DeepSeek Harness são código de terceiros executado dentro do seu agente, com os privilégios do agente, numa máquina pela qual você paga. A lista da comunidade inclui mais de vinte categorias e mais de mil entradas. Num servidor privado virtual (VPS) alugado, você precisa de cinco: dsh-budget para limitar despesas, dsh-permission-rules para controlar o acesso às ferramentas, dsh-defend para detetar injeções e verificar segredos, dsh-memory para factos que persistem além de uma sessão e dsh-web-lan-access apenas depois de decidir como fará a autenticação.

O harness é dsh, o harness de agente de código aberto do DeepSeek, criado para que tudo seja um plugin. O README do projeto chama-lhe uma prévia para programadores e avisa THERE WILL BE COMPATIBILITY-BREAKING CHANGES. Esse facto determina todas as escolhas abaixo. Fixe as versões do que instalar, espere que uma atualização possa causar incompatibilidades e mantenha o conjunto pequeno o suficiente para conseguir ler todo o código. Se o harness ainda não estiver a ser executado, comece por instalar o DeepSeek Harness num VPS e volte aqui. Se ainda não estiverem claros os componentes aos quais estes plugins se ligam — o ciclo do agente, as suas ferramentas e a sua memória — comece pelos fundamentos, porque será mais fácil avaliar cada escolha depois de perceber o que cada camada faz.

Como o dsh instala um plugin e onde a configuração fica

dsh monta-se a partir de plugins Cordis, por isso uma instância em execução é uma árvore de plugins, e não um único programa. Um perfil é uma composição nomeada desses plugins. Os dois modelos são web e headless. $DSH_HOME usa ~/.dsh por predefinição, e um perfil fica em $DSH_HOME/profiles/<name>/, contendo o seu próprio package.json, um manifesto dsh.profile e um cordis.patch.yml.

dsh plugin --profile web list
dsh plugin --profile web add dsh-budget
dsh plugin --profile web remove dsh-budget

Há quatro formas de origem: o nome simples de um pacote npm, um nome com escopo como @towzai/dsh-memory, uma referência do GitHub como github:PerryLink/dsh-budget#main e um caminho local com link: ou ./. Prefira a forma do GitHub, porque pode substituir #main por um commit e obter o mesmo código no próximo mês.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

As camadas são aplicadas numa ordem fixa: cada bundle pela ordem indicada no perfil, depois o cordis.patch.yml do perfil, depois o cordis.patch.yml ao nível do diretório pessoal e, por fim, qualquer overlay --patch. A ordem é importante porque uma camada posterior pode reconfigurar ou remover o que uma camada anterior definiu. Por isso, quando um plugin parece instalado, mas não faz nada, abra o cordis.patch.yml do perfil e verifique duas coisas: se o bloco de inserção está presente e se nenhuma camada posterior o desativa.

Em 17 August 2026, o pacote npm @deepseek-ai/dsh está em 0.1.0-rc.7, enquanto todos os plugins abaixo declaram compatibilidade com 0.1.0-rc.5 a 0.1.0-rc.6. Essa diferença é normal neste ecossistema e é a razão habitual para um plugin deixar de carregar: o harness avança mais depressa do que os plugins à sua volta. Atualize o harness de forma deliberada e teste um plugin de cada vez.

Leia um plugin antes de confiar nele

Um plugin do dsh não fica isolado do harness. Ele é carregado na mesma árvore Cordis, no mesmo processo e com o mesmo utilizador do sistema operativo, com acesso às mesmas credenciais do modelo e à mesma árvore de trabalho. Instalar um plugin é mais próximo de executar o script de outra pessoa com sudo do que de adicionar uma extensão ao navegador. Essa é a mesma questão de confiança que os plugins do Claude Code levantam, e a resposta é a mesma: leia o código ou não o instale.

Verifique quatro pontos, nesta ordem:

• Quais pontos de extensão ele utiliza. tools/pre-execute significa que ele vê todas as chamadas de ferramentas e pode bloqueá-las. agent/pre-step significa que ele vê as suas mensagens. webServer.tapIndex significa que ele reescreve a página servida ao seu navegador. Um plugin que não utiliza nenhum desses pontos pode fazer muito pouco; um plugin que utiliza todos eles é a sua fronteira de segurança.
• Se comunica com a rede. Procure no código-fonte por fetch, http e qualquer nome de host definido diretamente no código. Um medidor de custos que comunica com um servidor externo envia o seu padrão de utilização para algum lugar.
• Se lê credenciais. Qualquer componente que aceda a credentials.* ou a uma chave de provider precisa de uma justificação explícita no README.
• A licença e a data do último commit. Um plugin sem licença e sem alterações há meses, num ecossistema que muda semanalmente, representa um risco.

Depois, instale por commit, não por branch, e leia o bloco de inserção que o instalador escreveu em cordis.patch.yml. Esse bloco identifica o plugin e a configuração que ele registou. É a descrição mais curta e honesta do que acabou de adicionar. Mantenha as chaves de provider fora do alcance do plugin quando o harness permitir, seguindo a orientação de manter segredos fora dos agentes de IA.

dsh-budget: como impedir que um agente gaste toda a noite?

Um agente numa VPS é executado sem supervisão. Esse é o objetivo de o colocar lá, mas também é o risco. dsh-budget contabiliza tokens e o custo estimado por modelo, por sessão e por dia, e impõe limites sobre esses totais.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

Os valores predefinidos são generosos: 10 USD por sessão, 50 por dia e 500 por mês. São adequados para uma equipa com orçamento. Num servidor pessoal, são suficientemente elevados para que um loop descontrolado termine antes de o limite ser atingido. Por isso, reduza-os no primeiro dia.

[
  {
    "label": "Per session",
    "plugin_default_usd": 10,
    "suggested_start_usd": 2
  },
  {
    "label": "Per day",
    "plugin_default_usd": 50,
    "suggested_start_usd": 5
  },
  {
    "label": "Per month",
    "plugin_default_usd": 500,
    "suggested_start_usd": 40
  }
]

A coluna sugerida é um ponto de partida para um operador numa máquina, não um valor publicado. Aumente-a quando um mês real de utilização o justificar. Um limite mensal de 40 USD com um limite por sessão de 2 falha de forma explícita e rápida. É isso que pretende enquanto ainda está a avaliar o consumo da ferramenta.

- id: budget
  config:
    budgets:
      session: 2
      daily: 5
      monthly: 40
    warnRatio: 0.8
    overLimit: block

A definição que altera o comportamento da máquina é overLimit. O valor predefinido é alert. Este valor apresenta um aviso e continua a gastar, pelo que, sem alterações, este plugin funciona como um painel. Defina-o como block. O harness recusa novas chamadas ao modelo quando um limite é atingido. Assim, um trabalho noturno para em vez de continuar a gerar custos até de manhã. degrade é o terceiro modo. Substitui o modelo por um modelo mais barato do mapa degradation. É adequado quando um trabalho tem de terminar, mas não precisa do seu melhor modelo. warnRatio tem 0.8 como valor predefinido, pelo que recebe um aviso quando atinge 80 por cento do limite.

Há dois limites importantes. O custo é calculado com base nos preços que fornece: prices está vazio por predefinição e defaultPrice usa 1.0 USD por milhão de tokens de entrada e 3.0 por milhão de tokens de saída. Introduza os valores reais dos seus modelos. Caso contrário, o painel será apenas uma estimativa apresentada como medição. Em segundo lugar, o plugin agrega os valores no processo em execução a partir do fluxo de eventos da sessão. Por isso, os totais são repostos quando o harness reinicia. Um loop de falhas ou um supervisor que reinicie dsh repõe um limite diário. Considere dsh-budget uma proteção contra os seus próprios trabalhos e mantenha um limite de gastos na conta do fornecedor como teto efetivo. Esse é o argumento mais abrangente em controlar os custos de um agente de IA numa VPS.

No dia a dia, use /budget para a visão geral, /budget models para a discriminação por modelo e /budget unblock <scope> para levantar um bloqueio depois de decidir continuar.

regras de permissões do dsh: que chamadas de ferramentas nunca devem ser executadas?

dsh-permission-rules coloca regras declarativas no fluxo de tools/pre-execute, por isso uma regra é avaliada antes da execução de uma ferramenta. Existem três ações. allow deixa a chamada passar, deny bloqueia-a e devolve um motivo que o modelo pode ler, e ask encaminha-a para o mecanismo oficial de aprovação.

dsh plugin --profile web add "github:PerryLink/dsh-permission-rules#b30b4fb"

As regras ficam em .dsh/rules.yaml, relativo ao diretório de trabalho da sessão, com um fallbackPath global e um searchUp opcional para subir em direção à raiz do sistema de ficheiros. A correspondência abrange globos de nomes de ferramentas, globos de chaves e valores de parâmetros, globos de caminhos relativos ao workspace, seletores de agentes como main ou subagent e destinos de rede.

rules:
  - match: { tools: [bash], params: { command: "rm -rf*" } }
    action: deny
    reason: "No recursive deletes"
  - match: { tools: [edit, write], paths: ["**/.env*", "**/secrets/**"] }
    action: ask
    reason: "Secret files need confirmation"
  - match: { tools: ["mcp__*"] }
    action: ask
    reason: "MCP tools need confirmation"

A avaliação para na primeira correspondência, por isso um allow abrangente perto do início pode cancelar silenciosamente todas as regras mais específicas abaixo dele. Escreva primeiro as negações e deixe as regras permissivas para o fim. O glob do nome da ferramenta abrange mcp__*. É assim que pode controlar ferramentas fornecidas por um servidor de protocolo de contexto de modelo (MCP), em vez de pelo próprio harness. Isto é importante assim que começa a executar servidores MCP numa VPS.

Há um comportamento que deve ser planeado: ask precisa de alguém para responder. Num perfil headless, pode não estar ninguém a observar, pelo que uma regra ask pode manter uma execução suspensa até alguém aparecer. Use deny para tudo o que nunca aprovaria, mantenha ask para o perfil que acompanha diretamente e, se quiser que as aprovações funcionem sem intervenção, precisa de um caminho real para responder. Esse é o tema de controlar ações de agentes de IA com aprovações.

dsh-defend: e a injeção de prompts e o vazamento de segredos?

dsh-defend faz verificações em três pontos: mensagens recebidas em agent/pre-step, argumentos de ferramentas em tools/pre-execute, incluindo uma proteção contra exclusões destrutivas, e resultados das ferramentas em tools/post-execute. Este último ponto é o mais interessante, porque é onde o conteúdo obtido de uma página Web é analisado antes de o modelo agir sobre ele.

dsh plugin --profile web add "github:PerryLink/dsh-defend#7ba3427"

As predefinições são cautelosas, não rigorosas: detection.injectionAction, detection.jailbreakAction e detection.secretAction são todas ask, enquanto detection.secretBlockCritical é true. Assim, um segredo crítico é bloqueado independentemente das outras definições. Num servidor sem supervisão, altere para block as ações que pretende controlar, porque ask sem ninguém a quem perguntar não é uma decisão.

O desenho da auditoria merece reconhecimento. Os eventos defend/detection registam o ID da regra, a família, a categoria, a gravidade, a decisão e os dados da análise, mas nunca o texto correspondente. Os segredos são registados apenas pelo tipo. Assim, ativar o log de auditoria não cria uma segunda cópia da credencial que estava a tentar proteger.

É importante compreender o que isto proporciona. A deteção baseia-se em regras, e o README afirma claramente que formulações novas e ataques em várias etapas podem passar por ela. Isto reduz a frequência dos ataques óbvios. Não torna seguro apontar um agente para conteúdo não fiável. Por isso, mantenha as regras de permissões subjacentes.

dsh-memory: o que o agente recorda amanhã?

Existem dois plugins diferentes com o nome dsh-memory. É importante saber isto antes de executar um comando de instalação. Instale usando a origem explicitamente, para obter o plugin sobre o qual leu.

A opção que eu usaria num servidor pequeno é a compilação SQLite. Ela é registada como memory, mantém um único ficheiro em $DSH_HOME/memory/memory.db, partilhado entre perfis, e disponibiliza memory_write, memory_search e memory_forget. A pesquisa é baseada em palavras-chave sobre o texto e as etiquetas armazenados. Não existe um serviço de embeddings, uma chave de API ou um processo adicional.

dsh plugin --profile web add "github:ben7am1n/dsh-memory#def7c6a"

A configuração que irá alterar é pequena: path para o ficheiro da base de dados, promptRecentCount (por predefinição, 10) para o número de memórias não fixadas que são injetadas e promptMaxChars (por predefinição, 2000) para o orçamento de renderização. Ela depende de node:sqlite, que Node 22 e 24 continuam a marcar como experimental. Por isso, uma atualização do Node deve ser testada, não presumida como segura.

Eis o que a memória realmente altera na máquina: as memórias injetadas são incluídas no prompt do sistema em cada interação. Um orçamento de 2000 caracteres representa algumas centenas de tokens de entrada adicionais em cada pedido, permanentemente. Esse custo aparece efetivamente na fatura. É por isso que dsh-budget deve estar disponível no servidor antes de dsh-memory. Mantenha promptMaxChars reduzido e faça a limpeza com memory_forget, em vez de deixar o ficheiro crescer.

A compilação alternativa armazena as memórias num ficheiro YAML e faz pesquisas por embeddings com injeção automática no prompt. É instalada com dsh plugin --profile web add github:towzai/dsh-memory. Precisa de uma instância local do ollama e de um modelo de embeddings, qwen3-embedding:0.6b por predefinição, que pode ser substituído por DSH_MEMORY_EMBED_MODEL. A recuperação semântica é melhor do que a recuperação por palavras-chave. Também implica um segundo serviço e um conjunto de pesos de modelo residentes no mesmo servidor. Num plano pequeno, isso consome memória que deveria estar disponível para o trabalho para o qual alugou o servidor. Escolha esta opção quando tiver RAM disponível. O compromisso geral entre a qualidade da recuperação e o custo de memória residente é explicado em memória local para agentes.

dsh-web-lan-access: a interface web deve escutar além do loopback?

npx @deepseek-ai/dsh web disponibiliza a interface em 127.0.0.1:3080. Os browsers só expõem crypto.randomUUID() num contexto seguro, por isso abrir essa mesma página por HTTP simples a partir de outra máquina falha. dsh-web-lan-access corrige o problema ao usar webServer.tapIndex para injetar um pequeno polyfill e altera a ligação do servidor para 0.0.0.0.

Leia o aviso do próprio componente antes de o instalar. Associar 0.0.0.0 torna o agente acessível sem autenticação a qualquer pessoa na mesma rede local (LAN). Num servidor com um endereço IP público, isso significa toda a internet. Uma lista curta de métodos sensíveis (settings.*, credentials.*, llm.discoverModels) continua limitada ao loopback e devolve 403 a partir de origens remotas, o que reduz os danos. Não os impede, porque a superfície de chamadas de ferramentas continua aberta a quem encontrar a porta.

Na maioria dos casos, não precisa deste plugin. Encaminhe a porta por SSH.

ssh -N -L 3080:127.0.0.1:3080 you@your-server

Depois, abra http://127.0.0.1:3080 no browser local. O harness continua a escutar apenas no loopback, por isso nada fica exposto. Além disso, como os browsers tratam 127.0.0.1 como uma origem segura, crypto.randomUUID() fica disponível e não é necessário nenhum polyfill. Um comando, sem plugin e sem criar uma nova superfície de ataque.

Instale o plugin apenas quando um encaminhamento não for suficiente, por exemplo, quando um telemóvel na mesma rede precisar de aceder à interface. Nesse caso, associe-o a uma interface de rede privada, mantenha uma regra de firewall que permita apenas essa interface e indique os nomes que vai usar em trustedHosts na entrada web-runtime. Para acesso genuíno por vários utilizadores, existe dsh-passwords. Este componente adiciona permissões para subutilizadores, limites horários de tokens por subutilizador e limites diários de tempo, certificados TLS (transport layer security) automáticos através do Let's Encrypt e um log de auditoria encriptado. Avalie-o como uma plataforma, não como um plugin: precisa das portas 80 e 443, inclui o seu próprio instalador e o procedimento rápido documentado envia um script de shell da rede diretamente para bash. Prefira npm install -g dsh-passwords seguido de dsh-passwords install, para que o código fique no disco e possa ser lido antes de ser executado.

Como remover um plugin corretamente

A desinstalação tem duas etapas, mas muitas pessoas ignoram a segunda.

dsh plugin --profile web remove dsh-budget
dsh plugin --profile web list

list já não deve apresentá-lo. Em seguida, abra $DSH_HOME/profiles/web/cordis.patch.yml e elimine qualquer bloco de inserção restante que identifique esse plugin, porque é essa entrada que o carrega na árvore. Reinicie o harness para reconstruir a árvore; um plugin já carregado continua carregado até fazer isso. Por fim, lembre-se de que os dados sobrevivem ao código. $DSH_HOME/memory/memory.db e .dsh/rules.yaml permanecem depois da desinstalação. Elimine-os manualmente se o objetivo era remover os dados.

O que li e quando

Todas as referências aqui apontam para um commit, não para uma branch, porque main conterá código diferente quando você ler isto. Li tudo em 17 August 2026, e o próprio harness estava em 0.1.0-rc.7 no npm nesse dia.

Verifique novamente esses pins antes de copiar um comando. Num ecossistema em developer preview, um número de versão acompanhado de uma data é o único tipo que tem significado.

FAQ

Que plugins do DeepSeek Harness devo instalar primeiro num VPS?

Instale dsh-budget e dsh-permission-rules antes de qualquer outra coisa. Um orçamento com overLimit: block impede que uma execução não supervisionada gaste durante toda a noite, e um ficheiro .dsh/rules.yaml impede uma chamada de ferramenta que nunca teria aprovado. Adicione dsh-defend quando o agente começar a ler conteúdo da Web pública e dsh-memory quando notar que está a colar o mesmo contexto em todas as sessões. Ignore os temas e os indicadores de estado: acrescentam código executado com os privilégios do agente sem alterar o comportamento da máquina.

Os plugins do dsh estão isolados do harness?

Não. Um plugin é carregado na mesma árvore Cordis que o harness, no mesmo processo, com o mesmo utilizador do sistema operativo, as mesmas credenciais do modelo e a mesma árvore de trabalho. Um plugin que intercepte tools/pre-execute consegue ver e bloquear todas as chamadas de ferramentas; um plugin que intercepte agent/pre-step consegue ver as suas mensagens. Por isso, leia o código-fonte, verifique a licença e a data do último commit e instale por commit, não por branch, para impedir que o código seja alterado sem o seu conhecimento.

O dsh-budget vai realmente parar o agente ou apenas emitir um aviso?

Isso depende de overLimit. O valor predefinido é alert, que emite um aviso em warnRatio e continua a gastar. block recusa novas chamadas ao modelo quando o limite é atingido, e /budget unblock <scope> remove esse bloqueio quando decide continuar. degrade muda para um modelo mais barato a partir do mapa degradation. Existe uma limitação importante: os totais são agregados no processo em execução a partir do fluxo de eventos da sessão. Por isso, reiniciar o harness repõe os totais, e um ciclo de reinícios pode contornar um limite diário. Mantenha um limite de gastos na conta do fornecedor como limite efetivo.

Como removo completamente um plugin do dsh?

Execute dsh plugin --profile web remove <package-name>, confirme com dsh plugin --profile web list, abra $DSH_HOME/profiles/web/cordis.patch.yml e elimine qualquer bloco de inserção restante desse plugin, porque é essa entrada que o carrega. Reinicie o harness para reconstruir a árvore de plugins. Os dados escritos pelo plugin permanecem no disco: $DSH_HOME/memory/memory.db e .dsh/rules.yaml continuam a existir depois da desinstalação, até os eliminar manualmente.

É seguro expor a interface Web do dsh na rede?

Não sem configuração adicional. dsh web escuta em 127.0.0.1:3080, e dsh-web-lan-access altera essa ligação para 0.0.0.0. O README do próprio plugin indica que isto torna o agente acessível sem autenticação a qualquer pessoa na mesma rede; num endereço IP público, isso significa toda a Internet. Alguns métodos (settings.*, credentials.*, llm.discoverModels) continuam limitados ao loopback e devolvem 403 para origens remotas, o que reduz os danos sem impedir completamente o acesso. Use um encaminhamento de porta SSH, ssh -N -L 3080:127.0.0.1:3080 you@your-server, ou coloque a porta atrás de uma interface de rede privada e de uma regra de firewall. Adicione autenticação real antes de permitir qualquer acesso externo.