O Problema: 7 Apps em Produção, 1 Dev
Eu gerencio um servidor com 7 aplicações em produção. Laravel, Next.js, Python. MySQL, Redis, Nginx, Supervisor, PM2. Deploys, backups, monitoramento, certificados SSL, filas de jobs.
Cada uma dessas coisas pode quebrar a qualquer momento. E quando quebra num sábado às 23h, eu preciso resolver -- não importa onde eu esteja.
Antes, o fluxo era: abrir o notebook, conectar SSH, investigar logs, rodar comandos, torcer para o WiFi do bar não cair no meio do processo. Funciona, mas é lento e depende de eu ter o notebook por perto.
Aí veio a pergunta óbvia: e se eu pudesse fazer tudo isso pelo celular, conversando com uma IA que tem acesso direto ao servidor?
"Mas Já Existe o OpenClaw Pra Isso"
Sim. E eu comecei usando.
O OpenClaw é um projeto open source que faz exatamente isso: um assistente IA pessoal que roda na sua máquina, conectado ao Telegram, WhatsApp, Discord. Ele tem memória persistente, acesso ao sistema, 50+ integrações. É muito bom.
Usei por um tempo e me ajudou bastante. Era minha principal ferramenta pra gerenciar o servidor -- pedia pra verificar logs, checar serviços, coisas do tipo.
Mas aí bateu a coceira de dev.
Eu olhei pras minhas dores reais -- deploy de 7 apps diferentes, monitoramento de serviços específicos, backups com verificação no R2, SSL, filas do Horizon, Supervisor -- e percebi que eu queria algo moldado exatamente pro meu cenário. Cada servidor tem suas particularidades, cada projeto tem seus scripts, cada stack tem suas manhas.
Então decidi construir o meu. E no processo, aprendi infinitamente mais do que se tivesse ficado só usando uma ferramenta pronta.
Hoje ele substituiu completamente o que eu usava antes. Virou meu SRE 24/7 que conhece todos os meus projetos, meus runbooks, meus deploys. Responde em segundos pelo Telegram, faz deploy pelo celular, monitora tudo sem gastar um token de IA.
Um aviso importante: isso aqui é um projeto pessoal. Eu uso pra gerenciar meus side projects, meus testes, meu servidor de desenvolvimento. Não é um produto com clientes reais pagando. São projetos internos meus onde eu posso experimentar, quebrar e reconstruir sem consequências graves. É exatamente por isso que foi o ambiente perfeito pra esse tipo de experimento.
Se você tem necessidades simples ou o OpenClaw já resolve o seu caso -- use ele. Não precisa reinventar a roda. Eu reinventei porque queria, porque aprendi muito no processo, e porque minhas dores eram específicas o suficiente pra justificar.
Por Que Telegram
A primeira decisão foi a plataforma. Slack? Discord? App próprio?
Telegram. Por razões práticas:
- Funciona em qualquer lugar -- celular, tablet, desktop, web
- Suporte nativo a bot com inline buttons, comandos, grupos, fóruns
- Mensagens de voz -- eu posso literalmente falar com o bot enquanto dirijo
- Markdown nativo -- logs e outputs formatados direitinho
- Notificações configuráveis -- silêncio para monitoramento de rotina, alerta máximo para incidentes
Não precisei inventar nada. A infra do Telegram já resolve comunicação, autenticação, push notifications e histórico.
A Evolução: De Wrapper para SDK
O primeiro commit era simples: um bot Telegram que recebia mensagens e jogava para o Claude CLI via subprocess. Funcionava, mas era limitado. Sem streaming, sem controle granular, sem hooks.
Em um mês de desenvolvimento (21 commits, pra ser exato), o projeto evoluiu bastante:
Fase 1 -- Subprocess wrapper O básico. Mensagem entra pelo Telegram, vai pro Claude CLI, resposta volta. Funcionava, mas cada interação era uma sessão nova. Sem memória, sem contexto persistente.
Fase 2 -- Dashboard interativo Botões inline para ações rápidas: status do servidor, restart de serviços, health checks. O bot virou um painel de controle dentro do Telegram.
Fase 3 -- Comandos SRE de custo zero
Esse foi um ponto de virada. Percebi que nem tudo precisa passar pela IA. Verificar se o MySQL tá rodando? systemctl is-active mysql. Não preciso gastar tokens de API pra isso.
Criei comandos como /sre, /deploy, /logs, /backup que executam direto no servidor, sem chamar a IA. Monitoramento a custo zero.
Fase 4 -- Claude Agent SDK A migração de CLI subprocess para o Agent SDK foi a maior mudança. Em vez de spawnar um processo CLI, agora tenho controle total: streaming de respostas, hooks para interceptar ações, budget guard (limitar custo por interação), checkpointing de sessões.
# Antes: subprocess bruto
process = subprocess.Popen(["claude", "--print", message])
output = process.communicate()
# Depois: Agent SDK com controle total
async with AgentSession(model="claude-sonnet-4-20250514") as session:
response = await session.send(
message,
tools=tools,
max_tokens=budget_limit,
system=sre_context
)A diferença é como trocar de um script bash para um framework de verdade.
Desafios Técnicos Reais
O Problema da Janela de Contexto
O Claude tem uma janela de ~200k tokens. Parece muito, mas quando você está investigando um incidente em produção -- lendo logs, checando configs, analisando código -- isso acaba rápido.
A solução: delegação para subagentes. O bot principal funciona como um orquestrador thin. Tarefas que envolvem mais de 3 tool calls vão para um subagente que recebe um contexto focado, executa e retorna um resumo.
# Orquestrador decide: direto ou subagente?
if estimated_tool_calls > 3:
result = await delegate_to_subagent(task, focused_context)
# Subagente executa e retorna resumo compacto
else:
result = await execute_directly(task)O contexto do orquestrador principal fica leve. Quando a sessão chega perto do limite (150k tokens), ela rotaciona automaticamente e o novo agente lê um arquivo de estado para retomar de onde parou.
Skills Semânticas: TF-IDF Bilíngue
O bot aprende "skills" -- instruções sobre como executar tarefas específicas. Mas como encontrar a skill certa quando o usuário pede algo?
Implementei matching semântico com TF-IDF e similaridade de cosseno, com um twist: expansão de sinônimos PT-BR para EN. Quando o usuário digita "reiniciar o banco de dados", o sistema entende que "banco de dados" mapeia para "database" e "reiniciar" mapeia para "restart", encontrando a skill certa mesmo se ela foi escrita em inglês.
# Sinônimos bilíngues para expansão
SYNONYMS = {
"banco de dados": ["database", "mysql", "db"],
"reiniciar": ["restart", "reload", "reboot"],
"servidor": ["server", "host", "machine"],
# ...
}Não é um LLM fazendo embedding de 768 dimensões. É TF-IDF clássico com uma camada de expansão léxica. Simples, rápido, sem custo de API.
Segurança: Open Source Forçado
Decidi abrir o código do projeto. Isso me forçou a fazer algo que eu devia ter feito desde o começo: separar TODA informação pessoal do código.
Reescrevi o histórico do Git. Extraí tokens, IPs, nomes de projetos para arquivos de config externos. Criei um .gitignore decente. Auditei cada commit.
Open-sourcing é a melhor auditoria de segurança que existe. Quando você sabe que o mundo vai ler seu código, você escreve melhor.
Bugs do SDK: A Realidade de Usar Ferramentas Novas
O Claude Agent SDK (v0.1.46 na época) tinha bugs. TaskGroups que davam erro silenciosamente. Problemas de transport em sessões longas. Hooks que não disparavam na ordem esperada.
Não estou reclamando -- é um SDK novo e a equipe da Anthropic está iterando rápido. Mas é a realidade de adotar early: você vai encontrar bugs e precisa saber contornar.
Documentei cada workaround. Alguns viraram issues no repo. A experiência reafirmou algo que eu já sabia: ler o source code da ferramenta que você usa é tão importante quanto ler a documentação.
O Loop de Auto-Melhoria
A feature mais interessante: o bot revisa e sugere melhorias no próprio código.
Funciona assim: com um comando, o bot usa Claude com deep analysis para ler seu próprio source code, identificar problemas, sugerir refatorações e gerar um plano de melhorias priorizado.
É meta? Sim. Mas funciona. O bot já sugeriu:
- Simplificação de módulos que eu tinha over-engineered
- Remoção de 1500+ linhas de código morto (quando removi suporte multi-provider que não fazia mais sentido)
- Melhorias de error handling que eu não teria pensado
- Otimizações de queries SQLite para o histórico de mensagens
A regra é simples: o bot sugere, eu reviso e aprovo. Nada vai pra produção sem olho humano. Mas as sugestões são surpreendentemente boas.
Arquitetura Final
Depois de 21 commits, o projeto ficou assim:
- 6000+ linhas de Python
- Telegram bot (python-telegram-bot) como interface
- Claude Agent SDK para processamento de IA
- SQLite para sessões, custos, histórico de mensagens
- Skills semânticas com TF-IDF e expansão bilíngue
- Comandos SRE de custo zero (health checks sem IA)
- Voz: Whisper para transcrever áudio, ElevenLabs para TTS
- MCP: GitHub, Cloudflare, Playwright, Context7
- Auto-melhoria: revisão de código pelo próprio bot
O Que Eu Aprendi
1. Agentes de IA são tão bons quanto seu contexto e ferramentas. Um LLM sem acesso a ferramentas é um chatbot glorificado. A magia acontece quando ele pode ler logs, executar comandos, acessar APIs. O Agent SDK entendeu isso -- e por isso funciona melhor que simplesmente chamar a API de chat.
2. Nem tudo precisa de IA. Esse foi o aprendizado mais contra-intuitivo. Verificar se um serviço está rodando não precisa de IA. Listar backups não precisa de IA. Criar comandos de custo zero para operações simples economiza dinheiro e é mais rápido.
3. Open source te força a escrever código melhor. Quando você sabe que alguém pode ler seu código, você para de fazer gambiarra. Extrai configs, documenta decisões, organiza módulos. O código ficou objetivamente melhor depois que decidi abrir.
4. Ferramentas novas têm bugs. E tudo bem. Adotar early tem custo. Você vai encontrar problemas que ninguém documentou. Mas você também aprende mais rápido que todo mundo, e suas contribuições (issues, workarounds) ajudam a comunidade inteira.
O Projeto é Open Source
O código está aberto no GitHub. Se você quer montar algo parecido -- um bot Telegram que conecta IA a qualquer infraestrutura -- o repo é um bom ponto de partida.
github.com/billyfranklim1/telegram-claude-bot
Se usar, me conta como ficou. Se encontrar bugs ou tiver sugestões, abre uma issue. Contribuições são bem-vindas.
O servidor continua rodando. O bot continua gerenciando. E eu continuo fazendo deploy pelo celular no meio do almoço.
