KI-Agenten erstellen: ein Lesewerkzeug Schritt für Schritt anbinden

1. Eine Aufgabe wählen, die einen Agenten braucht

Um einen KI-Agenten zu erstellen, legen Sie Auftrag und Grenzen fest, definieren erlaubte Werkzeuge, verbinden das Modell mit diesen Funktionen und prüfen Ergebnis- und Fehlerpfade. Ein Agent unterscheidet sich von einem festen Ablauf dadurch, dass das Modell über den nächsten Schritt entscheidet. Diese Unterscheidung erläutert Anthropic anhand von Workflows und Agenten.

Hier lautet die Aufgabe: „Beantworte eine Produktfrage anhand freigegebener Dokumente; bei fehlender Grundlage frage nach.“ Das Modell kann Produkt A oder B nachlesen oder direkt eine Rückfrage formulieren. Es darf weder E-Mails versenden noch Dateien verändern. Die Antwort endet immer als Entwurf für einen Menschen.

Für eine Formular-ID mit fester Zuordnung zu einer Abteilung wäre das unnötig: Eine einfache Regel genügt. Auch unsere winzige Produktdatenbank ließe sich für exakt vorgegebene Fragen ohne Modell durchsuchen. Sie dient dazu, die Agentenschleife verständlich zu erproben, nicht um einen wirtschaftlichen Vorteil gegenüber einer Suche zu behaupten.

Teststatus: Der Offline-Modus und seine Sicherheitsprüfungen wurden am 10.09.2026 ausgeführt. Dabei ersetzen geskriptete Antworten das Modell. Die Live-Anbindung ist implementiert, wurde für diesen Artikel aber nicht mit einem API-Modell ausgeführt. Das ist kein Nachweis für Modellqualität oder produktive Eignung.

2. Code herunterladen und zunächst offline starten

Sie benötigen Python 3.10 oder neuer und grundlegende Terminalkenntnisse. Zusätzliche Python-Pakete sind nicht nötig. Laden Sie ki-agent-demo.py herunter, prüfen Sie den lesbaren Quellcode und öffnen Sie ein Terminal im Downloadordner. Die Demo enthält nur zwei frei erfundene Produkttexte: Produkt A besitzt zwei Anschlüsse, Produkt B vier. Preise fehlen ausdrücklich.

python3 ki-agent-demo.py --self-test
python3 ki-agent-demo.py
python3 ki-agent-demo.py --case unklar

Unter Windows kann der Aufruf py -3 statt python3 heißen. Der Selbsttest muss mit OK: beginnen. Fehlt Python oder ist die Version zu alt, richten Sie zunächst eine passende Python-Installation ein. Ein Offline-Lauf benötigt weder Konto noch Schlüssel und sendet keine Anfrage ins Netz.

Der erste Lauf verwendet den Fall klar. Der zweite fragt ohne Produktbezeichnung nach einem Preis. Im Offline-Modus sind Werkzeugwahl und Antwort bewusst vorgegeben: So können Sie den Codepfad nachbauen, ohne eine Modellrechnung auszulösen.

3. Das Lesewerkzeug technisch begrenzen

Im Quellcode legt DOCUMENTS den zulässigen Datenbestand fest. Die Funktion read_document akzeptiert ausschließlich produkt-a oder produkt-b und genau das Argument document_id. Unbekannte Funktionen, zusätzliche Argumente und nicht freigegebene IDs lösen einen Abbruch aus. Es gibt keinen frei wählbaren Dateipfad und keinen HTTP-Abruf innerhalb dieses Werkzeugs.

Die Werkzeugbeschreibung in TOOLS erklärt dem Modell die Funktion. Die Prüfung im Python-Code bleibt trotzdem erforderlich: Eine Beschreibung ist keine Zugriffssperre. Für eine echte Wissensquelle müssten Berechtigungen und Dokumentversionen beim Abruf geprüft werden. Tauschen Sie das Beispiel nicht einfach gegen ein Konto mit Zugriff auf sämtliche Unternehmensdateien aus.

4. Die Modellschleife verstehen und optional verbinden

Die Funktion run übergibt zunächst die gewählte Testfrage. Fordert das Modell ein Werkzeug an, führt Python nur die erlaubte Funktion aus und gibt das Ergebnis mit der zugehörigen Aufruf-ID zurück. Danach kann das Modell weiterarbeiten. Dieses Prinzip entspricht dem Function-Calling-Ablauf der OpenAI Responses API. Der Code übernimmt auch die zurückgegebenen Reasoning-Elemente in den weiteren Kontext.

