Pinvou Agent: ein Desktop-Arbeitsbereich, der drei Agentenrollen in einer App bündelt

Drei Arbeitsmodi statt eines Chatfensters

Die README beschreibt den Kern des Projekts mit einem Satz, der die Zielrichtung vorgibt: Aufgaben sollen mit einem Ergebnis enden, nicht mit einer weiteren Chatantwort. Daraus leitet sich die Aufteilung in drei Modi ab. Im Work-Modus kombiniert der Agent Anhänge, persönliches Wissen, Personas, Skills, MCP-Tools und Workflows, um Dateien zu erzeugen. Im Design-Modus entstehen Poster und Datenvisualisierungen, die anschließend im Design-Modus direkt bearbeitet werden können: Elemente auswählen, Text, Schrift, Farben, Abmessungen und Layout anpassen, oder weiter beschreiben und den Agenten iterieren lassen. Im Code-Modus wird ein externer Coding-Agent über ACP in ein reales Projekt eingebunden.

Die Zielgruppe ist damit breiter als bei reinen Coding-Agenten. Angesprochen sind Menschen, die Dokumente, Recherche und Gestaltung im selben Werkzeug erledigen wollen wie gelegentliche Programmierarbeit. Wer ausschließlich in einer IDE lebt, bekommt hier nichts, was ein dort integrierter Agent nicht auch liefert. Der Unterschied liegt in der Bündelung: Anhänge, Wissensdatenbank, Artefakt-Panel und Coding-Sitzung teilen sich eine Oberfläche und einen Sitzungsbegriff.

ACP für Coding-Agenten, MCP für Werkzeuge

Für den Code-Modus nennt die README drei unterstützte Agenten: Codex, Claude Code und Kimi, angebunden über ACP, dokumentiert in docs/multi-agent-acp.md. Die Sitzung bleibt an ihren Arbeitsbereich gebunden und lässt sich nach einem Neustart der Anwendung fortsetzen. Der Coding-Agent darf ein echtes Projekt oder einen isolierten temporären Arbeitsbereich lesen und bearbeiten, Befehle ausführen und Pläne, Werkzeugschritte, Berechtigungsanfragen sowie Dateiänderungen sichtbar machen. Das ist eine andere Architektur als bei Agenten, die ihr eigenes Modell mitbringen: Pinvou Agent orchestriert hier fremde Agentenprozesse und zeigt deren Zustand in der eigenen Oberfläche.

Für alles andere gibt es einen einheitlichen Tool-Store, der lokale MCP-Server, entfernte MCP-Server, CLI-Werkzeuge und API-Konnektoren aufnimmt. Die README listet fertige Konnektoren für Feishu (Lark), DingTalk, WeCom, Tencent Meeting, Tencent ima, Obsidian sowie Unternehmenswissensbasen und juristische bzw. Unternehmensdatendienste. Wo unterstützt, läuft die Autorisierung über OAuth oder SSO statt über manuell eingefügten Schlüssel. Der Datenfluss ist damit zweigeteilt: lokal bleibt es, wenn ein lokales Modell mit lokalen Werkzeugen arbeitet; Cloud-Modelle, entfernte MCP-Server und Drittanbieter-Konnektoren senden die jeweiligen Anfragen an ihre Dienste. Die README formuliert diese Grenze selbst als Hinweis, was für ein Projekt mit Konnektoren zu Unternehmensdiensten die ehrlichere Variante ist als ein pauschales Datenschutzversprechen.

Wissensdatenbank, Speicher und Provenienz

Die lokale Wissensdatenbank verwaltet Dateien und bietet Volltext- sowie Vektorsuche. Mehrere Sammlungen lassen sich an einen Chat anhängen und einzeln ein- und ausschalten. Die README betont, dass Sammlungs- und Dateiherkunft in den Antworten erhalten bleiben. Das ist der praktisch relevanteste Punkt des Wissensmoduls: Ohne Provenienz ist eine Vektorantwort in einem Fachkontext kaum überprüfbar.

Daneben steht ein Memory-Center, das langfristige Präferenzen und Kontext sammelt. Der Mechanismus ist explizit als Kandidatenprüfung beschrieben: Vorschläge werden zur Bestätigung vorgelegt, statt ungefragt übernommen zu werden. Das kostet Bedienaufwand und ist der Grund, warum der Speicher nicht unbemerkt driftet. Ein Persona-Kartenpool speichert Fachrollen, Skills, Commands und Workflows machen wiederkehrende Verfahren reproduzierbar. Alle diese Bausteine laufen auf Beschreibungen der README hinaus, nicht auf nachprüfbaren Details. Wie die Vektorsuche implementiert ist, welches Einbettungsmodell verwendet wird und wie groß eine Sammlung werden darf, steht im vorliegenden Material nicht.

