- ¿Qué es un flujo de trabajo agéntico?
- ¿En qué se diferencia un flujo de trabajo agéntico de un agente de IA?
- ¿Cuáles son las partes centrales de un flujo de trabajo agéntico?
- Por qué la planificación es importante al construir flujos de trabajo agénticos
- ¿Cómo debería funcionar el uso de herramientas en un flujo de trabajo agéntico?
- ¿Por qué la ejecución de código necesita un sandbox?
- ¿Cómo se evalúa un flujo de trabajo agéntico?
- Una arquitectura práctica para construir flujos de trabajo agénticos
- Ejemplo: un controlador de flujo de trabajo agéntico en Python
- ¿Qué modelo deberías usar como planificador?
- Modos de fallo comunes en flujos de trabajo agénticos
- ¿Cuándo no deberías usar un flujo de trabajo agéntico?
- FAQ
- Artículos recomendados
Un flujo de trabajo agéntico es un sistema de múltiples pasos donde un modelo de lenguaje hace más que responder una sola vez: planifica, elige herramientas, ejecuta acciones, verifica el resultado y decide qué hacer a continuación hasta que la tarea esté completa. En la práctica, esto significa combinar una capa de razonamiento LLM con llamadas a herramientas, un entorno de ejecución real y un bucle de evaluación. Si estás construyendo agentes de codificación, agentes de investigación o automatización interna que deba adaptarse durante la tarea, esta suele ser la arquitectura que realmente estás construyendo.
¿Qué es un flujo de trabajo agéntico?
Un flujo de trabajo agéntico es el patrón detrás de los sistemas de IA que pueden avanzar en una tarea en lugar de detenerse en la generación de texto. En lugar de pedirle al modelo una respuesta y devolvérsela al usuario, permites que el modelo opere dentro de un bucle controlado:
- Leer el objetivo y el estado actual.
- Planificar el siguiente paso.
- Llamar a una herramienta o ejecutar código.
- Observar el resultado.
- Evaluar si la tarea está completa.
- Repetir si es necesario.
Esto es diferente de un flujo de trabajo fijo, donde cada paso está preescrito en código. En un flujo de trabajo fijo, decides la ruta de antemano. En un flujo de trabajo agéntico, el modelo decide qué acción tomar a continuación dentro de los límites que proporcionas.
Esa distinción importa porque muchas tareas reales de desarrollo no son lineales. Un agente de codificación puede necesitar inspeccionar archivos antes de saber qué prueba ejecutar. Un agente de investigación puede necesitar buscar dos veces porque la primera fuente estaba incompleta. Un agente de navegador puede necesitar recuperarse de un fallo de inicio de sesión o de un diseño de página cambiado. Esos son problemas de flujo de trabajo, pero requieren adaptación.
¿En qué se diferencia un flujo de trabajo agéntico de un agente de IA?
Las personas suelen usar los dos términos indistintamente, pero es más útil separarlos:
- Un flujo de trabajo agéntico es el patrón de ejecución.
- Un agente de IA es el producto o sistema construido sobre ese patrón.
Puedes tener un flujo de trabajo agéntico de alcance limitado que solo clasifique tickets de soporte, o un agente de IA más amplio que coordine planificación, uso de herramientas, memoria y puntos de control de aprobación en muchas tareas.
Si quieres una regla práctica, usa flujo de trabajo cuando hables de arquitectura y flujo de control, y usa agente cuando hables del sistema orientado al usuario.
¿Cuáles son las partes centrales de un flujo de trabajo agéntico?
La mayoría de los sistemas en producción terminan teniendo las mismas cinco partes.
1. Planificador
El planificador convierte una instrucción amplia en la siguiente acción concreta. A veces, esto es un paso de planificación explícito que genera una lista de tareas. A veces es implícito y ocurre dentro de cada turno de llamada a herramientas. De cualquier manera, el modelo necesita suficiente contexto para decidir si debe leer, escribir, buscar, ejecutar o detenerse.
Una buena planificación no significa generar un esquema extenso para cada solicitud. Significa mantener el próximo movimiento legible. Para tareas cortas, la planificación de un solo paso es suficiente. Para tareas más largas, como refactorizaciones de repositorios, automatización de navegadores o revisión de documentos, un plan explícito reduce la ineficiencia.
2. Capa de herramientas
Las herramientas son la interfaz del flujo de trabajo con el mundo. Una capa de herramientas sólida suele ser estrecha y predecible. Por ejemplo:
read_file(ruta)write_file(ruta, contenido)search_files(consulta)run_command(comando)fetch_url(url)
Las herramientas pequeñas son más fáciles de llamar correctamente para el modelo, más fáciles de registrar y más fáciles de asegurar. Las herramientas grandes de “hacer de todo” parecen convenientes al principio, pero se vuelven difíciles de depurar porque no puedes saber si los fallos provinieron de la decisión del modelo, la implementación de la herramienta o el sistema externo detrás de ella.
3. Entorno de ejecución
Una vez que el modelo decide actuar, algo tiene que ejecutar la acción. Para cualquier flujo de trabajo que escriba archivos, instale paquetes, ejecute código o abra sesiones de navegador, este entorno de ejecución necesita aislamiento.
Ahí es donde entra un sandbox. Novita Agent Sandbox está diseñado para esta capa de ejecución: un entorno separado donde las acciones del agente pueden ejecutarse sin tocar directamente el sistema anfitrión. Esta es la diferencia entre “el modelo sugirió un comando” y “el flujo de trabajo ejecutó ese comando de forma segura”.
4. Estado y memoria
Un flujo de trabajo agéntico necesita memoria de trabajo a lo largo de los pasos. Eso generalmente incluye:
- estado de la conversación
- salidas de herramientas
- archivos intermedios
- registros de ejecución
- un bloc de notas o plan corto
Sin estado, cada paso se convierte en ingeniería de prompts sin estado, y el sistema se desmorona tan pronto como la tarea abarca más de una acción.
5. Bucle de evaluación
Esta es la parte que muchos equipos añaden demasiado tarde. El flujo de trabajo necesita una forma de juzgar si un paso tuvo éxito y si la tarea está hecha. En un flujo de trabajo de codificación, eso podría significar que las pruebas pasen. En un flujo de trabajo de investigación, podría significar que la respuesta cite suficientes fuentes confiables. En un flujo de trabajo de navegador, podría significar que el estado esperado de la interfaz de usuario sea visible.
Sin evaluación, “agéntico” a menudo se convierte en “sigue llamando herramientas hasta que se agote el tiempo de espera”.
Por qué la planificación es importante al construir flujos de trabajo agénticos
El mayor error al construir flujos de trabajo agénticos es asumir que el modelo debería improvisar todo desde cero en cada turno.
Eso generalmente crea tres problemas:
- el modelo revisa los mismos archivos o URLs repetidamente
- el uso de herramientas se vuelve ruidoso y costoso
- el flujo de trabajo pierde una condición de parada clara
Un mejor patrón es la planificación ligera más la ejecución fundamentada. Deja que el modelo decida la siguiente acción, pero hazlo con una tarea explícita, un estado actual visible y un pequeño conjunto de herramientas permitidas. Eso mantiene la flexibilidad donde ayuda y la elimina donde no.
En flujos de trabajo de codificación, la planificación a menudo se ve así:
- Identificar los archivos involucrados.
- Leer la implementación actual.
- Decidir el cambio mínimo.
- Hacer la edición.
- Ejecutar la verificación.
- Detenerse o reparar.
Esto sigue siendo agéntico, porque el modelo puede ramificarse cuando el repositorio lo sorprende. Pero no está deambulando.
¿Cómo debería funcionar el uso de herramientas en un flujo de trabajo agéntico?
El uso de herramientas debe ser explícito, tipado y observable.
Si tu modelo admite llamadas a funciones, úsalo. La API LLM de Novita expone un endpoint compatible con OpenAI y documenta directamente las llamadas a funciones, que es la forma más limpia de permitir que el modelo elija entre herramientas sin depender de un análisis de cadenas frágil.
Algunas reglas hacen que el uso de herramientas sea mucho más confiable:
- Mantén los nombres de las herramientas concretos.
- Usa esquemas con campos obligatorios.
- Devuelve resultados completos, incluidos los errores.
- Registra cada llamada, argumento y salida.
- Haz que las acciones destructivas sean raras y fáciles de controlar.
La capa de herramientas también debe reflejar los límites reales. Por ejemplo, no le des a un agente de codificación una megaherramienta llamada edit_repo_and_run_tests. Divide los pasos de lectura, escritura y ejecución para que el modelo pueda recuperarse cuando algo falle.
¿Por qué la ejecución de código necesita un sandbox?
Un flujo de trabajo agéntico que nunca ejecuta nada a menudo puede permanecer dentro de un servidor de aplicaciones normal. En el momento en que comienza a ejecutar comandos de shell, instalar dependencias, manejar archivos descargados o navegar por la web abierta, necesitas aislamiento.
El sandboxing resuelve dos problemas diferentes:
- Seguridad: el código generado y las salidas de las herramientas pueden ser incorrectos, hostiles o simplemente impredecibles.
- Estado: las tareas de múltiples pasos necesitan un espacio de trabajo persistente donde los archivos, paquetes y el historial de ejecución sobrevivan a través de los turnos.
Para muchos equipos, el segundo punto es tan importante como el primero. Un flujo de trabajo que edita código, ejecuta pruebas, corrige el fallo y vuelve a ejecutar la verificación no es posible si cada paso comienza desde una máquina limpia.
Por eso, la arquitectura práctica suele ser:
- API LLM para la planificación y selección de herramientas
- Entorno sandbox para la ejecución y persistencia
Novita se adapta naturalmente a esa división: la API LLM actúa como la capa de planificación y llamada a herramientas, mientras que Agent Sandbox maneja el entorno de ejecución real.
¿Cómo se evalúa un flujo de trabajo agéntico?
La evaluación debe ocurrir en dos niveles.
Evaluación a nivel de paso
¿Funcionó la última acción?
Ejemplos:
- ¿El comando salió exitosamente?
- ¿La API devolvió JSON válido?
- ¿Se creó el archivo esperado?
- ¿La página del navegador contenía el elemento objetivo?
Evaluación a nivel de tarea
¿El flujo de trabajo resolvió el problema del usuario?
Ejemplos:
- ¿Pasan las pruebas después del cambio de código?
- ¿El resumen responde a la pregunta de investigación con evidencia?
- ¿La automatización completó la transacción sin limpieza manual?
Los flujos de trabajo sólidos usan ambos. Si solo evalúas la salida final, te pierdes señales de fallo obvias durante la ejecución. Si solo evalúas pasos, el flujo de trabajo puede completar una larga serie de acciones localmente válidas y aún así fallar en la tarea real.
Una arquitectura práctica para construir flujos de trabajo agénticos
Aquí está la arquitectura con la que la mayoría de los equipos deberían comenzar:
- Una solicitud de usuario ingresa a tu aplicación.
- Tu controlador envía el objetivo, el estado y las herramientas disponibles a un LLM.
- El LLM devuelve una respuesta directa o una llamada a herramienta.
- Tu controlador ejecuta la herramienta dentro de un sandbox u otro entorno controlado.
- El resultado de la herramienta se agrega al estado de la conversación.
- Un evaluador verifica si hay finalización, fallo o puntos de control de aprobación.
- El bucle continúa hasta que el flujo de trabajo está terminado o bloqueado.
Este bucle de controlador puede ser simple. En muchos casos, un solo proceso orquestador es suficiente. No necesitas un sistema multigente desde el primer día. Comienza con un planificador, algunas herramientas bien definidas, un entorno sandbox y un evaluador claro.
Ejemplo: un controlador de flujo de trabajo agéntico en Python
El siguiente ejemplo muestra la forma del bucle de control. Utiliza la API compatible con OpenAI de Novita para llamadas a herramientas. Las funciones de ejecución son tuyas para implementar contra tu propio entorno de ejecución o sandbox.
import json
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.novita.ai/openai",
api_key=os.environ["NOVITA_API_KEY"],
)
tools = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Lee un archivo del espacio de trabajo",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "run_command",
"description": "Ejecuta un comando de shell en el sandbox",
"parameters": {
"type": "object",
"properties": {"cmd": {"type": "string"}},
"required": ["cmd"],
},
},
},
]
def read_file(path: str) -> str:
# Implementa esto contra tu propio espacio de trabajo o sistema de archivos sandbox.
raise NotImplementedError
def run_command(cmd: str) -> str:
# Implementa esto contra tu entorno de ejecución sandbox.
raise NotImplementedError
dispatch = {
"read_file": read_file,
"run_command": run_command,
}
def run_workflow(task: str, model: str) -> str:
messages = [
{
"role": "system",
"content": (
"Eres un controlador de flujo de trabajo. Usa herramientas cuando sea necesario, "
"verifica los resultados después de cada acción y detente cuando la tarea esté completa."
),
},
{"role": "user", "content": task},
]
while True:
response = client.chat.completions.create(
model=model,
messages=messages,
tools=tools,
tool_choice="auto",
)
message = response.choices[0].message
messages.append(message)
if not message.tool_calls:
return message.content
for call in message.tool_calls:
fn = dispatch[call.function.name]
args = json.loads(call.function.arguments)
result = fn(**args)
messages.append(
{
"role": "tool",
"tool_call_id": call.id,
"content": result,
}
)
Esto es intencionalmente mínimo. En producción, también añadirías:
- política de reintentos para errores transitorios
- tiempos de espera y límites de presupuesto
- aprobación humana para acciones sensibles
- registros de pasos estructurados
- un evaluador a nivel de tarea antes de la finalización
¿Qué modelo deberías usar como planificador?
Para un flujo de trabajo agéntico, el modelo planificador no solo necesita inteligencia bruta. Necesita la forma adecuada:
- llamadas a herramientas confiables
- comportamiento estable en contextos largos
- fuerte seguimiento de instrucciones
- latencia predecible en múltiples turnos
Si quieres un punto de partida de peso abierto en Novita, Qwen3 Coder 30B A3B Instruct es una opción práctica para la planificación de flujos de trabajo y el uso de herramientas orientado a la codificación. La página de modelos actual de Novita enumera acceso compatible con OpenAI, soporte para llamadas a funciones, soporte para salida estructurada y una ventana de contexto alojada de 160K. Para muchas tareas de automatización interna y codificación, eso es suficiente para construir una primera versión seria antes de pasar a un planificador más grande o más especializado.
El modelo correcto aún depende del trabajo. Para flujos de trabajo amplios y con mucho razonamiento, elige primero la calidad de la planificación. Para automatización de alto volumen, la latencia y el costo pueden importar tanto como la solidez de los puntos de referencia.
Modos de fallo comunes en flujos de trabajo agénticos
La mayoría de los fallos no son dramáticos. Son repetitivos y costosos.
Uso excesivo de herramientas
Si cada capacidad se convierte en su propia dependencia remota, el flujo de trabajo pasa más tiempo coordinando que haciendo trabajo útil.
Reglas de parada débiles
Si el sistema nunca sabe cuándo está “hecho”, sigue generando un paso más.
Manejo de errores deficiente
Si las herramientas devuelven mensajes vagos como “falló” en lugar de una salida procesable, el modelo no puede recuperarse.
Sin límite de sandbox
El flujo de trabajo puede funcionar en desarrollo, pero volverse inseguro en el momento en que toca archivos reales, credenciales o sistemas externos.
Sin evaluador
El agente parece ocupado pero nunca prueba que la tarea se completó correctamente.
¿Cuándo no deberías usar un flujo de trabajo agéntico?
No construyas uno solo porque el término es popular.
Probablemente no necesitas un flujo de trabajo agéntico si:
- la tarea es generación de una sola vez
- la ruta es fija y rara vez cambia
- un programa tradicional puede decidir cada paso de forma económica
- no hay necesidad de usar herramientas o ejecución
Por ejemplo, si tu aplicación siempre toma una entrada de formulario, llama a un prompt y devuelve un correo electrónico formateado, un flujo de trabajo LLM ordinario es más simple y mejor.
Los flujos de trabajo agénticos valen la pena cuando el entorno puede sorprender al sistema y el sistema aún necesita seguir adelante.
FAQ
¿Es un flujo de trabajo agéntico lo mismo que las llamadas a funciones?
No. Las llamadas a funciones son un mecanismo dentro del flujo de trabajo. El flujo de trabajo completo también necesita flujo de control, estado, ejecución y evaluación.
¿Necesito múltiples agentes para construir flujos de trabajo agénticos?
No. La mayoría de los equipos deberían comenzar con un bucle de controlador y algunas herramientas. Los diseños multigente son útiles más adelante, pero no son el punto de partida predeterminado.
¿Cuál es el control de seguridad más importante?
Para flujos de trabajo que ejecutan código o tocan sistemas externos, el control más importante es un entorno de ejecución aislado combinado con permisos de herramientas estrechos.
¿Cuál es la pila más simple lista para producción?
Una buena primera pila es: una API LLM compatible con OpenAI, un pequeño registro de herramientas, un entorno de ejecución sandbox y un evaluador que pueda decidir cuándo la tarea está realmente hecha.
