Startseite / Artikel / Was LangChain tatsächlich automatisiert, sobald man einen Agenten-Loop erstellt hat

Was LangChain tatsächlich automatisiert, sobald man einen Agenten-Loop erstellt hat

Erklärt, wie LangChain, LangGraph und ähnliche SDKs denselben aus dem Grund aufgebauten Kern-Agenten-Loop verwenden, und wann die Nutzung eines Frameworks hilft oder schadet.

1964 Wörter

Bis zu diesem Punkt haben Sie bereits einen vollständigen Agenten aus Rohmaterialien zusammengestellt – Schleifen, Speicher, Werkzeuge, Unteragenten, Hooks – und zwar ausschließlich mit dem einfachen Anthropic SDK. Kein Framework ist zu sehen.

Genau jetzt ist der richtige Zeitpunkt, über Frameworks zu sprechen, denn nun passiert etwas Nützliches: Da Sie den gesamten Mechanismus selbst erstellt haben, wird kein Framework Ihnen jemals wieder geheimnisvoll erscheinen.

Die Namen, die Sie ständig hören

LangChain. LangGraph. LlamaIndex. CrewAI. AutoGen. Das OpenAI Agents SDK.

Jedes davon verfügt über seine eigene Terminologie sowie seine eigene Art, das scheinbar gleiche zugrundeliegende Problem zu bewältigen. Wenn Sie neu in diesem Bereich sind, wirkt die enorme Anzahl an Optionen überwältigend.

Es gibt einen Erkenntnispunkt, der diese Verwirrung beseitigt:

Jedes einzelne dieser Frameworks umhüllt genau dieselbe Schleife, die Sie bereits früher in dieser Serie erstellt haben.

Das ist tatsächlich das ganze Geheimnis. Keines davon enthält verborgene Magie. Im Grunde laufen sie alle nach derselben Abfolge ab: Nachrichten senden, den Grund für die Unterbrechung überprüfen, Tools ausführen und die Ergebnisse wieder zurückgeben. Es handelt sich um denselben Kreislauf, den Sie bereits in- und auswendig kennen.

Stellen Sie es sich wie Kochen vor. Sobald man gelernt hat, ein Gericht aus Rohstoffen zuzubereiten, kennt man jeden einzelnen Schritt, kann unterwegs probieren und anpassen sowie genau wissen, was geändert werden muss, falls etwas nicht schmeckt. Ein Framework ähnelt eher einem Meal Kit – das Gemüse ist bereits gehackt, die Soße vormischt, und man muss alles nur noch in wenigen Minuten zusammenstellen. Das ist zwar schneller. Doch wenn die Soße falsch wird, gibt es keine Möglichkeit, sie zu reparieren, weil man sie nie selbst hergestellt hat und nicht weiß, was darin enthalten ist.

Das ist der Kompromiss, den jedes Framework anbietet: Man gibt etwas Kontrolle auf, um mehr Geschwindigkeit zu erlangen.

Aus eigener Sicht sehen

Lassen Sie uns denselben Agenten zweimal implementieren – einmal von Hand, einmal über ein Framework.

So sieht Ihr Agent im Großen und Ganzen aus, wenn er das rohe SDK verwendet, die Version, die Sie jetzt vollständig verstehen:

messages = [{"role": "user", "content": user_message}]

while True:
    # call the API — this runs again every time the model asks for a tool
    response = client.messages.create(
        model="claude-sonnet-4-6",
        tools=tools,
        messages=messages,
    )    # if the model is done, stop
    if response.stop_reason == "end_turn":
        break    # otherwise it asked for a tool: run it, append the result, loop again
    messages.append(response_as_message)
    messages.append(tool_result_message)

Das ist genau die Schleife, die zuvor in der Serie vorgestellt wurde. Der API-Aufruf befindet sich innerhalb einer while-Schleife, weil er wiederholt ausgeführt wird – einmal für die anfängliche Antwort und anschließend jedes Mal, wenn ein Tool-Ergebnis zurückkommt – bis das Modell signalisiert, dass es fertig ist.

Vergleichen Sie das nun mit dem im Großen und Ganzen identischen Agenten, der in LangChain gebaut wurde:

from langchain.agents import create_agent

agent = create_agent(model="claude-sonnet-4-6", tools=tools)
result = agent.invoke({"messages": [user_message]})

Fünf Zeilen anstelle von dreißig. Auf den ersten Blick scheint das eine offensichtliche Verbesserung zu sein.

Aber beachten Sie, was verschwunden ist. Die Schleife ist weg. Die Überprüfung von stop_reason ist weg. Die manuelle Verarbeitung der Nachrichten ist weg. Keine dieser Logiken ist wirklich verschwunden – sie läuft weiter, ist nur in create_agent versteckt, wo man sie nicht mehr sehen kann.

Wenn alles reibungslos läuft, gewinnen Sie Zeit. Wenn etwas schiefgeht, sind Sie gezwungen, einen Prozess zu debuggen, den Sie nicht überprüfen können.

