primera versión estable v1.0 a finales de octubre de 2025. Después de pasar los últimos dos meses trabajando con sus nuevas API, realmente siento que esta es la versión más coherente y cuidadosamente diseñada de LangChain hasta la fecha.
No siempre fui fanático de LangChain. Las primeras versiones eran frágiles, mal documentadas, las abstracciones cambiaban con frecuencia y parecía demasiado prematuro usarlas en la producción. Pero la versión 1.0 se sintió más intencional y tenía un modelo mental más consistente sobre cómo deberían fluir los datos a través de agentes y herramientas.
Por cierto, esta no es una publicación patrocinada. Me encantaría escuchar tu opinión. ¡No dudes en enviarme un mensaje de texto aquí!
Este artículo no está aquí para regurgitar los documentos. Supongo que ya has incursionado en LangChain (o eres un gran usuario). En lugar de tirar una larga lista de puntos, voy a seleccionar sólo cuatro puntos clave.
Un resumen rápido: LangChain, LangGraph y LangSmith
En un nivel alto, LangChain es un marco para crear aplicaciones y agentes LLM, lo que permite a los desarrolladores ofrecer funciones de IA rápidamente con abstracciones comunes.
LangGraph es el motor de ejecución basado en gráficos para flujos de trabajo de agentes duraderos y con estado de forma controlable. Finalmente, LangSmith es una plataforma de observabilidad para seguimiento y monitoreo.
En pocas palabras: LangChain le ayuda a crear agentes rápidamente, LangGraph los ejecuta de manera confiable y LangSmith le permite monitorearlos y mejorarlos en producción.
mi pila
A modo de contexto, la mayor parte de mi trabajo reciente se centra en la creación de funciones de múltiples agentes para una plataforma de inteligencia artificial orientada al cliente en el trabajo. Mi pila de backend es FastAPI, con Pydantic impulsando la validación de esquemas y los contratos de datos.
Lección 1: Eliminación del soporte para modelos Pydantic
Un cambio importante en la migración a la versión 1.0 fue la introducción del nuevo método create_agent. Simplifica la forma en que se definen e invocan los agentes, pero también deja de admitir modelos y clases de datos de Pydantic en estado de agente. Ahora todo debe expresarse como TypedDicts que extiende AgentState.
Si utiliza FastAPI, Pydantic suele ser el validador de esquema predeterminado y recomendado. Valoré la coherencia del esquema en todo el código base y sentí que mezclar modelos TypedDicts y Pydantic inevitablemente crearía confusión, especialmente para los nuevos ingenieros que tal vez no supieran qué formato de esquema seguir.
Para resolver esto, introduje un pequeño asistente que convierte un modelo de Pydantic en un TypedDict que extiende AgentState justo antes de pasarlo a create_agent. Es fundamental tener en cuenta que LangChain adjunta metadatos personalizados a las anotaciones de tipo que usted debe conservar. Las utilidades de Python como get_type_hints() eliminan estas anotaciones, lo que significa que una conversión ingenua no funcionará.
Lección 2: Los agentes profundos son obstinados por diseño
Junto con la nueva API create_agent en LangChain 1.0, apareció algo que me llamó la atención: la biblioteca deepagents. Inspirándose en herramientas como Claude Code y Manus, los agentes profundos pueden planificar, dividir las tareas en pasos e incluso generar subagentes.
Cuando vi esto por primera vez, quise usarlo en todas partes. ¿Por qué no querrías agentes “más inteligentes”, verdad? Pero después de probarlo en varios flujos de trabajo, me di cuenta de que esta autonomía adicional a veces era innecesaria (y en ciertos casos, contraproducente) para mis casos de uso.
La biblioteca de deepagents es bastante obstinada y en gran medida por diseño. Cada agente profundo viene con algún middleware integrado, cosas como ToDoListMiddleware, FilesystemMiddleware, SummarizationMiddleware, etc. Estos dan forma a la forma en que el agente piensa, planifica y gestiona el contexto. El problema es que no puedes controlar exactamente cuándo se ejecutan estos middleware predeterminados, ni puedes desactivar los que no necesitas.
Después de profundizar en el código fuente de los agentes profundos aquí, puede ver que el parámetro middleware es un middleware adicional que se aplica después del middleware estándar. Cualquier middleware que se haya pasado en middleware=[…] se agrega después de los valores predeterminados.
Toda esta orquestación adicional también introdujo una latencia notable y es posible que no proporcione un beneficio significativo. Entonces, si desea un control más granular, siga con el método create_agent más simple.
No digo que los agentes profundos sean malos, son poderosos en los escenarios correctos. Sin embargo, este es un buen recordatorio de un principio clásico de la ingeniería: no persigas lo “brillante”. Utilice la tecnología que resuelva su problema real, incluso si es la opción “menos glamorosa”.
Mi característica favorita: salida estructurada
Habiendo desplegado agentes en producción, especialmente aquellos que se integran con sistemas empresariales deterministas, era crucial lograr que los agentes produjeran consistentemente resultados de un esquema específico.
LangChain 1.0 hace que esto sea bastante fácil. Puede definir un esquema (por ejemplo, un modelo Pydantic) y pasarlo a create_agent a través del parámetro Response_format. Luego, el agente produce una salida que se ajusta a ese esquema dentro de un único bucle de agente sin pasos adicionales.
Esto ha sido increíblemente útil siempre que necesito que el agente se adhiera estrictamente a una estructura JSON con ciertos campos garantizados. Hasta ahora, la producción estructurada también ha sido muy fiable.
Lo que quiero explorar más: Middleware
Una de las partes más complicadas de crear agentes confiables es la ingeniería contextual: asegurarse de que el agente siempre tenga la información correcta en el momento adecuado. El middleware se introdujo para brindar a los desarrolladores un control preciso sobre cada paso del ciclo del agente, y creo que vale la pena profundizar en él.
El middleware puede significar diferentes cosas según el contexto (juego de palabras). En LangGraph, esto puede significar controlar la secuencia exacta de ejecución del nodo. En conversaciones de larga duración, podría implicar resumir el contexto acumulado antes de la próxima convocatoria de LLM. En escenarios de presencia humana, el middleware puede pausar la ejecución y esperar a que un usuario apruebe o rechace una llamada a la herramienta.
Más recientemente, en la última versión menor v1.1, LangChain también agregó un middleware de reintento de modelo con retroceso exponencial configurable, lo que permite una recuperación elegante para errores transitorios de endpoints.
Personalmente, creo que el middleware cambia las reglas del juego a medida que los flujos de trabajo agentes se vuelven más complejos, de larga duración y con estado, especialmente cuando se necesita un control detallado o un manejo sólido de errores.
Esta lista de middleware está creciendo y realmente ayuda que siga siendo independiente del proveedor. Si ha experimentado con middleware en su propio trabajo, ¡me encantaría saber qué le resultó más útil!
para terminar
Eso es todo por ahora: cuatro reflexiones clave de lo que he aprendido hasta ahora sobre LangChain. Y si alguien del equipo de LangChain está leyendo esto, siempre estaré encantado de compartir los comentarios de los usuarios en cualquier momento o simplemente chatear 🙂
¡Diviértete construyendo!