2026-08-01T06:53:41.539Z
n8n AI Agent Token Verwendung: Erstellen Sie ein Call Ledger
Aggregieren Sie jeden n8n-Modellanspruch mit stabilen Identitäten, erneuten Rechnungslegung, Nester-Work-Attribution und expliziter Nutzungsabdeckung.
Die zuverlässige Methode zur Messung von n8n AI Agent Token Verwendung besteht darin, für jede Modell Invocation eine Ledger Reihe zu erstellen und diese Reihen dann nach überprüftem Ergebnis zu aggregieren. Fügen Sie nicht jedes tokenUsage Objekt in einem Ausführungs Export wiederholt hinzu. Das kann einen wiederholten Ausführungs Snapshot zweimal zählen, die Nutzung durch einen Mutterknoten wieder zählen oder geschätzte Token in eine vom Anbieter gemeldete Gesamtzahl mischen. Ein nützlicher Standard hat vier Regeln: 1. die Nutzung ausschließlich aus der Ausgabe des Modellrufs erfassen; 2. Identifizieren Sie eine Beobachtung mit den Feldern Ausführung, Knoten, Lauf, Element und Provider Call; 3. Wiederversuche und eingeschlossene Anrufe als tatsächliche Nutzung aufbewahren, sie jedoch unter einem logicalOutcomeId gruppieren; 4. die Nutzung und Schätzungen des Anbieters in separaten Spalten mit einer Abdeckung neben der Gesamtzahl zu melden. Dieser Entwurf beantwortet die operative Frage hinter der Suche: Nicht nur Woher ist die Zahl?, sondern Was verbrauchte dieser erfolgreiche Workflow wirklich, und wie viel davon ist bekannt? Verwenden Sie ein Call Ledger, nicht eine rekursive Summe Die aktuelle n8n Quelle macht die erste Buchhaltungsgrenze sichtbar. Sein Typ TokenUsage enthält promptTokens , completionTokens und totalTokens , mit optionalem Cache Reading, Argumentation und anbieterspezifischen Metadaten. In der aktuellen LangChain Tracing Implementierung schreibt n8n tokenUsage , wenn der Anbieter Berechnungen bereitstellt. Wenn es keine tatsächliche Vollendungsanwendung erhält, schreibt es stattdessen tokenUsageEstimate . Diese Felder sind nicht austauschbar. Eine Schätzung kann bei einer Warnschwelle helfen, aber es handelt sich nicht um eine vom Anbieter gemeldete Nutzung oder eine Rechnungserklärung. Die Tracing Implementierung schreibt auch Modellleistung auf die AI Sprachmodellverbindung. Das gibt einem Sammler einen sicheren Ausgangspunkt, als alle Eigenschaften unter dem AI Agent Knoten zu durchsuchen. Verwenden Sie eine Reihe in der Form: Die Identifikatoren lösen verschiedene Probleme. n8n dokumentiert $execution.id als einzigartige Workflow Exekutions ID und $runIndex als die nullbasierte Anzahl der Zeiten, in denen der aktuelle Knoten ausgeführt wurde. nodeName und itemIndex trennen sich innerhalb dieser Ausführung. Eine Anbieter Reaktions ID, wenn verfügbar, stärkt die Identität. Erstellen Sie den Deduplikationsschlüssel aus der Beobachtungsidentität: Wenn ein Anbieter keine Anruf ID offenlegt, behalten Sie eine explizite providerCallId: null und verwenden Sie die stärkste stabile lokale Identität. Verwenden Sie nicht die Anforderung oder die Antwort als primären Schlüssel: identische Anforderungen können legitime getrennte Anrufe sein, und die Speicherung von Inhalten schafft ein vermeidbares Datenschutzproblem. Der Ereignisschlüssel antwortet habe ich diesen Anruf bereits aufgenommen? Er antwortet nicht Welches benutzersichtliche Ergebnis hat dieser Anruf beigetragen? Das erfordert einen zweiten Schlüssel. Erzeugen Sie logicalOutcomeId beim Eintritt in den Workflow, bewahren Sie es durch Wiederversuche und geben Sie es in jeden Unter Workflow weiter. Der Wert kann ein unsichtbarer Job oder Anfrage ID sein; er sollte keine Anforderung, keine E Mail Adresse oder andere sensiblen Inhalte enthalten. Wiederholen, aber wiederholte Beobachtungen deduplizieren Wiederversuche sind keine doppelte Nutzung. Ein gescheiterter Versuch, der ein Modell erreichte, verbrauchte Token, auch wenn der spätere Versuch erfolgreich war. Wenn man ihn ablässt, wird ein unzuverlässiger Workflow günstiger erscheinen, gerade wenn sich die Abfälle erneut vermehren. Wiederholte Beobachtungen sind unterschiedlich. Nehmen wir an, ein Umfrage Sammler holt die Hinrichtung 811 , und holt dann die gleiche vollendete Hinrichtung wieder. Das sind zwei Bilder der gleichen Anrufe. Ebenso kann eine Mutter AI Agent Ausgabe eine diagnostische Kopie der Modellnutzung enthalten, die bereits in der Modellnodes AI Sprachenmodell Ausgabe vorhanden ist. Diese Kopien sollten keine neuen Ledgerzeilen erstellen. Die Regel ist eng: dieselbe eventKey erneut gesehen: Frische oder Herkunft aktualisiert, jedoch keine Token hinzugefügt; unterschiedliche Anbieteranrufe im selben Knotenlauf: halten Sie sie bei; Unterschiedlicher Laufindex: behalten Sie ihn; eine erneute Ausführung mit einer anderen Ausführungs ID: behalten Sie sie; eine verschlossene Ausführung mit einer anderen Ausführungs ID: behalten Sie sie; der gleiche Anruf, der unter einer nichtmodellen Verbindung spiegeln wird: Ignorieren Sie den Spiegel. Ich habe diese Regel mit einem synthetischen Detail Exekutionsgerät getestet. Es enthält vier Snapshots: eine fehlgeschlagene Hinrichtung, dieselbe fehlgeschlagene Snapshot ein zweites Mal, ein erfolgreicher erneuter Versuch und eine eingebettete Kindsexekution. Elternknoten spiegeln die tatsächliche Nutzung wider, und ein Modellruf zeigt nur eine Schätzung. Messung Ergebnis : Sichtbare tokenUsage Objekte durch rekursive Suche gefunden 12 Naive rekursive tatsächliche Token Summe 6,020 Einzigartige von Anbietern gemeldete Modellanrufe 4 Echtzeit Token 1,670 Tatsächliche Abschluss Token 280 Tatsächliche Gesamttokene 1,950 Schätzungsgebundene Anrufe 1 Schätzungsweise Token, getrennt gemeldet 120 Wirkliche Anrufsdeckung 80% Das rekursive Ergebnis war 3.09× das semantische Ledger Gesamt. Es zählte die duplizierten Ausführungs Snapshots und Spiegel mit dem Hauptknoten. Das Hauptbuch entließ den fehlgeschlagenen Versuch nicht: Dieser Versuch hat 1.060 der 1.950 tatsächlichen Token für das endgültige Ergebnis oder 54.4% in diesem Fixtur beigetragen. Diese Unterscheidung ist wichtig. Der erste Versuch als Duplikat zu bezeichnen, würde die tatsächliche Nutzung um mehr als die Hälfte unterschätzen. Jede sichtbare Kopie als neue Invokation zu bezeichnen, würde die Nutzung um mehr als dreimal überschätzen. Identität löst beide Fehler. Das verschachtelte Kind gab noch 350 Token. Es behielt seine eigene Ausführungs ID und Ereignisschlüssel, so dass es nicht mit seinem Elternteil kollidieren konnte. Die Teilnahme an logicalOutcomeId: support ticket 42 führte diese Arbeit auf das gleiche beabsichtigte Ergebnis zurück. Der Schätzungsaufruf blieb außerhalb der tatsächlichen Gesamtzahl. Wenn man es hinzufügt, ergeben sich 2.070 Token, aber diese genauer aussehende Zahl verbirgt eine schwächere Tatsache: Einer von fünf Anrufen fehlte die vom Anbieter gemeldete Nutzung. Auf dem Dashboard sollte actualTotalTokens: 1950 , estimatedTotalTokens: 120 und actualCoveragePct: 80 angezeigt werden, nicht eine nicht gekennzeichnete Summe. Sie können den Vergleich reproduzieren, indem Sie die Ausführungsform oben als Fixure speichern und die unten gezeigte Hauptbuchschleife ausführen. Der wichtige Teil ist die Entscheidungsregel, nicht diese synthetischen Prozentsätze; Produktionsquoten hängen vom Workflow, Modellknoten, Anbietern, Wiederversuchpolitik und Datenspeicherung ab. Detaillierte Ausführungsdaten mit Abdeckungskontrollen extrahieren n8ns öffentlicher API Vertrag für Erholung einer Ausführung akzeptiert includeData . Die zugehörige Ausführungsschema sagt, dass detaillierte Daten nur dann enthalten sind, wenn diese Flagge wahr ist. Ein Sammler kann daher eine vollständige Ausführung mit einem Antrag in Form von: Behalten Sie den Schlüssel auf der Serverseite, bitten Sie um die erforderlichen Mindestvervollständigungsdaten und kopieren Sie keine Anfragen oder Reaktionskörper in das Token Ledger. Der Sammler benötigt Identifikatoren, Status, Laufstruktur, Nutzungsfelder und Berichtsnachweisenicht Konversationsinhalte. Dann gehen Sie data.resultData.runData Knoten nach Knoten: Behandeln Sie das als Version Adapter, nicht als zeitloses Parser. Validieren Sie die tatsächliche Ausgabe jedes Modellknotentyps, den Sie bereitstellen. Ein neuerer n8n Quellen Snapshot kann Tracing Metadaten wie llm.tokens.in , llm.tokens.out , llm.tokens.total und eine geschätzte Flagge aufdecken, aber ältere oder anbieterspezifische Knoten können unterschiedlich sein. Bewahren Sie unbekannte Felder zur Diagnose und lassen Sie die Abdeckung sichtbar ausfallen, wenn ein Modellverlauf keine anerkannte Nutzung hat. Auch detaillierte Daten sind möglicherweise nicht verfügbar. n8ns Exekutionsendpunkt dokumentiert eine konfigurierte Display Größe Grenze, und das Produkt unterstützt die Redaktion von Exekutionsdaten. Die Aufbewahrungseinstellungen können alte Exekutionskörper entfernen. Ein fehlender Körper bedeutet also Verwendung nicht verfügbar, nicht Null Token. Aufzeichnungszähler für jedes Sammelfenster: Der Nenner muss anerkannte Modell Invokationen ohne Verwendung enthalten. Andernfalls kann ein kaputtes Sammler über die wenigen Anrufe, die er analysiert hat, 100% Berichterstattung übermitteln. Aggregate pro überprüften Ergebnis Eine Token Gesamtheit ist nur neben der Arbeit nützlich, die sie gekauft hat. Für jede logicalOutcomeId : Aggregat: tatsächliche Eingabe , Ausgabe , Cache , Argumentations und Gesamthokene, wenn diese Felder vorhanden sind; geschätzte Token in separaten Spalten; Unterschiedliche Aufruf und Ausführungszahlen; Scheiternversuchs Token; Verknüpfte Ausführungs Token; Sammeldeckung und zuletzt gesehenes Zeitalter; ein deterministisches Ergebnis Receipt. Die Quittung hängt vom Workflow ab. Ein Support Workflow erfordert möglicherweise eine Ticket Aktualisierung mit dem erwarteten Status und der Ziel ID. Ein Dokument Workflow erfordert möglicherweise ein Objekt mit einem bekannten Speicherschlüssel plus einem Content Hash. Ein Einsatz Workflow erfordert möglicherweise Tests, den Einsatzzustand und eine öffentliche Gesundheitsreaktion. Die letzte erfolgreiche Ausführung ist Aktivitätsnachweis; sie beweist nicht den gewünschten externen Effekt. Verwenden Sie drei Ansichten statt einer überlasteten Nummer: 1. Invocation view zum Debuggen eines individuellen Modellanrufs. 2. Execution view für Knotenläufe, Status und Wiederversuchverhältnisse. 3. O Ausgangsschau für alle Versuche und eingeschlossenen Arbeiten, die das lieferbare produziert oder nicht produziert haben. Nur die Ergebnisansicht unterstützt eine Aussage wie Diese verifizierte Ticket Update verwendet 1.950 vom Anbieter gemeldete Token, plus 120 geschätzte Token, über fünf Modellgespräche mit 80% tatsächlicher Anrufsdeckung. Es zeigt auch ein fehlerhaftes Ergebnis mit hoher Nutzung anstelle eines durchschnittlichen Verkehrs in scheinbar gesunden Verkehr. Wenn Sie später Geld berechnen, fügen Sie das Hauptbuch zu einer datierten Modell Preis Tabelle mit Anbieter, Modell, Region oder Dienstleistungsstufe, wenn relevant, und Token Klasse. Der historische Preis darf nicht aus dem heutigen Preis abgeleitet werden. Verwenden Sie nicht nur Preisvoranschätzungszeilen, als wären sie vereinbarte Rechnungsdaten. Kennzeichnen Sie das geschätzte Ergebnis, bis es mit einer Rechnung des Anbieters oder einer zugelassenen Kostenakte übereinstimmt. Befördern Sie das Dashboard nur, wenn die Prüfung abgeschlossen ist Bevor Sie einem n8n AI Agent Token Dashboard vertrauen, führen Sie einen kontrollierten Workflow mit einem bekannten Modellanruf, einem wiederholten Knotenlauf, einem Zwangs erneuten Versuch und einem verschlossenen Sub Workflow aus. Überprüfen Sie die detaillierten Ausführungsdaten und verlangen Sie die folgenden Kontrollen: jede erwartete Invocation erzeugt genau eine Zeile im Hauptbuch; wenn die gleiche Ausführung zweimal durchgeführt wird, ändert sich die Gesamtzahl nicht; ein fehlgeschlagener Versuch bleibt im Ergebnisbestand; die Vollstreckung des Kindes erscheint einmal unter dem Elternurteil; die tatsächliche, geschätzte und fehlende Nutzung bleiben getrennt; Das Löschen oder Redaktieren von Ausführungsdaten senkt die Abdeckung anstelle von Nullen; die Ergebnisbestätigung fehlt, wenn das externe Lieferwert nicht vorhanden ist. Das System hat diese Rechnungsprüfungen bestanden, beweist jedoch nicht die Kompatibilität mit jedem N8n Knoten oder Anbieter. Das ist die Grenze: Das Hauptbuchdesign ist wiederverwendbar; der Adapter ist versionenspezifisch. Sidewisp soll die Zeit und Budgeteffizienz neben Verfügbarkeit, Ausführung, Speicher, Werkzeugen und Ergebnissen zum Bestandteil der AI Agentengesundheit machen. Token Nutzung und geschätzte Kosten Analysen sind geplant, aber diese Fähigkeit wird heute nicht geliefert. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Bis eine solche Gesundheitsschicht angeschlossen ist, halten Sie das Hauptbuch in der Nähe von n8n, sammeln Sie die erforderlichen Mindestmetadaten und fördern Sie keine Optimierung, es sei denn, sowohl die Nutzung als auch das verifizierte Ergebnis verbessern sich.