También puedes ver que esto se denomina llamada de herramientas o llamada de funciones. Los nombres suelen referirse al mismo mecanismo. Sin embargo, algunas plataformas utilizan herramientas como una categoría más amplia que incluye búsqueda alojada, ejecución de código, recuperación de archivos o control del ordenador, además de las funciones definidas por los desarrolladores.
El modelo mental útil
Piensa en el modelo como quien realiza la llamada, no como la máquina que ejecuta el trabajo.
El modelo puede producir una solicitud estructurada como «llamar a get_order_status con el ID de pedido 4821». Esa salida sigue siendo una respuesta del modelo. Por sí sola, no consulta una base de datos.
Una aplicación circundante recibe la solicitud y controla lo que ocurre después. Puede rechazar la llamada, pedir al usuario que la confirme, comprobar permisos, ejecutar código o devolver un error. Si ejecuta la herramienta, devuelve el resultado al modelo como contexto nuevo. Entonces el modelo puede explicar el resultado o solicitar otra herramienta.
Esa separación es el hecho central del uso de herramientas:
User request
↓
Model selects a tool and proposes inputs
↓
Application validates, authorizes, and executes
↓
Tool result returns to the model
↓
Model answers or requests another toolAlgunos proveedores también ofrecen herramientas alojadas que ejecutan en sus propios servidores. La API puede ocultar parte del ciclo, pero las etapas lógicas siguen siendo las mismas: el modelo solicita una operación, un sistema de ejecución la lleva a cabo y el resultado entra en la conversación.
Cómo funciona el uso de herramientas
1. La aplicación describe cada herramienta
Una definición de herramienta normalmente incluye:
- un nombre, como
get_order_status - una descripción en lenguaje natural de cuándo utilizarla
- las entradas que acepta
- reglas para la forma y el tipo de cada entrada
Estas reglas de entrada suelen expresarse mediante un esquema JSON. El esquema podría indicar que order_id es una cadena obligatoria. La descripción explica al modelo qué significa la herramienta; el esquema le indica cómo dar formato a una llamada.
2. El modelo recibe la solicitud y las definiciones de las herramientas
El modelo considera el mensaje del usuario junto con las descripciones de las herramientas disponibles. Puede responder normalmente, solicitar una herramienta o solicitar varias cuando la API y la aplicación lo permiten.
La selección de herramientas es una predicción, no un plan garantizado. Un modelo puede elegir la herramienta equivocada, omitir una llamada necesaria o proponer un argumento bien formado pero inapropiado.
3. El modelo devuelve una llamada de herramienta estructurada
En lugar de —o junto con— prosa normal, la respuesta contiene una llamada legible por máquina. Una versión simplificada podría verse así:
{
"name": "get_order_status",
"arguments": {
"order_id": "4821"
}
}Las API de los proveedores codifican esto mediante distintos tipos de mensajes y adjuntan un identificador para que el resultado posterior pueda asociarse con la llamada correcta. El envoltorio exacto cambia, pero la idea del nombre y las entradas es coherente entre las principales API.
4. La aplicación decide si ejecutarla
Aquí es donde una acción propuesta se convierte en una acción real —o no.
La aplicación analiza los argumentos y los comprueba con algo más que el esquema. Puede verificar el usuario que ha iniciado sesión, aplicar reglas de acceso, limitar valores, exigir aprobación para un efecto secundario o rechazar una herramienta que no esté disponible. Solo entonces un ejecutor de herramientas llama a la base de datos, API, calculadora, sistema de archivos u otro sistema.
Un esquema estricto puede mejorar la fiabilidad estructural, pero no es un sistema de autorización. "order_id": "4821" puede ser JSON válido y aun así referirse al pedido de otra persona.
5. El resultado de la herramienta vuelve al modelo
La aplicación envía la salida en un mensaje de resultado vinculado a la llamada original. La salida puede contener datos, un error o una indicación de que se denegó el permiso.
El modelo utiliza ese resultado como contexto adicional. Puede producir una respuesta final, corregir una suposición anterior o realizar otra llamada de herramienta. Un agente de IA de varios pasos puede repetir este ciclo hasta alcanzar una condición de parada.
Ejemplo práctico: comprobar un pedido
Supón que una tienda expone una herramienta de solo lectura:
Name: get_order_status
Purpose: Return shipping information for an order the current user owns
Input: order_id (required string)El usuario pregunta:
¿Dónde está el pedido 4821?
El modelo solicita:
{
"name": "get_order_status",
"arguments": {
"order_id": "4821"
}
}Antes de consultar nada, la aplicación comprueba la sesión actual. Si el usuario es propietario del pedido 4821, ejecuta la consulta y devuelve:
{
"status": "shipped",
"estimated_delivery": "Friday"
}Ahora el modelo puede responder: «El pedido 4821 se ha enviado y se estima que llegará el viernes».
Si la comprobación de propiedad falla, la aplicación no debería ejecutar la consulta ni revelar el estado. Puede devolver un error de permisos, que el modelo puede explicar sin exponer datos privados.
Nada en la llamada del modelo demostró la propiedad. El esquema de la herramienta describía una solicitud válida; la aplicación aplicó la regla real.
Por qué es importante el uso de herramientas
El uso de herramientas proporciona a un modelo de lenguaje acceso controlado a capacidades que la generación de texto por sí sola no ofrece.
- Datos actuales o privados: Una herramienta puede recuperar información actual o datos que nunca estuvieron en el material de entrenamiento del modelo.
- Operaciones exactas: Una calculadora, una consulta a una base de datos o un programa pueden realizar trabajos que no deberían depender de una estimación verosímil.
- Acciones reales: Las herramientas pueden crear registros, enviar mensajes, programar eventos u operar otro software.
- Sistemas existentes: Una herramienta puede convertir una solicitud en lenguaje natural en una llamada a una API empresarial existente.
- Trabajo de varios pasos: El resultado de una llamada puede orientar la siguiente.
El uso de herramientas no elimina las limitaciones del modelo. Traslada algunas tareas a sistemas más adecuados para ellas y crea una interfaz entre decisiones probabilísticas y software determinista.
La fiabilidad y la seguridad dependen del sistema circundante
El modelo no es una fuente fiable de comandos simplemente porque su salida coincida con un esquema. El uso de herramientas en producción requiere controles alrededor del modelo.
Valida el significado, no solo la forma. Comprueba identificadores, rangos, estados requeridos y reglas de negocio. La validación estructural no puede determinar si una transacción propuesta coincide con la solicitud del usuario.
Autoriza en el momento de la ejecución. Utiliza la identidad y los permisos que mantiene la aplicación. No permitas que el modelo se otorgue acceso a sí mismo colocando un ID de usuario o un rol en un argumento de herramienta.
Limita el poder de cada herramienta. Una herramienta get_order_status con un alcance limitado es más fácil de controlar que una herramienta de base de datos general. Las herramientas de solo lectura y las de escritura deberían ser distintas cuando sus riesgos difieran.
Trata la salida de las herramientas como datos no confiables. El contenido externo puede ser incorrecto o contener texto diseñado para redirigir al modelo. Un documento devuelto es información que debe inspeccionarse, no una nueva autoridad que pueda sustituir la solicitud del usuario o las reglas del sistema.
Gestiona deliberadamente los efectos secundarios. Enviar un mensaje o emitir un reembolso es diferente de consultar un estado. Las acciones sensibles pueden requerir confirmación, protección de idempotencia frente a ejecuciones duplicadas y un registro de auditoría.
Devuelve los fallos con claridad. Los tiempos de espera agotados, los servicios no disponibles, los permisos rechazados y los argumentos no válidos deberían convertirse en resultados explícitos de la herramienta. De lo contrario, el modelo podría rellenar el vacío inventando un éxito.
Ideas equivocadas frecuentes
«El LLM llamó a mi API»
Por lo general, el LLM generó una solicitud y una aplicación llamó a la API. Decir que el modelo «llamó» a la herramienta es una abreviatura práctica, pero oculta el límite de ejecución y seguridad.
«La llamada de funciones y la llamada de herramientas siempre son diferentes»
En el caso de funciones definidas por desarrolladores, los proveedores y marcos de trabajo suelen utilizar los términos indistintamente. La diferencia aparece cuando una plataforma utiliza herramienta como término general para funciones más capacidades integradas, como la búsqueda o la ejecución de código. Consulta la taxonomía de la plataforma en lugar de asumir una distinción universal.
«Un esquema válido significa que la llamada es correcta»
Un esquema puede exigir una cadena, un número, una lista o un objeto, y puede rechazar una salida con formato incorrecto. No puede garantizar que el modelo haya seleccionado la herramienta adecuada, inferido el valor correcto o respetado una regla de negocio.
«Añadir una herramienta crea un agente»
El uso de herramientas es una capacidad. Un agente es un sistema más amplio que puede decidir, actuar, observar resultados, conservar el estado pertinente, repetir el ciclo y detenerse. Una llamada estructurada puntual puede utilizar el mismo mecanismo sin convertirse en un flujo de trabajo autónomo.
«El resultado de la herramienta debe ser verdadero»
El modelo puede resumir fielmente un resultado incorrecto. La fiabilidad de las herramientas, la actualidad de los datos, el control de acceso y la resistencia al contenido malicioso son propiedades del sistema completo, no solo del modelo de lenguaje.
Cómo encaja el uso de herramientas en un sistema de IA
El uso de herramientas se sitúa en el límite entre un modelo de lenguaje y los sistemas que lo rodean.
El modelo interpreta el lenguaje y propone el siguiente paso estructurado. La aplicación proporciona las definiciones de las herramientas, conserva el estado de la conversación, valida las llamadas, gestiona los permisos, ejecuta las operaciones y devuelve las observaciones. Las herramientas ofrecen capacidades limitadas. Un agente puede utilizar esta disposición repetidamente para alcanzar un objetivo mayor.
Por eso la calidad del uso de herramientas no es solo una propiedad del modelo. Las descripciones claras de las herramientas, los esquemas diferenciados, los controles de ejecución, los mensajes de error útiles y unas reglas de parada razonables influyen en el funcionamiento del sistema.
Qué leer a continuación
Lee ¿Qué es un agente de IA? para ver cómo las llamadas de herramientas forman parte de un ciclo repetido de planificar-actuar-observar, con estado y reglas de parada. Lee ¿Qué es un arnés de IA? para conocer el software que valida y ejecuta esas llamadas; después, utiliza Modelo de IA frente a chatbot, arnés y agente para situar el uso de herramientas dentro del sistema más amplio.