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 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 procesar: ¿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.

Es posible que ni siquiera estés creando un agente

El juicio más duro del libro se esconde en el prólogo.

La mayor parte de la "IA" que la gente usa 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, adivina. El libro lo afirma claramente: El Nivel 0 no es un agente.

Subir de nivel es donde están 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 "poder 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 el contexto cuidadosamente. Se da un ejemplo ingenioso: 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 proporcionar un contexto breve, enfocado y potente". La ingeniería de contexto trata de lograr 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 multiagente

  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 a un "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 mezcla personalizada más flexible, con explicaciones de para qué escenarios es adecuado cada uno.

Después de leer estos cuatro niveles, de repente entendí 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 delante 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 alimentar 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 cuál es la reunión 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 automatizada de contexto", 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 realiza correcciones por sí mismo. Pero el método de implementación es crucial. El libro afirma claramente: El Productor y el Crítico deben usar dos agentes diferentes, con diferentes prompts de 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: "Es bastante bueno".

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 costos 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 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.

Multiagente no es mejor cuando es más complejo

Lo que más me gustó del capítulo de Colaboración Multiagente 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 entre pares (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 costos 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 fácil gestión. 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, mezcla 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 costos 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 al construir sistemas multiagente, 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á destinado a 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 resonó conmigo porque cuando escribí los artículos sobre Obsidian + Claude, constantemente me planteaba una pregunta: ¿cómo debería estructurarse la memoria del agente?

El libro da 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 proceso?". 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 sobre "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 enmarcado 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 primeras cuatro 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ó: Multiagente 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 procesar 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 multiagente 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 a la decisión del sistema. 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 de sistema diferente) revise la salida del paso anterior. Generación de código más revisión de código, redacción de artículos más verificación de hechos, planificación más evaluación de viabilidad. Añade una llamada al LLM más, pero la mejora de calidad a menudo se duplica. El modelo Productor-Crítico en el libro es plug-and-play.

• Segundo, comienza a hacer ingeniería de contexto, no solo ingeniería de prompts. Mira 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 en el libro y tu AGENTS.md son dos expresiones de lo mismo.

• Tercero, no te apresures con el multiagente. 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á destinado a 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 obstáculos 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 multiagente.

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?