5 plugins de DeepSeek Harness para un VPS

Qué plugins de DeepSeek Harness merece la pena instalar

Los plugins de DeepSeek Harness son código de terceros que se ejecuta dentro de su agente, con los privilegios de este, en una máquina que usted paga. La lista de la comunidad incluye más de veinte categorías y más de mil entradas. En un servidor privado virtual (VPS) alquilado necesita cinco: dsh-budget para limitar el gasto, dsh-permission-rules para controlar el acceso a las herramientas, dsh-defend para detectar inyecciones y secretos, dsh-memory para conservar datos que sobreviven a una sesión y dsh-web-lan-access sólo después de decidir cómo se autenticará.

El harness es dsh, el harness de agentes de código abierto de DeepSeek, diseñado para que todo sea un plugin. Su propio README lo presenta como una versión preliminar para desarrolladores y advierte THERE WILL BE COMPATIBILITY-BREAKING CHANGES. Ese hecho determina todas las decisiones siguientes. Fije las versiones de lo que instale, cuente con que una actualización pueda romperlo y mantenga el conjunto lo bastante pequeño como para poder revisarlo completo. Si el harness todavía no está en ejecución, empiece por instalar DeepSeek Harness en un VPS y vuelva aquí.

Cómo instala dsh un plugin y dónde se guarda la configuración

dsh se ensambla a partir de plugins de Cordis, por lo que una instancia en ejecución es un árbol de plugins y no un único programa. Un perfil es una composición con nombre de esos plugins. Las dos plantillas son web y headless. $DSH_HOME usa ~/.dsh de forma predeterminada, y un perfil se encuentra en $DSH_HOME/profiles/<name>/. Contiene su propio package.json, un manifiesto dsh.profile y un cordis.patch.yml.

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

Se admiten cuatro formas de origen: el nombre simple de un paquete npm, un nombre con ámbito como @towzai/dsh-memory, una referencia de GitHub como github:PerryLink/dsh-budget#main y una ruta local con link: o ./. Use la forma de GitHub, porque puede sustituir #main por un commit y obtener el mismo código el mes siguiente.

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

Las capas se aplican en un orden fijo: cada bundle en el orden indicado en el perfil, después cordis.patch.yml del perfil, luego cordis.patch.yml del nivel de usuario y, por último, cualquier overlay --patch. El orden importa porque una capa posterior puede reconfigurar o eliminar lo que configuró una capa anterior. Por eso, cuando un plugin parece instalado pero no hace nada, abra cordis.patch.yml del perfil y compruebe dos cosas: que su bloque de inserción esté presente y que ninguna capa posterior lo deshabilite.

A fecha de 17 de agosto de 2026, el paquete npm @deepseek-ai/dsh está en 0.1.0-rc.7, mientras que todos los plugins siguientes declaran compatibilidad con 0.1.0-rc.5 a 0.1.0-rc.6. Esta diferencia es normal en este ecosistema y suele ser la causa de que un plugin deje de cargarse: el harness evoluciona más rápido que los plugins que lo rodean. Actualice el harness de forma deliberada y pruebe un plugin cada vez.

Lee un plugin antes de confiar en él

Un plugin de dsh no está aislado del harness. Se carga en el mismo árbol de Cordis y en el mismo proceso, se ejecuta con el mismo usuario del sistema operativo y tiene acceso a las mismas credenciales del modelo y al mismo árbol de trabajo. Instalar uno se parece más a ejecutar el script de otra persona con sudo que a añadir una extensión del navegador. Es la misma cuestión de confianza que plantean los plugins de Claude Code, y la respuesta también es la misma: lee el código o no lo instales.

Comprueba cuatro aspectos, en este orden:

