DeepSeek Super-Agent: Qué es, cómo funciona y qué falta aún24 min read

Abra tres agentes de codificación a la vez y podrá sentir el problema. Uno está esperando una decisión, otro terminó hace veinte minutos y ya ha olvidado cuál tiene la corrección de autenticación. El equipo de Harness de DeepSeek le puso una cifra: según su experiencia, una persona puede seguir sólo de tres a cinco sesiones de agente activo a la vez. Pasado ese punto, el modelo ya no es el cuello de botella. Eres.

El 31 de octubre de 2026, el equipo publicó un artículo de diseño para lo que llama un superagente y abrió un prototipo llamado dsh-superagent. Es un agente de codificación proactivo para un repositorio GitHub. Una sesión de enrutador de larga duración habla con la gente y reparte trabajo, y cada solicitud aceptada obtiene su propia sesión de trabajo que termina en una solicitud de extracción o una pregunta. El repositorio superó las 12.000 estrellas en unos dos días. Su README es contundente al decir que se trata de un código de investigación y no de un producto oficial DeepSeek.

Esta guía está dirigida a ingenieros y líderes de equipo que desean saber qué hace el prototipo, cómo funciona el enrutador y el diseño del trabajador, qué prueban y qué no prueban los números de referencia, y qué verificar antes de apuntar a un repositorio real.

Una nota antes de los detalles. La respuesta de un trabajador para «corregir este error» es una solicitud de extracción, y GitHub es un buen hogar para eso. El resto de lo que los agentes producen en torno al código es más difícil de ubicar: el artículo sobre la causa raíz, el resumen de la prueba, la tabla de comparación que solicitó un revisor.AgentGrid.ioes un espacio de trabajo compartido donde las personas y los agentes de IA crean, editan y comparten documentos, aplicaciones y archivos, con una versión en vivo, atribución e historial. Volvemos a donde encaja cerca del final.

¿Qué es el DeepSeek Super-Agent?

Dos cosas aparecieron juntas. El primero es un artículo de diseño extenso, «Exploración del diseño de superagentes: hacia un sistema de agentes más autónomo». El equipo de Harness lo escribió en chino y publicó una versión traducida automáticamente en inglés en X el 1 de noviembre. Ha sido visto más de 2,2 millones de veces. El segundo es el código:deepseek-ai/dsh-superagent-prototipo, lanzado bajo la licencia MIT.

Explorando el diseño de superagentes: hacia un sistema de agentes más autónomo

https://t.co/gwwIHtyCRQ

– Arnés DeepSeek (@DeepSeekHarness)1 de noviembre de 2026

No es un modelo nuevo. dsh-superagent es un paquete paraArnés DeepSeek, el arnés de agente de código abierto de DeepSeek, que la compañía describe como una vista previa pública en todo el mundo. El paquete vigila un repositorio GitHub y, si lo enciende, chatea con Feishu. Cuando alguien en una lista permitida le pide trabajo al agente, este abre un elemento de trabajo, lo ejecuta en su propia sesión y directorio, y responde en la conversación original. Un panel web muestra sólo lo que necesita una persona.

El nombre es más fácil de lo que parece. Cui Tianyi, del departamento de productos de DeepSeek y uno de los revisores finales del artículo, explicó en una publicación de Zhihu que «super» significa superíndice versus subíndice. Un superagente agrega una capa encima del agente que hace el trabajo, lo opuesto a un subagente, que agrega una debajo. No es una afirmación de inteligencia superior.

El archivo README se abre con una advertencia que vale la pena leer en su totalidad: «Prototipo de investigación solo como referencia, no es un producto oficial DeepSeek». Agrega que gran parte de la ingeniería fue realizada por agentes de codificación, que el código puede contener errores y que algunos diseños en el artículo son instrucciones para trabajos futuros y no se implementan.

Otra caída de DeepSeek: dsh-superagent

Un marco de agente que funciona a través de los problemas GitHub de un repositorio y las relaciones públicas con muchos agentes en paralelo, diseñado para requerir la menor atención humana posible y al mismo tiempo ofrecer el mayor valor posible.

pic.twitter.com/XR73mIvA0V

– Leandro von Werra (@lvwerra)31 de octubre de 2026

¿Por qué DeepSeek dice que el cuello de botella es la atención humana?

