Wenn du im Foundations-Exam über Tools sprichst, geht es nicht um „kann der Agent irgendeine API callen?“, sondern um Systemverhalten unter Realbedingungen: Wiederholte Aufrufe, fehlerhafte Inputs, instabile externe Services, und Menschen, die Ergebnisse nachvollziehen müssen. Gute Tool-Design-Prinzipien reduzieren genau dort Risiko.
Das erste Kernprinzip ist Idempotenz. Ein idempotentes Tool produziert bei wiederholtem Aufruf mit denselben Parametern denselben fachlichen Endzustand. Warum ist das prüfungsrelevant? Weil Agents oft Retries machen (timeout, transient error, network jitter). Ohne Idempotenz kann ein Retry doppelte Rechnungen erzeugen, mehrere Tickets eröffnen oder denselben Datensatz mehrfach schreiben. In einer Exam-Situation solltest du klar argumentieren: „Wenn ein Tool write-Operationen ausführt, brauche ich entweder natürliche Idempotenz (z. B. upsert by unique key) oder einen deduplizierenden request_id/idempotency_key.“ Das zeigt Architekturverständnis statt nur Prompt-Wissen.
Das zweite Prinzip sind typed inputs. Ein Tool mit freiem String-Input („mach irgendwas mit dieser Nachricht“) lädt zu Fehlinterpretationen ein. Ein Tool mit explizitem Schema (z. B. `customer_id: string`, `amount_cents: integer`, `currency: enum`, `reason: string`) erzwingt Klarheit vor Ausführung. Für agentische Systeme hat das zwei Vorteile: Erstens kann der Agent vorab validieren und bei Schemafehlern nachfragen statt blind zu raten. Zweitens wird Verhalten testbar, weil Input-Varianten systematisch geprüft werden können. Im Exam ist das häufig der Unterschied zwischen „funktioniert im Demo-Case“ und „produktionsfähig“. Wenn du eine Tool-Schnittstelle beschreibst, nenne immer Datentypen, Pflichtfelder, Constraints und Defaults.
Das dritte Prinzip sind klare Fehler. Viele Teams liefern bei Problemen nur „500 Internal Error“. Für einen Agenten ist das kaum verwertbar. Gute Tools geben strukturierte Fehler zurück: Fehlercode, Ursache, Retry-Empfehlung und ggf. user-safe Message. Beispiel: `RATE_LIMITED` (retryable, wait 30s), `VALIDATION_FAILED` (nicht retryen, Input korrigieren), `UNAUTHORIZED_SCOPE` (Escalation/Human Approval nötig). So kann der Orchestrator entscheiden: nochmal versuchen, umplanen, oder an einen Menschen übergeben. Genau dieses Entscheidungsdenken wird in Foundations abgefragt.
Ein praktisches Designmuster ist: Validate → Execute → Return structured result. Das Tool validiert Input strikt, führt atomar aus (oder rollt bei Teilfehlern zurück), und liefert dann eine klar typisierte Antwort inkl. Metadaten (`status`, `resource_id`, `warnings`, `error_class`). Damit kann der Agent robust weiterarbeiten, ohne auf implizite Annahmen angewiesen zu sein.
Merksatz für die Prüfung: Tools sind keine „Fähigkeiten“, sondern Verträge. Je präziser der Vertrag (Input, Nebenwirkungen, Fehlersemantik), desto sicherer und günstiger läuft das Gesamtsystem.
1. Idempotenz ist Retry-Sicherheit: Wiederholte Calls dürfen keinen doppelten fachlichen Schaden erzeugen.
2. Typed Inputs sind Kontrollpunkte: Schema-first verhindert Ambiguität und verbessert Testbarkeit.
3. Klare Fehler steuern Orchestrierung: Strukturierte Fehlercodes ermöglichen korrektes Retry, Handoff oder Abbruch.
Du designst ein Tool `create_refund` für ein agentisches Support-System. Welche drei Änderungen machen das Tool am stärksten production-ready: (A) längere Prompt-Instruktion, (B) idempotency_key, (C) freier Textinput, (D) JSON-Schema mit Constraints, (E) strukturierte Fehlercodes mit Retry-Hinweis?
Richtig sind B, D und E. Idempotency-Keys verhindern doppelte Refunds bei Retries, ein JSON-Schema reduziert fehlerhafte oder unvollständige Eingaben, und strukturierte Fehlercodes ermöglichen dem Agenten saubere Folgeentscheidungen. Eine längere Prompt-Instruktion ersetzt keine robuste Tool-Schnittstelle.