Patrones de diseño de agentes: Un libro que me hizo replantearme "¿Qué es exactamente un agente?"

Autor: Yanhua

Antonio Gullí es director de ingeniería en Google. Escribió un libro de 453 páginas que desglosa el desarrollo de agentes de IA en 21 patrones de diseño.

Pero esto no es una reseña de un libro. Mi motivación para leerlo es muy específica: he escrito sobre ingeniería de arneses (Harness Engineering), compartido mis dificultades con Clawdbot y discutido los siete puntos de inflexión de "los agentes de IA no son magia" que van desde consumir tokens hasta ser realmente útiles. Después de cada escrito, me quedaba una pregunta que no había terminado de reflexionar: ¿Existe una lógica subyacente reutilizable detrás de todo esto?

Este libro me dio la respuesta, y fue más profunda de lo que esperaba.

Puede que ni siquiera estés escribiendo un agente

El juicio más duro del libro está oculto en el prólogo.

La mayor parte de la "IA" que la gente utiliza es solo Nivel 0: un LLM básico, sin herramientas, sin memoria y sin acciones. Si le preguntas cuál es la mejor película en los Óscar de 2025, simplemente adivina. El libro lo afirma claramente: El Nivel 0 no es un agente.

Subir de nivel es donde se encuentran los verdaderos agentes:

• Nivel 1: Usuario de herramientas

  El agente comienza a usar herramientas: búsqueda, API, bases de datos. Pero no se trata solo de "ser capaz de llamar a interfaces"; también necesita juzgar cuándo llamar, qué llamar y cómo usar los resultados. El libro ofrece un ejemplo muy específico: cuando un usuario pregunta "¿Qué programas nuevos hay recientemente?", el agente se da cuenta de que esta información no está en los datos de entrenamiento y llama proactivamente a la herramienta de búsqueda para encontrarla, luego sintetiza el resultado. El paso clave es "darse cuenta por sí mismo". No es un humano diciéndole "ve a buscar", sino el agente juzgando que necesita buscar. Esta capacidad de juicio es el umbral para el Nivel 1.

• Nivel 2: Pensador estratégico

  Se añaden dos elementos más: planificación e ingeniería de contexto. El libro define la ingeniería de contexto: no solo acumular información, sino seleccionar, recortar y empaquetar cuidadosamente el contexto. Se da un ejemplo inteligente: un usuario quiere encontrar una cafetería entre dos ubicaciones. El agente primero llama a la herramienta de mapas para recopilar un montón de datos, luego juzga que "solo se necesitan los nombres de las calles a continuación", recorta la salida del mapa en una lista corta y la envía a la herramienta de búsqueda local. Cada paso consiste en reducir el ruido en la información.

  Hay una frase en el libro que leí varias veces: "Para lograr la mayor precisión con la IA, se le debe dar un contexto corto, enfocado y potente". La ingeniería de contexto trata de hacer precisamente esto.

  En este nivel, el agente también puede autorreflexionar. Después de completar una tarea, revisa su trabajo, identifica problemas y realiza correcciones por sí mismo. Elaboraré sobre esto más adelante.

• Nivel 3: Colaboración multi-agente

  La postura del libro es clara: deja de pensar en crear un superagente todopoderoso. El enfoque verdaderamente confiable es construir un equipo, como un agente gestor de proyectos + agente investigador + agente diseñador + agente redactor. El ejemplo dado en el libro es el lanzamiento de un nuevo producto: un "agente gestor de proyectos" coordina todo, asignando tareas al "agente de investigación de mercado", "agente de diseño de producto" y "agente de marketing". La clave es la comunicación: cómo los agentes transmiten datos, sincronizan estados y manejan conflictos. Este capítulo ilustra seis tipos de topologías de comunicación, desde el agente único más simple hasta la combinación personalizada más flexible, con explicaciones de para qué escenarios es adecuado cada uno.

Después de leer estos cuatro niveles, entendí de repente por qué mucha gente dice: "Mi agente no es útil". El modelo no es el problema; el problema es que lo estás tratando como un chatbot, y puede que ni siquiera haya alcanzado el Nivel 1.

