Pi hat den brandneuen Agent Harness veröffentlicht und das MCP, über das er ein ganzes Jahr lang geschimpft hat, in seinen Kern integriert.

Pi erlebt das größte Update in diesem Jahr: Das Projekt wurde auf Version 1.0 aktualisiert, Code Mode und das native MCP sind offiziell in der stabilen Version verfügbar; Am selben Tag hat das Team auch ein brandneues Harness namens Pi Durable vorgestellt.

Diese Änderungen wurden schon seit einiger Zeit vorbereitet. Im vergangenen Jahr hat das MCP-Protokoll sechs bis sieben Anpassungen durchlaufen und ist allmählich zu einem wirklich nutzbaren Reifegrad gelangt; Die Architektur von Pi Durable hat ebenfalls acht Iterationen durchlaufen. Ein Protokoll, das einst von Pi öffentlich abgelehnt wurde, ist in den Kern eingezogen, und ein wiederholt verfeinerter Langzeit-Agent-Framework wird gleichzeitig vorgestellt, was bedeutet, dass Pi beginnt, sich von einem Endgerät-Programmieragenten zu einer vollständigen Agent-Infrastruktur zu entwickeln.

Für Entwickler besteht der direkteste Vorteil von Pi Durable darin, dass eine große Menge an wiederholtem Code entfällt. Früher mussten Entwickler beim Erstellen von persönlichen Assistenten, Slack-Bots oder anderen Agent-Anwendungen auf Pi selbst eine Datenbank entwerfen, um Nachrichten zu speichern, und dann den Start des Agenten, die Aufgabenplanung, den Prozessabsturz und die Zustandswiederherstellung verarbeiten. Einige Entwickler schätzen, dass Pi Durable direkt die Hälfte ihres Codes ersetzen kann, da alle diese peripheren Details vom Framework übernommen werden.

Dies erklärt auch, warum einige der Meinung sind, dass Pi Durable die Grundlage für viele Agent-Workflows und Anwendungen werden wird. Früher hat jedes Unternehmen wiederholt Dialogprotokolle, Aufgabenpersistenz, Fehlerwiederherstellung und Sitzungsverzweigung implementiert – Pi Durable schließt diese Lücke genau. Es speichert Benutzernachrichten, Modellantworten, Werkzeugausführungsergebnisse und Aufgabenstatus; Nach einem Prozessabsturz kann der Agent von der unterbrochenen Stelle fortfahren. Operationen, die sicher wiedergegeben werden können, werden neu ausgeführt, während Operationen, die zu doppelten Nebeneffekten führen könnten, nicht leichtfertig erneut ausgeführt werden.

Mario Zechner fasst es sehr einfach zusammen: Der Agent startet, ruft Werkzeuge auf, und der Prozess stürzt plötzlich ab. Nach dem Neustart sollte er genau von der ursprünglichen Stelle fortfahren, ohne dass der Mensch erneut „fortfahren“ eingeben muss, und die Werkzeugergebnisse sowie die Stream-Ausgabe dürfen nicht verloren gehen. Armin Ronacher konzentriert sich mehr auf die dahinterstehende Zuverlässigkeit: Das Modell selbst ist bereits unvorhersehbar genug. Wenn der Agent beginnt, sich aus der Echtzeitüberwachung des Menschen zu lösen, sollte die externe Aufgabenplanung und Fehlerwiederherstellung zumindest stabil und verständlich sein.

Eine weitere umstrittene Änderung stammt von MCP.

Im vergangenen Jahr waren Pi-Gründer Mario Zechner und Flask-Gründer Armin Ronacher die unverblümtesten Kritiker von MCP. Auf der offiziellen Website von Pi stand sogar einst stolz geschrieben: „Keine Unterstützung für MCP“. Sie kritisierten öffentlich, dass MCP aufgebläht ist, Tokens verschwendet und dass Agenten mit Bash-, CLI-Werkzeugen und Code oft viel effizienter arbeiten.

Heute wurden die Modelle bereits stärker im Zusammenhang mit MCP trainiert, und MCP Server sowie das Protokoll sind allmählich ausgereift, sodass Pi schließlich beschlossen hat, es offiziell zu integrieren. Es lädt jedoch nicht alle Werkzeugnamen, Parameter und Beschreibungen auf einmal in den Kontext, sondern lädt sie bei Bedarf über Werkzeugsuche und schrittweise Offenlegung.

