Andrew Ng veroffentlicht Desktop-KI, die Arbeit erledigt statt nur zu plaudern
Jeder KI-Assistent, den Sie bisher genutzt haben, hat eines gemeinsam: Er redet zuruck. Sie geben einen Prompt ein, er antwortet. Sie prazisieren, er formuliert um. Sie fragen erneut, er generiert mehr Text. Die Schleife endet nie, weil das Produkt die Konversation selbst ist.
Andrew Ngs OpenWorker behandelt die Konversation als Overhead.
Veroffentlicht am 23. Juli unter einer MIT-Lizenz, ist OpenWorker ein Desktop-KI-Agent, der ein Ergebnis entgegennimmt - "bereite ein Kundenbriefing vor", "entwirre meinen Kalender", "prufe den Stand des Releases in Jira und GitHub" - und zuruckkommt, wenn die Arbeit erledigt ist. Es lauft auf Ihrem Rechner, verwendet Ihre API-Schlussel (oder gar keinen Schlussel mit lokalem Ollama) und verbindet sich mit uber 25 Tools wie Slack, Gmail, GitHub, Notion und Jira. Das Ergebnis ist kein Chat-Thread, sondern ein fertiges Dokument, ein aktualisierter Kalender oder ein sortiertes Postfach.
Vom Chat zum Kollegen
Der konzeptionelle Wandel ist subtil, aber tiefgreifend. Jedes grobe KI-Produkt heute - ChatGPT, Claude, Gemini - optimiert auf Gesprachtiefe. Je langer Sie in der Schleife bleiben, desto mehr Wert kann die Plattform erfassen. OpenWorker optimiert auf das Gegenteil: herein, die Arbeit erledigt, raus.
Unter der Haube spiegelt die Architektur dies wider. Ein Tauri-2-Desktop-Shell umschliebt eine React-18-Oberflache, die mit einem lokalen Python-FastAPI-Agent-Server kommuniziert. Der Server, gebaut auf Ngs eigener aisuite-Bibliothek, zerlegt ein Ergebnis in Schritte, arbeitet uber lokale Dateien und verbundene Apps und fragt vor jeder folgenreichen Aktion nach. Das Repository enthalt 119 Python-Dateien (~32.400 Zeilen) fur das Backend und 149 TypeScript-Dateien fur die GUI.
Der Agent kann auch aus Slack heraus aktiviert werden, indem man @OpenWorker in einem Kanal erwahnt. Eine Sitzung offnet sich auf dem Desktop, die Arbeit wird mit den Werkzeugen des Benutzers erledigt, und die Antwort kommt als Thread-Antwort zuruck. Geplante Automatisierungen - ein Morgenbriefing, ein Wochenbericht - laufen im Hintergrund und landen in der App mit vollstandigen Transkripten.
Die Berechtigungs-Engine ist die eigentliche Ingenieursleistung
Die meisten Desktop-Agent-Projekte behandeln Benutzerfreigaben als UI-Nachgedanke - ein Popup, das "Aktion erlauben?" anzeigt, ohne Kontext. OpenWorker behandelt es als typisiertes System.
Jeder Tool-Aufruf wird in eine von vier Risikoklassen eingeteilt: read (keine Seiteneffekte), write_local (andert den Arbeitsbereich), exec (fuhrt Befehle aus) und external (Seiteneffekte auberhalb des Rechners). Funf Berechtigungsmodi entscheiden dann uber das Verhalten:
| Modus | Verhalten |
|---|---|
| Discuss and plan | Nur lesen - der Agent kann erkunden, aber nicht handeln |
| Interactive | Standard - fragt vor Schreib-, Befehls- und externen Aktionen |
| Auto | Erlaubt alles, bleibt aber pfad-beschrankt |
| Custom | Genehmigt automatisch eine benutzerdefinierte Tool-Liste |
| Unattended | Leitet Aufforderungen an ein Postfach weiter - die Sitzung pausiert bis zur Antwort |
Zwei Design-Entscheidungen stechen hervor. Erstens: Der Unbeaufsichtigt-Modus erhoht die Autonomiegrenze nicht - er andert nur, wo der Mensch erreicht wird. Aufforderungen, die inline erscheinen wurden, werden an ein Postfach weitergeleitet, und die Sitzung pausiert, bis der Benutzer antwortet. Es gibt keinen "mach, was Sie wollen"-Modus.
Zweitens: Die integrierte "Ops Persona" weist das Modell explizit an, Inhalte aus Tools, Logs, dem Web, Dateien und eingehenden Nachrichten als unvertrauenswurdige Daten zu behandeln, nicht als Anweisungen. Dies ist eine bewusste Prompt-Injection-Haltung, die in die ausgelieferte Persona eingebaut ist - nicht als nachtraglicher Einfall.
Eigenes Modell, eigene Daten
OpenWorker betreibt keinen eigenen Inferenzdienst. Benutzer fugen einen API-Schlussel ein oder richten die App auf eine lokale Laufzeit. Die kuratierte Modell-Matrix enthalt genau 30 Eintrage:
- Native Anbieter: OpenAI (GPT-5.6 Sol/Terra/Luna, GPT-5.5), Anthropic (Claude Fable 5, Opus 4.8, Sonnet 4.6, Haiku 4.5), Google (Gemini 3.1 Pro, 3.6 Flash, 2.5 Pro, 2.5 Flash)
- OpenAI-kompatibel: GLM-5.2, DeepSeek V4, Kimi K2.6, MiniMax M2.5, Qwen3 Max, Grok 4.3, Mistral Large
- Open-Weight: Together AI, Fireworks
- Vollstandig lokal: Ollama (kein Schlussel erforderlich)
Die Privatsphare folgt aus der Architektur: Modellaufrufe gehen direkt vom Rechner zum konfigurierten Anbieter. Gesprache, Connector-Tokens und Modell-Schlussel bleiben im lokalen Secret Store der App. Die einzige Cloud-Komponente ist ein optionaler Broker, der OAuth-Handshakes fur Ein-Klick-Connectors abwickelt - und die Tokens werden direkt an den Rechner ubergeben, nie in der Cloud gespeichert.
Die App ist im abgemeldeten Zustand voll funktionsfahig, mit manuell eingegebenen Zugangsdaten.
Der Ng-Effekt
Andrew Ng ist nicht einfach nur ein weiterer Entwickler, der einen Open-Source-Agenten veroffentlicht. Sein Kurs "AI for Everyone" auf Coursera hat Millionen von Menschen beigebracht, was maschinelles Lernen ist und was nicht. Seine Arbeit bei Google Brain und Baidu hat den Deep-Learning-Boom gepragt. Wenn Ng ein Tool veroffentlicht, tragt es ein padagogisches Signal: Das ist die Richtung, in die sich das Feld seiner Meinung nach entwickeln sollte.
OpenWorkers Richtung ist klar: KI sollte ein Werkzeug sein, das man besitzt, kein Dienst, den man abonniert. Sie sollte Arbeit erledigen, nicht nur reden. Und sie sollte um Erlaubnis fragen, bevor sie etwas Bedeutendes tut.
Ob diese Vision sich gegen die Bequemlichkeit von Cloud-basierten Assistenten durchsetzt - oder gegen die Tragheit der Chat-Oberflache - ist die Frage, die das nachste Jahr beantworten wird. Aber die Wette ist auf dem Tisch, und sie ist MIT-lizenziert fur jeden, der darauf aufbauen will.