Pregúntele a un chatbot sobre un pedido retrasado y le dará algunos consejos. Pregúntele a un agente de AI y podrá buscar el pedido, comprobar el retraso, aplicar un vale e informar. La diferencia es que un agente puede tomar acciones y reaccionar ante lo que sucede, en lugar de producir una sola respuesta.

El término se extiende en marketing, por lo que esta guía se centra en cómo funcionan realmente estos sistemas. Para hacerlo concreto, creamos un pequeño bucle de agente en Python 3.13 y lo ejecutamos, y el resultado a continuación proviene de esas ejecuciones. Nuestro “modelo” es una función programada, no un modelo de IA real, por lo que cualquier persona puede ejecutar y probar el bucle. Muestra la estructura de control, no la inteligencia. ¿Nuevo en lo básico? Lea primero qué es un modelo de lenguaje grande.

¿Qué es un agente de IA?

No existe una definición única acordada. En la práctica actual, un agente de IA es un software que persigue un objetivo decidiendo repetidamente qué hacer a continuación, utilizando herramientas para actuar en el mundo y ajustándolo en función de los resultados. Por lo general, la toma de decisiones proviene de un modelo de lenguaje grande.

Piense en la diferencia entre una persona que da instrucciones y una persona que hace el recado. El primero responde una vez. El segundo sale, encuentra la tienda cerrada, prueba en otra y sólo regresa cuando el trabajo está terminado.

¿Chatbot, flujo de trabajo o agente?

Estos existen en un espectro y muchos sistemas útiles son una combinación. La pregunta clave es qué parte del camino se decide en tiempo de ejecución.

¿Qué hay dentro de un agente?

El bucle del agente

1. Decidir. El modelo analiza el objetivo y el historial, elige una acción o decide que está terminada.
2. Act. Su código ejecuta la herramienta solicitada.
3. Observar. El resultado se agrega al historial.
4. Repetir, hasta alcanzar el objetivo o alcanzar un límite.

Ese es el núcleo de la mayoría de los agentes. La sofisticación reside principalmente en el modelo, las herramientas y las salvaguardias en torno a este circuito.

Un bucle que puedes ejecutar

Nuestro pequeño agente se encarga de los pedidos retrasados. Tiene dos herramientas y una de ellas necesita aprobación humana porque cuesta dinero:

ORDERS = {
    "A100": {"status": "delayed", "days_late": 6},
    "B200": {"status": "shipped", "days_late": 0},
}

def get_order(order_id):
    return ORDERS.get(order_id, {"error": "order not found"})

def issue_voucher(order_id, amount):
    return {"voucher": f"V-{order_id}", "amount": amount}

TOOLS = {"get_order": get_order, "issue_voucher": issue_voucher}
NEEDS_APPROVAL = {"issue_voucher"}

Y aquí está el bucle en sí. Es un código ordinario y todas las reglas de seguridad se encuentran aquí y no en el modelo:

def run_agent(goal, model, approve, max_steps=5):
    history = []
    for step in range(1, max_steps + 1):
        decision = model(goal, history)
        if "finish" in decision:
            return decision["finish"]

        name, args = decision["tool"], decision["args"]
        if name in NEEDS_APPROVAL and not approve(name, args):
            result = {"denied": True}
        else:
            result = TOOLS[name](**args)

        history.append({"tool": name, "result": result})
    return None   # stopped: step limit reached

Para usar un modelo real, reemplazaría la función model con una llamada a una API LLM, pasándole el objetivo, el historial y las descripciones de sus herramientas. El bucle sigue siendo casi el mismo.

¿Qué pasó en nuestras carreras?

Probamos cinco situaciones con la función de decisión programada y registramos cada paso.

Un pedido retrasado, con el bono aprobado

step 1: get_order({'order_id': 'A100'}) -> {'status': 'delayed', 'days_late': 6}
step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'voucher': 'V-A100', 'amount': 200}
step 3: finish -> Sorry for the delay. Voucher V-A100 issued.

Cada paso utilizó el resultado del anterior. El bono sólo fue considerado una vez confirmado el retraso.

La misma orden, con aprobación denegada.

step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'denied': True}
step 3: finish -> Your order is late. A person will review compensation.

El humano dijo que no, la herramienta nunca se ejecutó y el agente adaptó su respuesta.

Un orden desconocido