El artículo parte de una simple observación. Durante el año pasado, los agentes de codificación mejoraron lo suficiente como para que el modelo limite una sola tarea. Pero una vez que ejecutas varias tareas a la vez, el límite pasa a ti. Cada sesión está aislada, por lo que cambias entre ellas manualmente y realizas un seguimiento de lo que sabe cada uno. Conectar una CLI, MCP o un conector de chat a una sesión local le permite escuchar sobre nuevos eventos, pero aún bloquea comandos largos, mezcla contextos de diferentes tareas y se detiene cuando su computadora portátil duerme.

La respuesta de DeepSeek es dejar de tratar la sesión como la unidad que usted administra. Enumera cuatro rasgos que debe tener un superagente:

• Continuo.Le hablas donde ya trabajas, como en el chat o en los comentarios GitHub, y se comporta como un solo agente. Si solicita el plan A en el chat y cambia al plan B en un comentario de solicitud de extracción, lo sigue.
• Productivo.Ejecuta varias tareas complejas en paralelo y toma la siguiente instrucción antes de que finalice la última.
• Proactivo.Observa los acontecimientos, actúa sobre lo que vale la pena manejar y, en caso contrario, se queda callado.
• Persistente.Permanece en línea y se recupera de fallas sin que usted lo reinicie.

Los autores sostienen que ningún bucle ReAct puede ofrecer los cuatro, por lo que las cualidades tienen que provenir de la arquitectura que rodea al modelo. Ese es el verdadero tema del artículo, y la explicación visual a continuación, compartida por Hesam, es una forma rápida de ver el diseño completo en una sola página.

Aquí hay una explicación visual del artículo de DeepSeek sobre Super-Agent:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP

– ℏεsam (@Hesamation)1 de noviembre de 2026

¿Cómo funciona el diseño del enrutador y del trabajador?

Piense en un buen gerente de ingeniería que nunca escribe código mientras está de pie. elenrutadorEs una sesión de larga duración que recibe todos los mensajes de todos los canales. No ejecuta tareas. Decide qué solicita un mensaje, entrega un nuevo trabajo a un trabajador y escribe cada respuesta a las personas involucradas. El artículo dice que puede ejecutarse sin ninguna herramienta de shell y que un modelo más ligero y rápido suele ser suficiente.

untrabajadorEs una sesión separada con un contexto aislado y un conjunto completo de herramientas, dedicada a una tarea. Los trabajadores nunca hablan directamente con la gente. Informan del estado al enrutador, que mantiene las respuestas con una sola voz. En el prototipo, cada ticket obtiene su propia sesión y su propio directorio, normalmente un árbol de trabajo de git, y el número de trabajadores está limitado. El valor predeterminado es tres a la vez, ajustable de 1 a 16, con una ranura adicional libre para que el mensaje de una persona siempre pueda llegar.

Dos detalles hacen que esto sea más que una cola de tareas.

Los seguimientos se saltan el enrutador.Una vez que un trabajador posee una solicitud de extracción o un hilo de chat, se suscribe a ese hilo. Los comentarios posteriores van directamente a él, sin ninguna llamada de modelo adicional al enrutador. Si un comentario resulta ser sobre otra cosa, el trabajador lo devuelve.

Las ráfagas se agrupan.Los desencadenantes que llegan durante un modelo aumentan la cola y se inyectan juntos en la siguiente llamada. Los autores midieron el efecto y observamos los números a continuación.

Un punto más de contraste. El artículo lo distingue de un equipo de agentes. En un equipo de agentes, un líder divide una tarea compleja en pasos y coordina los roles que trabajan en ella, lo que supone una gran carga de razonamiento. El enrutador Super-Agent solo envía tareas independientes y rastrea cómo se relacionan en un alto nivel. No descompone la obra en sí.

¿Qué hace cuando nadie pregunta?

Aquí es donde la filosofía del proyecto se vuelve práctica. El primer documento del repositorio establece el principio en una sola línea: prestar la menor atención humana posible y dar el mayor valor posible. Cada mensaje que envía el agente cuesta la atención de un colega, por lo que habla sólo cuando una persona debe actuar o puede utilizar un resultado, y actúa sólo cuando se le pide o cuando una regla escrita por el equipo lo permite.

La puerta que impone esto es un código simple, no un modelo. Comprueba quién solicita la lista permitida del equipo y registra qué tan fuerte es la solicitud:

Ese modo de observación es la parte que más me gusta. El agente comienza registrando lo que habría hecho, para que el equipo pueda leer esos registros en la pestaña Evaluación y ampliar sus permisos solo cuando parezcan correctos. Los mensajes, comentarios y documentos citados se tratan como elementos de entrada para una decisión. No pueden cambiar lo que el agente puede hacer.

