dsh_ai1net_server/交付物/基础服务插件-能做不能做总清单与拍板路径-20260926.md

基础服务插件 · 能做 / 不能做 总清单与拍板路径（2026-09-26）

本文 = 决策件（成品）。逐模块明细 ⇒ 平台新增功能总盘点与插件化归属-20260926.md §3–§8（⛔ 不复制）。 本文只做三件事：① 按插件单元重组"能做/不能做"（换一个切面）② 列清不可做及其判据 ③ 给出拍板路径（哪个决定决定哪个）。 ⚠️ 本文的 ✅/❌ 全部沿用 §3–§16 的既有判定，⛔ 不新增结论；本棒的增量只有重组 ＋ 拍板路径。

---

0 一句话判定

• ✅ 能做：平台新增里的客户端侧能力（约九成，按功能组计）⇒ 收进「一个包、两个半」，以后随插件更新，不必重发安装包。
• ❌ 不能做：只有 5 件，全部发生在**「插件存在之前」**（引导层）。⛔ 不是"不做"，是"只能放在那里"。
• ⚠️ 范畴不同：服务器侧自有服务本来就不依赖 DSH ⇒ 不算"不能进插件"（算作候选是范畴错误）。

---

1 插件规划总览（四个层，只有第 3 层是"插件"）

层	是什么	改一次要重发安装包吗
L0 官方宿主	宿主进程 · 界面框架 · 插件机制与扩展点 · 技能加载	⛔ 不是我们的（R2 零改动）
引导层	起实例 · 起窗口 · 取身份 · 把包装进去 · 原生网络守护	🔴 要 —— 所以必须冻结到最薄
插件（本文主角）	能力入口与界面，全部落在官方已有槽位	✅ 不要 ← 规划的价值就在这一行
服务器侧自有服务	账号 · 多租户编排隔离 · 协作内核 · 中继 · 门户 · 运维	✅ 不要（跑在服务器上，不是客户端的事）

🔑 本规划的核心主张：把"客户端里会变的东西"尽可能压进第 3 层 —— 于是更新插件 = 更新客户端，第 2 层（唯一要重发安装包的那层）就永远不动。

---

2 判据 —— 一条就够，自己也能判

这件事发生在「插件存在之前」还是「之后」？ 之前 ⇒ 引导层，⛔ 不可插件化；之后 ⇒ ✅ 可插件化。

配套三条"为什么"（判据背后的机制，⛔ 记住就能自己推）：

#	为什么"之前"的事下不来	出处
①	先有鸡还是先有蛋 —— "把包装进去"这个动作，⛔ 不能由被装的那个包来做	§4 · §10-4
②	画面要先出来 —— 渲染早于插件加载，窗口与首屏不可能由插件画	§3 · §10-2
③	判决者唯一 —— 权威（谁托管谁、谁能进、谁是设备）不能由被判决的一方自己选；双写 = 脑裂 ⇒ 数据损坏	§16.2

---

3 ✅ 能做 —— 全部收进「一个包、两个半」

形态：一个包，两个入口（先例＝本地代理包就是"一个自研包两个入口"）。

3.1 服务端半（平台能力的统一出口）

能力	说明
身份态与账号设置	登录动作不在这里，但身份展示与设置在这里
可用插件清单 / 启停 / 版本矩阵 / 定向钉版	管理界面 ＋ 调接口（装配动作在引导层，见 §4）
插件数据面（一插件一库）	本来就是给插件用的 ⇒ 天然属于本包
插件 SDK / 扩展点 / 回调桥	同上 —— 本身就是给插件用的
协作（房间 / 消息 / 发言规则）的客户端侧	内核在服务器，客户端侧是插件
技能清单 / 共享模型授权态 / 网络与设备状态	全部为展示 ＋ 申请入口
更新检查（问一句"我落后了吗"）	拉取动作在引导层，见 §5-4
审计 / 日志 / 健康	展示

3.2 界面半（⛔ 不新造页面体系）

能力	落点
各能力的管理页／列表页	官方已有槽位（设置 → 插件 / 能力管理 …）各一页
工作台 UI / 窄档响应式	插件本来就是干这个的
会话与工作区分组的列表与切换	存储在服务器，界面在插件

⇒ 用户那句「基于这个插件可以去使用现有新增能力」—— ✅ 成立，而且这正是把这些能力统一出口的正确做法。

---

4 ❌ 不能做 —— 6 件（同一条判据：都在"插件存在之前"）

#	事情	归属	为什么（一句话）
1	起实例（把官方宿主进程跑起来）	引导层	插件跑在实例里，实例不可能由插件起
2	起窗口 / 渲染首屏	引导层	画面早于插件加载
3	取身份（登录 ＋ 设备授权）	引导层 ＋ 服务器侧	要先拿到身份才能取到包（⇒ 身份是信任链起点）
4	把包拉下来并装进去（含版本管理与拉取器）	引导层	判据① —— 装包的动作不能由被装的包做
5	原生网络守护（拨号 / 中继 / 寻址 / 组密钥）	引导层（原生进程）	隧道必须在界面之前建好，且要原生权限
6	起承载服务（Manager / Worker 本体）	引导层（原生进程）	它们要系统级能力（独立账号 / cgroup / 监听端口），而插件跑在实例里、权限是收窄的

