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 describe como una vista previa para desarrolladores y advierte THERE WILL BE COMPATIBILITY-BREAKING CHANGES. Ese hecho determina todas las decisiones siguientes. Fije las versiones de lo que instale, espere que una actualización pueda romperlo y mantenga el conjunto lo bastante pequeño como para poder leerlo completo. Si el harness todavía no se está ejecutando, empiece por instalar DeepSeek Harness en un VPS y vuelva aquí. Si aún no tiene claros los componentes en los que se integran estos plugins —el bucle del agente, sus herramientas y su memoria—, repase primero los fundamentos, porque resulta más fácil evaluar cada decisión cuando sabe qué hace cada capa.

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

dsh se compone 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

Hay cuatro formas de especificar el origen: el nombre de un paquete npm sin prefijo, 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 el cordis.patch.yml del perfil, luego el cordis.patch.yml del nivel del directorio de inicio 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 el cordis.patch.yml del perfil y compruebe dos cosas: que su bloque de inserción esté presente y que ninguna capa posterior lo desactive.

El 17 de agosto de 2026, el paquete npm @deepseek-ai/dsh estaba en 0.1.0-rc.7, mientras que los plugins siguientes se habían compilado para la línea 0.1.0-rc. dsh-permission-rules y dsh-defend declaran compatibilidad con 0.1.0-rc.5 a 0.1.0-rc.6, dsh-budget declara únicamente 0.1.0-rc.6, dsh-memory sólo establece rangos de peers a partir de ^0.1.0-rc.6 y dsh-web-lan-access no declara ninguna versión de dsh. El 10 de octubre de 2026, la etiqueta latest en npm es 0.2.0-rc.2, por lo que la diferencia es ahora mayor que cuando se eligieron estas versiones fijadas. Esta diferencia es normal en este ecosistema y suele ser la causa de que un plugin deje de cargarse: el harness avanza más rápido que los plugins que lo rodean. Actualice el harness de forma deliberada y pruebe después un plugin cada vez.

Lea 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, con el mismo usuario del sistema operativo, las mismas credenciales del modelo y el 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: lea el código o no lo instale.

Compruebe cuatro aspectos, en este orden:

• Qué puntos de extensión utiliza. tools/pre-execute significa que ve todas las llamadas a herramientas y puede bloquearlas. agent/pre-step significa que ve sus mensajes. webServer.tapIndex significa que reescribe la página que se sirve al navegador. Un plugin que no utiliza ninguno de esos puntos puede hacer muy poco; un plugin que utiliza los tres es su límite de seguridad.
• Si se comunica con la red. Busque en el código fuente fetch, http y cualquier nombre de host escrito directamente. Un medidor de costes que se comunica con un servidor externo está enviando su patrón de uso a algún lugar.
• Si lee credenciales. Todo lo que acceda a credentials.* o a una clave de proveedor necesita una justificación explícita 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, instálelo usando un commit en lugar de una rama y lea 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 acaba de añadir. Mantenga 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 evito que un agente gaste toda la noche?

Un agente en un VPS se ejecuta sin supervisión. Ese es el motivo para instalarlo allí y también el riesgo. dsh-budget contabiliza los tokens y el coste estimado por modelo, sesión y día, y aplica límites a 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 como para que un bucle descontrolado termine antes de que se active el límite. 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 equipo, no una cifra publicada. Auméntela cuando un mes completo de uso real se lo indique. Un límite mensual de 40 USD con un límite por sesión de 2 falla de forma clara y temprana. Eso es lo que necesita mientras todavía 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 de la máquina es overLimit. Su valor predeterminado es alert. Muestra una advertencia y mantiene el gasto, por lo que, sin cambios, este plugin funciona como un panel de control. Establézcalo en block y el harness rechazará nuevas llamadas al modelo cuando se alcance un límite. Así, un trabajo nocturno se detiene en lugar de seguir generando cargos hasta la mañana. degrade es el tercer modo. Bloquea la llamada y muestra instrucciones con el nombre de un modelo más barato del mapa degradation. Es adecuado cuando un trabajo debe terminar, pero no necesita el mejor modelo. warnRatio tiene el valor predeterminado 0.8, por lo que recibirá una advertencia al alcanzar el 80 por ciento del límite.

