dws: DingTalk-Dienste als Kommandozeile, gebaut für Menschen und KI-Agenten
Projektüberblick: DingTalk Workspace ist ein offiziell quelloffenes, plattformübergreifendes CLI-Tool von DingTalk. Es vereint die gesamten Produktfunktionen von DingTalk in einem einzigen Paket und ist sowohl für menschliche Benutzer als auch für KI-Agent-Szenarien konzipiert.
Auf einen Blick
- Was ist das?
- Ein Go-Tool unter Apache-2.0, das Kalender, Chat, Dokumente, Drive und weitere DingTalk-Dienste hinter eine einzige Kommandozeile legt und Agent-Skills mitliefert.
- Für wen ist es gedacht?
- dws passt für Teams, deren Organisation bereits DingTalk betreibt und die Dienstzugriff aus Skripten oder KI-Agenten wollen. Es passt nicht, wenn Videokonferenzen im Spiel sind oder die Unternehmensverwaltung CLI-Zugriff nicht freigibt.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 17. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Go-CLI für die gesamte DingTalk-Produktpalette
DingTalk Workspace CLI, aufgerufen als dws, ist ein in Go geschriebenes Kommandozeilenwerkzeug, das DingTalk-Real-AI als offizielle Open-Source-Veröffentlichung des Messenger-Anbieters betreibt. Statt zwischen Webclient, Mobilgerät und Verwaltungskonsole zu wechseln, sollen menschliche Benutzer und KI-Agenten Dienste wie Kalender, Chat, Dokumente, Drive, E-Mail, Wiki, AI-Tabellen (aitable), Besprechungsnotizen und Tabellenkalkulation (sheet) über eine einzige Schnittstelle erreichen.
Das README unterscheidet drei Zielgruppen. Menschen erhalten Hilfetexte über --help, Vorschauen ohne Ausführung über --dry-run sowie Ausgabeformate als Tabelle, JSON oder Rohformat über -f table/json/raw. KI-Agenten erhalten strukturierte JSON-Antworten und mitinstallierte Agent-Skills. Administratoren erhalten laut Projektbeschreibung OAuth-Device-Flow-Authentifizierung, Domain-Allowlisting und Rechtevergabe nach dem Prinzip der geringsten Privilegien. Die Repositorium-Metadaten nennen Apache-2.0 als Lizenz; der letzte Push liegt Ende August 2026.
Installation über Skript, npm, Homebrew und Go-Build
Für macOS und Linux dokumentiert das README eine Einzeilen-Installation per Shell-Skript, für Windows ein PowerShell-Gegenstück mit irm und iex. Daneben existiert ein npm-Paket namens dingtalk-workspace-cli, dessen Beta-Version über das Suffix @beta erreichbar ist. Der Homebrew-Weg verlangt beim ersten tap eine explizite Repository-URL, weil die Formula im selben Repository liegt; danach genügt brew upgrade dingtalk-workspace-cli.
Wer aus dem Quellcode baut, klont das Repository und ruft go build -o dws ./cmd auf, wofür Go 1.25 oder neuer nötig ist. make package überträgt laut README für alle Plattformen auf amd64 und arm64. Statische Endpunktdaten stammen aus einer Wukong-Basis und liegen eingecheckt unter internal/syncdata, sodass der Quellcode-Build keinen separaten Daten-Checkout braucht. Auf macOS kann das vorgefertigte Binärprogramm an der Gatekeeper-Prüfung scheitern; das README führt dafür xattr -d com.apple.quarantine /path/to/dws an.
Authentifizierung: Device-Flow, Profile und Unternehmensfreigabe
Der Einstieg läuft über dws auth login, das einen Browser öffnet, oder über dws auth login --device für Umgebungen ohne Browser wie Docker, SSH oder CI. Das Projekt befindet sich laut README in einer Co-Creation-Phase: Der Zugriff zielt auf DingTalk-Unternehmensdaten und setzt die Autorisierung durch Unternehmensadministratoren voraus. Hat eine Organisation den CLI-Zugriff nicht aktiviert, sendet der Benutzer eine Anfrage, die der Administrator genehmigen muss.
Für CI/CD und ISV-Integration gibt es einen Modus mit benutzerdefinierter App über Client-ID und Secret, wobei die Anmeldedaten im System-Keychain landen. Mehrere Organisationen und Konten werden über Profile unterstützt, die eindeutig über corpId:userId identifiziert werden. Ein Export- und Importverfahren verschiebt die Authentifizierung zwischen Linux-Sandboxes; unter Windows wird der Export absichtlich abgelehnt, weil dort Anmeldedaten als DPAPI-geschützte Registrierungswerte vorliegen.
Skill-Modi multi und mono für KI-Agenten
Der Installer liefert Agent-Skills in zwei Layouts aus. Der Standardmodus multi installiert pro Produkt eigene Skills wie dingtalk-aitable, dingtalk-calendar oder dingtalk-chat und hält laut README den Kontext pro Aufruf klein. Der ältere Modus mono bündelt alles in einen einzigen dws-Skill und bleibt über DWS_SKILL_MODE=mono oder nachträglich über dws skill setup --mode mono erreichbar, wobei die betroffenen Pfade aufgelistet und interaktiv bestätigt werden. Die CLI-Befehle selbst sind in beiden Modi identisch; nur die agentenseitige Organisation unterscheidet sich.
Die Skills landen in Tool-Verzeichnissen wie ~/.agents, ~/.claude und ~/.cursor. Wer die Beta des Homebrew-Pakets nutzt, findet das zugehörige Programm unter $(brew --prefix dingtalk-workspace-cli-beta)/bin/dws, ohne die stabile Formula zu überschreiben.
Agent-Schnittstelle: dws schema, NDJSON-Streams und Fehlerkorrektur
Für Agentenbetrieb exportiert dws schema Befehlskontrakte, die Agenten zur Befehlsauswahl und Parameterversorgung nutzen können. Als maßgebliche Quelle dafür, ob ein Befehl existiert und welche Flags er annimmt, nennt das README dws <path> --help. Eine eingebaute Eingabekorrektur normalisiert Flagnamen, trennt verklebte Argumente und gleicht Tippfehler ab; ein jq-Filter soll den Token-Verbrauch bei Antworten senken.
Für Ereignisse gibt es ein Abonnement persönlicher Nachrichten über einen Stream, das NDJSON auf die Standardausgabe schreibt, und dws dev connect verbindet einen DingTalk-Roboter mit einem lokalen KI-CLI. Die vollständige Befehlsliste liegt laut README in docs/command-index.md. Eine Grenze nennt die Dokumentation selbst: Videokonferenzen sind noch nicht abgedeckt.
Upgrade-Pfad und selbst berichtete Sicherheitsmerkmale
Ab Version 1.0.7 kann sich dws selbst aktualisieren. dws upgrade --check prüft ohne Installation, --list zeigt stabile Versionen, --beta wechselt auf den Beta-Kanal. Laut README werden Updates aus GitHub Releases mit SHA256-Prüfung und automatischer Sicherung bezogen, in zwei Phasen ausgeführt und erst nach erfolgreicher Vorbereitung angewendet. Das Repository enthält unter verify/ ein Skript, das Smoke-Tests für curl, PowerShell, npm-Stable, npm-Beta, Homebrew und den Upgrade-Pfad selbst ausführt und pro Plattform PASS, FAIL oder SKIP meldet.
Der Abschnitt Security by Design beschreibt eine Token-Verschlüsselung mit PBKDF2 und AES-256-GCM, gebunden an die physische MAC-Adresse des Geräts, Schutz vor Pfad-Traversal, eine Standard-Allowlist auf *.dingtalk.com und erzwungenes HTTPS. Diese Aussagen sind Selbstbeschreibungen des Projekts; ein unabhängiges Audit oder Zertifizierungen Dritter weist die Dokumentation nicht aus.
Fazit: für wen dws passt und was die Alternative ist
dws lohnt sich für Teams, die DingTalk im Betrieb haben und Dienstzugriffe aus Skripten, CI oder KI-Agenten heraus brauchen, ohne für jeden Vorgang den Webclient zu öffnen. Wer ein anderes Messaging-Produkt nutzt, Videokonferenzen braucht oder keine Kooperation der eigenen Administratoren bekommen kann, bleibt außen vor. Die Co-Creation-Phase und die Pflicht zur Administratorfreigabe sind reale Einstiegshürden, kein Detail.
Als Alternative bleibt der direkte Weg über die DingTalk Open Platform API: mehr Kontrolle über jeden Endpunkt, aber ohne die CLI-Ergonomie, ohne Skill-Layout und ohne die eingebaute Korrektur. Wer dws prüft, sollte konkret testen, ob die Verwaltung den CLI-Zugriff freigibt, und danach mit dws auth login --device und --dry-run einen ersten Lesezugriff gegen unkritische Daten ausführen.
Redaktionelles Fazit
dws passt für Teams, deren Organisation bereits DingTalk betreibt und die Dienstzugriff aus Skripten oder KI-Agenten wollen. Es passt nicht, wenn Videokonferenzen im Spiel sind oder die Unternehmensverwaltung CLI-Zugriff nicht freigibt. Vor der Einführung sollten Administratoren die Freigabe klären und ein Login über dws auth login --device gegen Testdaten ausprobiert werden.
Community-Notizen