Für die letzten paar Jahre bedeutete "ein Agent nutzt ein Tool" einen spezifischen Mechanismus: das Modell emittiert einen strukturierten Blob — normalerweise JSON — das einen Funktion und ihre Argumente benennt, eine Laufzeit parsed es, ruft die Funktion auf und füttert das Ergebnis zurück in den Kontext des Modells. Dieses Tool-Calling-Muster wurde die erste Generation Agent-Frameworks angetrieben und es funktioniert. Aber es hat eine stille Ineffizienz, die offensichtlich wird, sobald du danach suchst: Jede Aktion ist ein separater Hin-Weg durch das Modell. Möchte drei Tools anrufen und ihre Ergebnisse kombinieren? Das ist mindestens drei Modell-Aufrufe, jeder Re-Lesen des akkumulierten Kontexts, da das Modell nur einen JSON-Tool-Aufruf auf einmal emittieren kann und warten muss, um jedes Ergebnis zu sehen, bevor es das Nächste entscheidet. Eine wachsende Schule des Gedankens im Jahr 2026 argumentiert, es gibt einen besseren Weg, und er versteckt sich in Klartext: lass den Agent Code schreiben.
Das ist die Code-First-Agenten-Paradigma, und es gestaltet um, wie die effizienteren Agent-Frameworks funktionieren. Statt JSON zu emittieren, schreibt der Agent ein Snippet von Python — das mehrere Tools anrufen, Schleifen verwenden, Variablen verwenden und Ergebnisse kombinieren kann — und die Laufzeit führt es aus. Dieser Leitfaden erklärt, warum diese Verschiebung wichtig ist, wie sie Agent-Leistung und Kosten ändert, und wie die führenden Frameworks sie implementieren, über smolagents (der Code-First-Ansatz in seiner reinsten Form) und Pydantic AI (Type-Safe-Agenten vom Pydantic-Team). Es deckt auch die wesentliche Flip-Seite: das Ausführen von Modell-generiertem Code sicher.
Das Problem mit JSON-Tool-Aufrufen
Um zu sehen, warum Code-First wichtig ist, schaue genau, was JSON-Tool-Calling kostet. Betrachte eine Aufgabe, die das Abrufen von Daten aus einer API, das Filtern und das Berechnen einer Zusammenfassung erfordert. Mit Tool-Aufrufen emittiert das Modell einen Anruf an das Fetch-Tool, wartet auf das Ergebnis, emittiert einen Anruf an ein Filter-Tool, wartet, dann emittiert einen Anruf an ein Compute-Tool, wartet und liest schließlich eine Antwort zusammen. Das sind vier Modell-Aufrufe, und jeder Re-Prozessiert den gesamten wachsenden Kontext — die ursprüngliche Aufgabe, plus jeden Zwischenergebnis, der bisher akkumuliert ist. Die Token-Kosten und Latenz skalieren mit der Anzahl der Schritte, und komplexe Aufgaben haben viele Schritte.
Es gibt auch ein subtileres Problem: JSON-Tool-Aufrufe beschränken, wie der Agent Aktionen zusammen setzen kann. Jeder Schritt ist ein einzelner Funktions-Anruf mit Literal-Argumenten. Das Modell kann nicht leicht ausdrücken "rufe dieses Tool für jedes Element in dieser Liste auf," oder "wenn das Ergebnis leer ist, versuche eine andere Abfrage," oder "kombiniere diese zwei Ergebnisse mit einer Berechnung," ohne jeden in separate Hin-Wege zu brechen und über Zwischenzustand über Modell-Aufrufe zu vernünfteln. Der Ausdrucksvermögen normaler Programmierung — Schleifen, Konditionale, Variablen, Komposition — ist genau das, was fehlt, und die sind die Konstrukte, die Multi-Step-Logik natürlich machen. Tool-Aufrufe fragen das Modell, um ein Programm-Zähler zu sein, der einen Anweisung auf einmal emittiert, wenn das, was die Aufgabe braucht, ein Programm ist.
Das Code-First-Verständnis
Der Code-First-Ansatz wird beide Probleme auf einmal aufgelöst. Statt einen einzelnen JSON-Tool-Aufruf zu emittieren, schreibt der Agent einen Block von Python-Code, der mehrere Tools anrufen kann, Kontroll-Fluss verwenden, Zwischenwerte in Variablen halten und ein Ergebnis zurückgeben kann. Die Laufzeit führt diesen Code aus, und die Tools, die der Agent anrufen kann, sind einfach Python-Funktionen, die in seiner Ausführungs-Umgebung verfügbar sind. Das API-Fetch, das Filter und das Compute aus dem früheren Beispiel werden ein Code-Block mit drei Funktions-Aufrufen und ein wenig Logik dazwischen — ausgeführt in einem einzelnen Schritt, von einem einzelnen Modell-Anruf.
Der Effizienzgewinn ist real und messbar. Da ein Code-Block erreichen kann, was zuvor mehrere Tool-Call-Hin-Wege brauchten, machen Code-First-Agenten sinnvoll weniger LLM-Aufrufe — berichtete Reduktionen um ~30% — das senkt beide Kosten und Latenz. Und da der Agent Aktionen in einer echten Programmiersprache ausdrückt, handhbt es zusammengesetzte Aufgaben (über Ergebnisse iterieren, auf Konditionen verzweigen, Berechnungen kombinieren) viel natürlicher, als eine Reihe isolierter JSON-Aufrufe könnte. Es gibt auch ein Training-Data-Argument: Modelle haben enorme Mengen Code gesehen und sind echt gut dabei, Code zu schreiben, vielleicht besser als Tool-Call-JSON für neuartige Schemas zu produzieren. Ein Modell fragen, seine Absicht als Code auszudrücken, spielt zu einer Stärke.
smolagents: die Paradigma in ihrer reinsten Form
smolagents, von Hugging Face, ist der klares Ausdruck der Code-First-Idee. Es ist eine absichtlich minimale Bibliothek, die um den CodeAgent herum gebaut ist: ein Agent, dessen Aktionen sind Python-Code. Gib ihm eine Menge Tools (gewöhnliche Python-Funktionen) und ein Modell, überreiche ihm eine Aufgabe, und es funktioniert durch das Schreiben und Ausführen von Code, der diese Tools anruft, Schleifen macht und berechnet, bis es eine Antwort hat. Die Bibliothek bleibt klein und hackbar absichtlich — seine Philosophie ist, dass die Agent-Schleife einfach genug zum Lesen und Modifizieren sein sollte, mit der Intelligenz von dem Modell und dem Code-Ausführungs-Ansatz kommend statt von einem schweren Framework.
Was smolagents zwingend macht jenseits der Effizienz ist, wie natürlich es echte Aufgaben handhbt. Da der Agent Code schreibt, kann eine Forschungs-Aufgabe suchen, Ergebnisse parsen, sie filtern und über sie in einem kohärenten Schritt berechnen; eine Daten-Aufgabe kann laden, transformieren und analysieren ohne einen JSON-Hin-Weg pro Operation. Es ist Modell-agnostisch — arbeitet mit Hugging-Face-Modellen, lokalen Modellen oder jedem Provider über LiteLLM — sodass du nicht an ein Backend gebunden bist, und es unterstützt die Sandbox-Ausführung, die Code-First grundsätzlich erfordert (mehr zu dem unten). Für Teams, die die Code-First-Effizienz in einem kleinen, verständlichen Paket wollen, ist smolagents die Referenz-Implementierung, und der smolagents-Spickzettel deckt seine Agenten, Tools und Sandboxing.
Der Tradeoff von smolagents' Minimalismus ist, dass es weniger Gerüste als ein Schwergewichts-Framework bietet — weniger eingebaute Abstraktionen für komplexe Multi-Agent-Orchestrierung, langlebigen Zustand oder aufwändige Kontroll-Fluss. Für Single-Agent-Code-Schleifen ist das ein Feature, nicht eine Einschränkung; für ausschweifende zustandsbehaftete Systeme könntest du etwas Schwereres erreichen. Aber als der reinste, effizienteste Ausdruck von Code-First-Agenten ist es schwer zu schlagen.
Pydantic AI: Type-Safety trifft Agenten
Pydantic AI, vom Team hinter Pydantic (die Validierungs-Bibliothek, die FastAPI und viel des Python-AI-Ökosystems untermauert), nähert Agenten von einem anderen Winkel: Type-Safety und Developer-Experience. Seine Wette ist, dass die gleiche Strenge Pydantic zur Daten-Validierung gebracht hat — Deklarieren der Form deiner Daten mit Python-Type-Hints und Automatischer Validierung — sollte auf Agenten angewendet werden. Jeder Agent Input, Output und Tool-Aufruf ist typisiert, das Framework validiert, dass Modell-Outputs die erwartete Struktur passen, und es kann automatisch das Modell fragen, sich selbst zu korrigieren, wenn die Ausgabe nicht entspricht. Das Ergebnis ist eine FastAPI-Style-Developer-Experience für Agent-Aufbau: vertraut, Typ-überprüft und Production-orientiert.
Type-Safety ist wichtig für Agenten mehr als es scheint. Ein wiederkehrendes Leid von LLM-Anwendungen ist, dass Modell-Ausgabe unstrukturierter Text ist, und sie zuverlässig in die strukturierten Daten dein Programm braucht — die richtigen Felder, die richtigen Typen, gültige Werte — ist fiddly und fehler-anfällig. Pydantic AI macht strukturierte Ausgabe eine erste-Klasse-Garantie: Du deklarierst den Output-Typ, und das Framework erzwingt es, mit dem Modell neu versuchen, wenn nötig. Das dreht "parse die Modell-Text und hoffe, es ist gültig" in "erhalte ein validiertes, typisiertes Objekt," das ist genau, was Production-Code will. Seine V2-Umgestaltung in 2026 schob weiter mit einem Harness-First-Modell, das Tools, Anweisungen und Einstellungen in zusammengesetzte Fähigkeiten bündelt. Der Pydantic AI-Spickzettel deckt seine typisierten Agenten und Tools.
Pydantic AI und smolagents sind nicht wirklich Konkurrenten, sondern Ausdrücke unterschiedlicher Prioritäten. smolagents optimiert für die Effizienz und Ausdrucksvermögen von Code-as-Action; Pydantic AI optimiert für Type-Safety, validierte strukturierte Ausgabe und Production-Ergonomik. Ein Team, das weniger LLM-Aufrufe und natürliche Multi-Step-Logik wertet, lehnt smolagents; ein Team, das Typ-überprüfte, validierte, FastAPI-Style-Agent-Code wertet, lehnt Pydantic AI. Beide vertreten die 2026-Bewegung weg vom ersten-Generation, JSON-only-Frameworks hin zu etwas mehr Programmer-Native.
Das Sicherheits-Problem: das Ausführen von Modell-generiertem Code
Code-First-Agenten haben eine offensichtliche und ernsthafte Falle: Sie führen Code aus, der von einem Sprachmodell geschrieben wurde, und Modell-generierter Code ist per Definition nicht vertrauenswürdig. Ein Agent, der geschriebenen und Lauf-beliebigen Python kann, wenn kompromittiert von einer Prompt-Injection oder einfach falsch, Dateien löschen, Daten abkapseln, Netzwerk-Aufrufe machen oder Ressourcen ohne Bound verbrauchen. Das ist nicht eine hypothetische Sorge — es ist das zentrale operative Risiko der gesamten Paradigma, und sie ernsthaft zu nehmen ist nicht-Verhandelbar für jede Production-Bereitstellung.
Die Antwort ist Sandboxing: Laufe den generierten Code in einer isolierten Umgebung mit eingeschränkten Fähigkeiten aus. Die Frameworks unterstützen das direkt — smolagents kann Code in Remote-Sandboxen wie E2B ausführen, oder in Docker oder Modal-Containern, statt im Host-Prozess, und du kannst einschränken, welche Module generierter Code sogar erlaubt ist zu importieren. Das Prinzip ist das geringste Privileg: die Sandbox sollte nur den Zugang haben, das die Aufgabe echt erfordert — kein Datei-System-Zugang, das sie nicht brauchen, keine Netzwerk-Ausfahrt jenseits, was notwendig ist, keine Fähigkeit, den Host zu beeinflussen. Agent-generierten Code direkt in deinem Anwendungs-Prozess auszuführen, mit deinen Anwendungs-Berechtigungen, ist der Fehler, der einen nützlichen Agent in eine Remote-Code-Ausführungs-Sicherheitslücke in freundlicher Schnittstelle dreht.
Die praktische Anleitung ist unkompliziert, aber sie muss gefolgt werden. In Development ist lokale Ausführung bequem und akzeptabel für vertrauten, nicht-empfindlichen Aufgaben. In irgendetwas, das Production nähert, oder irgendwelche Aufgaben, die auf nicht-vertrauenswürdige Eingabe oder empfindliche Systeme berühren, laufe den Code in einer Sandbox mit Least-Privilege-Zugang, Restrict-Imports und behandle die Agent-Code-Ausgabe wie du jeden nicht-vertrauenswürdigen Input würdest — da ist, was es ist. Die Effizienz und Kraft von Code-First-Agenten sind real, aber sie kommen mit einer Verantwortung, die JSON-Tool-Calling (das von Design aus mehr eingeschränkt ist) nicht so scharf auferlegt. Diese Verantwortung akzeptieren und richtig Sandbox, und die Paradigma ist sowohl mächtig als auch sicher.
Wenn JSON-Tool-Aufrufe immer noch die rechte Wahl sind
Code-First-Agenten sind effizienter und ausdrucksvoller, aber es wäre ein Fehler zu schlussfolgern, dass JSON-Tool-Aufrufe obsolet sind. Es gibt echte Situationen, in denen das eingeschränkte, ein-Aufruf-zur-Zeit-Modell die bessere Passung ist, und sie zu verstehen behält die Wahl ehrlich. Das Klarste ist, wenn Aktionen fest kontrolliert und überprüft werden müssen. Ein JSON-Tool-Aufruf ist ein diskretes, inspektierbare, einfach-validierbare Ereignis: der Agent möchte diesen Funktion mit diesen Argumenten anrufen, und du kannst genehmigen, loggen oder es vor irgendetwas ablehnen, das läuft. Diese Audit-Fähigkeit ist wertvoll in High-Stakes-Domänen — finanzielle Aktionen, Infrastruktur-Änderungen, irgendetwas mit irreversiblen Seiteneffekten — wo du einen Menschen oder eine Richtlinien-Überprüfung zwischen der Agent's Absicht und seiner Ausführung wünschst. Code, der als Block läuft, ist an diesem Granularitäts-Level schwerer zu gating.
Der zweite Fall ist Simplicity. Viele Agenten brauchen echt nur, ein Tool auf einmal in einem unkomplizierten Loop anzurufen — antworte auf eine Frage durch das Anrufen eines Such-Tool, schau etwas auf, führe eine Aktion durch. Für die ist die Ausdrucksvermögen von Code-as-Action nicht genutzter Fähigkeit, und die extra Maschinerie eines Code-Sandbox ist Overhead ohne Lohn. Ein einfacher Tool-Calling-Agent ist einfacher zu vernünfteln und zu deployen, wenn die Aufgabe nicht Multi-Step-Komposition brauchen. Der dritte Fall ist Safety-Haltung: da JSON-Tool-Aufrufe nur den Agent vordefinierte Funktionen mit strukturierten Argumenten aufrufen lassen, ist es naturgemäß eingeschränkter als das Ausführen von beliebigem Code, und für manche Threat-Models ist das kleinere Blast-Radius der Effizienz-Kosten wertwert, sogar wenn eine Aufgabe von Code profitieren könnte.
Die reife Ansicht ist, dass dies zwei Tools für verschiedene Jobs sind, nicht ein Gewinner und ein Verlierer. Erreiche Code-First, wenn Aufgaben echte Multi-Step-Komposition, Iteration oder Berechnung über Zwischenergebnisse echt betreffen, und du Sandbox richtig kannst. Erreiche JSON-Tool-Aufrufe, wenn Aktionen fein-körnig Kontrolle und Audit brauchen, wenn die Aufgabe einfach genug ist, dass Code-as-Action Overkill ist oder wenn die tightere Beschränkung von vordefiniert-Funktionen-nur sich auf deine Safety-Anforderungen passt. Mehrere Frameworks, incl. smolagents, unterstützen sowohl einen CodeAgent als auch einen Tool-Calling-Agent für genau diesen Grund — die Paradigma ist eine Wahl, die du pro Verwendungsfall machst, nicht eine Doktrin, die du vollständig adoptierst.
Die Unterlinie
Die Bewegung von JSON-Tool-Aufrufen zu Code-First-Agenten ist eine der sinnvollen Verschiebungen in wie Agenten im Jahr 2026 aufgebaut werden, und es wird getrieben von einer einfachen Beobachtung: einen Agent Code schreiben lassen statt einen Tool-Aufruf auf einmal zu emittieren ist effizienter und ausdrucksvoller. Weniger LLM-Aufrufe, natürliche Multi-Step-Logik und Modelle spielen zu ihrer Code-Writing-Stärke sind der Lohn, sichtbar in den ~30% Aufruf-Reduktionen Code-First-Frameworks berichten. smolagents drückt die Paradigma in ihrer reinsten, minimalsten Form; Pydantic AI bringt Type-Safety und validierte strukturierte Ausgabe zu Agent-Aufbau. Beide zeigen weg von der ersten Generation von JSON-only-Frameworks hin zu etwas Programmer-Nativerem. Die eine Regel, die du nicht überspringen kannst: Modell-generierter Code ist nicht vertrauenswürdig, also Sandbox ihn mit geringsten Privileg. Tu das, und Code-First-Agenten sind der schnellere, fähigere Weg zu bauen.
Referenzen und Ressourcen
Frameworks
Hintergrund und Analyse
- Das beste quelloffene Framework für das Aufbauen von KI-Agenten im Jahr 2026 — Firecrawl
- Python-KI-Agent-Bibliotheks-Vergleich 2026 — Pydantic AI vs Instructor vs Smolagents
- Beste Python-KI-Agent-Frameworks im Jahr 2026 — Uvik
Verwandte 1337skills-Spickzettel