Tool Calling: Werkzeuge entwerfen, die der Agent richtig nutzt
Wenn ein Agent sich schlecht benimmt, ist der Reflex, den Prompt umzuschreiben. Nach unserer Erfahrung ist der Prompt etwa in einem Drittel der Fälle die Ursache; sonst wurden die Werkzeuge für ein Programm entworfen und nicht für eine Leserin, die aus Namen und Beschreibungen erschließen muss, was eine Funktion tut.
Werkzeuge sind die gesamte Wirkfähigkeit des Agenten, und ihre Definitionen sind buchstäblich Teil des Modellkontexts. Sie gut zu entwerfen ist billiger und haltbarer als Prompt-Tuning, weil ein gutes Werkzeug Verhalten erzwingt statt darum zu bitten.
Sieben Regeln gegen falsche Aufrufe#
- Ein Werkzeug, eine Aufgabe. `search_orders` und `refund_order` schlagen ein `manage_order` mit Modus-Argument.
- Typen statt Prosa. Enums, Wertebereiche und Formate leisten, was eine Beschreibung nie leistet.
- Namen, die sagen, was passiert. `send_email_to_customer` ist eindeutig, `notify` nicht.
- Fehler als Anweisung: was falsch war und was als Nächstes zu tun ist, in einem kurzen Satz.
- Leere Ergebnisse sind Ergebnisse. Ein explizites Kein-Treffer schlägt eine Exception.
- Idempotenzschlüssel auf allem mit Seiteneffekt, damit ein Retry nichts verdoppelt.
- Kleine Rückgaben. Auf die benötigten Felder kürzen; 40 KB JSON kaufen Verwirrung, keinen Kontext.
Vorher und nachher#
| Schwaches Design | Warum es scheitert | Besser |
|---|---|---|
| `query(sql)` | Unbegrenzte Macht, nicht prüfbar | `get_orders_by_customer(customer_id, limit)` |
| `date: string` | Modell erfindet Formate | `date: string, Format YYYY-MM-DD` |
| `HTTP 500` | Impliziert keine Handlung, endlos wiederholt | `Bestellservice nicht erreichbar. Bitte später erneut.` |
| Gibt ganzen Datensatz zurück | Füllt Kontext, verdünnt Aufmerksamkeit | Gibt sechs benannte Felder zurück |
| `update_status(id, status)` | Jeder Status, jeder Datensatz | `cancel_order(id)` mit Rechteprüfung |
Beschreibungen sind Prompt#
Das Beschreibungsfeld ist keine Dokumentation für Kolleginnen, sondern Text, den das Modell beim Entscheiden liest. Sagen Sie, wann das Werkzeug zu nutzen ist und wann nicht, nennen Sie die eine wichtige Vorbedingung und geben Sie ein Beispielargument. Drei Sätze schlagen drei Absätze. Und prüfen Sie alle Beschreibungen gemeinsam in einer Datei: Werkzeuge, die einzeln sinnvoll wirken, überlappen oft erst als Set erkennbar.
Könnten zwei Werkzeuge plausibel dieselbe Anfrage bedienen, wird der Agent manchmal falsch wählen. Zusammenlegen oder die Grenze in beiden Beschreibungen explizit machen.
Immer vor der Ausführung prüfen#
Geben Sie Modellausgaben nie ungeprüft an einen Systemaufruf. Argumente gegen das Schema validieren, Identifikatoren gegen Datensätze auflösen, die dieser Endnutzer sehen darf, und Nichtpassendes ablehnen statt zurechtzubiegen. Eine Ablehnung mit klarer Meldung ist ein gutes Ergebnis: Der Agent lernt die Randbedingung und versucht etwas anderes. Stilles Zurechtbiegen führt dazu, dass der falsche Datensatz aktualisiert wird und es niemand merkt.
Werkzeuge getrennt vom Agenten testen#
Jedes Werkzeug bekommt eigene Tests: gültiger Aufruf, ungültige Argumente, Rechte verweigert, leeres Ergebnis, Timeout. Danach testen Sie den Agenten gegen eine Stub-Schicht, um diese Bedingungen gezielt zu erzwingen. Fast jeder Produktionsvorfall, den wir geprüft haben, reproduziert sich auf dieser Ebene sofort — besonders der leere Treffer, in der Entwicklung selten und an einem echten Dienstagnachmittag Routine.
Häufige Fragen
Wie viele Werkzeuge sind zu viele?
Ab etwa zehn in einer Schleife sinkt die Auswahlgenauigkeit und Beschreibungen verdrängen Kontext. Brauchen Sie mehr, gruppieren Sie hinter einem engen Router oder teilen Sie in spezialisierte Agenten mit kleinen Sets.
Sollen Werkzeuge rohe API-Antworten liefern?
Nein. Geben Sie eine kleine, stabile Form mit den benötigten Feldern zurück. Rohe Antworten verschwenden Kontext, öffnen missbrauchbare Felder und koppeln Ihr Promptverhalten an fremde API-Versionen.
Wie verhindere ich erfundene Argumente?
Durch Einschränkung: Enums statt Freitext, explizite Formate, Identifikatoren, die sich auflösen müssen. Dann validieren und klar ablehnen. Erfundene Argumente zeigen meist, dass das Werkzeug etwas verlangt, das der Agent nicht wissen konnte.
tool callingfunction calling agentenwerkzeug designjson schema toolsllm werkzeugfehler
