# AI1NET 网络结构调整（三类节点）可行性评估

- 日期：2026-09-26
- 评估对象：用户提出的「覆盖网络连接所有节点和设备」三类节点划分（原话见 §9）
- 评估口径：🔴 **以定稿 `dsh-server-docs/02-架构设计/覆盖网络-顶层架构全貌.md`（2026-09-21 · 唯一权威）为准**；本文与定稿冲突 ⇒ 以定稿为准
- 证据等级：**读码 ＋ 既有真机实测**；凡标 ⚠️**待查** 的项**未经真机取证**（⛔ 不得当既成事实）
- 关联件：`交付物/全功能承载判定-底层插件能否承-20260926.md`（§3.10 K8S · §3.11 网络与 K8S API · §5 P6）

---

## §0 一句话判定

**三分法本身站得住，但有一个词站错了位置 ——「客户端版服务节点」不是"服务节点"，是"主权承载节点"。把这个定语补上，你的三分就与定稿完全对齐，不需要改架构。**

三条单句：

| # | 你的提法 | 判定 |
|---|---|---|
| **①** | 服务器版 服务节点（47 管理 ＋ 106 K8S 承载） | ✅ **成立，而且今天就是这么跑的**；⭐ 它还给出了比我的 P6 建议**更好**的落法（见 §2.1） |
| **②** | 客户端版 服务节点（桌面机装 K8S 提供多租户） | ⚠️ **拆两问**：**给自己用 ⇒ ✅ 成立**｜**给别人用 ⇒ ⛔ 不成立**（四条件缺二 ＋ 一条架构级信任门，见 §2.2） |
| **③** | 客户端版 实例节点（连到服务节点用） | ✅ **成立**，且这正是定稿 §5.3 里**唯一"机制齐备"**的那条路径（B，见 §2.3） |

🔴 **但比"可行不可行"更硬的是顺序** —— **F1.5（G1 签名清单序号 ＋ G6 撤根）＝一切前置**，而现状 **G1 未修、G6 无任何机制**。⇒ 「连接**所有**节点和设备」这件事，在**"撤不回去"这个问题解决之前，不能上规模**（§4）。

---

## §1 先对齐词：你的三分 vs 定稿的三层权威

这是本评估最重要的一节。**你的分类与定稿的分类不在同一个维度上，所以直接问"可行不可行"会答歪。**

| | 你分的 | 定稿分的 |
|---|---|---|
| **分的是什么** | **功能**（这台机器给别人跑实例吗） | **权威**（谁说了算） |
| **分了几类** | 服务节点 / 实例节点 / 设备 | 根 → 区 Manager → 区内 Worker·节点 |

定稿的三层权威（原文 §三）：

| 权威 | 管什么 | 在你这套里对应谁 |
|---|---|---|
| **根**（离线、可多把） | 区域名录 · 用户全局唯一名 · 联邦吊销 | 🔴 **你没提** —— 它不在任何一台"节点"上，在用户手里 |
| **区 Manager** | 本区归属 · 租约 · 资格 | 部分对应你的「服务节点」 |
| **区内 Worker / 节点** | 执行面 · 本机运维库 | 部分对应你的「服务节点」＋ 全部「实例节点」 |

🔴 **问题就在这**：你说的「服务节点」在定稿里其实是**两个不同的东西**——

- **区 Manager**（权威层：谁能入网、实例算谁的、租约给谁）
- **Worker / 承载节点**（执行层：真把实例跑起来）

定稿把这两者**分开**（因为它们必须分得开：管账的机器挂了不该带着实例一起挂）。你把它们合成一个词「服务节点」，于是产生一个**无解的歧义**：

> ⚠️ **「客户端版服务节点」是 Manager 吗？**
> - 若是 ⇒ 那就是定稿 §4.2「Manager 可升格」，牵动 **F8 根集合治理** 与 **G6 撤根**
> - 若不是 ⇒ 它只是"自己给自己跑实例"，**那它不该叫服务节点**

