GPT-6 Astra Programmatischer Tool-Aufruf: Wann und warum man ihn verwenden sollte
Erfahren Sie, wann GPT-6 Astra Tools in generierten Programmen aufrufen sollte, wie allowed_callers und output_schema funktionieren, und wie Sie Kosten, Sicherheit und Genehmigungen steuern können.

Herkömmliche Funktionsaufrufe pausieren das Modell, senden eine Tool-Anfrage an die Anwendung, warten auf ein Ergebnis und fahren dann fort. Diese Schleife ist klar und kontrollierbar, wird jedoch ineffizient, wenn eine Aufgabe viele abhängige Aufrufe, lokale Filterungen oder Aggregationen erfordert. Die programmatische Tool-Ausführung (PTC) von GPT-6 Astra ermöglicht es dem Modell, ein Programm zu schreiben, das berechtigte Tools innerhalb eines einzigen Ausführungsflusses aufruft.
Was sich geändert hat
Aktivieren Sie das gehostete Tool programmatic_tool_calling, und markieren Sie dann berechtigte Tools mit allowed_callers.
// Keine Übersetzung erforderlich, da es sich um TypeScript-Code handelt.
const tools = [ { type: "programmatic_tool_calling" } { type: "function", name: "get_sales", description: "Gibt Verkaufsaufzeichnungen für eine Region und einen Monat zurück.", erlaubte_anrufer: ["programmatisch"], strict: true, parameters: { type: "object", properties: { region: { type: "string" }, month: { type: "string" } }, erforderlich: ["Region", "Monat"], additionalProperties: false } } ];
Wenn `allowed_callers` weggelassen oder auf `["direkt"]`, das Tool ist direkt aufrufbar. `["programmatisch"]` beschränkt es auf generierten Code, während `["direkt", "programmatisch"]` erlaubt beides. Dies ist eine Ausführungsrichtlinien-Kontrolle, also überprüfen Sie sie eher wie Berechtigungen statt wie Eingabeaufforderungstexte.
PTC unterstützt dokumentierte Tool-Klassen, einschließlich Funktionen und benutzerdefinierte Tools, MCP, Patch anwenden, lokale oder gehostete Shell und Code-Interpreter. Unterstützung bedeutet nicht, dass jedes Tool offengelegt werden sollte.
## Wann PTC das bessere Muster ist
Verwenden Sie es, wenn das Modell Folgendes tun muss:
- viele unabhängige Datensätze abrufen und zusammenführen;
- ein Tool basierend auf einem vorherigen Ergebnis aufrufen;
- filtern Sie ein großes Ergebnis, bevor Sie es an den Reasoning-Kontext zurückgeben;
- strukturierte Ausgaben über Quellen hinweg vergleichen;
- eine begrenzte Datenverarbeitungsschleife ausführen.
Zum Beispiel kann eine vierteljährliche Analyse zwölf Region-Monats-Aufrufe erfordern, gefolgt von Summen und Anomalieerkennung. Ein Programm kann die Aufrufe durchführen und eine kompakte Zusammenfassung zurückgeben, anstatt zwölf Modell-Roundtrips zu erzwingen.
Bevorzugen Sie direkte Funktionsaufrufe für eine oder zwei einfache Operationen, risikoreiche Schreibvorgänge, Workflows, die eine explizite Anwendungsentscheidung zwischen jedem Schritt erfordern, oder Aufgaben, deren Graph deterministisch sein muss. PTC ist nicht automatisch günstiger: Ein schlecht begrenztes Programm kann zu viele Aufrufe tätigen.
## Strukturierte Ausgaben verbessern Programme
Für vorhersagbare Funktionen definieren Sie ein `output_schema`. Die tatsächliche `function_call_output.output` bleibt ein JSON-String, aber das Schema gibt generiertem Code eine verlässliche Form. Stabile Typen reduzieren defensives Parsen und zufällige Annahmen.
Gib kompakte Daten wie IDs, typisierte Metriken und explizite Fehlerobjekte zurück. Vermeide Prosa, wo Code Zahlen benötigt. Mache Paginierung, maximale Zeilen und Kürzungen im Ergebnis sichtbar, damit das Programm einen unvollständigen Datensatz nicht mit der gesamten Population verwechseln kann.
## Werkzeugsuche und verzögertes Laden
Die Werkzeugsuche bleibt eine übergeordnete Fähigkeit. Die offizielle Anleitung warnt, dass zurückgestellte Werkzeuge geladen werden müssen, bevor das Programm startet, da ein laufendes Programm keine Werkzeugsuche aufrufen kann. Planen Sie zuerst die Erkennung, dann die Ausführung. Wenn der Katalog dynamisch ist, lassen Sie das Modell die kleine erforderliche Teilmenge laden und erst dann mit PTC beginnen.
## Sicherheitskontrollen
Binde jedes Programm durch Wandzeit, Anzahl der Aufrufe, Ausgabebytes, Netzwerkziele und Kosten ein. Beschränke Werkzeuge auf minimale Berechtigungen und bewahre Geheimnisse in der Ausführungsumgebung auf, anstatt im generierten Code.
MCP-Zustimmung kann ein Programm anhalten. Bewahren Sie den Programmstatus, während Sie eine aussagekräftige Genehmigungsvorschau präsentieren. Verwenden Sie für Schreibvorgänge Idempotenzschlüssel und serverseitige Autorisierung. Generierter Code ist nicht vertrauenswürdig, selbst wenn das Modell ihn aus vertrauenswürdigen Anweisungen erstellt hat.
Protokollieren Sie den Program-Hash oder die redigierte Quelle, die Tool-Sequenz, bereinigte Argumente, Genehmigungen, Ergebnisse, Token-Nutzung und Dauer. Vermeiden Sie die Speicherung von Anmeldeinformationen oder rohen sensiblen Daten.
## Ein Produktionsentscheidungsrahmen
Stelle vier Fragen:
1. Gibt es genügend Anrufe oder Abhängigkeiten, um ein eingebettetes Programm zu rechtfertigen?
2. Kann jedes Werkzeug sicher begrenzt und typisiert werden?
3. Ist die Anwendung komfortabel darin, die Zwischenkontrolle zu delegieren?
4. Kann der Workflow nach einer Genehmigung oder einem teilweisen Fehlschlag fortgesetzt werden?
Falls eine Antwort Nein lautet, behalten Sie die Orchestrierung im Anwendungscode. Deterministischer Code, den Sie selbst besitzen, ist oft die richtige Wahl für feste Pipelines.
## Kosten- und Korrektheitsexperiment
Benchmark PTC gegen eine herkömmliche Schleife mit identischen Aufgaben. Enthalten Sie einen kleinen Ein-Aufruf-Fall, einen abhängigen Fünf-Aufruf-Fall und einen großen Aggregationsfall. Messen Sie die Gesamtzahl der Tokens, Tool-Aufrufe, Wanduhrzeit, Fehlerrate und Korrektheit des berechneten Ergebnisses. Eine schnellere Antwort, die stillschweigend paginierte Datensätze verwirft, ist keine Verbesserung.
Erzwinge partielle Fehler: Eine Region läuft aus, ein Ergebnis verletzt sein Ausgabeschema, eine MCP-Operation fordert Genehmigung an, und ein Datensatz ist leer. Das generierte Programm soll bewahren, welche Eingaben erfolgreich waren, Abwesenheit nicht als Null behandeln und genügend Details zurückgeben, damit das Modell Einschränkungen erklären kann.
Setze harte Grenzen unterhalb der Infrastrukturgrenzen, damit das Programm vorhersagbar fehlschlägt. Ein klares `CALL_BUDGET_EXCEEDED`-Ergebnis ist einfacher zu beheben als ein Container-Kill. Für analytische Arbeitslasten berechne unabhängig eine Stichprobe von Ergebnissen in deterministischem Code neu. Für jedes finanzielle oder Compliance-Ergebnis bevorzuge verifizierte Berechnungen gegenüber blindem Vertrauen in generierte Aggregationen.
Dieses Experiment offenbart oft ein gemischtes Design: PTC für leseintensive Erkundung und anwendungseigener Code für finale Schreibvorgänge oder regulierte Berechnungen. Hybride Orchestrierung ist eine Stärke, kein Versagen, überall die neueste Funktion zu nutzen.
## FAQ
### Ist PTC dasselbe wie Multi-Agent?
Nein. PTC führt ein Tool-Calling-Programm aus. Multi-Agent delegiert begrenzte Arbeit an Unteragenten mit eigenen Kontexten.
### Kann PTC ein MCP-Tool aufrufen, das eine Genehmigung benötigt?
Ja. Die Genehmigung kann das Programm anhalten. Ihre Anwendung muss den Zustand bewahren und sicher fortfahren.
### Entfernt PTC Funktionsschemata?
Nein. Starke Eingabe- und Ausgabeverträge werden sogar noch wichtiger, weil generierter Code sie konsumiert.
### Sollte jedes Werkzeug beide Anrufermodi erlauben?
Nein. Erlauben Sie nur die Modi, die der Workflow erfordert, insbesondere bei sensiblen Tools.
## Fazit
Programmatischer Tool-Aufruf ist wertvoll, wenn die Tool-Orchestrierung selbst der Engpass ist: viele Aufrufe, Abhängigkeiten, Filterung und Aggregation. Nutzen Sie es selektiv, laden Sie verzögerte Tools vor der Ausführung, definieren Sie strukturierte Ausgaben und setzen Sie strenge Ressourcen- und Berechtigungsgrenzen durch. Für kurze oder risikoreiche Workflows bleibt eine konventionelle anwendungsgesteuerte Schleife einfacher zu prüfen.






























































