Code Mode, der zusammen mit MCP in die stabile Version aufgenommen wurde, erlaubt es dem Agenten, ein Stück JavaScript-Programm in der QuickJS-Sandbox zu schreiben und auszuführen. Er kann Werkzeuge parallel aufrufen, Daten filtern, Duplikate entfernen und Berechnungen durchführen, und schließlich nur die wirklich nützlichen Ergebnisse an das Modell zurückgeben. Eine große Menge an Zwischendaten verbleibt in der Sandbox, wodurch der Token-Verbrauch, die Betriebskosten und die Kontextbelastung reduziert werden.

Code Mode hat auch eine sehr interessante Fähigkeit: Er kann das System-1-Modell, beispielsweise Jev, direkt innerhalb der JavaScript-Schleife aufrufen. Angenommen, Pi erhält 200 GitHub-Kommentare über MCP, dann kann Code Mode sie einzeln an Jev übergeben, um zu beurteilen, ob der Benutzer unzufrieden ist, ob das Problem dringend ist und zu welcher Kategorie es gehört. GPT oder Claude müssen am Ende nur die klassifizierten und zusammengefassten Ergebnisse sehen. MCP ist für den Datenabruf zuständig, Code Mode für die Orchestrierung und Verarbeitung, Jev übernimmt eine große Anzahl schneller Beurteilungen, und die fortschrittlichen Modelle konzentrieren sich auf hochrangige Schlussfolgerungen.

Aber einige Pi-Benutzer sind nicht glücklich. Jemand kommentierte: „Also fängt Pi jetzt auch an, Müll anzuhäufen.“ Dieser Satz steht für die Sorge der Minimalismus-Fraktion: Werden Pi mit der Aufnahme von MCP, Code Mode und weiteren Funktionen in den Kern allmählich zu dem aufgeblähten Harness, das es früher zu vermeiden versuchte?

Armin antwortete, dass der Inhalt, der standardmäßig von Pi geladen wird, nicht größer ist als zuvor. Code Mode ist auch kein „Umweg über Bash“: Bash führt Shell-Werkzeuge aus, während Code Mode es dem Modell erlaubt, direkt im Inneren des Harness nach Werkzeugen zu suchen, diese zu kombinieren und zu orchestrieren. Pi übernimmt das MCP-Ökosystem und kontrolliert gleichzeitig weiterhin die Belastung, die es dem Kontext auferlegt.

Interessanterweise lässt das Pi-Team den Agenten zwar mehr Werkzeuge verwenden und länger laufen, ist aber immer noch nicht bereit, alle Arbeiten ihm bedenkenlos zu überlassen. Mario gab offen zu, dass der Agent viele kleine Probleme beheben kann. Sobald es um Design und Architektur geht, stapelt er oft nur lokal Code und „schmeißt einen Haufen Mist in Ihre Codebasis“, was die Situation noch verschlechtert.

Wenn der Agent endlich Abstürze überwinden und mehrere Stunden oder sogar Tage lang kontinuierlich laufen kann, tauchen neue Probleme auf: Er hört nicht so leicht auf, aber wer garantiert, dass er die Codebasis nicht auf dem Weg zu einem Misthaufen macht?

Kürzlich haben Mario Zechner und Armin Ronacher in einem Podcast ausführlich über das Design von Pi Durable, die Fähigkeitsgrenzen der KI-Programmierung und warum Pi in Zukunft nicht nur ein Programmieragent sein möchte, gesprochen. InfoQ hat dieses Gespräch übersetzt und zusammengestellt, im Folgenden der bearbeitete vollständige Inhalt.

Version für Ungeduldige

Frage: Warum lässt man den Codierungsagenten nicht Fehler beheben?

Armin: Weil es fast unmöglich ist, ein Problem zu lösen, ohne den Code zu berühren. Je mehr Sie dem vollautomatischen Prozess vertrauen, desto natürlicher wächst die Codebasis mit jedem Bugfix.

Frage: Ist der von KI geschriebene Code überhaupt brauchbar?

Mario: Es hängt von der Ebene ab. Viele Dinge in der TUI-Bibliothek von Pi sind reiner Slop, ich habe bis heute nicht eine einzige Zeile Code der Markdown- und Textkomponenten durchgelesen. Das ist mir egal, solange die Tests bestehen und die Darstellung korrekt ist. Aber sobald es um Design oder Architektur geht, muss der Mensch eingreifen, weil der Agent nur „vor Ort einen Haufen Mist in die Codebasis wirft“ und die Situation verschlechtert.

