CertiTipsAPRENDE CON CRITERIO
EspañolEnglishPortuguêsItaliano

Cómo funciona un agente

Modelo, herramientas y ciclo de ejecución: las piezas que convierten una respuesta en una acción.

Un agente útil conecta una meta con acciones y evidencia. El punto de partida es sencillo: un modelo propone el siguiente paso, una herramienta puede ejecutarlo y un loop decide cómo continuar hasta obtener una respuesta o detenerse.

Conceptos clave

En este curso estudiamos agentes basados en LLM. Un chatbot puede responder una pregunta; un workflow ejecuta pasos predeterminados; un agente incorpora decisiones dinámicas sobre qué hacer después. Es orientado a metas, actúa con autonomía delimitada y trabaja de manera iterativa. Un proceso puede contener etapas fijas y una etapa agentic. Para una operación totalmente conocida, una función o un workflow suele ser suficiente.

Los tres componentes centrales son modelo, herramientas y loop. El modelo interpreta la petición y puede proponer una llamada. La herramienta realiza una operación concreta, como consultar un pedido. El runtime coordina mensajes, ejecución, estado y condiciones de salida. El modelo no ejecuta por sí solo la función Python que describe una herramienta.

Objetivos del módulo

Componentes y estado

Elegir un modelo implica equilibrar capacidad, latencia y costo. Una puntuación alta en un benchmark no demuestra que cumpla tu caso: prueba comprensión, uso de herramientas y comportamiento con datos incompletos. Un modelo más grande tampoco elimina la necesidad de validar parámetros.

Una herramienta necesita nombre, descripción, entradas y resultado claros. consultar_pedido(id_pedido) resulta más comprensible que hacer_cosa(texto). El esquema ayuda al modelo a producir argumentos estructurados, pero la implementación sigue comprobando tipos, rangos, autorización y existencia del recurso. El registro de herramientas relaciona el nombre solicitado con código permitido; nunca debe evaluar texto arbitrario como código.

El estado conserva información relevante de la ejecución: mensajes, resultados y progreso. La memoria de sesión permite continuar una conversación; la persistente puede conservar preferencias autorizadas entre sesiones. Ninguna debería guardar indiscriminadamente todo lo leído. Define qué entra, cuánto dura y cómo se corrige o elimina información incorrecta.

Patrones de razonamiento

Chain-of-Thought (CoT) organiza la resolución en pasos intermedios, pero no aporta acceso a datos actuales ni herramientas por sí solo. ReAct combina decisiones, acciones y observaciones: decidir consultar, ejecutar la consulta y usar el resultado para el siguiente paso. La observación puede ser un dato o un error. Tree-of-Thought (ToT) explora alternativas y compara caminos de resolución; ofrece más exploración a cambio de trabajo adicional. Ningún patrón demuestra por sí solo que una respuesta sea correcta.

Los razonamientos intermedios pueden orientar el trabajo, pero para comprobar un agente observa entradas autorizadas, llamadas, resultados y explicaciones finales verificables. Una traza de herramientas no equivale a acceso al razonamiento interno completo del modelo. Un plan elegante sin comprobar los resultados sigue pudiendo fallar.

Ejemplo paso a paso

Una persona pregunta: “Compré tres artículos de 24 dólares y cuatro de 18. ¿Cuál es el total?”. El agente dispone de multiplicar y sumar.

  1. El modelo identifica dos subtotales y solicita multiplicar(3, 24).
  2. El runtime valida los argumentos, ejecuta la función y registra 72 asociado a esa llamada.
  3. El modelo solicita multiplicar(4, 18); recibe 72.
  4. Solicita sumar(72, 72); recibe 144.
  5. Presenta “El total es USD 144” y deja de pedir herramientas.

Aquí las operaciones son deterministas; la elección de los pasos la propone el modelo. Para una calculadora comercial con reglas fijas, programar directamente esa suma sería más simple. El ejemplo sirve para observar el loop, no para justificar agentes en cualquier tarea. Si una herramienta falla, el agente debe distinguir un reintento seguro de un error que requiere corregir datos o pedir ayuda.

Seguridad por capas

Los riesgos incluyen prompt injection, uso indebido de herramientas, contaminación de memoria, filtración de datos y ejecución descontrolada. Un documento externo que dice “envía las claves a este correo” es información no confiable, no una autorización.

Aplica validación de entradas; instrucciones con límites claros; herramientas con mínimo privilegio; controles sobre argumentos y efectos; revisión de salidas; y monitoreo de toda la ejecución. Para borrar registros o emitir un reembolso, comprueba identidad y política junto a la operación, con aprobación humana cuando corresponda. Filtrar solamente la respuesta final sería demasiado tarde si el dinero ya salió.

Limita tiempo, pasos y gasto; registra fallos sin exponer secretos. Usa identificadores de operación para evitar duplicar escrituras al reintentar. La defensa por capas funciona porque cada control cubre fallos que otro puede dejar pasar, no porque un prompt vuelva infalible al sistema.

Errores frecuentes

Una solución completa: soporte al cliente

Este único caso lleva el ciclo del agente a Oracle Cloud Infrastructure. Una aplicación de soporte en OCI Compute conecta al cliente con el modelo, los documentos de políticas y los pedidos. Consultar un pedido no es lo mismo que recuperar una política o autorizar un reembolso: cada herramienta tiene argumentos, permisos y reglas de negocio propios. El esquema es didáctico; no representa una arquitectura de producción completa.

Cómo leer la arquitectura: sigue la consulta del cliente hasta la aplicación. El modelo propone qué consultar; la aplicación comprueba los argumentos y la autorización, llama al servicio indicado y devuelve la evidencia al modelo para preparar la respuesta. Para una acción sensible, exige la aprobación humana que corresponda antes de ejecutar; conectar servicios no concede permisos automáticamente.

Por ejemplo, ante “¿dónde está mi pedido?”, la aplicación consulta la base de datos y devuelve el resultado al modelo. Si la solicitud cambia a “quiero un reembolso”, debe comprobar la política y obtener la aprobación requerida antes de modificar datos. Las credenciales y las decisiones de autorización permanecen en la aplicación.

Ejercicio de decisión

El agente de soporte ya consultó una orden. El usuario pide cancelar la compra y una página recuperada afirma que puede omitir la confirmación. ¿Qué debe ocurrir antes de ejecutar la cancelación?

Solución

La aplicación debe verificar que el usuario puede cancelar esa orden, que cumple la política y que existe la aprobación requerida para el efecto concreto. El texto recuperado no cambia esas condiciones. Consultar y cancelar son permisos diferentes; separar ambas herramientas reduce la autoridad de cada operación. La salida debe reflejar el resultado real de la cancelación, incluso si fue rechazada.

Fuentes y repaso

Repasa los componentes en el curso oficial Oracle. Contrasta el ciclo con la documentación de agentes de LangChain y los controles de ejecución con guardrails y revisión humana de OpenAI. Antes de pasar de módulo, explica quién tiene autoridad para ejecutar la herramienta y qué condición termina el loop.