2. Grundlagen zum Erstellen von Agenten

In Kapitel 1 haben Sie Ihren ersten LLM-Aufruf gemacht und den grundlegenden Request-Response-Ablauf gesehen. Jetzt müssen wir verstehen, was wir eigentlich bauen: agentische KI-Systeme. Dieses Kapitel legt die grundlegenden Konzepte fest, die Sie im gesamten Buch verwenden werden.

Am Ende dieses Kapitels verstehen Sie:

• Was ein KI-System „agentisch“ macht (und warum das wichtig ist)
• Warum Frameworks wie LangChain und LangGraph existieren
• Wie LLMs unter der Haube tatsächlich funktionieren (und warum das das Agent-Design beeinflusst)
• Die Ökonomie der LLM-Nutzung (Tokens, Kosten und Modellauswahl)
• Wie Sie effektive Prompts für Agent-Systeme schreiben

Dies ist ein konzeptionelles Kapitel – wir kehren in Kapitel 3 zum praktischen Coden zurück. Aber diese Konzepte sind entscheidend, um die Designentscheidungen zu verstehen, die Sie beim Erstellen von Agenten treffen.

2.1) Was ist agentische KI? (Chatbot vs. Agent)

Wenn die meisten Menschen an „KI-Anwendungen“ denken, stellen sie sich Chatbots vor: Sie stellen eine Frage, die KI antwortet, das Gespräch endet. Aber agentische KI ist grundlegend anders. Ein Agent antwortet nicht nur – er handelt autonom, um Ziele zu erreichen.

Die zentrale Unterscheidung

Beginnen wir mit einer klaren Definition:

Chatbot: Ein System, das auf Benutzereingaben mit generiertem Text antwortet. Die Interaktion ist rein konversationell. Der Chatbot hat keine Fähigkeit, Handlungen in der Welt auszuführen, die über das Generieren seiner nächsten Nachricht hinausgehen.

Agent: Ein System, das:

1. wahrnehmen kann, was in seiner Umgebung passiert (z. B. Bestellstatus lesen, Lagerbestand prüfen)
2. entscheiden kann, welche Aktionen auszuführen sind (z. B. auswählen zwischen: Ticket erstellen, E-Mail senden oder eskalieren)
3. handeln kann auf Basis dieser Entscheidungen (z. B. API aufrufen, Datenbank aktualisieren)
4. iterieren kann, bis es ein Ziel erreicht (z. B. Bestellung verifizieren → Ticket erstellen → bestätigen → fertig)

Der wesentliche Unterschied ist Autonomie und Handlungsfähigkeit. Ein Chatbot ist reaktiv; ein Agent ist proaktiv.

Konkretes Beispiel: Kundensupport

Sehen wir uns diese Unterscheidung in der Praxis an.

Chatbot-Ansatz:

Benutzer: "Ich möchte eine Rückerstattung für Bestellung #12345"
 
Chatbot: "Ich verstehe, dass Sie eine Rückerstattung möchten. Um dies zu verarbeiten, gehen Sie bitte wie folgt vor:
1. Besuchen Sie unser Rückerstattungsportal unter example.com/refunds
2. Geben Sie Ihre Bestellnummer ein
3. Wählen Sie einen Grund aus
4. Senden Sie das Formular ab
5. Warten Sie 24–48 Stunden auf eine manuelle Prüfung
 
Kann ich Ihnen noch bei etwas anderem helfen?"

Der Chatbot liefert Informationen, unternimmt aber keine Aktion. Der Benutzer muss die ganze Arbeit erledigen.

Agent-Ansatz:

Benutzer: "Ich möchte eine Rückerstattung für Bestellung #12345"
 
Agent (internes Schlussfolgern):
1. Benutzer möchte Rückerstattung für Bestellung #12345
2. Ich muss verifizieren, dass diese Bestellung existiert
3. [Ruft get_order_details(order_id="12345") auf]
4. Bestellung gefunden, rückerstattungsberechtigt
5. [Ruft create_refund_ticket(order_id="12345", reason="customer_request") auf]
6. Ticket erstellt: TICKET-789
 
Agent: "Ich habe das Rückerstattungsticket TICKET-789 für Bestellung #12345 erstellt. 
Unser Rückerstattungsteam bearbeitet dies innerhalb von 3–5 Werktagen. 
Sie erhalten in Kürze eine E-Mail-Bestätigung."

Der Agent hat gehandelt: Er hat die Bestellung verifiziert, ein Ticket erstellt und das Ergebnis bestätigt. Das Problem des Benutzers wird ohne manuelle Schritte gelöst.

Warum das für die Entwicklung wichtig ist

Wenn Sie diese Unterscheidung verstehen, bestimmt das, wie Sie Ihr System entwerfen:

Chatbot-Entwicklung:

• Fokus auf Antwortqualität und Gesprächsfluss
• Hauptanliegen: hilfreichen, korrekten Text generieren
• Einfache Architektur: Prompt → LLM → Antwort
• Keine externen Integrationen nötig

Agent-Entwicklung:

• Fokus auf Entscheidungsfindung und Ausführung von Aktionen
• Hauptanliegen: korrekte Aktionen auswählen, Fehler behandeln, Zustand aufrechterhalten
• Komplexe Architektur: Wahrnehmung → Schlussfolgern → Aktionsauswahl → Ausführung → Verifikation
• Erfordert Tool-Integrationen, Fehlerbehandlung, Zustandsverwaltung

Das Spektrum der Autonomie

Nicht alle Agenten sind gleich autonom. Es gibt ein Spektrum:

Level 1: Unterstützte Aktionen

• Agent schlägt Aktionen vor, Benutzer genehmigt jede einzelne
• Beispiel: „Ich kann ein Rückerstattungsticket erstellen. Soll ich fortfahren?“
• Sicherster Ansatz für Operationen mit hohem Risiko

Level 2: Begrenzte Autonomie

• Agent handelt innerhalb vordefinierter Einschränkungen
• Beispiel: Kann Tickets erstellen und E-Mails senden, aber keine Rückerstattungen über 500 $ verarbeiten oder direkt auf Zahlungssysteme zugreifen
• Am häufigsten in Produktionssystemen (Balance aus Effizienz und Sicherheit)

Level 3: Volle Autonomie

• Agent handelt unabhängig, um Ziele zu erreichen
• Beispiel: Bearbeitet den gesamten Rückerstattungs-Workflow ohne menschliches Eingreifen
• Erfordert robuste Schutzmechanismen (Guardrails) und Überwachung (Monitoring)

Zentrale Eigenschaften von Agenten

Zusammengefasst hat ein agentisches KI-System diese Kern-Eigenschaften:

1. Tool-Nutzung: Kann Funktionen, APIs und externe Services aufrufen (Ohne das ist es nur ein Chatbot)
2. Zielorientiert: Arbeitet auf konkrete Ergebnisse hin, statt nur zu antworten
3. Mehrschrittig: Zerlegt komplexe Aufgaben in Aktionssequenzen
4. Adaptiv: Passt Verhalten basierend auf Zwischenergebnissen an
5. Zustandsbehaftet: Hält Kontext über mehrere Interaktionen hinweg

