failproofai 1.0.1-beta.0 → 1.0.1

package/.next/standalone/docs-old/de/agenteye/hermes-capture.mdx

@@ -0,0 +1,53 @@
+---
+title: "Hermes-Sitzungsaufzeichnung"
+description: "Bringen Sie die Hermes-Gateway-Sitzungen Ihres Teams — Slack, Telegram, CLI und geplante Ausführungen — als gewöhnliche Sitzungen und Ereignisse in AgentEye ein."
+---
+
+[Hermes](https://hermes-agent.nousresearch.com) beantwortet die Anfragen Ihres Teams von überall, wo es bereits arbeitet — Slack, Telegram, der CLI, geplante Ausführungen. Die Hermes-Sitzungsaufzeichnung bringt all das als gewöhnliche Sitzungen und Ereignisse in AgentEye ein, sodass der Assistent, mit dem Ihr Team täglich spricht, genauso beobachtbar ist wie die Agenten, die Sie selbst schreiben.
+
+Ein kleiner Hintergrund-Collector liest Hermes' lokalen Sitzungsspeicher, während dieser beschrieben wird, und überträgt die Sitzungen an AgentEye. Er funktioniert genauso wie die Aufzeichnung bei [Codex](/de/agenteye/codex-capture) und [OpenClaw](/de/agenteye/openclaw-capture), und ein einzelner Collector kann mehrere davon gleichzeitig aufzeichnen.
+
+---
+
+## Was aufgezeichnet wird
+
+Jede Hermes-Sitzung auf dem Rechner wird aufgezeichnet, unabhängig davon, über welchen Kanal sie zustande kam. Jede einzelne wird zu einer AgentEye-[Sitzung](/de/agenteye/sessions); ihre Benutzer- und Assistentennachrichten, Tool-Aufrufe und Tool-Ergebnisse werden zu den entsprechenden [Ereignissen](/de/agenteye/event-stream).
+
+Der Kanal, über den eine Sitzung gestartet wurde — Slack, Telegram, CLI oder eine geplante Ausführung — wird in der Sitzung festgehalten, sodass Sie sie unterscheiden und nach einer bestimmten filtern können. Dazu kommen das Modell, auf dem die Sitzung lief, der Chat und die Person, von der sie gestartet wurde, sowie — wenn eine Sitzung eine weitere erzeugt hat — die Verknüpfung zurück zur übergeordneten Sitzung.
+
+Sitzungen erscheinen, sobald Hermes sie startet, unabhängig davon, ob bereits etwas gesagt wurde. Die Antwort eines Gesprächsschritts und seine Tool-Aufrufe bleiben in der Reihenfolge, in der sie tatsächlich stattfanden. Wenn eine Sitzung endet, erfahren Sie auch, warum sie endete, was sie gekostet hat und wie viele Tokens sie verbrauchte.
+
+---
+
+## Aktivierung
+
+Die Aufzeichnung ist deaktiviert, bis Sie sie einschalten. Installieren Sie den Collector mit einem API-Schlüssel, der die Berechtigung `events:add` besitzt (siehe [API-Schlüssel](/de/agenteye/api-keys)), und aktivieren Sie die Hermes-Aufzeichnung:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/FailproofAI/agenteye-collector/main/install.sh \
+  | sh -s -- --key <YOUR_API_KEY> --hermes-enabled
+```
+
+Dadurch wird der Collector installiert, als Hintergrunddienst registriert und die Aufzeichnung gestartet. Bestätigen Sie, dass er läuft:
+
+```bash
+agenteye-collector health
+```
+
+Möchten Sie mehrere Agenten auf demselben Rechner aufzeichnen? Fügen Sie das Flag jedes Agenten demselben Befehl hinzu — zum Beispiel `--hermes-enabled --codex-enabled`.
+
+Beim ersten Start werden Ihre vorhandenen Hermes-Sitzungen einmalig nachgefüllt, und neue Aktivitäten werden dann innerhalb von Sekunden übertragen. Die eigenen Daten von Hermes werden dabei nur gelesen — niemals verändert oder gelöscht — und jede Nachricht wird genau einmal übertragen, auch nach Neustarts.
+
+`health` teilt Ihnen außerdem mit, ob alles, was der Collector aufgezeichnet hat, tatsächlich bei AgentEye angekommen ist. Wenn ein Batch nicht zugestellt werden konnte, wird er aufbewahrt und erneut versucht, anstatt verworfen zu werden. Die Prüfung meldet so lange einen ungesunden Zustand, wie noch etwas aussteht — „gesund" bedeutet also, dass Ihre Daten angekommen sind, nicht lediglich, dass der Prozess läuft.
+
+---
+
+## Wo es erscheint
+
+Aufgezeichnete Sitzungen erscheinen unter **Sessions** und ihre Ereignisse im **Events**-Stream, genauso wie bei jedem anderen beobachteten Agenten — sodass [Sitzungswiedergabe](/de/agenteye/sessions), [Suche](/de/agenteye/queries), [Auswertungen](/de/agenteye/evaluations) und [Benachrichtigungen](/de/agenteye/alerts) alle darauf anwendbar sind. Filtern Sie nach dem Hermes-Agenten, um nur dessen Sitzungen anzuzeigen.
+
+---
+
+## Datenschutz
+
+Hermes-Sitzungen enthalten das vollständige Gesprächsprotokoll — einschließlich Befehlsausgaben, Dateiinhalten und allem, was der Agent gelesen oder geschrieben hat — und können Geheimnisse enthalten. Aufgezeichnete Sitzungen werden unverändert übertragen. Aktivieren Sie die Aufzeichnung daher nur dort, wo die Zentralisierung dieser Inhalte in AgentEye angemessen ist, und vergeben Sie dem Collector einen Schlüssel, der ausschließlich auf `events:add` beschränkt ist. Unter [Sicherheit](/de/agenteye/security) erfahren Sie, wie Ihre Daten isoliert aufbewahrt werden.

package/.next/standalone/docs-old/de/agenteye/incidents.mdx

@@ -0,0 +1,50 @@
+---
+title: "Incidents"
+description: "Wenn ein Alert ausgelöst wird, sieht jeder, dass der Incident offen ist, wer ihn verantwortet und was bisher geschehen ist – in einer übersichtlichen, zugeordneten Timeline."
+---
+
+
+Wenn ein Alert ausgelöst wird, lautet die erste Frage immer: „Wer kümmert sich darum?" Incidents liefern die Antwort: Sobald eine Schwellenwertüberschreitung eintritt, sieht jeder, dass der Incident offen ist, wer ihn verantwortet und was bisher genau passiert ist – als saubere, zugeordnete Dokumentation, die sich direkt für eine Post-mortem-Analyse verwenden lässt.
+
+![Der Incidents-Posteingang: alert-verknüpfte und manuell geöffnete Incident-Karten, nach Status gruppiert, jeweils mit Schweregrad-Badge und zugewiesener Person](/agenteye/images/incidents.png)
+*Der Posteingang gruppiert offene Incidents nach Status und filtert nach Schweregrad und zugewiesener Person, sodass sofort ersichtlich ist, was jetzt menschliches Eingreifen erfordert.*
+
+## Auf einen Blick sehen, wer zuständig ist
+
+Kein „Schaut da gerade jemand drauf?" mehr im Chat. Eine Schwellenwertüberschreitung öffnet automatisch einen Incident und legt ihn in einen gemeinsamen Posteingang, gruppiert nach Status. Wer ihn bestätigt, erscheint namentlich darauf – das Team weiß sofort, dass es in Bearbeitung ist. Die Bestätigung ist gemeinsam nutzbar: Mehrere Operatoren können denselben Incident bestätigen, wobei jeder einzeln erfasst wird. So ist ein vollständiges War-Room-Team namentlich sichtbar, ohne dass sich Einträge überschneiden. Eine verantwortliche Person für das Triage lässt sich zuweisen; der Posteingang kann nach Schweregrad oder zugewiesener Person gefiltert werden, um nur die eigenen Incidents anzuzeigen.
+
+## Die vollständige Geschichte in einer Timeline
+
+Wenn der Incident abgeschlossen ist, ist das Protokoll bereits fertig. Beim Öffnen eines Incidents sind der Auslöser, eine Zusammenfassung der Überschreitung, zugewiesene Personen und Abonnenten, ein Kommentarbereich zur direkten Koordination sowie eine unveränderliche Aktivitäts-Timeline sichtbar.
+
+![Eine Incident-Detailansicht: der übergeordnete Alert und die Überschreitungszusammenfassung, zugewiesene Personen und Abonnenten, eine zugeordnete Aktivitäts-Timeline und ein Kommentarbereich](/agenteye/images/incident-detail.png)
+*Alles, was passiert ist, in chronologischer Reihenfolge – jede Zeile mit dem Namen der verantwortlichen Person.*
+
+Jede Aktion (geöffnet, bestätigt, gelöst usw.) wird in diese Timeline geschrieben und niemals nachträglich geändert. Jeder Eintrag ist zugeordnet: per E-Mail dem Operator, der die Aktion durchgeführt hat, oder **automated** für alles, was Failproof AI Observability selbstständig getan hat – beispielsweise das Öffnen des Incidents bei einer Schwellenwertüberschreitung. Nichts ist anonym und nichts geht verloren, sodass die Post-mortem-Analyse nahezu von selbst entsteht.
+
+## Wie sich ein Incident entwickelt
+
+```mermaid
+stateDiagram-v2
+    [*] --> firing
+    firing --> acknowledged: an operator acks
+    firing --> resolved: an operator resolves
+    acknowledged --> resolved: an operator resolves
+    resolved --> [*]
+```
+
+- **Offen (firing):** Die Überschreitung öffnet den Incident und benachrichtigt die konfigurierten Kanäle einmalig. Wiederholte Überschreitungen werden in denselben Incident aufgenommen und aktualisieren dessen Nachweis, anstatt erneut Benachrichtigungen zu versenden.
+- **Bestätigt (acknowledged):** Ein Operator übernimmt den Incident. Er bleibt offen, und spätere Überschreitungen aktualisieren den Nachweis ohne weitere Benachrichtigungen.
+- **Gelöst (resolved):** Ein Operator schließt den Incident. Eine automatische Auflösung beim Wegfall der Bedingung ist geplant, aber noch nicht aktiviert – ein Incident bleibt daher offen, bis ein Mensch ihn manuell auflöst. Das sorgt für Klarheit darüber, was tatsächlich behoben ist. Für denselben Alert kann später ein neuer Incident geöffnet werden.
+
+Ein Alert kann zu einem Zeitpunkt höchstens einen offenen Incident haben, sodass eine flatternde Regel keine Duplikate erzeugen kann. Incidents lassen sich auch manuell öffnen: als eigenständiger Incident für etwas, das kein Alert erfasst hat, oder als einem bestehenden Alert zugeordneter Incident – sofern die Berechtigung `incidents:write` vorhanden ist.
+
+## Wo es zu finden ist
+
+Incidents befinden sich unter `/<org-slug>/incidents`. Für die Anzeige wird **`incidents:read`** benötigt; für das manuelle Öffnen eines Incidents **`incidents:write`**; für das Bestätigen, Zuweisen, Kommentieren und Lösen **`incidents:ack`**. Ältere Schlüssel mit der zurückgezogenen Berechtigung `alerts:ack` funktionieren weiterhin, da sie als `incidents:ack` anerkannt werden – eine Neuausstellung für Bereitschaftsrotationen ist daher nicht erforderlich.
+
+## Verwandte Themen
+
+- [Alerts](/de/agenteye/alerts): die Regeln, die Incidents öffnen, wenn ein Schwellenwert überschritten wird.
+- [Error Tracking](/de/agenteye/error-tracking): alle Fehler an einem Ort einsehen und einen davon zu einem Alert heraufstufen.
+- [Audits](/de/agenteye/audits): der geplante Analyst, der Fehler findet, die von keiner Regel überwacht wurden.

package/.next/standalone/docs-old/de/agenteye/observability.mdx

@@ -0,0 +1,23 @@
+---
+title: "Beobachten"
+description: "Die Beobachtungsoberflächen zeigen Ihnen, was Ihre Agenten gerade tun, und ermöglichen den detaillierten Einblick in einzelne Ausführungen."
+---
+
+
+Die Beobachtungsoberflächen zeigen Ihnen, was Ihre Agenten gerade tun, und ermöglichen den detaillierten Einblick in einzelne Ausführungen. Alle Daten hier sind live, auf Ihre Organisation beschränkt und nach Datumsbereich, Umgebung, Agent und Sitzung filterbar – so gelangen Sie in Sekunden von „irgendetwas stimmt nicht" zum exakten Ausführungslauf.
+
+![Der Live-Event-Stream, farbcodiert nach Typ und filterbar nach Umgebung, Agent und Sitzung](/agenteye/images/events-stream.png)
+
+Vier Oberflächen, jede mit einer eigenen Seite:
+
+- **[Event-Stream](/de/agenteye/event-stream)**: der live, schrittweise Verlauf jeder Ausführung über alle Agenten hinweg, neueste zuerst. Die Startseite Ihrer Organisation und erste Anlaufstelle bei der Fehlersuche.
+- **[Sitzungen und Ausführungsgraph](/de/agenteye/sessions)**: diese Ereignisse zu einer Zeile pro Ausführung zusammengefasst, plus eine git-artige Darstellung des Ablaufs jeder Ausführung.
+- **[Performance-Metriken](/de/agenteye/telemetry)**: Latenz-Heatmaps und p50/p95/p99-Kennwerte für Ihre Modelle, Tools und Hooks, sodass ein Ausreißer am oberen Ende sofort vom Median auffällt.
+- **[Fehlerverfolgung](/de/agenteye/error-tracking)**: eine einzige Triage-Oberfläche für alles, was schiefgelaufen ist – mit einem Klick von einem ausgelösten Alert zum fehlerhaften Ausführungslauf.
+
+## Verwandte Themen
+
+- [Evaluierungen](/de/agenteye/evaluations): Bewerten Sie jeden Ausführungslauf hinsichtlich der Qualität.
+- [Alerts](/de/agenteye/alerts): Wandeln Sie beliebige Schwellenwerte in Benachrichtigungsregeln um.
+- [Audits](/de/agenteye/audits): Lassen Sie Failproof AI Observability Fehlermuster über Sitzungen hinweg für Sie finden.
+- [CLI und Agenten](/de/agenteye/cli-and-agents): dieselbe Observability direkt aus Ihrem Terminal.

package/.next/standalone/docs-old/de/agenteye/openclaw-capture.mdx

@@ -0,0 +1,49 @@
+---
+title: "OpenClaw Session-Aufzeichnung"
+description: "Leiten Sie die lokalen OpenClaw-Sitzungen Ihres Teams als gewöhnliche Sessions und Events in AgentEye weiter — ohne Änderungen an der Art, wie OpenClaw ausgeführt wird."
+---
+
+Wenn Ihr Team [OpenClaw](https://docs.openclaw.ai) nutzt, bringt die OpenClaw-Sitzungsaufzeichnung diese Sessions als gewöhnliche Sessions und Events in AgentEye ein. So können Sie sie durchsuchen, wiedergeben und gemeinsam mit allem anderen auswerten, was Sie beobachten. Sie ergänzt das [Python SDK](/de/agenteye/python-sdk): Das SDK instrumentiert Agenten, die Sie selbst schreiben, während diese Funktion die OpenClaw-Arbeit erfasst, die Ihr Team bereits durchführt — ohne Änderungen an deren Arbeitsweise.
+
+Ein kleiner Hintergrund-Collector liest OpenClaw's lokale Sitzungsprotokolle, während sie geschrieben werden, und übermittelt sie an AgentEye. Er funktioniert genauso wie der [Codex Capture](/de/agenteye/codex-capture), und ein einzelner Collector kann beide gleichzeitig erfassen.
+
+---
+
+## Was aufgezeichnet wird
+
+Jeder Agent, der im OpenClaw-Setup eines Rechners konfiguriert ist, wird vom Collector dieses Rechners erfasst — es ist keine agentenspezifische Einrichtung erforderlich.
+
+Jede OpenClaw-Sitzung wird zu einer AgentEye-[Session](/de/agenteye/sessions); ihre Benutzer- und Assistentennachrichten, Tool-Aufrufe und Tool-Ergebnisse werden zu den entsprechenden [Events](/de/agenteye/event-stream).
+
+---
+
+## Aktivierung
+
+Die Aufzeichnung ist deaktiviert, bis Sie sie einschalten. Installieren Sie den Collector mit einem API-Schlüssel, der die Berechtigung `events:add` besitzt (siehe [API-Schlüssel](/de/agenteye/api-keys)), und aktivieren Sie die OpenClaw-Aufzeichnung:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/FailproofAI/agenteye-collector/main/install.sh \
+  | sh -s -- --key <YOUR_API_KEY> --openclaw-enabled
+```
+
+Dadurch wird der Collector installiert, als Hintergrunddienst registriert und die Aufzeichnung gestartet. Bestätigen Sie, dass er läuft:
+
+```bash
+agenteye-collector health
+```
+
+Möchten Sie mehr als einen Agenten auf demselben Rechner erfassen? Fügen Sie das Flag für jeden weiteren Agenten demselben Befehl hinzu — zum Beispiel `--openclaw-enabled --codex-enabled`.
+
+Beim ersten Start werden Ihre vorhandenen OpenClaw-Sitzungen einmalig nachträglich importiert, danach wird neue Aktivität innerhalb von Sekunden übertragen. Die eigenen Dateien von OpenClaw werden ausschließlich gelesen — niemals verändert, verschoben oder gelöscht — und jede Sitzung wird genau einmal übermittelt, auch nach Neustarts.
+
+---
+
+## Wo die Daten erscheinen
+
+Aufgezeichnete Sitzungen erscheinen unter **Sessions** und ihre Events im **Events**-Stream, genau wie bei jedem anderen beobachteten Agenten — sodass [Session-Wiedergabe](/de/agenteye/sessions), [Suche](/de/agenteye/queries), [Auswertungen](/de/agenteye/evaluations) und [Benachrichtigungen](/de/agenteye/alerts) alle darauf anwendbar sind. Filtern Sie nach dem OpenClaw-Agenten, um nur dessen Daten anzuzeigen.
+
+---
+
+## Datenschutz
+
+OpenClaw-Protokolle enthalten die vollständige Sitzung — einschließlich Befehlsausgaben, Dateiinhalte und alles, was der Agent gelesen oder geschrieben hat — und können vertrauliche Informationen enthalten. Aufgezeichnete Sitzungen werden unverändert übermittelt. Aktivieren Sie die Aufzeichnung daher nur auf Rechnern und für Teams, bei denen die Zentralisierung dieser Inhalte in AgentEye angemessen ist, und vergeben Sie dem Collector ausschließlich einen auf `events:add` beschränkten Schlüssel. Unter [Sicherheit](/de/agenteye/security) erfahren Sie, wie Ihre Daten isoliert aufbewahrt werden.

package/.next/standalone/docs-old/de/agenteye/overview.mdx

@@ -0,0 +1,108 @@
+---
+title: "Failproof AI: Agenten auf Fehler überwachen"
+description: "Failproof AI Observability ist eine selbst gehostete Plattform zur Beobachtung, Bewertung und Verbesserung Ihrer KI-Agenten in der Produktion."
+---
+
+
+Failproof AI Observability ist eine selbst gehostete Plattform zur Beobachtung, Bewertung und Verbesserung Ihrer KI-Agenten in der Produktion. Sie zeichnet alles auf, was Ihre Agenten tun (jeden Tool-Aufruf, jede Modellanfrage, jeden Hook und jeden Fehler), bewertet die Qualität jedes Durchlaufs und zeigt Ihnen die Fehler, nach denen Sie nicht aktiv gesucht haben – alles in einem Dashboard, das Sie in Ihrer eigenen Infrastruktur betreiben.
+
+Wenn Sie KI-Agenten einsetzen und es leid sind zu rätseln, warum ein Durchlauf schiefgelaufen ist, sind Sie hier genau richtig. Diese Seite erklärt, was Failproof AI Observability Ihnen bietet und wie die einzelnen Teile zusammenpassen – noch bevor Sie irgendetwas installieren.
+
+> **Failproof AI Observability ist ein Enterprise-Produkt von Failproof AI.** Sie möchten es in Aktion sehen? Fordern Sie eine Demo an: E-Mail an [nikita@befailproof.ai](mailto:nikita@befailproof.ai).
+
+![Eine Failproof AI Observability-Sitzung als git-ähnlicher Ausführungsgraph neben der Ereigniszeitachse, mit einer Aufschlüsselung von Tools, Modellen und Hooks in der rechten Seitenleiste](/agenteye/images/session-detail.png)
+
+*Jeder Agentendurchlauf wird als git-ähnlicher Ausführungsgraph (links) neben seiner Ereigniszeitachse dargestellt. Parallele Unteragenten erhalten jeweils ihre eigene Spur; die rechte Seitenleiste schlüsselt die Tools, Modelle, Hooks und den Token-Verbrauch des Durchlaufs auf.*
+
+---
+
+## In Aktion erleben
+
+Zwei kurze Videos zeigen die zwei Dinge, die Teams zuerst nutzen: einen Durchlauf nachverfolgen und Fehler automatisch erkennen.
+
+<div style={{ position: "relative", width: "100%", paddingBottom: "56.25%", height: 0, overflow: "hidden", borderRadius: "12px", margin: "1.5rem 0" }}>
+  <iframe src="https://www.youtube.com/embed/VWxukZc5k7s?autoplay=1&mute=1&loop=1&playlist=VWxukZc5k7s&rel=0&playsinline=1" title="Watch: Agent Tracing by Failproof AI (2 min)" allow="autoplay; encrypted-media; picture-in-picture; fullscreen" allowFullScreen style={{ position: "absolute", top: 0, left: 0, width: "100%", height: "100%", border: 0 }}></iframe>
+</div>
+
+*Agenten-Tracing: Verfolgen Sie einen einzelnen Durchlauf Schritt für Schritt, vom Ziel über die Tools bis zur endgültigen Antwort.*
+
+<div style={{ position: "relative", width: "100%", paddingBottom: "56.25%", height: 0, overflow: "hidden", borderRadius: "12px", margin: "1.5rem 0" }}>
+  <iframe src="https://www.youtube.com/embed/C5nHKGQIqZQ?autoplay=1&mute=1&loop=1&playlist=C5nHKGQIqZQ&rel=0&playsinline=1" title="Watch: Automatically find where your agent is failing (2 min)" allow="autoplay; encrypted-media; picture-in-picture; fullscreen" allowFullScreen style={{ position: "absolute", top: 0, left: 0, width: "100%", height: "100%", border: 0 }}></iframe>
+</div>
+
+*Failproof Audit: Lassen Sie Failproof AI Observability Ihre Logs sitzungsübergreifend durchsuchen und erfahren Sie, was behoben werden muss.*
+
+---
+
+## Warum Teams es nutzen
+
+- **Sehen Sie, was Ihr Agent wirklich getan hat.** Jeder Durchlauf wird zu einem lesbaren, git-ähnlichen Ausführungsgraphen: welche Tools parallel liefen, welche Unteragenten abgezweigt wurden, wo es ins Stocken geriet und was es gekostet hat.
+- **Qualitätsrückgänge automatisch erkennen.** Verbinden Sie einen kleinen Scoring-Dienst, und Failproof AI Observability bewertet jeden abgeschlossenen Durchlauf – sodass ein Rückgang der Hilfsbereitschaft oder ein Anstieg von Halluzinationen von selbst sichtbar wird.
+- **Fehler finden, für die Sie keine Regel geschrieben haben.** Regelmäßige Audits durchsuchen Ihre Logs sitzungsübergreifend nach Fehlerclustern, Latenz-Ausreißern, niedrigen Bewertungen und hängenden Durchläufen und liefern Ihnen priorisierte, evidenzbasierte Erkenntnisse.
+- **Benachrichtigt werden, wenn es darauf ankommt.** Schwellenwertregeln reagieren auf Fehlerrate, Latenz, Kosten oder Evaluator-Scores und eröffnen Incidents, die Sie bestätigen, zuweisen und lösen können.
+- **Fragen in natürlicher Sprache stellen.** Ein KI-Assistent im Dashboard beantwortet Fragen wie „Wie entwickelt sich die Qualität in der Produktion diese Woche?" – auf Basis Ihrer eigenen Daten. Jede Änderung, die er vornimmt, ist genehmigungspflichtig.
+- **Ihre Daten behalten.** Failproof AI Observability ist selbst gehostet: Ereignisse, Prompts und Analysen bleiben in der von Ihnen kontrollierten Infrastruktur.
+
+---
+
+## Was Sie erhalten
+
+Failproof AI Observability ist um drei Ideen herum organisiert (**Beobachten**, **Analysieren** und **Verwalten**), die in der linken Seitenleiste des Dashboards gespiegelt werden.
+
+**Beobachten** (die unverfälschte Wahrheit dessen, was passiert ist):
+
+- **[Ereignis-Stream](/de/agenteye/event-stream)**: die Live-Aufzeichnung jedes einzelnen Schritts jedes Durchlaufs (Tool-Aufrufe, Modellaufrufe, Hooks, Fehler).
+- **[Sitzungen](/de/agenteye/sessions)**: diese Ereignisse zusammengefasst zu einer Zeile pro Durchlauf, jeweils bereit zur Bewertung, mit einem git-ähnlichen Ausführungsgraphen.
+- **[Performance-Metriken](/de/agenteye/telemetry)**: Latenz-Heatmaps pro Oberfläche und p50/p95/p99-Werte für Modelle, Tools und Hooks, damit ein Ausreißer im langen Ende sofort auffällt.
+- **[Fehlerverfolgung](/de/agenteye/error-tracking)**: eine einzige Triage-Oberfläche für alles, was schiefgelaufen ist, einen Klick von einem ausgelösten Alert entfernt.
+
+![Die Tools-Beobachtungsseite: eine Latenz-Heatmap, ein Perzentil-Band und ein Tool-Verteilungsbalken über 24 Zeitabschnitte](/agenteye/images/tools.png)
+
+*Jede Beobachtungsoberfläche kombiniert eine Sparkline und p50/p95/p99-Werte mit einer Latenz-Heatmap und einem Perzentil-Band. Hier gezeigt: Tools.*
+
+**Analysieren** (Aktivitäten in Erkenntnisse verwandeln):
+
+- **[Abfragen](/de/agenteye/queries)** und **[Dashboards](/de/agenteye/dashboards)**: gespeichertes SQL über Ihre Ereignisse und Evaluierungen, als geteilte, organisationsweite Dashboards visualisiert.
+- **[Evaluierungen](/de/agenteye/evaluations)**: Qualitätsbewertungen, die von Ihrem eigenen Evaluator-Dienst erstellt werden, mit Begründung pro Bewertung.
+- **[Audits](/de/agenteye/audits)**: wiederkehrende Untersuchungen, die Fehlermuster sitzungsübergreifend aufdecken.
+- **[Alerts](/de/agenteye/alerts)** und **[Incidents](/de/agenteye/incidents)**: Schwellenwertregeln, die Sie benachrichtigen, sowie ein Incident-Workflow zur Triage.
+
+**Schnittstellen** (auf Ihre Daten auf Ihre Weise zugreifen):
+
+- **[CLI](/de/agenteye/cli-and-agents)**: Steuern Sie Ihre gesamte Deployment vom Terminal oder einem Skript aus, und lassen Sie einen Coding-Agenten dies für Sie in natürlicher Sprache erledigen.
+- **[KI-Assistent](/de/agenteye/assistant)**: Stellen Sie Fragen zu Ihren Agenten in natürlicher Sprache, direkt im Dashboard.
+- **REST API**: Alles, was Dashboard und CLI tun, wird durch eine REST API unterstützt, die Sie direkt mit einem bereichsbegrenzten [API-Schlüssel](/de/agenteye/api-keys) aufrufen können – Ereignisse erfassen, Sitzungen und Evaluierungen abfragen sowie Dashboards, Alerts, Audits, Benutzer und Schlüssel verwalten, sodass Sie Failproof AI Observability in Ihr eigenes Tooling integrieren können.
+
+**Verwaltung** (für Ihr Team betreiben):
+
+- **[API-Schlüssel](/de/agenteye/api-keys)**: bereichsbegrenzte Token für den Collector, das Dashboard und den Assistenten.
+- **Benutzer**: passwortlose, E-Mail-basierte Anmeldung mit einer Zulassungsliste.
+- **Einstellungen**: organisationsweite Konfiguration, einschließlich Modell-Kontextfenster-Überschreibungen.
+
+---
+
+## Wie die Teile zusammenpassen
+
+Daten fließen in eine Richtung, von Ihrem Agenten-Code zum Dashboard: Ihr Agent sendet (über das Python-SDK) Ereignisse an den agenteye-collector, der sie an den Server weiterleitet, der das Dashboard bedient. Zwei optionale Dienste ergänzen das Ganze – ein Scoring-Dienst (Evaluierungen) und ein KI-Assistenten-Dienst (der In-Dashboard-Chat).
+
+- **Python SDK**: Sie fügen Ihrem Agenten einige `agenteye.event.*`-Aufrufe hinzu; Ereignisse werden lokal gepuffert.
+- **agenteye-collector**: ein schlanker Daemon auf jeder Agenten-Maschine, der Ereignisse bündelt und an den Server sendet.
+- **Server**: nimmt Ihre Ereignisse entgegen, verwaltet den Betriebszustand in Ihren eigenen Datenbanken und stellt die REST API bereit, die das Dashboard, die CLI und Ihre eigenen Integrationen verwenden.
+- **Dashboard**: wo Sie alles erkunden.
+- **Optionale Dienste**: ein Scoring-Dienst (Evaluierungen) und ein KI-Assistenten-Dienst (der In-Dashboard-Chat).
+
+Für das in der gesamten Dokumentation verwendete Vokabular (*Ereignis, Sitzung, Evaluierung, Audit, Befund, Incident*) siehe [Konzepte](/de/agenteye/concepts).
+
+---
+
+## Failproof AI Observability erhalten
+
+Failproof AI Observability ist ein Enterprise-Produkt von Failproof AI und funktioniert zusammen mit Failproof AI Enforcement – dem Richtlinien- und Guardrail-Produkt – unter der Failproof AI-Marke. Es läuft vollständig in Ihrer eigenen Umgebung. Wenn Sie noch keinen Zugang zu den Paketen haben, fordern Sie eine Demo an, und wir richten alles für Sie ein: E-Mail an [nikita@befailproof.ai](mailto:nikita@befailproof.ai).
+
+---
+
+## Nächste Schritte
+
+- [Konzepte](/de/agenteye/concepts): das Failproof AI Observability-Vokabular an einem Ort.
+- [Observability](/de/agenteye/observability): Verfolgen Sie, was Ihre Agenten tun, Durchlauf für Durchlauf.
+- [Sicherheit](/de/agenteye/security): Wie Failproof AI Observability Ihre Daten isoliert und unter Ihrer Kontrolle hält.

package/.next/standalone/docs-old/de/agenteye/python-sdk-skill.mdx

@@ -0,0 +1,131 @@
+---
+title: "Failproof AI Observability Python SDK Agent Skill"
+description: "Von einem nicht instrumentierten Agenten zu sichtbaren Events – Ihr Coding-Agent findet die Instrumentierungspunkte, implementiert sie und beweist, dass sie korrekt funktionieren."
+---
+
+Sagen Sie Ihrem Coding-Agenten *„Füge Failproof AI Observability zu diesem Agenten hinzu"* und lassen Sie ihn Ihre Schleife lesen, die richtigen Instrumentierungspunkte ermitteln, den Code schreiben und die Events verifizieren – bevor er die Aufgabe als erledigt markiert.
+
+Der **Python SDK Skill** (`agenteye-python-sdk`) ist ein *Agent Skill*: ein Ordner mit Anweisungen, den ein Coding-Agent wie Claude Code oder Codex bei Bedarf lädt, wenn eine Aufgabe dazu passt. Er bringt dem Agenten bei, das [Python SDK](/de/agenteye/python-sdk) zu verwenden – er ist keine Bibliothek und ändert nichts an der Funktionsweise des SDK.
+
+## Instrumentierung ist leicht zu schreiben – und leicht still falsch zu machen
+
+Das SDK ist klein: dreizehn Event-Methoden, alle ausschließlich als Keyword-Argumente. Ein Coding-Agent kann die [Python SDK](/de/agenteye/python-sdk)-Referenz lesen und in einer Minute plausible Instrumentierung produzieren.
+
+Das Problem ist, dass dieses SDK keinen Fehler wirft, wenn etwas falsch ist – und falsche Instrumentierung sieht genauso aus wie richtige Instrumentierung, bis jemand ein Dashboard öffnet und es leer vorfindet. Die Fehler, die wirklich Zeit kosten, sind allesamt stille:
+
+| Der Fehler | Was Sie sehen |
+|---|---|
+| Kein `agent_start` | Alle Events landen. Null Sessions. |
+| Environment nie gesetzt | Alles funktioniert, wird unter `dev` abgelegt. |
+| `outcome="failure"` | Der Lauf zeigt grün – nur `failed`, `error`, `timeout`, `rejected` zählen. |
+| Tippfehler im Feldnamen | Akzeptiert und als neues Feld gespeichert. |
+| Events aus einem Thread-Pool emittiert | Werden still verworfen. |
+
+Keiner davon wirft einen Fehler. Keiner taucht in Tests auf. Jeder einzelne ist im Skill dokumentiert – als Vertrag zusammen mit dem Check, der ihn erkennt.
+
+## Was der Skill tut – der Reihe nach
+
+Der Skill durchläuft dieselben drei Schritte, die ein sorgfältiger Entwickler gehen würde:
+
+1. **Planen.** Er liest Ihre Agenten-Schleife und stellt die zwei Fragen, die nur Sie beantworten können: Was zählt als ein Lauf (Ihre `session_id`), und wer sind die unterscheidbaren Akteure (Ihre `agent_id`)? Das wird geklärt, bevor Code geschrieben wird – denn eine spätere Änderung spaltet Ihre Historie und bricht die Trends.
+2. **Schreiben.** Er bindet die Identität einmal pro Lauf statt sie durch jede Aufrufstelle durchzufädeln, und wählt eine nebenläufigkeitssichere Form – ein Detail, das wichtig ist, weil die naheliegende Abkürzung zwei überlappende Läufe stillschweigend in einer einzigen Session vermischt.
+3. **Verifizieren.** Er führt Ihren Agenten aus und liest die entstandenen Event-Dateien, prüft ob `agent_start` vorhanden ist, das Environment stimmt und ein Lauf genau eine Session erzeugt hat.
+
+Dieser dritte Schritt ist der, den die meisten überspringen. Das SDK schreibt Events in lokale Dateien, sodass eine vollständige Integration auf einem Laptop bewiesen werden kann – ohne Server, ohne API-Key, ohne Netzwerk. Genau deshalb besteht der Skill darauf, diesen Schritt durchzuführen.
+
+## Verhältnis zu den anderen Skills
+
+Drei Skills, eine klare Aufteilung:
+
+| Skill | Einsetzen wenn | Was er berührt |
+|---|---|---|
+| **Python SDK Skill** (diese Seite) | Sie möchten, dass Ihr Agent Telemetrie *emittiert* – „Observability hinzufügen", „Warum erscheint mein Agent nicht?" | Schreibt Code in Ihrem Agenten-Repo. Liest nichts. |
+| **[Evaluator Skill](/de/agenteye/evaluator-skill)** | Sie möchten Läufe *bewerten* – „Was sollen wir überhaupt messen?" | Schreibt Code in Ihrem Repo; liest Telemetrie |
+| **[CLI Skill](/de/agenteye/cli-skill)** | Sie möchten *nachlesen*, was passiert ist, oder Ihr Deployment betreiben | Steuert die CLI als Sie, inklusive Änderungen |
+
+Die Übergabe erfolgt in dieser Reihenfolge: Dieser Skill bringt Events zum Fließen, der Evaluator bewertet sie, die CLI liest sie aus. Es gibt nichts zu bewerten und nichts zu lesen, bis Ihr Agent Sessions emittiert – wenn Sie von vorne beginnen, fangen Sie hier an.
+
+## Voraussetzungen
+
+1. **Python 3.10+** und die Agenten-Codebasis, die Sie instrumentieren möchten.
+2. **Das SDK.** Es wird an Kunden als privates Wheel ausgeliefert und nicht über einen öffentlichen Index – Ihr Onboarding erklärt, wie Sie es beziehen und installieren. Der Skill kennt den Installationspfad und fragt Sie, anstatt zu raten, falls er ihn nicht finden kann.
+3. **Nichts weiter.** Kein Dashboard-Login, kein API-Key, kein Netzwerk. Der Skill verifiziert anhand der Event-Dateien, die das SDK schreibt, und kann seine Arbeit offline abschließen und beweisen.
+
+## Bezugsquelle
+
+Der Skill befindet sich in der öffentlichen [`FailproofAI/skills`](https://github.com/FailproofAI/skills)-Sammlung:
+
+```bash
+npx skills add FailproofAI/skills --skill agenteye-python-sdk -a claude-code
+```
+
+Fügen Sie `-g` hinzu, um ihn für alle Projekte statt nur das aktuelle zu installieren, und `--copy`, wenn Ihre Umgebung keine Symlinks unterstützt. Für Codex übergeben Sie `-a codex`.
+
+## Manuelle Installation
+
+Agent Skills sind Ordner, die eine `SKILL.md` plus Referenzen enthalten. Falls Sie den Installer nicht verwenden möchten:
+
+- **Claude Code**: Kopieren Sie den Ordner `agenteye-python-sdk/` nach `~/.claude/skills/` (alle Projekte) oder `<Ihr-Repo>/.claude/skills/` (nur dieses Repo). Claude Code erkennt ihn automatisch – prüfen Sie die `/skills`-Liste oder fragen Sie einfach etwas, das dazu passt.
+- **Codex**: Codex liest dieselbe `SKILL.md`. Das mitgelieferte `agents/openai.yaml` setzt `allow_implicit_invocation: true`, sodass er automatisch gewählt wird, wenn eine Aufgabe passt; andernfalls rufen Sie ihn als `$agenteye-python-sdk` auf.
+
+Führen Sie Ihren Agenten **im Repository mit dem Code aus, den Sie instrumentieren möchten** – der Skill liest Ihre Agenten-Schleife, bevor er etwas vorschlägt.
+
+## Wie eine Session aussieht
+
+```text
+you   ▸ Add Failproof AI Observability to this agent.
+
+agent ▸ Read your loop — one tool dispatcher in tools.py, one Anthropic
+        wrapper in llm.py. Two questions before I write anything.
+
+        What counts as one run? You handle requests concurrently, so I'd
+        use the request id you already have in ctx.request_id — then a
+        session here and a request in your logs are the same string.
+
+        And who are the actors? I see a planner path and a researcher
+        path. Label them separately, or is that one agent to you?
+
+you   ▸ Request id is right. They're one agent, call it "assistant".
+
+agent ▸ Done. Wrapped the dispatcher and the LLM client; agent_start and
+        agent_end bracket handle_request, including the error path. Used
+        a context-local for identity — your dispatcher runs tools in a
+        thread pool, and the simpler approach would have mixed concurrent
+        runs into one session without complaining.
+
+        Verified against a real run: 11 events across 4 files —
+        agent_start, model_request/response, tool_use/tool_result x3,
+        agent_end (outcome=success). environment=production, one session
+        per request, durations paired.
+
+        One thing I did NOT do: your worker pool in batch.py submits
+        straight to the executor, so events from there would be dropped.
+        Want me to fix those too?
+```
+
+Das Muster, das auffällt: Er hat den Code gelesen, bevor er etwas vorschlug, nur die Fragen gestellt, die Sie beantworten können, eine bereits vorhandene ID wiederverwendet, die nebenläufigkeitssichere Form gewählt *weil* er einen Thread-Pool sah, und **durch Lesen der tatsächlichen Events verifiziert** statt einfach Erfolg zu erklären – und dann die eine Stelle markiert, von der er wusste, dass sie still versagen würde.
+
+## Was Sie ihn fragen können
+
+- *„Warum erscheint mein Agent nicht im Dashboard?"* → Geht die Leiter hinab: Werden Events geschrieben, ist `agent_start` vorhanden, stimmt das Environment, liest der Collector am richtigen Ort?
+- *„Alles landet unter dev."* → Das Environment wurde nie gesetzt oder durch einen späteren Aufruf zurückgesetzt.
+- *„Token-Tracking hinzufügen."* → Findet Ihren LLM-Wrapper und erfasst Modell, Stop-Grund und Nutzung.
+- *„Auch die Sub-Agenten instrumentieren."* → Eine Session, eindeutige Agenten-Labels, verschachtelt unter ihrem Elternteil.
+- *„Tests für die Instrumentierung schreiben."* → Zeigt das SDK auf ein temporäres Verzeichnis und macht Assertions auf die geschriebenen Events.
+
+## Worauf Sie achten sollten
+
+**Lassen Sie ihn verifizieren.** Der Schritt, der diesen Skill wertvoll macht, ist der letzte – Ihren Agenten ausführen und die Events zurücklesen. Ein Agent, der Instrumentierung schreibt und dann aufhört, hat die einfache Hälfte erledigt; die Hälfte, die still versagt, ist die andere.
+
+**Namen vereinbaren, bevor Code geschrieben wird.** `session_id` und `agent_id` sind die Achsen, nach denen jede Oberfläche gruppiert. Sie später umzubenennen spaltet die Historie: Alte Läufe behalten die alten Labels und Ihre Trends brechen. Der Skill wird fragen; die Antwort ist eine Minute Nachdenken wert.
+
+**Wenn Ihr Agent vorschlägt, das SDK von einem öffentlichen Index zu installieren, wurde der Skill nicht geladen.** Das SDK wird privat vertrieben. Dieser Vorschlag ist ein zuverlässiges Zeichen dafür, dass Ihr Coding-Agent rät statt dem Skill zu folgen – stoppen Sie ihn dort und prüfen Sie, ob der Skill installiert ist.
+
+Abgesehen davon ist der Wirkungsbereich überschaubar: Er schreibt Code in Ihrem Arbeitsverzeichnis und Event-Dateien dort, wo Sie es angeben. Er liest nichts aus Ihrem Deployment und ändert nichts daran.
+
+## Nächste Schritte
+
+- **[Python SDK](/de/agenteye/python-sdk)**: Die vollständige Event-Referenz – jeder Event-Typ und jedes Feld – hinter dem, was dieser Skill automatisiert.
+- **[Sessions](/de/agenteye/sessions)**: Was Ihre Instrumentierung produziert, sobald Events ankommen.
+- **[Evaluator Agent Skill](/de/agenteye/evaluator-skill)**: Der nächste Schritt, sobald Läufe ankommen – ihre Bewertung.
+- **[CLI Agent Skill](/de/agenteye/cli-skill)**: Ihre Telemetrie zurücklesen.