LangSmith: aus einem Observability-Produkt wurde eine Agent-Plattform

LangSmith ist eine gehostete Tracing- und Evaluierungsplattform für LLM-Anwendungen: jeder Aufruf, den ein Agent tätigt, wird zu einem Baum von Runs mit Ein- und Ausgaben, Latenz und Tokenzahlen, den man durchsuchen, bewerten und vergleichen kann. Das Urteil nach der Lektüre der Dokumentation: es ist das leistungsfähigste Werkzeug dieser Art und gleichzeitig das teuerste im Verständnis, denn es ist nicht mehr nur ein Observability-Produkt.

Es konkurriert mit Langfuse, Arize Phoenix und Helicone um das Observability-Budget und zunehmend mit der eigenen Runtime, denn derselbe Anbieter verkauft auf derselben Preisseite Deployment, Studio, Engine, Fleet, Sandboxes und ein LLM Gateway. Diese Ausweitung ist das wichtigste Abwägungspunkt, weil jeder zusätzliche Dienst separat abgerechnet wird.

Was es ist

Die Plattform hat vier Teile, die sich eine Rechnung teilen: Tracing, Evaluierung, Prompt-Verwaltung und eine Agent-Runtime. Das Ressourcenmodell ist wichtiger als der Funktionsumfang. Eine Organisation hält Workspaces, Workspaces halten Tracing-Projekte, Datensätze, Annotation Queues und Prompts, und jeder Trace liegt in genau einem Projekt. Die Kernfakten:

• Ein Trace ist eine Ausführung aus verschachtelten Runs; ein Run wird angelegt und dann aktualisiert, während die Arbeit vorankommt, deshalb sind Event- und Trace-Limit verschiedene Zahlen.
• Tracing läuft über die Dekoratoren des langsmith SDK, über eine REST-Ingest-API oder über OpenTelemetry-Spans jeder instrumentierten Anwendung.
• Offline-Evals laufen gegen Datensätze aus Beispielen mit Referenzausgaben, Online-Evals bewerten Live-Traces ohne Referenz.
• Evaluatoren können Code, LLM-as-judge, ein typisiertes Entscheidungsmodell, paarweise Bewertung oder Mensch sein, und ein Evaluator kann an mehrere Projekte gehängt werden.
• Annotation Queues, Dataset-Versionen und Splits, eine Prompt-Registry mit Commit-Tags und ein Playground sind alle enthalten.
• Selbstbetrieb gibt es, aber nur als Enterprise-Add-on hinter einem Lizenzschlüssel.

Wie es funktioniert

Die Instrumentierung läuft im eigenen Prozess und sendet Runs über HTTPS an LangSmith. Das SDK arbeitet in einem Hintergrundthread und fasst bis zu 100 Runs einer Session in einem API-Aufruf zusammen, damit Tracing nicht im Request-Pfad hängt. Eine serverseitige Queue übernimmt Ingestion, Retries und Integritätsprüfungen, bevor in den Trace-Speicher geschrieben wird.

Diese Queue erklärt, warum die Ingest-Grenzen als festes Fenster und nicht als glatter Durchschnitt formuliert sind und warum ein 429 ein normales Ereignis mit Backoff ist und kein Ausfall. Der Load Balancer setzt auf jedem Plan feste Grenzen pro Minute: 5000 POST- oder PATCH-Anfragen an die Runs-Endpunkte, 5000 an Feedbacks, 2000 für alle anderen Endpunkte und 30 Löschungen. Das SDK bündelt, und genau das hält eine ausgelastete Anwendung unter diesen Werten.

Erste Schritte

Zwei Umgebungsvariablen schalten Tracing ohne Codeänderung ein, was für die lokale Entwicklung zählt: LANGSMITH_TRACING steuert Dekorator und Context Manager, LANGSMITH_PROJECT benennt das Zielprojekt und ist standardmäßig default. Das minimale Python-Setup verfolgt eine Pipeline als verschachtelte Runs:

import asyncio

from langsmith import Client, traceable
from openai import AsyncOpenAI

client = Client()
llm = AsyncOpenAI()


@traceable(run_type="retriever", name="retrieve_docs")
async def retrieve_docs(question: str) -> list[str]:
    return ["Annual report: revenue up 12 percent."]


