120 lines
10 KiB
Markdown
120 lines
10 KiB
Markdown
|
# 平台能力插件化 —— 形态判定与分层（2026-09-26）
|
|||
|
|
|
|||
|
|
> **回答的问题**（用户原话）：「设置中的功能是否也可以做一个插件，这样平台节点用户和客户端用户只需要接入这个插件就可以进行登录、更新、获取插件、使用插件接入平台功能。基于插件去构建平台功能。」
|
|||
|
|
> **本文口径**：判定在先；A/B 方案只在**真取舍**时出现（只有优点／只有缺点的候选已自行拍掉）。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 0 判定
|
|||
|
|
|
|||
|
|
⚠️ **部分可行** —— 「设置里的功能做成插件」**本平台已有先例且跑通了**；但 ⛔ **不能做成"一个插件包办登录 / 更新 / 取插件 / 用插件"**。
|
|||
|
|
|
|||
|
|
| 要的能力 | 能不能做成插件 | 一句依据 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| **登录 / 身份** | ❌ **不能** | 插件是"实例与界面起来之后"才存在的东西；登录必须发生在**它之前** ⇒ 把前置条件做成后置产物 = **逻辑倒置** |
|
|||
|
|
| **客户端自身更新** | ❌ **不能** | 换壳、换安装包只能在壳这一层；插件在壳里跑，改不了壳 |
|
|||
|
|
| **插件包的更新** | ✅ **能，且本会话刚跑通** | 平台侧共享包库已具备版本维度（归档/通道/钉版/矩阵），节点侧对账-拉取-校验已上线 |
|
|||
|
|
| **获取 / 启停 / 使用插件** | ✅ **能，已有先例** | 桌面线的「设置 → 插件 → 本地代理」就是**一个自研包两个入口**、界面落在**官方已有槽位** ⇒ 同一套路可承载平台能力 |
|
|||
|
|
| **接入平台功能（数据 / 模型 / 即时通讯）** | ✅ **能，且插件是唯一合适的位置** | 用户自配模型只在**实例内**可见；平台侧内核在平台进程 ⇒ 插件的身份就是"实例内的平台代理" |
|
|||
|
|
|
|||
|
|
**一句话结论**：**能做的比想象的多，但"全部塞进一个包"是错的形态** —— 正确形态是 **薄壳 ＋ 一个能力包**（§2）。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1 四件事为什么不能都进插件（同一句话讲清）
|
|||
|
|
|
|||
|
|
- **登录**：桌面线已定的形态是「**开窗直接进实例页**，未登录时点右下角胶囊才弹登录」⇒ **实例与界面先于登录**。若把登录做成插件，就变成"插件要等登录、登录要等插件"的**死锁**。
|
|||
|
|
- **更新**：这里混着两件不同的事 ——
|
|||
|
|
- 「**插件包**的版本更新」= 插件/共享层的事 ✅（本会话落地）；
|
|||
|
|
- 「**客户端程序**的更新」= 壳的事 ❌（插件无权替换自己所在的宿主）。
|
|||
|
|
- **获取插件 / 使用插件 / 接入平台功能**：这三件**正是插件该干的**，而且平台侧九成能力已经就位（§5）。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2 正确形态：**薄壳 ＋ 一个能力包**
|
|||
|
|
|
|||
|
|
**壳只做四件**：① 起实例 ② 渲染页面 ③ 壳级自更新 ④ 把身份（登录态 / 设备凭据）**交出去**。
|
|||
|
|
|
|||
|
|
**其余全部由一个「平台能力包」承载**：对外只留一个入口 —— 登录态、更新检查、可用插件列表、平台能力调用；界面**落在官方已有槽位**（设置 → 插件 / 能力管理），⛔ **不新造页面体系**（守桌面线"客户端不另做业务页面"的口径）。
|
|||
|
|
|
|||
|
|
🔴 **分层不倒置的判据**：**插件不可用 / 卸载时，壳照常起、实例照常用**（= 离线可用**不被插件绑架**）。任何"没这个插件就用不了"的设计 ⇒ **属负向迭代（R11）**，当场停下复盘。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3 三条必须守的边界
|
|||
|
|
|
|||
|
|
1. **一处身份、一处可撤回**：登录/设备授权既用于入网，也用于取内容与调平台功能 ⇒ **同一次发放**、撤回即全失效（⛔ 不各发一套凭据）。
|
|||
|
|
2. **⛔ 不给插件开"平台内网直达"**：能力包 = **实例内插件 ＋ 平台侧一个薄配对端**，两者走**既有对外 https 面**；插件拿不到平台内网、拿不到别的用户数据。
|
|||
|
|
3. **⛔ 插件不背壳级职责**：不承担登录、不承担自更新、不承担启实例。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4 代价与风险（诚实，不藏）
|
|||
|
|
|
|||
|
|
- **插件跑在实例内 ⇒ 它天然拥有该实例的全部权限**（含用户自配模型凭据）。⇒ 能力包必须**收窄**：只暴露必要能力、⛔ **不下发平台共享密钥**、⛔ 不做"万能代理"。
|
|||
|
|
- **「一个包办全部」会把离线可用打破**（插件挂 ⇒ 壳起不来/页面不出来）⇒ 明确的负向迭代，⛔ 不做。
|
|||
|
|
- **官方客户端封包有特殊契约**（手写模块直交会出现"界面不出现"这类静默失败，桌面线已把它列为真缺陷）⇒ **走官方包形态，⛔ 不自创封包**。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5 落地顺序（已具备 / 待办，逐项标状态）
|
|||
|
|
|
|||
|
|
| # | 事项 | 状态 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 1 | 平台侧**共享包库**（版本归档 / 通道 / 钉版 / 全局矩阵）＋ 节点侧**对账-拉取-校验** | ✅ **本会话已上机**（真跑：2 MB / 3,437 ms） |
|
|||
|
|
| 2 | 插件模型（实例内 host 半 ＋ 界面槽位 client 半）＋「设置里的功能做成插件」**先例** | ✅ 桌面线已跑通（本地代理包） |
|
|||
|
|
| 3 | **设备读内容**的权限（一处校验臂） | ⏸️ **待用户点头**（权限面，R5） |
|
|||
|
|
| 4 | 桌面侧**拉取器** ＋ 把共享包**接进实例装配**（判据：那栏「能力管理」开始出现） | ⏸️ 待桌面线接棒（对接单已交付「AI1Net Desktop 工作区」） |
|
|||
|
|
| 5 | 把平台能力做成**一个能力包**：第一版只做**只读三件**（看登录态 / 查更新 / 列可用插件），跑通后再加写面 | 🔜 新增（本判定之后） |
|
|||
|
|
|
|||
|
|
**⛔ 明确不做**：登录插件化、壳级自更新插件化、把壳级职责搬进插件。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 6 仍待你定（上一轮已问，**本轮不重复问**）
|
|||
|
|
|
|||
|
|
- **设备要不要获得「读取平台插件包」的权限** —— 已在上一轮作为待拍板项提出（A/B 案及优缺点见 `交付物/版本管理与包更新机制-执行报告-20260926.md` §9）；本文只登记依赖关系：**本判定 §5 第 4、5 项都等它**。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 7 追问逐条判定（2026-09-26 08:1x · 用户原话：「把这些功能都做在插件中是否就可以实现插件的更新就是客户端的更新，使用这个插件就需要登录确认身份，跟 DSH 的主程序也脱离开来」）
|
|||
|
|
|
|||
|
|
| 期望 | 判定 |
|
|||
|
|
|---|---|
|
|||
|
|
| ① **插件的更新 = 客户端的更新** | ⚠️ **九成成立，不是全部** |
|
|||
|
|
| ② **用这个插件就要登录确认身份** | ✅ **成立**（把身份当**启用门禁**）—— ⛔ 但"登录动作"仍归壳级 |
|
|||
|
|
| ③ **跟 DSH 主程序脱离开来** | ⚠️ **只能"业务脱开、扩展点依附"**，⛔ 做不到结构性脱离 |
|
|||
|
|
|
|||
|
|
### 7.1 ① 为什么是"九成"而不是"全部"
|
|||
|
|
|
|||
|
|
- **能随插件更新的**：所有界面（界面半注册到**官方已有槽位**）＋ 全部平台侧能力（身份态、更新检查、取插件、数据面、即时通讯）—— ⛔ 不需要重新发安装包。这正是用户想要的那部分。
|
|||
|
|
- **不能的（必须留在引导层）**：换壳、换安装包、换官方主程序版本 —— **以及"把插件取下来并装进去"这件事本身**（先有鸡还是先有蛋）。
|
|||
|
|
- ⇒ 结论：**"客户端"要拆成两层** —— **引导层**（极小、跟安装包走）＋ **能力层**（插件，可随时更新）。用户说的"插件更新即客户端更新"，成立的正是**能力层**。
|
|||
|
|
- ⭐ **设计目标 = 把引导层冻结到只做五件事**：起实例、渲染、取身份、拉包并装配、壳级自更新。引导层越薄 ⇒ "客户端更新"就越等于"插件更新"。
|
|||
|
|
|
|||
|
|
### 7.2 ② 成立的形态（而且比"门票"更强）
|
|||
|
|
|
|||
|
|
- 插件可以把「**拿到有效身份**」当**启用门禁**：没身份 ⇒ 不注册功能 / 界面显示未登录态。✅
|
|||
|
|
- ⭐ **更强的一层**：如果**包本身就只能在登录之后拿到**（用设备凭据去拉），那么"登录"同时是**取内容的前提** ⇒ 未登录 = **既没有功能、也没有代码**。这条**天然把身份变成信任链的起点**，比只当"功能门票"强得多。
|
|||
|
|
- ⛔ 唯一不许的：让**登录动作本身**依赖插件（死锁，见 §1）。
|
|||
|
|
|
|||
|
|
### 7.3 ③ 精确边界（"脱开"要分两半说）
|
|||
|
|
|
|||
|
|
- **已经脱开的**（其实一直就是脱开的）：账号体系、门户、内容分发、数据面、即时通讯 —— 官方 dsh **没有账号体系**，这些全在平台自己的控制面里。
|
|||
|
|
- **脱不开的**：插件**寄生于**官方 dsh 的进程与扩展点（服务端半走 `apply(ctx)`、界面半注册官方槽位、桌面端只有"精确路径"的挂载口）⇒ **官方接口变，插件要跟**。
|
|||
|
|
- 🔴 **实测反例（用本线自己的数据，别夸大）**：上一轮基线从 0.1.5 升到 0.1.7，**自研插件零源码改动就平移成功** —— 看着像"解耦"，但**同期壳与启动侧硬改了三处**（profile 路径、必需的运行时目录、协议版本）⇒ 真结论是「**插件对官方接口有韧性，但那是"恰好契约没变"，不是结构性解耦**」。⛔ 别把一次幸运当架构。
|
|||
|
|
- ⇒ 真要"彻底脱离"只剩一条路：**自研内核**（不用官方那份）。代价 = 放弃官方演进 ＋ 与「UI 与服务器版本一模一样」的既定口径冲突 ＋ 现有扩展点成果作废 ⇒ **不建议**（真要做，另立专项评估）。
|
|||
|
|
|
|||
|
|
### 7.4 「插件 = 客户端」形态**新增的那一条**安全成本（必须点名）
|
|||
|
|
|
|||
|
|
- 既然插件承担客户端功能 ⇒ **"内容即代码"**：若没有**包签名校验**，凡能拿到拉取权限的一方都能把代码塞进客户端。
|
|||
|
|
- 现状：平台共享层只有**内容指纹**（防传输/装配出错）＋ 发布时的包哈希校验，**没有发布者签名** —— 执行单 §2.3 已把"发布者签名校验"登记为建议项，且**签名者根密钥归覆盖网络线口径**（跨线）。
|
|||
|
|
- ⇒ 在本形态下这条从"建议"升级为**要件**；⚠️ **本线只登记、不设计**（跨线议题）。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 附 · 本判定的依据来源（单一来源，⛔ 不复制正文）
|
|||
|
|
|
|||
|
|
- 平台侧共享层与拉取机制：本工作区 `交付物/版本管理与包更新机制-执行报告-20260926.md`（判定表 ＋ S4 真跑读数）。
|
|||
|
|
- 插件模型 / 界面槽位先例 / 离线可用口径 / 封包契约：`E:/ProgramData/AIProject/dsh-ai1net-desktop/MEMORY.md` §1（乙方案、"零 UI"口径）＋ `docs/S12_…_20260925.md` §9、`docs/S15_…_20260925.md` §11-⑪。
|
|||
|
|
- 插件必须在实例内跑（用户自配模型可见性 / 跨进程边界）：本工作区 `交付物/IM插件接入完备性审计-20260925.md`。
|