⇒ **这个歧义是本方案唯一真正需要澄清的地方**（§2.2 给解法）。

---

## §2 逐条评估

### §2.1 ① 服务器版 服务节点 —— ✅ 成立，且已是现状

**你说的**：47 服务器上的官方 dsh 实例 ＋ 底层插件（admin 使用），可配置服务集群（106：K8S 集群，开多个实例给多租户用户）。

**逐项对照实测**：

| 你的说法 | 对照 | 判定 |
|---|---|---|
| 47 = 管理入口 | 47 是 **Manager**（`dshs`；PG13 `15432`）＋ Worker `w-47`(19100) | ✅ 已是 |
| 「官方 dsh 实例 ＋ 底层插件 · admin 使用」 | **管理员实例＝普通租户**：`dsh_instances` 按 `user_id` 建，`grep "role === 'admin'" src/supervisor/ src/web/routes/dsh.ts` ＝ **零命中**；`requireAdmin` 只是一句 DB 角色判断（`middleware/authn.ts:31-38`） | ✅ **成立，且今天就是这么跑的** |
| 106 = 承载（开多实例给多租户） | 106 是 **Worker `w-106`**(19000) | ✅ 同层，但见下方 ⚠️ |
| 「可配置服务集群」 | 定稿 §三第 3 行「区内 Worker / 节点 ＝ **执行面**」 | ✅ **是执行面的替换，⛔ 不动权威结构** |

⚠️ **一处必须点名的现状冲突**：**106 上现在已经有 `w-106` 实例在 `19000` 上跑** ⇒ 把它变成 K8S 集群是**形态切换**，⛔ 不是叠加。「106 上现存的实例怎么办」（迁走 / 保留并行 / 退役）**必须先定**，否则是**带数据的一次性动作**。

⚠️ **待查**：**106 的机器规格**（核数 / 内存 / 磁盘）—— 本评估**未取证**。参照 `orchestrator.ts:1233` 实测宿主 2 核 / 1870 MiB、单实例基座 106~145 MiB（`:1229`）：若 106 与 47 同规格，**装不下 K8S 再装多租户实例**（命中 R11）；若 106 是更大规格，则此条自动解除。**这一项要真机取证后才能定 A 案可行性。**

⭐ **本条最大的价值（比你自己可能意识到的更大）**：
它给 **P6（承载走不走 K8S）** 提出了一个**比我原来建议更好的落法**。

- 我原来的建议：**先 B 后 A**（先维持自研单机，K8S 登记为演进方向）
- **你的方案实际是：B 与 A 并存** —— **47 维持自研 `uid ＋ bwrap ＋ cgroup ＋ systemd`（生产不动）**，**106 试点 K8S（新承载）**

⇒ **这是"隔离试点"，风险最低**：47 生产路径零改动，106 本来就是 Worker、可以当试验田；跑通了再谈要不要把 47 换过去。
⇒ **我据此修正 P6 的建议**（§7）。这是本评估里唯一一处**你的方案优于我原建议**的地方。

---

### §2.2 ② 客户端版 服务节点 —— ⚠️ 必须拆成两问，答案相反

**你说的**：官方 dsh 客户端版，装底层插件（admin 使用），**可在本机安装 K8S 集群，提供多租户服务**。

这句话里藏着**两件不同的事**，答案一个是 ✅ 一个是 ⛔。

#### 问 1：桌面机能不能跑 K8S 开多实例？

**分平台看**（读码实证，非推测）：

| 平台 | 能不能 | 证据 |
|---|---|---|
| **Linux 桌面** | ✅ 能（k3s / kind） | — |
| **Windows / macOS** | ⚠️ **要连过三关**：虚拟化 → Linux 内核 → **systemd** | 见下 |

🔴 **三关的实证**：

