Un agente de programación diseñado para gestionar varios trabajos a la vez
El equipo de Harness de DeepSeek publicó el diseño de su Super-agent el 31 de octubre de 2026, junto con un prototipo de investigación con licencia MIT que convierte solicitudes para un repositorio de GitHub en sesiones de programación separadas. El objetivo es permitir que varios trabajos avancen al mismo tiempo y reducir el tiempo que los desarrolladores dedican a cambiar de conversación y revisar el progreso.
Contenido
- Un agente de programación diseñado para gestionar varios trabajos a la vez
- Por qué DeepSeek quiere ocultar la gestión de sesiones
- Un Router coordina y varios Workers ejecutan
- Cómo los mensajes se convierten en tareas sin interrupciones constantes
- Actuar pronto y hablar solo cuando sea útil
- Mantener disponibles el contexto anterior y las instrucciones nuevas
- Coordinación en la nube con trabajo en un equipo local
- Qué midió el experimento
- Una coordinación más rápida utiliza más tokens en caché
- Los permisos locales convierten la seguridad en una preocupación central
- Puntos clave
El experimento preliminar del equipo utilizó unos 300 mensajes simulados que contenían alrededor de 20 solicitudes de trabajo. Super-agent completó la mitad de las tareas en 12,4 minutos y el 95% en 15,7 minutos. Un sistema de comparación que utilizaba una sesión principal con acceso a un agente auxiliar tardó 29,5 minutos en alcanzar el umbral del 95% con instrucciones neutrales.
El repositorio público del prototipo de DeepSeek, llamado dsh-superagent-prototype, presenta un lanzamiento más acotado y práctico: un agente de programación proactivo para un único repositorio de GitHub, distribuido como un paquete para DeepSeek Harness. El sistema escucha a GitHub y, de forma opcional, a Feishu; crea una tarea cuando una persona autorizada solicita trabajo y responde en la conversación original, posiblemente con una solicitud de incorporación de cambios que propone modificaciones al código.
El archivo README también incluye una advertencia clara. El código publicado difiere del sistema interno y de algunas partes del ensayo de diseño. Algunas funciones propuestas siguen siendo trabajo futuro, y DeepSeek describe el lanzamiento como código de investigación, no como un producto terminado.
El equipo de DeepSeek Harness, que mantiene el prototipo, indica su estado en el README:
«Prototipo de investigación solo como referencia, no es un producto oficial de DeepSeek».
Para los desarrolladores, el lanzamiento ofrece código que pueden inspeccionar y adaptar. El experimento central analiza cómo un agente organiza el trabajo, recuerda conversaciones relacionadas y decide cuándo debe intervenir una persona.
Por qué DeepSeek quiere ocultar la gestión de sesiones
El diseño de DeepSeek parte de una observación sobre su propio trabajo: una persona normalmente solo puede seguir entre tres y cinco sesiones de agentes activas a la vez. Cada sesión conserva su propio historial de conversación, por lo que el desarrollador debe recordar qué tarea corresponde a cada una y qué instrucciones recibió cada agente.
Un arnés es el software que rodea a un modelo de IA y gestiona herramientas, archivos, conversaciones y ejecución. El modelo razona sobre una tarea; el arnés determina cómo se le asigna y cómo se ejecutan sus acciones. Super-agent traslada una mayor parte de la coordinación de varios trabajos a ese software complementario.
El equipo señala cuatro objetivos: continuidad entre conversaciones, ejecución paralela eficiente, respuestas proactivas a eventos y funcionamiento persistente con recuperación ante fallos. Un ejemplo contempla a desarrolladores que eligen un plan en un chat y luego lo cambian en un comentario de GitHub. El sistema debería conectar ambos intercambios y actualizar la misma tarea.
El lanzamiento llega después del experimento de DeepSeek del 3 de octubre sobre la compatibilidad con extensiones de Claude Code en Harness v0.2.1-alpha.1. Esa actualización probó un puente para extensiones; Super-agent explora cómo el propio arnés puede coordinar el trabajo en curso. Yujia Qiao figura como responsable de implementar el sistema y redactar el ensayo de diseño, junto con otras 15 personas que participaron en la revisión y el debate.
Un Router coordina y varios Workers ejecutan
Super-agent distribuye las responsabilidades entre un Router permanente y varios Workers independientes. El Router recibe las interacciones con las personas, mantiene información compartida entre tareas y asigna el trabajo. Evita encargarse directamente de la programación, de modo que puede seguir coordinando mientras otras sesiones están ocupadas.
Los Workers se encargan de los trabajos individuales. Cada uno tiene su propio contexto de conversación y herramientas de ejecución, lo que permite investigar un error, responder a una revisión de código y modificar una función al mismo tiempo. Los Workers informan al Router, que se comunica con las personas en lugar de permitir que varias sesiones respondan por separado.
DeepSeek sugiere que un modelo más ligero puede encargarse a menudo de asignar tareas, mientras que modelos más potentes realizan el trabajo que determina la calidad del código. Un Worker también puede crear agentes auxiliares para una tarea compleja. El Router gestiona las relaciones entre los trabajos en lugar de planificar cada paso de cada uno.
El prototipo asigna a cada tarea una sesión y un directorio propios, y permite ejecutar varias en paralelo hasta alcanzar un límite configurado. Por tanto, quienes operan el sistema controlan cuántos trabajos comienzan a la vez. Los historiales de conversación separados reducen la posibilidad de que los detalles de una tarea desplacen a los de otra, mientras que el Router mantiene una visión compartida.
Cómo los mensajes se convierten en tareas sin interrupciones constantes
Los mensajes de chat, los comentarios de revisión de código y los resultados de pruebas automatizadas se convierten en eventos que pueden activar una acción. El diseño general también contempla el correo electrónico y los recordatorios del calendario. La integración continua, o CI, se refiere a las comprobaciones automatizadas que compilan o prueban el código después de un cambio y generan resultados a los que puede responder un agente.
DeepSeek filtra estos eventos en dos etapas. Primero, reglas de programa convencionales comprueban aspectos como el origen, el grupo y las personas autorizadas. Luego, un modelo evalúa las opciones restantes según el contexto y las políticas escritas. Así se evitan consultas al modelo para mensajes rutinarios que no requieren ninguna acción.
Los eventos relacionados forman un Thread, como los comentarios de una solicitud de incorporación de cambios o los mensajes de un tema de chat. Cuando un Worker acepta la tarea, se suscribe a ese Thread. Los comentarios y resultados de pruebas posteriores pueden llegar directamente a ese Worker, sin que el Router tenga que asignarlos de nuevo.
Las suscripciones pueden coincidir. Varios Workers que trabajan en la misma solicitud de incorporación de cambios pueden recibir las mismas actualizaciones y detectar cambios que afecten a su trabajo. Un Worker también puede seguir varios Threads relacionados o devolver un evento al Router si no corresponde a su tarea.
Actuar pronto y hablar solo cuando sea útil
DeepSeek afirma que un Super-agent interno ya funciona continuamente: reproduce y corrige problemas, responde a revisiones de código y ayuda a desarrollar Harness. Una regla escrita le permite investigar errores mencionados en un chat grupal incluso cuando nadie etiqueta directamente al agente.
La regla indica que primero debe investigar en silencio. El agente intenta reproducir el problema informado y encontrar una solución sencilla, y después presenta un resultado útil. En un ejemplo, los desarrolladores debatían un problema por el que las tildes aparecían como texto tachado, mientras el agente ya había abierto una solicitud de incorporación de cambios con una posible solución.
El equipo de Harness describe el principio de funcionamiento en su README:
«Requerir la menor atención humana posible y ofrecer el mayor valor posible».
El prototipo actúa cuando una persona autorizada lo solicita o cuando una regla escrita por el equipo lo permite. Su panel web muestra las tareas que requieren atención humana. Así, la interfaz se centra en las decisiones y los resultados utilizables, en lugar de mostrar cada llamada a una herramienta o cada pensamiento intermedio.
Mantener disponibles el contexto anterior y las instrucciones nuevas
El diseño de DeepSeek trata la ventana de contexto de un modelo —la cantidad limitada de información que puede considerar a la vez— como una memoria caché. El material que se necesita con frecuencia permanece a mano; el historial más extenso o menos relevante queda fuera de la ventana hasta que se solicita.
El ensayo denomina Inline y Spill a estas operaciones. Inline incorpora los detalles útiles directamente al contexto actual, como mensajes cercanos del chat, identificadores o una breve vista previa. Spill deja el contenido más extenso en otro lugar, junto con una referencia que el modelo puede seguir para consultarlo.
Chain of Recall enlaza esas referencias. Los eventos, los Threads y las sesiones de Worker reciben identificadores únicos, lo que permite al agente pasar de un mensaje actual a su conversación, luego a un Worker relacionado y después a otra revisión de código. El objetivo es recuperar una tarea antigua en distintos canales sin volver a cargar repetidamente todo su historial.
DeepSeek también aborda un problema más inmediato de las interrupciones: un comando largo puede impedir que un agente convencional responda. Su mecanismo asíncrono inicia el trabajo en segundo plano y devuelve el resultado como un nuevo evento. Los usuarios pueden seguir dando instrucciones, incluso pedir al agente que cambie de rumbo o se detenga.
El equipo afirma que este mecanismo está implementado en DeepSeek Harness, pero no viene activado de forma predeterminada. Las reglas de comunicación también varían según el canal: el diseño limita a 100 palabras una respuesta en una aplicación de mensajería instantánea, mientras que las solicitudes de incorporación de cambios y los documentos reciben explicaciones más estructuradas sobre los cambios y su verificación.
Coordinación en la nube con trabajo en un equipo local
DeepSeek separa el procesamiento del agente, el historial de sesiones almacenado y la máquina donde se ejecutan los comandos. El bucle de funcionamiento propuesto para el agente se ejecuta en contenedores en la nube, el estado de las sesiones se guarda en una base de datos y un servicio local ligero ejecuta comandos y devuelve los resultados.
Esta configuración permite usar Bring Your Own Machine, o BYOM («traiga su propio equipo»). Un desarrollador puede conectar un equipo existente que contenga el repositorio, las herramientas y los cambios sin terminar, en lugar de trasladarlo todo a un nuevo entorno remoto. La coordinación en la nube puede seguir disponible si ese equipo se desconecta, mientras que las tareas que lo requieran esperan a que vuelva a conectarse.
Una sesión de Watchdog independiente comprueba si hay fallos o trabajos detenidos. Su función va más allá de detectar un mensaje de error: utiliza el criterio de un modelo para evaluar si los Workers progresan realmente o se alejan del objetivo, y luego intenta recuperarse cuando es necesario.
DeepSeek presenta estos elementos como parte de una exploración más amplia de su arquitectura. El README advierte que el paquete público y la implementación interna son distintos, por lo que los desarrolladores deben revisar el código publicado antes de confiar en una función de diseño concreta.
Qué midió el experimento
DeepSeek repitió cada configuración experimental cinco veces y comparó Super-agent con una versión que no enviaba eventos directamente y con dos configuraciones de una sola sesión equipada con un agente auxiliar. La carga de trabajo utilizó mensajes sintéticos y una herramienta que simulaba tareas de programación prolongadas. Los intervalos entre mensajes y la duración de los trabajos se redujeron a una cuarta parte.
La mediana de 12,4 minutos significa que la mitad de las tareas terminó para ese momento. El percentil 95 de 15,7 minutos significa que el 95% terminó en ese plazo. Frente al percentil 95 de 29,5 minutos de la sesión única con instrucciones neutrales, Super-agent redujo esa medida en 13,8 minutos, alrededor del 47%.
El comportamiento de delegación ayuda a explicar el resultado. Con instrucciones neutrales, la sesión única nunca recurrió a su agente auxiliar en ninguna de las cinco pruebas. Cuando se le indicó que diera prioridad a la delegación, delegó en cuatro pruebas y realizó el trabajo por su cuenta en la quinta. Super-agent convierte la separación entre coordinación y ejecución en una decisión estructural.
Las pruebas evaluaron la programación y la coordinación mediante una ejecución simulada. No se han publicado datos sobre la calidad de la programación en situaciones reales, mediciones independientes del rendimiento ni el número de usuarios activos, y el equipo califica sus mediciones de preliminares. DeepSeek no ha anunciado una fecha para el lanzamiento de producción.
Una coordinación más rápida utiliza más tokens en caché
La ejecución simultánea de Super-agent implicó un mayor uso de entradas en caché. Leyó 23,23 millones de tokens en caché, frente a 6,05 millones y 10,82 millones en las dos configuraciones de sesión única. Los tokens son las unidades pequeñas de texto que procesa un modelo; las lecturas en caché reutilizan entradas conservadas de solicitudes anteriores.
Eliminar el envío directo de eventos aumentó las lecturas en caché de 23,23 millones a 31,77 millones, alrededor del 37%, e incrementó las decisiones del Router en aproximadamente un 30%. Por tanto, enviar las actualizaciones directamente al Worker asignado redujo el trabajo de coordinación dentro del diseño paralelo.
El procesamiento por lotes ayudó al Router a gestionar un mayor volumen de actividad. Cuando la llegada de eventos aumentó de alrededor de uno a 40 activadores por minuto, el tamaño medio de los lotes pasó de 1,0 a 2,8 y la duración de las solicitudes subió de 2,5 a 3,9 segundos. El tiempo de inferencia asignado a cada decisión del Router bajó, según el informe, de 6,4 a 1,6 segundos.
La disyuntiva práctica consiste en reducir la espera de las personas a cambio de aumentar el procesamiento del modelo en sesiones separadas. Las cifras de tokens no indican el costo monetario; los equipos que consideren implementar el sistema tendrían que tener en cuenta los precios de sus modelos, los ajustes de concurrencia y su carga de trabajo real.
Los permisos locales convierten la seguridad en una preocupación central
La documentación de ejecución del prototipo indica que los comandos de los Workers se ejecutan sin aprobación con la cuenta del operador en el sistema operativo. Los comandos de terminal en primer plano pasan a ejecutarse en segundo plano después de cinco segundos, y los procesos en segundo plano pueden durar hasta 30 minutos por turno. Estos ajustes convierten los permisos de la cuenta del operador en una cuestión concreta para la implementación.
Un equipo conectado puede contener credenciales, código privado y archivos confidenciales. La inyección de instrucciones, en la que contenido malicioso intenta desviar a un agente mediante el material que lee, plantea un riesgo especialmente grave cuando los mensajes entrantes o el contenido de un repositorio pueden influir en los comandos ejecutados en ese equipo.
DeepSeek señala que la seguridad y la privacidad, la capacidad de ampliar el Router, la memoria durante periodos prolongados y la comunicación entre instancias de agentes siguen siendo áreas pendientes. Su README pide a los usuarios que revisen y adapten el código y advierte que pueden quedar errores y prácticas de ingeniería poco coherentes. Gran parte del trabajo de ingeniería también fue realizada por agentes de programación.
El lanzamiento recibió atención rápidamente, incluida una publicación de Leandro von Werra, director de investigación de Hugging Face. La secuencia muestra lo rápido que se difundió el prototipo:
- 31 de octubre de 2026, a las 09:32 UTC: se creó el repositorio de GitHub.
- 31 de octubre: el equipo de Harness publicó su ensayo de diseño; a las 22:10 UTC, el repositorio tenía 2.046 estrellas y 172 bifurcaciones.
- 1 de noviembre, a las 04:20 UTC: el repositorio había alcanzado las 3.433 estrellas.
Para los equipos de ingeniería, la decisión inmediata es si conviene inspeccionar y adaptar un sistema experimental de coordinación. Su atractivo es la posibilidad de gestionar más trabajos con menos interrupciones; entre las exigencias de operación están revisar el código, establecer permisos y decidir qué acciones requieren la intervención de una persona.
Puntos clave
- DeepSeek publicó un prototipo de investigación con licencia MIT para realizar tareas de programación en un único repositorio de GitHub, con integración opcional con Feishu.
- Un Router se encarga de la coordinación mientras varios Workers ejecutan tareas en paralelo.
- El sistema interno puede investigar errores informados conforme a reglas escritas, sin que se etiquete directamente al agente.
- Las pruebas sintéticas registraron un tiempo mediano de finalización de 12,4 minutos y un percentil 95 de 15,7 minutos, con un uso de tokens en caché mayor que las alternativas de sesión única.
- Los Workers ejecutan comandos con la cuenta del operador y sin aprobación, por lo que los permisos y las credenciales son cuestiones centrales.
- El código público difiere del sistema interno y sigue siendo un prototipo de investigación, no un producto oficial de DeepSeek.