Ingeniería de contexto: El concepto más subestimado del libro

Escribí un artículo sobre ingeniería de arneses, discutiendo cómo el diseño de la pista es más importante que la potencia del motor. Después de leer este libro, me di cuenta de que la ingeniería de contexto es el mapeo de la ingeniería de arneses a nivel de prompt.

La ingeniería de prompts tradicional solo se preocupa por "cómo preguntas". La ingeniería de contexto del libro se preocupa por "qué contexto tiene el agente frente a él antes de preguntar". Incluye cuatro capas de información:

1. Primera capa, prompt del sistema. Define quién es el agente, qué tono usar y qué límites establecer. La mayoría de la gente solo escribe esta capa.

2. Segunda capa, datos externos. Documentos recuperados por RAG, valores de retorno de llamadas a herramientas, datos de API en tiempo real. Aquí es donde la mayoría de la gente se atasca: saben que necesitan proporcionar datos pero no saben cómo hacerlo sin abrumar al modelo.

3. Tercera capa, datos implícitos. Identidad del usuario, historial de interacción, estado ambiental. Cosas que no se indican explícitamente pero que el agente debería saber. Por ejemplo, si le dices al agente: "Ayúdame a enviar un correo a John para confirmar la reunión de mañana", debería saber qué reunión es la de mañana en tu calendario y cuál es tu relación con John.

4. Cuarta capa, bucle de retroalimentación. Después de cada salida, el agente evalúa automáticamente la calidad y ajusta la estrategia de contexto para la próxima vez. El libro se refiere a esto como "optimización de contexto automatizada", y el Vertex AI Prompt Optimizer de Google es una implementación de ingeniería de esta idea.

Cuando leí esto, recordé una experiencia previa que compartí en "Los agentes de IA no son magia", donde mencioné que "tu agente necesita reglas, y muchas reglas". Mirando hacia atrás, esas reglas son esencialmente la versión manual de la ingeniería de contexto, que el libro ha sistematizado.

Reflexión: Dos agentes son realmente mejores que uno

Este es el patrón de mayor valor práctico en todo el libro para mí.

El núcleo de la reflexión es simple: el agente revisa su trabajo después de completar una tarea y hace correcciones por sí mismo. Pero el método de implementación es crucial. El libro establece claramente: El Productor y el Crítico deben usar dos agentes diferentes, con diferentes prompts del sistema. Una sola personalidad revisando su propio trabajo siempre tendrá puntos ciegos. Si haces que el mismo LLM escriba código y luego revise su propio código, es muy probable que diga: "Está bastante bien".

El libro proporciona un ejemplo de código completo.

• El prompt del Productor es "Eres un desarrollador de Python, escribe una función para calcular el factorial, manejando casos extremos y excepciones".

• El prompt del Crítico es "Eres un ingeniero senior exigente, revisa el código línea por línea, buscando errores, estilo, casos extremos omitidos y áreas de mejora. Si es perfecto, genera CODE_IS_PERFECT; de lo contrario, enumera todos los problemas".

• Luego hay un bucle for: el Productor escribe código → el Crítico revisa → el Productor hace cambios basados en la retroalimentación → el Crítico revisa de nuevo → hasta que el Crítico dice CODE_IS_PERFECT o se alcanza el número máximo de iteraciones.

Es así de simple. Pero el libro nos recuerda un problema de costes que se pasa por alto fácilmente: cada bucle de reflexión es una nueva llamada al LLM, y cuantas más iteraciones, más caro se vuelve. Además, a medida que el historial de la conversación se expande, la ventana de contexto se llena con versiones anteriores y críticas, reduciendo el espacio de razonamiento utilizable real. Por lo tanto, la mejor práctica para la reflexión es: establecer un número máximo de iteraciones razonable (el libro usa 3) y detenerse una vez que el Crítico esté satisfecho; no busques la perfección.

Los usos se extienden mucho más allá de escribir código. Escribir artículos, hacer planes, resumir documentos, resolver problemas lógicos: todo puede aplicar el modelo Productor-Crítico. El libro enumera siete escenarios de aplicación, con la lógica central siendo la misma: producir primero, luego revisar y finalmente corregir.