El artículo de diseño muestra cómo se ve el trabajo proactivo en la práctica. En el grupo de usuarios interno del arnés DeepSeek, el equipo configuró una política de «reproducción y reparación silenciosa». Cuando alguien informa un problema o analiza un cambio propuesto, el agente intenta reproducirlo y encontrar una solución en segundo plano, y entrega un resultado solo después de haber confirmado el problema y encontrado una solución simple. De lo contrario, permanece en silencio. El artículo también ofrece una regla contundente para los canales de chat que los autores dicen haber verificado: limitar cada respuesta a 100 palabras. En GitHub, por el contrario, las solicitudes de extracción deben ser densas, con los antecedentes del problema, la descripción del cambio y los resultados de la verificación.

De forma predeterminada, cada mensaje GitHub que publica el agente comienza con la línea «Esto es de un agente automatizado, no de un humano». Los equipos pueden editar eso, junto con el resto de las indicaciones.

¿Se mantienen las cifras de referencia?

El artículo incluye un pequeño experimento y los autores tienen cuidado de llamarlo sólo indicativo. Cuatro diseños se ejecutaron uno al lado del otro en un flujo de chat grupal y mensajes de CI: alrededor de 300 mensajes por ejecución, alrededor de 20 de ellos solicitudes de trabajo reales, cinco ejecuciones cada uno. El trabajo de codificación se simuló mediante una herramienta que simplemente consume tiempo, por lo que la prueba mide la programación y la coordinación, no la calidad del código de nadie.

Lea la tabla dos veces, porque el titular no es toda la historia. El diseño del enrutador redujo el tiempo de finalización de p95 a aproximadamente la mitad que el de una sola sesión, pero utilizó aproximadamente de dos a cuatro veces los tokens de lectura de caché. Y la fila más interesante es la segunda: eliminar el atajo de paso no hizo que las tareas terminaran más rápido o más lento, solo hizo que el enrutador tomara aproximadamente un 30 por ciento más de decisiones y quemara un 37 por ciento más de tokens.

Mi lectura es que el verdadero hallazgo se encuentra en las filas de una sola sesión. Con una indicación neutral, el modelo nunca llamó a un subagente en ninguna de las cinco ejecuciones. Hizo el trabajo por sí solo, los nuevos mensajes lo interrumpían continuamente y las tareas más lentas tardaron 29,5 minutos. Con un mensaje que le decía que delegara, delegó en cuatro de cinco ejecuciones, y en la ejecución restante el modelo consideró que el trabajo era «pequeño» y lo hizo él mismo. Una sola sesión depende del estado de ánimo de la modelo. Un enrutador al que no se le permite ejecutar código no puede cometer ese error.

Una prueba de estrés independiente realizada únicamente en el enrutador elevó la tasa de llegada de eventos dignos de decisión de aproximadamente 1 a aproximadamente 40 por minuto. El lote promedio creció de 1,0 a 2,8 eventos, el tiempo por solicitud aumentó sólo de 2,5 a 3,9 segundos y el tiempo amortizado por decisión cayó de 6,4 a 1,6 segundos. Cuantos más eventos se acumulan, más barato se vuelve cada uno, hasta un límite que, según los autores, depende de la duración del contexto y de cuántos eventos un modelo puede manejar con precisión en un turno.

DeepSeek acaba de abrir el código abierto de su prototipo de superagente. Una sesión de enrutador habla con las personas y reparte el trabajo, y los trabajadores aislados ejecutan tareas en paralelo a partir de eventos GitHub. En su propia prueba, el tiempo de finalización de p95 se redujo de 29,5 a 15,7 minutos en comparación con una sola sesión con subagentes.

La ballena vuelve a ser de código abierto.pic.twitter.com/mS4sRbHmyx

– Gordito (@kimmonismus)1 de noviembre de 2026

Estos son resultados autoinformados sobre el trabajo sintético. Muestran que la idea de programación es sólida. No muestran que el prototipo corrija los errores más rápido.

¿Qué dicen personas cercanas al proyecto sobre sus límites?

Poco después del lanzamiento, Cui Tianyi, del departamento de productos de DeepSeek y uno de los revisores finales del artículo de diseño, escribió cómo ve el diseño. Su encuadre es útil porque es modesto. Él nombra la compensación central como continuidad entre tareas versus rendimiento de las tareas.

