DeepSeek Super-agent: qué son los agentes de programación en la nube y dónde encaja

Se ha extendido un nuevo hábito en las herramientas para desarrolladores: dejar una tarea en algún sitio —una Issue, una mención en un chat, un cuadro de prompt—, cerrar el portátil y volver para encontrar una rama o una solicitud de incorporación de cambios creada por un agente mientras no estabas. GitHub, Cursor, OpenAI, Anthropic, Cognition y xAI ya ofrecen alguna versión, con nombres como agente en la nube, agente en segundo plano, sesión en la nube o ingeniero de software autónomo. Este artículo explica la categoría: qué hacen realmente estos productos, cómo funciona el ciclo, a qué renuncias y qué lugar ocupa el prototipo de Super-agent de código abierto de DeepSeek.

Qué se considera un agente de programación en la nube

La etiqueta es imprecisa, así que conviene identificar los tres elementos que comparten todos los productos de esta categoría:

• Un activador que no requiere tener un editor abierto. El trabajo llega como una asignación de Issue, una @mención en Slack o Feishu, un prompt en una aplicación web, una llamada a la API o una transferencia desde la CLI.
• Un entorno fuera de tu máquina. El agente clona el repositorio, instala lo que necesita y trabaja en un entorno aislado o espacio de trabajo gestionado por el proveedor o tu organización.
• Un resultado que se puede revisar. Termina con una rama, un diff, un borrador de PR o un comentario: algo que una persona pueda revisar y sobre lo que pueda actuar.

Esto distingue la categoría de dos alternativas cercanas. Un agente de IDE local se ejecuta en tu portátil mientras lo observas; un asistente de chat responde preguntas sin tocar el repositorio. Un agente de programación en la nube se sitúa entre ambos: tiene herramientas reales y una copia local real del repositorio, pero la idea es que la persona pueda marcharse.

La palabra bot describe la versión de la misma idea basada en chat. En vez de asignar una Issue, mencionas al agente en Slack, Teams o Feishu. Cambia el activador, pero no el entorno remoto. El resultado puede ser un PR, un diff o un conjunto de archivos terminados.

El panorama de productos

Seis productos, descritos según sus propios proveedores:

Grok Bot es la opción más amplia: xAI lo describe como un compañero de equipo de IA persistente, al que se puede iniciar desde un chat en desktop o móvil, o mencionando @bot en X cuando las cuentas están vinculadas. Se ejecuta en una máquina en la nube por cuenta, alojada por Cursor, con acceso al navegador, al almacenamiento y a la línea de comandos. Su documentación describe archivos terminados y borradores, no un flujo de trabajo con repositorios; no documenta la creación de ramas ni de PR. Eso lo sitúa en el extremo de los bots del espectro.

Hay cuatro diferencias más importantes que la tabla:

Dónde se encuentra el activador. El agente en la nube de GitHub Copilot y OpenAI Codex Cloud están diseñados para trabajar con tareas que ya se encuentran en GitHub o en la aplicación ChatGPT. Cursor Cloud Agents y Devin se basan más en el chat: un hilo de Slack o Teams es el punto de entrada. Las sesiones en la nube de Claude Code aceptan activadores desde un navegador, un teléfono, la aplicación de escritorio o claude --cloud en una terminal, y también pueden ejecutarse según una programación.

Cuánto revela el proveedor. Claude Code documenta el aislamiento con detalle: en los entornos alojados por Anthropic, cada sesión se ejecuta en una VM aislada, el acceso a la red está limitado de forma predeterminada y las credenciales de git permanecen fuera del entorno aislado, mientras un proxy se autentica en nombre de la sesión. Las organizaciones pueden dirigir las sesiones a un entorno autogestionado, en cuyo caso son responsables del aislamiento. Las sesiones en la nube comparten los límites de solicitudes de tu plan, sin cargos aparte por VM; requieren iniciar sesión en claude.ai y no están disponibles cuando Claude Code se configura para Amazon Bedrock, Agent Platform de Google Cloud u otro proveedor externo. Los demás proveedores publican menos información sobre los aspectos internos; «entorno aislado» o «VM» suele ser todo lo que incluye la descripción pública.

Qué puede tocar el agente. Algunos productos se limitan a un solo repositorio; otros ofrecen trabajo en toda la organización o en varios repositorios. Es lo primero que debes comprobar en relación con tu propia configuración, porque un agente capaz con acceso al repositorio equivocado es inútil o peligroso.

Para qué tipo de trabajo sirve. La mayoría de los productos de esta lista se ocupan de tareas de programación limitadas a un repositorio. Grok Bot es un compañero de equipo general en la nube: su documentación describe archivos y borradores, no un flujo de trabajo con repositorios. Entiende «agente en la nube» como un espectro, no como una única forma de producto.

Cómo funciona realmente el ciclo

Si dejamos de lado la marca, el ciclo es parecido en todas partes:

