dsh-fast-mode

dsh-fast-mode

思考强度不变，只给“能并行的读”提速。
有证据才并行，没证据就原生；不加请求字段、不改思考强度。

English

---

它到底做什么

一步的用时 = 往返开销 × 步数 + 解码时间 × 输出 token + 工具等待。模型和思考强度不在这个式子里，所以快模式只动三个程序量：

• 并行扇出：调度器先判断这一步是不是“多个互不依赖的读”，是才要宽（最多 8），并且跨轮记住这个形状；写操作、单调用、连续报错或无进展的回合保持原生 —— 整段批处理提示不渲染，不为它付输入 token。
• 输出纪律：只裁剪过程叙述（不预告、不复述、不写进度），最终答案完整保留。
• 卡顿看门狗：给 shell/脚本类调用设 120–300 秒自适应上限，卡住的调用被取消并把“换做法”写回上下文。

没有模型切换、没有 reasoningEffort 改写、没有请求字段注入；开着时模型输入里会多出本插件自己的调度提示与提醒（这是机制本身），关掉后连这些也不存在。DeepSeek 官方 API、OpenAI 兼容中转、自建网关、Anthropic 协议 —— 走哪条路由都成立。

先把三个词说清楚

• 墙钟（wall clock）：任务从发出到 headless 进程退出的端到端真实耗时，包含模型延迟、工具等待、插件开销。下文“X 秒”都是它。
• 速率：墙钟的倒数（1/墙钟）。墙钟从 10 s 降到 8 s，速率就是 1.25 倍。
• 加速比：关掉时的墙钟 ÷ 打开时的墙钟。大于 1 才是变快；1.28× 等于省 22 % 的时间，0.8× 等于慢了 25 %。95 % 区间（CI）跨过 1 就是“和没开分不出来”。

实测

打开小闪电，排头的一句结论：整任务总量约快 20 %，适合的场景快 25–39 %。 这是把所有有 off 锚的干净块一起加总的结果（7 个块、120 对有效配对、10 个任务家族，python3 bench/pool.py 可复算）：总墙钟 0.798×（省 20 %）、输出 token 0.806×、步数 0.800×、逐格中位 0.829×、120 对里 81 对更快。分任务看，收益集中在有多份产物、需要多轮复验的中长任务：codeimpl 0.608×（省 39 %，13 对 12 对更快）、stategraph 0.708×、migrate 0.748×、shellpipeline 0.749×；csvpipe 0.982× 打平；perfrefactor 1.077×、debugfix 1.245× 更慢——这两个都是 1–5 步、5k token 以内的小改修，没有可省的重复复验，提醒本身按「注入一次 ≈0.7 s」计价就收不回来。「整任务约快 26–28 %」已撤回：那个数字来自三个被挑出来的块（1.5.1 0.72×、W5 0.73×、W7 0.73×，合并 65 个有效单元 0.74×），样本扩大后合池回到 0.798×，所以对外只说 20 %，不再说 26–28 %。「典型一格约快 36 %」也已撤回（逐格中位 0.83×，收益集中在少数长格）。1.5.1 那一块自身仍是真实的：60 次运行、隐藏测试有效单元 29/29 全绿（另 1 个单元因会话启动崩溃作废，不是红灯）、单块总墙钟 0.72×（3434.7 s → 2472.5 s）、逐格中位 0.64×——它只是一块的记录，不是全池承诺。这是「不牺牲完成度和复验」换来的速度，再往下压就要开始省检查，本版不做。逐块、逐任务表与上限推导见 BENCHMARK.md 的「全量池化复核」。

1.5.0 的默认不做步数收尾。 finishLineSteps 与 stepBudget 默认都是 0：没有“第 10 步提醒收尾”，也没有“30 步停止”。结束由任务状态和完成证据决定 —— 同一份产物上逐字重复一条已通过的检查，建议复用结果、把这一步留给剩下的工作；连续几步没有新结果，建议换方法（只是提醒，不结束回合）；工具卡住，看门狗取消它并等它真正停下。任务做完就正常报告，提醒不会替你判停。