Diese Spannung ist im Grunde die ganze Geschichte hinter Frameworks. Alles andere sind nur zusätzliche Details.

Was Sie tatsächlich tun vs. was das Framework tut

Das ist der Teil, der die Leute oft überrascht. Sobald Sie ein Framework verwenden, schauen Sie niemals direkt auf stop_reason. Sie überprüfen nie einen tool_use-Block. Sie fügen niemals manuell einen tool_result hinzu. Sie schreiben die Schleife überhaupt nicht.

Anstelle dessen reduziert sich Ihre Aufgabe auf drei Schritte:

Schreiben Sie die Funktionen Ihres Tools genauso, wie Sie es mit dem Roh-SDK tun würden.
Registrieren Sie diese Funktionen beim Agenten mithilfe von etwas wie create_agent(tools=[...]).
Rufen Sie agent.invoke(...) ein einziges Mal auf.

Das ist der gesamte Workflow. Sie verbinden die Tools miteinander und lösen den Aufruf einmal aus.

Hinter diesem einzigen Aufruf läuft das Framework stillschweigend den gesamten zuvor erstellten Loop ab: Es sendet die Nachrichten, überprüft den Stoppgrund, erkennt, dass das Modell ein Tool benötigt, ruft Ihre Funktion auf, fügt das Ergebnis hinzu, läuft erneut im Loop und wiederholt diesen Zyklus, bis das Modell schließlich end_turn zurückgibt. Erst dann übergibt es Ihnen die fertige Antwort.

Ein Framework versteckt also nicht nur den Loop selbst – es verbirgt auch das gesamte Mechanismus, der erst einmal die Aufrufe von Tools ermöglicht. Jemand, der Agenten durch das Arbeiten mit einem Framework lernt, würde nicht einmal wissen, dass es eine Abbruchgrund wie end_turn gibt oder dass Toolaufrufe durch wiederholte Iterationen abgewickelt werden. Für ihn würde es einfach so aussehen, als „hätte ich ein Tool registriert und es wurde automatisch verwendet.“

Das ist in Ordnung – solange die Toolaufrufe sich normal verhalten. Sobald sie jedoch Probleme machen, steht man vor einer Black Box, denn man hat die dahinterliegenden Mechanismen nie gesehen. Im Gegensatz dazu hat man diesen Mechanismus selbst mit eigenen Händen gebaut und weiß genau, was darin vor sich geht.

LangChain, LangGraph – was ist der Unterschied?

Man wird auf beide Namen ständig stoßen, daher hier die kurze Erklärung.

LangChain ist das Framework selbst. Es stellt Tool-Definitionen, Modellverbindungen sowie die create_agent-Funktion bereit – denselben Abkürzungsweg zur Vermeidung von Schleifen, den wir oben besprochen haben.

LangGraph ist eine untere Ebene des Laufzeitumfelds, auf der LangChain basiert. Man greift darauf zurück, wenn man eine genauere Kontrolle benötigt – beispielsweise um einen Agenten anzuhalten, damit ein Mensch einen Schritt freigeben kann, um branchende Logik zwischen mehreren Agenten zu koordinieren oder den Zustand zu speichern, damit ein abstürzender Server genau dort weitermachen kann, wo er aufgehört hat.

Ein einfaches mentales Modell: LangChain ist der schnelle, hochlevelige Einstiegspunkt. LangGraph ist das, was man einsetzt, wenn dieser Einstiegspunkt nicht ausreicht. Seit Ende 2025 wurde LangChain auf LangGraph neu aufgebaut, sodass es sich nicht mehr um konkurrierende Tools handelt – es sind zwei Ebenen eines einzigen Systems, eine einfache und eine leistungsstarke.

Falls Sie gerade erst anfangen, benötigen Sie vermutlich noch keines von beidem. Das reine SDK, das Sie bereits kennen, kann Sie überraschend weit bringen.

Wann ein Framework hilft

Frameworks sind an sich keine Falle. In manchen Situationen ist der Einsatz eines Frameworks tatsächlich die richtige Entscheidung.

Ihnen fehlen fertige Integrationen. Angenommen, Ihr Agent muss Datensätze aus einem Pinecone-Vector-Speicher abrufen und Dokumente aus Google Drive holen. Beide Anbindungen selbst im reinen SDK zu schreiben ist möglich, aber zeitaufwendig. LangChain liefert sie bereits vorgefertigt – Sie müssen sie nur importieren und verbinden. Das spart echte Zeit.

Sie entwickeln unter Zeitdruck ein Prototypen. Ihr Vorgesetzter möchte morgen früh eine funktionierende Demo haben. Zu diesem Zeitpunkt spielen die internen Details noch keine Rolle – Sie brauchen einfach schnell etwas Funktionsfähiges. Eine fünfzeilige Einrichtung kann Sie bereits heute Abend dorthin bringen.

