Construindo um Agente SRE de Bitcoin: Resposta a Incidentes Encontra IA

E se seu nó Bitcoin tivesse um SRE de IA disponível 24/7?

Não um chatbot que responde "o que é Bitcoin?" -- um verdadeiro engenheiro de confiabilidade de site que detecta picos de taxas às 3 da manhã, investiga inundações de mempool, diagnostica causas raízes e diz exatamente o que fazer. Um que segue o mesmo protocolo de resposta a incidentes que seu melhor engenheiro de plantão segue, exceto que nunca dorme e nunca esquece um runbook.

Foi isso que eu construí para o Hackathon MCP & Agentes de IA. Aqui está como.

O Problema com a Monitorização de Bitcoin Hoje

Executar infraestrutura de Bitcoin é operacionalmente exigente. Um operador de nó lida com:

• Volatilidade de taxas: As taxas podem saltar 10x em minutos durante a mintagem de inscrições ou consolidações de câmbio. Envie uma transação no momento errado e você paga a mais $50. Espere muito tempo e seu pagamento não é confirmado por horas.
• Inundações de mempool: Mais de 200.000 transações não confirmadas se acumulam, o uso de memória dispara e seu nó começa a expulsar transações de baixa taxa. Você precisa saber se isso é transitório ou sustentado.
• Anomalias de mineração: Um grande pool fica offline, a taxa de hash cai 15%, os tempos de bloco se estendem para 25 minutos. Isso é uma interrupção temporária ou algo para se preocupar?
• Saúde do nó: Seu nó fica para trás, perde pares ou fica com pouco espaço em disco. Quando o Grafana te alerta, você já perdeu blocos.

A resposta padrão é uma parede de painéis, limites de alerta estáticos e uma página wiki de runbook que foi atualizada pela última vez há seis meses. O operador acorda, faz SSH, executa comandos, faz referência cruzada com exploradores de blocos e toma uma decisão. Esse processo é lento, propenso a erros e não escala.

A Solução: Um Agente de IA Que Segue o Protocolo SRE

O Agente SRE de Bitcoin substitui o runbook por um agente de IA que segue um protocolo estruturado de resposta a incidentes em quatro fases:

DETECTAR -- Compare o estado atual com os limites de referência. Essa taxa de taxa é 3x a média de 7 dias? Existem mais de 100 mil transações não confirmadas? Já se passaram mais de 20 minutos desde o último bloco?

INVESTIGAR -- Coletar contexto. Se as taxas dispararam, verifique a composição do mempool. As transações de inscrição estão dominando? A produção de blocos está normal? Como é o próximo modelo de bloco?

DIAGNOSTICAR -- Correlacione sinais. Pico de taxa + inundação de mempool + aumento de inscrições = evento de mintagem de Ordinais. Pico de taxa + mempool normal = superestimação. Blocos lentos + queda de taxa de hash = interrupção de pool de mineração.

RECOMENDAR -- Produza orientações acionáveis. "Espere 2 horas, as taxas devem se normalizar. Use 15 sat/vB se for urgente. Nenhuma escalonamento necessário." Ou: "CRÍTICO -- taxas acima de 500 sat/vB sustentadas por 3 blocos. Alerta a equipe."

Arquitetura: Três Projetos Patrocinadores Trabalhando Juntos

O agente utiliza os três projetos patrocinadores do hackathon, cada um em seu papel natural:

agentregistry (descobrir bitcoin-mcp)
    |
    v
agentgateway (limitar taxa + rastreamentos OTEL)
    |
    v
kagent ToolServer (bitcoin-mcp, 49 ferramentas)
    |
    v
kagent Agent CRD (Agente SRE de Bitcoin)
    |
    v
Ciclo de Resposta a Incidentes

kagent fornece a camada de orquestração. O ToolServer CRD envolve bitcoin-mcp -- meu servidor MCP com 49 ferramentas para consultar a rede Bitcoin. O Agent CRD define o próprio agente SRE, incluindo um prompt de sistema de mais de 500 palavras que codifica todo o protocolo de resposta a incidentes, limites de detecção, padrões de diagnóstico e regras de segurança.

