Comparación de AutoGen y CrewAI: creación de equipos de agentes y cálculo de sus costos.

Durante mucho tiempo en el trabajo aplicado con LLM, la interacción con la IA se concebía como un bucle simple: alguien escribe una solicitud, un modelo responde y la conversación continúa. Eso funciona bien para responder preguntas. Pero comienza a presentar problemas cuando se trata de realizar tareas concretas, como escribir y depurar un programa, planificar un informe de investigación o ejecutar un flujo de trabajo de varios pasos que involucre varias herramientas y fuentes de datos.

Los sistemas multiagente existen para llenar esa brecha. En lugar de pedir una sola instrucción monolítica que se encargue de todo, la tarea se divide en roles: un ingeniero, un crítico, un investigador y un escritor. Cada rol se convierte en un agente, que es una capa que envuelve a un LLM y cuenta con su propia personalidad, memoria y responsabilidades. Los agentes se comunican entre sí, intercambian resultados parciales, se critican mutuamente e iteran hasta que el trabajo está terminado. La experiencia se asemeja menos a consultar a un oráculo y más a gestionar un equipo pequeño y muy rápido.

Hay dos frameworks que dominan este campo y que se comparan aquí: AutoGen, desarrollado por Microsoft Research como código abierto, y CrewAI, una plataforma más reciente diseñada teniendo en cuenta flujos de trabajo empresariales. Una tercera herramienta, AgentOps, añade una capa de observabilidad que permite ver qué están haciendo los agentes y cuál es su costo.

Roles en lugar de una sola instrucción extensa

El cambio conceptual ocurre antes de utilizar cualquier herramienta. En un entorno de un solo agente, una única instrucción del sistema cumple dos funciones al mismo tiempo: definir una personalidad y anticipar lo que se le podría pedir al modelo. Los marcos de trabajo multiagente distribuyen la carga. Cada agente recibe una descripción de tareas más específica, compuesta por una personalidad, un objetivo y, a veces, un trasfondo que influye en su enfoque.

Esto imita la forma en que trabajan los equipos humanos. Un ingeniero senior no es también el revisor de calidad, el gerente de proyecto ni el redactor técnico. Dividir esas funciones entre varios agentes genera tres ventajas prácticas:

• La especialización mejora la calidad. Un agente cuyo único propósito es verificar el código en busca de problemas de seguridad lo inspeccionará de manera más consistente que un generalista que debe manejar varios objetivos al mismo tiempo.
• Los ciclos de retroalimentación se vuelven explícitos. Dirigir la salida de un agente a otro cuya función es criticarla crea un ciclo de revisión deliberado, en lugar de confiar en que el mismo modelo detecte sus propios errores.
• Se vuelve posible el trabajo en paralelo. En sistemas más complejos, los agentes pueden abordar diferentes partes de un objetivo más amplio al mismo tiempo, con un agente de investigación y uno de redacción encargándose de subtareas separadas.

La parte difícil, que cada framework resuelve a su manera, es la comunicación. ¿Cómo intercambian información los agentes? ¿Comparten una misma conversación o mantienen intercambios aislados que solo se cruzan ocasionalmente? Las respuestas difieren entre AutoGen y CrewAI, y esa diferencia determina todo lo demás.

AutoGen: todo es una conversación

AutoGen de Microsoft trata cada interacción entre agentes como una conversación. Su decisión fundamental es que los agentes se comuniquen entre sí en lenguaje natural, tal como lo hacen las personas en un hilo de chat. Eso lo hace intuitivo: cualquiera que haya visto a dos colegas en un canal de Slack intercambiarse comentarios para perfeccionar una idea ya posee el modelo mental detrás de los agentes conversacionales de AutoGen.

Probándolo en AutoGen Studio