@traceable(run_type="llm", name="answer")
async def answer(question: str, context: list[str]) -> str:
    reply = await llm.chat.completions.create(
        model="gpt-5.4-mini",
        messages=[{"role": "user", "content": f"{question}\n{chr(10).join(context)}"}],
    )
    return reply.choices[0].message.content


@traceable(name="support_agent")
async def support_agent(question: str) -> str:
    return await answer(question, await retrieve_docs(question))


async def main() -> None:
    try:
        print(await support_agent("How did revenue move?"))
    finally:
        await client.flush()  # background thread must finish before exit


asyncio.run(main())

Der Dekorator propagiert den Kontext, die drei Funktionen erscheinen also ohne manuelles Verdrahten als Baum, und run_type entscheidet, wie das Dashboard einen Knoten darstellt: llm liefert Tokenzahlen und Latenz, retriever und tool kennzeichnen die übrigen Schritte. Derselbe Client fährt Offline-Evaluierungen gegen einen Datensatz, und dort fängt der eigentliche Wert an, sich zu verzinsen.

Dieselbe API betreibt die Eval-Schleife. evaluate nimmt eine Zielfunktion, einen Datensatz und eine Liste von Evaluatoren, erzeugt ein Experiment mit einem Run pro Beispiel und lässt sich aus CI steuern: Jede eingecheckte Prompt-Änderung gegen die getaggte Dataset-Version evaluieren und den Build fehlschlagen lassen, wenn die Groundedness um mehr als einen Punkt fällt. LangSmith versioniert Datensätze automatisch, wenn sich Beispiele ändern, ein Tag pinnt einen CI-Lauf also auf einen Datenstand. Die Dokumentation ist deutlich: fünf bis zehn kuratierte Beispiele für gute Ausgaben schreiben, bevor irgendein Evaluator entsteht.

Was es kostet

Seats sind der sichtbare Preis, Traces sind die metrierte Größe. Der Developer-Plan ist für einen Seat kostenlos und enthält 5.000 Base-Traces pro Monat; Plus kostet 39 US-Dollar pro Seat und Monat mit 10.000 enthalten und unbegrenzt vielen weiteren Seats; Enterprise wird angeboten und ergänzt Selbst- und Hybrid-Betrieb, eigenes SSO sowie attribut- und rollenbasierte Zugriffskontrolle.

Ein Event ist das Anlegen oder das Aktualisieren eines Runs, ein in derselben Stunde angelegter und dann gepatchter Run zählt also zweimal gegen das Stundenlimit, und ein 2 MB großer Run, der später auf 3 MB aktualisiert wird, zählt 5 MB gegen das Volumenlimit. Das ist der Mechanismus, den man in der Kapazitätsplanung modellieren muss: die Form des Traces, nicht die Zahl der Requests, treibt die Grenze.

Der Rest der Plattform wird in LangChain Standard Units abgerechnet, eine LSU kostet 1,00 US-Dollar. Die Engine läuft alle sechs Stunden, ein einzelner Lauf wird je nach Tracevolumen und Issue-Zahl auf 7 bis 45 LSU geschätzt. Fleet enthält 7 LSU auf Developer und 37 LSU auf Plus, Sandboxes 8 LSU, ein Perceived-Error-Evaluator-Lauf 0,015 LSU. Ein Seat für 39 US-Dollar sagt also wenig über die Rechnung aus, sobald die Runtime genutzt wird.

Natives Tracing oder OpenTelemetry

LangSmith nimmt OpenTelemetry-Spans auf zwei Wegen an. Mit der SDK-Integration sorgt LANGSMITH_OTEL_ENABLED=true dafür, dass LangChain und LangGraph Spans über den LangSmith-Exporter senden, und LANGSMITH_OTEL_ONLY=true unterbindet zusätzlich das eigene Format. Bei jeder anderen Anwendung zeigt man einen Standard-OTLP-Exporter auf den Basis-Endpunkt https://api.smith.langchain.com/otel; für EU, APAC und AWS US gibt es regionale Endpunkte. Der Exporter ergänzt den Signalpfad selbst, ein /v1/traces in der Basis-URL ergibt deshalb einen 404.

pip install "langsmith[otel]"          # needs langsmith >= 0.3.18, 0.4.25 recommended

