33 Agentes, herramientas y memoria
Dónde estamos. En el Cap. 31, el modelo recuperaba texto para responder mejor. Aquí damos el salto: convertirlo en un agente que actúa —usa herramientas, ejecuta código, navega— en un bucle para cumplir un objetivo en varios pasos. Veremos el bucle razonamiento-acción, el uso de herramientas, la planificación, la memoria… y, sobre todo, los límites y fallos —porque aquí el hype superó con creces a la fiabilidad real—.
33.1 La idea en una frase
Un agente es un LLM metido en un bucle que puede observar, razonar y actuar sobre el mundo (herramientas, APIs, código), repitiendo el ciclo hasta lograr la meta —pasando de “una boca que habla” a “manos y ojos con una lista de tareas”—.
🧩 Analogía — la boca, las manos y los ojos. El LLM “plano” solo tiene boca: produce texto y se acabó. Las herramientas le dan ojos (observar resultados) y manos (actuar), y el bucle le da una lista de pendientes que va tachando. Eso es un agente.
33.2 Conceptos clave y su papel en el transformer
Antes de entrar en detalle, definimos los términos de este capítulo y para qué sirve cada uno dentro de un transformer:
- Agente. Definición: un LLM metido en un bucle que observa, razona y actúa sobre el mundo. En el transformer: pasa de “generar texto” a actuar con efectos (herramientas, código, APIs).
- Bucle percibir→razonar→actuar→observar. Definición: el ciclo que se repite hasta lograr la meta o agotar el presupuesto. En el transformer: cierra el lazo con el mundo que la generación de un tiro no tiene.
- ReAct. Definición: intercalar Pensamiento, Acción y Observación. En el transformer: ancla el razonamiento en información externa real → menos alucinación.
- Herramientas / function calling. Definición: el LLM emite una llamada estructurada (nombre + argumentos JSON) que un runtime ejecuta. En el transformer: conecta con la decodificación restringida (Cap. 29) —el JSON debe ser válido—.
- Código como acción. Definición: generar y ejecutar código como espacio de acciones. En el transformer: preciso, componible, con bucles y librerías —un formato cubre muchas herramientas—.
- Planificación. Definición: descomponer una meta en sub-pasos antes de ejecutar. En el transformer: es el punto débil del LLM autónomo → a veces se delega en un planificador clásico.
- Memoria (episódica / semántica). Definición: un almacén externo de interacciones pasadas, más allá del contexto. En el transformer: el contexto es finito y volátil; la memoria es RAG sobre la propia historia del agente.
- Composición de errores. Definición: la fiabilidad de una cadena de \(n\) pasos cae \(\approx p^{n}\). En el transformer: explica por qué las tareas largas colapsan aunque cada paso sea bueno.
- Inyección de prompts. Definición: instrucciones maliciosas escondidas en datos recuperados. En el transformer: se agrava en un agente porque tiene manos (acciones con efectos).
Con esto en mente, abrimos el bucle.
33.3 Qué es un agente (y qué no)
Operativamente: un LLM situado en un bucle percibir → razonar → actuar → observar, que repite hasta cumplir el objetivo o agotar el presupuesto. Dos contrastes útiles:
- Vs. generación de un tiro: el LLM normal produce texto en una pasada y termina; no ejecuta nada ni cierra el lazo con el mundo.
- Vs. RAG (Cap. 31): RAG recupera contexto (lectura) para una respuesta; el agente actúa (lectura y efectos). De hecho, RAG es una “herramienta de búsqueda” dentro de un agente; el agente generaliza a cualquier acción.
(Honesto: no hay definición canónica única; “agente” se usa con laxitud. La convención de facto es “LLM + herramientas + bucle + memoria + planificación”.)
33.4 El bucle razonamiento-acción
La columna vertebral es ReAct (Yao et al. 2023) (lo asomamos en el Cap. 30): intercala Pensamiento (razonar), Acción (llamar una herramienta) y Observación (leer el resultado), en ciclo. El razonamiento decide la acción; la acción ancla el razonamiento en información externa real → menos alucinación que razonar a solas.
🧩 Analogía — pensar en voz alta, probar, mirar, repetir. ReAct es como alguien depurando código: formula una hipótesis (pensamiento), prueba un comando (acción), lee el error (observación) y ajusta. Un paso cada vez, mirando qué pasó.
Sobre eso, Reflexion (Shinn et al. 2023) añade auto-reflexión verbal: tras un fallo, el agente escribe en su memoria qué salió mal y lo usa en el reintento —un “refuerzo” por lenguaje, sin tocar los pesos—.
33.5 Usar herramientas
¿Cómo “actúa” un LLM? Emitiendo llamadas a herramientas:
- Toolformer (Schick et al. 2023): el modelo aprende de forma auto-supervisada cuándo y cómo llamar APIs (calculadora, búsqueda, calendario…), insertando las llamadas en el texto —se queda con las que mejoran su predicción—.
- Function calling: el modelo emite una llamada estructurada (nombre + argumentos JSON), el runtime la ejecuta y devuelve el resultado. Conecta con la decodificación restringida (Cap. 29): el JSON de la llamada debe ser válido. (Las interfaces modernas de “herramientas” y estándares como MCP exponen herramientas a los modelos de forma uniforme.)
- Código como acción: generar y ejecutar código es una herramienta poderosísima. PAL (Gao et al. 2023) delega el cómputo a un intérprete (evita los errores aritméticos del razonamiento en lenguaje); CodeAct (Wang et al. 2024) unifica todas las acciones en Python ejecutable. ¿Por qué el código? Es preciso, componible, tiene bucles y condicionales, reutiliza librerías, y un solo formato cubre muchas herramientas.
(Se mide con benchmarks* como ToolLLM (Qin et al. 2024) —16 000+ APIs reales— y API-Bank (M. Li et al. 2023).)*
33.6 Planificar
Para metas complejas, descomponer en sub-pasos:
- Plan-and-Solve (L. Wang et al. 2023): primero idear un plan (subtareas), luego ejecutarlo —ataca los pasos que el CoT zero-shot se salta—.
- ReWOO (Xu et al. 2023): genera todo el plan de antemano, sin intercalar observaciones → menos tokens que el estilo ReAct.
- LLM+P (Liu et al. 2023): el LLM traduce el problema a un formato formal (PDDL), un planificador clásico halla el plan óptimo, y se retraduce. Externaliza la planificación precisamente porque el LLM solo es flojo en ella.
La planificación autónoma a horizonte largo es frágil. En una investigación crítica (Valmeekam et al. 2023), GPT-4 generó planes ejecutables de forma autónoma con solo ~12 % de éxito en dominios de planificación estándar. Por eso enfoques como LLM+P delegan en un planificador clásico en vez de fiarse del modelo.
33.7 Memoria
La ventana de contexto no es memoria: es finita, volátil y desaparece al acabar la sesión. Por eso los agentes añaden memoria explícita:
- Corto plazo: el contexto / un scratchpad del razonamiento actual.
- Largo plazo: un almacén vectorial externo de interacciones pasadas (¡es RAG, Cap. 31, aplicado a la propia historia del agente!). Se distingue memoria episódica (qué pasó) de semántica (hechos destilados).
Dos arquitecturas canónicas: Generative Agents (Park et al. 2023) —un memory stream con recuperación por relevancia + recencia + importancia y reflexión periódica (las simulaciones “Smallville” de 25 agentes)— y MemGPT (Packer et al. 2023), que gestiona la memoria como un sistema operativo (paging de información dentro/fuera del contexto).
🧩 Analogía — el cuaderno. La memoria externa es un cuaderno donde el agente escribe y relee, porque no le cabe todo “en la cabeza” (el contexto). MemGPT es el cuaderno con un sistema de archivado; Generative Agents, el cuaderno con índice de relevancia y resúmenes.
33.8 Multi-agente (breve)
Varios agentes colaborando o debatiendo: CAMEL (G. Li et al. 2023) (juego de roles), AutoGen (Wu et al. 2023) (conversación entre agentes componibles), debate multi-agente (Du et al. 2023) (varias instancias debaten → mejor factualidad) y Voyager (G. Wang et al. 2023) (agente en Minecraft que acumula una biblioteca de habilidades). Los proyectos AutoGPT/BabyAGI (2023) popularizaron el bucle autónomo —más fenómeno/demo que resultado científico—.
33.9 Límites y modos de fallo (el corazón honesto)
Aquí está lo que las demos no enseñan.
Composición de errores. Si cada paso tiene probabilidad de éxito \(p\), una cadena de \(n\) pasos (idealizando que son independientes) acierta \(\approx p^{n}\):
\[ P(\text{éxito}) \approx p^{\,n} \]
Con \(p=0{,}95\) y \(n=20\) pasos → ~36 %; con \(n=50\) → ~8 %. La fiabilidad colapsa al alargar la cadena. (Es un modelo ilustrativo —los errores no son del todo independientes—, pero captura el fenómeno.)
🧩 Analogía — el teléfono escacharrado. Cada eslabón de la cadena falla con poca probabilidad, pero una cadena larga casi siempre se rompe por algún punto. Un agente de muchos pasos es esa cadena.
Y la evidencia empírica es sobria:
| Benchmark | Mejor agente | Humano |
|---|---|---|
| GAIA (Mialon et al. 2024) | GPT-4 + plugins 15 % | 92 % |
| WebArena (Zhou et al. 2024) | GPT-4 14,4 % | 78 % |
| τ-bench (pass^8) (Yao et al. 2024) | GPT-4o ~25 % | — |
El τ-bench (Yao et al. 2024) es revelador: mide pass^k (¿lo logra de forma consistente k veces?). GPT-4o ronda 61 % a la primera pero ~25 % si exiges 8 aciertos seguidos → inconsistencia brutal. (Las brechas entre modelos se ven en AgentBench (Liu et al. 2024).)
Otros fallos: llamadas a herramientas alucinadas o con JSON inválido; bucles infinitos; coste/latencia de muchas llamadas por tarea; y un punto clave de la crítica sobria (Kapoor et al. 2024): los benchmarks premian exactitud ignorando el coste, y a menudo un baseline simple iguala a un agente complejo a ~50× menos coste. Honestidad: el hype agéntico de 2023-2024 superó a la fiabilidad real.
La inyección de prompts (Cap. 30) se agrava enormemente aquí: instrucciones maliciosas escondidas en datos que el agente recupera (una web, un correo, un documento) pueden secuestrar su comportamiento —exfiltrar datos, ejecutar acciones no deseadas— (Greshake et al. 2023). La diferencia con un chatbot es que el agente tiene manos: la superficie de ataque crece con cada herramienta con efectos secundarios.
tafagent no orquesta agentes, pero un agente acumula contexto que crece a cada paso (historial, observaciones, memoria recuperada). Su γ y horizonte efectivo (Cap. 15-20) te dicen hasta dónde el modelo de verdad atiende ese historial: un horizonte corto explica por qué un agente “olvida” instrucciones del principio en cadenas largas —y cuánto KV te costará mantener esa historia—.
33.10 Resumen
- Agente = LLM en un bucle percibir→razonar→actuar→observar; va más allá de generar (RAG recupera, el agente actúa).
- Bucle: ReAct (Yao et al. 2023) (Pensamiento/Acción/Observación, menos alucinación); Reflexion (Shinn et al. 2023) (aprende de fallos por lenguaje).
- Herramientas: Toolformer (aprende a llamar APIs), function calling (JSON válido, Cap. 29), código como acción (PAL, CodeAct) — preciso y componible.
- Planificar: Plan-and-Solve, ReWOO, LLM+P (delega en planificador clásico). Honesto: planificación autónoma frágil (~12 % GPT-4 (Valmeekam et al. 2023)).
- Memoria: contexto ≠ memoria; almacén externo (RAG sobre la propia historia); Generative Agents, MemGPT.
- Límites (honesto): composición de errores (\(p^n\) colapsa); brecha demo↔︎producción (GAIA 15 % vs 92 %; τ-bench pass^8 ~25 %); coste; inyección de prompts amplificada por poder actuar. El hype 2023-24 superó la fiabilidad.
Siguiente (Capítulo 33): cerramos la Parte V saliendo del texto: transformers multimodales —ver imágenes (ViT), unir visión y lenguaje (CLIP), audio—.
33.11 Ejercicios
- Agente vs RAG. ¿En qué se diferencia “actuar” de “recuperar”? ¿Por qué RAG es un caso particular dentro de un agente?
- ReAct. Describe el ciclo Pensamiento/Acción/Observación. ¿Por qué reduce la alucinación frente a razonar a solas?
- Código como acción. Da dos razones por las que el código es un buen “espacio de acciones” para un agente.
- Composición de errores. Con pasos al 90 % de éxito, ¿qué fiabilidad esperas en una tarea de 10 pasos? ¿Qué dice eso de los agentes de horizonte largo?
- Demo vs producción. Cita una cifra de la brecha agente-vs-humano y explica qué mide pass^k.
- Seguridad. ¿Por qué la inyección de prompts es más peligrosa en un agente que en un chatbot?