UFO³ 拆解：把 Windows 桌面代理接進多裝置 DAG 星系

UFO 從單機 GUI 代理長成多裝置星系，中間多了什麼

README 的時間線把三代放在一起：2024 年 2 月的 UFO 是 Windows 的 GUI Agent，2025 年 4 月的 UFO² 定位為 Desktop AgentOS，2025 年 11 月的 UFO³ Galaxy 則是多裝置編排。這條線索決定了誰該看這個專案。如果你手上是一台 Windows 機器、要讓模型去點選單、填表單、跨應用搬資料，那 UFO² 就是為此設計的，README 把它標為 LTS 並描述為 battle-tested。真正的新問題出現在任務跨出單機之後：同一件事要同時涉及桌機、Linux 主機和 Android 裝置，UFO² 的 HostAgent 加 AppAgents 架構沒有處理跨裝置依賴的層次。Galaxy 補的就是這一層。它不取代裝置代理，而是把裝置代理當成被編排的節點。README 的對照表寫得很直白：UFO² 的任務模型是 sequential ReAct loop，Galaxy 是 DAG-based Constellation workflows；UFO² 的協調者是 HostAgent 與 AppAgents，Galaxy 換成 ConstellationAgent 與 TaskOrchestrator；跨裝置協作在 UFO² 欄位是 Not Supported，在 Galaxy 是 Core Feature。這不是功能疊加，而是任務模型換了一套。

Constellation 如何把一句話需求變成可改寫的 DAG

Galaxy 的核心機制是宣告式分解。使用者給的請求先被拆成結構化的 DAG，節點稱為 TaskStar，節點之間帶依賴關係，排程器再依這些依賴決定先後與並行。README 列出的第一條設計原則是 declarative decomposition into dynamic DAG，第二條是 continuous result-driven graph evolution，意思是這張圖在執行期間還會被改寫。這一點值得停下來看：多數工作流引擎的圖在提交後就固定，Galaxy 允許依執行回饋做受控的 rewrite 與動態調整。好處是中途發現某台裝置不可用、或某步驟輸出和預期不同時，不必整條重跑。代價是行為不像靜態管線那樣可預測，除錯時你面對的是一張會變的圖，而不是一份固定的步驟清單。README 對「受控改寫」的具體邊界沒有展開，官網文件是唯一能補細節的地方，若你的流程有合規稽核需求，這部分要先問清楚改寫的觸發條件與紀錄方式。

AIP 與非同步編排：能力匹配、鎖與重連

跨裝置的第二個問題是通訊。README 說 Galaxy 使用統一的 Agent Interaction Protocol，以 WebSocket 為基礎，具備容錯與自動重連。第三條設計原則提到 capability-based device matching，也就是依裝置能力去配對任務，而非硬編裝置名稱；同時有 async execution 與 safe locking。這組合透露了一個實際約束：當多個 TaskStar 並行、又可能搶同一台裝置的資源時，鎖是必要的，而鎖的存在代表某些任務其實無法真正平行。README 沒有給出鎖的粒度或逾時行為，這是我認為文件最薄的一塊。第四條原則把 AIP 描述為安全協調層，但 README 層級沒有說明認證與憑證交換的細節。若你要把裝置代理放到不同網段，這些細節會直接決定能不能上線，建議直接查官網文件而不是只看 README。

裝置代理的兩種來源：模板與 MCP 擴充

第五條設計原則是 template-driven MCP-empowered device agents，README 稱之為快速開發代理的輕量工具包，並整合 MCP 做工具擴充。這裡有兩條取得裝置代理的路徑。一條是用模板新建，適合 Linux 或 Android 這類 UFO² 原本不覆蓋的平台；另一條是直接沿用既有的 UFO²，README 在對照表與遷移路徑中都寫明 UFO² 可以作為 Galaxy 的 Windows device agent。第二條路對既有使用者更實際：你不必重寫 Windows 端的自動化邏輯，只要把它註冊進 Galaxy 當節點。README 列出的裝置支援範圍是 Windows、Linux、Android，並註明 more coming。這句話要當成邊界而非承諾，你的目標平台若不在這三個之內，現在沒有可依循的實作路徑。

