So habe ich Pi als Coding-Agent eingerichtet: LSP, MCP, Skills und Erweiterungen

Man fragt mich regelmäßig, wie ich meinen Code-Agenten konfiguriert habe. Die kurze Antwort lässt sich in einen Satz fassen: Ich nutze Pi und füge nur genau die Bausteine hinzu, die ich wirklich brauche. Die wirklich nützliche Antwort erfordert jedoch einen ganzen Artikel.

Pi ist nicht der spektakulärste Agent, den man in einem Video vorführen kann. Er kommt nicht mit einer Kontrollzentrale, zwölf digitalen Charakteren und einem Knopf, der angeblich ein ganzes Team ersetzt. Auf den ersten Blick wirkt er wie eine Schnittstelle in einem Terminal. Genau das hat mir gefallen: Statt mir eine komplexe Fabrik aufzuzwingen, gibt er mir einen kleinen, verständlichen und erweiterbaren Kern an die Hand.

Warum Minimalismus mehr zählt als eine lange Liste von Funktionen

Ich habe dieses Szenario bei vielen Softwareprodukten schon erlebt. Am Anfang erfüllt ein Programm eine Aufgabe hervorragend. Dann fügt jede Version einen Reader, einen Konverter, einen Synchronisierer, einen Assistenten, einen Store und drei Panels hinzu, an die sich niemand mehr erinnert. Am Ende startet die Software wie ein kleines Betriebssystem, obwohl ich eigentlich nur eine Disc brennen, eine Datei bearbeiten oder einen Befehl ausführen wollte.

Pi folgt der umgekehrten Logik. Das erinnert mich daran, was ich an einer minimalen Linux-Distribution schätze: Der Kern beansprucht nicht, meine ideale Umgebung zu erraten. Ich baue schrittweise die auf, die zu mir passt. Diese Schlichtheit ist keine ästhetische Laune. Je weniger Regeln, Werkzeuge und unnötige Server der Agent lädt, desto besser verstehe ich, was er tut, desto weniger Tokens verschwendet man und desto leichter lässt sich die Ursache für seltsames Verhalten finden.

Man muss jedoch ehrlich sein: „Minimal“ bedeutet nicht „magisch einfach“. Ein erweiterbares Werkzeug gibt mir auch die Wahl, Erweiterungen zu installieren und zu pflegen. Pi passt zu mir, weil ich die Mechanik gerne nachvollziehe. Wenn du ein vollständig vorkonfiguriertes Produkt suchst, kann diese Freiheit wie zusätzliche Arbeit wirken.

Installation und Arbeitsbereich

Die offizielle Installation fasst sich in einem Befehl unter macOS oder Linux zusammen. Wie immer bei einem Remote-Skript rate ich dazu, die Herkunft zu prüfen, bevor du es ausführst:

curl -fsSL https://pi.dev/install.sh | sh

Man kann auch über npm gehen — mit einer aktuellen Node.js-Version — und es gibt ein separates Verfahren für natives Windows. Sobald installiert, prüfe ich sofort die Version, wechsle in das Projektverzeichnis und starte Pi von dort aus. Das Startverzeichnis zählt: Es dient dazu, die Anweisungen zu finden und die Sessions zu bündeln.

pi --version
cd /pfad/zum/projekt
pi

Die hier gezeigte Konfiguration entspricht Pi 1.0.4, der Version, die ich während meines Tests verwendet habe. Das Projekt entwickelt sich schnell weiter: Der Befehl pi update aktualisiert eine Installation, die mit dem Skript erfolgte, während eine npm- oder Nix-Installation über ihren eigenen Paketmanager aktualisiert wird. Das ist ein kleiner, aber wichtiger Punkt, der verhindert, dass man glaubt, eine Funktion fehle, obwohl man einfach nur eine alte Version startet.

Pi läuft im Terminal, aber das Terminal ist kein Detail. Ich nutze Kitty und seine Tabs, um meine Projekte zu trennen, und Zellij innerhalb jedes Tabs. Ich halte den Code oft in einem Panel, Pi in einem zweiten, den Entwicklungsprozess in einem dritten und Tests, Logs oder eine Remote-Umgebung in einem vierten. So sehe ich sofort, ob die Änderung kompiliert, der Server neu startet und sich die Fehler ändern, während der Agent arbeitet.

Das ist keine Pflicht: tmux, ein klassisches Terminal oder das des Editors funktionieren ebenfalls sehr gut. Es geht nicht darum, meinen Bildschirm pixelgenau nachzubilden, sondern das einzelne Terminal zu vermeiden, in dem Pi, der Server und die Tests sich gegenseitig verdrängen. Ein Agent wird viel angenehmer, wenn seine Arbeit beobachtbar bleibt.

Die Benutzerkonfiguration befindet sich in ~/.pi/agent/. Pi kann auch eine projektspezifische Konfiguration lesen. Diese Trennung ist gesund: Meine persönlichen Einstellungen und Zugangsdaten dürfen nicht in das Repository gelangen, während Architekturrichtlinien und Testbefehle mit dem Team geteilt werden können.

