dsh-approval-latency
告知模型工具调用因等待人工审批而耗时较长，避免将延迟响应误认为代码故障 · 审批等太久时自动回传「这是人类延迟，不是代码有问题」，设置页可切换自适应 / 固定时长
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:UPxianyu/dsh-approval-latency#991cb3ce8be10aa7001999430a4dd26905a9f2e2Approval Latency 以 dsh-approval-latency 发布，当前版本为 0.5.1。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
把「这次工具调用在等人类点审批」这件事回传给模型：
一次调用卡在审批上等了 6 分 42 秒才被放行时，模型在下一轮会收到一条上下文消息， 说明那段空档是人的响应延迟，不是工具报错、不是超时、也不是它上一轮的代码有问题—— 因此不必因为「时间过了很久」去重新排查已经正确的东西。
English · MIT · 纯 host 侧，无网络、无文件访问、不改任何审批结果 · 仓库 https://github.com/UPxianyu/dsh-approval-latency
DSH 的运行时上下文里有一行：
Elapsed since the preceding model-visible message: 6m 42s
（来自 @deepseek-ai/dsh-time-context。）它算的是墙上时间，但模型看到的只有两个数字：
「上一条消息」和「现在」。审批是唯一会让这个数字突然变大的日常路径——你去开会、去倒水、
去回别人消息，回来才点了「允许一次」。
于是模型面对的是这样的推理岔路：
| 模型看到的 | 常见的错误结论 |
|---|---|
| 工具结果正常返回，但中间空了 7 分钟 | 「刚才那条命令是不是卡住了 / 环境不稳定」 |
| 工具被拒绝，而拒绝出现在 9 分钟后 | 「我的改法不对，用户否掉了，我重写一版」 |
| 两个文件都改完，但两步之间各空了几分钟 | 「前面那些改动可能没生效，重新验证一遍」 |
这三条都会烧掉注意力，而且都建立在一个并不存在的因果上：时间 ≠ 结果。 审批的等待时间属于「人」这一侧，跟工具、代码、参数、沙箱都没有关系。
本插件把那句话补上：等待超过阈值时，在该步骤的工具结果之后追加一条上下文消息， 明确说清「这段空档是审批等待」。模型不需要猜，也不需要再从时间戳反推。
「太长」不是常量，是先量出来的：门槛默认由本机最近回答过的审批耗时决定（见第 4 节）。 下表的「门槛」指生效的那个数，不是写死的 30 秒。
| 情形 | 结果 |
|---|---|
| 调用需要审批，等待 ≥ 通过门槛，最终通过 | 追加一条提示：等了多久、是人的响应时间、不要因此重开前面的工作 |
| 等待 ≥ 拒绝门槛（默认是通过门槛的一半），最终被拒绝 | 追加一条提示：等了多久、这么久之后的「否」可能是过期/误触，若与用户要求不符应先问再改 |
| 等待 ≥ 通过门槛，最终取消 / 无人应答 | 追加一条提示：这一枪没打响，空档不代表调用或代码有问题 |
| 等待 < 对应门槛 | 什么都不加（正常人点审批的速度不该产生噪音） |
| 该调用没有经过审批 | 什么都不加 |
reportDenials: false | 只回报「通过」的等待，拒绝/取消的不回报 |
提示不会改写工具结果本身（审计里 tool/result 仍是工具自己的输出），而是作为一条
notice 形式的用户消息，紧随本步骤的工具结果进入下一轮请求。
值得开的四种情形
不需要它的情形
never 策略（审批被确定性拒绝）——没有等待，也就没有通知。2026-10-18 的实测：把一次 pwsh 调用挂起 9 分 8 秒后才批准。模型在这一步实际收到的两条信息：
[tool/result] marker read back: Synthetic approval test at 2026-10-18T14:30:34+08:00
directory removed again: True
[user/message, source.kind = approval-latency]
Approval wait: "pwsh" ran 9m 8s after the user approved it — human latency, not a tool failure,
and not evidence about earlier work. Judge only this result.
同一时刻，运行时上下文里的耗时行是这个：
Elapsed since the preceding step context: unavailable.
也就是：没有这条通知，模型完全不知道中间过了 9 分钟。 这不是个例——从本机 6 个会话日志、
32 次审批里统计，工具步骤之后（step ≥ 2）的 elapsed 全部是 unavailable，
带数字的只出现在两条用户消息之间。所以在这台机器上，这条通知是唯一的时间归因来源，
成本 156 字符 ≈ 41 token。
它也确实进了会话日志，能回放：
seq 3217 user/message source = {"kind":"approval-latency","form":"notice",
"summary":"approval wait 9m 8s before pwsh ran"}
另一类更早的真实事故没有日志可查：跑 ComfyUI 出图时模型思考跑偏，只能强行终止。 当时既没有时间线索、也没有「这个否可能是过期的」语义，模型只能自己编原因——这正是本插件要堵的洞。
每条都是一行、三件事：等了多久 → 这是人的延迟而不是失败/代码问题 → 只判这次结果。 解释性从句全部砍掉：一段「关于时间的说明」本身就在邀请模型讨论时间，而这正是要避免的跑偏，还白付一倍 token。
通过（154 字符 ≈ 41 token）：
Approval wait: "bash" ran 2m 8s after the user approved it — human latency, not a tool failure,
and not evidence about earlier work. Judge only this result.
拒绝（154 字符 ≈ 41 token；注意这里没有「先去问用户」，只陈述事实）：
Approval wait: the user rejected "write" after 4m 10s. A "no" that late may be stale rather than
a verdict on your approach — check it against what was asked.
取消 / 无人应答（127 / 116 字符 ≈ 33 / 31 token）：
Approval wait: "pwsh" stayed unapproved for 1m 0s and was cancelled, so it never ran.
Human latency, not evidence about the code.
长度预算是硬约束：
test/latency.test.mjs断言四种变体分别不超过 200 / 200 / 170 / 170 字符， 且不超过 3 句、必须以Approval wait:开头——防止以后越写越长。 answer, so the call never ran. That gap is human or scheduling latency — not evidence about the call or the code it touches.
## 3. 安装
在 DSH 里（profile 名换成你自己的，桌面版默认 `desktop`）：
```sh
dsh plugin --profile desktop add /path/to/dsh-approval-latency
或从仓库：
dsh plugin --profile desktop add github:UPxianyu/dsh-approval-latency
装完重启 dsh web（或桌面版），插件随 profile 的 cordis.patch.yml 插入
approval-latency 这一行即可生效。
卸载：
dsh plugin --profile desktop remove dsh-approval-latency
插件管理不在设置对话框里，它是主界面左侧「全局面板图标」里的一个面板（图标是风车，tooltip「插件」； 设置里的「内置插件」是只读清单）。路径：
左侧风车图标「插件」→「已安装」→ dsh-approval-latency 卡片 → 点带 › 的那一行标题
（显示为 审批等待回传（Approval Wait Notice） ›，它的无障碍名就是「配置 审批等待回传（Approval Wait Notice）」）
那一行标题之所以是可点的按钮（带 ›），正是因为本插件为这一行注册了配置页；
没有注册页的行只是纯文本、没有箭头。
| 控件 | 作用 |
|---|---|
| 自适应 开关 | 开（默认）：门槛跟着你回答审批的速度走（见 4.2）。关：用下面的固定时长。 |
| 固定时长 输入框 | 秒数，默认 30。回车或失焦才写入；填 0 / 非数字会被拦下并提示，不会写进配置。 |
| 恢复默认 | 清掉本页写入的覆盖，回落到本 bundle 的默认值（30 秒 / 自适应）。 |
写进去的值由 Host 落到 profile 的 Cordis patch（与手改 YAML 同一层），不需要重启：
这些字段是 volatile 的，改完从下一次审批开始生效。页面上的「已覆盖」徽标表示这一项有页面写入。
页面上看不到「当前学到的基线是多少」——那是宿主内存里的数，只写进 debug 日志； 页面只负责改配置（延迟、体积、侵入性都最小的那一半）。
这一节是同一份配置的 YAML 写法（适合脚本化、团队统一、CI）。两种模式都能在设置页里切换（见 3.1）， 定义与算法完全相同。
改配置就在 profile 的 cordis.patch.yml 里用同 id 覆盖（同 id 覆盖会整块替换
config，所以只写你要改的字段，其余回落到默认值）：
| 你写的 | 生效 |
|---|---|
| 什么都不写 | mode: auto（自适应） |
mode: auto | 自适应，用本机速度；fixedMs 不参与 |
mode: fixed | 固定 fixedMs，默认 30000（30 秒） |
只写 fixedMs: 45000 | 自动当成 mode: fixed（填了数，数字就该生效） |
只写 thresholdMs: 45000（0.2.0 的旧写法） | 同上，按别名处理，仍然可用 |
mode 显式写了就听它的：mode: auto 同时给 fixedMs 不算冲突，只是那个数用不上
（和 mode: fixed 下 floorMs 用不上是一个道理）。
# profile/cordis.patch.yml
- id: approval-latency
name: dsh-approval-latency
config:
mode: fixed # 不写 fixedMs 就用默认 30000 = 30 秒
- id: approval-latency
name: dsh-approval-latency
config:
mode: fixed
fixedMs: 45000 # 45 秒
默认为什么是 30 秒：低于 30 秒基本还是正常点击速度，提醒只会变成噪音；到 30 秒以上，
模型那行 Elapsed since the preceding model-visible message 已经大到足以让它怀疑自己，
这时一条「这是审批延迟」最值钱。宁可少提醒，也别让提醒变成背景音。
通过门槛 = clamp( multiplier × median(最近 20 次真实回答的耗时), floorMs, ceilingMs )
allowed-once 与 rejected。取消、无人应答不算，
因为它们不代表你回答得慢。ceilingMs：一次出门三小时不会把基线拽走。minSamples（默认 3）时用 30 秒冷启动值——30s 只是「还没有数据时」的占位，
不是永恒的门槛。floorMs（默认 10s）保证再灵敏也不会为「点得挺快」打扰；ceilingMs（默认 5min）
保证基线不会漂到永远不触发。举例：你平时 4 秒点掉审批 → 门槛 12 秒；某天你一直 90 秒才点 → 门槛自动抬到 5 分钟（上限）。 换台机器、换个人，就是另一套数——因为这个数字本来就该是「对谁而言」。
拒绝门槛 = clamp( 通过门槛 × rejectionScale, min(floorMs, 通过门槛), 通过门槛 )
迟到的「否」是最贵的误解（模型会去重写代码），所以默认用一半的门槛先提醒一次；
设 rejectionScale: 1 就与通过同门槛。取消 / 无人应答仍用通过门槛，因为那本来就不是一次判断。
reportDenials: false 只回传通过的等待。
本 bundle 的 patch 已写入全部默认值：
- id: approval-latency
name: dsh-approval-latency
config:
mode: auto # auto = 自适应；fixed = 固定 fixedMs
fixedMs: 30000 # fixed 模式的固定时长（毫秒）；不写 mode 时填了它即按 fixed
floorMs: 10000 # auto：门槛下限
ceilingMs: 300000 # auto：门槛上限，也是单条样本的截断值
multiplier: 3 # auto：几倍本机中位数算「异常长」
minSamples: 3 # auto：攒够几条真实回答才从冷启动切到学习值
rejectionScale: 0.5 # 拒绝门槛 = 通过门槛 × 该系数，范围 (0, 1]
reportDenials: true # 是否也回传拒绝 / 取消 / 无人应答
| 字段 | 默认值 | 含义 |
|---|---|---|
mode | auto | auto 学习本机速度；fixed 永远用 fixedMs。 |
fixedMs | 30000 | 固定模式的门槛（毫秒）。0 表示每次审批都回传（调试用）。 |
floorMs | 10000 | 自适应门槛下限：低于它的等待永不打扰。 |
ceilingMs | 300000 | 自适应门槛上限，同时截断单条样本。 |
multiplier | 3 | 「异常长」= 多少倍本机中位数。越小越敏感。 |
minSamples | 3 | 攒够多少条真实回答才从冷启动切到学习值。 |
rejectionScale | 0.5 | 拒绝门槛 = 通过门槛 × 该系数，范围 (0, 1]。 |
reportDenials | true | 是否也回传「等到最后被拒绝 / 取消 / 无人应答」。 |
thresholdMs | — | 已弃用：fixedMs 的别名，写了即等于 mode: fixed。 |
| 想要 | 改什么 |
|---|---|
| 稳定可预测，不看历史 | mode: fixed（默认 30 秒）或 mode: fixed + fixedMs |
| 更敏感（离开 10 秒就提醒） | floorMs: 5000、multiplier: 2 |
| 更安静（只在明显离开时提醒） | multiplier: 5、ceilingMs: 600000 |
| 只拦「真的离开了」 | mode: fixed + fixedMs: 120000（2 分钟） |
| 拒绝别那么吵 | rejectionScale: 1 或 reportDenials: false |
| 刚装上看效果 | mode: fixed、fixedMs: 0（每条审批都回传） |
按实测校准：从本机 6 个会话日志里解出 32 次审批——等待中位数 4.6 秒、p90 15.0 秒、 最长 44.2 秒；32 次全是「允许一次」，0 次拒绝。把这段历史原样重放：
| 配置 | 会触发 |
|---|---|
| 固定 30 秒 | 2 次 |
| 固定 10 秒 | 10 次 |
| 自适应（默认） | 7 次，门槛收敛到 11.4 秒 |
所以默认档的定位是「几乎不打扰，但真离开时一定提醒」；如果你的使用习惯是经常离开（比如挂着跑长任务），
用 mode: fixed + fixedMs: 120000 更符合直觉；如果你的审批总是秒回，默认档已经足够安静。
生效中的门槛不用猜：每次回传都会写一行 debug 日志，含 mode（cold/learned/fixed）、
两个门槛、基线中位数与样本数。
非法值（未知 mode、负数、NaN、minSamples 不是整数、ceilingMs < floorMs、
rejectionScale 越界等）会让插件在激活时直接报错，而不是悄悄退回默认值——
避免「我明明配了固定 45 秒，怎么没反应」这种静默差异。
| 备选 | 为什么不用 |
|---|---|
| 工具自己跑了多久 | 与「人在不在」无关；一次 10 分钟的构建不该被当成审批延迟。 |
| 运行时上下文里的 elapsed | 那正是要解释的东西，不能拿它当判据（否则会自我强化）。 |
| 时间戳 / 几点钟 | 需要日历或历史，等于把作息画像塞进插件；收益也更低。 |
| 键鼠空闲、窗口是否失焦 | host 侧拿不到，且属于隐私面；用「回答速度」已经等价地表达了同一件事。 |
| 按工具设不同门槛 | 同一个人回答审批的速度与点的是哪个工具无关，只会增加配置面。 |
| 让模型自报「我刚才好像卡住了」 | 不可靠，而且提示必须在模型开始推理之前到达。 |
approval/request 上的监听器永远 next() 委托，绝不返回结果。
批准/拒绝仍由部署里真正的应答者（Web 面板、ACP、无头策略）决定。additionalContexts 里追加一条消息；
tool/result 审计事件与工具自己的 content 原样保留，后续监听器的 block 反馈也照旧生效。ctx.configForms 提交字段读写，落盘、校验、冲突检测都在 Host
的 settings 服务里；页面本身没有 fetch、没有 localStorage、没有文件访问。approval/request ──(prepend 包装)──▶ 真正的应答者（Web 面板 / ACP / 策略）
│ 记录 startedAt / endedAt / outcome，按 agent + callId 记账
▼
tools/post-execute ──(先 next() 拿到最终决策)──▶ 追加 additionalContexts
│
▼
agent loop 在本步骤工具结果之后，将它作为 user/message 注入 → 下一轮请求里模型可见
宿主半侧还多一层：index.js 导出 Config，字段全部 .volatile()。这带来两件事——
Host 会为这一行开一个名为 approval-latency 的 settings 命名空间（只暴露 volatile 字段），
并且 volatile 的改动会被原地提交进正在运行的 fiber（每个字段在运行期是个 .get() ref）。
设置页 ──ctx.configForms.set('fixedMs', 45000)──▶ Host settings 校验 + 写入 profile 的 Cordis patch
│
volatile-only 变更 → 运行时 ref 原地更新
▼
下一次审批：config.fixedMs.get() 就是 45000
浏览器半侧（client.js）注册进「插件」页的 plugins.row.config 键控 slot，
key 为 <包名>#<行 id> = dsh-approval-latency#approval-latency——这是 DSH 给
bundle 自己的配置指定的位置（plugins.item 是官方分组的位置，不占）。
五处关键接口都不是猜的，是按 0.2.1-rc.2 的 app.asar 逐个核对过的：
ctx.on('approval/request', fn, { prepend: true }) 一定排在应答者外层——
Cordis 的瀑布式派发按注册顺序链接 next()，prepend 就是 unshift；
反过来（排在内层）会根本收不到请求，因为应答者不会调用 next()。tools/post-execute 的决策里 additionalContexts 会被 @deepseek-ai/dsh-agent-loop
收进 next-step 收件箱，并在本步骤工具结果之后作为 user/message 追加。source.kind 用本插件自己的 approval-latency（form: 'notice'）：
会话格式 v4 明确要求「producer-owned source kind」，不用 plugin 这类已退休的包装。dsh-settings 按 entry.id 建命名空间，且只收
volatile 字段）；ui-theme 的命名空间常量就是它的行 id，可直接对照。plugins.row.config 的 key 由宿主按 `${包名}#${行 id}` 派发
（ui-plugin-manager 的 rowConfigKey），slot 的 ownerProps 是 {view: 'summary'|'page'}。时间用 performance.now() 取，避免系统改时间造成负数或异常大的时长。
门槛的记账也在同一条链上：
approval/request 计时 → tools/post-execute 取回 → 先用历史算门槛 → 判断 → 再把这次回答并入历史
「先判断、后并入」是刻意的：本次等待不能参与决定自己要不要被回报，否则越长的等待越容易 把基线抬高、把自己洗成「正常」。
lib/latency.js + lib/plugin.js + index.js + client.js 写了 52 项测试
（npm run test:inprocess；其中 2 项 schema 断言需要 @deepseek-ai/schemastery，
在裸仓库里会自动跳过）。@deepseek-ai/cordis 4.0.5 与 @deepseek-ai/schemastery 3.18.5 抽出来
做了真实运行验证：prepend 的监听器确实排在应答者外层、next() 确实到达应答者并原样返回结果、
30ms 的等待被如实测到、低于阈值不追加、fiber.dispose() 后监听器被移除；
index.js 用真实 Config 挂载后四种配置（自适应冷启动 / 固定 0 / 固定 30s / 学到基线）行为一致。mode: fixed、
填 90 秒失焦写入 fixedMs: 90000、填 0 被本地拦下不发请求、恢复默认走 unset、
只读 / 未服务两种状态控件禁用。真实浏览器里的渲染没有验证过（需要装进 profile 后刷新页面）。package.json 顶层的 engines.dsh 声明为 >=0.2.1-rc.2 <0.3.0-0：0.2.1-rc.2 的
@deepseek-ai/dsh-app-boot（evaluatePluginCompatibility）只读顶层 engines.dsh，
满足即准入、不满足则整个 bundle 在启动时被跳过（而不是带着未知接口跑起来）。
注意不是 dsh.engines.dsh，也不是 dsh.compatibility——那两个位置启动时没人读。@deepseek-ai/schemastery 写在 peerDependencies 里。
这不是装饰——DSH 的解析路由（dsh-app-boot 的 ResolutionRouter）对 link: 安装的插件
只把清单里声明为 peer 的 bare specifier 拦截到安装内的那一份（读的就是 peerDependencies）；
没声明就会走原生解析并找不到。profile 的 pnpm-workspace.yaml 里 autoInstallPeers: false，
所以声明 peer 不会触发任何下载。dsh-context 等已装插件正是同样写法。approval/request 或 tools/post-execute 的形状，插件最坏的结果是
不再回传（静默退回现状），不会误批、也不会改变任何审批结果；若改掉 settings 的 slot 契约，
最坏结果是设置页不出现（配置仍可用 YAML），不影响审批行为。先看插件页：
dsh-approval-latency 卡片；
点带 › 的行标题（审批等待回传（Approval Wait Notice） ›）进入配置页，
里面有「自适应」开关与「固定时长（秒）」输入框。120 并回车 → 保存。1（秒）再重复 → 应当出现提示。再看提示本身：
Approval wait: ... 消息，时长与你实际等待相符。mode 已从 cold
变成 learned，baseline 接近你秒回的速度。callId 关联，就不会回报。ceilingMs）。
想锁死就设 mode: fixed（必要时再填 fixedMs）。never 策略（审批被确定性拒绝）时没有等待，因此不会有提示。见 SECURITY.md：两个事件监听器、一条日志、零网络、零文件、零凭据， 且不参与任何审批决策。