Automações do Cursor economizam tempo ao automatizar tarefas repetitivas com agentes sempre ativos. Esta versão apresenta a habilidade /automate, novos gatilhos para GitHub e Slack e suporte a uso do computador.
Reaja a qualquer mensagem do Slack com um emoji específico para acionar uma automação. Na Cursor, usamos isso para acionar automações específicas direto do Slack.
Agentes na nuvem iniciados por automações agora podem usar seus próprios computadores para gerar demonstrações ou artefatos do trabalho que realizam.
A ferramenta de uso do computador está habilitada por padrão em todas as automações, basta dizer ao agente para incluir uma demonstração do seu trabalho nas instruções.
Para começar, atualize para a versão mais recente do Cursor. Saiba mais na nossa documentação.
Automações agora podem ser salvas em estado incompleto, para que você possa sair da página para configurar uma autenticação MCP sem perder seu progresso
Automações agora podem abrir PRs por padrão; assim, você não precisa mais especificar essa ferramenta na interface
Agora você pode excluir arquivos de memória na interface ou pedir à sua automação para excluir memórias desatualizadas quando ela for executada
Agora, o Cursor pode ajudar você a configurar seu ambiente de desenvolvimento na nuvem em menos de 10 minutos. Você pode acompanhar o progresso do agente em uma sessão compartilhada do Terminal enquanto ele cuida de tarefas de configuração, como instalar dependências.
Seu ambiente é salvo em um snapshot reutilizável, para que futuros agentes na nuvem iniciem mais rápido e possam testar alterações executando seu software. Ele pode continuar iterando por longos períodos até que as saídas sejam verificadas. Isso beneficia toda a sua equipe quando essa configuração é commitada em .cursor/environment.json.
Use /in-cloud para iniciar um subagente na nuvem em sua própria VM e trabalhar na próxima tarefa que você enviar. Ele é executado em sua própria VM e branch, para que seu espaço de trabalho local permaneça limpo e responsivo.
Isso é especialmente útil para isolar trabalhos de longa duração ou paralelos, como corrigir a CI, investigar um problema ou explorar uma base de código enquanto você continua trabalhando localmente.
Você também pode pedir a um subagente na nuvem para acompanhar uma PR clicando no botão de ação rápida ou usando /babysit. O agente na nuvem fará iterações remotamente para preparar sua PR para merge sem ocupar a sessão local.
O subagente na nuvem pode ser executado em segundo plano sem interromper o agente principal, que pode continuar sendo executado localmente ou na nuvem.
Transfira sessões de agente com mais confiabilidade entre seu computador local e a nuvem. Você pode tirar da sua máquina tarefas de longa duração e executar quantos agentes na nuvem quiser em paralelo. Traga um agente na nuvem de volta para o ambiente local para testar as alterações você mesmo.
O tempo médio de revisão do Bugbot agora é de ~90 segundos, abaixo de ~5 minutos. O Bugbot também encontra, em média, 10% mais bugs por revisão — 0,62, acima de 0,56 — e custa ~22% menos por execução.
Esses ganhos de performance foram possíveis graças aos avanços que fizemos no treinamento do Composer 2.5, que agora alimenta o Bugbot. O Bugbot respeita listas de bloqueio de modelos, e a velocidade e a performance podem variar dependendo da sua configuração.
Agora você pode executar Bugbot e Revisão de segurança com /review antes de fazer push do código. O /review pede que você escolha quais agentes executar, ou você pode usar /review-bugbot e /review-security diretamente.
/review também sincroniza com o Bugbot no GitHub e no GitLab. Se você executar /review e depois abrir uma PR com o mesmo diff, o Bugbot a reconhece, ignora a revisão e deixa um comentário informando que aquele diff já foi revisado.
Disponível no Cursor 3.7+ e em cursor.com/agents, com suporte na CLI em breve.
Agora você pode configurar o Bugbot para revisar apenas o que há de novo desde a última revisão, mantendo o feedback focado nas suas atualizações mais recentes.
Clique em dois ou mais elementos no Browser ao mesmo tempo. O Cursor vê os elementos selecionados, o código deles, o layout ao redor e as relações visuais na página.
Peça ao agente para fazer com que um corresponda ao outro, remover conteúdo repetido ou ajustar um grupo de componentes de uma só vez.
Descreva as alterações pela sobreposição do Design Mode. O microfone continua disponível enquanto um agente está em execução, para que você possa enfileirar a próxima alteração por voz sem esperar a anterior terminar.
Entregamos um conjunto de novas funcionalidades nos SDKs de TypeScript e Python. Agora você pode escolher como os metadados do agente e da execução são persistidos, expor suas próprias funções ao agente como ferramentas, encaminhar chamadas de ferramentas locais por meio do Auto-review e aninhar subagentes em qualquer profundidade. Esta versão também traz um conjunto de correções de confiabilidade, performance e plataforma que facilitam a execução de agentes de SDK locais e na nuvem em scripts de produção, CI e integrações personalizadas.
Agora você pode passar suas próprias ferramentas para o agente local fornecendo definições de função por meio de local.customTools, em Agent.create() ou em cada send(). O SDK as expõe ao agente por meio de um servidor MCP integrado chamado custom-user-tools, para que o modelo chame seu código pelo mesmo caminho e com o mesmo controle de permissões que qualquer outra ferramenta MCP.
Antes, expor uma capacidade personalizada significava configurar seu próprio servidor MCP stdio ou HTTP remoto e conectá-lo ao agente. Agora, uma definição de função é suficiente. As ferramentas personalizadas também ficam visíveis para todos os subagentes de um agente pai, então uma ferramenta definida uma vez fica disponível ao longo de toda a execução.
Por padrão, um agente local do SDK executa chamadas de ferramenta sem pedir aprovação, já que não há nenhum humano no processo em uma execução headless. Defina local.autoReview para encaminhar essas chamadas para o Auto-review. Um classificador decide quais chamadas são executadas automaticamente e quais devem ser mantidas em espera, em vez de ignorar a revisão por completo.
Você orienta esse classificador com instruções em linguagem natural em permissions.json. O campo autoRun.allow_instructions descreve padrões de chamadas que devem tender a ser permitidos, e autoRun.block_instructions descreve aqueles que devem ser mantidos para revisão. Por exemplo, você pode permitir inspeções somente leitura de artefatos de build, sempre pausando em operações destrutivas, como exclusões.
{ "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 os SDKs persistem os metadados de agentes e execuções para que você possa retomar um agente após reiniciar um processo. Até agora, esse armazenamento era feito em SQLite. Agora, você também pode optar por um armazenamento em JSONL, que grava um arquivo simples, append-only, que você pode ler, comparar com diff e versionar. Tanto SqliteLocalAgentStore quanto JsonlLocalAgentStore são exportados diretamente.
Se nenhuma das opções padrão se adequar à sua configuração, implemente a interface pública LocalAgentStore e passe-a por local.store. Crie um armazenamento em memória para execuções efêmeras de CI ou use o Postgres como backend de persistência quando quiser que o estado do agente fique junto com o restante dos dados da sua aplicação. O SDK de Python expõe armazenamentos de host, JSONL e JSONL composto por meio da bridge.
Os subagentes agora podem criar seus próprios subagentes, e assim por diante. Um subagente revisor pode delegar para um subagente que escreve testes, que pode delegar ainda mais, com cada nível mantendo seu próprio prompt e modelo. Não há nada para ativar; uma sessão de subagente registra o executor necessário para chamar Task, então o aninhamento funciona automaticamente para qualquer agente que defina subagentes.
#Melhorias de confiabilidade, performance e plataforma
Esta versão também inclui uma série de correções que melhoram a experiência em ambos os SDKs.
Correlação de execuções: Todo send() agora inclui um requestId gerado pela plataforma, exposto em Run e RunResult e persistido nos armazenamentos em memória, SQLite e JSONL. Vincule um script ou uma execução de CI a logs de backend, análises e threads de suporte sem precisar inferi-lo a partir de agentId.
wait() confiável em execuções locais: Execuções locais não resolvem mais wait() antes que o resultado do terminal seja gravado. A hidratação continua sendo atualizada até que a execução chegue a um estado final, para que a automação leia um resultado completo.
Checkpoints seguros ao descartar: Descartar um agente local não remove mais dados de checkpoint quando falta uma referência raiz, mas ainda existem blobs de checkpoint. O diretório do agente só é limpo quando realmente não há mais nada a preservar.
Streaming na nuvem por HTTP/1.1: Sessões de agente na nuvem agora fazem streaming corretamente em transportes HTTP/1.1 usados por alguns proxies, implementações fetch mais antigas do Node e certas imagens de CI. O comportamento em HTTP/2 permanece inalterado.
Importação mais leve: Importar @cursor/sdk não carrega mais antecipadamente toda a stack de agente local. Consumidores que usam apenas a nuvem ou apenas tipos evitam o custo do tempo de execução local até a primeira chamada local, sem nenhuma mudança na API. A primeira chamada local paga o custo de uma importação única e depois permanece em cache.
Tipos TypeScript autocontidos: Os arquivos .d.ts publicados não fazem mais referência a pacotes de espaço de trabalho não publicados. Isso corrige erros TS2305 e TS2307 com skipLibCheck: false e o any silencioso em tipos de stream como TurnEndedUpdate.
ripgrep empacotado: Execuções locais de shell usam o binário rg empacotado da plataforma sem modificar o seu PATH global. No Windows, adicionar o ripgrep no início não sobrescreve mais a variável Path.
Composer 2 direciona para Composer 2.5: Clientes SDK que ainda fixam slugs composer-2 descontinuados são direcionados automaticamente para o Composer 2.5, preservando as variantes rápidas, para que scripts mais antigos continuem funcionando.
list_runs com escopo de espaço de trabalho: Client, AsyncClient e Agent.list_runs aceitam um cwd opcional, e a bridge usa como fallback o espaço de trabalho em que foi iniciada. Isso corrige resultados espúrios de "agente não encontrado" quando a bridge é executada como subprocesso.
Erros de não encontrado mais claros: Buscar um agente que não está no espaço de trabalho resolvido retorna um erro claro de não encontrado, em vez de um erro interno opaco.
Versão 0.1.6 e análises: cursor-sdk 0.1.6 documenta o caminho de release do Buildkite e rotula o uso do SDK como sdk-python- para análises mais claras.
Execute npm install @cursor/sdk ou pip install cursor-sdk para atualizar. Scripts que fixam composer-2 passam automaticamente para o Composer 2.5, e requestId é uma adição segura ao esquema de metadados da sua execução. Consulte a documentação do TypeScript e do Python para ver todos os detalhes.
Automações do Cursor economizam tempo ao automatizar tarefas repetitivas com agentes sempre ativos. Esta versão apresenta a habilidade /automate, novos gatilhos para GitHub e Slack e suporte a uso do computador.
Reaja a qualquer mensagem do Slack com um emoji específico para acionar uma automação. Na Cursor, usamos isso para acionar automações específicas direto do Slack.
Agentes na nuvem iniciados por automações agora podem usar seus próprios computadores para gerar demonstrações ou artefatos do trabalho que realizam.
A ferramenta de uso do computador está habilitada por padrão em todas as automações, basta dizer ao agente para incluir uma demonstração do seu trabalho nas instruções.
Para começar, atualize para a versão mais recente do Cursor. Saiba mais na nossa documentação.
Automações agora podem ser salvas em estado incompleto, para que você possa sair da página para configurar uma autenticação MCP sem perder seu progresso
Automações agora podem abrir PRs por padrão; assim, você não precisa mais especificar essa ferramenta na interface
Agora você pode excluir arquivos de memória na interface ou pedir à sua automação para excluir memórias desatualizadas quando ela for executada
Agora, o Cursor pode ajudar você a configurar seu ambiente de desenvolvimento na nuvem em menos de 10 minutos. Você pode acompanhar o progresso do agente em uma sessão compartilhada do Terminal enquanto ele cuida de tarefas de configuração, como instalar dependências.
Seu ambiente é salvo em um snapshot reutilizável, para que futuros agentes na nuvem iniciem mais rápido e possam testar alterações executando seu software. Ele pode continuar iterando por longos períodos até que as saídas sejam verificadas. Isso beneficia toda a sua equipe quando essa configuração é commitada em .cursor/environment.json.
Use /in-cloud para iniciar um subagente na nuvem em sua própria VM e trabalhar na próxima tarefa que você enviar. Ele é executado em sua própria VM e branch, para que seu espaço de trabalho local permaneça limpo e responsivo.
Isso é especialmente útil para isolar trabalhos de longa duração ou paralelos, como corrigir a CI, investigar um problema ou explorar uma base de código enquanto você continua trabalhando localmente.
Você também pode pedir a um subagente na nuvem para acompanhar uma PR clicando no botão de ação rápida ou usando /babysit. O agente na nuvem fará iterações remotamente para preparar sua PR para merge sem ocupar a sessão local.
O subagente na nuvem pode ser executado em segundo plano sem interromper o agente principal, que pode continuar sendo executado localmente ou na nuvem.
Transfira sessões de agente com mais confiabilidade entre seu computador local e a nuvem. Você pode tirar da sua máquina tarefas de longa duração e executar quantos agentes na nuvem quiser em paralelo. Traga um agente na nuvem de volta para o ambiente local para testar as alterações você mesmo.
O tempo médio de revisão do Bugbot agora é de ~90 segundos, abaixo de ~5 minutos. O Bugbot também encontra, em média, 10% mais bugs por revisão — 0,62, acima de 0,56 — e custa ~22% menos por execução.
Esses ganhos de performance foram possíveis graças aos avanços que fizemos no treinamento do Composer 2.5, que agora alimenta o Bugbot. O Bugbot respeita listas de bloqueio de modelos, e a velocidade e a performance podem variar dependendo da sua configuração.
Agora você pode executar Bugbot e Revisão de segurança com /review antes de fazer push do código. O /review pede que você escolha quais agentes executar, ou você pode usar /review-bugbot e /review-security diretamente.
/review também sincroniza com o Bugbot no GitHub e no GitLab. Se você executar /review e depois abrir uma PR com o mesmo diff, o Bugbot a reconhece, ignora a revisão e deixa um comentário informando que aquele diff já foi revisado.
Disponível no Cursor 3.7+ e em cursor.com/agents, com suporte na CLI em breve.
Agora você pode configurar o Bugbot para revisar apenas o que há de novo desde a última revisão, mantendo o feedback focado nas suas atualizações mais recentes.
Clique em dois ou mais elementos no Browser ao mesmo tempo. O Cursor vê os elementos selecionados, o código deles, o layout ao redor e as relações visuais na página.
Peça ao agente para fazer com que um corresponda ao outro, remover conteúdo repetido ou ajustar um grupo de componentes de uma só vez.
Descreva as alterações pela sobreposição do Design Mode. O microfone continua disponível enquanto um agente está em execução, para que você possa enfileirar a próxima alteração por voz sem esperar a anterior terminar.
Entregamos um conjunto de novas funcionalidades nos SDKs de TypeScript e Python. Agora você pode escolher como os metadados do agente e da execução são persistidos, expor suas próprias funções ao agente como ferramentas, encaminhar chamadas de ferramentas locais por meio do Auto-review e aninhar subagentes em qualquer profundidade. Esta versão também traz um conjunto de correções de confiabilidade, performance e plataforma que facilitam a execução de agentes de SDK locais e na nuvem em scripts de produção, CI e integrações personalizadas.
Agora você pode passar suas próprias ferramentas para o agente local fornecendo definições de função por meio de local.customTools, em Agent.create() ou em cada send(). O SDK as expõe ao agente por meio de um servidor MCP integrado chamado custom-user-tools, para que o modelo chame seu código pelo mesmo caminho e com o mesmo controle de permissões que qualquer outra ferramenta MCP.
Antes, expor uma capacidade personalizada significava configurar seu próprio servidor MCP stdio ou HTTP remoto e conectá-lo ao agente. Agora, uma definição de função é suficiente. As ferramentas personalizadas também ficam visíveis para todos os subagentes de um agente pai, então uma ferramenta definida uma vez fica disponível ao longo de toda a execução.
Por padrão, um agente local do SDK executa chamadas de ferramenta sem pedir aprovação, já que não há nenhum humano no processo em uma execução headless. Defina local.autoReview para encaminhar essas chamadas para o Auto-review. Um classificador decide quais chamadas são executadas automaticamente e quais devem ser mantidas em espera, em vez de ignorar a revisão por completo.
Você orienta esse classificador com instruções em linguagem natural em permissions.json. O campo autoRun.allow_instructions descreve padrões de chamadas que devem tender a ser permitidos, e autoRun.block_instructions descreve aqueles que devem ser mantidos para revisão. Por exemplo, você pode permitir inspeções somente leitura de artefatos de build, sempre pausando em operações destrutivas, como exclusões.
{ "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 os SDKs persistem os metadados de agentes e execuções para que você possa retomar um agente após reiniciar um processo. Até agora, esse armazenamento era feito em SQLite. Agora, você também pode optar por um armazenamento em JSONL, que grava um arquivo simples, append-only, que você pode ler, comparar com diff e versionar. Tanto SqliteLocalAgentStore quanto JsonlLocalAgentStore são exportados diretamente.
Se nenhuma das opções padrão se adequar à sua configuração, implemente a interface pública LocalAgentStore e passe-a por local.store. Crie um armazenamento em memória para execuções efêmeras de CI ou use o Postgres como backend de persistência quando quiser que o estado do agente fique junto com o restante dos dados da sua aplicação. O SDK de Python expõe armazenamentos de host, JSONL e JSONL composto por meio da bridge.
Os subagentes agora podem criar seus próprios subagentes, e assim por diante. Um subagente revisor pode delegar para um subagente que escreve testes, que pode delegar ainda mais, com cada nível mantendo seu próprio prompt e modelo. Não há nada para ativar; uma sessão de subagente registra o executor necessário para chamar Task, então o aninhamento funciona automaticamente para qualquer agente que defina subagentes.
#Melhorias de confiabilidade, performance e plataforma
Esta versão também inclui uma série de correções que melhoram a experiência em ambos os SDKs.
Correlação de execuções: Todo send() agora inclui um requestId gerado pela plataforma, exposto em Run e RunResult e persistido nos armazenamentos em memória, SQLite e JSONL. Vincule um script ou uma execução de CI a logs de backend, análises e threads de suporte sem precisar inferi-lo a partir de agentId.
wait() confiável em execuções locais: Execuções locais não resolvem mais wait() antes que o resultado do terminal seja gravado. A hidratação continua sendo atualizada até que a execução chegue a um estado final, para que a automação leia um resultado completo.
Checkpoints seguros ao descartar: Descartar um agente local não remove mais dados de checkpoint quando falta uma referência raiz, mas ainda existem blobs de checkpoint. O diretório do agente só é limpo quando realmente não há mais nada a preservar.
Streaming na nuvem por HTTP/1.1: Sessões de agente na nuvem agora fazem streaming corretamente em transportes HTTP/1.1 usados por alguns proxies, implementações fetch mais antigas do Node e certas imagens de CI. O comportamento em HTTP/2 permanece inalterado.
Importação mais leve: Importar @cursor/sdk não carrega mais antecipadamente toda a stack de agente local. Consumidores que usam apenas a nuvem ou apenas tipos evitam o custo do tempo de execução local até a primeira chamada local, sem nenhuma mudança na API. A primeira chamada local paga o custo de uma importação única e depois permanece em cache.
Tipos TypeScript autocontidos: Os arquivos .d.ts publicados não fazem mais referência a pacotes de espaço de trabalho não publicados. Isso corrige erros TS2305 e TS2307 com skipLibCheck: false e o any silencioso em tipos de stream como TurnEndedUpdate.
ripgrep empacotado: Execuções locais de shell usam o binário rg empacotado da plataforma sem modificar o seu PATH global. No Windows, adicionar o ripgrep no início não sobrescreve mais a variável Path.
Composer 2 direciona para Composer 2.5: Clientes SDK que ainda fixam slugs composer-2 descontinuados são direcionados automaticamente para o Composer 2.5, preservando as variantes rápidas, para que scripts mais antigos continuem funcionando.
list_runs com escopo de espaço de trabalho: Client, AsyncClient e Agent.list_runs aceitam um cwd opcional, e a bridge usa como fallback o espaço de trabalho em que foi iniciada. Isso corrige resultados espúrios de "agente não encontrado" quando a bridge é executada como subprocesso.
Erros de não encontrado mais claros: Buscar um agente que não está no espaço de trabalho resolvido retorna um erro claro de não encontrado, em vez de um erro interno opaco.
Versão 0.1.6 e análises: cursor-sdk 0.1.6 documenta o caminho de release do Buildkite e rotula o uso do SDK como sdk-python- para análises mais claras.
Execute npm install @cursor/sdk ou pip install cursor-sdk para atualizar. Scripts que fixam composer-2 passam automaticamente para o Composer 2.5, e requestId é uma adição segura ao esquema de metadados da sua execução. Consulte a documentação do TypeScript e do Python para ver todos os detalhes.
