Was LangChain Ihnen tatsächlich bietet außer dem einfachen Aufrufen von Tools

KI-Apps können direkt eine LLM-API aufrufen und jeden Detail selbst steuern. Dieser Ansatz hat tatsächlich Vorteile: Der Ablauf der Steuerung ist sichtbar. Gleichzeitig hat er auch Nachteile. Sobald das Produkt über einen einzigen Chatwechsel hinauswächst, entsteht viel Code, der eigentlich keine Produktlogik darstellt.

Zu den typischen Aufgaben gehören:

• Definieren von Werkzeugen und Schemata
• Senden der Werkzeuge an das Modell
• Bearbeiten der Antworten auf Werkzeugaufrufe
• Ausführen der angeforderten Funktionen
• Zurückgeben der Ergebnisse der Werkzeuge
• Aufbewahren des Gesprächsverlaufs
• Koordinieren mehrerer Werkzeugaufrufe
• Steuerung des Kreislaufs Modell↔Werkzeug

Diese Schritte eignen sich hervorragend zum Lernen. In einer Liefer-App wird das Manuell-Wiederholen dieser Schritte zur Hauptaufgabe.

Frameworks wie LangChain existieren, um diese Wiederholungen zu übernehmen.

Der Aufwand beim Manuell-Erledigen aller Aufgaben

Stellen Sie sich ein winziges Rechenwerkzeug vor. Ohne Framework sieht der Ablauf ungefähr so aus:

User
  ↓
LLM API
  ↓
LLM requests calculator
  ↓
Our code detects the request
  ↓
Our code executes calculator()
  ↓
Our code sends the result back
  ↓
LLM generates the final answer

Ein Werkzeug bleibt überschaubar. Zwanzig Werkzeuge, mehrere Modelle, eine dauerhafte Chat-Statusverwaltung, Wiederholungsversuche sowie verzweigte Agenten-Arbeitsabläufe verwandeln eine „einfache Produktlogik“ in ein Orchestrierungsprojekt.

Abstraktionen existieren, weil diese Mechanismen schneller wachsen als die Liste der Funktionen.

Was LangChain beiträgt

LangChain stellt gemeinsame Strukturen für Modelle, Werkzeuge, Nachrichten und Agenten-Runtimes bereit. Anstatt jeden Schritt manuell zu verbinden, beschreiben Sie die Funktionalitäten und lassen das Framework den größten Teil der Standardprozesse übernehmen.

Eine Werkzeug erstellen

Eine normale Python-Funktion wird zu einem Werkzeug:

from langchain.tools import tool

def calculator(a: float, b: float, operation: str):
    """Perform a mathematical calculation."""
    if operation == "add":
        return a + b
    elif operation == "subtract":
        return a - b
    elif operation == "multiply":
        return a * b
    elif operation == "divide":
        if b == 0:
            return "Cannot divide by zero."
        return a / b
    return "Unknown operation."

Der Körper des Rechenwerks bleibt die Anwendungslogik. LangChain umhüllt ihn lediglich, damit ein LLM darauf zugreifen kann.

Das Werkzeug mit einem Modell verbinden

from langchain_google_genai import ChatGoogleGenerativeAI

model = ChatGoogleGenerativeAI(
    model="gemini-3.5-flash-lite"
)
model_with_tools = model.bind_tools([calculator])

Dann rufen Sie es auf:

response = model_with_tools.invoke(
    "What is 2 + 6?"
)

Das Modell kann mit einer strukturierten Tool-Anfrage antworten, wie zum Beispiel:

calculator(
    a=2,
    b=6,
    operation="add"
)

bind_tools() führt die Rechenmaschine nicht aus. Es gibt lediglich Anzeige über die Verfügbarkeit: Das Modell kann das Tool bei Bedarf anfordern.

Wo die Abstraktion zum Tragen kommt

Mit manuellen Methoden verantwortet der Ingenieur einen langen Prozessablauf:

Create function
     ↓
Create tool schema
     ↓
Send schema to LLM
     ↓
Receive tool call
     ↓
Extract arguments
     ↓
Execute function
     ↓
Create tool result
     ↓
Send result back to LLM
     ↓
Check if another tool call is needed
     ↓
Repeat

Mit LangChain befindet sich ein Großteil dieses Prozesses im Agenten-Runtime. Der Fokus verschiebt sich auf:

What capability does my application need?
              ↓
        Define the tool
              ↓
      Give it to the model
              ↓
       Build the application

Die Komplexität ist nicht verschwunden – sie befindet sich nun hinter einer Grenze.

Was tatsächlich gewonnen wird

LangChain erfindet keine neuen Methoden zum Aufrufen von Tools; bereits vorhandene APIs unterstützen dies. Der Vorteil liegt nicht darin, für jede Funktion erneut Schemata, Schleifen und Verarbeitungsmethoden für Historien zu entwickeln. Die Zeit wird stattdessen für produktbezogene Fragen genutzt:

• Was sollte der Assistent können?
• Welche Tools gehören zum Aufgabengebiet?
• Was passiert, wenn ein Tool fehlschlägt?

Wie sollte der Rest der App reagieren?

Welche Geschäftsregeln müssen fest codiert bleiben?

Soll jedes Projekt ein Framework verwenden?

Nicht immer. Das manuelle Aufrufen von Tools bleibt der beste Lehrmeister. Wenn man den Prozess einmal durchläuft:

LLM
 ↓
Tool call
 ↓
Application
 ↓
Tool execution
 ↓
Tool result
 ↓
LLM

wird das spätere Verhalten der Frameworks weniger rätselhaft. Das Verwenden von Abstraktionen, ohne zu kennen, welches Problem sie lösen, erschwert das Debuggen erheblich.

Eine nachhaltige Gewohnheit: Zuerst die zugrundeliegenden Mechanismen verstehen, anschließend Abstraktionen einsetzen, damit diese nicht für jedes Anliegen neu geschrieben werden müssen. Teams, die diesen ersten Schritt überspringen, betrachten LangChain oft als Magie und geraten ins Stocken, wenn das Schema eines Tools oder eine Wiederholungspolitik nicht funktioniert. Teams, die beides beherrschen, arbeiten schneller, ohne die Fähigkeit zu verlieren, bei Produktionsproblemen direkt auf die zugrundeliegenden Mechanismen zurückzugreifen.