LangChain em produção: Habr AI explicou por que sistemas multiagentes estão migrando para Python puro

No Habr AI, foi publicada uma análise detalhada sobre por que sistemas multi-agentes em produção nem sempre se beneficiam do LangChain. O autor descreve um stack em Python puro e mostra onde abstrações LLM universais param de economizar tempo e começam a quebrar a previsibilidade.

Onde a Abstração Falha

A principal crítica ao LangChain no artigo é que a promessa de "trocar um modelo com uma linha" quase nunca funciona tão simplesmente em um serviço real. Na prática, até modelos do mesmo provedor se comportam de forma diferente: a versão cara retorna JSON consistentemente, enquanto a mais barata começa a mudar chaves, esquecer instruções do sistema e se confundir em exemplos few-shot. Se você adicionar outro provedor como YandexGPT a isso, quebra não apenas o formato da resposta, mas também as categorias em si, nas quais a lógica downstream depende.

"Abstração é prejudicial quando finge que coisas diferentes são iguais."

Isso leva a um segundo pensamento: fallback entre OpenAI e YandexGPT é uma tarefa de engenharia separada, não uma caixa de seleção na config. Cada agente precisa de prompts separados, um schema de validação unificado e um conjunto de testes de requisições reais. No sistema descrito, o limiar de aceitação para um provedor de backup é 85%, e cada resultado de chamada passa por um schema Pydantic antes de ser enviado ao cliente. Além disso, o autor coloca provedores em interfaces de Protocol para que o comportamento comum seja unificado, enquanto diferenças em prompts, autorização e formatos permaneçam explícitas.

RAG Sem Mágica

Uma seção separada do artigo é dedicada a RAG, onde "três linhas de código" também terminam rapidamente. Mudar o modelo de embedding sem reindexar a base de conhecimento essencialmente anula o propósito da busca vetorial: consultas e documentos acabam em espaços diferentes, e o sistema formalmente continua funcionando, apenas encontrando as peças erradas de texto. O mesmo acontece ao mudar o tamanho do chunk: documentos antigos são fatiados de um jeito, novos de outro, e a qualidade de busca se torna uma loteria que usuários notam antes que a equipe.

Portanto, em produção, de acordo com o autor, o que importa mais que uma chain conveniente é controle completo sobre o pipeline de retrieval. Quando uma resposta vai para um cliente real, a equipe precisa ver não apenas o texto final bonito, mas todo o caminho até lá: qual filtro foi aplicado, quais chunks entraram no contexto, quais eram os scores e por que um documento venceu o outro. Sem essa transparência, debugging vira adivinhação, e problemas surgem apenas após reclamações de usuários.

• score e metadados de cada chunk
• candidatos que não passaram na seleção
• filtragem por produto, cliente ou cenário
• atualizações da base de conhecimento sem downtime

Controle Importa Mais que o Agente

A parte mais frágil, de acordo com o autor, é o tool calling. O modelo pode escolher a ferramenta errada, passar parâmetros incorretos, ou se recusar a chamar e confiantemente alucinar uma resposta. O artigo explica isso com um exemplo simples: um usuário pergunta sobre seu cronograma pessoal, mas o agente vai não para o CRM mas para a base de conhecimento e retorna uma descrição geral do curso.

Tentar corrigir esses erros apenas com prompts frequentemente leva a novos edge cases, porque o modelo toma decisões probabilisticamente, não deterministicamente. Por isso, em sua própria arquitetura, o autor move o roteamento crítico para fora do LLM em um classificador baseado em regras, e mantém o modelo apenas para casos ambíguos. Sobre isso estão contratos explícitos para agentes, clientes separados para CRM e base de conhecimento, respostas tipadas, retry para falhas temporárias e escalação para um humano se um resultado válido não for obtido.

Um argumento adicional é segurança: quanto menor o framework e suas dependências transitivas, menor a superfície de ataque e mais fácil entender o que exatamente protege o sistema. O sistema resultante roda em FastAPI, usa diretamente SDKs de provedor, ChromaDB e API Bitrix24, em vez de uma camada de orquestração geral. Na versão open-source, o projeto tem cerca de 4500 linhas de código, 170 testes e 84% de cobertura.

Isso é mais trabalho manual do que em um cenário com um framework pronto, mas cada passo pode ser registrado, reproduzido e verificado separadamente. Para produção, esse é o trade-off chave: menos mágica, mais código, mas comportamento mais previsível em falhas, fallbacks e requisições não-padrão.

O Que Isso Significa

A análise do Habr AI captura bem o deslocamento no desenvolvimento LLM: frameworks ainda são convenientes para protótipos e demos, mas em produção, o valor se desloca para contratos explícitos, validação e observabilidade. Quanto mais provedores, integrações e riscos de negócio um sistema tem, mais difícil é esconder diferenças atrás de uma abstração única, e mais importante é controlar manualmente cada ponto de conexão.