Die ersten beiden sind essenziell – ohne Tools und Ziele haben Sie keinen Agenten. Der Rest sind Qualitätsfaktoren, die gute Agenten von großartigen unterscheiden.

Jetzt verstehen Sie, was Agenten sind und warum sie so leistungsfähig sind.

2.2) Warum LangChain und LangGraph?

Sie fragen sich vielleicht: „Warum brauche ich Frameworks? Kann ich nicht einfach direkt die OpenAI-API aufrufen?“ Schauen wir uns an, warum Frameworks existieren und welche Probleme sie lösen.

Die Komplexität der Agent-Entwicklung

Einen einfachen Chatbot mit rohen API-Aufrufen zu bauen, ist unkompliziert:

import openai
 
response = openai.chat.completions.create(
    model="gpt-5-mini",
    messages=[{"role": "user", "content": "Hallo!"}]
)
print(response.choices[0].message.content)

Das funktioniert für grundlegende Anwendungsfälle gut. Aber sobald Sie einen Agenten bauen möchten, explodiert die Komplexität:

Herausforderung 1: Mehrschritt-Workflows Ihr Agent muss:

• Relevante Dokumente aus einer Wissensbasis abrufen
• Entscheiden, welches Tool basierend auf der Nutzerabsicht aufgerufen werden soll
• Das Tool ausführen und Fehler behandeln
• Ergebnisse formatieren und dem Benutzer antworten

Jeder Schritt erfordert sorgfältige Orchestrierung, Fehlerbehandlung und Zustandsverwaltung.

Herausforderung 2: Anbieter-Abstraktion Was, wenn Sie:

• Von OpenAI zu Anthropic oder Google wechseln möchten?
• Verschiedene Modelle für verschiedene Aufgaben verwenden möchten?
• Auf ein günstigeres Modell zurückfallen möchten, wenn das primäre Modell fehlschlägt?

Mit rohen API-Aufrufen müssten Sie für jeden Anbieter wesentliche Teile des Codes neu schreiben.

Herausforderung 3: Konversationsspeicher Agenten müssen sich Kontext merken:

• Frühere Nachrichten im Gespräch
• Abgerufene Dokumente aus früheren Anfragen
• Zwischenergebnisse aus Tool-Aufrufen

Diesen Zustand manuell zu verwalten ist fehleranfällig und mühsam.

Herausforderung 4: Tool-Integration Ihr Agent muss:

• Verfügbare Tools mit Schemas definieren
• Das LLM entscheiden lassen, welches Tool aufgerufen wird
• Tool-Argumente aus der LLM-Ausgabe parsen
• Tools sicher mit Validierung ausführen
• Tool-Fehler und Retry-Logik behandeln

Das erfordert erheblichen Boilerplate-Code und Sicherheitsüberlegungen in jedem Schritt.

Herausforderung 5: Komplexes Routing Echte Agenten brauchen bedingte Logik:

• „Wenn der Benutzer nach Rückerstattungen fragt, Policy-Dokumente abrufen“
• „Wenn der Benutzer eine Rückerstattung will, ein Ticket erstellen“
• „Wenn die Frage off-topic ist, höflich ablehnen“

Das mit if-else-Anweisungen zu implementieren wird schnell schwer wartbar.

Was LangChain bereitstellt

LangChain ist ein Framework zum Erstellen von LLM-Anwendungen. Es bietet:

1. Modell-Abstraktion

Einheitliches Interface für verschiedene LLM-Anbieter (OpenAI, Anthropic, Google usw.).

from langchain_openai import ChatOpenAI
from langchain_anthropic import ChatAnthropic
 
# Gleiches Interface, unterschiedliche Anbieter
openai_llm = ChatOpenAI(model="gpt-5-mini")
anthropic_llm = ChatAnthropic(model="claude-4-5-sonnet")
 
# Beide verwenden .invoke() mit demselben Nachrichtenformat
response = openai_llm.invoke([{"role": "user", "content": "Hallo"}])

Wechseln Sie Anbieter, ohne Ihre Anwendungslogik neu zu schreiben.

2. Komponierbare Chains (LCEL)

LangChain Expression Language – eine Syntax, um Komponenten zu Pipelines zu verbinden.

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
 
# Komponieren Sie eine Pipeline mit dem | Operator (wie Unix-Pipes)
chain = prompt | llm | output_parser
 
# Führen Sie die gesamte Pipeline mit einem Aufruf aus
result = chain.invoke({"input": "Benutzerfrage"})

Bauen Sie komplexe Workflows ohne manuelles Weiterreichen von Daten zwischen Schritten. LCEL lernen wir in Kapitel 6.

3. Konversationsspeicher

Verwaltung des Chatverlaufs für zustandsbehaftete Gespräche.

from langchain_core.chat_history import InMemoryChatMessageHistory
 
# Hilfsklasse für die Nachrichtenhistorie
history = InMemoryChatMessageHistory()
history.add_user_message("Hi")
history.add_ai_message("Hallo!")
 
# Nachrichten bei Bedarf abrufen
messages = history.messages
response = llm.invoke(messages)

Abstrahieren Sie die Nachrichtenspeicherung mit Hilfsklassen, statt Listen manuell zu verwalten. In diesem Stadium wird history weiterhin explizit an das Modell übergeben. Wir integrieren das in Kapitel 8 in Chains. LangGraph (Kapitel 15+) macht das mit eingebauter Zustandsverwaltung noch einfacher.

4. Tool-Integration

Decorator-basiertes System, um Python-Funktionen für LLMs verfügbar zu machen.

from langchain_core.tools import tool
 
@tool
def create_ticket(order_id: str, reason: str) -> str:
    """Erstellt ein Support-Ticket für eine Bestellung."""
    # Implementierung hier
    return f"Ticket für {order_id} erstellt"
 
# LangChain übernimmt Schema-Generierung und LLM-Integration

Machen Sie aus jeder Python-Funktion ein Tool, das von Tool-fähigen LLMs oder Agenten gefunden und aufgerufen werden kann — ohne manuelles Schreiben von JSON-Schemas.

5. Dokument-Loader und Vector Stores

Fertig nutzbare Komponenten, um Dokumente aus verschiedenen Quellen zu laden und als durchsuchbare Embeddings zu speichern.

from langchain_community.document_loaders import TextLoader
from langchain_chroma import Chroma
from langchain_openai import OpenAIEmbeddings
 
# Dokumente laden
docs = TextLoader("support_docs.txt").load()
 
# Durchsuchbaren Index erstellen
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(docs, embeddings)
 
# Relevante Dokumente abrufen
results = vectorstore.similarity_search("refund policy")

Bauen Sie RAG-Systeme mit vorgefertigten Loadern und Vector Stores, statt Parsing, Embedding und Retrieval von Grund auf zu implementieren.

Was LangGraph bereitstellt

LangGraph erweitert LangChain für komplexe Agent-Workflows. Es bietet:

1. Explizites Zustandsmanagement

Definieren Sie alle Agent-Daten in einem einzigen typisierten Schema, statt sie über Variablen zu verstreuen.