Frage: Haben sich die Architekturfähigkeiten der Modelle überhaupt verbessert?

Armin: Nein, sie sind sogar möglicherweise zurückgegangen. Ihre Ausgaben werden immer komplexer, ihre Ausdrucksweise wird immer seltsamer, und sie sind voll von technischen Begriffen, die aus Wörterbüchern mit Synonymen stammen.

Frage: Warum kann das Modell Architektur nicht lernen?

Mario: Weil Architektur der einzige Teil der Programmierung ist, der nicht in Text kodiert ist und daher von LLMs nicht erlernt werden kann. Sie können leicht Trainingsdaten für Cybersicherheit, Webseitenerstellung und Frontendentwicklung erstellen, aber für den Prozess des „Bauens“ selbst, also den Prozess des Entwerfens und Architektierens eines Dings, gibt es keine Trainingsdaten.

Frage: Welche Aufgaben können Modelle also besonders gut erledigen?

Mario: Aufgaben mit einem Oracle, die binär sind und gefuzzed werden können. Wenn Sie ein Oracle haben, das dem LLM sagen kann, ob das, was es getan hat, richtig oder falsch ist, haben Sie im Grunde gewonnen. Die Rust-Neuimplementierung von Bun basiert genau darauf: Lassen Sie die Testsuite laufen.

Frage: Was ist Pi Durable?

Mario: Der Agent startet im Prozess, ruft Werkzeuge auf, der Prozess stürzt ab, wird neu gestartet und fährt genau am Breakpoint fort. Pi Durable verwendet jedoch kein Event Sourcing, sondern ein „Effekt-Sandwich“ aus „Absicht, Ausführung, Ergebnis“ und speichert den Anwendungszustand mit versionierten Dokumenten.

Frage: Ist das Konzept des persönlichen Agenten vertrauenswürdig?

Armin: Millionen von Menschen verwenden Dinge wie den Grok Bot und melden alles auf ihren Geräten an – ich denke, das ist eine Katastrophe, alle diese Unternehmen stehen vor einer Katastrophe.

Frage: Was möchte Earendil als Nächstes tun?

Armin: Wir wollen kein Unternehmen für Codierungsagenten werden. Es gibt zwei Linien: Erstens Produkte entwickeln, bei denen auch Nicht-Ingenieure Spaß haben können; zweitens Infrastruktur aufbauen, mit der jeder seinen eigenen Agenten erstellen kann.

Frage: Was ist die zukünftige Richtung von Pi?

Mario: Ich arbeite kürzlich an PIM (Pi Mobile) auf dem Handy. Es geht nicht mehr um „ich und Clanker“, sondern um viele Clanker auf vielen Geräten, die mit vielen Menschen sprechen.

Agenten beheben Fehler – und werfen auch einen Haufen Mist in die Codebasis

0xSero: Warum habt ihr beschlossen, Pi zu übernehmen?

Armin: Tatsächlich haben wir lange versucht, Mario zu uns zu holen, bevor wir Pi übernommen haben. Nach der verrückten Phase um OpenClaw ergab sich die Gelegenheit, und Mario war damit einverstanden. Wir arbeiten an „formbarer Software (malleable software)“, und Pi ist eine sehr gute Version früher Experimente in diesem Bereich, also war die Übernahme logisch.

Mario: Ich wäre ein Idiot, Pi zu entwickeln – jetzt bin ich hier gefangen und muss es weiter pflegen.

0xSero: Glaubst du wirklich, dass du von diesem Projekt gefangen bist? Es ist so erfolgreich, dass es nicht sinnvoll wäre, es einzustellen.

Mario: Wie Armin habe ich auch eine lange Open-Source-Geschichte, nur kommen wir aus verschiedenen Bereichen. Sobald mein Open-Source-Projekt Nutzer hat, pflege ich es dumm weiter für alle, auch wenn sie keinen Cent bezahlen. Manchmal sind die negativen Rückmeldungen sehr zeitraubend.

Aber mein Ziel ist jetzt nicht, Pi abzugeben, sondern mehr Menschen an der Entwicklung von Pi teilhaben zu lassen, sodass der Faktor „ich muss anwesend sein“ abnimmt. Bisher haben wir dieses Ziel ziemlich gut erreicht – selbst wenn ich morgen sterbe, liegt Pi immer noch in zuverlässigen Händen.

