DeepSeek abre el código del prototipo Super-agent: p95 de ejecución de 15,7 min frente a 29,5

El equipo DeepSeek Harness publicó un artículo sobre la arquitectura del prototipo Super-agent y subió su código al repositorio abierto dsh-superagent-prototype. Según el resumen en X, en el experimento el p95 del tiempo de ejecución de la tarea fue de 15,7 minutos con el esquema multicomponente y de 29,5 minutos con la solución de una sola sesión. La diferencia ronda el 47%: las ejecuciones más largas terminan casi el doble de rápido. El artículo en sí no figura en el texto al que tenemos acceso, así que nos basamos en el resumen del autor del post.

Qué se sabe a partir del post

La fuente es una publicación breve en X de @JamesX_ai, con un alcance muy pequeño: unas 22 visualizaciones. El autor afirma que siete blogueros de IA de su feed comentan la noticia y fecha la publicación del artículo el 31 de octubre. De la arquitectura, solo llegó a nombrar un elemento: Router, es decir, un componente que, a juzgar por el nombre, reparte el trabajo entrante. La descripción se interrumpe ahí, de modo que se desconocen el resto de los nodos, el número de subagentes y la forma de transferir el contexto entre ellos.

De todo esto solo se pueden afirmar con seguridad pocas cosas. El prototipo se ha publicado en abierto. El equipo lo comparó con una variante en la que todo el proceso transcurre en una sola sesión. La comparación se hizo por el p95 del tiempo de finalización. Todo lo demás son suposiciones, y presentarlas como hechos sería incorrecto.

Por qué importa precisamente el p95

La métrica p95 indica el tiempo en el que terminan el 95% de las ejecuciones. Capta la «cola larga»: los casos raros pero penosos en los que el agente da vueltas en círculo, relee un contexto que ha crecido demasiado o espera a que termine un paso pesado. En los productos con agentes, este indicador suele pesar más que la media, porque el usuario no recuerda la ejecución típica, sino la más larga.

La sesión de un solo hilo suele sufrir justo en la cola. El contexto crece, cada paso siguiente cuesta más y las subtareas independientes se ejecutan estrictamente una tras otra. Si el Router del prototipo permite dividir el trabajo y ejecutar partes en paralelo, la mejora en el p95 resulta verosímil. Pero es una hipótesis: el resumen no aporta datos sobre cómo se logra exactamente la aceleración.

Qué falta en el mensaje

Para valorar el resultado hacen falta datos que el post no ofrece:

• qué tareas se usaron y cuántas fueron;
• qué modelo se empleó en ambas configuraciones y si los presupuestos de tokens eran iguales;
• cuántas ejecuciones entraron en el cálculo del p95: con una muestra pequeña, una métrica de cola es muy ruidosa;
• si se comparó la calidad del resultado y no solo la velocidad;
• cuánto costó la aceleración: los subagentes paralelos suelen consumir más tokens.

El último punto es fundamental. Reducir el tiempo casi a la mitad puede comprarse fácilmente con una factura de inferencia mayor o con una caída de precisión en las tareas complejas. Mientras la fuente no ofrezca datos sobre la proporción de tareas resueltas con éxito ni sobre el gasto de tokens, 15,7 frente a 29,5 minutos habla solo de velocidad.

Qué hacer en la práctica

El repositorio es abierto, así que la afirmación se puede comprobar de forma independiente. A los desarrolladores que construyen sistemas con agentes les conviene examinar cómo están implementados en el código el Router y la transferencia de estado, y ejecutar el prototipo con sus tareas habituales. La comparación debe hacerse en tres ejes a la vez: p95 del tiempo, proporción de ejecuciones exitosas y coste en tokens.

Hasta que se publique el artículo completo y haya mediciones independientes, la noticia debe tomarse como el planteamiento de una arquitectura interesante, no como un resultado demostrado. Que DeepSeek haya abierto el código es relevante en sí mismo: permite a la comunidad confirmar o desmentir estas cifras con rapidez.