from typing import TypedDict, Optional
from langchain_core.messages import BaseMessage
from langchain_core.documents import Document
 
class AgentState(TypedDict):
    messages: list[BaseMessage]
    retrieved_docs: list[Document]
    current_step: Optional[str]
 
# Alle Agent-Daten leben hier – ein Ort zum Inspizieren beim Debugging

Kein Suchen mehr danach, wo Daten liegen oder wie sie zwischen Schritten fließen. Zustandsänderungen sind explizit: Nodes lesen aus state und geben Updates zurück. Ihre IDE vervollständigt Feldnamen automatisch, und Type-Checker finden Fehler vor der Laufzeit.

2. Graph-basierte Workflows

Bauen Sie Workflows, indem Sie Schritte (Nodes) und ihre Verbindungen (Edges) deklarieren, statt Orchestrierungs-Code zu schreiben.

graph = StateGraph(AgentState)
 
# Nodes definieren (Schritte in Ihrem Workflow)
graph.add_node("retrieve", retrieve_docs)
graph.add_node("answer", generate_answer)
 
# Edges definieren (Übergänge zwischen Schritten)
graph.add_edge("retrieve", "answer")

Sie definieren die Struktur – „retrieve läuft, dann läuft answer“ – und LangGraph übernimmt die Ausführung. Es ist nicht nötig, Orchestrierungs-Code zu schreiben, um Zustand zwischen Schritten zu übergeben. Kontrollfluss wie Sequenzierung oder Branching wird in der Graph-Struktur selbst deklariert.

3. Bedingtes Routing

Laufzeit-Entscheidungen darüber, welchen Pfad der Workflow nehmen soll.

from langchain_core.messages import BaseMessage
 
def route_request(state):
    last_message = state["messages"][-1].content
    if "refund" in last_message:
        return "create_ticket"
    else:
        return "answer_question"
 
graph.add_conditional_edges(
    "classify",
    route_request,
    {
        "create_ticket": "create_ticket",
        "answer_question": "answer_question",
    }
)

Die zentrale Erkenntnis: Die Routing-Funktion gibt den Namen des nächsten Nodes zurück („create_ticket“ oder „answer_question“).

Warum das wichtig ist: Ihre Entscheidungslogik ist von der Ausführung getrennt. Routing-Regeln ändern? Bearbeiten Sie eine Funktion. Alle möglichen Pfade und Übergänge sehen? Schauen Sie in die Graph-Definition. Debuggen, welcher Pfad genommen wurde? Inspizieren Sie die Ausführungsspur – ohne sich durch verschachtelte Funktionsaufrufe zu wühlen.

4. Checkpointing und Persistenz

Zustand wird nach jedem Schritt automatisch gecheckpointet, wodurch Wiederherstellung nach Abstürzen sowie Pause-und-Resume-Workflows möglich werden.

from langgraph.checkpoint.sqlite import SqliteSaver
 
checkpointer = SqliteSaver("agent_state.db")
graph = graph.compile(checkpointer=checkpointer)
 
# State wird bei jedem Schritt automatisch gespeichert
result = graph.invoke(
    input_state,
    config={"configurable": {"thread_id": "user-123"}}
)

Nach jedem Schritt checkpointet LangGraph den aktuellen Zustand in persistente Speicherung. Wenn der Prozess abstürzt, kann die Ausführung vom neuesten Checkpoint fortgesetzt werden, der mit derselben Thread-ID verknüpft ist.

Checkpointing ermöglicht Pause-und-Resume-Workflows, z. B. das Warten auf menschliche Freigabe, wenn es mit bedingtem Routing oder Interrupts kombiniert wird.

Wann Sie welches Framework verwenden

Verwenden Sie LangChain, wenn:

• Sie einfache Chains bauen (Prompt → LLM → Parser)
• Sie RAG-Systeme implementieren
• Sie nachrichtenbasierten Kontext behandeln (Chatverlauf explizit übergeben)
• Sie über LLM-Anbieter abstrahieren möchten

Verwenden Sie LangGraph, wenn:

• Sie mehrschrittige Agent-Workflows bauen
• Sie bedingte Routing-Logik implementieren
• Sie komplexen Zustand über Schritte hinweg verwalten
• Sie Checkpointing und Crash-Recovery benötigen

2.3) Wie LLMs funktionieren (für Agent-Entwickler)

Um effektive Agenten zu bauen, müssen Sie verstehen, wie LLMs tatsächlich funktionieren. Es geht hier nicht um die Mathematik von Transformers – es geht um das mentale Modell, das prägt, wie Sie Agent-Systeme entwerfen.

Der Kernmechanismus: Token-Vorhersage

Hier ist die fundamentale Einsicht: LLMs „wissen“ Fakten nicht so, wie Datenbanken es tun. Sie sagen das nächste Token voraus.

Zerlegen wir das an einem konkreten Beispiel.

Input: „Die Hauptstadt von Frankreich ist“

Was Sie vielleicht denken, was passiert:

1. Das LLM „schlägt“ die Hauptstadt von Frankreich in seiner Wissensbasis nach
2. Das LLM „ruft“ die Antwort ab: Paris
3. Das LLM gibt „Paris“ zurück

Was tatsächlich passiert:

1. Das LLM wandelt die Eingabe in Tokens um: ["Die", "Hauptstadt", "von", "Frankreich", "ist"]
2. Das LLM berechnet eine Wahrscheinlichkeitsverteilung über ALLE möglichen nächsten Tokens
3. Wahrscheinlichstes nächstes Token: "Paris" (höchste Wahrscheinlichkeit)
4. Das LLM sampelt aus der Verteilung (meist wird die höchste Wahrscheinlichkeit gewählt)
5. Das LLM gibt „Paris“ zurück

Das LLM „weiß“ nicht, dass Paris die Hauptstadt ist. Es sagt voraus, dass „Paris“ das wahrscheinlichste nächste Token ist, angesichts des Eingabemusters.

(Hinweis: Tokenisierung und Wahrscheinlichkeiten sind konzeptionell und variieren je nach Modell und Tokenizer.)

Warum das für Agenten wichtig ist

Dieses Token-Vorhersage-Modell hat tiefgreifende Auswirkungen auf das Agent-Design:

Implikation 1: LLMs können halluzinieren

Da LLMs Tokens vorhersagen (statt Fakten abzurufen), können sie plausibel klingende, aber falsche Informationen erzeugen.

from langchain_openai import ChatOpenAI
 
llm = ChatOpenAI(model="gpt-4o-mini")
response = llm.invoke("Was ist die Hauptstadt von Atlantis?")
print(response.content)
 
# Hinweis: Die tatsächliche Ausgabe kann variieren. 
# Moderne Modelle könnten Atlantis als fiktiv erkennen und die Antwort verweigern.
# Der zentrale Punkt:
# Ohne explizites Fact-Checking können LLMs plausibel klingende falsche Informationen erzeugen.

Mögliche (historische oder unbeschränkte) Ausgabe:

Die Hauptstadt von Atlantis ist Etheria. Laut Platons Aufzeichnungen war Etheria eine Hafenstadt an der östlichsten Spitze der Insel, und ihr Name leitete sich aus dem Glauben ab, dass sie bis in den Himmel reichte.