Installation und Modellanbindung

Die README verweist für den Bezug auf die Releases-Seite; ein Paketmanager-Befehl oder ein Build-from-Source-Ablauf ist im vorliegenden Ausschnitt nicht enthalten. Das ist eine Lücke, die man beim Ausprobieren einplanen sollte. Die Plattformangabe lautet Windows, macOS und Linux, der Technologie-Stack Rust mit Tauri und React.

Für die Modellanbindung ist das Vorgehen dagegen konkret. Der Agent spricht lokales vLLM und jede OpenAI-kompatible API an. Die README zeigt ein Beispiel für lokales vLLM:

export DEEPSEEK_BASE_URL="http://127.0.0.1:8000/v1" export DEEPSEEK_API_KEY="local-no-auth" export DEEPSEEK_MODEL="your-model-name"

Endpunkte, Modellnamen und Schlüssel lassen sich auch direkt in den Anwendungseinstellungen verwalten. Mehrere Modellkonfigurationen können gespeichert werden, Cloud-Konfigurationen optional einen Anzeigealias erhalten, und der Wechsel erfolgt pro Sitzung, ohne dass sich die an den Anbieter gesendete Modellkennung ändert. Eingebaute Vorlagen decken lokales vLLM, DeepSeek, Kimi, Qwen, Doubao, MiniMax, Zhipu (GLM), MiMo, OpenAI, Anthropic, Gemini und xAI ab. Bemerkenswert ist die Trennung von Alias und Kennung: Sie erlaubt lesbare Namen in der Oberfläche, während das Modellrouting unverändert bleibt.

Sitzungen, Artefakte und der Preis der Bündelung

Der Arbeitsbereich führt mehrere Sitzungen mit Titelsuche; Nachrichten, Werkzeugaufrufe und Artefakte bleiben je Sitzung erhalten. Ein Artefakt-Panel sammelt jede Datei, die der Agent erstellt oder bearbeitet, und bietet Vorschau, Verortung und Öffnen an einer Stelle. Markdown-Artefakte sind direkt editierbar, oder eine Passage wird ausgewählt und der Agent um Überarbeitung gebeten. Plan- und YOLO-Modus stehen für zwei Vorgehensweisen: erst den Plan prüfen oder direkt ausführen.

Das ist der eigentliche Produktkern, und gleichzeitig der Punkt, an dem der Umfang zum Risiko wird. Eine Anwendung, die Wissensverwaltung, Designbearbeitung, Coding-Sitzungen, Sprachsteuerung und Konnektoren für Unternehmensdienste vereint, hat viele Stellen, an denen etwas brechen kann. Die Versionsnummern stützen diese Einschätzung: v0.9.1, v0.9.2 und v0.9.3 erschienen zwischen dem 2. und 9. September 2026, alle als Preview gekennzeichnet. Drei Releases in acht Tagen deuten auf schnelle Iteration, nicht auf eingefrorene Schnittstellen. Wer das Projekt produktiv einsetzen will, sollte mit Änderungen an Konfigurationsformaten und Sitzungsdaten rechnen. Die README macht dazu keine Zusage.

Grenzen: Preview-Status, Update-Pfad und Dokumentationstiefe

Die README nennt selbst eine Einschränkung, die im Betrieb sofort auffällt: Updates laufen über GitHub Releases, eine Prüfung auf Aktualisierungen in der Anwendung ist noch nicht aktiviert. Wer die App auf mehreren Rechnern betreibt, muss den Aktualisierungsvorgang manuell organisieren. Das ist kein Detail, sondern eine Betriebsaufgabe, die bei einer Desktop-Anwendung mit Konnektoren und Zugangsdaten regelmäßig anfällt.

Die zweite Grenze ist die Dokumentationslage. Das Repository enthält eine ausführliche README mit Screenshots, einen Verweis auf docs/multi-agent-acp.md und eine SECURITY.md. Für die Kernversprechen des Wissensmoduls, der Vektorsuche, des Memory-Centers und der Workflows liefert der vorliegende Ausschnitt jedoch keine Implementierungsdetails. Man erfährt nicht, welche Einbettungen verwendet werden, wie Berechtigungen für Werkzeugaufrufe im Detail durchgesetzt werden oder wie sich der YOLO-Modus gegenüber dem Plan-Modus in den Genehmigungsschritten unterscheidet. Das ist kein Widerspruch zur README, aber es bedeutet, dass eine Bewertung der Sicherheitsgrenzen ohne Blick in den Quellcode nicht möglich ist.

Das falsche Werkzeug ist Pinvou Agent für Teams, die eine serverbasierte, zentral administrierte Agentenplattform mit Audit-Trail brauchen. Die Datenhaltung unter ~/.pinvou3/ ist bewusst lokal und benutzerbezogen. Für eine Organisation, die Sitzungen zentral protokollieren oder Richtlinien über eine Verwaltungskonsole durchsetzen muss, ist das die falsche Bauform.

