Erklärung der Werkzeugaufrufe: Wie Modelle Software dazu bringen, Aktionen auszuführen, und wo es zu Fehlern kommt.
Eine praktische Einführung in die Funktionsaufrufe und Werkzeugnutzung: Der Anfragenzyklus, Schemata, Lesewerkzeuge gegenüber Aktionswerkzeugen, Agenten, MCP, Prompt-Injektion, Tracing sowie häufige Fehler.
Quellen: Function Calling and Tool Use: How AI Agents Automate Workflows
Frühe Chatbots waren Maschinen zum Beantworten von Fragen. Eine Person tippte etwas ein, es kam eine Antwort zurück, und der Austausch endete dort. Nützlich, aber eingeschränkt. Ein Modell konnte beschreiben, wie man einen Flug bucht, ohne die aktuellen Preise abrufen zu können. Es konnte erklären, was auf einer Rechnung steht, doch nie eine solche im Rechnungssystem erstellen. Es konnte einen Treffzeitvorschlag machen, ohne jedoch in die Kalender anderer Personen schauen zu können, geschweige denn die Veranstaltung dort hinzufügen.
Funktionsaufrufe beseitigen diese Grenze. Ein Sprachmodell erhält die Möglichkeit, die umgebende Software um Hilfe zu bitten, und der Rest des Systems entwickelt sich aus dieser einen Fähigkeit weiter.
Ein Modell, das um Dinge bitten kann
Ohne Werkzeuge antwortet ein Modell auf der Grundlage dessen, was es während des Trainings aufgenommen hat. Mit Werkzeugen kann es feststellen, dass eine Frage externe Hilfe erfordert, und angeben, welches Werkzeug diese liefern sollte: ein Wetterdienst, ein Suchindex, eine Datenbankabfrage, ein Rechner, ein Kalender, ein Zahlungsablauf, eine CRM-Suche, ein Codeinterpreter oder eine interne Geschäftsfunktion. Anstatt zu raten, sendet das Modell eine strukturierte Anfrage, die Anwendung erfüllt sie, und das Modell setzt seine Arbeit mit aktuelleren und genaueren Informationen fort. Die großen Anbieter wie OpenAI, Anthropic und Google sowie Frameworks wie LangChain beschreiben die Nutzung von Werkzeugen auf ähnliche Weise: Dem Modell werden gut definierte Werkzeuge zur Verfügung gestellt, es entscheidet, wann sie aufgerufen werden sollen, übermittelt strukturierte Argumente und integriert die zurückgegebenen Ergebnisse in seine Antwort oder Aktion.
Eine nützliche Vorstellung: Das Modell ist das „Gesprächsgehirn“, und die Tools sind die Hände, Augen, das Gedächtnis, die Recheneinheit, der Aktenschrank und der Lieferwagen. Das Gehirn ermittelt, was der Benutzer möchte. Die Tools erledigen die Aufgaben, die eine reine Textgenerierung nicht sicher oder zuverlässig ausführen kann.
Funktion aufrufen versus Tool aufrufen
Beide Begriffe werden austauschbar verwendet, wobei der zweite genauer ist, da die Idee über klassische Programmierfunktionen hinausgeht. Ein Tool kann so einfach sein wie get_weather(location). Es kann genauso gut eine Datenbanksuche, eine Browser-Sitzung, die Abrufung eines Dokuments, eine Recheneinheit, ein Shell-Befehl, ein Designprozess oder ein Link zu einem externen Service sein. In OpenAI’s Begrifflichkeiten ist ein Tool eine Fähigkeit, die dem Modell zur Verfügung gestellt wird, und ein Tool-Aufruf ist eine spezielle Art von Modellantwort, bei der darum gebeten wird, eines dieser Tools zu verwenden.
Wichtig ist, dass das Modell normalerweise nichts selbst ausführt. Im üblichen Client-seitigen Ansatz gibt es eine strukturierte Anfrage zurück, ähnlich einem Aufruf von get_customer_profile mit einer customer_id von 12345. Die Anwendung empfängt diese Anfrage, prüft sie, führt die eigentliche Funktion aus, sammelt die Ausgabe ein und gibt sie an das Modell zurück, welches anschließend seine endgültige Antwort erstellt. Die dokumentierte Abfolge lautet: verfügbare Tools bereitstellen, einen Tool-Aufruf erhalten, den Code in der eigenen Anwendung ausführen, das Ergebnis senden und entweder eine endgültige Antwort oder weitere Tool-Aufrufe erhalten.
Es gibt Ausnahmen. Einige Anbieter bieten außerdem Server-seitige Tools an, die auf ihrer Infrastruktur laufen. Anthropic trennt diese beiden Ansätze klar voneinander: Client-Tools werden von Ihrer Anwendung ausgeführt und als strukturierte Tool-Nutzungsblokke dargestellt, während Server-Tools wie Web-Suche oder Code-Ausführung auf Seiten von Anthropic laufen können.
Der Unterschied ist von Bedeutung. Wenn gesagt wird „das Modell ruft eine API auf“, kann das bedeuten, dass das Modell eine Anfrage zur Ausführung durch Ihre Software erzeugt hat, oder es kann bedeuten, dass die Plattform im Auftrag des Modells ein integriertes Tool ausgeführt hat. In der Produktion ändert sich dadurch die Sicherheitsarchitektur, die Protokollierung, die Kosten, die Art und Weise, wie mit Daten umgegangen wird, wer was genehmigt und wer für Fehler verantwortlich ist.
Der Kreislauf in fünf Schritten
Die meisten Systeme zur Funktionsaufrufung wiederholen einen Zyklus.
- Definieren Sie die Tools. Jedes Tool erhält einen Namen, eine Beschreibung sowie eine Liste der erwarteten Eingaben. Ein Wetter-Tool benötigt möglicherweise eine Stadt und ein Land. Ein Rückerstattungs-Tool benötigt möglicherweise eine Bestellnummer, einen Grund sowie einen maximalen Betrag. Ein Terminplanungs-Tool benötigt möglicherweise Teilnehmer, ein Datum, eine Uhrzeit und ein Thema. Die Beispiele von OpenAI beschreiben die Parameter im Stil eines JSON Schemas mit erforderlichen Feldern und Einschränkungen wie additionalProperties auf false gesetzt, während die Dokumentation von Googles Gemini Funktionserklärungen zeigt, die aus Namen, Beschreibungen und Eingabestrukturen erstellt werden.
- Der Benutzer bittet um etwas. Das Modell liest die Anfrage und prüft, ob es sofort antworten kann. „Erklären Sie, was eine Funktionsaufruf ist“ benötigt vermutlich kein Tool. „Wie ist der Status der Bestellung 8472?“ benötigt fast sicher eines.
Der Zyklus kann einmal ablaufen oder mehrfach wiederholt werden. Ein Agent kann suchen, Ergebnisse vergleichen, ein anderes Tool aufrufen, nachfragen, eine Eintragung aktualisieren und schließlich zusammenfassen, was er getan hat.
Sprache als Schnittstelle
Der eigentliche Vorteil der Nutzung von Tools besteht darin, dass die Alltagssprache zu einer flexiblen Benutzeroberfläche für Software wird.
Traditionell benötigt jede Funktion eigene Schaltflächen, Formulare, Menüs und Abläufe. Durch Funktionsaufrufe kann ein Benutzer seine Absicht direkt angeben: den neuesten Acme-Rechnungsentwurf finden, prüfen, ob die Zahlung eingegangen ist, und falls nicht, eine höfliche Erinnerungse-Mail schreiben. Ein einziger Satz verbirgt mehrere Tools dahinter: eine CRM-Suche, das Abrufen einer Rechnung, die Überprüfung des Zahlungszustands, das Erstellen eines E-Mail-Vorlagenentwurfs und möglicherweise eine Freigabeanfrage, bevor etwas gesendet wird.
Gutes Produktdesign ist keine Option. Was sich ändert, ist der Punkt, an dem die Benutzeroberfläche beginnt. Anstatt die Nutzer dazu zu bringen, die Struktur der Software zu lernen, passt sich die Software an die Art und Weise an, wie die Menschen bereits über ihre Arbeit sprechen.
Dadurch kommt viel Bedeutung auf die Beschreibungen der Tools zu. Eine vage Beschreibung lässt das Modell unsicher, wie das Tool verwendet werden soll. Eine klare Beschreibung gibt an, wann es eingesetzt werden sollte, was es tut, was jede Eingabe bedeutet und was nicht vorausgesetzt werden darf. Die Dokumentation von LangChain stellt Tools als Funktionen mit klar definierten Eingaben und Ausgaben dar und weist darauf hin, dass Typhinweise sowie kurze Beschreibungen dem Modell helfen, sie richtig zu verwenden.
Ein gutes Tool ist mehr als nur eine Funktion – es ist ein Vertrag.
Vier Begriffe, die sich überschneiden
Die Menschen vermischen diese Begriffe, obwohl sie sich auf unterschiedlichen Ebenen befinden.
- Funktionsaufruf ist das Mechanismus: Das Modell bittet um einen strukturierten Funktions- oder Werkzeugaufruf.
- Werkzeugnutzung ist die umfassendere Fähigkeit. Sie umfasst Funktionsaufrufe, eingebaute Werkzeuge, Web-Suche, Dateisuche, Codeausführung, Computersteuerung, entfernte Server sowie alle anderen Möglichkeiten, wie ein Modell auf externe Systeme zugreifen kann.
- Ein Agent ist ein System, das die Werkzeugnutzung in mehreren Schritten zu einem Ziel kombiniert. OpenAI beschreibt Agenten als Anwendungen, die planen, Werkzeuge nutzen, mit Spezialisten zusammenarbeiten und Fortschritt bei mehrschrittigen Aufgaben verfolgen; dessen Agents SDK definiert einen Agenten als ein LLM, das mit Anweisungen, Werkzeugen sowie optionalen Elementen wie Übergaben, Schutzmaßnahmen und strukturierten Ausgaben konfiguriert ist.
Anders ausgedrückt: Funktionsaufrufe sind die Anschlüsse, Tools sind die darin eingesteckten Geräte, Agents entscheiden, wie und wann sie verwendet werden, und die Automatisierung sorgt dafür, dass alles als Teil eines lebendigen Systems funktioniert.
Warum sich die Mühe machen?
Sprachmodelle sind gut darin, Informationen zu verstehen, zu kombinieren und zu kommunizieren. Sie eignen sich jedoch nicht als Ersatz für Rechner, Datenbanken oder Live-Überwachungssysteme. Sie können über das Wetter schreiben, kennen aber die heutige Wettervorhersage nur, wenn sie mit diesen Daten verbunden sind. Sie können über Rechnungen sprechen, können aber auf Ihr Buchungssystem zugreifen, nur wenn dieses verbunden ist. Sie können Code erklären, können aber ohne Überwachungsdaten nicht feststellen, ob Ihr Service ausgefallen ist.
Tools schließen diese Lücken. Ein Rechner sorgt für zuverlässige Arithmetik. Suchfunktionen liefern aktuelle Fakten. Dokumentenabruffunktionen stützen Antworten auf private Dokumente. Datenbank-Tools beantworten Fragen zu Unternehmensdaten. Workflow-Tools erstellen Tickets, senden Nachrichten, aktualisieren Bestellungen oder buchen Termine. In Googles Gemini-Dokumentation werden die Vorteile auf drei Punkte zusammengefasst: Wissen hinzufügen, Fähigkeiten erweitern und über externe Systeme handeln.
An diesem Punkt wirkt die Erfahrung nicht mehr wie ein Chat, sondern eher wie Software. Das Modell erzeugt nicht länger nur Wörter; es hilft dabei, Arbeiten zu koordinieren.
Forschung hinter der Idee
Werkzeugnutzende Agenten sind nicht aus heiterem Himmel entstanden. Vier frühere Forschungsarbeiten haben diesen Bereich geprägt.
- MRKL Systems (2022) schlug ein modulares Design vor, das Sprachmodelle mit externen Wissens- und Schlussfolgerungsmodulen verbindet. Die Kernidee war einfach: Lassen Sie kein einziges Modell alles erledigen; übertragen Sie jede Aufgabe auf eine spezialisierte Komponente.
- ReAct (2022) untersuchte, wie Modelle Schlussfolgerungen mit Handlungen verknüpfen können. Anstatt nur zu denken oder nur zu handeln, führt ein ReAct-basiertes Prompting dazu, dass das Modell schlussfolgert, handelt, das Ergebnis beobachtet und seinen Plan anpasst. Dieser Kreislauf verbessert die Leistung bei Fragen beantworten und Entscheidungsaufgaben und macht das Verhalten leichter nachvollziehbar.
- Toolformer (2023) prüfte, ob ein Modell sich selbst durch einfache APIs dazu bringen lassen kann, Tools zu verwenden. Es lernte, wann ein Tool sinnvoll ist, was gesendet werden soll und wie die Ausgabe genutzt werden kann, wobei Taschenrechner, Suchmaschinen, Übersetzer und Kalender als Beispiele dienten.
- Gorilla (2023) befasste sich mit großangelegten API-Aufrufen und einem praktischen Problem: Angesichts der vielen verfügbaren Tools erfinden Modelle manchmal falsche Aufrufe oder liefern falsche Argumente. Gorilla kombinierte Training mit Informationsabruf, sodass das System sich ändernde API-Dokumentationen verfolgen und weniger Fehler machen konnte.
Alles läuft auf eine Idee hinaus: Die besten KI-Systeme sind keine isolierten Modelle. Sie sind Teil größerer Systeme, die mit Tools, Speicher, Regeln, Software und menschlicher Überwachung verbunden sind.
Wie ein gutes Tool aussieht
Starke Tools sind spezifisch, verständlich und sicher.
Spezifische Tools sind für Modelle leichter zu wählen und für Entwickler leichter zu steuern. Ein Tool namens update_everything ist vage und gefährlich. create_refund_request ist klarer. approve_refund erfordert sogar noch mehr Vorsicht, da es die reale Welt verändert.
Verständliche Tools haben einfache Namen und Beschreibungen. Ein Modell sollte nicht raten müssen, ob fetch_record bedeutet, ein Kundenprofil abzurufen, eine Datei herunterzuladen oder ein medizinisches Dokument zu holen. Die Beschreibung sollte den Zweck des Tools, die Situationen, in denen es benötigt wird, die Bedeutung jeder Argumente sowie die Struktur des Rückgabewerts angeben.
Sichere Tools verfügen über eingebaute Beschränkungen. Sie überprüfen Berechtigungen, validieren Eingaben und vermeiden die Gewährung von Zugriffen, die nicht erforderlich sind. Sie melden klare Fehler, führen Protokolle und bitten um menschliche Genehmigung vor sensiblen Aktionen. Sie gewähren dem Modell niemals mehr Befugnisse, als die Aufgabe erfordert.
OpenAI empfiehlt strenge Schemata, damit Argumente zuverlässig übermittelt werden können, und sein Agents SDK weist Entwickler darauf hin, dass bei wachsenden Workflows Schutzmechanismen, menschliche Überprüfung, klare Ergebnisse, Zustandsverwaltung und Überwachungsfunktionen wichtig sind. In der Praxis sind die besten Tools langweilig: Jedes erledigt eine Aufgabe gut und überrascht weder Entwickler noch Nutzer.
Schemata als Grammatik
Ein Schema ist die Grammatik der Toolnutzung. Wenn das Modell eine Funktion aufruft, muss es Argumente in einer vom Anwendungsprogramm verständlichen Form liefern. Das Schema legt fest, welche Felder vorhanden sind, welche Typen sie haben, welche erforderlich sind und manchmal auch, welche Werte zulässig sind. Ein Wettertool könnte beispielsweise eine Standortangabe als Zeichenkette sowie ein Feld für die Temperaturangabe verlangen, das auf Celsius oder Fahrenheit beschränkt ist.
Strikte Schemata beseitigen Unklarheiten und vereinfachen die Validierung. In der Dokumentation von OpenAI wird erklärt, dass der strenge Modus sicherstellt, dass die Aufrufe dem deklarierten Schema entsprechen, und dabei Anforderungen wie „additionalProperties“ auf „false“ setzen muss, wenn jedes Feld als erforderlich markiert ist, wobei nutzlose Typen zur Darstellung optionaler Werte verwendet werden.
Ein Schema macht ein System jedoch nicht sicher. Eine fehlerfrei formatierte Anfrage kann dennoch schlecht sein. Ein Aufruf „send_email“ an all_customers@example.com mag das Schema perfekt erfüllen, ist aber dennoch eine schreckliche Idee. Daher muss die Schemavvalidierung zusammen mit Geschäftsregeln, Autorisierungen, Rate Limits, Überprüfungsverfahren und Überwachung eingesetzt werden.
Lesen versus Handeln
Eine wichtige Gestaltungsentscheidung ist, ob ein Tool nur liest oder auch handelt.
Lesereine Tools holen Informationen ab: Dokumente durchsuchen, Einträge abrufen, Lagerbestände überprüfen, Wetterdaten abrufen, Gesamtbeträge berechnen, Protokolle inspizieren. Sie können dennoch sensible Daten freigeben und benötigen eine Zugriffskontrolle, ändern aber in der Regel nichts.
Aktionswerkzeuge erledigen Aufgaben. Sie senden E-Mails, stellen Bestellungen auf, kündigen Abonnements, leisten Rückerstattungen, aktualisieren Datenbanken, eröffnen Tickets, verteilen Code oder planen Meetings. Fehler mit ihnen haben ernste Folgen.
Ein gut konstruierter Agent behandelt diese beiden Arten unterschiedlich. Lesereine Tools können zwar freier genutzt werden, bleiben aber weiterhin unterliegen Zugriffskontrollen. Aktionswerkzeuge erfordern in der Regel strengere Kontrollmechanismen: Bestätigungsseiten, Genehmigungsverfahren, Transaktionslimits, Prüfprotokolle, Rollback-Möglichkeiten sowie klare Benachrichtigungen an den Benutzer.
Zu diesem Zeitpunkt wird die Automatisierung zu einer Managementfrage und nicht nur zu einer technischen. Es geht nicht darum, ob das Modell die Funktion aufrufen kann, sondern unter welchen Bedingungen einem System erlaubt werden sollte, eine Aktion im Namen einer Person auszuführen.
Von einzelnen Aufrufen zu Agenten
Ein einziger Tool-Aufruf kann eine einfache Frage beantworten. Agenten dienen für längere, komplexere Aufgaben. Wenn ein Agent beauftragt wird, eine wöchentliche Verkaufsübersicht zu erstellen und Konten zu markieren, die Aufmerksamkeit benötigen, muss er möglicherweise Verkaufsdaten abrufen, sie mit früheren Wochen vergleichen, ungewöhnliche Muster erkennen, CRM-Hinweise lesen, die Übersicht schreiben und sie an einen Manager senden. Das ist eine Kette von Entscheidungen, kein einziger Aufruf.
Agent-Frameworks verwalten die gesamte Kette. Sie speichern den Zustand, führen Tools aus, versuchen fehlgeschlagene Schritte erneut, leiten Aufgaben an spezialisierte Agenten weiter, erzeugen strukturierte Ausgaben, setzen Sicherheitsregeln durch und führen Protokolle. Die Dokumentation zum Agents SDK von OpenAI beschreibt zwei gängige Ansätze: ein Manager-Muster, bei dem ein zentraler Agent spezialisierte Agenten wie Tools aufruft, sowie Übertragungen, bei denen ein Agent die Kontrolle an einen Spezialisten abgibt.
Ja, sie sind leistungsstark – aber nicht etwas, was idealisiert werden sollte. Ein Agent ist kein kleiner Mitarbeiter, der in Ihrer Software lebt. Es handelt sich um ein probabilistisches System, das aus Code aufgebaut ist, und es benötigt definierte Verantwortlichkeiten, eingeschränkte Berechtigungen, Testfälle, Überwachung, Eskalationswege sowie Pläne für Fehlschläge. Je mehr Freiheit ein Agent erhält, desto sorgfältiger muss die darum herum entwickelte Ingenieursarbeit sein.
Wo Automatisierung auf echte Arbeit trifft
Automatisierung ist der Punkt, an dem der Einsatz von Tools in operative Abläufe übergeht.
- Ein Support-Team kann einen Mitarbeiter einsetzen, um Tickets zu kategorisieren, relevante Richtliniedokumente abzurufen, Antworten zu entwerfen und weitere Schritte vorzuschlagen.
- Ein Finanzteam kann Rechnungen abgleichen, fehlende Bestellaufträge finden und Ausnahmberichte erstellen.
- Ein Engineering-Team kann fehlerhafte Tests überprüfen, Logs durchsuchen, Lösungen vorschlagen und Pull-Requests öffnen.
- Ein Vertriebsteam kann potenzielle Kunden besser auswerten, Notizen zu Telefonaten erstellen und das CRM aktualisieren.
Die effektivste Automatisierung beginnt nicht damit, was das Modell leisten kann, sondern mit einem bereits vorhandenen Arbeitsablauf. Wo beginnt die Arbeit? Welche Informationen sind erforderlich? Welche Entscheidungen sind routinemäßig und welche sensibel? Wo prüfen, genehmigen oder korrigieren Menschen derzeit? Welche Fehler wären ärgerlich und welche teuer?
Mit diesen Antworten in der Hand helfen Tools dabei, den Prozess reibungsloser ablaufen zu lassen. Der Agent sammelt Fakten, füllt Formulare aus, entwirft Nachrichten, vergleicht Aufzeichnungen und gibt Empfehlungen ab, während Menschen weiterhin eingebunden bleiben, wo Urteilsvermögen, Verantwortung oder Vertrauen eine Rolle spielen.
Standardisierte Verbindungen
Frühe Integrationen waren maßgeschneidert. Jede Anwendung hatte ihre eigene Art, Tools, Ressourcen, Anfragen und Authentifizierungsverfahren bereitzustellen. Das funktionierte bei kleinen Projekten, wurde aber unübersichtlich, als Organisationen immer mehr Modelle mit immer mehr Systemen verbanden.
Das Model Context Protocol (MCP) ist ein Versuch, diese Schicht zu standardisieren. Seine Spezifikation beschreibt, wie Anwendungen Kontext teilen, Tools und Funktionen bereitstellen sowie durch eine Anordnung aus Host, Client und Server flexible Integrationen erstellen können. MCP-Server können Ressourcen, Anfragen und Tools anbieten. Das Protokoll tauscht JSON-RPC 2.0-Nachrichten aus und umfasst die Verhandlung von Fähigkeiten, das Tracking des Fortschritts, die Stornierung, das Protokollieren sowie die Fehlerberichterstattung.
Der Vorteil ist offensichtlich: Eine gemeinsame Tool-Schicht ermöglicht es KI-Anwendungen, konsistent mit Datenquellen und Arbeitsabläufen zu verbinden, sodass jedes Unternehmen nicht jede Integration erneut entwickeln muss. Der Nachteil sind neue Risiken. Ein Tool-Server, der leistungsstarke Funktionen bietet, sollte von der Host-App als echte Sicherheitsgrenze betrachtet werden und nicht als weiteres Plugin. Die eigene Spezifikation von MCP betont die Einwilligung der Nutzer, die Datensicherheit, die Sicherheit der Tools sowie die Sorgfalt bei willkürlichem Datenzugriff und Codeausführungswegen.
Sicherheit hat Vorrang
Tools verwendende Agenten sind wertvoll, weil sie handeln – und genau diese Fähigkeit birgt auch Risiken.
Prompt-Injektion ist die bekannteste Bedrohung: feindliche Anweisungen, die in Benutzereingaben oder externen Inhalten versteckt sind und das Modell dazu bringen, Verhaltensweisen an den Tag zu legen, die es vermeiden sollte. OWASP zählt sie zu den größten Risiken für LLM-Anwendungen, und in ihren Materialien für 2025 wird auch das Problem der übermäßigen Handlungsfähigkeit hervorgehoben – dabei hat ein auf LLMs basierendes System mehr Befugnisse, als ratsam ist, wodurch unerwartete, unklare oder manipulierte Ausgaben zu schädlichen Handlungen führen können.
Indirekte Injektion bereitet insbesondere bei Agenten Sorgen. Angenommen, ein Agent liest E-Mails und kann Antworten senden. Ein böswilliger Absender könnte in einer Nachricht eine Zeile verstecken, die dem Agenten vorschreibt, seine Regeln zu ignorieren und die Kontakte des Benutzers weiterzuleiten. Der Benutzer sieht diese Zeile möglicherweise nie, doch das Modell verarbeitet sie dennoch. Wenn das System übermäßig vertrauensvoll und mit zu vielen Berechtigungen ausgestattet ist, kann eine auf den ersten Blick harmlose Nachricht zu einer tatsächlichen Handlung führen.
Sicherheitsteams neigen dazu, LLMs als Systeme zu betrachten, die allein durch die Formulierung getäuscht werden können – und nicht nur durch Codefehler. Das UK National Cyber Security Centre weist darauf hin, dass Prompt-Injection sich von SQL-Injection unterscheidet, da LLMs keine strenge Trennung zwischen Anweisungen und unzuverlässigen Daten vorhalten.
Die geeignete Reaktion ist eine mehrschichtige Verteidigung:
- Beschränken Sie die Berechtigungen der Tools so weit wie möglich.
- Trennen Sie Lesetools von Schreibtools.
- Erfordern Sie Genehmigung vor sensiblen Aktionen.
- Betrachten Sie alles, was abgerufen wird – sei es Webseiten, E-Mails, Dokumente oder Datenbankfelder – als unzuverlässig.
- Überprüfen Sie jeden Argumentwert der Tools und reinigen Sie die Ausgaben, bevor Sie sie an andere Systeme weiterleiten.
- Verwenden Sie Allowlists, protokollieren Sie jeden Toolaufruf und achten Sie auf ungewöhnliche Aktivitäten.
- Testen Sie mit adversarialen Beispielen und entwickeln Sie Möglichkeiten, Aktionen rückgängig zu machen, wo immer möglich.
Geben Sie einem Agenten nur so viel Befugnis, wie der Workflow tatsächlich erfordert.
Was der Agent getan hat
Agentenbasierte Software benötigt noch umfangreichere Aufzeichnungen als herkömmliche Software, denn eine Ausführung kann Modelllogik, Toolaufrufe, Weiterleitungen, Sicherheitsprüfungen, Wiederholungsversuche sowie ein Endresultat umfassen. Das Tracing ermöglicht es Entwicklern, den gesamten Weg von der Anfrage bis zum Ergebnis nachzuvollziehen. Laut der Dokumentation zu OpenAI’s Agents SDK können Traces die Erzeugung von LLMs, Toolaufrufe, Weiterleitungen, Sicherheitsmechanismen sowie benutzerdefinierte Ereignisse erfassen und Teams dabei helfen, Workflows in der Entwicklung und im Produktivbetrieb zu debuggen, zu visualisieren und zu überwachen.
Das ist wichtig für Qualität und Sicherheit. Wenn ein Agent eine falsche Antwort gibt, muss die Ursache gefunden werden. Hat er das falsche Werkzeug gewählt? Hat das Werkzeug veraltete Daten zurückgegeben? Hat das Modell die Beschreibung falsch interpretiert? Ist eine Schutzmaßnahme versagt? Hat der Benutzer keine Berechtigungen? Hat der Agent zu früh aufgehört? Ohne Spuren müssen die Teams raten. Mit guter Beobachtbarkeit wird das Erstellen von Agenten zu einer echten Ingenieurpraxis.
Wie diese Systeme üblicherweise versagen
Fehler sind vorhersehbar. Auf der Seite des Modells kann es das falsche Werkzeug wählen, wenn Namen oder Beschreibungen unklar sind, unvollständige oder falsche Argumente senden, ein Werkzeug aufrufen, obwohl es eine klärende Frage stellen sollte, oder einen Aufruf überspringen, wenn frische Daten benötigt werden. Es kann auch Werkzeuge zu oft aufrufen, was Kosten und Latenz erhöht, in endlosen Schleifen ohne Fortschritt verharren oder dem Ausgangsergebnis eines Werkzeugs mehr Vertrauen schenken, als es verdient.
Auch die Anwendung kann versagen. Sie kann Argumente, die vom Modell bereitgestellt werden, ohne Überprüfung akzeptieren, zu viele Werkzeuge gleichzeitig bereitstellen, riesige, unübersichtliche Ausgaben liefern, die das Modell verwirren, nützliche Fehlermeldungen verschlucken, Ergebnisse fälschlicherweise den jeweiligen Aufrufen zuordnen oder auf Prüfprotokolle, Geschwindigkeitsbeschränkungen und Genehmigungsmechanismen verzichten.
Leichte Anpassungen an den Eingabefragen beheben diese Probleme selten. Die Lösung liegt in einer besseren Konzeption der Werkzeuge, klareren Schemata, strengeren Berechtigungen, einer solideren Handhabung des Zustands, mehr Tests sowie einer besseren Überwachung.
Wann auf Werkzeuge verzichtet werden sollte
Die Aufrufung von Funktionen ist nicht immer notwendig. Wenn eine Aufgabe nur eine Erklärung erfordert, fügt ein Tool nur Komplikationen hinzu. Wenn die benötigten Informationen bereits im Prompt enthalten sind und sich nicht ändern, gibt es nichts zu holen. Bei hochriskanten Aktionen, die nicht sicher überprüft oder rückgängig gemacht werden können, ist vollständige Automatisierung möglicherweise die falsche Wahl. Und wenn die Ausgabe eines Tools unzuverlässig, undokumentiert oder unsicher ist, verstärkt die Verbindung mit einem Agenten das Problem.
Auch die Benutzererfahrung hat ihren Preis. Tool-Aufrufe verursachen Verzögerungen, Berechtigungsanfragen unterbrechen den Ablauf, und komplexe Agenten können unvorhersehbar wirken. Manchmal ist ein einfaches Formular besser als ein Chat-Workflow – besonders dann, wenn die Nutzer genau wissen, was sie wollen, und Geschwindigkeit, Konsistenz oder Konformität benötigen.
Das Ziel ist es nicht, alles agentbasiert zu gestalten. Verwenden Sie ein Tool nur dort, wo Sprache, Kontext und Aktion tatsächlich zusammenpassen.
Gewohnheiten für ein gutes Aufbauen
Beginnen Sie mit einer Handvoll eindeutiger Tools und erweitern Sie den Zugang zum Modell nur schrittweise. Wählen Sie spezifische Funktionen mit klaren Namen aus. Schreiben Sie Beschreibungen für das Modell – nicht nur für Ingenieure. Verwenden Sie möglichst strenge Schemata und validieren Sie die Eingaben stets in Ihrem eigenen Code. Halten Sie die Ausgaben kurz und übergeben Sie dem Modell nur das, was es tatsächlich benötigt.
Legen Sie die Berechtigungen Tool für Tool fest. Ein Support-Mitarbeiter, der den Bestellstatus überprüfen kann, muss nicht automatisch Rückerstattungen ausstellen. Ein Terminplanungs-Assistent benötigt möglicherweise die Kalenderverfügbarkeit, aber nicht private Eventnotizen. Ein Programmier-Assistent sollte in der Lage sein, einen Repository gut zu durchforsten, bevor er Pull Requests erstellen darf.
Verlangen Sie, dass eine Person alles Sensible, Teure, Öffentliche, rechtlich Verbindliche, Finanzielle oder Schwierig zu rückgängig Machende freigibt, und formulieren Sie die Anfrage konkret, damit der Prüfer genau sieht, was geschehen wird.
Verwandte Literatur
- Verwendung von Produktionswerkzeugen für Agenten: Herkunft, Wiederholungsversuche und Beobachtbarkeit — Ein Agent einer Bank rief eine kostenpflichtige API zu oft auf und erfand eine Telefonnummer. Erfahren Sie mehr über minimale Werkzeugsets, die Herkunft von Parametern, dreistufige Wiederholungsversuche sowie Metriken pro Werkzeug.
- Gedächtnissnapschüsse von Agenten, Fähigkeiten, Verfall und Branchenbegrenzung — Vier Erweiterungen für eine eingebettete Vektor-Datenbank-Gedächtnisschicht für Programmieragenten: portable Snapschüsse mit Zusammenführung, Aktivierung von Fähigkeiten, Verfall mit Konfliktprüfungen sowie branchenbasiert begrenztes Gedächtnis.