1. **实例的启动链是 Linux 专有的**
   `src/cli.ts:106` 依赖检查：`['bwrap', 'setpriv', 'systemd-run', 'nft', 'dsh']`
   `orchestrator.ts:1249`：真起实例走 **`spawn('systemd-run', sdArgs, …)`**
   ⇒ **需要 Linux 内核 ＋ systemd**。Windows 上只能靠 WSL2，而 **WSL2 默认不开 systemd**（须显式 `systemd=true`）；Docker Desktop 的 VM 也没有。

2. **强隔离能力直接 `return`**
   `src/cli.ts:39` —— `--isolation-mode <m> Isolation tier: "soft" or "account" (**Linux, needs root**)`
   `src/supervisor/firewall.ts:42` —— `process.platform === 'linux' && getuid() === 0`
   `src/worker/agent.ts:147` —— `if (process.platform !== 'linux') return`
   `src/supervisor/plugin-assembly.ts:796` —— 注释原文：「`runPnpmAs` 走 `setpriv`（**Linux 专有**），**Windows 开发机上必然 `ENOENT`**」
   ⇒ 🔴 **不是"性能差一点"，是这些代码路径在非 Linux 上直接不执行**。平台**自己就知道**这件事（注释写明了）。

3. **而"官方 dsh 客户端版"这个描述，今天对不上**
   `package.json` 的 description 原文：「面向公网的多租户 DSH 托管平台：登录审核、每用户隔离的 DSH 环境（主 + 按需守护）、**桌面与域名访问**」
   ⇒ 这里的「**桌面**」指的是**桌面浏览器的访问方式**，⛔ **不是 desktop app**。
   ⇒ 本仓库（生产口径 `dshs`）**没有 `apps/` 目录，没有桌面壳**。「桌面壳」在 P1 的 A 案里是**待实现项**（缺点栏原文：「**桌面/服务器两条壳要分别实现**」）。

⇒ **问 1 的结论**：**「用 dsh 客户端 ＋ 底层插件在本机装 K8S」这句话，今天描述不成立** —— 客户端壳不存在，而承载链要 Linux ＋ systemd。**真要落地，实际形态是「dsh 客户端（Windows 侧）＋ 一个 WSL2/VM（Linux 侧）＋ 里面一个 K8S」**，⛔ 不是"客户端版 ＋ 插件"。

#### 问 2：就算跑起来了，能不能"提供多租户服务"（给别人）？

**四个必要条件**（缺一不可）：

| 条件 | 为什么必须 | 服务器版 | 客户端版（桌面） |
|---|---|---|---|
| **常开** | 别人的实例随时要用 | ✅ | ❌ **合盖 ＝ 断服** |
| **可达** | 别人得连得上 | ✅ 固定 IP | ⚠️ **NAT 后面** ⇒ 每个用户各自解决一次 |
| **有特权** | 要能起隔离进程 | ✅ root | ⚠️ 需管理员 ＋ 虚拟化 ＋ systemd |
| **不占用主用机** | 要腾得出资源 | ✅ | ❌ 跑 K8S ＋ 多租户实例，**主机自己就没法用了** |

⚠️ **「可达」这条不是新问题，是 D8 那个门槛的翻版**：09-26 已实测结论 ——「**中继方需"别人能连到它"＝用户侧 NAT 门槛**（≠ 云安全组；同局域网零门槛）」。
⇒ 服务器版只需解决**一次**；客户端版是 **N 个用户 ＝ N 个 NAT 问题**。

#### 🔴 但最要紧的一条不是能力，是**信任**

**现状安全模型的根信任 ＝ 平台容器。** 实证：`orchestrator.ts:823-827` 原文 —— 平台**主动关掉** DSH 内置沙箱（改 `danger-full-access`），理由是「**不在实例内再叠加沙箱，隔离交由平台容器（bwrap + uid + cgroup）负责**」。

⇒ 桌面机当承载方 ＝ **把这条链的根信任从"平台"搬到"私人设备"**。而这个设备：

