DeepSeek ha publicado dsh-superagent, un prototipo de investigación bajo licencia MIT, presentado como un agente de programación proactivo destinado a un único repositorio de GitHub. Empaquetado para DeepSeek Harness, escucha GitHub y, opcionalmente, Feishu, luego transforma las solicitudes autorizadas en tareas paralelas, cada una en su propia sesión de agente.
- DeepSeek publica dsh-superagent, un prototipo de investigación bajo licencia MIT.
- El agente convierte las solicitudes autorizadas en tareas paralelas, cada una en su propia sesión.
- Un Router gestiona los intercambios, mientras que los Workers aislados realizan el trabajo.
- Las pruebas son simuladas y la calidad real del código producido no se ha medido.
Un agente que espera a ser solicitado
El funcionamiento se basa en la noción de Ticket, una unidad de trabajo abierta cuando una persona autorizada se dirige al agente. Cada Ticket se ejecuta en su propia sesión y su propio directorio, y los resultados vuelven a la conversación original, a menudo en forma de una pull request, es decir, una propuesta de modificación de código sometida a revisión. Una interfaz web local solo lista los elementos que requieren la intervención de una persona.
El README del proyecto establece una regla simple: reducir al mínimo la atención humana mientras se aporta el máximo valor. Según el documento de filosofía del proyecto, el agente solicita confirmación una sola vez, permanece en silencio durante su trabajo y solo vuelve a hablar con un resultado, una pregunta o un fallo.
Una arquitectura Router-Worker
Según el equipo, los agentes comunes consideran la sesión como unidad básica. Según el informe citado por ifeng, una persona solo puede seguir activamente de 3 a 5 sesiones a la vez, por lo que la atención humana, y no la capacidad del modelo, se convierte en el factor limitante del trabajo en paralelo. La arquitectura propuesta consta de dos capas: un Router de larga duración gestiona los intercambios y la distribución de tareas, mientras que sesiones Worker aisladas realizan el trabajo real.
El modelo de dominio describe una secuencia precisa: GitHub o Feishu producen eventos, llamados Triggers; una etapa de evaluación decide si un lote de Triggers requiere un nuevo trabajo; cada Ticket lleva un Mandate inmutable que enuncia por qué puede ejecutarse; finalmente, los comentarios posteriores en una pull request se dirigen al Worker correcto sin nueva mención. Los comandos shell pasan a segundo plano después de 5 segundos, para que los Workers sigan recibiendo mensajes. El trabajo proactivo se enmarca en tres modos: off, observe (por defecto) y auto. En modo observe, el agente se limita a registrar lo que habría aceptado.
Resultados procedentes de una simulación
DeepSeek probó el sistema en flujos simulados de discusión de grupo y CI de GitHub, con unos 300 mensajes por prueba, de los cuales unas 20 eran solicitudes de trabajo reales, ejecutando cada configuración 5 veces. El super-agente muestra un p50 de 12,4 minutos y un p95 de 15,7 minutos, frente a un p95 de 29,5 minutos para una sesión única con subagentes y prompt neutro, para la cual no se comunicó ningún p50. En esta configuración de referencia, el subagente no fue llamado ninguna vez en 5 pruebas.
Según estos mismos datos, cuando el número de llegadas pasó de aproximadamente 1 a 40 por minuto, el tamaño de los lotes pasó de 1,0 a 2,8 y la latencia por solicitud de 2,5 a 3,9 segundos. Estas cifras son autodeclaradas por DeepSeek y proceden de informes secundarios del informe. El proyecto precisa además que solo se ha probado en mensajes sintéticos y herramientas simuladas, y que no se ha medido la calidad real del código producido.
Para la instalación, el prototipo requiere Node.js 22.19+ o 24+, git 2.32+, Python 3.8+, tmux y GitHub CLI 2.48+. El repositorio indica finalmente que el agente se ejecuta con todos los derechos del usuario del sistema operativo, lo que obliga a aislarlo antes de cualquier uso.
