El panorama de los frameworks de agentes en 2026 es más maduro que hace dos años, pero no más claro. LangChain/LangGraph sigue dominando, aunque recibe cada vez más críticas. CrewAI ha encontrado su nicho. Pydantic AI gana adeptos gracias a la seguridad de tipos. Los SDK de agentes de OpenAI y Anthropic crecen. Al mismo tiempo, muchos equipos vuelven discretamente a las llamadas directas a la API, sobre todo en producción.
Cada marco tiene sus partidarios y sus críticos. Las discusiones son fuertes. La decisión suele ser más personal que objetiva.
Este artículo elimina el ruido desde una perspectiva de arquitectura práctica: qué hace realmente cada framework, dónde encaja y qué patrones observamos en producción. Sin guerras religiosas, solo compromisos.
Para qué sirve un framework de agentes
Antes de comparar, aclaremos qué se está eligiendo. Un «framework de agentes» suele proporcionar:
- Una forma de definir agentes — qué rol tienen, qué herramientas poseen, qué comportamiento tienen.
- Un bucle de ejecución — llamar a LLM, analizar la salida, decidir qué hacer, llamar a herramientas, repetir.
- Gestión de estado — qué recuerda el agente, cómo está organizado.
- Integración de herramientas — cómo se definen y exponen las herramientas.
- Orquestación — múltiples agentes trabajando juntos, flujos de trabajo ramificados, reintentos.
- Conexiones de observabilidad — seguimiento, registro, depuración.
- Utilidades prácticas — plantillas de prompts, patrones comunes y funciones auxiliares.
Cada marco prioriza estos aspectos de forma diferente. Algunos se centran en la orquestación; otros en la definición de agentes; algunos son capas mínimas sobre las APIs del modelo.
El panorama
LangChain / LangGraph
El más grande. LangChain comenzó como una biblioteca de Python para encadenar llamadas a LLM; se convirtió en el marco de facto para muchos proyectos de IA. LangGraph es el marco específico de agentes construido encima.
Lo que hace bien:
- LangGraph para máquinas de estado. Su modelo de grafo —nodos como pasos, aristas como transiciones y estado compartido— encaja bien en flujos complejos.
- Ecosistema rico. Muchas integraciones: bases de datos vectoriales, proveedores de modelos, herramientas, observabilidad.
- LangSmith para observabilidad. Interfaz de seguimiento y depuración madura.
- Adopción amplia. Muchos ejemplos, mucha documentación, muchos que lo conocen.
Lo que no hace bien:
- Coste de la abstracción. LangChain contiene muchas capas que dificultan la depuración y obligan a invertir esfuerzo para entender qué sucede realmente.
- Cambios de API frecuentes. Cambios rotos con frecuencia. El código de hace 12 meses a menudo necesita actualizaciones.
- Sobrecarga de rendimiento. Las capas de indirección generan latencia y tokens.
- Curva de aprendizaje. La fluidez real toma semanas.
Cuándo elegir:
- Flujos de trabajo complejos de agentes con estado ramificado.
- Equipos que se benefician de un marco estándar (muchos ingenieros, patrones comunes).
- Cuando quieres observabilidad de LangSmith.
Cuándo omitir:
- Chatbots simples o bucles de agentes únicos (la API directa es más simple).
- Equipos que han sufrido antes los cambios frecuentes de LangChain.
- Proyectos donde cada milisegundo de latencia importa.
CrewAI
Un framework multiagente centrado en roles. Cada agente tiene un rol, un objetivo y un contexto, y colaboran en las tareas.
Lo que hace bien:
- Orquestación de agentes múltiples. Soporte integrado para que los agentes se comuniquen entre sí, deleguen, colaboren.
- Modelo mental basado en roles. Fácil de pensar (“el agente Investigador hace X; el agente Escritor hace Y”).
- Más simple que LangGraph para agentes múltiples. Más rápido de comenzar.
- Comunidad activa.
Lo que no hace bien:
- Profundidad limitada de agentes únicos. Si tu tarea es un agente complejo único, las abstracciones de CrewAI pueden parecer mal ajustadas.
- Rendimiento. Las configuraciones de agentes múltiples multiplican las llamadas a LLM; el coste y la latencia crecen rápidamente.
- Madurez limitada. Es más joven que LangChain y aún presenta aspectos poco pulidos.
- Prescriptivo. Ofrece menos flexibilidad que enfoques más directos.
Cuándo elegir:
- Flujos de trabajo de agentes múltiples donde la diferenciación de roles tiene sentido.
- Planteamientos basados en un «equipo» de agentes que colaboran.
- Prototipar ideas de agentes múltiples rápidamente.
Cuándo omitir:
- Tareas de un solo agente (exceso de capacidad).
- Producción donde el rendimiento importa (los agentes múltiples son costosos).
- Tareas donde el “enfoque de colaboración de agentes” es más teatro que sustancia.
Pydantic AI
Un framework más reciente centrado en la seguridad de tipos y la experiencia de desarrollo.
Lo que hace bien:
- Tipado fuerte. Basado en Pydantic en todo. Las entradas y salidas están tipadas. Los errores se detectan en tiempo de desarrollo.
- API limpia. Menos abstracción que LangChain; más cercana a las APIs del modelo.
- Python moderno. Asincronía, sugerencias de tipo, Pydantic v2.
- Agnóstico de modelos. Funciona con la mayoría de los proveedores.
Lo que no hace bien:
- Ecosistema más pequeño. Menos integraciones que LangChain.
- Menos probado a gran escala. Más reciente; los patrones de producción aún están emergiendo.
- Menos herramientas de orquestación. No ofrece las mismas capacidades que LangGraph para flujos complejos.
Cuándo elegir:
- Equipos de Python que priorizan la seguridad de tipos.
- Configuraciones de un solo agente o simples de agentes múltiples.
- Equipos que prefieren una abstracción mínima.
Cuándo omitir:
- Orquestación muy compleja (LangGraph podría adaptarse mejor).
- Proyectos no de Python (es solo para Python).
- Cuando necesitas un ecosistema grande de integraciones preconstruidas.
OpenAI Agents SDK
El marco de agentes oficial de OpenAI, optimizado para modelos de OpenAI.
Lo que hace bien:
- Optimizado para OpenAI. Diseñado específicamente para patrones de GPT-5/o3.
- API simple. Menos abstracta que LangChain.
- Transferencias integradas. Los handoffs entre agentes son un concepto de primer nivel.
- Seguimiento maduro. Observabilidad integrada vinculada al panel de OpenAI.
Lo que no hace bien:
- Dependencia de OpenAI. Está diseñado para sus modelos y utilizar otros proveedores resulta incómodo.
- Menos flexibilidad. Algunos patrones son más fáciles en marcos más generales.
- Más reciente que LangChain. Comunidad más pequeña.
Cuándo elegir:
- Invertir completamente en modelos de OpenAI.
- Quieres un camino respaldado por el proveedor.
- Agentes simples a moderadamente complejos.
Cuándo omitir:
- Estrategia multi-proveedor (mejor usar un marco más general o la API directa).
- Estás usando principalmente Anthropic o Google.
Anthropic Claude SDK
Similar — el camino de Anthropic para construir agentes con Claude.
Lo que hace bien:
- Optimizado para Claude. Especialmente bueno para el pensamiento extendido de Claude, el uso de computadoras, la integración de MCP.
- Diseño idiomático para los modelos Claude.
- Soporte fuerte de MCP.
Lo que no hace bien:
- Dependencia de Claude. Presenta el mismo compromiso que el SDK de agentes de OpenAI.
Cuándo elegir:
- Invertir completamente en Claude.
- Uso intensivo de características específicas de Claude.
Cuándo omitir:
- Estrategia multi-proveedor.
API directa
Prescindir de frameworks, llamar directamente a las API de OpenAI, Anthropic o Gemini y escribir el bucle de ejecución.
Lo que hace bien:
- Control total. Todo aspecto del sistema es tuyo.
- Sin coste de abstracción. Se ejecuta exactamente lo que ves.
- Fácil de depurar. No hay capas para analizar.
- Fácil de optimizar. Sin sobrecarga de marco.
- Sin cambios de versión. Actualizas cuando lo elijas.
Lo que no hace bien:
- Más código. Patrones que el marco maneja, tú los manejas.
- Reinventar. Patrones comunes se reimplementan por proyecto.
- Menos estandarización. Diferentes equipos construyen sistemas similares de forma diferente.
Cuándo elegir:
- Equipos maduros que envían sistemas de producción donde la fiabilidad importa más que la comodidad.
- Casos de uso específicos que no necesitan la flexibilidad de un marco.
- Rutas críticas de rendimiento.
- Después de prototipar con un marco y aprender los patrones.
Cuándo omitir:
- Fases de campo, exploratorias, “¿qué debemos construir” (los marcos te ayudan a descubrir patrones).
- Equipos con capacidad de ingeniería limitada.
LlamaIndex
Comenzó como una biblioteca enfocada en RAG; ha crecido hacia territorio más amplio de agentes.
Lo que hace bien:
- Sistemas RAG-heavy. Clase mundial para agentes enfocados en recuperación.
- Conectores de datos. Muchas integraciones para fuentes de datos.
- Abstracciones de recuperación maduras.
Lo que no hace bien:
- Abstracciones de agentes más débiles. Mejor para RAG que para agentes generales.
- Algunas superposiciones con el ecosistema de LangChain.
Cuándo elegir:
- Enfoque pesado en recuperación / RAG.
- Necesidad de muchos conectores de fuentes de datos.
Cuándo omitir:
- Trabajo de agentes no RAG.
Microsoft Autogen, Semantic Kernel
Ofrecimientos de Microsoft. Autogen para agentes múltiples; Semantic Kernel para aplicaciones de IA generales.
Lo que hace bien:
- Integración con el ecosistema de Microsoft. Funciona bien con Azure, .NET, Microsoft 365.
- Semantic Kernel: más empresarial que alternativas.
- Autogen: fuerte para investigación de agentes múltiples.
Lo que no hace bien:
- Comunidad más pequeña fuera de Microsoft.
- Menos impulso que LangChain/LangGraph.
Cuándo elegir:
- Equipos de Microsoft.
- Integración pesada con Azure.
Las dimensiones a considerar
Elegir no consiste en declarar un ganador, sino en ajustar los compromisos a las necesidades del proyecto.
Dimensión 1: Complejidad de orquestación
¿Cuán complejos son tus flujos de trabajo de agentes?
- Simple (chatbot, agente único, flujo lineal): API directa o Pydantic AI.
- Moderado (agente único, lógica ramificada): Pydantic AI, LangGraph, API directa.
- Complejo (múltiples agentes, máquinas de estado, reintentos): LangGraph, CrewAI, personalizado.
- Muy complejo (máquinas de estado grandes, agentes paralelos, enrutamiento complejo): LangGraph o personalizado.
Dimensión 2: Madurez de producción
¿Cuán importante es la fiabilidad frente a la experimentación?
- Experimentación / prototipo: cualquier marco te ayuda a moverte rápido.
- Producción, orientada a clientes: preferir marcos bien entendidos (LangChain tiene más patrones; la API directa tiene más control).
- Producción crítica: la API directa suele imponerse porque el equipo entiende cada línea.
Dimensión 3: Tamaño y habilidades del equipo
- Equipo pequeño (1-3 ingenieros): menos sobrecarga de marco es mejor. API directa o marcos simples.
- Equipo mediano (5-15): un marco ayuda a estandarizar. LangChain o Pydantic AI.
- Equipo grande (20+): el marco es esencial para patrones compartidos. LangGraph o marco interno.
Dimensión 4: Estrategia de proveedor
- Multi-proveedor: marcos generales (LangChain, Pydantic AI) o API directa.
- Proveedor único: SDKs del proveedor (OpenAI Agents SDK, Anthropic Claude SDK).
Dimensión 5: Sensibilidad al rendimiento
- Crítico para latencia (experiencia de usuario en tiempo real): API directa. Los marcos añaden latencia.
- Coste crítico (volumen alto): API directa. Los frameworks pueden añadir tokens.
- Estándar: cualquier marco es aceptable.
Dimensión 6: Necesidades de observabilidad
- Sólida de fábrica: LangChain + LangSmith.
- DIY: cualquier marco + tu capa de observabilidad.
El cambio hacia la API directa
Un patrón que vemos cada vez más en 2026: equipos maduros que se mueven de marcos a la API directa para producción.
¿Por qué?
- Después de 1-2 años de trabajo con agentes, los equipos conocen los patrones. El valor del marco (enseñar patrones) se agota.
- Los marcos cambian. La API directa no lo hace. La estabilidad de producción favorece la directa.
- Rendimiento: los marcos añaden sobrecarga. La API directa no lo hace.
- Facilidad de depuración: cuando algo falla, la API directa deja claro qué ha sucedido.
- Personalización: cada sistema de producción tiene requisitos únicos. Los marcos resisten la personalización; la API directa la acepta.
Esto no es un juicio contra los marcos. Son excelentes para aprender, prototipar y sistemas de producción moderadamente complejos. Pero para producción madura: la API directa suele ser la mejor opción.
El patrón de migración:
- Comenzar con LangChain o similar.
- Construir versiones iniciales.
- Aprender los patrones.
- Notar puntos de fricción (depuración, rendimiento, personalización).
- Migrar rutas calientes a la API directa.
- Finalmente, la mayor parte del código de producción es API directa.
No representa un fracaso de los frameworks, sino su ciclo de vida natural en algunos equipos.
Un marco de decisión práctico
Si estás eligiendo para un nuevo proyecto:
Paso 1: Definir el proyecto.
- ¿Cuál es la complejidad del agente?
- ¿Cuántos ingenieros?
- ¿Producción o prototipo?
- ¿Proveedor único o múltiples?
Paso 2: Aplicar heurísticas.
| Escenario | Recomendado |
|---|---|
| Prototipo, orquestación compleja | LangGraph |
| Prototipo, agentes múltiples | CrewAI |
| Producción, agente simple | API directa o Pydantic AI |
| Producción, orquestación compleja | LangGraph o personalizado |
| Proveedor único (OpenAI / Anthropic) | SDK del proveedor |
| Equipo de Python enfocado en seguridad de tipos | Pydantic AI |
| Uso pesado de RAG | LlamaIndex + tu elección |
| Equipo de Microsoft | Semantic Kernel / Autogen |
Paso 3: Crear un prototipo y después evaluar.
Pasas una semana con el marco elegido. Construyes una sección representativa. Evalúas:
- ¿Se adapta a tus patrones?
- ¿Estás luchando contra el marco o con él?
- ¿La depuración resulta manejable?
- ¿Es aceptable el rendimiento?
Si la respuesta es sí, continúa. Si no, prueba otro framework o utiliza la API directa.
Paso 4: Evitar una dependencia irreversible.
Incluso dentro de un framework, estructura el código para poder sustituirlo. Aísla su uso en una capa fina y mantén la lógica de negocio independiente.
Patrones que viajan entre marcos
Independientemente de la elección del marco, ciertos patrones son universales:
Separación de preocupaciones. Gestión de prompts separada de la lógica del agente separada de las definiciones de herramientas separada del bucle de ejecución. Cada marco ayuda con algunos; tú manejas el resto.
Observabilidad. Rastrear cada llamada a LLM. Rastrear cada llamada a herramienta. Agregar métricas. Es tu trabajo independientemente del marco.
Presupuestos de pasos y salidas controladas. Todo agente de producción los necesita. Los frameworks no los imponen; debes añadirlos.
Conjuntos de evaluación. Los marcos no incluyen herramientas serias de evaluación. Constrúyelos por separado (Promptfoo, Braintrust, personalizado).
Refuerzo para producción. Límites de tasa, idempotencia, gestión de errores y alternativas. El framework proporciona algunas primitivas; el resto corresponde al equipo.
Si te enfocas en estos patrones universales, la elección específica del marco importa menos. La disciplina del equipo importa más.
Veredictos por marco
Después de trabajar con muchos de estos, nuestra opinión:
LangChain/LangGraph: poderoso pero pesado. Vale la pena aprender. En producción, a menudo se migra lejos para rutas calientes.
CrewAI: útil para explorar ideas multiagente. En producción, este paradigma suele malgastarse en tareas que no lo necesitan. Utilízalo de forma selectiva.
Pydantic AI: subvalorado. La seguridad de tipos paga dividendos. Vale la pena probar.
SDK de agentes de OpenAI / Anthropic Claude: bueno si estás comprometido con ese proveedor. De lo contrario, riesgo de bloqueo.
LlamaIndex: aún el rey para trabajo pesado de RAG. Menos atractivo para agentes generales.
API directa: una evolución habitual en equipos maduros. No es necesario empezar aquí, pero es razonable acabar aquí para el código crítico.
Autogen / Semantic Kernel de Microsoft: bueno para el ecosistema de Microsoft; menos atractivo fuera.
Una historia de migración
Para hacerlo concreto, una progresión real:
Meses 1-3: El equipo construye las primeras características de IA en LangChain. Rápido para lanzar, muchos patrones aprendidos.
Meses 4-6: Surgen requisitos de producción — observabilidad, evaluaciones, rendimiento. El equipo los construye encima de LangChain.
Meses 7-9: Algunas abstracciones de LangChain se convierten en puntos de fricción. El equipo comienza a envolver LangChain en sus propias interfaces.
Meses 10-12: Una actualización de versión de LangChain rompe varios sistemas. El equipo reescribe rutas calientes en API directa. Rutas frías permanecen en LangChain.
Año 2: La mayor parte del código de producción es API directa. LangChain se usa para prototipos ocasionales. El “marco de agentes” interno del equipo — construido sobre API directa — es el estándar.
Este es un trayecto válido. Otros también son válidos — algunos equipos permanecen en LangChain felizmente; algunos lo omiten desde el primer día.
Una lente diferente: lo que realmente estás eligiendo
Más allá del marco, estás eligiendo:
- Una comunidad de la cual aprender.
- Un ritmo de cambio de API con el cual vivir.
- Un conjunto de patrones en los que estandarizar.
- Una experiencia de depuración.
- Una historia de observabilidad.
- Un coste de migración futuro.
El marco es una expresión de estos. Pero estas son las cosas que afectan a tu equipo día a día.
La elección correcta es el framework que encaja con la comunidad del equipo, su tolerancia a los cambios de API, sus patrones, su forma de depurar y sus necesidades de observabilidad. Sin ese ajuste, incluso la opción más popular será inadecuada.
Conclusión
No existe un mejor marco de agentes universal en 2026. La elección correcta depende de la complejidad del proyecto, el tamaño del equipo, la madurez de producción, la estrategia del proveedor y las preferencias del equipo.
Un enfoque funcional:
- Ajusta el marco a las necesidades del proyecto usando las heurísticas anteriores.
- Prototipa antes de comprometerte.
- Estructura el código para que el cambio sea posible.
- Enfócate en patrones universales independientemente del marco.
- Espera evolucionar — lo que se adapta ahora puede no adaptarse en 12 meses.
Muchos equipos maduros convergen en la API directa para código crítico de producción. Los marcos siguen siendo útiles para prototipos, aprendizaje y orquestación moderadamente compleja. La elección no es religiosa; es contextual.
Elige el que se adapte hoy. Ajusta cuando deje de adaptarse. El sistema que construyas importa más que el marco con el que lo construyas.
