加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
「把智能体能力从单台设备扩展到多设备协同」——这是微软研究院 UFO 项目第三代版本给出的答案。
设想一个真实场景：周五下午，你要在家里 Windows 电脑上整理一份季度报表，需要从公司邮箱里抠出三张销售表；把表填进财务系统；再在平板上的 VPN 客户端上确认提交成功。三个应用分属不同设备、无法共享剪贴板、界面风格还完全不同。传统 RPA 脚本会卡在第二台设备；单设备 GUI Agent（比如 UFO 第一代）也只能盯着眼前这块屏幕。
UFO³（UFO Cubed，微软研究院 2024 年 1 月开源，2026 年 10 月仍在活跃提交）的做法不是「让智能体更会点鼠标」，而是换了一个抽象层级：把用户的一句话拆成一张有向无环图（DAG），图上的每个节点是一个可执行子任务，边是依赖关系，然后把这张图分发到多台设备上的「设备智能体」并行执行。这个被项目称为 Task Constellation（任务星座） 的结构，是整个 UFO³ 的核心创新。
UFO 项目的演进时间线本身就是一份智能体工程演进史：
| 版本 | 时间 | 定位 | 核心抽象 |
|---|---|---|---|
| UFO (v1) | 2024-02 | Windows GUI 智能体 | HostAgent + AppAgent 双智能体，UI 自动化 |
| UFO² | 2025-04 | 桌面 AgentOS | 混合 GUI+API 动作、推测式多动作、持续知识沉淀 |
| UFO³ Galaxy | 2025-11 | 多设备编排星系 | Task Constellation DAG、AIP 协议、MCP 设备智能体模板 |
项目背景是微软研究院对「通用桌面智能体」的长期押注：第一代证明「LLM 能可靠地驱动 Windows GUI」，第二代把这件事工程化（沙箱化虚拟桌面、UIA+视觉混合控件检测、RAG 知识底座），第三代则把边界从「一台机器」推到「一堆机器」。UFO² 至今仍被官方标注为 STABLE & BATTLE-TESTED，而 UFO³ 是 NEW & RECOMMENDED——两者是并存关系，UFO² 可以直接作为 Galaxy 体系里的一个设备智能体挂载。
项目配套两篇 arXiv 论文（2511.11332 对应 UFO³，2504.14603 对应 UFO²），以及完整的 ReadTheDocs 文档站 microsoft.github.io/UFO。
如果把 UFO² 比作「一位坐在电脑前的手速很快的调度员」——他只能指挥眼前这一支乐器的独奏；那么 UFO³ 更像是「一位坐在指挥台上的总指挥」：他把一段复杂乐谱拆成多个声部（TaskStar），标注好谁先谁后（TaskStarLine），然后让分布在不同乐房的演奏者（设备智能体）按图谱各自动作。
更贴切的类比是外卖调度：骑手分布在城市各处，订单之间有依赖（取餐 → 送达 → 结算），调度系统需要实时知道每个骑手状态、动态改派、在部分失败时自动补单。UFO³ 里的 AgentProfiles（OS、硬件、工具能力画像）就是骑手画像，MAX_CONCURRENT_TASKS 就是同时跑单的骑手数上限，节点改写就是改派。
ConstellationAgent 负责把自然语言请求拆成 TaskStar（节点）与 TaskStarLine（边）的结构化 DAG。关键在于这张图不是一次性产物：galaxy/constellation/editor/ 模块提供了运行时改写能力，包括诊断节点注入、失败后的 fallback 节点创建、依赖重连优化、完成后节点剪枝。也就是说，工作流不是「失败即终止」，而是像活体一样随执行反馈演化。
设备匹配基于能力画像而非固定绑定；执行侧配套安全分配锁（避免同一任务被重复派发）、事件驱动的就绪调度、DAG 一致性检查、批量原子编辑。项目 README 声称对并发修改下的 DAG 一致性给出了形式化证明——这是学术项目里少见的严谨表述。
aip/ 目录是独立的一套协议层，基于 WebSocket，定义了注册（含能力画像）、会话管理、任务路由、心跳健康检查、断线自动重连与重试。协议层与设备智能体实现解耦，意味着手机、IoT、Web 端都可以按同一套模板接入。
项目提供「模板驱动 + MCP 集成」的设备智能体开发框架：声明能力、绑定本地环境、挂载 MCP Server 即插即用接入工具。仓库中的 tests/integration/test_mobile_mcp_server.py、test_mobile_mcp_standalone.py 表明移动端接入已有可运行实现。
galaxy/webui/ 是基于 FastAPI + Vite + React/TypeScript 的完整 Web 控制台，后端通过 WebSocket 实时推送事件（WebSocketObserver），前端提供设备注册、任务查看、星座拓扑可视化等界面，源码中还专门有 security/ 子包处理认证、路径校验与角色伪造防护。这对「不写代码也能编排多设备任务」的用户群体是重要降低门槛的一环。
这是本项目最需要提醒的地方，官方文档的 Quick Start 是 PowerShell 命令（git clone → conda create -n ufo3 python=3.10 → pip install -r requirements.txt），默认面向 Windows。
依赖实测情况（来自 requirements.txt）：
Windows 专属依赖：pywinauto、pyautogui、uiautomation、comtypes、pywin32、PyPDF2（sys_platform=='win32' 条件安装）。这些是 UFO² GUI 自动化底座，Linux/macOS 上会被跳过，导致功能降级或直接缺依赖。
LLM 接入：需自行配置 OpenAI / Azure（azure-identity）或 Anthropic（anthropic==0.64.0）等 API Key，config/galaxy/agent.yaml.template 为配置模板。
本地 RAG 组件：faiss-cpu、sentence-transformers、langchain_huggingface——默认会拉取本地嵌入模型，首次运行需下载数百 MB 权重，磁盘与内存开销比想象中大。
服务栈：fastapi + uvicorn + websockets + fastmcp，启动 Galaxy 服务与 WebUI 均可本地完成。
容器化：仓库没有 Dockerfile / docker-compose / K8s manifest（.github/workflows/ 里只有文档部署流水线）。Galaxy 编排层本身可容器化，但 UFO² 依赖 Windows GUI 自动化，容器化收益有限。
分路径建议：
| 目标 | 建议路径 | 难度 |
|---|---|---|
| 学习桌面智能体原理 | 只装 UFO² 依赖，Windows 10/11 实机跑通示例 | 中 |
| 体验多设备编排 | Linux 起 Galaxy 控制端 + WebUI，另备一台 Windows 机做设备智能体 | 中高 |
| 生产落地 | 需自行补齐容器化、鉴权、审计与高可用，工程量不小 | 高 |
平台绑定明显。尽管 Galaxy 层声称跨平台异构，但仓库默认配置、文档与大量测试都围绕 Windows 与 pywinauto 展开；Linux/macOS 作为设备智能体的支持更像「有代码但未打磨」。
无容器化交付。对开源框架类项目，缺少 Dockerfile 是一个明显短板，也直接限制了 quick_deploy 只能评为「部分支持」。
强依赖外部 LLM 服务。项目本身不含模型，成本、延迟与可用性完全受制于所选模型服务，Token 消耗在多设备并行场景下可能迅速放大。
安全面的双刃剑。GUI 自动化 + WebSocket 编排意味着极强的系统操作权限。项目在 tests/security/ 下有 session id 复用、任务名路径穿越、WS 角色伪造、SSRF 校验等测试，说明团队重视这一点，但生产环境仍需自行加固（密钥管理、Agent 白名单、网络隔离）。
复杂度陡增。UFO³ 的概念密度很高（Constellation / TaskStar / AIP / AgentProfiles / MCP / DI 容器 / 事件总线），对团队学习成本不小；README 中大量表格与动图也说明其传播定位偏向研究演示而非「拿来即用」的产品。
本地 RAG 权重成本。默认嵌入模型体积不小，faiss-cpu + sentence-transformers 对低配机器不友好。
UFO³ 代表的趋势非常明确：智能体竞争的焦点正在从「单点能力」转向「编排能力」。当每个厂商都在做自己的 GUI Agent、Browser Agent、手机 Agent 时，谁能把它们组织成一张可动态改写、可并行执行、可跨设备协同的任务图，谁就掌握了下一层入口。
UFO³ 的三个选择值得行业观察：
用 DAG 而非线性 ReAct 循环作为一等公民，并强调运行时可改写——这与主流 Agent 框架（如 LangGraph 的图式编排）思路一致，但更强调「执行反馈驱动的图演化」；
用 AIP 这样独立的协议层做设备接入，而非各家私有的 SDK 接口，本质上在做「Agent 互联协议」的标准化尝试；
用 MCP 承载工具扩展，主动接入而非另起炉灶，与 2025 年之后 MCP 成为事实标准的趋势同频。
从仓库活跃度看（pushed_at 持续到 2026 年 10 月，96 个 open issue，1144 个文件、近 10 万行 Python + TypeScript），微软研究院对这个项目的投入是持续的，不是刷完 star 就放着。10k+ star 也印证了社区对「桌面/多设备智能体」这一方向的强烈兴趣。
如果你的团队正在做 GUI 自动化或多智能体协作，UFO³ 值得当作技术雷达上的重点观察对象，但短期内更适合作为架构参考与实验平台，而非直接上生产。原因很实在：Windows 依赖、缺少容器化、概念复杂度、以及对 LLM 服务的强依赖，都是真实的落地成本。反过来，如果你正在研究「多设备任务编排」该长什么样，这份代码给出了一套相当完整、且有形式化正确性论证的参考实现，学术与工程价值都很高。