Agent Tool Calling Best Practices: Warum Ihr Agent das falsche Tool wählt

Agent Tool Calling Best Practices: Warum Ihr Agent das falsche Tool wählt

Agent Tool Calling Best Practices sind der Unterschied zwischen einer funktionierenden Demo und einem Agenten, der in der Produktion unbemerkt das falsche Tool aufruft. Das Engineering-Team von Anthropic hat gemessen, wie eine einzige umgeschriebene Beschreibung ein Tool-Ergebnis von 206 Tokens auf 72 reduzierte, und Claude Code begrenzt inzwischen jede Tool-Antwort hart auf 25.000 Tokens, denn der Token-Verlust ist real. Ihr Agent scheitert auf vier Arten: falsches Tool, falsche Argumente, Endlosschleifen, Token-Verlust. Für jede davon gibt es eine Lösung, die Sie diese Woche noch ausliefern können.

Die wichtigsten Punkte:

• Agent Tool Calling scheitert auf genau vier Arten: falsches Tool, falsche Argumente, Endlosschleifen und Token-Verlust.
• Tool-Beschreibungen sind die einzige Anweisung, die das Modell bei der Auswahl sieht, daher beheben sie die meisten falschen Tool-Aufrufe.
• Flache, auf die Aufgabe zugeschnittene Schemas mit validierten Eingaben beseitigen die meisten Fehler bei Argumenten.
• Kompakte Tool-Antworten und eine Eval-Schleife bei jeder Änderung halten Token-Kosten und Regressionen messbar.

Warum scheitert Agent Tool Calling in der Produktion?

Agent Tool Calling scheitert auf vier Arten: Das Modell wählt das falsche Tool, schreibt falsche Argumente, dreht sich in einer Endlosschleife oder verliert Tokens durch fette Antworten. Jeder Fehler trifft einen anderen Schritt der Aufruf-Schleife, daher zählt die Reihenfolge der Behebung. Beginnen Sie mit der Auswahl, denn eine falsche Tool-Wahl vergiftet jeden Schritt danach.

Die vollständige Verordnung auf einen Blick:

Gehen Sie sie in dieser Reihenfolge durch. Die Praxen 1 und 2 dauern einen Nachmittag und beseitigen die meisten Fehler durch falsche Tools und falsche Argumente, die Sie heute sehen. Eine Tool-Beschreibung ist keine Dokumentation. Sie ist die einzige Anweisung, die das Modell zum Zeitpunkt der Auswahl erhält.

Phase 1: Entwerfen Sie Tools, die das Modell tatsächlich nutzen kann

Die günstigsten Zuverlässigkeitsgewinne beim Agent Tool Calling liegen in Ihren Tool-Definitionen, nicht in Ihren Prompts oder Ihrer Modellwahl. Das Modell liest niemals Ihre API-Docs oder Ihr README. Es sieht einen Namen, einen Beschreibungsstring und ein JSON-Schema und entscheidet allein danach. Wenn diese drei stimmen, verbessert sich die Auswahlgenauigkeit, bevor Sie überhaupt etwas anderes anfassen.

Praxis 1: Schreiben Sie Beschreibungen, mit denen das Modell arbeiten kann

