Witdem
EN / DE
Zurück

LangGraph

LangGraph-Observability jenseits eines grünen Graphen

Ein beendeter LangGraph-Lauf heißt: Nodes sind gelaufen. Nicht: Der Job war ein Erfolg. Observability muss beides auf demselben Lauf zeigen.

Was gelaufen ist vs. Bedeutung

LangGraph baut Graphen aus Nodes, Edges und gemeinsamem State. Tracing zeigt, welche Nodes gelaufen sind. Das hilft. Es ist aber nur die halbe Geschichte.

Du brauchst auch ein klares Ziel. Hat der Job gehalten, den du benannt hast? Ohne diese Frage kann ein grüner Graph eine leere Antwort im State verstecken. Oder eine Antwort ohne Beleg.

Denk in Schichten auf einem Lauf. Tracing für Node-Spans. Checks für Qualität. Kosten für Spend. Outcomes für „war der Job erledigt?“ Halte sie zusammen. Lass die letzte Schicht nicht nur in LangSmith oder einer Tabelle liegen.

Produktziel — war der Job erledigt? Kosten — was hat dieser Lauf gekostet? Evaluation — Qualität vs. Kriterien? Tracing — LangGraph-Node-Spans

Was das in der Praxis heißt

Stell dir einen LangGraph-Support-Lauf von Start bis Ende vor. Du gehst denselben Lauf zweimal durch. Einmal für Nodes und State. Einmal für den Job, den du dem Nutzer zugesagt hast.

Zuerst schaust du auf Tracing. Classify lief. Retrieve lief. Answer gab Text zurück. Die Spans sehen gut aus. Das sagt nur: Der Graph hat seinen Pfad beendet.

Dann kommt die Frage zum Job. Gibt es eine brauchbare Antwort im State? Steht sie auf dem, was du geholt hast? Fallen die Checks durch, ist der Lauf für den Nutzer ein Fail. Auch wenn der Graph gesund wirkt.

Hänge Kosten an dieselbe Lauf-ID. Tokens und Tool-Spend zählen mehr, wenn du weißt, ob das Ziel passt. Ein günstiger Fail und ein teurer Fail sind zwei Reviews. Beide brauchen das markierte Ziel.

Schreib die Regel einmal neben den Code. Jede Person soll denselben Lauf gleich werten. Das ist LangGraph-Observability jenseits einer grünen Ampel.

Beispiel: falscher Erfolg

Jeder Node kann fertig werden. State-Updates können greifen. Der Graph kann HTTP 200 liefern. Der finale State kann trotzdem eine leere Antwort halten. Oder eine ohne Beleg. Diese Lücke ist ein falscher Erfolg.

Trace

Sieht gesund aus

  1. Nodes abgeschlossen
  2. State-Updates angewendet
  3. HTTP 200 OK

Alles wie geplant gelaufen.

Produktziel

Trotzdem verfehlt

Leere Antwort oder ohne Beleg

Runtime OK. Job nicht erledigt.

Ops traut vielleicht dem grünen Pfad. Produkt sieht trotzdem einen Fail. Ohne ein benanntes Ziel auf dem Lauf treffen sich diese beiden Sichten nie.

Ein beendeter Graph ist nicht dasselbe wie ein erfolgreicher Job. Node-Spans zeigen den Pfad. Sie beweisen nicht das Antwortfeld, das der Nutzer brauchte.

Ein Produktziel ist eine kurze, geteilte Regel für „fertig“. Belege sind die Felder, die Pass oder Fail zeigen. Behalte beides neben den LangGraph-Node-Spans.

Dann kann ein Review fair fragen: Haben wir Geld für einen echten Erfolg ausgegeben? Oder für einen sauberen Graphen, der den Job trotzdem verfehlt hat?

Graph anbinden

Nutze eine Stelle zum Anbinden. Wrappe den Graph. Behalte LangGraphs eigenes Tracing. Hänge Sinn an den State, der zurückkommt.

Das Snippet unten meldet, ob eine Antwort da ist. Das ist ein einfacher Start. Später kannst du mehr Checks ergänzen. Die Wrap-Form bleibt gleich.

from witdem_sdk.integrations.langgraph import instrument

graph = instrument(
    build_graph(),
    report_result=lambda state: {
        "result": "completed" if state.get("answer") else "unresolved",
        "result_valid": bool(state.get("answer")),
        "requirements": {"non_empty_answer": bool(state.get("answer"))},
    },
)

Erfolg neben dem Code deklarieren

Lege das Produktziel im Repo ab. Dann wertet jede Person denselben Lauf mit derselben Regel.

Ein Contract benennt Artefakt und Ziel. Pass heißt: Das Antwortfeld ist da. Die Regel liegt in Git beim Graph. Nicht nur hinter einem Schalter im Dashboard.

version: 1
service:
  name: langgraph-answer
  runtime: langgraph
contracts:
  useful_answer:
    artifact:
      name: Answer
      valid:
        non_empty: $.answer
    product_goal:
      name: Non-empty answer
      achieved:
        all:
          - $.witdem.artifact_valid

Was am Lauf zählt

Ob das Ziel hält, welche Belege da sind und was der Spend war: Das sollte dieselbe Lauf-ID teilen. Behalte es neben den Node-Spans. Ersetze Spans nicht durch einen einzelnen Score.

Wenn du einen Lauf öffnest, willst du Pfad und Outcome zusammen. So findest du einen falschen Erfolg. Ohne über Tools hinweg zu raten.

Workflow Replay von LangGraph Support Routing mit Classify-, Retrieve- und Answer-Schritten auf demselben Lauf
Workflow Replay — LangGraph Support-Routing-Pfad (Classify → Retrieve → Answer) mit inaktivem Escalate-Zweig

Beispiel ausführen

Starte mit dem State-Graph-Beispiel im Open-Source-Repo. Binde den Helper an. Deklariere ein Ziel. Prüfe einen Lauf von Ende zu Ende.

Lies die LangGraph-Docs, wenn du die API-Form brauchst. Behalte Tracing. Ergänze die Outcome-Schicht daneben.

GitHub-Beispiel LangGraph-Docs

FAQ

Heißt ein grüner LangGraph-Lauf Erfolg? Nein. Grün heißt: Nodes sind fertig. Erfolg heißt: Das Ziel, das du benannt hast, hat für diesen Lauf gehalten.

Ersetze ich LangSmith oder natives Tracing? Nein. Behalte LangSmith oder natives Tracing für Node-Spans. Hänge Outcome-Felder daneben an denselben Lauf. Sie arbeiten zusammen.

Was ist ein Produktziel für einen Graph? Eine kurze, geteilte Regel für „fertig“. Zum Beispiel: Antwort im State ist nicht leer. Belege sind die Felder, die Pass oder Fail zeigen.

Wo soll die Regel liegen? Im Repo neben dem Graph. So nutzen Reviews eine Definition. Nicht in jedem Tool neu erfinden, was „gut“ heißt.

Weiterführend

Observability für agentische Workflows · Haystack-Observability · LangChain-Observability · OpenAI-Agents-Observability

Loslegen Dokumentation lesen GitHub
Witdem

Analytics für AI-Agenten und mehrstufige AI-Anwendungen.

Start Leitfaden Datenschutz Impressum Lizenz