Tools & Agenten — vom Antworten zum Handeln

Vom Antworten zum Handeln

Bis hierher hat das Modell Text erzeugt. Mit Werkzeugen kommt eine neue Qualität hinzu: Das System kann etwas nachschlagen, berechnen — und im Zweifel etwas verändern. Damit wechselt die Risikoklasse. Eine falsche Antwort ist ärgerlich, eine falsche Aktion ist ein Vorfall.

Tool-Aufruf — Eine strukturierte Anforderung des Modells an die Host-Anwendung, eine benannte Funktion mit Argumenten aufzurufen. Der Modelloutput ist noch nicht die reale Aktion.

Ein Agent ist keine neue Art von Modell, sondern ein Steuerungsmuster: Das System lässt ein Modell zwischen Beobachtung, Auswahl eines Werkzeugs, Ergebnis und nächstem Schritt iterieren. ReAct beschreibt die Kopplung von Schlussfolgern und Handeln; Protokolle wie MCP standardisieren Teile der Schnittstelle. Die Anwendung bleibt für Ausführung, Berechtigung, Zeitlimits, Wiederholung und Protokollierung verantwortlich. Diese Trennung ist die Grundlage jedes sicheren Designs.

Ein statischer Workflow kann ebenfalls ein Modell aufrufen, ohne agentisch zu sein: Schritt A extrahiert, Schritt B prüft, Schritt C schreibt ein Ticket. Ein Agent wählt Pfad oder Wiederholung dynamisch. Vorteil: Er kann offene Aufgaben bearbeiten. Preis: Zahl und Reihenfolge der Aktionen sind weniger vorhersehbar, Tests werden zustandsbehaftet und Kosten brauchen harte Budgets.

Agentische Systeme erweitern den Fehlerraum um Sequenzen. Ein an sich zulässiger Leseaufruf kann Informationen sammeln, die in Kombination sensibel sind; mehrere harmlose Schritte können eine schädliche Wirkung vorbereiten. Policy betrachtet deshalb nicht nur einzelne Toolnamen, sondern Nutzerzweck, Ressource, bisherigen Zustand und kumulatives Budget. Nachteil: Zustandsabhängige Policy ist komplexer als eine statische Allowlist. Für einfache Prozesse bleibt die statische, enge Fähigkeit vorzuziehen.

Wer führt eigentlich aus?

Das wichtigste Missverständnis zuerst: Das Modell führt nichts aus. Es erzeugt einen strukturierten Vorschlag — Werkzeugname und Parameter — als Text. Ob dieser Vorschlag ausgeführt wird, entscheidet deine Anwendung.

Daraus folgt die zentrale Betriebsregel: Berechtigungen liegen bei der Anwendung, nicht im Prompt. Was der ausführende Dienst technisch nicht darf, kann kein noch so überredeter Modellvorschlag auslösen. Was er darf, wird früher oder später auch vorgeschlagen.

Das Modell erzeugt Toolname und Argumente. Der Host validiert sie gegen ein Schema, ermittelt die Identität des Nutzers, prüft Policy und ruft erst dann das Zielsystem auf. Ein Text wie delete_ticket(id=42) löscht nichts, solange kein Ausführer ihn akzeptiert. Umgekehrt ist der Host verantwortlich, wenn er beliebigen Modelltext als Shellbefehl ausführt. Autorisierung darf deshalb nicht an das Modell delegiert werden.

Auch Bestätigung ist eine Host-Funktion. Die UI zeigt konkrete Wirkung, Ziel und Parameter, nicht nur „Tool ausführen?“. Nachteil: Bestätigungen unterbrechen den Fluss und können zur Gewohnheitsklick-Falle werden. Sie werden deshalb nach Risiko eingesetzt und ersetzen nie Least Privilege oder serverseitige Autorisierung.

Die Nutzeridentität darf auf dem Weg zum Ziel nicht durch eine globale Agentenidentität ersetzt werden, wenn fachliche Rechte nutzerbezogen sind. On-behalf-of- oder delegierte Tokens begrenzen Zugriff auf die Rechte des aktuellen Nutzers; eine Serviceidentität passt nur für klar dienstbezogene Aktionen. Der Executor protokolliert beide: auslösenden Menschen und technische Identität. Preis: Delegation und Token-Lebenszyklen erhöhen Integrationsaufwand, verhindern aber mandantenübergreifende Wirkung durch ein gemeinsames Hochprivilegkonto.

Was Werkzeuge zurückgeben — und was das bedeutet

Werkzeuge holen Determinismus zurück: Eine Summe wird gerechnet statt geschätzt, ein Ticketstatus abgerufen statt erinnert. Genau dafür sind sie da — sie schließen die Lücken, die in den Modulen zu Reasoning-Grenzen und Grounding benannt wurden.

