Code as Action: Das Muster hinter Programmatic Tool Calling

In jedem KI-Agenten steckt eine Designentscheidung, die die meisten Entwickler treffen, ohne zu merken, dass sie sie getroffen haben: Was ist die atomare Einheit einer Aktion? Bei den meisten Agentensystemen der letzten zwei Jahre lautet die Antwort: der Tool-Aufruf. Eine einzelne Funktion wird mit einem JSON-Payload aufgerufen, ihr Ergebnis geht an das Modell zurück, das Modell überlegt, was als Nächstes zu tun ist, und der nächste Tool-Aufruf folgt. Das funktioniert. Es skaliert schlecht.

Das Muster Code as Action, als CodeAct 2024 in einem ICML-Paper von Xingyao Wang und Kollegen an der UIUC formalisiert und inzwischen in Anthropics Programmatic Tool Calling API zum Produkt geworden, ersetzt den Tool-Aufruf als atomare Einheit durch einen Codeblock. Statt ein Tool auszuwählen und einen JSON-Payload auszugeben, schreibt das Modell Python, das mehrere Tools aufruft, ihre Ergebnisse verarbeitet und Kontrollfluss-Logik anwendet. Zwischendaten können Sie dabei im Container behalten, statt sie durch den Kontext des Modells zu schicken. Der Unterschied ist architektonisch, nicht graduell.

Das Problem mit dem Tool-Aufruf als Atom

Der übliche agentische Tool-Einsatz sieht so aus: Claude ruft check_status(server_1) auf, wartet auf das Ergebnis, verarbeitet es, ruft check_status(server_2) auf und so weiter. Fünfzig Server bedeuten fünfzig API-Roundtrips, und jeder davon verbraucht Token für die Anfrage, das Reasoning und die Antwort. Der Kontext füllt sich mit Zwischenergebnissen, die nur als Eingabe für den nächsten Schritt relevant sind. Die Latenz summiert sich. Die Kosten auch.

Das strukturelle Problem ist nicht die Zahl der Tool-Aufrufe. Das Modell wird als Orchestrator für Arbeit eingesetzt, die nicht bei jedem Schritt das Schlussfolgern eines Sprachmodells braucht. Über eine Liste iterieren, einen Datensatz filtern, einen fehlgeschlagenen Aufruf mit angepassten Parametern wiederholen: Das sind Programmierprobleme. Dafür gibt es Programmierlösungen. Sie bei jeder Iteration durch ein Sprachmodell zu schleusen, ist die falsche Abstraktion.

Anthropics eigenes Engineering-Team hat es bei der Veröffentlichung von PTC so formuliert: „Beim Tool Calling in natürlicher Sprache erfordert jeder Aufruf einen vollständigen Inferenzdurchlauf, und Zwischenergebnisse häufen sich im Kontext an, ob sie nützlich sind oder nicht. Code eignet sich von Natur aus für Orchestrierungslogik, etwa Schleifen, Bedingungen und Datentransformationen.“

Code ist hier genau deshalb die richtige Abstraktion, weil man damit deterministischen Kontrollfluss über unordentliche Daten aus der realen Welt ausdrückt. Schleifen, Bedingungen, Ausnahmebehandlung, Aggregation: Darüber muss ein LLM nicht bei jedem Schritt nachdenken. Das führt ein Python-Interpreter aus.

So funktioniert es

Der Mechanismus ist einfach. Claude schreibt den Code, Ihr Service führt ihn in einem verwalteten Container aus und löst alle Tool-Aufrufe auf, die der Code anfordert. Die Ausgabe der Ausführung (auch Fehler) kommt als nächste Beobachtung zurück. Das Modell gibt dann entweder weiteren Code aus oder antwortet in natürlicher Sprache.

observe → plan → write code → execute → observe → ...

In Anthropics PTC-Implementierung wird ein Tool über allowed_callers in seiner Definition freigeschaltet:

{
  "name": "query_database",
  "description": "Execute a SQL query. Returns rows as JSON objects.",
  "input_schema": { "...": "..." },
  "allowed_callers": ["code_execution_20250825"]
}

