企业官网建设流程全解析

UFO² 迁移至 UFO³ Galaxy 完整指南：从单机 AgentOS 到多设备分布式编排

【免费下载链接】UFOUFO³: Weaving the Digital Agent Galaxy项目地址: https://gitcode.com/GitHub_Trending/uf/UFO

本指南以仓库文档 migration_ufo2_to_galaxy.md 为主线，系统讲解 UFO 项目从 UFO v1（纯 GUI 单机自动化）到 UFO²（Windows 桌面 AgentOS）再到 UFO³ Galaxy（跨设备分布式 AgentOS）的演进脉络，并给出从 UFO² 平滑迁移到 Galaxy 的三条可执行路径：保留 UFO² 做本地任务、将 UFO² 实例转换为 Galaxy 设备、以及基于GalaxyClient的编程式迁移。读完你将掌握 Galaxy 的配置文件体系（agent.yaml、devices.yaml、constellation.yaml）、设备注册与 WebSocket 服务端启动方式，以及 Task Constellation（DAG）跨设备编排的核心概念，能够把已有的 UFO² 工作流无缝迁移到 Galaxy 多设备架构中。

一、理解 UFO 的演进：v1 → UFO² → UFO³ Galaxy

UFO 项目经历了三次大的迭代，每一代都在解决越来越复杂的自动化难题，演进关系如下：

1.1 UFO (v1.0)：起点——纯 GUI 单机自动化

• 发布时间：2024 年 2 月
• 愿景：基于截图的 Windows 自动化
• 架构：多智能体（HostAgent + AppAgents）
• 方案：GPT-4V + 纯 GUI 自动化（点击/输入）
• 范围：单个 Windows 桌面、跨应用工作流
• 局限：没有深度的操作系统集成

关键创新：第一个由 LLM 驱动的多智能体 GUI 自动化框架。在仓库中，这一代的设计思路仍保留在 ufo/agents/ 的 HostAgent / AppAgent 体系中，不过后续已全部演进为更复杂的双层结构。

1.2 UFO² (v2.0)：桌面 AgentOS

• 发布时间：2025 年 4 月（对应论文UFO²: A Windows Agent for Seamless OS Interaction）
• 愿景：深度操作系统集成，实现稳健自动化
• 架构：两层层级（HostAgent + AppAgents）
• 创新点：
  • 混合 GUI–API 执行（减少约 51% 的 LLM 调用）
  • Windows UIA + Win32 + WinCOM API
  • 从文档与经验中持续学习知识（Continuous knowledge learning）
  • 画中画桌面（非侵入式自动化）
  • MCP 服务器集成以增强工具能力
• 范围：单个 Windows 桌面
• 定位：首个深度集成 Windows 系统内部机制的智能体框架

这些能力在仓库中的实现对应：ufo/automator/ui_control/（UIA/Win32 控制）、ufo/automator/app_apis/（Excel/Word/PowerPoint/Web/Shell 应用 API）、ufo/client/mcp/（MCP 客户端）以及 ufo/experience/（经验学习）。

1.3 UFO³ Galaxy：多设备 AgentOS

• 发布时间：2025 年 11 月（对应论文UFO³: Weaving the Digital Agent Galaxy）
• 愿景：大规模跨设备编排
• 架构：基于星座（Constellation）的分布式 DAG 编排
• 创新点：
  • Task Constellation（动态 DAG 任务分解）
  • 跨设备异步并行执行
  • 事件驱动协调，并带有形式化安全保证
  • 双模式 DAG 演化（创建 + 编辑）
  • Agent Interaction Protocol（持久化 WebSocket 通信）
  • 异构设备支持（Windows、Linux、macOS）
• 范围：跨平台多设备工作流
• 能力：可同时编排 10+ 台设备

关键创新：第一个具备可证明正确性的 LLM 驱动的多设备编排框架。仓库中对应实现位于 galaxy/ 目录：星座编排在 galaxy/constellation/orchestrator/，Agent 交互协议（AIP）在 aip/，状态机与安全不变量在 galaxy/agents/constellation_agent_states.py 等模块中。

1.4 架构演进对照

UFO v1（纯 GUI 多智能体）

User Request ↓ HostAgent ↓ AppAgent 1, 2, 3... ↓ Windows Apps (GUI)

