DSH LLM Verifier

基于 llm-as-a-verifier/llm-as-a-verifier 迁移构建的 DSH 原生模型可配置复核插件（Verifier）。

---

它是什么？

dsh-llm-verifier 为 DeepSeek Harness（DSH）引入了一套独立的裁判复核机制。在主 Agent 负责生成代码、执行命令与工具交互的同时，Verifier 会收集当前任务目标、各候选方案过程以及真实的终端执行结果，交由你在设置中指定的独立 DSH 模型进行仲裁：评估哪个方案更可靠、当前任务的实际完成进度、以及是否存在未发现的潜在错误。

插件提供五个显式工具，并支持可配置的宿主级自动会话验收：

• verifier_compare：对两个候选执行过程进行成对比较（Pairwise Comparison）；
• verifier_select：在多个候选方案中通过锦标赛机制选出最优解，供 Best-of-N / 多候选编排器直接调用；
• verifier_track：评估任务在已有检查点（Checkpoint）的完成度与进展，供 Goal / Workflow 等长任务编排器直接调用；
• verifier_best_of_n：唯一会自己生成候选的工具——用当前会话模型并行起草 N 份完整候选，再用独立裁判排序，并额外给出与验收门控同源的绝对分（见关键交付物的 best-of-N）；
• verifier_current_session：显式提取当前 DSH 会话记录，进行脱敏并执行复核；
• 自动路由与早评审：智能或严格策略在 agent/turn-stopping 生命周期边界按阶段调度 select → compare → track → current_session（verifier_best_of_n 永不自动触发）。第一阶段只信任 Workflow 的版本化候选协议与发生真实变化的 Todo 快照；普通 Subagent 输出必须经第二阶段的证据引用分类，避免把不同子任务误当候选。此外，智能模式还会在 agent/pre-step（下一次模型生成之前）对已完成的 Workflow 候选信封做一次受限的 compare/select 早评审，让选择结果直接影响接下来的实施；该入口不跑语义分类、track、最终验收或候选生成，严格模式不参与；
• 自动验收门控：候选选择与进度检查完成后，宿主运行同一会话验收逻辑；未通过时以插件 steering 反馈要求 Agent 修复并重新验证，而不是依赖模型是否主动想起工具。

安装与启用 (Installation & Usage)

1. 使用 dsh plugin 安装

DeepSeek Harness（DSH）通过 profile 独立管理各个运行环境的插件依赖。请使用 dsh plugin 命令将插件安装至目标 profile（如 web）：

# 方式 A：从 npm 官方 Registry 安装（推荐）
dsh plugin --profile web add dsh-llm-verifier

[!NOTE] dsh plugin add 安装成功后，DSH 会自动识别包内的 dsh.bundle 声明并完成插件层自动对齐（Reconcile），无需手动修改任何配置文件。

2. 启动与配置

启动 DSH Web 客户端：

dsh web
# 或
dsh --profile web

启动后进入前端界面，打开 设置 → LLM Verifier 即可可视化配置裁判所使用的 Provider、Model、推理强度（Reasoning Effort）、最大并发与缓存策略。

3. 常用管理命令

# 更新插件至最新版本
dsh plugin --profile web update dsh-llm-verifier

# 卸载插件
dsh plugin --profile web remove dsh-llm-verifier

# 查看当前 Profile 已安装的插件与依赖列表
dsh plugin --profile web list

4. 作为独立库引用（可选）

如果你在其它 TypeScript / JavaScript 项目中需要复用核心评分标尺与锦标赛算法，可直接作为普通 npm 依赖安装并引入：

pnpm add dsh-llm-verifier

import {
  extractScore,
  extractProgressScore,
  bradleyTerry,
  pivotRoundPairs,
} from 'dsh-llm-verifier/core'

本地开发

pnpm install
pnpm run build      # 生成 lib/，宿主加载的就是这份产物
pnpm run typecheck  # 按 package.json 里锁定的 @deepseek-ai/dsh-* 版本检查类型
pnpm test           # vitest 单元测试

当 DSH 本体是本地 checkout（默认位于同级目录 ../deepseek-harness）时，用下面的命令按实际运行版本检查类型：

pnpm run typecheck:local   # 依据 tsconfig.local.json，把 @deepseek-ai/dsh-* 解析到本地 checkout 的 lib/types

两套类型定义可能不同步：例如 Session.events 在 DSH 0.1.5 已被 snapshotEvents() 取代，tool/code-dispatch 也已改名 tool/ptc-dispatch。插件内部的 sessionEvents() 同时兼容两种会话形态，两类派发事件都会计入证据，因此 0.1.1 与 0.1.7 宿主都可以运行。

DSH 0.1.7 又搬动了两处判定地基，两侧形态插件都读：

• 工具结果从内容块变成独立消息。0.1.6 及以前，一条工具结果是一个 tool-result 内容块，真正的输出套在里面、失败标志 isError 挂在块上；0.1.7 删除了该块类型，工具结果改为 role: 'tool' 的独立消息，isError 上移到消息本身。session.ts 的 toolResultBlocks() / toolResultFailed() 是这两个差异的唯一读取点，旧宿主的嵌套输出仍会被渲染成 [Tool Result] 证据。
• 注入消息的来源改为生产者自报。0.1.7 删除了 MessageSourceMap 的统一包装 { kind: 'plugin', plugin }（持久化准入还会直接拒绝该包装），改为每个生产者声明自己的 kind。插件在 src/message-source.ts 声明并使用 kind: 'llm-verifier'；宿主读取旧日志时会把历史包装行改写成 plugin:<名称>，那只是历史行的显示名，不影响判定。

…