En cuanto a los límites, la revisión es directa. El prototipo implementa sólo una parte del diseño propuesto. En el momento de su revisión, el arnés DeepSeek no tenía memoria a largo plazo incorporada entre las sesiones. Y el sistema ha sido validado únicamente en un entorno pequeño y confiable dentro de la empresa. La propia sección de problemas abiertos del artículo enumera el escalado del enrutador, la memoria durante meses, el trabajo sin sesiones, los límites de contexto entre agentes y cómo los agentes aislados deben comunicarse entre sí, y la seguridad.

¿Qué deberías comprobar antes de ejecutarlo?

La documentación es más sincera que la mayoría de las publicaciones de lanzamiento y vale la pena tratar sus advertencias como requisitos.

• Los trabajadores tienen amplio acceso.Ambos ajustes preestablecidos de permisos, para el enrutador y para los trabajadores, se ejecutan condanger-full-accesscomo usuario del sistema operativo del operador. Los envoltorios de cuenta eligen qué credenciales GitHub usa el agente, pero los documentos dicen que son valores predeterminados y no un límite de seguridad, porque un trabajador aún puede ejecutar un programa por ruta absoluta o leer su directorio de inicio. La recomendación es una cuenta de sistema operativo dedicada que contenga únicamente las credenciales del agente.
• La entrada que no es de confianza es la cuestión de seguridad abierta.El artículo advierte que si una inyección rápida o una intrusión en el servidor compromete el bucle del agente en la nube, se podría acceder a todos los dispositivos conectados y las credenciales que ingresan al contexto del modelo pueden filtrarse.
• Los humanos se fusionan por defecto.El agente nunca habilita la fusión automática en su propia cuenta. La fusión automática necesita la CLI de una segunda cuenta mencionada en el mensaje Requisitos de entrega, y las instrucciones predeterminadas solo lo permiten para solicitudes de extracción pequeñas y aprobadas de menos de 200 líneas modificadas.
• Está construido alrededor de un repositorio.Cada configuración supervisa un único repositorio GitHub, y Feishu, una herramienta de chat en el lugar de trabajo común en China, es la otra fuente de primera clase.
• Necesita el arnés DeepSeek y un proveedor de modelos.La configuración enumera Node.js 22.19 o posterior, pnpm, git 2.32 o posterior, tmux, Python 3.8 o posterior y GitHub CLI 2.48 o posterior. Configurar un proveedor de modelo es un paso del operador.
• El ruido es un costo.El documento de filosofía dice que no se debe utilizar el agente para producir volumen. Las solicitudes de extracción masivas y los mensajes de difusión le cuestan a su equipo más de lo que aportan.

¿Cómo lo probarías sin arriesgar tu repositorio principal?

La configuración tiene muchos pasos, por lo que el proyecto le pide que deje que un agente de codificación lo haga con usted. Según el archivo README, el agente hace una pregunta breve a la vez, muestra el plan completo una vez y luego instala y configura todo. Una primera ejecución cautelosa se ve así:

1. Elija un repositorio desechabley un usuario de máquina dedicado o una cuenta de sistema operativo. No utilice su propio inicio de sesión.
2. Cree una cuenta GitHub separada para el agente.Todo lo que escribe aparece bajo ese nombre.
3. Abra el repositorio en su agente de codificación y pegue el mensaje a continuación.Responda sus preguntas una a la vez.
4. Mantén la lista permitida para tiy dejar el modo de aceptación en pista.
5. Solicita algo pequeño.Desde una cuenta permitida, comenta@<agent login> <request>sobre un tema. Un ticket debería aparecer en la descripción general del panel en aproximadamente un minuto.
6. Lea la pestaña Evaluación durante una semana.Amplíe la lista o cambie a automático sólo cuando los registros «aceptarían» se vean bien.

Read SETUP.md in this repository and set up dsh-superagent with me.

El documento de filosofía del proyecto brinda a los operadores cuatro reglas que vale la pena repetir: comenzar con poco, sintonizar para lograr menos ruido, no usar el agente para producir volumen y ser dueño de lo que dice en su nombre.

¿A dónde debería ir el resto del trabajo del agente?

Supongamos que un trabajador pasa una hora realizando una prueba de integración poco fiable. La solicitud de extracción es la solución. Pero la investigación detrás de esto, qué pruebas fallaron, qué hipótesis descartó, qué mostró el cronograma, no pertenece a una descripción de relaciones públicas, y es exactamente lo que el crítico quiere cuestionar. Si eso se encuentra solo en una respuesta de chat, el siguiente agente o compañero de equipo comienza desde cero.

