Lo que pide el superagente de DeepSeek antes de arrancar

Un agente de programación para un solo repositorio

dsh-superagent es, en palabras de su documentación, «a proactive coding agent for one GitHub repository»: un agente de programación que atiende un único repositorio de GitHub, la plataforma de código de Microsoft, y, si se quiere, también los chats de Feishu, la mensajería de trabajo de ByteDance, que fuera de China se llama Lark. Cuando alguien autorizado le pide algo, abre una ficha de trabajo, lo hace en su propia sesión y su propia carpeta y responde en la misma conversación. Un panel web enseña lo que necesita la intervención de una persona.

Lo publicó el 31 de octubre de 2026, con licencia MIT, DeepSeek, el laboratorio chino de inteligencia artificial nacido del fondo cuantitativo High-Flyer y controlado por su fundador, Liang Wenfeng. El propio repositorio avisa de que es un «research prototype for reference only, not an official DeepSeek product»: código de investigación que hay que revisar y adaptar antes de usarlo en un entorno propio.

Qué propone y cómo reparte el trabajo entre agentes está en «DeepSeek pone capataz a sus agentes» (01-11-2026).

Se instala dentro de DeepSeek Harness

DeepSeek Harness es de código abierto (open source), con licencia MIT, y su repositorio se creó el 13 de agosto de 2026; DeepSeek lo presenta en vista previa pública. Se usa como aplicación de escritorio o desde una interfaz web, y todo lo que hace se añade en forma de complemento (plugin): su lema es «Everything is a plugin».

dsh-superagent es uno de esos complementos, empaquetado en lo que la documentación llama un bundle. Por eso no basta con descargar el repositorio: hace falta DeepSeek Harness en una versión compatible, y la guía fija la 0.2.1-rc.3. Y, dentro de él, un proveedor de modelo configurado: sin modelo, el agente no tiene con qué pensar.

Tampoco vale cualquier GitHub. El repositorio tiene que estar en github.com: GitHub Enterprise Server, la versión que las empresas instalan en sus propios servidores, no está admitido.

Antes de instalar: una cuenta para el agente y otra para aislarlo

La documentación lo deja escrito: «For isolation, use a dedicated OS account containing only the agent's credentials». Para aislarlo, una cuenta del sistema operativo solo para el agente, con sus credenciales y nada más. En la práctica, un usuario de Linux aparte, o una máquina aparte, sin tus claves, tus sesiones abiertas ni tus documentos.

La segunda cuenta es la de GitHub. Tiene que ser una cuenta de usuario y no una GitHub App, «because dsh-superagent reads the account's notifications», y necesita permiso de escritura en el repositorio. Nunca la tuya: todo lo que el agente escriba aparecerá con ese nombre. Se maneja con un envoltorio propio de la herramienta de línea de comandos de GitHub, `gh-agent`, que guarda sus credenciales en una carpeta aparte, `~/.config/gh-agent`.

La tercera pieza es la clave de API (API key) del modelo. La configuración que se crea al instalarlo usa por defecto el modelo `deepseek-flash`, del proveedor `deepseek-official`, y lee la clave de la variable `DEEPSEEK_API_KEY`: sin una cuenta en la API de DeepSeek u otro proveedor configurado en DeepSeek Harness, no trabaja.

Quedan las herramientas. La tabla recoge las versiones que pide y lo que había en la máquina de nuestra prueba.

Lo instala otro agente, pregunta a pregunta

La guía de instalación no está pensada para que la leas tú. El README pide abrir tu agente de programación habitual y decirle: «Read SETUP.md in this repository and set up dsh-superagent with me», es decir, que lea SETUP.md y lo instale contigo.

SETUP.md le pone normas a ese agente: una sola pregunta por mensaje, cada una con una respuesta recomendada que se acepta con una palabra; nada de ejecutar mientras pregunta, y el plan entero en un único mensaje antes de esperar tu confirmación. Y una que conviene vigilar: «Never ask for a secret in the chat». Crear la cuenta, iniciar sesión o meter una clave lo haces tú, con los comandos que te da para tu terminal.

Antes de preguntar, el agente lanza una sonda que comprueba las herramientas instaladas. Después vienen nueve preguntas en tres bloques: de dónde llegan las peticiones, quién puede pedir trabajo y qué hace el agente con cada encargo.

Nuestra prueba: instalado en un minuto, y a esperar

La prueba se hizo el 1 de noviembre en una máquina Linux, siguiendo la documentación oficial y sin las dos cosas que solo puede poner el operador: la cuenta de GitHub del agente y la clave del proveedor de modelo. No se llamó a ningún modelo ni se creó ninguna cuenta. Coste: 0 dólares.

Con `DSH_HOME` apuntando a una carpeta propia, para no tocar `~/.dsh`, en unos 60 segundos de máquina quedaron el paquete compilado, DeepSeek Harness 0.2.1-rc.3 instalado y el perfil `superagent` creado con dsh-superagent dentro. Ahí se para: `status` devuelve el código 1, porque el servicio no corre, y arrancarlo exige tmux, que no estaba, y después la cuenta del agente y la clave. No se intentó.

