dsh-fast-mode

DeepSeek Harness 自己的快速模式：用几项配置控制任务的运行速度。
默认不改模型、不改 reasoningEffort；用执行策略提示减少冗余回合与输出——收益来自步数与输出 token 下降，不是删旁白。唯一的例外是默认关闭的 `lazy`：过度思考时收一档，开关在你手里。

English

先看结论

在 10 类任务、30 个完整单元上（隐藏测试 60/60 全绿）：

• 默认配置（全池口径，不挑块）：12 个干净块、10 类任务、138 对有效配对的整任务总量 —— 总耗时 0.823×（省约 18 %）、输出 token 0.818×、步数 0.806×，138 对里 93 对更快（python3 bench/pool.py 可复算）。之前对外说的 0.72–0.74× 只来自挑出来的三块，已撤回，原因写在 BENCHMARK.md。
• 发布版复核（1.5.19，默认 vs 完全关闭）：migrate 5 对可用 0.688×（5/5 更快）、debugfix 7 对 0.770×（4/7 更快、几何被三格反向拉低但赢面更大），12 对合池 0.735×、逐格中位 0.708×、9/12 更快（bench/block_score.py 可复算）。1.5.19 减少了提示，这一轮就是用发布版确认「提示变少没把收益吃掉」；单块 n 小，对外仍只用上面的 138 对全池口径。
• 把「省着写」提醒从第 4 步提前到第 2 步：debugfix 0.535×（快约 47%）、ledger 0.506×（快约 49%）、migrate 0.751×；13 对合并 0.625×（快约 38%）、输出 token 0.614×（少约 39%）。再提前到第 3 步，migrate 单族 0.509×（快约 49%）、输出 token 0.528×（少约 47%）。
• 质量：上述每一对里两臂的隐藏断言逐格相同、全绿；快的是少做几遍「改一版→再读一遍→再改一版」，不是少验证。
• 不承诺的地方：1–5 步的小改修与数据整形收不回提醒成本（perfrefactor 1.18×、csvpipe 1.12×），所以按任务形状先试一次再定。

它到底做什么

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

• 并行扇出：调度器先判断这一步是不是“多个互不依赖的读”，是才要宽（最多 8），并且跨轮记住这个形状；写操作、单调用、连续报错或无进展的回合保持原生 —— 整段批处理提示不渲染，不为它付输入 token。
• 输出纪律：提示模型不预告调用、不复述结果、不写进度报告，但不缩短最终答案。口径要说清：实测里可见助手正文只占「正文+工具参数」字符的 1.19%（def15 全量 385 会话 / 3,659 消息 / 4,007 调用，正文 57,101 / 参数 4,757,921 字符；不含 reasoning 与工具返回；python3 bench/textshare.py --limit 0 可复算），所以提速不能归因于删旁白——它来自回合数与输出 token 变少（少重复编辑、少回头读、少验证往返），这和「内容不受影响」不是一回事。
• 卡顿看门狗：给 shell/脚本类调用设 120–300 秒自适应上限，卡住的调用被取消并把“换做法”写回上下文。

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

三条边界

• 明确承诺：不改模型、不注入请求字段、默认不改 reasoningEffort。打开 lazy 时它只降一档、从不升档、最低 low、每轮最多两次、下一个请求就从你的选择重新读起；降智风险最容易发生的地方，默认一个字段都不碰。
• 机制诚实：靠执行策略提示减少冗余回合与输出。证据是步数与输出 token 下降（全池默认臂 0.806× 步数、0.818× 输出）；不宣称收益来自「删旁白」。
• 质量边界：任务质量以隐藏测试判分与真实评测为准，不宣称行为完全等价。质量门槛不过就优先保质量：实验性旋钮默认关闭，默认配置只在两臂隐藏断言逐格相同的批次里采用。

先把三个词说清楚

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

实测

打开小闪电，排头的一句结论：整任务总量约快 18 %，适合的形状快 25–30 %。 这是把所有有 off 锚的干净块一起加总的结果（12 个块、138 对有效配对、10 类固定任务，python3 bench/pool.py 可复算）：总耗时 0.823×（省 18 %）、输出 token 0.818×、步数 0.806×、逐格中位 0.799×、138 对里 93 对更快（符号检验 p = 0.0001）。对这 138 对自助重抽 2000 次，总比 95 % 区间是 [0.742, 0.913]（即省 9 %–26 %），逐格中位区间 [0.703, 0.885]，几何均值 0.825×（区间 0.753–0.900；这是配对几何均值，与全池总量比 0.823× 是两种口径，不可互换）——「约 18 %」是点估计、不是下限承诺。质量的同口径结论只有一句：138 对里两臂隐藏断言逐格完全相同（off 2038/2038、默认 2037/2038，唯一差的是一格 21/22），这是断言对等，不是「零质量损失」。逐家族稳定性与符号检验见 BENCHMARK.md 的「合池的自助区间与逐任务稳定性」一节，那里也写了为什么逐家族数字不能跨块引用。