Schreiben Sie Tool-Beschreibungen als Anweisungen an das Modell, nicht als API-Dokumentation. Eine Beschreibung, die einen menschlichen Entwickler zufriedenstellt („REST-Wrapper für den Users-Endpunkt"), gibt dem Modell nichts, worauf es eine Entscheidung stützen kann. Sowohl Anthropics Engineering-Leitfaden zum Schreiben von Tools als auch ihre Best Practices für Tool-Definitionen empfehlen dasselbe Muster: Sagen Sie, wann das Tool zu verwenden ist, was es zurückgibt und wann es NICHT zu verwenden ist.

{
  "name": "get_user",
  "description": "Fetches a user profile. Use ONLY when you already have a user_id. Do NOT use to search or list users; call search_users instead. Returns name, email, plan. Errors if user_id is not a valid UUID."
}

gegenüber der Version, die die meisten Teams ausliefern:

{
  "name": "get_user",
  "description": "Gets a user."
}

Hier erledigen zwei Regeln den Großteil der Arbeit. Benennen Sie erstens Parameter so, dass ihre Bedeutung eindeutig ist: user_id, niemals user oder id, denn user lädt das Modell dazu ein, einen Namen oder eine E-Mail zu übergeben, wo eine UUID hingehört. Sagen Sie zweitens Ausschlüsse explizit. „Do NOT use to search users" verhindert mehr falsche Tool-Aufrufe als jede Menge positiver Beschreibungen, denn Modelle verwechseln überlappende Tools weit häufiger, als sie einzelne, klar abgegrenzte missverstehen. Für die Anbieter-Mechanik dahinter, wie diese Definitionen die APIs von OpenAI, Anthropic und Google erreichen, siehe unser Leitfaden für Function Calling mit mehreren Anbietern.

Praxis 2: Halten Sie Schemas flach und aufgabenförmig

Halten Sie Eingabe-Schemas flach, mit jedem Feld, das die Aufgabe tatsächlich braucht, und keinem, das sie nicht braucht. Verschachtelte Objekte mit optionalen Zweigen sind der Nährboden für Fehler bei Argumenten: Das Modell muss eine Struktur erschließen, für die es nie Beispiele sieht. Der OpenAI-Leitfaden für Function Calling akzeptiert beliebiges JSON Schema, aber großzügig ist nicht dasselbe wie zuverlässig.

{
  "name": "create_ticket",
  "parameters": {
    "type": "object",
    "properties": {
      "ticket": {
        "type": "object",
        "properties": {
          "details": {
            "type": "object",
            "properties": {
              "title": { "type": "string" },
              "meta": { "type": "object" }
            }
          }
        }
      }
    }
  }
}

Vereinfachen Sie es auf die Aufgabe:

{
  "name": "create_ticket",
  "parameters": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "assignee_id": { "type": "string" }
    },
    "required": ["title", "priority"]
  }
}

Enums schlagen Freitext bei jedem Feld mit einer begrenzten Wertemenge. Required-Arrays schlagen optionale Alles. Wenn das Modell ein Feld fast immer braucht, machen Sie es im Tool-Schema erforderlich, selbst wenn Ihre API es als optional bezeichnet. Sie spiegeln nicht Ihre API. Sie entwerfen eine Oberfläche, die ein bestimmtes Modell korrekt ausfüllen kann.

Phase 2: Verwalten Sie das Tool-Set, nicht nur die Tools

Die Qualität einzelner Tools reicht nicht mehr aus, sobald ein Agent mehr als eine Handvoll Tools trägt, denn Auswahlfehler wachsen mit der Größe der Liste, die das Modell liest.

Praxis 3: Bündeln Sie mehrstufige API-Sequenzen zu atomaren Tools

Fassen Sie jede feste Sequenz von API-Aufrufen zu einem atomaren Tool zusammen. Anthropics Engineering-Beitrag verwendet schedule_event und get_customer_context als Vorbild: Ein Aufruf, der die ganze Arbeit erledigt, schlägt drei Aufrufe, die der Agent jedes Mal korrekt verketten muss. Jedes Glied in einer Kette ist eine weitere Runde, in der das Modell stecken bleiben, falsch wiederholen oder in eine Schleife geraten kann.

# What the agent does WITHOUT an atomic tool: 3 calls, 3 chances to fail
calendar = call_tool("list_calendars", {})
free = call_tool("find_free_slot", {"calendar_id": calendar["items"][0]["id"], "duration": 30})
call_tool("create_event", {"calendar_id": calendar["items"][0]["id"], "start": free["start"]})

# One atomic tool: the sequence lives in your code, not the model's head
call_tool("schedule_event", {"duration": 30, "attendees": ["[email protected]"]})

Die Faustregel: Wenn das Modell immer B nach A aufrufen muss, sind A und B ein Tool in zwei Verkleidungen.

Praxis 4: Namespacing, Bereinigung und dynamische Filterung der Tools

Versehen Sie jeden Tool-Namen mit einem Namespace und zeigen Sie jedem Agenten nur die Teilmenge, die seine aktuelle Aufgabe braucht. Generische Namen kollidieren in dem Moment, in dem Sie zwei Integrationen anbinden. Stellen Sie sich einen Agenten vor, der an zwei MCP-Server angebunden ist, die beide ein Tool namens search bereitstellen: zwei identische Verben, keine Möglichkeit, sie zu unterscheiden. Anthropic dokumentiert messbare Eval-Gewinne durch Präfix-Namespacing:

