Error en las llamadas de herramientas para agentes que usan OpenRouter (varios modelos)

Describe el problema/error/pregunta

Estoy encontrando un problema con las llamadas de herramientas donde los agentes producen llamadas de herramientas vacías cuando se usan en un flujo.

Configuración del flujo: Nodo de disparador programado → Agente AI (con openrouter + herramienta) → Nodo Merge (y otros probados)

Al ejecutar el Agente AI usando el botón “Execute step” la herramienta funciona perfectamente pero cuando se ejecuta el nodo como parte del flujo incluyendo flujos en producción en vivo, las llamadas de herramientas fallan silenciosamente (no parecen ser ni siquiera utilizadas por el agente en la interfaz de usuario pero sí aparecen en los registros como llamadas vacías). A veces aparecen vacías y a veces aparecen dentro de la entrada del agente AI.

Notas:

  • Se probaron varios modelos y me aseguré de que tuvieran longitudes de contexto de token suficientes. Encontré este problema en al menos 6 modelos diferentes capaces de herramientas de diferentes costos.
  • Se probaron varias herramientas (búsqueda brave, gmail, nodo http) todas fallaron de la misma manera

¿Alguien tiene experiencia corrigiendo esto o es un error?

¿Cuál es el mensaje de error (si lo hay)?

No hay mensaje de error pero las llamadas de herramientas regresan vacías cuando se ejecutan como parte de un flujo

Por favor comparte tu flujo de trabajo

Correcto: Usando el botón “execute step”
Las llamadas de herramientas funcionan bien y entrada y salida. La interfaz de usuario del nodo (no mostrada) también se ilumina en verde con marcas de verificación

Error: Desde dentro de un flujo
Las herramientas durante la ejecución no aparecen en los registros pero mágicamente aparecen al final sin embargo son llamadas vacías y parecen hacer cosas como inyectar llamadas de herramientas en la entrada.

Ejemplo de llamada de herramienta en entrada de AI
image

Ejemplo de fallo de herramienta en la interfaz de usuario mostrando una llamada de herramienta en los registros pero no en la interfaz de usuario

Ejemplo de herramienta ejecutándose correctamente cuando se usa “Execute step”

Problema relacionado: Tool calling bug for agents using OpenRouter (various models) · Issue #29758 · n8n-io/n8n · GitHub

(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)

Comparte la salida devuelta por el último nodo

Ejemplo cuando falla
[ { "response": { "generations": [ [ { "text": "Lo siento, pero no pude encontrar información relevante en los correos electrónicos a los que tengo acceso. ¿Hay algo más con lo que pudiera ayudarte?", "generationInfo": { "finish_reason": "stop" } } ] ] }, "tokenUsage": { "completionTokens": 31, "promptTokens": 607, "totalTokens": 638 } } ]

Información sobre tu configuración de n8n

  • Versión de n8n: 2.18.7

Esto es lo esperado. No todos los modelos de IA funcionan de manera confiable con llamadas de herramientas.
¿Qué modelos estás utilizando?
Declarar el esquema de llamadas de herramientas puede mejorar la confiabilidad de tus llamadas de herramientas.
Necesitas probar y cometer errores

El equipo de IA de n8n ya ha identificado este problema, el problema de GitHub vinculado ha sido marcado con status:in-linear y team:ai, lo que significa que el equipo está trabajando actualmente en él.
El problema está relacionado con la forma en que el nodo AI Agent interactúa con el contexto cuando se ejecuta paso a paso en comparación con cuando se ejecuta como parte del flujo de trabajo completo. Cuando se ejecuta como parte del flujo de trabajo, el disparador de contexto de entrada de OpenRouter se ignora en el esquema de llamada de herramienta, o se incrusta en el mensaje tal como está y no puede realizar ninguna llamada de función. Este no es un problema específico de OpenRouter, sucede por la solicitud de n8n durante la ejecución en producción.
Actualmente, la única solución alternativa consistente es no encadenar directamente el AI Agent después de nodos en producción, usar pruebas con una configuración simple de disparador → agente → salida para aislarlo, y estar atento a la corrección en el problema de GitHub:

¿Estás usando n8n Cloud o tienes tu propia versión alojada con docker? La información de depuración muestra que estás usando la versión docker (cloud) 2.18.7, solo pregunto porque la corrección probablemente será en una versión de parche, y será útil saber cuándo realizar las actualizaciones.

¡Hola Miliaga, gracias por tu respuesta! Por ahora intentaré analizar la información de otra manera como solución alternativa.

Estoy usando n8n Cloud. Estaré atento a la actualización.

@ChrisA una solución rápida hasta que se lance esa corrección: cambia el nodo OpenRouter Chat Model por el nodo OpenAI Chat Model. En la credencial de OpenAI, establece Base URL en OpenRouter y pega tu clave de OpenRouter. Model name = tu slug (p. ej. anthropic/claude-3.5-sonnet), luego reconéctalo al Agent. Pasar por la ruta de OpenAI de n8n evita el bug del esquema que causa esas llamadas vacías de finish_reason: stop cuando el agent se dispara desde un trigger en lugar de Execute Step.

¡Excelente hilo, @ChrisA! Bien que el equipo de n8n ya esté rastreando esto.

Solo para agregar un poco más de contexto sobre por qué sucede esto: la discrepancia entre “Execute step” y la ejecución del flujo completo proviene de cómo se construye el contexto de ejecución. Cuando activas a través de Execute Step, n8n construye un contexto fresco solo para ese nodo. Pero en un flujo completo, el contexto ascendente del Schedule Trigger se pasa, y el manejo del esquema del nodo OpenRouter Chat Model no procesa correctamente la señal finish_reason: stop en ese escenario, lo que causa que el agente omita la llamada de herramienta por completo.

La solución alternativa de @achamm es exactamente correcta: usar el nodo OpenAI Chat Model con Base URL apuntando a OpenRouter es actualmente la solución más confiable porque utiliza la ruta de código OpenAI nativa de n8n, que maneja el esquema correctamente.

Algunas otras cosas que vale la pena intentar mientras esperas la corrección oficial:

  • Cambiar a un modelo alojado directamente en OpenRouter pero que sea conocido por ser compatible con OpenAI en su esquema tool_call (como openai/gpt-4o-mini a través de OpenRouter) para reducir si es una varianza de esquema específica del modelo
  • Intentar envolver solo el nodo AI Agent en su propio sub-flujo con un activador manual para eliminar cualquier fuga de contexto ascendente

¡Espero que el parche llegue pronto a n8n Cloud!