⚠️ 计数沿革（如实记）：§10 原记 4 件 → 本轮并入第 5 件（原生网络守护，原散在 §7）→ 再并入第 6 件（起承载服务，见 五种角色选择场景-明确件-20260926.md §2）。总数 6。 ⚠️ 第 6 件的口径辨析：服务本体属范畴不同（本来就不依赖 DSH，见 §5），但**"把它起起来"这件事**需要系统级权限 ⇒ 属引导层。两者不矛盾。

🔴 这 6 件必须"冻结到最薄"：它们是唯一"一变就要重发安装包"的部分 ⇒ 每加一点，就永久损失一点"插件更新即客户端更新"的收益。

---

5 ⚠️ 范畴不同 —— 服务器侧自有服务（⛔ 别算作插件的候选）

多租户编排 / 沙箱隔离 / 用户卷 / 协作内核 / 中继 / 门户 / 运维（部署·回滚·备份·域名·证书）

• 它们不是"不能进插件"，而是"本来就不依赖 DSH" —— 官方没有账号体系，所以这部分从第一天起就是我们自己的独立进程。
• 客户端在其中只能是调用方（插件里只做入口与展示）。
• 运维面（部署 / 回滚 / 备份）根本不在客户端。

⚠️ 一处不建议（可推翻）：门户六页（含登录页）不要搬进插件 —— 桌面线口径是「套壳 ＋ 同步服务器代码」「UI 与服务器版本一模一样」；插件里再实现一份 ⇒ 两份 UI 必然漂移（负向迭代）。⇒ 门户保持服务器页面，插件只做入口与内嵌。

⚠️ 本组是此前"为什么不能"的最大误会来源：把服务器提供的能力当成客户端功能，再看插件，就会得出"什么都做不了"。

---

6 拍板路径（哪个决定决定哪个）

        ┌─────────────────────────────────────────────┐
        │ P1  插件规划走不走？（产品主路径 · 业务方向） │
        └───────────────────────┬─────────────────────┘
                    ┌───────────┴───────────┐
                    ▼                       ▼
        ┌───────────────────────┐  ┌──────────────────────────┐
        │ P2 设备要不要有读包的权 │  │ P3 节点提供哪些具体服务   │
        │ （权限面 · 决定安全要件）│  │ （业务方向 · 决定值不值得）│
        └───────────┬───────────┘  └──────────────────────────┘
                    ▼
        ┌─────────────────────────────────────────────┐
        │ 自动结论：包签名校验（P2 给权 ⇒ 立即由"要件"升"必需"）│
        └─────────────────────────────────────────────┘

顺序不可颠倒：P1 是"要不要这么规划"；P2/P3 是"规划里的两条支路"。⛔ 先答 P2/P3 会白答 —— 若 P1 走别的形态，这两条的前提就变了。

⚠️ 上图只覆盖"客户端形态"这一轴。2026-09-26 09:4x 起新增 P5（服务端形态：平台要不要做成用户可自建），与 P1 并列但不同轴 ⇒ 见 §7-P5。

本线已自决、⛔ 不必你拍（登记备查，可推翻）：

项	自决结果	依据
引导层冻结到最薄	✅ 冻结（列 5 件为上限）	判据：它一变就要重发安装包
门户搬不搬进插件	⛔ 不搬（保服务器页面）	两份 UI 必漂移 ⇒ 负向迭代（R11）
承载归属迁移（实例换机）立不立项	⛔ 不立项（登记为具名未设计项）	候选只有缺点（不可逆级、需独立设计）⇒ 按判据自己拍掉
包签名校验谁做/何时	由 P2 自动决定	给读取权 ⇒ 必需；不给 ⇒ 非阻塞

不在本线拍板（指向他线，⛔ 本线不替代）：

• 跨区可见性默认（各区互不可见 vs 允许自由接入任意节点）⇒ 属覆盖网络线口径；本规划触发了它（§16.2-3），但不在此处定。
• 多 Manager（控制面联邦）治理口径 ⇒ 同属覆盖网络线架构定稿。

---

7 待拍板（按 §6 顺序，逐条编号 · 候选带优缺点）

P1 —— 插件规划走不走？

要你定的是：以后客户端**"只装官方宿主 ＋ 装我们的插件"，还是继续保留我们自己那个壳**。

为什么需要你定：它决定"更新"这件事的成本结构 —— 走插件路线 ⇒ 以后改功能不重发安装包；保留自研壳 ⇒ 每次改客户端都要用户重装。这是产品形态，我定不了。

• A 案｜只装官方宿主 ＋ 我们的插件 优点：功能更新不重发安装包；我们的维护面收到一个包；界面上限受官方槽位约束反而稳定。 缺点：第一眼是官方页面、不是我们的门户；界面受官方槽位限制（⛔ 做不了官方没给的位置）；与官方版本升级绑定；引导层 5 件仍需自己维护并冻结。
• B 案｜保留自研壳（现状为主） 优点：界面与体验完全自主；可以做官方没给的页面结构。 缺点：每次改客户端都要重发安装包；壳的升级要自己维护；与官方宿主仍是两套东西。

