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_current_session：显式提取当前 DSH 会话记录，进行脱敏并执行复核；
• 四工具自动路由：智能或严格策略在 agent/turn-stopping 生命周期边界按阶段调度 select → compare → track → current_session。第一阶段只信任 Workflow 的版本化候选协议与发生真实变化的 Todo 快照；普通 Subagent 输出必须经第二阶段的证据引用分类，避免把不同子任务误当候选；
• 自动验收门控：候选选择与进度检查完成后，宿主运行同一会话验收逻辑；未通过时以插件 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'

迁移来源

本插件的核心评估理论、A–T 评分标尺、进度判定算法以及概率基准锦标赛（Probabilistic Pivot Tournament）均源自开源项目：

• 上游项目：llm-as-a-verifier/llm-as-a-verifier

本插件将上游算法完整移植为 TypeScript 实现，并深度集成了 DSH 的模型路由、设置面板、附件管理、会话日志与工具生态。上游实现作为本插件的算法基准；本仓库内置了 Python / TypeScript 一致性测试（Parity Tests），确保核心评分与锦标赛赛制（Tournament Fixture）的跨语言逻辑完全一致。

核心原理

可以将整体协作模式理解为 “选手 + 裁判”：

1. 主 Agent（选手）：专注于具体任务的执行（编写代码、运行命令、执行单元测试）；
2. Verifier（现场记录）：收集题目要求、候选代码/解答及真实的终端输出证据；
3. 独立模型（裁判）：在 DSH 设置中自由选择可用模型担任裁判；
4. 输出判定：裁判必须在 A–T 细粒度标尺中给出明确的判定（Verdict）；
5. 分数换算与聚合：插件将字母判定换算为 0–1 区间的分数，并在多个评判维度、重复轮次以及交换位置后取加权平均；
6. 多候选优化：在多候选方案场景下启用 Pivot Tournament 算法，避免高成本的全量两两比对。

一次成对比较的完整流程

flowchart TD
    U[任务目标 Problem] --> P[构造裁判提示词]
    A[候选 A 与真实工具输出] --> P
    B[候选 B 与真实工具输出] --> P
    P --> C{持久缓存是否命中?}
    C -- 是 --> R[直接复用历史评分]
    C -- 否 --> D[通过 DSH LLM Runtime 调用指定裁判模型]
    D --> V[模型输出 A–T Verdict]
    V --> S[换算为 0–1 分数]
    S --> W[写入持久化成功缓存]
    W --> R
    R --> O[按评估标准与重复轮次聚合]
    O --> X[返回胜出者、得分、Token 消耗及缓存统计]

如何消除位置偏见（Position Bias）？

大语言模型通常存在“首位偏好（First-token Bias）”或对特定选项标签的偏置。为此，插件默认在每个评判标准下进行两轮对决：

第 1 轮：候选 A 放置于左侧，候选 B 放置于右侧
第 2 轮：候选 B 放置于左侧，候选 A 放置于右侧
最 终：将第 2 轮结果还原至原始候选身份后，与第 1 轮计算平均得分

通过位置对称交换与结果求平均，最大程度抵消模型的位置偏置干扰。

A–T 细粒度标尺说明

在成对比较（Pairwise）中，标尺定义如下：

A       = 明确、完整、有确凿证据证明成功
B ... J = 置信度依次递减，但整体偏向成功
K ... S = 偏向失败的程度依次递增
T       = 明确且无可争议的失败

字母按等距标尺线性映射到 [0, 1] 区间。在打分计算上，插件采用自适应评分机制：

…