Sage: eine Agenten-Plattform mit Desktop, Web, CLI und IM-Anbindung

Welches Problem Sage adressiert und für wen es gedacht ist

Ein Sprachmodell allein löst keine mehrstufige Aufgabe. Es braucht eine Schleife, die plant, Werkzeuge aufruft, Ergebnisse prüft und Zwischenstände behält. Genau dort setzt Sage an: Das Repository beschreibt einen Kern namens SAgents mit Plan-, Simple-, Fibre- und Self-Check-Agenten, die laut README zusammenarbeiten, um komplexe Aufgaben bis zur Auslieferung zu bringen. Die Zielgruppe sind damit keine Anwender, die eine einzelne Chat-Oberfläche suchen, sondern Entwickler und kleine Plattform-Teams, die einen eigenen Agenten-Stack betreiben wollen. Der Umfang der Oberflächen deutet das an: Desktop-App, Web-App, CLI, TUI und eine Chrome-Erweiterung greifen alle auf dieselbe Service-Schicht zu. Dazu kommen IM-Kanäle für WeChat Personal (iLink), WeCom, Feishu und DingTalk. Wer nur eine Funktion in eine bestehende Python-Anwendung einbauen will, findet hier deutlich mehr Bauteile als nötig. Der Nutzen liegt eher im Gegenteil: Man bekommt Sitzungsverwaltung, Werkbank, Aufgabenplanung und Auslieferungswege als zusammenhängendes System, statt sie einzeln zu verdrahten.

Aufbau: Produktschicht über einem Agenten-Kern

Das Architekturdiagramm im README zeigt zwei Schichten. Oben steht die Produktschicht mit Chat und Sitzungen, Agentenverwaltung, Tasks und Automatisierungen, einer Browser Bridge und der als Visual Workbench bezeichneten Ansicht. Alle Clients münden in dieselbe App Service Layer. Darunter liegt der Kern SAgents mit einer Session Runtime, die wiederum AgentFlow nutzt, und AgentFlow verteilt die Arbeit auf die Agenten Plan, Simple, Fibre und Self-Check. Das ist der eigentliche Mechanismus: Eine Anfrage wird nicht direkt an ein Modell geschickt, sondern durchläuft eine Runtime, die den Ablauf steuert und die einzelnen Agentenrollen einbindet. Das README nennt zusätzlich Memory Recall und Tool Suggestion als Bestandteile, ohne deren Schnittstellen zu erläutern. Die Datenhaltung ist konfigurierbar: Beim Web-Start fragt der erste Lauf nach einem Minimal-Stack mit SQLite oder einem Full-Stack, und die CLI erwartet SAGE_DB_TYPE mit dem Wert file. Mehr Details zur Runtime gibt das Repository an dieser Stelle nicht her. Wer wissen will, wie AgentFlow einen Plan in Aufrufe übersetzt, muss die verlinkte Wiki oder den Quellcode lesen.

Startwege: Web aus dem Quellcode, CLI mit Umgebungsvariablen

Der schnellste Weg führt über das Skript im Repository. Nach git clone, cd Sage und ./scripts/dev-up.sh läuft die Oberfläche unter http://localhost:5173. Voraussetzung sind Python 3.10 oder neuer und Node.js 18 oder neuer; für SAgents v2 und Desktop v2 verlangt das README Python 3.12 oder neuer. Wer eine eigene Python-Installation oder uv nutzt, kann PYTHON_BIN setzen oder mit USE_UV=1 starten. Nach der Anmeldung muss zuerst ein Modell-Provider in der Model Source Management eingetragen werden, danach ein Agent angelegt oder konfiguriert werden. Der CLI-Weg ist kürzer, setzt aber die Umgebung voraus: pip install -e ., dann SAGE_DEFAULT_LLM_API_KEY, SAGE_DEFAULT_LLM_API_BASE_URL und SAGE_DEFAULT_LLM_MODEL_NAME exportieren, SAGE_DB_TYPE auf file setzen, und danach sage doctor zur Prüfung sowie sage run "Say hello briefly." oder sage chat. Für die TUI kommt nach derselben Einrichtung sage-terminal zum Einsatz, alternativ ein cargo-Lauf aus app/terminal/. Die Desktop-Varianten liegen als .dmg, .exe und .deb in den Releases; unter macOS ist ein xattr -dr com.apple.quarantine /Applications/Sage.app nötig, wenn das System die App als beschädigt meldet. Die Chrome-Erweiterung wird als unpacked extension aus app/chrome-extension/ geladen.

Die Desktop-Builds sind nicht notarisiert

Das README sagt es offen: Der macOS-Build ist derzeit nicht Apple-notarisiert. Das ist keine Randnotiz, sondern eine Betriebseinschränkung. Nutzer müssen den Rechtsklick-Umweg über Finder, den Dialog in den Systemeinstellungen unter Privacy & Security oder das Entfernen des Quarantäne-Flags in Kauf nehmen. In Umgebungen mit verwalteten Geräten, in denen solche Ausnahmen zentral gesperrt sind, kann das den Desktop-Weg vollständig blockieren. Unter Windows warnt SmartScreen vor einem unbekannten Herausgeber, und das README verweist auf More info und Run anyway. Für einen internen Rollout bedeutet das zusätzlichen Aufwand bei der Verteilung, unabhängig davon, wie gut die Anwendung danach läuft. Wer Sage nur als Bibliothek oder über die CLI einsetzen will, umgeht das Problem, weil dann kein signierter Installer im Spiel ist. Diese Trennung sollte man vor der Entscheidung treffen: Der Desktop-Client ist der bequemste Einstieg, aber auch der Teil mit den meisten plattformspezifischen Hürden.