Hay dos límites importantes. El coste se calcula a partir de una tabla de precios integrada combinada con los precios que proporcione, y el mantenedor advierte que los precios integrados cambian. prices está vacío de forma predeterminada. En el commit fijado 461d478, defaultPrice, el valor alternativo para un modelo que no aparece en ninguna de las dos tablas, es de 1.0 USD por millón de tokens de entrada y 3.0 por millón de tokens de salida. En la versión actual de main, comprobada el 10 October 2026, el valor predeterminado es cero y el modelo aparece sin precio. Introduzca los valores reales de sus modelos. De lo contrario, el panel será una estimación presentada como una medición. En segundo lugar, en 461d478 el plugin agrega los datos en el proceso en ejecución a partir del flujo de eventos de la sesión. Por tanto, los totales se reinician cuando se reinicia el harness. Un bucle de fallos, o un supervisor que reinicie dsh, también reinicia un límite diario. La versión actual de main conserva de forma predeterminada los intervalos diarios y mensuales (persistence.enabled: true, con una instantánea cada 10 segundos) y los restaura al iniciar. En ese caso, un reinicio ya no elimina un límite diario o mensual, siempre que el harness proporcione el dominio de almacenamiento. Sin él, la agregación permanece limitada al proceso. main también está dirigido a la línea de harness 0.2, por lo que cambiar la referencia fijada implica cambiar también el harness. En cualquier caso, 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. Ese es el argumento más amplio de controlar el coste de los agentes de IA en un VPS.

En el uso diario, utilice /budget para la vista general, /budget models para 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, de modo 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 deriva 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 incluye 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 sigue el criterio de que gana la primera coincidencia. Por tanto, un allow general 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 la herramienta cubre mcp__*. Así puede controlar las herramientas que proceden de un servidor de protocolo de contexto del modelo (MCP) y no del propio entorno de ejecución. Esto es importante en cuanto ejecute servidores MCP en un VPS.

Debe prever un comportamiento: ask necesita una persona o proceso que responda. En un perfil headless puede que nadie esté observando, y un ask sin respuesta no espera a que aparezca alguien. Si no se compone ningún respondedor, la cadena de aprobación del entorno de ejecución aplica una denegación por defecto y rechaza la llamada. En un equipo desatendido, una regla ask se comporta como un deny que no escribió intencionadamente. 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 una ruta de respuesta real. Ese 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 tres puntos: los mensajes entrantes en agent/pre-step, los argumentos de las herramientas en tools/pre-execute, incluido un control contra eliminaciones destructivas, y los resultados de las herramientas en tools/post-execute. Este último punto es el más interesante, porque permite analizar 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 cautelosos, no estrictos: detection.injectionAction, detection.jailbreakAction y detection.secretAction están todos en ask, mientras que detection.secretBlockCritical está en true. Por tanto, un secreto crítico se bloquea independientemente de lo que indiquen los demás ajustes. En un equipo sin supervisión, cambie a block las acciones que necesite, porque ask sin nadie a quien preguntar no es una decisión.

El diseño de auditoría merece reconocimiento. Los eventos defend/detection registran el ID 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, habilitar el registro de auditoría no crea una segunda copia de la credencial que intentaba proteger.

Debe tener claro qué ofrece esta función. La detección se basa en reglas, y el README indica claramente que las formulaciones nuevas y los ataques en varios pasos pueden eludirla. Reduce la frecuencia de los ataques evidentes. No hace seguro dirigir un agente hacia 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 distintos llamados dsh-memory. Conviene saberlo antes de escribir un comando de instalación. Instálelo indicando el origen de forma explícita para obtener el que ha consultado.

La versión que instalaría en un servidor pequeño es la basada en SQLite. Se registra como memory, mantiene un 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 deberá 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 y no darse por supuesta.

Esto es lo que cambia realmente la memoria en la máquina: las memorias inyectadas se incluyen en el mensaje del sistema en cada turno. promptMaxChars establece un límite máximo para la sección renderizada, no una cantidad fija. Sin embargo, cuando las memorias almacenadas ocupan todo ese límite, un presupuesto de 2000 caracteres añade varios cientos de tokens de entrada adicionales en cada solicitud, de forma permanente. Es un coste real en la factura. Por eso dsh-budget debe estar en el servidor antes que dsh-memory. Mantenga promptMaxChars bajo y elimine memorias con memory_forget en lugar de permitir que el archivo crezca.

