Un agente de programación está disponible solo en la medida en que lo esté la máquina donde se ejecuta. Inicia un refactor largo con Claude Code o Codex, cierra la tapa para alcanzar un tren y la ejecución muere junto con tu sesión SSH. Lanza dos agentes en el mismo portátil y los ventiladores girarán a tope mientras tu editor se entrecorta. Llega un momento en que la pregunta deja de ser «qué agente» y pasa a ser «dónde se ejecuta realmente el agente».
La respuesta suele ser una de tres: mantenerlo en tu portátil, moverlo a un servidor remoto o repartir el trabajo entre ambos. Cada opción cambia comodidad por fiabilidad. Un portátil lo tienes ahí mismo, pero se suspende, se limita y se desconecta. Un servidor permanece despierto y tiene más núcleos, pero añade configuración y una capa de «¿qué está haciendo ahora mismo?». Repartir la diferencia te da lo mejor de ambos y la contabilidad de ambos.
Este artículo recorre de principio a fin la configuración de un agente remoto: la vía hazlo-tú-mismo con comandos reales, el modo de fallo que acecha en cada paso y dónde un Computer conectado en Sharkly elimina la parte que no deja de romperse. Ya tienes agentes de programación. El problema es ejecutarlos en algún sitio duradero y saber qué ocurrió cuando dejas de mirar.
Por qué querrías sacar un agente de tu portátil
El portátil es la opción por defecto porque es donde escribes. También es el peor anfitrión para cualquier cosa que se ejecute durante más tiempo que tu capacidad de atención. macOS se suspende al cerrar la tapa. El modo batería limita la CPU. Las VPN corporativas se caen. Cada uno de esos eventos mata al agente a mitad de tarea, y el agente ni se entera de que lo interrumpieron; te enteras tú cuando reabres la terminal y te encuentras con un prompt muerto y sin resumen.
Un host remoto soluciona la física. Una VM en la nube o un Linux de repuesto permanece encendido, mantiene su red y tiene núcleos de sobra para trabajo en paralelo. El coste es que ahora el agente se ejecuta en un sitio que no puedes ver. Te conectas por SSH para comprobar cómo va, recorres un log adivinando hasta dónde llegó, y los resultados viven en esa máquina hasta que los copias de allí.
Ejecutar ambos es el estado final honesto para la mayoría de la gente. Mantienes las ediciones rápidas e interactivas en el portátil, donde el feedback es instantáneo, y empujas los trabajos largos o paralelos al servidor, donde pueden correr durante una hora sin que tengas que estar pendiente. El truco está en hacer que uno o cinco hosts se sientan como un solo lugar en vez de una hoja de cálculo de direcciones IP.
La configuración remota DIY y dónde falla cada paso
La vía manual se conoce bien. Aquí va la versión resumida, con el modo de fallo que aparece en cada paso.
Aprovisiona el host y lleva tu agente a él:
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 fallo: el agente se autentica contra tu cuenta en una máquina que otras personas podrían tocar, y las credenciales se quedan en el historial y la configuración de ese shell. No hay registro de qué host guarda qué claves.
Mantén la ejecución viva más allá de tu sesión 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 fallo: tmux sobrevive a una conexión SSH caída, pero no a un reinicio del servidor, a un OOM kill ni a que se te olvide cuál de las seis sesiones en cuál de los tres servidores tiene la ejecución que te importa. Desacoplar no es lo mismo que durar.
Recupera los resultados y mira qué pasó:
scp you@build-server:~/your-repo/CHANGES.md .
ssh you@build-server 'cd your-repo && git diff'
Modo de fallo: el diff está en la máquina; el razonamiento está en un búfer de scrollback que ya se truncó; el «por qué» desapareció. Multiplica esto por dos agentes en dos hosts y estarás reconstruyendo el estado a mano cada vez que hagas una comprobación.
Ninguno de estos pasos es difícil. El problema es que no se componen. Cada nuevo host y cada nuevo agente es otro objetivo SSH, otra sesión de tmux, otro sitio donde vive un secreto y otro log que tienes que leer para responder a «¿ya terminó?».
Qué cambia un Computer conectado
Sharkly le pone nombre a eso que llevas improvisando. Un Computer es un dispositivo, servidor o contenedor conectado donde un Agent puede ejecutar trabajo; proporciona el sistema operativo, los archivos, las credenciales, el acceso a la red y las herramientas que el Agent necesita. Esa definición cubre tus tres opciones: «Puede ser un ordenador local, un servidor remoto, un contenedor o un host en la nube compatible».
Registras un host una vez en lugar de conectarte por SSH cada vez. Genera un token de instalación de un solo uso desde Settings, Computers en la máquina de destino y luego ejecuta:
sharkly computer register --install-token <install-token>
El token es de corta duración y un solo uso, así que no tiene sitio en una imagen ni en un script. Después de eso, un servicio local en segundo plano se ejecuta en el Computer. Registra el host, detecta qué herramientas de agente están instaladas y reporta cada una como un Runtime, envía heartbeats, recibe ejecuciones en cola, prepara directorios y reporta el progreso y los resultados de vuelta.
Merece la pena dejar claros dos límites, porque son donde la gente asume mal. Primero, el servicio local inicia la conexión al servidor, así que una configuración típica no requiere un puerto de entrada; no estás abriendo tu máquina de compilación a internet. Segundo, que un Computer muestre Online solo significa que su servicio local está enviando heartbeats. No significa que el Runtime pueda ejecutar una Task. Si una ejecución no arranca en un host online, revisa el estado de capacidad del Runtime antes de tocar la red.
A partir de aquí los modos de fallo anteriores tienen dirección. Las credenciales son del host, con alcance en él. Una ejecución sobrevive a tu terminal porque el servicio local es su dueño, no una sesión de tmux. Y el diff, el resumen y el razonamiento vuelven a la Task en lugar de vivir en un búfer de scrollback en una máquina a la que tienes que conectarte por SSH.
Portátil, servidor o ambos: cómo elegir de verdad
Más hosts no es automáticamente mejor, así que elige según el trabajo.
Usa tu portátil cuando la tarea sea corta, interactiva y quieras observarla. Regístralo como un Computer personal y, en Sharkly Desktop, activa Prevent sleep para que un trabajo rápido no se corte por la suspensión del sistema. Ten en cuenta que Prevent sleep solo aparece en la máquina local en la app de escritorio; no está disponible en un Computer compartido o remoto. Si todo lo que ejecutas termina dentro de una pausa para el café y nunca necesita sobrevivir a una tapa cerrada, todavía no necesitas un servidor, y añadir uno es solo mantenimiento que acabarás resentir.
Usa un servidor remoto cuando las tareas sean largas, necesiten más núcleos o no deban pelearse con tu editor por los recursos. Un host Linux registrado o una VM en la nube permanece despierto de forma predeterminada y da a los agentes en paralelo espacio para trabajar. Aquí es también donde el límite de concurrencia de tareas por host de un Computer y la visibilidad de Organization o Space se ganan su sitio: la máquina y sus credenciales están pensadas para compartirse, y Sharkly las trata como tal.
Usa ambos cuando quieras ediciones interactivas en local y ejecuciones pesadas en remoto sin mantener dos modelos mentales. Registra el portátil y el servidor, y luego asigna cada Task al Computer y Runtime que mejor encaje. El aislamiento con worktrees que evita que los agentes en paralelo colisionen funciona igual tanto si los agentes comparten un host como si se reparten entre varios, así que «ambos» te cuesta una selección, no un segundo flujo de trabajo.
Dónde deja de escalar el DIY y qué añade un tablero de tareas
La configuración de SSH y tmux aguanta para un agente en un host. Se rompe en el momento en que tienes varios agentes en varias máquinas, porque no hay una respuesta compartida a «qué agente está en qué, qué terminó, qué falló y qué necesita mi revisión». Esa pregunta es la razón de ser de ejecutar más de un agente a la vez, y es justo lo que un montón de terminales no puede responder.
Un tablero de tareas cambia la unidad de «una sesión en un host» a «una Task con un registro». Los agentes investigan, ejecutan, prueban e informan; las personas marcan la dirección, conceden autoridad y aceptan el resultado. La ejecución, los bloqueos, los resultados y la discusión de seguimiento vuelven a la línea temporal de la Task, así que comprobar una ejecución remota es abrir una Task, no conectarte por SSH a adivinar. La automatización se detiene donde se requiere el criterio del equipo: el agente te entrega un cambio con su resumen y su evidencia, y la decisión de merge y release sigue siendo tuya.
Esa es la línea entre los dos enfoques. El DIY ejecuta el agente en remoto. Un tablero de tareas mantiene el contexto, el progreso, los bloqueos, los resultados y la revisión humana visibles desde la petición hasta el release, sin importar qué host hizo el trabajo.
La checklist que puedes ejecutar hoy
Recorre esta lista en los hosts que tengas previsto usar:
- [ ] Elige tus hosts con honestidad: portátil para interactivo, servidor para largo o paralelo, ambos si de verdad lo necesitas.
- [ ] Instala un Runtime de agente compatible en cada host y autentícalo con tu propia suscripción o clave de API.
- [ ] Registra cada host una vez con
sharkly computer register --install-token <token>en lugar de conectarte por SSH en cada ejecución. - [ ] Confirma que cada Computer muestre Online y tenga al menos un Runtime reportando Available; solo estar online no basta para ejecutar una Task.
- [ ] Configura la visibilidad del Computer como Personal para tu portátil, Organization o Space para un servidor compartido.
- [ ] En el portátil, activa Prevent sleep para las ejecuciones que deban sobrevivir a una tapa cerrada.
- [ ] Asigna una Task pequeña y aburrida a un host remoto y confirma que el resultado vuelve a la Task, no a un búfer de scrollback.
- [ ] Usa
sharkly computer listysharkly daemon disk-usagepara llevar el control de los hosts y recuperar espacio.
Puedes construir la configuración remota a mano con SSH, tmux y worktrees, o puedes registrar tus hosts existentes como Computers y dejar que el servicio local sea el dueño de las ejecuciones. Si ya ejecutas varios agentes de programación en más de una máquina, Sharkly te da un solo lugar para gestionar sus tareas y resultados. Conecta un Computer, crea un Agent y asígnale algo aburrido para empezar.
