En este artículo, aprenderá cómo decidir si una determinada funcionalidad del agente debe crearse como una herramienta o como un subagente, y cómo evitar realizar demasiada ingeniería en la arquitectura de su agente en el proceso.
Los temas que cubriremos incluyen:
Qué son las herramientas y los subagentes, y las diferencias clave entre ellos. Cuándo una herramienta es la mejor opción y cuándo un subagente merece la complejidad añadida. Cómo aplicar un marco de decisión simple de tres preguntas y cuánto cuesta realmente agregar subagentes.
Con ese marco establecido, veamos cómo encaja cada pieza.
Introducción
Cada agente de IA que crees llega eventualmente al mismo punto de decisión. Tiene una tarea que debe realizarse (llamar a una API, buscar en una base de datos, ejecutar un cálculo) y debe decidir: ¿debería ser una herramienta que el agente llame directamente o debería ser un agente separado que maneje el trabajo de forma independiente?
Si se hace mal en una dirección, se terminará con un agente inflado que intenta hacer demasiado en una única ventana contextual. Si se hace mal en la otra dirección, se agregará una sobrecarga de coordinación, llamadas LLM adicionales y complejidad de depuración a un problema que una función simple habría resuelto.
Este artículo explica qué son las herramientas y los subagentes, dónde encaja cada uno y cómo elegir cada vez.
¿Qué herramientas son?
Una herramienta es una capacidad que utiliza un agente para interactuar con sistemas externos y realizar acciones más allá del conocimiento integrado del modelo. En la práctica, las herramientas suelen ser funciones, llamadas API, consultas de bases de datos, búsquedas, operaciones de archivos u otro código ejecutable expuesto al modelo a través de una interfaz definida.
Una interacción de herramienta típica se ve así:
El modelo recibe una tarea y determina que se necesita información externa o una acción. El modelo genera una llamada de herramienta estructurada con los argumentos requeridos. Su aplicación ejecuta la herramienta y devuelve un resultado. El resultado se vuelve a agregar a la conversación, lo que permite que el modelo continúe razonando y decida qué hacer a continuación.
La distinción importante es que las herramientas no realizan el razonamiento por sí mismas. Ejecutan operaciones predefinidas y devuelven datos. El modelo maneja la planificación, interpretación y toma de decisiones en torno a esas operaciones.
Las herramientas son la principal forma en que los agentes interactúan con el mundo exterior. Pueden consultar una base de datos, llamar a una API, buscar en la web, leer archivos, ejecutar cálculos o activar flujos de trabajo. Debido a que las herramientas ejecutan código en lugar de ejecutar otro LLM, suelen ser rápidas, deterministas y económicas en comparación con generar un subagente.
¿Qué son los subagentes?
Un subagente es una llamada LLM separada (generalmente una instancia de agente distinta con su propio sistema, su propia ventana de contexto y, a menudo, su propio conjunto de herramientas) que recibe una tarea, la ejecuta de forma independiente y devuelve un resultado al agente orquestador.
Desde la perspectiva del orquestador, llamar a un subagente parece idéntico a llamar a una herramienta: envía una tarea y obtiene un resultado. La diferencia es lo que sucede en el medio. Un subagente ejecuta su propio ciclo de razonamiento de varios pasos, potencialmente realiza sus propias llamadas a herramientas y administra su propio estado. El orquestador no tiene visibilidad de ese proceso; solo obtiene el resumen al final.
Herramientas vs Subagentes
Herramientas frente a subagentes: las diferencias clave
Las herramientas ejecutan código. Los subagentes ejecutan el razonamiento.
Aspecto Herramientas Subagentes Qué se ejecuta Su código Otra ventana contextual de LLM Compartida con el orquestador Separado, aislado Razonamiento Ninguno; ejecución determinista Bucle de razonamiento completo de varios pasos Manejo de errores Devoluciones estructuradas, reintento en el mismo bucle El subagente maneja internamente o se muestra al orquestador Costo Solo costo de ejecución Llamadas LLM adicionales Latencia baja; una llamada de función Superior; ciclo de inferencia completo Visibilidad completa; resulta en el contexto del orquestador Parcial; El orquestador solo ve el resumen Cuando se rompe Esquema incorrecto, falla de API, argumentos incorrectos Alucinaciones en el subagente, contexto perdido, falla de coordinación
La distinción de la ventana de contexto importa más de lo que parece a primera vista. Cuando un agente llama a una herramienta, el resultado regresa al mismo contexto en el que el agente está razonando activamente: razonamiento previo, resultado de la herramienta y todo lo demás junto. Cuando un orquestador genera un subagente, ese subagente comienza de nuevo solo con lo que le pasó el orquestador.
Cuándo utilizar una herramienta
Utilice una herramienta cuando la operación esté bien definida, tenga un comportamiento determinista y no requiera un razonamiento de varios pasos para completarse.
Llame a una API externa. Tareas como recuperar un registro de usuario, publicar en Slack o consultar una base de datos son tareas puramente de ejecución. La modelo decide llamarlos; tu código los ejecuta.
Transformar o validar datos. Ejecutar una expresión regular, formatear una fecha, calcular un hash o convertir unidades. Las operaciones deterministas pertenecen a funciones, no a llamadas LLM.
Leer o escribir archivos. Abrir un archivo, escribir resultados, comprobar si existe algo. Las operaciones del sistema de archivos son predecibles y rápidas cuando se implementan como llamadas directas a herramientas.
Ejecute una búsqueda. Búsqueda semántica sobre una base de datos vectorial, consulta SQL sobre una base de datos, búsqueda web. La búsqueda en sí se ejecuta de forma determinista y arroja resultados. El modelo interpreta esos resultados, pero la búsqueda se ejecuta como una herramienta.
La prueba práctica: si puedes escribir el comportamiento como una función de Python con entradas y salidas escritas, y no necesita razonar a través de múltiples pasos, debería ser una herramienta.
Cuándo utilizar un subagente
Utilice un subagente cuando la tarea requiera un razonamiento de varios pasos, cuando el trabajo intermedio crearía ruido en el contexto del orquestador o cuando las tareas puedan ejecutarse en paralelo.
La tarea tiene pasos intermedios no obvios. “Investigar el panorama competitivo para X” implica decidir qué buscar, leer los resultados, decidir qué buscar a continuación, sintetizar fuentes y producir un resumen estructurado. Cada paso depende del anterior. Ése es un proceso de razonamiento y pertenece a su propio contexto.
El trabajo se puede paralelizar. El procesamiento de k documentos de forma independiente se ejecuta más rápido entre k subagentes simultáneos que de forma secuencial en un contexto. El marco AutoGen de Microsoft se basa en parte en este patrón, coordinando agentes especializados que trabajan en paralelo en subtareas independientes.
La subtarea necesita su propio conjunto de herramientas. Un subagente de escritura de código necesita un ejecutor de código y herramientas de sistema de archivos. Un subagente de investigación necesita herramientas de búsqueda y documentos en la web. Darle al orquestador acceso a todos estos crea una sobrecarga de herramientas. La investigación sobre la llamada de herramientas a agentes confirma que la precisión se degrada a medida que aumenta el número de herramientas. Las herramientas de alcance por subagente mantienen pequeño el espacio de decisión de cada agente.
La salida intermedia introduciría ruido en el contexto del orquestador. Un único resultado de consulta de base de datos es compacto y útil en contexto. Una síntesis de investigación de varios pasos que abarca docenas de documentos recuperados es ruido. Aislar ese trabajo en un subagente y sacar a la luz sólo la conclusión mantiene limpio el razonamiento del orquestador.
Cuando usar subagentes
El aislamiento del contexto mejora la confiabilidad. Un subagente que trabaja en un contexto nuevo no puede distraerse con la historia acumulada del orquestador. Para tareas en las que el enfoque es importante, como la generación de código, la extracción de datos estructurados o el análisis de varios pasos, el aislamiento tiende a producir resultados más consistentes.
El marco de decisión
La mayoría de las decisiones se reducen a tres preguntas.
1. ¿La tarea es principalmente ejecución o razonamiento?
Si la tarea es una operación bien definida con entradas y salidas predecibles, una herramienta suele ser la elección correcta. Las consultas de bases de datos, llamadas API, búsquedas, cálculos y operaciones de archivos entran en esta categoría.
Si la tarea requiere explorar, analizar, sintetizar o tomar una serie de decisiones donde cada paso depende del anterior, suele ser más adecuado para un subagente.
2. ¿El trabajo intermedio le importa al orquestador?
Los resultados de las herramientas suelen ser lo suficientemente pequeños y útiles como para mantenerlos directamente en el contexto del orquestador. Un registro de base de datos, un resultado de búsqueda o una respuesta de API a menudo se pueden consumir inmediatamente.
Cuando una tarea genera grandes cantidades de trabajo intermedio (múltiples búsquedas, revisiones de documentos, iteraciones o análisis), un subagente puede mantener ese trabajo aislado y devolver solo la conclusión final.
3. ¿Se puede ejecutar la tarea de forma independiente?
Una herramienta se ejecuta como parte del flujo de trabajo del orquestador y devuelve un resultado antes de que el flujo de trabajo continúe.
Un subagente suele ser más adecuado cuando el trabajo se puede delegar, ejecutar de forma independiente o ejecutar en paralelo con otras tareas. Esto es especialmente útil al procesar múltiples documentos, investigar múltiples temas o coordinar flujos de trabajo especializados.
Las herramientas son las mejores para la ejecución determinista:
Obtener datos de una base de datos, API o sistema de búsqueda Ejecutar cálculos, transformaciones o validaciones Leer, escribir o actualizar archivos y registros
Los subagentes son mejores para tareas de razonamiento acotado:
Investigar un tema y sintetizar hallazgos a través de fuentes Escribir, revisar y refinar contenido complejo Analizar grandes colecciones de documentos o datos en paralelo
La trampa de la sobreingeniería
El error más común es introducir subagentes antes de que realmente sean necesarios.
Un subagente puede hacer que una arquitectura sea más limpia, pero también agrega complejidad. Cada subagente introduce otra ventana de contexto, otro bucle de razonamiento y otro traspaso entre componentes. Eso significa más latencia, más costo y más partes móviles para depurar.
En muchos casos, basta con una herramienta bien diseñada. Si una tarea se puede completar mediante una llamada API sencilla, una consulta de base de datos, una búsqueda u otra operación determinista, agregar un agente independiente a menudo genera más gastos generales que valor.
Como regla general, comience con un único agente y un pequeño conjunto de herramientas bien diseñadas. Introduzca subagentes solo cuando resuelvan un problema específico que las herramientas no pueden resolver de manera limpia, como aislar grandes cantidades de trabajo intermedio, permitir la ejecución paralela o darle a una tarea compleja su propio espacio de razonamiento dedicado.
Una pregunta útil es: “¿Qué me compra realmente el subagente?”
Si la respuesta es solo una pequeña cantidad de procesamiento antes de devolver un resultado, probablemente una herramienta sea suficiente. Si la respuesta es razonamiento independiente, aislamiento del contexto, capacidades especializadas o ejecución paralela, probablemente esté justificado un subagente.
Las herramientas deben ser las predeterminadas. Los subagentes deben introducirse cuando proporcionen una clara ventaja arquitectónica.
Lo que realmente cuesta agregar subagentes
Llamar a una herramienta es simple: proporcione entradas, obtenga un resultado. Llamar a un subagente es diferente. También estás delegando parte del proceso de pensamiento.
Eso significa que el orquestador debe definir la tarea con suficiente claridad para que el subagente pueda trabajar de forma independiente. El subagente no hereda automáticamente los objetivos, las suposiciones ni el historial de conversaciones completo del orquestador. Sólo sabe lo que le dieron.
Como resultado, las buenas arquitecturas de subagente dependen de transferencias claras:
El orquestador envía una tarea centrada y autónoma. El subagente realiza su propio razonamiento y uso de herramientas. El subagente devuelve un resultado conciso que el orquestador puede utilizar.
Por ejemplo, un subagente de investigación podría devolver: "Identifiqué tres competidores, junto con sus modelos de precios y diferenciadores clave".
Por lo general, no debería devolver todas las consultas de búsqueda, extractos de documentos y observaciones intermedias que llevaron a esa conclusión.
Mantener los límites limpios tiene dos beneficios. Primero, evita que el contexto del orquestador se llene con trabajo intermedio innecesario. En segundo lugar, hace que el sistema sea más fácil de entender y depurar porque cada subagente tiene una responsabilidad clara y un resultado bien definido.
Subagentes en la práctica
Una regla general útil es: pasar las tareas; Pasar las conclusiones de nuevo. Una tarea limpia y un resumen limpio es el contrato que mantiene la depuración de los sistemas multiagente. Los sistemas que permiten a los subagentes compartir estados mutables o transmitir resultados parciales a mitad de la tarea introducen una complejidad de coordinación que rápidamente supera el problema original.
Resumen
Elegir entre herramientas y subagentes es una decisión arquitectónica clave en los sistemas agentes. Si bien ambos ayudan a realizar tareas, difieren significativamente en el modelo de ejecución, las capacidades de razonamiento, el costo y la complejidad operativa. La siguiente comparación resalta cuándo cada enfoque es más apropiado.
Herramientas conceptuales Subagentes Qué ejecuta Su código Otro LLM con su propio ciclo de razonamiento Lo mejor para ejecución determinista: llamadas API, búsquedas, cálculos, operaciones de archivos Razonamiento complejo: investigación, generación de código, procesamiento paralelo Contexto Compartido con el orquestador Aislado; nueva ventana de contexto por tarea Costo Solo costo de ejecución Una o más llamadas LLM adicionales Latencia Baja Mayor Depuración Alta; resultado visible en el contexto del orquestador Inferior; los pasos internos son opacos Cuándo alcanzarlo La tarea se puede escribir como una función determinista La tarea necesita razonamiento de varios pasos, paralelismo o aislamiento de herramientas Riesgo de sobreingeniería Bajo Alto; agrega sobrecarga de coordinación si se usa prematuramente Contrato de comunicación Entrada de función escrita → retorno de salida estructurada Cadena de tarea autónoma → cadena de resumen Comenzar aquí Sí; por defecto a las herramientas primero Sólo cuando las herramientas alcanzan un límite concreto
Esta separación mantiene los sistemas simples de forma predeterminada, al tiempo que permite agregar subagentes solo cuando el diseño basado en herramientas ya no es suficiente.