Amp leva o Portals para máquinas locais: o servidor de desenvolvimento aparece direto na thread

Situação familiar: o agente escreveu um frontend, subiu um servidor de desenvolvimento, e agora você mesmo precisa abrir o terminal, procurar a porta e conferir o que saiu. Se o agente trabalha em outra máquina, por exemplo no Mac de casa enquanto você está com o notebook em um café, a tarefa vira uma pequena missão. A equipe do Amp, da Sourcegraph, fecha essa lacuna: o Portals, que antes existia apenas em orbs na nuvem, agora funciona também no seu próprio runner.

O que mudou

Portal é uma aba ao lado da thread em que se abre uma página web criada pelo agente. Antes, ela estava disponível quando o agente trabalhava em um orb. Agora o mesmo mecanismo funciona em máquinas locais: você pede ao Amp para subir um servidor de desenvolvimento ou montar um site, e abre o resultado na aba Portal da thread. Um detalhe importante do anúncio é «onde quer que você esteja». Ou seja, o runner pode ficar em uma máquina enquanto você vê o resultado em outra.

Exemplo do anúncio

Os desenvolvedores do Amp mostraram um caso simples, mas revelador. Em uma thread em um runner macOS, o usuário pede uma página de visão geral sobre o uso do sistema de arquivos do Mac e que ela seja exibida em um portal. O agente responde com um link para o portal Disk Usage, e ao lado abre-se um pequeno aplicativo web: 241 GB ocupados de 383 GB, uma barra de capacidade dividida por categorias e um gráfico de rosca mostrando que simuladores e dados do Xcode ocupam 155 GB.

O valor não está no gráfico em si, mas no ciclo: pergunta, código, página ao vivo, e você olha o resultado de imediato e refina a tarefa. Painéis internos descartáveis que antes ninguém faria à mão passam a ser quase de graça. Precisa entender o que consumiu o disco, ver métricas de build ou conferir o layout? Peça ao agente e receba uma página, não um paredão de texto no chat.

Como ativar e quem vai ver

Há duas formas. No aplicativo macOS, abra Settings › Runner e ative Allow Portals. Se você trabalha pelo terminal, inicie o runner com o comando amp --no-tui --remote-control-portals.

Por padrão, os portais do seu runner ficam disponíveis apenas para você. Para mostrá-los aos colegas, inicie um runner compartilhado (shared runner) com a flag --share ou ative Share With Workspace no aplicativo macOS. Assim, qualquer membro do workspace poderá abrir os portais desse runner. Mais detalhes estão na documentação do Amp, na seção Portals on Your Runner.

Limitações e conclusão prática

Há alguns pontos a ter em mente. A opção vem desativada por padrão, e isso é correto: você decide se dá ao agente a possibilidade de expor páginas web a partir da sua máquina. Ao ativar o compartilhamento para todo o workspace, lembre-se de que os colegas verão tudo o que o agente exibir no portal.

E em uma máquina local pode parar na página qualquer coisa: caminhos, nomes de projetos, dados do sistema de arquivos. O relatório de disco do exemplo é inofensivo em um Mac pessoal, mas não deve ser mostrado a todo um workspace sem verificação. O anúncio não traz detalhes sobre como funciona o acesso nem quais são as limitações técnicas dos portais, então consulte a documentação para as nuances.

A conclusão prática é simples. Se você já usa o Amp com um runner local, ative Allow Portals e teste em uma tarefa em que antes precisava subir o servidor manualmente: preview de frontend, relatório de dependências, dashboard de logs. Se trabalha em equipe, comece pelo modo pessoal e ative --share apenas em runners que não tenham nada sensível.

E se você mesmo cria agentes, anote a ideia. A capacidade de mostrar o resultado como uma página ao vivo, e não como texto no chat, é uma função à parte e muito subestimada. Ela encurta o caminho entre o pedido e a verificação do resultado com os próprios olhos, e é justamente nessa etapa que o tempo costuma ser perdido.