1.5.1 干净重基线（10 家族、30 个完整单元、隐藏测试 60/60 全绿）：不剔任何运行（只看产物里有没有泄漏标记）、按整任务总量加总 —— 关闭 3434.7 s / 591 244 token / 390 步；默认臂 0.72× 墙钟 / 0.74× 输出 / 0.71× 步数；逐格中位 0.64×、均值 0.84×、90 % 区间 [0.59, 0.79]。收益集中在反复重跑同一条检查的任务（migrate 0.45×、shellops 0.57×、codebase 0.55×、stategraph 0.64×、ledger 0.64×）；短任务收益不稳定，perfrefactor 1.18×、csvpipe 1.12×、debugfix 输出反而 2.01×——短任务本来就没有可省的重复验证，提醒本身也是成本。这一轮同时修掉了两个会让旧数字失真的测量缺陷（运行目录曾在仓库内、指标曾按字节偏移切片），旧口径的 0.86× 已撤回，详见 BENCHMARK.md 的「1.5.1」与「1.5.0 重基线（已撤回）」。 复现块 W5（2026-10-26，19 个完整单元）：同一块里三臂直接对照，off 1855.5 s，默认臂 0.73× 墙钟 / 0.77× 输出 / 0.89× 步数，与 1.5.1 的 0.72× 一致。同块的 batchVerify 臂记到 0.84×，但那一臂的提醒实际一次都没下发（20 个会话逐条检索命中 0），所以 batchVerify 是未测、不是变慢也不是被证伪，默认保持关闭、修复后重测。这一块还有 1 行泄漏（shellpipeline p1 的 bv15 读到隐藏测试与参考解），已点名剔除；跑批器现在开跑前会把 hidden/、ref/ 置为不可读，详见 BENCHMARK.md 的「复现块 W5」与 bench/README.md 协议第 12 条。 筛选块 W10 + 复现块 W11（2026-10-26，合并 23 个有效单元）：workspaceMap 只兑现一半，默认关闭。 1.5.2 加了一个默认关闭的旋钮：会话第一次动手前，把工作目录的清单（深度 2、≤60 条、跳过依赖与构建目录）先交给模型一次，省掉它自己 ls/find 的那一步。两块同块对照 def15：合并 23 个单元 墙钟 0.927×、输出 0.896×、步数 1.099×，逐格中位 0.791×、13/23 格更快、隐藏测试零红。方向被证实一半——输出确实少 10 %（两块分别是 0.90×、0.89×）；但步数反而多 10 %，而且尾部变差：两臂 p90 是 559 s 对 369 s、最慢 714 s 对 510 s，W10 与 W11 都出现同一形状的反向格（stategraph 两轮都 1.4×–1.77×）。按「长任务不能变慢」的门槛它不进默认，1.5.2 的默认行为与 1.5.1 完全相同，旋钮与数字一起公开。这一轮同时把余量算清了：重复验证只占 6 % 墙钟、工具结果中位 1.2 kB、重复写文件占 0.8 %，所以 0.67× 在「不动 reasoningEffort、不加请求字段」的约束内不可达，细节见 BENCHMARK.md 的「复现块 W11」与「0.67× 在现有约束下的可达性」。

复现块 W7（2026-10-26，17 个有效单元）：默认臂 0.73× 墙钟 / 0.75× 输出 / 0.59× 步数（最长一格 36 步 → 17 步），与 1.5.1 的 0.72×、W5 的 0.73× 一致：三块合并 65 个有效单元 0.74×。同块的 openBatch 是 0.91×，对默认头对头 1.136×，W6 的 0.77× 没有复现，淘汰。这一块还有 7 行运行崩溃（会话启动阶段 exit=1、1 步、0 输出），3 个单元因此作废并点名；从这一块起判据要求 exit == 0 && 步数 ≥ 1 && 输出 > 0 && 判分完成 && 未泄漏 才计数，所以「全绿」一律指有效单元全绿（1.5.1 29/29、W5 19/19、W7 17/17）。详见 BENCHMARK.md 的「复现块 W7」。

发版前复核（REL16，10 个单元）：用当时的默认再对 off 跑一块，只查「质量有没有被发版弄坏」。结果两臂 10/10 全绿、逐任务通过数完全相同（14/14、22/22、18/18、10/10、14/14），无 leak；墙钟合计 0.967×、逐格中位 0.999×、3/5 格更快。单对 n=5，噪声带比总量宽，所以这条只作复核，不替换合池 0.798× 的总口径，详见 BENCHMARK.md。

更快但没过门禁的配置只作消融臂。 fl10（第 10 步提醒收尾）是实测最快的配置，但它会压掉「测试通过后又改了代码」的必要复验，且出现过基线与默认都绿而它红的一格，所以只是消融臂（这些数字出自已撤回的批次，只保留决策记录）。openBatch（开局发一次「把独立调用并进同一块」）在 W6 筛查里以 0.77× 快过默认的 0.93×，但 W7 独立复测回到 0.91×、头对头 1.136×，没有复现即淘汰。batchVerify（改完一批文件再跑一次覆盖检查）在 W5 同块对照里记到 0.84×，但那一臂的提醒实际零下发，测到的不是机制本身，所以它算未测，默认保持关闭。所以默认不变：不按步数收尾、stepBudget: 0、上述机制全关。单元级数据与门禁逐条见 BENCHMARK 的 H2/H3。

