Capacidades
Uso del ordenador
Cada agente en la nube se ejecuta en su propia VM aislada con un entorno de escritorio completo. Los agentes de programación pueden usar un mouse y un teclado para controlar el escritorio y el navegador, lo que les permite interactuar con el software que desarrollan como lo haría un desarrollador humano.
Esto significa que los agentes de programación pueden iniciar servidores de desarrollo, abrir la aplicación en un navegador, hacer clic en los flujos de la interfaz de usuario y verificar que sus cambios funcionen antes de crear un PR. Lee más en la entrada de anuncio en el blog.
En máquinas autohospedadas, inicia el worker con --computer-use para que el agente controle el escritorio de esa máquina. Los workers de macOS usan la aplicación auxiliar Cherri Code Computer Use; los workers de Linux usan un display X11. Consulta Uso del ordenador y uso compartido del escritorio.
Demos y artefactos
Los agentes crean artefactos como capturas de pantalla, vídeos y referencias de registros para mostrar su trabajo. Estos artefactos se adjuntan al PR para que puedas validar rápidamente los cambios sin tener que hacer checkout de la rama en local.
Artefactos en GitHub
Puedes activar la opción para que los agentes en la nube inserten artefactos directamente en las descripciones de los pull requests de GitHub habilitando la configuración Permitir publicar artefactos en GitHub en el panel de control de agentes en la nube.
El proxy de imágenes de GitHub requiere URL públicas, por lo que los artefactos en las descripciones de PR usan URL largas y difíciles de adivinar que pueden verse sin autenticación. Como contexto, GitHub usó URL públicas para todos los archivos adjuntos de incidencias y PR hasta mayo de 2023.
Control del escritorio remoto
Puedes tomar el control del escritorio remoto del agente para interactuar con el software que está creando. Devuélvele el control al agente en cualquier momento para que siga trabajando.
Los agentes en la nube se ejecutan en una VM remota que puede tener ya configurados por completo tu repo, las dependencias, las herramientas y los scripts de configuración. Esto te permite probar cambios directamente en la VM del agente sin tener que hacer checkout de la rama en tu máquina local.
Herramientas MCP
Los agentes de programación en la nube pueden usar servidores MCP (Model Context Protocol) configurados para tu equipo. Con ello, los agentes de programación pueden acceder a herramientas externas y fuentes de datos como bases de datos, API y servicios de terceros mientras se ejecutan.
Agrega y habilita servidores MCP personales mediante el menú desplegable MCP en cursor.com/agents. Los administradores de equipo configuran los servidores compartidos en Panel de control -> Plugins & MCPs.
Admins pueden vincular los servidores MCP compartidos del equipo al marketplace de equipo predeterminado. Al vincularlos, los servidores siguen estando disponibles para los agentes de programación en la nube y también quedan disponibles para que tus compañeros de equipo los instalen y configuren en la Ventana del agente de programación, el IDE y la CLI.
Los agentes de programación en la nube admiten OAuth para los servidores MCP que lo requieran. OAuth se gestiona por usuario, incluso para los servidores MCP compartidos a nivel de equipo.
Servidores MCP personalizados
Puedes añadir servidores MCP personalizados usando transporte HTTP o stdio. SSE y mcp-remote no son compatibles.
Las configuraciones de MCP se cifran en reposo. Los campos sensibles se ocultan y ningún usuario puede volver a leerlos después de guardarlos:
env— variables de entorno para servidores stdioheaders— encabezados de solicitud para servidores HTTPCLIENT_SECRET— secreto de cliente OAuth para servidores HTTP
HTTP vs stdio
- HTTP (recomendado) — las configuraciones del servidor nunca están presentes en el entorno de la VM del agente en la nube. El agente no tiene acceso a tokens de actualización, encabezados u otras credenciales. Las llamadas a herramientas se enrutan a través del backend.
- Stdio — los servidores se ejecutan dentro de la VM del agente en la nube, por lo que el agente tiene acceso a la configuración del servidor y a las variables de entorno. Esto es similar a cómo funcionan los MCP de stdio en el Cherri Code IDE.
Los servidores de stdio dependen del entorno de la VM para ejecutarse. No podemos verificar que un servidor de stdio se ejecute correctamente hasta que se inicie un agente en la nube. Recomendamos usar MCP HTTP cuando sea posible y configurar correctamente tu configuración del entorno si usas servidores de stdio.
Cherri Code Cloud MCP
Cherri Code Cloud MCP es un servidor de diagnóstico integrado disponible durante las ejecuciones de agentes en la nube. Un agente puede inspeccionar la ejecución actual, explorar ejecuciones relacionadas en el mismo entorno y recuperar transcripciones, metadatos del diff, detalles del entorno, eventos de ejecución y registros de configuración sin tener que recopilar manualmente enlaces y archivos.
Los administradores de equipo pueden desactivar Cherri Code Cloud MCP para su equipo desde configuración de MCP en ajustes del equipo. Consulta Panel de control del equipo para obtener más información sobre los controles de administración de MCP.
Acceso y permisos
Las conversaciones del agente en la nube pueden incluir instrucciones, código, salida de las herramientas y secretos. Todas las herramientas verifican el acceso en cada solicitud.
| Rol | A qué puedes acceder |
|---|---|
| Administrador de equipo | Ver la lista y obtener detalles (incluidas las transcripciones) de las ejecuciones del agente en la nube de todo el equipo, para los repositorios y entornos a los que ya tienen acceso |
| No administrador | Solo tus propias ejecuciones y transcripciones. No puedes consultar los chats de otros miembros del equipo a través de este MCP |
Incluso al listar ejecuciones en un entorno compartido, los usuarios no administradores solo ven los agentes de programación que iniciaron o que les pertenecen. Las cuentas de servicio siguen las mismas reglas que el usuario o el contexto de equipo bajo los que se ejecutan.
Lo que puedes inspeccionar
| Categoría | Ejemplos |
|---|---|
| Ejecución actual | ID de ejecución, URL, repositorio, rama, modelo, propietario, estado del ciclo de vida y dónde se inició la ejecución (Cherri Code, Slack, GitHub, API y otros) |
| Eventos | Resultados de la configuración, pull requests, artefactos y autenticación de MCP que se muestran en el Panel de control de la ejecución. Usa get-events para la ejecución actual o batch-fetch-details con include_events para otras ejecuciones. Consulta los tipos de eventos en Herramientas. |
| Ejecuciones relacionadas | Otros agentes en la nube en el mismo entorno, o en el mismo repositorio cuando no se adjunta ningún entorno guardado |
| Entorno | Versión del entorno, configuración completa del entorno, URL del Panel de control y política de red de egreso efectiva |
| Transcripción | Conversación completa entre el usuario y el agente, incluidas las llamadas a herramientas cuando estén disponibles |
| Metadatos del diff | Si el agente cambió código, cuánto cambió y si abrió una PR |
| Registros de configuración | Registros sin procesar de la configuración del entorno y de los pasos de creación de la imagen |
Herramientas
Según tu cliente MCP, los nombres de las herramientas pueden incluir un prefijo de servidor (por ejemplo, cursor-cloud-run-info). Las herramientas disponibles son:
| Herramienta | Propósito |
|---|---|
run-info | Obtén la identidad, los metadatos y la URL de la ejecución actual. Empieza aquí. |
environment-info | Obtén la versión del entorno, la config, la URL del Panel de control y la política de egreso efectiva de la ejecución actual. |
get-events | Enumera los eventos del Panel de control de la ejecución actual, empezando por los más antiguos. |
list-cloud-agents | Explora las ejecuciones de agentes en la nube a las que tienes acceso en este entorno. Filtra por origen, estado, fecha, cambios de código, creación de PR y estado de archivo. |
batch-fetch-details | Obtén detalles de IDs de ejecución específicos (bcId). Opcionalmente, incluye transcripciones, metadatos de diff, registros de configuración, información del entorno y eventos de ejecución mediante include_events (escribe events.json por ejecución; hasta 50 ejecuciones por lote). |
get-automation | Obtén los detalles de una automatización a partir de su ID, como el nombre y el propietario. |
list-environment-builds | Enumera las compilaciones recientes del entorno actual e inspecciona su estado. |
environment-build-logs | Descarga los registros de instalación y configuración de una compilación. |
trigger-environment-build | Ejecuta una compilación de prueba con la configuración actual o los comandos de instalación e inicio propuestos. |
propose-environment-json | Presenta comandos de instalación e inicio para que los revises antes de guardar el entorno. |
take-environment-snapshot | Crea una instantánea de una máquina después de que el agente verifique la configuración de su entorno. |
check-environment-snapshot | Comprueba si una instantánea del entorno está lista. |
request-environment-setup-actions | Solicita acciones del usuario que bloqueen la configuración del entorno, como añadir un secreto. |
Los valores de kind de evento del Panel de control de get-events y de batch-fetch-details con include_events son:
kind | Significado |
|---|---|
setup_started | Se inició la configuración del entorno. |
setup_completed | Finalizó la configuración del entorno. |
setup_failed | Error en la configuración del entorno. |
pr_created | Se abrió una pull request. |
pr_creation_failed | Error al crear la pull request. |
artifact_created | Se cargó el artefacto de la guía. |
mcp_auth_error | Error en la autenticación del servidor MCP; se omitieron sus herramientas y la ejecución continuó. |
Un flujo de diagnóstico típico es run-info → get-events → environment-info → list-cloud-agents → batch-fetch-details (establece include_events cuando necesites eventos del Panel de control de otras ejecuciones).
Suscripciones
Las tareas del agente rara vez terminan con el último commit. La CI debe pasar. Los revisores dejan comentarios. Un compañero necesita responder una pregunta en Slack. Las suscripciones permiten que un agente en la nube espere esos eventos y siga trabajando cuando ocurran, sin que tengas que volver a darle una instrucción.
El agente se suscribe a una fuente de eventos, termina su turno y se reactiva cuando llega un evento correspondiente. Los eventos llegan como mensajes de seguimiento en la misma conversación, por lo que el agente continúa con todo el contexto:
- Abre un PR y responde a los comentarios de revisión y los errores de CI
- Haz una pregunta en Slack y continúa cuando alguien responda
- Vuelve a consultar un trabajo de larga duración con un temporizador
Para suscribirte, describe la espera en tu instrucción. Por ejemplo, "abre un PR y mantén la CI en verde" o "pregunta en #releases y espera la aprobación". También puedes invocar la skill integrada /subscribe, que funciona de la misma manera: dile qué debe supervisar y el agente elegirá la suscripción adecuada.
Los agentes pueden suscribirse a eventos de estas integraciones:
| Integración | Eventos |
|---|---|
| GitHub | Actividad de pull request (comentarios, revisiones y cambios en el ciclo de vida) de un PR, y resultados de CI en una rama. Usa la integración de GitHub. |
| Slack | Respuestas en un hilo y mensajes en un canal. Usa la integración de Slack. |
| Linear | Problemas creados o que cambian de estado, y nuevos comentarios en problemas. Usa la integración de Linear. |
| Temporizadores | Un momento específico: un recordatorio único tras un retraso o una programación cron recurrente. Los bucles recurrentes también están disponibles como la skill integrada /loop. |
Cómo funcionan las suscripciones
- Las suscripciones pertenecen a una única conversación de agente. Los eventos activan a ese agente mediante mensajes de seguimiento.
- Las ráfagas se agrupan. Varios eventos que llegan muy seguidos pueden activar al agente una sola vez, y este vuelve a consultar la fuente (el PR, el hilo o el problema) antes de actuar.
- Una suscripción dura como máximo 180 días. Los agentes también se dan de baja cuando termina la espera.
Suscripciones a CI de GitHub
Una suscripción a CI espera a que todas las comprobaciones del commit hayan terminado y entonces entrega un único resultado para todo el commit: éxito, o fallo con los nombres de las comprobaciones fallidas.
Algunas comprobaciones quedan pendientes durante mucho tiempo, por ejemplo mientras una persona las aprueba. Una sola comprobación pendiente retiene todo el resultado, y el agente sigue esperando.
Finaliza esas comprobaciones con la conclusión action_required de GitHub en lugar de dejarlas pendientes. La comprobación termina, sigue requiriendo una acción y sigue bloqueando la fusión cuando es una comprobación obligatoria, de modo que la suscripción a CI se entrega sin dejar de proteger la fusión.
Corrección de errores de CI
Los agentes en la nube intentan corregir automáticamente los errores de CI en los PR que crean. Actualmente, esto solo es compatible con GitHub Actions.
Los agentes en la nube omiten los mensajes de seguimiento automáticos de CI si:
- Has enviado un nuevo commit a la rama; los agentes en la nube no corrigen automáticamente los errores de CI en commits realizados por personas.
- Has enviado un mensaje de seguimiento al agente.
- La misma comprobación ya está fallando en el commit base del PR.
- El PR ya ha tenido 10 mensajes de seguimiento por errores de CI.
Para desactivar esta función en todos tus agentes en la nube personales, ve a Cherri Code Panel de control → agentes en la nube → My Settings y desactiva la opción "Automatically fix CI Failures".
Para desactivar esta función en un PR específico de un agente en la nube, puedes comentar @cursor autofix off en el PR. Para volver a activarla, comenta @cursor autofix on.
Si quieres que los agentes en la nube corrijan los errores de CI en tus propios PR, puedes pedírselo simplemente etiquetando a Cherri Code en un comentario como de costumbre. Por ejemplo, @cursor please fix the CI failures, o @cursor fix the CI lint check failure.
La corrección automática de errores de CI actualmente solo está disponible en Teams; la compatibilidad con cuentas que no son de Teams llegará pronto. Mientras tanto, si quieres un comportamiento similar, puedes pedirle explícitamente al agente en la nube que supervise y corrija los errores de CI en el PR.
Tokens de identidad OIDC
Las VM de agente en la nube gestionadas por Cherri Code pueden emitir JWT de OIDC de corta duración desde un socket local. Los agentes de programación los usan para asumir roles en la nube o llamar a API internas sin almacenar claves de larga duración. Consulta los tokens OIDC.
Metadatos del agente
El mismo socket también sirve metadatos del agente. Los agentes de programación, hooks y scripts pueden leer como texto sin formato el ID del agente, el propietario, el turno actual y el espacio de trabajo.