Comparación de seis frameworks de agentes de IA en Python al crear el mismo agente.
El mismo agente de investigación creado en LangGraph, CrewAI, PydanticAI, OpenAI Agents SDK, Smolagents y Google ADK, con líneas, tokens, puntuaciones de depuración y una guía de selección.
Si le preguntas a un grupo de personas qué framework de agente utilizar, obtendrás una docena de respuestas seguras pero contradictorias. Un grupo considera que LangGraph está sobrediseñado; otro lo ve como la única opción seria. Un tercero sugiere ignorar por completo los frameworks y comunicarse directamente con la API del modelo. Dado que un proyecto para cliente hace que ese enfoque sea costoso, la solución práctica es dejar de discutir y realizar un experimento.
El experimento fue sencillo: desarrollar el mismo agente en seis frameworks de Python durante un fin de semana, utilizando la misma tarea, el mismo modelo, las mismas herramientas y el mismo sistema de puntuación. El proyecto en cuestión consistía en un proceso de análisis de documentos, es decir, extraer datos de PDFs, cruzarlos con una base de datos, redactar un resumen y enviar el resultado por correo electrónico. Los resultados no favorecieron a ninguno de los grupos más vehementes.
Qué se desarrolló y cómo se evaluó
El agente de pruebas acepta el nombre de una empresa, busca noticias recientes en la web, extrae las cifras financieras clave, las compara con una base de datos SQLite local y devuelve un resumen estructurado en JSON. Eso son tres herramientas, un agente y un esquema de salida.
Se hace intencionadamente aburrido. Casi nadie lanza un agente de programación autónomo como su primer sistema en producción. La mayor parte del trabajo con agentes reales consiste en un orquestador de APIs con un poco de razonamiento adicional, y cualquier framework debería manejarlo sin problemas. GPT-4o sirvió como modelo en todos los casos en que un framework lo permitió.
Se midieron cinco aspectos:
- líneas de código necesarias
- tokens por ejecución, promediado en 10 ejecuciones
- latencia promedio
- horas desde cero hasta un prototipo funcional
- un “índice de depuración a las 2 AM”, que indica cuán fácil es averiguar qué salió mal cuando el proceso falla tarde en la noche
Esa última métrica es más importante de lo que parece. Las cosas siempre se rompen.
LangGraph: para quienes prefieren el control
Aproximadamente 210 líneas. Tres horas para obtener un agente funcional. 2,847 tokens por ejecución.
LangGraph da la impresión de haber sido diseñado por ingenieros de sistemas distribuidos. Se declara el estado, se definen los nodos, se dibujan conexiones entre ellos y se compila el resultado. Se parece menos a la creación de un agente de IA y más a la configuración de un pipeline de datos, lo cual es un cumplido.
La primera hora es complicada. Ver StateGraph, add_node y add_conditional_edges para un agente con tres herramientas parece una cantidad excesiva de pasos, por lo que resulta tentador abandonarlo y probar otro candidato.
Luego, un fallo cambia completamente la situación. En la tercera consulta de prueba, el agente funcionó muy mal, y al abrir LangSmith se pudo ver todo el proceso paso a paso: qué nodo tomó la decisión incorrecta, qué estado tenía y por qué llamó a la herramienta de base de datos antes de realizar la búsqueda. Pocos frameworks permiten un diagnóstico tan directo.
La característica que pocas personas mencionan: la ejecución duradera. Una ejecución interrumpida se reanuda desde su último punto de control. En un experimento durante el fin de semana, eso es conveniente. Pero en un proceso que procesa 10,000 documentos durante la noche, eso determina si podrás dormir o si te despertarán a las 3 de la mañana.
LangGraph también utilizó la menor cantidad de tokens en la prueba. Dado que el grafo representa el flujo de control, el modelo no gasta tokens decidiendo qué sucederá a continuación; ya se lo has indicado.
El costo implica pensar de antemano. No basta con pegar instrucciones y esperar. Un problema bien definido permite estructurar la solución, pero si aún estás definiendo el flujo de trabajo, dibujarás más diagramas de los que lanzarás funcionalidades reales.
Puntuación de depuración a las 2 AM: 9/10. LangSmith merece su reputación, ya que los problemas se diagnosticaron aquí más rápido que en cualquier otro lugar.
CrewAI: la máquina para prototipos rápidos
Aproximadamente 340 líneas de código. 45 minutos para obtener un agente funcional. 4,216 tokens por ejecución.
Desde pip install crewai hasta obtener una salida correcta solo se necesitaron tres cuartos de hora, lo que representa el inicio más rápido entre todas las opciones, aparte de Smolagents.
CrewAI piensa en equipos, no en agentes individuales. Cada miembro tiene un rol, un objetivo y una historia de fondo; las tareas se asignan al grupo y los miembros deciden quién hace qué.
researcher = Agent(
role="Financial Research Analyst",
goal="Find and verify recent financial data",
backstory="You're a senior analyst at a hedge fund...",
)
El campo de historia de fondo parece algo artificial y fue recibido con desdén. Sin embargo, los resultados obtenidos con el agente CrewAI resultaron notablemente más detallados que los mismos prompts enviados mediante llamadas API directas, por lo que la definición del rol sí influye en la forma en que el modelo aborda la tarea.
La velocidad tiene su precio. CrewAI consumió aproximadamente un 48% más de tokens que LangGraph para realizar la misma tarea. La arquitectura presupone al menos dos o tres agentes colaborando, así que incluso una combinación de un investigador y un escritor, tarea que un solo agente podría realizar, requiere costos adicionales por las comunicaciones entre ellos. Además, funciona de forma síncrona, y integrarla en un backend FastAPI asíncrono obligó a envolver las llamadas en run_in_executor. Es algo soportable, aunque irritante.
Los costos aumentan rápidamente. Una comparación publicada mostró que los gastos en pruebas con CrewAI ascendieron a 1,088 dólares, frente a 390 dólares para una versión equivalente de PydanticAI. Si se ejecutan miles de veces al día, la diferencia se vuelve exponencial.
En la escala de depuración, obtiene una puntuación de 5/10 a las 2 AM. Los éxitos son maravillosos, pero los fallos desaparecen en una cadena de delegación que funciona como una caja negra. Un error consumió 40 minutos antes de que se descubriera que se trataba de dos agentes pasándose la misma tarea de un lado a otro.
PydanticAI: el sobredotado silencioso
Aproximadamente 130 líneas. 1,5 horas para crear un agente funcional. 2.912 tokens por ejecución.
Mientras LangGraph es adecuado para quienes buscan control y CrewAI para los impacientes, PydanticAI está pensado para el desarrollador que quiere que su código funcione correctamente en seis meses. El equipo de Pydantic lo creó, y cualquiera que ya haya usado FastAPI conoce ya la mitad de la API. Los agentes están tipados, las salidas se validan y se inyectan las dependencias, por lo que todo lo que se puede detectar antes de la ejecución lo se hace.
agent = Agent(
"openai:gpt-4o",
result_type=CompanyAnalysis, # Pydantic model
system_prompt="You are a financial research assistant.",
)
El argumento result_type hace más de lo que parece. Cada respuesta del modelo se verifica automáticamente contra su esquema. Cuando el modelo devuelve JSON mal formado, lo cual ocurrirá eventualmente, el framework lo detecta y vuelve a intentarlo, por lo que no se necesita código de validación escrito a mano.
El proyecto full-stack-ai-agent-template realizó una comparación controlada que sigue este patrón. La misma aplicación de chat requería aproximadamente 160 líneas efectivas en PydanticAI, unas 280 en LangGraph y unas 420 en CrewAI.
Un código más corto no es automáticamente mejor, pero en este caso se midió la rapidez con la que se podía comprender cada versión. La versión de PydanticAI podía leerse y entenderse línea por línea. La de LangGraph exigía seguir mentalmente el grafo, mientras que la de CrewAI requería comprender su modelo de delegación.
La limitación es que PydanticAI es un framework de agente único. No cuenta con orquestación multiagente, transferencias de tareas ni delegación integradas, por lo que un diseño con tres agentes implica tener que escribir la coordinación uno mismo. Existe el módulo pydantic-graph, pero aún no compite con LangGraph o CrewAI para flujos de trabajo complejos.
La depuración en horas nocturnas obtiene una puntuación de 8/10. Los errores de tipo se detectan temprano, el IDE señala los problemas antes de que se ejecute cualquier cosa y los rastros de pila indican la línea correcta.
OpenAI Agents SDK: el éxito sorpresa
Aproximadamente 150 líneas de código. Una hora para tener un agente funcional. 2,791 tokens por ejecución.
Un framework del proveedor del modelo suena como una forma de encadenamiento, y casi no se incluyó en las pruebas. Esa expectativa resultó ser incorrecta.
El SDK es la versión final de OpenAI basada en su experimento anterior Swarm, y se reduce a cuatro primitivas: Agentes, Transferencias, Herramientas y Límites. Las Transferencias son las más destacadas. Usted indica qué agentes pueden pasar tareas a otros, y el framework se encarga de enrutarlas. Es menos flexible que el modelo de grafo de LangGraph, pero para aproximadamente el 80% de los casos de uso multiagente es suficiente y mucho más sencillo.
agent = Agent(
name="Researcher",
instructions="You are a financial research assistant.",
tools=[search_tool, db_tool],
handoffs=[summary_agent],
)
Tampoco está vinculado ya a un único proveedor. Se ha incorporado soporte para más de 100 LLMs a través de un adaptador any-llm, y la misma prueba se ejecutó con Claude sin necesidad de cambios en el código.
La eficiencia en el uso de tokens es comparable a la de LangGraph, lo que las sitúa entre las más bajas en la prueba. El seguimiento integrado es sólido, aunque ligeramente inferior al de LangSmith.
La desventaja es que su ecosistema es más pequeño. LangGraph cuenta con años de herramientas comunitarias, tutoriales y patrones probados. Aquí el producto es más reciente, por lo que en casos extremos a menudo uno se queda solo.
Puntuación de depuración a las 2 AM: 7/10. El seguimiento está integrado y es útil, y los errores son claros. Sin embargo, las carencias en la documentación obligan a leer el código fuente con más frecuencia de la deseable.
Smolagents: la opción para los minimalistas
Aproximadamente 95 líneas. 30 minutos para crear un agente funcional. 3,340 tokens por ejecución.
Esos números no son un error tipográfico. La implementación de Hugging Face toma en serio el minimalismo, con una lógica básica de unas 1,000 líneas de Python que se pueden leer en una tarde. Prueba hacer lo mismo con LangGraph.
La diferencia no radica solo en el tamaño. Todos los demás frameworks aquí utilizan llamadas a herramientas JSON, donde el agente emite un bloque de datos indicando qué función ejecutar con qué argumentos. En cambio, CodeAgent de Smolagents escribe código Python real.
agent = CodeAgent(
tools=[search_tool, db_tool],
model=InferenceClientModel(),
)
result = agent.run("Analyze recent financial news for Acme Corp")
Escribir código permite a un agente componer herramientas de forma natural, con bucles, condicionales y operaciones en cadena que las llamadas JSON no pueden expresar. La investigación de pruebas de rendimiento lo confirma, ya que los agentes de código superan a los basados en JSON en la mayoría de las pruebas.
El compromiso es la seguridad, ya que el agente genera y ejecuta Python. El aislamiento está disponible a través de E2B, Docker y Pyodide, pero debe configurarse manualmente. El LocalPythonExecutor por defecto no constituye explícitamente una barrera de seguridad, y sus documentaciones lo indican.
El consumo de tokens fue mayor que en LangGraph y el SDK de OpenAI. El Python generado resulta más extenso en comparación con el JSON compacto, y cada importación y declaración de variable consume tokens.
Con Gemini o GPT funciona bien, pero parece un clavo cuadrado. Brilla con los modelos e infraestructura de Hugging Face, y la integración con Hub, que permite compartir y cargar agentes de la misma manera que se comparte un modelo, es excelente si ya trabajas en ese ecosistema.
Puntuación de depuración a las 2 AM: 8/10. Leer el código escrito por un agente es mejor que decodificar una cadena de llamadas a herramientas en JSON, y una falla genera un rastro de errores normal de Python.
Google ADK: el caballo oscuro para empresas
Aproximadamente 180 líneas. Dos horas para tener un agente funcional. 3,102 tokens por ejecución.
El Kit de Desarrollo de Agentes de Google apareció discretamente en 2025, y muchos desarrolladores de Python aún no lo han probado. Ese es un vacío que merece ser llenado.
ADK es estricto en cuanto a la estructura pero flexible en la ejecución, tal como suelen ser las herramientas internas de Google. Los agentes se definen con un modelo, un nombre, instrucciones y herramientas, de forma muy similar al SDK de OpenAI. Encima de esto se encuentran los agentes de flujo de trabajo (Secuenciales, Paralelos y en Bucle), además de la API AgentTeam más reciente para coordinar varios agentes.
from google.adk.agents import Agent
root_agent = Agent(
model="gemini-2.5-flash",
name="financial_analyst",
instruction="You are a financial research assistant.",
tools=[search_tool, db_tool],
)
El marco de evaluación es lo que lo diferencia. Los casos de prueba se escriben en JSON, adk eval los ejecuta y se obtienen informes estructurados que indican si el comportamiento coincide con las expectativas. Ningún otro framework del mercado incluye herramientas de evaluación tan avanzadas.
La implementación también es sencilla, siempre y cuando se utilice Google Cloud. Vertex AI Agent Engine se encarga del escalado, el monitoreo y las sesiones, pero esta condición tiene una gran importancia.
ADK está optimizado para Gemini. Otros modelos funcionan a través de LiteLLM, pero los documentos, ejemplos y herramientas asumen siempre el uso de Gemini. Al ejecutar GPT-4o se encontraron casos límite no documentados que requirieron 45 minutos para resolver.
Puntuación de depuración a las 2 AM: 6/10. La interfaz de desarrollo adk web ayuda, pero los mensajes de error a veces son enigmáticos, y la documentación es exhaustiva al estilo típico de Google, lo que la hace difícil de navegar.
¿Cuál elegir?
“Depende” frustra a todos, así que aquí está la lógica de toma de decisiones que surgió de desarrollar el agente seis veces:
- Producción para el viernes: elija CrewAI o Smolagents. CrewAI es adecuado para equipos que no se sienten cómodos depurando la ejecución de código en Python. Smolagents es adecuado para aquellos que sí lo hacen y desean la menor cantidad de dependencias.
- Debe funcionar de manera fiable durante meses: elija LangGraph o PydanticAI. LangGraph es adecuado para lógicas ramificadas, pasos con intervención humana y la necesidad de una ejecución duradera. PydanticAI es adecuado principalmente para trabajos con un solo agente y salidas estructuradas, donde los lectores futuros deberían poder entender el código.
- Ya comprometido con un ecosistema: elija el OpenAI Agents SDK en la plataforma de OpenAI por sus funciones de seguimiento y evaluación, o Google ADK en GCP para una integración nativa con Vertex AI y evaluaciones integradas.
Lo problemático es que, en la mayoría de los proyectos, el framework importa menos que la ingeniería de prompts y el diseño de herramientas. La calidad de los resultados fue prácticamente idéntica en los seis casos una vez que se prestó atención real al prompt del sistema y a las descripciones de las herramientas. Lo que sí varió fue la experiencia del desarrollador, la posibilidad de depurar y la carga operativa.
La configuración que funcionó fue: PydanticAI para tareas de un solo agente, que son las más comunes, y LangGraph cuando el flujo de trabajo es realmente complejo. No hay necesidad de disculparse por utilizar dos frameworks.
Los seis uno al lado del otro
| Metric | LangGraph | CrewAI | PydanticAI | OpenAI SDK | Smolagents | Google ADK |
| ----------------- | ----------- | --------------- | ------------- | ---------------- | --------------- | --------------- |
| Lines of code | ~210 | ~340 | ~130 | ~150 | ~95 | ~180 |
| Time to prototype | 3 hrs | 45 min | 1.5 hrs | 1 hr | 30 min | 2 hrs |
| Avg tokens/run | 2,847 | 4,216 | 2,912 | 2,791 | 3,340 | 3,102 |
| Multi-agent | Yes (graph) | Yes (teams) | Manual | Yes (handoffs) | Yes (hierarchy) | Yes (AgentTeam) |
| Type safety | TypedDict | Pydantic config | Full generics | Generic context | Minimal | Standard |
| MCP support | Yes | Limited | Native + A2A | Native | Yes | Yes |
| Model-agnostic | Yes | Yes | Yes (20+) | Yes (100+) | Yes (LiteLLM) | Gemini-first |
| Best debugger | LangSmith | Logs | IDE/types | Built-in tracing | Code output | ADK Web UI |
| GitHub stars | ~48K | ~44K | ~15K | ~16K | ~26K | ~23K |
| 2 AM debug | 9/10 | 5/10 | 8/10 | 7/10 | 8/10 | 6/10 |
Ninguno de estos datos cuenta toda la historia, pero constituyen un punto de partida más honesto que la mayoría de los artículos comparativos.
Esté preparado para cambios
Estos frameworks evolucionan más rápido de lo que cualquiera puede documentar. LangGraph lanzó una actualización importante mientras se escribía este texto. La versión empresarial de CrewAI incorporó nuevas integraciones en menos de una semana. PydanticAI añadió soporte para el protocolo A2A, y Google ADK publicó una función SkillToolset unos días antes.
Toda comparación tiene una fecha de vencimiento. En seis meses las diferencias de rendimiento podrían disminuir, podrían aparecer nuevas funciones, y el framework que descartó podría convertirse en la opción obvia. Por lo tanto, elija aquel con el que su equipo pueda depurar a las 2 a.m., con el flujo de trabajo detenido y un cliente esperando, y no aquel con más estrellas en GitHub.
Leer más
- Agent Plugins 1.0.0: El formato de empaquetado compartido para habilidades y servidores MCP — Agent Plugins 1.0.0 estandariza las carpetas de plugins, plugin.json, las habilidades y mcp.json en todos los clientes. Qué abarca, qué omite en cuanto a seguridad, y un ejemplo de la CLI de Google Agents.
- MCP, A2A y ACP en la práctica: cómo un banco conecta herramientas y agentes entre sí — Cómo MCP, A2A y ACP dividen la tarea de conectar modelos con herramientas y agentes entre sí, ilustrado a través de un asistente bancario que gestiona fraudes y préstamos.