Sobre o projeto
AgentPod é um centro de comando portátil para runtimes de agentes de IA — um único lugar para gerenciar os ambientes onde os agentes vivem, onde quer que sejam executados. Para cada runtime, ele gerencia o sistema de arquivos, logs, terminal, configuração, saúde, ciclo de vida, limpeza e provisionamento, entre máquinas, harnesses e limites de rede. É primeiro anexável: você o aponta para runtimes que já executa ou permite que ele provisione novos.
A arquitetura tem três camadas. O console voltado ao operador é um SPA estático SvelteKit que fala com o hub via HTTPS e WSS. O hub é construído em Bun, Hono e Postgres (via Drizzle) e atua como registro de nós/estações, corretor de conexões, serviço de inscrição e autenticação (Better Auth), log de auditoria e atividade, e host de driver de provisionamento. O agente de nó é um binário Go estático instalado por host que faz chamadas *de saída* para o hub via WSS, funcionando atrás de NAT e CGNAT sem abrir portas de entrada. Cada agente de nó executa descritores de harness e executa verbos de contrato localmente.
AgentPod inclui descritores para vários harnesses de agentes — Hermes, OpenClaw, Claude Code, Codex, OpenCode e Pi — registrados em `apps/node-agent/cmd/agentpod-node/registry.go`. Cada descritor envolve a CLI ou API nativa do harness para enumerar runtimes, localizar configuração, logs e espaço de trabalho, e implementar operações de ciclo de vida sem reinventar a introspecção de cada harness.
A implantação é direta: execute o hub com Postgres e Bun (com auto-migração no primeiro início), construa o console com pnpm e implante a saída estática no Cloudflare Pages ou em qualquer host estático em um subdomínio do domínio registrável do hub (para que o cookie de sessão do Better Auth permaneça no mesmo site), depois inscreva agentes de nó nos hosts de destino com um script de instalação via curl que cria um serviço systemd. Binários pré-compilados para linux/darwin × amd64/arm64 são publicados em cada tag `v*` via GitHub Actions.
O status é de operador único: uma conta de administrador, inscrição fechada após o primeiro usuário, releases marcadas como `v0.1.x`. O limite de isolamento de tenant foi implementado — uma tabela `tenants`, `tenant_id` em cada tabela com escopo, e um helper `tenantScope()` que se recusa a construir uma consulta sem um, fixado por testes unitários. Tudo hoje roda sob o tenant de bootstrap único `fleet_00000000000000000000`; o que resta é o que usa o limite: organizações, principais e cobrança. O produto anterior baseado em OpenCode está congelado na tag `v0.0.4-opencode` com documentação arquivada em `docs/archive/`. Licenciado sob MIT.
Comments
0 Rating appears after 10 ratings
Sign in to join the discussion.