Bereinigung ist genauso wichtig wie Benennung. Ein Support-Agent braucht seine Billing-Tools nicht geladen, während er eine Passwortfrage beantwortet. Das Planner-Worker-Muster, bei dem ein Planner eine Aufgabe an einen Worker routet, der nur die relevanten Tools lädt, ist die Standardlösung; die LangGraph-Anleitung zum dynamischen Laden von Tools zeigt die Implementierung. Wie viele Tools sind zu viele? Behandeln Sie 5-10 pro Agent als Arbeitsbereich, nicht als Gesetz: Die Genauigkeit sinkt, wenn die Liste wächst, und die Lösung ist Filterung, nicht ein größeres Modell. Wenn Sie gerade die Routing- und Filterungsschicht selbst auswählen, vergleichen Sie die Optionen in unserer Übersicht über die besten Function-Calling-Bibliotheken.

Phase 3: Kontrollieren Sie, was zurückkommt und was hinausgeht

Die Schleife läuft in beide Richtungen, und die meisten Teams konstruieren nur die ausgehende Hälfte. Was Ihre Tools zurückgeben, bestimmt, wie viel des Kontextfensters bis zur nächsten Runde überlebt, und was Ihre Validierung ablehnt, bestimmt, ob das Modell aus seinen Fehlern lernt oder sie wiederholt.

Praxis 5: Geben Sie kompakte, signalstarke Ergebnisse zurück

Geben Sie das kleinste Ergebnis zurück, mit dem das Modell arbeiten kann, mit menschenlesbaren Bezeichnern statt roher IDs. Anthropics Engineering-Beitrag dokumentiert ein Tool, dessen Standardergebnis 206 Tokens umfasste; eine kompakte response_format-Einstellung reduzierte dasselbe Ergebnis auf 72 Tokens, etwa ein Drittel der Größe. Multiplizieren Sie das mit Dutzenden von Aufrufen pro Aufgabe, und es entscheidet darüber, ob Ihr Agent überhaupt fertig wird.

// Before: 206 tokens (shape per Anthropic's documented example)
{
  "status": "success",
  "data": {
    "id": "8f14e45f-ceea-3f9c-a2f3-90c1b5e0a7d2",
    "object": "task", "created_at": "2026-07-02T09:14:00Z",
    "updated_at": "2026-07-11T16:40:12Z", "completed_at": null,
    "assignee": {"id": "c9a1...f2", "object": "user"},
    "projects": [{"id": "b7d3...91", "object": "project"}],
    "permalink": "https://app.asana.com/0/.../f"
  }
}

// After: 72 tokens
{ "task": "Fix login redirect", "assignee": "Dana Kim", "project": "Web App", "due": "2026-07-20" }

Zwei weitere Details aus derselben Quelle: Anthropic unterstützt einen response_format-Enum (detailliert versus kompakt) in Tool-Definitionen, sodass Sie die gewünschte Form deklarieren können, statt den Datenstrom zu parsen. Und Claude Code begrenzt Tool-Antworten auf 25.000 Tokens, eine harte Obergrenze, die aufgedunsene Ergebnisse so oder so abschneidet. Anthropic berichtet außerdem als eigenen Befund, dass die Auflösung von UUIDs in semantische Namen Retrieval-Halluzinationen messbar reduzierte, weshalb das „Nachher"-Payload oben „Dana Kim" sagt und nicht c9a1...f2. Fette Antworten sind auch ein Kostenproblem; unser Leitfaden zum Senken der LLM-API-Kosten zeigt das Gesamtbild.

Praxis 6: Validieren Sie jeden Aufruf und lassen Sie Fehler das Modell lehren

Validieren Sie jeden Tool-Aufruf serverseitig und geben Sie Fehler zurück, die die Lösung enthalten. Martin Fowlers Artikel über Function Calling formuliert es unverblümt: Vertrauen Sie niemals der Ausgabe des Modells. Es übergibt Strings, wo Enums hingehören, und erfindet IDs, die nicht existieren.

def create_ticket(args):
    if args.get("priority") not in {"low", "medium", "high"}:
        return {"error": f"priority must be one of: low, medium, high. Got '{args.get('priority')}'. Pass priority='medium' for normal issues."}
    if not is_valid_uuid(args.get("assignee_id")):
        return {"error": "assignee_id must be a UUID. Call list_team_members to get valid IDs, then retry."}
    return db.create_ticket(**args)

Der Fehlerstring ist das ganze Spiel. Vergleichen Sie:

# Unhelpful: the model retries the same bad call
{"error": "invalid input"}

