Andrew Ng kündigt OpenWorker an, einen quelloffenen, lokal ausgerichteten Desktop-KI-Coworker
Wichtige Erkenntnisse
- •OpenWorker ist ein quelloffener, MIT-lizenzierter Desktop-Agent von Andrew Ng, der fertige Arbeitsergebnisse statt Chat-Antworten erzeugt.
- •Das System läuft vollständig auf dem Gerät des Nutzers und nutzt eine Vier-Schichten-Architektur aus Tauri-2-Desktop-Shell, lokalem Python-FastAPI-Agentenserver, Fähigkeits- und Konnektorschicht sowie Modell-Router.
- •Nutzer müssen eigene API-Schlüssel oder lokale Laufzeitumgebungen bereitstellen, um auf 30 kuratierte Modelle von Anbietern wie OpenAI, Anthropic, Google und Ollama zuzugreifen.
- •Eine typisierte Risiko-Engine ordnet jeden Tool-Aufruf einer von vier Risikoklassen zu — read, write_local, exec oder external — und steuert die Ausführung über fünf Berechtigungsmodi hinweg.
- •Das Local-first-Datenschutzmodell hält Konversationen, Konnektor-Tokens und Modellschlüssel auf dem Gerät des Nutzers; ein optionaler Cloud-Broker wird ausschließlich für OAuth-Handshakes verwendet.