Auf Projektebene leben ausführbare Einstellungen eher in .pi/: .pi/settings.json, .pi/mcp.json, lokale Erweiterungen, Skills, Prompts und Themen. Pi lädt diese Konfiguration erst nach dem Vertrauensentscheid des Projekts. Kontextdateien werden hingegen im aktuellen Verzeichnis und seinen Elternverzeichnissen entdeckt. Nach einer manuellen Änderung lädt /reload die Ressourcen neu, ohne einen vollständigen Neustart zu erzwingen.

Die genaue Verzeichnisstruktur kann sich mit Pi weiterentwickeln. Ich prüfe daher immer die Dokumentation der installierten Version, statt blind eine vor sechs Monaten gefundene Konfiguration zu kopieren.

Das Modell zuerst, das Zubehör danach

Ein Agent ohne Modell ist nur eine schöne Schleife von Werkzeugen. Der erste echte Schritt besteht daher darin, den Anbieter mit /login zu verbinden und dann das Modell mit /model zu wählen. Der Denklevel lässt sich mit /thinking einstellen, wenn das Modell dies unterstützt.

Für einen integrierten Anbieter ziehe ich diesen Weg vor, statt sofort ein großes models.json zu basteln. Diese Datei wird nützlich für einen kompatiblen Endpunkt, ein lokal bereitgestelltes Modell via Ollama, LM Studio oder vLLM oder eine interne Infrastruktur. Lokal bedeutet übrigens nicht automatisch schnell: Ein kleines Modell kann reichen, um zu suchen oder zu klassifizieren, aber eine Refaktorierung über ein Monorepo hinweg erfordert viel mehr Denkvermögen und Kontext.

Hier ein bewusst minimales Beispiel für Ollama. Der Schlüssel ist fiktiv — Ollama ignoriert ihn — und die Adresse zeigt auf die lokale Maschine. Für einen authentifizierten Endpunkt verweise ich auf eine Umgebungsvariable, statt das Geheimnis im Klartext zu notieren.

{
  "$schema": "https://pi.dev/schemas/models.schema.json",
  "providers": {
    "ollama": {
      "baseUrl": "http://localhost:11434/v1",
      "api": "openai-completions",
      "apiKey": "ollama",
      "models": [
        { "id": "qwen2.5-coder:7b" }
      ]
    }
  }
}

Der Modellname reicht nicht aus. Man muss auch seine Fähigkeiten, den Kontextfenster und die Denklevel beachten. Manche bieten nur low, medium und high an; andere fügen xhigh oder max hinzu. Pi beschränkt /thinking normalerweise auf die vom Modell deklarierten Stufen. Im Selektor speichert Ctrl+S das Modell oder den Standardlevel, während Ctrl+P schnelles Durchsuchen der erlaubten Modelle ermöglicht. Eine Session merkt sich auch Modellwechsel: Wird sie fortgesetzt, stellt sie die Wahl wieder her, ohne den Standard für neue Sessions zu ändern.

Ich schreibe niemals einen API-Schlüssel in AGENTS.md oder in ein Beispiel für das Repository. Zugangsdaten gehören in den dafür vorgesehenen Mechanismus. Das klingt offensichtlich, aber Agenten lesen genau die Dateien, die man ihnen gibt: Ein Schlüssel, der „temporär“ in einer Anweisung steht, landet sehr schnell in einer Session, einem Log oder einem Commit.

Warum ich den System-Prompt in Ruhe lasse

Die Versuchung ist groß, SYSTEM.md sofort umzuschreiben, um einen „perfekten“ Agenten zu erhalten. Das ist auch eine gute Methode, um Anweisungen zu löschen, die Pi für seine Werkzeuge und seine Oberfläche nutzt. Ich ersetze das System nur, wenn ich genau weiß, was ich entfernen will und welche Konsequenzen ich akzeptiere.

In den meisten Projekten reicht AGENTS.md. Dort beschreibe ich die Architektur, Befehle, Konventionen, was verboten ist und die Definition einer abgeschlossenen Aufgabe. Eine allgemeine Regel kann in die Benutzerdatei; eine Repository-Regel bleibt im Repository. So gewinne ich einen konsistenten Agenten, ohne seinen Motor umzubauen.

# Projekt
- Vor einem Architekturvorschlag den bestehenden Code lesen.
- Nach jeder Änderung die betroffenen Tests ausführen.
- Bereits bereitgestellte Migrationsdateien niemals ändern.
- Vor jeder irreversiblen Aktion das Diff und die Risiken vorstellen.
- Die in package.json definierten Befehle nutzen.

LSP: Die erste Erweiterung, die ich installiere

