CodeAct: Warum ausführbarer Python-Code LLM-Agenten um 20 % genauer macht

Nachdem ich letzte Woche das Paper „cannot self-correct“ gelesen habe, stellt sich eine natürliche Anschlussfrage: Wenn LLMs ihren eigenen Output nicht zuverlässig prüfen können, welches Aktionsformat bietet Agenten dann die beste Chance, Fehler automatisch zu erkennen und zu beheben? CodeAct, veröffentlicht von Xingyao Wang et al. und akzeptiert auf der ICML 2024, argumentiert, dass die Antwort Python-Code ist – nicht weil Code magisch ist, sondern weil ein Python-Interpreter genau die Art von externem, deterministischem Feedback liefert, das LLMs laut der Literatur zur Selbstkorrektur dringend benötigen.

Das Paper

„Executable Code Actions Elicit Better LLM Agents“ (arXiv:2402.01030) von Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng und Heng Ji schlägt vor, die bei Tool-Calling-Agenten üblichen JSON- und Text-Aktionsformate durch ausführbaren Python-Code zu ersetzen. Die Kernidee ist, dass Code eine bessere Lingua Franca für Agenten-Aktionen ist als entweder natürliche Sprachanweisungen oder strukturiertes JSON, da Code bereits Kontrollfluss, Datenabhängigkeiten und mehrstufige Komposition kodiert – und weil LLMs intensiv darauf trainiert wurden.

Das Paper liefert drei Beiträge: (1) ein konzeptionelles Argument für Code als einheitlichen Aktionsraum; (2) M3ToolEval, ein neuer Benchmark mit 82 von Menschen kuratierten Aufgaben, die eine Multi-Tool-Komposition erfordern; und (3) CodeActAgent, ein feinabgestimmtes 7B-Modell, das auf CodeActInstruct trainiert wurde, einem Datensatz von 7.139 mehrstufigen, codebasierten Trajektorien, die Informationsbeschaffung, Softwarepakete, externen Speicher und Roboterplanung umfassen.

Kernideen

• Auf M3ToolEval erreicht GPT-4 mit CodeAct eine Erfolgsquote von 74,4 % gegenüber 53,7 % bei Textaktionen – eine absolute Verbesserung von rund 20 Prozentpunkten im anspruchsvollsten Multi-Tool-Setting.
• CodeAct erfordert etwa 30 % weniger Interaktionsschritte als JSON-basierte Agenten bei denselben Aufgaben. Weniger Schritte sind wichtig: Jeder zusätzliche Round-Trip ist eine weitere Gelegenheit für Fehlerfortpflanzung.
• Der Python-Interpreter fungiert als automatisches, kostenloses Fehlersignal. Eine falsche Zwischenrechnung löst sofort eine Exception aus; der Agent sieht den Traceback und kann ohne einen separaten Kritik-Schritt korrigieren.
• Open-Source-Modelle profitieren stärker als Closed-Source-Modelle. CodeActAgent (Mistral 7B) erreicht 12,2 % auf M3ToolEval gegenüber 3,7 % für den zuvor stärksten Open-Source-Agenten (Lemur-70B mit Text). Der Hebel ist größer, da Python in den Pretraining-Daten reichlich vorhanden ist; spezialisierte JSON-Tool-Calling-Formate hingegen nicht.
• CodeActInstruct trainiert auf vier Domänen, die speziell ausgewählt wurden, um die Komposition zu testen: Informationssuche, Paketaufrufe, Manipulation des externen Speichers und Roboterplanung. Dies sind alles mehrstufige, zustandsabhängige Aufgaben – genau die Fehlermodi, an denen JSON-Agenten scheitern.

Was Bestand hat – und was nicht

Die Verbesserung um 20 % auf M3ToolEval ist signifikant, aber M3ToolEval umfasst nur 82 Aufgaben. Das ist eine kleine Stichprobe, und das Paper gibt keine Konfidenzintervalle an. Der Benchmark wurde zudem von demselben Team kuratiert, das die Methode vorschlägt, was in diesem Bereich üblich ist, aber dennoch erwähnt werden sollte. Ich würde dies gerne auf einem völlig unabhängigen Benchmark repliziert sehen, bevor ich 74,4 % als verlässlichen Wert betrachte.

