microsoft/UFO: Vom Windows-Agenten zum Multi-Device-Orchestrator
UFO³: Weaving the Digital Agent Galaxy
Auf einen Blick
- Was ist das?
- UFO³ besteht aus zwei Teilen: dem stabilen Windows-Agenten UFO² und dem neuen Orchestrierungsframework Galaxy. Der Artikel beschreibt, wie die DAG-Planung funktioniert, was die Einrichtung verlangt und wo das Projekt an seine Grenzen stößt.
- Für wen ist es gedacht?
- Wer einzelne Windows-Aufgaben automatisieren will, fährt mit UFO² als LTS-Pfad und sollte dort zuerst die Quick-Start-Anleitung und die Modellkonfiguration prüfen. Für verteilte Abläufe über mehrere Geräte ist Galaxy gedacht, aber der Status aktiver Entwicklung und die Einstiegshürde machen einen Test auf einem einzelnen Gerät vor jedem Rollout sinnvoll.
- Darf ich es kommerziell nutzen?
- Ja. MIT 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 Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem UFO adressiert und für wen es gedacht ist
UFO ist ein Agenten-Framework von Microsoft, das grafische Benutzeroberflächen steuert. Der Ursprung liegt laut der im README abgebildeten Evolutionsgrafik bei einem GUI-Agenten für Windows (Februar 2024), der im April 2025 zu UFO² als Desktop AgentOS wurde und im November 2025 mit UFO³ Galaxy um eine Multi-Device-Orchestrierung erweitert wurde. Die Zielgruppe sind damit zwei verschiedene Leser: Wer einzelne Windows-Programme per Agent automatisieren möchte, ist bei UFO² richtig. Wer Abläufe über mehrere Rechner oder Plattformen hinweg koordinieren will, wird auf Galaxy verwiesen.
Das README nennt für UFO² ausdrücklich Single-Windows-Automatisierung, schnelle Aufgabenausführung und einfachen Einstieg. Für Galaxy stehen Cross-Device-Kollaboration, komplexe mehrstufige Automatisierung, DAG-basierte Aufgabenorchestrierung und die Integration heterogener Plattformen im Vordergrund. Der Unterschied ist nicht kosmetisch: UFO² arbeitet mit einer sequenziellen ReAct-Schleife auf Anwendungsebene, Galaxy plant auf Geräteebene mit Abhängigkeiten zwischen den Aufgaben. Wer nur ein Programm auf einem Rechner bedienen will, trägt mit Galaxy zusätzliche Komplexität ohne Gegenwert.
Constellation, TaskStars und der Orchestrierungsfluss in Galaxy
Galaxy zerlegt eine Anfrage in einen gerichteten azyklischen Graphen, im README als DAG mit TaskStars und Abhängigkeiten beschrieben. Die Planungskomponente heißt ConstellationAgent, die Ausführung übernimmt ein TaskOrchestrator. Das README führt fünf Designprinzipien auf: deklarative Zerlegung in einen dynamischen DAG, kontinuierliche ergebnisgetriebene Graph-Evolution, heterogene asynchrone Orchestrierung mit Capability-basiertem Gerätematching, ein einheitliches Agent Interaction Protocol (AIP) sowie templategetriebene, MCP-gestützte Device Agents.
Für die Praxis ist vor allem die Graph-Evolution relevant. Der DAG ist kein statischer Plan, der einmal erstellt und dann abgearbeitet wird. Er wird zur Laufzeit umgeschrieben, wenn Ausführungsergebnisse zurückkommen. Das erklärt, warum Galaxy asynchron arbeitet und Aufgaben parallel koordinieren kann: Abhängigkeiten können sich während des Laufs ändern, und der Orchestrator muss damit umgehen. Die Kommunikation zwischen den Agenten läuft laut README über AIP, ein WebSocket-basiertes Protokoll mit Fehlertoleranz und automatischer Wiederverbindung. Sicherheit wird über Capability-basiertes Gerätematching und Locking adressiert. Wer den DAG nachvollziehen will, muss also die Rückmeldungen der Device Agents mitlesen, nicht nur den initialen Plan.
Installation und Konfiguration: was das Material hergibt
Das README verweist für Galaxy auf eine Quick-Start-Seite unter microsoft.github.io/UFO/getting_started/quick_start_galaxy/ und für UFO² auf ufo/README.md. Konkrete Befehle oder Config-Keys sind im vorliegenden Auszug nicht enthalten. Wer die Einrichtung plant, muss diese Seiten selbst aufrufen; aus dem Repository-Auszug lassen sich weder ein pip-Paketname noch eine Konfigurationsdatei ableiten. Das ist eine Einschränkung dieses Artikels, keine Aussage über die Dokumentation insgesamt.
Gesichert ist aus dem Auszug nur der Rahmen: Python 3.10 oder 3.11, Lizenz MIT, Standardbranch main. Die Versionsnummern der jüngsten Releases lauten v3.0.8 (August 2026), 3.0.7 (Juni 2026) und 3.0.6 (Juni 2026). Der Rhythmus deutet auf häufige Patch-Releases hin. Wer Galaxy produktiv einsetzen will, sollte die Quick-Start-Seite und die Galaxy-README als primäre Quellen nehmen und die dort genannten Schritte befolgen, statt aus dem Haupt-README Kommandos zu rekonstruieren. Für UFO² gilt dasselbe: Die verlinkte README ist die maßgebliche Anleitung.
Wo UFO an Grenzen stößt
Die deutlichste Einschränkung steht im README selbst: UFO² unterstützt Cross-Device-Kollaboration nicht, Galaxy dagegen schon. Umgekehrt gilt, dass Galaxy mit moderater Lernkurve und mittlerem Setup-Aufwand beschrieben wird, während UFO² als einfach einzurichten gilt. Wer also nur ein Windows-Programm automatisieren will, zahlt bei Galaxy für Fähigkeiten, die er nicht braucht.
Ein zweiter Punkt betrifft den Reifegrad. UFO² wird als LTS gekennzeichnet, Galaxy als aktive Entwicklung. Das README nennt Galaxy zwar empfohlen und neu, aber der Status aktiver Entwicklung bedeutet, dass sich Verhalten und Schnittstellen zwischen Releases ändern können. Die Release-Historie mit drei Veröffentlichungen innerhalb weniger Monate stützt diese Einschätzung. Ein weiterer Vorbehalt: Das README listet Windows, Linux und Android als unterstützte Geräte und fügt hinzu, dass weitere folgen. Wer heute andere Plattformen einbinden will, findet dafür im Auszug keine Zusage. Und die Aussage zur formal verifizierten Korrektheit der Orchestrierung ist eine Designaussage aus dem README, kein unabhängig geprüfter Nachweis. Wer Korrektheitsgarantien braucht, sollte die verlinkten arXiv-Papiere heranziehen und selbst bewerten.
UFO² als Alternative zu Galaxy und der Unterschied im Ansatz
Die naheliegende Alternative innerhalb desselben Projekts ist UFO². Der Ansatz unterscheidet sich grundlegend: UFO² arbeitet mit einer sequenziellen ReAct-Schleife und einem HostAgent plus AppAgents auf einem einzigen Windows-Rechner. Galaxy ersetzt das durch einen DAG über mehrere Geräte, mit ConstellationAgent und TaskOrchestrator als Koordinationsebene und paralleler Ausführung. Die Aufgabenplanung wandert von der Anwendungsebene auf die Geräteebene.
Das ist keine Ablösung. Das README beschreibt ausdrücklich einen Migrationspfad: UFO² bleibt vollständig unterstützt und aktiv gepflegt, Galaxy kann einen UFO²-Agenten als Windows Device Agent verwenden, und der Umstieg kann schrittweise erfolgen. Wer heute mit UFO² arbeitet, muss also nicht wechseln. Wer einen einzelnen Windows-Rechner automatisiert, sollte es auch nicht, weil die sequenzielle Schleife für diesen Fall einfacher zu verstehen und zu debuggen ist. Der Wechsel lohnt erst, wenn Abhängigkeiten zwischen Aufgaben auf mehreren Geräten tatsächlich auftreten.
Pflegeaufwand, Versionen und Lizenz
Der Pflegeaufwand hängt davon ab, welchen Pfad man wählt. UFO² trägt das LTS-Label, was auf längere Stabilität und seltenere Breaking Changes hindeutet. Galaxy steht unter aktiver Entwicklung, und die Release-Folge v3.0.6, 3.0.7 und v3.0.8 zwischen Juni und August 2026 zeigt, dass mit häufigen Aktualisierungen zu rechnen ist. Wer Galaxy einsetzt, sollte einplanen, Releases zu verfolgen und die Änderungen an AIP, DAG-Format und Agent-Templates zu prüfen, bevor er aktualisiert. Für UFO² ist der Anpassungsdruck geringer.
Lizenzseitig steht das Projekt unter MIT. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, sofern der Urheberrechtshinweis und der Lizenztext beibehalten werden. Das README enthält keine zusätzlichen Bedingungen, keine Klauseln zu Marken oder Patenten und keine Hinweise auf duale Lizenzierung. Wer den Code in ein eigenes Produkt einbettet, muss die MIT-Bedingungen erfüllen; eine rechtliche Bewertung ersetzt diese Zusammenfassung nicht. Zu beachten ist außerdem, dass der Agent auf Modelle von Drittanbietern zugreift. Deren Nutzungsbedingungen und Kosten sind nicht Teil der MIT-Lizenz und müssen getrennt geprüft werden.
Für wen sich der Einstieg lohnt und was zuerst zu prüfen ist
Wer einzelne Windows-Aufgaben automatisieren will, sollte mit UFO² beginnen und die verlinkte ufo/README.md sowie die Quick-Start-Dokumentation als Ausgangspunkt nehmen. Das Setup gilt als einfach, die Lernkurve als niedrig, und der LTS-Status spricht für den Pfad. Wer dagegen Abläufe über mehrere Geräte koordinieren muss, für den ist Galaxy gedacht, aber mit dem Vorbehalt aktiver Entwicklung und mittlerem Setup-Aufwand.
Vor jedem Rollout zu klären ist, welche Geräte jenseits von Windows, Linux und Android tatsächlich unterstützt werden. Das README lässt das offen. Ebenso zu prüfen ist, ob Galaxy einen vorhandenen UFO²-Agenten als Device Agent einbinden kann, weil das den Migrationsaufwand bestimmt. Und wer die Aussage zur formal verifizierten Orchestrierung als Entscheidungsgrundlage nutzen will, sollte die beiden verlinkten arXiv-Papiere lesen, statt sich auf die README-Formulierung zu verlassen. Der erste konkrete Schritt ist die Quick-Start-Seite für Galaxy beziehungsweise die ufo/README.md für UFO², nicht die Lektüre des Haupt-README.
Redaktionelles Fazit
Wer einzelne Windows-Aufgaben automatisieren will, fährt mit UFO² als LTS-Pfad und sollte dort zuerst die Quick-Start-Anleitung und die Modellkonfiguration prüfen. Für verteilte Abläufe über mehrere Geräte ist Galaxy gedacht, aber der Status aktiver Entwicklung und die Einstiegshürde machen einen Test auf einem einzelnen Gerät vor jedem Rollout sinnvoll. Vor dem Einsatz zu klären sind der tatsächlich unterstützte Geräteumfang jenseits von Windows, Linux und Android sowie die Frage, ob Galaxy einen vorhandenen UFO²-Agenten als Device Agent einbinden kann.
Community-Notizen