Wenn ich nur eine einzige Verbesserung für die Codearbeit behalten dürfte, wäre es das Language Server Protocol. Ohne LSP inspiziert der Agent das Projekt mit Textsuche, liest Dateien und leitet Beziehungen ab. Das ist nützlich, aber er bleibt der vom Compiler und Editor verstandenen Struktur teilweise blind gegenüber.

Mit einem Language-Server kann er fragen, wo ein Symbol definiert ist, welche Referenzen darauf zeigen, welcher Typ erwartet wird, welche Fehler existieren und welche Dateien von einem Umbenennen betroffen sein werden. Für TypeScript braucht man den TypeScript-Server; für Go gopls; für jede Sprache die passende Komponente. Die Pi-Erweiterung ersetzt diesen Server nicht: Sie gibt ihm Zugang zu dessen Antworten.

Das ist eine zweischichtige Architektur, die ich unzureichend erklärt hatte. Man muss zuerst den echten Language-Server auf der Maschine installieren und dann die Erweiterung, die seine Funktionen Pi zugänglich macht. Nur die Erweiterung zu installieren, lässt gopls, typescript-language-server, Pyright oder rust-analyzer nicht einfach so erscheinen.

pi install npm:pi-lsp-extension

# dann in Pi
/reload
/lsp doctor

Name und Optionen der Erweiterung können sich ändern, und es gibt mehrere LSP-Implementierungen im Katalog. Ich prüfe daher die Quelle und wähle die, die zu meiner Sprache passt. Die nützliche Kontrolle ist einfach: Der Server muss aktiv erscheinen, und eine Anfrage nach Definition, Referenzen oder Diagnosen muss das LSP-Werkzeug wirklich auslösen. Nur ein installiertes Paket zu haben, beweist nicht, dass der Agent es nutzt.

Der Unterschied ist nicht theoretisch. Bei einer Referenzsuche fand grep dreißig Vorkommen. Der LSP identifizierte fünfunddreißig, verteilt auf drei Dateien, weil er das Symbol verstand und nicht nur die Zeichenkette. Fünf vergessene Referenzen reichen völlig aus, um ein „einfaches“ Umbenennen in einen Freitagabend-Bug zu verwandeln.

LSP macht das Modell nicht unfehlbar. Es liefert ihm einfach eine genauere Karte. Ich bitte ihn immer noch, Implementierungen zu lesen, Tests zu starten und mir das Diff zu zeigen. Aber ich bevorzuge einen Agenten, der die Compiler-Karte befragt, gegenüber einem Agenten, der die Straßen errät, indem er auf Straßenschilder schaut.

RAG: Nützlich für Wissen, nicht als Dekoration

Die Textsuche beantwortet gut „Wo erscheint diese Funktion?“. Sie antwortet schlechter auf „Welche Dokumente erklären unsere Aufbewahrungsrichtlinie?“, wenn die Texte andere Wörter verwenden. Genau hier kann ein RAG-System interessant werden.

Das Prinzip ist einfach: Dokumente werden zerteilt, in Vektoren umgewandelt und in einer passenden Datenbank gespeichert, zum Beispiel Qdrant. Die Frage erfährt die gleiche Transformation. Die Suche bringt semantisch nahe Passagen zurück, auch wenn sie die Suchbegriffe nicht exakt enthalten. Pi kann sie anschließend als Kontext nutzen.

Ich habe einen solchen Dienst über MCP angebunden, mit einigen klaren Aktionen: Dokumente hinzufügen, suchen, löschen und Status prüfen. Das funktioniert gut für umfangreiche Dokumentation, technische Entscheidungen, einen Korpus von Verfahren oder mehrere Repositories. Für ein kleines Projekt mit zwanzig Dateien ist es oft eine unnötige Komplikation. LSP und eine klassische Suche sind dort einfacher, ressourcenschonender und leichter zu kontrollieren.

So sieht mein lokaler RAG aus

Meine Installation ist kein mysteriöses Cloud-Gebilde. Qdrant läuft in Docker als Vektordatenbank. Ein kleiner RAG-Dienst, gestartet neben dem Modellserver, konvertiert Dokumente in Embeddings und bietet einige Operationen an: Hinzufügen, Suchen, Löschen und Gesundheitsprüfung. Ein MCP-Server übersetzt diese Operationen anschließend in Werkzeuge, die Pi aufrufen kann. Ich kann die Prozesse sehen, den Dienst neu starten und Qdrant unabhängig vom Agenten abfragen.

Pi
 └─ Lokaler MCP local-rag
     └─ RAG-Dienst
         ├─ Embeddings
         └─ Qdrant in Docker

In meinem Fall dient dieser RAG auch dazu, einen großen Feed von Veröffentlichungen zu filtern. Eine wörtliche Suche nach „rosa Lieferwagen“ wird nicht unbedingt einen Text über einen „roten Lastwagen“ zurückgeben, während die semantische Nähe beide Themen als nachbar einstufen kann. Ich nutze dieses Prinzip, um Inhalte mit meinen Interessen zu vergleichen und zu klassifizieren. Das ist ein gutes Beispiel für das, was RAG wirklich bringt: Nicht eine magische Erinnerung, sondern eine retrieval by meaning.