Antes incluso de escribir código en Python, AutoGen Studio ofrece una forma gráfica de experimentar. Se instala con pip, lee una clave API desde una variable de entorno y comienza con una sola llamada desde la línea de comandos. Luego se abre una interfaz de navegador. Allí se escribe una tarea, y un agente proxy de usuario trabaja con uno o más agentes asistentes hasta completarla.

El patrón que se presenta merece ser aprendido, ya que se repite en todas partes. Supongamos que la solicitud es trazar la popularidad de un término de búsqueda a lo largo del tiempo. El agente asistente comienza a generar fragmentos de código para las subtareas. Luego, el agente proxy del usuario ejecuta esos fragmentos en un entorno aislado y evalúa si el resultado parece correcto. Si el código falla o la salida es incorrecta, el proxy envía retroalimentación, el asistente la revisa, y el ciclo de código, ejecución, evaluación y revisión continúa hasta que el proxy queda satisfecho.

Ese bucle automatiza la parte humana de la revisión de código. En una sesión normal, un desarrollador escribe código, lo ejecuta, observa cómo falla y corrige el error personalmente. Aquí, el proxy se encarga del paso de ejecutar y verificar, de modo que una persona puede alejarse mientras los dos agentes resuelven el problema. No es perfecto, ya que las bibliotecas modificadas o las funciones obsoletas a veces causan problemas a los agentes, pero para problemas bien delimitados es excepcionalmente eficaz. La generación de imágenes, la visualización de datos y las aplicaciones cortas suelen completarse en un par de iteraciones.

Hay una recomendación que surge repetidamente: ejecutar AutoGen y AutoGen Studio dentro de Docker siempre que el código generado pueda interactuar con el sistema operativo subyacente. Los agentes están diseñados para escribir y ejecutar código arbitrario, por lo que un contenedor protege al sistema anfitrión de efectos secundarios. Este consejo cobra aún más importancia a medida que se les otorga más autonomía a los agentes.

Habilidades como capacidades adicionales

Studio viene con solo unas pocas herramientas integradas, como la de obtener contenido web o generar imágenes. Su verdadera fortaleza radica en las habilidades personalizadas. Una habilidad es una función ordinaria de Python con un nombre claro y una documentación bien escrita, y el framework lee esa documentación para decidir cuándo y cómo llamarla.

Un ejemplo práctico muestra cómo funciona la habilidad describe_image, que envía una imagen a un modelo con capacidades visuales y recibe una descripción a cambio. Al registrarse con el asistente principal, permite realizar solicitudes muy específicas: crear la portada de un libro dado y luego utilizar la habilidad image-description para verificar que el texto del título esté escrito correctamente. Los generadores de imágenes son notoriamente deficientes a la hora de producir texto legible, por lo que esto constituye un bucle de verificación natural. El asistente genera una imagen, la habilidad visual comprueba la escritura y, si hay errores, el asistente vuelve a intentarlo. La creación de herramientas pequeñas y bien documentadas genera un comportamiento sorprendentemente resistente.

Subyace una filosofía de diseño. En lugar de depender de los agentes para que escriban código completamente nuevo para cada necesidad, suele ser más sólido entregarles una biblioteca fija de habilidades probadas. El código que escribe un LLM de forma dinámica puede fallar cuando las bibliotecas evolucionan o las dependencias cambian, mientras que una habilidad revisada y empaquetada se comporta de manera predecible. Si los agentes deben escribir código dinámicamente o utilizar herramientas ya creadas se abordará más adelante en las discusiones sobre planificación y acción, y se trata de una de las decisiones más importantes al diseñar un sistema de agentes.

Código en bruto con pyautogen

Después de Studio, el siguiente paso es escribir código en Python utilizando el paquete pyautogen. Dos componentes son clave:

• ConversableAgent es un agente de uso general que se comunica directamente con un LLM.
• UserProxyAgent representa al usuario humano y puede ejecutar código en un directorio de trabajo.

