Bug de chamada de ferramenta para agentes usando OpenRouter (vários modelos)

Descreva o problema/erro/pergunta

Estou encontrando um problema com chamadas de ferramentas onde agentes produzem chamadas vazias quando usadas em um fluxo.

Configuração do fluxo: Nó de gatilho agendado → Agente de IA (com openrouter + ferramenta) → Nó de mesclagem (e outros testados)

Ao executar o Agente de IA usando o botão “Executar passo”, a ferramenta funciona perfeitamente, mas ao executar o nó como parte do fluxo, incluindo fluxos de produção ao vivo, as chamadas de ferramentas falham silenciosamente (elas não parecem nem ser usadas pelo agente na interface, mas aparecem nos registros como chamadas vazias). Às vezes aparecem vazias e às vezes aparecem dentro da entrada do agente de IA.

Notas:

  • Vários modelos testados e me certifiquei de que tinham comprimentos de contexto de token suficientes. Encontrei esse problema em pelo menos 6 modelos diferentes capazes de ferramentas com custos diferentes.
  • Várias ferramentas testadas (busca Brave, Gmail, nó HTTP) todas falharam da mesma forma

Alguém tem experiência em corrigir isso ou é um bug?

Qual é a mensagem de erro (se houver)?

Nenhuma mensagem de erro, mas as chamadas de ferramentas voltam vazias quando executadas como parte de um fluxo

Por favor, compartilhe seu fluxo de trabalho

Correto: Usando o botão “executar passo”
As chamadas de ferramentas funcionam bem com entrada e saída. A interface do nó (não mostrada) também fica verde com marcas de seleção

Com bug: De dentro de um fluxo
As ferramentas durante a execução não aparecem nos registros, mas magicamente aparecem no final, porém são chamadas vazias e parecem fazer coisas como injetar chamadas de ferramentas na entrada.

Exemplo de chamada de ferramenta na entrada de IA
image

Exemplo de falha de ferramenta na interface mostrando uma chamada de ferramenta nos registros, mas não na interface

Exemplo de ferramenta funcionando corretamente ao usar “Executar passo”

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

(Selecione os nós no seu canvas e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o fluxo de trabalho.)

Compartilhe a saída retornada pelo último nó

Exemplo quando falha
[ { "response": { "generations": [ [ { "text": "Desculpe, mas não consegui encontrar nenhuma informação relevante nos emails que tenho acesso. Há algo mais que eu pudesse ajudá-lo?", "generationInfo": { "finish_reason": "stop" } } ] ] }, "tokenUsage": { "completionTokens": 31, "promptTokens": 607, "totalTokens": 638 } } ]

Informações sobre sua configuração n8n

  • versão n8n: 2.18.7

Isso é esperado. Nem todos os modelos de IA funcionam de forma confiável com chamadas de ferramentas.
Quais modelos você está usando?
Declarar o esquema de chamada de ferramentas pode melhorar a confiabilidade de suas chamadas de ferramentas.
Você precisa fazer testes e ajustes

O time de IA do n8n já identificou esse problema, a issue do GitHub vinculada foi marcada com status:in-linear e team:ai, o que significa que esse problema está sendo trabalhado no momento.
O problema está relacionado à forma como o nó AI Agent interage com o contexto quando é executado passo a passo versus quando é executado como parte do fluxo de trabalho completo. Quando executado como parte do fluxo de trabalho, o trigger de contexto de entrada do OpenRouter é ignorado no schema da chamada de ferramenta, ou é incorporado no prompt como está e não consegue realizar nenhuma chamada de função. Isso não é um problema específico do OpenRouter, acontece por causa da solicitação do n8n durante a execução em produção.
Atualmente, a única solução alternativa consistente é não encadear o AI Agent diretamente após nodes em produção, usar teste com uma configuração simples trigger → agent → output para isolá-lo, e fique atento à correção na issue do GitHub:

Você está usando n8n Cloud ou tem a sua própria instalação auto-hospedada com docker? As informações de debug mostram que você está usando a versão docker (cloud) 2.18.7, apenas verificando porque a correção provavelmente será em uma versão de patch, e será útil saber quando executar as atualizações.

Oi Miliaga, obrigado pela sua resposta! Vou tentar analisar as informações de uma forma diferente por enquanto como solução alternativa.

Estou usando n8n Cloud e ficarei atento para a atualização.

@ChrisA uma solução rápida até esse fix chegar: troque o nó OpenRouter Chat Model pelo nó OpenAI Chat Model. Na credencial OpenAI, defina Base URL como OpenRouter e cole sua chave OpenRouter. Model name = seu slug (ex: anthropic/claude-3.5-sonnet), depois reconecte-o ao Agent. Passando pelo caminho OpenAI do n8n, você evita o bug de schema que causa aquelas chamadas vazias com finish_reason: stop quando o agent é disparado a partir de um trigger em vez de Execute Step.

Ótima thread, @ChrisA! Bom saber que o time do n8n já está acompanhando isso.

Só para adicionar um pouco mais de contexto sobre por que isso acontece: a discrepância entre “Execute step” e execução de fluxo completo vem de como o contexto de execução é construído. Quando você dispara via Execute Step, n8n constrói um contexto fresco apenas para aquele nó. Mas em um fluxo completo, o contexto upstream do Schedule Trigger é passado, e o tratamento de schema do nó OpenRouter Chat Model não processa corretamente o sinal finish_reason: stop nesse cenário, o que faz o agente pular a chamada de ferramenta inteira.

O workaround do @achamm está exatamente certo - usar o nó OpenAI Chat Model com Base URL apontando para OpenRouter é atualmente o fix mais confiável porque usa o código nativo OpenAI do n8n, que trata o schema corretamente.

Algumas outras coisas que valem a pena tentar enquanto você aguarda o fix oficial:

  • Mude para um modelo que é hospedado diretamente no OpenRouter, mas é conhecido por ser compatível com OpenAI em seu schema tool_call (como openai/gpt-4o-mini via OpenRouter) para estreitar se é uma variância de schema específica do modelo
  • Tente envolver apenas o nó AI Agent em seu próprio sub-workflow com um gatilho manual para eliminar qualquer vazamento de contexto upstream

Espero que o patch chegue em breve no n8n Cloud!