Ein Chatbot beantwortet Fragen. Ein Agent erledigt Aufgaben. Wer einen “KI-Agenten” baut, der keine Tools aufrufen kann, keinen Fortschritt verfolgt und nicht selbst entscheidet, was als Nächstes kommt, hat einen Chatbot mit aufwendigem System-Prompt gebaut. Diese Unterscheidung ist entscheidend: Sie bestimmt, ob das System tatsächlich Workflows automatisiert oder nur so tut.
Dieses Tutorial baut einen echten KI-Agenten in Python. Keinen Spielzeug-Prototyp, der eine API aufruft und das Ergebnis ausgibt, sondern einen Agenten, der selbstständig über Werkzeuge entscheidet, sie ausführt, die Ergebnisse auswertet und den nächsten Schritt plant. Am Ende steht funktionierender Code, dazu ein klarer Blick auf die Fehler, die im Produktivbetrieb garantiert auftreten.
Was einen Agenten vom Chatbot unterscheidet
Drei Eigenschaften trennen Agenten von Chatbots. Erstens, Tool-Nutzung: Der Agent kann externe Funktionen aufrufen, etwa Websuchen, Datenbankabfragen oder API-Calls. Zweitens, Reasoning-Schleifen: Der Agent entscheidet anhand des aktuellen Zustands, welches Tool er braucht, statt einer festgelegten Reihenfolge zu folgen. Drittens, State Management: Der Agent weiß, was er schon getan hat und was noch fehlt.
IBMs Architektur-Übersicht beschreibt das als den “Perceive, Reason, Act”-Zyklus. Das LLM ist die Denkmaschine. Tools sind die Hände. State ist das Gedächtnis. Fehlt eines davon, bleibt es ein Chatbot.
Der minimale Agent funktioniert so: Ein Nutzer gibt eine Aufgabe, das LLM wählt ein Tool, das Tool liefert ein Ergebnis, das LLM prüft, ob die Aufgabe erledigt ist, und falls nicht, wählt es das nächste Tool. Diese Schleife klingt simpel, ist aber genau das, was einen Agenten von einer linearen Kette vordefinierter Schritte trennt.
Die Wahl des Frameworks: Drei Ansätze, drei Philosophien
Für den Bau von KI-Agenten in Python gibt es 2026 drei ernstzunehmende Optionen. Jede spiegelt eine andere Philosophie wider, wie viel Kontrolle der Entwickler behalten soll.
LangGraph: Maximale Kontrolle, maximale Transparenz
LangGraph modelliert den Agenten als State Machine. Man definiert Nodes (Funktionen), Edges (Übergänge) und ein State-Objekt, das durch den Graphen fließt. Jeder Entscheidungspunkt ist explizit. Jeder Tool-Call ist ein Node. Jede Routing-Entscheidung ist eine Edge.
Das klingt nach Overhead, bis man debuggen muss, warum der Agent dreimal hintereinander dasselbe Tool aufruft. Mit LangGraph sieht man exakt, welcher Node gefeuert hat, welchen State er erhalten hat und warum die Conditional Edge zu diesem Node statt zu einem anderen geführt hat. Diese Sichtbarkeit ist der Grund, warum LangGraph bei Produktiv-Deployments dominiert: Die State of Agent Engineering 2026 Umfrage von LangChain zeigt, dass es das am häufigsten eingesetzte Framework für Agenten in Produktion ist.
Geeignet für: Entwickler, die volle Kontrolle über den Entscheidungsfluss des Agenten brauchen und testbare, debugbare Agenten-Logik wollen.
OpenAI Agents SDK: Minimaler Boilerplate, schneller Start
Das OpenAI Agents SDK geht den entgegengesetzten Weg. Man definiert einen Agenten mit Name, Instruktionen und Tools. Dann Runner.run() aufrufen. Das SDK kümmert sich intern um Reasoning-Loop, Tool-Dispatch und Konversationsmanagement.
Prototypen gehen damit schnell. Ein funktionierender Agent in 15 Zeilen Code. Aber man tauscht Kontrolle gegen Bequemlichkeit: Die Reasoning-Schleife ist eine Blackbox, Routing-Logik zwischen Agenten nutzt Handoffs, die schwer zu testen sind, und man ist lose an OpenAIs API-Design gekoppelt.
Geeignet für: Prototypen, Hackathons und Teams, die schnell ein Ergebnis sehen wollen.
CrewAI: Rollenbasierte Multi-Agenten
CrewAI strukturiert Agenten als Teammitglieder mit Rollen, Zielen und Hintergrundgeschichten. Man definiert eine “Crew” von Agenten, weist Aufgaben zu und lässt sie zusammenarbeiten. Das Framework übernimmt Delegation und Kommunikation zwischen den Agenten.
Die Rollen-Metapher macht es für nicht-technische Stakeholder intuitiv, zu verstehen, was das System tut. In deutschen Unternehmen, wo Fachabteilungen bei KI-Projekten mitreden, ist das ein echter Vorteil. Aber die Abstraktion kann bei feingranularer Kontrolle im Weg stehen.
Geeignet für: Multi-Agenten-Workflows, in denen verschiedene Agenten auf unterschiedliche Aufgaben spezialisiert sind.
Einen Research-Agenten Schritt für Schritt bauen
Jetzt wird es konkret: Ein Research-Agent, der ein Thema erhält, das Web durchsucht, Kernaussagen extrahiert und eine strukturierte Zusammenfassung liefert. Wir nutzen LangGraph, weil es die beste Sichtbarkeit in jeden einzelnen Schritt bietet.
Schritt 1: Abhängigkeiten installieren
pip install langgraph langchain-openai langchain-community tavily-python
Benötigt werden ein OpenAI API Key und ein Tavily API Key für die Websuche:
export OPENAI_API_KEY="dein-key-hier"
export TAVILY_API_KEY="dein-key-hier"
Schritt 2: State definieren
Der State ist ein TypedDict, das Informationen zwischen Nodes transportiert. Jeder Node liest daraus und schreibt hinein.
from typing import TypedDict, Annotated
from langgraph.graph.message import add_messages
class ResearchState(TypedDict):
messages: Annotated[list, add_messages]
topic: str
search_results: list[str]
summary: str
messages speichert die Konversation mit dem LLM. topic ist die Eingabe. search_results sammelt Ergebnisse. summary ist die Ausgabe.
Schritt 3: Tools definieren
from langchain_community.tools.tavily_search import TavilySearchResults
search_tool = TavilySearchResults(max_results=3)
Tavily liefert strukturierte Suchergebnisse mit Titeln, URLs und Inhalts-Snippets. Drei Ergebnisse reichen für den ersten Agenten. Mehr bedeutet mehr Tokens, höhere Kosten und sinkender Grenznutzen.
Schritt 4: Agent-Node bauen
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model="gpt-4o", temperature=0)
llm_with_tools = llm.bind_tools([search_tool])
def research_node(state: ResearchState):
"""Der Agent entscheidet, was als Nächstes zu tun ist."""
system_msg = (
f"Du bist ein Research-Agent. Dein Thema ist: {state['topic']}. "
"Suche nach Fakten, Statistiken und Expertenmeinungen. "
"Wenn du genug Informationen hast, fasse deine Ergebnisse zusammen."
)
messages = [{"role": "system", "content": system_msg}] + state["messages"]
response = llm_with_tools.invoke(messages)
return {"messages": [response]}
Schritt 5: Tool-Execution-Node bauen
from langgraph.prebuilt import ToolNode
tool_node = ToolNode([search_tool])
LangGraphs ToolNode übernimmt die Tool-Ausführung automatisch. Wenn die Antwort des LLM einen Tool-Call enthält, führt dieser Node ihn aus und schreibt das Ergebnis zurück in den State.
Schritt 6: Den Graphen verdrahten
from langgraph.graph import StateGraph, END
def should_continue(state: ResearchState):
"""Weiter zu Tools, wenn das LLM eines aufrufen will, sonst Ende."""
last_message = state["messages"][-1]
if last_message.tool_calls:
return "tools"
return END
graph = StateGraph(ResearchState)
graph.add_node("agent", research_node)
graph.add_node("tools", tool_node)
graph.set_entry_point("agent")
graph.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END})
graph.add_edge("tools", "agent")
app = graph.compile()
Der Ablauf: Der Agent-Node denkt nach und ruft optional ein Tool auf. Wenn ja, leitet der Graph zum Tool-Node, der den Call ausführt und zurück zum Agent-Node geht. Wenn der Agent keine weiteren Tool-Calls hat, endet der Graph.
Schritt 7: Ausführen
result = app.invoke({
"messages": [{"role": "user", "content": "Recherchiere den aktuellen Stand von KI-Agenten in Unternehmen"}],
"topic": "KI-Agenten in Unternehmen",
"search_results": [],
"summary": ""
})
print(result["messages"][-1].content)
Rund 60 Zeilen Code für einen funktionierenden Research-Agenten. Er durchsucht das Web, synthetisiert seine Funde und produziert eine strukturierte Antwort. Produktivreif ist er noch nicht, aber es ist ein echter Agent: Er entscheidet selbst, wann er sucht, bewertet Ergebnisse und erkennt, wann er genug Informationen hat.
Die fünf Fehler, die jeder erste Agent hat
Den Agenten zu bauen ist der einfache Teil. Ihn zuverlässig zu machen, daran arbeiten Teams monatelang. Hier die fünf Probleme, die garantiert zuerst auftreten, basierend auf dokumentierten Produktivfällen.
1. Die Endlosschleife
Der Agent ruft dasselbe Tool immer wieder auf, weil das LLM nicht erkennt, dass es die Antwort bereits hat. Lösung: Einen Schrittzähler im State und eine Conditional Edge, die nach N Iterationen den Abbruch erzwingt.
def should_continue(state: ResearchState):
if state.get("step_count", 0) >= 5:
return END # Nach 5 Schritten erzwungen stoppen
last_message = state["messages"][-1]
if last_message.tool_calls:
return "tools"
return END
2. Context-Window-Überlauf
Jeder Tool-Call fügt Tokens zur Nachrichtenhistorie hinzu. Nach zehn Suchen ist das Context Window voll mit Suchergebnissen, die der Agent nicht mehr braucht. Produktiv-Agenten nutzen Context-Kompression und Memory Management, um veraltete Informationen zu bereinigen. Der einfachste Ansatz: Tool-Ergebnisse zusammenfassen, bevor sie in den State wandern, und die Länge der Nachrichtenhistorie begrenzen.
3. Das Gott-Agent-Antipattern
Man baut einen einzigen Agenten, der alles macht: Suchen, Analysieren, Schreiben, Formatieren. Funktioniert in der Demo. Dann kommt die vierte Aufgabe dazu und der Agent verwechselt seine Instruktionen. Lösung: Verantwortlichkeiten auf spezialisierte Agenten aufteilen. Ein Such-Agent findet Informationen. Ein Analyse-Agent bewertet sie. Ein Schreib-Agent produziert die Ausgabe.
4. Keine Fehlerbehandlung für Tool-Ausfälle
APIs haben Timeouts. Suchmaschinen liefern leere Ergebnisse. Datenbankverbindungen brechen ab. Ohne Fallback für Tool-Fehler stürzt der Agent entweder ab oder halluziniert eine Antwort basierend auf dem, was er “erwartet” hätte. Tool-Calls in try/except-Blöcke packen und strukturierte Fehlermeldungen zurückgeben, über die das LLM nachdenken kann.
5. Human-in-the-Loop vergessen
Der Agent funktioniert bei zehn Testfällen perfekt. Beim elften schickt er eine E-Mail an einen Kunden, die völlig daneben ist. Jeder Agent, der externe Systeme berührt, braucht einen Checkpoint, an dem ein Mensch risikoreiche Aktionen prüfen kann, bevor sie ausgeführt werden. Gerade in deutschen Unternehmen, wo Betriebsräte bei automatisierten Entscheidungen mitbestimmen, ist das keine Option, sondern Pflicht.
Vom Tutorial zur Produktion: Was sich ändert
Der Abstand zwischen Tutorial-Agent und Produktiv-Agent ist Infrastruktur. Folgendes kommt dazu, bevor etwas Reales in Betrieb geht.
Observability: Man muss jeden Schritt des Agenten sehen können: jeden Tool-Call, jede LLM-Antwort, jede Routing-Entscheidung. LangSmith traced LangGraph-Agenten nativ. Für andere Frameworks bietet OpenTelemetry mit den GenAI Semantic Conventions framework-agnostisches Tracing.
Persistenz: Wenn der Agent mitten in einer Aufgabe abstürzt, soll er dort weitermachen, wo er aufgehört hat. LangGraphs Checkpointing erledigt das. Bei anderen Frameworks muss man eine eigene State-Persistenz-Schicht bauen.
Kostenkontrolle: Ein außer Kontrolle geratener Agent kann in Minuten hunderte Euro an API-Kosten verbrennen. Pro Ausführung Token-Budgets setzen, maximale Iterationen erzwingen und Kosten pro Ausführung loggen.
Evaluation: “Ich habe mit dem Agenten gechattet und es sah gut aus” ist keine Evaluation. Automatisierte Testsuiten bauen, die den Agenten gegen definierte Aufgaben laufen lassen und die Ergebnisse bewerten. Braintrust und LangSmith bieten Evaluations-Frameworks für nicht-deterministische Agenten-Outputs.
Sicherheit und Compliance: Wenn der Agent mit echten Credentials Tools aufruft, müssen diese Berechtigungen minimal sein. In der DACH-Region kommen DSGVO-Anforderungen hinzu: Wenn der Agent personenbezogene Daten verarbeitet, braucht es eine Datenschutz-Folgenabschätzung. Der EU AI Act verlangt ab August 2026 zusätzlich Transparenz- und Aufsichtspflichten für bestimmte Agent-Deployments.
Der Tutorial-Agent von heute ist ein Startpunkt. Produktiv-Agenten legen Schichten von Sicherheit, Observability und Resilienz um denselben Kern-Loop. Die Reasoning-Logik bleibt gleich. Die Infrastruktur drumherum macht den Unterschied zwischen Demo und vertrauenswürdigem System.
Häufig gestellte Fragen
Welche Programmiersprache eignet sich am besten für KI-Agenten?
Python dominiert die KI-Agenten-Entwicklung 2026. Alle drei großen Frameworks (LangGraph, OpenAI Agents SDK, CrewAI) sind Python-nativ, und das Ökosystem an LLM-Bibliotheken, Tool-Integrationen und Evaluations-Frameworks ist in Python am breitesten aufgestellt. TypeScript ist eine Alternative für Browser-basierte oder Node.js-Agenten.
Was kostet der Betrieb eines KI-Agenten?
Die Kosten hängen vom Modell und der Anzahl der Schritte ab. Ein einzelner GPT-4o-Aufruf kostet etwa 0,005 € pro 1.000 Input-Tokens. Ein Research-Agent mit fünf Suchanfragen und Ergebnis-Verarbeitung kostet 0,05-0,15 € pro Durchlauf. Agenten ohne Iterationslimit können in einer Session hunderte Euro verursachen, weshalb Kostenkontrolle unverzichtbar ist.
Mit welchem KI-Agent-Framework sollte ich anfangen?
LangGraph ist die beste Wahl, um zu verstehen, wie Agenten intern funktionieren. Der explizite State-Machine-Ansatz zwingt dazu, über jeden Entscheidungspunkt nachzudenken. Das OpenAI Agents SDK ist ideal für schnelle Prototypen mit minimalem Code. CrewAI eignet sich für Multi-Agenten-Workflows, in denen verschiedene Agenten spezialisierte Rollen haben.
Kann ich einen KI-Agenten ohne Programmierung bauen?
Ja. Plattformen wie n8n, Make und Zapier unterstützen KI-Agenten-Workflows mit visuellen Drag-and-Drop-Buildern. n8n ist dabei besonders bei deutschen Unternehmen beliebt, weil es Self-Hosted betrieben werden kann und so DSGVO-Anforderungen leichter erfüllt. Diese Tools funktionieren gut für einfache Workflows, stoßen aber bei komplexer State-Verwaltung oder Multi-Agenten-Orchestrierung an Grenzen.
Wie teste ich einen KI-Agenten vor dem Deployment?
Testfälle mit bekannten erwarteten Ergebnissen definieren und den Agenten automatisiert dagegen laufen lassen. Erfolgsquote, Kosten pro Durchlauf und Durchlaufzeit tracken. Tools wie LangSmith und Braintrust bieten Evaluations-Frameworks für nicht-deterministische Agenten-Outputs. Sich nie allein auf manuelles Testen durch Chatten mit dem Agenten verlassen.