Das LLM generiert eine vernünftig klingende Antwort, obwohl Atlantis fiktiv ist. Für Agenten bedeutet das:

• Vertrauen Sie LLM-Ausgaben niemals blind
• Validieren Sie Fakten gegen maßgebliche Quellen
• Implementieren Sie Schutzmechanismen (Guardrails)

Implikation 2: Kontext ist alles

LLMs sehen nur die Tokens, die Sie bereitstellen. Sie haben keine Erinnerung an vorherige Gespräche, es sei denn, Sie fügen diesen Kontext explizit hinzu.

# Erster Aufruf
response1 = llm.invoke("Mein Name ist Alice")
print(response1.content)  # "Schön, Sie kennenzulernen, Alice!"
 
# Zweiter Aufruf (separate Invocation)
response2 = llm.invoke("Wie heiße ich?")
print(response2.content)  # "Ich habe keinen Zugriff auf Ihren Namen..."

Der zweite Aufruf hat keinen Kontext aus dem ersten. Für Agenten bedeutet das:

• Sie müssen den Chatverlauf verwalten
• Kontextfenster-Limits sind wichtig
• Zustandsverwaltung ist kritisch

Implikation 3: Prompts sind Anweisungen, keine Queries

Da LLMs Tokens vorhersagen, beeinflusst die Formulierung Ihres Prompts die Ausgabequalität dramatisch.

# Schwacher Prompt (Query-Stil)
response = llm.invoke("refund policy")
# Ausgabe: "Was möchten Sie über die Rückerstattungsrichtlinie wissen?"
 
# Starker Prompt (Anweisungs-Stil)
response = llm.invoke(
    "Sie sind ein Kundensupport-Agent. Erklären Sie unsere Rückerstattungsrichtlinie klar und prägnant."
)
# Ausgabe: "Unsere Rückerstattungsrichtlinie erlaubt Rückgaben innerhalb von 30 Tagen..."

Für Agenten bedeutet das:

• Prompts sind Ihr primärer Kontrollmechanismus
• Prompt Engineering ist eine Kernkompetenz
• Systemnachrichten legen das Agent-Verhalten fest

Implikation 4: Strukturierte Ausgabe erfordert Anleitung

LLMs generieren von Natur aus Freitext. Strukturierte Ausgabe (JSON, spezifische Formate) zu erhalten, erfordert explizite Anweisungen.

# Ohne Struktur-Anleitung
response = llm.invoke("Extrahieren Sie die Bestell-ID aus: 'Ich möchte eine Rückerstattung für Bestellung #12345'")
print(response.content)
# Ausgabe: "Die Bestell-ID ist 12345" (Plaintext, inkonsistentes Format)
 
# Mit Struktur-Anleitung
response = llm.invoke(
    'Extrahieren Sie die Bestell-ID und geben Sie NUR ein JSON-Objekt im Format zurück: {"order_id": "..."}\n\n'
    "Text: 'Ich möchte eine Rückerstattung für Bestellung #12345'"
)
print(response.content)
# Ausgabe: {"order_id": "12345"} (strukturiert, parsebar)

Für Agenten bedeutet das:

• Verwenden Sie Schemas, um das Ausgabeformat einzuschränken
• Spezifizieren Sie Ausgabeformate explizit
• Validieren und parsen Sie LLM-Antworten

Freitext ist für Menschen optimiert. Agenten brauchen explizite Formatierung, um Maschinenlesbarkeit sicherzustellen.

Determinismus, Stochastik und moderne LLMs

LLMs sind grundlegend probabilistische Systeme. Sie generieren Text, indem sie die wahrscheinlichsten nächsten Tokens vorhersagen, nicht indem sie deterministische Regeln ausführen. Daher garantiert derselbe Input nicht immer denselben Output.

In früheren Modellen kontrollierten Entwickler diese Zufälligkeit explizit mit Parametern wie temperature. Niedrigere Werte erzeugten vorhersehbarere Ausgaben, während höhere Werte Variation und Kreativität förderten.

Viele moderne schlussfolgerungsorientierte Modelle stellen keine Parameter wie temperature oder top_p mehr bereit. Stattdessen verwalten sie Decoding- und Sampling-Strategien intern, um stabiles, strukturiertes Schlussfolgern zu priorisieren. Das bedeutet jedoch nicht, dass diese Modelle vollständig deterministisch sind.

Auch diese Modelle garantieren keine identischen Ausgaben. Ausgaben können variieren durch:

• Internes Sampling: Das Modell kann unterschiedliche Schlussfolgerungs-Pfade verfolgen und Ausgaben erzeugen, die sich in Struktur, Detailgrad oder Formulierung unterscheiden.
• Modell-Updates: Anbieter aktualisieren Modelle kontinuierlich ohne Ankündigung, sodass derselbe Prompt im Laufe der Zeit unterschiedliche Antworten liefern kann.
• Safety-Filter: Content Moderation kann dazu führen, dass das Modell in einem Fall direkt antwortet, in einem anderen ausweicht, verweigert oder umformuliert.
• Tool-Policies: In Agent-Systemen kann das Modell für denselben Input unterschiedliche Tools aufrufen – oder gar keine – und dadurch Ausführungspfade ändern.

Was das für Agent-Builder bedeutet:

Die zentrale Sorge ist nicht Parameter-Tuning – sondern Vorhersagbarkeit. Agent-Systeme sollten so entworfen werden, dass LLM-Ausgaben in Wortlaut, Struktur oder sogar Schlussfolgerungen variieren können, sofern sie nicht explizit eingeschränkt werden.

Das führt zu mehreren konkreten Designprinzipien für Agent-Systeme:

• Verlassen Sie sich nie auf exakte Formulierungen für Logikentscheidungen — der Kontrollfluss sollte von strukturierten Signalen (Schemas, Enums, Flags) abhängen, nicht vom Abgleich bestimmter Phrasen in der Modellausgabe.
• Erzwingen Sie Struktur an Schnittstellen — wann immer eine LLM-Ausgabe von Code konsumiert wird, schränken Sie sie mit Schemas, Validatoren oder strikten Formaten ein, sodass das Programm niemals Freitext „interpretieren“ muss.
• Verifizieren Sie alles, was wichtig ist — Fakten, die Geld, Berechtigungen oder irreversible Aktionen betreffen, müssen mit Tools oder externen Systemen geprüft werden, nicht allein dem Modell vertraut werden.
• Behandeln Sie LLM-Ausgaben als Vorschläge, nicht als Entscheidungen — das Modell schlägt vor, was zu tun ist, aber das System entscheidet, ob, wann und wie gehandelt wird.

In modernen Agent-Systemen kommt Zuverlässigkeit aus Systemdesign, nicht aus Parameter-Tuning. Je kritischer die Aufgabe, desto weniger Freiheit sollte das Modell haben – und desto mehr Struktur sollte Ihr Agent erzwingen.

Kernaussage: Bauen Sie zuverlässige Agenten durch Schemas, Validierung und Tool-Integration – nicht, indem Sie auf konsistente LLM-Ausgaben hoffen.

