@zhz8888/dsh-radeon-cloud-patcher 1.2.0 → 1.3.0

package/README.md

@@ -30,13 +30,15 @@
    命令行执行
    `dsh plugin --profile <profile> add @zhz8888/dsh-radeon-cloud-patcher`。
    装不上（pnpm 报 404）就改用[安装](#安装)里的方式三，从源码装同一个包。
-2. **重启 DSH** —— 定义写在补丁层的 config 行里，而插件市场的**热挂载只支持纯 insert 行**，
-   因此安装后市场会提示「重启后生效」，这一步不能省。重启后 provider 就位，没有其它后置步骤。
+   装好后插件列表里显示的条目名是 **Radeon Cloud**（中文界面为「Radeon Cloud 提供方」），
+   而不是上面那串包名——名称取自包内的 `locale/`，见[项目结构](#项目结构)。
+2. **重启 DSH** —— 定义写在补丁层的 config 行里，插件管理器对这类变更只会给出
+   `restart-required`，不会在运行中生效。重启后 provider 就位，没有其它后置步骤。
 3. **填密钥** —— 左下角「账号菜单 → 设置 → 模型」，找到 **Radeon Cloud** 一行，
    点「编辑」，在「API 密钥」里粘贴密钥，点「保存」。
 
 装好之后：那一行右侧出现**绿点**（悬停显示「API 密钥已配置」）；回到对话，点输入框下方的
-模型选择器，Radeon 的 8 个模型会出现在列表里；选中模型后再选「推理等级」就是思考档位。
+模型选择器，Radeon 的 10 个模型会出现在列表里；选中模型后再选「推理等级」就是思考档位。
 
 **怎么确认真的装好了** —— 三个现象同时成立，说明插件与它的补丁层都到位：
 
@@ -109,7 +111,7 @@ Radeon 的响应体与流式分片都存在一个容易致错的形态：思考
 
 ### 其他
 
-- 8 个对话模型全部可选，思考档位按模型独立声明
+- 10 个对话模型全部可选，思考档位按模型独立声明
 - 视觉模型支持图片输入
 - 限流退避遵循服务端 `Retry-After`
 - 附带离线校验、回归测试与档位实测工具
@@ -172,8 +174,9 @@ printf 'registry=https://registry.npmmirror.com\n' >> ~/.dsh/profiles/<profile>/
 dsh plugin --profile <profile> add @zhz8888/dsh-radeon-cloud-patcher@<版本>
 ```
 
-> 本包的 tarball 里只有 JSON / YAML / JS，**没有安装期构建脚本**，
-> 因此换源、离线镜像、内网私服都不会碰到 pnpm 的 `allowBuilds` 授权那一步。
+> 本包的 tarball 里只有插件自己的源码、定义与脚本（不含 `test/` 与 `docs/`），
+> **没有安装期构建脚本**，因此换源、离线镜像、内网私服都不会碰到 pnpm 的
+> `allowBuilds` 授权那一步。
 
 ### 方式三：从源码 / GitHub 安装
 
@@ -281,13 +284,15 @@ RADEON_CLOUD_API_KEY=rc-你的密钥 dsh --profile <profile>
 
 对话输入框下方点模型选择器 → 选 Radeon Cloud 的模型 → 再选「推理等级」，
 那就是思考档位。档位按模型逐个声明（见[可用模型](#可用模型)）：
-GLM 与 Qwen 系不接受 `none`，因此没有关闭档位；`MiniCPM5-2B` 不是推理模型，
-不会出现档位下拉。选了服务端不接受的档位是**硬失败**（400 / 422），不会静默降级。
+GLM-5.3-Flash 与 MiniCPM-V-4.7-1B 不接受 `none`，因此没有关闭档位；
+`MiniCPM5-2B` 不是推理模型，不会出现档位下拉。
+选了服务端不接受的档位是**硬失败**（400 / 422），不会静默降级。
 
 ### 3. 图片输入
 
 支持图片：DeepSeek-V4.1-Flash、DeepSeek-V4-Flash-Vision-Exp、MiMo-V2.6-Flash、
-Qwen3.8-27B、Qwen3.8-Flash-Next。只收文本：DeepSeek-V4-Flash、GLM-5.3-Flash、MiniCPM5-2B。
+MiniCPM-V-4.7-1B、MiniCPM-V-4.7-35B-A3B、Qwen3.8-27B、Qwen3.8-Flash-Next。
+只收文本：DeepSeek-V4-Flash、GLM-5.3-Flash、MiniCPM5-2B。
 
 ### 4. 升级与卸载
 
@@ -297,7 +302,7 @@ dsh plugin --profile <profile> remove @zhz8888/dsh-radeon-cloud-patcher      #
 ```
 
 升级不需要额外动作：定义由插件层声明，装上新版本重启即生效
-（在市场里升级同样会提示「重启后生效」，原因与安装一致）。
+（在市场里升级同样要重启，原因与安装一致）。
 **卸载即删除供应商**——插件层消失，provider 与设置页那一行一起消失。
 
 > 例外：如果你曾用 `pnpm install:profile` 把定义合并进 profile（见[归属与删除](#归属与删除)），
@@ -336,7 +341,7 @@ dsh plugin --profile <profile> remove @zhz8888/dsh-radeon-cloud-patcher      #
   **本 provider 那一行**的标签隐藏掉：
 
   ```css
-  li:has(button[aria-label*="(radeon-cloud)"]) span[class*="rowTag"] { display: none }
+  li:has(button[aria-label*="(radeon-cloud)"]) span[class*="rowTag"] { display: none !important }
   ```
 
   代价说清楚：它依赖 DSH 的 DOM 结构与类名片段，DSH 改版后可能静默失效——
@@ -354,6 +359,7 @@ DSH 的非 insert 补丁是**整体替换**：`llm-pi-ai` 的 config 只要在 p
 | profile 里有一份**与本插件一致**的同 id 声明 | 放行，并提示它会在卸载后残留（通常是你在设置页保存过一次、被物化出的副本） |
 | profile 里有一份**与之不一致**的同 id 声明 | **启动失败**：报「provider id 冲突」，并指名第一处差异字段 |
 | profile 给 `llm-pi-ai` 写了 config 却没有本 provider | **启动失败**：报「定义未生效」，并打印可直接执行的合并命令 |
+| 那一层的 config 是 `!!js` 表达式，或本次运行读不到 profile 目录 | 跳过判定并告警——静态判断不了，不等于失败；真正生效的是哪一份以 `dsh --profile <profile> --dump-config` 为准 |
 
 后两种是**失败 + 原因**，而不是静默接管或静默消失——这是本项目的取舍：id 冲突要响亮。
 处置方式（按键合并、`--force`、输出示例）见[已知限制](#6-与用户自有-provider-共存)。
@@ -383,9 +389,13 @@ dsh-radeon-cloud-patcher/
 ├── client/                                    客户端补丁
 │   └── client.js                              隐藏本行的「自定义」标签（DSH 客户端模块格式，非 ESM）
 │
+├── locale/                                    插件页显示名称（DSH 按包内 locale 读取，缺了就回落成 npm 包名）
+│   ├── en.json                                英文：{"meta":{"title":"Radeon Cloud",…}}
+│   └── zh.json                                中文：{"meta":{"title":"Radeon Cloud 提供方",…}}
+│
 ├── src/                                       插件实现（薄壳，不含 provider 逻辑）
 │   ├── index.js                               插件入口：启动校验、所有权判定、收尾核验
-│   ├── ownership.js                           所有权判定的纯函数（四种结局与差异定位）
+│   ├── ownership.js                           所有权判定的纯函数（四种归属结局 + dynamic 哨兵、差异定位）
 │   ├── merge.js                               键级合并的纯函数（补救路径使用）
 │   ├── patch-text.js                          文本级合并，保留用户注释与格式
 │   ├── validate.js                            定义的结构校验
@@ -398,24 +408,15 @@ dsh-radeon-cloud-patcher/
 │   ├── probe-efforts.mjs                      实测逐模型 reasoning_effort 档位表
 │   └── radeon-api.sh                          API 调用助手（密钥取自环境变量或凭据存储）
 │
-├── test/                                      离线测试
-│   ├── merge.test.mjs                         合并语义与幂等性
-│   ├── patch-text.test.mjs                    不破坏用户 provider 与注释
-│   ├── ownership.test.mjs                     四种所有权结局与差异定位
-│   ├── apply-guard.test.mjs                   启动看护：放行、或失败并说明原因
-│   ├── patch-sync.test.mjs                    补丁与定义真源一致、结构符合「无删除按钮」
-│   ├── client-patch.test.mjs                  客户端补丁注入的规则
+├── test/                                      离线测试（自研 runner，无测试框架）
+│   ├── *.test.mjs                             清单不变式、插件页元信息、合并语义、
+│   │                                          文本级编辑、所有权判定、启动看护、
+│   │                                          补丁与客户端一致性
 │   ├── verify-reasoning.mjs                   思考文本取回的回归测试
-│   └── fixtures/
-│       └── stream-reasoning.sse               实测抓取的真实流
+│   └── fixtures/stream-reasoning.sse          实测抓取的真实流
 │
 └── docs/                                      技术文档
-    ├── plugin-parity-assessment.md            与其他 provider 插件的使用方式差异评估
-    ├── feasibility-assessment.md              可行性评估与线格式差异矩阵
-    ├── implementation-plan.md                 实施计划与检查点结论
-    ├── live-verification.md                   真机联调实测记录
-    ├── reference-commandcode-provider.md      第三方 provider 插件参考实现分析
-    └── market-submission.md                   插件市场投稿说明
+    └── market-submission.md                   插件市场投稿与 npm 发布说明
 ```
 
 > 插件壳只做四件事：**分发**（npm 包，可被插件市场安装）、**声明**（provider 定义写在
@@ -428,13 +429,16 @@ dsh-radeon-cloud-patcher/
 ## 常用命令
 
 ```bash
-# 全量测试（合并语义、所有权判定、启动看护、补丁一致性、思考字段取回）
+# 全量测试（清单不变式、插件页元信息、合并语义、所有权判定、启动看护、补丁一致性、思考字段取回）
 pnpm test
 
-# 只跑启动看护（四种所有权结局）与补丁一致性
+# 只跑启动看护（四种归属结局 + dynamic 跳过）与补丁一致性
 pnpm test:guard
 pnpm test:patch
 
+# 只跑插件页显示名称的契约（locale 文件 + exports 模式 + files 白名单）
+pnpm test:meta
+
 # 校验 provider 定义：结构校验 + llm-pi-ai 真实 schema 校验
 # 这是判断「字段在当前 DSH 版本里是否仍然有效」的那道校验，建议升级 DSH 后跑一次
 pnpm validate
@@ -456,7 +460,7 @@ pnpm probe --only Qwen3.8-27B
 
 ## 可用模型
 
-> 采集日期：**2026-10-04**
+> 采集日期：**2026-10-16**
 
 | 模型 | 上下文 | 图片 | 思考档位 |
 | --- | --- | --- | --- |
@@ -464,13 +468,16 @@ pnpm probe --only Qwen3.8-27B
 | DeepSeek-V4-Flash | 1,048,576 | ❌ | off/minimal/low/medium/high/xhigh/max |
 | DeepSeek-V4-Flash-Vision-Exp | 1,048,576 | ✅ | off/minimal/low/medium/high/xhigh/max |
 | MiMo-V2.6-Flash | 1,048,576 | ✅ | off/minimal/low/medium/high/xhigh/max |
+| MiniCPM-V-4.7-35B-A3B | 262,144 | ✅ | off/minimal/low/medium/high/xhigh/max |
 | Qwen3.8-27B | 262,144 | ✅ | off/low/medium/xhigh |
 | Qwen3.8-Flash-Next | 262,144 | ✅ | off/low/medium/xhigh |
 | GLM-5.3-Flash | 262,144 | ❌ | low/medium/high |
+| MiniCPM-V-4.7-1B | 262,144 | ✅ | low/medium/high |
 | MiniCPM5-2B | 131,072 | ❌ | （不返回分离思考，故不提供档位） |
 
 `off` 表示发送 `reasoning_effort: "none"` 关闭思考。
-**GLM-5.3-Flash 与 Qwen3.8-27B 不支持 `none`**，因此没有关闭档位；其中 Qwen 系在「不传档位」时也会思考（AMD 服务端行为）。
+**GLM-5.3-Flash 与 MiniCPM-V-4.7-1B 不接受 `none`**，因此没有关闭档位；Qwen 系靠 `none` 关闭，而**不传档位时仍会思考**（AMD 服务端行为）。
+`MiniCPM-V-4.7-35B-A3B` 与 `MiniCPM-V-4.7-1B` 同属 MiniCPM 系，但档位表并不相同——**不要按模型名的相近程度推断档位**。
 
 > **档位表不在 API 里**（`GET /v1/models` 不返回该信息），只能实测。模型上下架会导致此表过期，
 > 请用 `pnpm probe` 复测后再更新 `provider/radeon-cloud.yml`。
@@ -504,8 +511,10 @@ DSH 的 `dsh-llm-pi-ai` 会对此抛 `UNSUPPORTED_OPTION`，属于响亮失败
 
 ### 3. 部分模型不接受 `developer` 角色
 
-DSH 默认对 OpenAI 兼容端点使用 `developer` 承载系统提示词，8 个模型中有 5 个会直接报
-`unknown role: developer`。已通过 `compat.supportsDeveloperRole: false` 关闭。
+DSH 默认对 OpenAI 兼容端点使用 `developer` 承载系统提示词，10 个模型中有 6 个会拒绝，
+且报错文本分两种：GLM-5.3-Flash、MiniCPM5-2B、MiniCPM-V-4.7-1B 报 `422 unknown role: developer`；
+Qwen 系两个与 MiniCPM-V-4.7-35B-A3B 报 `400 Unexpected message role.`。
+已通过 `compat.supportsDeveloperRole: false` 关闭，改用 `system` 角色。
 
 ### 4. 档位被拒是硬失败
 
@@ -540,7 +549,7 @@ node ~/.dsh/profiles/<profile>/node_modules/@zhz8888/dsh-radeon-cloud-patcher/sc
 
 ```
 【写入】 ~/.dsh/profiles/desktop/cordis.patch.yml
-  新增 providers.radeon-cloud（8 个模型）
+  新增 providers.radeon-cloud（10 个模型）
   保留的其它 provider：my-corp-proxy, another-one
   顶层条目 12 个，增减 0 个
 ```
@@ -559,17 +568,15 @@ node ~/.dsh/profiles/<profile>/node_modules/@zhz8888/dsh-radeon-cloud-patcher/sc
 ## 兼容性
 
 - 目标 DSH 版本：`>=0.2.0-rc.1`，**无上界**（三处声明一致，见[版本闸门](#版本闸门)）
-- 模型目录与档位表采集日期：**2026-10-04**
-- 收录的模型当前均为 `stability: experimental`
+- 收录的模型当前均为 `stability: experimental`——上游接口行为可能变，档位失效时先复测
 - 仅覆盖 Public Free Model APIs（共享端点）；独占端点的基础 URL 每次实例重启都会变化，不在本项目范围内
-- 客户端补丁依赖 DSH 模型设置页的 DOM 结构（`aria-label` 中的 provider 路由名 + `rowTag` 类名片段）。
-  DSH 改版后它会静默失效——「自定义」标签重新出现，功能不受影响
+- 客户端补丁依赖 DSH 的 DOM 结构，DSH 改版后可能静默失效（机制与代价见[归属与删除](#归属与删除)）
 
 ---
 
 ## 许可证
 
-本项目以 [MIT 许可证](LICENSE) 开源。
+本项目以 [MIT 许可证](https://github.com/zhz8888/dsh-radeon-cloud-patcher/blob/main/LICENSE) 开源。
 
 MIT 许可证允许你自由使用、复制、修改、合并、发布、分发、再许可及销售本项目的副本，
 唯一义务是在所有副本或实质性部分中保留版权声明与许可声明。

package/cordis.plugin.patch.yml

@@ -49,7 +49,7 @@
         baseURL: https://developer.amd.com.cn/radeon/api/v1
         displayName: Radeon Cloud
 
-        # 默认思考档位。medium 在全部 8 个已收录模型上均被接受。
+        # 默认思考档位。medium 在全部 10 个已收录模型上均被接受。
         reasoning: medium
 
         # Radeon 的思考与答案共用同一个 max_tokens 预算，预算不足时 content
@@ -76,7 +76,9 @@
         # ── 协议兼容开关 ──────────────────────────────────────────────
         compat:
           # ★ 关键：DSH 默认对普通 OpenAI 兼容端点发送 developer 角色，
-          #   而 8 个模型中有 5 个直接拒绝（unknown role: developer）。
+          #   而 10 个模型中有 6 个直接拒绝——GLM-5.3-Flash、MiniCPM5-2B、
+          #   MiniCPM-V-4.7-1B 报 422 unknown role: developer，Qwen 系两个与
+          #   MiniCPM-V-4.7-35B-A3B 报 400 Unexpected message role。
           supportsDeveloperRole: false
           supportsReasoningEffort: true
           # Radeon 的网关只按白名单转发字段，thinking_budget /
@@ -87,11 +89,14 @@
           thinkingFormat: openai
 
         # ── 模型目录 ──────────────────────────────────────────────────
-        # 共收录 8 个对话模型。目录接口里还有 MinerU2.5-Pro，但它的
+        # 共收录 10 个对话模型。目录接口里还有 MinerU2.5-Pro，但它的
         # context_length 为 0、tools 为 false，走的是独立的 /v1/ocr
         # 文档识别端点而非对话接口，故不收录。
+        #
+        # 下面的分组按「档位表的形状」而非厂商划分——同一个厂商的模型档位
+        # 未必相同（MiniCPM 系即是如此），按厂商分组会把读者引向错误预期。
         models:
-          # ── DeepSeek 系：7 档全接受，`none` 可关闭思考 ──
+          # ── 全档接受：none 可关闭思考 ──
           - id: DeepSeek-V4.1-Flash
             name: DeepSeek-V4.1-Flash
             contextWindow: 1048576
@@ -144,6 +149,21 @@
               xhigh: xhigh
               max: max
 
+          # 同一个 MiniCPM 系里两个模型档位形状并不相同：35B-A3B 全档接受，
+          # 1B 只接受 low/medium/high。实测确认两者都返回分离的思考内容。
+          - id: MiniCPM-V-4.7-35B-A3B
+            name: MiniCPM-V-4.7-35B-A3B
+            contextWindow: 262144
+            input: [text, image]
+            reasoningEfforts:
+              off: none
+              minimal: minimal
+              low: low
+              medium: medium
+              high: high
+              xhigh: xhigh
+              max: max
+
           # ── Qwen 系：无 minimal/max/high，仅 none/low/medium/xhigh ──
           # 这两个模型唯一能关闭思考的方式是 none；传入 high 会返回 400。
           - id: Qwen3.8-27B
@@ -166,8 +186,8 @@
               medium: medium
               xhigh: xhigh
 
-          # ── GLM 系：不接受 none/minimal/xhigh/max ──
-          # 不声明 off 键：该模型没有「关闭思考」的档位。
+          # ── 仅 low/medium/high：不接受 none/minimal/xhigh/max ──
+          # 不声明 off 键：这两个模型没有「关闭思考」的档位。
           - id: GLM-5.3-Flash
             name: GLM-5.3-Flash
             contextWindow: 262144
@@ -177,9 +197,18 @@
               medium: medium
               high: high
 
+          - id: MiniCPM-V-4.7-1B
+            name: MiniCPM-V-4.7-1B
+            contextWindow: 262144
+            input: [text, image]
+            reasoningEfforts:
+              low: low
+              medium: medium
+              high: high
+
           # MiniCPM5-2B 接受 low/medium/high，但不返回分离的思考内容
-          # （思考字段恒为空）。给出档位控件会误导用户，
-          # 故显式声明为非推理模型。
+          # （实测 reasoning 恒为空、reasoning_tokens 为 0）。
+          # 给出档位控件会误导用户，故显式声明为非推理模型。
           - id: MiniCPM5-2B
             name: MiniCPM5-2B
             contextWindow: 131072

package/locale/en.json

@@ -0,0 +1,6 @@
+{
+  "meta": {
+    "title": "Radeon Cloud",
+    "description": "Unofficial Radeon Cloud provider: full reasoning-effort support, declared in the plugin's own patch layer with no profile writes."
+  }
+}

package/locale/zh.json

@@ -0,0 +1,6 @@
+{
+  "meta": {
+    "title": "Radeon Cloud 提供方",
+    "description": "非官方 Radeon Cloud 提供方：完整支持模型思考档位；provider 定义由插件自带的补丁层声明，不写用户 profile。"
+  }
+}

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@zhz8888/dsh-radeon-cloud-patcher",
-  "version": "1.2.0",
-  "description": "为 DeepSeek Harness 接入 AMD Radeon Cloud，完整支持模型思考（reasoning）功能。把 provider 定义按键合并进 profile，由 DSH 自带的 dsh-llm-pi-ai 承载，不修改 DSH 本体，也不自研适配器。",
+  "version": "1.3.0",
+  "description": "为 DeepSeek Harness 接入 AMD Radeon Cloud，完整支持模型思考（reasoning）功能。provider 定义由插件自带的补丁层声明，交由 DSH 自带的 dsh-llm-pi-ai 承载，不修改 DSH 本体、不写用户 profile，也不自研适配器。",
   "keywords": [
     "amd",
     "deepseek-harness",
@@ -34,6 +34,7 @@
     "./merge": "./src/merge.js",
     "./provider": "./provider/radeon-cloud.yml",
     "./client": "./client/client.js",
+    "./locale/*.json": "./locale/*.json",
     "./package.json": "./package.json"
   },
   "dsh": {
@@ -59,14 +60,16 @@
     "src",
     "client",
     "provider",
+    "locale",
     "scripts",
     "cordis.plugin.patch.yml",
     "LICENSE",
     "README.md"
   ],
   "scripts": {
-    "test": "node test/manifest.test.mjs && node test/merge.test.mjs && node test/patch-text.test.mjs && node test/ownership.test.mjs && node test/apply-guard.test.mjs && node test/patch-sync.test.mjs && node test/client-patch.test.mjs && node test/verify-reasoning.mjs",
+    "test": "node test/manifest.test.mjs && node test/plugin-meta.test.mjs && node test/merge.test.mjs && node test/patch-text.test.mjs && node test/ownership.test.mjs && node test/apply-guard.test.mjs && node test/patch-sync.test.mjs && node test/client-patch.test.mjs && node test/verify-reasoning.mjs",
     "test:manifest": "node test/manifest.test.mjs",
+    "test:meta": "node test/plugin-meta.test.mjs",
     "test:merge": "node test/merge.test.mjs && node test/patch-text.test.mjs && node test/ownership.test.mjs",
     "test:guard": "node test/apply-guard.test.mjs",
     "test:patch": "node test/patch-sync.test.mjs && node test/client-patch.test.mjs",

package/provider/radeon-cloud.yml

@@ -17,7 +17,7 @@ api: openai-completions
 baseURL: https://developer.amd.com.cn/radeon/api/v1
 displayName: Radeon Cloud
 
-# 默认思考档位。medium 在全部 8 个已收录模型上均被接受。
+# 默认思考档位。medium 在全部 10 个已收录模型上均被接受。
 reasoning: medium
 
 # Radeon 的思考与答案共用同一个 max_tokens 预算，预算不足时 content
@@ -44,7 +44,9 @@ retryPolicy:
 # ── 协议兼容开关 ──────────────────────────────────────────────
 compat:
   # ★ 关键：DSH 默认对普通 OpenAI 兼容端点发送 developer 角色，
-  #   而 8 个模型中有 5 个直接拒绝（unknown role: developer）。
+  #   而 10 个模型中有 6 个直接拒绝——GLM-5.3-Flash、MiniCPM5-2B、
+  #   MiniCPM-V-4.7-1B 报 422 unknown role: developer，Qwen 系两个与
+  #   MiniCPM-V-4.7-35B-A3B 报 400 Unexpected message role。
   supportsDeveloperRole: false
   supportsReasoningEffort: true
   # Radeon 的网关只按白名单转发字段，thinking_budget /
@@ -55,11 +57,14 @@ compat:
   thinkingFormat: openai
 
 # ── 模型目录 ──────────────────────────────────────────────────
-# 共收录 8 个对话模型。目录接口里还有 MinerU2.5-Pro，但它的
+# 共收录 10 个对话模型。目录接口里还有 MinerU2.5-Pro，但它的
 # context_length 为 0、tools 为 false，走的是独立的 /v1/ocr
 # 文档识别端点而非对话接口，故不收录。
+#
+# 下面的分组按「档位表的形状」而非厂商划分——同一个厂商的模型档位
+# 未必相同（MiniCPM 系即是如此），按厂商分组会把读者引向错误预期。
 models:
-  # ── DeepSeek 系：7 档全接受，`none` 可关闭思考 ──
+  # ── 全档接受：none 可关闭思考 ──
   - id: DeepSeek-V4.1-Flash
     name: DeepSeek-V4.1-Flash
     contextWindow: 1048576
@@ -112,6 +117,21 @@ models:
       xhigh: xhigh
       max: max
 
+  # 同一个 MiniCPM 系里两个模型档位形状并不相同：35B-A3B 全档接受，
+  # 1B 只接受 low/medium/high。实测确认两者都返回分离的思考内容。
+  - id: MiniCPM-V-4.7-35B-A3B
+    name: MiniCPM-V-4.7-35B-A3B
+    contextWindow: 262144
+    input: [text, image]
+    reasoningEfforts:
+      off: none
+      minimal: minimal
+      low: low
+      medium: medium
+      high: high
+      xhigh: xhigh
+      max: max
+
   # ── Qwen 系：无 minimal/max/high，仅 none/low/medium/xhigh ──
   # 这两个模型唯一能关闭思考的方式是 none；传入 high 会返回 400。
   - id: Qwen3.8-27B
@@ -134,8 +154,8 @@ models:
       medium: medium
       xhigh: xhigh
 
-  # ── GLM 系：不接受 none/minimal/xhigh/max ──
-  # 不声明 off 键：该模型没有「关闭思考」的档位。
+  # ── 仅 low/medium/high：不接受 none/minimal/xhigh/max ──
+  # 不声明 off 键：这两个模型没有「关闭思考」的档位。
   - id: GLM-5.3-Flash
     name: GLM-5.3-Flash
     contextWindow: 262144
@@ -145,9 +165,18 @@ models:
       medium: medium
       high: high
 
+  - id: MiniCPM-V-4.7-1B
+    name: MiniCPM-V-4.7-1B
+    contextWindow: 262144
+    input: [text, image]
+    reasoningEfforts:
+      low: low
+      medium: medium
+      high: high
+
   # MiniCPM5-2B 接受 low/medium/high，但不返回分离的思考内容
-  # （思考字段恒为空）。给出档位控件会误导用户，
-  # 故显式声明为非推理模型。
+  # （实测 reasoning 恒为空、reasoning_tokens 为 0）。
+  # 给出档位控件会误导用户，故显式声明为非推理模型。
   - id: MiniCPM5-2B
     name: MiniCPM5-2B
     contextWindow: 131072

package/scripts/probe-efforts.mjs

@@ -9,11 +9,14 @@
  *
  * 探测手法：对每个「模型 × 档位」组合发一次 max_tokens 为 1 的极小请求，
  * 只看 HTTP 状态码，200 即视为接受，不关心回复内容；这样单次探测的产出
- * token 成本可忽略。按每分钟 20 次的账户限流节流到约 19 次/分钟。
+ * token 成本可忽略。
  *
- * 注意：429 表示触发了限流，不代表该档位被拒绝，遇到时应单独复测确认。
+ * 只有 200 才是「接受」；400 与 422 才是「拒绝」。429（限流）与 5xx
+ * （上游偶发故障，README 记录过 504 被包装成 500）都不构成结论，本脚本会
+ * 自动重测，避免把「测不出来」写成档位表里的一个 ✗——那会让用户在选择器里
+ * 少一个本来可用的档位，且全程不产生任何报错。
  *
- * 用法: node scripts/probe-efforts.mjs [--only ModelId] [--tiers a,b,c]
+ * 用法: node scripts/probe-efforts.mjs [--only ModelId] [--tiers a,b,c] [--interval 毫秒]
  */
 import { execFile } from 'node:child_process'
 import { promisify } from 'node:util'
@@ -48,8 +51,22 @@ const only = argOf('--only')
 /** 只探测这些档位，逗号分隔；未指定时用 ALL_TIERS。 */
 const tiers = (argOf('--tiers') ?? ALL_TIERS.join(',')).split(',')
 
-/** 相邻两次请求之间的最小间隔，取 3100 毫秒约为每分钟 19 次。 */
-const MIN_INTERVAL_MS = 3100
+/** 相邻两次请求之间的默认最小间隔。
+ *
+ * 网关的账户限流是每分钟 20 次（响应头 x-ratelimit-limit-user-rpm）。原先取
+ * 3100 毫秒看似合规（≈19.4 次/分），但节流判据是「距上次请求满 3.1 秒」，
+ * 第 21 次请求会落在与第 1 次同一个滚动窗口内，实测必踩 429。取 4500 毫秒
+ * 把网关这一层躲开；上游自身仍会偶发限流，那由下面的重测兜住。 */
+const DEFAULT_INTERVAL_MS = 4500
+/** 相邻两次请求之间的最小间隔，可用 --interval 覆盖。 */
+const MIN_INTERVAL_MS = Number(argOf('--interval') ?? DEFAULT_INTERVAL_MS)
+/** 命中 429 后的冷却时长：服务端 Retry-After 为 60 秒，多留几秒余量。 */
+const RATE_LIMIT_COOLDOWN_MS = 65000
+/** 命中 5xx 后的重试间隔。上游偶发故障，等几秒再问通常就好了。 */
+const UPSTREAM_RETRY_DELAY_MS = 5000
+/** 单个「模型 × 档位」组合命中可重试错误后最多重测的次数。 */
+const MAX_RETRIES = 2
+
 /** 上一次请求发出的时间戳，用于计算需要等待多久。 */
 let lastAt = 0
 
@@ -73,6 +90,30 @@ async function throttle() {
  * @returns {Promise<{status: number, error?: string}>} HTTP 状态码；取不到时为 -1
  */
 async function call(model, effort) {
+  for (let attempt = 0; ; attempt += 1) {
+    const res = await once(model, effort)
+    // 429 是限流，5xx 是上游故障，两者都测不出该档位的真实结论。直接返回会把
+    // 「没测到」写成「不接受」，进而从档位表里删掉一个本来可用的档位，所以必须重测。
+    const delay = res.status === 429
+      ? RATE_LIMIT_COOLDOWN_MS
+      : res.status >= 500 ? UPSTREAM_RETRY_DELAY_MS : 0
+    if (delay === 0 || attempt >= MAX_RETRIES) return res
+    process.stderr.write(
+      `  ${model.padEnd(30)} ${effort.padEnd(9)} ${res.status} 非结论，`
+      + `${delay / 1000} 秒后重测（第 ${attempt + 1} 次）\n`,
+    )
+    await new Promise((r) => setTimeout(r, delay))
+  }
+}
+
+/**
+ * 发起一次探测请求，不做限流重试。
+ *
+ * @param {string} model 模型 id
+ * @param {string} effort reasoning_effort 取值
+ * @returns {Promise<{status: number, error?: string}>} HTTP 状态码；取不到时为 -1
+ */
+async function once(model, effort) {
   await throttle()
   // max_tokens 压到 1，让这次请求只为确认档位是否被接受，不产生实际产出。
   const body = JSON.stringify({
@@ -118,7 +159,8 @@ for (const model of models) {
   for (const effort of tiers) {
     const { status } = await call(model, effort)
     result[model][effort] = status
-    // 200 为接受；400 与 422 为档位不被接受；其余（429 等）需人工复测。
+    // 200 为接受；400 与 422 为档位不被接受；冷却重测后仍非这三者的
+    // （例如持续 429、5xx）说明这次没测出结论，须人工复测后手工入表。
     const mark = status === 200 ? '✓' : status === 400 ? '✗400' : status === 422 ? '✗422' : `?${status}`
     process.stderr.write(`  ${model.padEnd(30)} ${effort.padEnd(9)} ${mark}\n`)
   }

package/src/ownership.js

@@ -6,7 +6,7 @@
  * home 的 ~/.dsh/cordis.patch.yml、命令行 overlay 都排在 bundle 层之后，
  * 因此其中任何一条针对 llm-pi-ai 的 config 都会把插件层的定义整份盖掉。
  *
- * 三种结局必须被区分开，否则用户只会看到 provider 无声消失：
+ * 四种归属结局必须被区分开，否则用户只会看到 provider 无声消失：
  *
  *   plugin-layer  之后各层没碰 llm-pi-ai → 插件层的定义生效，一切正常；
  *   materialized  之后的层声明了同 id 定义，且与本插件定义一致 —— 这是设置页
@@ -16,12 +16,15 @@
  *   conflict      之后的层声明了同 id 定义但与本插件不一致 —— 用户自己维护了
  *                 一份同名 provider，插件拒绝接管（这是需求里的「id 冲突」）。
  *
+ * 另有哨兵 dynamic：config 是 !!js 表达式、或本次运行拿不到 profile 目录时，
+ * 静态判断不了谁生效，此时只告警并照常加载——「判不了」不等于「失败」。
+ *
  * 与 merge.js 的关系：merge.js 负责「把定义按键合并进 profile」这条补救路径，
  * 本模块负责「启动时判断谁在管理这个 id」。两者共用同一个 PROVIDER_KEY。
  */
 import { PROVIDER_KEY, TARGET_ENTRY_ID, deepEqual } from './merge.js'
 
-/** 所有权判定的四种结局。 */
+/** 所有权判定的四种归属结局，外加「判不了就跳过」的哨兵 dynamic。 */
 export const OWNERSHIP = {
   pluginLayer: 'plugin-layer',
   materialized: 'materialized',