1. Recepción. Llega un activador. El producto decide si se trata de una tarea real, a veces hace una pregunta para aclarar algún detalle y pone en cola una sesión.
2. Entorno. El agente clona el repositorio en la rama adecuada, ejecuta un script de configuración o una imagen e instala las herramientas necesarias. El acceso a la red y los secretos se configuran aquí, no después.
3. Trabajo. El agente lee código, edita archivos, ejecuta pruebas y comandos y, en ocasiones, abre un navegador. Las tareas largas continúan aunque tu portátil entre en suspensión.
4. Resultado. Sube una rama y abre un PR, o deja un diff y un resumen por escrito. Algunos productos devuelven borradores de PR porque se espera que el agente se detenga antes de fusionar los cambios.
5. Revisión. Una persona lee el diff, comenta y decide si fusiona los cambios, solicita modificaciones o retoma el trabajo en una sesión local. Algunos productos también pueden supervisar el PR y subir correcciones si falla la CI.

Las diferencias que pueden dar problemas están en los pasos 2 y 5. Un script de configuración que tarda demasiado, un repositorio que el agente no puede clonar, una política de red que bloquea un registro de paquetes o una credencial que el entorno aislado no puede ver detendrán una tarea que parecía sencilla. Y «resultado que se puede revisar» sigue significando que una persona lo revisa: ninguno de estos productos elimina el paso de revisión, sino que traslada la escritura.

Por qué esta ola se produce ahora

Tuvieron que coincidir tres condiciones. Los modelos se volvieron lo bastante fiables como para ejecutar ciclos largos de uso de herramientas sin supervisión constante. Los entornos aislados y los scripts de configuración se abarataron lo suficiente como para asignar un entorno propio a cada tarea. Y las solicitudes de incorporación de cambios se convirtieron en la interfaz predeterminada entre un agente y quien revisa el trabajo, de modo que los equipos no tuvieron que inventar un proceso de revisión nuevo.

También hay un argumento relacionado con la atención. El ensayo complementario de diseño de DeepSeek lo plantea explícitamente: un modelo limita la capacidad de resolver una tarea individual, pero la atención limita el rendimiento de una persona en muchas tareas. Un agente en la nube le quita de encima a la persona la gestión de sesiones, los cambios de contexto y las esperas. Esa afirmación procede del ensayo de DeepSeek, no de un estudio independiente, pero explica por qué esta categoría resulta útil.

A qué renuncias

Todos los productos alojados intercambian control por comodidad:

• Límite de confianza. Tu código y, a veces, tus credenciales salen de tu máquina. Los proveedores publican distintos niveles de detalle sobre el aislamiento, la retención y el acceso a la red; consulta la información de cada producto en lugar de dar por sentado que toda la categoría funciona igual.
• Aislamiento. Una VM gestionada está diseñada para contener al agente, pero sigue siendo el entorno del proveedor. «Entorno aislado» puede referirse a cualquier cosa, desde una VM reforzada hasta un contenedor con amplio acceso a la red.
• Personalización. Los agentes alojados ofrecen ajustes, no código fuente. Si tu flujo de trabajo requiere otro activador, otra regla de revisión u otro modelo, estás limitado a lo que ofrece el producto.
• Modelo de costes. La mayoría de estos productos se factura mediante una suscripción o un plan con límites de uso; el tiempo del agente no es una partida cuyo coste controles directamente. Haz el presupuesto según el plan, no según los tokens.
• Alcance y dependencia del proveedor. La compatibilidad con varios repositorios, las integraciones de chat y los controles empresariales varían según el proveedor, y migrar un flujo de trabajo de uno a otro tiene un coste.

La opción autohospedada: Super-agent de DeepSeek

El lanzamiento de DeepSeek resulta interesante porque plantea cómo sería el mismo ciclo si conservaras el control. El repositorio contiene un plugin de TypeScript con licencia MIT para DeepSeek Harness (DSH), versión 0.1.0, publicado como prototipo de investigación. El README lo deja claro: está adaptado para su publicación, no es idéntico a la versión interna de DeepSeek y no implementa todas las ideas del ensayo de diseño.

Su estructura consta de una sesión persistente de Router y una sesión de Worker por cada ticket. Los eventos siguen esta secuencia: Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor. Un equipo autoriza el trabajo mediante una política; se aceptan las @menciones explícitas de personas autorizadas, mientras que el trabajo proactivo empieza en modo observe, que registra lo que habría hecho el agente sin crear tickets. Cada ticket tiene su propia sesión y directorio; un comando de preparación puede crear un árbol de trabajo de git por ticket.

El modelo operativo es lo opuesto a un entorno aislado de un proveedor. Escucha un único repositorio de github.com (no GitHub Enterprise Server) y, de forma opcional, Feishu. Los ajustes preestablecidos de Router y Worker se ejecutan ambos con danger-full-access como usuario del sistema operativo del operador; los wrappers de cuenta eligen las credenciales del agente, pero no aíslan el proceso. La guía de implementación recomienda usar una cuenta dedicada del sistema operativo que tenga únicamente las credenciales del agente. El estado se guarda en SQLite, en un stateDir configurado. La filosofía se expresa como una meta: dedicar la menor atención humana posible y obtener el mayor valor posible.

