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

O dsh é montado a partir de plugins Cordis, por isso uma instância em execução é uma árvore de plugins, não um único programa. Um perfil é uma composição nomeada desses plugins. Os dois templates são web e headless. O $DSH_HOME usa ~/.dsh por padrão, e um perfil fica em $DSH_HOME/profiles/<name>/, onde mantém 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 GitHub como github:PerryLink/dsh-budget#main e um caminho local com link: ou ./. Prefira a forma 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 por uma 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 configurou. Por isso, quando um plugin parece instalado mas não faz nada, abra o cordis.patch.yml do perfil e confirme 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 estava em 0.1.0-rc.7, enquanto os plugins abaixo foram compilados para a linha 0.1.0-rc. dsh-permission-rules e dsh-defend declaram compatibilidade com 0.1.0-rc.5 a 0.1.0-rc.6, dsh-budget declara apenas 0.1.0-rc.6, dsh-memory define apenas intervalos de peers a partir de ^0.1.0-rc.6 e dsh-web-lan-access não declara nenhuma versão do dsh. Em 10 October 2026, a tag latest no npm é 0.2.0-rc.2, por isso a diferença é agora maior do que quando estas versões foram fixadas. 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 a noite inteira?

Um agente num VPS é executado sem supervisão. Esse é o motivo para o instalar ali, mas também é o risco. dsh-budget contabiliza os tokens e o custo estimado por modelo, por sessão e por dia, e aplica limites a esses totais.

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

Os valores predefinidos são elevados: 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 altos para que um ciclo descontrolado termine antes de o limite ser atingido. Por isso, reduza-os logo 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 de utilização real justificar essa alteração. Um limite mensal de 40 USD com um limite por sessão de 2 falha de forma imediata e explícita. É 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, mas continua a permitir gastos. Assim, por predefinição, este plugin funciona como um painel. Defina-o como block para que o harness recuse novas chamadas ao modelo quando um limite for atingido. Deste modo, uma tarefa noturna para em vez de continuar a gerar custos até de manhã. degrade é o terceiro modo. Bloqueia a chamada e apresenta instruções com o nome de um modelo mais barato do mapa degradation. É adequado quando uma tarefa tem de terminar, mas não precisa do seu melhor modelo. warnRatio tem o valor predefinido 0.8. Assim, recebe um aviso quando atingir 80 por cento do limite.

Há duas limitações importantes. O custo é calculado a partir de uma tabela de preços incorporada, combinada com os preços que fornecer. O maintainer avisa que os preços incorporados podem ficar desatualizados. prices está vazio por predefinição. No commit fixado 461d478, defaultPrice, o valor de fallback para um modelo que não esteja em nenhuma das tabelas, é 1.0 USD por milhão de tokens de entrada e 3.0 por milhão de tokens de saída. Na versão atual de main, verificada em 10 October 2026, o valor predefinido é zero e o modelo aparece como sem preço. Preencha os valores reais dos seus modelos. Caso contrário, o painel será uma estimativa apresentada como medição.

A segunda limitação é que, em 461d478, o plugin agrega os dados 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 ciclo de falha, ou um supervisor que reinicie dsh, também repõe um limite diário. A versão atual de main mantém os intervalos diário e mensal por predefinição (persistence.enabled: true, com uma captura a cada 10 segundos) e restaura-os no arranque. Assim, um reinício já não elimina um limite diário ou mensal nessa versão, desde que o harness forneça o domínio de armazenamento. Sem esse domínio, a agregação continua limitada ao processo. main também se destina à linha de harness 0.2. Por isso, alterar o commit fixado implica alterar também o harness. Em qualquer caso, trate dsh-budget como uma proteção contra as suas próprias tarefas. Mantenha um limite de gastos na conta do fornecedor como teto efetivo. Esse é o ponto mais amplo explicado em controlar o custo de agentes de IA num 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 remover 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 tools/pre-execute, por isso uma regra é avaliada antes de uma ferramenta ser executada. Existem três ações. allow deixa a chamada prosseguir, 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 relativamente 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 cancela silenciosamente todas as regras mais específicas abaixo dele. Escreva primeiro as recusas e deixe as regras permissivas para o fim. O globo do nome da ferramenta abrange mcp__*. É assim que pode controlar ferramentas fornecidas por um servidor de model context protocol (MCP), em vez de pelo próprio harness. Isto é importante assim que começa a executar servidores MCP numa VPS.

