Arize bringt Code Mode in die Web-Oberfläche von Phoenix: Der PXI-Agent klickt sich per Skript durch die App

Was Code Mode hier bedeutet

Code Mode heißt nach Arizes Beschreibung, dass ein Agent während einer Aufgabe Code schreibt, um etwas zu erledigen, und der Code nicht das Endergebnis ist. Das Unternehmen argumentiert, dass Code einem Modell Bedingungen, Schleifen, Batching und Verkettung an die Hand gibt. Damit werde Verhalten möglich, für das niemand ein eigenes Tool geschrieben hat.

Arize sieht zwei Probleme beim klassischen Tool Calling. Jeder Tool-Aufruf ist ein vollständiger Durchlauf: Das Modell entscheidet, erzeugt Argumente, die Harness führt aus, das Ergebnis kommt zurück, und das Modell liest es, bevor es erneut entscheidet. Drei Tools bedeuten drei Durchläufe. Hinzu kommt, dass jedes Tool für genau einen Anwendungsfall geschrieben wird, was die Möglichkeiten des Modells einschränkt.

Der Wert liege weniger darin, einem Modell einen JavaScript-Interpreter zu geben, so der Autor, sondern darin, ihm über Code Einfluss auf seine Umgebung zu verschaffen. Für Phoenix bedeutet das ein SDK: "The SDK is the things that used to be tools, now expressed as functions."

Der Schritt in eine laufende Web-App

Phoenix bot Code Mode bereits in klassischer Form an. Der MCP-Server führt vom Modell geschriebenen Python-Code in einer Monty-Sandbox aus, mit einem SDK nach dem Vorbild der REST-API und einer Funktion zum Schreiben von SQL. Neu ist laut Arize, dass Code Mode in einer Web-App läuft, in der gleichzeitig ein Mensch klickt, und das habe man anderswo noch nicht gesehen.

Die Phoenix-Oberfläche steckt voller Handler, die an Schaltflächen, Enter-Tasten und Routenwechsel gekoppelt sind. Arize hat diese Auslöser in einem automatisch generierten SDK gebündelt. PXI, der in Phoenix eingebaute Agent, schreibt ein Skript auf dem Server und schickt es an den Browser. Der Nutzer sieht eine einzeilige Beschreibung dessen, was das Skript nach eigener Angabe tun wird, und auf Wunsch den Code. Er genehmigt oder lehnt ab. Danach läuft das Skript in einem Web Worker neben der App im selben Tab. Jede Funktion, die es aufruft, wird von der Web-App protokolliert, geprüft und ausgeführt, als wäre es ein Klick auf eine Schaltfläche.

Arize nennt zwei Gründe, PXI nicht einfach die API zu überlassen. Erstens erreicht nicht alles in der Oberfläche das Netzwerk. Im Playground sind Vergleiche, Instanzen, Modelleinstellungen und Variablen lokaler Zustand im Browser-Tab, der Server sieht nur Prompts und Ausgaben. Zweitens reagiert die Synchronisierung des Frontends nicht auf Ereignisse außerhalb des Tabs. Über GraphQL angelegte Datensätze würden erst nach einem Neuladen erscheinen. Ruft ein Skript dagegen ui.dataset.create in einer Schleife auf, kann die App die Ansicht jedes Mal aktualisieren, und der zuschauende Mensch sieht es geschehen.

Der Autor nennt außerdem einen Vorteil für Entwickler: Früher berührte eine neue UI-Fähigkeit Frontend-Code, Backend-Code, eine Tool-Definition und das Prompting. Heute genügen ein Deskriptor und eine Registrierung im Frontend. Da der Katalog auf Anfrage gerendert wird, kann er sich ohne Backend-Release ändern.

Zwei Tools, 54 Operationen

Die UI-Schnittstelle von PXI besteht jetzt aus zwei Tools. search_browser_actions liefert den vollständigen Katalog der Browser-Operationen, jeweils als TypeScript-Signatur mit Doc-Kommentar. Dazu gehört die Angabe, ob die Operation auf der aktuellen Seite nutzbar ist und, falls nicht, wo sie nutzbar wird. Die Suchanfrage sortiert die Ergebnisse nur. execute_browser_action nimmt ein JavaScript-Programm entgegen, eine einzeilige Zusammenfassung für den Nutzer und, falls das Skript etwas verändert, eine Beschreibung der Änderungen zur Genehmigung.

Der Katalog umfasst 54 Operationen, abgeleitet aus den 58 gelöschten Tools. Die meisten wurden direkt übernommen, ein Tool wurde dabei zu einer Funktion. Lesezugriffe auf Serverdaten entfielen, weil GraphQL über Bash sie als derselbe authentifizierte Nutzer bereits abdeckt.

Arize berichtet, dass das alte Design im Playground 33 Tools anbot, die bei jeder Anfrage rund 14.700 Token kosteten, während die zwei neuen Tools auf jeder Seite etwa 2.300 kosten. Ein Ablauf, der zehn Modellrunden als zehn Tool-Aufrufe brauchte, wird zu einer Runde mit einem Skript. Extremfälle mit 15 Hin-und-her-Runden seien auf ein einziges Skript zusammengeschrumpft, sagt der Autor, allerdings nur dort, wo der nächste Schritt eine Berechnung ist und kein Urteil.

Ein Skript, das PXI selbst geschrieben hat

Die Playground-Oberfläche begrenzt Vergleiche auf vier Instanzen. Laut Arize schrieb PXI ein Skript, das diese Grenze mit nur einer Instanz umgeht: Es listet jedes eingebaute Modell auf, setzt dann für jedes das Modell, führt es aus, liest die Ausgabe, speichert das Ergebnis und gibt am Ende alles zurück. Niemand habe ein Tool gebaut, um fünfzig Modelle zu vergleichen, merkt der Autor an. Das Modell habe eines aus drei Operationen und einer for-Schleife zusammengesetzt.

Der Ablauf, auf den sich Arize in der Entwicklung am stärksten stützte, ist größer: Ausgehend von einem leeren Playground und einem Datensatz mit Ein- und Ausgaben soll PXI einen Prompt bauen, der einen Evaluator besteht. Dafür muss es den Prompt schreiben, den Datensatz laden, Evaluatoren anlegen, den Playground ausführen, bewertete Ergebnisse lesen und den Prompt so lange anpassen, bis alles besteht. Arize nennt das die UI-intensivste Aufgabe, die sich PXI stellen lasse, und diejenige, bei der weniger Hin-und-her-Runden am meisten zählen.

Beim Aufbau des Katalogs habe man sich bei json-render bedient, sagt Arize. Die Bibliothek lässt ein Modell aus vorhandenen React-Komponenten eine Oberfläche zusammenstellen, anhand eines Katalogs aus Namen, Beschreibungen und typisierten Verträgen.

Was das für Phoenix-Nutzer bedeutet

Für Nutzer von Phoenix beschreibt Arize folgende praktische Effekte: weniger Wartezeit durch Runden, wenn PXI mehrstufige Playground-Aufgaben übernimmt, eine kleinere Token-Last pro Anfrage und einen Genehmigungsschritt, bevor ein Skript läuft, das den Zustand ändert. Weil die Aktionen über dieselben Handler laufen wie Klicks, kann der Nutzer zusehen, wie Änderungen in der Seite erscheinen.