Für einen echten Modelllauf brauchen Sie ein eigenes OpenAI-API-Projekt, einen dort nutzbaren Schlüssel und eine Modell-ID, die Responses und Function Calling unterstützt. Prüfen Sie Modellzugang, aktuelle Preise und Projektlimits vorab. Setzen Sie den Schlüssel lokal als Umgebungsvariable OPENAI_API_KEY, niemals im heruntergeladenen Code, in einem Screenshot oder auf einer Website.

python3 ki-agent-demo.py --live --model IHRE_MODELL_ID
python3 ki-agent-demo.py --live --model IHRE_MODELL_ID --case unklar

IHRE_MODELL_ID ist ein Platzhalter, kein Modellname. Der Live-Modus sendet ausschließlich die ausgewählte synthetische Frage und gegebenenfalls die synthetischen Dokumenttexte an die API. Er kann Kosten verursachen. Es gibt höchstens vier Modellaufrufe, jeweils ein Ausgabelimit und einen Netzwerk-Timeout. Diese technischen Grenzen sind kein garantiertes Euro-Budget.

Ein Fehler beim Modellzugang oder Kontingent beendet den Lauf ohne automatischen Wiederholungsversuch. Prüfen Sie dann die angegebene HTTP-Statusnummer und Ihre Projektkonfiguration. store: false wird gesetzt; daraus folgt keine pauschale Zusage, dass keinerlei Datenverarbeitung oder Protokollierung beim Anbieter erfolgt.

5. Ergebnisse und Fehlerpfade nachvollziehen

Der folgende Ausschnitt stammt aus dem ausgeführten Offline-Lauf. Er zeigt das erwartete Werkzeugergebnis und die Übergabe, keine beobachtete Modellentscheidung. Vergleichen Sie Ihre Ausgabe Zeile für Zeile.

Eingang: Wie viele Anschlüsse hat Produkt A? Bitte mit Quelle.
Werkzeug: read_document(produkt-a)
Quelle: FIKTIV, Version 1: Produkt A hat zwei Anschlüsse. Keine Preisangabe.
ENTWURF: Produkt A hat zwei Anschlüsse. Quelle: produkt-a, Version 1.
Übergabe: Mensch prüft. Kein Versand.

Beim Fall unklar lautet der geskriptete Entwurf: „Rückfrage: Welches Produkt meinen Sie? Preise liegen nicht vor.“ Das ist die gewünschte Behandlung der fehlenden Grundlage. Im Live-Modus müssen Sie prüfen, ob das gewählte Modell tatsächlich so reagiert; die Formulierung kann abweichen.

Der Selbsttest prüft außerdem: unbekanntes Werkzeug, verbotene Dokument-ID, zusätzliches Argument, ungültiger Argumenttyp, unvollständige Modellantwort und Erreichen des Schrittlimits. Für ein echtes Modell ergänzen Sie eigene Formulierungen, widersprüchliche Fragen und Versuche, die Aufgabe durch fremde Anweisungen umzulenken. Eine im Prompt formulierte Grenze ist kein bestandener Sicherheitstest.

Ein Mensch gleicht den Antwortentwurf mit der ausgegebenen Quelle ab. Eine belegte Anschlusszahl ist akzeptabel; eine erfundene Preisangabe oder eine nicht vorhandene Fundstelle ist ein Fehler. Bei einem Fehler bleibt der Entwurf ungenutzt und der Fall wird dokumentiert. Es existiert in dieser Demo absichtlich keine Versandfunktion.

6. Testkosten und die Grenze zum Unternehmensbetrieb

Beobachtet wurden ausschließlich Offline-Läufe ohne API-Aufruf. Dafür entstanden keine API-Nutzungskosten. Ein Modellpreis pro Anfrage, Laufzeitvergleich oder eine Erfolgsquote wurde nicht gemessen. Im Live-Modus gibt die Demo die API-Usage je abgeschlossenem Lauf aus; für tatsächliche Kosten sind die Nutzungsdaten und die geltenden Tarife Ihres Projekts maßgeblich.

Die Demo besitzt keine Nutzerverwaltung, dauerhafte Protokollierung, Unternehmensintegration oder automatisierte fachliche Abnahme. Sie ist eine Lernhilfe. Vor einem Unternehmenspilot müssen Zuständigkeiten, Rechteprüfung, Tests, Freigaben und der Stopppfad ergänzt werden. Diese Aufgaben behandelt der Leitfaden zum kontrollierten Pilotieren von KI-Agenten.

Wenn Sie einen eigenen Prozess abgrenzen und umsetzen möchten, erklärt die Seite KI-Agenten für Unternehmen geeignete Einsatzfelder und die mögliche Begleitung. Beginnen Sie mit der Aufgabe und ihren Grenzen, nicht mit möglichst vielen Werkzeugen.