dsh-deepseek-web-login 0.6.3 → 0.6.5

package/CHANGELOG.md

@@ -2,6 +2,60 @@
 
 本项目遵循大致语义化版本；日期为本地时间。
 
+## 0.6.5 — 2026-09-27
+
+> 修复 0.6.3 的重试策略**形状**错误：它会让「按本地退避重试」算出 `NaN`，把整轮打成 UNKNOWN 错误。
+
+### 修复
+
+- **`providerRetryPolicy` 的返回值改成扁平字段**（0.6.3 包了一层 `backoff`）。dsh-llm 的取法是
+  `adapter.providerRetryPolicy(p) ?? resolveRetryPolicy(…)` —— 我们一返回对象，右侧那个"会把 `backoff`
+  展开成扁平字段"的规范化就**不会执行**，而运行期的消费方读的正是扁平字段
+  （`policy.initialDelayMs / maxDelayMs / jitterRatio`）。实测 DSH 会话日志里 `llm/retry` 事件的
+
+  ```
+  "policyKey":"[\"normal\",5,[\"EMPTY_RESPONSE\",\"RATE_LIMIT\",…],null,null,null]"
+  ```
+
+  后三项是 `null` = `undefined` —— 两个后果，第二个是致命的：
+
+  1. `providerRetryAfterMs > maxDelayMs` 变成 `X > undefined` = **恒 false** ⇒「要等太久就放弃」失效
+     （连封禁一天的解除时间也会被照单等下去）；
+  2. 失败**不带** provider 延迟时（例如 `EMPTY_RESPONSE`）走本地退避 `initialDelayMs * 2**n`，
+     `undefined` ⇒ **`NaN`** ⇒ DSH 写会话事件时拒收非有限数 ⇒ 整轮以
+     `UNKNOWN: session event "llm/retry" carries non-JSON-serializable data` 结束。
+
+     实测 2026-09-27 17:33:51：一轮里第一次重试（限流，带 2s）正常成功；第二次重试
+     （`EMPTY_RESPONSE`，无 provider 延迟）触发该错误 ⇒ 现象就是"任务突然自己停了"。
+
+### 测试
+
+- `check-llm-retry.mjs` 补四条**意图级**断言：策略扁平键齐全且**无 `backoff` 嵌套**、
+  **回放 DSH 的 `retryPolicyKey` 不许出现 `null`**、**回放 `localDelay` 必须算出有限正数**、
+  超长解除时间仍须被判「等太久」而放弃。
+- 反向验证 3 步全部如期红：改回嵌套 → 6 条红；`maxDelayMs` 调小到 10s → 2 条；抽掉 `initialDelayMs` → 4 条。
+
+## 0.6.4 — 2026-09-27
+
+> 文档版本：把「封号归因」那一节带到 npm 包页面上（纯文档，**无代码改动**）。
+
+### 文档
+
+- README（中/英）新增 **「关于『装了这个插件之后封号了』」**，放在「免责声明」之前：
+  把上下文里各部分的量级摆出来，再给自查顺序。
+
+  | 来源 | 量级 | 由谁决定 |
+  |---|---|---|
+  | 本插件协议指令 | **3,045 字符 ≈ 950 token** | 本插件（多个版本未变） |
+  | 工具目录 | 0.6.2 起长尾压成一行，同口径 **-50%** | 你装了多少工具插件 |
+  | `~/.dsh/prompt-inject.md` + `AGENTS.md` | **49,185 字节 ≈ 1.2 万 token（协议的 16 倍）** | 你的全局注入 |
+
+  另附维护者实测：连续 5 天无封禁；单日 178 次请求中 6 次限流、全部在退避后自动恢复。
+
+### 说明
+
+- 仅为让 npm 包页面的 README 与仓库同步；代码与产物逻辑与 0.6.3 一致。
+
 ## 0.6.3 — 2026-09-27
 
 > 限流之后**任务自己接下去**，不用再手点「继续」。

package/README.en.md