É preciso planear um comportamento: ask precisa de um respondente. Num perfil headless, pode não estar ninguém a observar a sessão. Um ask sem resposta não espera que alguém apareça: sem um respondente configurado, a cadeia de aprovação do harness falha de forma segura e a chamada é recusada. Num sistema não supervisionado, uma regra ask comporta-se, portanto, como um deny que não escreveu intencionalmente. Use deny para tudo o que nunca aprovaria, mantenha ask no perfil que está a supervisionar e, se quiser que as aprovações funcionem sem supervisã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ã?

Dois plugins diferentes são chamados dsh-memory, o que é importante saber antes de executar um comando de instalação. Instale a partir de uma origem explícita para obter aquele que leu.

Num servidor pequeno, eu usaria a versão com SQLite. Ela é registada como memory, mantém um 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 no texto e nas etiquetas armazenadas. Não existe nenhum serviço de embeddings, nenhuma chave de API e nenhum processo adicional.

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

A configuração que irá alterar é pequena: path define o ficheiro da base de dados, promptRecentCount (predefinição 10) define quantas memórias não fixadas são injetadas e promptMaxChars (predefinição 2000) define o orçamento de renderização. O plugin depende de node:sqlite, que o Node 22 e 24 ainda classificam 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. promptMaxChars é o limite superior da secção renderizada, não uma quantidade fixa. No entanto, quando as memórias armazenadas ocuparem esse limite, um orçamento de 2000 caracteres representará algumas centenas de tokens de entrada adicionais em todos os pedidos, para sempre. Esse custo aparece efetivamente na fatura. É por isso que dsh-budget deve estar configurado na máquina antes de dsh-memory. Mantenha promptMaxChars baixo e faça a limpeza com memory_forget, em vez de deixar o ficheiro crescer.

A versão alternativa armazena as memórias num ficheiro YAML e faz pesquisa por embeddings com injeção automática no prompt. É instalada com dsh plugin --profile web add github:towzai/dsh-memory. A pesquisa por embeddings precisa de uma instância local do ollama e de um modelo de embeddings, qwen3-embedding:0.6b por predefinição, substituível por DSH_MEMORY_EMBED_MODEL. Sem o ollama, recorre a uma pesquisa apenas por palavras-chave. A recuperação semântica é melhor do que a recuperação por palavras-chave. Isso também significa executar um segundo serviço e manter um conjunto de pesos de modelo no mesmo servidor. Num plano pequeno, essa memória é retirada do trabalho para o qual alugou a máquina. Escolha esta opção quando tiver RAM disponível. O compromisso geral entre a qualidade da recuperação e o custo de manter os recursos residentes é 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 navegadores só expõem crypto.randomUUID() num contexto seguro, por isso carregar essa mesma página por HTTP simples a partir de outra máquina falha. dsh-web-lan-access corrige o problema através de webServer.tapIndex para injetar um pequeno polyfill e altera a ligação do servidor para 0.0.0.0.