已退役的默认：finishLineSteps: 10。 1.4.4 用它跑出 7 家族 14 对中位 1.86×、13/14 更快（符号检验 p = 0.002）、输出 −52 %、步数 −10.0、隐藏测试 14/14 全绿。这条线的速度是真的，代价也是真的：它到第 10 步就要求停止扩大范围，对仍在推进的长任务同样开火。所以 1.5.0 把它降级为消融臂（fl10），默认关闭。

诚实的历史边界：1.4.1 把样本从 5 对扩到 76 对后，1.4.0 的 1.86× 回落到中位 1.06×（45/76 对更快）—— 小样本倍数是噪声。短任务（1–5 步）没有可省的，收益随步数出现。

一句话结论：在已测的有限任务中观察到加速，未观察到这些隐藏断言上的退化。这不是对所有任务的普遍质量保证。

每个原始数字、步数分桶、被否掉的候选与失败模式：BENCHMARK.md。fixture、跑批器、汇总器与三块原始结果在 bench/，跑一遍 bench/report.py 就能打出同一组总量表、分家族表与门禁违规。

使用

1. 装（任选其一）：
   • npm（推荐）：插件管理器 → 安装 bundle，目标填 dsh-fast-mode；终端等价 pnpm add dsh-fast-mode --dir ~/.dsh/profiles/desktop。包页 https://www.npmjs.com/package/dsh-fast-mode。
   • GitHub：目标填 github:regrevia/dsh-fast-mode；终端等价 pnpm add github:regrevia/dsh-fast-mode --dir ~/.dsh/profiles/desktop。
   • 市场索引：插件 → 发现 → 索引源，添加 https://raw.githubusercontent.com/regrevia/dsh-fast-mode/main/market/index.json（format 1，已用宿主索引解析器验过）。精选列表 awesome-dsh-plugin 的收录 PR 是 #9650，合并后 dshmarket 与站点自动收录，不用手动加源。
2. 开：重载页面，点输入框旁的小闪电。没有档位要选。
3. 生效：下一条请求生效，不用重启、不用新开会话。

- insert:
    - id: fast-mode
      name: dsh-fast-mode
      config:
        enabled: true   # 装好默认关闭；这一行才是真正的开关

旧配置里的 fast / turbo / max / ludicrous 会被当作 auto 并打一条弃用日志，不会再动思考强度。

排错：如果本应在跑的任务被一条 Stop working now and report instead 强制收尾，说明装的是 1.1.0 或更早的版本——那版在「单轮 30 步」或「连续 12 步没有新产出」时无条件叫停。1.5.0 起默认没有任何按步数收尾的提醒：无进展只换方法，不结束回合；硬停只在你自己设了 stepBudget 时存在。升级到当前版本后重启一次即可（host 侧代码是启动时加载的）。

开关

闪电就是开关：开/关即写，按会话独立，重启按会话恢复。没有面板、没有下拉、没有倍数估算。

思路参考了 dsh-batch-tool-calls 与 dsh-ops（批量调用、有界执行），但它们的规则是静态的，这里的宽度来自会话自身的调用证据；不需要同时装。压缩类插件可以共存。

边界与下一步

判断“这一步值不值得提速”的可编程信号现在有三个：请求自身的措辞（串行/扇出/shell，见 src/shape.js）、上一步的调用是否全为只读且目标两两不同、以及连续只读步数。前两个让单轮任务第一步就能选对宽度。

在线选择（UCB/Thompson）不在这一版里，原因不是网络 —— bandit 全是本地算术，不额外发请求、不增加往返，实测代价可以忽略。真正的问题是奖励太吵：本项目 40 对配对里，同一任务两臂的方差远大于宽度带来的效应；把这种噪声喂给 UCB，学到的会是抖动而不是策略。等请求形状分类把“该宽的样本”筛出来、每步墙钟的方差降下来，再上 bandit 才有意义；设计上会用折扣 Thompson 采样（先验 N(0, σ²)，只对“扇出/未知”两类上下文分别维护宽度后验），而不是全局 UCB。

实测与复现 · 参考手册 · 改了什么 · English

许可

MIT。