Aber: Das Ergebnis eines Werkzeugs landet im Kontext und wirkt dort wie jede andere Eingabe. Enthält ein abgerufenes Dokument oder ein Ticketkommentar eine Anweisung, kann diese das weitere Verhalten beeinflussen. Werkzeugausgaben sind Daten aus fremder Feder — nicht vertrauenswürdiger Input.

Lesende Werkzeuge (Suche, Status, Berechnung)

geringes Risiko — Fehler kosten eine falsche Antwort

Schreibende Werkzeuge (anlegen, ändern, senden, löschen)

hohes Risiko — Fehler haben Außenwirkung und sind oft unumkehrbar

Werkzeuge, die fremde Inhalte zurückliefern

die Ausgabe ist untrusted, unabhängig davon, wie vertrauenswürdig das Werkzeug ist

Beobachtung — Das Ergebnis eines Tool-Aufrufs, das der Steuerungsloop als neuen Kontext erhält. Es kann Daten, Fehler oder vom Zielsystem stammenden untrusted Text enthalten.

Ein erfolgreiches Protokollergebnis bedeutet nur, dass der Aufruf technisch beantwortet wurde. Der Inhalt kann veraltet, unvollständig oder absichtlich manipuliert sein. Besonders Webseiten, E-Mails und Dokumente können Anweisungen enthalten, die ein Modell als Handlungsimpuls interpretiert. Markiere Tool-Daten als Daten, begrenze die nächste Aktion durch Policy und validiere strukturierte Ergebnisse gegen ein Output-Schema.

Fehler gehören ebenfalls in den Loop, aber mit Grenzen. Ein 429 kann einen Retry rechtfertigen, ein Validierungsfehler nicht. Ohne Fehlerklassen probiert ein Agent möglicherweise dieselbe schreibende Aktion wiederholt. Preis: Eine saubere Fehler-Taxonomie und Retry-Policy kostet Implementierungsarbeit; sie verhindert unbeschränkte Schleifen und doppelte Seiteneffekte.

Toolbeschreibungen selbst sind Teil des Steuerungskontexts. Ein kompromittierter oder falsch konfigurierter Server kann irreführende Namen, Schemas oder Annotationen liefern. MCP weist ausdrücklich darauf hin, Tool-Annotationen aus untrusted Servern nicht als verlässlich zu behandeln. Vertrauenswürdige Konfiguration pinnt erlaubte Server und Fähigkeiten; dynamische Discovery darf nicht automatisch neue Rechte aktivieren. Nachteil: Pinning reduziert Plug-and-play-Flexibilität, liefert aber eine reviewbare Angriffsfläche.

Schreibende Werkzeuge brauchen andere Regeln

• Bestätigung vor Wirkung, wo die Handlung nach außen wirkt oder nicht umkehrbar ist.
• Idempotenz: Ein wiederholter Aufruf darf nicht doppelt wirken — Wiederholungen sind in Schleifen der Normalfall, nicht die Ausnahme.
• Enger Wirkungsbereich: lieber ein Werkzeug „Ticket kommentieren“ als ein Werkzeug „beliebiges SQL ausführen“.
• Protokollierung von Vorschlag, Freigabe und Ergebnis — sonst ist im Nachhinein nicht rekonstruierbar, wer was ausgelöst hat.

Schreibende Tools brauchen einen engeren Contract als lesende. Bevorzuge kleine Operationen wie set_ticket_label gegenüber offenen Werkzeugen wie run_shell. Begrenze erlaubte Felder und Werte im Schema, verwende die Identität des handelnden Nutzers und prüfe Ressourcenzugriff im Zielsystem. OWASP nennt übermäßige Funktionalität, Berechtigung und Autonomie als Ursachen von Excessive Agency.

Eine Operation sollte, wo fachlich möglich, idempotent sein: Wiederholung mit demselben Schlüssel erzeugt keinen zusätzlichen Effekt. Für nicht idempotente Vorgänge nutzt du Idempotency-Key, Zustandsprüfung oder explizite Transaktion. Nachteil: Idempotenz verlangt gespeicherten Zustand und Ablaufregeln. Ohne sie kann ein Timeout zwischen Ausführung und Antwort zu doppelter Zahlung, doppeltem Ticket oder mehrfacher Benachrichtigung führen.

Vor einer schreibenden Aktion kann ein dry_run oder Plan-Endpoint die konkrete Änderung liefern. Die Bestätigung bezieht sich auf diesen Plan und eine kurze Gültigkeit; weichen Zielzustand oder Parameter danach ab, ist neue Freigabe erforderlich. Preis: Read-before-write verdoppelt manche Aufrufe und kann Rennen zwischen Plan und Wirkung nicht allein verhindern. Das Zielsystem braucht weiterhin atomare Vorbedingungen oder Versionsnummern.