agentgateway fica na frente do bitcoin-mcp, aplicando limites de taxa (60 req/min para evitar loops de investigação descontrolados) e exportando rastreamentos OpenTelemetry para Jaeger. Após um incidente, você pode reproduzir cada chamada de ferramenta que o agente fez -- forense completa.

agentregistry publica bitcoin-mcp para que outros agentes e operadores possam descobri-lo. A entrada do registro descreve todas as 49 ferramentas em 9 categorias, tornando-o compostável em outros fluxos de trabalho de agentes.

A Demonstração: Um Pico de Taxa às 3 da Manhã

Veja o que acontece quando você executa o agente:

=== Agente SRE de Bitcoin -- Demonstração de Resposta a Incidentes ===

[1/4] VERIFICAÇÃO DE SAÚDE DO NÓ
  Altura do Bloco:    889.241
  Status de Sincronização:     VERDE -- SINCRONIZADO (altura 889.241)
  Rede:         principal

[2/4] AMBIENTE DE TAXAS
  Avaliação:      AMARELO -- Elevado (28,0 sat/vB)
  Recomendação:  Transações não urgentes devem esperar. Use 17 sat/vB se for urgente.

[3/4] ANÁLISE DO MEMPOOL
  Avaliação:      AMARELO -- Congestionado (67.234 txs, 245 MB)
  Recomendação:  Tempo estimado de limpeza: ~3 horas na taxa de hash atual.

[4/4] RELATÓRIO DE SITUAÇÃO
  Status Geral:  AMARELO
  Diagnóstico:       Pico de taxa correlacionado com congestionamento do mempool.
                   Provável aumento de demanda orgânica ou evento de inscrição.
  Recomendação:  Transações não urgentes devem esperar.
                   Monitorar para resolução nas próximas 1-3 horas.

O agente chamou três ferramentas do bitcoin-mcp (get_blockchain_info, get_fee_estimates, get_mempool_info), analisou os resultados em relação aos seus limites internos, correlacionou os sinais e produziu um relatório de situação estruturado. Sem painéis, sem investigação manual, sem consultas a runbooks.

O Prompt do Sistema: Codificando o Conhecimento do Operador

A parte mais interessante deste projeto não é o código -- é o prompt do sistema no kagent Agent CRD. Ele codifica anos de conhecimento do operador em regras estruturadas:

• Interpretação de taxas: Normal é 1-10 sat/vB. Elevado é 10-50. Alto é 50-200. Crise é 200+.
• Padrões de diagnóstico: Pico de taxa + inundação de mempool + inscrições = evento de mintagem. Pico de taxa + mempool normal = superestimação.
• Regras de segurança: Nunca transmita uma transação sem aprovação explícita. Nunca faça recomendações financeiras. Sempre caveat incerteza.
• Critérios de escalonamento: Alerta humanos quando os pares caem abaixo de 2, o nó cai mais de 100 blocos atrás ou as taxas excedem 500 sat/vB por 3+ blocos.

Essa é a chave: a inteligência do agente vem do prompt, não do código. O código apenas chama ferramentas e formata a saída. O prompt o torna um SRE.

Por Que Esse Padrão Importa Além do Bitcoin

A arquitetura -- servidor MCP de domínio + orquestração kagent + segurança agentgateway -- não é específica do Bitcoin. É um modelo para qualquer agente SRE de infraestrutura:

• SRE de Banco de Dados: Envolva pg_stat_statements como ferramentas MCP. Detecte consultas lentas, recomende alterações de índice.
• SRE de Kubernetes: Envolva kubectl como ferramentas MCP. Detecte loops de falha, recomende ajustes de recursos.
• SRE de Rede: Envolva SNMP/NetFlow como ferramentas MCP. Detecte tráfego anômalo, recomende regras de firewall.

O padrão é sempre o mesmo: ferramentas de domínio (servidor MCP) + raciocínio estruturado (prompt do agente) + guardrails (gateway) + descobribilidade (registro). kagent torna o agente nativo do Kubernetes. agentgateway torna seguro para produção. agentregistry torna compostável.

Experimente Você Mesmo

# Clone e execute a demonstração
pip install bitcoin-mcp
python demo.py

Nenhum nó Bitcoin necessário -- bitcoin-mcp fal