AI Beobachtbarkeit: Erstellen Sie einen Vier-Schicht-Signalvertrag

AI Beobachtbarkeit ist keine Dashboard Kategorie. Es ist die Fähigkeit, vier verschiedene Fragen mit Beweisen zu beantworten: Wurden die Arbeiten erwartet? Was ist eigentlich los? Warte ich auf eine legitime Abhängigkeit? Besteht das beabsichtigte Ergebnis und kann die Überprüfung bestanden? Ein Stapel, der nur auf die zweite Frage antwortet, kann schöne Spuren erzeugen, während ein geplanter Agent nie startet, eine menschliche Genehmigung unbemerkt bleibt oder ein erfolgreicher Lauf keine Ergebnisse hinterlässt. Der praktische Standard ist daher ein vier Schicht Signalvertrag: Zeitraum, Ausführung, Abhängigkeit und Ergebnis . Halten Sie Modell Latenz, Token, Fehler, Tool Anrufe und Spans, aber verwechseln Sie sie nicht mit dem gesamten Vertrag. Dieser Artikel testet die Regel für ein kleines NDJSON Gerät und gibt Ihnen eine Prüfung, die Sie anpassen können, bevor Sie eine andere Plattform kaufen oder instrumentalisieren. Die Beobachtbarkeit von AI wird als Abdeckungsproblem betrachtet Die Suchergebnisse für die Beobachtbarkeit von AI mischen mehrere berechtigte Bedenken: Modellqualität, Datendrift, GPU und Anwendungsleistung, Agentenspuren, Sicherheit, Governance und Kosten. Diese Breite ist der Grund, warum wir beobachtbar sind, schwer zu bewerten. Zwei Teams können dieselbe Phrase verwenden, während sie unterschiedliche Beweise sammeln. Für einen Agenten, der geplante oder delegierte Arbeiten erledigt, ist die beabsichtigte Aufgabe als Analyseeinheit zu verwenden. Dann benötigen Sie eine Schicht für jede Frage, die das operative Urteil ändern kann. Schicht Mindestbeweise Ausfall, den sie aufdecken kann Zeitplan erwartete Zeit, Frist, Startzeit, Zeitplanidentität Der Lauf hat nie begonnen. Ausführung Run ID, Schritt oder Spanne, Werkzeugergebnis, Terminalstatus, Fehlerklasse die Laufbahn ist gestoppt, eingeschaltet, erneut ausprobiert oder gescheitert Abhängigkeit ausdrücklicher Wartezustand, Abhängigkeitstyp, Zulassung oder Bezugnahme auf das externe System Rechtmäßige Wartezeit wurde falsch als eingeschlossen bezeichnet. Ergebnis Identifizierung von Artefakten oder Nebenwirkungen, Deterministikprüfung, Überprüfungszeit Die Ausführung sagte Erfolg, aber die Arbeit war abwesend oder falsch Diese Schichten sind keine vier Lieferantenprodukte. Es sind vier Verbindungen rund um eine stabile ID. Ein Spuren Backend kann die meisten Hinrichtungsherausfälle enthalten. Ein Zeitplaner kann die erwarteten Zeiten kennen. Ein Zulassungssystem besitzt möglicherweise Wartungsnachweise. Die Bestimmungsstelle selbst Objektspeicher, ein Repository, eine Ticketing API, eine Datenbank besitzt in der Regel die stärkste Ergebnisprüfung. Diese Gestaltung hält auch die Überwachung und Bewertung getrennt, ohne sie auseinander zu zwingen. Eine auf Rubriken basierende Qualitätsbewertung kann als Ergebnisprüfer dienen, wenn keine deterministische Prüfung vorhanden ist. Es sollte keinen Dateihash, Testergebnis, Zeilenzählung oder API Receipt schweigend ersetzen, wenn eines davon verfügbar ist. Warum eine vollständige Spur den Vorfall noch verpassen kann Die Standards für die Verfolgung verbessern sich schnell. Bei dem 74fd2e0 Verpflichtungsprozess sind das OpenTelemetry Generative AI semantische Konventionen Abdeckungsmodell und die Agentenspanne, die Messwerte, die Ereignisse, die Ausnahmen, die anbieterspezifischen Übereinkommen und die MCP zu berücksichtigen. Das Dokument markiert die GenAI Konventionen als Development , eine wichtige Versiongrenze, wenn Sie langlebige Schemata entwerfen. Die Spezifikation für den Agentenbereich definiert Operationen wie create agent , invoke agent , invoke workflow , plan und execute tool . Es enthält auch nützliche Eigenschaften, einschließlich gen ai.operation.name , gen ai.agent.name , und bedingungsmäßig erforderlich error.type Siehe die Pinned Agent Span Quelle. Das ist ein starker Hinrichtungsergebnis. Es sagt einem Ermittler, welche Operation stattfand, wie sich die Spannungen beziehen, wie lange sie dauerten und ob ein gemeldeter Fehler die Operation beendete. Das Framework Tracing kann noch reicher sein. Das OpenAI Agents SDK Tracing Dokumentation sagt, dass seine Standardspur Renner Invokationen, Aufgaben und Turnspannungen, Agenten, Generationen, Funktionswerkzeuge, Schutzgänge und Handoffs abdeckt. Es unterstützt auch benutzerdefinierte Spans und Prozessoren. Das ermöglicht es, fehlende Geschäftsbeweise zu befestigen. Aber weder eine fertige Strecke noch ein Terminal ok beweisen, dass zunächst eine geplante Strecke erwartet wurde. Es beweist auch nicht, dass weekly report.pdf existiert, den neuen Berichtszeitraum hat und einen Parser absolviert hat. Die Abwesenheit ist kein Fehler bei der Nachverfolgung. Es ist eine Grenze zwischen der Ausführungstelemetrie und den Beweisen für die Ergebnisse des Betriebs. Diese Grenze ist verfälschbar: Sie nehmen zwei Rennen mit identischen erfolgreichen Ausführungsereignissen, fügen Sie nur einem outcome verified Ereignis hinzu, und das operative Urteil muss sich unterscheiden. Wenn Ihre aktuelle Warnung beide Laufwerke im gleichen grünen Zustand gibt, kann sie falschen Erfolg nicht erkennen. Führen Sie einen vier Schicht Audit auf einem festen Gerät durch Das begleitende Gerät enthält vier Rennen, die bei 2026 07 25T02:42:00Z beobachtet wurden: run alpha startet, nennt sein Berichtswerkzeug, beendet und registriert ein verifiziertes Artefakt; run beta hat die gleiche erfolgreiche Ausführungsform, jedoch kein überprüftes Ergebnis; run gamma wartet explizit auf die Genehmigung approve 42 ; run delta überschreitet seine erwartete Frist ohne Startveranstaltung. Führen Sie die Prüfung mit Node.js 20 oder neuerer Ausführung durch: Der Klassifizierer gibt in jedem Zustand einen Lauf zurück: Der Code verwendet eine bewusst langweilige Entscheidung. Ein bestätigtes Ergebnis gewinnt. Eine explizite Wartezeit mit einem Grund und einer Genehmigungsreferenz ist eine Wartezeit, nicht fest. Ein Lauf, der nie vor seiner Frist begonnen hat, wird verpasst. Ein abgeschlossener Lauf ohne Ergebnisnachweis ist ein falscher Erfolg. Ein begannender Lauf, der seine Frist überschritten hat, steckt fest. Alles andere funktioniert, anstatt gesund zu werden. Das ist ein Experiment, kein Maßstab. Vier handgefertigte Fälle können die Produktionsfehlerraten nicht schätzen, und ein echter Klassifikator benötigt doppelte Ereignisse, Toleranzen für Uhrverzerrungen, späte Ankunftsergebnisse und Fristen pro Job. Das Gerät ist nützlich, weil jedes Urteil überprüfbar ist und die Änderung eines Ereignisses ein Ergebnis verändert. Erhaltet das Warten als seinen eigenen Zustand Ein binäres gesundes/ungesundes Feld zerstört Informationen, wenn ein Betreiber sie benötigt. Betrachten Sie run gamma : Der Prozess schreitet nicht voran, aber es wäre der falsche Standard, ihn neu zu starten. Es hat eine ausdrückliche Genehmigungsabhängigkeit. Die richtige Handlung besteht darin, den Antrag an die richtige Person zu stellen und gleichzeitig den Umfang, das Alter und die Grenzen der Autorität zu bewahren. Speichern Sie mindestens: Verwenden Sie denselben Ansatz für Rate Limit Reset Zeiten, externe Job IDs, Wartungsfenster und Upstream Datenanmeldungen. Eine freie Textnachricht wie still waiting ist ein schwacher Beweis: Sie ist schwierig zu vermitteln, zu verfallen oder zu korrelieren. Eine getippte Abhängigkeit plus eine unsichtbare Referenz unterstützt eine begrenzte Reaktion, ohne den geheimen, prompt oder genehmigungsmäßigen Inhalt in die Telemetrie zu kopieren. Aktivität ist ebenso leicht zu überschätzen. Wiederholte Tool Anrufe zeigen, dass ein Prozess beschäftigt ist; nur Delta Systeme oder Ergebnisse zeigen nützliche Fortschritte. Ein Wiederversuchzähler gehört daher neben der letzten bedeutungsvollen Veränderungszeit, nicht neben einem generischen letzte Ereignis Zeitstempel, den eine Schleife für immer erfrischen kann. Erstellen Sie die Ergebnisprüfung als Ziel Native Der stärkste Überprüfer lebt dort, wo die Arbeit landen sollte. Für eine Datei erfassen Sie einen stabilen Objektschlüssel, Größe, Verdauung und Parser Ergebnis. Für eine Anforderung zur Anziehung erfassen Sie das Repository, die PR Nummer, den Zielzweig und den erforderlichen Check Zugriff. Für eine CRM Aktualisierung erfassen Sie die nicht geheime Entitäts ID, den erwarteten Feldübergang und das Ergebnis "Lese after Writing". Lassen Sie das Rohprodukt nicht in jede Spur. Speichern Sie die geringsten Beweise, die zur Wiederholung der Prüfung erforderlich sind. Die OpenAI Agents SDK Dokumentation warnt, dass Generations und Funktionsspannungen empfindliche Eingaben und Ausgänge enthalten können und beschreibt die Kontrollen für die Deaktivierung dieser Erfassung. Verwenden Sie das gleiche Prinzip auf Ihre benutzerdefinierten Veranstaltungen: Identifikatoren und Digests sind in der Regel sicherer als Anfragen, Antworten, Anmeldeinformationen, absolute lokale Wege oder Kundeninhalte. Die Prüfung der Ergebnisse erfordert auch Frische. Eine Datei, die von gestern hinterlassen wurde, ist kein Beweis dafür, dass der heutige Vorgang erfolgreich war. Verbinden Sie das Artefakt mit dem aktuellen Lauf durch eine Lauf ID, eine erwartete Berichtszeit, ein Erstellungsfenster oder eine nach der aktuellen Startzeit berechnete Vergabe. Es gibt einen Kompromiss. Bestimmungsort native Kontrollen ergänzen Integrationsarbeit und können unabhängig davon versagen. Eine nicht verfügbare Verifikatorin gilt als unknown , nicht gesund und nicht automatisch gescheitert. Überschreiten Sie die fehlenden Beweise, die letzte erfolgreiche Prüfung und das Vertrauen des daraus resultierenden Urteils. Prüfwerkzeuge gegen den Vertrag, bevor Sie Merkmale vergleichen Eine nützliche Produktbewertung beginnt mit vier Zeilen, nicht mit einem Logo. Fragen Sie für jeden Kandidatenstap, wo jede Schicht entsteht, wie sie mit dem Lauf verbunden ist, wie lange sie aufbewahrt wird und welche Abfrage die Abdeckung beweist. 1. Kann es erwartete Zeiträume, einschließlich Zeitzone und Frist, importieren oder ableiten? 2. Kann es Modell , Werkzeug , Handover , Wiederversuch und Fehlerereignisse verfolgen, ohne dass eine empfindliche Nutzlast Fassung erforderlich ist? 3. Kann es das Warten mit einer eingeschriebenen Abhängigkeit und einem Ziel der Eskalation darstellen? 4. Kann es deterministische Ergebnisergebnisse vom Bestimmungsort aufnehmen oder verknüpfen? 5. Kann es nicht verfügbare Beweise von einem gesunden Ergebnis unterscheiden? 6. Können Sie die Daten über ein offenes Format oder API exportieren, wenn sich das Tool ändert? Verwerfen Sie kein zielgerichtetes Spurenwerkzeug, weil es keine Zeitplan oder Ergebnissemantik hat. Paare sie mit den fehlenden Quellen, wenn die Verbindungen zuverlässig sind. Ablehnen Sie die Architektur, wenn sie nicht die Unterscheidung darstellen kann, die Sie benötigen, fehlende Daten hinter dem grünen Status versteckt oder für routinemäßige Gesundheitsprüfungen empfindliche Rohinhalte benötigt. Der Vier Schicht Vertrag löst die ursprüngliche Frage: Die Beobachtbarkeit von AI für operative Agenten ist nur dann vollständig, wenn sie Erwartungen, Ausführung, Abhängigkeit und verifiziertes Ergebnis separat erklären kann. Spuren sind wesentliche Beweise, aber sie sind eine Schicht. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Seine vorgesehene Rolle ist eine gesundheitliche Schicht neben bestehenden Laufzeiten, mit Beweisen und menschlichen Autoritätsgrenzen; Produktionsüberwachungs und Wiederherstellungsadapter werden heute im Allgemeinen nicht ausgeliefert. Wenn dieser Signalvertrag den Fehlern entspricht, die Sie fangen müssen, können Sie sich der Liste für frühen Zugriff anschließen, ohne Ihre Laufzeit oder Ihr Modell Gateway zu ersetzen.