• A qué puntos de extensión accede. tools/pre-execute significa que puede ver cada llamada a una herramienta y bloquearla. agent/pre-step significa que puede ver tus mensajes. webServer.tapIndex significa que reescribe la página que se sirve al navegador. Un plugin que no accede a ninguno de esos puntos puede hacer muy poco; un plugin que accede a todos ellos es tu límite de seguridad.
• Si se comunica con la red. Busca en el código fuente fetch, http y cualquier nombre de host codificado. Un medidor de costes que envía datos a un servidor externo está enviando tu patrón de uso a algún lugar.
• Si lee credenciales. Cualquier componente que acceda a credentials.* o a una clave de proveedor necesita indicar un motivo explícito en el README.
• La licencia y la fecha del último commit. Un plugin sin licencia y sin cambios durante meses, en un ecosistema que cambia cada semana, supone un riesgo.

Después, instala usando un commit en lugar de una rama y revisa el bloque de inserción que el instalador escribió en cordis.patch.yml. Ese bloque indica el id del plugin y la configuración que registró. Es la descripción más breve y fiable de lo que acabas de añadir. Mantén las claves de proveedor fuera del alcance del plugin cuando el harness lo permita, siguiendo un enfoque similar al de mantener los secretos fuera del alcance de los agentes de IA.

dsh-budget: ¿cómo impido que un agente gaste durante toda la noche?

Un agente en un VPS se ejecuta sin supervisión. Ese es el motivo para instalarlo allí, pero también supone un riesgo. dsh-budget contabiliza los tokens y el coste estimado por modelo, sesión y día, y aplica límites sobre esos totales.

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

Sus valores predeterminados son generosos: 10 USD por sesión, 50 al día y 500 al mes. Son adecuados para un equipo con presupuesto. En un servidor personal son lo bastante altos para que un bucle descontrolado termine antes de que se active el límite, así que redúzcalos el primer día.

[
  {
    "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
  }
]

La columna sugerida es un punto de partida para un operador en un solo equipo, no una cifra publicada. Auméntela cuando un mes real de uso lo justifique. Un límite mensual de 40 USD con un límite por sesión de 2 falla de forma visible y rápida, que es lo que necesita mientras aprende cuánto consume la herramienta.

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

El ajuste que cambia el comportamiento del equipo es overLimit. Su valor predeterminado es alert, que muestra una advertencia y mantiene el gasto, por lo que este plugin funciona como un panel de control de forma predeterminada. Configúrelo como block y el harness rechazará nuevas llamadas al modelo cuando se alcance un límite. Así, un trabajo nocturno se detendrá en lugar de seguir generando cargos hasta la mañana. degrade es el tercer modo: cambia el modelo por otro más barato del mapa degradation. Es adecuado cuando el trabajo debe terminar, pero no necesita el mejor modelo. warnRatio tiene 0.8 como valor predeterminado, por lo que recibirá un aviso al alcanzar el 80 por ciento del límite.

Hay dos limitaciones importantes. El coste se calcula a partir de los precios que proporcione: prices está vacío de forma predeterminada y defaultPrice usa como alternativa 1.0 USD por millón de tokens de entrada y 3.0 por millón de tokens de salida. Introduzca los valores reales de sus modelos. De lo contrario, el panel será una estimación presentada como una medición. En segundo lugar, el plugin agrega los datos en el proceso en ejecución a partir del flujo de eventos de la sesión, por lo que los totales se restablecen cuando se reinicia el harness. Un bucle de fallos, o un supervisor que reinicie dsh, restablece un límite diario. Considere dsh-budget una protección contra sus propios trabajos y mantenga un límite de gasto en la cuenta del proveedor como techo real. Este es el argumento más amplio de controlar el coste de un agente de IA en un VPS.

En el uso diario, utilice /budget para obtener una vista general, /budget models para consultar el desglose por modelo y /budget unblock <scope> para levantar un bloqueo cuando haya decidido continuar.

dsh-permission-rules: ¿qué llamadas de herramientas no deben ejecutarse nunca?

dsh-permission-rules coloca reglas declarativas en el flujo de tools/pre-execute, por lo que una regla se evalúa antes de ejecutar una herramienta. Existen tres acciones. allow deja pasar la llamada, deny la bloquea y devuelve un motivo que el modelo puede leer, y ask la dirige al mecanismo oficial de aprobación.

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