# Helpful: the model knows exactly what to change
{"error": "priority must be one of: low, medium, high. Got 'urgent'. Use 'high'."}

Jeder Validierungsfehler, den Ihr Tool zurückgibt, ist ein Prompt, den Sie für den nächsten Versuch des Modells schreiben. Fehler, die die Einschränkung benennen und auf das korrigierende Tool verweisen, machen aus einer Wiederholungsschleife eine Einmal-Wiederherstellung. Das ist auch Ihre erste Sicherheitslinie; unser LLM-Guardrails-Leitfaden behandelt das in der Tiefe.

Phase 4: Wie machen Sie es sicher und dann messbar?

Sicherheit und Messung sind dieselbe Phase, denn eine nicht abgesicherte destruktive Aktion und eine nicht gemessene Regression treten beide als Vorfälle in Erscheinung, die Sie nicht haben kommen sehen. Sichern Sie die Aktionen ab, die nicht rückgängig gemacht werden können, und instrumentieren Sie dann alles, damit die nächste Tool-Änderung eine Entscheidung mit Belegen dahinter ist, keine Hoffnung.

Praxis 7: Sichern Sie destruktive Aktionen durch einen Menschen ab

Trennen Sie Lese-Tools von Schreib-Tools und setzen Sie eine menschliche Bestätigung vor alles Destruktive. Die Tool-Annotationen der MCP-Spezifikation existieren genau dafür: destructiveHint markiert Tools, die destruktive Aktualisierungen durchführen, und openWorldHint kennzeichnet Tools, die externe Systeme berühren, damit Clients vor der Ausführung nachfragen können. Nutzen Sie sie.

Der Fehlermodus ist nicht hypothetisch. Laurent Kubaski dokumentierte einen Fall, in seinem Tool-Calling-Artikel vom Juli 2025 mit verlinktem Originalbericht, in dem ein Nutzer Copilot in Excel bat, Zeile 4 zu bearbeiten, und der Agent stattdessen Zeile 8 bearbeitete. Zwischen der falschen Zeile und dem Schreibvorgang stand keine Bestätigung. Die Lösung ist das Muster, das AWS für Bedrock Agents dokumentiert: Der Agent bereitet die Aktion vor, gibt sie zur Freigabe zurück und führt sie erst aus, nachdem ein Mensch bestätigt hat. Cursor macht dasselbe für Dateiänderungen. Begrenzen Sie Berechtigungen auf Nur-Lesen, wo Lesen für die Aufgabe genügt, und behandeln Sie Bestätigungs-Gates als Teil Ihrer Injection-Angriffsfläche, das Thema unseres Leitfadens zur Verhinderung von Prompt Injection.

Praxis 8: Führen Sie bei jeder Tool-Änderung eine Eval-Schleife aus

Führen Sie vor und nach jeder Tool-Änderung eine kleine Eval-Suite aus und lesen Sie die Metriken in einer festen Reihenfolge. Der Optimierungsleitfaden von Paragon schlägt einen Vier-Metriken-Rahmen vor, den zu übernehmen sich lohnt:

Anthropics Tool-Evaluation-Cookbook, aufgebaut auf echten Slack- und Asana-MCP-Evals, zeigt, wie gute und schlechte Eval-Aufgaben aussehen:

# Weak: vague, many valid paths, impossible to score
"Use the Asana tools to organize some work."

# Strong: one correct tool, checkable arguments, binary outcome
"Create a task titled 'Renew TLS cert' in project 'Infra' assigned to [email protected], due 2026-08-15. Expect exactly one create_task call with those four fields."

Unsere Interpretation, als solche gekennzeichnet: Die veröffentlichten Zahlen geben Ihnen die Reihenfolge der Arbeit vor. Prüfen Sie zuerst die Tool-Korrektheit, denn Anthropics eigene Messungen zeigen, dass Beschreibungs- und Benennungsänderungen sie direkt bewegen (die Umschreibung von 206 auf 72 Tokens, der UUID-zu-Name-Halluzinationsbefund), und heben Sie sich die Aufgabeneffizienz für zuletzt auf, da sie meist Fehler widerspiegelt, die die ersten drei Metriken bereits eingefangen haben. Entwerfen Sie für die Einstiegs-Suite 15-30 Aufgaben, zwei oder drei pro Tool, jede mit einem einzigen erwarteten Aufruf und einer binären Bestehensbedingung. Diese Größe reicht aus, um eine Regression durch eine Beschreibungs-Umschreibung einzufangen, ohne eine Woche lang zu labeln, und wir lesen das Slack- und Asana-Setup des Cookbooks als Beleg dafür, dass eine so kleine Suite der vorgesehene Einstiegspunkt ist, keine Abkürzung. Die tieferen Mechaniken finden Sie in unserem Leitfaden zum Evaluieren von KI-Agenten in Produktion, und wenn Ihre Eval-Ergebnisse sagen, dass die Tools selbst in Ordnung sind, aber die Orchestrierung nicht, dann ist der Moment gekommen, Ihre Framework-Wahl gegen die besten KI-Agenten-Frameworks zu prüfen.