Der Effizienzvorteil – 30 % weniger Schritte – ist plausibel, vermischt jedoch zwei Dinge. Weniger Schritte könnten bedeuten, dass der Agent pro Schritt genauer ist, oder dass Fehler früher zum Abbruch führen. Das Paper schlüsselt dies nicht sauber auf.

Die anerkannte Lücke zwischen Open- und Closed-Source-Modellen ist groß und wird durch CodeAct nicht beseitigt. CodeActAgent (Mistral 7B) ist mit 12,2 % viel besser als Lemur-70B mit 3,7 %, aber GPT-4 mit CodeAct liegt bei 74,4 %. Das Format hilft, aber es schließt keine 60-Punkte-Fähigkeitslücke. Jeder, der plant, einen Open-Source-Beancount-Agenten einzusetzen, sollte diese Zahl sorgfältig prüfen.

Die Frage des Sandboxings wird in einem einzigen Absatz abgehandelt. Willkürliche Codeausführung im Finanzkontext ist kein unbedeutender Grenzfall – es ist das primäre Sicherheitsrisiko. Das Paper geht nicht darauf ein, was passiert, wenn der Agent Code generiert, der Dateien löscht, Netzwerkaufrufe tätigt oder unerwartete Bibliotheken importiert. Für einen produktiven Buchhaltungs-Agenten ist das Sandbox-Design mindestens so wichtig wie das Aktionsformat.

Warum dies für Finance-KI wichtig ist

Das Beancount-Write-back-Problem ist im Wesentlichen das Problem, für das CodeAct entwickelt wurde: Ein Agent muss mehrere Operationen (aktuellen Kontostand lesen, Transaktion validieren, eine neue Buchung schreiben, die Bilanzgleichung verifizieren) in einer bestimmten Reihenfolge zusammensetzen, wobei Daten zwischen den Schritten fließen. JSON-Tool-Calling bewältigt dies schlecht, da jeder Aufruf isoliert ist. Python löst dies auf natürliche Weise.

Konkreter ausgedrückt: Ein Beancount-Agent im CodeAct-Stil könnte einen gesamten Abstimmungs-Workflow als einzelnes Python-Skript ausdrücken – das Hauptbuch über eine Bibliothek abfragen, Deltas berechnen, neue Einträge vorschlagen und bean-check auf das Ergebnis anwenden –, bevor irgendetwas festgeschrieben wird. Der Interpreter fängt die offensichtlichen Fehler ab; das LLM muss nur noch die semantischen Fehler behandeln. Das ist eine bessere Arbeitsteilung, als das LLM zu bitten, sein eigenes JSON zu validieren.

Die Sicherheitsbedenken schlagen in die andere Richtung aus. Ein Agent mit uneingeschränkter Python-Ausführung über einem Finanz-Hauptbuch stellt eine erhebliche Angriffsfläche dar. Das richtige Design ist fast sicher eine stark eingeschränkte Sandbox – keine Dateisystem-Schreibzugriffe außerhalb eines festgelegten Temp-Verzeichnisses, kein Netzwerkzugriff, keine Shell-Befehle – kombiniert mit einem obligatorischen bean-check-Gate, bevor eine Datei angefasst wird. CodeAct liefert das Aktionsformat; den Käfig müssen Sie immer noch selbst bauen.

Was Sie als Nächstes lesen sollten

• OpenHands (ehemals OpenDevin) – das auf CodeAct basierende Produktionssystem für Agenten von derselben Forschungsgruppe; zeigt, wie das Sandboxing und die Ausführungsumgebung tatsächlich implementiert sind (arXiv:2407.16741)
• ToolBench / ToolLLM – Benchmarks und Trainingsdaten für Tool-Calling-Agenten, die REST-APIs anstelle von Python verwenden; ein nützlicher Kontrast zum Code-First-Ansatz von CodeAct (arXiv:2307.16789)
• SWE-bench – evaluiert Agenten anhand realer GitHub-Issues, was mehrstufige Codeausführung und Dateibearbeitung erfordert; der am nächsten liegende existierende Benchmark für das, was ein Beancount-Write-back-Agent bestehen müsste (arXiv:2310.06770)