Im nächsten Abschnitt betrachten wir die wirtschaftlichen Auswirkungen tokenbasierter Verarbeitung.

2.4) Tokens: Die grundlegende Ressource

Tokens sind die Basiseinheit, die LLMs verarbeiten. Tokens zu verstehen ist essenziell, weil sie sowohl bestimmen, was möglich ist (Einschränkungen) als auch, was teuer wird (Kosten) in Agent-Systemen.

Was ist ein Token?

Ein Token ist die kleinste Texteinheit, über die ein LLM „nachdenkt“ und die es generiert.

Je nach Sprache und Kontext kann ein Token darstellen:

• Ein Wort (agent)
• Einen Teil eines Wortes (calculat, ion)
• Eine Zahl oder ein Symbol (#, 123)
• Interpunktion oder Whitespace

Tokens sind keine Zeichen und keine Wörter — sie sind modellspezifische Einheiten, die vom Tokenizer erzeugt werden.

Jede Information, die an das Modell gesendet oder vom Modell generiert wird, wird in Tokens gemessen:

• System Instructions
• User Messages
• Abgerufene Dokumente
• Tool-Beschreibungen
• Modell-Ausgaben

Tokens sind die grundlegende Währung der LLM-Interaktion.

Tokens als Systemeinschränkung

Tokens sind nicht nur ein Kostenfaktor – sie sind eine harte Grenze dafür, was Ihr Agent in einer einzelnen Anfrage tun kann.

Jedes LLM hat ein Kontextfenster: eine feste maximale Anzahl von Tokens, die es auf einmal verarbeiten kann.

Beispielszenario: Ihr Kundensupport-Agent benötigt:

• System Instructions: 200 Tokens
• Letzte 10 Nachrichten: ~2.000 Tokens
• 3 abgerufene Hilfe-Artikel: ~1.500 Tokens
• Generierte Antwort: ~200 Tokens
• Summe: 3.900 Tokens

Wenn das Kontextfenster Ihres Modells 4.000 Tokens beträgt, sind Sie bei 97,5 % Auslastung. Eine weitere lange Nachricht, und das System funktioniert nicht mehr.

(Moderne Modelle haben typischerweise Kontextfenster mit 128K+ Tokens, aber das Prinzip bleibt: Kontext ist endlich, und Sie müssen um diese Grenze herum entwerfen.)

Was passiert, wenn Sie das Limit überschreiten:

• Ältere Nachrichten werden verworfen → Agent vergisst früheren Kontext, was Gesprächskontinuität bricht
• Abgerufene Dokumente werden abgeschnitten → Kritische Informationen gehen verloren, was zu falschen Antworten führt
• Die Anfrage schlägt komplett fehl → Das System kann überhaupt nicht antworten

Sie können nicht für mehr Platz bezahlen. Das Kontextfenster ist eine harte Grenze – wie der Versuch, 2 Liter in eine 1-Liter-Flasche zu füllen.

Deshalb müssen Agenten mit langen Laufzeiten aktiv verwalten, was im Kontext bleibt und was nicht. Token-Management ist eine architektonische Kernfrage, kein Optimierungsdetail.

Was Tokens direkt beeinflussen

Über die unmittelbare Kontextfenster-Grenze hinaus prägen Tokens zwei kritische Designentscheidungen:

1. Konversationsspeicher-Strategie: Vollständige Historie vs. Zusammenfassung

Den vollständigen Chatverlauf zu behalten erhält Details, lässt aber die Token-Nutzung kontinuierlich wachsen.

Eine gängige Alternative ist Zusammenfassung des Konversationsspeichers:

• Ersetzen Sie ältere Nachrichten durch eine kompakte Zusammenfassung
• Bewahren Sie die Intention, während Sie die Token-Kosten reduzieren

Dieser Trade-off beeinflusst:

• Kosten
• Genauigkeit
• Langfristige Agent-Konsistenz

Konversationsspeicher-Design ist daher ein Token-Management-Problem.

2. RAG-Chunk-Größe und Retrieval-Strategie

Bei Retrieval-Augmented Generation (RAG) werden Dokumente vor dem Retrieval in Chunks aufgeteilt.

• Große Chunks

  • Weniger Retrieval-Aufrufe
  • Höhere Token-Kosten pro Anfrage
  • Mehr irrelevanter Kontext

• Kleine Chunks

  • Niedrigere Token-Kosten
  • Höhere Präzision
  • Risiko, wichtige Informationen zu verpassen

Chunk-Größe ist eine kritische Designentscheidung — sie beeinflusst sowohl Kosten als auch Antwortqualität direkt.

Token-Ökonomie

Token-Kosten zu verstehen hilft Ihnen, kosteneffektive Systeme zu bauen.

Typische Preise (2026):

Zentrale Einsicht: Output-Tokens kosten 4–8x mehr als Input-Tokens, was bedeutet, dass unkontrollierte Generierung oft der größte Kostentreiber in Produktionssystemen ist.

Schnelle Kostenschätzung:

Für eine typische Anfrage mit 500 Input-Tokens und 50 Output-Tokens mit GPT-5-mini:

• Input: (500 / 1.000.000) × $0.25 = $0.000125
• Output: (50 / 1.000.000) × $2.00 = $0.0001
• Summe: ~$0.000225 pro Anfrage

Bei 10.000 Anfragen/Tag: ~$67.5/Monat

Kostenoptimierung in der Praxis

Strategie 1: Modell an Aufgabenkomplexität anpassen

Verwenden Sie kleinere, günstigere Modelle für einfache Aufgaben:

from langchain_openai import ChatOpenAI
 
# Teures Modell für komplexes Schlussfolgern
complex_llm = ChatOpenAI(model="gpt-5")
 
# Günstiges Modell für einfache Aufgaben
simple_llm = ChatOpenAI(model="gpt-5-nano")
 
def get_llm_for_task(task_type):
    if task_type == "complex_reasoning":
        return complex_llm
    else:
        return simple_llm

Strategie 2: Kontextgröße mit Qualität ausbalancieren

Fügen Sie nur notwendigen Kontext hinzu:

# Effizient: Nur relevante Chunks einschließen
relevant_chunks = retrieve_top_k(user_question, k=3)  # ~500 tokens
prompt = f"Kontext: {relevant_chunks}\n\nFrage: {user_question}"

Wichtig: Zu aggressive Kontextreduktion kann die Antwortgenauigkeit verschlechtern. Balancieren Sie Kosteneinsparungen mit Qualität.

Strategie 3: Output-Länge kontrollieren

Begrenzen Sie, wie viel das Modell generiert:

# Kostenkontrolliert
llm = ChatOpenAI(model="gpt-5-mini", max_tokens=100)
response = llm.invoke(messages)
# Maximal 100 Output-Tokens

Kernaussage: Token-Management geht nicht nur darum, Kosten zu senken – es geht darum, zuverlässige, skalierbare Agent-Systeme innerhalb harter Ressourceneinschränkungen zu entwerfen.

Im nächsten Abschnitt betrachten wir die Modelllandschaft und lernen, wie Sie das richtige Modell für jede Aufgabe wählen.

2.5) Die Modelllandschaft verstehen