Una configuración mínima conecta los dos elementos y inicia una conversación, por ejemplo pidiendo una solución de FizzBuzz en una sola línea. Al ejecutarse, el proxy solicita comentarios después de que el asistente proponga algo. Presionar Enter sin ofrecer comentarios le indica que proceda a ejecutar el código directamente. Si falta un paquete necesario como Pygame, el proxy lo instala antes de ejecutar el programa. Esa capacidad de autoprovisión es una señal pequeña pero significativa de la libertad que pueden tener estos sistemas, con ventajas e inconvenientes por igual.

Desafíos de programación útiles para evaluar un modelo incluyen verificar si un número es primo, crear un juego Snake y desarrollar una versión similar a Asteroids con Pygame. Son autónomos, verificables y lo suficientemente variados en dificultad como para revelar diferencias entre modelos o configuraciones.

Agregar un crítico mediante chats anidados

Un asistente más un proxy son útiles, pero los sistemas multiagente se destacan gracias a personas especializadas. Un segundo asistente puede actuar como revisor de código, con un mensaje del sistema que lo hace exhaustivo, estricto con los estándares y centrado en los problemas de seguridad y calidad.

En lugar de incluir directamente al crítico en la conversación principal, AutoGen ofrece chats anidados. El proxy del usuario registra un chat anidado que se activa cada vez que el agente ingeniero genera nuevo contenido. El código llega automáticamente al crítico, dentro de una conversación separada propia; el crítico responde con una revisión, y esa revisión se vuelve a integrar en el hilo principal. Se inserta un paso de revisión sin que el crítico interfiera en cada turno, y solo habla cuando hay algo nuevo que inspeccionar.

En una tarea como desarrollar un juego Snake con Pygame, la diferencia con respecto a un simple ejecución por parte de un ingeniero más un proxy es notable. Después de que se ejecuta el código, llega el evaluador con una lista de mejoras sugeridas, reproduciendo así de forma efectiva la revisión de las solicitudes de integración que los equipos humanos realizan a diario.

Uso del caché para controlar los costos

Las conversaciones entre múltiples agentes se vuelven costosas rápidamente. Cada intercambio consume tokens, y las tareas complejas pueden requerir decenas de turnos. AutoGen incluye un sistema de caché: por defecto, el estado de la conversación se guarda en el disco en una carpeta .cache, de modo que una tarea larga o interrumpida puede reanudarse sin tener que pagar por los mismos tokens dos veces.

Se puede establecer este comportamiento de forma explícita al envolver la llamada de chat en un gestor de contexto que proporcione un cache_seed. Es fácil subestimar la importancia de esto. En el desarrollo de agentes, es común querer reproducir o auditar una ejecución anterior en lugar de regenerarla, ya sea para depurar o para mostrar a las partes interesadas exactamente cómo llegó el agente a una salida.

Chat grupal y el problema del telégrafo

Los chats anidados presentan una debilidad estructural que recuerda al juego infantil del telégrafo. La información se transmite de un agente a otro en cadena, y los detalles se pierden, se distorsionan o se reinterpretan en cada paso. Si el crítico nunca ve la tarea original completa, solo lo que el ingeniero decidió transmitir, su retroalimentación puede no captar el punto esencial.

La solución de AutoGen es el chat grupal. Un objeto GroupChat mantiene un conjunto compartido de agentes y mensajes, similar a un canal de equipo, en lugar de una serie de enlaces punto a punto. Un GroupChatManager coordina el turno de respuesta para que los agentes no respondan todos al mismo tiempo. La característica clave es que cada miembro puede ver todo el historial de la conversación, no solo lo que se le ha transmitido explícitamente.

Reconstruir el ejemplo del ingeniero y el crítico con chat grupal permite una colaboración más coherente. Los comentarios del crítico se basan en el mismo contexto completo que tenía el ingeniero, y este puede responder directamente a las críticas específicas en lugar de trabajar a partir de una paráfrasis. El precio, como era de esperar, es la verbosidad. Las conversaciones grupales consumen más tokens porque cada agente escucha efectivamente cada intercambio, lo cual es importante cuando se paga por token a gran escala.

