UFO³：从单机 GUI 代理到跨设备 DAG 编排的跃迁
UFO³: Weaving the Digital Agent Galaxy
秒懂
- 它是什么？
- 微软 UFO 仓库已从单机 Windows 代理演进为 UFO³ Galaxy 多设备编排框架。本文基于仓库文档与发布记录，拆解其 DAG 任务模型、AIP 通信协议与设备代理机制，并指出它在复杂度和运维上的真实代价。
- 适合谁用？
- UFO³ 适合需要跨 Windows、Linux 与 Android 设备协调多步骤任务的团队，尤其是已有 UFO² 单机自动化基础、想向编排层扩展的用户。它不适合只需要单设备简单 GUI 点击流的人，那种场景直接使用 UFO² 的 ReAct 循环更省事。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个仓库，两条产品线
microsoft/UFO 的根 README 不再描述单一软件，而是指向两个并列的入口。UFO² 是稳定的单机 Windows 桌面代理，采用 HostAgent 加 AppAgents 的层级结构，在 ReAct 循环里顺序执行 GUI 与 API 混合动作。UFO³ Galaxy 则是 2025 年 11 月出现的新框架，把任务分解成有依赖关系的 DAG，由 ConstellationAgent 和 TaskOrchestrator 协调，跨 Windows、Linux、Android 设备并行执行。仓库默认分支仍在活跃推送，2026 年 8 月发布了 v3.0.8。两条线不是替代关系，文档明确说 UFO² 仍受长期支持，并且可以作为 Galaxy 的 Windows 设备代理。选择哪条路径，取决于你要处理的是单机点击流，还是跨设备的工作流。
DAG 不是噱头，是调度根基
Galaxy 的核心机制是把用户请求声明式地分解为动态 DAG，节点是 TaskStar，边是依赖关系。这与 UFO² 的顺序 ReAct 循环有本质区别。顺序循环里，下一步动作依赖上一步的文本输出，天然串行。DAG 模型则允许调度器在依赖满足时并行推进多个节点。文档强调两个特性：动态 DAG 编辑，以及结果驱动的图演化。意思是执行反馈可以触发受控的图重写，而不是执行前一次性定死。这种设计适合多设备场景，因为设备间的等待时间远大于单机函数调用，并行度直接决定端到端延迟。代价是任务必须能被建模为无环图，如果工作流本质是长串的强顺序步骤，DAG 的调度开销不会带来收益。
AIP：设备之间的安全信道
跨设备协调需要一个统一的通信层。Galaxy 把它做成 Unified Agent Interaction Protocol，简称 AIP，基于 WebSocket，带容错与自动重连。文档用词是 secure coordination layer，但并未给出握手、鉴权或加密的具体细节，仓库材料里也没有协议规范文件。这一点值得注意：如果你要把 AIP 暴露到不可信网络，需要自行补安全设计。AIP 解决的是设备发现与消息路由问题，让 ConstellationAgent 能把子任务派发给不同平台上的设备代理。能力匹配是另一层机制，文档称为 capability-based device matching，即调度器按设备声明的能力而非固定拓扑来选择执行者。协议本身不限定设备类型，这为后续加入更多平台留了接口。
设备代理的模板化路线
Galaxy 不要求所有设备运行 UFO²。文档提出 Template-Driven MCP-Empowered Device Agents，即用轻量模板快速开发设备代理，并通过 MCP 接入外部工具。这意味着新设备接入的成本被压缩到写一个代理模板，而不是移植整个 GUI 代理栈。UFO² 的角色被降级为可选的 Galaxy 设备代理之一，而不是唯一选项。这个设计有实际意义：Android 设备不可能跑完整的 Windows AgentOS，模板化是覆盖异构平台的务实路径。但模板化也意味着能力上限由模板决定，复杂的应用内状态管理仍然需要专门的代理逻辑，模板只是起点。仓库没有给出模板的代码示例，实际开发难度需要看 galaxy 子目录的文档才能判断。
版本节奏与演进时间线
仓库的版本历史显示三个节点：2024 年 2 月的 UFO，2025 年 4 月的 UFO²，2025 年 11 月的 UFO³ Galaxy。发布频率在 2026 年明显加快，v3.0.6 在 6 月 6 日，v3.0.7 在 6 月 12 日，v3.0.8 在 8 月 10 日。间隔从六天到两个月不等，说明 Galaxy 处于快速迭代期。对采用者意味着两件事：缺陷修复和功能增补来得快，但 API 变动风险也高。文档把 Galaxy 标注为 Active Development，UFO² 标注为 LTS，这个区分是诚实的。如果你需要可预测的长期稳定，UFO² 是更安全的选择；如果你要跨设备能力，就得接受 Galaxy 的版本波动。Python 版本限定为 3.10 和 3.11，没有跟进 3.12 或 3.13，这在实际部署中可能是个约束。
与 UFO² 的边界在哪里
README 中的对比表把两条线的分工说得很清楚。UFO² 是单设备多应用，任务是应用级别的规划，执行是顺序的。Galaxy 是设备级别的规划，任务带依赖关系，执行是并行的。文档给出的迁移路径有三步：继续用 UFO²，逐步采用 Galaxy 并把 UFO² 当作 Windows 设备代理，最后扩展规模。这个路径设计说明微软意识到用户不会一夜切换。真正的分界点在于任务是否天然跨设备。一个只在单台 Windows 机器上操作 Excel 和 Outlook 的流程，用 Galaxy 只会引入不必要的编排层。反过来，一个需要 Windows 处理文档、Linux 跑脚本、Android 收通知的流程，UFO² 根本做不到，Galaxy 才是对应工具。
替代方案的差异不在功能表
与 UFO³ 可比的不是另一个 GUI 代理，而是任务编排框架本身。比如 Temporal 或 Prefect 这类通用工作流引擎，它们同样用 DAG 建模任务依赖，同样支持异步执行与重试。差异在于抽象层级。Temporal 把活动定义为代码函数，设备只是执行环境；UFO³ 把设备当作一等公民，调度器按能力匹配设备，并且通过 AIP 协议与设备上的 GUI 代理通信。这意味着 UFO³ 能操作没有 API 的桌面应用，而 Temporal 只能调用有程序接口的服务。反过来，Temporal 不关心 GUI，也没有 MCP 工具接入的概念。如果你的自动化目标全是命令行或 HTTP 服务，通用引擎更轻；如果目标是跨设备的图形界面操作，UFO³ 的模型更贴近问题本身。
许可与维护的现实考量
项目采用 MIT 许可，这对商业使用是低摩擦的，没有 copyleft 义务。但 MIT 不附带任何维护承诺，仓库的活跃推送和版本发布只能说明当前状态，不能保证未来方向。Galaxy 的文档、演示视频和 arXiv 论文（编号 2511.11332 与 2504.14603）都存在，但 README 本身没有列出贡献指南、问题跟踪规范或安全响应流程。如果你要把它嵌入生产环境，需要自己承担升级测试、协议兼容性验证和故障排查。AIP 的容错与自动重连是文档承诺，但具体行为边界没有细节，比如网络分区时 DAG 如何暂停或回滚，这些只能通过实际部署或阅读源码确认。对一个编排框架来说，失败模式的可预期性比功能数量更重要。
编辑结论
UFO³ 适合需要跨 Windows、Linux 与 Android 设备协调多步骤任务的团队，尤其是已有 UFO² 单机自动化基础、想向编排层扩展的用户。它不适合只需要单设备简单 GUI 点击流的人，那种场景直接使用 UFO² 的 ReAct 循环更省事。若要采用，先验证三件事：你的任务能否被拆成无环依赖图，而不是天然顺序执行的长链；你的设备是否满足 Python 3.10 或 3.11 的运行要求；你是否接受 MIT 许可下微软对架构的持续改动，因为 Galaxy 仍处活跃开发期，v3.0.8 只是 2026 年 8 月的版本，API 未必稳定。该仓库的长期价值在于把设备级依赖显式建模为 DAG，这是单机代理无法覆盖的边界。
社区笔记