Werkzeuge: das Modell darf handeln

Werkzeuge — das Modell darf handeln

0:00 Bis hierher liest unser Feature und formuliert. Jetzt soll es etwas tun: nach einem Ersatzteil suchen, einen Bestand prüfen, einen Rückruf anlegen. Damit verlassen wir das sichere Gebiet der Auskunft und betreten das der Wirkung — und genau deshalb ist dieses Modul zugleich der erste Teil des Sicherheitskapitels. Ein Satz zieht sich durch alles Folgende, und ich sage ihn schon jetzt: Das Modell entscheidet, aber der Code führt aus. Alle Rechte liegen beim Code.

Vom Antworten zum Handeln

0:27 Sehen wir uns zuerst an, wie das technisch überhaupt abläuft — und vor allem, wer dabei welche Rolle hat. Diese Rollenverteilung ist der Kern des ganzen Moduls und zugleich die Grundlage des Sicherheitskapitels, das in Modul zehn folgt. Wenn sie klar ist, sind viele spätere Fragen bereits beantwortet, und die restlichen Kapitel sind Handwerk.

0:48 Der Ablauf ist einfacher, als viele denken. Sie beschreiben der Anwendung Werkzeuge, die das Modell aufrufen darf. Das Modell antwortet dann nicht mit Text, sondern mit dem Wunsch, ein bestimmtes Werkzeug mit bestimmten Argumenten aufzurufen. Ihre Anwendung führt aus und gibt das Ergebnis zurück. Stellen Sie es sich vor wie einen Berater am Telefon, der selbst keinen Zugang zum System hat: Er sagt der Kollegin, was sie nachschlagen soll — und sie entscheidet, ob sie es tut.

1:15 Das Modell hat keine Rechte. Der ausführende Code hat sie. Fünf Werkzeuge, und die entscheidende Spalte ist die rechte. Drei sind lesend und laufen ohne Rückfrage — Suchen, Prüfen, Nachschlagen richtet keinen Schaden an. Zwei sind schreibend, und beide brauchen eine Bestätigung, weil sie außerhalb des Systems sichtbar werden.

1:35 Achten Sie auf die Trennung: Lesend und schreibend bleiben nicht nur in dieser Tabelle getrennt, sondern auch im Code. Das klingt nach Formalismus und ist der Grund, warum ein fehlgeleitetes Modell bei Talwerk höchstens Unsinn erzählen, aber nichts anrichten kann.

Werkzeugschnitt

1:51 Jetzt zum häufigsten Entwurfsfehler in diesem ganzen Themengebiet — und er passiert fast immer aus einem sehr verständlichen Reflex heraus. Man hat schließlich schon eine Schnittstelle, warum sollte man sie nicht anbieten? Wir schauen uns an, warum das regelmäßig scheitert und wie ein Werkzeugschnitt aussieht, der sich am fachlichen Handeln orientiert statt an der vorhandenen Technik.

2:11 Der Reflex lautet: Wir haben doch eine REST-Schnittstelle, die bieten wir einfach an. Vierzig Endpunkte, jeder mit zwölf Parametern. Das Ergebnis ist ein Modell, das ständig das falsche Werkzeug greift oder drei Aufrufe braucht, wo einer gereicht hätte. Dazu kommen technische Namen, die nichts über den fachlichen Zweck sagen, und interne Schlüssel in den Signaturen — die wird das Modell erfinden, es kann sie ja nicht kennen.

2:36 Eine API ist für Programmierer gemacht, die die Dokumentation lesen. Ein Werkzeug nicht. Der bessere Weg beginnt bei den Menschen: Beschreiben Sie, welche Handlungen jemand am Telefon tatsächlich ausführt. Daraus wird eine Handvoll fachlich benannter Werkzeuge. Und dann die Prüffrage, die ich Ihnen ans Herz lege: Kann ein neuer Kollege aus dieser Liste verstehen, was das System kann?

2:59 Ist die Liste dafür zu lang oder zu technisch, ist sie auch für das Modell zu lang. Werkzeuge mit fünf optionalen Parametern sind meist zwei Werkzeuge. Und alles, was aus der Sitzung kommt, fliegt aus der Signatur.

Die Beschreibung ist ein Prompt

3:12 Ein kurzes Kapitel über etwas, das im Code aussieht wie ein Kommentar und in Wirklichkeit die Entscheidungsgrundlage des Modells ist. Die Beschreibung eines Werkzeugs wird meist in einem Halbsatz erledigt — und ist doch der Text, nach dem entschieden wird, ob dieses Werkzeug überhaupt zum Einsatz kommt. Die halbe Stunde, die Sie hier investieren, wirkt stärker als jede Feinarbeit am Systemprompt.

3:34 Sehen Sie sich an, was in dieser Beschreibung steht — nicht die Syntax, sondern die Aussagen. Wofür das Werkzeug da ist. Für welche Fälle es nicht funktioniert. Wohin das Modell stattdessen gehen soll. Und was zurückkommt. Besonders der zweite Satz ist Gold wert: Ohne den Hinweis auf ausgelaufene Teile ruft das Modell die Prüfung mit einer ausgelaufenen Nummer auf, bekommt einen Fehler und gibt entnervt eine Vermutung aus.

3:59 Die halbe Stunde, die Sie in Werkzeugbeschreibungen stecken, zahlt sich stärker aus als jede Feinarbeit am Systemprompt. Vier Punkte, die zusammen selten mehr als fünf Zeilen brauchen. Wofür das Werkzeug da ist, in einem Satz. Wann es verwendet werden soll — und wann ausdrücklich nicht; dieser zweite Teil fehlt fast immer und ist der wirksamste.

