一个引擎五种形态 — FluxDown 全家桶架构总览

引擎是唯一的真源

FluxDown 的全家桶做法在下载器里很少见——不是每个形态各写一套下载逻辑，而是只有一个 Rust 引擎（fluxdown_engine），其他所有形态都是这个引擎的「壳」：

                ┌── Desktop（GPUI 原生界面）
                ├── Headless Server（Docker / Web UI）
fluxdown_engine →├── NAS（DSM .spk / 一键包）
                ├── CLI（fluxdown add / list / pause）
                └── Android（原生 Flutter 界面）

每个壳的区别只是「怎么把引擎暴露给用户」——引擎本身的协议解析、分段、Work Stealing、BT/eD2K 客户端、SQLite 持久化、令牌桶限速，全都一模一样。

五种形态对比

形态	界面	运行方式	和引擎的关系
桌面端	GPUI 原生窗口	用户启动，关窗口仍在跑	引擎在进程内，三层架构
Headless Server	Web UI（React）	Docker / NAS 启动，7×24	引擎在容器内 daemon
CLI	命令行参数	单次执行后退出或 `--local` 嵌入引擎	可选连远程 Server 或本地嵌入
Android	Flutter 原生界面	手机常驻	引擎在 Android native 层
NAS 套件	Web UI（同 Headless）	DSM 服务管理	和 Docker Server 同一套组件

统一的 API 协议

所有形态对外暴露的 API 完全一样：

HTTP REST（/api/v1/tasks 等）
aria2 RPC 兼容层（/jsonrpc）
MCP（/mcp，给 AI agent 用）

这意味着你写了一个脚本给桌面端发任务，直接把 127.0.0.1:17800 换成 NAS 上的 <nas-ip>:17800 就能对 NAS 上的 FluxDown Server 发同样的任务。

跨形态协作场景

几个典型用法：

本机桌面端 + NAS Server — 桌面端负责你盯着时的即时下载，NAS Server 负责 7×24 大文件；脚本里把任务发给 NAS。
CLI 给 Server 发任务 — 桌面端没开但 Server 在跑，CLI 可以远程下发：fluxdown --server http://nas:17800 add https://...。
Android 控制 NAS — Android App 填 NAS 的 API 地址，出门在外手机上加下载任务，NAS 回家继续跑。
AI agent 控制 Server — 配置 MCP server 后 AI 可以自然语言让 FluxDown 下载、查状态、暂停任务。

代码结构

GitHub 仓库 zerx-lab/FluxDown 用 Cargo workspace 组织：

FluxDown/
├── engine/           # fluxdown_engine，所有形态共用
├── daemon/           # fluxdownd，engine 壳
├── agent/            # fluxdown-agent，daemon + API 网关
├── desktop/          # GPUI 桌面端（agent 壳）
├── server/           # Docker headless（agent 壳 + Web UI）
├── cli/              # fluxdown CLI
├── android/          # Flutter + native engine 桥
└── website-v2/       # 官方网站 + 文档

引擎永远是 engine/ 这一个 crate，每个形态都是它的应用层壳。