Experiência prática substituindo a pilha de automação por servidores MCP e LLMs locais

Configuração e hardware

O desenvolvedor executa uma combinação de Qwen 2.5 32B (quantizado) e Llama 3.3 70B em uma configuração dual 3090. Cada tarefa de automação possui seu próprio servidor MCP que expõe ferramentas que o modelo pode chamar, funcionando como uma API que um LLM consome em vez de um humano.

O que funciona bem

• Automação de revisão de código: Apontar o modelo para um diff do git através de ferramentas MCP detecta problemas reais incluindo bugs de lógica, tratamento de erros ausente e condições de corrida. Funciona cerca de 70% tão bem quanto uma revisão de um desenvolvedor sênior.
• Análise de logs e alertas: Servidor MCP conecta-se à stack ELK, com o modelo monitorando padrões de anomalias. Ele detectou 3 problemas de produção antes que os alertas do Grafana fossem acionados. A chave é fornecer contexto suficiente sobre como é o "normal" para seu sistema.
• Geração de documentação: Modelo lê a base de código através de ferramentas de arquivo MCP e gera/atualiza documentação de API, economizando horas por semana com qualidade de saída genuinamente boa.

O que não funciona (ainda)

• Cadeias de raciocínio de múltiplos passos: Qualquer coisa que exija mais de 3-4 chamadas de ferramentas em sequência começa a sair dos trilhos conforme o modelo perde o contexto do objetivo original. Janelas de contexto menores pioram isso. Prompting de cadeia de pensamento ajuda mas não resolve.
• Tomada de decisão em tempo real: Latência em modelos 70B significa que isso não pode ser usado para tarefas sensíveis ao tempo. O pipeline de revisão de código leva 2-3 minutos por PR, tornando-o adequado para fluxos de trabalho assíncronos mas inútil para aplicações em tempo real.
• Resolução criativa de problemas: Modelos locais têm dificuldade com tarefas que exigem abordagens não bem representadas nos dados de treinamento. Modelos de API (Claude, GPT-4) são notavelmente melhores aqui.

Lições arquiteturais principais

• Mantenha servidores MCP sem estado. Deixe o modelo gerenciar estado através de chamadas de ferramentas, não por sessão no lado do servidor.
• Construa lógica de repetição no seu cliente MCP, não no servidor. Modelos farão chamadas de ferramentas malformadas aproximadamente 5% das vezes.
• Registre cada chamada de ferramenta e resposta para depuração quando o modelo fizer algo inesperado.
• Use saída estruturada (modo JSON) para qualquer coisa que sistemas downstream consumam. Saída de texto livre é um pesadelo de depuração.