Andrew Ng hat OpenWorker angekündigt, einen quelloffenen Desktop-Agenten, der darauf ausgelegt ist, fertige Arbeitsergebnisse statt chatbasierter Antworten zu liefern. Ng ist Gründer von DeepLearning.AI, leitete zuvor die KI-Forschung bei Google Brain und Baidu und war Mitgründer von Coursera. Die Ankündigung wurde auf X unter https://x.com/AndrewYNg/status/2080333504446108104 geteilt.
OpenWorker ist auf Ergebnisse statt auf Prompts ausgerichtet. Ein Nutzer kann ein ausgearbeitetes Dokument, eine Slack-Antwort mit konkreten Zahlen, einen aktualisierten Kalender oder einen vorsortierten Posteingang anfordern. Das System zerlegt das gewünschte Ergebnis anschließend in Schritte, arbeitet über lokale Dateien und verbundene Anwendungen hinweg und fragt beim Nutzer nach, bevor es folgenreiche Aktionen ausführt. Damit gehört OpenWorker zu einer entstehenden Kategorie agentischer KI-Tools, die mehrstufige Aufgaben anwendungsübergreifend erledigen, statt lediglich Textantworten zu erzeugen.
Vier-Schichten-Architektur auf dem lokalen Gerät
Die Architektur von OpenWorker ist in vier Schichten organisiert, die alle auf dem Gerät des Nutzers laufen. Das Repository enthält 119 Python-Dateien mit insgesamt rund 32.400 Zeilen unter coworker/, 149 TypeScript/TSX-Dateien unter surfaces/gui/ sowie 78 Backend-Testmodule.
Die Desktop-Shell ist ein natives Tauri-2-Fenster, das eine React-18-Benutzeroberfläche kapselt. Tauri ist ein quelloffenes Framework zum Erstellen leichtgewichtiger Desktop-Anwendungen mit Web-Frontends und nativem Systemzugriff. Die Bundle-ID lautet com.openworker.desktop, und die Shell überwacht den Python-Server selbst.
Der lokale Agentenserver nutzt Python 3.10+ mit FastAPI und uvicorn. Standardmäßig bindet er an 127.0.0.1:8765. Die Beispielkonfiguration begrenzt einen einzelnen Durchlauf auf 12 Modell-Tool-Iterationen.
Die Fähigkeits- und Konnektorschicht umfasst geprüfte lokale Tools für Dateien, git, ripgrep-gestützte Suche, Shell-Zugriff und Todo-Verwaltung sowie gehostete Integrationen und MCP, das Model Context Protocol: MCP ist ein offener Standard, der Ende 2024 von Anthropic eingeführt wurde, um KI-Assistenten über ein gemeinsames Protokoll mit externen Datenquellen und Tools zu verbinden.
Der Modell-Router stellt eine einheitliche Schnittstelle für native, OpenAI-kompatible, Reseller- und lokale Anbieter bereit. Die Engine basiert auf aisuite, Andrew Ngs anbieterunabhängiger LLM-Bibliothek: https://github.com/andrewyng/aisuite. aisuite bietet eine einheitliche Schnittstelle zum Aufrufen von Modellen mehrerer Anbieter, ohne den Anwendungscode ändern zu müssen.
Bring-your-own-model-Zugang
OpenWorker stellt keinen eigenen Inferenzdienst bereit. Nutzer fügen entweder einen API-Schlüssel in die App ein oder verweisen sie auf eine lokale Laufzeitumgebung. Das bedeutet, dass Nutzer Anbieter direkt bezahlen und die Kontrolle darüber behalten, welche Modelle ihre Daten verarbeiten.
Die kuratierte Modellmatrix enthält genau 30 Einträge. Zu den nativen Anbietern zählen OpenAI mit GPT-5.6 Sol, GPT-5.6 Terra, GPT-5.6 Luna und GPT-5.5; Anthropic mit Claude Fable 5, Opus 4.8, Sonnet 4.6 und Haiku 4.5; sowie Google mit Gemini 3.1 Pro, 3.6 Flash, 2.5 Pro und 2.5 Flash.
OpenAI-kompatible Anbieter ergänzen GLM-5.2, DeepSeek V4, Kimi K2.6, MiniMax M2.5, Qwen3 Max, Grok 4.3 und Mistral Large. Open-weight-Modelle sind über Together AI, und Fireworks, verfügbar. Vollständig lokale Modelle sind über Ollama, verfügbar, wofür kein API-Schlüssel erforderlich ist.
Berechtigungssystem und Risikoklassen
OpenWorker behandelt Genehmigungen als typisierte Schicht und nicht nur als Funktion der Benutzeroberfläche. Jeder Tool-Aufruf wird einer von vier Risikoklassen zugewiesen: read für Aktionen ohne Nebenwirkungen, write_local für pfadgebundene Änderungen am Arbeitsbereich, exec für das Ausführen von Befehlen und external für Aktionen mit Nebenwirkungen außerhalb des Geräts.
Fünf Berechtigungsmodi bestimmen, wie diese Aktionen behandelt werden. discuss und plan sind schreibgeschützte Modi. interactive ist die Standardeinstellung und fordert vor Schreibvorgängen, Befehlen und externen Aktionen eine Genehmigung an. auto erlaubt alle Aktionen, bleibt dabei jedoch pfadgebunden. custom genehmigt automatisch eine vom Nutzer definierte Liste von Tools.
Zwei Designentscheidungen prägen das Genehmigungsmodell. Erstens erhöht der unbeaufsichtigte Modus nicht den Autonomiegrad; er ändert nur, wo der Nutzer kontaktiert wird. Prompts, die normalerweise inline erscheinen würden, werden an einen Posteingang weitergeleitet, und die Sitzung wird ausgesetzt, bis der Nutzer antwortet.
Zweitens sind aufgabenbezogene Dauerregeln auf externe Risiken beschränkt. Shell-Befehle erfordern weiterhin grundsätzlich eine Genehmigung.
Die integrierte Ops-Persona weist das Modell außerdem an, Inhalte aus Tools, Logs, dem Web, Dateien und eingehenden Nachrichten als nicht vertrauenswürdige Daten und nicht als Anweisungen zu behandeln. Diese Haltung gegenüber Prompt-Injection ist in die ausgelieferte Persona eingeschrieben. Die Behandlung externer Inhalte als nicht vertrauenswürdige Daten ist eine Abwehr gegen indirekte Prompt-Injection, einen Angriffsvektor, bei dem bösartige Anweisungen, die in Datenquellen eingebettet sind, versuchen, das Verhalten eines Agenten zu manipulieren.
Local-first-Datenschutzmodell
Modellaufrufe werden direkt vom Gerät des Nutzers an den konfigurierten Anbieter gesendet. Konversationen, Konnektor-Tokens und Modellschlüssel bleiben lokal. Der Secret Store ist so konzipiert, dass Geheimnisse nicht in den Kontext, die Prompts oder die Traces des Modells gelangen.
Die einzige Cloud-Komponente ist ein optionaler Broker für OAuth-Handshakes, die von One-Click-Konnektoren verwendet werden. Er nutzt Auth0 Authorization Code mit PKCE. Konnektor-Tokens werden direkt an das Gerät des Nutzers übergeben und nicht in der Cloud gespeichert. Die App bleibt auch abgemeldet vollständig funktionsfähig, wenn manuell eingefügte Zugangsdaten verwendet werden.
OpenWorker ist MIT-lizenziert und als Desktop-KI-Coworker positioniert, der fertige Arbeitsergebnisse statt Chat-Antworten zurückgibt. Sein Stack kombiniert eine Tauri-2- und React-Shell mit einem lokalen Python-FastAPI-Agentenserver auf Basis von aisuite. Der Modellzugang erfolgt per Bring-your-own-key über 30 kuratierte toolaufrufende Modelle, mit vollständig lokalem Zugriff über Ollama. Eine typisierte Risiko-Engine mit read, write_local, exec und external steuert Aktionen über fünf Berechtigungsmodi hinweg.
Das GitHub-Repository von OpenWorker ist unter https://github.com/andrewyng/openworker verfügbar, die Projektseite unter