Las reglas se encuentran en .dsh/rules.yaml, relativo al directorio de trabajo de la sesión, con un fallbackPath global y un searchUp opcional para subir hacia la raíz del sistema de archivos. La coincidencia admite patrones glob para nombres de herramientas, patrones glob para claves y valores de parámetros, patrones glob para rutas relativas al espacio de trabajo, selectores de agentes como main o subagent y destinos de red.

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"

La evaluación usa la primera coincidencia, por lo que un allow amplio al principio anula silenciosamente todas las reglas más específicas que aparecen después. Escriba primero las denegaciones y deje las reglas permisivas para el final. El patrón glob del nombre de herramienta cubre mcp__*. Así puede controlar las herramientas proporcionadas por un servidor de protocolo de contexto de modelo (MCP), en lugar de las proporcionadas por el propio arnés. Esto es importante en cuanto ejecuta servidores MCP en un VPS.

Debe prever un comportamiento: ask necesita una persona que responda. En un perfil headless puede que nadie esté observando, por lo que una regla ask puede mantener una ejecución bloqueada hasta que aparezca alguien. Use deny para todo lo que nunca aprobaría, mantenga ask para el perfil que supervisa directamente y, si quiere que las aprobaciones funcionen sin supervisión, necesita un mecanismo real para responder. Este es el tema de controlar las acciones de agentes de IA mediante aprobaciones.

dsh-defend: ¿qué ocurre con la inyección de prompts y los secretos expuestos?

dsh-defend analiza en tres puntos: los mensajes entrantes en agent/pre-step, los argumentos de las herramientas en tools/pre-execute, incluido un bloqueo para eliminaciones destructivas, y los resultados de las herramientas en tools/post-execute. Este último punto es el más interesante, porque es donde se revisa el contenido obtenido de una página web antes de que el modelo actúe sobre él.

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

Los valores predeterminados son prudentes, no estrictos: detection.injectionAction, detection.jailbreakAction y detection.secretAction están todos en ask, mientras que detection.secretBlockCritical está en true, por lo que un secreto crítico se bloquea independientemente de los demás ajustes. En un equipo sin supervisión, cambie a block las acciones que le interesen, porque ask sin nadie a quien consultar no es una decisión.

El diseño de auditoría merece reconocimiento. Los eventos defend/detection registran el identificador de la regla, la familia, la categoría, la gravedad, la decisión y los datos del análisis, pero nunca el texto coincidente; los secretos se registran sólo por tipo. Por tanto, activar el registro de auditoría no crea una segunda copia de la credencial que intentaba proteger.

Tenga claro qué ofrece esto. La detección se basa en reglas, y el README indica claramente que las formulaciones nuevas y los ataques de varios pasos pueden eludirla. Reduce la frecuencia de los ataques obvios. No hace que un agente sea seguro para usarlo con contenido no confiable, así que mantenga las reglas de permisos por debajo de esta capa.

dsh-memory: ¿qué recuerda el agente mañana?

Hay dos plugins diferentes que se llaman dsh-memory. Conviene saberlo antes de escribir un comando de instalación. Instálalo indicando explícitamente el origen para obtener el que has consultado.

El que instalaría en un servidor pequeño es la compilación con SQLite. Se registra como memory, mantiene un único archivo en $DSH_HOME/memory/memory.db compartido entre perfiles y expone memory_write, memory_search y memory_forget. La búsqueda se basa en palabras clave sobre el texto y las etiquetas almacenados. No necesita un servicio de embeddings, una clave de API ni otro proceso.

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

La configuración que tendrás que modificar es pequeña: path para el archivo de base de datos, promptRecentCount (valor predeterminado: 10) para indicar cuántas memorias no fijadas se inyectan y promptMaxChars (valor predeterminado: 2000) para el presupuesto de renderizado. Depende de node:sqlite, que Node 22 y 24 todavía marcan como experimental. Por tanto, una actualización de Node debe probarse, no darse por supuesta.