Qué enseñan los ejemplos iniciales

En conjunto, las sesiones de estudio y los experimentos con código en bruto destacan varios puntos aplicables a cualquier proyecto de agente. Una tarea debe ser lo suficientemente pequeña como para poder verificar su éxito, ya que el bucle de proxy solo funciona cuando existe una forma de determinar si el resultado es correcto. La ejecución debe ser aislada, puesto que la misma autonomía que hace útil el bucle también le permite instalar paquetes y ejecutar programas arbitrarios. Las revisiones son fáciles de incorporar una vez existen los roles, por lo que casi siempre vale la pena intentar contar con un crítico. Además, el costo debe tenerse en cuenta desde el inicio del diseño: el caché, la reproducción y la estimación del número de pasos necesarios para completar una tarea forman parte de la construcción del sistema, y no son consideraciones posteriores.

También existe una lección sobre dónde concentrar los esfuerzos. Escribir un buen mensaje del sistema para el crítico o una documentación clara para una habilidad cambia el comportamiento mucho más que añadir más agentes. Ambos frameworks premian descripciones precisas y específicas de para qué sirve cada agente.

CrewAI: estructura sobre improvisación

Mientras que AutoGen se inclina por conversaciones abiertas, CrewAI es más estructurado y definido, orientado claramente a entornos empresariales y de producción. En lugar de un diálogo fluido, exige tres definiciones explícitas: los agentes, con sus roles, objetivos e historias de fondo; las tareas que se les asignan; y el equipo que los une bajo una estrategia de procesamiento definida.

De qué está compuesto un agente

Un agente de CrewAI se configura a través de unos pocos parámetros:

• role: una etiqueta breve que describe la función del agente, como Investigador Senior de Chistes.
• goal: una declaración en lenguaje natural de lo que el agente intenta lograr, a menudo estructurada para ser reutilizada con diferentes entradas.
• backstory: una narrativa que construye la personalidad del agente y proporciona contexto, similar a una plantilla de prompt para el sistema.
• memory y verbose: indicadores que controlan si el agente mantiene el contexto a lo largo de las interacciones y si muestra su razonamiento en la consola.
• allow_delegation: si el agente puede asignar tareas a otros miembros del equipo.

Las tareas se definen por separado. Cada una incluye una descripción del trabajo, un campo expected_output que explica cómo se considera un éxito tanto para el agente como para el lector, una referencia al agente responsable, y opciones como ejecutar de forma asíncrona o guardar el resultado en un archivo.

El objeto Crew reúne finalmente a los agentes y las tareas junto con configuraciones sobre cómo se desarrollará la colaboración, ya sea de forma secuencial o jerárquica, además de opciones para compartir memoria, usar caché y establecer un límite en las solicitudes por minuto para controlar el uso de la API.

Un ejemplo divertido: el equipo de chistes

Para concretar esto, se crea un equipo de dos agentes especializados en chistes. Un Investigador Sénior de Chistes analiza qué hace que un tema sea gracioso y registra las tendencias sociales relevantes, mientras que un Redactor de Chistes transforma esa investigación en un chiste real. El investigador puede delegar tareas, pero el redactor no. Es una división sensata, ya que el redactor debe ser el último paso en el proceso y no un centro que redistribuya el trabajo.

Al tomar como ejemplo los chistes sobre ingenieros de IA, el equipo genera resultados verdaderamente divertidos mediante un proceso de investigación seguido de redacción, en lugar de usar una sola instrucción general. Aunque parezca absurdo, ilustra por qué separar la comprensión del tema de la creación del resultado creativo puede producir outputs más bien pensados. El trabajo preliminar del investigador sirve como contexto de referencia para el redactor, como un paso de recuperación de información integrado en el flujo de trabajo.

AgentOps: vigilando cómo se gasta el dinero