Wenn die Aufgabe von Batch-Ausführung oder komplexer Datenverarbeitung profitiert, schreibt Claude ein Skript, das Ihre Tools als asynchrone Python-Funktionen aufruft. Die Code-Ausführungsumgebung fordert die Tool-Aufrufe an, Ihre Anwendung löst sie auf und setzt die Ausführung fort. Sie bestimmen, was in das Kontextfenster des Modells gelangt: Im typischen Fall ist das nur die fertig verarbeitete Ausgabe, nicht die fünfzig Zwischenergebnisse aus fünfzig einzelnen Roundtrips.

So sieht das für das Beispiel mit den fünfzig Servern aus:

# Claude writes this; your infrastructure executes it
results = await asyncio.gather(*[
    check_status(f"server_{i}") for i in range(50)
])
healthy = sum(1 for r in results if r["status"] == "ok")
print({"healthy": healthy, "total": 50, "degraded": 50 - healthy})

Ein einziger Ausführungsblock. Im typischen Muster geben Sie nur das aggregierte Ergebnis an das Modell zurück, die rohen Zwischendaten bleiben im Container. Die Zwischenergebnisse müssen das Kontextfenster nicht füllen.

Zwei operative Details sollten Sie festnageln, bevor Sie eine Integration in Produktion bringen. Erstens garantiert PTC keine parallele Ausführung. Das Skript kann Parallelität über asyncio.gather() ausdrücken, aber ob Tool-Aufrufe tatsächlich gleichzeitig laufen, hängt allein davon ab, wie Ihre Host-Anwendung die ausgegebenen Anfragen behandelt. Der Hauptgewinn von PTC liegt in der Kontexthygiene und der Token-Effizienz: Die Orchestrierungslogik wandert aus den Gesprächsrunden in expliziten Code, auch wenn die Ausführung am Ende sequenziell läuft. Wenn Sie viele Aufrufe gleichzeitig auffächern, berücksichtigen Sie die Rate Limits der empfangenden Services.

Zweitens, und das ist die eigentliche Falle: Solange der Container auf Tool-Ergebnisse wartet, darf Ihre API-Antwort nur aus tool_result-Blöcken bestehen, ohne zusätzlichen Text. Mischen Sie bei offenen Aufrufen eine Textnachricht hinein, wirft der Container einen Fehler. Richten Sie Ihre Logik für das Antwort-Routing danach aus, bevor Sie in Produktion gehen.

Warum LLMs das gut können

Für Code as Action spricht mehr als die Effizienz. Die Trainingsverteilung des Modells passt auch zu der Aufgabe, die es erledigen soll.

JSON-Tool-Schemas erzeugen aus einem strukturellen Grund Reibung: Sie sind lokal, neu und für jede Anwendung eigen. Ihr spezielles Tool-Schema hat ein Modell im Training nie gesehen. Es muss jedes Mal aus Grundprinzipien heraus verallgemeinern. Python-Syntax und -Idiome sind dagegen in den Trainingsdaten überall präsent: GitHub-Repositories, Stack-Overflow-Antworten, Dokumentation, Lehrbücher. Wenn Sie von Claude einen JSON-Funktionsaufruf gegen ein unbekanntes Schema verlangen, muss es mit etwas Neuem umgehen. Wenn Sie es Python schreiben lassen, bewegen Sie sich auf vertrautem Terrain.

Dieses konzeptionelle Argument hat empirische Rückendeckung. Das ICML-2024-Paper von Wang et al. hat 17 LLMs auf zwei Benchmarks untersucht (API-Bank und M³ToolEval) und codebasierte Aktionen mit Text- und JSON-Alternativen verglichen. Code schlägt auf M³ToolEval beide um bis zu 20 % bei der Erfolgsquote der Aufgaben und braucht für gleichwertige Aufgaben im Schnitt deutlich weniger Runden (§2.3, Tabelle 3, Wang et al. ICML 2024). Weniger Runden bedeuten weniger Modellaufrufe, und das heißt bei Produktionsvolumen direkt niedrigere Kosten.

Self-Debugging als vollwertiges Feature

Verlagert man die Aktion in eine Code-Ausführungsumgebung, hat das eine Folge: Das Modell bekommt strukturierte Fehlerrückmeldungen statt einer undurchsichtigen Fehlermeldung in einem Tool-Ergebnis.

Schlägt die Ausführung fehl, sieht das Modell den Fehler als Ausführungsausgabe des Containers. Es erkennt, welcher Teil der Orchestrierung versagt hat, und kann den Code entsprechend überarbeiten. Self-Debugging wird zum natürlichen Teil der Ausführungsschleife, statt nachträglich angeflanscht zu sein:

