Was sind programmatische Tool-Aufrufe?
Programmatische Tool-Aufrufe ermöglichen es einem KI-Agenten, Code zu schreiben, der Tools in einer Sandbox-Umgebung aufruft — anstatt für jeden Tool-Aufruf einen separaten Modell-Roundtrip zu benötigen. Der Agent schreibt ein Skript, die Laufzeitumgebung führt es aus, und Tool-Aufrufe erfolgen direkt aus dem Code. Nur das Endergebnis wird in das Kontextfenster des Modells zurückgegeben.
Warum es wichtig ist
Code kann abhängige Aufrufe koordinieren und Ergebnisse filtern, ohne für jeden Schritt eine neue Modellentscheidung anzufordern. Unabhängige Standardaufrufe können bereits parallel laufen; vergleiche auch mit diesem Ausgangspunkt.
Weniger Roundtrips
Mehrere Tools in einer einzigen Code-Ausführung aufrufen statt ein Modell-Turn pro Tool.
Geringerer Token-Verbrauch
Zwischenergebnisse bleiben in der Sandbox — nur die Zusammenfassung gelangt ins Kontextfenster.
Datenfilterung
Große Tool-Ausgaben im Code verarbeiten und filtern, bevor sie das Modell erreichen.
Nativer Kontrollfluss
Schleifen, Bedingungen und Fehlerbehandlung nutzen — das Modell schreibt echten Code, nicht nur JSON-Aufrufe.
Wie es funktioniert
Der Ablauf umfasst vier Schritte zwischen Agent, Sandbox und deinem Tool-Server.
Agent schreibt Code
Das Modell generiert ein Python-Skript, das deine Tools als asynchrone Funktionen aufruft.
Sandbox führt aus
Der Code läuft in einem Sandbox-Container. Wenn eine Tool-Funktion aufgerufen wird, pausiert die Ausführung.
Tool wird extern ausgeführt
Dein Server empfängt den Tool-Aufruf, führt ihn aus und gibt das Ergebnis an die Sandbox zurück.
Ergebnis ans Modell
Sobald das Skript fertig ist, wird nur die finale Ausgabe dem Kontext des Modells hinzugefügt.
Traditionell vs. Programmatisch
So unterscheiden sich die beiden Ansätze bei einer Aufgabe, die drei Datenbankregionen abfragt.
Traditionelle Tool-Nutzung
Bei drei sequenziellen, abhängigen Aufrufen wird das Modell vor jedem Tool und nochmals für die Endantwort aufgerufen: vier Modellaufrufe.
Modell → Tool-Aufruf → Ergebnis → Modell → Tool-Aufruf → Ergebnis → Modell → Tool-Aufruf → Ergebnis → Modell → Antwort
4 Modellaufrufe (sequenzielles Beispiel)
Programmatische Tool-Aufrufe
Ein Modellaufruf schreibt das Skript; ein weiterer verarbeitet sein Ergebnis und antwortet. Das Skript koordiniert die Toolaufrufe.
Modell → Code (3 Toolaufrufe + Aggregation) → Ergebnis → Modell → Endantwort
2 Modellaufrufe
Kontrollfall: Drei unabhängige Standard-Toolaufrufe lassen sich ebenfalls parallel ausführen. Ein Modellaufruf fordert sie an, ein weiterer fasst zusammen, genauso wie in diesem PTC-Beispiel. PTC kann zusätzlich Zwischendaten im Code filtern und aggregieren, sodass weniger in den Modellkontext gelangt.
Beispiel: Programmatische Datenbankabfrage
Der Agent schreibt Python, das über Regionen iteriert, ein Datenbank-Tool aufruft und Ergebnisse aggregiert — alles in einer Ausführung.
import json
regions = ["West", "East", "Central"]
results = {}
for region in regions:
raw = await query_database({
"sql": f"SELECT SUM(revenue) AS total FROM sales WHERE region='{region}'"
})
rows = json.loads(raw)
results[region] = rows[0]["total"] or 0
print(json.dumps({
"top_region": max(results, key=results.get),
"total": sum(results.values())
}))Anwendungsfälle
Programmatische Tool-Aufrufe glänzen, wenn Agenten mehr als einzelne Tool-Aufrufe benötigen.
Batch-Verarbeitung
Eine Datenbank für 50 Regionen in einer Schleife abfragen, Ergebnisse aggregieren und eine Zusammenfassung zurückgeben — alles in einer Ausführung.
Bedingte Logik
Zürst die Dateigröße prüfen, dann entscheiden, ob die ganze Datei oder nur eine Zusammenfassung gelesen wird. Keine verschwendeten Roundtrips.
Datenfilterung
10.000 Log-Einträge abrufen, nur Fehler filtern und die letzten 10 zurückgeben — das Kontextfenster bleibt sauber.
Frühzeitiger Abbruch
Endpunkte der Reihe nach prüfen und stoppen, sobald ein funktionierender gefunden wird. Nicht alle müssen geprüft werden.
Das allowed_callers-Konzept
In Anthropics API benennt allowed_callers den vorgesehenen direkten oder versionierten Code-Execution-Aufrufer. Das steuert die Toolnutzung, ersetzt aber keine Berechtigungsprüfung zur Laufzeit.
Für Klarheit ist es am besten, pro Tool einen Modus zu wählen, anstatt beide zu aktivieren. Das gibt dem Modell klarere Hinweise zur Nutzung jedes Tools.
Anthropic-API-Beispiel, geprüft im September 2026. allowed_callers steuert die Aufrufwahl; erzwinge Zugriffsrechte in der Tool-Laufzeit, denn das Feld ist keine harte API-Sicherheitsgrenze.
{
"type": "code_execution_20260120",
"name": "code_execution"
}Nur Direkt
Das Modell ruft das Tool direkt über den Standard-Tool-Use-Flow auf. Das ist die Standardeinstellung.
"allowed_callers": ["direct"]
Nur Code-Ausführung
Leite das Modell zum Aufruf aus der benannten Code-Execution-Version an. Prüfe Aufrufer und Berechtigungen im eigenen Toolhandler.
"allowed_callers": ["code_execution_20260120"]
Beide Modi
Das Tool kann entweder direkt oder aus Code aufgerufen werden. Sparsam verwenden — kann die Tool-Auswahl verwirren.
"allowed_callers": ["direct", "code_execution_20260120"]
Wichtige Erkenntnisse
- 1Programmatische Tool-Aufrufe lassen Agenten Code schreiben, der Tools aufruft — ohne Roundtrips pro Tool.
- 2Nur die Skriptausgabe muss in den Modellkontext; ausgegebene rohe Zwischendaten heben diesen Vorteil auf.
- 3Verwende die versionierten Aufruferkennungen des Anbieters und erzwinge Zugriffsrechte zur Laufzeit.
- 4Ideal für Batch-Verarbeitung, bedingte Workflows, Datenfilterung und mehrstufige Tool-Ketten.
- 5Mehrere KI-Anbieter implementieren dieses Muster, um Agenten schneller und effizienter zu machen.