Execute agentes na nuvem em máquinas que você gerencia
Os agentes na nuvem do Cursor podem ser executados em pools de máquinas agendados dinamicamente dentro da sua rede. Você gerencia a infraestrutura subjacente, enquanto os agentes continuam sendo iniciados e gerenciados pelo Cursor.
Isso dá às equipes mais controle sobre onde os agentes são executados e qual infraestrutura eles usam. Os agentes podem trabalhar ao lado de serviços internos e do controle de versão, rodar em hardware personalizado ou usar sistemas operacionais e pipelines de build difíceis de empacotar como um build de Agente na nuvem.
Hoje, os agentes na nuvem criam mais de 60% das PRs que fazemos merge internamente e vêm assumindo uma parcela cada vez maior do trabalho de software em muitas das maiores empresas com as quais trabalhamos. À medida que esse papel cresce, as máquinas em que eles são executados também ganham importância. Essas novas capacidades tornam viável para as equipes fornecer e gerenciar essa infraestrutura em escala.
Com as MicroVMs do Lambda como camada de computação para os Agentes na nuvem do Cursor, os desenvolvedores podem executar agentes de programação com IA na própria conta AWS. Cada máquina é iniciada quase instantaneamente a partir de um snapshot, é suspensa quando ociosa e retomada com o estado completo. Seus agentes de programação se beneficiam da inicialização rápida do Lambda, do forte isolamento e da ausência de gerenciamento de frota, enquanto o Cursor orquestra o trabalho.
Controle onde os agentes são executados
Os ambientes hospedados pela Cursor continuam sendo o padrão para agentes na nuvem. Cada sessão roda em uma VM dedicada dentro da nuvem da Cursor, com suas dependências instaladas e seus próprios controles de rede. O isolamento por agente, a supressão de secrets, os controles de egress e os commits assinados atendem aos requisitos de segurança da maioria das equipes.
Em geral, as equipes usam Máquinas Auto-hospedadas quando:
- A execução de ferramentas do agente precisa acontecer dentro da rede da empresa, com acesso direto ao controle de versão, aos serviços internos e aos repositórios de código.
- Os agentes exigem hardware personalizado, como GPUs ou Macs para desenvolvimento iOS, ou infraestrutura como Kubernetes, sandboxes ou VMs gerenciadas.
- O sistema operacional ou o pipeline de build é difícil de empacotar como um build de Agente na nuvem.
Com as Máquinas Auto-hospedadas, apenas o ambiente de execução muda de lugar: o agente loop, a inferência e o planejamento permanecem na nuvem da Cursor. As saídas das ferramentas voltam para a Cursor para inferência e podem conter código, e as transcrições de agente podem ser processadas e armazenadas pela Cursor. As equipes seguem podendo acessar os agentes na nuvem pelo app de desktop, pelo cursor.com, por dispositivos móveis, Slack, GitHub e Linear.
Os workers conectam sua infraestrutura ao agente loop do Cursor
Com as Máquinas Auto-hospedadas, a execução de ferramentas deixa de ocorrer em uma VM hospedada pelo Cursor e passa para uma máquina no seu ambiente. Essa máquina mantém a cópia de trabalho do repositório, edita arquivos e executa comandos. Um worker a conecta ao restante do sistema de agentes.
Para registrar uma máquina, execute um worker instalando a CLI do Cursor e rodando agent worker start. Isso abre uma conexão HTTPS de saída de longa duração com a nuvem do Cursor. Quando uma sessão começa, o agente harness do Cursor cuida da inferência e do planejamento e, em seguida, envia as tool calls para um worker dedicado executá-las. O worker devolve os resultados para a próxima rodada de inferência. O Cursor nunca inicia uma conexão para dentro da sua rede.
Os workers podem ser configurados de duas maneiras.
- Minhas Máquinas. Essa configuração conecta um único notebook ou VM à sua conta e é mais indicada para fluxos de trabalho pessoais.
- Pools. Um pool é uma fila nomeada de workers que pode atender uma equipe ou uma empresa. A capacidade aumenta conforme as requisições chegam e diminui depois que os workers se desconectam, permitindo que sua infraestrutura de nuvem existente escale de acordo com a demanda dos desenvolvedores.
Os desenvolvedores devem ter a flexibilidade de executar agentes de programação na plataforma que melhor atende ao seu fluxo de trabalho, e as empresas não deveriam precisar abrir mão do controle sobre onde os agentes são executados e o que eles podem acessar. O futuro do desenvolvimento será construído sobre agentes poderosos, executados em ambientes seguros e isolados.
Agentes na nuvem se adaptam à sua infraestrutura
Os worker pools agora podem escalar conforme as requisições na fila e executar trabalhos de qualquer repositório. Também adicionamos suporte a diversos provedores de sandbox e ao uso do computador no Linux, além do Mac.
Os pools escalam conforme a demanda e atendem qualquer repositório
A demanda por agentes na nuvem costuma chegar em picos, e os pools de máquinas auto-hospedadas se ajustam a esses picos automaticamente. Isso acontece por meio de um controlador que monitora a fila de requisições e usa um script de spawn fornecido pela equipe para iniciar máquinas conforme necessário.
Se o pool tiver um worker disponível, esse worker assume a requisição. Caso contrário, a requisição aguarda até que haja mais capacidade disponível, de modo que as equipes não precisam decidir quantas máquinas deixar em execução.
As equipes podem definir um tempo limite de ociosidade para cada conexão de worker. Quando ele expira, a máquina pode ser reiniciada e voltar ao pool. As equipes também podem preservar o espaço de trabalho, caso o agente receba uma continuação.
As máquinas auto-hospedadas dão às equipes o controle de onde os agentes do Cursor são executados, e o Vercel Sandbox torna isso simples. Cada tarefa recebe um sandbox isolado sob demanda, sem frota para gerenciar e nada parado ocioso.
Manter uma máquina em execução enquanto o agente está ocioso pode sair caro. Mas, se a máquina for liberada, o agente pode levar vários minutos para reconstruir seu espaço de trabalho quando chegar uma continuação. Com a hibernação, as equipes podem, em vez disso, criar um snapshot e parar a máquina ociosa. Se uma continuação chegar dentro da janela de reconexão, o snapshot é restaurado e um worker inicia com o mesmo ID. Caso contrário, a requisição pode ser transferida para uma nova máquina.
Os pools não estão vinculados a repositórios específicos. Uma requisição só precisa identificar o pool, e qualquer worker disponível pode assumi-la. Assim, um único pool consegue atender muitos repositórios.
Os workers são executados nos provedores de sandbox compatíveis
As Máquinas Auto-Hospedadas não exigem construir uma camada de sandbox personalizada do zero. Somos parceiros de AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace e Vercel, permitindo iniciar e orquestrar workers onde quer que os sandboxes da equipe já estejam em execução.
As Máquinas Auto-Hospedadas do Cursor no Modal dão a cada sessão de Agente na nuvem um Modal Sandbox, para que você possa entregar a ela uma máquina sob medida para sua tarefa.
Agentes controlam browsers no Linux e no Mac
Os workers Linux agora oferecem suporte a uso do computador, assim como os Macs. Com as dependências necessárias de uso do computador instaladas, incluindo Chrome ou Chromium, um agente pode clicar, tirar screenshots e controlar o browser. Você pode acompanhar o desktop dele ou assumir o controle diretamente do Cursor.
Não dá para construir apps para iOS ou macOS sem um Mac. Os Devboxes da Namespace sobem um Mac real para cada Agente na nuvem do Cursor, que agora pode realizar esse trabalho em Apple silicon.
Traga os agentes na nuvem para o seu ambiente
As equipes passaram anos moldando sua infraestrutura de acordo com a forma como criam software. As Máquinas Auto-hospedadas permitem que os agentes na nuvem se encaixem nela com mais naturalidade, e estamos animados para ver até onde as equipes vão levá-los.
Para conectar uma máquina ou configurar um pool, comece pela documentação.