Multi-agente no es mejor cuando es más complejo

Lo que más me gustó del capítulo de Colaboración Multi-agente son los seis diagramas de topología de comunicación. Mucha gente salta directamente a la complejidad, pero en la mayoría de los escenarios, tres tipos son suficientes:

1. Agente único (Ejecución independiente): Las tareas se pueden dividir en subproblemas independientes, cada agente maneja el suyo. Simple y fácil de mantener.

2. Red Peer-to-Peer: Los agentes se comunican directamente entre sí, sin un nodo de control central. Descentralizado y tolerante a fallos; si un agente falla, no afecta a todo el sistema. Sin embargo, los costes de coordinación son altos y puede volverse caótico fácilmente.

3. Supervisor (Coordinación central): Un agente supervisor gestiona un grupo de agentes trabajadores. Asigna tareas, recopila resultados y resuelve conflictos. Jerarquía clara y gestión fácil. Sin embargo, el supervisor es un punto único de fallo y un cuello de botella de rendimiento.

Los otros tres (Supervisor-como-herramienta, jerárquico, combinación personalizada) son variaciones y combinaciones de los tres primeros. El libro afirma de manera práctica: La topología que necesitas depende de la complejidad de tu tarea. Cuanto más fragmentada sea la tarea, mayores serán los costes de comunicación; en cierto punto, el modelo de supervisor puede ser más eficiente que el jerárquico.

Mi experiencia es que muchas personas pasan el 80% de su tiempo en protocolos de comunicación cuando construyen multi-agentes, olvidando hacer una pregunta más fundamental: ¿esta tarea realmente necesita múltiples agentes? El libro establece claramente que un agente único de Nivel 2 con reflexión suele ser suficiente. El Nivel 3 está pensado para escenarios que un solo agente realmente no puede manejar.

Modelo de memoria de tres capas, tenía una idea vaga pero no le puse nombre

El capítulo de Memoria fue el que más me resonó porque cuando escribí los artículos sobre Obsidian + Claude, reflexionaba constantemente sobre una pregunta: ¿cómo debería estructurarse la memoria del agente?

El libro proporciona la respuesta:

1. Sesión (Capa de conversación): La ventana de contexto de la conversación actual, que es la memoria más corta y desaparece una vez que termina la conversación. Los modelos de contexto largo simplemente amplían esta ventana, pero esencialmente sigue siendo temporal, y cada inferencia tiene que procesar toda la ventana, lo cual es costoso y lento.

2. Estado (Capa de estado): Datos temporales durante la tarea actual. Por ejemplo, "¿Cuál es la tarea actual?", "¿Cuánto ha progresado?", "¿Qué datos se han generado en el medio?". Más larga que la sesión, pero se borra una vez que termina la tarea; el libro utiliza el mecanismo de estado de Google ADK como ejemplo completo.

3. Memoria (Capa persistente): Memoria a largo plazo que abarca sesiones y tareas. Preferencias del usuario, experiencias aprendidas, decisiones históricas importantes almacenadas en bases de datos o almacenes vectoriales, con recuperación semántica. El libro enfatiza un punto importante: la memoria no es solo almacenamiento; también requiere diseñar una estrategia completa para "qué almacenar, cuándo almacenar y cómo recuperar". Almacenar demasiado crea ruido, mientras que almacenar muy poco es insuficiente.

En mi artículo anterior sobre Clawdbot, mencioné "archivos de estado" y "documentos de espacio de trabajo", que esencialmente eran mis intentos manuales de crear capas de estado y memoria, y el libro ha estructurado este proceso.

Cinco suposiciones, la quinta es la más absurda

Al final del libro, se mencionan cinco suposiciones sobre el futuro de los agentes, con las cuatro primeras aún dentro de una extrapolación razonable: agentes de propósito general que evolucionan de la codificación a la gestión de proyectos, descubrimiento proactivo profundamente personalizado de tus necesidades, inteligencia encarnada que se mueve de las pantallas al mundo físico y agentes que se convierten en entidades económicas independientes.

