Das Problem: LangChain ist überall, aber nirgendwo erklärt
Wer aktuell eine KI-Stelle ausschreibt, listet als Erstes LangChain. Wer einen RAG-Workshop besucht, sieht LangChain-Code. Wer KI-Tutorials auf Medium liest, fängt mit LangChain an. In zwei Jahren ist „LangChain" zum Synonym für „KI-Agenten in Python" geworden, ohne dass die meisten Entscheider verstehen, was das überhaupt ist und wann es Sinn ergibt.
Das wird zum Problem, wenn man ein produktives System baut. Du wirst gefragt: „Nutzen Sie LangChain?" Du sagst „nein", und dann ist Pause. Als ob du verstanden hättest, dass die Erde flach ist.
Dabei ist die Antwort nicht „LangChain ist schlecht" oder „LangChain ist gut". Es ist eine Architektur-Entscheidung mit klaren Trade-offs. Und im Mittelstand fällt sie oft anders aus als im Konzern.
Was LangChain eigentlich ist
LangChain ist ein Python-Framework, das eine Abstraktionsschicht über LLM-APIs legt. Statt direkt mit der Anthropic- oder OpenAI-SDK zu arbeiten, schreibst du gegen Konzepte des Frameworks: „Chains", „Agents", „Tools", „Retrievers", „Memory", „Vector Stores". LangChain übersetzt das dann in Aufrufe gegen den jeweiligen LLM-Provider. LangGraph ist der Aufsatz für komplexere Agent-Workflows, definiert als Zustandsmaschine mit Knoten und Kanten.
Die Idee dahinter ist gut gemeint. Du sollst einmal schreiben und später den Provider tauschen können. Heute Claude, morgen GPT, übermorgen Gemini. Dazu kommen Hunderte von vorgebauten Integrationen für Vektordatenbanken, Dokumentenparser, Memory-Systeme.
Klingt nach einem No-Brainer. Ist es nicht.
Was du dir mit LangChain einkaufst
Drei Probleme, die in Demos nicht sichtbar werden, in produktiven Systemen aber zu Schmerzpunkten werden.
Erstens: Debugging durch acht Wrapper-Layer. Wenn dein Agent die falsche Antwort gibt, willst du wissen warum. Bei LangChain gehst du dafür durch eine Stack-Trace, die durch fünf bis zehn Framework-Klassen läuft, bevor du den eigentlichen Modell-Call siehst. Du fragst dich: „Was hat das Framework eigentlich an meinen Prompt drangehängt?" Die Antwort findest du, wenn überhaupt, in einer LangSmith-Trace oder mit zehn Print-Statements an strategisch verteilten Stellen.
Zweitens: Versionsstabilität. LangChain ist berüchtigt dafür, alle paar Wochen Breaking Changes auszurollen. Klassen werden umbenannt, Pakete aufgeteilt, APIs deprecated. Wenn dein Kunde in zwei Jahren ein Sicherheitsupdate einspielen will, kann es passieren, dass plötzlich die Hälfte der Codebase nicht mehr kompiliert. Bei einem internen Tool, das im Mittelstand zwei Jahre laufen soll, ist das ein echtes Risiko.
Drittens: Token-Kontrolle. LLM-APIs kosten Geld pro Token. Bei einem Chatbot mit 5000 Mitarbeitern und 100 Anfragen pro Tag und Person sind das schnell vier- bis fünfstellige Beträge im Monat. Du willst wissen, was in jedem Prompt steht und was zurückkommt, um zu optimieren. LangChain abstrahiert genau das weg. Es injiziert eigene Prompt-Strukturen, die du nicht direkt siehst, und macht es schwer, an jeder Stelle die echte Token-Nutzung zu kontrollieren.
Mein Weg: Claude Tool Use direkt
Statt LangChain nutze ich für meine produktiven RAG- und Agent-Pipelines die Anthropic-SDK direkt mit dem Tool-Use-Feature von Claude. Tool Use ist Anthropics natives Konzept dafür, dass Claude externe Werkzeuge aufrufen kann: Datenbank-Abfragen, API-Calls, Datei-Operationen. Es ist Teil der API selbst, kein Framework.
Der Code ist dadurch länger. Statt zehn Zeilen LangChain-Setup brauche ich für einen Agent oft 80 bis 150 Zeilen, weil ich die Orchestrierungs-Schleife selbst schreibe. Das klingt wie ein Nachteil. Ist es in Wahrheit nicht.
Diese 80 bis 150 Zeilen sind nämlich vollständig unter meiner Kontrolle. Wenn der Agent in Schritt drei einen falschen Werkzeug-Call macht, sehe ich auf einen Blick warum. Wenn ich das Logging anpassen will, ist es eine Zeile. Wenn ich einen Token-Counter einbauen will, klatsche ich ihn in die Schleife rein. Wenn ich die Fehlerbehandlung auf einen bestimmten Edge Case zuschneiden will, weiß ich genau, an welcher Stelle der Code reagieren muss.
Das ist der Unterschied zwischen „ich habe ein Framework benutzt" und „ich habe ein System gebaut".
Wie das im Alltag aussieht
Stell dir einen Wissensmanagement-Agent für ein Mittelstands-Unternehmen vor. Der Mitarbeiter fragt: „Wie lief das letzte Audit bei Kunde Müller GmbH?" Der Agent muss in der eigenen Wissensdatenbank suchen, in den E-Mails der letzten sechs Monate, in den CRM-Notizen, und daraus eine kompakte Antwort mit Quellenangabe formulieren.
Bei LangChain würdest du jetzt einen Agent mit drei Tools definieren, einen Retriever einhängen, eine Chain orchestrieren und auf das Beste hoffen. Das funktioniert, ist aber eine Black Box. Wenn der Agent in einem Edge Case in eine Endlos-Schleife läuft (ja, das passiert), oder wenn er die falsche Quelle als wichtigste einstuft, oder wenn der Token-Verbrauch plötzlich durch die Decke geht, brauchst du Tage, um das Problem zu lokalisieren.
Bei Claude Tool Use direkt schreibst du eine simple while-Schleife. Der Agent gibt dir bei jedem Modell-Call zurück, welches Werkzeug er aufrufen will und mit welchen Parametern. Du führst das Werkzeug aus, gibst das Ergebnis zurück, schließt den Kreis, bis Claude sagt „fertig". An jeder Stelle dieser Schleife kannst du loggen, abbrechen, modifizieren, debuggen. Wenn der Agent auf der zweiten Iteration plötzlich abdreht, siehst du das im nächsten Log-Statement.
Genau das war meine Wahl bei der Wissensplattform, die ich für einen Kunden gebaut habe. Drei Werkzeuge im Agent: semantische Suche in der Wissensdatenbank, Web-Suche für externe Aktualitätsprüfung und ein Update-Tool für Versionierung. Keine 800 Zeilen LangChain-Konfiguration, sondern eine 200-Zeilen-Orchestrierung, die jeder im Team in einer Stunde versteht.
Wann LangChain trotzdem Sinn macht
Damit kein Missverständnis entsteht: LangChain ist nicht schlecht. Es gibt klare Szenarien, in denen es das richtige Werkzeug ist.
In der Prototypen-Phase, wenn du in einem Tag ein PoC für eine Idee bauen willst, ist LangChain Gold wert. Zehn Zeilen, fertig ist der Demo-Chat. Das eignet sich super für „lass uns mal sehen, ob die Idee überhaupt trägt".
In Konzern-Umgebungen mit klassischen Procurement-Prozessen ist LangChain oft die einzige Option, weil es als Industriestandard akzeptiert wird. Wenn die Stellenausschreibung „LangChain" sagt, weil HR weiß, was zu suchen ist, kannst du das nicht von außen ändern. In dem Fall ist die Kosten-Nutzen-Rechnung anders.
Wenn dein Team aus Junior-Devs besteht, die schnell produktiv werden sollen, ist LangChain eine niedrige Einstiegshürde. Sie schreiben Code, der „funktioniert", auch wenn sie nicht im Detail verstehen, was unter der Haube passiert. Im Mittelstand ist das oft kein realistisches Szenario, weil es da meist nicht Junior-Teams gibt, sondern einzelne erfahrene Entwickler. Aber bei größeren Organisationen ist das ein echtes Argument.
Was sich verändert, wenn man bewusst entscheidet
Wenn du einmal verstanden hast, dass es eine bewusste Entscheidung ist und kein Default, ändert sich der Tonfall in Architektur-Gesprächen. Du kannst dem Auftraggeber begründen, warum dein Stack so aussieht, wie er aussieht. Du kannst die Trade-offs erklären, die der Klient vermutlich vorher noch nie ausgesprochen gehört hat. Und du kannst klar sagen: in meinem Fall war pgvector mit eigener Orchestrierung die richtige Wahl, weil das Team klein ist, das Wartungsfenster lang ist und die Kosten kontrollierbar sein sollen.
Das ist der Unterschied zwischen einem Berater, der einen Standard-Stack verkauft, und einem, der für einen konkreten Kontext baut.
Wie funktioniert das technisch?
Jetzt wird es etwas technischer. Wer nur die Architektur-Logik mitnehmen wollte, kann direkt zum Fazit springen.
Der Kern einer Tool-Use-Schleife mit Claude sieht aus, als würdest du normalen Python-Code schreiben. Du definierst deine Werkzeuge als JSON-Schema mit Name, Beschreibung und Parametern. Du gibst diese Werkzeuge im API-Call mit, zusammen mit dem User-Prompt. Claude antwortet entweder mit einem natürlichsprachigen Text (wenn keine Werkzeuge nötig sind) oder mit einem tool_use-Block, der sagt „rufe Werkzeug X mit Parametern Y auf".
Du parst das, führst dein Werkzeug aus (egal ob das eine Datenbankabfrage, ein API-Call oder ein Dateizugriff ist), packst das Ergebnis in einen tool_result-Block, schickst alles zusammen mit dem bisherigen Verlauf zurück an Claude. Claude entscheidet dann, ob es nochmal ein Werkzeug braucht oder mit einer finalen Antwort fertig ist. Diese Schleife läuft, bis das Modell aufhört, Werkzeuge anzufordern.
Das ist transparent, deterministisch und vollständig debugbar. Jeder Schritt ist sichtbar. Wenn du Logging brauchst, schreibst du Logging. Wenn du Caching brauchst, schreibst du Caching. Wenn du eine Sicherheitsprüfung brauchst (welcher Nutzer darf welche Werkzeuge aufrufen?), schreibst du die als Middleware in die Schleife.
Der einzige echte Nachteil ist, dass du selbst die Provider-Abstraktion baust, falls du sie brauchst. Wenn der Klient morgen von Claude auf Gemini wechseln will, schreibst du einen Adapter. Das sind etwa 100 Zeilen pro Provider, einmalig. Klingt nach Aufwand, ist es nicht.
Was ich aus diesem Vorgehen heraus für Projekte tatsächlich nutze: Anthropic-SDK für Claude, FastAPI als Backend, PostgreSQL mit pgvector als Vektordatenbank, Mistral Embeddings für die Retrieval-Schicht, Temporal für lange laufende Workflows, die pausierbar sein müssen. Kein LangChain, kein LangGraph, keine Magic. Alles geschriebener Code, alles wartbar.
Die Infrastruktur läuft auf Hetzner Cloud in Deutschland. Kundendaten und Datenbank liegen vollständig in der EU. Für die Modell-Calls werden Inhalte verschlüsselt an Anthropic übermittelt, dort aber nicht gespeichert oder zum Training verwendet.
Fazit
LangChain ist nicht schlecht, aber überbewertet. Für Prototypen, für Junior-Teams und für Konzern-Umgebungen mit Procurement-Standard ist es das richtige Werkzeug. Für produktive Systeme im Mittelstand mit klarem Owner und langem Wartungsfenster ist es oft das falsche.
Mein Weg ist nicht „dagegen", er ist bewusst. Direkt mit Claude Tool Use zu arbeiten heißt mehr Code, aber kompletten Durchblick. Wenn dein Use Case wartbar bleiben soll und du verstehen willst, was im System passiert, ist das oft die bessere Entscheidung. Wenn dein Team in der Lernphase ist und du in zwei Wochen ein PoC brauchst, ist LangChain das schnellere Werkzeug.
Wichtig ist nur, dass es eine bewusste Wahl bleibt und nicht einfach „das macht doch jeder".