Das richtige LLM für Ihren Agenten auszuwählen erfordert das Ausbalancieren von:

• Kontextfenster: Wie viel Text kann das Modell verarbeiten?
• Kosten: Wie viel kostet jede Anfrage?
• Latenz: Wie schnell antwortet das Modell?
• Fähigkeiten: Wie gut kann das Modell schlussfolgern?

Schauen wir uns die Modelllandschaft 2026 an.

Große Modellfamilien

OpenAI GPT-Modelle

Anthropic Claude-Modelle

Google Gemini-Modelle

Anbieterspezifische Merkmale

OpenAI:

• Am besten für: General-purpose Agenten, breite Multi-Domain-Workflows, Function Calling
• Stark in: Vielseitigem Schlussfolgern, starkem Entwickler-Tooling & Ökosystem, häufigen Modell-Updates

Anthropic:

• Am besten für: Safety-sensitive Workflows, strukturiertes und erweitertes Schlussfolgern
• Stark in: Tiefgehender Analyse, methodischen Ausgaben, erweitertem Denken mit starker Alignment

Google:

• Am besten für: Massive Kontextaufnahme und multimodale Aufgaben
• Stark in: Großskaliger Dokumentanalyse, multimodalem Verständnis, High-Throughput-Processing

Modelle an Aufgaben anpassen

Wählen Sie basierend auf Aufgabenkomplexität, Kontextgröße und Latenzanforderungen:

Nach Aufgabenkomplexität

Einfache Aufgaben → Kostenoptimierte Modelle (GPT-5-nano, GPT-5-mini):

• Intent-Klassifikation, Sentiment-Analyse, Keyword-Extraktion, einfache Formatierung
• Geeignet, wenn: Kosten die primäre Sorge sind

Moderate Aufgaben → Ausbalanciertes Modell (GPT-5-mini):

• Question Answering, Zusammenfassung, Tool-Auswahl
• Geeignet, wenn: Sie Kosten und Qualität ausbalancieren müssen

Komplexe Aufgaben → Performance-orientierte Modelle (GPT-5, Claude Sonnet, Gemini Pro):

• Mehrschrittiges Schlussfolgern, Code-Generierung, detaillierte Analyse
• Geeignet, wenn: Schlussfolgerungsfähigkeit wichtig ist und Kosten akzeptabel sind

Höchste Komplexität → Premium-Modelle (Claude Opus):

• Extrem komplexes Schlussfolgern, mission-kritische Entscheidungen
• Geeignet, wenn: Genauigkeit oberste Priorität hat und Kosten zweitrangig sind

Nach Latenzanforderungen

Echtzeit (~1s oder weniger wahrgenommene Latenz) → Schnelle Modelle (GPT-5-nano, Gemini Flash):

• Benutzerorientierter Chat
• Interaktive Anwendungen

Nahe Echtzeit (1–3s) → Die meisten Modelle:

• Standard-Agent-Aufgaben

Batch (>3s) → Fähige Modelle:

• Hintergrundanalyse

Kontextfenster-Überlegungen

Standardaufgaben: Alle großen Modelle unterstützen 200K+ Tokens, ausreichend für die meisten Agent-Workflows.

Sonderfälle:

• Wenn Sie 400K Tokens benötigen: GPT-5-Familie (vollständige Dokumentanalyse, große Codebases)
• Wenn Sie 1M Tokens benötigen: Gemini-Modelle (ganze Bücher, massive Dokumentsets)

Praktischer Rat: Selbst bei großen Kontextfenstern liefert selektives Retrieval (RAG) meist bessere Ergebnisse.

Zentrale Erkenntnisse

1. Kein einzelnes „bestes“ Modell → Verschiedene Modelle sind in verschiedenen Aufgaben stark
2. Modell an Aufgabenkomplexität anpassen → Bezahlen Sie nicht zu viel für einfache Aufgaben
3. Kontextfenster ≠ besser → Verwenden Sie selektives Retrieval
4. Latenz beeinflusst die User Experience → Berücksichtigen Sie Antwortzeiten für interaktive Aufgaben

In der Praxis: Die meisten Agenten verwenden mehrere Modelle — günstige Modelle für einfache Aufgaben, leistungsfähige Modelle für komplexes Schlussfolgern. Wir implementieren das in späteren Kapiteln.

Im nächsten Abschnitt lernen wir, wie Sie Modellverhalten durch effektives Prompting steuern.

2.6) Prompting-Grundlagen für Agent-Systeme

Prompts sind Ihre primäre Schnittstelle, um LLM-Verhalten zu steuern. Für Agenten ist effektives Prompting kritisch – es entscheidet, ob Ihr Agent korrekte Entscheidungen trifft, die richtigen Tools aufruft und zuverlässige Ausgaben produziert.

Die Anatomie eines Prompts

Ein vollständiger Prompt hat drei Komponenten:

1. Systemnachricht (Rolle und Einschränkungen) Definiert Persona, Fähigkeiten und Grenzen des Agenten.

2. Kontext (relevante Informationen) Liefert die Informationen, die benötigt werden, um die Aufgabe zu erledigen.

3. Anweisung (konkrete Aufgabe) Sagt dem Agenten exakt, was zu tun ist.

Sehen wir uns das in der Praxis an:

from langchain_openai import ChatOpenAI
 
llm = ChatOpenAI(model="gpt-5-mini")
 
response = llm.invoke([
    # Systemnachricht: Rolle und Einschränkungen definieren
    {
        "role": "system",
        "content": """Sie sind ein Kundensupport-Agent für TechCorp.
        
Ihre Fähigkeiten:
- Beantworten Sie Fragen zu Rückerstattungsrichtlinien
- Erstellen Sie Support-Tickets
- Geben Sie Troubleshooting-Anleitungen
 
Ihre Einschränkungen:
- Beantworten Sie nur Fragen zu TechCorp-Produkten
- Machen Sie niemals Zusagen zu Rückerstattungszeiten
- Seien Sie immer höflich und professionell"""
    },
    
    # User Message: Kontext + Anweisung
    {
        "role": "user",
        "content": """Kontext: Kunde hat Laptop-Modell X500 am 2026-01-15 gekauft.
Heute ist 2026-02-20. Unsere Rückerstattungsrichtlinie erlaubt Rückgaben innerhalb von 30 Tagen.
 
Anweisung: Der Kunde möchte eine Rückerstattung. Was sollte ich ihm sagen?"""
    }
])
 
print(response.content)

Ausgabe:

Ich verstehe, dass Sie eine Rückerstattung für Ihr Laptop-Modell X500 möchten. Leider 
liegt Ihr Kaufdatum am 15. Januar und heute ist der 20. Februar, sodass wir 
außerhalb unseres 30-Tage-Rückgabefensters sind. Gern kann ich jedoch ein Support- 
Ticket erstellen, um andere Optionen zu prüfen, z. B. Garantieservice oder Austausch. 
Möchten Sie, dass ich damit fortfahre?

Systemnachrichten: Agent-Verhalten festlegen