Mein Satz an MCP-Servern, und warum ich nicht alle aktiviere

MCP bietet eine gemeinsame Möglichkeit, Werkzeuge und Ressourcen für den Agenten bereitzustellen. Das ist praktisch, daher verlockt das Ökosystem schnell dazu, fünfzehn davon zu installieren. Ich widerstehe dieser Versuchung. Jeder Server fügt Beschreibungen, Berechtigungen, Abhängigkeiten, manchmal Geheimnisse und eine neue Art hinzu, zu versagen. Meine mcp.json ist keine Sammlung: Sie ist eine Werkzeugkiste für die Arbeit.

Aktuelle Versionen von Pi können MCP direkt verwalten. Ein Server kann global in ~/.pi/agent/mcp.json oder projektspezifisch in .pi/mcp.json sein. Hier ist der Zyklus, den ich nutze, um nicht „im JSON geschrieben“ mit „funktionsfähig“ zu verwechseln:

pi mcp add -l docs --url https://example.com/mcp \
  --bearer-token-env-var DOCS_TOKEN
pi mcp list

# in einer bereits offenen Session
/reload
/mcp

pi mcp list verbindet sich mit aktivierten Servern und zeigt Werkzeuge oder Fehler an. In Pi dient /mcp dazu, Verbindungen zu inspizieren, einen Server neu zu starten, sich per OAuth zu verbinden und die Exposition zu ändern. Ich halte normale Werkzeuge im codemode, häufig genutzte kleine Werkzeuge in direct, große Kataloge in deferred und alles Gefährliche oder Unnötige in hidden. Diese Unterscheidung begrenzt die Menge der an das Modell gesendeten Beschreibungen.

Context7 für aktuelle Dokumentation

Das Modell kennt eine Bibliothek vielleicht gut, aber sein Gedächtnis entspricht einem vergangenen Zustand. Eine Methode könnte umbenannt worden sein, eine Option ist verschwunden oder ein altes Beispiel kompiliert nicht mehr. Context7 ermöglicht es dem Agenten, die aktuelle Dokumentation einer Bibliothek genau dann abzurufen, wenn er sie braucht. Das verhindert eine besonders ärgerliche Art von Halluzinationen: Code, der plausibel klingt, aber eine nicht existierende API aufruft.

SearXNG zum Suchen ohne Browsersteuerung

Ich nutze auch eine SearXNG-Instanz, die über MCP exponiert wird. Der Agent kann eine Suche starten, strukturierte Ergebnisse lesen und mehrere Motoren kreuzen, ohne für jede Frage graphisch einen Browser zu öffnen. Um einen aktuellen Fehler zu prüfen, Dokumentation wiederzufinden oder mehrere Ansätze zu vergleichen, ist das viel leichter.

SearXNG ist ein Metasuchmaschine: Je nach Konfiguration aggregiert sie unter anderem Web-, Enzyklopädie- und Code-Repository-Ergebnisse. Der Aufruf erfolgt per HTTP und das Ergebnis kommt in strukturierter Form zurück, zum Beispiel als JSON. Context7 und SearXNG sind also keine Konkurrenten. Der erste beantwortet „Wie ist die aktuelle API dieser Bibliothek?“; der zweite „Was findet man heute zu diesem Fehler oder diesem Thema?“.

Das entbindet nicht davon, die Quellen zu prüfen. Ein Suchergebnis ist keine Wahrheit und eine Webseite kann feindselige Anweisungen für Agenten enthalten. Ich behandle abgerufene Inhalte als unzuverlässige Daten, niemals als neue Systemregel.

Chrome DevTools und Playwright machen nicht denselben Job

Für die Webentwicklung ist der Chrome-DevTools-Server einer der praktischsten Ergänzungen. Der Agent öffnet die Seite, klickt, füllt Felder, inspiziert das DOM, liest die Konsole, untersucht Netzwerk-Anfragen, Antworten, Cookies oder lokalen Speicher und macht Screenshots. Er beschränkt sich nicht mehr darauf zu behaupten, der Button sollte funktionieren: Er kann sehen, was passiert.

Ich nutze den ersten, um zu ermitteln, während ich baue, und den zweiten, um das erwartete Verhalten in einen dauerhaften Test zu verwandeln. Beide können in einer Seite klicken, aber das ist kein Grund, sie zu verwechseln.

PostgreSQL, ja; Postman, nicht unbedingt

Ein begrenzter PostgreSQL-Zugang ermöglicht es dem Agenten, das Schema zu lesen, eine langsame Abfrage zu untersuchen, ein EXPLAIN zu starten, einen fehlenden Index zu erkennen oder eine Migration vorzubereiten. Ich gebe ihm vorzugsweise eine Leseverbindung in einer Entwicklungsumgebung. Ein Agent, der eine Abfrage optimiert, hat keinen Grund, die Produktionsdatenbank löschen zu können.