Los desarrolladores de agentes siguen enfrentándose a una preocupación constante: ¿cuánto cuesta ejecutar esto y dónde se va el tiempo? Si no se monitorean, los sistemas multiagente pueden generar facturas sorprendentemente altas, ya que cada intercambio entre agentes, delegación y llamada a herramientas suma costos. AgentOps es una plataforma de observabilidad diseñada específicamente para el comportamiento de los agentes basados en LLM, a diferencia de las herramientas tradicionales de MLOps, que no fueron creadas para agentes autónomos y conversacionales.

Añadirlo a un proyecto de CrewAI requiere poco esfuerzo: instale el paquete, obtenga una clave API, colóquela en la configuración del entorno e inicialice la biblioteca al principio del script. Cada ejecución del equipo se registra luego en un panel de control que muestra:

• la duración total de la ejecución y el entorno en el que se realizó,
• el número de tokens de prompt y de respuesta para cada llamada al LLM,
• el tiempo de cada llamada individual,
• el costo estimado en dólares para toda la ejecución.

El último punto resulta sorprendente la primera vez que se comprende. Una sola ejecución del grupo de bromas, que parece trivial para un ser humano, cuesta una fracción considerable de dólar una vez que se suman todos los razonamientos intermedios, las delegaciones y las llamadas a herramientas. Para quienes desarrollan sistemas de agentes con ambiciones comerciales, esto representa una valiosa realidad: orquestar agentes es poderoso, pero no es gratuito, y la capacidad de observación convierte un costo abstracto en una cifra que se puede presupuestar y optimizar.

Un equipo de desarrollo de juegos

Para una comparación directa con los ejemplos de programación de AutoGen, CrewAI se utiliza para armar un pequeño equipo de desarrollo de juegos formado por tres agentes:

1. Un ingeniero de software senior escribe la implementación en Python del juego solicitado.
2. Un ingeniero de control de calidad de software revisa el código en busca de defectos, desde importaciones faltantes y paréntesis desequilibrados hasta brechas de seguridad y lógica defectuosa.
3. Un ingeniero jefe de QA puede delegar tareas y es el responsable final de asegurarse de que el código final cumpla con la solicitud inicial.

Las tareas siguen esa misma estructura: uno realiza la implementación inicial, otro la audita en busca de defectos, y un tercero combina ambas en una versión final corregida. Este proceso de revisión en tres etapas —escribir, criticar y finalizar— es una versión más elaborada del modelo de ingeniero y crítico de AutoGen, expresado a través de la separación declarativa de tareas y agentes en CrewAI.

Cuando se ejecuta de forma interactiva, con el script preguntando qué tipo de juego se desea y cómo debe comportarse, el código tiende a ser notablemente más pulido que el generado por un único agente de programación sin supervisión. En parte, esto se debe a que la supervisión del ingeniero jefe de calidad detecta problemas que de otro modo podrían pasar desapercibidos.

Procesamiento secuencial versus jerárquico

CrewAI ofrece dos formas de organizar cómo el equipo realiza las tareas, y elegir la correcta es importante.

Procesamiento secuencial es el modo predeterminado y el más sencillo. Las tareas se ejecutan una tras otra en el orden definido, y cada agente termina antes de pasarle el control al siguiente. Es adecuado para flujos de trabajo cuyos pasos dependen realmente unos de otros en un orden fijo: investigación seguida de redacción, o implementación seguida de revisión y finalización.

Procesamiento jerárquico coloca a un administrador por encima del equipo, generalmente utilizando su propia conexión LLM solo para coordinación, el cual supervisa a los agentes y las tareas en lugar de hacer que actúen de forma sincronizada. El cambio es sencillo: especifique Process.hierarchical en lugar de Process.sequential y proporcione un manager_llm, comúnmente una instancia de ChatOpenAI con temperatura cero para tomar decisiones de supervisión más estables.

