FluxDown 三层进程架构：桌面界面之外常驻的 Agent 与 Daemon

为什么关窗口还能继续下载

传统下载器关闭界面即停止任务，因为下载逻辑和界面在同一个进程里。FluxDown 在启动时会起三个进程，每个进程职责单一：

fluxdown-desktop    (L3，按需启动，关窗口即退出)
  ↕ 本地 RPC
fluxdown-agent      (L2，常驻托盘)
  ↕ 本地 RPC
fluxdownd           (L1，守护进程)
  ↕ 进程内调用
fluxdown_engine     (L0，Rust 引擎核心)

三层之间通过本地 RPC（Windows Named Pipe / Unix Socket）通信，进程崩溃不会连锁死亡。

各层职责

L0 — fluxdown_engine（引擎核心）

Rust Tokio 异步实现，负责六种协议、分段调度、Work Stealing、哈希校验、SQLite 读写。被 Daemon 在进程内调用，不单独启动。

L1 — fluxdownd（守护进程）

真正下载的主人。它持有任务、队列、调度计划、RSS 订阅、插件、Webhook 这些长期状态。无论桌面界面开不开着，它都一直在跑。关闭桌面时下载不停。

L2 — fluxdown-agent（网关）

常驻托盘，承接所有外部入口：浏览器扩展 Native Messaging、剪贴板监听、云同步、本地 API（默认监听 127.0.0.1:17800）、fluxdown:// 协议。它把这些请求转换成 Daemon 的命令再转发下去。

L3 — fluxdown-desktop（桌面界面）

GPUI 渲染的 GPU 原生窗口。按需启动、打开即显、关闭即退。它并不执行下载，只是向 Agent/Daemon 发命令、拉状态来渲染。

为什么这样分

这种分层带来三个好处：

界面可弃 — 关掉不丢下载，再打开直接拉取 Daemon 当前状态继续显示。
多客户端安全 — 同一个 Daemon 可以被桌面界面、CLI、Docker Web UI、Android 应用同时访问，全部走本地 API，互不干扰。
崩溃隔离 — 某层崩了不会拖垮其他层。比如浏览器扩展 Native Messaging 出问题最多让 Agent 重启，引擎任务本身还在 Daemon 里跑。

关闭到托盘

桌面端默认行为是点 X 关闭到系统托盘而不是退出。托盘图标点击打开界面，右键菜单有「暂停全部 / 继续全部 / 退出」。从托盘退出才会真的终止 Daemon。

启动顺序

桌面端启动时会检查 Daemon 是否已在运行：

已运行 — 直接连本地 RPC 接入，复用已有下载状态。
未运行 — 先起 Daemon 再起 Agent，最后打开界面。

这意味着如果 Agent 和 Daemon 已经在跑，CLI 或 Docker Server 完全可以单独工作，桌面界面不是必须的。