Umgekehrt habe ich es nicht für unverzichtbar gehalten, in allen meinen Projekten einen Postman-Server hinzuzufügen. Pi kann bereits APIs mit Terminal-Werkzeugen aufrufen, ein OpenAPI-Schema lesen oder bestehende Tests starten. Wenn das Team seine gesamte Wahrheit in Postman-Sammlungen hält, kann die Integration gerechtfertigt sein. Andernfalls dupliziert sie oft eine bereits vorhandene Fähigkeit.

Codemode: Aufhören, für jeden Schraubenzieher hin- und herzureisen

Eine naive Aneinanderreihung von Werkzeugen sieht so aus: Das Modell fragt eine Suche an, wartet auf das Ergebnis, denkt nach, fragt eine Datei an, wartet erneut und ruft dann einen MCP-Server auf. Jeder Schritt fügt eine Hin- und Rückfahrt hinzu und bläht den Kontext auf.

Codemode ermöglicht es Pi, ein kleines JavaScript-Programm zu schreiben, das in einer kontrollierten Umgebung ausgeführt wird, um mehrere Aufrufe zu orchestrieren. Es kann zum Beispiel zwei Ressourcen parallel abfragen, Antworten filtern und dem Modell nur das nützliche Ergebnis zurückgeben. Das ist nicht nur schneller: Es vermeidet auch, den Verlauf mit jedem einzelnen Zwischenschritt zu füllen.

const [docs, search] = await Promise.all([
  tools.mcp__context7__lookup({ library: "next" }),
  tools.mcp__search__query({ q: "Next.js current cache behavior" })
]);

return { docs, search };

Das Skript läuft in einer QuickJS-Sandbox, ohne direkten Zugriff auf Node.js, die Festplatte oder das Netzwerk: Es kommt nur über die erlaubten Werkzeuge heraus. Nur sein Ergebnis kehrt zum Modell zurück. Das ist wichtig, wenn zwei Aufrufe jeweils Tausende von Zeilen produzieren: JavaScript kann sortieren, filtern und mechanisch zusammenfassen, bevor Tokens in der Konversation verbraucht werden.

Mit einem im codemode exponierten MCP-Server aktiviert Pi diesen Mechanismus normalerweise automatisch. Um ihn auch ohne MCP verfügbar zu halten, kann ich ihn in settings.json hinzufügen:

{
  "defaultTools": ["+codemode"]
}

Ich behalte dennoch eine einfache Regel: Das Orchestrierungsprogramm muss kurz und lesbar bleiben. Wenn der Agent ein halbfertiges Softwareprodukt in einem Werkzeugaufruf versteckt, wird es schwieriger zu prüfen als die ursprüngliche Aufgabe.

Die Erweiterungen, die meinen Umgang wirklich verändert haben

Das Erweiterungs-Ökosystem ist der Ort, an dem Pi von einem minimalen Kern zu meinem Werkzeug wird. Hier sind diejenigen, die in meiner Organisation Sinn ergeben, keine obligatorische Liste.

Auf einen anderen Ordner zugreifen, ohne die ganze Festplatte zu öffnen

Pi denkt zunächst von seinem Arbeitsverzeichnis aus. Die Erweiterung für zusätzliche Ordner dient, wenn ein Projekt von einem benachbarten Repository, einem Dokumentationsordner oder einem gemeinsamen Schema abhängt. Ich deklariere diesen Pfad explizit, statt Pi zu hoch in der Verzeichnisstruktur zu starten. Der Agent sieht, was er braucht, nicht mein ganzes persönliches Verzeichnis.

fzf: Fuzzy-Suche und Multi-Grep

Die fzf-Erweiterung fügt normalerweise mehrere Werkzeuge hinzu: Dateisuche, Fuzzy-Grep und Suche nach mehreren Mustern. Der Agent kann weiterhin find oder grep nutzen; fzf wird zu einer zusätzlichen Option, nicht zu einem erzwungenen Ersatz. In der Oberfläche öffnet das Zeichen @ ebenfalls die Dateisuche und spart das erneute Tippen langer Pfade.

Neovim: Dort beginnen, wo ich arbeite

Mit der Neovim-Integration platziere ich den Cursor in einer Funktion, nutze mein Kürzel — in meiner Konfiguration eine Kombination um die Leader-Taste — und öffne ein kleines Dialogfeld. Eine Frage wie „Erkläre diesen Abschnitt“ kommt bei Pi mit der Datei und der aktuellen Position an. Dieser Kontext ist viel präziser als „Schau irgendwo im Controller nach“.

Subagents: Nur wenn die Trennung etwas bringt

