Índice de contenidos
Function calling y tool calling a menudo describen el mismo comportamiento del modelo: un LLM devuelve una solicitud estructurada para una capacidad externa en lugar de responder completamente a partir de su propio texto generado. La diferencia práctica es el alcance. Una función es un tipo de herramienta, normalmente definida con un nombre, una descripción y un JSON Schema. Tool calling es el término más amplio y también puede incluir búsqueda alojada, ejecución de código, control del ordenador, recuperación de archivos o herramientas expuestas a través del Model Context Protocol (MCP).
La distinción también depende de la API. Algunos proveedores usan los dos términos indistintamente. Otros reservan "function calling" para el código definido por el desarrollador y usan "tool calling" como el término general tanto para capacidades personalizadas como alojadas. El enfoque más seguro es leer el esquema de solicitud y respuesta del proveedor en lugar de inferir el comportamiento solo a partir de la etiqueta.
¿Qué es LLM Function Calling?
LLM function calling es una interfaz estructurada entre un modelo y el código de la aplicación. La aplicación proporciona al modelo una o más definiciones de funciones, incluidos el propósito de cada función y los argumentos aceptados. Cuando una solicitud del usuario coincide con una de esas definiciones, el modelo puede devolver el nombre de la función y los argumentos propuestos.
Por ejemplo, una aplicación podría exponer esta función:
Si el usuario pregunta: "¿Se ha enviado el pedido A104?", el modelo puede devolver una llamada a get_order_status con {"order_id":"A104"}. Esa salida estructurada es una propuesta, no una prueba de que el pedido exista o de que el usuario pueda acceder a él.
Normalmente, el modelo no ejecuta código definido por el desarrollador. La aplicación debe analizar los argumentos, validarlos, comprobar la autorización, ejecutar la función y devolver el resultado. La documentación de function calling de Google describe el mismo patrón principal: el modelo conecta la intención en lenguaje natural con una función definida y suministra los parámetros necesarios para la operación.
Function calling resulta útil cuando un LLM necesita:
recuperar datos actuales o privados de una API o base de datos;
convertir una solicitud en lenguaje natural en argumentos tipados;
desencadenar una operación empresarial controlada;
delegar trabajo determinista a una calculadora, validador u otro servicio; o
seleccionar entre varias capacidades de la aplicación en tiempo de ejecución.
Por sí mismo no hace que cada respuesta sea un hecho contrastado. Un modelo aún puede seleccionar la función incorrecta, inventar un argumento, hacer un mal uso de un resultado correcto o llamar a una función cuando debería pedir una aclaración al usuario.
¿Qué es Tool Calling?
Tool calling es el patrón más amplio en el que un modelo solicita acceso a funcionalidades fuera de la generación de texto ordinaria. Una herramienta puede ser una función definida por el desarrollador, pero también puede ser un servicio de búsqueda, un entorno de ejecución de código, un índice de archivos, un navegador, un conector de base de datos, un generador de imágenes u otro agente.
Una definición útil separa tres componentes:
Definición de la herramienta: lo que se le dice al modelo que puede usar, incluidos el nombre, la descripción, el esquema de entrada y, a veces, los metadatos de salida.
Llamada a la herramienta (tool call): la solicitud estructurada producida por el modelo.
Ejecución de la herramienta: la operación realizada por el código de la aplicación, un servicio gestionado por el proveedor u otro entorno de ejecución.
La ubicación de la ejecución no es lo que separa function calling de tool calling. Una función personalizada puede llamar a una API remota, mientras que una herramienta de shell o calculadora puede ejecutarse localmente. El acceso a Internet tampoco es una diferencia definitoria. Las preguntas relevantes son qué capacidad se expone, quién la ejecuta y qué controles se aplican antes de la ejecución.
Las plataformas modernas utilizan cada vez más "herramienta" como el objeto de API de nivel superior. OpenAI, por ejemplo, define una función como un tipo específico de herramienta y utiliza tool calling para el bucle completo de solicitud–ejecución–resultado en su guía de function calling. Anthropic afirma igualmente que el uso de herramientas también se denomina function calling, al tiempo que distingue las herramientas del cliente de las herramientas ejecutadas en su propia infraestructura.
Function Calling vs. Tool Calling: ¿son lo mismo?
A menudo son intercambiables en una conversación, pero no siempre son idénticos a nivel de API. Es mejor tratar function calling como un subconjunto de tool calling.
Dimensión | Function Calling | Tool Calling |
|---|---|---|
Alcance | Una operación invocable con nombre, normalmente con argumentos estructurados | Cualquier capacidad externa accesible para el modelo |
Entradas habituales | JSON Schema o una definición de parámetros tipados similar | Parámetros estructurados, entrada de texto libre, acciones de interfaz de usuario, código o formatos específicos del proveedor |
Ejecutor típico | La aplicación del desarrollador | La aplicación, el proveedor del modelo, el entorno de ejecución local, el servidor MCP u otro servicio |
Ejemplos | get_weather, create_ticket, lookup_customer | Herramientas de función, búsqueda web, búsqueda de archivos, ejecución de código, uso del ordenador, herramientas MCP |
Mejor término al debatir la arquitectura | Preciso cuando solo intervienen funciones personalizadas | Mejor cuando varios tipos de herramientas comparten un bucle de orquestación |
La terminología debe seguir la superficie de implementación. En SiliconFlow, la API de Chat Completions admite herramientas de función a través del campo tools, con hasta 128 definiciones de función por solicitud a fecha de 26 de agosto de 2026. En esta interfaz, "LLM function calling" y "LLM tool calling" suelen referirse al mismo mecanismo. Las categorías de herramientas más amplias disponibles en otras plataformas no se admiten automáticamente a través del mismo endpoint. Consulte la referencia de la API actual antes del despliegue en producción, ya que los tipos de herramientas admitidos y los límites de solicitudes pueden cambiar.
Cómo decide un LLM cuándo llamar a una herramienta
Un LLM no inspecciona los sistemas en vivo antes de elegir una herramienta. Predice una respuesta a partir de la conversación, las instrucciones y las definiciones de herramientas incluidas en su contexto. El nombre de la herramienta, la descripción, el esquema de parámetros, los ejemplos y las políticas circundantes influyen en si responde directamente, hace una pregunta o emite una llamada.
La decisión suele implicar cuatro juicios:
Necesidad: ¿Requiere la solicitud datos actualizados, estado privado, computación determinista o una acción externa?
Coincidencia: ¿Qué herramienta disponible se ajusta más a la intención del usuario?
Preparación: ¿Están presentes todos los argumentos obligatorios o debería el modelo solicitar la información que falta?
Permiso: ¿Está permitida la acción solicitada y requiere confirmación o aprobación humana?
Las descripciones de las herramientas deben expresar límites, no solo capacidades. "Buscar un pedido" es más débil que "Devolver el estado de un pedido perteneciente al usuario autenticado; no utilizar para la búsqueda de productos". Nombres claros y descripciones sin solapamientos facilitan la evaluación del enrutamiento.
Los desarrolladores también pueden disponer de controles a nivel de API que permitan la selección automática, requieran una función concreta o impidan llamadas. Esos controles varían según el proveedor y el modelo. Las instrucciones del prompt pueden guiar el comportamiento, pero las reglas de autorización y aprobación deben permanecer en el código de la aplicación, ya que las instrucciones generadas no son un límite de seguridad.
¿Qué sucede después de que el modelo devuelve una llamada a una herramienta?
Una aplicación de producción debe tratar una llamada a una herramienta como una entrada estructurada no confiable. El bucle completo es:
Enviar el mensaje del usuario y las definiciones de herramientas elegibles al modelo.
Inspeccionar la respuesta en busca de una o más llamadas a herramientas.
Analizar los argumentos y validarlos con respecto al esquema esperado.
Verificar el nombre de la herramienta con una lista de permitidos y aplicar reglas de identidad, permisos, presupuestos y aprobación.
Ejecutar la operación aprobada con un tiempo de espera (timeout) y una estrategia de idempotencia donde puedan existir efectos secundarios.
Devolver el resultado con el ID de llamada de herramienta coincidente.
Pedir al modelo que continúe y luego repetir hasta que devuelva una respuesta final o la aplicación alcance un límite de pasos.
El siguiente ejemplo utiliza nuestro endpoint compatible con OpenAI y se centra en el límite de orquestación. La función get_order_status aún necesita una autenticación real y lógica de acceso a datos en producción.
El tiempo de espera de 30 segundos y los dos reintentos son configuraciones de cliente de ejemplo en lugar de límites de la plataforma. Establézcalos de acuerdo con el margen de latencia de la operación y la seguridad de los reintentos, especialmente cuando una función pueda crear un efecto secundario externo.
Para ejecutar este flujo de trabajo en SiliconFlow, defina las funciones disponibles a través de la estructura tools compatible con OpenAI y seleccione un modelo que actualmente admita function calling. Compruebe de nuevo la compatibilidad del modelo antes de cambiar el ID del modelo, ya que la disponibilidad de la API y las capacidades del modelo pueden cambiar de forma independiente.
Algunos modelos de razonamiento mantienen un estado adicional a través de los pasos de las herramientas. Al usar DeepSeek V3.2 o GLM-4.7 con Interleaved Thinking, conserve y reproduzca cada segmento de reasoning_content exactamente como se devolvió, incluidos los segmentos generados después de los resultados de las herramientas. Omitir o editar ese campo puede romper la secuencia de varios pasos. Este requisito es específico del modelo y no debe asumirse para todos los modelos.
Tool Calling en flujos de trabajo de agentes de IA
Una sola llamada a una función no es automáticamente un agente de IA. Un agente agrega un bucle de ejecución alrededor de las decisiones del modelo para que el sistema pueda observar resultados, actualizar el estado, elegir otra acción, solicitar aprobación o detenerse.
Considere un agente de soporte al que se le pide que reembolse un cobro duplicado. Puede que necesite:
recuperar la cuenta y la transacción;
determinar si los dos cobros cumplen la regla de pago duplicado;
pedir confirmación si el reembolso es irreversible;
enviar el reembolso a través de una función autorizada;
verificar el estado resultante de la transacción; y
resumir el resultado sin exponer datos internos.
El modelo proporciona un enrutamiento flexible, mientras que la aplicación proporciona el control. Un bucle de agente fiable necesita límites explícitos en cuanto a pasos, tiempo transcurrido, gasto, reintentos y acceso a herramientas. También necesita un estado persistente, IDs de traza, gestión estructurada de errores y una condición de parada clara.
Utilice un flujo de trabajo determinista cuando la secuencia ya se conozca de antemano. Deje que el modelo elija las herramientas cuando la intención del usuario, la información faltante o los resultados intermedios puedan cambiar genuinamente el siguiente paso. Esto mantiene las operaciones rutinarias evaluables, reservando el criterio del modelo para las partes que realmente lo necesitan.
Modos de fallo comunes en Tool Calling
Tool calling puede fallar antes de la ejecución, durante la operación o después de que se devuelva el resultado. Registrar únicamente la respuesta final oculta dónde se inició el fallo.
Modo de fallo | Qué aspecto tiene | Control práctico |
|---|---|---|
Llamada omitida | El modelo responde de memoria cuando se requieren datos recientes o privados | Añadir ejemplos de enrutamiento positivos y negativos; medir la exhaustividad (recall) de las llamadas |
Herramienta incorrecta | Se selecciona una función similar | Separar descripciones superpuestas y limitar el conjunto de herramientas activas |
Argumentos no válidos | El JSON está mal formado, faltan campos obligatorios o los tipos son incorrectos | Analizar de forma segura y validar con respecto al esquema del lado del servidor |
Argumentos verosímiles pero incorrectos | El esquema pasa la validación, pero un ID, fecha, unidad o alcance es incorrecto | Validar la semántica y confirmar valores ambiguos o de alto impacto |
Llamada innecesaria | El modelo invoca una herramienta para una solicitud conversacional o ya respondida | Probar casos en los que no debe llamarse y ajustar la instrucción de enrutamiento |
Secuencia incorrecta | Se produce una escritura antes de una lectura, comprobación o aprobación obligatoria | Hacer cumplir los requisitos previos de la máquina de estados y de aprobación fuera del modelo |
Efecto secundario duplicado | Un reintento crea dos tickets, pagos o mensajes | Utilizar claves de idempotencia y registrar los IDs de llamadas completadas |
Inyección en el resultado de la herramienta | Contenido no confiable intenta redirigir al modelo o solicitar secretos | Tratar los resultados como datos, restringir el flujo de datos entre herramientas y filtrar el contexto confidencial |
Bucle infinito | El modelo repite llamadas fallidas o alterna entre herramientas | Establecer límites de pasos, reintentos, latencia y gasto con un mecanismo alternativo definido |
Mala síntesis final | La herramienta tiene éxito, pero la respuesta distorsiona u omite el resultado | Puntuar la fundamentación de la respuesta final por separado de la precisión de la llamada |
Los errores deben devolverse en un formato sobre el que el modelo pueda actuar, como invalid_order_id, permission_denied o temporary_unavailable. No exponga trazas de pila (stack traces), credenciales ni detalles de la red interna. Reintente únicamente los errores que probablemente sean transitorios y no permita que el modelo invalide las políticas de la aplicación.
Cómo probar la fiabilidad de Tool Calling
Pruebe el modelo, las definiciones de herramientas, el prompt, el código de orquestación y el entorno de ejecución como un solo sistema. Un benchmark público puede ayudar a filtrar modelos, pero no puede representar los esquemas exactos, las políticas, el lenguaje del usuario o los efectos secundarios de una aplicación.
El Berkeley Function-Calling Leaderboard evalúa el function calling nativo y basado en prompts en categorías que incluyen comportamiento simple, múltiple, en paralelo y multironda. Para la selección en producción, añada un conjunto de evaluación privado construido a partir de patrones de tareas reales y riesgos de fallo conocidos.
Incluya al menos estos grupos de casos:
Llamadas directas: la solicitud se asigna claramente a una función con todos los argumentos presentes.
Prompts sin llamada: el modelo debe responder con normalidad o declinar en lugar de utilizar una herramienta.
Información faltante: falta un campo obligatorio y la acción correcta es pedir aclaraciones.
Herramientas fáciles de confundir: varias funciones tienen nombres, entradas o dominios empresariales similares.
Valores adversarios: IDs, fechas, unidades, cadenas vacías, enumeraciones no admitidas y campos adicionales ponen a prueba el esquema.
Tareas de varios pasos: las llamadas posteriores dependen de resultados de herramientas anteriores o del cambio de estado.
Límites de permisos: el usuario solicita datos o acciones fuera de su autorización.
Inyección de fallos: las herramientas agotan el tiempo de espera, devuelven datos parciales, rechazan una solicitud o generan texto no confiable.
Casos de reintento: el entorno de pruebas verifica que una entrega reiterada no pueda duplicar un efecto secundario.
Informe de las métricas por categoría en lugar de comprimirlo todo en una sola cifra de precisión:
Métrica | Qué mide |
|---|---|
Precisión y exhaustividad en la selección de herramientas | Si el modelo llama a la herramienta adecuada cuando es necesario y la evita cuando no lo es |
Tasa de validez de argumentos | Si los argumentos generados se analizan correctamente y cumplen el esquema |
Precisión semántica de los argumentos | Si los valores son correctos para la solicitud del usuario, y no meramente bien tipados |
Precisión de aclaración o abstención | Si el modelo hace una pausa cuando falta información, capacidad o permiso |
Tasa de éxito de la secuencia | Si las llamadas de varios pasos se producen en un orden válido |
Tasa de éxito del estado final | Si el sistema externo alcanza el estado esperado |
Tasa de efectos secundarios duplicados | Si los reintentos o bucles repiten una operación irreversible |
Tasa de respuestas finales fundamentadas | Si la respuesta final refleja con precisión los resultados de las herramientas |
Latencia y coste P50 y P95 | Si el bucle completo cumple con los objetivos operativos |
Utilice parámetros deterministas cuando el modelo seleccionado los admita, pero realice ensayos repetidos cuando el muestreo o el comportamiento del proveedor puedan variar. Congele el ID del modelo, los esquemas, el prompt, las respuestas de las herramientas, el evaluador y la versión del conjunto de prueba para cada comparación. En SiliconFlow, esto hace que las pruebas entre modelos sean más significativas porque la superficie de la API se mantiene uniforme mientras cambia el modelo compatible seleccionado.
Establezca barreras de lanzamiento en torno a los errores de mayores consecuencias. Una búsqueda para atención al cliente puede tolerar una aclaración ocasional, pero requerir cero revelaciones entre cuentas en el conjunto de prueba. Un flujo de trabajo de pagos debe priorizar la autorización, la prevención de ejecuciones duplicadas y el estado final correcto por encima de una redacción final fluida.
Function Calling, MCP y agentes de IA: cómo encajan entre sí
Function calling, MCP y los agentes resuelven diferentes capas del sistema:
Capa | Responsabilidad principal |
|---|---|
Function calling | Proporciona al modelo una forma estructurada de solicitar una operación definida por el desarrollador |
Tool calling | Cubre el patrón más amplio de interacción entre el modelo y las capacidades |
MCP | Estandariza cómo una aplicación de IA se conecta a servidores que exponen herramientas, recursos y prompts |
Entorno de ejecución del agente | Repite los pasos del modelo y de las herramientas al tiempo que gestiona el estado, las políticas, las aprobaciones, los reintentos y la finalización |
MCP no sustituye la decisión del modelo de utilizar una capacidad. Estandariza la conexión entre una aplicación de IA y los servidores externos. Bajo la especificación actual de MCP, los servidores pueden exponer herramientas con esquemas de entrada, mientras que los clientes pueden listarlas y llamarlas a través de mensajes JSON-RPC. El host sigue decidiendo qué herramientas llegan al modelo y cómo se autorizan y ejecutan las llamadas. Dado que MCP está versionado, confirme el cliente, el servidor y las capacidades negociadas antes de depender de campos más recientes del protocolo.
Por lo tanto, una arquitectura habitual se parece a esto:
Un cliente MCP descubre herramientas de un servidor aprobado.
El host convierte o presenta las definiciones elegibles al modelo.
El modelo devuelve una llamada a una herramienta.
El host valida la política y solicita aprobación cuando se requiere.
El cliente MCP envía tools/call al servidor.
El host devuelve el resultado al modelo.
El bucle del agente continúa o produce una respuesta final.
Los metadatos y los resultados de las herramientas siguen siendo entradas no confiables. La especificación de herramientas de MCP recomienda una visibilidad clara de las herramientas expuestas y la confirmación humana para las operaciones. En la práctica, las acciones de alto impacto también necesitan credenciales de privilegio mínimo, comprobaciones de destino, registros de auditoría y autorización del lado de la aplicación.
Utilice function calling cuando baste con un pequeño conjunto de operaciones propiedad de la aplicación. Añada MCP cuando el descubrimiento estandarizado y las integraciones reutilizables reduzcan el trabajo de desarrollo de conectores personalizados. Añada un entorno de ejecución de agentes cuando las tareas requieran genuinamente decisiones reiteradas, observaciones intermedias o bifurcaciones basadas en aprobaciones. Las capas pueden funcionar juntas, pero cada una añade una superficie independiente de fiabilidad y seguridad que debe probarse.
Preguntas frecuentes
¿Se pueden transmitir en streaming las llamadas a herramientas en SiliconFlow?
Sí. Con el streaming habilitado, los datos de la llamada a la herramienta pueden llegar de forma incremental a través de delta.tool_calls, por lo que el cliente debe ensamblar los fragmentos antes de analizar los argumentos. Para los modelos compatibles con Interleaved Thinking, recopile también delta.reasoning_content y consérvelo para la siguiente solicitud.
¿Deben versionarse las definiciones de las herramientas?
Sí. Versione el nombre de la herramienta o el contrato del esquema cuando un cambio pueda alterar los argumentos aceptados, el significado de la salida o los efectos secundarios. Registre la versión utilizada por cada evaluación y traza de producción para que las regresiones en el enrutamiento puedan vincularse a un cambio de definición específico.
¿Es JSON Mode lo mismo que LLM Tool Calling?
No. JSON Mode restringe cómo se formatea el contenido generado por el modelo. Tool calling además asocia argumentos estructurados con una capacidad con nombre y un bucle de ejecución. Un JSON válido por sí solo no garantiza que se haya seleccionado, autorizado o ejecutado la herramienta correcta, ni que esté fundamentada en la respuesta final.
¿Se puede utilizar el mismo esquema de función en distintos proveedores de LLM?
No siempre. Los proveedores suelen utilizar esquemas de tipo JSON, pero los campos de solicitud, las funciones de esquema admitidas, los controles de selección de herramientas, el comportamiento de las llamadas en paralelo y los formatos de los mensajes de resultado pueden diferir. Adapte la integración a la API de destino y vuelva a ejecutar las mismas pruebas de fiabilidad después de cambiar de proveedor o de despliegue.
¿Cómo deben pasarse las credenciales a una herramienta de LLM?
Mantenga las credenciales fuera del contexto del modelo siempre que sea posible. La aplicación host debe inyectar credenciales de corta duración y de privilegio mínimo en el momento de la ejecución, tras las comprobaciones de autorización. Oculte los secretos de los prompts, los resultados de las herramientas, las trazas y los mensajes de error, y nunca trate una credencial generada por el modelo como confiable.
