DeepSeek Harness Hub
← 返回列表

WsTe47/dsh-step-clock

DeepSeek Harnessspec-screened在 GitHub 查看 ↗
未验证

一个给 DeepSeek Harness…

尚未跑自动兼容性验证,可查看页面内的依赖与入口分析。 · 最近上游提交 2026/9/13 · 已提供中文文档

DeepSeek Harness Web GUI 的实时每步耗时时钟

综合分
29.6
GitHub 分
29.6
用户评分
★ Stars
0
周下载量
安装插件(需先安装 dsh CLI 引擎:npm install -g @deepseek-ai/dsh)
dsh plugin --profile web add WsTe47/dsh-step-clock
该插件未发布到 npm,走 GitHub 源安装(pnpm 若拦截 prepare 脚本,按其提示在 pnpm-workspace.yaml 的 allowBuilds 中放行后重跑)
数据截至 2026/9/16(元数据每日更新 · 实装验证按队列轮转,单条结论的验证时间见上方)
用户评分
还没有人投票,来当第一个
订阅周报,不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动

README

dsh-step-clock

一个给 DeepSeek Harness 网页版用的单步耗时实时秒表。它回答内建计时器回答不了的那个问题:正在跑的这一小步,已经跑了多久?

● 正在执行 bash,已运行 1 分 12 秒    第 12 步   [bash]        1:12

那一步跑完之后,它会继续把结果留在屏幕上:

● 上一步(第 12 步)已完成,用时 3 分 45 秒                    3:45

状态条位于输入框上方的那一条(和 todo、goal 条同排),并在输入框下方另有一处,这样目标条再高也挤不掉它。

为什么需要它

Harness 本身已在对话底部显示一个轮次(turn)级时钟,但它要等 15 秒才出现,而且计的是整轮的时间。当你盯着一个长时间的 bash 调用时,你无法判断它是刚开始两秒,还是已经卡了四分钟——那个轮次时钟也回答不了。

本插件计量的是当前这一小步,并且从它真正开始活动的时刻起算:

- 工具步骤锚定在该工具调用自身的开始时间上。运行中的调用只在其运行期间存在于实时快照里,所以 0:47 表示这次调用本身已跑了 47 秒,而不是从轮次推算出来的估计值。
- 思考步骤回退到步骤边界,这是模型耗时最诚实的锚点。
- 秒表从 0:00 就开始跳,没有任何延迟门槛。

它会说什么

它用直白的中文句子描述当前状况,而不是丢一个光秃秃的数字:

| 状态 | 文案 |
| --- | --- |
| 正在执行工具 | 正在执行 ,已运行 47 秒 |
| 多个工具并行 | 正在执行 bash,另有 2 个工具并行,本步已运行 5 秒 |
| 模型流式输出中 | 模型正在思考,本步已耗时 23 秒 |
| 已提交、还没输出 | 已提交,正在等待模型响应,已等待 3 秒 |
| 上一步已完成 | 上一步(第 12 步)已完成,用时 3 分 45 秒 |
| 什么都没跑 | 空闲,等待下一步 |

旁边还有:步号、正在执行的工具名标签(最多 4 个,超出 +N,悬停看全部)、以及最右侧一个紧凑的 m:ss 数字。

时长按中文习惯换算——47 秒、1 分 12 秒、2 分钟、1 小时 3 分——所以0:03 不会产生"3 秒还是 3 分钟"的歧义。

为什么完成后还要留着

一个步骤经常在一秒内就结束了,只在"运行期间"存在的状态条极易被错过。把上一步的用时留到下一步开始前,你就能事后发现某个慢步骤——比如一个跑了四分钟的 bash。只有在该步骤自己的 start 与 end 时间戳都存在时才记录;不存在时它会老老实实显示"空闲",而不是编一个看起来像真的耗时。

安装

dsh plugin --profile web add @climber47/dsh-step-clock

然后重启 dsh web。下一次有步骤运行时,状态条就会出现在输入框上方。

实现方式

这是一个 dsh bundle,以单条 insert 行挂载:

- package.json 声明 dsh.bundle.patch(这是它能被安装的关键)与 dsh.client(platform: web,这是浏览器半边被加载的关键)。
- cordis.patch.yml 插入 step-clock 行。
- lib/index.js 是(有意为空的)宿主半边。bundle 的 insert 行会解析包根,所以包必须可被导入;本插件没有宿主行为。
- lib/client.js 是浏览器半边,采用客户端 bundle 必须的 window.__ModuleLoader__.load({ id, factory }) 注册形状。React 通过 require('react') 从模块加载器取得,不打包进产物。
- 它只注册一个纯新增条目:输入框上方的 conversation.input.dock(replaceRisk: none,不会动自带的 todo / goal / queue 条目)。样式通过创建一个带标记的  元素注入,插件卸载时移除。
- 它只声明真实存在的服务(slots、timer)。客户端插件没有样式服务——styles 只存在于动态插件沙箱里。声明一个无人提供的服务会让 Cordis 无限期等待,插件会显示"已加载"、不报任何错,却永远不渲染。
- 发布的 bundle 由 npm run build 从 src/client/ 生成,因此可读源码与产物不会漂移;npm test 会先重新构建,再把 bundle 喂进它真实的加载器契约里跑行为测试。

它只读取引擎已经发布的事实——Chat 时间线快照与运行中调用列表——自身不做任何轮询。

环境要求

- dsh >=0.1.5-rc.1
- React 18(peer 依赖,由 harness 外壳提供)

许可

MIT

上游仓库有新提交时邮件通知你(每天最多一封,无更新不打扰),随时一键退订。

💬 加入 DPharness 群聊

插件用法、部署报错、新插件第一时间同步——群里问,比一个人翻文档快。

点击加入 QQ 群
DPharness 群聊二维码,手机 QQ 扫码进群
扫码进群