啟動前要準備的設定與官方入口

README 沒有在首頁塞完整安裝指令，而是把入口指到兩處：galaxy/README.md 與官網的 getting_started/quick_start_galaxy 頁面。這是這個專案在文件組織上的特徵，Galaxy 與 UFO² 各有自己的 README，首頁只做分流。因此實際的安裝步驟、依賴清單與 LLM 設定鍵，必須以 quick_start_galaxy 為準，我在這裡不複述我無法從材料確認的指令。可以確認的環境條件有兩項：Python 版本標示為 3.10 與 3.11，授權為 MIT。另外 README 提供了官方 YouTube 示範影片與 arXiv 論文編號 2511.11332、2504.14603，前者對應 Galaxy 的設計說明，若你要評估 DAG 改寫與 AIP 的實際行為，論文比 README 更值得先讀。至於設定檔的具體鍵名與範例值，材料中沒有出現，請直接開 quick_start_galaxy 對照。

什麼時候 Galaxy 是錯的工具

README 自己的對照表給了最誠實的答案：UFO² 的學習曲線是 Low、設定難度標為 Easy、狀態是 LTS；Galaxy 的學習曲線是 Moderate、設定難度標為 Moderate、狀態是 Active Development。這三格放在一起，結論很清楚。如果你的自動化只在一台 Windows 機器上跑，導入 Galaxy 等於為了你不需要的跨裝置能力，額外承擔 DAG 編排、多節點部署與 WebSocket 連通性的成本。第二個不適用的情境是流程本身高度固定且步驟短：sequential ReAct loop 在這種任務上反而更容易預測與除錯，動態改寫的彈性在此沒有回報。第三個要留意的是版本節奏。README 列出的近期版本是 3.0.6、3.0.7、3.0.8，2026 年 6 月到 8 月之間連出三個版本，對照表中 Galaxy 標為 Active Development。這代表 API 與設定格式仍有變動空間，把它放進長期維運的生產流程前，要先確認你的升級策略能吸收這種頻率。

與同類方案的差異，以及維護成本與授權

要理解 Galaxy 的取捨，得把它和傳統工作流引擎放在一起看。Airflow 這類工具用 Python 定義 DAG，節點是函式或容器，圖在排程前就確定，重跑靠重試與冪等設計；Galaxy 的節點是裝置上的代理，圖會在執行中依回饋改寫，配對靠裝置能力而非寫死的 worker 佇列。差異在失敗處理：Airflow 假設失敗可以重試同一個任務，Galaxy 假設失敗可能意味著要換一台裝置、或改寫後續依賴。反過來說，Airflow 的執行紀錄與重現性是成熟的，Galaxy 的動態圖在這方面需要你自行確認。維護成本方面，UFO² 被標為 LTS，Galaxy 是 Active Development，兩者的升級負擔不同；若你同時跑兩者，等於維護兩套版本線。授權是 MIT，README 與 badge 都標明，這對商業整合相對寬鬆，但 MIT 只處理著作權層面的授權，不涉及你接上的 LLM 服務條款、也不涉及把代理部署到他人裝置時的合規問題。這些不在開源授權的範圍內，也不是本文能給出結論的部分，請依你的實際部署情境自行確認。

編輯結論

如果你要的是跨 Windows、Linux、Android 的多步驟自動化，而且願意承擔 DAG 編排與多節點部署的複雜度，UFO³ Galaxy 值得先做概念驗證；如果你只想在單台 Windows 上跑 GUI 自動化，UFO² 仍是官方標示為 LTS 的選項，README 也明確寫著 Galaxy 可以把 UFO² 當成 Windows 裝置代理使用，不需要二選一。動手前先確認三件事：你要接的裝置平台是否在 Windows、Linux、Android 這三個已列出的範圍內，你的 LLM 端點與金鑰設定是否符合文件中 quick_start_galaxy 的欄位，以及你的網路環境能不能讓 AIP 的 WebSocket 連線穩定重連。最後一點最容易被低估：README 把 AIP 描述為具備容錯與自動重連的協調層，但這意味著你的部署必須先解決跨機器連通性，否則 DAG 再漂亮也跑不起來。

官方來源

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