能力：多应用工作流、纯截图 + 点击/输入、无 API 集成、单设备。

UFO²（两层层级，混合执行）

User Request ↓ HostAgent ↓ AppAgent 1, 2, 3... ↓ Windows Apps (GUI + API)

能力：多应用工作流、桌面级编排、混合 GUI–API 执行、深度 OS 集成、单设备。

UFO³ Galaxy（星座模型，分布式）

User Request ↓ ConstellationAgent ↓ Task Constellation (DAG) ↓ Device 1, 2, 3... (UFO² instances) ↓ Cross-Platform Apps

能力：多设备工作流、并行执行、动态自适应、异构平台。从源码结构看，这条链路在 galaxy/session/galaxy_session.py 中由GalaxySession串联：用户请求进入ConstellationAgent（galaxy/agents/constellation_agent.py），经由TaskConstellation（galaxy/constellation/task_constellation.py）维护 DAG，再通过ConstellationClient（galaxy/client/constellation_client.py）把 TaskStar 分发到各设备。

二、何时用 UFO²，何时用 Galaxy？

2.1 适合继续使用 UFO² 的场景

• 在单个 Windows 桌面上完成自动化任务
• 需要深度 Windows 集成（Office、文件资源管理器等）
• 希望快速、简单执行，避免网络开销
• 正在学习智能体自动化的基础知识
• 工作流完全本地化（无跨设备依赖）

典型示例：

• "根据这份 Excel 数据创建一个 PowerPoint 演示文稿"
• "按文件类型整理我的 Downloads 文件夹"
• "给这个电子表格里的所有联系人发送邮件"

2.2 适合使用 UFO³ Galaxy 的场景

• 工作流跨多台设备（Windows、Linux、服务器）
• 需要并行任务执行以提升性能
• 子任务之间存在复杂依赖
• 希望根据结果动态调整工作流
• 需要容错与自动恢复
• 正在编排异构系统（桌面 + 服务器 + 云）

典型示例：

• "在笔记本上克隆仓库，在 GPU 服务器上构建 Docker 镜像，部署到 staging 环境，在 CI 集群上运行测试"
• "从云存储拉取数据，在 Linux 工作站上预处理，在 A100 节点上训练模型，在我的 Windows 机器上可视化"
• "收集所有 Linux 服务器的日志，分析错误，在 Windows 上生成报告"

2.3 可以两者并用吗？

可以！UFO² 可以作为 Galaxy 中的设备智能体运行：

Galaxy (Orchestrator) ├── Windows Device (UFO² instance) ├── Linux Device (UFO² instance) └── Server Device (UFO² instance)

这是复杂工作流推荐采用的混合方案——这也是本文后面第三条迁移路径（混合共存）的底层原理。

三、核心概念映射

从 UFO² 迁移到 Galaxy 时，最需要做的是把熟悉的概念"翻译"成新的星座语言：

3.1 架构翻译示例

UFO²（单设备）：

# UFO² 在本地执行 python -m ufo --task "Create report from data.xlsx" # HostAgent 协调单个桌面上的 AppAgents HostAgent ├── ExcelAgent (data.xlsx) ├── WordAgent (report.docx) └── OutlookAgent (send email)

Galaxy（多设备）：

# Galaxy 跨设备编排 python -m galaxy --request "Create report from data on Server, generate PDF on Windows" # ConstellationAgent 创建 DAG 并分配给设备 ConstellationAgent └── TaskConstellation (DAG) ├── TaskStar-1: Fetch data → Linux Server ├── TaskStar-2: Process → GPU Workstation └── TaskStar-3: Generate PDF → Windows Desktop

从源码看，TaskStar（galaxy/constellation/task_star.py）与TaskStarLine（galaxy/constellation/task_star_line.py）构成了 DAG 的节点与依赖边，由TaskConstellation（galaxy/constellation/task_constellation.py）统一管理，并提供环检测、动态增删依赖、导入导出等能力。

四、配置迁移：从config/ufo/到config/galaxy/

4.1 第一步：保留 UFO² 配置

保留现有 UFO² 配置——设备智能体仍会用到它：