write code → execute → observe failure → revise → execute → ...

Der CodeActAgent aus dem ICML-Paper, per Feintuning aus Llama 2 und Mistral-7B auf dem CodeActInstruct-Datensatz (7.000 mehrstufige Trajektorien) entstanden, wurde gezielt dafür gebaut, diese Schleife zu nutzen. Dass er so gut auf Agentenaufgaben außerhalb der Trainingsverteilung verallgemeinert, liegt zum Teil daran, dass die fehlergetriebene Iteration schon in seiner Trainingsverteilung steckt.

Dazu kommt ein Vorteil beim Debugging in der Produktion, der eine Erwähnung wert ist: Code-Aktionen lassen sich auf eine Weise prüfen, die JSON-Tool-Aufrufsequenzen nicht erlauben. Wenn etwas schiefgeht, haben Sie Python vor sich, das Sie lesen, in ein Notebook kopieren und selbst ausführen können. Diese Nachvollziehbarkeit zahlt sich mit der Zeit immer mehr aus.

Eine Anmerkung zur Versionierung

In diesem Artikel begegnen Ihnen Bezeichner wie code_execution_20250825 und advanced-tool-use-2025-11-20. Das sind die aktuellen Beta-Bezeichner, Stand Februar 2026. Anthropic hat ähnliche Bezeichner in der Vergangenheit geändert oder ersetzt, ohne längere Deprecation-Fristen zu gewähren. Verstehen Sie sie als Illustration der aktuellen Implementierung, nicht als stabile öffentliche Verträge. Prüfen Sie vor jedem Deployment in Produktion die offizielle Dokumentation.

Musterwahl: Wann sich der Mehraufwand für Code as Action lohnt

Code as Action bringt echte Kosten mit: eine Sandbox-Ausführungsumgebung, die verwaltet werden will, einen Container-Lebenszyklus, den Sie im Blick behalten müssen (Anthropics PTC-Container laufen nach etwa 4,5 Minuten Inaktivität ab), und eine größere Angriffsfläche. Eine Prompt Injection, die einen Code-Executor erreicht, ist ein anderes Kaliber als eine, die bei einem Schema-Parser landet. Diese Kosten sind nicht trivial.

Diese Kosten lohnen sich, wenn der Workflow wirklich programmatisch ist: Iteration, bedingte Verzweigung, Datenaggregation, Retry-Logik oder Komposition, die sonst viele aufeinanderfolgende Modellaufrufe erfordern würde. Sie lohnen sich nicht, wenn Ihr Agent eine kleine Zahl klar definierter API-Aufrufe in fester Reihenfolge orchestriert.

Hier lohnt sich der explizite Vergleich:

Muster	Aktionsformat	Stärken	Schwächen	Am besten für
ReAct / Tool-Use-Schleife	JSON- / Text-Tool-Aufrufe	Einfach, leicht nachzuverfolgen, keine Sandbox nötig	Wortreich, keine nativen Schleifen, aufgeblähter Kontext bei großem Umfang	Feste sequenzielle Workflows
PTC (Anthropic-Implementierung)	Verwaltete Ausführung + allowed_callers	Kontexthygiene, Token-effizient, Opt-in pro Tool	Beta-API-Oberfläche, Container-Lebenszyklus, noch keine Unterstützung in Claude Code	Produktions-Workloads mit mehreren Tools, vielen Daten und Iteration
CodeAct (Forschungsmuster)	Python-Ausführung; Umgebung variiert	Maximale Flexibilität, selbstkorrigierend	Umgebungsverwaltung, größte Angriffsfläche	Forschungsagenten, explorative Automatisierung, eigene Runtimes

Eine Anmerkung zur Tabelle: „CodeAct (Forschungsmuster)“ heißt nicht generell uneingeschränkter PyPI-Zugriff. Es heißt Code as Action mit einem Python-Executor; die Umgebung kann je nach Implementierung minimal oder erweitert sein. Der entscheidende Unterschied zwischen dem Forschungsmuster und Anthropics PTC liegt in der verwalteten Umgebung und der expliziten Opt-in-Schnittstelle für einzelne Tools.

Die offizielle Dokumentation empfiehlt, pro Tool entweder ["direct"] oder ["code_execution_20250825"] zu wählen, nicht beides. Damit bekommt das Modell eine eindeutige Vorgabe, wie jedes Tool gedacht ist.

Die Verbindung zu Programmatic Tool Calling