| 私人设备的性质 | 后果 |
|---|---|
| 可被物理接触 | 内存可 dump、磁盘可直读（对方是 owner，`chown` 一句话） |
| 管理员就是用户本人 | 他能读**所有**租户的 home 与凭据 |
| 不受平台运维管辖 | 不能打补丁、不能审计、不能强制下线 |

⇒ ⛔ **这不是"能不能做到"，是"要不要把信任根搬家"。这是架构级的一道门** —— 与 §3.10 那条「设备侧不进集群」是同一件事的两面。

#### ✅ 那 ② 什么时候成立？—— 换一个定语

**区别只在"服务谁"**：

| 读法 | 服务谁 | 判定 |
|---|---|---|
| **主权服务节点** | **只服务自己的租户**（我一个人的多个工作区 / 多个身份） | ✅ **完全成立** |
| **公共服务节点** | **服务别人的租户** | ⛔ **要过上面那道信任门** |

⭐ **而「主权服务节点」恰恰是客户端版最大的价值所在** —— 它就是**单机多租户**：一个用户在**自己的机器**上，用自己的 admin 身份，开自己的几个隔离实例。

⇒ 这个形态：
- ✅ **与定稿不冲突**（定稿 §5.3 路径 **C**：自建独立区、**不需要任何根**、自成一网）
- ✅ **与「资源口径 = 机器可换」不冲突**
- ⚠️ 但**今天无通路**（见 §5）

🔴 **一句话**：**把「服务节点」拆成「主权服务节点（只服务自己的租户）」和「公共承载节点（服务别人的租户）」—— 前者客户端版可以，后者不行。② 的原文写的是后者，所以不成立；改成前者，立刻成立。**

---

### §2.3 ③ 客户端版 实例节点 —— ✅ 成立，且是唯一"机制齐备"的那条

**你说的**：安装 dsh 客户端版 ＋ 底层插件，**可选择连接到服务节点**，作为单独实例使用。

**对照定稿 §5.1「设备入网六步」**：

| 步 | 做什么 | 现状 | 你说的"可选择连接到服务节点" |
|---|---|---|---|
| ① 拿到入口（邀请码 / 扫码） | ✅ 已有 | ✅ |
| ② 知道有哪些区可加入 | 🔴 **缺**（无区域名录 G2） | ⚠️ |
| ③ 选加入哪个区（需该区审批） | ⚠️ 半成 | ✅ 「可选择」 |
| ④ 该区签发凭据 | ✅ 已有 | ✅ |
| ⑤ 节点**本地**校验 | ✅ 已有 | ✅ |
| ⑥ 建隧道（打洞 / relay） | ✅ 已有 | ✅ |

⇒ **这就是定稿 §5.3 路径 B「设备加入已有区」，原文标注 ✅「机制齐备」** —— 也是四条入口路径里**今天唯一通的一条**。

⚠️ **一处用词建议**：「**实例节点**」这个词与定稿不齐，且在中文里有歧义——
- 读成「**跑着实例的节点**」⇒ 那是**承载方**（＝服务节点）
- 读成「**以实例身份入网的设备**」⇒ 那是**使用端**

从上下文看你是后者。**建议改称「使用端 / 设备」**，与定稿 §2.1「节点（每机一钥）」对齐 —— 否则下一棒读到"实例节点"会当成承载方。

---

## §3 你的方案缺的那一维：**承载能力**

你的三分是按"**给别人跑实例吗**"分的，这是**功能维**。但**能不能给别人跑**取决于四个独立条件，而这四个条件**不随软件配置改变**：

| 判据 | 含义 | 服务器 | 桌面 |
|---|---|---|---|
| **常开** | 物理事实，不是配置项 | ✅ | ❌ |
| **可达** | 固定入口 / 公网 / 中继 | ✅ | ⚠️ |
| **有特权** | root / K8S / bwrap / cgroup | ✅ | ⚠️ Linux 专有 |
| **不占用主用机** | 腾得出资源 | ✅ | ❌ |
| **➕ 受平台管辖** | 能打补丁 / 能审计 / 能强制下线 | ✅ | ❌ |