config/ufo/ ├── agents.yaml.template # 设备智能体的 LLM 配置模板 ├── mcp.yaml # MCP 服务器配置 ├── system.yaml # 系统级配置 └── ...

无需任何改动——每台 Galaxy 设备都会使用自己的 UFO² 配置。配置中心机制见 config/config_loader.py 与 config/config_schemas.py，实际模板位于 config/ufo/。

4.2 第二步：创建 Galaxy 配置

Galaxy 新增了编排层配置，共三份核心文件，全部位于 config/galaxy/。

A. ConstellationAgent LLM 配置（agent.yaml）

# 复制模板 cp config/galaxy/agent.yaml.template config/galaxy/agent.yaml

编辑config/galaxy/agent.yaml（以下为仓库 agent.yaml.template 中的实际字段）：

# Galaxy Constellation Agent Configuration CONSTELLATION_AGENT: REASONING_MODEL: False API_TYPE: "openai" # "openai" 使用 OpenAI API，"aoai" 使用 Azure OpenAI，"azure_ad" 使用 Azure AD 认证 API_BASE: "https://api.openai.com/v1/chat/completions" # API 端点 API_KEY: "YOUR_KEY" API_VERSION: "2025-02-01-preview" API_MODEL: "gpt-5-chat-20251003" # 编排模型，推荐使用 GPT-4o/Claude 等强推理模型处理复杂 DAG 分解 # Azure AD 认证参数（使用 azure_ad 类型时必填） AAD_TENANT_ID: "72f988bf-86f1-41af-91ab-2d7cd011db47" AAD_API_SCOPE: "openai" AAD_API_SCOPE_BASE: "feb7b661-cac7-44a8-8dc1-163b63c23df2" # ConstellationAgent 提示词配置 CONSTELLATION_CREATION_PROMPT: "galaxy/prompts/constellation/share/constellation_creation.yaml" CONSTELLATION_EDITING_PROMPT: "galaxy/prompts/constellation/share/constellation_editing.yaml" CONSTELLATION_CREATION_EXAMPLE_PROMPT: "galaxy/prompts/constellation/examples/constellation_creation_example.yaml" CONSTELLATION_EDITING_EXAMPLE_PROMPT: "galaxy/prompts/constellation/examples/constellation_editing_example.yaml"

其中API_TYPE支持openai（OpenAI 兼容接口）、aoai（Azure OpenAI）、azure_ad（Azure AD 认证）三种取值，可直接复用 UFO² 中已有的 LLM 配置。提示词模板实际位于 galaxy/prompts/constellation/ 下，负责驱动"创建 DAG"与"编辑 DAG"两种模式（对应文档中提到的双模式 DAG 演化）。

B. 设备池配置（devices.yaml）

Galaxy 新增能力：声明所有可用设备。以下是仓库 devices.yaml 的完整结构：

# Device Configuration - YAML Format # 运行时设置（constellation_id、heartbeat_interval 等）在 constellation.yaml 中配置 devices: # - device_id: "windowsagent" # server_url: "ws://localhost:5005/ws" # os: "windows" # capabilities: # - "web_browsing" # - "office_applications" # - "file_management" # - "send emails" # - "any windows tasks" # metadata: # location: "home_office" # os: "windows" # performance: "medium" # description: "Primary development laptop" # operation_engineer_email: "hidan.zhang@gmail.com" # app_log_file: "log_detailed.xlsx" # sheet_name_for_writing_log_in_excel: "report" # sender_name: "Zac" # operation_engineer_name: "Hidan Zhang" # tips: "If you want to use PowerShell, please launch a new PowerShell window to run the commands." # max_retries: 5 - device_id: "linux_agent_1" server_url: "ws://localhost:5001/ws" os: "linux" capabilities: - "server" metadata: os: "linux" performance: "medium" logs_file_path: "/root/log/log1.txt" dev_path: "/root/dev1/" warning_log_pattern: "WARN" error_log_pattern: "ERROR or FATAL" auto_connect: true max_retries: 5 # ... linux_agent_2、linux_agent_3 结构相同，端口分别为 5002/5003

各字段说明：

能力匹配（Capability Matching）：ConstellationAgent正是依据这些capabilities标签来智能分配任务的。从 config_loader.py 的DeviceConfig数据结构可以看到，device_id、server_url、os、capabilities、metadata、auto_connect、max_retries与 YAML 字段一一对应；ConstellationConfig.from_yaml（galaxy/client/config_loader.py#L102-L150）负责把 YAML 解析为配置对象。