Esto es lo que la memoria cambia realmente en la máquina: las memorias inyectadas se incluyen en el prompt del sistema en cada turno. Un presupuesto de 2000 caracteres añade varios cientos de tokens de entrada a cada solicitud, de forma permanente. Es un coste real en la factura. Por eso dsh-budget debe estar instalado en el servidor antes que dsh-memory. Mantén promptMaxChars ajustado y depura con memory_forget en lugar de dejar que el archivo crezca.

La compilación alternativa almacena las memorias en un archivo YAML y realiza búsquedas mediante embeddings con inyección automática en el prompt. Se instala con dsh plugin --profile web add github:towzai/dsh-memory. Necesita una instancia local de ollama y un modelo de embeddings, qwen3-embedding:0.6b de forma predeterminada, que puede sustituirse mediante DSH_MEMORY_EMBED_MODEL. La recuperación semántica es mejor que la recuperación por palabras clave. También implica un segundo servicio y un conjunto de pesos del modelo residentes en el mismo servidor. En un plan pequeño, esa memoria se resta de la capacidad disponible para el trabajo que debe realizar el servidor. Elígelo si tienes RAM disponible. El equilibrio general entre la calidad de recuperación y el coste de mantener los recursos residentes se explica en memoria local para agentes.

dsh-web-lan-access: ¿debería la interfaz web escuchar más allá de loopback?

npx @deepseek-ai/dsh web sirve la interfaz en 127.0.0.1:3080. Los navegadores sólo exponen crypto.randomUUID() en un contexto seguro, por lo que cargar esa misma página mediante HTTP sin cifrar desde otra máquina falla. dsh-web-lan-access lo resuelve aprovechando webServer.tapIndex para inyectar un pequeño polyfill y cambia la vinculación del servidor a 0.0.0.0.

Lea su propia advertencia antes de instalarlo. Vincular 0.0.0.0 hace que el agente sea accesible sin autenticación para cualquiera que esté en la misma red de área local (LAN). En un servidor con una dirección IP pública, eso significa todo Internet. Una lista breve de métodos sensibles (settings.*, credentials.*, llm.discoverModels) permanece fijada a loopback y devuelve 403 desde orígenes remotos, lo que limita los daños. No los evita, porque la superficie de llamadas a herramientas sigue abierta a cualquiera que encuentre el puerto.

La mayoría de las veces no necesita este plugin. En su lugar, reenvíe el puerto mediante SSH.

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

Después, abra http://127.0.0.1:3080 en el navegador local. El harness sigue escuchando sólo en loopback, por lo que no se expone nada. Además, como los navegadores tratan 127.0.0.1 como un origen seguro, crypto.randomUUID() está disponible y no se necesita ningún polyfill. Un comando, ningún plugin y ninguna superficie de ataque nueva.

Instale el plugin sólo cuando el reenvío no sea suficiente, por ejemplo, cuando un teléfono de la misma red deba acceder a la interfaz. Si lo hace, vincúlelo detrás de una interfaz de red privada, mantenga una regla del firewall que permita únicamente esa interfaz y enumere los nombres que usará en trustedHosts dentro de la entrada web-runtime. Para un acceso multiusuario real existe dsh-passwords, que añade permisos para subusuarios, cuotas horarias de tokens y cuotas diarias de tiempo por subusuario, certificados TLS (seguridad de la capa de transporte) automáticos mediante Let's Encrypt y un registro de auditoría cifrado. Considérelo una plataforma y no un plugin: necesita los puertos 80 y 443, incluye su propio instalador y el procedimiento rápido documentado canaliza un script de shell desde la red directamente a bash. Prefiera npm install -g dsh-passwords seguido de dsh-passwords install, para que el código quede en el disco y pueda leerlo antes de ejecutarlo.

Cómo eliminar un plugin correctamente

La desinstalación consta de dos pasos, y muchas personas omiten el segundo.

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

list ya no debería mostrarlo. Después, abra $DSH_HOME/profiles/web/cordis.patch.yml y elimine cualquier bloque de inserción restante que mencione ese plugin, porque esa entrada es la que lo carga en el árbol. Reinicie el harness para reconstruir el árbol; un plugin que ya se haya cargado seguirá cargado hasta que lo haga. Por último, recuerde que los datos sobreviven al código. $DSH_HOME/memory/memory.db y .dsh/rules.yaml permanecen después de desinstalar. Elimínelos manualmente si el objetivo era eliminar los datos.

