Las Automatizaciones de Cursor te ahorran tiempo al automatizar tareas repetitivas con agentes siempre activos. Esta versión incorpora la skill /automate, nuevos disparadores para GitHub y Slack, y compatibilidad con el uso del ordenador.
Añade el emoji designado como reacción a cualquier mensaje de Slack para iniciar una automatización. En Cursor, usamos esto para activar automatizaciones específicas directamente desde Slack.
#Herramienta de uso del ordenador para automatizaciones
Los Cloud Agents iniciados por automatizaciones ahora pueden usar sus propios equipos para generar demos o artefactos de su trabajo.
La herramienta de uso del ordenador está habilitada por defecto en todas las automatizaciones. Solo tienes que especificar en tus instrucciones que el agente debe incluir una demo de su trabajo.
Para empezar, actualiza a la versión más reciente de Cursor. Obtén más información en nuestra documentación.
Las automatizaciones ahora pueden guardarse en un estado incompleto, para que puedas salir y configurar una autenticación de MCP sin perder tu progreso
Las automatizaciones ahora pueden abrir PR por defecto; así que ya no tienes que especificar esa herramienta en la interfaz
Ahora puedes eliminar archivos de memoria en la interfaz o pedirle a tu automatización que elimine memorias desactualizadas cuando se ejecute
Cursor ahora puede ayudarte a configurar tu entorno de desarrollo en Cloud en menos de 10 minutos. Puedes seguir el progreso del agente en una sesión de terminal compartida mientras se encarga de tareas de configuración, como instalar dependencias.
Tu entorno queda guardado en una instantánea reutilizable, para que los futuros agentes en Cloud arranquen más rápido y puedan probar cambios ejecutando tu software. El agente puede iterar durante largos periodos de tiempo hasta que se verifiquen los resultados. Esto beneficia a todo tu equipo al hacer commit de .cursor/environment.json.
Usa /in-cloud para iniciar un subagente en Cloud en su propia VM y trabajar en la siguiente tarea que envíes. Se ejecuta en su propia VM y rama, para que tu espacio de trabajo local se mantenga limpio y responsive.
Esto es especialmente útil para aislar trabajo de larga duración o en paralelo, como solucionar problemas de CI, investigar una incidencia o explorar una base de código mientras sigues trabajando localmente.
También puedes pedirle a un subagente en Cloud que vigile una PR haciendo clic en la pastilla de acción rápida o usando /babysit. El agente en Cloud iterará de forma remota para preparar tu PR para fusionarla sin bloquear la sesión local.
El subagente en Cloud puede ejecutarse en segundo plano sin interrumpir al agente principal, que puede seguir ejecutándose localmente o en Cloud.
Traslada las sesiones de agente de forma más fiable entre tu equipo local y Cloud. Puedes sacar de tu máquina las tareas de larga duración y ejecutar tantos agentes en Cloud en paralelo como quieras. Vuelve a traer un agente de Cloud a tu entorno local para probar tú mismo los cambios.
El tiempo promedio de revisión de Bugbot es ahora de ~90 segundos, frente a ~5 minutos. Bugbot también encuentra, en promedio, un 10% más de errores por revisión — 0.62, frente a 0.56 — y cuesta ~22% menos por ejecución.
Estas mejoras de rendimiento son posibles gracias a los avances que hemos logrado al entrenar Composer 2.5, que ahora potencia Bugbot. Bugbot respeta las listas de bloqueo de modelos, y la velocidad y el rendimiento pueden variar según tu configuración.
Ahora puedes ejecutar Bugbot y Revisión de seguridad con /review antes de hacer push del código. /review te pide que elijas qué agentes ejecutar, o puedes usar /review-bugbot y /review-security directamente.
/review también se sincroniza con Bugbot en GitHub y GitLab. Si ejecutas /review y luego abres una PR con la misma diferencia, Bugbot la reconoce, omite la revisión y deja un comentario indicando que esa diferencia ya se revisó.
Disponible en Cursor 3.7+ y en cursor.com/agents; próximamente, compatible con CLI.
Ahora puedes configurar Bugbot para que solo revise lo nuevo desde la última revisión, manteniendo los comentarios centrados en tus cambios más recientes.
Haz clic en dos o más elementos a la vez en el navegador. Cursor ve los elementos seleccionados, su código, el diseño que los rodea y las relaciones visuales en la página.
Pídele al agente que haga coincidir uno con otro, elimine el contenido repetido o ajuste un grupo de componentes a la vez.
Describe los cambios a través de la superposición de Design Mode. El micrófono sigue disponible mientras un agente está ejecutándose, para que puedas poner en cola el siguiente cambio por voz sin esperar a que termine el anterior.
Hemos lanzado un conjunto de nuevas funcionalidades en los SDK de TypeScript y Python. Ahora puedes elegir cómo se almacenan los metadatos del agente y de la ejecución, exponer tus propias funciones al agente como herramientas, dirigir las llamadas locales a herramientas a través de Auto-review y anidar subagentes con cualquier nivel de profundidad. Esta versión también incorpora un conjunto de correcciones de fiabilidad, rendimiento y plataforma que facilitan la ejecución de agentes del SDK locales y en Cloud en scripts de producción, CI e integraciones personalizadas.
Ahora puedes proporcionar tus propias herramientas al agente local pasando definiciones de funciones mediante local.customTools, en Agent.create() o en cada send(). El SDK se las expone al agente a través de un servidor MCP integrado llamado custom-user-tools, para que el modelo llame a tu código a través de la misma ruta y el mismo control de permisos que cualquier otra herramienta MCP.
Antes, exponer una capacidad personalizada implicaba configurar tu propio servidor MCP por stdio o HTTP remoto y conectarlo al agente. Ahora basta con una definición de función. Las herramientas personalizadas también son visibles para todos los subagentes de un agente principal, así que una herramienta que defines una vez queda disponible durante toda la ejecución.
Por defecto, un agente local del SDK ejecuta llamadas a herramientas sin pedir aprobación, ya que no hay ningún humano supervisando en una ejecución sin interfaz. Configura local.autoReview para que esas llamadas pasen por Auto-review. Un clasificador decide qué llamadas se ejecutan automáticamente y cuáles se dejan en espera, en lugar de omitir la revisión por completo.
Controlas ese clasificador con instrucciones en lenguaje natural en permissions.json. El campo autoRun.allow_instructions describe patrones de llamadas que conviene permitir, y autoRun.block_instructions describe las que deben dejarse para revisión. Por ejemplo, puedes permitir inspecciones de solo lectura de artefactos de compilación y pausar siempre ante operaciones destructivas, como las eliminaciones.
{ "autoRun": { "allow_instructions": [ "Read-only inspections of build artifacts under ./dist are fine." ], "block_instructions": [ "Always pause delete operations so I get a chance to review them." ] }}
Ambos SDK conservan los metadatos de agentes y ejecuciones para que puedas reanudar un agente después de reiniciar el proceso. Hasta ahora, ese almacén era SQLite. Ahora también puedes optar por un almacén JSONL, que escribe un archivo de texto sin formato de solo anexado que puedes leer, comparar e incluir en el control de versiones. Tanto SqliteLocalAgentStore como JsonlLocalAgentStore se exportan directamente.
Si ninguna de las opciones predeterminadas se adapta a tu configuración, implementa la interfaz pública LocalAgentStore y pásala a través de local.store. Crea un almacén en memoria para ejecuciones efímeras de CI, o usa Postgres para la persistencia cuando quieras que el estado del agente se almacene junto con el resto de los datos de tu aplicación. El SDK de Python expone almacenes de host, JSONL y JSONL compuestos a través del puente.
Ahora los subagentes pueden crear sus propios subagentes, y así sucesivamente. Un subagente revisor puede delegar en un subagente que escriba pruebas, que a su vez puede seguir delegando, y cada nivel mantiene su propio prompt y modelo. No hace falta activar nada; una sesión de subagente registra el ejecutor que necesita para llamar a Task, por lo que el anidamiento funciona automáticamente para cualquier agente que defina subagentes.
Esta versión también incluye una serie de correcciones de calidad de vida en ambos SDK.
Correlación de ejecuciones: Cada send() ahora incluye un requestId generado por la plataforma, expuesto en Run y RunResult y persistido en los almacenes en memoria, SQLite y JSONL. Vincula una ejecución de script o CI con los logs del backend, las analíticas y los hilos de soporte sin tener que inferirlo a partir de agentId.
wait() fiable en ejecuciones locales: Las ejecuciones locales ya no resuelven wait() antes de que se escriba el resultado del terminal. La hidratación sigue actualizándose hasta que la ejecución alcanza un estado final, para que la automatización lea un resultado completo.
Checkpoints seguros al liberar recursos: Liberar un agente local ya no elimina los datos de checkpoint cuando falta una referencia raíz pero todavía existen blobs de checkpoint. El directorio del agente solo se borra cuando de verdad no queda nada que conservar.
Streaming de Cloud sobre HTTP/1.1: Las sesiones de agentes en Cloud ahora se transmiten correctamente en transportes HTTP/1.1 usados por algunos proxies, implementaciones antiguas de fetch en Node y ciertas imágenes de CI. El comportamiento en HTTP/2 no cambia.
Importación más ligera: Importar @cursor/sdk ya no carga de forma anticipada toda la pila local de agentes. Los consumidores que solo usan Cloud o solo tipos evitan el coste del runtime local hasta la primera llamada local, sin cambios en la API. La primera llamada local sí asume ese coste de importación una sola vez y luego queda en caché.
Tipos de TypeScript autocontenidos: Los archivos .d.ts publicados ya no hacen referencia a paquetes del workspace no publicados. Esto soluciona los errores TS2305 y TS2307 con skipLibCheck: false y los any silenciosos en tipos de stream como TurnEndedUpdate.
ripgrep incluido: Las ejecuciones locales de shell usan el binario rg incluido para la plataforma sin modificar tu PATH global. En Windows, anteponer ripgrep ya no sobrescribe la variable Path.
Composer 2 se redirige a Composer 2.5: Los clientes del SDK que todavía fijan slugs retirados de composer-2 se redirigen automáticamente a Composer 2.5, manteniendo intactas las variantes rápidas, para que los scripts antiguos sigan funcionando.
list_runs con ámbito de workspace: Client, AsyncClient y Agent.list_runs aceptan un cwd opcional, y el puente usa como fallback el workspace desde el que se inició. Esto soluciona resultados espurios de "agent not found" cuando el puente se ejecuta como subproceso.
Errores de "no encontrado" más claros: Buscar un agente que no está en el workspace resuelto devuelve un error claro de no encontrado en lugar de un error interno opaco.
Versión 0.1.6 y analíticas: cursor-sdk 0.1.6 documenta la ruta de lanzamiento de Buildkite y etiqueta el uso del SDK como sdk-python- para ofrecer analíticas más claras.
Ejecuta npm install @cursor/sdk o pip install cursor-sdk para actualizar. Los scripts que fijan composer-2 pasan a Composer 2.5 automáticamente, y requestId es una incorporación segura al esquema de metadatos de tus ejecuciones. Consulta la documentación de TypeScript y Python para ver todos los detalles.
Las Automatizaciones de Cursor te ahorran tiempo al automatizar tareas repetitivas con agentes siempre activos. Esta versión incorpora la skill /automate, nuevos disparadores para GitHub y Slack, y compatibilidad con el uso del ordenador.
Añade el emoji designado como reacción a cualquier mensaje de Slack para iniciar una automatización. En Cursor, usamos esto para activar automatizaciones específicas directamente desde Slack.
#Herramienta de uso del ordenador para automatizaciones
Los Cloud Agents iniciados por automatizaciones ahora pueden usar sus propios equipos para generar demos o artefactos de su trabajo.
La herramienta de uso del ordenador está habilitada por defecto en todas las automatizaciones. Solo tienes que especificar en tus instrucciones que el agente debe incluir una demo de su trabajo.
Para empezar, actualiza a la versión más reciente de Cursor. Obtén más información en nuestra documentación.
Las automatizaciones ahora pueden guardarse en un estado incompleto, para que puedas salir y configurar una autenticación de MCP sin perder tu progreso
Las automatizaciones ahora pueden abrir PR por defecto; así que ya no tienes que especificar esa herramienta en la interfaz
Ahora puedes eliminar archivos de memoria en la interfaz o pedirle a tu automatización que elimine memorias desactualizadas cuando se ejecute
Cursor ahora puede ayudarte a configurar tu entorno de desarrollo en Cloud en menos de 10 minutos. Puedes seguir el progreso del agente en una sesión de terminal compartida mientras se encarga de tareas de configuración, como instalar dependencias.
Tu entorno queda guardado en una instantánea reutilizable, para que los futuros agentes en Cloud arranquen más rápido y puedan probar cambios ejecutando tu software. El agente puede iterar durante largos periodos de tiempo hasta que se verifiquen los resultados. Esto beneficia a todo tu equipo al hacer commit de .cursor/environment.json.
Usa /in-cloud para iniciar un subagente en Cloud en su propia VM y trabajar en la siguiente tarea que envíes. Se ejecuta en su propia VM y rama, para que tu espacio de trabajo local se mantenga limpio y responsive.
Esto es especialmente útil para aislar trabajo de larga duración o en paralelo, como solucionar problemas de CI, investigar una incidencia o explorar una base de código mientras sigues trabajando localmente.
También puedes pedirle a un subagente en Cloud que vigile una PR haciendo clic en la pastilla de acción rápida o usando /babysit. El agente en Cloud iterará de forma remota para preparar tu PR para fusionarla sin bloquear la sesión local.
El subagente en Cloud puede ejecutarse en segundo plano sin interrumpir al agente principal, que puede seguir ejecutándose localmente o en Cloud.
Traslada las sesiones de agente de forma más fiable entre tu equipo local y Cloud. Puedes sacar de tu máquina las tareas de larga duración y ejecutar tantos agentes en Cloud en paralelo como quieras. Vuelve a traer un agente de Cloud a tu entorno local para probar tú mismo los cambios.
El tiempo promedio de revisión de Bugbot es ahora de ~90 segundos, frente a ~5 minutos. Bugbot también encuentra, en promedio, un 10% más de errores por revisión — 0.62, frente a 0.56 — y cuesta ~22% menos por ejecución.
Estas mejoras de rendimiento son posibles gracias a los avances que hemos logrado al entrenar Composer 2.5, que ahora potencia Bugbot. Bugbot respeta las listas de bloqueo de modelos, y la velocidad y el rendimiento pueden variar según tu configuración.
Ahora puedes ejecutar Bugbot y Revisión de seguridad con /review antes de hacer push del código. /review te pide que elijas qué agentes ejecutar, o puedes usar /review-bugbot y /review-security directamente.
/review también se sincroniza con Bugbot en GitHub y GitLab. Si ejecutas /review y luego abres una PR con la misma diferencia, Bugbot la reconoce, omite la revisión y deja un comentario indicando que esa diferencia ya se revisó.
Disponible en Cursor 3.7+ y en cursor.com/agents; próximamente, compatible con CLI.
Ahora puedes configurar Bugbot para que solo revise lo nuevo desde la última revisión, manteniendo los comentarios centrados en tus cambios más recientes.
Haz clic en dos o más elementos a la vez en el navegador. Cursor ve los elementos seleccionados, su código, el diseño que los rodea y las relaciones visuales en la página.
Pídele al agente que haga coincidir uno con otro, elimine el contenido repetido o ajuste un grupo de componentes a la vez.
Describe los cambios a través de la superposición de Design Mode. El micrófono sigue disponible mientras un agente está ejecutándose, para que puedas poner en cola el siguiente cambio por voz sin esperar a que termine el anterior.
Hemos lanzado un conjunto de nuevas funcionalidades en los SDK de TypeScript y Python. Ahora puedes elegir cómo se almacenan los metadatos del agente y de la ejecución, exponer tus propias funciones al agente como herramientas, dirigir las llamadas locales a herramientas a través de Auto-review y anidar subagentes con cualquier nivel de profundidad. Esta versión también incorpora un conjunto de correcciones de fiabilidad, rendimiento y plataforma que facilitan la ejecución de agentes del SDK locales y en Cloud en scripts de producción, CI e integraciones personalizadas.
Ahora puedes proporcionar tus propias herramientas al agente local pasando definiciones de funciones mediante local.customTools, en Agent.create() o en cada send(). El SDK se las expone al agente a través de un servidor MCP integrado llamado custom-user-tools, para que el modelo llame a tu código a través de la misma ruta y el mismo control de permisos que cualquier otra herramienta MCP.
Antes, exponer una capacidad personalizada implicaba configurar tu propio servidor MCP por stdio o HTTP remoto y conectarlo al agente. Ahora basta con una definición de función. Las herramientas personalizadas también son visibles para todos los subagentes de un agente principal, así que una herramienta que defines una vez queda disponible durante toda la ejecución.
Por defecto, un agente local del SDK ejecuta llamadas a herramientas sin pedir aprobación, ya que no hay ningún humano supervisando en una ejecución sin interfaz. Configura local.autoReview para que esas llamadas pasen por Auto-review. Un clasificador decide qué llamadas se ejecutan automáticamente y cuáles se dejan en espera, en lugar de omitir la revisión por completo.
Controlas ese clasificador con instrucciones en lenguaje natural en permissions.json. El campo autoRun.allow_instructions describe patrones de llamadas que conviene permitir, y autoRun.block_instructions describe las que deben dejarse para revisión. Por ejemplo, puedes permitir inspecciones de solo lectura de artefactos de compilación y pausar siempre ante operaciones destructivas, como las eliminaciones.
{ "autoRun": { "allow_instructions": [ "Read-only inspections of build artifacts under ./dist are fine." ], "block_instructions": [ "Always pause delete operations so I get a chance to review them." ] }}
Ambos SDK conservan los metadatos de agentes y ejecuciones para que puedas reanudar un agente después de reiniciar el proceso. Hasta ahora, ese almacén era SQLite. Ahora también puedes optar por un almacén JSONL, que escribe un archivo de texto sin formato de solo anexado que puedes leer, comparar e incluir en el control de versiones. Tanto SqliteLocalAgentStore como JsonlLocalAgentStore se exportan directamente.
Si ninguna de las opciones predeterminadas se adapta a tu configuración, implementa la interfaz pública LocalAgentStore y pásala a través de local.store. Crea un almacén en memoria para ejecuciones efímeras de CI, o usa Postgres para la persistencia cuando quieras que el estado del agente se almacene junto con el resto de los datos de tu aplicación. El SDK de Python expone almacenes de host, JSONL y JSONL compuestos a través del puente.
Ahora los subagentes pueden crear sus propios subagentes, y así sucesivamente. Un subagente revisor puede delegar en un subagente que escriba pruebas, que a su vez puede seguir delegando, y cada nivel mantiene su propio prompt y modelo. No hace falta activar nada; una sesión de subagente registra el ejecutor que necesita para llamar a Task, por lo que el anidamiento funciona automáticamente para cualquier agente que defina subagentes.
Esta versión también incluye una serie de correcciones de calidad de vida en ambos SDK.
Correlación de ejecuciones: Cada send() ahora incluye un requestId generado por la plataforma, expuesto en Run y RunResult y persistido en los almacenes en memoria, SQLite y JSONL. Vincula una ejecución de script o CI con los logs del backend, las analíticas y los hilos de soporte sin tener que inferirlo a partir de agentId.
wait() fiable en ejecuciones locales: Las ejecuciones locales ya no resuelven wait() antes de que se escriba el resultado del terminal. La hidratación sigue actualizándose hasta que la ejecución alcanza un estado final, para que la automatización lea un resultado completo.
Checkpoints seguros al liberar recursos: Liberar un agente local ya no elimina los datos de checkpoint cuando falta una referencia raíz pero todavía existen blobs de checkpoint. El directorio del agente solo se borra cuando de verdad no queda nada que conservar.
Streaming de Cloud sobre HTTP/1.1: Las sesiones de agentes en Cloud ahora se transmiten correctamente en transportes HTTP/1.1 usados por algunos proxies, implementaciones antiguas de fetch en Node y ciertas imágenes de CI. El comportamiento en HTTP/2 no cambia.
Importación más ligera: Importar @cursor/sdk ya no carga de forma anticipada toda la pila local de agentes. Los consumidores que solo usan Cloud o solo tipos evitan el coste del runtime local hasta la primera llamada local, sin cambios en la API. La primera llamada local sí asume ese coste de importación una sola vez y luego queda en caché.
Tipos de TypeScript autocontenidos: Los archivos .d.ts publicados ya no hacen referencia a paquetes del workspace no publicados. Esto soluciona los errores TS2305 y TS2307 con skipLibCheck: false y los any silenciosos en tipos de stream como TurnEndedUpdate.
ripgrep incluido: Las ejecuciones locales de shell usan el binario rg incluido para la plataforma sin modificar tu PATH global. En Windows, anteponer ripgrep ya no sobrescribe la variable Path.
Composer 2 se redirige a Composer 2.5: Los clientes del SDK que todavía fijan slugs retirados de composer-2 se redirigen automáticamente a Composer 2.5, manteniendo intactas las variantes rápidas, para que los scripts antiguos sigan funcionando.
list_runs con ámbito de workspace: Client, AsyncClient y Agent.list_runs aceptan un cwd opcional, y el puente usa como fallback el workspace desde el que se inició. Esto soluciona resultados espurios de "agent not found" cuando el puente se ejecuta como subproceso.
Errores de "no encontrado" más claros: Buscar un agente que no está en el workspace resuelto devuelve un error claro de no encontrado en lugar de un error interno opaco.
Versión 0.1.6 y analíticas: cursor-sdk 0.1.6 documenta la ruta de lanzamiento de Buildkite y etiqueta el uso del SDK como sdk-python- para ofrecer analíticas más claras.
Ejecuta npm install @cursor/sdk o pip install cursor-sdk para actualizar. Los scripts que fijan composer-2 pasan a Composer 2.5 automáticamente, y requestId es una incorporación segura al esquema de metadatos de tus ejecuciones. Consulta la documentación de TypeScript y Python para ver todos los detalles.
