¿Qué es un agente en segundo plano de Cursor?
Primero, el nombre: la documentación de Cursor dice que "los Cloud Agents se llamaban antes Background Agents." Mismo producto, nombre nuevo — usamos ambos en esta guía. [3] Un agente en segundo plano es un agente de código que se ejecuta durante un largo tramo de tiempo lejos de tu portátil: la tarea se traslada a la nube, y un agente la lleva de principio a fin sin interrupción, y luego informa con pruebas de que el trabajo está hecho. [1]
Cada uno se ejecuta en su propia máquina virtual dedicada con un entorno de desarrollo completo — tu repositorio, dependencias, secretos y acceso de red. El agente planifica la tarea, edita código, ejecuta comandos y prueba su trabajo durante minutos u horas, y sigue adelante esté tu máquina conectada o no. [1] La VM está en sandbox y aislada de tu máquina local, y tú controlas qué repositorios, secretos y acceso de red recibe un entorno. [1]
Cuando el trabajo está hecho, el agente abre un pull request — y muestra su trabajo. Mientras se ejecuta, adjunta capturas de pantalla, vídeos y referencias de logs al PR para que puedas validar los cambios sin descargar la rama. [1] Los Cloud Agents incluso pueden manejar su propio escritorio y navegador, haciendo clic a través de flujos de interfaz para verificar que lo que construyeron realmente funciona antes de hacer push. [2]
Cinco formas de iniciar uno
Puedes lanzar un Cursor Cloud Agent desde donde ya trabajas: [3]
En Cursor Desktop
Selecciona Cloud junto al campo de entrada del agente y entrégale la tarea.
En la web o en iPhone
Inicia y gestiona agentes desde Cursor Web (cursor.com/agents) o Cursor para iOS.
Desde donde vive el trabajo
Menciona a @Cursor en Slack, en un issue o PR de GitHub o Bitbucket, o asígnale un issue de Linear.
Con Automations
Ejecuta agentes según un horario (cron) o ante eventos de GitHub, GitLab, Slack, Linear y webhooks.
Desde tu propio código
Inicia y gestiona agentes mediante la API.
Automations está documentado por separado. [4] Antes de que alguien pueda iniciar un agente desde un repositorio, un administrador de la cuenta de Cursor conecta el control de código fuente: GitHub (Cloud y Enterprise Server), GitLab (Cloud y Self-Hosted), Bitbucket Cloud o Azure DevOps. [3]
Por qué ejecutar muchos es la parte difícil
La característica principal es fácil de pasar por alto: puedes ejecutar tantos agentes como quieras en paralelo, y ninguno necesita que tu máquina local esté conectada. [3] Paralelo es todo el sentido. Un solo agente en segundo plano es una comodidad agradable; cinco ejecutándose a la vez es un cambio de escala en cuánto se entrega por semana.
Pero los agentes en paralelo cambian cuál es el cuello de botella. Los agentes pueden programar todo el día — lo que no pueden hacer es decidir qué vale la pena hacer, en qué orden, y si el trabajo está realmente terminado. Cada agente que añades consume más de tu atención justo en los momentos en que estás más ocupado: definiendo la siguiente tarea, revisando un PR recién terminado, detectando un agente que se ha desviado. Ejecuta suficientes sin gestión y pasas el día saltando entre paneles en lugar de dirigir el producto.
Hay un segundo fallo, más silencioso: la calidad. Un agente que se ejecuta sin supervisión durante una hora construirá con gusto lo equivocado de forma preciosa si la instrucción era vaga. Con un agente, lo notas. Con diez, instrucciones vagas se convierten silenciosamente en diez pull requests equivocados.
Y esos pull requests equivocados cuestan dinero real. "Los Cloud Agents se cobran al precio de API del modelo elegido… una ventana de contexto más grande puede aumentar el uso de tokens y los costes." [3] El paralelismo multiplica esa factura — así que una historia vaga no solo es tiempo de revisión desperdiciado, son tokens gastados construyendo lo equivocado, varias veces.
Así que la habilidad que importa con los agentes en segundo plano no es iniciarlos — Cursor lo redujo a una mención. Es alimentarlos. Los equipos que más sacan de los agentes en paralelo son los que pueden escribir trabajo lo bastante afilado como para ejecutarse sin supervisión, y mantener a la vista cada agente en marcha sin estar encima de ninguno. Cuántos puedes realmente seguir es sobre todo una cuestión de capacidad de revisión.
Prácticas que mantienen sana una flota
Escribe la historia antes de despachar
Da a cada agente un alcance claro y criterios de aceptación, no una sensación. Una historia afilada con una definición de terminado se ejecuta sin supervisión; una difusa vuelve mal.
Mantén la cola en un solo lugar
Planifica en un tracker como Linear para saber siempre qué está en cola, qué se está ejecutando y qué está bloqueado — no disperso entre hilos de Slack y pestañas de terminal.
Deja que los agentes tomen su propio trabajo
Una vez que tus historias son suficientemente buenas, los agentes pueden lanzarse directamente desde el issue al que pertenecen — en Linear, Slack o GitHub — en lugar de que copies y pegues prompts uno a uno.
Vigila la desviación, no solo la finalización
Un agente que corre dos horas en el problema equivocado cuesta más que uno que termina rápido en el correcto. Revisa la desviación de alcance pronto, no solo en el PR.
Confía en los artefactos, verifica los bordes
Los agentes adjuntan capturas, vídeos y logs a sus PRs — úsalos para revisar rápido sin descargar cada rama, y profundiza solo donde importa.
Usa entornos multi-repositorio cuando el trabajo abarca varios servicios
Para tareas que tocan frontend, backend y bibliotecas compartidas en una sola ejecución, un entorno multi-repositorio permite que un agente vea y cambie el panorama completo.
Una nota sobre esa última práctica: los entornos multi-repositorio permiten que un solo agente trabaje a través de repositorios separados de frontend, backend, infraestructura o bibliotecas compartidas, y abra pull requests en cada repositorio que modifique. [3] Pero incluso el mejor entorno multi-repositorio trabaja una tarea a la vez — decidir cuál debe ser la historia a nivel de arquitectura, en todos esos repositorios, sigue siendo tu trabajo. Para saber cómo escribirla, consulta nuestra guía sobre historias para agentes de código.
Cursor ya se integra con Linear — ¿para qué más?
Pregunta justa. Puedes asignar un issue de Linear a @Cursor y un Cloud Agent lo toma, [5] y Automations puede iniciar agentes desde eventos de GitHub, Linear o Slack. [4] Cursor es un muy buen motor. Lo que no hace es decidir qué ejecutar, ni en qué orden — ejecuta el issue que le des, cuando se lo des.
Ese es el hueco que Aerunit llena. Piensa en Cursor como el motor y Aerunit como el despachador: hace que el issue valga la pena ejecutarse, lo envía cuando está listo para ejecutarse, y devuelve los hallazgos de revisión a la misma sesión del agente para que los corrija.
Dónde encaja Aerunit
Además de la propia integración de Cursor con Linear y Automations, Aerunit añade cuatro cosas:
- Escribe las historias. Describes el trabajo; Aerunit lee cada repositorio que la historia toca y propone issues de Linear con alcance, criterios de aceptación y no-objetivos — una historia padre más un sub-issue por repositorio para trabajo entre repositorios.
- Despacha en orden de dependencia. Aerunit sigue las relaciones blocks/blocked-by de Linear, así que cuando un PR se fusiona, los issues que bloqueaba van automáticamente a Cursor Cloud Agents — sin despachar a mano.
- Revisa cada PR. Cuando un agente abre un pull request, Aerunit ejecuta una revisión de código y devuelve los hallazgos a la misma sesión del agente para que los corrija — así el agente que escribió el código es el que lo arregla.
- Muestra toda la flota. Una lista de cada sesión de Cloud Agent en marcha, cada una vinculada a su issue de Linear — envía mensajes a varias a la vez, archiva las terminadas.
Motor: Cursor
Ejecuta cada tarea en su propia VM en la nube y abre el pull request.
Despachador: Aerunit
Escribe la historia, la envía cuando su bloqueador se fusiona, revisa el PR.
Preguntas frecuentes
¿Cuántos agentes en segundo plano de Cursor puedo ejecutar a la vez?
Tantos como quieras, en paralelo — se ejecutan en sus propias VMs y no necesitan que tu máquina esté conectada. Quedan dos límites prácticos: el coste, porque los Cloud Agents se cobran al precio de API del modelo elegido y cada agente en paralelo se suma a esa factura; y la revisión, porque cada agente te entrega un pull request para revisar. [3]
Cursor ya tiene una integración con Linear y Automations — ¿para qué Aerunit?
Cursor es el motor: asignas un issue de Linear a @Cursor y un agente lo ejecuta, o disparas ejecuciones desde eventos con Automations. Aerunit es el despachador encima: escribe las historias (entre repositorios), sigue las relaciones de bloqueo de Linear para que la siguiente parte empiece cuando se fusione su bloqueador, revisa cada PR de agente automáticamente y envía los hallazgos de vuelta al agente, y muestra todas las sesiones en marcha en una sola lista, cada una vinculada a su issue de Linear. [5] [4]
¿Los agentes en segundo plano se ejecutan en mi ordenador?
No. Cada Cloud Agent se ejecuta en una máquina virtual dedicada en la nube con tu repositorio, dependencias, secretos y acceso de red — aislada y en sandbox respecto a tu máquina local. Puedes cerrar tu portátil y revisar el resultado más tarde. [1]
¿Cómo sé lo que el agente hizo realmente?
Los agentes adjuntan capturas de pantalla, vídeos y referencias de logs al pull request para que puedas validar el trabajo sin descargar la rama. También puedes tomar el control del escritorio remoto del agente para probar el software tú mismo. [2]
¿Puede un agente en segundo plano trabajar en varios repositorios?
Sí. Los entornos multi-repositorio permiten que un solo agente inspeccione todo el espacio de trabajo, haga cambios coordinados entre repositorios de frontend, backend, infraestructura o bibliotecas compartidas, y abra un pull request en cada repositorio que modifique. [3]