@@ -472,6 +472,48 @@ but only when the array itself is closed (a truncated stream must never be repai
 and an unparsable protocol block is never emitted as answer text again: with no other text in the step it
 reports a retryable `EMPTY_RESPONSE`, otherwise it appends a one-line notice and logs the raw block.
 
+## On "your plugin got my account banned"
+
+This attribution shows up from time to time. Before blaming the plugin, compare the **sizes** of what actually
+goes into your context.
+
+**What this plugin contributes**
+
+| Source | Size | Decided by |
+|---|---|---|
+| Tool protocol instructions (text written by this plugin) | **3,045 chars ≈ 950 tokens** | this plugin; unchanged for many versions |
+| Tool catalog (rendered by this plugin; content comes from the tools DSH hands over) | long-tail tools collapsed to one line since 0.6.2 — measured **-50%** like-for-like | **how many tool plugins you installed** |
+| Above + system header, in a 61-tool setup | ~64k chars ≈ 16k tokens | the bulk is the tool catalog, not the protocol |
+
+So the part that can fairly be blamed on this plugin is **those 3,000 characters**.
+
+**What actually inflates the context**
+
+- **MCP servers** — each one puts its whole tool schema into the context, on **every turn**
+- **Skills** — the more you install, the thicker the system prompt
+- **Jailbreak / "armor-breaking" prompts** — routinely tens of thousands of tokens, and they stay in context
+- **Global injection files** — `~/.dsh/prompt-inject.md` (41 KB on our machine) + `~/.dsh/AGENTS.md` (7 KB),
+  sent **in full, every turn** ≈ 49 KB ≈ 12k tokens, i.e. **16×** this plugin's protocol text
+
+A bigger context means heavier requests per turn, which makes volume/density heuristics more likely to trip.
+**That part has nothing to do with this plugin, and this plugin cannot control it.**
+
+**Maintainer's own experience (reference, not a guarantee)**
+
+Five consecutive days of daily use (including tool-call-heavy sessions) with **no ban**; of 178 requests in one
+day, 6 hit the web endpoint's "too frequent" throttle and all recovered after backoff.
+The distinction matters: **throttling is routine and recovers; a ban is a different thing.**
+
+**If you suspect you got hit, check in this order**
+
+1. Count your MCP servers and skills — every line is visible in `~/.dsh/profiles/desktop/cordis.patch.yml`
+2. `wc -c ~/.dsh/prompt-inject.md ~/.dsh/AGENTS.md` — see how large those two files are
+3. Open the "Token usage" tab and look at per-turn input (our median is around 100k tokens; the tool catalog is a small slice)
+4. Disable the MCP servers / plugin lines you do not use (`- id: xxx` + `disabled: true`, takes effect after restart)
+
+Everything this plugin can do about the risk (gating request density, serializing tool calls, session cleanup,
+slimming the tool catalog) is documented in the sections above. **The rest has to come from your own context.**
+
 ## Disclaimer
 
 > ⚠️ **Unofficial.** Not affiliated with, endorsed by, or sponsored by DeepSeek. "DeepSeek" is a trademark of its owner.

package/README.md

@@ -643,6 +643,46 @@ DSH Desktop 用的是 `desktop` profile，而注入器的 junction 默认建在
 
 同时感谢 DeepSeek Harness 生态与 [dsh-super-injector](https://github.com/yjh051108/dsh-super-injector)（运行时注入 / 侧挂开发链路）。
 
+## 关于「装了这个插件之后封号了」
+
+这个归因在群里出现过几次。先把**上下文的各部分量级**摆出来，再判断该怪谁。
+
+**本插件这一侧到底占多少**
+
+| 来源 | 量级 | 由谁决定 |
+|---|---|---|
+| 工具协议指令（本插件自己写的文本） | **3,045 字符 ≈ 950 token** | 本插件，多个版本未变 |
+| 工具目录（本插件负责渲染，内容来自 DSH 下发的工具） | 0.6.2 起长尾工具压成一行，同口径实测 **-50%** | **你装了多少工具插件** |
+| 以上 + system 头合计（61 个工具的环境） | 约 6.4 万字符 ≈ 1.6 万 token | 大头是工具目录，不是协议 |
+
+**能记在本插件账上的，只有那 3,000 字符。**
+
+**真正把上下文撑大的，通常是别的东西**
+
+- **MCP 服务器**：每接一个，它的工具 schema 就整份进上下文，而且是**每一轮**都在
+- **Skills**：装得越多，system prompt 越厚
+- **越狱 / 破甲类提示词**：这类文本动辄上万 token，且会一直留在上下文里
+- **全局注入文件**：`~/.dsh/prompt-inject.md`（本机实测 41 KB）+ `~/.dsh/AGENTS.md`（7 KB）
+  —— 这两个文件是**每轮整份**进 system prompt 的，合计约 49 KB ≈ 1.2 万 token，
+  是本插件协议文本的 **16 倍**
+
+上下文越大 ⇒ 每轮请求越重 ⇒ 越容易撞上风控的体量与密度判定。**这部分与本插件无关，本插件也管不到。**
+
+**维护者本机实测（供参考，不是担保）**
+
+连续 5 天日常使用（含工具调用密集的会话）**未被封禁**；单日台账 178 次请求里有 6 次「网页版限流」，
+全部在退避后自动恢复。区别很重要：**限流是常态、可自动恢复；封禁是另一回事。**
+
+**怀疑自己中招，按这个顺序自查**
+
+1. 数一下装了哪些 MCP 服务器、哪些 skill —— `~/.dsh/profiles/desktop/cordis.patch.yml` 里逐行可见
+2. `wc -c ~/.dsh/prompt-inject.md ~/.dsh/AGENTS.md` —— 看这两个文件的体积
+3. 打开设置页的「Token 统计」，看单轮输入量级（本机中位数在 10 万 token 上下，工具目录只占其中一小块）
+4. 把用不到的 MCP / 插件行禁用掉（`- id: xxx` + `disabled: true`，重启生效），再观察
+
+本插件能做的（压密度、串行工具调用、会话清理、长尾工具瘦身）都写在上面「请求节流」等章节里；
+**剩下的大头，只能从你自己的上下文里省。**
+
 ## 免责声明
 
 > ⚠️ **非官方项目**：与 DeepSeek 无任何关联，未获其授权、认可或赞助。"DeepSeek" 为其权利人商标。

package/lib/index.js

@@ -1566,7 +1566,7 @@ const THROTTLE_JITTER_RATIO = .3;
 /**
 * 我们**可能**上报给调用方（`dsh-llm-retry`）的**最大**限流退避。
 *
-* 🔴 它必须 ≤ 适配器声明的 `providerRetryPolicy().backoff.maxDelayMs`（见 `adapter.ts`）：
+* 🔴 它必须 ≤ 适配器声明的 `providerRetryPolicy().maxDelayMs`（**扁平字段**，见 `adapter.ts`）：
 * dsh-llm 的重试策略在 normal 模式下，一旦「提供方要的延迟 > maxDelayMs」就**直接放弃重试**
 * （`return next()`），整轮随即以 error 结束 —— 表现就是"任务停在限流上，要用户手点继续"。
 *
@@ -5784,13 +5784,41 @@ function allowsAutoContinue(purpose) {
 * 声明之后：提供方要的延迟 ≤ `maxDelayMs` 会被**照单等待并重试**（同一个打开的轮次里重跑
 * 失败步骤，历史保持一致），任务自己接下去 —— 重发时"自动换号"的检查点还会换上可用账号。
 *
+* ---
+*
+* 🔴🔴 **形状必须是「扁平」的，不能包一层 `backoff`**（0.6.3 就栽在这上面，0.6.5 修）：
+*
+* dsh-llm 的取法是 `adapter.providerRetryPolicy(provider) ?? resolveRetryPolicy(undefined, …)`
+* —— 我们一返回对象，右边的 `resolveRetryPolicy` **就不会执行**，也就**没人把
+* `backoff: {…}` 展开成扁平字段**。而运行期的消费方（`dsh-llm-retry`）读的是扁平字段：
+*
+*   ```js
+*   retryPolicyKey(policy)  → [policy.mode, policy.maxRetries, […], policy.initialDelayMs,
+*                              policy.maxDelayMs, policy.jitterRatio]
+*   localDelay(config, …)   → config.initialDelayMs / config.maxDelayMs / config.jitterRatio
+*   ```
+*
+* 写成嵌套时的实况（DSH 会话日志里 `llm/retry` 事件的 `policyKey`）：
+*   `["normal",5,[…],null,null,null]` ← 后三项全是 null，即三个字段 **undefined**
+* ⇒ 两个后果，第二个是致命的：
+*   ① `providerRetryAfterMs > maxDelayMs` 变成 `2000 > undefined` = false ⇒ **"要不要放弃"这条
+*      判断彻底失效**（长封禁的解除时间也会被照单等下去）；
+*   ② 失败**不带** provider 延迟时走 `localDelay()`，`initialDelayMs * 2**n` = `NaN`
+*      ⇒ `delayMs: NaN` ⇒ DSH 写会话事件时校验拒收（`walkJsonValue` 拒绝非有限数）
+*      ⇒ 整轮以 **`UNKNOWN: session event "llm/retry" carries non-JSON-serializable data`** 死掉。
+*      实测 2026-09-27 17:33:51（用户以为是"模型自己停了"）。
+*
+* ⇒ 结论：**要么返回扁平策略（本实现），要么干脆返回 `undefined` 走 dsh-llm 自己的默认策略**
+* （`resolveRetryPolicy` 会替我们规范化）。半吊子的中间形态最危险。
+* `tests/check-llm-retry.mjs` 守这条：断言扁平键齐全、无 `backoff` 嵌套、且 `localDelay` 算得出有限值。
+*
 * 取值理由：
 * - `initialDelayMs` = `FAILOVER_RETRY_MS`：本地退避起点与"能换号"那条路一致；
 * - `maxDelayMs` = `MAX_THROTTLE_RETRY_MS`（117s）：**必须 ≥ 我们可能上报的最大退避**，
 *   否则又回到"要等太久 ⇒ 放弃"。`tests/check-llm-retry.mjs` 守这个不变量；
 * - `maxRetries` = 5（与 dsh-llm 默认一致）：**有界** —— 避免账号真被封时无限打请求。
 *   想更激进可以调大，或改 `mode: 'always'`（无尝试上限）；那会在坏账号上一直重试，默认不开；
-* - `retryableCodes` 与 dsh-llm 默认一致（含 `RATE_LIMIT`）—— 我们只抛这几个码。
+* - `retryableCodes` 与 dsh-llm 默认一致（含 `RATE_LIMIT`、`EMPTY_RESPONSE`）—— 我们只抛这几个码。
 */
 const RETRY_POLICY = Object.freeze({
 	mode: "normal",
@@ -5802,11 +5830,9 @@ const RETRY_POLICY = Object.freeze({
 		"TIMEOUT",
 		"TRANSPORT"
 	]),
-	backoff: Object.freeze({
-		initialDelayMs: FAILOVER_RETRY_MS,
-		maxDelayMs: MAX_THROTTLE_RETRY_MS,
-		jitterRatio: .2
-	})
+	initialDelayMs: FAILOVER_RETRY_MS,
+	maxDelayMs: MAX_THROTTLE_RETRY_MS,
+	jitterRatio: .2
 });
 /** 构造 deepseek-web 适配器（鸭子类型满足 LlmAdapter 契约，无需继承）。 */
 function createAdapter(deps) {
@@ -8994,7 +9020,7 @@ async function checkForUpdate(current, fetchImpl) {
 * 兜底常量与 package.json 的一致性由 `tests/check-smoke.mjs` 守着，不会漂。
 */
 /** 与 package.json 保持一致的兜底版本（由测试保证不会漂）。 */
-const FALLBACK_VERSION = "0.6.3";
+const FALLBACK_VERSION = "0.6.5";
 let cached;
 /** 本插件版本（如 `0.1.26`）。 */
 function pluginVersion() {