En teoría, el modo jerárquico debería ser el ganador, ya que el rol de gerente refleja cómo operan las organizaciones humanas más grandes. Los experimentos dicen lo contrario. Según AgentOps, la misma tarea de juego, ejecutada bajo un gerente jerárquico, costó más del doble, y el código no fue significativamente mejor para ello. Es un dato que resulta humillante. Agregar coordinación, supervisión y capas de agentes no mejora automáticamente los resultados, y los sistemas multiagente pueden igualmente caer en bucles costosos e improductivos cuando nadie los vigila de cerca.

Detener a los agentes descontrolados

Ese hallazgo está relacionado con un modo de fallo sutil: patrones de pensamiento repetitivos. Un agente que no confía en sus propios resultados puede seguir repitiendo variantes de la misma idea en lugar de decidirse y avanzar, gastando recursos sin lograr progreso real.

AgentOps cuenta con una visualización llamada “Repeat Thoughts” precisamente para esto, que muestra con qué frecuencia el razonamiento de un agente vuelve a contenido similar durante una ejecución. Una repetición excesiva es una señal de que algo estructural debe cambiar. Quizás las descripciones de las tareas son demasiado ambiguas, quizás hay demasiados agentes involucrados dada la complejidad del problema, o quizás el modo de procesamiento merece ser revisado. Diagnósticos como este separan la experimentación casual del trabajo disciplinado de calidad profesional. Es mejor detectar los problemas a tiempo que esperar a recibir una factura sorprendentemente alta.

Estilos de comunicación uno al lado del otro

La pregunta planteada al principio, sobre cómo los agentes intercambian información, ahora cuenta con respuestas concretas. AutoGen ofrece dos modelos: los chats anidados transmiten el material a través de conversaciones paralelas, lo que mantiene el hilo principal organizado pero corre el riesgo de perder detalles en cada paso. El chat grupal proporciona a todos el historial completo, lo que mejora la coherencia a costa de más tokens. CrewAI evita esta elección al hacer explícita la transferencia de tareas: cada tarea indica su agente y su resultado esperado, y la configuración del proceso decide si los resultados se transmiten directamente o a través de un administrador. Un enfoque favorece la colaboración emergente, mientras que el otro prioriza un flujo de trabajo que pueda consultarse con antelación.

Ninguno de ellos elimina la necesidad de supervisar la facturación. Ambos generan más llamadas al modelo que un único prompt, y ambos pueden entrar en bucles. Por eso, las herramientas de observabilidad son tan importantes como la elección del marco de trabajo.

Elegir entre los dos

Ninguno de los frameworks gana por completo. Cada uno refleja una creencia diferente sobre cuánto soporte debería tener un sistema multiagente. AutoGen permite que la estructura surja de la conversación misma, mientras que CrewAI exige al creador que la defina con antelación.

AutoGen es adecuado cuando:

• se desea la máxima flexibilidad y los agentes pueden improvisar su enfoque a través de un diálogo abierto;
• la tarea se beneficia de un intercambio exploratorio, como en sesiones de lluvia de ideas o depuración iterativa, donde la secuencia correcta de pasos no se conoce de antemano;
• un punto de entrada visual accesible como AutoGen Studio resulta útil para experimentos no técnicos antes de pasar al código.

CrewAI es adecuado cuando:

• se necesitan pipelines predecibles y auditables con roles y responsabilidades claros, como en flujos de trabajo empresariales donde la consistencia prevalece sobre la improvisación;
• Se prefieren la memoria integrada, el caché y la limitación de velocidad en lugar de las versiones implementadas a mano;
• La capacidad de observabilidad de primera clase es importante, dada la casi total ausencia de fricciones en la integración con AgentOps.

En la práctica, muchos proyectos reales aprovechan elementos de ambos enfoques: la claridad declarativa de CrewAI para las partes bien comprendidas de un pipeline, y la flexibilidad conversacional de AutoGen para las partes más complejas y exploratorias.