El ensayo presenta cifras de planificación basadas en una carga de trabajo sintética —unas 300 notificaciones y 20 solicitudes de trabajo, herramientas simuladas y cinco ejecuciones—, con un p50/p95 de alrededor de 12.4 / 15.7 minutos, frente a unos 29.5 minutos de p95 en una línea de base de sesión única que no realizaba llamadas a subagentes. Esas son mediciones propias del ensayo con herramientas simuladas, no un benchmark independiente de calidad de programación.

Lo que demuestra el prototipo es más concreto y útil que el lanzamiento de un producto: el agente de programación que se activa ante eventos y se revisa al final no está confinado a la nube de un proveedor. Puedes controlar el orquestador, el estado y la elección del modelo. También demuestra el coste de tener ese control: ejecutas el proceso, proteges la cuenta y aceptas que el prototipo no incluye un entorno aislado de forma predeterminada.

Quién debería elegir cada opción

Quédate con un agente en la nube alojado si quieres olvidarte de las operaciones, tener un entorno aislado gestionado por un proveedor, funciones para varios repositorios o para organizaciones y un activador en GitHub, Slack, Teams o una aplicación web. El proveedor se ocupa del aislamiento y el tiempo de actividad.

Considera el prototipo autohospedado si el código no puede salir de tu infraestructura, necesitas modificar la orquestación o quieres elegir el modelo para cada rol. Reserva presupuesto para una máquina dedicada o una cuenta del sistema operativo y trata el código como software de investigación.

Una combinación práctica: agentes alojados para el trabajo rutinario en repositorios y un agente autohospedado solo para los repositorios donde importa mantener los datos dentro de ciertos límites. El paso de revisión es el mismo en ambos casos.

Una nota sobre los modelos

El prototipo no fija un modelo en el código. Usa el modelo predeterminado del perfil de Harness, a menos que Eval o Execution lo sobrescriban, de modo que un equipo puede asignar un modelo más ligero al Router y otro más potente a los Workers. AIHubMix conecta DeepSeek Harness mediante un endpoint compatible con OpenAI en https://aihubmix.com/v1; el ejemplo de la guía de DeepSeek Harness usa el proveedor aihubmix y el modelo auto. La guía explica la conexión básica con DSH, no el complemento Super-agent, y los productos alojados mencionados arriba gestionan su propia selección de modelos.

Preguntas frecuentes

¿Qué es un agente de programación en la nube?
Un software que recibe una tarea de programación desde una incidencia, una mención en un chat o una llamada a la API, la ejecuta en un entorno fuera de tu máquina y devuelve una rama, un diff o una solicitud de incorporación de cambios para que la revises.

¿Es lo mismo que un agente de programación local?
No. Un agente local se ejecuta en tu terminal o IDE mientras lo supervisas. Un agente en la nube sigue trabajando cuando cierras el portátil y está pensado para revisarse más tarde.

¿Aun así hay que revisar el código?
Sí. Todos los productos de aquí terminan con un diff o una solicitud de incorporación de cambios que debe revisar una persona. El agente se encarga de escribir, no de aprobar.

¿Dónde se ejecuta el código?
En el entorno del proveedor. Los detalles varían: Copilot describe un entorno aislado en la nube o un entorno de Actions; Cursor, máquinas virtuales aisladas; Codex, un espacio de trabajo en la nube; Claude Code, una máquina virtual aislada gestionada por Anthropic o el entorno autohospedado de una organización; y Devin, un espacio de trabajo con terminal, editor y navegador. Lee la documentación de seguridad de cada proveedor antes de confiarle código privado.

¿Qué es un bot de programación?
La versión integrada en el chat de la misma idea: mencionas al agente en Slack, Teams o Feishu en lugar de asignarle una incidencia. Sigue trabajando en un entorno remoto; el resultado puede ser una solicitud de incorporación de cambios o un diff, o, en el caso de un compañero de equipo de propósito general como Grok Bot, archivos terminados y borradores.

¿Qué aporta Super-agent de DeepSeek?
Una implementación autohospedada con licencia MIT del mismo ciclo, con un diseño Router–Worker, un modelo de políticas e incidencias y compatibilidad opcional con Feishu. Es un prototipo de investigación, no un producto alojado.

¿Está listo para producción?
No. El README lo describe como código de investigación, los ajustes preestablecidos se ejecutan con danger-full-access y no hay un entorno aislado predeterminado. Si lo pruebas, usa una cuenta dedicada del sistema operativo y una cuenta de GitHub exclusiva para el agente.

Fuentes

1. deepseek-ai/dsh-superagent-prototype — README, el ensayo de diseño que cita y docs/000–008
2. Conectar DeepSeek Harness a AIHubMix — AIHubMix
3. Agente en la nube de GitHub Copilot — Documentación de GitHub
4. Agentes en la nube de Cursor — Documentación de Cursor
5. Codex Cloud — ChatGPT Learn / OpenAI
6. Claude Code en la nube — Anthropic
7. Documentación de Devin — Cognition
8. Documentación de Grok Bot — xAI