前言¶
在 DSH（DeepSeek Harness）的工程实践中，工具调用通常通过 timeoutMs 或 job_output 的 timeout_ms 参数控制等待时间。这些参数由模型填写，若模型未指定或填写的值过大，部署侧通常缺乏细粒度的兜底机制，可能导致长时间阻塞或资源占用。
插件简介¶
dsh-limit-timeout 是一个由 azazo1 维护的管理安全类插件，用于在 DSH agent 单次工具调用执行前拦截并检查等待时长。
该插件在 tools/pre-execute 阶段介入，覆盖模型可控的等待参数。当调用请求超过配置的上限时，插件会拒绝该次调用，记录日志，并提供三条替代方案供模型参考（降低等待时间、改用后台执行、申请提升）。
安装与启用¶
安装前请确保 DSH 引擎版本满足要求：@deepseek-ai/dsh-* 需要大于或等于 0.2.0-rc.1 且小于 0.3.0。
Web 端安装需指定 web profile：
dsh plugin --profile web add azazo1/dsh-limit-timeout
安装完成后，重启 dsh web 以刷新页面。
桌面端不支持通过命令行直接安装（命令行会拒绝 --profile desktop 参数）。需在应用内的插件管理器中填写包名 azazo1/dsh-limit-timeout 进行安装，随后重启桌面端应用。
配置说明¶
设置入口位于 Settings > 等待上限。该页面为草稿式编辑，改动不会立即生效，需点击“保存”或“放弃更改”。
保存操作为原子写入，若配置冲突（如默认上限高于硬天花板），保存会被拒绝。
设置包含以下字段：
| 字段 | 默认值 | 说明 |
|---|---|---|
全局默认等待上限 (defaultLimitMs) |
120000 | 单次调用可声明的最大等待时间，覆盖 timeoutMs 与 timeout_ms |
硬天花板 (hardLimitMs) |
1800000 | 即使批准了提升，实际等待也不会超过此值；调低它会收回已批准的提升 |
允许模型申请提升 (allowEscalation) |
开 | 开启后模型可通过 request_wait_extension 申请提升，由部署侧审批 |
要求显式声明等待时长 (requireExplicitJobWaitMs) |
关 | 开启后 job_output 的 wait: true 必须同时给出 timeout_ms |
屏蔽重复调用提醒 (suppressRepeatToolReminders) |
关 | 开启后 repeat-tool-reminder 注入的提醒不再进入模型请求 |
支持的时间格式包括：120000（毫秒）、500ms、90s、2m、1h。未编辑时，保存后与放弃更改后都会还原成合适的单位写法。
运行时行为¶
- 拦截与拒绝：插件在
tools/pre-execute阶段拦截调用。放行时继续进入下游策略（权限、沙箱）判断；超限时直接短路成错误结果，调用不会真正执行。 - 拒绝日志：每次拒绝都会以 info 级别记入 Host 日志，包含工具名、调用 ID、当前上限与提升状态。
- 提升机制：申请走 DSH 原生审批通道，批准后仅对当前进程内的会话生效。提升不写入会话日志，因此不可回放，也不能跨进程保留。
- 重复提醒：通过
agent/pre-step过滤repeat-tool-reminder注入的消息。此功能仅改变模型看到的内容，不影响会话日志与历史回放，被过滤的条数记入 debug 日志。
适用场景与边界¶
- 边界检查：该插件仅覆盖模型可控的等待参数（
timeoutMs、timeout_ms）。工具自身的部署超时（如web_fetch的fetchTimeoutMs）不受本插件约束。 - job_output 行为：当
job_output仅写wait: true而不写timeout_ms时，等待时长由dsh-tool-jobs的waitTimeoutMs决定，默认配置下不受本插件约束。需严格限制时可开启“要求显式声明等待时长”。 - 安全提示：插件以当前 DSH 进程权限运行，安装前建议检查源码与许可证（MIT）。
开发¶
插件基于 TypeScript 开发，源码位于 src/ 目录，构建产物位于 lib/ 目录。
常用开发命令如下：
just install
just typecheck
just build
just test
just verify
结尾¶
该插件为 DSH 生态提供了一种在部署侧控制工具调用时延的手段。通过设置全局上限与硬天花板，结合模型申请提升机制，可以在保障系统稳定性的同时，给予模型灵活的执行空间。