我的倾向：A 案，但引导层那 5 件按"最小原生守护 ＋ 半个宿主插件"来落地（即形态上走 A，实现上不放弃既有壳的资产）。理由：只有 A 能让"九成功能随插件更新"这句话成立；B 案的代价是每次改界面都要用户重装，长期最贵。

P2 —— 用户设备要不要获得「读取平台插件包」的权限？

要你定的是：让不让用户设备也能读平台上的插件包。

为什么需要你定：它决定"轻节点当内容副本 / 设备当消费者"这条路走不走得通；它会让设备能读到平台上的包，属权限面变动。

• A 案｜给（只读、可撤销） 优点：设备可当内容副本；断网时靠邻居；省跨区流量。 缺点：多开一个读取口，包来源面变大；必须配套包签名校验才安全。
• B 案｜不给（维持现状） 优点：权限面零变化，攻击面最小。 缺点："轻节点当副本 / 设备当消费者"直接堵死；以后要再开等于重走一遍权限评估。

我的倾向：A 案，前提是与包签名校验绑在一起上线。

P3 —— 节点提供哪些具体服务？

要你定的是：当一台机器"成为节点"时，它对别人到底提供什么。

为什么需要你定：这决定"自选当节点"值不值得做、以及节点之间怎么分工。属业务目标，我定不了。

• A 案｜先只提供"内容"（插件与能力的来源） 优点：已实测跑通（106 → 47）；不新增权限面；范围最小、最快能用。 缺点：节点只是"下载源"，吸引力有限；用不上节点的算力。
• B 案｜内容 ＋ 承载（还能托管别人的实例） 优点：真正用上节点的机器资源；"当节点"有意义。 缺点：要入向可达（家用网络不一定满足）；要平台的放行与配额治理；离"迁移"议题很近，而迁移未设计。

我的倾向：先 A 案，把 B 案里"承载"部分挂在迁移机制之后（迁移未设计 ⇒ ⛔ 现在不做）。

P4 —— 跨用户要不要打通？（2026-09-26 09:2x 新登记）

要你定的是：让不让不同用户之间的设备/实例直接连上（现状是结构性不通）。

为什么需要你定：现状每个用户各一张网，u:A 与 u:B 之间在"能不能拨"那一步就走不到 ⇒ 跨用户协作只能走平台（443）。打通 = 扩大可见面，属权限面决策。

• A 案｜不打通（维持现状） 优点：隔离是结构性的（⛔ 不靠一张可写错的清单）；跨用户协作一律过平台 ⇒ 可审计、可限流。 缺点：跨用户的数据交换多一跳、依赖平台在线；点对点能力用不上。
• B 案｜打通（按需授权互联） 优点：跨用户可直连，省中继流量、低延迟。 缺点：可见面扩大（要新增"谁能连谁"的授权面，而现状刻意没有它）；网维度从"结构性隔离"退化为"策略性隔离"；审计面变复杂。

我的倾向：A 案。理由：本规划的价值在"把能力收进插件、把隔离做成结构性的"，B 案会把已经做硬的隔离重新变软。⚠️ 本条排在 P1 之后 —— 若 P1 走"只装官方宿主 ＋ 插件"，跨用户协作本来就该走平台，P4 可能自动消失。

P5 —— 平台要不要做成「用户可以自己搭一套」？（2026-09-26 09:4x 新登记）

⚠️ 与 P1 是不同轴：P1 = 客户端形态；P5 = 服务端形态。⛔ 答了 P1 不等于答了 P5。

要你定的是：允不允许用户在自己机器上建自己的控制面（即"装插件后选 Manager、多个 Manager 关联、其中一个升为根"这条路），也就是把平台从「一个我们的服务」变成「一份可被别人部署的东西」。

为什么需要你定：它决定后面全部工作量的方向 —— 走这条路，要新做三件硬东西（选主实现、多控制面权威关系、撤根机制）；不走，那些场景就只对我们自己那几台机器成立。

• A 案｜做成可自建 优点：平台变成可分发的东西，用户能自建自己的区（5 个角色场景全部成立）。 缺点：要新做三件硬东西（选主实现 / 多控制面权威关系 / 撤根机制）；⚠️ 撤根机制缺失 ⇒ "升根"暂时不可逆；运维面显著变复杂。
• B 案｜维持单一控制面（只对我们自己的机器） 优点：零新增风险，现有隔离与 fencing 口径原样成立。 缺点："用户自建 Manager / 多 Manager 网络 / 升根"三条不成立，只剩"当 Worker"与"当客户端"可用。

我的倾向：A 案，但分两步 —— 先只做「多控制面共存」所需的最小件（选主），把「升格为根」明确挂起到撤根机制有结论之后。理由：多控制面共存是这条形态里唯一有独立价值、且不引入不可逆操作的一步；升根在撤根机制缺失时只有缺点（按判据 ⇒ 自己拍掉）。

📂 逐条判定与代码实测缺口 ⇒ 交付物/五种角色选择场景-明确件-20260926.md（⛔ 不复制正文）。