Ich arbeite immer noch oft mit einem einzigen Modell. Subagents werden nützlich, wenn man ein günstiges Modell für einfache Suchen und ein robusteres für schwierige Entscheidungen reservieren will, oder eine spezialisierte Fähigkeit aufrufen will: Bild, Video, Audio-Transkription oder Sprachsynthese. Ihr Nutzen liegt in der Trennung der Rollen, nicht in der Anzahl kleiner Charaktere auf dem Bildschirm.

Apply Patch und Toolwatch: Eine sichtbare Barriere zurückbringen

Minimalistisches Pi unterbricht nicht jede Änderung, um um Erlaubnis zu bitten. Apply Patch passt, wenn ich das Diff vor der Anwendung jeder Änderung prüfen will. Toolwatch spielt eine ähnliche Rolle für Werkzeuge und Befehle: Ich kann gängige Operationen erlauben, eine Bestätigung für bestimmte anfordern und gefährliche Aktionen blockieren. Diese beiden Erweiterungen fügen Reibung hinzu, aber genau diese Reibung will ich vor einer Löschung oder einem Befehl, der die Umgebung berührt.

Eine Erweiterung läuft im Pi-Prozess mit den Rechten meines Benutzers. Das ist kein kleines Plugin, das magisch hinter einer Scheibe eingesperrt ist. Ich lese den Code, prüfe die Herkunft und begrenze Zugänge. Willkürlich eine Erweiterung zu installieren, die verspricht, den Agenten „zehnfach mächtiger“ zu machen, bedeutet, die Software eines Unbekannten auf dem eigenen Rechner auszuführen.

Sessions sind Bäume, keine langen Magnetbänder

Pi speichert seine Sessions als JSONL unter ~/.pi/agent/sessions. Der Vorteil liegt nicht nur darin, ein Gespräch fortzusetzen. Eine Session bildet einen Baum: Ich kann zu einem früheren Punkt zurückkehren, einen Ast erstellen und einen anderen Ansatz versuchen, ohne die ganze vorherige Arbeit wegzuwerfen.

/tree dient mir zur Navigation oder zum Abzweigen in der bestehenden Session. /fork erstellt eine separate Session, wenn ich eine Spur in unabhängige Arbeit verwandeln will. Ich kann eine Session auch benennen, klonen, exportieren oder fortsetzen. Diese Unterscheidung wirkt nebensächlich, bis der Tag kommt, an dem eine Refaktorierung in die falsche Richtung geht: Ich kehre lieber sauber an die Kreuzung zurück, als das Modell zu bitten, zwanzig Nachrichten mental zu vergessen.

Das anschaulichste Beispiel ist ein Versuch mit Redis. Ich bitte Pi, es zu integrieren, es ändert mehrere Dateien, dann stelle ich fest, dass dieser Weg nicht der richtige war. Mit /tree kehre ich zur Nachricht vor dieser Entscheidung zurück und erstelle einen anderen Ast in derselben Session-Datei; der alte Ast bleibt einsehbar. Mit /fork verwandle ich einen früheren Eintrag in eine neue, unabhängige Session. Mit /clone kopiere ich den aktiven Ast einfach so, wie er ist.

Wenn der Kontext sich seiner Grenze nähert, fasst die Kompression den alten Teil zusammen und macht Platz frei. Die Zusammenfassung dient als aktueller Kontext, während die Originalereignisse in der Session bleiben. Das ist keine perfekte Erinnerung: Eine Nuance kann in der Synthese verschwinden. Bei wichtigen Entscheidungen schreibe ich sie ins Repository — ADR, Ticket, Dokumentation oder AGENTS.md — statt auf ein endloses Gespräch zu vertrauen.

Die Grenze hängt vom Modell ab: 128.000, 256.000 Tokens, manchmal mehr. Pi komprimiert normalerweise automatisch, aber /compact ermöglicht es anzugeben, was die Zusammenfassung unbedingt bewahren muss. Ich habe auch im Kopf, dass das ursprüngliche JSONL Prompts, Werkzeugaufrufe, Befehlsausgaben und manchmal Dateiinhalte enthält. Eine exportierte Session ist daher kein unbedenkliches Dokument, das man ohne Nachlesen veröffentlichen sollte.

Eine root-AGENTS.md, dann lokale Regeln

In einem Monorepo wird eine einzige zweihundertzeilige Datei schnell ebenso lästig wie fehlende Dokumentation. Pi kann Anweisungen kombinieren, die sich auf mehreren Ebenen befinden. Ich behalte daher die gemeinsamen Regeln im Root und füge die Besonderheiten nahe dem betreffenden Code hinzu.

monorepo/
├── AGENTS.md              # Architektur, Git, gemeinsame Befehle
├── apps/
│   ├── web/AGENTS.md      # Next.js, Barrierefreiheit, UI-Tests
│   └── admin/AGENTS.md    # React, Berechtigungen und interne Komponenten
└── services/
    └── api/AGENTS.md      # Go, Migrationen und Integrationstests