⇒ 🔴 **补上这五条，"服务节点"自然裂成两个**：

```
                 有没有特权？          → 没有 ⇒ 只能当「使用端 / 设备」
                    │ 有
                    ▼
            常开 + 可达 + 不占主用机 + 受管辖？
                 │ 全有                     │ 缺任一条
                 ▼                          ▼
        【公共承载节点】              【主权承载节点】
        服务别人的租户                  只服务自己的租户
        ⇒ 只有服务器能当              ⇒ 服务器 ✅ / 桌面机 ✅
```

⭐ **这张图就是本评估的核心产出** —— 你的三分只要插入这一层，就完整了：

| 你的原分类 | 补维度后 |
|---|---|
| ① 服务器版服务节点 | = **区 Manager ＋ 公共承载节点** ✅ |
| ② 客户端版服务节点 | = **主权承载节点**（⛔ 不是公共承载）|
| ③ 客户端版实例节点 | = **使用端 / 设备** ✅ |

---

## §4 🔴 比"可行性"更硬的：**顺序**

你问的是"结构调整是否可行"。**结构本身可行 —— 但它的规模放大了一个未修缺口的爆炸半径。**

**你要的效果**：「覆盖网络连接**所有**节点和设备」。

**它要求什么**：签发身份 ＋ **撤回身份**。

**现状（定稿 §六 · §七）**：

| 缺口 | 内容 | 现状 |
|---|---|---|
| **G1** 🔴 | `SignerSet` / `NodeGrant` **只有 `issuedAt`、无序号**，而 `issuedAt` **不参与任何判定** ⇒ **一份旧名单（已撤销的签名者还在里面）重放给节点，验签会通过** | **未修** |
| **G6** 🔴 | **撤根无任何机制** —— 吊销清单只能撤**节点**，撤签名者靠"根签新名单"，**撤根本身没有手段** | **无机制** |
| **G1 ＋ G6 叠加** | 撤根的唯一补救是"换新名单"，而名单无序号 ⇒ **这条路本身也不可靠** | 定稿原文：「**G1 与 G6 必须一起解决**」 |

定稿 §七 原文：

> 🔴 **一句话记法：F1.5 是一切的前置** —— 没有防重放序号，后面每一项下发的签名清单都是可重放的。

⇒ **结论**：
1. ⛔ **在 F1.5 之前，"把所有节点和设备都连进来"做不了** —— 因为**撤不回去**。
2. ⚠️ **且规模越大越撤不回去** —— 节点越多，一份可重放的旧名单能影响的机器越多。**这正是"先小规模、再扩张"的理由，不是"先扩张、再补机制"。**
3. ⚠️ 定稿 §九 第 1 条已如实标注：**G1 重放未实测**（"`issuedAt` 不参与判定"是**读码推断**）⇒ **落地前须构造真实重放实验复现**。

⇒ 🔴 **这不是"能不能"，是"什么时候"，而且顺序不可颠倒。**

---

## §5 今天哪些有通路、哪些没有（对照定稿 §5.3 四条入口路径）

| 路径 | 说明 | 现状（定稿原文） | 你的方案对应 |
|---|---|---|---|
| **A** 新服务器首启 | 显示首管理员设置页（一次性）⇒ 建本区或加入他区 | ⚠️ **今天只有 CLI，无 Web 通路** | ① 服务器版服务节点 |
| **B** 设备加入已有区 | 邀请码 ⇒ 该区签发 ⇒ 本地校验 | ✅ **机制齐备** | ③ 客户端版实例节点 |
| **C** 自建独立区（**不联联邦**） | **不需要任何根**，自成一网 | ⚠️ **今天无通路** | ② 的"主权服务节点"读法 |
| **D** 自建区加入联邦 | 需根背书区身份 | 🔴 **今天无通路** | ② 的"公共服务节点"读法 |