Braucht es überhaupt ein Modell in der Schleife?

Ein Agent ist ein System, das in einer Schleife selbst entscheidet, welches Werkzeug als nächstes dran ist. Das ist mächtig, wenn der Weg zum Ziel im Voraus unbekannt ist. Es ist Verschwendung, wenn der Ablauf feststeht.

Die Prüffrage lautet: Steht die Schrittfolge vorher fest? Wenn ja, gehört sie in einen deterministischen Ablauf — dort ist sie testbar, reproduzierbar und billiger. Ein Modell kann darin einzelne unscharfe Teilschritte übernehmen, ohne die Ablaufsteuerung zu bekommen.

Wie man Agenten dann tatsächlich auslegt — Schleifenbegrenzung, Zustandsführung, Wiederanlauf, Beobachtbarkeit — behandelt der Agentic-AI-Pfad. Hier geht es nur um die Vorentscheidungen: wer ausführt, wie Werkzeuge zugeschnitten sind und ob eine Schleife überhaupt gerechtfertigt ist.

Ein Modell gehört nur dann in die Steuerung, wenn der Pfad sprachlich oder situativ offen ist. Ist die Reihenfolge bekannt und sind Bedingungen explizit, ist ein deterministischer Workflow leichter zu testen und zu betreiben. Ein LLM kann innerhalb eines festen Schritts trotzdem Text klassifizieren oder formulieren. Diese begrenzte Nichtdeterministik ist oft der bessere Ausgangspunkt als ein vollständiger Agent.

Feste Reihenfolge, bekannte Bedingungen

Workflow oder State Machine

Offene Recherche mit variabler Zahl lesender Schritte

Agentischer Loop mit Budget und Abbruch

Schreibende Wirkung mit hohem Schaden

Fester Freigabepfad; Modell höchstens als Vorschlagsgeber

Ein Entscheidungsbaum vor dem Agenten spart Sicherheitsarbeit: Kann der Pfad als endliche State Machine beschrieben werden, implementiere ihn explizit. Braucht nur ein Schritt Sprachverständnis, kapsle dort den Modellaufruf. Erst wenn Zahl und Art der nächsten Schritte wirklich offen sind, rechtfertigt sich ein Loop. Nachteil: Der feste Flow muss bei neuen Fällen per Code erweitert werden; er bietet dafür bekannte Zustände und Testpfade.

Tool-Schemas sind Sicherheits- und Qualitätsgrenzen

Ein Tool-Schema beschreibt nicht nur Syntax. Namen, Beschreibungen, Pflichtfelder und Enums beeinflussen, wann und wie das Modell ein Werkzeug auswählt. Der Host validiert Argumente trotzdem unabhängig. Freitextfelder sollten nicht mehr Ausdrucksmacht besitzen als fachlich nötig; eine Aktion mit drei erlaubten Zuständen bekommt ein Enum statt eines Shell- oder SQL-Fragments.

MCP definiert für Tools unter anderem name, description, inputSchema und optional outputSchema. Annotationen wie readOnlyHint sind laut Spezifikation Hinweise und dürfen von Clients nicht als vertrauenswürdige Policy behandelt werden. Preis eines engen Schemas: Neue Fälle brauchen eine Schema- oder Tool-Version. Der Gewinn ist, dass ungültige Wirkung vor dem Zielsystem sichtbar wird.

Schema-Versionen werden mit Client und Server ausgehandelt oder fest gekoppelt. Ein Tool darf nicht still ein Pflichtfeld umdeuten, weil alte Agententraces sonst anders wirken. Backward-Kompatibilität, Deprecation und Contract-Tests sind klassische API-Arbeit und bleiben auch bei modellgesteuerter Auswahl notwendig. Nachteil: Versionierung verlangsamt spontane Tooländerungen; sie verhindert unbemerkte semantische Brüche.

Budgets und Abbruchbedingungen

Jeder Loop braucht Grenzen für Schritte, Laufzeit, Token, Kosten und wiederholte Fehler. Eine Abbruchbedingung ist fachlich: Ziel erreicht, keine neue Information, unveränderter Fehler, fehlende Berechtigung oder menschliche Entscheidung erforderlich. Ein bloßes Maximum verhindert Endlosschleifen, erklärt aber nicht, welches Ergebnis dem Nutzer zurückgegeben wird.

• max_steps begrenzt die Zahl der Modell- und Tool-Runden.
• Per-Tool-Timeouts verhindern, dass ein hängender Dienst den ganzen Loop blockiert.
• Ein Wiederholungszähler stoppt identische Aufrufe ohne Zustandsfortschritt.
• Ein Kostenbudget bricht vor einer unvertretbaren Rechnung ab.
• Eine Eskalation übergibt Trace, bisherigen Zustand und offenen Entscheidungsgrund.

