N8n AI Token de agente Uso: Construir un libro de llamadas

La forma confiable de medir el uso de tokens n8n AI Agent es crear una fila de libro mayor para cada invocación de modelo, y luego agregar esas filas por resultado verificado. No agregue recursivamente todos los objetos tokenUsage en una exportación de ejecución. Eso puede contar una instantánea de ejecución repetida dos veces, contar el uso reflejado por un nodo padre de nuevo, o mezclar tokens estimados en un total reportado por el proveedor. Un defecto útil tiene cuatro reglas: 1. recoger el uso únicamente a partir de la salida de la llamada de modelo; 2. Identificar una observación con campos de ejecución, nodo, ejecución, elemento y llamada del proveedor; 3. mantener las retens y las llamadas anidadas como uso real, pero agruparlas bajo una logicalOutcomeId ; 4. el uso y las estimaciones del proveedor de informes en columnas separadas, con cobertura junto al total. Ese diseño responde a la pregunta operativa detrás de la búsqueda: no sólo ¿dónde está el número?, sino ¿qué consumió realmente este flujo de trabajo exitoso, y cuánto de ese número se sabe? Utilice un libro mayor de llamadas, no una suma recursiva La fuente n8n actual hace visible el primer límite contable. Su Tipo de TokenUsage contiene promptTokens , completionTokens y totalTokens , con metadatos opcionales de lectura en caché, razonamiento y específicos para el proveedor. En el Implementación del seguimiento de LangChain actual, n8n escribe tokenUsage cuando el proveedor suministrado cuenta. Si no puede obtener el uso de finalización real, escribe tokenUsageEstimate en su lugar. Esos campos no son intercambiables. Una estimación puede ayudar con un umbral de advertencia, pero no es un uso informado por el proveedor o un recibo de facturación. La implementación de rastreo también escribe la salida de modelo en la conexión de lenguaje modelo AI. Eso le da a un coleccionista un punto de partida más seguro que buscar todas las propiedades debajo del nodo de agente AI. Utilice una fila en forma de esto: Los identificadores resuelven diferentes problemas. n8n documenta a $execution.id como el ID único de ejecución del flujo de trabajo y a $runIndex como el recuento basado en cero de veces en que se ejecutó el nodo actual. nodeName y itemIndex llamadas separadas dentro de esa ejecución. Una identificación de respuesta del proveedor, cuando esté disponible, hace que la identidad sea más fuerte. Construye la clave de deduplicación a partir de la identidad de observación: Si un proveedor no expone una identificación de llamada, mantenga una providerCallId: null explícita y utilice la identidad local estable más fuerte disponible. No hashes el prompt o la respuesta como la clave principal: las instrucciones idénticas pueden ser llamadas separadas legítimas, y almacenar contenido crea un problema de privacidad evitable. La clave de evento responde ¿Ya he grabado esta llamada? No responde ¿a qué resultado visible para el usuario contribuyó esta llamada? Eso requiere una segunda clave. Generar logicalOutcomeId en la entrada del flujo de trabajo, preservarlo a través de retemplajes, y pasarlo a cada subflujo de trabajo. El valor puede ser un trabajo opaco o una identificación de solicitud; no debe contener una solicitud, una dirección de correo electrónico u otro contenido sensible. Mantenga los intentos de nuevo, pero deduplica las observaciones repetidas Las repeticiones no son de uso duplicado. Un intento fallido que alcanzó un modelo consumió tokens incluso cuando el intento posterior tuvo éxito. La eliminación hace que un flujo de trabajo poco fiable parezca más barato precisamente cuando los residuos de ensayo vuelven a crecer. Las observaciones repetidas son diferentes. Supongamos que un colector de encuestas trae la ejecución 811 , y luego trae la misma ejecución completa de nuevo. Son dos instantáneas de las mismas llamadas. Del mismo modo, una salida de AI Agent madre puede contener una copia diagnóstica del uso del modelo que ya existe en la salida del modelo de lenguaje nodes AI. Esas copias no deben crear nuevas filas de libros principales. La regla es estrecha: el mismo eventKey visto de nuevo: actualizar la frescura o procedencia, pero no añadir tokens; una llamada de proveedor diferente en el mismo nodo: mantenerla; índice de ejecución diferente: manténlo; una nueva ejecución con una identificación de ejecución diferente: mantenerla; una ejecución anida con una identificación de ejecución diferente: mantenerla; la misma llamada reflejada bajo una conexión no modelo: ignora el espejo. Probé esa regla con un dispositivo sintético de ejecución detallada. Contiene cuatro instantáneas: una ejecución fallida, la misma instantáneas fallidas una segunda vez, un nuevo intento exitoso, y una ejecución de un niño en un nido. Los nodos padres reflejan el uso real, y una llamada modelo expone solo una estimación. Medición Resultado : Objetos tokenUsage visibles encontrados por búsqueda recursiva 12 Suma recurrente real token ingenuo 6,020 Llamadas de modelo reportadas por proveedores únicos 4 Tokens de respuesta reales 1,670 Tokens de finalización reales 280 Tokens totales reales 1,950 Las llamadas solo para estimaciones 1 Las fichas estimadas, reportadas por separado 120 Cobertura de llamadas reales 80% El resultado recursivo fue 3.09× el total del libro mayor semántico. Contó las imágenes duplicadas de ejecución y los espejos del nodo padre. El libro mayor no descartó el intento fallido: ese intento contribuyó a 1.060 de los 1.950 tokens reales para el resultado final, o 54.4% en esta fijación. Esa distinción es importante. Si llamamos al primer intento un duplicado, subestimaríamos el uso real en más de la mitad. Si llamamos a cada copia visible una nueva invocación, exageraría el uso en más de tres veces. La identidad resuelve ambos errores. El niño anidado aportó otros 350 tokens reales. Mantuvo su propia identificación de ejecución y clave de evento, por lo que no podía chocar con su padre. La participación de logicalOutcomeId: support ticket 42 atribuyó ese trabajo al mismo resultado previsto. La llamada de estimación sólo se mantuvo fuera del total real. Añadirlo producirá 2.070 tokens, pero ese número que parezca más preciso ocultaría un hecho más débil: una de cada cinco llamadas carecía de uso informado por el proveedor. El panel de control debe mostrar actualTotalTokens: 1950 , estimatedTotalTokens: 120 y actualCoveragePct: 80 , no una suma sin etiquetar. Puede reproducir la comparación guardando la forma de ejecución anterior como fijación y ejecutando el bucle de registro que se muestra a continuación. La parte importante es la regla de decisión, no estos porcentajes sintéticos; las proporciones de producción dependen del flujo de trabajo, los nodos de modelo, los proveedores, la política de retiro y la retención de datos. Extraer datos detallados de ejecución con controles de cobertura El contrato público de API n8n para Recuperando una ejecución acepta includeData . El esquema de ejecución relacionado dice que los datos detallados solo se incluyen cuando esa bandera es cierta. Por lo tanto, el recaudador puede obtener una ejecución completa con una solicitud en forma de: Mantenga la clave en el lado del servidor, solicite los datos mínimos de ejecución requeridos y no copie las instrucciones o los cuerpos de respuesta en el libro mayor de tokens. El coleccionista necesita identificadores, estado, estructura de ejecución, campos de uso y evidencia de cobertura, no contenido de conversación. Luego camina data.resultData.runData nodo por nodo: Trata esto como un adaptador de versiones, no como un analizador atemporal. Valida la salida real de cada tipo de nodo modelo que despliegue. Una instantánea de fuente n8n más reciente puede exponer metadatos de rastreo como llm.tokens.in , llm.tokens.out , llm.tokens.total y una bandera estimada, pero los nodos más antiguos o específicos del proveedor pueden diferir. Preservar campos desconocidos para el diagnóstico y no cubrir visiblemente cuando una ejecución de modelo no tenga un uso reconocido. Los datos detallados también pueden no estar disponibles. El punto final de ejecución de n8ns documenta un límite de tamaño de pantalla configurado, y el producto admite la redacción de datos de ejecución. Las configuraciones de retención pueden eliminar los cuerpos de ejecución antiguos. Un cuerpo faltante significa, por lo tanto, que el uso no está disponible, no los tokens cero. Contadores de cobertura de registro para cada ventana de recogida: El denominador deberá incluir invocaciones de modelo reconocidas sin uso. De lo contrario, un coleccionista roto puede reportar cobertura del 100% sobre las pocas llamadas que sucedió a analizar. El resultado verificado es el resultado de la evaluación. Un total simbólico es útil sólo junto al trabajo que compró. Para cada logicalOutcomeId , agregado: los tokens de entrada, salida, caché, razonamiento y total reales cuando existan dichos campos; los tokens estimados en columnas separadas; cuentas distintas de convocatorias y de ejecución; fichas de intento fallido; los tokens de ejecución anidada; la cobertura de la recogida y la última vez que se vio; un recibo de resultado determinista. El recibo depende del flujo de trabajo. Un flujo de trabajo de soporte puede requerir una actualización del boleto con el estado esperado y la identificación de destino. Un flujo de trabajo de documento puede requerir un objeto en una clave de almacenamiento conocida más un hash de contenido. Un flujo de trabajo de despliegue puede requerir pruebas, estado de despliegue y una respuesta de salud pública. La última ejecución n8n exitosa es evidencia de actividad; no prueba el efecto externo solicitado. Utilice tres vistas en lugar de un número sobrecargado: 1. Vista de invocación para desactivar una llamada de modelo individual. 2. Execution view para ejecutar correcciones de nodos, estado y relaciones de repetición. 3. O resultado vista para todos los intentos y trabajos anidados que produjeron o no produjeron el producto entregado. Sólo la vista de resultados respalda una declaración como Esta actualización de boletos verificada utilizó 1.950 tokens reportados por el proveedor, más 120 tokens estimados, en cinco llamadas modelo con cobertura de llamadas reales del 80%. También expone un resultado fallido con un alto uso en lugar de promediarlo en tráfico aparentemente saludable. Si más tarde calcula dinero, únete al libro mayor a una tabla de precios de modelo con fecha utilizando proveedor, modelo, región o nivel de servicio cuando sea relevante, y clase de tokens. No deducir el coste histórico del precio actual. No haga filas de precios estimados únicamente como si fueran datos de facturación reconciliados. Etiquetar el resultado estimado hasta que coincida con una factura del proveedor o con un registro de costes autorizado. Promover el tablero de control sólo cuando la auditoría pasa Antes de confiar en un tablero de control de tokens de agente AI n8n, ejecuta un flujo de trabajo controlado con una llamada de modelo conocida, una ejecución repetida de nodo, un retiro forzado y un subflujo de trabajo anidado. Inspeccionar los datos detallados de ejecución y exigir las siguientes verificaciones: cada invocación esperada produce exactamente una fila del libro mayor; el hecho de que la misma ejecución se realice dos veces no cambia los totales; un intento fallido permanece en el total de resultados; la ejecución de un niño aparece una vez en el resultado de los padres; el uso real, estimado y ausente se mantendrán separados; la eliminación o la edición de datos de ejecución reduce la cobertura en lugar de producir ceros; el recibo de resultado falla cuando el producto externo de entrega no esté presente. La fijación aquí pasó esas verificaciones contables, pero no demuestra compatibilidad con todos los nodos o proveedores n8n. Ese es el límite: el diseño del libro mayor es reutilizable; el adaptador es específico de la versión. Sidewisp está destinado a hacer que la eficiencia del tiempo y el presupuesto formen parte de la salud del agente AI junto con la disponibilidad, ejecución, memoria, herramientas y resultados. Se planea el uso de tokens y el análisis de costos estimados, pero esa capacidad no se envía hoy. Sidewisp se encuentra actualmente en versión preliminar privada. Hasta que se conecte tal capa de salud, mantenga el libro mayor cerca de n8n, recopile los metadatos mínimos necesarios y no promueva la optimización a menos que mejoren tanto el uso como el resultado verificado.