4:20 Was es zurückgibt, damit das Modell weiß, was es erwarten darf. Und welche Einschränkungen gelten. Schreiben Sie diese vier Punkte so, als erklärten Sie einem neuen Kollegen am ersten Tag, wann er dieses Werkzeug benutzen soll. Genau das ist die Situation.

Fehler als Ergebnis zurückgeben

4:37 Jetzt zu einer Umkehrung gewohnter Praxis: Im Werkzeugcode ist die geworfene Ausnahme der falsche Weg. Das widerspricht allem, was man sich als Entwicklerin angewöhnt hat, und hat einen guten Grund. Wir schauen uns an, warum ein Fehler als Ergebnis zurückkommen muss und warum die Formulierung dieser Fehlermeldung darüber entscheidet, ob sich ein Ablauf fängt oder in einer Schleife endet.

4:58 Wenn ein Werkzeugaufruf scheitert, werfen Sie keine Ausnahme in die Schleife, sondern geben das Ergebnis zurück und kennzeichnen es als Fehler. Der Grund: Das Modell braucht diese Information, um zu reagieren. Es kann die Nummer korrigieren, ein anderes Werkzeug wählen oder nachfragen — vorausgesetzt, es erfährt, was schiefging.

5:18 Eine Ausnahme, die den Ablauf abbricht, nimmt ihm genau diese Möglichkeit. Und damit wird die Fehlermeldung zu etwas, das sie in gewöhnlichem Code nie ist: zu Lehrmaterial. Vergleichen Sie die beiden Spalten und achten Sie darauf, was die rechte mehr enthält: nicht mehr Details, sondern einen Weg nach vorn. „Fehler 404" sagt, dass etwas nicht ging.

5:40 „Katalognummer unbekannt, ausgelaufene Teile über die Teilesuche" sagt, was als Nächstes zu tun ist. Genau das entscheidet darüber, ob sich der Ablauf fängt oder in einer Wiederholungsschleife endet. Und eine Warnung: Diese Texte landen im Prompt. Also keine Stapelabbilder, keine Datenbankfehler im Klartext, keine internen Pfade.

Idempotenz und Wiederholungen

6:02 Ein Thema, das in vielen Projekten erst nach der ersten Doppelbuchung besprochen wird — wir machen es vorher. Sobald Werkzeuge schreiben, wird Wiederholbarkeit zur Frage mit Folgen, und die Ursachen dafür liegen selten in Ihrem Code. Sehen wir uns an, wie Wiederholungen entstehen und mit welchen Mitteln man verhindert, dass aus einem Aufruf zwei Vorgänge werden.

6:22 Vier Ursachen, und keine davon ist ein Fehler in Ihrem Code. Die erste Antwort ging verloren, also wird der Aufruf erneut abgesetzt. Ein Zwischenschritt schlug fehl, das Modell versucht es noch einmal. Das Modell ist unsicher und prüft lieber doppelt. Oder Ihre eigene Anwendung wiederholt nach einer Zeitüberschreitung. In allen vier Fällen entstehen ohne Vorkehrung zwei Rückrufaufträge für dieselbe Werkstatt — und die zweite Werkstatt ruft dann an und fragt, warum sie zweimal angerufen wurde.

6:52 Fünf Maßnahmen. Ein Schlüssel je Vorgang sorgt dafür, dass der wiederholte Aufruf denselben Auftrag trifft statt einen neuen anzulegen — das ist die technische Antwort auf die vier Ursachen von eben. Lesende und schreibende Werkzeuge bleiben getrennt. Schreibende werden so eng geschnitten wie möglich. Und jeder schreibende Aufruf wird mit seinen Argumenten protokolliert.

7:13 Der Gedanke dahinter: Ein Werkzeug, das ausschließlich Rückrufe anlegen kann, bleibt auch bei völligem Fehlverhalten des Modells in seinem Schaden begrenzt.

Bestätigung vor Folgenreichem

7:23 Zum Abschluss die Frage, wo der Mensch im Ablauf steht — und warum er nicht im Prompt stehen darf. Für alles, was außerhalb des Systems sichtbar wird, braucht es eine Bestätigung. Der Entwurf dafür ist einfacher, als er klingt, und er hat eine wichtige Eigenschaft: Er funktioniert auch dann noch, wenn das Modell vollständig fehlgeleitet wurde.

7:42 Der Entwurf ist einfacher, als er klingt: Das Werkzeug legt den Vorgang im Zustand „vorgeschlagen" an und gibt eine Zusammenfassung zurück, keine Vollzugsmeldung. Die Oberfläche zeigt sie, ein Klick löst aus, der Zustandswechsel wird mit Person und Zeit protokolliert. Entscheidend ist, wo diese Logik lebt: nicht im Prompt.

8:01 Eine Anweisung, vor dem Absenden nachzufragen, ist eine Bitte — und Bitten lassen sich durch eingeschleusten Text aushebeln, wie wir in Modul zehn sehen werden. Die Bestätigung gehört in den Code und ins Datenmodell. Damit sind Sie dran. Bauen Sie vier Werkzeuge: fachlich benannt, sauber beschrieben, ohne einen einzigen internen Schlüssel in der Signatur.

8:23 Fehler kommen als verwertbares Ergebnis zurück, und der Rückruf entsteht erst nach Bestätigung. Ein Hinweis zum Testen, der über diese Übung hinaus gilt: Decken Sie die Werkzeuge mit gewöhnlichen Tests ab — ohne Modell. Dann läuft Ihre Suite ohne Zugangsdaten, ohne Kosten und in Sekunden. Im nächsten Modul stellen wir dann die Frage, ob aus diesen Werkzeugen überhaupt ein Agent werden muss.