Sandbox, Werkzeuge und die Grenze der Beschreibung

Sage bündelt Werkzeuge in einem Stack: eingebaute Tools, Skills, MCP-Server, Browser-Automatisierung, Suche und Bilderzeugung. Für die Ausführung nennt das README drei Sandbox-Varianten: local, passthrough und remote. Das sind sehr unterschiedliche Sicherheitsniveaus unter einem gemeinsamen Etikett. Local und passthrough dürften auf demselben Rechner laufen und damit dieselben Dateien und Netzwerkzugriffe sehen; remote verlagert die Ausführung. Welche Variante was genau isoliert, welcher Standard gilt und wie ein Agent an einen entfernten Sandbox-Endpunkt gebunden wird, steht im bereitgestellten Material nicht. Das ist eine echte Lücke für alle, die Agenten auf fremden Code oder auf Webinhalte loslassen. Die Visual Workbench ist dem README zufolge in der Lage, Dateien, Tool-Ausgaben, Code, Diagramme in Mermaid und Draw.io, Audio, Video und entfernte Vorschauen darzustellen. Auch hier gilt: Die Existenz der Funktion ist belegt, ihr Verhalten nicht. Wer die Sandbox als Sicherheitsgrenze einplant, sollte die Konfigurationsschlüssel und das tatsächliche Isolationsmodell im Quellcode prüfen, bevor Agenten Zugriff auf produktive Systeme erhalten.

Alternative: eine feste Pipeline statt einer Plattform

Der naheliegende Vergleich ist nicht ein anderes Agenten-Framework mit denselben Oberflächen, sondern ein Werkzeugkasten wie LangChain oder LlamaIndex. Der Unterschied liegt im Ansatz, nicht im Funktionsumfang. Diese Bibliotheken liefern Bausteine: Sie verbinden Prompts, Modelle und Werkzeuge, und der Entwickler entscheidet, wie die Schleife aussieht, wo Zustand liegt und wie der Dienst ausgeliefert wird. Sage dreht das um. Es bringt die Schleife als AgentFlow mit vordefinierten Rollen mit, dazu Sitzungen, Aufgabenplanung, eine Werkbank und mehrere fertige Clients. Man tauscht Gestaltungsfreiheit gegen einen fertigen Betriebsrahmen. Wer eine klar umrissene Kette aus festen Schritten braucht, die in eine bestehende Anwendung eingebettet wird, fährt mit einer Bibliothek besser, weil er keine Agentenverwaltung, keine Oberfläche und keinen Desktop-Installer mitschleppen muss. Wer dagegen plant, Ausführung, Selbstprüfung und Auslieferung über mehrere Kanäle hinweg selbst zu betreiben, spart mit Sage den Aufbau dieser Teile. Die Entscheidung hängt also daran, ob man die Plattform oder nur den Kern will.

Wartung, Versionen und Lizenz

Die letzten veröffentlichten Releases tragen die Bezeichnung desktop-v1.1.8, desktop-v1.1.7 und desktop-v1.1.6, alle vom 26. Mai 2026 und innerhalb weniger Stunden erstellt. Das sind Nachbesserungen am Desktop-Paket, keine Funktionssprünge. Der letzte Push auf den Hauptzweig datiert vom 9. September 2026, das Repository ist nicht archiviert. Eine Aussage über die Zahl der Mitwirkenden oder die Stabilität der Schnittstellen lässt sich daraus nicht ableiten, und das README gibt keine Kompatibilitätszusage für den Kern. Wer SAgents v2 nutzt, ist an Python 3.12 oder neuer gebunden, während der übrige Web-Start mit Python 3.10 und Node.js 18 auskommt. Diese Versionsspanne sollte man beim Aufsetzen einer Umgebung berücksichtigen, weil sie die Wahl des Basis-Images bestimmt. Die Lizenz ist MIT, was Weitergabe und Änderung mit Namensnennung erlaubt; das ist eine Einordnung, keine Rechtsberatung. Zu prüfen bleibt, ob mitgelieferte Assets und die Desktop-Pakete unter derselben Lizenz stehen, denn das README trennt das nicht.

Redaktionelles Fazit

Sage passt zu Teams, die einen Agenten-Stack selbst betreiben wollen und Python 3.10 oder neuer sowie Node.js 18 mitbringen. Wer eine einzelne Bibliothek für eine feste Pipeline sucht, ist hier falsch, weil das Projekt auf eine komplette Plattform mit Sitzungsverwaltung, Werkbench und mehreren Clients zielt. Vor dem Einsatz zu prüfen: ob die verlinkte Wiki unter wiki.sage.zavixai.com den eigenen Modell-Provider und die Sandbox-Variante abdeckt, ob der Desktop-Build auf der Zielplattform ohne Quarantäne-Hinweis startet, und ob die MIT-Lizenz mit den eigenen Weitergabeanforderungen zusammenpasst.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. ZHangZHengEric/Sage on GitHub