C. 星座运行时配置（constellation.yaml）

vi config/galaxy/constellation.yaml

以下是仓库 constellation.yaml 的实际内容：

# Galaxy Constellation Configuration # Constellation Runtime Settings CONSTELLATION_ID: "test_constellation" # 星座唯一标识 HEARTBEAT_INTERVAL: 30.0 # 设备健康检查心跳间隔（秒） RECONNECT_DELAY: 5.0 # 断线自动重连延迟（秒） MAX_CONCURRENT_TASKS: 6 # 星座内最大并行任务数 MAX_STEP: 15 # 每个会话最大编排轮次 # Device Configuration DEVICE_INFO: "config/galaxy/devices.yaml" # 设备配置文件路径 # Logging Configuration LOG_TO_MARKDOWN: true # 是否将轨迹日志保存为 markdown 格式

参数速查：

CONSTELLATION_ID、HEARTBEAT_INTERVAL等运行时参数由 config/config_loader.py 的 Galaxy 配置加载逻辑读取，并最终注入ConstellationClient（galaxy/client/constellation_client.py）用于初始化设备管理器的心跳与重连调度。

五、三条迁移路径

5.1 路径一：保留 UFO² 做本地，另起 Galaxy 做多设备

适用场景：渐进式采用，保住现有工作流不动。

1. 单设备任务继续用 UFO²：

   python -m ufo --task "Your local task"

2. 仅在多设备编排时使用 Galaxy：

   python -m galaxy --request "Your cross-device task"

3. 无需迁移——两者独立共存，互不干扰。

这条路径的成本最低，适合先在团队内验证 Galaxy 的价值。

5.2 路径二：把 UFO² 实例转换为 Galaxy 设备

适用场景：所有工作流都交给 Galaxy 编排。

Step 1：在每台设备上以 Agent Server 方式启动 UFO²

在每台设备（Windows、Linux 等）上运行 UFO 服务端：

# Windows Desktop python -m ufo.server.app --port 5005 # Linux Workstation python -m ufo.server.app --port 5001 # GPU Server python -m ufo.server.app --port 5002

这条命令的作用（与源码 ufo/server/app.py 的实现一致）：

• 在设备上启动 WebSocket 服务（--port参数默认 5000，可显式指定）
• 监听来自 Galaxy 的任务分派
• 复用设备本地已有的 UFO² 智能体（HostAgent/AppAgent）执行任务
• 把结果回传给 ConstellationClient

Step 2：配置 Galaxy 客户端

在config/galaxy/devices.yaml中登记所有设备（写法见 4.2-B 节）。

Step 3：启动 Galaxy 客户端

# 交互模式 python -m galaxy --interactive # 直接请求 python -m galaxy --request "Clone repo on laptop, build on server, test on Windows"

启动后实际发生的流程：

1. ConstellationAgent把请求分解为 DAG（创建 Task Constellation）
2. 依据capabilities把 TaskStar 分配到对应设备
3. 设备使用本地 UFO² 智能体执行任务
4. 结果汇总后呈现给用户

从源码看，galaxy.py入口（galaxy/galaxy.py）支持--interactive、--request、--session-name、--task-name、--max-rounds（默认 10）、--output-dir、--log-level、--mock（无 LLM 的测试模式）等参数；GalaxyClient.initialize()（galaxy/galaxy_client.py）内部会先注册所有设备，若检测到设备离线，process_request()会先调用ensure_devices_connected()自动重连。

5.3 路径三：编程式迁移

适用场景：自定义工作流、CI/CD 集成。

UFO² API（迁移前）：

from ufo.module.session_pool import SessionFactory, SessionPool import asyncio async def main(): # 在本地设备上创建 UFO² session sessions = SessionFactory().create_session( task="my_task", mode="normal", plan="", request="Create a presentation from data.xlsx" ) # 运行 session pool = SessionPool(sessions) await pool.run_all() asyncio.run(main())

Galaxy API（迁移后）：