AgentGrid.ioestá diseñado para ese traspaso. Los humanos y los agentes de IA trabajan en los mismos documentos, aplicaciones y archivos en vivo, con una dirección estable, acceso controlado y un historial de versiones. Los documentos de AgentGrid.io describen la conexión de un agente con capacidad de comando ejecutandonpx @animaapp/cli@latest login. Un humano aprueba el nombre del agente, el equipo y lo que puede hacer: leer, escribir, compartir o publicar. Después de eso, los cambios del agente aparecen en el historial con su propio nombre. El prototipo no tiene integración AgentGrid.io incorporada, así que trátelo como un patrón para probar con sus trabajadores, no como una característica documentada.

En la práctica, el trabajador escribe su investigación como un archivo Markdown, el revisor comenta en una fila de la tabla, otro asistente ajusta el resumen y la solicitud de extracción se vincula a una versión actual en lugar de tres copias pegadas.

Para conocer otra versión de varias personas que comparten un agente, consulte nuestra guía paraBots del equipo Grok Bot. Y si se pregunta qué se ejecuta debajo de un agente alojado, nuestra guía paraClaude Managed Agentsanaliza la versión de Anthropic del mismo cerebro y manos divididas, que cita el artículo de DeepSeek.

¿Cuándo debería utilizar dsh-superagent y cuándo algo más?

• Utilice dsh-superagentaprender de un diseño serio y documentado, ejecutar un experimento contenido en un repositorio de bajo riesgo o tomar prestadas sus ideas: un enrutador que nunca ejecuta código, tickets con un alcance establecido, modo de observación antes que el modo automático.
• Utilice un único agente de codificación interactivocuando trabajas una tarea a la vez y quieres dirigirla paso a paso. El superagente está diseñado para la situación opuesta.
• Utilice AgentGrid.iocuando el resultado es un documento, informe o aplicación que varias personas y agentes necesitan revisar, editar y publicar, cualquiera que sea el agente que lo haya producido.

Preguntas frecuentes

¿Qué es el DeepSeek Super-Agent?

Es un prototipo de investigación llamado dsh-superagent, lanzado por el equipo Harness de DeepSeek el 31 de octubre de 2026 bajo la licencia del MIT. Es un agente de codificación proactivo para un repositorio GitHub. Una sesión de enrutador de larga duración recibe solicitudes y asigna cada una aceptada a su propia sesión de trabajo, que responde en la conversación original, generalmente con una solicitud de extracción.

¿Es el DeepSeek Super-Agent un producto oficial DeepSeek?

No. El README lo llama un prototipo de investigación solo como referencia y no un producto oficial DeepSeek, y dice que lo revise y adapte antes de usarlo en su propio entorno. Tampoco es idéntico a la versión interna ni a la implementación que describe el artículo de diseño.

¿En qué se diferencia un superagente de un subagente?

Un subagente agrega una capa debajo del agente de trabajo. Un superagente agrega una capa encima. En este diseño, el enrutador se ubica encima de muchos trabajadores, habla con la gente y distribuye tareas, mientras que cada trabajador maneja una tarea de forma aislada. El nombre tiene que ver con la posición, no con una afirmación de mayor inteligencia.

¿Necesita Feishu o solo GitHub?

GitHub por sí solo es suficiente. Feishu es una segunda fuente opcional y la documentación dice que un error de configuración de Feishu deshabilita solo la fuente Feishu.

¿Es seguro ejecutarlo en un repositorio de la empresa?

No como está. Los documentos dicen que los trabajadores se ejecutan con acceso completo como usuario del sistema operativo del operador y que las cuentas contenedoras no son un límite de aislamiento. Recomiendan una cuenta de sistema operativo dedicada, una cuenta de agente dedicada en GitHub, una breve lista de permitidos y un modo de observación mientras aprende cómo se comporta el agente.

¿Es más rápido que una única sesión de agente de codificación?

En la prueba simulada de los propios autores, el diseño del enrutador finalizó las tareas más lentas en 15,7 minutos frente a los 29,5 minutos de una sola sesión con una herramienta de subagente, utilizando más tokens. La prueba utilizó trabajo de codificación simulado y cinco ejecuciones por diseño, por lo que muestra beneficios de programación, no calidad del código.