La llamada a herramientas programáticas (PTC) es un cambio de paradigma en cómo los modelos de lenguaje grandes (LLM) interactúan con herramientas externas. En un flujo de trabajo tradicional de llamada de herramientas, cada invocación de herramienta requiere un viaje completo de ida y vuelta al modelo. El modelo llama a una herramienta, recibe el resultado, razona al respecto, llama a la siguiente herramienta, etc. Para los flujos de trabajo que involucran múltiples llamadas a herramientas, esto crea una latencia compuesta y un consumo de tokens porque cada resultado intermedio debe pasar por la ventana de contexto del modelo.
PTC adopta un enfoque diferente. En lugar de orquestar llamadas a herramientas de una en una, el modelo escribe código, generalmente Python, que invoca múltiples herramientas mediante programación dentro de un entorno de ejecución aislado. El código puede incluir bucles, condicionales, filtrado y lógica de agregación. El modelo solo se muestrea una vez para producir el código. Luego, el entorno de ejecución maneja las invocaciones de herramientas y solo el resultado final procesado se devuelve al contexto del modelo. Esto reduce drásticamente tanto la latencia como el uso de tokens para flujos de trabajo de múltiples herramientas. PTC es particularmente eficaz para el procesamiento de grandes cantidades de datos, cálculos numéricos precisos, orquestación de procesos de varios pasos y escenarios sensibles a la privacidad donde los datos sin procesar no deben ingresar al contexto del modelo.
PTC se originó como una característica específica del proveedor, pero el patrón subyacente (el modelo genera código, el sandbox lo ejecuta, solo el resultado final regresa al contexto) es independiente del modelo. En esta publicación, mostramos tres formas de implementar PTC en Amazon Bedrock: un entorno limitado de Docker autohospedado en ECS para un control máximo, una solución administrada que utiliza Amazon Bedrock AgentCore Code Interpreter y una ruta compatible con Anthropic SDK a través de un proxy para equipos que prefieren esa experiencia de desarrollador.
Cuellos de botella en la llamada de herramientas tradicionales
Considere este ejemplo: "¿Qué miembros del equipo de ingeniería excedieron su presupuesto de viaje del tercer trimestre?" Con la llamada a herramientas tradicional (suponiendo que no haya llamadas a funciones paralelas), el modelo debe:
Llame a una herramienta para obtener la lista de miembros del equipo: 20 personas. Llame a una herramienta para obtener registros de gastos de cada persona: 20 llamadas a herramientas separadas, cada una de las cuales devuelve entre 50 y 100 partidas. Llame a herramientas adicionales para recuperar los umbrales presupuestarios. Reciba más de 2000 registros de gastos en su ventana contextual. Razone el conjunto de datos completo en lenguaje natural para filtrar, comparar y resumir.
Cada una de esas llamadas a herramientas requiere un recorrido completo por el modelo. El modelo genera una llamada a la herramienta, hace una pausa, recibe el resultado, razona al respecto, genera la siguiente llamada a la herramienta, etc. Esto crea tres problemas agravantes:
Consumo de tokens: cada resultado intermedio, incluidos miles de partidas de gastos que el modelo finalmente descartará, pasa por la ventana de contexto. Latencia: cada invocación de herramienta requiere un ciclo completo de inferencia del modelo. 20 llamadas secuenciales a herramientas significan 20 viajes de ida y vuelta de inferencia. Precisión: pedirle a un modelo de lenguaje que filtre, agregue y compare miles de registros en lenguaje natural es propenso a errores. Estas son operaciones que unas pocas líneas de Python manejarían con precisión.
Cómo resuelve esto PTC
PTC invierte el patrón. El modelo escribe un único bloque de código Python que organiza las llamadas a la herramienta, procesa los resultados y devuelve solo el resultado final.
Utilizando el mismo ejemplo de auditoría de gastos, esto es lo que genera el modelo cuando se habilita PTC:
Hay dos cosas a tener en cuenta aquí. Primero, asyncio.gather() emite las 20 búsquedas de gastos en paralelo en lugar de secuencialmente; las llamadas a la herramienta ocurren casi simultáneamente. En segundo lugar, el filtrado, la agregación y la comparación de presupuestos se realizan en Python, no en lenguaje natural. Sólo la salida final de print() se devuelve a la ventana de contexto del modelo. Los más de 2.000 registros de gastos sin procesar no lo tocan. El modelo se muestrea sólo dos veces: una para generar el código y otra para interpretar el resultado final. Todo lo intermedio (las llamadas a la herramienta, el procesamiento de datos, el filtrado) sucede dentro del contenedor sin inferencia adicional del modelo.
Parte 1: PTC autohospedado con Amazon Bedrock y Amazon ECS
¿Por qué autohospedarse?
Las implementaciones de PTC administradas se basan en un entorno de pruebas administrado por el proveedor. Pero hay buenas razones para autohospedarse:
Independiente del modelo: admite modelos disponibles en Amazon Bedrock (por ejemplo, Claude, Qwen, MiniMax, Llama, Nova y más). Control total: personalice el entorno de pruebas, instale paquetes de Python específicos del dominio y configure políticas de seguridad que se ajusten a sus requisitos. Implementación privada: mantenga la ejecución del código y los datos intermedios dentro de su propia cuenta de AWS.
Arquitectura
La solución autohospedada tiene dos componentes:
Orquestador: su aplicación (tarea de Amazon Elastic Container Service (Amazon ECS), AWS Lambda o un proceso) que llama a la API de InvokeModel mediante Boto3, administra el ciclo de vida del espacio aislado de Docker y maneja el ciclo de llamadas de la herramienta. Docker Sandbox: un contenedor aislado que ejecuta código Python generado por modelos. Se comunica con el orquestador a través de IPC a través de stdin/stderr.
La idea central es sencilla: tomar las definiciones de herramientas que normalmente van en tool_config, inyectarlas en el indicador del sistema e indicar al modelo que escriba código Python que orqueste esas herramientas. El código generado se ejecuta en el entorno limitado de Docker. El orquestador actúa como un plano de control, interceptando llamadas a herramientas a través de IPC, ejecutándolas externamente e inyectando los resultados nuevamente en el sandbox.
El mensaje del sistema
El indicador del sistema es la pieza crítica que hace que un modelo se comporte como si fuera compatible con PTC de forma nativa. Describe el entorno de ejecución, las herramientas disponibles y las reglas para generar código. Se proporciona una versión simplificada:
Este mensaje guía al modelo para producir código Python bien estructurado que sigue los mismos patrones que la implementación nativa de PTC, bloques de código único, llamadas a herramientas asíncronas e print() para la salida.
Componentes principales
SandboxExecutor: el ejecutor de la zona de pruebas de Docker
SandboxExecutor es el componente central. Gestiona el ciclo de vida de contenedores Docker aislados, ejecuta código generado por modelos de forma segura y maneja el protocolo IPC para llamadas a herramientas. El sistema utiliza una arquitectura de proceso dual. El orquestador (que se ejecuta en su tarea ECS) lanza un contenedor Docker para cada solicitud de ejecución de código. La comunicación se produce a través de flujos de E/S estándar, el contenedor escribe solicitudes de llamada de herramientas en stderr y el orquestador inyecta los resultados de las herramientas a través de stdin.
El guión del corredor
El orquestador genera dinámicamente el script del ejecutor y lo inyecta en cada contenedor Docker al inicio. Se encarga de:
Ejecución de código: envolver el código generado por el modelo en un contexto asíncrono, capturar resultados y manejar excepciones. Protocolo IPC: uso de marcadores de mensajes estructurados (por ejemplo, __PTC_TOOL_CALL__, __PTC_END_CALL__, __PTC_OUTPUT__) para separar las solicitudes de llamadas de herramientas, los resultados y la salida final en el flujo de texto. Generación de funciones de herramienta: creación dinámica de funciones asíncronas de Python para cada herramienta definida en la configuración. Cuando las llamadas de código del modelo await get_team_members(department=”engineering”), la función generada serializa los argumentos, escribe una solicitud de llamada de herramienta en stderr, bloquea hasta que el orquestador inyecta el resultado usando stdin y devuelve el resultado deserializado.
El script de ejecución admite dos modos de ejecución:
Modo único: ejecuta el código una vez y sale. Adecuado para tareas de una sola vez sin estado. Modo de bucle: mantiene el contenedor en ejecución para aceptar múltiples ejecuciones de código, lo que admite la reutilización de sesiones y la retención de estado entre llamadas.
protocolo PCI
Para separar de manera confiable diferentes tipos de mensajes en una secuencia de texto, el sistema define marcadores de límites:
__PTC_TOOL_CALL__ / __PTC_END_CALL__: envuelve una solicitud de llamada de herramienta (nombre de la herramienta + argumentos como JSON). __PTC_OUTPUT__: marca el resultado final de la ejecución del código.
Cuando el script del ejecutor encuentra una llamada a una herramienta en el código de ejecución, serializa la llamada como JSON, la escribe en stderr entre los límites del marcador y bloquea la entrada estándar esperando el resultado. El orquestador lee stderr, analiza la llamada a la herramienta, ejecuta la herramienta y escribe el resultado en stdin. El script del ejecutor se desbloquea y continúa la ejecución.
El bucle del orquestador
Habilitar PTC en Amazon Bedrock requiere tres elementos:
Un mensaje del sistema que indica al modelo que escriba código Python para la orquestación de herramientas. Una definición de herramienta de ejecución_código que el modelo utiliza para enviar código al entorno sandbox. Descripciones de herramientas comerciales integradas en el mensaje del sistema (no como herramientas independientes de Amazon Bedrock).
El orquestador une Amazon Bedrock y el sandbox de Docker. Aquí está el bucle central:importar boto3importar json
El orquestador envía la consulta del usuario a Amazon Bedrock, extrae el código generado por el modelo de la respuesta de uso de herramienta, lo ejecuta en el entorno limitado de Docker y devuelve el resultado como resultado de herramienta. Luego, el modelo produce su respuesta final legible por humanos, muestreada solo dos veces en total.
Seguridad de la zona de pruebas de Docker
El contenedor sandbox funciona con un aislamiento estricto. A continuación se muestra un comando de ejecución de Docker de ejemplo que aplica las capas de seguridad:
Esto facilita: ningún acceso a la red, un sistema de archivos de solo lectura (con un pequeño tmpfs para espacio temporal), un usuario no root, capacidades de Linux eliminadas y límites de memoria/CPU. El código generado por el modelo no puede escapar del entorno limitado, conservar datos ni consumir recursos excesivos.
Parte 2: PTC administrado con el intérprete de código AgentCore de Amazon Bedrock
Para los equipos que no desean administrar contenedores Docker ni la infraestructura ECS, Amazon Bedrock AgentCore proporciona un intérprete de código administrado que implementa el mismo patrón de PTC. El modelo escribe código, un entorno limitado administrado lo ejecuta y solo el resultado final regresa al contexto del modelo. Aquí está la misma arquitectura modificada con el uso de AgentCore Code Interpreter para la ejecución de código:
La diferencia clave con el enfoque autohospedado es que las herramientas se cargan previamente en la sesión de la zona de pruebas en lugar de enviarse de regreso al cliente a través de IPC. Inicia una sesión de intérprete de código, inyecta las definiciones de funciones de su herramienta como código Python y luego deja que el modelo genere código que llame directamente a esas funciones precargadas.
AgentCore utiliza el cliente boto3 bedrock-agentcore:
Comparación entre alojamiento propio y gestionado
Aspecto Autohospedado (Parte 1) AgentCore (Parte 2) Infraestructura Usted administra ECS + Docker Totalmente administrado Personalización Control total sobre Sandbox Tiempo de ejecución estándar Ejecución de herramientas Lado del cliente (IPC) Dentro de Sandbox Acceso a red Configurable Predeterminado desactivado, modo PÚBLICO disponible
El enfoque administrado se recomienda para equipos que desean el ahorro de tokens y los beneficios de precisión de PTC sin la sobrecarga operativa de ejecutar contenedores Docker. El enfoque autohospedado es mejor cuando necesita paquetes Python personalizados, configuraciones de seguridad específicas o control total sobre el entorno de ejecución.
Parte 3: compatibilidad con Anthropic SDK a través de proxy
Si su equipo prefiere la experiencia de desarrollador de Anthropic SDK y quiere usarla con Amazon Bedrock como backend, puede crear un proxy de traducción de API liviano que se ubique entre Anthropic SDK y Amazon Bedrock.
El proxy se implementa en Amazon ECS y traduce las llamadas a la API de Anthropic en llamadas de Amazon Bedrock InvokeModel. También gestiona de forma transparente el ciclo de vida de Docker Sandbox y el protocolo PTC completo. Para migrar, cambie base_url para que apunte al proxy:
Este enfoque se recomienda para equipos que prefieren la interfaz Anthropic SDK mientras usan Amazon Bedrock para la inferencia de modelos y los beneficios de ejecutar dentro de su cuenta de AWS. El proxy maneja la traducción de modelos, la administración de la zona de pruebas y el protocolo PTC completo de forma transparente.
Resultados experimentales
Para validar la solución PTC autohospedada, ejecutamos la misma tarea de auditoría de gastos en varios modelos disponibles en Amazon Bedrock.
Configuración empresarial:
Datos del equipo: ocho miembros del equipo de ingeniería en varios niveles. Datos de gastos: entre 20 y 50 registros por persona por trimestre, cada uno con más de 15 campos (id_gasto, fecha, monto, categoría, estado). Reglas de presupuesto: Presupuesto de viaje trimestral estándar de $5000, con excepciones personalizadas para puestos de alto nivel. Sólo cuentan los gastos aprobados.
Mensaje de tarea: "¿Qué miembros del equipo de ingeniería excedieron su presupuesto de viaje del tercer trimestre? El presupuesto de viaje trimestral estándar es de $5000. Sin embargo, algunos empleados tienen límites de presupuesto personalizados. Para cualquiera que excedió el presupuesto estándar de $5000, verifique si tiene una excepción de presupuesto personalizada".
Respuesta correcta esperada:
Nombre Presupuesto real superado por Alice Chen $5.000,00 $9.876,54 +$4.876,54 Emma Johnson $5.000,00 $5.266,02 +$266,02 Grace Taylor $5.000,00 $6.474,46 +$1.474,46
Comparación de PTC y no PTC
Modelo Tokens PTC Tokens no PTC Reducción de tokens PTC preciso No PTC preciso Claude Sonnet 4.6 (pensamiento adaptativo) 12.739 128.043 90,1% Sí Sí Claude Opus 4.6 (pensamiento adaptativo) 13.043 126.152 89,7% Sí Sí Qwen3-Coder-480B 34.159 305.114 88,8% Sí No Qwen3-Next-80B 28.878 233.332 87,6% Sí No deepseek.v3.2 (pensamiento) 19.543 245.967 92,1% Sí No MiniMax M2.1 (pensamiento) 11.787 101.990 88,4% Sí No Kimi 2,5 (pensando) 10.875 148.085 92,7% Sí No GLM 4,7 (pensando) 11.550 115.829 90,0% Sí No
Nota: Los modelos marcados con pensamiento o pensamiento adaptativo utilizaron sus respectivos modos de razonamiento durante la generación del código.
Hallazgos clave
El consumo de tokens cayó entre un 87% y un 92% en todos los modelos en modo PTC. En lugar de cientos de miles de tokens fluyendo a través de la ventana contextual, solo el código y el resumen final llegan al modelo. La precisión mejoró significativamente. En el modo PTC, los ocho modelos produjeron la respuesta correcta (los nombres y las cantidades coincidían exactamente). En el modo sin PTC, sólo los modelos Claude (Sonnet 4.6 y Opus 4.6) produjeron respuestas completamente correctas. El procesamiento en lenguaje natural de grandes datos tabulares de los otros modelos introdujo errores en el filtrado, la agregación o ambos. Se confirma la compatibilidad entre modelos. Los modelos Claude, Qwen, DeepSeek, MiniMax, Kimi y GLM lograron resultados correctos en el modo PTC, lo que demuestra que este paradigma funciona eficazmente en diversas familias de modelos. El ahorro de tokens osciló entre el 87% y el 92%. La solución autohospedada funcionó de manera idéntica en todos los modelos. El mismo entorno limitado de Docker, el mismo protocolo IPC y el mismo orquestador, solo el parámetro model_id cambió entre pruebas.
La conclusión clave: PTC como paradigma no está vinculado a ningún modelo único. A través del enfoque de entorno aislado autohospedado, un modelo que admita el uso de herramientas puede beneficiarse de la llamada a herramientas orquestada por código.
Análisis de costos y valores.
Ahorro de tokens a escala
Tomando como ejemplo Claude Sonnet 4.6, la tarea de auditoría de gastos mostró una reducción de aproximadamente el 90 % en el consumo de tokens entre los modos PTC y no PTC. La razón es sencilla: en el modo sin PTC, cada resultado de la herramienta intermedia ingresa a la ventana contextual. En modo PTC, sólo lo hacen el código y el resumen final.
Proyección de costos (basada en el precio de Claude Sonnet de $3/$15 por 1 millón de tokens de entrada/salida):
Si esta tarea se ejecuta 1000 veces por día en un entorno de producción:
Métrico Modo sin PTC Modo PTC Costo diario estimado ~$520 ~$52 Costo mensual estimado ~$15,600 ~$1,560 Ahorro mensual ~$14,040 (90%)
Estas cifras variarán según la complejidad de la tarea y el volumen de datos, pero el patrón es consistente: PTC reduce el costo aproximadamente en proporción a la cantidad de datos intermedios que mantiene fuera de la ventana contextual.
Conclusión
Las llamadas a herramientas programáticas representan un cambio en la forma en que los agentes de IA interactúan con las herramientas, desde invocaciones conversacionales, una a la vez, hasta ejecuciones filtradas, paralelas y orquestadas por código. Los resultados de nuestras pruebas confirman la propuesta de valor central:
El consumo de tokens cae entre un 87% y un 92% al mantener los datos intermedios fuera del contexto del modelo. La precisión mejora porque el procesamiento de datos se realiza en Python, no en lenguaje natural. La latencia disminuye porque las llamadas a herramientas se pueden ejecutar en paralelo y el modelo se muestrea solo dos veces.
Presentamos tres formas de implementar PTC en Amazon Bedrock:
Autohospedado en ECS: control total con Boto3 y un entorno limitado de Docker, recomendado para equipos que necesitan entornos personalizados y máxima flexibilidad. Gestionado a través de AgentCore Code Interpreter: un espacio aislado totalmente gestionado para equipos que prefieren menos gastos operativos. Compatible con Anthropic SDK: una ruta basada en proxy para equipos que prefieren la interfaz de Anthropic SDK mientras se ejecuta en Amazon Bedrock.
Los tres enfoques son independientes del modelo, se implementan de forma privada dentro de su cuenta de AWS y se pueden ampliar a nuevos modelos a medida que estén disponibles en Amazon Bedrock. Amazon Bedrock proporciona el backend de inferencia de modelos con precios de pago por uso, soberanía de datos dentro de su cuenta de AWS y acceso a un conjunto diverso de modelos a través de una única API.
Referencias
Anthropic: documentación de llamadas de herramientas programáticas Anthropic: introducción al uso avanzado de herramientas Documentación del intérprete de código AgentCore de Amazon Bedrock AWS sample-ai-possibilities: patrón de llamadas de herramientas programáticas Amazon Bedrock: servicio de modelo básico totalmente administrado Muestras de AWS: proxy API de Anthropic-Bedrock
Sobre los autores
Shreyas Subramanian es un científico de datos principal y ayuda a los clientes mediante el uso de IA generativa y aprendizaje profundo para resolver sus desafíos comerciales utilizando servicios de AWS como Amazon Bedrock y AgentCore. El Dr. Subramanian contribuye a la investigación de vanguardia en aprendizaje profundo, IA agente, modelos básicos y técnicas de optimización con varios libros, artículos y patentes a su nombre. En su puesto actual en Amazon, el Dr. Subramanian trabaja con varios líderes científicos y equipos de investigación dentro y fuera de Amazon, ayudando a guiar a los clientes a aprovechar mejor los algoritmos y técnicas de última generación para resolver problemas críticos para el negocio. Fuera de AWS, el Dr. Subramanian es un revisor experto de artículos sobre IA y financiación a través de organizaciones como Neurips, ICML, ICLR, NASA y NSF.
Pratik Raichura es ingeniero principal de desarrollo de software en AWS, donde ha pasado más de una década creando servicios de inteligencia artificial desde cero, incluidos Amazon Bedrock y Amazon Lex. Su trabajo abarca sistemas distribuidos, infraestructura de inferencia de IA, IA responsable y gestión de cargas de trabajo a escala. Fuera del trabajo, le apasiona ayudar a las empresas emergentes de IA en sus etapas iniciales y contribuir a la comunidad de IA en general a través de IEEE y ACM.
River Xie es arquitecto senior de soluciones especializado en GenAI en la región CMHK de AWS. Con años de experiencia en productos e ingeniería que abarcan las industrias de telecomunicaciones, comercio electrónico e Internet, River ha adquirido una profunda experiencia en ciencia de datos, sistemas de recomendación, plataformas de ajuste de LLM e IA agente, y es titular de múltiples patentes en tecnologías relacionadas con la IA.