En este artículo, aprenderá las diferencias clave entre los flujos de trabajo de IA y los agentes, y cómo decidir qué enfoque es el adecuado para su caso de uso antes de escribir una sola línea de código.
Los temas que cubriremos incluyen:
Qué distingue un flujo de trabajo de un agente, utilizando ejemplos concretos de cada uno. Una prueba única y práctica para determinar si su aplicación realmente requiere un agente. Una lista de verificación de cinco puntos para guiar su decisión antes de construir.
“Agente” se ha convertido en una de las palabras más utilizadas en IA.
Un chatbot con tres herramientas se llama agente. Una canalización fija de procesamiento de documentos se denomina agente. Una automatización programada se denomina agente. A veces, también se llama agente a un sistema genuinamente autónomo que planifica, actúa, observa resultados y cambia su estrategia.
Debido a todo este revuelo, las personas a menudo confían en agentes incluso cuando su aplicación en realidad no los necesita.
Entonces, antes de continuar, comprendamos brevemente qué es un agente y qué es un flujo de trabajo.
¿Qué es un flujo de trabajo?
Un flujo de trabajo, también llamado canalización o cadena, es un sistema donde el flujo de control se fija en el momento del diseño.
El desarrollador decide de antemano la secuencia de pasos, bifurcaciones, condiciones de parada y otra lógica. Aún puedes usar un LLM para uno o más pasos, lo que lo convierte en un sistema híbrido, pero el camino general está predeterminado.
Por ejemplo, si tiene que procesar reembolsos de clientes, su flujo de trabajo podría verse así:
Puedes ver que hay decisiones aquí. También hay LLM y herramientas.
Pero sigue siendo fundamentalmente un flujo de trabajo porque los posibles caminos se diseñan de antemano. Puede dibujar el diagrama de estado antes de recibir la solicitud del cliente.
¿Qué es un agente?
Un agente es un sistema donde el propio LLM decide qué hacer a continuación en tiempo de ejecución.
Recibe un objetivo, tiene acceso a herramientas y decide qué herramienta llamar, en qué orden y cuándo detenerse. Puede retroceder, hacer un bucle o recopilar más información dependiendo de lo que descubra.
En otras palabras, el flujo de control vive con el modelo.
Supongamos que tiene una interrupción de la producción y desea responder esta pregunta:
Descubra por qué las fallas en el proceso de pago aumentaron en los últimos 30 minutos y encuentre una posible causa raíz.
Puede brindarle al sistema herramientas para consultar registros y métricas, buscar rastros de errores y leer documentos de incidentes. Pero no se puede saber de antemano con certeza cuál debería ser la secuencia correcta de acciones.
Para un incidente, podría servir:
Verifique la tasa de errores → inspeccionar la implementación reciente → inspeccionar los seguimientos de la pila → identificar la llamada de base de datos fallida → verificar la latencia de la base de datos
Controlar error tasa
→ inspeccionar reciente despliegue
→ inspeccionar pila rastros
→ identificar defecto base de datos llamar
→ verificar base de datos estado latente
Para otro incidente, podría servir:
Verifique la tasa de errores → segmente fallas por región → inspeccione el estado de CDN → inspeccione errores de DNS → identifique la interrupción del proveedor regional
Controlar error tasa
→ segmento fracasos por región
→ inspeccionar CDN estado
→ inspeccionar DNS errores
→ identificar regional proveedor corte
Aquí, la observación después de cada acción determina lo que hace el sistema a continuación. Eso es lo que lo hace agente.
La prueba práctica única
Hágase una pregunta antes de escribir cualquier código:
¿Puedes dibujar un diagrama de flujo completo de la tarea antes de que se ejecute el LLM?
En caso afirmativo, y cada paso y rama importante se puede enumerar con una confianza razonable, cree un flujo de trabajo. Si el siguiente paso depende de lo que el sistema descubre durante la ejecución (como datos nuevos, resultados inesperados de la herramienta o hallazgos intermedios), probablemente necesite un agente.
Esta única prueba puede eliminar muchos agentes innecesarios.
Si un ingeniero competente puede describir el proceso en una pizarra utilizando un número razonable de pasos condicionales, la flexibilidad adicional de un agente generalmente no justifica la complejidad adicional.
Un error común es asumir:
Flujo de trabajo = sencillo
Agente = sofisticado
Eso no es cierto.
Un flujo de trabajo puede contener múltiples llamadas de LLM, recuperación, llamadas de herramientas, lógica de reintento, aprobaciones humanas y reglas comerciales complicadas.
Al mismo tiempo, un sistema muy simple puede seguir siendo agente si el propio modelo decide lo que sucede a continuación.
Entonces, antes de tomar una decisión, revise la lista de verificación a continuación.
Una lista de verificación simple antes de construir
1. ¿Puedo enumerar los pasos y ramas principales antes del tiempo de ejecución?
Sí → Flujo de trabajo
Por ejemplo, si desea extraer información de un contrato y guardarla en una base de datos, ya conoce los pasos generales.
Lea el contrato, extraiga los campos, valídelos y guárdelos.
Puede utilizar un LLM para la extracción, pero no necesita un agente para decidir qué sucede a continuación.
2. ¿Es la variabilidad de los insumos lo suficientemente baja como para que se pueda mantener un árbol de decisión?
Sí → Flujo de trabajo
Si las entradas son abiertas e impredecibles, un agente puede tener más sentido.
Por ejemplo:
Ayúdame a resolver este problema inusual de un cliente.
Puede resultar difícil crear un flujo de trabajo fijo para cada problema posible. En este caso, puede resultar útil dejar que un agente decida dinámicamente qué información recopilar y qué acción tomar.
3. ¿La aplicación es sensible al volumen, costo y latencia?
Requisitos de alto volumen, presupuesto ajustado o baja latencia → Flujo de trabajo
Los agentes normalmente requieren más razonamiento y llamadas a herramientas, lo que significa más tokens, más llamadas API y más latencia.
Si la tarea es menos frecuente y lo suficientemente valiosa como para justificar la exploración de múltiples posibilidades (como investigaciones o investigaciones complejas), un agente puede tener sentido.
Para preguntas frecuentes o tareas rutinarias de gran volumen, limítese a los flujos de trabajo.
4. ¿Necesito rutas de ejecución idénticas para auditoría o cumplimiento?
Requisitos estrictos de auditoría o cumplimiento → Flujo de trabajo
Por ejemplo:
Verificar identidad → verificar crédito → aplicar política → aprobar/rechazar
Verificar identidad
→ controlar crédito
→ aplicar política
→ aprobar/rechazar
Si cada solicitud debe pasar por los mismos controles documentados, utilice un flujo de trabajo.
Si son aceptables diferentes caminos de investigación siempre que el resultado final sea correcto, un agente puede ser adecuado.
5. ¿He probado ya un flujo de trabajo con criterio de LLM?
Este suele ser el mejor lugar para empezar.
Por ejemplo, en atención al cliente:
Flujo de trabajo fijo → clasificar el problema con LLM → verificar política → elegibilidad de jueces de LLM → procesar reembolso
Fijado flujo de trabajo
→ clasificar asunto con LLM
→ controlar política
→ LLM jueces elegibilidad
→ proceso reembolso
Si esto funciona bien, probablemente no necesite un agente.
Flujo de trabajo + criterio de LLM → pruebe esto antes de pasar a un agente totalmente autónomo.
Conclusión final
Los agentes son poderosos cuando el problema es genuinamente abierto.
Sin embargo, para muchos procesos comerciales, un flujo de trabajo bien diseñado con llamadas de LLM específicas es más simple, más económico, más confiable y más fácil de mantener.
El enfoque práctico es comenzar con restricciones.
Primero dibuja el diagrama de flujo. Construya el flujo de trabajo. Mida dónde falla. Sólo entonces se decide si realmente se necesita un agente, e incluso entonces, puede que sólo sea necesario para una parte limitada de la tarea. Si puede dibujar el diagrama de flujo antes de que se ejecute el LLM, comience con un flujo de trabajo. Si es necesario descubrir el flujo mientras el sistema está en ejecución, probablemente necesite un agente.