Durante los últimos años, "un agente usa una herramienta" significaba un mecanismo específico: el modelo emite un blob estructurado — usualmente JSON — nombrando una función y sus argumentos, un runtime lo analiza, llama la función y alimenta el resultado de vuelta al contexto del modelo. Este patrón de llamada de herramientas impulsó la primera generación de frameworks de agentes y funciona. Pero tiene una ineficiencia tranquila que se hace obvia una vez la buscas: cada acción es un viaje separado de ida y vuelta a través del modelo. ¿Quieres llamar tres herramientas y combinar sus resultados? Eso es al menos tres llamadas al modelo, cada una releyendo el contexto acumulado, porque el modelo solo puede emitir una llamada a herramienta JSON a la vez y debe esperar ver cada resultado antes de decidir la siguiente. Una escuela de pensamiento creciente en 2026 argumenta que hay una forma mejor, y está escondida a simple vista: deja que el agente escriba código.
Este es el paradigma de agentes orientados a código, y está remodelando cómo trabajan los frameworks de agentes más eficientes. En lugar de emitir JSON, el agente escribe un fragmento de Python — que puede llamar múltiples herramientas, bucle, usar variables y combinar resultados — y el runtime lo ejecuta. Esta guía explica por qué ese cambio importa, cómo cambia el rendimiento y costo de los agentes, y cómo lo implementan los frameworks líderes, a través de smolagents (el enfoque orientado a código en su forma más pura) y Pydantic AI (agentes type-safe del equipo de Pydantic). También cubre el flip side esencial: ejecutar código generado por modelo de forma segura.
El problema con las llamadas a herramientas JSON
Para ver por qué importa orientado a código, mira de cerca qué cuesta las llamadas a herramientas JSON. Considera una tarea que requiere obtener datos de una API, filtrarlos y calcular un resumen. Con llamadas a herramientas, el modelo emite una llamada a la herramienta fetch, espera el resultado, emite una llamada a la herramienta filter, espera, luego emite una llamada a la herramienta compute, espera, y finalmente compone una respuesta. Eso son cuatro invocaciones de modelo, y cada una reprocesa todo el contexto creciente — la tarea original, más cada resultado intermedio acumulado hasta ahora. El costo de token y latencia escalan con el número de pasos, y las tareas complejas tienen muchos pasos.
Hay un problema más sutil también: las llamadas a herramientas JSON constriñen cómo el agente puede componer acciones. Cada paso es una llamada a función única con argumentos literales. El modelo no puede expresar fácilmente "llama esta herramienta para cada elemento en esa lista", o "si el resultado está vacío, intenta una consulta diferente", o "combina estos dos resultados con un cálculo", sin romper cada una de esas en viajes separados de ida y vuelta y razonando sobre estado intermedio en llamadas del modelo. La expresividad de la programación ordinaria — bucles, condicionales, variables, composición — es exactamente lo que falta, y esas son las construcciones que hacen la lógica multi-paso natural. Las llamadas a herramientas piden al modelo que sea un contador de programa emitiendo una instrucción a la vez, cuando lo que la tarea necesita es un programa.
La visión de orientado a código
El enfoque orientado a código resuelve ambos problemas a la vez. En lugar de emitir una sola llamada a herramienta JSON, el agente escribe un bloque de código Python que puede llamar varias herramientas, usar control de flujo, mantener valores intermedios en variables y devolver un resultado. El runtime ejecuta ese código, y las herramientas que el agente puede llamar son simplemente funciones Python disponibles en su entorno de ejecución. La obtención de API, el filtrado y el cálculo del ejemplo anterior se convierten en un bloque de código único con tres llamadas a función y un poco de lógica entre ellas — ejecutado en un paso único, de una sola invocación de modelo.
La ganancia de eficiencia es real y medible. Porque un bloque de código puede lograr lo que previamente tomó varios viajes de ida y vuelta de llamada a herramienta, los agentes orientados a código hacen significativamente menos llamadas a LLM — reducciones reportadas alrededor del 30% — que reduce tanto costo como latencia. Y porque el agente expresa acciones en un lenguaje de programación real, maneja tareas composicionales (iterando sobre resultados, ramificándose en condiciones, combinando cálculos) mucho más naturalmente que una secuencia de llamadas JSON aisladas podría. También hay un argumento de datos de entrenamiento: los modelos han visto cantidades enormes de código y son genuinamente buenos en escribirlo, quizás mejor que son en producir JSON de llamada a herramienta perfectamente formateado para esquemas novedosos. Pedirle a un modelo que exprese su intención como código juega a una fortaleza.
smolagents: el paradigma en su forma más pura
smolagents, de Hugging Face, es la expresión más clara de la idea orientada a código. Es una librería deliberadamente minimalista construida alrededor del CodeAgent: un agente cuyas acciones son código Python. Dále un conjunto de herramientas (funciones Python ordinarias) y un modelo, entrégale una tarea, y funciona escribiendo y ejecutando código que llama esas herramientas, bucles y calcula hasta que tiene una respuesta. La librería se mantiene pequeña y modificable a propósito — su filosofía es que el bucle del agente debe ser lo suficientemente simple para leer y modificar, con la inteligencia viniendo del modelo y el enfoque de ejecución de código en lugar de un framework pesado.
Lo que hace smolagents convincente más allá de la eficiencia es lo naturalmente que maneja tareas reales. Porque el agente escribe código, una tarea de investigación puede buscar, analizar resultados, filtrarlos y calcular sobre ellos en un paso coherente; una tarea de datos puede cargar, transformar y analizar sin un viaje JSON de ida y vuelta por operación. Es agnóstico de modelo — funcionando con modelos de Hugging Face, modelos locales o cualquier proveedor a través de LiteLLM — así que no estás encerrado a un backend único, y soporta la ejecución sandboxeada que orientado a código fundamentalmente requiere (más sobre eso abajo). Para equipos que quieren la eficiencia orientada a código en un paquete pequeño y comprensible, smolagents es la implementación de referencia, y la hoja de trucos de smolagents cubre sus agentes, herramientas y sandboxing.
El compromiso del minimalismo de smolagents es que proporciona menos andamios que un framework pesado — menos abstracciones integradas para orquestación de agentes complejos, estado duradero o control de flujo elaborado. Para bucles de código de agente único eso es una característica, no una limitación; para sistemas duraderos amplios podrías alcanzar algo más pesado. Pero como la expresión más pura y eficiente de agentes orientados a código, es difícil de superar.
Pydantic AI: type safety encuentra agentes
Pydantic AI, del equipo detrás de Pydantic (la librería de validación que sustenta FastAPI y mucho del ecosistema de IA de Python), se aproxima a agentes desde un ángulo diferente: type safety y experiencia del desarrollador. Su apuesta es que el mismo rigor que Pydantic llevó a validación de datos — declarando la forma de tus datos con type hints de Python y obteniendo validación automática — debería aplicarse a agentes. Cada entrada, salida y llamada a herramienta del agente está tipificada, el framework valida que salidas del modelo coincidan la estructura esperada, y puede pedir automáticamente al modelo que se corrija cuando la salida no se conforma. El resultado es una experiencia estilo FastAPI para construir agentes: familiar, type-checked y orientado a producción.
Type safety importa para agentes más de lo que podría parecer. Un dolor recurrente de aplicaciones de LLM es que la salida del modelo es texto no estructurado, y convertirla confiablemente en los datos estructurados que tu programa necesita — los campos correctos, los tipos correctos, valores válidos — es complicado y propenso a errores. Pydantic AI hace salida estructurada una garantía de primera clase: declara el tipo de salida, y el framework lo refuerza, reintentando con el modelo si es necesario. Eso transforma "analiza el texto del modelo y espera que sea válido" en "recibe un objeto validado y tipificado", que es exactamente lo que el código de producción quiere. Su rediseño V2 en 2026 fue más lejos con un modelo orientado a arnés que agrupa herramientas, instrucciones y configuraciones en capacidades componibles. La hoja de trucos de Pydantic AI cubre sus agentes tipificados y herramientas.
Pydantic AI y smolagents no son realmente competidores sino expresiones de diferentes prioridades. smolagents optimiza por la eficiencia y expresividad del código-como-acción; Pydantic AI optimiza por type safety, salida estructurada validada y ergonomía de producción. Un equipo que valora menos llamadas a LLM y lógica multi-paso natural se inclina hacia smolagents; un equipo que valora code type-checked, validado y estilo FastAPI se inclina hacia Pydantic AI. Ambos representan el movimiento de 2026 lejos de los primeros frameworks de sólo JSON hacia algo más programador-nativo.
El problema de seguridad: ejecutar código generado por modelo
Los agentes orientados a código tienen un problema obvio y serio: ejecutan código escrito por un modelo de lenguaje, y código generado por modelo es no confiable por definición. Un agente que puede escribir y ejecutar Python arbitrario puede, si está comprometido por inyección de prompts o simplemente por estar equivocado, eliminar archivos, exfiltrar datos, hacer llamadas de red o consumir recursos sin límite. Esto no es una preocupación hipotética — es el riesgo operacional central de todo el paradigma, y tomarlo en serio es no negociable para cualquier despliegue de producción.
La respuesta es sandboxing: ejecuta el código generado en un entorno aislado con capacidades restringidas. Los frameworks soportan esto directamente — smolagents puede ejecutar código en sandboxes remotas como E2B, o en contenedores Docker o Modal, en lugar de en el proceso anfitrión, y puedes restringir qué módulos el código generado está incluso permitido importar. El principio es privilegio mínimo: el sandbox debe tener solo el acceso que la tarea genuinamente requiere — sin acceso al sistema de archivos que no necesita, sin egreso de red más allá de lo necesario, sin capacidad de afectar el anfitrión. Ejecutar código generado por agente directamente en tu proceso de aplicación, con permisos de tu aplicación, es el error que convierte un agente útil en una vulnerabilidad de ejecución de código remoto vistiendo una interfaz amigable.
La guía práctica es directa pero debe ser seguida. En desarrollo, ejecución local es conveniente y aceptable para tareas no sensibles y de confianza. En algo que se aproxime a producción, o cualquier tarea tocando entrada no confiable o sistemas sensibles, ejecuta el código en un sandbox con acceso de privilegio mínimo, restringe importaciones, y trata la salida de código del agente como tratarías cualquier entrada no confiable — porque eso es lo que es. La eficiencia y poder de agentes orientados a código son reales, pero vienen con una responsabilidad que las llamadas a herramientas JSON (que son más constreñidas por diseño) no impusieron tan bruscamente. Acepta esa responsabilidad y haz sandbox correctamente, y el paradigma es tanto poderoso como seguro.
Cuándo las llamadas a herramientas JSON aún son la elección correcta
Los agentes orientados a código son más eficientes y expresivos, pero sería un error concluir que las llamadas a herramientas JSON están obsoletas. Hay situaciones reales donde el modelo constreñido de una-llamada-a-la-vez es el mejor ajuste, y entenderlas mantiene la elección honesta. El más claro es cuando las acciones deben ser estrictamente controladas y auditadas. Una llamada a herramienta JSON es un evento discreto, inspectable, fácilmente validable: el agente quiere llamar esta función con estos argumentos, y puedes aprobarlo, registrarlo o rechazarlo antes de que algo se ejecute. Esa auditabilidad es valiosa en dominios de alto riesgo — acciones financieras, cambios de infraestructura, cualquier cosa con efectos irreversibles — donde quieres una comprobación humana o de política entre la intención del agente y su ejecución. Código que se ejecuta como un bloque es más difícil de acceder a esa granularidad.
El segundo caso es simplicidad. Muchos agentes genuinamente solo necesitan llamar una herramienta a la vez en un bucle directo — responder una pregunta llamando una herramienta de búsqueda, buscar algo, realizar una acción. Para esos, la expresividad de código-como-acción es capacidad no usada, y la maquinaria extra de un sandbox de código es sobrecarga sin beneficio. Un agente simple de llamada a herramientas es más fácil de razonar e desplegar cuando la tarea no necesita composición multi-paso. El tercer caso es postura de seguridad: porque las llamadas a herramientas JSON solo dejan que el agente invoque funciones predefinidas con argumentos estructurados, es inherentemente más constreñido que ejecutar código arbitrario, y para algunos modelos de amenaza ese radio de blast más pequeño vale el costo de eficiencia incluso cuando una tarea podrías beneficiarte del código.
La vista madura es que estas son dos herramientas para diferentes trabajos, no un ganador y un perdedor. Alcanza el código-first cuando las tareas involucran composición genuina multi-paso, iteración o cálculo sobre resultados intermedios, y puedes hacer sandbox correctamente. Alcanza las llamadas a herramientas JSON cuando las acciones necesitan control fino y auditoría, cuando la tarea es lo suficientemente simple que código-como-acción es sobrecarga, o cuando la restricción más apretada de funciones predefinidas solamente se adapta a tus requisitos de seguridad. Varios frameworks, incluyendo smolagents, soportan tanto un CodeAgent como un agente de llamada a herramientas exactamente por esta razón — el paradigma es una elección que haces por caso de uso, no una doctrina que adoptas al por mayor.
El resultado final
El movimiento de llamadas a herramientas JSON a agentes orientados a código es uno de los cambios significativos en cómo se construyen agentes en 2026, y está impulsado por una observación simple: dejar que un agente escriba código, en lugar de emitir una llamada a herramienta a la vez, es más eficiente y expresivo. Menos llamadas a LLM, lógica natural multi-paso y modelos jugando a su fortaleza de escritura de código son el resultado, visible en las reducciones de aproximadamente 30% de llamadas que los frameworks orientados a código reportan. smolagents expresa el paradigma en su forma más pura y minimalista; Pydantic AI trae type safety y salida estructurada validada a construcción de agentes. Ambos apuntan lejos de la primera generación de frameworks sólo JSON hacia algo más programador-nativo. La única regla que no puedes saltarte: código generado por modelo es no confiable, así que haz sandbox con privilegio mínimo. Haz eso, y los agentes orientados a código son la forma más rápida y capaz de construir.
Referencias y Recursos
Frameworks
Fondo y análisis
- The best open source frameworks for building AI agents in 2026 — Firecrawl
- Python AI Agent Library Comparison 2026 — Pydantic AI vs Instructor vs Smolagents
- Best Python AI Agent Frameworks in 2026 — Uvik
Hojas de trucos relacionadas de 1337skills