Agent Tool Calling vs. MCP: Was ist der Unterschied?

MCP ist ein Transport- und Registry-Standard, keine Zuverlässigkeitsschicht, daher gelten dieselben acht Praxen, egal ob Ihre Tools über MCP ankommen oder inline definiert sind. Natives Tool Calling ist der Vertrag des Modellanbieters: wie das Modell einen tool_call ausgibt und einen tool_result liest. MCP standardisiert, wie Tools das Modell erreichen; es tut nichts dafür, ob das Modell das richtige auswählt.

Ein MCP-Server, der ein Tool namens search mit der Beschreibung „searches things" bereitstellt, scheitert identisch zu einer inline definierten Funktion mit derselben Beschreibung. Beheben Sie die Definition, dann sorgen Sie sich um den Transport. Unser Model-Context-Protocol-Leitfaden deckt die Protokollseite vollständig ab.

Wie Techsy diese acht Praxen anwendet

Bei jedem Kunden-Agenten-Projekt erzwingen wir drei davon, bevor irgendetwas anderes ausgeliefert wird: Beschreibungen, die als Anweisungen geschrieben sind (Praxis 1), Validierungs-Gates an jedem Schreib-Tool (Praxis 6) und eine Eval-Suite, die vor dem Deploy läuft, nicht nach einem Vorfall (Praxis 8). Diese drei decken falsche Tool-Aufrufe, falsche Argumente und die Regressionen ab, die beide wieder einschleppen, und dort begann jeder Produktionsvorfall eines Agenten, den wir debuggt haben. Die anderen fünf Praxen folgen, wenn der Agent wächst. Wenn Ihr Agent über das Demo-Stadium hinaus ist und die falschen Tools wählt, sichern Sie sich eine kostenlose Beratung, und wir sagen Ihnen, welche der acht Sie zuerst beheben sollten.

Häufig gestellte Fragen

Was ist Agent Tool Calling?

Agent Tool Calling ist der Mechanismus, bei dem ein LLM beschließt, eine externe Funktion aufzurufen, einen strukturierten tool_call ausgibt und darauf wartet, dass Ihr Code einen tool_result zurückgibt, mit dem es weiterarbeiten kann. Das ist es, was ein Chat-Modell in einen Agenten verwandelt, der Datenbanken abfragen, APIs aufrufen und Aktionen ausführen kann: Das Modell wählt Tool und Argumente, Ihr Executor führt sie aus.

Wie funktioniert die Agent-Tool-Calling-Schleife?

Die Schleife hat fünf Schritte: Die Nutzeranfrage erreicht das Modell, das Modell wählt ein Tool und schreibt einen tool_call, Ihr Executor führt ihn aus, ein tool_result kehrt zum Modell zurück, und das Modell antwortet entweder oder gibt einen weiteren Aufruf aus. Dieser Zyklus wiederholt sich, bis die Aufgabe erledigt ist. Die vier Fehlermodi in diesem Leitfaden sitzen jeweils an einem bestimmten Schritt dieser Schleife.

Warum wählt mein Agent das falsche Tool?