Ihnen fehlt eine wirklich komplexe Orchestrierungslösung zum Aufbau. Stellen Sie sich einen Agenten vor, der mitten in einer Aufgabe pausiert, darauf wartet, dass jemand „Genehmigen“ klickt, bevor er eine Zahlung freigibt, und anschließend genau dort weitermacht, wo er aufgehört hat – selbst nach einem Serverneustart. Bestimmte Frameworks bieten dieses Verhalten bereits standardmäßig. Es erfordert erhebliche ingenieurtechnische Anstrengungen, es von Grund auf neu zu erstellen.

Wenn ein Framework zum Problem wird

Das Debuggen wird schwierig. Stellen Sie sich vor, Ihr Agent gibt gelegentlich eine leere Antwort zurück und Sie können nicht erkennen, warum. In Code, den Sie selbst geschrieben haben, würden Sie eine Ausgabeanweisung einfügen, die Schleife nachverfolgen und das Problem innerhalb von Minuten finden. In einem Framework befindet sich derselbe Fehler irgendwo in der Funktion create_agent – also in Code, der nicht Ihnen gehört. Am Ende müssen Sie sich durch die Quellcode des Frameworks auf GitHub wühlen, nur um zu verstehen, was Ihr eigener Agent tut.

Die Abstraktion beginnt zu undichten. Frameworks sind für den gängigen Fall optimiert. Angenommen, Sie benötigen eine Tool-Ausgabe in einer nichtstandardmäßigen Form oder eine Wiederholungspolitik, die genau auf Ihre spezifische Einrichtung zugeschnitten ist – das Framework hat so etwas nie vorgesehen. Nun müssen Sie umständliche Workarounds einsetzen, nur um es dazu zu zwingen, etwas zu tun, was dreißig Zeilen eigener Code direkt erledigt hätten.

Am Ende lernen Sie das Tool statt des Konzepts kennen. Mit einem Framework zu beginnen lehrt Sie „wie LangChain funktioniert“, nicht wie Agenten tatsächlich arbeiten. Wenn sich anschließend die API von LangChain ändert – was wiederholt der Fall ist – wird Ihr Wissen über Nacht veraltet. Der Zyklus, den es in dieser Serie bereits früher gab, hat sich seit der Erstellung der ersten Agenten nicht geändert und wird es auch nicht tun.

Die Regel, der man folgen sollte

Fangen Sie mit dem rohen SDK an. Bauen Sie den Loop manuell. So wissen Sie genau, was Ihr Agent tut, und können jede Zeile nachvollziehen, wenn etwas schiefgeht. Für die meisten Agenten ist das tatsächlich alles, was Sie jemals benötigen werden.

Fügen Sie ein Framework nur dann hinzu, wenn es etwas Bestimmtes besser löst als Sie selbst – eine fertige Integration, einen Zustand, der auch nach einem Absturz erhalten bleibt, oder Schritte zur menschlichen Überprüfung. Verwenden Sie es bewusst aus genau diesem Grund und nicht als Standardlösung.

Suchen Sie kein Framework, nur um das Erlernen des Loops zu umgehen. Das ist die eigentliche Falle. Überspringen Sie diesen Schritt, und am Ende haben Sie eine Black Box, die auf Ideen beruht, die Sie nie wirklich verinnerlicht haben.

Verstehen Sie zunächst den Loop. Danach wird ein Framework zu einem Werkzeug, das Sie absichtlich wählen – nicht zu einer Stütze, auf die Sie sich stützen, weil Sie die Grundlagen nie gelernt haben.

Warum diese Serie alles von Grund auf entwickelt hat

Das ist genau der Grund, warum bis jetzt auf Frameworks verzichtet wurde.

Hätte diese Serie mit „install LangChain, call create_agent“ begonnen, hätten Sie einen funktionierenden Agenten, aber kein wirkliches Verständnis dafür. Sie würden nicht wissen, was ein tool_use-Block ist, warum die Ergebnisse paralleler Toolaufrufe in einer einzigen Nachricht zusammengefasst werden oder warum die Autorisierungslogik in einem Hook untergebracht wird.

Sobald Sie diese Grundlagen bereits beherrschen, lässt sich das Vokabular jedes Frameworks sofort übersetzen. Was auch immer es als „Agent“ bezeichnet, ist im Grunde nur derselbe zugrundeliegende Loop. Was es als „Gedächtnis“ bezeichnet, ist nichts anderes als die laufende Liste der Nachrichten, die Sie bereits kennen. Was es als „Werkzeuge“ bezeichnet, entspricht direkt den tool_use-Blöcken, mit denen Sie bisher manuell gearbeitet haben. Und was es als „Middleware“ vermarktet, ist lediglich ein anderer Name für die Hooks, die Sie selbst erstellt haben.

Das ist die gewünschte Position – nicht „Ich kenne LangChain“ – sondern „Ich verstehe, wie Agenten funktionieren, und LangChain ist nur eine Möglichkeit, das auszudrücken.“

Frameworks werden weiterentwickelt. Jede paar Monate tauchen neue auf. Der zugrundeliegende Loop bleibt jedoch konstant. Bauen Sie Ihr Verständnis auf dem unveränderlichen Teil auf.