Skip to main content
Was jede Einstellung, Methode und jedes Feld bewirkt. Wenn Sie zum ersten Mal instrumentieren, beginnen Sie mit dem Leitfaden – diese Seite dient als Nachschlagewerk.

Leitfaden für benutzerdefinierte Agents

Installation, Instrumentierung, die Event-Methoden, ein ausgearbeitetes Beispiel und häufige Probleme.

Framework im Einsatz?

LangChain, CrewAI, LlamaIndex und Pydantic AI instrumentieren sich mit einem einzigen Aufruf selbst.
Python 3.10 oder neuer. Keine Laufzeitabhängigkeiten.

Installation

Das Paket wird als failproofai-sdk installiert und in Python als failproofai_sdk importiert. Framework-Extras wie failproofai-sdk[langgraph] installieren das Framework selbst; die Adapter werden stets im Basis-Wheel mitgeliefert.

Verbindung zum Failproof-Daemon herstellen

  1. Gehen Sie zu Admin → Keys und erstellen Sie einen Schlüssel mit events:add.
  2. Verbinden Sie den Failproof-Daemon mit Cloud auf der Agent-Maschine.
  3. Führen Sie eine instrumentierte Sitzung aus und suchen Sie die genaue ID unter Observe → Events.
  4. Gehen Sie zu Observe → Sessions, wählen Sie dieselbe Umgebung und öffnen Sie den rekonstruierten Trace. Eine benutzerdefinierte Python-Agent-Sitzung, rekonstruiert als Ausführungsgraph und geordneter Event-Trace.

Konfiguration

Alternativ per Umgebungsvariable setzen:
Keine Kommas in environment. Die Verarbeitungspipeline teilt dieses Feld an Kommas auf, um Filter zu erstellen, und verwirft jeden Event, dessen Bezeichnung ein Komma enthält – ein ganzer Durchlauf verschwindet dabei lautlos. Schreiben Sie prod-eu, nicht prod,eu.configure(environment="prod,eu") löst eine Exception aus, damit Sie es sofort bemerken. AGENTEYE_ENVIRONMENT kann keine Exception auslösen – niemand ruft Sie auf – daher wird einmal gewarnt und auf dev zurückgefallen.
Events werden im Arbeitsspeicher gepuffert und im Hintergrund alle flush_interval Sekunden geschrieben, mit einem abschließenden Flush beim Beenden des Interpreters. Ein abrupt beendeter Prozess verliert alle noch nicht geschriebenen Events.

Identität

Jeder Event gehört zu einer Sitzung und einem Agent. Die Scopes füllen beides aus, sodass Sie sie selten selbst übergeben müssen:
session_id oder agent_id explizit zu übergeben funktioniert weiterhin und hat Vorrang. Wenn weder ein Scope gebunden noch ein Wert übergeben wird, löst der Aufruf einen TypeError aus, anstatt einen Event zu senden, den Cloud stillschweigend verwerfen würde.
Die Identität wird über Kontextvariablen weitergegeben. Sie folgt asyncio-Tasks automatisch, jedoch nicht neuen Threads – umschließen Sie einen Worker mit failproofai_sdk.propagate(), sonst landen seine Events ohne Zuordnung.

Event-Katalog

Fünfzehn Methoden. Die meisten kommen in Paaren – Sie rufen den Öffner auf, dann den Schließer, und das SDK misst den Zeitraum dazwischen. Drei stehen für sich allein: error, human_pause, human_interrupt.
Jede Methode akzeptiert außerdem session_id und agent_id, die die Scopes für Sie befüllen. Alles, was als None belassen wird, wird weggelassen und nicht als JSON null gesendet; jede Methode gibt None zurück.
Um einen Durchlauf als fehlgeschlagen zu markieren, muss outcome einen der folgenden Werte haben: failed, error, timeout oder rejected. Alles andere – einschließlich des ähnlichen "failure" – wird als Erfolg gewertet.

Paarung und Dauer