Meist, weil sich zwei Tools überschneiden und ihre Beschreibungen nicht sagen, welches welches ist. Das Modell wählt allein nach Namen und Beschreibungen, daher lesen sich „gets a user" und „finds users" als austauschbar. Beheben Sie es mit Ausschlusszeilen („do NOT use to search"), Namen mit Namespace und weniger Tools im Kontext. Kubaskis Vier-Modell-Test zeigte, dass selbst starke Modelle bei mehrdeutigen Listen falsch routen.

Wie zwinge ich einen Tool-Calling-Agenten, seine Ausgabe zu strukturieren?

Schränken Sie das Schema ein, nicht den Prompt. Verwenden Sie Enums für begrenzte Felder, Required-Arrays für alles, was die Aufgabe braucht, und flache Objekte statt verschachtelter. Für die endgültige Antwort statt des Tool-Aufrufs erzwingen Anbieter-Features wie OpenAIs Structured Outputs und Anthropics Tool-Choice-Modi eine bestimmte Form. Unser Leitfaden für strukturierte Ausgaben deckt beide Wege mit Code ab.

Agent Tool Calling vs. MCP: Was ist der Unterschied?

Natives Tool Calling ist der Vertrag zwischen Ihrem Code und einem Modellanbieter: das Nachrichtenformat von tool_call und tool_result. MCP ist eine Protokollschicht, die standardisiert, wie Tools erkannt und an jeden kompatiblen Client ausgeliefert werden. MCP ändert die Verrohrung, nicht die Zuverlässigkeit. Ein schlecht beschriebenes Tool scheitert auf beiden Wegen gleich, wie unser Model-Context-Protocol-Leitfaden erklärt.

Wie viele Tools sind zu viele für einen LLM-Agenten?

Behandeln Sie 5-10 Tools pro Agent als Arbeitsbereich, nicht als Gesetz. Die Auswahlgenauigkeit sinkt, wenn die sichtbare Liste wächst, besonders wenn sich Namen oder Beschreibungen überschneiden. Die Lösung ist nicht ein größeres Modell, sondern Filterung: Laden Sie nur die Teilmenge, die die aktuelle Aufgabe braucht, mit einer Planner-Worker-Aufteilung. Versehen Sie alles mit einem Namespace, damit zwei Integrationen nie beide ein nacktes search bereitstellen.

Was ist das beste Modell für Tool Calling?

Es gibt keine einzelne Antwort, und veröffentlichte Benchmarks altern in diesem Bereich schlecht. Frontier-Modelle von OpenAI, Anthropic und Google bewältigen alle grundlegende Tool-Use-Aufgaben, während kleinere Modelle, gepaart mit gut entworfenen Tools, Aufgaben oft nahezu gleich häufig zu einem Bruchteil der Token-Kosten erledigen. Bauen Sie die Eval-Suite mit 15-30 Aufgaben aus Praxis 8 und testen Sie Kandidaten gegen Ihre eigenen Tools.

Wie senke ich die Token-Kosten durch Tool Calling?

Kürzen Sie, was zurückkommt. Geben Sie kompakte, signalstarke Ergebnisse zurück statt roher API-Payloads: Anthropic dokumentierte eine Reduktion von 206 auf 72 Tokens durch eine einzige response_format-Änderung. Lösen Sie UUIDs in Namen auf, streichen Sie Felder, die das Modell nie nutzt, und denken Sie daran, dass jedes Tool-Ergebnis in jeder folgenden Runde wieder ins Kontextfenster eintritt. Weniger Aufrufe durch atomare Tools entfernen ganze Ergebnisse aus der Rechnung.

Wie evaluiere ich die Qualität von Tool Calling?

Bewerten Sie vier Metriken der Reihe nach: Tool-Korrektheit (richtiges Tool?), Eingabegenauigkeit (gültige Argumente?), Aufgabenerfüllung (Ziel erreicht?) und Aufgabeneffizienz (Anzahl Tokens und Aufrufe?). Schreiben Sie 15-30 Aufgaben, von denen jede einen bestimmten Aufruf mit prüfbaren Argumenten und einer binären Bestehensbedingung erwartet. Führen Sie die Suite vor und nach jeder Tool-Änderung aus, damit eine Beschreibungs-Umschreibung nie ungemessen ausgeliefert wird.

Fazit

Diagnostizieren Sie, bevor Sie optimieren. Ihr Agent wählt das falsche Tool aus einem von vier Gründen, und drei der acht Praxen oben, Beschreibungen, flache Schemas und Filterung, beheben die Auswahlfehler, die die meisten Produktionsvorfälle treiben. Beginnen Sie dort, denn sie kosten einen Nachmittag, und sie sind der Grund, warum dieses Problem überhaupt lösbar ist. Halten Sie Validierungsfehler aussagekräftig, sichern Sie alles Destruktive durch einen Menschen ab, und führen Sie die Eval-Schleife bei jeder Änderung aus, damit Sie messen, bevor Sie Modelle tauschen. Das Falsche-Tool-Problem ist kein Modellproblem. Es ist ein Tool-Design-Problem, und das Design gehört Ihnen.