← 返回列表
未验证
DeepSeek Harness 的独立只读验收层。
尚未跑自动兼容性验证,可查看页面内的依赖与入口分析。 · 最近上游提交 2026/8/14 · 已提供中文文档
DeepSeek Harness 的只读验收层:验证器对每一轮进行把关,并将缺口引导回智能体。
综合分
26.8
GitHub 分
26.8
用户评分
—
★ Stars
1
周下载量
—
安装插件(需先安装 dsh CLI 引擎:npm install -g @deepseek-ai/dsh)
dsh plugin --profile web add EvilIrving/dsh-proof该插件未发布到 npm,走 GitHub 源安装(pnpm 若拦截 prepare 脚本,按其提示在 pnpm-workspace.yaml 的 allowBuilds 中放行后重跑)
信任档位:仅索引本站尚未对其实装验证,仅收录元数据
- 是什么
- dsh 原生插件 · chat
- 装得上吗
- 本站尚未做安装检查
- 安全吗
- 本站尚未对该插件做风险分级(暂未覆盖,不等同于无风险)
- 还在维护吗
- 更新放缓:最近一次提交在 42 天前
档位由下列信号合成:本站实装验证(真实安装,当前最高到 L4)· 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。 验证判据与等级说明 →
数据截至 2026/9/23(元数据每日更新 · 实装验证按队列轮转,单条结论的验证时间见上方)
依赖的 DSH / Cordis 模块
@deepseek-ai/schemastery@deepseek-ai/cordis@deepseek-ai/dsh-agent@deepseek-ai/dsh-llm@deepseek-ai/dsh-subagent@deepseek-ai/dsh-tools用户评分
还没有人投票,来当第一个
订阅周报,不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
由 DeepSeek 最新模型翻译生成dsh-proof
DeepSeek Harness 的独立只读验收层。
Awesome DSH Plugin
在每个顶层回合结束之前,dsh-proof 会启动一个只读验证器子代理,收集其结构化裁决,并将任何非 pass 的缺口引导回驱动代理。它是该 harness 缺失的“代理是否真的完成了”关卡——没有其他插件可以替代它。
安装
dsh plugin --profile add github:EvilIrving/dsh-proof
或者,从本地检出安装:
dsh plugin --profile add ./dsh-proof
该 bundle 补丁会插入一行插件配置(dsh-proof);它需要 subagents 服务(官方 dsh-subagent 提供者),而基础 profile 已经挂载了该服务。
工作原理
| 步骤 | 机制 |
|---|---|
| 拦截“即将关闭” | agent/turn-stopping(串行,在回合提交前等待) |
| 启动只读验证器 | ctx.subagents.start('spawn', …) 配合 toolFilter.deny + outputSchema |
| 阻止递归 | delegationDepthOf(agent) > 0 过滤器 + maxDepth: 0 |
| 将缺口引导回去 | 在 fail / insufficient-evidence 时执行 agent.inject(gap details) + agent.steer(followup) |
验证器继承父级的工具集,并通过拒绝列表进行收窄(参见拒绝列表);它永远不会看到一个可能意外隐藏新添加的只读工具的白名单。如果验证器以 stopReason !== 'completed' 结束,或缺少 structured 结果,则被视为“无异议”,因此验证失败永远不会导致用户的回合失败。
配置
export interface Config {
providerName: string // default 'spawn'
maxAttemptsPerTurn: number // default 3
denyTools: string[] // default mutating-tool deny list
verifierPrompt: string // read-only acceptance instruction
followupInstruction: string // steering text after a failed verdict
}
从 cordis.yml 设置任意字段:
plugins:
dsh-proof:
config:
maxAttemptsPerTurn: 2
denyTools: [write, edit, str_replace_editor, bash, run_code, subagent]
拒绝列表
toolFilter.deny 会从验证器继承的完整工具集中移除工具。tools.restrict 会大声校验每个名称,因此 denyTools 必须命名部署实际注册的工具。默认值为
write, edit, str_replace_editor, bash, run_code, subagent,这会保留只读发现工具(read、read_image、glob、grep)可用。添加了自己的变更工具的部署必须扩展该列表;即使 shell/读取访问也被禁止的部署应改用显式的 allow 白名单(将 denyTools 和 verifierPrompt 设置为匹配,或扩展插件以添加 allowTools 字段)。
模型体验
请求上下文与条件
模型看到的内容
顶层代理会收到一条注入的用户消息,其中列出验证器的缺口和证据,随后是配置的 followupInstruction。只有
非 pass 判定会注入任何内容;通过的回合不添加任何内容。
Token 影响
对通过的回合没有直接影响。失败的回合会添加一条有界的注入消息(缺口 + 证据)以及简短的后续行。
KV 缓存影响
仅追加:注入的上下文和后续内容作为新的用户消息追加,绝不会重写先前的请求 token。
已知限制与推迟的工作
- 拒绝列表必须与部署的工具匹配 — tools.restrict 在遇到未知名称时会显式失败,因此不匹配的默认值会阻止验证器启动。确切的变更工具集是部署特定的,并在首次安装时解析。
- 没有证据规范化 — 验证器自行收集证据;此插件不会重新实现 diff/test/typecheck/lint。希望使用特定证据通道的部署应扩展 verifierPrompt。
- 尽力而为的生成 — 提供程序不存在或拒绝请求时会降级为无操作(已记录日志),而不是使用户的回合失败。