In der Systemnachricht definieren Sie Persönlichkeit und Fähigkeiten Ihres Agenten. Das ist der wichtigste Teil beim Prompting für Agenten.

Schwache Systemnachricht:

system_message = "Sie sind ein hilfreicher Assistent."

Starke Systemnachricht:

system_message = """Sie sind ein Kundensupport-Agent für TechCorp.
 
ROLE:
Sie helfen Kunden bei Rückerstattungsanfragen, Produktfragen und technischen Problemen.
 
CAPABILITIES:
- Beantworten Sie Fragen anhand bereitgestellter Dokumentation
- Erstellen Sie bei Bedarf Support-Tickets
- Geben Sie Schritt-für-Schritt-Troubleshooting
 
CONSTRAINTS:
- Beantworten Sie nur Fragen zu TechCorp-Produkten
- Wenn Sie etwas nicht wissen, sagen Sie es – raten Sie niemals
- Zitieren Sie immer Quellen, wenn Sie Dokumentation verwenden
- Versprechen Sie niemals konkrete Zeitpläne oder Ergebnisse
 
TONE:
Professionell, empathisch und lösungsorientiert.
"""

Warum die starke Version besser funktioniert:

1. Explizite Fähigkeiten → Agent weiß, was er tun kann
2. Klare Einschränkungen → Agent weiß, was er vermeiden soll
3. Definierter Ton → Konsistente Persönlichkeit
4. Spezifische Anweisungen → Reduziert Mehrdeutigkeit

Klarheit von Anweisungen: Seien Sie spezifisch

LLMs folgen Anweisungen wörtlich. Vage Anweisungen liefern unzuverlässige Ergebnisse.

Vage Anweisung:

instruction = "Helfen Sie dem Kunden mit seiner Rückerstattung."

Spezifische Anweisung:

instruction = """Analysieren Sie die Anfrage des Kunden und bestimmen Sie:
1. Ist die Bestellung für eine Rückerstattung berechtigt? (Kaufdatum vs. Rückerstattungsrichtlinie prüfen)
2. Wenn berechtigt: Erklären Sie den Rückerstattungsprozess
3. Wenn nicht berechtigt: Erklären Sie warum und bieten Sie Alternativen an
 
Formatieren Sie Ihre Antwort als:
- Eligibility: [YES/NO]
- Reason: [Kurze Erklärung]
- Next Steps: [Was der Kunde tun sollte]
"""

Kontext-Management: Geben Sie, was benötigt wird

Agenten brauchen Kontext, um Entscheidungen zu treffen, aber zu viel Kontext verschwendet Tokens und verwirrt das Modell.

Over-Contextualization (Verschwendung):

context = f"""
Unternehmensgeschichte: TechCorp wurde 1995 gegründet...
Produktkatalog: Wir verkaufen 500+ Produkte, darunter...
Rückerstattungsrichtlinie: {refund_policy_text}
Versandrichtlinie: {shipping_policy_text}
Garantiebedingungen: {warranty_policy_text}
Kundenhistorie: {full_customer_history}
"""
# 5000+ tokens, das meiste irrelevant

Selektiver Kontext (Effizient):

context = f"""
Relevante Richtlinie: {refund_policy_text}
Bestelldetails: {order_details}
"""
# 200 tokens, alles relevant

Output-Formatierung: Strukturieren Sie Ihre Antworten

Für Agenten benötigen Sie häufig strukturierte Ausgabe (JSON, spezifische Formate) statt Freitext.

Unstrukturierte Ausgabe (schwer zu parsen):

response = llm.invoke([
    {"role": "system", "content": "Sie sind ein Support-Agent."},
    {"role": "user", "content": "Sollten wir für diese Rückerstattungsanfrage ein Ticket erstellen?"}
])
print(response.content)
# Ausgabe: "Ja, ich denke wir sollten ein Ticket erstellen, weil..."
# Problem: Schwer zu parsen, inkonsistentes Format

Strukturierte Ausgabe (leicht zu parsen):

response = llm.invoke([
    {"role": "system", "content": """Sie sind ein Support-Agent.
    
Antworten Sie immer in diesem JSON-Format:
{
  "action": "CREATE_TICKET" or "ANSWER_QUESTION" or "ESCALATE",
  "reason": "Kurze Erklärung",
  "response_text": "Was dem Kunden zu sagen ist"
}"""},
    {"role": "user", "content": "Kunde möchte Rückerstattung für Bestellung #12345, vor 40 Tagen gekauft"}
])
print(response.content)

Ausgabe:

{
  "action": "CREATE_TICKET",
  "reason": "Bestellung liegt außerhalb des 30-Tage-Rückerstattungsfensters, benötigt manuelle Prüfung",
  "response_text": "Ich habe ein Support-Ticket erstellt, um Ihre Rückerstattungsanfrage zu prüfen. Unser Team wird Sie innerhalb von 24 Stunden kontaktieren."
}

Wir verwenden in Kapitel 7 Pydantic-Schemas für robuste strukturierte Ausgabe.

Few-Shot-Beispiele: Zeigen statt nur sagen

Für komplexe Aufgaben sind Beispiele wirksamer als lange Anweisungen.

Zero-Shot (nur Anweisungen):

prompt = """Extrahieren Sie die Bestell-ID, den Produktnamen und das Problem aus Kundennachrichten.
 
Kundennachricht: "Mein Laptop X500, Bestellung #12345, geht nicht an"
"""
# Modell könnte mit dem Format kämpfen

Few-Shot (mit Beispielen):

prompt = """Extrahieren Sie die Bestell-ID, den Produktnamen und das Problem aus Kundennachrichten.
 
Beispiel 1:
Input: "Mein Laptop X500, Bestellung #12345, geht nicht an"
Output: {"order_id": "12345", "product": "laptop X500", "issue": "geht nicht an"}
 
Beispiel 2:
Input: "Bestellung 67890 – Telefon lädt nicht"
Output: {"order_id": "67890", "product": "Telefon", "issue": "lädt nicht"}
 
Extrahieren Sie nun aus dieser Nachricht:
Input: "Meine Tablet-Bestellung #11111 hat einen gesprungenen Bildschirm"
Output:
"""

Das Modell lernt das Muster aus den Beispielen und wendet es konsistent an.

Prompt-Engineering-Patterns für Agenten

Pattern 1: Chain of Thought (Schlussfolgern)

Für komplexe Entscheidungen bitten Sie das Modell, „Schritt für Schritt zu denken“:

prompt = """Sie müssen entscheiden, ob ein Support-Ticket erstellt werden soll.
 
Denken Sie das Schritt für Schritt durch:
1. Worum bittet der Kunde?
2. Kann das mit vorhandener Dokumentation beantwortet werden?
3. Erfordert das manuelle Intervention?
4. Welche Aktion sollten wir ausführen?
 
Kundennachricht: "Ich möchte eine Rückerstattung für Bestellung #12345, aber ich habe den Beleg verloren"
 
Reasoning:
"""

Das Modell zeigt sein Schlussfolgern explizit, wodurch Entscheidungen transparenter und zuverlässiger werden.

