DeepSeek publicó bajo licencia MIT un prototipo que distribuye solicitudes de GitHub entre sesiones de agentes separadas. En pruebas simuladas, su tiempo de finalización p95 fue de 15,7 minutos, frente a 29,5 minutos para una línea base de sesión única, aunque el equipo no midió la calidad de la programación real.
***
- dsh-superagent separa la coordinación de tareas, a cargo de un Router, de la ejecución que realizan sesiones Worker independientes.
- En simulaciones con mensajes y herramientas sintéticos, registró un p95 de 15,7 minutos, frente a 29,5 minutos para la comparación de sesión única.
- El prototipo se ejecuta en una máquina propia; el modo de autorización predeterminado es observe, que registra las solicitudes sin ejecutarlas automáticamente. El equipo recomienda aislamiento por los amplios permisos del sistema operativo.
🚨 DeepSeek publica bajo MIT un prototipo que divide tareas de código entre sesiones.
En simulaciones, el p95 fue de 15,7 minutos, frente a 29,5 con una sesión única.
No se midió la calidad del código real. El modo predeterminado solo observa solicitudes; opera localmente con… pic.twitter.com/xTVXEcSNQl
— Diario฿itcoin (@DiarioBitcoin) November 1, 2026
DeepSeek lleva la programación de GitHub a un sistema de agentes en paralelo
Un prototipo que organiza el trabajo en tickets
DeepSeek Harness publicó dsh-superagent, un prototipo de investigación de código abierto con licencia MIT diseñado para atender solicitudes de programación vinculadas a un repositorio de GitHub. El paquete, escrito en TypeScript y presentado como versión 0.1.0 en un único commit, funciona como un perfil dedicado de DeepSeek Harness y utiliza el modelo configurado en ese perfil. La propuesta no consiste en un asistente que responde a cada mensaje por separado, sino en un sistema que recibe solicitudes autorizadas y las convierte en unidades de trabajo independientes.
Cuando una persona autorizada menciona al agente, el sistema puede abrir un ticket y asignarle una sesión de trabajo propia, junto con un directorio separado. Los resultados vuelven a la conversación original y, con frecuencia, pueden tomar la forma de una solicitud de cambios en GitHub. El prototipo también ofrece un panel web local que muestra los elementos que requieren atención humana, una decisión de diseño que busca evitar que cada paso interno del proceso interrumpa a quien solicitó el trabajo.
El equipo presentó el lanzamiento junto con el texto de diseño Exploring Super-agent Design: Towards a More Autonomous Agent System. En la filosofía del proyecto, el agente debe consumir la menor atención humana posible y entregar el mayor valor que pueda, una prioridad que se refleja en su patrón de comunicación: confirma la solicitud una vez, trabaja sin enviar actualizaciones constantes y vuelve a escribir cuando tiene un resultado, necesita hacer una pregunta o enfrenta un fallo. Así, el silencio durante la ejecución forma parte del comportamiento previsto, no indica por sí solo que el proceso se haya detenido.
El prototipo puede escuchar eventos de GitHub y, de manera opcional, de Feishu. Su trabajo proactivo depende de reglas de autorización con tres modos: off, observe y auto; observe es la opción predeterminada y registra las solicitudes que el agente habría aceptado sin ejecutarlas automáticamente. Este ajuste deja la decisión de activar acciones proactivas en manos de cada equipo y distingue la capacidad técnica del sistema de la autorización para usarla en un repositorio.
Router y Workers: coordinación separada de ejecución
La arquitectura distribuye el proceso en dos capas. Un Router de larga duración mantiene la interacción y decide cómo despachar el trabajo, mientras que sesiones Worker separadas realizan las tareas asignadas; cada ticket funciona como unidad autorizada e incluye un mandato inmutable que explica por qué puede proceder. La separación permite que una solicitud nueva no tenga que esperar a que una sesión anterior termine para empezar a procesarse, aunque el material disponible no demuestra por sí mismo que todas las tareas puedan dividirse de manera efectiva.
El flujo descrito comienza cuando GitHub o Feishu genera eventos, que el sistema trata como desencadenantes. Después, una etapa de evaluación determina si un conjunto de esos eventos solicita trabajo nuevo; si corresponde, se crea el ticket y se envía a un Worker. También se contemplan suscripciones para que los comentarios posteriores en una solicitud de cambios lleguen al Worker responsable sin que alguien tenga que volver a mencionar al agente, lo que mantiene la continuidad de la conversación asociada a esa tarea.
La sesión principal utiliza el preset dsh-superagent-router y un conjunto de herramientas más reducido, mientras cada sesión de trabajo ejecuta dsh-superagent-worker. Según la documentación de ejecución descrita en el material de lanzamiento, los comandos de shell pasan a segundo plano después de cinco segundos, de modo que los Workers pueden seguir recibiendo mensajes mientras esos comandos avanzan. La división tiene una consecuencia práctica: coordinación y ejecución se administran en contextos distintos, en lugar de concentrar toda la actividad en una sola sesión conversacional.
El diseño también plantea límites que conviene considerar antes de probarlo. DeepSeek indica que el agente corre en la máquina del usuario y requiere Node.js 22.19 o superior, o Node.js 24 o superior, además de Git 2.32 o superior, Python 3.8 o superior, tmux y GitHub CLI 2.48 o superior. Como el programa opera con acceso completo del usuario del sistema operativo, el propio equipo recomienda aislarlo antes de utilizarlo, una precaución relevante para cualquier herramienta que pueda interactuar con archivos y comandos locales.
Resultados simulados y límites de la evaluación
DeepSeek comparó el sistema con una línea base de sesión única mediante un chat grupal simulado y flujos de integración continua de GitHub. Cada ejecución contenía alrededor de 300 mensajes, de los cuales cerca de 20 eran solicitudes reales de trabajo, y cada configuración se probó cinco veces. En ese entorno, dsh-superagent registró una mediana de finalización de 12,4 minutos y un percentil 95 de 15,7 minutos, mientras la referencia de sesión única alcanzó un p95 de 29,5 minutos, según las cifras reportadas por el equipo.
La comparación, sin embargo, no ofrece una medida de la calidad del código generado ni una prueba con solicitudes reales de desarrollo. Además, bajo el prompt neutral, la línea base no llamó a ningún subagente en ninguna de sus cinco corridas, por lo que la diferencia refleja tanto la arquitectura como el hecho de que el sistema de referencia no activó ese recurso en esas pruebas. El resultado permite hablar de tiempos dentro de una simulación concreta, pero no basta para afirmar que el prototipo programe mejor o mantenga la misma ventaja en repositorios reales.
Las pruebas también examinaron la carga del Router cuando el ritmo de llegadas aumentó de aproximadamente una a 40 por minuto. A medida que creció ese flujo, el tamaño promedio de los lotes pasó de 1,0 a 2,8, mientras la latencia por solicitud subió de 2,5 a 3,9 segundos. Esos datos describen cómo respondió la coordinación bajo el escenario simulado y muestran que el sistema agrupó más eventos ante una mayor demanda, aunque también aumentó el tiempo de procesamiento por solicitud.
En otra prueba de ablación, los investigadores quitaron el paso de envío directo de eventos y observaron que las decisiones del Router aumentaron cerca de 30%. Los tokens de lectura de caché también subieron alrededor de 37%, desde 23,23 millones hasta 31,77 millones, de acuerdo con las cifras reportadas sobre el análisis. El material de MarkTechPost atribuye estos resultados a informes secundarios del trabajo, entre ellos una versión publicada por ifeng; por eso, deben leerse como datos autorreportados y no como una validación independiente.
Disponibilidad, alternativas y preguntas pendientes
El informe sitúa el proyecto frente a herramientas que también conectan agentes de programación con GitHub, aunque sus modalidades y entornos de ejecución difieren. En esa comparación, GitHub Copilot cloud agent aparece vinculado a asignaciones de issues, chat, API y otros canales, y ejecutándose en segundo plano dentro de GitHub; Claude Code Action se presenta con activación mediante menciones, asignaciones o flujos de trabajo y ejecución en un runner de GitHub Actions. El cuadro también incluye a Codex, asociado con tareas en la nube y menciones en Slack.
La comparación no establece que dsh-superagent supere a esos productos, y varios campos aparecen como no divulgados. Sí distingue al prototipo de DeepSeek por ejecutar una sesión separada por ticket en la máquina del usuario y admitir trabajo proactivo sujeto a reglas, con observe como valor inicial. El informe describe Copilot como disponible en planes de pago, Claude Code Action como utilizable con una clave API o un proveedor de nube, y Codex como disponible desde ChatGPT Plus; esas referencias son parte del cuadro comparativo publicado, no una evaluación de rendimiento homogénea.
Fuera del prototipo actual, el equipo enumera ideas de diseño que todavía no presenta como funciones implementadas: un watchdog externo, una separación entre almacenamiento y cómputo, y un bucle ReAct asíncrono. Esas propuestas apuntan a ampliar la autonomía y a separar mejor la supervisión de la ejecución, pero el material no ofrece resultados que permitan medir su desarrollo o impacto. Por ahora, la evidencia concreta se limita al sistema Router-Worker descrito y a las pruebas sintéticas que acompañaron su presentación.
La publicación abre una vía para experimentar con agentes de programación que distribuyen solicitudes y reducen interrupciones, pero también deja tareas pendientes antes de considerar el enfoque probado para producción. La evaluación futura tendría que mostrar cómo se comporta con código y equipos reales, qué tan fiables son sus resultados y qué controles de seguridad funcionan cuando opera con permisos amplios en una máquina local. Hasta entonces, el dato más sólido es acotado: en las simulaciones reportadas, dsh-superagent terminó las tareas más rápido que la referencia de sesión única, sin que eso demuestre una mejora en la calidad de programación.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
IA
Científicos captan cómo el parásito de la malaria invade los glóbulos rojos
Empresas
Amazon apuesta por Alexa para disputar las compras con agentes de IA
AltCoins
FET: debilidad técnica mantiene la presión el 1 de noviembre de 2026
Curiosidades