🔴 **硬事实**：
- **①** ✅ 已是现状（CLI 侧）
- **③** ✅ **有通路**（唯一通的一条）
- **②** ⛔ **两种读法今天都没有通路** —— 单机（C）⚠️ 无通路，联邦（D）🔴 无通路
- ⚠️ C 与 D 都依赖 **G2 区域名录**，而 G2 依赖 **F1.5**

⇒ **你要做的"结构调整"，其中两块（② 的两种读法）今天是空的**。这不是你的方案错，是**地基还没浇到那一层**。

⚠️ **另附定稿硬约束**（会被误做成需求）：
> 首管理员设置页上的「有哪些 manager 可选」**⛔ 不可做成公开列表** —— 那是**拓扑信息**，公开即扩大暴露面。改法：**凭邀请码**才列出该区信息。

---

## §6 我建议的调整版

**不改你的三个角色，只把维度补齐 ＋ 改两个词**：

| # | 你的原文 | 建议改成 | 为什么 |
|---|---|---|---|
| ① | 服务器版 服务节点 | 服务器版 **管理节点 ＋ 公共承载节点** | 把"权威"与"执行"分开（定稿本来就是分开的） |
| ② | 客户端版 服务节点 | 客户端版 **主权承载节点**（只服务自己的租户） | ⛔ 「公共服务」要过信任门；「主权服务」今天就能立项 |
| ③ | 客户端版 实例节点 | 客户端版 **使用端 / 设备** | 与定稿 §2.1「节点」对齐，⛔ 避免被读成承载方 |

**补一句总纲**：

> **覆盖网络连接"所有节点和设备" —— 目标是 ☑ 对的；但"公共承载"这一档，"所有设备"进不来，只有服务器能进。**
> ⇒ 设备能以**使用端**身份入网（✅ 路径 B），能以**主权承载**身份自成一区（⚠️ 路径 C，待建），⛔ **不能以公共承载身份服务别人的租户**。

**推进顺序（若采纳）**：

| 序 | 做什么 | 前置 | 说明 |
|---|---|---|---|
| 1 | **① 的 106 试点**（106 → K8S 承载池） | 定 106 现存实例处置 ＋ 取证 106 规格 | ⛔ 与 F1.5 无关，**可以并行** |
| 2 | **③ 定型**（使用端入网，路径 B） | — | ✅ 机制已齐备 |
| 3 | **② 的"主权"读法**（路径 C 通路） | **F1.5 ＋ G2** | ⚠️ 无通路，须先建 |
| 4 | **② 的"公共"读法**（路径 D 通路） | 上面的 ＋ **G6 撤根 ＋ F8 根治理 ＋ 信任根决策** | 🔴 三重前置 |

---

## §7 与既有拍板的关系

| 项 | 原状态 | 本评估的影响 |
|---|---|---|
| **P6**（承载走不走 K8S） | 我倾向**先 B 后 A** | 🔴 **修正**：你的方案给了**第三条路 —— B 与 A 并存**（47 维持自研生产不动 ＋ 106 试点 K8S）⇒ **这是风险最低的落法，我改为推荐它**。「先 B 后 A」不再是最优。 |
| **D8**（端口） | 09-26 拍板「先不开端口」 | ✅ **不变** —— 本方案**不需要开任何端口**（② 的主权承载走本机回环；① 走 443 中继） |
| **P5**（平台可自建） | 倾向分成两步、排在 F1.5 之后 | ⚠️ **② 的"主权"读法其实就是 P5 的客户端形态** ⇒ **两条线是同一件事**，应合并考虑 |
| **§3.10 结论**（设备侧不进集群） | 已定 | ✅ **不变**，且本评估用②的信任分析**加强了它** |
| **G1 / G6 / F1.5** | 一切前置 | ⚠️ **本评估进一步强化**：方案想连"所有节点和设备" ⇒ **规模直接放大 G1 的爆炸半径** |

---

## §8 待拍板