Pattern 2: Constrained Generation (Safety)

Begrenzen Sie die möglichen Ausgaben des Modells:

prompt = """Klassifizieren Sie die Absicht des Kunden. Antworten Sie mit EXAKT EINER dieser Optionen:
- REFUND_REQUEST
- PRODUCT_QUESTION
- TECHNICAL_ISSUE
- OFF_TOPIC
 
Kundennachricht: "Wie setze ich mein Passwort zurück?"
 
Classification:
"""

Das verhindert, dass das Modell unerwartete Ausgaben generiert. Durch das explizite Einschränken der Output-Optionen:

• Verhindert Parsing-Fehler (immer eine von vier definierten Optionen)
• Blockiert unbeabsichtigte Aktionen (verhindert die Ausführung undefinierter Aktionen)
• Vereinfacht Debugging (begrenzter Output-Raum macht Probleme leichter nachverfolgbar)

Pattern 3: Self-Critique (Quality)

Bitten Sie das Modell, seine eigene Ausgabe zu überprüfen und zu verbessern:

prompt = """Generieren Sie eine Antwort an den Kunden und kritisieren Sie sie anschließend.
 
Kundennachricht: "Ich möchte eine Rückerstattung"
 
Schritt 1 – Antwort generieren:
[Your response here]
 
Step 2 – Critique:
- Is this response accurate?
- Is it helpful?
- Does it follow company policy?
- What could be improved?
 
Step 3 – Final response (incorporating critique):
[Improved response here]
"""

Dieser mehrschrittige Ansatz erzeugt oft hochwertigere Ausgaben, weil:

• Fängt Fehler früh ab: Das Modell überprüft sein eigenes Schlussfolgern, bevor es finalisiert
• Verbessert Ton und Klarheit: Selbstreflexion hilft, unklare oder unangemessene Sprache zu identifizieren
• Stellt Policy-Compliance sicher: Der Kritik-Schritt prüft die Einhaltung der Guidelines

Häufige Prompting-Fehler

Fehler 1: Annehmen, dass das Modell Dinge „weiß“

LLMs haben keinen Zugriff auf Echtzeitinformationen oder impliziten Kontext. Stellen Sie alle notwendigen Daten immer explizit bereit.

# Schlecht: Geht davon aus, dass das Modell das aktuelle Datum kennt
prompt = "Ist diese Bestellung für eine Rückerstattung berechtigt? Bestellung #12345"
 
# Gut: Alle notwendigen Informationen bereitstellen
prompt = f"""Ist diese Bestellung für eine Rückerstattung berechtigt?
Bestellung #12345
purchased {purchase_date}
Today: {current_date}
Richtlinie: 30-Tage-Rückgabe
"""

Fehler 2: Mehrdeutige Anweisungen

Vage Verben wie „handle“, „process“ oder „deal with“ lassen zu viel Interpretationsspielraum. Seien Sie explizit, welche genaue Aktion nötig ist.

# Schlecht: Was bedeutet "handle"?
prompt = "Bearbeiten Sie diese Rückerstattungsanfrage"
 
# Gut: Explizite Aktion
prompt = "Stellen Sie fest, ob diese Rückerstattungsanfrage berechtigt ist. Wenn ja, erstellen Sie ein Ticket. Wenn nein, erklären Sie warum."

Fehler 3: Kontext überladen

Irrelevante Informationen zu inkludieren verschwendet Tokens, erhöht Latenz und kann das Modell verwirren. Rufen Sie nur ab, was für die konkrete Aufgabe nötig ist.

# Schlecht: 10.000 Tokens Kontext, das meiste irrelevant
prompt = f"""
{entire_knowledge_base}
 
Frage: Wie lautet die Rückerstattungsrichtlinie?
"""
 
# Gut: Nur relevanten Abschnitt abrufen
prompt = f"""
{refund_policy_section}
 
Frage: Wie lautet die Rückerstattungsrichtlinie?
"""

Fehler 4: Inkonsistente Formatierung

Wenn das Ausgabeformat variiert, bricht Downstream-Code. Spezifizieren Sie immer das exakte Format, das Sie erwarten, besonders bei strukturierten Daten.

# Schlecht: Mal JSON, mal Plaintext
prompt = "Geben Sie Ihre Entscheidung zurück"
 
# Gut: Format immer spezifizieren
prompt = 'Antworten Sie im JSON-Format: {"decision": "...", "reason": "..."}'

Zentrale Erkenntnisse

Effektives Prompting für Agenten erfordert:

1. Klare Systemnachrichten → Definieren Sie Rolle, Fähigkeiten, Einschränkungen
2. Spezifische Anweisungen → Sagen Sie dem Modell exakt, was zu tun ist
3. Selektiven Kontext → Geben Sie nur relevante Informationen
4. Strukturierte Ausgabe → Spezifizieren Sie das Format explizit
5. Few-Shot-Beispiele → Zeigen Sie das Muster, das Sie möchten
6. Schlussfolgerungs-Prompts → Bitten Sie um Schritt-für-Schritt-Denken

Prompting ist eine Fähigkeit, die durch Übung besser wird. Im Laufe dieses Buches sehen Sie diese Patterns in echten Agent-Systemen angewendet.

Kapitelzusammenfassung

Sie verstehen jetzt die grundlegenden Konzepte zum Erstellen agentischer KI-Systeme:

Agentische KI vs. Chatbots:

• Agenten handeln autonom, um Ziele zu erreichen
• Agenten nutzen Tools und treffen mehrschrittige Entscheidungen
• Agenten halten Zustand und passen sich basierend auf Ergebnissen an

Warum Frameworks wichtig sind:

• LangChain bietet Modell-Abstraktion, Chains, Konversationsspeicher, Tools und RAG
• LangGraph ergänzt Zustandsverwaltung, Routing und Checkpointing
• Frameworks reduzieren Boilerplate und ermöglichen komplexe Workflows

LLM-Mechanik:

• LLMs sagen Tokens voraus, sie rufen keine Fakten ab
• Kontext ist explizit, nicht implizit
• Prompts sind Anweisungen, keine Queries
• Strukturierte Ausgabe erfordert Anleitung
• Kontextfenster sind endlich

Token-Ökonomie:

• Output-Tokens kosten 4–8x mehr als Input-Tokens
• Modellwahl hat 10–100x Kosteneffekt
• Selektiver Kontext senkt Kosten dramatisch
• Überwachung (Monitoring) und Budgets verhindern ausufernde Ausgaben

Modellauswahl:

• Modell an Aufgabenkomplexität anpassen
• Kontext-Anforderungen und Latenz-Einschränkungen berücksichtigen
• Multi-Modell-Architekturen zur Kostenoptimierung nutzen
• Günstig starten, nur bei Bedarf upgraden

Prompting-Grundlagen:

• Systemnachrichten definieren Agent-Verhalten
• Spezifische Anweisungen erzeugen zuverlässige Ergebnisse
• Selektiver Kontext verbessert Qualität und senkt Kosten
• Strukturierte Ausgabe ermöglicht Parsing und Validierung
• Few-Shot-Beispiele lehren Patterns effektiv