Alternative: ein IDE-gebundener Coding-Agent

Der naheliegende Vergleich ist ein Coding-Agent, der direkt in der Entwicklungsumgebung läuft, etwa Claude Code als eigenständiges Werkzeug oder die in Editoren integrierten Agenten. Der Unterschied liegt nicht in der Modellqualität, sondern im Zuschnitt. Ein IDE-Agent kennt den Projektbaum, den Compiler, den Testrunner und die Versionskontrolle als erstklassige Objekte. Pinvou Agent bindet solche Agenten über ACP ein und stellt sie in einen Arbeitsbereich, der auch Anhänge, Wissensdatenbank und Design-Artefakte enthält. Das ist ein Mehrwert für gemischte Aufgaben und ein Umweg für reine Codearbeit: Wer den ganzen Tag in einem Repository arbeitet, gewinnt nichts dadurch, dass die Coding-Sitzung in einer separaten Desktop-Anwendung mit eigenem Sitzungs- und Berechtigungsmodell liegt.

Umgekehrt gilt derselbe Schnitt. Ein IDE-Agent liefert keine lokale Wissensdatenbank mit Provenienz und kein Artefakt-Panel für Poster oder Datenvisualisierungen. Für die Kombination aus Recherche, Dokument und gelegentlichem Code ist der gebündelte Ansatz sinnvoll, für spezialisierte Einzeldisziplinen ist der fokussierte Agent die günstigere Wahl. Pinvou Agent positioniert sich bewusst in der Mitte, und diese Positionierung ist eine Entscheidung mit Kosten auf beiden Seiten.

Lizenz, Wartung und was vor dem Einsatz zu klären ist

Das Projekt steht unter der MIT-Lizenz. Für die meisten internen Einsätze ist das eine der permissivsten Ausgangslagen: Weitergabe und Änderung sind erlaubt, solange der Lizenztext und der Urheberrechtshinweis erhalten bleiben. Eine Rechtsberatung ersetzt das nicht, insbesondere nicht bei der Frage, welche Haftungs- und Gewährleistungsregeln für abgeleitete Distributionen gelten. Relevant ist die Lizenz hier vor allem in Kombination mit den Konnektoren: Wenn ein Agent Anfragen an Unternehmensdienste wie Feishu, DingTalk oder juristische Datendienste sendet, entstehen Verpflichtungen aus deren Nutzungsbedingungen, nicht aus der MIT-Lizenz des Clients.

Der Wartungsaufwand hängt an der Release-Kadenz. Drei Preview-Versionen in einer Woche bedeuten, dass Fehlerkorrekturen schnell kommen, aber auch, dass sich Verhalten zwischen Versionen ändern kann. Wer Pinvou Agent einführt, sollte die Konfiguration unter ~/.pinvou3/ versionieren oder sichern, weil Sitzungen, Einstellungen, Wissen und Laufzeiterweiterungen dort gemeinsam liegen. Ein Rückschritt auf eine ältere Version ist damit nicht nur ein Paketwechsel, sondern potenziell ein Datenformatwechsel.

Vor dem ersten produktiven Einsatz sind drei Dinge zu prüfen. Erstens, ob der vorhandene Modellendpunkt OpenAI-kompatibel ist, denn davon hängt die gesamte Modellanbindung ab. Zweitens, welche der benötigten Konnektoren Daten nach außen senden und ob das mit den eigenen Vorgaben vereinbar ist. Drittens, ob die Anwendung auf allen Zielplattformen aus den Releases installierbar ist, da der vorliegende Ausschnitt keinen Installationsbefehl enthält. Diese drei Punkte lassen sich in einem Nachmittag klären, und sie entscheiden darüber, ob der Rest des Funktionsumfangs überhaupt zum Tragen kommt.

Redaktionelles Fazit

Wer einen lokalen, dateibasierten Agenten mit MCP-Anbindung und ACP-Coding-Sitzungen sucht, findet in Pinvou Agent einen Kandidaten, dessen Datenhaltung unter ~/.pinvou3/ transparent genug für einen Testlauf ist. Wer eine stabile, dokumentierte Plattform für ein Team braucht, sollte die Preview-Reihe 0.9.x meiden. Prüft zuerst, ob euer Modellendpunkt OpenAI-kompatibel ist und ob die benötigten Konnektoren unter euren Datenschutzvorgaben laufen dürfen, denn die README stellt ausdrücklich fest, dass Daten nur bei lokalem Modell und lokalen Tools auf dem Rechner bleiben.

Offizielle Quellen

1. License: MIT
2. Pinvou/pinvou-agent on GitHub
3. Project website
4. README
5. Releases