He estado construyendo un flujo de trabajo de IA en n8n para operaciones internas, y espero obtener retroalimentación de personas que han enfrentado problemas similares.
El flujo de trabajo maneja diferentes solicitudes según el contexto. Extrae datos, enruta tareas, actualiza sistemas y pasa el trabajo al proceso correcto. Funcionaba bien al principio, pero a medida que hemos expandido el flujo de trabajo, el agente ha comenzado a tomar decisiones deficientes sobre qué herramienta o flujo de trabajo llamar.
A veces omite la recuperación cuando debería consultar una base de conocimientos. Otras veces llama a la rama incorrecta o responde de memoria en lugar de usar los datos más recientes. El prompt ha crecido con el tiempo, así que me pregunto si eso es parte del problema o si la arquitectura general necesita cambiar.
Actualmente estamos usando n8n con OpenAI, una base de datos vectorial para recuperación y algunas API internas. También hemos estado probando Workbeaver para tareas de escritorio que no se exponen a través de API, mientras mantenemos n8n como la capa de orquestación principal.
Para quienes construyen agentes de IA más grandes en n8n:
¿Mantienes un único orquestador o divides responsabilidades entre agentes más pequeños?
¿Cómo reduces alucinaciones cuando hay múltiples herramientas disponibles?
¿Te basas principalmente en ingeniería de prompts o has encontrado que los cambios arquitectónicos son más efectivos?
¿Hay mejores prácticas para decidir cuándo un agente debe recuperar datos versus responder directamente?
Realmente apreciaría escuchar qué ha funcionado para tus proyectos. Gracias de antemano.
Esto huele menos a un problema de prompt y más a que has superado el orquestador único. Cuando un agente tiene todas las herramientas, está eligiendo de un menú grande en cada turno, y las descripciones de herramientas más tu prompt crecido están compitiendo por el mismo presupuesto de atención, así que la selección de herramientas se vuelve imprecisa exactamente cuando añades ramas. Ese es el patrón que describes.
Lo que me funcionó fue dividirlo. Mantén un agente router delgado cuyo único trabajo es elegir el carril, luego delega en pequeños sub-agentes que cada uno posee 2 o 3 herramientas. Espacio de decisión más pequeño por agente, prompt más corto cada uno, selección de herramientas mucho más confiable. El orquestador gordo único se ve elegante pero se degrada con cada herramienta que añades.
Para el problema de saltar recuperación, deja de permitir que la recuperación sea una herramienta que el agente pueda elegir saltarse. En las ramas donde la respuesta tiene que estar fundamentada, ejecuta la recuperación como un paso fijo antes de que el agente vea siquiera la solicitud, así siempre tiene contexto fresco y no puede responder de la memoria. Quítale esa decisión al modelo donde la precisión importa.
Ingeniería de prompts vs arquitectura, pasado cierto tamaño la arquitectura gana y no es ni cerca. Los ajustes de prompts tienen un techo, el enrutamiento más sub-agentes con alcance es lo que aguanta cuando la superficie sigue creciendo.
He construido un puñado de estas configuraciones multi-agente en producción, feliz de profundizar en la estructura de enrutamiento si ayuda.
Has chocado contra el muro que casi todo agente n8n en crecimiento choca: un orquestador con un prompt gordo y una docena de herramientas. La precisión en la selección de herramientas del modelo se desploma conforme aumentan tanto el número de herramientas como la longitud del prompt, así que los síntomas que ves (recuperación omitida, rama equivocada, respuestas de la memoria) son el modo de fallo esperado, no un problema de ajuste del que puedas salir solo con prompts.
Tomando tus preguntas en orden.
Un orquestador vs dividido. Dividido. Convierte uno o dos workflows grandes en cuatro o cinco más pequeños, cada uno responsable de una sola tarea, y haz que el orquestador los llame vía webhook o Execute Workflow. El único trabajo del orquestador es el enrutamiento: clasificar la solicitud, pasarla al sub-workflow correcto, recopilar el resultado. No debe recuperar, actualizar ni tocar APIs directamente. Cada sub-agente entonces ve solo las 3 a 5 herramientas relevantes para su trabajo en lugar del menú completo, y el modelo elige correctamente mucho más a menudo cuando el menú es corto. Como bonus puedes realmente debuggearlo, porque un fallo ahora está aislado en un workflow pequeño en lugar de enterrado en un monolito.
Reducir alucinaciones con múltiples herramientas disponibles. Dos palancas. Primero, reduce el conjunto de herramientas por agente, como se indicó arriba. Segundo, quita decisiones del modelo dondequiera que la decisión sea realmente determinística. Si una rama puede elegirse de un campo conocido con un nodo Switch, hazlo y no hagas que el LLM decida. Reserva el juicio del agente para los casos genuinamente ambiguos. La mayoría de problemas “llamó a la rama equivocada” son realmente “le pedí al modelo que tomara una decisión que una regla hubiera podido tomar.”
Ingeniería de prompts vs arquitectura. El ajuste de prompts tiene un límite y parece que lo estás alcanzando. Pasado cierto tamaño el prompt es el problema, no la solución, porque estás empujando la ventana de contexto lo suficiente como para que el modelo pierda las instrucciones anteriores. Un agente ajustado de 3 herramientas con un prompt corto supera a un agente de 15 herramientas con un prompt gigante cada vez. Arregla la arquitectura primero, luego ajusta los prompts dentro de las piezas más pequeñas.
Decidir recuperar vs responder directamente. No dejes esto a la discreción del modelo, porque “respondió de la memoria en lugar de datos frescos” significa que le diste la opción de saltarse la recuperación. En la rama que necesita datos frescos, haz que la recuperación sea un paso requerido en el flujo, no una herramienta que el agente puede o no llamar. Si debe pasar por la base de datos vectorial o la API para llegar a la respuesta, no puede tomar un atajo a la memoria. Fuerza el camino en lugar de esperar que el prompt lo convenza.
Una cosa más que vale la pena mencionar ya que estás ejecutándolo en producción: una vez que divides en sub-workflows vinculados por webhook, vigila los fallos silenciosos entre ellos. Un sub-agente puede devolver verde mientras silenciosamente deja trabajo sin hacer, y el orquestador continuará felizmente con datos obsoletos o vacíos. Vale la pena vigilar los conteos de elementos en cada transferencia.
Con gusto profundizo más en el patrón de enrutamiento si es útil.
@James198 Un punto más a favor de dividir el flujo: ahora puedes ajustar cada tarea (subflujo) y sus herramientas al modelo que funciona mejor para esa parte del trabajo. Haiku es terrible en llamadas de herramientas, GPT 4 mini también, pero Sonnet y GPT 5 funcionan increíblemente bien con ello. Y segregar partes de tu flujo de trabajo te permite realmente ajustar y optimizar tu salida.
El problema de la rama equivocada es interesante. Cuando elige el carril incorrecto, ¿suele ser el mismo par de ramas las que se confunden, o es aleatorio en todos los casos? ¿Y cuando responde de memoria en lugar de consultar el almacén vectorial, ocurre en un tipo de solicitud específico (como búsquedas de estado versus activaciones de procesos)?
He estado construyendo capas de evaluación precisamente para este patrón y me gustaría saber cuál es la tasa de fallos en un día típico. La división de subagentos que mencionaron otros ayuda, pero generalmente hay una decisión de clasificar-y-enrutar que sigue siendo frágil incluso después de la división.
La cosa útil es el salto-recuperación / rama-incorrecta / respuesta-de-memoria. Tomo un flujo de trabajo de producción durante cinco días y envío un mapa redactado de dos o tres fallos reproducidos, más el primer cambio y una reversión. Solo escrito. Tú escribes el error y el flujo de trabajo, pagas, sueltas trazas redactadas. Sin llamadas, sin reescritura. ¿Cuánto costó el último error?