Capítulo 4 — Agentes de IA y llamada a herramientas

Cuarta entrega del recorrido capítulo por capítulo de LLM Primer V: Building Real-World LLM Applications. El capítulo que trata a un agente como un modelo de lenguaje en bucle contra herramientas cuyos esquemas, capas de memoria y cableado multi-agente hay que diseñar antes de poder confiar el bucle a nada real.

Por qué existe este capítulo

Un modelo sin estado que solo recibe texto y emite texto es una calculadora. El trabajo de producción exige convertirlo en un actor que persigue objetivos a lo largo de varios pasos — llama esta herramienta, después aquella, decide cuál de los resultados resumir para el usuario y detente cuando la tarea esté hecha. El movimiento parece sencillo en un diagrama y no lo es en la realidad. Los agentes vagan, entran en bucles, llaman a la herramienta equivocada, inventan argumentos que la herramienta no puede aceptar, olvidan lo que ya han traído y actúan fuera de su autoridad. El Capítulo 4 trata de la ingeniería que mantiene el bucle legible y acotado — los esquemas, la disciplina de memoria y la estructura multi-agente que convierten una demo de aspecto plausible en un actor de producción.

4.1 Las arquitecturas de agente como composición, no como selección

El bucle base es ReAct: razona sobre la situación, actúa llamando a una herramienta, observa el resultado y repite hasta que el objetivo se cumple o el presupuesto de pasos se agota. Los sistemas de producción componen tres aumentaciones encima del base en lugar de elegir entre ellas. La llamada nativa a funciones — el proveedor restringe los argumentos de la herramienta contra un JSON Schema en tiempo de decodificación — endurece el contrato de I/O de modo que el bucle ya no tiene que recuperarse de llamadas malformadas. La planificación explícita, al estilo Plan-and-Execute, adelanta un plan para tareas de horizonte largo y solo reejecuta el planificador cuando el mundo cambia. La orquestación por flujo codifica las transiciones conocidas de la tarea como un grafo y deja solo las decisiones intra-fase al modelo, que es la forma sobre la que converge la mayoría de despliegues empresariales porque separa lo que se sabe de lo que necesita juicio. Los bucles de reflexión, el enrutado multi-modelo a través de una flota escalonada por coste y los sub-agentes especialistas se sitúan al lado como aumentaciones adicionales.

4.2 Mecánica de la llamada a herramientas — el esquema es el contrato

Cada herramienta tiene un esquema, y el esquema es el contrato que el bucle impone al modelo. Las descripciones a nivel de propiedad son documentación para el modelo, no para el lector humano; los enums cierran el espacio de argumentos donde el dominio lo permite; las idempotency keys permiten al bucle reintentar una llamada a herramienta sin duplicar su efecto; los errores estructurados reintentables permiten al modelo recuperarse limpiamente en lugar de adivinar. Las herramientas deben ser mínimas — un trabajo claro por herramienta — porque una herramienta gorda con diez flags opcionales es una herramienta que el modelo se equivocará al invocar. Una herramienta ask_user pertenece al catálogo de forma explícita, para que el agente tenga una vía legítima de escalar la ambigüedad en lugar de inventar argumentos. La concurrencia solo es segura cuando las herramientas declaran independencia; el bucle trata las herramientas declaradas independientes como paralelizables y todo lo demás como estrictamente secuencial. Cada incidente real de producción rastreado hasta "el agente hizo lo equivocado" se resuelve en una herramienta cuyo esquema no dejaba claro qué significaban sus argumentos.

4.3 Tres capas de memoria: a corto plazo, a largo plazo, semántica

Los agentes necesitan memoria porque una tarea rara vez cabe en un turno. La memoria a corto plazo es una ventana deslizante sobre la conversación reciente con mensajes fijados que sobreviven al deslizamiento — el system prompt, el objetivo actual, el plan en curso — y resumen periódico de las tandas que caen fuera de la ventana. La memoria a largo plazo es un almacén vectorial de hechos curados escritos al confirmar, no a cada observación, y recuperados en varios puntos del bucle, no solo al comienzo. La memoria semántica es un grafo de conocimiento de triples para las consultas que necesitan composición estructurada en lugar de similitud — "quién reporta a quién", "qué productos pertenecen a qué categoría", relaciones que el almacén vectorial aplana. Las tres se guardan distinto porque se usan distinto, y la disciplina es enrutar escrituras y lecturas a la capa correcta en lugar de colapsarlo todo en un único índice de embeddings.

Lo que prepara el Capítulo 4

Los agentes y RAG producen ambos trazas estocásticas. El usuario se queja, el log muestra cien spans a lo largo de tres herramientas y ocho llamadas al modelo, y el equipo tiene que decidir si el fallo es una regresión de recuperación, una deriva de prompt, un problema de esquema de herramienta o el agente eligiendo correctamente contra un sistema aguas abajo que está roto. Esa pregunta no puede responderse sin una disciplina para convertir trazas en señales medibles de pasa/no pasa. El Capítulo 5 es esa disciplina — LLM-as-judge, el RAG Triad, tests de trayectoria para agentes y el bucle continuo donde las trazas de producción alimentan el conjunto de evaluación que da paso a la siguiente release.

Próximamente — Capítulo 5: Evaluar aplicaciones LLM. La disciplina de evaluación que convierte trazas estocásticas en señales de pasa/no pasa contra las que un equipo puede desplegar.