from galaxy import GalaxyClient import asyncio async def main(): # Galaxy session 协调多台设备 client = GalaxyClient(session_name="my_workflow") await client.initialize() result = await client.process_request( "Clone repo on laptop, build on server, test on Windows" ) print(f"Workflow completed: {result}") await client.shutdown() asyncio.run(main())

关键差异：

• 两者都是async风格（UFO² v2.0+ 基于 asyncio）
• UFO² 使用SessionFactory+SessionPool模式；Galaxy 使用GalaxyClient做多设备编排
• Galaxy 返回的是星座级结果（跨设备），process_request()的返回值中会附带constellation信息（id、name、task_count、dependency_count、state），见 galaxy/galaxy_client.py
• Galaxy 要求先注册设备，GalaxyClient构造时会通过get_galaxy_config()读取DEVICE_INFO指向的devices.yaml

GalaxyClient还提供了interactive_mode()（交互式 CLI）、reset_session()（重置当前会话）、create_next_session()（创建新会话）、shutdown(force=True)（强制取消运行中任务并清理资源）等完整生命周期方法。

六、功能对比：保留的能力 vs Galaxy 新增能力

6.1 Galaxy 中完整保留的 UFO² 能力

当 UFO² 作为 Galaxy 设备运行时，UFO² 的全部能力原样保留：

6.2 Galaxy 独占的新功能

其中"动态自适应"与"双模式 DAG 演化"对应ConstellationAgent的创建/编辑两套提示词（见 4.2-A），运行期对 DAG 的增删改由TaskConstellation的动态依赖管理 API 支撑（galaxy/constellation/task_constellation.py）；"事件驱动协调"则由 galaxy/core/events.py 的事件总线与 galaxy/session/observers/ 下的一组观察者实现。

七、实战示例

7.1 示例一：简单本地任务

UFO²（迁移前）：

python -m ufo --task "Create a presentation from data.xlsx"

Galaxy（迁移后）——方案 A：继续用 UFO²

# 无需改动——本地任务继续使用 UFO² python -m ufo --task "Create a presentation from data.xlsx"

Galaxy（迁移后）——方案 B：改用 Galaxy

# Galaxy 会自动把任务分配给本地 Windows 设备 python -m galaxy --request "Create a presentation from data.xlsx on my desktop"

何时用哪个？

• 只有一台 Windows 桌面时用 UFO²（更简单）
• 需要日志/监控能力时用 Galaxy（LOG_TO_MARKDOWN: true可生成轨迹报告）

7.2 示例二：跨设备工作流

UFO²（迁移前）：

# ❌ 不可能——UFO² 仅支持单设备 # 你只能手动： # 1. SSH 到服务器 # 2. 运行构建命令 # 3. 把结果拷回 # 4. 本地打开

Galaxy（迁移后）：

python -m galaxy --request \ "Clone https://github.com/myrepo on laptop, \ build Docker image on gpu_server, \ deploy to staging server, \ open logs on my Windows desktop"

Galaxy 会自动：

1. 创建 4 任务的 DAG
2. 把任务分配给具备相应capabilities的设备
3. 在可能的地方并行执行（受MAX_CONCURRENT_TASKS约束）
4. 流式回传结果

7.3 示例三：数据管线

UFO²（迁移前）——需要手动编排多步：

from ufo.module.session_pool import SessionFactory, SessionPool import asyncio async def main(): # Step 1: 拉取数据（本地） sessions_1 = SessionFactory().create_session( task="fetch_data", mode="normal", plan="", request="Download dataset from cloud storage" ) pool_1 = SessionPool(sessions_1) await pool_1.run_all() # Step 2: 手动传输到服务器 # scp data.csv user@server:/data/ # Step 3: SSH 并运行处理 # ssh server "python process.py" # Step 4: 手动拷回结果 # scp server:/output/results.csv . # Step 5: 本地可视化 sessions_2 = SessionFactory().create_session( task="visualize", mode="normal", plan="", request="Create charts from results.csv" ) pool_2 = SessionPool(sessions_2) await pool_2.run_all() asyncio.run(main())

Galaxy（迁移后）——一次请求完成全管线：

