dsh-pain-point-check

English | 中文

DeepSeek Harness (dsh) 的强制版卡点检查 guard 插件。

官方自带的 repeat-tool-reminder 是建议性的——只对"逐字重复同一条调用"的 agent 递话；本插件会拦截：同一问题连续 2 个实验未收敛后，注入三问、否决非调查类工具调用直到模型在回复正文答出三问，并阻止继续沿原方向开火。

为什么

进入"解决态"的 agent 会丢掉 meta-cognition，连续猛攻同一个问题——确认偏执（只设计支持当前假设的实验）、沉没成本（已投入就舍不得换方向）、叙事偏执（想把故事收尾）。本插件在开下一枪前强制回到卡点，把负结果变成信息。

安装

包尚未发布到 npm，直接从本仓库安装：

npm install github:ICCuse/dsh-pain-point-check
# 或：pnpm add github:ICCuse/dsh-pain-point-check

然后在你的 profile 组装中挂载一行。以 web profile 为例，编辑 ~/.dsh/profiles/web/cordis.patch.yml：

- id: pain-point-check
  name: 'dsh-pain-point-check'
  config:
    failureThreshold: 2
    repeatThreshold: 2

重启（dsh web）后即对每个会话生效。

工作机制

钩子	作用
tools/result	按 agent 统计当前问题内的实验：失败（报错）调用与连续相同调用。
agent/pre-step	真实用户插话（新问题）时重置计数；门禁 pending 时把三问检查块追加进下一步。
tools/pre-execute	门禁期间否决所有非调查类调用（放行：read、read_image、glob、grep、web_search、ask_user_question、skill、todo_write）。
session/event	检测模型回复正文中的三个答案（卡点=… 排除=… 性价比=…，也接受英文标记）并解除门禁。

三问：当前最该解决的还是这个卡点吗？上一轮负结果到底排除了什么？各备选路径的性价比如何，哪个最具性价比？若模型说不出负结果排除了什么，说明它没有可证伪的假设——检查文本会要求它回去写假设，而不是再开一枪。

配置

字段	默认	含义
failureThreshold	2	触发门禁的失败调用数。
repeatThreshold	2	触发门禁的连续相同调用数。
allowlist	调查工具集	门禁期间仍可调用的工具。

两个阈值必须为 >= 1 的整数；配置错误会在插件加载时直接抛错。

开发

lib/ 为预构建产物（由 DeepSeek Harness monorepo 工具链构建）。测试：

npm install
npm test

测试套件用脚本化 mock 适配器驱动真实 agent loop（无网络）：触发、拦截、放行、解禁、部分作答、重置、配置校验失败等路径全覆盖。

许可

MIT