La batería de comprobaciones, `pnpm check`, pasa la revisión de tipos y 1.196 de los 1.197 tests, pero se detiene en el primer fallo y no llega a compilar. En cada pasada falló uno, y no siempre el mismo. Con el sistema en español falla uno que espera el mensaje de error de git en inglés y recibe «fatal: mala línea de config»; con `LC_ALL=C`, que deja los mensajes en inglés, ese pasa. El otro, del lector de mensajes de Feishu, es intermitente: pasó en la primera ejecución completa y falló en las demás.

La salida práctica es ejecutar `LC_ALL=C pnpm check` y, si corta por el de Feishu, compilar aparte con `pnpm build`, que terminó sin errores. Es lo esperable en un prototipo de investigación.

Queda un aviso por revisar: al instalar DeepSeek Harness, npm advierte de que no ejecutó los scripts de instalación de cinco dependencias, entre ellas node-pty y koffi. No se ha comprobado si hacen falta para arrancar.

Los comandos de la prueba, en orden

Son los de la guía de instalación manual con dos cambios: las herramientas van a una carpeta local, en vez de instalarse para todo el sistema con `npm install -g`, y DeepSeek Harness guarda sus perfiles en una carpeta aparte. Mejor aún si se hace con el usuario del sistema reservado para el agente.

Un aviso de la propia documentación: el comando que crea el perfil se usa solo en una instalación nueva. Si el perfil ya existe, lo sustituye y borra su `cordis.patch.yml`, el fichero con la configuración de esa máquina.

La primera petición se hace en un issue

Con el servicio en marcha, la prueba que propone la guía es sencilla: desde una cuenta de la lista de permitidos, comentar `@<cuenta del agente> <petición>` en un issue del repositorio. Según la documentación, la ficha de trabajo aparece en el resumen del panel en un minuto, más o menos. El panel es la entrada Superagent de la barra lateral de DeepSeek Harness y enseña primero lo que espera a una persona.

Hay una trampa: la mención tiene que ir en un issue o un comentario nuevos. Añadirla editando el texto de un issue ya abierto no llega al agente.

Según su documentación, el agente confirma el encargo una vez, calla mientras trabaja y vuelve a escribir cuando tiene un resultado, como un pull request, necesita una decisión o no puede terminar.

En las primeras semanas conviene medir tres cosas: cuánto tarda en confirmar, cuántas preguntas hace antes de ponerse a trabajar y si el pull request que entrega se puede revisar como el de un compañero. Ninguna de las tres se ha podido medir en nuestra prueba.

Una temporada mirando antes de darle más cuerda

La guía deja el agente en `observe` sin preguntar, y su filosofía pide lo mismo al operador: «Start narrow». Una lista de permitidos corta y el trabajo por iniciativa propia solo anotado; las dos cosas se amplían cuando lo que el agente habría hecho parece correcto.

La documentación marca el orden: empezar en `observe` y pasar a `auto` después de repasar las decisiones anotadas. Están en la pestaña Eval del panel, cada una con su motivo y las reglas que encajaron.

Y añade tres normas para quien lo opera. Si hace ruido, acortar y endurecer sus instrucciones o pausarlo («Tune for less noise»). No usarlo para producir volumen («Do not use it to produce volume»). Y leer lo que publica («Own what it says»): firma con una cuenta que el equipo ve cada día.

Pararlo, vigilarlo y quitarlo

`scripts/dsh-superagent start` lo lanza dentro de una sesión de tmux y espera hasta un minuto a que esté listo o diga qué le falta. `stop` pide un cierre ordenado y espera hasta cinco minutos a que terminen los trabajos en curso; nunca mata el proceso a la fuerza. `status` responde con uno de cuatro códigos.

La comprobación horaria se crea en tu perfil habitual de DeepSeek Harness, no en el del agente, para que siga viva si el agente cae. Si encuentra el código 1, reinicia con `--respect-stop`, que respeta una parada hecha a propósito: solo `stop` deja esa marca.

Para quitarlo, en nuestra prueba bastó con haber puesto `DSH_HOME` y las herramientas en carpetas propias: todo quedó dentro y `~/.dsh` ni llegó a existir. Se para el servicio y se borran esas carpetas y el clon. Si creaste la cuenta del agente, retírale el acceso al repositorio.

Lo que esta prueba no dice

No dice si atiende bien peticiones reales, cuánto tarda, cuántas preguntas hace, qué pull requests abre ni cuánto cuesta en tokens: para eso hacen falta la cuenta de GitHub del agente y una clave de API, que son pasos del operador. Tampoco se ha comprobado con qué otros proveedores de modelo funciona.

Lo siguiente que pediría, según la tabla de problemas de su documentación, es la herramienta de GitHub del agente («The agent GitHub CLI is not set»), el repositorio («The GitHub Source names no repository») y, con la herramienta ya puesta, una sesión iniciada con la cuenta del agente. Es una deducción a partir de la documentación, no algo observado.