step 1: get_order({'order_id': 'Z999'}) -> {'error': 'order not found'}
step 2: finish -> I could not find that order.

Proporcionar a las herramientas mensajes de error claros ayuda. Un modelo real puede leerlos y responder con sensatez, en lugar de adivinar.

Un modelo que se estanca

También intercambiamos una función de decisión defectuosa que repetía la misma acción para siempre:

step 1: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 2: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 3: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
stopped: step limit reached

Los agentes realmente pueden caer en bucles como este, y cada paso con un modelo real cuesta dinero. Sin max_steps, este nunca habría terminado.

Cómo funcionan las herramientas

Esta es la parte más incomprendida. Un modelo de lenguaje no puede ejecutar nada por sí solo. Produce un texto estructurado que dice qué herramienta quiere y con qué argumentos. Tu código decide si ejecutarlo. Por eso el bucle es el lugar adecuado para permisos, validación y registro.

Los proveedores de modelos ofrecen herramientas o funciones que lo requieren. El Model Context Protocol (MCP) es un estándar abierto para conectar modelos a herramientas y datos, y nuestro artículo sobre Playwright MCP muestra un uso. Escriba nombres y descripciones claros de las herramientas, porque el modelo depende de ellos para elegir correctamente.

Memoria

Las tareas largas pueden superar la ventana de contexto de un modelo, por lo que los sistemas suelen resumir pasos más antiguos. Los resúmenes pueden perder detalles, lo cual es una de las razones por las que los agentes de larga trayectoria pueden desviarse del rumbo.

Sistemas multiagente

Algunos sistemas dividen el trabajo entre varios agentes especializados, como un planificador, un investigador y un revisor. Esto puede ayudar con tareas grandes que se dividen claramente. También agrega costos, más formas de fallar y una depuración más difícil. Pruebe primero con un solo agente con buenas herramientas y divídalo solo cuando haya una razón clara.

Riesgos y límites

• Acciones incorrectas. El error de un chatbot es una mala sentencia. El error de un agente puede ser un correo electrónico enviado o un registro eliminado.
• Inyección rápida. Una página web o un correo electrónico que lee el agente podría contener instrucciones ocultas. Trate todos los resultados de la herramienta como datos que no son de confianza, no como comandos.
• Errores agravantes. Un pequeño error al principio puede enviar cada paso posterior en la dirección equivocada.
• Costo y latencia. Cada paso puede ser otra llamada de modelo, por lo que una tarea puede ser mucho más lenta y costosa que un solo mensaje.
• Inconsistencia. El mismo objetivo puede tomar un camino diferente en cada ejecución, lo que dificulta las pruebas.
• Responsabilidad. Las personas siguen siendo responsables de lo que hace el sistema, así que mantenga registros.

Barandillas que importan

1. Mínimo privilegio. Proporcione a cada agente solo las herramientas y el acceso que necesita.
2. Aprobación humana para cualquier cosa costosa, irreversible o externa, como lo hace nuestra demostración.
3. Límites estrictos en cuanto a pasos, tiempo y gastos.
4. Valide las entradas de la herramienta en el código y no dependa de las instrucciones del modelo.
5. Registra cada paso para que puedas ver por qué sucedió algo. Consulte monitoreo versus observabilidad.
6. Prueba con escenarios reales, incluidos fallos. Verifique los resultados finales y las respuestas individuales. Nuestra guía de mejores prácticas para agentes de IA va más allá de la implementación.

Cuando usar un agente

Los asistentes de codificación son uno de los ejemplos más maduros en la actualidad, ya que pueden leer archivos, ejecutar pruebas, ver fallas y volver a intentarlo, con un humano revisando el resultado. Un conjunto de pruebas les da una clara señal de éxito. Nuestra guía para la ingeniería rápida también se aplica a la redacción de buenas instrucciones para los agentes. Comience con lo más simple que pueda funcionar, porque una sola llamada bien solicitada a menudo supera a un agente complicado.

Conclusión

Un agente de IA es menos misterioso de lo que parece: un modelo, algunas herramientas y un bucle con límites. La parte difícil es la confianza, no el código. Para saber cómo se comportan, tome nuestro pequeño bucle, conéctelo a un modelo real con herramientas de solo lectura y observe los registros mientras funciona. Pronto verás dónde brilla y dónde necesita un humano.

Preguntas frecuentes

sigue aprendiendo