UFO 场景：AI 编码 Agent 太多调度不过来？用自托管面板让它们自动排队和交接
早上你打开一个终端跑 Claude Code 重构后端，另一个终端用 Codex 写测试，第三个窗口里 OpenCode 在按 PR 反馈修改代码。三个 AI 编码 Agent 同时工作，但没人协调它们——上下文各自为战、工作目录各占一摊、谁做了什么全靠翻终端历史。
这不是你的问题，是整个”多 Agent 并行”工作流的通病。直到遇到了 UFO（Unified Fleet Orchestrator）——一个开源的自托管调度平台，让你像 Jira 管理开发任务一样管理 AI 编码 Agent 的执行队列。
问题：三个 Agent 三个窗口，谁来串联？
同时跑多个 AI 编码 Agent 听起来很有效率，但实际体验往往是：
- 上下文碎片化：每个 Agent 有自己独立的会话历史，上一个 Agent 分析完的结论，下一个 Agent 没看到，又重新分析一遍
- 手动接力：Agent A 做完了，你需要在 Agent B 里手动粘贴上下文、描述任务、等待输出——这种”人工中间件”极其低效
- 缺乏全局视角：三个 Agent 各跑各的，你不知道哪个完成了、哪个卡住了、哪个出错了——除非你不断在终端窗口间切换检查
- 工作目录混乱：Claude Code 改了这个目录，Codex 又改了同一个文件的不同部分——冲突和覆盖是家常便饭
UFO 解决这个问题的思路很直接：给所有 AI 编码 Agent 配一个统一调度面板。
UFO 三层架构
UFO 不是又一个 Agent 编排框架，而是一个零人工运维平台（zero-human ops platform）。它不取代 Claude Code 或 Codex，而是在它们上面加一层调度层：
| 层 | 职责 |
| — | — |
| Fleet（舰队） | 信任边界：人员、Rover、Mission 和 Operation |
| Hub（枢纽） | 控制平面：API 和舰队状态 |
| Board（看板） | Web UI：任务队列、状态更新、结果回顾 |
核心概念：
- Rover：运行在开发者本机的本地运行时连接器，负责从 Hub 接收任务并在隔离的工作目录中执行
- Pilot：实际的 AI CLI 工具（Claude Code、Codex、Grok Build、Cursor Agent 等）
- Operation：看板上的一个工作任务单元
- Routine：重复执行模式——任务完成后自动触发下一个任务
+-------+ +------+ +------+ +-------+
| Board | <-> | Hub | <-> | Rover| <-> | Pilot |
+-------+ +------+ +------+ +-------+
| | (telemetry)
v v
[PostgreSQL] [local worktree]
快速上手：5 分钟搭好调度面板
UFO 完全自托管，不需要注册任何云服务。只要你的机器上有 Docker 和 Rust/Cargo：
git clone https://github.com/fengsi/ufo.git cd ufo scripts/dev.sh up # 启动 Postgres + API + Web
启动后，打开 http://localhost:3000 注册账号——UFO 会自动为你创建一个个人 Fleet 和一个默认的 Launch Bay Mission。
注册 Rover
Rover 是连接到你本机的执行器，它在本地运行 AI CLI 工具：
scripts/dev.sh rover enroll
在浏览器中确认注册请求后，Rover 就启动成功了。后续运行只需：
scripts/dev.sh rover
一个主机可以注册多个 Rover，也可以连接到不同的 Hub。通过 units 参数可以设置每台 Rover 的并发工作数。
配置 Pilot
确保至少有一个 AI CLI 工具在 PATH 上（如 claude、codex、grok 等）。UFO 目前支持 14 种 Pilot，包括 Claude Code、Codex、Antigravity、Grok Build、Cursor Agent、GitHub Copilot、Amp Code、OpenCode、OpenClaw、Hermes、Pi、Kimi、Kiro、CodeBuddy Code。
Rover 只会运行它能找到的 Pilot——所以安装好 CLI 工具后无需额外配置。
开始调度
- 在 Board 上创建 Mission（项目框架）
- 创建一个 Operation（工作任务）
- 分配 Pilot（指定用哪个 AI 工具执行）
- 在 Board 上看着状态变化：
queued → accepted → running → review/done
每个 Operation 都在隔离的工作目录（worktree）中执行，互不干扰。Rover 会实时上报状态和差异回 Board。
高级特性：自动接力
UFO 不止是调度面板，还支持任务自动接力：
- Routine：Operation 完成后自动触发下一个任务——比如”前端重构完成 → 自动创建测试任务”
- Skills：可复用的指令包（SKILL.md），绑定到 Operation 或 Crew，执行时自动注入 worktree
- Crews：Pilot + 人的团队，可以指定多个 AI 工具和人协作完成一个任务
- Auto-commit：Unattended 模式下，Rover 可以自动提交变更（带 fail-closed 安全防护）
这使得”写代码 → 写测试 → 跑测试 → 修 bug”的循环可以全自动完成，开发者只需要在 Board 上查看最终结果。
自部署的安全考虑
Rover 以宿主 OS 用户的权限运行 Pilot CLI 工具。Fleet 中的任何人都可以向该 Fleet 的 Rover 分发任务。对于严肃项目，建议使用专用账号或隔离主机运行 Rover。Hub 使用 JWT 认证，生产环境需要配置 UFO_HUB_JWT_PRIVATE_KEY。
代码和密钥始终留在开发者的机器上——UFO 不要求上传代码到云端。Rover 只在本地执行 Pilot，将任务状态和 diffs 报告给 Hub。
总结
UFO 的价值不在于取代 Claude Code 或 Codex，而在于给多个 AI 编码 Agent 配上了统一的指挥中心。当你的工作流从”一个 Agent 干一件事”升级到”多个 Agent 并行协作”时，UFO 的调度面板、自动接力、隔离工作目录和实时监控就能节省大量”人工中间件”时间。
对于正在重度使用多个 AI 编码 Agent 的团队和开发者来说，UFO 是填补多 Agent 协作空白的一个实用选择。
相关链接：