Recursos
Uso do computador
Cada agente em nuvem é executado em sua própria VM isolada com um ambiente de desktop completo. Os agentes podem usar mouse e teclado para controlar o desktop e o navegador, permitindo que interajam com o software que desenvolvem como um desenvolvedor humano.
Isso significa que os agentes podem iniciar servidores de desenvolvimento, abrir o app em um navegador, percorrer fluxos de UI e verificar se suas alterações funcionam antes de abrir um PR. Leia mais no post de anúncio no blog.
Em Máquinas Self-Hosted, inicie o worker com --computer-use para permitir que o agente controle o desktop dessa máquina. Workers macOS usam o helper app Cherri Code Computer Use; workers Linux usam um display X11. Veja Uso do computador e compartilhamento de desktop.
Demonstrações e Artefatos
Agentes criam artefatos, como capturas de tela, vídeos e referências de log para demonstrar seu trabalho. Esses artefatos são anexados ao PR para que você possa validar rapidamente as alterações sem fazer checkout do branch localmente.
Artefatos no GitHub
Você pode ativar a opção para que os agentes na nuvem incorporem artefatos diretamente nas descrições de pull requests do GitHub, habilitando a configuração Permitir publicar artefatos no GitHub no dashboard do agente na nuvem.
O proxy de imagens do GitHub exige URLs públicas, então os artefatos em descrições de PR usam URLs longas e difíceis de adivinhar, que podem ser acessadas sem autenticação. Para contextualizar, o GitHub usou URLs públicas para todos os anexos de issues e PRs até maio de 2023.
Controle da área de trabalho remota
Você pode assumir o controle da área de trabalho remota do agente para interagir com o software que ele está desenvolvendo. Devolva o controle ao agente a qualquer momento para que ele continue trabalhando.
Agentes na nuvem são executados em uma VM remota que pode ser totalmente configurada com seu repositório, dependências, ferramentas e scripts de configuração. Isso permite testar alterações diretamente na VM do agente sem precisar fazer checkout da branch na sua máquina local.
Ferramentas MCP
agentes na nuvem podem usar servidores MCP (Model Context Protocol) configurados para sua equipe. Isso dá aos agentes acesso a ferramentas externas e fontes de dados, como bancos de dados, APIs e serviços de terceiros, durante a execução.
Adicione e ative servidores MCP pessoais pelo menu suspenso MCP em cursor.com/agents. Admins da equipe configuram servidores compartilhados em Dashboard -> Plugins & MCPs.
Admins podem vincular servidores MCP de equipe compartilhados ao marketplace padrão da equipe. Vincular mantém os servidores disponíveis para agentes na nuvem e também os disponibiliza para que membros da equipe os instalem e configurem na Janela do Agente, na IDE e na CLI.
agentes na nuvem oferecem suporte a OAuth para servidores MCP que precisam dele. O OAuth é por usuário, inclusive para servidores MCP compartilhados no nível da equipe.
Servidores MCP personalizados
Você pode adicionar servidores MCP personalizados usando HTTP ou stdio como transporte. SSE e mcp-remote não são suportados.
As configurações MCP são criptografadas em repouso. Campos sensíveis são mascarados e não podem ser lidos por nenhum usuário após serem salvos:
env— variáveis de ambiente para servidores stdioheaders— cabeçalhos de requisição para servidores HTTPCLIENT_SECRET— segredo de cliente OAuth para servidores HTTP
HTTP vs stdio
- HTTP (recomendado) — as configurações do servidor nunca ficam presentes no ambiente de VM do agente em nuvem. O agente não tem acesso a refresh tokens, cabeçalho de requisição ou outras credenciais. As chamadas de ferramenta são roteadas por proxy pelo backend.
- Stdio — os servidores são executados dentro da VM do agente em nuvem, então o agente tem acesso à configuração do servidor e às variáveis de ambiente. Isso é semelhante ao modo como MCPs stdio funcionam no Cherri Code IDE.
Servidores stdio dependem do ambiente da VM para serem executados. Não podemos verificar se um servidor stdio será executado com sucesso até que um agente em nuvem seja iniciado. Recomendamos usar MCPs HTTP sempre que possível e configurar corretamente sua configuração de ambiente se você usar servidores stdio.
Cherri Code Cloud MCP
O Cherri Code Cloud MCP é um servidor de diagnósticos integrado disponível durante execuções do agente em nuvem. Um agente pode inspecionar a execução atual, consultar execuções relacionadas no mesmo ambiente e consultar transcrições, metadados de diff, detalhes do ambiente, eventos da execução e logs de configuração sem precisar coletar links e arquivos manualmente.
Admins da equipe podem desativar o Cherri Code Cloud MCP para a equipe em Configuração do MCP nas configurações da equipe. Veja dashboard da equipe para mais informações sobre os controles de administração do MCP.
Acesso e permissões
As conversas do agente em nuvem podem incluir prompts, código, saída de ferramentas e segredos. Todas as ferramentas aplicam verificações de acesso a cada solicitação.
| Função | O que você pode acessar |
|---|---|
| Admin da equipe | Listar e consultar detalhes (incluindo transcrições) de execuções do agente em nuvem em toda a equipe, para repositórios e ambientes aos quais já têm acesso |
| Não administrador | Apenas suas próprias execuções e transcrições. Você não pode ver os chats de outros membros da equipe por meio deste MCP |
Mesmo ao listar execuções em um ambiente compartilhado, não administradores só veem agentes que iniciaram ou possuem. As contas de serviço seguem as mesmas regras do usuário ou do contexto da equipe em que são executadas.
O que você pode inspecionar
| Categoria | Exemplos |
|---|---|
| Execução atual | Run ID, URL, repositório, branch, modelo, responsável, status no ciclo de vida e onde a execução foi iniciada (Cherri Code, Slack, GitHub, API e outros) |
| Eventos | Resultados da configuração, do pull request, do artefato e da autenticação do MCP exibidos no dashboard da execução. Use get-events para a execução atual ou batch-fetch-details com include_events para outras execuções. Consulte os tipos de evento em Ferramentas. |
| Execuções relacionadas | Outros agentes em nuvem no mesmo ambiente ou no mesmo repositório quando não houver ambiente salvo associado |
| Ambiente | Versão do ambiente, configuração completa do ambiente, URL do dashboard e política efetiva de rede egress |
| Transcrição | Conversa completa entre usuário e agente, incluindo chamadas de ferramenta quando disponíveis |
| Metadados do diff | Se o agente alterou código, quanto mudou e se abriu um PR |
| Logs de configuração | Logs brutos da configuração do ambiente e das etapas de build da imagem |
Ferramentas
Dependendo do seu cliente MCP, os nomes das ferramentas podem incluir um prefixo de servidor (por exemplo, cursor-cloud-run-info). As ferramentas disponíveis são:
| Ferramenta | Finalidade |
|---|---|
run-info | Obtém a identidade, os metadados e a URL da execução atual. Comece por aqui. |
environment-info | Obtém a versão do ambiente, a configuração, a URL do dashboard e a política efetiva de egress da execução atual. |
get-events | Lista os eventos do dashboard da execução atual, do mais antigo ao mais recente. |
list-cloud-agents | Consulte as execuções de agente em nuvem visíveis para você neste ambiente. Filtre por origem, status, data, alterações de código, criação de PR e status de arquivamento. |
batch-fetch-details | Consulta detalhes de IDs de execução específicos (bcIds). Opcionalmente, inclui transcrições, metadados de diff, logs de configuração, informações do ambiente e eventos da execução por meio de include_events (grava events.json por execução; até 50 execuções por lote). |
get-automation | Obtém os detalhes de uma automação a partir do seu ID, como nome e proprietário. |
list-environment-builds | Lista as Builds recentes do ambiente atual e verifica seu status. |
environment-build-logs | Baixa os logs de instalação e configuração de uma Build. |
trigger-environment-build | Executa uma Build de teste com a configuração atual ou comandos propostos de instalação e inicialização. |
propose-environment-json | Apresenta comandos de instalação e inicialização para sua revisão antes de salvar o ambiente. |
take-environment-snapshot | Cria um snapshot de uma máquina após o agente verificar a configuração do ambiente. |
check-environment-snapshot | Verifica se um snapshot do ambiente está pronto. |
request-environment-setup-actions | Solicita ações do usuário que bloqueiam a configuração do ambiente, como adicionar um segredo. |
Os valores de kind de evento do dashboard de get-events e de batch-fetch-details com include_events são:
kind | Significado |
|---|---|
setup_started | A configuração do ambiente foi iniciada. |
setup_completed | A configuração do ambiente foi concluída. |
setup_failed | A configuração do ambiente falhou. |
pr_created | Pull request aberto. |
pr_creation_failed | A criação do pull request falhou. |
artifact_created | Artefato do tutorial carregado. |
mcp_auth_error | A autenticação do servidor MCP falhou; suas ferramentas foram ignoradas, e a execução continuou. |
Um fluxo de diagnóstico típico é run-info → get-events → environment-info → list-cloud-agents → batch-fetch-details (defina include_events quando precisar dos eventos do dashboard de outras execuções).
Assinaturas
As tarefas dos agentes raramente terminam com o último commit. A CI precisa passar. Revisores deixam comentários. Um colega precisa responder a uma pergunta no Slack. As assinaturas permitem que um agente em nuvem aguarde esses eventos e continue trabalhando quando eles acontecerem, sem que você precise enviar outro prompt.
O agente se inscreve em uma fonte de eventos, encerra seu turno e é reativado quando chega um evento correspondente. Os eventos chegam como mensagens de acompanhamento na mesma conversa, para que o agente continue com todo o contexto:
- Abrir uma PR e responder a comentários de revisão e falhas de CI
- Fazer uma pergunta no Slack e continuar quando alguém responder
- Acompanhar um trabalho de longa duração com um temporizador
Para se inscrever, descreva a espera no prompt. Por exemplo, "abra uma PR e mantenha a CI sem falhas" ou "pergunte em #releases e aguarde aprovação". Você também pode invocar a skill integrada /subscribe, que funciona da mesma forma: diga o que monitorar, e o agente escolherá a assinatura certa.
Os agentes podem se inscrever em eventos destas integrações:
| Integração | Eventos |
|---|---|
| GitHub | Atividades de pull request (comentários, revisões e alterações no ciclo de vida) de uma PR, além de resultados de CI em uma branch. Usa a integração com o GitHub. |
| Slack | Respostas em uma thread e mensagens em um canal. Usa a integração com o Slack. |
| Linear | Issues criadas ou que mudam de estado e novos comentários em issues. Usa a integração com o Linear. |
| Temporizadores | Um momento específico: um lembrete único após um atraso ou uma programação cron recorrente. Loops recorrentes também estão disponíveis como a skill integrada /loop. |
Como as assinaturas funcionam
- As assinaturas pertencem a uma única conversa de agente. Os eventos despertam esse agente por meio de mensagens de acompanhamento.
- Eventos em sequência são agrupados. Vários eventos que chegam próximos uns dos outros podem despertar o agente uma única vez, e ele relê a fonte (a PR, a thread ou a issue) antes de agir.
- Uma assinatura dura no máximo 180 dias. Os agentes também cancelam suas assinaturas quando a espera termina.
Assinaturas de CI do GitHub
Uma assinatura de CI aguarda até que todas as verificações do commit sejam concluídas e então entrega um único resultado para o commit inteiro: sucesso, ou falha com os nomes das verificações que falharam.
Algumas verificações ficam pendentes por muito tempo, por exemplo enquanto alguém as aprova. Uma única verificação pendente segura o resultado inteiro, e o agente continua aguardando.
Finalize essas verificações com a conclusão action_required do GitHub em vez de deixá-las pendentes. A verificação é concluída, continua exigindo ação e continua bloqueando o merge quando é uma verificação obrigatória, de modo que a assinatura de CI é entregue enquanto o merge permanece protegido.
Corrigindo falhas de CI
Os agentes na nuvem tentam corrigir automaticamente falhas de CI nos PRs que criam. No momento, isso é compatível apenas com GitHub Actions.
Os agentes na nuvem pulam mensagens de acompanhamento automáticas de CI se:
- Você enviou um novo commit para a branch; agentes na nuvem não corrigem automaticamente falhas de CI em commits feitos por humanos.
- Você enviou uma mensagem de acompanhamento ao agente.
- A mesma verificação já está falhando no commit base do PR.
- O PR já teve 10 mensagens de acompanhamento de falha de CI.
Para desativar esse recurso em todos os seus agentes na nuvem pessoais, acesse Cherri Code Dashboard → Cloud Agents → My Settings e desative a opção "Automatically fix CI Failures".
Para desativar esse recurso em um PR específico de um agente na nuvem, você pode comentar @cursor autofix off no PR. Para reativá-lo, comente @cursor autofix on.
Se você quiser que os agentes na nuvem corrijam falhas de CI nos seus próprios PRs, basta pedir, marcando o Cherri Code em um comentário como de costume. Por exemplo, @cursor please fix the CI failures ou @cursor fix the CI lint check failure.
A correção automática de falhas de CI está disponível atualmente apenas em Teams; o suporte para contas fora de Teams chegará em breve. Enquanto isso, se você quiser um comportamento semelhante, pode pedir explicitamente ao agente na nuvem para monitorar e corrigir falhas de CI no PR.
Tokens de identidade OIDC
As VMs do agente em nuvem gerenciadas pelo Cherri Code podem emitir JWTs OIDC de curta duração a partir de um socket local. Os agentes os usam para assumir funções na nuvem ou chamar APIs internas sem armazenar chaves de longa duração. Consulte tokens OIDC.
Metadados do agente
O mesmo socket também disponibiliza os metadados do agente. Agentes, hooks e scripts podem ler o ID do agente, o proprietário, o turno atual e o espaço de trabalho como texto simples.