CodeAct ist das Forschungsmuster. Anthropics Programmatic Tool Calling ist die Produktionsumsetzung derselben Grundeinsicht, mit zwei wichtigen Ergänzungen: dem Opt-in über allowed_callers und der expliziten Angabe des Aufrufers in jedem tool_use-Block.

{
  "type": "tool_use",
  "id": "toolu_xyz789",
  "name": "query_database",
  "input": { "sql": "SELECT ..." },
  "caller": {
    "type": "code_execution_20250825",
    "tool_id": "srvtoolu_abc123"
  }
}

Das Feld caller ist keine Kosmetik. Darüber leitet Ihre Anwendung Tool-Ergebnisse entweder zurück in einen laufenden Code-Ausführungscontainer oder zurück in den direkten Kontext des Modells. Ihr Handler für Tool-Ergebnisse muss dieses Feld prüfen und entsprechend reagieren. Und denken Sie daran: Solange offene Tool-Aufrufe bestehen, dürfen Ihre Antworten nur aus tool_result-Blöcken bestehen. Programmatisch aufgerufene Tools müssen ihre Ergebnisse liefern, bevor der Container abläuft (etwa 4,5 Minuten Inaktivität, behalten Sie das Feld expires_at im Auge).

Aktuelle Modellkompatibilität (laut offizieller Dokumentation, Februar 2026):

Modell	Tool-Version
Claude Opus 4.5 (claude-opus-4-5-20251101)	code_execution_20250825
Claude Opus 4.6 (claude-opus-4-6)	code_execution_20250825
Claude Sonnet 4.5 (claude-sonnet-4-5-20250929)	code_execution_20250825
Claude Sonnet 4.6 (claude-sonnet-4-6)	code_execution_20250825

Laut Anthropics Dokumentation ist die Funktion derzeit über die Claude API und Microsoft Foundry verfügbar.

Was PTC noch nicht abdeckt

Wenn Sie mit Claude Code statt über die direkte API-Integration arbeiten, ist der aktuelle Stand folgender: PTC hat mit Stand Februar 2026 keine dokumentierte Unterstützung in Claude Code, weder im Terminal noch in der Desktop-App. Es gibt einen aktiven Feature-Wunsch aus der Community (GitHub-Issue #12836), der viel Zuspruch bekommen hat, aber keinen zugesagten Zeitplan von Anthropic.

Für die meisten Workflows mit Claude Code ist die Lücke in der Praxis nicht akut: Native Bash-Ausführung und parallele Sessions in der Desktop-App decken vieles davon ab. Wenn Sie aber gezielt die Kontexthygiene von PTC für Produktions-Workloads mit hohem Volumen brauchen, bleibt die direkte API-Integration heute der einzige Weg. Da die Infrastruktur auf API-Ebene existiert, darf man annehmen, dass das irgendwann auch in Claude Code ankommt. Behalten Sie die Release Notes im Auge.

Das zugrunde liegende Prinzip

Lässt man die API-Oberfläche, die Beta-Header und die SDK-Optionen weg, bleibt als Kern von Code as Action diese Einsicht: Bauen Sie Agenten-Schnittstellen, die zu dem passen, was das Modell tatsächlich kann.

Tool-Schemas sind lokal und neu, jede Anwendung erfindet ihre eigenen. Python-Syntax und -Idiome sind global und in den Trainingsdaten stark vertreten. Wenn Sie ein Modell, das fließend Code spricht, zwingen, über künstliche JSON-Funktionssignaturen zu kommunizieren, arbeiten Sie gegen das System. Wenn Sie es Python schreiben lassen, arbeiten Sie mit ihm.

Dieses Prinzip bewährt sich in der Produktion immer öfter. Anthropics Engineering-Team hat Claude for Excel auf PTC aufgebaut, und zwar gerade weil es Tabellen mit Tausenden Zeilen lesen und ändern musste, ohne das Kontextfenster des Modells zu überladen. Das Muster begann als Forschungsergebnis (Code ist ein besseres Aktionsprimitiv als JSON) und ist heute tragende Infrastruktur.

Die Analogie mit dem Konzertpianisten hält weiter. Wenn Sie die Leistung bekommen wollen, für die Sie den Pianisten engagiert haben, geben Sie ihm das Instrument, auf dem er ausgebildet wurde.

Aus dem Englischen übersetzt: zum Originalbeitrag