LangChain en producción: Habr AI explicó por qué los sistemas multiagente están migrando a Python puro

En Habr AI se publicó un análisis detallado sobre por qué los sistemas multi-agente en producción no siempre se benefician de LangChain. El autor describe un stack en Python puro y muestra dónde las abstracciones LLM universales dejan de ahorrar tiempo y comienzan a romper la previsibilidad.

Dónde Falla la Abstracción

La principal crítica a LangChain en el artículo es que la promesa de "cambiar un modelo con una línea" casi nunca funciona tan simplemente en un servicio real. En la práctica, incluso los modelos del mismo proveedor se comportan de manera diferente: la versión cara devuelve JSON consistentemente, mientras que la más barata comienza a cambiar claves, olvidar instrucciones del sistema y confundirse en ejemplos few-shot. Si añades otro proveedor como YandexGPT a esto, se rompe no solo el formato de respuesta, sino también las categorías en sí, de las cuales depende la lógica descendente.

"La abstracción es perjudicial cuando pretende que cosas diferentes

son iguales."

Esto lleva a un segundo pensamiento: el fallback entre OpenAI y YandexGPT es una tarea de ingeniería separada, no una casilla en la config. Cada agente necesita prompts separados, un esquema de validación unificado y un conjunto de pruebas de solicitudes reales. En el sistema descrito, el umbral de aceptación para un proveedor de respaldo es del 85%, y cada resultado de llamada pasa por un esquema Pydantic antes de ser enviado al cliente. Además, el autor coloca proveedores en interfaces de Protocol para que el comportamiento común sea unificado, mientras que las diferencias en prompts, autorización y formatos permanecen explícitas.

RAG Sin Magia

Una sección separada del artículo se dedica a RAG, donde "tres líneas de código" también terminan rápidamente. Cambiar el modelo de embedding sin reindexar la base de conocimiento esencialmente anula el propósito de la búsqueda vectorial: las consultas y documentos terminan en espacios diferentes, y el sistema formalmente continúa funcionando, solo encuentra las piezas de texto equivocadas. Lo mismo sucede al cambiar el tamaño del chunk: documentos antiguos se dividen de una manera, nuevos de otra, y la calidad de búsqueda se convierte en una lotería que los usuarios notan antes que el equipo.

Por lo tanto, en producción, según el autor, lo que importa más que una cadena conveniente es el control completo sobre el pipeline de retrieval. Cuando una respuesta va a un cliente real, el equipo necesita ver no solo el texto final hermoso, sino todo el camino hacia él: qué filtro se aplicó, qué chunks entraron en el contexto, cuáles eran los scores y por qué un documento ganó sobre otro. Sin esta transparencia, la depuración se convierte en adivinanza, y los problemas surgen solo después de quejas de usuarios.

• score y metadatos de cada chunk
• candidatos que no pasaron la selección
• filtrado por producto, cliente o escenario
• actualizaciones de la base de conocimiento sin downtime

El Control es Más Importante que el Agente

La parte más frágil, según el autor, es el tool calling. El modelo puede elegir la herramienta equivocada, pasar parámetros incorrectos, o rehusarse a llamar y alucinar confiadamente una respuesta. El artículo explica esto con un ejemplo simple: un usuario pregunta sobre su horario personal, pero el agente va no al CRM sino a la base de conocimiento y devuelve una descripción general del curso.

Intentar corregir tales errores solo con prompts a menudo lleva a nuevos edge cases, porque el modelo toma decisiones probabilísticamente, no determinísticamente. Por eso, en su propia arquitectura, el autor mueve el enrutamiento crítico fuera del LLM a un clasificador basado en reglas, y mantiene el modelo solo para casos ambiguos. Encima de esto hay contratos explícitos para agentes, clientes separados para CRM y base de conocimiento, respuestas tipadas, reintentos para fallos temporales y escalación a un humano si no se obtiene un resultado válido.

Un argumento adicional es la seguridad: cuanto más pequeño es el framework y sus dependencias transitivas, menor es la superficie de ataque y más fácil es entender qué exactamente protege el sistema. El sistema resultante se ejecuta en FastAPI, usa directamente SDKs de proveedores, ChromaDB y API Bitrix24, en lugar de una capa de orquestración general. En la versión open-source, el proyecto tiene alrededor de 4500 líneas de código, 170 pruebas y 84% de cobertura.

Esto es más trabajo manual que en un escenario con un framework listo, pero cada paso puede registrarse, reproducirse y verificarse por separado. Para producción, este es el trade-off clave: menos magia, más código, pero comportamiento más predecible en fallos, fallbacks y solicitudes no estándar.

Lo Que Esto Significa

El análisis de Habr AI captura bien el cambio en el desarrollo LLM: los frameworks siguen siendo convenientes para prototipos y demostraciones, pero en producción, el valor se desplaza hacia contratos explícitos, validación y observabilidad. Cuantos más proveedores, integraciones y riesgos comerciales tenga un sistema, más difícil es ocultar diferencias detrás de una única abstracción, y más importante es controlar manualmente cada punto de conexión.