> ⛔ 顺序不可颠倒；每项一句话说清 + 为什么需要你定 + 候选优缺点。**本轮只问 1 条**。

### 🔴 S1 —— 106 上现在那个实例怎么办？（**带数据的一次性动作，不可逆**）

**要你定的是**：106 服务器上现有的那个租户实例（跑在 19000 端口），在你把它变成 K8S 承载池之前，是**先迁走**、**原地保留并行**，还是**退役**。

**为什么需要你定**：这是一次**带用户数据的一次性动作**，做错了数据就丢了／或者用户会突然断服。而且它**决定了 106 这条路是"替换"还是"叠加"**——两种做法的后续工作量差一个量级。

**A 案 · 先迁走**（把那个实例搬到 47 或别的机器，再在 106 上装 K8S）
（优点：106 可以干净地当承载池，架构清晰，⛔ 不留两套共存；缺点：迁移本身是**带数据**的动作，有停机窗口，且**跨节点迁移今天未设计**——memory 已登记"实例跨节点迁移 ⛔ 未设计"。）

**B 案 · 原地保留并行**（106 上既有实例照跑，K8S 用另一组端口／目录起）
（优点：⛔ 零迁移风险，可以立刻开工试点；缺点：106 上**两套承载并存**，资源要重新算（2 核机可能不够），运维要同时管两套。）

**C 案 · 退役**（把那个实例停掉，用户另行安排）
（优点：最干净；缺点：**要用户配合**，且如果那是真实用户，等于给人断服。）

**我的倾向**：**B（原地保留并行）** —— 106 本来就是 Worker、试点阶段不需要它"干净"；先拿到 K8S 跑通与否的答案，再谈要不要清场。⚠️ 但前提是 **106 的规格装得下两套** —— 这一项**我还没取证**（§2.1 待查项），**要么先让我取证、要么你直接告诉我 106 的机器规格**。

---

## §9 出处

**用户原话（2026-09-26）**：

> AI1NET 网络结构调整为是否可行：覆盖网络连接所有节点和设备
> 1、服务器版 服务节点：（47服务器dsh官方实例+底层插件 admin 使用）可配置服务集群（106服务器：K8S集群 开启多个实例分别给多租户用户使用）
> 2、客户端版 服务节点：（官方dsh客户端版本，安装底层插件 admin使用，可在本机安装K8S集群 提供多租户服务）
> 3、客户端版 实例节点：（安装dsh客户段版本，安装底层插件 可选择连接到 服务节点作为单独实例使用）

**本评估引用的证据**：

| 证据 | 位置 |
|---|---|
| 定稿（唯一权威） | `dsh-server-docs/02-架构设计/覆盖网络-顶层架构全貌.md`（§三 三层权威 · §4.2 升格 · §5.1 入网六步 · §5.3 四条入口路径 · §六 G1–G7 · §七 推进顺序） |
| 实例启动链（`systemd-run` / `bwrap` / `setpriv`） | `src/supervisor/orchestrator.ts:1249`、`:1221`、`:1219` |
| 平台依赖检查（Linux 专有） | `src/cli.ts:106`、`:39` |
| 隔离能力平台分支 | `src/supervisor/firewall.ts:42`、`src/worker/agent.ts:147`、`src/supervisor/plugin-assembly.ts:796` |
| 平台主动关掉内置沙箱（信任根＝平台容器） | `src/supervisor/orchestrator.ts:823-827` |
| 管理员实例＝普通租户 | `src/db/repo.ts:617`、`src/web/middleware/authn.ts:31-38` |
| 「桌面」＝桌面浏览器访问（⛔ 非 desktop app） | `package.json` description |
| 宿主规格与单实例内存 | `orchestrator.ts:1233`、`:1229` |
| NAT 门槛（D8 实测） | `交付物/端口决策与设备中继可行性-20260926.md` |
| K8S 判定与 P6 | `交付物/全功能承载判定-底层插件能否承-20260926.md` §3.10／§3.11／§5 |