Leia o aviso próprio antes de o instalar. No commit citado aqui, e27e909, o README indicava que configurar a ligação em 0.0.0.0 tornava o agente acessível sem autenticação por qualquer pessoa na mesma rede local (LAN) e, num servidor com um endereço IP público, por toda a internet. Apenas uma lista curta de métodos sensíveis (settings.*, credentials.*, llm.discoverModels) ficava limitada ao loopback e devolvia 403 quando chamada a partir de origens remotas. Isso mudou. As builds atuais do harness, verificadas em 10 October 2026, autenticam o navegador: o token de lançamento incluído no URL impresso é trocado por um cookie de sessão assinado, exigido por todas as rotas da Host API e por todos os streams. O README atual do plugin chama a trustedHosts uma barreira Origin/Host, não uma identidade, indica que configurar a ligação em 0.0.0.0 expõe a superfície de autenticação em todas as interfaces acessíveis e agora ativa definições baseadas em Host para uma página remota autenticada. Assim, nas builds atuais, um navegador remoto com sessão iniciada também pode aceder às definições da Host. O risco mudou, mas não desapareceu: qualquer pessoa que consiga alcançar a porta pode testar o início de sessão, o URL impresso é uma credencial por si só e, através de HTTP simples, esse token atravessa a rede em texto claro.

Na maioria dos casos, não precisa deste plugin. Encaminhe a porta através de SSH.

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

Depois, abra http://127.0.0.1:3080 no seu navegador local. O harness continua a escutar apenas no loopback, por isso nada fica exposto. Como os navegadores 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 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 tiver 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 utilizar em trustedHosts na entrada web-runtime. Para acesso real de vários utilizadores, existe dsh-passwords. Esta opção acrescenta 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 cifrado. 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 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 consultei e quando

Todas as referências aqui são commits, não branches, porque main conterá código diferente quando você ler isto. Consultei todo o conteúdo em 17 de agosto de 2026, e o próprio harness estava em 0.1.0-rc.7 no npm nesse dia. Verifiquei novamente os padrões e o comportamento descritos acima nas fontes primárias em 10 de outubro de 2026, quando a tag latest no npm era 0.2.0-rc.2.

Verifique novamente esses pins antes de copiar um comando. Em um ecossistema em prévia para desenvolvedores, um número de versão acompanhado de uma data é o único tipo que tem significado.

FAQ

Quais plugins do DeepSeek Harness devo instalar primeiro numa VPS?

Instale dsh-budget e dsh-permission-rules antes de qualquer outro. 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 ler conteúdo da web pública e dsh-memory quando der por si 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 funcionamento 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 ligado a tools/pre-execute vê e pode bloquear todas as chamadas de ferramentas; um plugin ligado a agent/pre-step vê 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 mude sem o seu conhecimento.

O dsh-budget vai realmente parar o agente ou apenas avisar-me?

Isso depende de overLimit. O valor predefinido é alert, que avisa em warnRatio e continua a gastar. block recusa novas chamadas ao modelo quando o limite é atingido, e /budget unblock <scope> remove o bloqueio quando escolher continuar. degrade bloqueia e apresenta instruções com o nome de um modelo mais barato do mapa degradation. Existe uma limitação importante: no commit fixado 461d478, os totais são agregados no processo em execução. Reiniciar o harness repõe esses totais, e um ciclo de reinício pode contornar um limite diário. A versão atual main mantém os intervalos diário e mensal entre reinícios por predefinição. Em qualquer caso, mantenha um limite de gastos na conta do fornecedor como teto efetivo.

Como removo completamente um plugin dsh?

Execute dsh plugin --profile web remove <package-name>, confirme com dsh plugin --profile web list e abra $DSH_HOME/profiles/web/cordis.patch.yml. Apague 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 disponíveis depois da desinstalação, até os apagar manualmente.

É seguro expor a interface web do dsh na rede?

Não sem medidas adicionais. dsh web escuta em 127.0.0.1:3080, e dsh-web-lan-access altera essa ligação para 0.0.0.0. No commit citado aqui, o README indicava que isso tornava o agente acessível sem autenticação a qualquer pessoa na mesma rede, com apenas settings.*, credentials.* e llm.discoverModels limitados à interface de loopback. As versões atuais do harness, verificadas em 10 October 2026, autenticam a sessão do navegador com o token de lançamento incluído no URL apresentado e um cookie de sessão assinado. No entanto, a superfície de login fica exposta em todas as interfaces, e um URL HTTP simples envia esse token em texto não cifrado. 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. Mantenha TLS à frente de tudo o que seja acessível a partir do exterior.