DeepSeek Harness 运行时排查太麻烦?装一个插件,让模型自己查
DeepSeek Harness 运行时排查太麻烦?装一个插件,让模型自己查
一个真实场景
用 DeepSeek Harness(下面简称 DSH)的时候,你大概率遇到过这几件事:
- 某个工具突然从模型的工具列表里消失了,不知道是没装、装了没启用、还是被限制掉了
- 模型说"批准策略拒绝了我的请求",但你不确定当前生效的到底是哪条策略
- 配的凭证到底有没有生效,翻半天配置文件也说不准
- 会话卡了半天没反应,怀疑是不是该压缩上下文了,但不知道怎么确认
以前的办法是:手动跑 dsh --profile <p> --dump-config,翻一堆 YAML;或者去读文档,猜哪个服务该负责这件事。整个过程都是人在排查,模型帮不上忙。
dsh-tool-diagnose 就是为了解决这件事:装上之后,模型能直接调用一个 diagnose 工具,自己查真实的运行时状态,把结果结构化地报给你——不用你手动跑命令,也不用模型瞎猜。
一条命令装上
平时用网页界面的,复制这条:
dsh plugin --profile web add dsh-tool-diagnose
平时在终端里跑一次性任务(dsh --profile headless "..." 这种)的,复制这条:
dsh plugin --profile headless add dsh-tool-diagnose
两条命令唯一的区别就是 web/headless 这个词——这是 DSH 自带的两种运行模式,你平时用哪种,就照哪条抄。不确定的话,先试 headless 这条,装完效果都一样。
装完之后,直接在对话里说"帮我看看 xxx 工具为什么用不了",模型就会自己调用 diagnose 工具去查。
能查什么
现在有 6 个检查,覆盖日常排查最常遇到的几类问题:
| 遇到的问题 | 对应检查 |
|---|---|
| 某个插件是不是真的装上了、启用了 | plugin-fiber-state |
| 某个工具模型是不是真的看得见 | tool-visibility |
| 某个凭证(比如 API Key)是不是配置好了(不会泄露值本身) | credential-resolution |
| 当前生效的批准策略是什么 | approval-policy |
| 这个会话的 token 压力多大,该不该压缩了 | token-pressure |
| 某个会话下面挂了多少子代理,深度多少 | subagent-tree |
每一个都是直接读 DSH 已经在跑的真实服务状态,不是让模型自己去猜或者跑 shell 命令拼凑答案。
还能自己加检查
这套注册表是开放的。如果你自己维护插件,遇到自己特有的排查场景,几行代码就能接进来,不用改这个包一行代码:
export const inject = ['diagnostics']
export function apply(ctx) {
ctx.inject(['diagnostics'], (ctx) => {
ctx.diagnostics.registerCheck({
id: 'my-check',
description: '排查什么问题、target 传什么',
run(target) {
return [/* 结构化结果 */]
},
})
})
}
别的插件作者装了你的插件之后,diagnose 工具会自动带上你新加的检查。
靠谱吗
写完之后没有只跑单元测试就算完事——专门装进一个真实跑起来的 dsh 进程,让模型真的调用工具,确认返回的结果和运行时的真实状态对得上(比如凭证配置状态、工具可见性都是拿真实数据核对过的),过程中还揪出了两个单元测试完全没测出来的问题并修掉了。细节记录在仓库 README 的 Audit notes 里,这里不展开。
链接
- 装:
dsh plugin --profile <name> add dsh-tool-diagnose - 仓库:https://github.com/xu-kai-quan/dsh-tool-diagnose
- npm:https://www.npmjs.com/package/dsh-tool-diagnose
更多推荐


所有评论(0)