0xSero: Wenn es um die Suche nach Mitwirkenden geht – was hat sich da geändert? Immer mehr Menschen verwenden KI. Ich weiß, dass du früher nicht mochtest, wenn andere wahllos einen Haufen KI-Code zusammenkleistern. Wie ist die Erfahrung jetzt?

Mario: Sehr schlecht. Anders ausgedrückt: Wenn ich nicht den Großteil der Zeit von Februar bis etwa Juli damit verbracht hätte, Pi zu pflegen, Issues zu prüfen und zu beheben, wäre Pi Durable viel früher veröffentlicht worden.

Das Problem ist, dass Agenten derzeit noch nicht dabei helfen können, Issues zu beheben, zumindest nicht bei meinem Projekt. Ich vertraue ihnen nicht genug, um sie beurteilen zu lassen, welcher gemeldete Issue wirklich unsere Zeit wert ist und behoben werden muss. Also muss ich zumindest alle eingereichten Issues persönlich durchgehen.

Können Agenten Issues beheben? Natürlich. Der Schlüssel ist, wie gut sie es machen. Viele Probleme können tatsächlich an Agenten übergeben werden, besonders sehr kleine Probleme. Aber sobald es um Design oder Architektur geht, braucht es immer noch menschliche Beteiligung, weil Agenten oft nur lokal einen Haufen Mist in die Codebasis werfen und die Situation verschlechtern. Stimmt's, Armin?

Armin: Das Problem mit Agenten ist auch, dass sie das aktuelle Problem definitiv lösen, aber es ist fast unmöglich, es zu beheben, ohne den Code zu erweitern. Das ist seltsam, weil viele Probleme nach der Behebung eigentlich nicht zu einer Erhöhung des Netto-Codevolumens der Codebasis führen sollten.

Natürlich ist es ironisch, dass ich das sage – ich reiche oft PRs ein, die 200 Dateien ändern und 20.000 Zeilen Code hinzufügen, das ist erschreckend. Ich bin selbst ein Opfer des Missbrauchs von „Clanker“ (der Spitzname für KI). Aber Software sollte sich nicht so entwickeln. Besonders eine vollständig automatisiert gewartete Codebasis wird fast zwangsläufig mit jedem Bugfix ständig größer.

Wann ist KI-Müllcode akzeptabel?

0xSero: DHH hat sich vollständig dieser Arbeitsweise des „Zusammenkleistern von Code mit KI“ verschrieben. Ich nenne meine eigene Arbeit „Slop-Operationen“, weil ich im Grunde alles mit Modellen erledige. In gewisser Weise fühle ich mich tatsächlich viel dümmer als früher, aber andererseits ist die Effizienz extrem hoch. Wenn Ihre Arbeit nicht darin besteht, etwas zu bauen, das von Millionen von Menschen kopiert und verwendet wird, sehe ich keinen Nachteil darin, schnell ein Skript zusammenzukleben. Zum Beispiel erstelle ich kürzlich Docker-Container für bestimmte Hardwarekombinationen, damit das Modell in einer zufälligen VRAM- und RAM-Konfiguration optimal läuft. Das funktioniert immer gut, Design und Architektur sind nicht so wichtig, solange das Ergebnis läuft und tut, was es tun soll. Aber ihr habt dieses Privileg nicht – ihr baut Dinge, die von Millionen von Menschen verwendet werden.

Mario: Natürlich haben wir das auch. Viele Dinge in Pi sind reiner zusammengekleisterter Slop. Der Unterschied liegt nur darin, auf welcher Ebene der Mensch eingreift und auf welcher Ebene Sie dem Agenten vertrauen, dass er etwas Brauchbares erzeugt, ohne sich darum zu kümmern, wie genau er es implementiert.

Nehmen wir als Beispiel die TUI-Bibliothek von Pi: Das ursprüngliche Design habe ich Anfang 2025 für ein anderes Projekt handgeschrieben. Das Design war sehr robust und minimalistisch, ich wusste, dass es der realen Welt standhalten würde, auch wenn es nicht perfekt ist, reicht es aus. Aber als ich tatsächlich angefangen habe, Pi zu bauen, habe ich nicht gesagt „schreib mir ein Markdown-Komponente, eine Text-Komponente, eine Editor-Komponente“ – ich habe dem Agenten direkt gesagt: Das ist die API