Lokale Dateien ergänzen die übergeordneten Regeln. Pi erkennt auch die Varianten CLAUDE.md und AGENTS.override.md; Letztere ersetzt die Kontextdatei desselben Verzeichnisses, löscht aber nicht die von übergeordneten Verzeichnissen geerbten Anweisungen. Ein Team kann so überall das Erstellen von Tests vorschreiben und in der API nur präzise, wie eine Migration zu generieren ist.

Ich halte diese Dokumente konkret: Next.js- oder React-Versionen, striktes TypeScript, Verbot von any, Präferenz für Server-Komponenten, exakte Befehle, Verzeichnisse, Einschränkungen und kurze Beispiele. Dreißigzeilige Ermahnungen über die „Codequalität“ helfen weniger als ein korrekter Testbefehl.

Skills: Eine Gewohnheit in ein Verfahren verwandeln

Eine Skill ist im Wesentlichen eine wiederverwendbare Anweisung, die der Agent lädt, wenn eine Aufgabe übereinstimmt. Ich erstelle eine, nachdem ich denselben Prozess mehrfach wiederholt habe: Eine Migration vorbereiten, eine Version veröffentlichen, einen CI-Fehler analysieren, eine Seite vor dem Deployment prüfen oder ein Änderungsprotokoll verfassen.

Die gute Skill sagt nicht nur „Deploye die Anwendung“. Sie beschreibt Vorbedingungen, die Reihenfolge der Prüfungen, Befehle, Abbruchkriterien und Elemente, die am Ende zurückzugeben sind. Sie muss es einem Kollegen ermöglichen, den Prozess zu verstehen, auch ohne Agent.

Ich misstraue großen Sammlungen, die blockweise heruntergeladen werden. Sie füllen die Umgebung mit Annahmen, die nicht zu meiner Infrastruktur passen, und sie stellen unzuverlässigen Code oder Anweisungen dar. Drei kurze Skills, geschrieben für mein Projekt und mit ihm gepflegt, sind besser als dreihundert mysteriöse Rezepte.

Packages: Eine stabile Konfiguration teilen

Wenn ein Set sich bewährt hat, kann ein Pi-Package Erweiterungen, Skills, Prompts und Themen bündeln. Das ist praktisch, um dieselbe Umgebung auf mehreren Maschinen wiederzufinden oder eine gemeinsame Basis für ein Team bereitzustellen.

Ich beginne nicht mit dem Package. Ich beginne mit dem Problem, füge das Werkzeug hinzu, nutze es, entferne, was nicht dient, und verpacke es erst dann. Sonst verwandle ich noch unklare Entscheidungen in einen internen Standard und jeder erbt meine Versuche.

Der Punkt, den Demonstrationen oft überspringen: Sicherheit

Pi kann lesen, ändern und ausführen mit den Berechtigungen des Kontos, das ihn gestartet hat. Standardmäßig darf man keine undurchdringliche Sandbox-Grenze oder eine automatische Bestätigung vor jedem Befehl erwarten. Es ist ein leistungsstarkes Entwicklungswerkzeug, daher ist die Reichweite real.

Ich behandle es wie einen sehr schnellen technischen Kollegen, der einen Satz missverstehen könnte:

• Arbeit unter Git und verfügbare Backups;
• Geheimnisse auf das Nötigste reduziert, niemals ein vollständiger Schlüsselbund;
• dedizierter Account, Container oder VM, wenn das Projekt sensibel ist;
• Leseverbindung zur Datenbank für Analysen;
• Diff vor dem Merge geprüft und Tests ausgeführt;
• zerstörerische Befehle blockiert oder zur Bestätigung vorgelegt;
• Web-Inhalte, Issues und externe Dateien als unzuverlässig betrachtet.

Der letzte Punkt betrifft Prompt-Injection. Eine Seite oder ein Ticket kann einen Satz enthalten, der den Agenten überzeugen soll, seine Regeln zu ignorieren oder ein Geheimnis zu exfiltrieren. Für mich ist ein konsultiertes Dokument ein zu analysierendes Objekt, nicht jemand, der plötzlich das Recht erhält, das Terminal zu befehligen.

Die Konfiguration, die ich zum Start empfehle

Nach all diesen Werkzeugen wirkt die beste Erstinstallation fast enttäuschend. Das ist ein gutes Zeichen.

1. Pi installieren und ein einziges Modell verbinden.
2. Eine kurze AGENTS.md mit den Befehlen und Grenzen des Projekts erstellen.
3. Den Language-Server der Sprache installieren und prüfen, ob er antwortet.
4. Einige Tage mit den integrierten Werkzeugen arbeiten.
5. Einen MCP-Server erst hinzufügen, wenn ein Mangel klar wiederkehrt.
6. Wiederkehrende Verfahren in Skills verwandeln.
7. Das Ganze nach Stabilisierung in ein Package verpacken.

Dieser Fortschritt vermeidet ein häufiges Problem: Wenn ein Agent am ersten Tag zwei Suchmaschinen, drei Browser, vier Speicher und zehn Datenbanken hat, weiß ich nicht mehr, welche Komponente eine Antwort erzeugt hat und warum der Kontext so viele Tokens kostet.