import asyncio from galaxy import GalaxyClient async def main(): client = GalaxyClient(session_name="data_pipeline") await client.initialize() # 单个请求——编排交给 Galaxy await client.process_request( "Fetch dataset from cloud to laptop, " "preprocess on linux_workstation, " "train model on gpu_server, " "visualize results on my Windows desktop" ) await client.shutdown() asyncio.run(main())

Galaxy 会自动：

• 建立依赖链（DAG 边）
• 在设备间传递数据
• 按顺序执行管线各阶段
• 失败时自动重试（max_retries生效）

八、UFO² 用户的学习路径

1. 第 1 周：理解概念

   • 阅读 Galaxy 总览，理解 Task Constellation 与 DAG 模型
   • 与 UFO² 的两层层级结构做对比（UFO² 总览）
   • 结合本文第三节的概念映射表

2. 第 2 周：动手实践

   • 把一台 Windows 设备配置为 Galaxy 设备（按第五章节路径二）
   • 运行一个简单的多步骤工作流
   • 对比 UFO² 与 Galaxy 的日志

3. 第 3 周：多设备

   • 向设备池加入一台 Linux 设备
   • 创建跨平台工作流
   • 用轨迹报告（Trajectory Report）监控执行

4. 第 4 周：进阶

   • 构建自定义设备能力（自定义capabilities标签）
   • 跨设备集成 MCP 服务器
   • 优化任务分配逻辑

九、常见问题（FAQ）

Q：迁移到 Galaxy 后还能继续用 UFO² 吗？A：可以！两者共存。简单本地任务用 UFO²，多设备工作流用 Galaxy。

Q：需要重写我的自定义智能体吗？A：不需要。现有 UFO² 智能体作为 Galaxy 设备运行时可以原样工作。

Q：Galaxy 适合生产环境吗？A：Galaxy 处于活跃开发阶段；对于关键的单设备工作流，UFO² 更成熟稳定。

Q：可以混用 Windows 和 Linux 设备吗？A：可以！这正是 Galaxy 的核心特性。每台设备使用其原生的 UFO² 实现。

Q：如何调试失败的跨设备工作流？A：查看logs/galaxy/<session>/output.md，其中包含逐步执行细节与 DAG 可视化。Galaxy 的轨迹报告机制见 轨迹报告 与 性能指标 文档。

十、相关文档导航

迁移资源

• Galaxy 快速开始 — 逐步搭建 Galaxy
• UFO² 快速开始 — UFO² 参考
• 设备配置 — 设备池设置
• Agent 注册 — 设备如何加入 Galaxy

架构深度阅读

• Galaxy 总览 — 星座架构
• UFO² 总览 — 桌面 AgentOS 设计
• Constellation Agent — DAG 编排
• Task Constellation — DAG 结构

运维指南

• 轨迹报告 — 执行日志
• 性能指标 — 监控
• AIP 协议 — 设备通信协议

源码速查

• 编排入口：galaxy/galaxy.py、galaxy/galaxy_client.py
• 设备客户端：galaxy/client/constellation_client.py、galaxy/client/device_manager.py
• 配置解析：galaxy/client/config_loader.py
• DAG 管理：galaxy/constellation/task_constellation.py、galaxy/constellation/orchestrator/orchestrator.py
• 会话编排：galaxy/session/galaxy_session.py
• 设备端服务：ufo/server/app.py

十一、迁移检查清单

• 理解 UFO 演进（v1 → UFO² → Galaxy）
• 决定迁移策略（混合共存 vs 全面迁往 Galaxy）
• 保留 UFO² 配置（config/ufo/不动）
• 创建 Galaxy 配置（config/galaxy/agent.yaml、devices.yaml、constellation.yaml）
• 以服务端方式启动设备（每台设备运行python -m ufo.server.app --port <port>）
• 测试单设备工作流（验证连通性）
• 测试多设备工作流（跨平台任务）
• 审查轨迹报告（logs/galaxy/*/output.md）
• 对比性能（针对你的用例对比 UFO² 与 Galaxy）
• 更新自动化脚本（若使用编程式 API）
• 培训团队（分享本指南）

按此清单推进，即可在保留既有 UFO² 工作流的前提下，逐步释放 UFO³ Galaxy 多设备编排的全部能力。

【免费下载链接】UFOUFO³: Weaving the Digital Agent Galaxy项目地址: https://gitcode.com/GitHub_Trending/uf/UFO