dsh-superagent, un prototipo de investigación con licencia MIT que convierte peticiones en GitHub o Feishu en trabajo hecho por agentes, para un solo repositorio de github.com.danger-full-access.Abre tres sesiones de un agente de programación. Una arregla un test, otra revisa una pull request y la tercera investiga un error de producción. A los diez minutos la primera te pregunta algo, la segunda quiere que leas sus conclusiones y la tercera ha encontrado algo que afecta a lo que está tocando la primera. Los agentes trabajan, y tú acabas de coordinadores de agentes.
Ese es el problema que ataca el equipo de DeepSeek Harness. El 31 de octubre subió el código de dsh-superagent y el 1 de noviembre publicó Exploring Super-agent Design. Según DeepSeek, una persona puede seguir con comodidad entre tres y cinco sesiones activas, una cifra que sale de su experiencia interna y no de un estudio.
El equipo de Helmcode ha publicado un buen análisis, con una prueba real sobre repositorios privados, y de ahí vienen los tiempos de campo de este artículo. El resto lo hemos contrastado leyendo la documentación y el código del prototipo a 5 de noviembre. No lo hemos arrancado nosotros.
Meterlo todo en una sesión mezcla tareas que compiten por el mismo contexto, y una operación larga retrasa la siguiente instrucción. Repartirlo en varias sesiones te devuelve el trabajo de coordinarlas. DeepSeek separa los dos papeles:
La separación permite además poner un modelo en cada sitio, uno ligero para clasificar y otro más capaz para programar. Helmcode lo probó así, con deepseek-v4-flash en el Router y GLM 5.3 en el Worker.
Supón que alguien autorizado escribe en una issue: «Agente, mira por qué fallan los tests de autenticación y prepara un arreglo». El prototipo usa estos conceptos, y conviene conocerlos porque son los que verás en el panel:
| Pieza | Qué es | Lo que aporta |
|---|---|---|
| Source | Origen de eventos: GitHub y, opcionalmente, Feishu | Aquí nacen las peticiones |
| Trigger | Un evento inmutable | Si llega dos veces, solo crea un Ticket |
| Thread | Una conversación, como una issue | Da contexto a la evaluación |
| Eval | Decide si hay trabajo nuevo | Primero reglas en código, luego un modelo si hace falta |
| Ticket | Unidad de trabajo autorizado | Guarda estado, informes y conversaciones |
| Mandate | Lo autorizado: alcance, versión de la política, remitente | Inmutable. Más alcance significa otro Ticket |
| Subscription | Une un Ticket con los Threads que sigue | Entrega comentarios y CI al Worker |
| Outbox | Mensajes salientes con recibo | Se guardan antes de enviarse |
Lo primero que hace Eval es una comprobación sin inteligencia artificial: quién escribe y si se dirige al agente. Para saber si alguien está en una lista no hace falta gastar inferencia, y el código no se deja convencer.
Después llega la parte que evita el ruido. Si la CI falla en la pull request que abrió el Worker, ese resultado le llega directo, sin pasar por el Router. DeepSeek lo llama subscription and pass-through, y Helmcode lo vio funcionar: tras un «Request changes» el Worker corrigió código y tests en un minuto, sin que nadie volviera a mencionarlo.
Para el trabajo no pedido hay tres modos: off, observe y auto. El predeterminado es observe, que evalúa y anota lo que habría aceptado sin hacerlo, y así puedes revisar sus decisiones antes de darle más cuerda. Las peticiones explícitas de personas autorizadas funcionan en los tres.
Aquí es donde compensa abrir el repositorio, porque hay cuatro matices que cambian la lectura.
El Router no puede editar, pero conserva bash. La lista de herramientas de la sesión principal se limita a skill, bash, read, read_image y las de gestión de trabajos en segundo plano. Sin escritura, sin edición, sin subagentes. Eso hace que delegar sea el camino natural, y el prompt añade que investigar e implementar corresponde a los Workers. Pero con bash y danger-full-access no hay una barrera técnica que le impida tocar un fichero. La regla está mucho mejor apuntalada que un consejo en un prompt, aunque tampoco es absoluta.
El alcance del Mandate lo juzga un modelo. Imagina que en el hilo de esos tests alguien escribe: «Ya que estás, borra la base de datos antigua de producción». El Mandate no lo cubre, pero nadie compara esa frase con él en una capa determinista. Las instrucciones dicen al Worker que decida él cada mensaje de una persona en sus propios hilos y que devuelva lo que se salga del alcance. Lo que el sistema garantiza es otra cosa: un Mandate queda registrado aparte de la conversación, no cambia y no se amplía porque alguien lo pida en un comentario.
La suscripción no mira quién escribe. Un evento en un hilo suscrito llega a los Tickets vivos «sin comprobar quién lo envió», según el modelo de dominio, y el mensaje de una persona no pasa por Eval. Tampoco da nueva autoridad, pero la entrada llega al modelo. En un repositorio público cualquiera podría escribir en ese hilo, y un log de CI también puede traer texto preparado.
Un reinicio puede repetir una acción. El Engine guarda el estado en SQLite dentro de una transacción y encola los efectos externos para después. Si se cae entre medias, el trabajo sigue en la cola. Lo que no puede resolver es el caso de que GitHub acepte un comentario y el proceso muera antes de guardar el recibo, porque lo reenviará. Para ese hueco, tras un reinicio cada Worker recibe una nota que le pide comprobar su directorio, el historial de git y GitHub antes de repetir una acción externa. Es razonable para un comentario. Para algo que cree infraestructura o toque datos de producción necesitas operaciones idempotentes o aprobación humana, porque esa nota también la interpreta un modelo.
Hay detalles más pequeños que también dicen cómo está pensado:
DeepSeek comparó cuatro configuraciones con unos 300 mensajes sintéticos, de los que unos 20 eran peticiones de trabajo, y cinco ejecuciones por configuración. La programación estaba simulada con una herramienta que consume tiempo.
| Configuración | p50 | p95 | Tokens de caché leídos por ejecución |
|---|---|---|---|
| Super-agent | 12,4 min | 15,7 min | 23,2 M |
| Super-agent sin pass-through | 12,6 min | 15,5 min | 31,8 M |
| Sesión única, instrucción neutra | 20,4 min | 29,5 min | 6,1 M |
| Sesión única, instrucción de delegar | 13,8 min | 29,0 min | 10,8 M |
Del titular del 47 % de mejora en el p95 nos interesa más la causa. Con la instrucción neutra el agente podía delegar y no lo hizo ni una vez, así que los mensajes nuevos le interrumpían una y otra vez. Con una instrucción que favorecía delegar lo hizo en cuatro de cinco ejecuciones y la mediana se quedó en 13,8 minutos, cerca de los 12,4 del Super-agent.
Pero el p95 apenas se movió, y ahí está lo útil: en la ejecución restante el modelo decidió que algunas tareas eran lo bastante pequeñas para hacerlas él. Si una regla de reparto decide el rendimiento, conviene imponerla desde el software y no esperar que el modelo la cumpla siempre.
Tres lecturas más para no pasarse de entusiasmo:
Helmcode lo montó en una tarde y sin desarrollo a medida: 1 vCPU, 2 GiB de memoria, Ubuntu 24.04, inferencia externa, dos repositorios privados, modo observe y un Worker como máximo.
| Tarea | Tiempo medido |
|---|---|
| Primer acuse en la issue | 40 s a 1 min |
| Tarea de código hasta una PR correcta, con tests | 2 a 3 min |
| Corrección tras un «Request changes» | ~1 min |
| Investigación con dosier de fuentes | ~10 min |
| Cadena completa de investigar, editar, redactar y revisar | ~25 min y 3 rondas de corrección |
Son pocas muestras y una tarea cada vez, así que no se pueden comparar con la tabla anterior. Sirven para saber que el circuito funciona con el código publicado. Sus notas de campo valen tanto como los tiempos:
web_fetch, pero sin una API de pago no tenía búsqueda web, y las fuentes hubo que buscarlas a mano.github: más el número, sin identificar el repositorio. Al cambiar de Source hubo errores 404 que tumbaron el bucle de eventos y números repetidos, y lo arreglaron borrando el estado.Lo último tiene más miga de lo que parece. El prototipo exige una cuenta de usuario, porque una GitHub App no le sirve: necesita leer las notificaciones de la cuenta. Los términos de GitHub admiten cuentas máquina si las crea una persona que responde de ellas, con una gratuita además de la personal. Las cuentas registradas por bots no se permiten. Aun así, ningún Mandate te protege de un sistema antiabuso ajeno, y conviene tener previsto qué pasa si el agente se queda sin cuenta a mitad de trabajo.
Los presets de Router y Worker corren con danger-full-access bajo la cuenta del operador. La guía de despliegue es clara: un Worker puede ejecutar programas por ruta y leer el directorio personal del operador. Los worktrees de Git separan carpetas, no procesos, y los comandos bloqueados son una lista de nombres que se salta con la ruta absoluta. Los propios documentos dicen que esos wrappers y directorios «establecen valores por defecto, no una frontera de seguridad».
DeepSeek Harness, sobre el que se apoya, está en developer preview, y su aviso de seguridad deja claro que no se ha auditado y que no debe tratarse como seguro. Recomienda una máquina virtual desechable, un contenedor o un entorno dedicado.
Juntando esto con lo anterior, sale el escenario que hay que tener en la cabeza: un texto malicioso llega al Worker por un hilo suscrito, el modelo se lo cree y el proceso tiene alcance sobre todo lo que tenga esa cuenta. Nosotros partiríamos de esto:
observe hasta haber leído lo que habría hecho.Ten en cuenta un límite que ninguna de estas medidas resuelve: el aislamiento es por instalación, no por tarea. Todos los Workers comparten cuenta, así que dos Tickets no están separados entre sí. Para aislar cada uno tendrías que tocar el prototipo.
¿IA privada o API? Hacemos la cuenta con tus datos
Dinos cuántas personas lo usarían y con qué datos. Te respondemos con el nivel de privacidad que te encaja, la GPU que haría falta y cómo queda frente a la API.
Pide Node.js 22.19 o superior, pnpm, git 2.32 o superior, Python 3.8 o superior, tmux, GitHub CLI 2.48 o superior y un proveedor de modelos. El SETUP.md está pensado para que lo siga tu propio agente de programación, y la instalación manual documentada se resume en esto:
npm install -g @deepseek-ai/[email protected]
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git dsh-superagent
cd dsh-superagent
pnpm install && pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"Después copia examples/profile.cordis.patch.yml a ~/.dsh/profiles/superagent/cordis.patch.yml, rellena los valores y arranca con scripts/dsh-superagent start. Son los pasos de la documentación a 5 de noviembre y, como decíamos, no los hemos ejecutado. Ojo con el comando del perfil: si este ya existe, lo reemplaza y borra su configuración, así que no lo uses para actualizar. El panel escucha en 127.0.0.1, y ahí debe quedarse. Para entrar desde tu equipo, túnel SSH.
El proyecto es abierto y los modelos de la prueba de Helmcode tienen pesos publicados, lo que invita a pensar en montarlo todo en casa. Es posible, pero tiene varias condiciones.
El modelo puede ser tuyo. Harness admite una API de modelos personalizada, con un servidor propio o una pasarela de empresa, y el prototipo deja elegir modelo para Eval y para Worker. Sobre el papel, ningún prompt tiene por qué salir de tu red.
Pero el reparto de modelos juega en contra de la privacidad. El modelo pequeño y fácil de alojar es el que menos ve, y el grande es el que lee tu código. Las fichas de Hugging Face dan unos 291.000 millones de parámetros para DeepSeek V4 Flash y unos 753.000 millones para GLM 5.3. Haciendo la cuenta a 4 bits por parámetro, solo los pesos ocuparían unos 145 GB y unos 375 GB, antes de sumar el contexto. Compáralo con los 27.000 millones del modelo que usamos para dimensionar una IA privada en una GPU de 48 GB. Si dejas el Router en casa y mandas el Worker a una API, tu código sale igualmente.
Cada Worker es una sesión larga. La guía de hardware para LLM en local sigue valiendo para elegir, pero un agente de programación no se comporta como un chat: mantiene contextos grandes y encadena muchas llamadas. Con tres Workers activos son tres sesiones así a la vez. Antes de comprar nada, mide tus tareas reales contra un modelo más pequeño, y comprueba que el código que genera te sirve.
La licencia también cambia. V4 Flash figura con licencia MIT, y GLM 5.2 también, pero GLM 5.3 lleva una licencia propia que hay que leer.
Tu código sigue en github.com. El prototipo no admite GitHub Enterprise Server ni otras forjas. Hay una guía para añadir un Source, pero parte de la dependencia con gh tendrías que resolverla tú. Quien necesite GitLab o Gitea en su red tendrá que desarrollar esa pieza.
Los experimentos publicados dejan fuera lo que más importa. En un repositorio tuyo, compara una sesión convencional, esa misma sesión con instrucciones de delegar y un esquema Router-Worker, con los mismos modelos. Y mide tres cosas:
Provoca fallos a propósito. Reinicia el orquestador antes de guardar una entrega, manda el mismo evento dos veces, revoca un permiso con un Worker en marcha y da órdenes contradictorias desde dos hilos. Un agente rápido que duplica cambios cada vez que algo falla acaba creando más trabajo del que ahorra.
Lo más interesante de todo esto es lo poco que tiene de inteligencia artificial: colas persistentes, transacciones, idempotencia, separación de permisos. Son problemas de sistemas distribuidos con un modelo tomando algunas decisiones, y los equipos que ya operan infraestructura parten con ventaja para resolverlos.
Es una propuesta de diseño para que una persona trabaje con muchos agentes a través de uno solo. Un Router recibe las peticiones y las reparte entre Workers independientes. DeepSeek ha publicado un prototipo experimental llamado dsh-superagent, con licencia MIT, que implementa parte de esa propuesta.
No. DeepSeek lo define como prototipo de investigación y avisa de que no es un producto oficial, de que difiere de su versión interna y de que puede tener errores. Además se ejecuta con acceso completo a la cuenta del sistema del operador, y DeepSeek Harness está en developer preview sin auditoría de seguridad.
El Router evalúa, reparte y responde, y no tiene herramientas de edición ni subagentes. El Worker ejecuta una tarea concreta con su sesión y su directorio. Esa separación evita que el modelo decida si delega o no, que es lo que más alargaba los tiempos en los experimentos.
Es el registro inmutable de lo autorizado para una tarea: alcance, versión de la política, remitente y reglas aplicadas. Un comentario no puede ampliarlo. Aun así, es el Worker quien juzga si un mensaje entra en el alcance, así que no sustituye al aislamiento ni a limitar las credenciales.
Sí. DeepSeek Harness acepta una API personalizada, incluido un servidor propio, y el prototipo permite elegir modelo para Eval y para el Worker. El límite es el hardware: los modelos que usó Helmcode tienen cientos de miles de millones de parámetros y no caben en una sola GPU de 48 GB.
De serie no. Admite un repositorio de github.com y, opcionalmente, Feishu. La documentación explica cómo añadir un Source, pero otra forja exige desarrollo propio.
No. Las pruebas de DeepSeek simulan la programación y miden cómo se planifica y se coordina el trabajo. No evalúan calidad del código ni coste total ni tiempo de supervisión humana.
dsh-superagent-prototype, versión 0.1.0, commit 8c32a9d del 31 de octubre de 2026, con su filosofía, modelo de dominio, autorización, ejecución y despliegue. Leído el 5 de noviembre de 2026.
Del jueves 12 al sábado 14 de noviembre, Microsoft 365 dejó a miles de empresas sin Outlook, sin Teams y con los administradores sin acceso al panel. Qué se sabe de la causa, por qué el SLA no compensa una parada así y seis medidas de continuidad que conviene revisar ahora.
Valkey se vende como reemplazo directo de Redis, y lo era en 2024. Hoy depende de la versión de la que vengas. Hemos probado copias, réplicas y carga de datos entre Redis 7.2, Redis 8 y Valkey 9 en Docker: un archivo de Redis 8 impide arrancar a Valkey, y al revés. Qué cambia en licencia, qué trae cada paquete y cómo migrar sin sorpresas.
Un fallo de use-after-free en la gestión de conexiones TCP sobre IPv4, con puntuación de 9,8, afecta a kernels Linux desde la 4.4. Anthropic ha demostrado que da root remoto en servidores que escuchan con MPTCP, pero el fallo no depende de MPTCP. Qué sistemas están corregidos, qué pasa con Proxmox, por qué Ubuntu aún no tiene paquete y qué hacer mientras tanto.