N8n AI Token d'agent Utilisation: Construire un registre d'appels

Le moyen fiable de mesurer l'utilisation des jetons n8n AI Agent est de créer une ligne de registre pour chaque invocation de modèle, puis d'agréger ces lignes par résultat vérifié. Ne pas ajouter récursivement chaque objet tokenUsage dans une exportation d'exécution. Cela peut compter un instantané d'exécution répété deux fois, compter l'utilisation reflétée par un nœud parent à nouveau, ou mélanger des jetons estimés dans un total rapporté par le fournisseur. Un défaut utile a quatre règles: 1. collecter l'utilisation uniquement à partir de la sortie de l'appel modèle; 2. identifier une observation avec des champs d'exécution, de nœud, d'exécution, d'élément et d'appel du fournisseur; 3. conserver les retries et les appels encastrés comme une utilisation réelle, mais les regrouper sous une logicalOutcomeId ; 4. rapporter l'utilisation et les estimations du fournisseur dans des colonnes distinctes, avec une couverture en plus du total. Cette conception répond à la question opérationnelle qui se pose à l'origine de la recherche: non seulement où se trouve le nombre ?, mais qu'a réellement consommé ce flux de travail réussi, et combien de nombre est connu ? Utilisez un registre d'appels, pas une somme récursive La source n8n actuelle rend visible la première limite comptable. Son type TokenUsage contient promptTokens , completionTokens et totalTokens , avec des métadonnées en cache, en raisonnement et spécifiques au fournisseur. Dans le Implementation du suivi de la chaîne LangChain actuel, n8n écrit tokenUsage lorsque le fournisseur a fourni des comptes. S'il ne peut pas obtenir l'utilisation réelle de l'achèvement, il écrit tokenUsageEstimate à la place. Ces champs ne sont pas interchangeables. Une estimation peut aider à atteindre un seuil d'avertissement, mais ce n'est pas une utilisation déclarée par le fournisseur ou un reçu de facturation. L'implémentation de traçage écrit également la sortie du modèle sur la connexion langage modèle AI. Cela donne à un collectionneur un point de départ plus sûr que de fouiller toutes les propriétés sous le nœud AI Agent. Utilisez une rangée en forme de ceci: Les identifiants résolvent différents problèmes. n8n documente $execution.id comme ID unique d'exécution du flux de travail et $runIndex comme le nombre de fois de fonctionnement du nœud actuel basé sur zéro. nodeName et itemIndex séparent les appels à l'intérieur de cette exécution. Un identifiant de réponse du fournisseur, lorsqu'il est disponible, rend l'identité plus forte. Construire la clé de déduplication à partir de l'identité d'observation: Si un fournisseur n'expose pas un identifiant d'appel, conservez un providerCallId: null explicite et utilisez l'identité locale stable la plus forte disponible. N'utilisez pas le prompt ou la réponse comme clé principale: les demandes identiques peuvent être des appels séparés légitimes, et le stockage du contenu crée un problème de confidentialité évitable. La clé d'événement répond ai je déjà enregistré cet appel? Il ne répond pas à quel résultat visible par l'utilisateur cet appel a t il contribué? Cela nécessite une deuxième clé. Générer logicalOutcomeId à l'entrée du flux de travail, le préserver à travers les retries, et le passer dans chaque sous flux de travail. La valeur peut être une tâche opaque ou une ID de demande; elle ne doit pas contenir un prompt, une adresse e mail ou un autre contenu sensible. Continuez à réessayer, mais dédupliez les observations répétées Les répétitions ne sont pas une utilisation dupliquée. Une tentative ratée qui atteint un modèle consomme des jetons même lorsque la tentative ultérieure réussit. Le démantèlement rend un flux de travail peu fiable plus bon marché précisément lorsque les déchets sont en augmentation. Les observations répétées sont différentes. Supposons qu'un collecteur de sondages récupère l'exécution 811 , puis récupère la même exécution complète à nouveau. Ce sont deux instantanés des mêmes appels. De même, une sortie parent AI Agent peut contenir une copie diagnostique de l'utilisation du modèle qui existe déjà dans la sortie du modèle de modèle de langage AI. Ces copies ne devraient pas créer de nouvelles rangées de livres. La règle est restreinte: le même eventKey vu à nouveau: mise à jour de la fraîcheur ou de la provenance, mais ne pas ajouter de jetons; d'appel à fournisseur différent dans le même emplacement de nœud: conservez le; indice de fonctionnement différent: conservez le; une nouvelle tentative d'exécution avec un identifiant d'exécution différent: conservez le; une exécution en nid avec une identité d'exécution différente: conserver; le même appel reflété sous une connexion non modèle: ignorez le miroir. J'ai testé cette règle avec un dispositif d'exécution détaillée synthétique. Il contient quatre instantanés: une exécution ratée, le même instantané raté une deuxième fois, une nouvelle tentative réussie et une exécution d'enfant en nid. Les nœuds parents reflètent l'utilisation réelle, et un modèle d'appel n'expose qu'une estimation. Mesure Résultat : Objets tokenUsage visibles trouvés par recherche récursive 12 Summe récursive naïve du jeton réel 6,020 Appels de modèle uniques signalés par le fournisseur 4 Les jetons de prompt réels 1,670 Les jetons d'achèvement réels 280 Total réel des jetons 1,950 Les appels estimés uniquement 1 Par exemple, le taux de change de la valeur de l'épargne est le taux de change de la valeur de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épargne de l'épar 120 Couverture des appels réels 80% Le résultat récursif était 3.09× le total du registre sémantique. Il a compté les instantanés d'exécution dupliquées et les miroirs du nœud parent. Le registre n'a pas rejeté la tentative ratée: cette tentative a contribué à 1.060 des 1.950 jetons réels pour le résultat final, ou 54.4% dans ce fichier. Cette distinction compte. Si l'on considérait la première tentative comme une copie, on sous estimerait l'utilisation réelle de plus de la moitié. Appeler chaque copie visible une nouvelle invocation surestimerait l'utilisation de plus de trois fois. L'identité résout les deux erreurs. L'enfant enlevé a apporté 350 autres jetons réels. Il a conservé son propre identifiant d'exécution et sa clé d'événement, de sorte qu'il ne pouvait pas entrer en collision avec son parent. Le partage de logicalOutcomeId: support ticket 42 a attribué ce travail au même résultat prévu. L'appel estimé est resté en dehors du total réel. L'ajout de celui ci produirait 2 070 jetons, mais ce numéro plus précis aurait caché un fait plus faible: un des cinq appels manquait d'utilisation rapportée par le fournisseur. Le tableau de bord doit afficher actualTotalTokens: 1950 , estimatedTotalTokens: 120 et actualCoveragePct: 80 , pas une somme non étiquetée. Vous pouvez reproduire la comparaison en sauvegardant la forme d'exécution ci dessus en tant que fixation et en exécutant la boucle de registre montrée ci dessous. La partie importante est la règle de décision, pas ces pourcentages synthétiques; les ratios de production dépendent du flux de travail, des nœuds de modèle, des fournisseurs, de la politique de retrait et de la conservation des données. Extraire des données d'exécution détaillées avec des contrôles de couverture Le contrat public d'API n8n pour récupérer une exécution accepte includeData . Le schéma d'exécution connexe indique que les données détaillées ne sont incluses que lorsque ce drapeau est vrai. Un collecteur peut donc obtenir une exécution complète avec une demande en forme de: Gardez la clé du côté serveur, demandez les données d'exécution minimales requises et ne copiez pas les instructions ou les corps de réponse dans le registre des jetons. Le collectionneur a besoin d'identifiants, de statut, de structure d'exécution, de champs d'utilisation et de preuves de couverture, pas de contenu de conversation. Puis marchez node par node data.resultData.runData : Traitez cela comme un adaptateur de version, pas un analyseur intemporel. Valider la sortie réelle de chaque type de nœud modèle que vous déployez. Une nouvelle capture instantanée de source n8n peut exposer des métadonnées de suivi telles que llm.tokens.in , llm.tokens.out , llm.tokens.total et un drapeau estimé, mais les nœuds plus anciens ou spécifiques au fournisseur peuvent différer. Préserver des champs inconnus pour le diagnostic et échouer la couverture visiblement lorsqu'un modèle n'a pas d'utilisation reconnue. Des données détaillées peuvent également ne pas être disponibles. Le n8ns d'exécution du point final documente une limite de taille d'affichage configurée, et le produit prend en charge la rédaction des données d'exécution. Les paramètres de rétention peuvent supprimer les anciens organes d'exécution. Un corps manquant signifie donc utilisation indisponible, pas zéro jetons. Compteurs de couverture de l'enregistrement pour chaque fenêtre de collecte: Le dénominateur doit inclure des invocations de modèle reconnues sans utilisation. Sinon, un collectionneur cassé peut signaler une couverture de 100% sur les quelques appels qu'il s'est passé à analyser. Aggrégé par résultat vérifié Un total symbolique n'est utile qu'à côté de l'œuvre qu'il a achetée. Pour chaque logicalOutcomeId , l'agrégat: les entrées, sorties, caches, raisonnements et jetons totaux réels lorsque ces champs existent; les jetons estimés dans des colonnes distinctes; compte distinct de l'appel et de l'exécution; les jetons qui ont échoué; les jetons d'exécution en nid; la couverture de la collecte et le moment de la dernière visite; une réception déterministe du résultat. Le reçu dépend du flux de travail. Un flux de travail de support peut nécessiter une mise à jour du billet avec l'état attendu et l'identifiant de destination. Un flux de travail de document peut nécessiter un objet à une clé de stockage connue plus un hash de contenu. Un flux de travail de déploiement peut nécessiter des tests, l'état du déploiement et une réponse de santé publique. La dernière exécution n8n réussie est une preuve d'activité; elle ne prouve pas l'effet externe demandé. Utilisez trois vues au lieu d' un numéro surchargé: 1. Vue d'invocation pour débogage d'un appel de modèle individuel. 2. Execution view pour les coureurs de nœuds, l'état et les relations de réessayer. 3. O vue de sortie pour toutes les tentatives et travaux ancrés qui ont produit ou ont échoué à produire le produit de livraison. Seule la vue des résultats prend en charge une déclaration telle que Cette mise à jour de billets vérifiée a utilisé 1 950 jetons signalés par le fournisseur, plus 120 jetons estimés, sur cinq appels modèles avec une couverture d'appels réels de 80%. Elle expose également un résultat raté avec une utilisation élevée au lieu de le mesurer en trafic apparemment sain. Si vous calculez plus tard de l'argent, rejoignez le registre à un tableau de prix modèle daté en utilisant le fournisseur, le modèle, la région ou le niveau de service, le cas échéant, et la classe des jetons. Ne déduisez pas le coût historique du prix d'aujourd'hui. N'utilisez pas les lignes de prix seulement pour les estimations de prix comme si elles étaient des données de facturation reconciliées. Étiquettez le résultat estimé jusqu'à ce qu'il correspond à une facture du fournisseur ou à un dossier de coûts autorisé. Promouvoir le tableau de bord uniquement lorsque l'audit est passé Avant de faire confiance à un tableau de bord de jeton agent n8n AI, exécutez un flux de travail contrôlé avec un appel de modèle connu, une exécution de nœud répétée, une réessaye forcée et un sous flux de travail niché. Inspecter les données détaillées sur l'exécution et exiger ces vérifications: chaque invocation attendue produit exactement une ligne de registre; l'exécution du même acte deux fois ne modifie pas les totaux; une tentative ratée reste dans le total des résultats; l'exécution d'un enfant apparaît une fois sous le résultat parental; l'utilisation réelle, estimée et manquante restent séparées; la suppression ou la suppression des données d'exécution réduit la couverture au lieu de produire des zéros; la réception du résultat échoue lorsque le livrable externe est absent. L'appareil a passé ces vérifications comptables, mais il ne prouve pas la compatibilité avec tous les n8n nœuds ou fournisseurs. C'est la limite: la conception du registre est réutilisable; l'adaptateur est spécifique à la version. Le Sidewisp est destiné à faire de l'efficacité du temps et du budget une partie de la santé de l'agent AI en plus de la disponibilité, de l'exécution, de la mémoire, des outils et des résultats. L'utilisation des jetons et l'analyse des coûts estimés sont prévus, mais cette capacité n'est pas expédiée aujourd'hui. Sidewisp est actuellement en préversion privée. Jusqu'à ce qu'une telle couche de santé soit connectée, gardez le registre proche de n8n, recueillez les métadonnées minimales nécessaires et ne favorisez aucune optimisation à moins que l'utilisation et le résultat vérifié ne s'améliorent.