Llamada a herramientas programáticas de GPT-6 Astra: Cuándo y por qué usarla
Aprende cuándo GPT-6 Astra debe llamar herramientas dentro de programas generados, cómo funcionan allowed_callers y output_schema, y cómo controlar costos, seguridad y aprobaciones.
El llamado tradicional a funciones pausa el modelo, devuelve una solicitud de herramienta a la aplicación, espera un resultado y se reanuda. Ese bucle es claro y controlable, pero se vuelve ineficiente cuando una tarea requiere muchas llamadas dependientes, filtrado local o agregación. El llamado programático a herramientas (PTC) de GPT-6 Astra permite que el modelo escriba un programa que invoque herramientas elegibles dentro de un único flujo de ejecución.
Qué cambios
Habilita la herramienta alojada programmatic_tool_calling, luego marca las herramientas elegibles con allowed_callers.
const tools = [
{ type: "programmatic_tool_calling" }
{
type: "function",
name: "obtener_ventas",
description: "Devuelve los registros de ventas de una región y un mes.",
allowed_callers: ["programático"],
strict: true,
parámetros: {
type: "objeto",
properties: {
region: { type: "string" },
month: { type: "string" }
},
requerido: ["región", "mes"],
additionalProperties: false
}
}
];
Si allowed_callers se omite o se establece en ["directo"], la herramienta es directamente invocable.["programático"] lo restringe al código generado, mientras que ["directo", "programático"] permite ambos. Esto es un control de política de ejecución, por lo que debes revisarlo como permisos en lugar de redacción de aviso.
PTC admite clases de herramientas documentadas, incluyendo funciones y herramientas personalizadas, MCP, aplicar parches, shell local o alojada, e intérprete de código. El soporte no significa que todas las herramientas deban exponerse.
Cuándo PTC es el mejor patrón
Úselo cuando el modelo necesite:
OUTPUT ONLY TRANSLATION:
- obtener muchos registros independientes y agregarlos;
- llamar a una herramienta basándose en un resultado anterior;
- filtrar un resultado grande antes de devolverlo al contexto de razonamiento;
- comparar resultados estructurados entre fuentes;
- ejecutar un bucle de procesamiento de datos acotado.
Por ejemplo, un análisis trimestral puede requerir doce llamadas de región-mes seguidas de totales y detección de anomalías. Un programa puede realizar las llamadas y devolver un resumen compacto en lugar de forzar doce viajes de ida y vuelta del modelo.
Prefiere la llamada directa a funciones para una o dos operaciones simples, escrituras de alto riesgo, flujos de trabajo que requieran una decisión explícita de la aplicación entre cada paso, o tareas cuyo gráfico deba ser determinista. PTC no es automáticamente más barato: un programa mal acotado puede realizar demasiadas llamadas.
Las salidas estructuradas mejoran los programas
Para funciones predecibles, define un output_schema. El function_call_output.output real sigue siendo una cadena JSON, pero el esquema le da al código generado una forma confiable. Los tipos estables reducen el análisis defensivo y las suposiciones accidentales.
Devuelve datos compactos como IDs, métricas tipadas y objetos de error explícitos. Evita la prosa donde el código necesite números. Haz que la paginación, el máximo de filas y el truncamiento sean visibles en el resultado para que el programa no pueda confundir un conjunto de datos parcial con la población completa.
Búsqueda de herramientas y carga diferida
La búsqueda de herramientas sigue siendo una capacidad de primer nivel. La guía oficial advierte que las herramientas diferidas deben cargarse antes de que el programa comience, porque un programa en ejecución no puede invocar la búsqueda de herramientas. Primero el descubrimiento del plan, luego la ejecución. Si el catálogo es dinámico, deje que el modelo cargue el pequeño subconjunto requerido y solo entonces comience el PTC.
Controles de seguridad
Limita cada programa por tiempo de ejecución, número de llamadas, bytes de salida, destinos de red y costo. Restringe las herramientas al mínimo privilegio y mantén los secretos en el entorno de ejecución en lugar del código generado.
La aprobación de MCP puede pausar un programa. Preserve el estado del programa mientras presenta una vista previa de aprobación significativa. Para escrituras, use claves de idempotencia y autorización del lado del servidor. El código generado no es confiable incluso cuando el modelo lo escribió a partir de instrucciones confiables.
Registra el hash del programa o la fuente censurada, la secuencia de herramientas, los argumentos sanitizados, las aprobaciones, los resultados, el uso de tokens y la duración. Evita almacenar credenciales o datos sensibles sin procesar.
Un marco de decisión para la producción
Haz cuatro preguntas:
- ¿Hay suficientes llamadas o dependencias para justificar un programa integrado?
- ¿Puede cada herramienta ser limitada y tipada de manera segura?
- ¿La aplicación se siente cómoda delegando el control intermedio?
- ¿Puede reanudarse el flujo de trabajo después de una aprobación o fallo parcial?
Si alguna respuesta es no, mantén la orquestación en el código de la aplicación. El código determinista que posees suele ser la opción correcta para pipelines fijos.
Experimento de costo y corrección
Compara PTC con un bucle convencional usando tareas idénticas. Incluye un caso pequeño de una sola llamada, un caso dependiente de cinco llamadas y un caso grande de agregación. Mide el total de tokens, las llamadas a herramientas, el tiempo real, la tasa de fallos y la corrección del resultado calculado. Una respuesta más rápida que omita silenciosamente registros paginados no es una mejora.
Forzar fallos parciales: una región agota el tiempo de espera, un resultado viola su esquema de salida, una operación MCP solicita aprobación y un conjunto de datos está vacío. El programa generado debe preservar qué entradas tuvieron éxito, evitar tratar la ausencia como cero y devolver suficientes detalles para que el modelo explique las limitaciones.
Establezca límites estrictos por debajo de los límites de infraestructura para que el programa falle de manera predecible. Un resultado claro de CALL_BUDGET_EXCEEDED es más fácil de recuperar que un contenedor eliminado. Para cargas de trabajo analíticas, recalcule de forma independiente una muestra de resultados en código determinista. Para cualquier resultado financiero o de cumplimiento, prefiera cálculos verificados en lugar de confiar ciegamente en la agregación generada.
Este experimento a menudo revela un diseño mixto: PTC para exploración intensiva de lectura y código propiedad de la aplicación para escrituras finales o cálculos regulados. La orquestación híbrida es una fortaleza, no un fracaso al usar la función más nueva en todas partes.
Preguntas Frecuentes
¿Es PTC lo mismo que multiagente?
No. PTC ejecuta un programa de llamada a herramientas. El multiagente delega trabajo limitado a subagentes con sus propios contextos.
¿Puede PTC llamar a una herramienta MCP que necesita aprobación?
Sí. La aprobación puede pausar el programa. Su aplicación debe preservar el estado y continuar de manera segura.
¿PTC elimina los esquemas de funciones?
No. Los contratos de entrada y salida sólidos se vuelven aún más importantes porque el código generado los consume.
¿Debería cada herramienta permitir ambos modos de llamada?
No. Permita solo los modos requeridos por el flujo de trabajo, especialmente para herramientas sensibles.
Conclusión
La llamada programática a herramientas es valiosa cuando la propia orquestación de herramientas es el cuello de botella: muchas llamadas, dependencias, filtrado y agregación. Úsela de forma selectiva, cargue herramientas diferidas antes de la ejecución, defina salidas estructuradas y aplique límites estrictos de recursos y autoridad. Para flujos de trabajo cortos o de alto riesgo, un bucle convencional controlado por la aplicación sigue siendo más fácil de auditar.