什么时候开、什么时候别开（按实测形状，不按任务名）。 开：有多份产物、要反复跑同一份检查的中长任务——codeimpl 0.663×（15 对里 13 对更快，符号检验 p = 0.007）、shellpipeline 0.749×（p = 0.039），stategraph 0.708×、shellops 0.748×、codebase 0.808×、migrate 0.822× 也在同一侧但样本撑不起单列结论。别开：1–5 步的小改修与数据整形——debugfix 1.032×（输出反而长 1.29×）、perfrefactor 1.009×，提醒本身的注入成本收不回来。ledger 0.915×、csvpipe 0.982× 打平，开不开都行。开关就是每会话的小闪电，默认记住上次选择，下一个请求生效。

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

1.5.1 干净重基线（10 家族、30 个完整单元、隐藏测试 60/60 全绿；这三块后来被认为挑块，只作历史记录，对外只用上面的全池 0.823×）：不剔任何运行（只看产物里有没有泄漏标记）、按整任务总量加总 —— 关闭 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 当时是未测、不是变慢也不是被证伪。后来修好接线重测，结论是淘汰：codeimpl 8 对几何 1.478×、shellpipeline 8 对 0.956×，合并 16 对 1.188×、中位 1.148×、只有 7/16 更快，全绿且提醒确实下发（8/16 会话命中）—— 所以不是没测到，是家族方向不一致、合起来更慢，默认保持 false，见 BENCHMARK.md 的「batchVerify 复测块 BV8」。这一块还有 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×，但那一臂的提醒零下发，当时只能算未测；接线修好后在 BV8 复测块实测 16 对合并 1.188× 更慢（codeimpl 1.478×、shellpipeline 0.956×，方向不一致），淘汰，默认保持 false。所以默认不变：不按步数收尾、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 侧代码是启动时加载的）。

开关

闪电就是开关：开/关即写，按会话独立，重启按会话恢复。右键闪电是一块六行的面板，六行都只影响当前会话：

• 更快：这个会话开不开快模式，和点闪电是同一件事。
• 少写过程：第 4 步那句「省着写」提醒的总开关，关掉后输出会变长、耗时变慢（长任务约 2.7×），默认开。
• 最多几步：15 / 30 / 不限，默认不限。到上限只先汇报，不截断任务。
• 先列文件清单：开启后，回合的第一次工具调用之前先收到一份工作目录清单（相对路径 + 字节数 + 可见的测试入口），省掉开头的 ls/find 探路。默认关；23 个配对实测几何 0.927×，尾部变慢、步数 +10%，没有达到进默认的门槛，只作为可试的开关。
• 一次读多个文件：把互不依赖的读取合成一批发出，少几个来回。默认关；单独开测不到显著，和上一项一起开才有（见下）。
• 过度思考时降档（lazy）：一轮里思考文字明显超量时，先给一次"先找最省的一级、不扩范围、不砍校验"的提示，再把下一个请求的思考强度降一档。默认关；它动的是答案而不只是时延。

六项都写在本会话的条目里，对下一个回合生效；另一个会话开不开、写成什么样，互不影响。没有下拉，没有倍数估算。

几个一起开会不会更快？ 会，但只有实测过的那几个。默认 + workspaceMap + openBatch 两开：11 对 0.742×；再把 disciplineAfterSteps 提前到 2（面板里没有这一项，属于 HOLD 的时点实验）三开：22 对 0.669×、CI95 [0.554, 0.799]、18/22 更快、隐藏测试全绿。单独开其中任何一个都测不到显著（0.80–0.88，置信区间全跨 1）——所以增益来自它们各自省掉的是同一类成本的不同份，不是哪个开关本身。其余开关（batchVerify、preferPatch、步数预算、更宽并行）叠上去都是 0.96–1.10，没有理由跟着一起开。细节见 BENCHMARK.md 的「直接跑一次多个开关一起开」。

lazy 不与上面这些同口径：它动的是答案而不只是时延，所以哪怕测出来更快（LZ1：12 对里 11 对更快，逐对几何 0.39–0.43×，判分 216/216 全绿）也仍然默认关闭，不进任何默认组合。纯提示臂（lazyEffort: false）的读数同样在 BENCHMARK.md 的 LZ1 块。

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

边界与下一步

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

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

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

许可

MIT。