Qué leí y cuándo

Todas las referencias de esta sección apuntan a un commit, no a una rama, porque main contendrá código diferente cuando lea esto. Leí todo el contenido el 17 de agosto de 2026, y el propio harness estaba en 0.1.0-rc.7 en npm ese día.

Vuelva a comprobar esas referencias antes de copiar un comando. En un ecosistema en vista previa para desarrolladores, un número de versión asociado a una fecha es el único que tiene algún significado.

FAQ

¿Qué plugins de DeepSeek Harness debería instalar primero en un VPS?

Instale dsh-budget y dsh-permission-rules antes que cualquier otra cosa. Un presupuesto con overLimit: block evita que una ejecución desatendida consuma recursos durante toda la noche, y un archivo .dsh/rules.yaml impide una llamada a una herramienta que nunca habría aprobado. Añada dsh-defend cuando el agente lea contenido de la web pública, y dsh-memory cuando se dé cuenta de que pega el mismo contexto en todas las sesiones. Omita los temas y los indicadores de estado: añaden código que se ejecuta con los privilegios del agente sin cambiar el funcionamiento de la máquina.

¿Los plugins de dsh están aislados del harness?

No. Un plugin se carga en el mismo árbol de Cordis que el harness, en el mismo proceso, con el mismo usuario del sistema operativo, las mismas credenciales del modelo y el mismo árbol de trabajo. Un plugin que intercepte tools/pre-execute puede ver y bloquear todas las llamadas a herramientas; uno que intercepte agent/pre-step puede ver sus mensajes. Por tanto, lea el código fuente, compruebe la licencia y la fecha del último commit, e instale por commit en lugar de por rama para impedir que el código cambie sin que usted lo advierta.

¿dsh-budget detendrá realmente al agente o sólo me avisará?

Depende de overLimit. El valor predeterminado es alert, que avisa en warnRatio y continúa consumiendo recursos. block rechaza nuevas llamadas al modelo cuando se alcanza un límite, y /budget unblock <scope> lo levanta cuando usted decide continuar. degrade cambia a un modelo más barato según el mapa degradation. Hay una limitación importante: los totales se agregan en el proceso en ejecución a partir del flujo de eventos de la sesión, por lo que reiniciar el harness los restablece, y un bucle de reinicio puede dejar sin efecto un límite diario. Mantenga un límite de gasto en la cuenta del proveedor como límite real.

¿Cómo elimino completamente un plugin de dsh?

Ejecute dsh plugin --profile web remove <package-name> y confirme con dsh plugin --profile web list. Después, abra $DSH_HOME/profiles/web/cordis.patch.yml y elimine cualquier bloque de inserción restante de ese plugin, porque esa entrada es la que lo carga. Reinicie el harness para reconstruir el árbol de plugins. Los datos escritos por el plugin permanecen en el disco: $DSH_HOME/memory/memory.db y .dsh/rules.yaml sobreviven a la desinstalación hasta que los elimine manualmente.

¿Es seguro exponer la interfaz web de dsh a través de la red?

No por sí sola. dsh web escucha en 127.0.0.1:3080, y dsh-web-lan-access cambia esa vinculación a 0.0.0.0. Su propio README indica que esto hace que el agente sea accesible sin autenticación para cualquiera que esté en la misma red; con una IP pública, eso significa que queda accesible desde Internet. Algunos métodos (settings.*, credentials.*, llm.discoverModels) permanecen vinculados a loopback y devuelven 403 cuando el origen es remoto, lo que reduce el impacto sin eliminarlo. Use un reenvío de puertos SSH, ssh -N -L 3080:127.0.0.1:3080 you@your-server, o coloque el puerto detrás de una interfaz de red privada y una regla de firewall. Añada autenticación real antes de que algo sea accesible desde el exterior.