La versió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. Esta búsqueda necesita una instancia local de ollama y un modelo de embeddings, qwen3-embedding:0.6b de forma predeterminada, que puede cambiarse con DSH_MEMORY_EMBED_MODEL. Sin ollama, vuelve a una búsqueda basada sólo en palabras clave. 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 de modelo residentes en el mismo servidor. En un plan pequeño, esa memoria se resta del trabajo para el que ha alquilado el servidor. Elíjalo cuando tenga RAM disponible. La compensación 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 soluciona usando 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. En el commit citado aquí, e27e909, el README indicaba que vincularse a 0.0.0.0 hacía que el agente fuera accesible sin autenticación para cualquier persona de la misma red de área local (LAN) y, en un servidor con una dirección IP pública, para todo Internet. Sólo una lista breve de métodos sensibles (settings.*, credentials.*, llm.discoverModels) quedaba fijada a loopback y devolvía 403 cuando se accedía desde orígenes remotos. Esto ha cambiado. Las compilaciones actuales de harness, comprobadas el 10 October 2026, autentican el navegador: el token de inicio incluido en la URL impresa se intercambia por una cookie de sesión firmada, que requieren todas las rutas de la API de Host y todos los streams. El README actual del plugin denomina a trustedHosts una barrera de Origin/Host, no un mecanismo de identidad; indica que vincularse a 0.0.0.0 expone la superficie de autenticación en todas las interfaces accesibles y ahora habilita la configuración respaldada por Host para una página remota autenticada. Por tanto, en las compilaciones actuales, un navegador remoto con sesión iniciada también puede acceder a la configuración de Host. El riesgo ha cambiado, pero no ha desaparecido: cualquiera que pueda alcanzar el puerto puede probar el inicio de sesión, la URL impresa es una credencial y, mediante HTTP sin cifrar, ese token atraviesa la red en texto claro.

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. harness seguirá 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, sin plugin y sin una nueva superficie de ataque.

Instale el plugin sólo cuando el reenvío no sea suficiente, por ejemplo, cuando un teléfono de la misma red tenga que acceder a la interfaz. Si lo hace, vincúlelo detrás de una interfaz de red privada, mantenga una regla de firewall que permita únicamente esa interfaz y enumere los nombres que usará bajo trustedHosts en la entrada web-runtime. Para un acceso multiusuario real existe dsh-passwords, que añade permisos para subusuarios, límites horarios de tokens por subusuario y cuotas diarias de tiempo, certificados TLS (transport layer security) automáticos mediante Let's Encrypt y un registro de auditoría cifrado. Evalúelo como una plataforma, no como un plugin: necesita los puertos 80 y 443, incluye su propio instalador y la ruta rápida documentada canaliza un script de shell desde la red directamente hacia 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 indique 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 la desinstalación. Elimínelos manualmente si el objetivo era quitar los datos.

Qué leí y cuándo

Todas las referencias de esta sección corresponden a un commit, no a una rama, porque main contendrá código diferente cuando lea esto. Leí todo el material el 17 August 2026, y el propio harness estaba en 0.1.0-rc.7 en npm ese día. Volví a comprobar los valores predeterminados y el comportamiento descritos anteriormente con las fuentes principales el 10 October 2026, cuando la etiqueta latest de npm era 0.2.0-rc.2.

Vuelva a comprobar esas referencias antes de copiar un comando. En un ecosistema de versiones preliminares para desarrolladores, un número de versión acompañado de una fecha es el único que tiene un significado fiable.

FAQ

¿Qué plugins de DeepSeek Harness debo 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 gaste durante toda la noche, y un archivo .dsh/rules.yaml evita 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 de su agente sin cambiar el comportamiento 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, dentro del mismo proceso, con el mismo usuario del sistema operativo, las mismas credenciales del modelo y el mismo árbol de trabajo. Un plugin conectado a tools/pre-execute puede ver y bloquear todas las llamadas a herramientas; uno conectado a agent/pre-step puede ver sus mensajes. Por tanto, lea el código fuente, compruebe la licencia y la fecha del último commit, e instálelo 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 gastando. block rechaza nuevas llamadas al modelo cuando se alcanza un límite, y /budget unblock <scope> lo levanta cuando decide continuar. degrade bloquea la ejecución e indica un modelo más barato del mapa degradation. Hay una limitación importante: en el commit fijado 461d478, los totales se agregan en el proceso en ejecución, por lo que reiniciar el harness los restablece y un bucle de reinicio puede eludir un límite diario. La versión actual main conserva los acumulados diarios y mensuales entre reinicios de forma predeterminada. En cualquier caso, mantenga un límite de gasto en la cuenta del proveedor como límite máximo real.

¿Cómo elimino completamente un plugin de dsh?

Ejecute dsh plugin --profile web remove <package-name>, confirme con dsh plugin --profile web list y abra después $DSH_HOME/profiles/web/cordis.patch.yml para eliminar 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 en 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. En el commit citado aquí, su README indicaba que esto hacía que el agente fuera accesible sin autenticación para cualquier persona de la misma red, con sólo settings.*, credentials.* y llm.discoverModels vinculados a loopback. Las versiones actuales del harness, comprobadas el 10 October 2026, autentican la sesión del navegador con el token de lanzamiento incluido en la URL mostrada y una cookie de sesión firmada, pero la superficie de inicio de sesión queda expuesta en todas las interfaces, y una URL HTTP sin cifrar envía ese token en texto plano. Use un reenvío de puertos SSH, ssh -N -L 3080:127.0.0.1:3080 you@your-server, o sitúe el puerto detrás de una interfaz de red privada y una regla de firewall, y mantenga TLS delante de todo lo que sea accesible desde el exterior.