export LANGSMITH_TRACING=true
export LANGSMITH_OTEL_ENABLED=true
export LANGSMITH_ENDPOINT=https://api.smith.langchain.com
export LANGSMITH_API_KEY=...

# fan out one OTLP stream to LangSmith and to the rest of the stack
export OTEL_EXPORTER_OTLP_ENDPOINT=https://api.smith.langchain.com/otel
export OTEL_EXPORTER_OTLP_HEADERS="x-api-key=...,Langsmith-Project=support"

# OTel-only, for teams that do not want a second transport
export LANGSMITH_OTEL_ONLY=true

Der Trade-off ist Bequemlichkeit gegen Overhead. Der OTel-Weg kostet eine Übungsrunde im Attribut-Mapping, denn Span-Attributen müssen mit dem langsmith-Namespace beschriftet werden, damit aus ihnen Run-Typen, Run-IDs und dotted order werden; LangChains eigene Ankündigung beschreibt den OpenTelemetry-Weg als etwas höheren Overhead und empfiehlt das native Format, wenn LangSmith das einzige Ziel ist. Das native Format liefert außerdem Pending Runs, die schon im UI erscheinen, während die Arbeit noch läuft.

Wo es knirscht

Zuerst die Schwächen, weil sie entscheiden, ob man dieses Produkt braucht. Die Abrechnungseinheit ist der Trace, was Sampling belohnt und eine Anwendung bestraft, die jeden Request traced; die Caps des Load Balancers gelten pro Service Key oder Personal Access Token, nicht pro Organisation, eine horizontal skalierte Flotte braucht also mehr Keys oder das Batching des SDK. Rollenbasierte Zugriffsrechte pro Workspace gibt es nur in Enterprise, ein wachsendes Team auf Plus teilt sich ein Rollenmodell. Und die Ressourcenhierarchie wird einem unter den Füßen weggebaut: Workspaces hießen Tenants, Agents sind als Gruppierung über Projekten in Beta, und in einem agent-basierten Workspace werden Traces über Agent und Environment adressiert statt über das Projekt.

Was LangSmith nicht aufgibt, ist die Messbarkeit: es ist die Referenzimplementierung für Run-Bäume, Thread-Ansichten für Unterhaltungen und dataset-getriebenes Regressionstesten, und die Annotation Queue mit Reservierungen ist eine ernsthafte Antwort auf die Frage, wer was labelt. Läuft die Anwendung bereits auf LangGraph, ist die Wahl offensichtlich, und die Wechselkosten liegen in der Runtime, nicht in den Traces.

Fazit

LangSmith ist sein Geld wert, wenn das Verhalten eines Agents und nicht dessen Verfügbarkeit das ist, was bricht, und wenn Menschen labeling übernehmen sollen, deren Runs und Datensätze ein Release-Gate steuern. Weniger wert ist der Preis, wenn man nur ein Request-Log braucht, wenn ein Trace pro Nutzeranfrage zu viele Traces für das Budget sind, oder wenn die Ausbreitung der Plattform unklar macht, wofür man bezahlt.

1. Einführen, wenn dataset-getriebene Regressionstests in CI gebraucht werden und nicht nur ein Trace-Viewer.
2. Einführen, wenn mehrere Leute Runs labeln müssen, denn Annotation Queues mit Reservierungen und Dataset-Export lassen sich schwer nachbauen.
3. Einführen, wenn ohnehin auf LangGraph gebaut wird, und die Runtime in die Rechnung einbeziehen, statt so zu tun, als wären die Traces etwas anderes.
4. Vorsichtig sein, wenn jeder Request getraced werden soll: die Event- und Byte-Grenzen pro Stunde modellieren, bevor in der Produktion instrumentiert wird.
5. Woanders suchen, wenn Selbstbetrieb ohne Vertriebsgespräch, rollenbasierte Rechte pro Workspace oder ein flacher Preis pro Trace besser passen als eine LSU-abgerechnete Plattform.

Quellen

1. LangSmith Preise
2. LangSmith Dokumentation: administration overview
3. LangSmith Dokumentation: custom instrumentation
4. LangSmith Dokumentation: trace with OpenTelemetry
5. LangSmith Dokumentation: evaluation concepts
6. LangSmith Dokumentation: self-hosted deployment
7. LangChain: End-to-End OpenTelemetry in LangSmith