Um agente de programação só está disponível na medida da máquina em que ele roda. Inicie um refactor longo com o Claude Code ou o Codex, feche a tampa para pegar o trem e a execução morre junto com a sua sessão SSH. Dispare dois agentes no mesmo notebook e as ventoinhas vão girar enquanto seu editor engasga. Em algum momento, a pergunta deixa de ser “qual agente” e passa a ser “onde o agente realmente roda”.
A resposta costuma ser uma entre três: manter no notebook, mover para um servidor remoto ou dividir o trabalho entre os dois. Cada escolha troca conveniência por confiabilidade. O notebook está bem ali, mas hiberna, limita o desempenho e desconecta. Um servidor fica acordado e tem mais núcleos, mas adiciona configuração e uma camada de “o que ele está fazendo agora, afinal?”. Ficar no meio do caminho te dá o melhor dos dois mundos e também a burocracia dos dois.
Este artigo percorre a configuração de agente remoto de ponta a ponta: o caminho faça-você-mesmo com comandos reais, o modo de falha à espreita em cada etapa e onde um Computer conectado no Sharkly elimina a parte que vive quebrando. Você já tem agentes de programação. O problema é rodá-los em algum lugar durável e saber o que aconteceu quando você desvia o olhar.
Por que tirar um agente do seu notebook
O notebook é o padrão porque é onde você digita. Também é o pior host para qualquer coisa que dure mais que a sua capacidade de atenção. O macOS hiberna ao fechar a tampa. O modo bateria limita a CPU. VPNs corporativas caem. Cada um desses eventos mata um agente no meio da tarefa, e o agente não faz ideia de que foi interrompido; você descobre quando reabre o terminal e encontra um prompt morto e nenhum resumo.
Um host remoto corrige a física. Uma VM na nuvem ou uma máquina Linux sobrando fica ligada, mantém a rede e tem núcleos de sobra para trabalho paralelo. O custo é que o agente agora roda em algum lugar que você não vê. Você entra por SSH para ver como está, rola um log para adivinhar até onde ele chegou, e os resultados ficam naquela máquina até você copiá-los para fora.
Rodar os dois é o estado final mais honesto para a maioria das pessoas. Você mantém edições rápidas e interativas no notebook, onde o feedback é instantâneo, e empurra tarefas longas ou paralelas para o servidor, onde podem rodar por uma hora sem supervisão. O truque é fazer um ou cinco hosts parecerem um só lugar, em vez de uma planilha de endereços IP.
A configuração remota faça-você-mesmo e onde cada etapa quebra
O caminho manual é bem conhecido. Aqui está a versão resumida, com o modo de falha que aparece em cada etapa.
Provisione o host e coloque seu agente nele:
ssh you@build-server
# install the agent's CLI, e.g. Claude Code or Codex
# authenticate it with your own subscription or API key
git clone [email protected]:your-org/your-repo.git
cd your-repo
claude
Modo de falha: o agente se autentica com sua conta em uma máquina que outras pessoas podem acessar, e as credenciais ficam no histórico e na configuração daquele shell. Não há registro de qual host guarda quais chaves.
Mantenha a execução viva além da sua sessão SSH:
tmux new -s agent
claude # start the long task
# Ctrl-b d to detach, close the laptop, reconnect later
tmux attach -t agent
Modo de falha: o tmux sobrevive a uma conexão SSH derrubada, mas não a um reinício do servidor, a um kill por OOM ou a você esquecer qual de seis sessões, em qual de três servidores, contém a execução que te interessa. Desanexar não é a mesma coisa que durar.
Recupere os resultados e veja o que aconteceu:
scp you@build-server:~/your-repo/CHANGES.md .
ssh you@build-server 'cd your-repo && git diff'
Modo de falha: o diff está na máquina; o raciocínio está em um buffer de histórico que já foi truncado; o “porquê” se foi. Multiplique isso por dois agentes em dois hosts e você vai reconstruir o estado na mão toda vez que for verificar.
Nenhuma dessas etapas é difícil. O problema é que elas não se compõem. Cada novo host e cada novo agente é outro alvo SSH, outra sessão tmux, outro lugar onde vive um segredo e outro log que você precisa ler para responder “acabou?”.
O que um Computer conectado muda
O Sharkly dá nome àquilo que você vem improvisando. Um Computer é um dispositivo, servidor ou contêiner conectado onde um Agent pode executar trabalho; ele fornece o sistema operacional, os arquivos, as credenciais, o acesso à rede e as ferramentas de que o Agent precisa. Essa definição cobre as suas três opções: “Pode ser um computador local, um servidor remoto, um contêiner ou um host de nuvem compatível.”
Você registra um host uma vez, em vez de entrar por SSH nele toda vez. Gere um token de instalação de uso único em Configurações, Computers, na máquina de destino, e execute:
sharkly computer register --install-token <install-token>
O token tem vida curta e é de uso único, então não deve ficar em uma imagem ou em um script. Depois disso, um serviço local em segundo plano roda no Computer. Ele registra o host, detecta quais ferramentas de agente estão instaladas e reporta cada uma como um Runtime, envia heartbeats, recebe execuções na fila, prepara diretórios e reporta o progresso e os resultados de volta.
Vale deixar dois limites bem claros, porque é aí que as pessoas erram na suposição. Primeiro, o serviço local inicia a conexão com o servidor, então uma configuração típica não exige porta de entrada; você não está abrindo sua máquina de build para a internet. Segundo, um Computer aparecendo como Online significa apenas que o serviço local dele está enviando heartbeats. Não significa que o Runtime consegue executar uma Task. Se uma execução não inicia em um host online, verifique o status de capacidade do Runtime antes de mexer na rede.
A partir daqui, os modos de falha anteriores têm endereço. As credenciais são do host, com escopo nele. Uma execução sobrevive ao seu terminal porque quem a detém é o serviço local, não uma sessão tmux. E o diff, o resumo e o raciocínio voltam para a Task, em vez de ficarem em um buffer de histórico numa máquina em que você precisa entrar por SSH.
Notebook, servidor ou ambos: como escolher de verdade
Mais hosts não é automaticamente melhor, então escolha de acordo com o trabalho.
Use o notebook quando a tarefa for curta, interativa e você quiser acompanhá-la. Registre-o como um Computer pessoal e, no Sharkly Desktop, ative o Prevent sleep para que um trabalho rápido não seja interrompido pela suspensão do sistema. Vale notar que o Prevent sleep aparece apenas na máquina local no app de desktop; ele não está disponível em um Computer compartilhado ou remoto. Se tudo o que você roda termina dentro de uma pausa para o café e nunca precisa sobreviver à tampa fechada, você ainda não precisa de um servidor, e adicionar um é só manutenção que vai te irritar.
Use um servidor remoto quando as tarefas durarem muito, precisarem de mais núcleos ou não deverem disputar recursos com o seu editor. Um host Linux registrado ou uma VM na nuvem fica acordado por padrão e dá espaço para agentes paralelos trabalharem. É também aqui que o limite de concorrência de tarefas por host de um Computer e a visibilidade de Organization ou Space se justificam: a máquina e suas credenciais existem para serem compartilhadas, e o Sharkly as trata assim.
Use os dois quando quiser edições interativas locais e execuções pesadas remotas sem manter dois modelos mentais. Registre o notebook e o servidor, e então atribua cada Task ao Computer e ao Runtime que fizerem sentido. O isolamento por worktree que evita que agentes paralelos colidam funciona igual, estejam os agentes em um host ou espalhados por vários, então “os dois” custa uma seleção, não um segundo fluxo de trabalho.
Onde o faça-você-mesmo para de escalar, e o que um quadro de tarefas acrescenta
A configuração de SSH e tmux dá conta de um agente em um host. Ela para de funcionar no momento em que você tem vários agentes em várias máquinas, porque não há uma resposta compartilhada para “qual agente está em quê, o que terminou, o que falhou e o que precisa da minha revisão”. Essa pergunta é o motivo inteiro de rodar mais de um agente ao mesmo tempo, e é exatamente o que uma pilha de terminais não consegue responder.
Um quadro de tarefas muda a unidade de “uma sessão em um host” para “uma Task com registro”. Os agentes pesquisam, executam, testam e reportam; as pessoas definem a direção, concedem autoridade e aceitam o resultado. A execução, os bloqueios, os resultados e a discussão de acompanhamento voltam para a linha do tempo da Task, então verificar uma execução remota é abrir uma Task, não entrar por SSH em um chute. A automação para onde o julgamento da equipe é necessário: o agente te entrega uma mudança com seu resumo e evidências, e a decisão de merge e release continua sendo sua.
Essa é a linha divisória entre as duas abordagens. O faça-você-mesmo roda o agente remotamente. Um quadro de tarefas mantém o contexto, o progresso, os bloqueios, os resultados e a revisão humana visíveis da solicitação até o release, não importa qual host fez o trabalho.
O checklist que você pode executar hoje
Percorra esta lista nos hosts que você pretende usar:
- [ ] Escolha seus hosts com honestidade: notebook para interativo, servidor para execuções longas ou paralelas, ambos se você realmente precisar.
- [ ] Instale um Runtime de agente compatível em cada host e autentique-o com sua própria assinatura ou chave de API.
- [ ] Registre cada host uma vez com
sharkly computer register --install-token <token>em vez de entrar por SSH a cada execução. - [ ] Confirme que cada Computer aparece como Online e tem pelo menos um Runtime reportando Available; só online não executa uma Task.
- [ ] Defina a visibilidade do Computer como Personal para o seu notebook e Organization ou Space para um servidor compartilhado.
- [ ] No notebook, ative o Prevent sleep para execuções que precisam sobreviver à tampa fechada.
- [ ] Atribua uma Task pequena e chata a um host remoto e confirme que o resultado volta para a Task, não para um buffer de histórico.
- [ ] Use
sharkly computer listesharkly daemon disk-usagepara acompanhar os hosts e recuperar espaço.
Você pode montar a configuração remota na mão com SSH, tmux e worktrees, ou pode registrar seus hosts existentes como Computers e deixar o serviço local cuidar das execuções. Se você já roda vários agentes de programação em mais de uma máquina, o Sharkly te dá um único lugar para gerenciar as tarefas e os resultados deles. Conecte um Computer, crie um Agent e atribua a ele algo chato primeiro.
