Agentes de IA y uso de herramientas

Ganancias:

• Definir un agente como 'modelo + herramientas + bucle' y decidir cuándo es necesario
• Escribir la definición de la herramienta con nombre, descripción y esquema_entrada
• Monitoreo del flujo y manejo de errores de los bucles tool_use y tool_result

Hasta ahora, el modelo siempre ha hecho un trabajo: recibir entradas de texto, producir respuestas de texto. Pero el trabajo real a menudo requiere más que texto; realizar un cálculo, consultar una base de datos, llamar a una API, averiguar el tipo de cambio actual. La modelo no puede hacer estas cosas por sí misma, pero puede decidir cuándo es necesario hacerlas y pedirle a alguien que las haga. Esto es lo que el uso de herramientas le da al modelo, y esta es la base de los agentes de IA. En esta unidad, aprenderemos qué es un agente, cómo se define la herramienta y cómo funciona el bucle tool_use.

¿Qué es un agente? Modelo + Herramientas + Bucle

Un agente de IA consta de tres partes: el modelo (el cerebro que toma la decisión), las herramientas (las funciones que el modelo puede llamar: clima, consulta de base de datos, envío de correo electrónico) y el bucle (el bucle; el modelo llama a la herramienta, obtiene el resultado, decide nuevamente qué hacer, etc.).

Distinción crítica: una llamada de patrón único no es un agente. Agente es un proceso en el que el modelo avanza paso a paso, eligiendo en cada paso el siguiente movimiento en función del resultado de la herramienta. "Piensa como un humano, usa tus manos, mira el resultado, piénsalo de nuevo".

Un dato importante: el modelo por sí solo no hace funcionar el vehículo. El modelo simplemente dice "Quiero llamar a esta herramienta con estas entradas". Su aplicación (llamada arnés) ejecuta la herramienta y devuelve el resultado al modelo. Esto es vital para la seguridad: el modelo no toca directamente su sistema; Cada acción está bajo tu control.

Consejo: no intente resolver todos los problemas con el agente. Agente; aumenta el riesgo de retrasos, costes y errores. Pregunte primero: "¿Esto se resolverá con una sola llamada o con un flujo de trabajo fijo?" Si la respuesta es sí, no es necesario un agente. El agente es para tareas abiertas donde los pasos no se pueden conocer de antemano.

Definición de herramienta: nombre, descripción, esquema_entrada

Para introducir una herramienta en el modelo, se dan tres cosas:

• nombre: Identidad del vehículo, p.e. obtener_clima.
• descripción: Qué hace la herramienta y cuándo llamarla. Esta es el área más importante que permite al modelo elegir la herramienta adecuada en el momento adecuado. Escriba no sólo "qué hace", sino también "llamar cuándo".
• input_schema (esquema de entrada): esquema JSON que define qué parámetros espera la herramienta, en qué tipo.

# Definición del vehículo (conceptual — esquema JSON){ "name": "get_order_status", "description": "Recupera el estado de envío actual de un pedido. Llama cuando el usuario pregunta dónde está un número de pedido o cuándo llegará.", "input_schema": { "type": "object", "properties": { "order_no": {"type": "string", "description": "Número de pedido, por ejemplo, SP-1024"} }, "requerido": ["order_no"] }}

Reglas para una buena descripción de una herramienta: nombre claro y conciso, descripción con "cuándo usar", descripción de cada parámetro, poniendo los verdaderamente obligatorios en requeridos. Mantenga enfocado el número de vehículos; Decenas de modelos de vehículos similares sorprenden.

área

¿Qué hace?

buen ejemplo

mal ejemplo

nombre

Identificación del vehículo

orden_estado_getir

traer

descripción

Qué hace + cuándo llamar

"Devuelve el estado de la carga; llamar cuando el usuario pregunta dónde está el pedido"

"obtiene datos"

esquema_entrada

Tipo de parámetro y requisito

{order_no: cadena, anotada}

sin diagrama / sin descripción

herramienta_uso → herramienta_resultado Bucle

El ciclo funciona así, paso a paso:

1. Envía la pregunta del usuario + descripciones de herramientas al modelo.
2. El modelo responde directamente o genera un bloque tool_use: "llamar a order_durumu_getir con order_no=SP-1024".
3. Su aplicación realmente ejecuta la herramienta (consulta la base de datos).
4. Envía el resultado al modelo como resultado_herramienta.
5. Con este resultado, el modelo produce la respuesta final o llama a otra herramienta. El ciclo continúa hasta que el modelo dice "Ya terminé".

# Mensajes (conceptuales) del bucle del agente = [pregunta_usuario] while True: respuesta = model.uret(mensajes, herramientas=definiciones_herramientas) if respuesta.tur == "uso_herramienta": resultado = arnés.run(respuesta.nombre_herramienta, entradas.respuesta) # LA APLICACIÓN ejecuta mensajes += [respuesta, resultado_herramienta(resultado)] # devuelve resultado else: break # respuesta final; extremos del bucle

Los SDK modernos ofrecen ejecutores de herramientas que ejecutan este ciclo por usted; simplemente escribe las funciones de la herramienta. Pero eso es exactamente lo que está sucediendo detrás de escena.

