Einen funktionierenden KI-Agenten bauen: Ein praktisches Glossar
Was ein KI-Agent wirklich ist, wie er sich von einem Chatbot unterscheidet, und welche Komponenten du brauchst, um einen zu bauen, der funktioniert.
Ein KI-Agent ist ein Programm, das ein Ziel erhält, eine Abfolge von Aktionen entscheidet und diese Aktionen mithilfe von Tools ausführt, bis das Ziel erreicht ist oder es aufgibt. Das unterscheidet sich von einem Chatbot, der einfach auf Nachrichten antwortet. Ein Agent plant, ruft Funktionen auf, prüft Ergebnisse und passt sich an. Wenn du ChatGPT bisher nur über einen Browser verwendet hast, ist das Bauen deines ersten Agenten der Punkt, an dem das Modell aufhört, nur ein Text-Generator zu sein, und zum Bestandteil eines größeren Systems wird.
Die Kernschleife
Jeder Agent, egal wie er vermarktet wird, führt irgendeine Version derselben Schleife aus: beobachten, denken, handeln, wiederholen. Konkret:
- Der Agent erhält eine Aufgabe ("find the cheapest flight to Lisbon next month and draft an email summary").
- Er ruft das LLM mit der Aufgabe plus einer Beschreibung der verfügbaren Tools auf.
- Das Modell gibt entweder eine endgültige Antwort oder einen Tool-Aufruf zurück, wie
search_flights(destination="Lisbon", month="2025-06"). - Dein Code führt diese Funktion aus, erhält ein echtes Ergebnis und speist es zurück in den Kontext des Modells.
- Das Modell entscheidet, was als Nächstes zu tun ist: ein anderes Tool aufrufen, um Klärung bitten oder beenden.
Dieses Muster wird oft ReAct-Schleife genannt (reason plus act), und es ist das Rückgrat von Frameworks wie LangChain's agent executors, LlamaIndex agents und OpenAI's function-calling API. Du kannst das Ganze selbst in weniger als 100 Zeilen Python mit nur einer LLM API und einer while-Schleife implementieren – die Frameworks bieten Bequemlichkeit, keine Magie.
Tools machen es zu einem Agenten
Ein Modell ohne Tools kann nur reden. Gib ihm Funktionen und es kann handeln. Tools sind typischerweise einfache Python-Funktionen mit einem Schema, das ihren Namen, ihre Parameter und ihren Zweck beschreibt, damit das Modell weiß, wann und wie man sie aufruft. Beispiel:
def get_weather(city: str) -> str:
"""Return current weather for a given city."""
resp = requests.get(f"https://api.weather.example/v1/{city}")
return resp.json()["summary"]
Bei OpenAI's function-calling übergibst du ein JSON-Schema zusammen mit dieser Funktion, und das Modell gibt einen strukturierten Aufruf wie {"name": "get_weather", "arguments": {"city": "Lisbon"}} statt freiem Text aus. Dein Code analysiert das, führt die echte Funktion aus und gibt das Ergebnis als neue Nachricht in der Konversation zurück. Wiederhole das, bis das Modell genug Informationen hat, um zu antworten.
Speicher und Zustand
Ein einzelner API-Aufruf hat keinen Speicher über sein Kontextfenster hinaus. Agenten brauchen expliziten Zustand: eine laufende Liste von Nachrichten (die Konversationshistorie) und oft einen separaten Speicher für längerfristige Fakten. Für kurze Aufgaben reicht eine Python-Liste von Dicts, die die Konversation darstellen. Für Agenten, die sich über Sitzungen hinweg an Dinge erinnern müssen, greifst du zu einer Vektor-Datenbank (Chroma, Pinecone, Qdrant), um relevante vergangene Informationen über Embeddings zu speichern und abzurufen.
Überkompliziere das nicht früh. Eine überraschend große Zahl von "Agent"-Projekten scheitert nicht, weil das LLM schwach ist, sondern weil die Zustandsverwaltung schlampig ist: doppelte Nachrichten, unbegrenztes Kontextwachstum oder der Verlust des Überblicks darüber, welcher Tool-Aufruf zu welchem Ergebnis gehört.
Ein minimales funktionierendes Beispiel
Hier ist die Form eines elementaren Agenten, der OpenAI's API nutzt, ohne Framework:
messages = [{"role": "user", "content": "What's the weather in Lisbon?"}]
while True:
response = client.chat.completions.create(
model="gpt-4o",
messages=messages,
tools=[weather_tool_schema],
)
msg = response.choices[0].message
if msg.tool_calls:
for call in msg.tool_calls:
result = get_weather(**json.loads(call.function.arguments))
messages.append(msg)
messages.append({
"role": "tool",
"tool_call_id": call.id,
"content": result,
})
else:
print(msg.content)
break
Das ist ein echter, funktionierender Agent. Alles andere – Planungsstrategien, Multi-Agent-Koordination, Abruf-Pipelines – baut auf dieser Schleife auf.
Wo es bricht
Agenten scheitern auf vorhersehbare Weise: unendliche Tool-Aufruf-Schleifen, wenn das Modell nicht erkennen kann, dass es erfolgreich war, halluzinierte Funktionsargumente und ausufernde Kosten durch wiederholte Aufrufe teurer Tools. Schütze dich vor Schleifen mit einer harten Iterationsobergrenze (sagen wir 10 Schritte) und protokolliere jeden Tool-Aufruf während der Entwicklung. Validiere Argumente, bevor du etwas ausführst, das ein echtes System berührt – ein Agent, der E-Mails senden oder Shell-Befehle ausführen kann, braucht die gleiche Eingabebereinigung, die du auf Code für Benutzer anwenden würdest, denn das LLM ist im Grunde ein nicht vertrauenswürdiger Benutzer, der diese Eingabe erzeugt.
Was kommt als Nächstes
Sobald die Schleife funktioniert, beginnen die interessanten Probleme: die Wahl zwischen Single-Agent- und Multi-Agent-Designs, die Entscheidung, wie viel Autonomie man gewähren möchte, und das zuverlässige Testen von Agenten, wenn ihre Ausgabe nicht deterministisch ist. Korra Studio's AI- und Python-Tracks behandeln retrieval-augmented generation, Prompt-Design und Tool-Calling-Muster tiefer, wenn du von hier aus weiterbauen möchtest.
Mit KI-Unterstützung geschrieben, von Michal Pilch (CISSP), Korra Studio, überprüft und veröffentlicht.
Das ist eine Notiz aus der Korra-Studio-Wissensdatenbank — die Plattform verbindet jedes Thema mit 1-zu-1-Mentoring.
Kostenlos startenarrow_forward