DeepSeek publica el prototipo de Super-agent: el p95 del tiempo de tarea baja de 29,5 a 15,7 minutos

DeepSeek ha publicado en abierto el prototipo de Super-agent, un sistema multiagente que separa en sesiones distintas la comunicación con las personas y la ejecución del trabajo. Una sesión router recibe las solicitudes y distribuye las tareas, y workers aislados las ejecutan en paralelo, lanzándose por eventos de GitHub. En una prueba propia de DeepSeek, el p95 del tiempo de ejecución de una tarea bajó de 29,5 a 15,7 minutos en comparación con una sesión única. El lanzamiento lo comentó el analista de noticias de IA @kimmonismus, cuya publicación en X acumuló unas 91,6 mil visualizaciones.

El router por un lado, los workers por otro

El esquema les resultará familiar a quienes han montado agentes para desarrollo. En una configuración típica de sesión única, un mismo agente conversa con el usuario y además lleva a cabo el trabajo largo: lee el repositorio, edita código y lanza las comprobaciones. Mientras está ocupado, las nuevas solicitudes o bien esperan, o bien se cuelan en el contexto y descarrilan la tarea en curso.

En Super-agent estos roles están separados. El router sigue siendo la «cara» del sistema: habla con las personas, entiende qué quieren y traspasa el trabajo. El trabajo en sí pasa a los workers. Cada uno está aislado: vive en un entorno propio, con su propio contexto, y no afecta a los demás. El disparador son los eventos de GitHub: la aparición de una tarea, un comentario, un pull request y señales similares. El agente no espera órdenes en un chat, sino que reacciona a lo que ocurre en el repositorio.

Este enfoque tiene dos ventajas evidentes. Las tareas paralelas no hacen cola en un mismo punto, y el error o el bloqueo de un worker no corrompe el contexto de los demás ni interrumpe el diálogo con la persona.

Qué mostró la medición de DeepSeek

La única cifra pública del mensaje es el p95 del tiempo de ejecución. Es el tiempo dentro del cual se completa el 95% de las tareas, es decir, un indicador de la «cola larga», de los casos más lentos. Es justo el que importa en el trabajo en equipo: la velocidad media dice poco si una de cada veinte tareas se queda colgada media hora. Con una sola sesión, el p95 fue de 29,5 minutos; con el sistema de router y workers, de 15,7 minutos. Es decir, la cola de latencias se redujo casi a la mitad, en torno a un 47%.

La explicación plausible es el paralelismo. Cuando las tareas llegan en tandas, una sesión única las procesa por turnos y las últimas esperan más que nadie. Los workers las toman a la vez y la cola no crece. Esta explicación se deduce de la descripción de la arquitectura, no de datos publicados de la prueba.

Lo que falta en el mensaje

Conviene leer las cifras con cautela. En primer lugar, la prueba la realizó la propia DeepSeek y por ahora no hay reproducciones independientes. En segundo lugar, la publicación no deja ver la composición de la carga: cuántas tareas hubo, cuán complejas eran y con qué frecuencia llegaron de forma simultánea. Con poco paralelismo, la mejora podría ser bastante más modesta. En tercer lugar, el enlace a la solución de referencia aparece cortado en la publicación, por lo que no está claro con qué configuración de sesión única se hizo la comparación.

Además, la velocidad es solo un eje. El mensaje no dice nada sobre la calidad del resultado: la proporción de pull requests aceptados, el número de errores o el consumo de tokens. Varios workers casi con seguridad consumen más cómputo que una sola sesión, lo que significa que la aceleración habrá que pagarla con dinero.

Qué deberían hacer los desarrolladores

El lanzamiento merece una mirada de quienes construyen agentes en torno a GitHub y chocan con las colas. El prototipo permite ver cómo organiza DeepSeek el router, el aislamiento de los workers y el arranque por eventos, y compararlo con el esquema propio. El propio nombre «prototipo» lo dice todo: todavía es pronto para considerarlo un producto listo para producción.

La mejora anunciada se puede comprobar con la carga propia: tomar un repositorio con un flujo de tareas típicas, pasarlas por un agente único y por el esquema de «router más workers», y comparar el p95, además del coste y la proporción de cambios aceptados. Si la cola de latencias se reduce en una medida comparable, la arquitectura se amortizará. Si no, las cifras de DeepSeek seguirán siendo un buen resultado en su propio conjunto de tareas.