Ein Tool-Call kann perfekt gültige strukturierte Daten sein und dennoch die falsche Operation beschreiben. Ein Datum kann das richtige Format haben, aber die falsche Zeitzone. Ein Kundenname kann mehreren Personen entsprechen. Ein leeres Suchergebnis kann bedeuten, dass es keine passenden Datensätze gibt, oder es kann bedeuten, dass die Suche fehlgeschlagen ist.
Wenn ich ein agentenorientiertes Tool entwerfe, betrachte ich diese Unterscheidungen als Teil seines Vertrags. Das Modell muss wissen, was die Eingaben bedeuten, welche Beweise das Ergebnis liefert und welche Unsicherheiten nach dem Aufruf verbleiben.
Verwenden Sie Bezeichner mit einer expliziten Bedeutung
Angenommen, ein Assistent erhält „Überprüfen Sie die Bestellung für Alex.“ Ein Tool, das nur ein Freitextfeld für Kunden akzeptiert, ermutigt dazu, Mehrdeutigkeiten in das Backend zu übertragen. Eine bessere Interaktion löst zuerst die möglichen Konten auf und übergibt dann einen stabilen Identifikator an die Bestellabfrage.
Wenn mehrere Kandidaten verbleiben, sollte das Ergebnis diese Mehrdeutigkeit offenlegen, ohne stillschweigend den ersten auszuwählen. Eine Werkzeugbeschreibung kann die beabsichtigte Reihenfolge erklären, aber das Backend sollte dennoch einen Bezeichner außerhalb des Geltungsbereichs des authentifizierten Kontos ablehnen.
Diese letzte Überprüfung ist notwendig, selbst wenn das Modell der dokumentierten Reihenfolge gefolgt ist. Anweisungen erklären die korrekte Verwendung; Ausführungsregeln bestimmen, was die Anwendung tatsächlich erlaubt.
Dokument fehlend, leere und unbekannte Werte
Ein ausgelassener Filter, ein leerer Filter und ein auf „unbekannt“ gesetzter Filter können unterschiedliche geschäftliche Bedeutungen haben. Zum Beispiel könnte das Auslassen eines Datumsbereichs ein Standardfenster verwenden, während ein leerer Bereich ungültig sein könnte. Die Unterscheidung implizit zu lassen, zwingt das Modell, zu raten.
Ich bevorzuge Verträge, die Standardwerte und Grenzen ausdrücklich angeben. Eine Suchantwort sollte melden, ob sie vollständig ist, ob weitere Seiten existieren und ob eine angeforderte Quelle nicht abgefragt werden konnte. „Keine Ergebnisse“ sollte für eine Suche reserviert sein, die tatsächlich innerhalb ihres angegebenen Umfangs abgeschlossen wurde.
Der Kundenservice-Kontext von Conviro, der Plattform, die ich entwickle, macht dies besonders konkret. Ein Assistent muss in der Lage sein, nicht verfügbare Informationen von Beweisen zu unterscheiden, dass ein Ereignis nie stattgefunden hat. Das sind unterschiedliche Antworten für einen Kunden.
Geben Sie Fehler zurück, die die nächste Entscheidung unterstützen
Ein nützlicher Fehler unterscheidet eine ungültige Anfrage von einem vorübergehenden Serviceproblem, einer Zugangsverweigerung und einem mehrdeutigen Ergebnis. Jede sollte zu einer anderen Handlung führen. Ein erneuter Versuch kann einen Berechtigungsfehler nicht beheben, und den Kunden zu bitten, die Anfrage umzuformulieren, kann einen nicht verfügbaren Dienst nicht reparieren.
Für eine Abfrage würde ich Ergebnisse definieren wie found, not_found, ambiguous und unavailable, zusammen mit einer Ergebnisversion. Die Namen sind illustrativ. Der wichtige Punkt ist, dass der Aufrufer die nächste Entscheidung treffen kann, ohne den Erfolg aus Prosa abzuleiten.
Detaillierte Diagnosen können einem Betreiber zur Verfügung stehen, ohne Anmeldeinformationen, interne Abfragen oder private Aufzeichnungen dem Modell auszusetzen. Ein umsetzbarer Fehler muss nicht jedes Implementierungsdetail enthalten.
Beschreiben Sie die Auswirkungen getrennt von den Vorschlägen.
Ein Werkzeug namens „Bestellung aktualisieren“ verbirgt mehr Ungewissheit als „Lieferadresse ändern vorschlagen“. Wenn ein Werkzeug seinen Zustand ändert, sollte sein Vertrag das Ziel, die Voraussetzungen und das Ergebnis angeben, das die Akzeptanz bestätigt. Eine generierte Vorschau sollte niemals wie ein Beweis aussehen, dass das Update bereits stattgefunden hat.
Ich bespreche diese Ausführungsgrenze weiter in der Trennung der Empfehlung eines Agenten von seinen Nebenwirkungen. Eine präzise Benennung ist nützlich, aber die Unterscheidung muss die gesamte Anfrage und Antwort überstehen.
Versionieren Sie den Vertrag, während das System wächst.
Das Ändern eines Standardwerts oder der Bedeutung eines Ergebnisfeldes kann einen Agenten brechen, selbst wenn seine Eingabe weiterhin gültig ist. Ich würde repräsentative Aufrufe und erwartete Interpretationen beibehalten, einschließlich mehrdeutiger Identitäten und unvollständiger Suchen, als Vertragsbeispiele.
Werkzeugbeschreibungen, Schemata und Laufzeitvalidierung sollten dieselbe Operation beschreiben. Wenn ein Werkzeug eine neue Art von Arbeit unterstützt, überprüfen Sie den Workflow, der entscheidet, wann es aufgerufen wird. Gute Verträge reduzieren das Rätselraten auf beiden Seiten der Modellgrenze und erleichtern die Identifizierung falscher Aufrufe.
Aktualisiert am 30. September 2026.