n8n AI Token do agente Utilização: Construa um livro de ligações

A forma confiável de medir o uso de tokens n8n AI Agent é criar uma linha de livro razão para cada invocação de modelo e, em seguida, agregar essas linhas por resultado verificado. Não adicionar recursivamente todos os objetos tokenUsage em uma exportação de execução. Isso pode contar um instantâneo de execução repetida duas vezes, contar o uso refletido por um nó mãe novamente, ou misturar tokens estimados em um total relatado pelo provedor. Um padrão útil tem quatro regras: 1. recolher a utilização apenas a partir da saída da chamada de modelo; 2. Identificar uma observação com campos de execução, nó, execução, item e chamada do prestador; 3. manter as retries e as chamadas aninhadas como utilização real, mas agrupá las sob um logicalOutcomeId ; 4. Relatório da utilização e estimativas do prestador em colunas separadas, com cobertura ao lado do total. Esse projeto responde à pergunta operacional por trás da pesquisa: não apenas onde está o número?, mas o que esse fluxo de trabalho bem sucedido realmente consumiu, e quanto desse número é conhecido? Use um livro de chamadas, não uma soma recorrente A fonte corrente n8n torna visível o primeiro limite contabilístico. Seu Tipo TokenUsage contém promptTokens , completionTokens e totalTokens , com leitura em cache opcional, raciocínio e metadados específicos do provedor. No Implementação do rastreamento da LangChain atual, n8n escreve tokenUsage quando o fornecedor fornece contas. Se não conseguir obter uso de conclusão real, escreve tokenUsageEstimate em vez disso. Esses campos não são intercambiáveis. Uma estimativa pode ajudar com um limiar de aviso, mas não é o uso relatado pelo fornecedor ou um recibo de faturamento. A implementação de rastreamento também escreve a saída do modelo na conexão linguística modelo AI. Isso dá ao coletor um ponto de partida mais seguro do que procurar todas as propriedades abaixo do nó agente AI. Use uma linha com a forma deste: Os identificadores resolvem diferentes problemas. N8n documenta o $execution.id como o ID de execução único do fluxo de trabalho e o $runIndex como o conteúdo baseado em zero das vezes em que o nó atual foi executado. nodeName e itemIndex chamadas separadas dentro dessa execução. Uma identificação de resposta do fornecedor, quando disponível, torna a identidade mais forte. Construir a chave de deduplicação a partir da identidade de observação: Se um prestador não divulgar uma identificação de chamada, retém uma providerCallId: null explícita e use a identidade local estável mais forte disponível. Não hash o prompt ou resposta como a chave primária: as mesmas solicitações podem ser chamadas separadas legítimas, e armazenar conteúdo cria um problema de privacidade evitável. A chave do evento responde Já gravei esta chamada? Não responde que resultado visível ao usuário contribuiu esta chamada? Isso requer uma segunda chave. Gerar logicalOutcomeId na entrada do fluxo de trabalho, preservá lo através de retries e passá lo em cada sub fluxo de trabalho. O valor pode ser um trabalho opaco ou ID de solicitação; não deve conter um prompt, endereço de e mail ou outro conteúdo sensível. Manter as repetições, mas deduplicar as observações repetidas As retries não são duplicadas. Uma tentativa fracassada que alcançou um modelo consumiu tokens mesmo quando a tentativa posterior teve sucesso. Deixá lo cair faz com que um fluxo de trabalho não confiável pareça mais barato precisamente quando os resíduos estão a crescer. As observações repetidas são diferentes. Suponha que um coletor de sondagens traga a execução 811 , e depois traga a mesma execução completa novamente. São duas fotos das mesmas chamadas. Da mesma forma, uma saída de agente AI mãe pode conter uma cópia diagnóstica do uso do modelo que já existe na saída do modelo de linguagem do modelo AI. Essas cópias não devem criar novas linhas de contabilidade. A regra é estreita: O mesmo eventKey visto novamente: actualizar a frescura ou a proveniência, mas não adicionar tokens; chamada de um prestador diferente na mesma execução do nó: mantenha a; Indice de execução diferente: mantenha o; Uma nova execução com uma identificação de execução diferente: mantenha a; Uma execução aninhada com uma identificação de execução diferente: mantenha a; A mesma chamada refletida sob uma conexão não modelo: ignore o espelho. Testei essa regra com um dispositivo sintético de execução detalhada. Ele contém quatro instantâneos: uma execução fracassada, a mesma instantânea fracassada uma segunda vez, uma nova tentativa bem sucedida e uma execução infantil aninhada. Os nós mães refletem a utilização real, e um modelo de chamada expõe apenas uma estimativa. Medida Resultado : Objetos visíveis tokenUsage encontrados por pesquisa recursiva 12 Sumas reais tokens recorrentes ingênuos 6,020 As chamadas de modelo reportadas por fornecedores únicos 4 Tokens de prompt reais 1,670 Tokens de conclusão efetivas 280 Tokens totais reais 1,950 Só chamadas estimativas 1 Indicações de risco 120 Cobertura de chamadas reais 80% O resultado recorrente foi 3.09× o total do livro de conta semântica. Contou as imagens duplicadas de execução e os espelhos do nó mãe. O livro não descartou a tentativa fracassada: essa tentativa contribuiu com 1.060 dos 1.950 tokens reais para o resultado final, ou 54.4% nesta fixação. Essa distinção importa. Chamando a primeira tentativa de duplicação, subestimaria o uso real em mais da metade. Chamar cada cópia visível uma nova invocação exageraria o uso em mais de três vezes. A identidade resolve ambos os erros. A criança aninhada contribuiu com mais 350 tokens reais. Manteve a sua própria identificação de execução e chave de evento, para que não pudesse entrar em colisão com a sua mãe. A partilha do logicalOutcomeId: support ticket 42 atribuiu esse trabalho ao mesmo resultado pretendido. A chamada apenas estimativa ficou fora do total real. Adicionar lhe ia produzir 2.070 tokens, mas esse número de aparência mais precisa ocultaria um fato mais fraco: uma das cinco chamadas não tinha uso relatado pelo provedor. O painel deve mostrar actualTotalTokens: 1950 , estimatedTotalTokens: 120 e actualCoveragePct: 80 , não uma soma não rotulada. Você pode reproduzir a comparação salvando a forma de execução acima como uma fixação e executando o ciclo do livro razão mostrado abaixo. A parte importante é a regra de decisão, não estas percentagens sintéticas; as proporções de produção dependem do fluxo de trabalho, dos nós de modelo, dos provedores, da política de retest e da retenção de dados. Extrair dados detalhados de execução com controles de cobertura O contrato público de API n8n para Recuperação de uma execução aceita o includeData . A esquema de execução diz que os dados detalhados só são incluídos quando essa bandeira é verdadeira. Um colecionador pode, portanto, obter uma execução concluída com um pedido em forma de: Mantenha o lado do servidor da chave, solicite os dados de execução mínimos necessários e não copie as instruções ou corpos de resposta no livro de registros de tokens. O coletor precisa de identificadores, status, estrutura de execução, campos de uso e evidências de cobertura, não conteúdo de conversa. Então caminhe node por node data.resultData.runData : Trata isto como um adaptador de versões, não como um analisador atemporal. Validar a saída real de cada tipo de nó modelo que você implantar. Um snapshot de fonte n8n mais recente pode expor metadados de rastreamento, como llm.tokens.in , llm.tokens.out , llm.tokens.total e uma bandeira estimada, mas nós mais antigos ou específicos do provedor podem diferir. Preservação de campos desconhecidos para diagnóstico e falha de cobertura visível quando uma execução de modelo não tem utilização reconhecida. Os dados detalhados também podem não estar disponíveis. O endpoint de execução n8ns documenta um limite de tamanho de exibição configurado e o produto suporta a edição de dados de execução. As configurações de retenção podem remover antigos corpos de execução. Um corpo faltante significa, portanto, que os tokens não estão disponíveis para uso, e não para zero. Contadores de cobertura de registro para cada janela de coleta: O denominador deve incluir invocações de modelo reconhecidas sem utilização. Caso contrário, um coletor quebrado pode relatar 100% de cobertura sobre as poucas chamadas que aconteceu para analisar. Agregação por resultado verificado Um total simbólico só é útil além do trabalho que comprou. Para cada logicalOutcomeId , agregado: Os dados de entrada, saída, cache, raciocínio e tokens totais reais, quando esses campos existem; Tokens estimados em colunas separadas; Contagens distintas de convocação e execução; Tokens de tentativa fracassada; Tokens de execução aninhados; Cobertura da recolha e data de última visita; um recibo determinista de resultado. O recibo depende do fluxo de trabalho. Um fluxo de trabalho de suporte pode exigir uma atualização do bilhete com o status esperado e o ID de destino. Um fluxo de trabalho de documento pode exigir um objeto em uma chave de armazenamento conhecida mais um hash de conteúdo. Um fluxo de trabalho de implantação pode exigir testes, estado de implantação e uma resposta de saúde pública. A última execução n8n bem sucedida é evidência de actividade; não prova o efeito externo solicitado. Use três visualizações em vez de um número sobrecarregado: 1. View de invocação para depurar uma chamada de modelo individual. 2. Execution view para corridas de nós, status e relações de retest. 3. Ooutcome view para todas as tentativas e trabalhos aninhados que produziram ou falharam em produzir o entregue. Apenas a visão de resultados suporta uma declaração como Esta atualização de bilhetes verificada usou 1.950 tokens relatados pelo provedor, mais 120 tokens estimados, em cinco chamadas modelo com cobertura de chamadas reais de 80%. Também expõe um resultado falhado com alto uso em vez de mediá lo em tráfego aparentemente saudável. Se você calcular dinheiro mais tarde, junte o livro razão a uma tabela de preço modelo datada usando fornecedor, modelo, região ou nível de serviço, quando relevante, e classe de tokens. Não deduzir o custo histórico do preço de hoje. Não coloque apenas linhas de estimativas de preços como se fossem dados de facturação reconciliados. Marcar o resultado estimado até que corresponda a uma fatura do fornecedor ou a um registro de custos autorizado. Promover o painel de instrumentos apenas quando a auditoria passar Antes de confiar em um painel de controle de tokens AI Agent n8n, execute um fluxo de trabalho controlado com uma chamada de modelo conhecida, uma execução repetida de nó, uma tentativa forçada e um subfluxo de trabalho aninhado. Inspeccionar os dados detalhados de execução e exigir as seguintes verificações: Cada invocação esperada produz exatamente uma linha do livro de contabilidade; A execução dupla não altera os totais; Uma tentativa fracassada permanece no total de resultados; A execução infantil aparece uma vez sob o resultado dos pais; O uso real, estimado e ausente permanecem separados; A exclusão ou a redacção de dados de execução reduz a cobertura em vez de produzir zeros; O recebimento do resultado falha quando o entregue externo estiver ausente. A fixação aqui passou por essas verificações contábeis, mas não demonstra a compatibilidade com todos os nós ou provedores n8n. Esse é o limite: o desenho do livro razão é reutiliável; o adaptador é específico de versão. O Sidewisp destina se a fazer da eficiência do tempo e do orçamento parte da saúde do agente AI, juntamente com a disponibilidade, execução, memória, ferramentas e resultados. O uso de tokens e análises de custo estimado estão planejados, mas essa capacidade não é enviada hoje. A Sidewisp está atualmente em prévia privada. Até que tal camada de saúde seja conectada, mantenha o livro de conta perto de n8n, coleta os metadados mínimos necessários e não promova nenhuma otimização, a menos que o uso e o resultado verificado melhorem.