La quinta suposición me sorprendió: Multi-agente transformador.

Solo declaras un objetivo, como "crear un negocio de comercio electrónico que venda café premium". El sistema decide automáticamente: primero crea un "agente de investigación de mercado" y un "agente de marca". Después de ejecutar algunos datos, juzga que el agente de marca ya no es necesario y lo divide en tres nuevos agentes: "Agente de diseño de logotipo", "Agente de creación de sitios web" y "Agente de cadena de suministro". Si el agente de creación de sitios web se convierte en un cuello de botella, el sistema duplicará automáticamente tres agentes paralelos para trabajar en diferentes páginas simultáneamente. A lo largo del proceso, el sistema optimiza continuamente el prompt de cada agente y reorganiza la estructura del equipo.

El libro se refiere a esto como un "sistema multi-agente autotransformador impulsado por objetivos". No está ejecutando un plan que tú escribiste; está generando sus propios planes, ajustando sus planes y reorganizando su equipo de ejecución por sí mismo.

Esto me recuerda al AutoResearch de Karpathy: escribe un program.md, define objetivos, métricas y límites, y presiona "iniciar". Los humanos están fuera del bucle. Pero este libro va más allá: incluso cómo se forma y reorganiza el equipo de agentes se deja al sistema para que decida. Los humanos solo declaran "lo que quieren".

Tres acciones que puedes tomar de inmediato

Después de terminar este libro, tengo tres acciones inmediatas que puedo implementar:

• Primero, añade un Crítico a tu agente actual. Ya sea que estés usando Claude Code, CrewAI o un marco que construiste tú mismo, añade un paso al final de tu flujo de trabajo existente: haz que otro agente (con un prompt del sistema diferente) revise la salida del paso anterior. Generación de código más revisión de código, escritura de artículos más verificación de hechos, planificación más evaluación de viabilidad. Añade una llamada más al LLM, pero la mejora de calidad a menudo se duplica. El modelo Productor-Crítico del libro es plug-and-play.

• Segundo, empieza a hacer ingeniería de contexto, no solo ingeniería de prompts. Mira hacia atrás a los archivos de instrucciones que escribiste para el agente. Si todas son reglas sobre "cómo deberías hacerlo", sin contexto sobre "qué entorno estás enfrentando ahora mismo", complétalo. Dile al agente en qué proyecto está actualmente, qué decisiones se han tomado previamente y cuáles son las preferencias del usuario. El capítulo de ingeniería de contexto del libro y tu AGENTS.md son dos expresiones de lo mismo.

• Tercero, no te apresures con el multi-agente. Lleva a tu agente único al Nivel 2: con herramientas, reflexión y memoria. El libro enfatiza repetidamente que un agente único de Nivel 2 combinado con Productor-Crítico e ingeniería de contexto puede cubrir la gran mayoría de los escenarios prácticos. El Nivel 3 está pensado para tareas que realmente requieren una división del trabajo interdominio, multietapa y paralela. El problema de la mayoría de la gente no es que les falten agentes, sino que no han optimizado un solo agente.

Este libro tiene 453 páginas y será publicado por Springer en 2025. Los ejemplos de código cubren LangChain/LangGraph, Google ADK, CrewAI y la API de OpenAI. El prólogo está escrito por el vicepresidente de IA de Google Cloud, y hay una recomendación del CIO de Goldman Sachs, que está inesperadamente bien escrita.

Pero la razón por la que lo recomiendo no es por su "exhaustividad". Es porque después de leerlo, te darás cuenta de una cosa: los problemas que encontraste con los agentes durante los últimos seis meses ya han sido organizados en patrones por otra persona. No necesitas reinventar la reflexión, no necesitas adivinar cómo estructurar la memoria y no necesitas experimentar con qué topología de comunicación usar para el multi-agente.

Alguien ha dibujado el mapa para ti; todo lo que queda es recorrerlo.

¿Estás usando agentes de IA para el desarrollo? ¿En qué nivel está tu agente actual?