Eine Regel: Geben Sie dem schließenden Event dieselbe ID wie dem öffnenden. Damit werden sie verknüpft, und das SDK kann den Zeitraum dazwischen messen. Übergeben Sie duration_ms nicht selbst. Das SDK misst den Wert, und eine eigene Übergabe löst einen ValueError aus. Die einzige Ausnahme ist model_response, wo nur Sie die tatsächliche Provider-Latenz kennen. Übergeben Sie eine ganze Anzahl von Millisekunden – ein Float löst eine Exception aus, da die Spalte eine 32-Bit-Ganzzahl ist und der Wert sonst leer gespeichert würde.
  • IDs müssen nur pro Typ und pro Sitzung eindeutig sein. Ein Tool-Aufruf und ein Hook können dieselbe ID teilen; zwei gleichzeitig laufende Sitzungen können dieselben IDs ohne Kollision wiederverwenden.
  • Sie sind nicht auf einen Agent beschränkt. Ein Paar, das unter einem Agent geöffnet und unter einem anderen geschlossen wird, wird dennoch korrekt zugeordnet – was bei Multi-Agent-Code der Normalfall ist.
  • request_id ist optional, wird aber empfohlen. Ohne sie werden Model-Events in der Reihenfolge ihres Eintreffens gepaart, sodass zwei gleichzeitige Aufrufe im selben Agent falsch zugeordnet werden können.
  • Ein Paar, das sich über mehrere Prozesse erstreckt, wird in Cloud weiterhin abgeglichen, aber das SDK kann die Zeit nicht messen – kein Prozess hat beide Hälften gesehen.
  • Höchstens 10.000 Öffner warten gleichzeitig auf einen Schließer. Darüber hinaus wird der älteste verworfen, damit ein Speicherleck nicht unbegrenzt wachsen kann.

Eigene Felder

Jedes zusätzliche Schlüsselwort, das Sie übergeben, wird zusammen mit dem Event gespeichert:
Verwenden Sie nach Möglichkeit JSON-Typen, wenn Sie die Werte später abfragen möchten. Alles andere – eine UUID, ein Datetime-Objekt, ein Decimal, ein Set, Bytes, ein Modellobjekt – wird als Zeichenkette gespeichert.
Präfixieren Sie Ihre Feldnamen. Zusätzliche Felder werden zuletzt angewendet, sodass ein Feld mit dem Namen model, tool_name oder outcome den eigentlichen Wert stillschweigend überschreibt. Die Framework-Adapter verwenden fw_; tun Sie dasselbe, und es kann zu keinen Kollisionen kommen.Aus diesem Grund führt ein falsch geschriebenes optionales Feld auch nie zu einem Fehler – es wird einfach zu einem neuen benutzerdefinierten Feld. Wenn ein Standardfeld in Cloud fehlt, prüfen Sie zuerst die Schreibweise.
Diese fünf Namen sind reserviert und werden direkt abgelehnt: timestamp, session_id, agent_id, type, environment.

Zustellung und Überprüfung

Überprüfen Sie unter Observe → Events, ob agent_start als erster und agent_end als letzter Event vorhanden ist. Öffnen Sie dann Observe → Sessions und stellen Sie sicher, dass Model-, Tool-, Human-, Hook- und Error-Events in der vorgesehenen Reihenfolge erscheinen. Verwenden Sie die Sitzungs-ID als primären Schlüssel zur Fehlersuche.
Wenn Cloud leer ist, prüfen Sie $FAILPROOFAI_HOME/custom-agents/events, andernfalls ~/.failproofai/custom-agents/events. JSONL-Dateien belegen die Emission durch das SDK; ein wachsender Spool deutet auf ein Daemon-Konfigurations- oder Zustellungsproblem hin, während ein leerer Spool auf ein Instrumentierungs- oder Prozesslebensdauerproblem hindeutet.
Prüfen Sie den Spool nur, wenn der Daemon gestoppt ist. Während er läuft, erfasst und löscht er jede Charge innerhalb von Millisekunden – eine Verzeichnisauflistung steht dann im Wettbewerb mit dem Collector und zeigt weit weniger Events als tatsächlich emittiert wurden.

Fehler in einer benutzerdefinierten Laufzeitumgebung verhindern

Nutzen Sie Audit-Befunde und verknüpfte Traces, um die unsichere Aktion, den erforderlichen Nachweis und die beabsichtigte Reaktion zu definieren. Eine benutzerdefinierte Enforcement-Integration muss die Aktion vor der Ausführung offenlegen, ihre strukturierte Eingabe an die Policy-Engine weiterleiten und die daraus resultierende allow-, instruct- oder deny-Entscheidung anwenden. Kontaktieren Sie Failproof AI – wir helfen Ihnen dabei, die Modell-, Tool- und Lebenszyklus-Grenzen Ihrer Laufzeitumgebung auf Policy-Hooks abzubilden, und validieren die Integration gemeinsam mit Ihnen.