Wann ich Pi nicht nutze

Wenn die Aufgabe deterministisch, bekannt und ohne Mehrdeutigkeit wiederholt wird, schreibe ich ein Skript oder einen Test. Immer dieselbe Datei umbenennen, einen Port prüfen, ein Verzeichnis sichern oder eine API mit festen Parametern aufrufen, braucht kein Modell, das bei jeder Ausführung nachdenkt.

Pi wird interessant, wenn ich mich in unbekanntem Code zurechtfinden muss, mehrere Quellen verknüpfen, zwischen Optionen wählen, einen Fehler erklären oder eine Änderung nach den Testergebnissen weiterentwickeln muss. Mit anderen Worten: Ich nutze ihn für kontrollierte Unsicherheit, nicht als teuren Ersatz für jeden Shell-Befehl.

Was ich schließlich gebaut habe

Mein Pi hat kaum noch etwas mit einer leeren Installation zu tun. Er versteht Code dank LSP, konsultiert aktuelle Dokumentation, befragt eine Suche, beobachtet den Browser, erkundet bestimmte Datenbanken, delegiert Unteraufgaben und weiß, wie man einen Konversationsast fortsetzt. Doch das Ganze bleibt lesbar, weil jedes Stück auf einen bestimmten Grund antwortet.

Dort wird Minimalismus wirklich interessant. Es geht nicht darum, mit den wenigsten Funktionen auszukommen. Es geht darum, erklären zu können, warum jede Funktion da ist, welche Daten sie sieht und was passiert, wenn sie ausfällt.

Ich suche daher nicht den besten Agenten im Absoluten. Ich suche ein Werkzeug, das ich formen, inspizieren und stoppen kann. Pi passt zu mir, weil er klein beginnt und mir die Entscheidung überlässt, wie weit er wächst. In einer Welt, in der jede Software eine totale Plattform werden will, ist diese Bescheidenheit fast eine Premium-Funktion.

Technische Referenzen

• Pi: Installation und Erste Schritte
• Pi: Konfigurationsdateien und -ebenen
• Pi: Anbieter, Modelle und Denklevel
• Pi: MCP-Server und Werkzeugexposition
• Pi: Funktionsweise von Codemode
• Pi: Sessions, Äste, Export und Kontext
• Pi: Erweiterungen
• Pi-Paketkatalog: LSP-Erweiterung in diesem Leitfaden
• Pi: Skills
• Pi: Sessions und Kontextkompression
• Pi: Sicherheitsmodell

🔗 Источники: [1] CERTS pi.dev https://crt.sh/?q=%25.pi.dev [2] DNS pi.dev https://dns.google/resolve?name=pi.dev [3] Pi.dev - Learn AI https://ai.miraheze.org/wiki/Pi.dev [4] GitHub - earendil-works/pi: AI agent toolkit: unified LLM API, agent ... https://github.com/earendil-works/pi [5] How I run pi.dev safely (and actually get work done) https://krisconstable.com/start-with-pidev/ [6] Pi.dev — The Minimalist AI Coding Agent That Wants ... - Medium https://medium.com/@anubhavbhatt/pi-dev-review-the-minimalist-ai-coding-agent-for-developers-in-control-e3e7c7afba90 [7] pi.dev : un agent de code en terminal minimaliste, extensible et ... https://mondary.design/2026/03/pi-dev-un-agent-de-code-en-terminal-minimaliste-extensible-et-vraiment-faconnable/ [8] Pi https://pi.dev/ [9] Package Catalog - pi.dev https://pi.dev/packages [10] WHOIS pi.dev https://rdap.org/domain/pi.dev [11] Pi https://pi.dev [12] Pi · Documentation · Pi https://pi.dev/docs/latest

Als Nächstes lesen

• Ich habe OpenClaw zwei Wochen getestet: Das ist mein Fazit KI und Automatisierung · 42 Min.

Über den Autor

Jeremy Kraft betreut die Infrastruktur und die selbst gehosteten Dienste des IBCSC. Diese Anleitungen beschreiben Konfigurationen, die tatsächlich im Einsatz waren und vor der Veröffentlichung erneut geprüft wurden.

Eine Frage stellen Alle Anleitungen

Diskussion

Kommentare

0

Noch kein Kommentar. Eröffnen Sie die Diskussion gern mit einer Frage oder Ihrem eigenen Erfahrungsbericht.

Website

Ihr Name Sie haben ein Konto? Anmelden

Ihr Kommentar

Reiner Text, höchstens 2 000 Zeichen. Neue Kommentare werden moderiert. Ihr Name wird mit dem Kommentar angezeigt. Es wird keine E-Mail-Adresse abgefragt; gegen Spam wird nur ein nicht umkehrbarer Fingerabdruck Ihrer IP-Adresse gespeichert.

Kommentar senden