Gestión de errores

Las herramientas pueden fallar: pedido no encontrado, tiempo de espera de API, entrada no válida. Si no puede ejecutar la herramienta, devuelva el error al modelo como un resultado_herramienta descriptivo ("error: número de pedido SP-9999 no encontrado") y el indicador de error. El modelo puede ver esto y explicárselo amablemente al usuario, o intentarlo de otra manera. No se trague el error y devuelva resultados vacíos; El modelo debe saber qué salió mal.

Descripción del vehículo débil/fuerte

Débil (sustantivo indefinido, sin "cuándo"):

nombre: "datos", descripción: "obtiene datos"# El modelo no sabe cuándo ni cómo llamar; O no llama en absoluto o llama incorrectamente.

Fuerte (nombre de red + cuándo + descripción del parámetro):

name: "musteri_bakiyesi_getir"description: "Devuelve el saldo de la cuenta actual de un cliente. Llama cuando el usuario solicita débito, crédito o saldo. NO realiza el pago."input_schema: {custeri_id: string ("Customer ID")}# El modelo llama en el momento adecuado, con los parámetros correctos, conociendo su límite.

Tres mini estuches

Caso 1: Agente innecesario. Un equipo creó el negocio de “resumir texto” con un agente multiherramienta; Cada resumen requiere 4 llamadas de modelo y 9 segundos. En realidad, el trabajo era un trabajo de una sola llamada. Cuando eliminamos el agente y lo redujimos a una sola llamada, el tiempo disminuyó a 1,5 segundos y el costo disminuyó a una cuarta parte. Lección: utilice el agente cuando sea realmente necesario.

Caso 2: Explicación débil, decisión equivocada. En un agente de soporte, el modelo llamó aleatoriamente a una herramienta oscura llamada fetch tanto en la pregunta de saldo como en la pregunta de envío. Cuando los vehículos se dividieron en balance_getir y cargo_durumu_getir y se agregaron explicaciones de "llamar cuando", la selección incorrecta de vehículos disminuyó de 18 a 1 en 50 ejemplos.

Caso 3: Error tragado. Un agente devolvía resultados vacíos cuando no se encontró el pedido; La modelo interpretó esto como "el pedido fue entregado" y engañó al cliente. Cuando el mensaje de error se escribe explícitamente en tool_result ("pedido no encontrado"), el modelo dice correctamente "No pude encontrar este número, ¿puedes comprobarlo?" empezó a decir.

Errores comunes

• Dejar todo en manos de un agente: si bien una llamada es suficiente, el agente añade costos y demoras.
• Descripción vaga del vehículo: el modelo no sabe cuándo llamar; elige mal.
• Pensar que el modelo hace funcionar el vehículo: El arnés hace funcionar el vehículo; el modelo solo quiere.
• Tragarse el error: el modelo debe saber qué salió mal; Proporcione el error como open tool_result.
• Demasiados vehículos similares: el modelo se confunde; Mantenga el conjunto de herramientas enfocado y mínimo.

Atención: El hecho de que el modelo diga "llamar a ese vehículo" no significa que se deban tomar medidas. En el caso de herramientas destructivas (eliminar, pagar, enviar por correo electrónico), su aplicación no debe ejecutar la llamada a ciegas; este es el núcleo del tema de seguridad en la siguiente unidad.

En resumen

• Agente = modelo (decisión) + herramientas (funciones) + bucle (llamar a la herramienta, obtener resultado, decidir nuevamente).
• Una llamada de patrón único no es un agente; agente es un proceso paso a paso.
• El modelo no hace funcionar el vehículo; Su aplicación se ejecuta (aprovecha) y devuelve el resultado como resultado_herramienta.
• La herramienta se identifica por nombre, descripción (específicamente "llamar cuando") y esquema_entrada.
• El bucle continúa como uso_herramienta → ejecuciones de arnés → resultado_herramienta → modelo continúa hasta que el modelo dice "hecho"; Los errores se informan explícitamente al modelo.

Tarea de aplicación

Diseña 3 herramientas de tu propio negocio que se pueden entregar al agente. (1) Escriba el nombre, la descripción con "llamar cuando" y el esquema de entrada para cada uno; Que al menos uno sea una herramienta de lectura no destructiva y el otro un cálculo. (2) Elija una pregunta de usuario realista y escriba manualmente paso a paso (en un bucle) a cuál de estas herramientas llamará el modelo, con qué entradas y qué hará después de que llegue el resultado_herramienta. (3) Configure un escenario en el que una de las herramientas falla y muestre cómo el mensaje de error volverá al modelo.

lista de verificación

• [] Puedo definir el agente como "modelo + herramientas + bucle" y decidir cuándo es necesario.
• [ ] Sé que el arnés hace funcionar el vehículo, el modelo simplemente lo quiere.
• Puedo escribir una descripción sólida del vehículo con [] nombre, descripción ("llamar cuando") y input_schema.
• Puedo seguir el ciclo [] tool_use → tool_result paso a paso.
• [] Reporto errores de herramientas al modelo como resultado_herramienta abierto.