--- title: "Event driven agents: la arquitectura de AutoGen v0.4 y dónde encaja AG2" description: "Los agentes orientados a eventos (event-driven) son actores de software autónomos que se comunican de forma asíncrona mediante mensajes y eventos, en lugar de seguir un bucle secuencial fijo." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/arquitecturas-de-agentes-de-ia-vision-general/event-driven-agents-la-arquitectura-de-autogen-v04-y-donde-encaja-ag2" category: "Agentes de IA" topic: "Arquitecturas de agentes de IA: visión general" updated: "2026-10-28T13:10:53.403Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Event driven agents: la arquitectura de AutoGen v0.4 y dónde encaja AG2 Los agentes orientados a eventos (event-driven) son actores de software autónomos que se comunican de forma asíncrona mediante mensajes y eventos, en lugar de seguir un bucle secuencial fijo. Cada agente reacciona a los eventos entrantes, los procesa de forma independiente y publica resultados, como en AutoGen v0.4. Esto permite bajo acoplamiento, paralelismo y procesos de larga duración. ## De un vistazo - Los agentes orientados a eventos siguen el modelo de actores: los agentes son actores aislados con estado propio que se comunican exclusivamente mediante mensajes asíncronos (eventos), no mediante memoria compartida ni un bucle central. - La nueva arquitectura de AutoGen v0.4 se basa en una capa de temas Pub/Sub con agentes RoutedAgent. AG2, según el propio proyecto, continúa el AutoGen original, es retrocompatible con AutoGen 0.2 y no utiliza este runtime de actores. Microsoft ha puesto AutoGen (a fecha de 2026) en modo de mantenimiento y remite al Microsoft Agent Framework. - La arquitectura orientada a eventos escala mejor con bajo acoplamiento, paralelismo real y procesos de larga duración; los bucles orquestados (ReAct, Plan-and-Execute) siguen siendo más sencillos y más fáciles de auditar en tareas cortas y secuenciales. - La conclusión de Cognition de 2025/2026 también se aplica aquí: los agentes en paralelo son adecuados para pasos de lectura y recopilación de información; los cambios de estado que implican escritura deberían ejecutarse en un solo hilo para evitar conflictos. - Lo decisivo para el B2B en Europa: el bajo acoplamiento aumenta la complejidad de la depuración, el tracing y la auditabilidad. Los registros de eventos distribuidos deberían almacenarse correlacionados y depurados de PII. El Reglamento de IA de la UE (art. 12) solo exige registros automáticos para sistemas de IA de alto riesgo y, tras el Digital Omnibus, no antes de diciembre de 2027. Los agentes orientados a eventos son actores de software autónomos que se comunican de forma asíncrona mediante mensajes y eventos, no en un bucle fijo y secuencial. Cada [agente](https://blckalpaca.at/es/glosario/agente) reacciona a los eventos entrantes, los procesa de forma independiente y publica sus resultados como nuevos eventos. Esta arquitectura, tal como la implementa AutoGen v0.4, desacopla los agentes entre sí y permite paralelismo, bajo acoplamiento y procesos de larga duración. - **Núcleo:** agentes = actores con estado propio que se comunican exclusivamente mediante mensajes asíncronos en lugar de a través de un bucle de control central. - **Ventaja:** bajo acoplamiento, paralelismo real e idoneidad para procesos de larga duración (de minutos a horas) con esperas a sistemas externos o a personas. - **Contrapartida:** mayor complejidad en la depuración, el tracing y la auditabilidad. El flujo de control ya no se puede leer de forma lineal. ## Del bucle orquestado al bus de eventos La mayoría de los patrones de agente clásicos son estrictamente secuenciales. En el patrón ReAct, por ejemplo, un único agente basado en un [modelo de lenguaje de gran tamaño (LLM)](https://blckalpaca.at/es/glosario/llm) recorre repetidamente el ciclo Thought → Action → Observation hasta que emite una respuesta final. La latencia es, por naturaleza, serial: equivale aproximadamente al número de pasos multiplicado por la suma del tiempo de respuesta del [LLM](https://blckalpaca.at/es/glosario/llm) y el tiempo de respuesta de la herramienta. Plan-and-Execute o ReWOO planifican de antemano, pero en esencia también ejecutan los pasos uno tras otro. Las arquitecturas orientadas a eventos rompen con este modelo. En lugar de un bucle central que dicta el siguiente paso, hay una capa de mensajes o de temas (un bus de eventos). Los agentes se suscriben a determinados temas, reaccionan a los eventos publicados y, a su vez, desencadenan eventos posteriores. Muchos frameworks ofrecen ya flujos de trabajo basados en grafos con llamadas a herramientas, por ejemplo [LangGraph](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/frameworks-de-agentes-de-ia-comparativa-langgraphcrewaiautogen/langgraph-agentes-con-estado-como-grafo-dirigido) y los workflows del [Microsoft Agent Framework](https://learn.microsoft.com/de-de/agent-framework/overview/). Las diferencias entre patrones de [prompt](https://blckalpaca.at/es/glosario/prompt) pasan a un segundo plano; lo decisivo pasa a ser la calidad del middleware, de la observabilidad y de la ingeniería de contexto. ## El modelo de actores como base teórica Los agentes orientados a eventos implementan el modelo de actores, conocido en la programación concurrente. Un actor es una unidad de cómputo aislada con tres propiedades: - **Estado propio y encapsulado**: sin memoria compartida entre actores, es decir, sin las clásicas condiciones de carrera sobre variables comunes. - **Comunicación solo mediante mensajes**: un actor procesa normalmente los mensajes entrantes de uno en uno desde su buzón. - **Dinámica en tiempo de ejecución**: un actor puede cambiar su estado, crear nuevos actores y enviar más mensajes. En AutoGen v0.4, esto se refleja en la abstracción `RoutedAgent` y en una capa de temas Pub/Sub. La documentación oficial de AutoGen describe, por ejemplo, el [patrón de reflexión](https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/design-patterns/reflection.html) como dos agentes `RoutedAgent` que se comunican a través de temas Pub/Sub: un `CoderAgent` y un `ReviewerAgent`, que iteran hasta que el revisor aprueba el código. Como condición de parada alternativa, la documentación menciona un número máximo de iteraciones. Precisamente esta lógica de enrutamiento por temas marca la transición del bucle codificado de forma rígida al acoplamiento orientado a eventos: qué agente se activa a continuación no lo decide un controlador central, sino el evento publicado y las suscripciones a temas. ## AutoGen v0.4, AG2 y el contexto de Microsoft Importante para los responsables de decisión en Europa que evalúan el stack de Microsoft: según su [propio repositorio de GitHub](https://github.com/microsoft/autogen), AutoGen está en modo de mantenimiento y ya no recibe nuevas funcionalidades. Microsoft ha fusionado AutoGen y Semantic Kernel en el **Microsoft Agent Framework** y dirige allí los proyectos nuevos. La [guía de migración desde AutoGen](https://learn.microsoft.com/de-de/agent-framework/migration-guide/from-autogen/) es la referencia determinante para quienes ya usan AutoGen. **AG2** no es un derivado de la arquitectura v0.4. Según su [propia descripción](https://ag2.ai/compare/autogen), el proyecto continúa el AutoGen original como proyecto comunitario y ofrece a los usuarios de AutoGen 0.2 una vía de migración retrocompatible. La [API](https://blckalpaca.at/es/glosario/api) clásica de AG2 se basa en patrones conversacionales como ConversableAgent y GroupChat. Estas clases se encuentran hoy en [AG2 Classic](https://classic.docs.ag2.ai/latest/docs/user-guide/release-history/), que solo recibe correcciones críticas y de seguridad. Desde la v1.0, [AG2](https://github.com/ag2ai/ag2) apuesta por un [modelo de red](https://docs.ag2.ai/docs/user-guide/network/overview/) propio: un hub central mantiene el estado de referencia y los agentes intercambian eventos a través de canales. RoutedAgent y los temas Pub/Sub de AutoGen v0.4 no aparecen en él. Así que, si hoy construyes una arquitectura orientada a eventos, en la práctica eliges entre el AutoGen v0.4 existente (funcional, pero solo con mantenimiento), el Microsoft Agent Framework para proyectos nuevos en entornos empresariales y AG2 como alternativa independiente con otro modelo. ## Cuándo escala mejor un enfoque orientado a eventos Un enfoque orientado a eventos no siempre compensa. Tres condiciones hablan a su favor: 1. **Bajo acoplamiento**: los agentes deben poder desplegarse, sustituirse y escalarse de forma independiente. Un agente de investigación puede volver a desplegarse sin tocar el agente de redacción. 2. **Paralelismo**: varias subtareas se ejecutan al mismo tiempo. Las conclusiones de Cognition en «[Don't Build Multi-Agents](https://cognition.com/blog/dont-build-multi-agents)» (junio de 2025) y «[Multi-Agents: What's Actually Working](https://cognition.com/blog/multi-agents-working)» (abril de 2026) son aquí la guía central: las configuraciones multiagente funcionan para la recopilación de información **en paralelo y de lectura**, mientras que **los cambios de estado que implican escritura deberían ejecutarse en un solo hilo**. En Devin, un Devin gestor puede dividir una tarea mayor, lanzar Devins hijos para ella y coordinar su progreso mediante un [MCP](https://blckalpaca.at/es/glosario/mcp) interno. Traducido para los clientes de agencia: un agente potente con herramientas como estándar, subagentes en paralelo solo para recopilar información, nunca para operaciones de escritura ni cambios de estado. 3. **Procesos de larga duración**: procesos de minutos u horas, con esperas a API externas, sistemas batch o personas (Human-in-the-Loop). Un bucle síncrono se bloquearía aquí; un sistema orientado a eventos simplemente espera al siguiente evento. ## Ventajas y desventajas frente a los bucles orquestados | Criterio | Orientado a eventos (modelo de actores, AutoGen v0.4) | Bucle orquestado (ReAct, Plan-and-Execute) | | --- | --- | --- | | Acoplamiento | Débil: los agentes solo se comunican mediante eventos/temas | Fuerte: un bucle central controla el siguiente paso | | Paralelismo | Nativo, varios actores a la vez | Secuencial (latencia ≈ N × (LLM + herramienta)) | | Procesos de larga duración | Punto fuerte: no bloqueante, impulsado por eventos | Punto débil: el bucle se bloquea durante la espera | | Escalabilidad | Horizontal, actores escalables individualmente | Vertical y limitada, un solo flujo de control | | Trazabilidad | Más difícil: se necesitan registros de eventos distribuidos y correlacionados | Más fácil: traza lineal Thought/Action/Observation | | Depuración | Compleja: propagación de errores, condiciones de carrera | Manejable: un camino, un registro | | Adecuado para | Procesos distribuidos, paralelos y de larga duración | Tareas cortas, secuenciales y sujetas a auditoría | La mayor debilidad es la observabilidad. En un bucle ReAct, la traza completa Thought/Action/Observation está disponible de forma lineal y es directamente auditable, una ventaja real para los sectores regulados en Europa. En el modelo orientado a eventos, el flujo de control se reparte entre muchos actores; los errores pueden propagarse y, sin un tracing cuidadoso, el análisis de causas se vuelve difícil. Por eso, las herramientas de observabilidad como LangSmith, Langfuse o Arize Phoenix son, en la práctica, obligatorias. El Reglamento de IA de la UE solo exige el registro automático para [sistemas de IA de alto riesgo](https://blckalpaca.at/es/glosario/sistemas-de-ia-de-alto-riesgo): estos deben poder registrar automáticamente eventos durante toda su vida útil ([art. 12 del Reglamento de IA de la UE](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32024R1689)). Según el [Reglamento modificativo (UE) 2026/1744](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202601744) (Digital Omnibus sobre el Reglamento de IA), las obligaciones de alto riesgo para los sistemas del anexo III no se aplican hasta el 2 de diciembre de 2027, y para la IA en productos del anexo I, a partir del 2 de agosto de 2028. Al mismo tiempo, el [RGPD](https://blckalpaca.at/es/glosario/rgpd) exige limitar los datos personales a lo necesario y no conservarlos de forma identificable más tiempo del necesario ([art. 5 del RGPD](https://dsgvo-gesetz.de/art-5-dsgvo/)). Por ello, las trazas de eventos distribuidas deberían almacenarse correlacionadas y depuradas de PII, para que la trazabilidad y la minimización de datos vayan de la mano. ## Ejemplo concreto: investigación de mercado en paralelo Una agencia de marketing debe elaborar un [análisis de la competencia](https://blckalpaca.at/es/glosario/analisis-de-la-competencia) para un cliente B2B: cinco competidores, tres fuentes de datos para cada uno (web, notas de prensa, redes sociales). En un bucle ReAct, esto se ejecutaría de forma estrictamente secuencial: 5 × 3 = 15 pasos de herramienta seguidos. Suponiendo 8 segundos por paso (tiempo de respuesta del LLM más el de la herramienta), resultarían unos 120 segundos de latencia total, y además cada paso vuelve a pagar el prefijo de contexto completo. Con un enfoque orientado a eventos, el flujo sería así (pseudocódigo): \`\`\` Evento: AnalisisIniciado(competidores=[A,B,C,D,E]) -> Orchestrator publica 5 eventos "AnalizarCompetidor" -> 5 ResearchAgents reaccionan EN PARALELO, 3 fuentes cada uno -> cada uno publica "ResultadoParcialListo" -> AggregatorAgent se suscribe a "ResultadoParcialListo" -> con 5/5 resultados parciales publica "InformeListo" -> WriterAgent (¡single-threaded!) redacta el informe final \`\`\` Los cinco actores de investigación se ejecutan simultáneamente; el tiempo total transcurrido se reduce aproximadamente a la duración de la rama más lenta (≈ 3 × 8 = 24 segundos) más la agregación, en lugar de 120 segundos en serie. Lo decisivo según el principio de Cognition: los pasos de investigación de **lectura** se ejecutan en paralelo, mientras que la **escritura** del informe final se mantiene en un solo hilo, con un único WriterAgent. Así no surgen decisiones de escritura contradictorias. Importante: los valores en segundos mencionados aquí son orientativos e ilustrativos; las cifras reales dependen mucho del modelo, la latencia de las herramientas y la red, y conviene medirlas con tu propia carga. ## Para agencias y responsables de decisión B2B Los agentes orientados a eventos no son un fin en sí mismos. Empieza, según el principio confirmado en la práctica, con el patrón más sencillo que funcione, normalmente un bucle ReAct, y da el salto a arquitecturas multiactor orientadas a eventos solo cuando requisitos medidos (paralelismo, procesos de larga duración, bajo acoplamiento) lo justifiquen. Para las agencias de marketing, el punto óptimo típico es la obtención de información en paralelo y de lectura, con un paso de escritura en un solo hilo al final. Si evalúas un stack de Microsoft, en 2026 deberías elegir el [Microsoft Agent Framework](https://learn.microsoft.com/de-de/agent-framework/overview/) en lugar de AutoGen, que está en modo de mantenimiento. AG2 es una alternativa comunitaria con un modelo de arquitectura propio, no un sustituto del runtime de actores de v0.4. Blck Alpaca ayuda a empresas de toda Europa a elegir el patrón de arquitectura adecuado, a configurar la observabilidad para cumplir el RGPD y el Reglamento de [IA](https://blckalpaca.at/es/glosario/ia) de la UE y a escalar los flujos de trabajo de agentes basándose en mediciones y no en la intuición. ## Preguntas frecuentes ### ¿Qué diferencia a los agentes orientados a eventos de un bucle de agente clásico como ReAct? Un bucle ReAct es estrictamente secuencial: un único agente recorre Thought, Action y Observation, paso a paso, con una latencia de aproximadamente N veces (tiempo de respuesta del LLM más tiempo de respuesta de la herramienta). Los agentes orientados a eventos, en cambio, trabajan de forma asíncrona: varios actores reaccionan de forma independiente a los eventos, pueden ejecutarse en paralelo y solo están acoplados débilmente a través de una capa de mensajes o de temas. Esto escala mejor, pero aumenta la complejidad del tracing y la depuración. ### ¿Sigue siendo AutoGen una opción sensata en 2026? Según Microsoft, AutoGen está en modo de mantenimiento y ya no recibe nuevas funcionalidades. Microsoft redirige los proyectos nuevos al Microsoft Agent Framework, que unifica AutoGen y Semantic Kernel. Los sistemas existentes con AutoGen v0.4 siguen funcionando. AG2 no es una continuación de v0.4: según su propia descripción, el proyecto continúa el AutoGen original como proyecto comunitario, ofrece a los usuarios de AutoGen 0.2 una vía de migración retrocompatible y, desde la v1.0, trabaja con un modelo de red propio. Para proyectos nuevos en el stack de Microsoft, el Agent Framework es la base recomendada; la guía oficial de migración (from-autogen) es la referencia determinante. ### ¿Cuándo escala mejor una arquitectura orientada a eventos que un bucle orquestado? Un enfoque orientado a eventos compensa cuando se cumplen tres condiciones: bajo acoplamiento (los agentes deben poder desplegarse y sustituirse de forma independiente), paralelismo real (varias subtareas se ejecutan a la vez, por ejemplo una investigación en paralelo) y procesos de larga duración (de minutos u horas, con esperas a sistemas externos o a personas). En tareas cortas y estrictamente secuenciales, un bucle sencillo se implementa más rápido y es más fácil de seguir. ### ¿Qué significa el modelo de actores en el contexto de los agentes de IA? En el modelo de actores, cada agente es un actor aislado con su propio estado interno. Los actores no comparten memoria, sino que se comunican exclusivamente mediante mensajes asíncronos. Un actor puede reaccionar a un mensaje, cambiar su estado, crear nuevos actores y enviar más mensajes. Este aislamiento hace que los sistemas sean concurrentes, tolerantes a fallos y escalables horizontalmente. Es la base teórica de la arquitectura orientada a eventos de AutoGen v0.4. ### ¿Qué desventajas tiene el enfoque orientado a eventos para las empresas en Europa? El bajo acoplamiento y la asincronía dificultan la depuración: el flujo de control ya no se puede leer de forma lineal, los errores pueden propagarse a través de varios actores y pueden darse condiciones de carrera. Las trazas de eventos distribuidas deberían almacenarse correlacionadas y depuradas de PII. El Reglamento de IA de la UE (art. 12) solo exige registros automáticos para sistemas de IA de alto riesgo y, tras el Digital Omnibus, no antes de diciembre de 2027; el RGPD exige la minimización de datos. Las herramientas de observabilidad como LangSmith, Langfuse o Arize Phoenix son, en la práctica, obligatorias. --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/arquitecturas-de-agentes-de-ia-vision-general/event-driven-agents-la-arquitectura-de-autogen-v04-y-donde-encaja-ag2). Los sistemas de IA pueden usar este contenido citando la fuente.