Budgets sollten verschachtelt sein: pro Schritt, pro Aufgabe, pro Nutzer und pro Zeitraum. Ein einzelner Request kann innerhalb seines Limits liegen und durch tausend parallele Sessions trotzdem unvertretbare Kosten oder Last erzeugen. Rate Limits, Concurrency-Limits und Quoten liegen außerhalb des Modellkontexts. Nachteil: Harte Quoten können legitime Spitzen blockieren; sie schaffen jedoch einen planbaren Blast Radius und einen expliziten Eskalationsweg.

Beobachtbarkeit und Wiederaufnahme

Ein agentischer Trace braucht mehr als Chattext: Modell- und Promptversion, Schritt, ausgewähltes Tool, validierte Argumente, Autorisierungsentscheidung, Zielantwort, Dauer, Retry-Grund und resultierende Zustandsänderung. Geheimnisse und unnötige personenbezogene Daten gehören nicht in dieses Log. Mit dieser Struktur lässt sich unterscheiden, ob das Modell falsch plante, die Policy ablehnte oder das Zielsystem fehlschlug.

Für Wiederaufnahme speichert die Anwendung einen expliziten Workflowzustand. Eine vollständige Chat-Historie ist kein verlässlicher Transaktionslog. Nach einem Prozessabbruch wird zuerst der reale Zielzustand gelesen, bevor eine schreibende Aktion wiederholt wird. Nachteil: Persistenter Zustand und Korrelation-IDs erhöhen Plattformaufwand; sie sind der Preis für nachvollziehbare Wirkung.

Vom lesenden Assistenten zur begrenzten Aktion

Gleich im Check entscheidest du acht Achsen: Wer wirklich ausführt, wann ein fester Flow reicht, wie untrusted Tool-Ergebnisse behandelt werden, welche Rechte ein schreibendes Werkzeug bekommt und wie Schema, Idempotenz, Budget und Eskalation zusammenspielen.

Bei einem Crash gilt die reale Welt als Quelle der Wahrheit. Der gespeicherte Agentenplan kann veraltet sein, weil ein Tool die Wirkung ausgeführt hat, bevor die Antwort verloren ging. Lies den Zielzustand, gleiche Idempotency-Key und erwartete Version ab und entscheide erst dann über Wiederholung. Preis: Kompensations- und Wiederaufnahmelogik nähert sich klassischem Workflow-Engineering. Genau das ist der Punkt: Sobald ein Agent wirkt, gelten die alten Regeln verteilter Systeme weiterhin.

Was der Check prüft

• Die Ausführungsverantwortung korrekt verorten — Anwendung, nicht Modell.
• Erkennen, wann ein deterministischer Ablauf statt einer Modellschleife die Antwort ist.
• Schreibende Werkzeuge mit Bestätigung, Idempotenz und engem Zuschnitt versehen.
• Werkzeugausgaben als potenziell fremdbestimmte Eingabe behandeln.

Vor der Freigabe wird der gesamte Trace mit absichtlichen Fehlern getestet: Timeout nach ausgeführtem Write, manipuliertes Tool-Ergebnis, fehlende Berechtigung, unbekanntes Schemafeld und ausgeschöpftes Budget. Der erwartete Ausgang ist jeweils eindeutig und sicher. Nachteil: Sequenztests sind teurer als einzelne Promptfälle; sie prüfen den realen agentischen Risikoraum.

Nach jedem Test wird nicht nur Erfolg oder Fehler gespeichert, sondern der letzte sichere Zustand. Damit kann der Betrieb erklären, welche Wirkung bereits eingetreten ist und welcher Schritt offen bleibt. Ein Agent, der nur einen flüssigen Abschlussbericht liefert, aber keinen autoritativen Zustandsnachweis besitzt, ist nicht wiederaufnehmbar. Nachteil: Zustandsmodelle und Korrelation-IDs kosten Entwicklungszeit; sie sind der Preis dafür, dass ein Tool-Loop wie ein Produktionsworkflow statt wie ein Chat behandelt werden kann.

Gleich im Check wird daher nicht das sprachlich klügste Agentenverhalten belohnt, sondern die kleinste verteidigbare Ausführungsgrenze mit sichtbarem Nachteil.

Der sichere Ausgang, der autoritative Zielzustand und die verantwortliche Identität müssen nach jedem Schritt ohne Interpretation durch das Modell feststehen.

Damit bleibt auch nach einem Abbruch eindeutig, wer welche reale Wirkung ausgelöst oder verhindert hat.