- ¿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 fundamentales de un flujo de trabajo agéntico?
- Por qué la planificación importa 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 evalúas 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 falla comunes en flujos de trabajo agénticos
- ¿Cuándo no deberías usar un flujo de trabajo agéntico?
- Preguntas frecuentes
- Artículos recomedados
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, eso 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 a un modelo una respuesta única y devolvérsela al usuario, permites que el modelo opere dentro de un bucle controlado:
- Lee el objetivo y el estado actual.
- Planifica el siguiente paso.
- Llama a una herramienta o ejecuta código.
- Observa el resultado.
- Evalúa si la tarea está completa.
- Repite 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 es importante 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 un cambio en el diseño de la página. 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 trie los 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 fundamentales 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 herramienta. 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 legible el próximo movimiento. Para tareas cortas, la planificación de un solo paso es suficiente. Para tareas más largas como refactorizaciones de repositorio, automatización del navegador o revisión de documentos, un plan explícito reduce el cambio constante.
2. Capa de herramientas
Las herramientas son la interfaz del flujo de trabajo con el mundo. Un nivel de herramientas sólido suele ser estrecho y predecible. Por ejemplo:
read_file(path)write_file(path, content)search_files(query)run_command(cmd)fetch_url(url)
Las herramientas pequeñas son más fáciles para que el modelo las llame correctamente, 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 las fallas vinieron 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 el sistema anfitrión directamente. Esta es la diferencia entre “el modelo sugirió un comando” y “el flujo de trabajo ejecutó ese comando de manera segura”.
4. Estado y memoria
Un flujo de trabajo agéntico necesita memoria de trabajo a través de los pasos. Eso generalmente incluye:
- estado de la conversación
- salidas de herramientas
- archivos intermédios
- registros de ejecución
- un bloc de notas o plan corto
Sin estado, cada paso se convierte en ingeniería de prompt sin estado, y el sistema se derrumba tan pronto como la tarea abarca más de una acción.
5. Bucle de evaluación
Esta es la parte que muchos equipos agregan demasiado tarde. El flujo de trabajo necesita una forma de juzgar si un paso tuvo éxito y si la tarea está terminada. En un flujo de trabajo de codificación, eso podría signifcar que las pruebas pasan. En un flujo de trabajo de investigación, podría signifcar que la respuesta cita suficientes fuentes confiables. En un flujo de trabajo de navegador, podría signifcar que el estado de UI esperado es visible.
Sin evaluación, “agéntico” a menudo se vuelve “sigue llamando herramientas hasta que se agote el tiempo”.
Por qué la planificación importa al construir flujos de trabajo agénticos
El error más grande al construir flujos de trabajo agénticos es asumir que el modelo debe improvisar todo desde cero en cada turno.
Eso generalmente crea tres problemas:
- el modelo revisa los mismos archivos o URL 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 planificación ligera más ejecución fundamentada. Deja que el modelo decida la próxima acción, pero hazlo contra 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 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 function calling, úsalo. La API LLM de Novita expone un endpoint compatible con OpenAI y documenta function calling directamente, 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 requeridos.
- Devuelve resultados completos, incluidos 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 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 falla.
¿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 ordinario. 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 sandbox 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 la falla 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 planificación y selección de herramientas
- Entorno de ejecución sandbox para ejecución y persistencia
Novita encaja esa división naturalmente: 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 evalúas un flujo de trabajo agéntico?
La evaluación tiene que ocurrir en dos niveles.
Evaluación a nivel de paso
¿Funcionó la última acción?
Ejemplos:
- ¿El comando salió con éxito?
- ¿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:
- ¿Las pruebas pasan 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 falla 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, falla o puertas de aprobación.
- El bucle continúa hasta que el flujo de trabajo termina o se bloquea.
Este bucle de controlador puede ser simple. En muchos casos, un solo proceso orquestador es suficiente. No necesitas un sistema multiagente desde el primer día. Comienza con un planificador, algunas herramientas bien definidas, un entorno de ejecución en sandbox y un evaluador claro.
Ejemplo: un controlador de flujo de trabajo agéntico en Python
El ejemplo a continuación 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": "Read a file from the workspace",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "run_command",
"description": "Run a shell command in the sandbox",
"parameters": {
"type": "object",
"properties": {"cmd": {"type": "string"}},
"required": ["cmd"],
},
},
},
]
def read_file(path: str) -> str:
# Implement this against your own workspace or sandbox filesystem.
raise NotImplementedError
def run_command(cmd: str) -> str:
# Implement this against your sandbox runtime.
raise NotImplementedError
dispatch = {
"read_file": read_file,
"run_command": run_command,
}
def run_workflow(task: str, model: str) -> str:
messages = [
{
"role": "system",
"content": (
"You are a workflow controller. Use tools when needed, "
"check results after each action, and stop when the task is complete."
),
},
{"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 agregarí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 correcta:
- llamada a herramientas confiable
- comportamiento estable en contexto largo
- 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 orientadas a la codificación. La página de modelos actual de Novita enumera acceso compatible con OpenAI, soporte de function calling, soporte de 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 con mucho razonamiento, elige primero la calidad de planificación. Para automatización de alto volumen, la latencia y el costo pueden importar tanto como la fortaleza en los benchmarks.
Modos de falla comunes en flujos de trabajo agénticos
La mayoría de las fallas no son dramáticas. Son repetitivas y costosas.
Exceso 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 “terminado” es verdadero, sigue generando un paso más.
Manejo de errores deficiente
Si las herramientas devuelven mensajes vagos como “falló” en lugar de resultados procesables, el modelo no puede recuperarse.
Sin límite de sandbox
El flujo de trabajo puede funcionar en desarrollo, pero se vuelve inseguro en el momento en que toca archivos reales, credenciales o sistemas externos.
Sin evaluador
El agente parece ocupado pero nunca demuestra 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 única
- la ruta es fija y rara vez cambia
- un programa tradicional puede decidir cada paso de manera económica
- no hay necesidad de uso de herramientas o ejecución
Por ejemplo, si tu aplicación siempre toma una entrada de formulario, llama a un prompt y devuelve un correo 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 continuar.
Si quieres un punto de partida de modelo de contexto largo, compara Macaron V1 Tall Quick Start on Novita AI y Qwen3.8-Max on Novita AI.
Preguntas frecuentes
¿Un flujo de trabajo agéntico es lo mismo que function calling?
No. Function calling es 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 solo bucle de controlador y algunas herramientas. Los diseños multiagente son útiles más adelante, pero no son el punto de partida prederterminado.
¿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 registro de herramientas pequeño, un entorno de ejecución en sandbox y un evaluador que pueda decidir cuándo la tarea está realmente terminada.
