Idea + plugin: an enforced pain-point check to stop rabbit-holing

[ICCuse]

Idea + plugin: an enforced pain-point check to stop rabbit-holing

中文版见下方 / Chinese version below.

TL;DR

An agent in "solution state" loses meta-cognition and keeps attacking the same problem — three biases inherited from human problem-solving: confirmation bias (designing experiments that support the current hypothesis), sunk cost (refusing to change direction), and narrative closure (wanting to finish the story). The official repeat-tool-reminder is advisory — it nudges an agent that repeats the exact same call. I built the enforced sibling: after two non-converged experiments on the same problem, a gate injects the three questions, denies non-investigative tool calls until the model answers them in its reply text, and blocks same-direction retries.

Plugin: ICCuse/dsh-pain-point-check (dsh-plugin topic).

The mechanism

Hook	Role
tools/result	Per-agent counters on the current problem: failed (errored) calls and consecutive identical calls.
agent/pre-step	Reset on a real user interjection (new problem); while pending, append the three-question block to the next step.
tools/pre-execute	Deny every non-investigative call while pending (allowlist: read, read_image, glob, grep, web_search, ask_user_question, skill, todo_write).
session/event	Detect the three answers (痛点=… 排除=… 更便宜=…, English markers accepted) and lift the gate.

The three questions: is this pain point still the most painful? What did the last negative result actually rule out? Is there a cheaper path? If the model cannot name what the negative result excluded, it has no falsifiable hypothesis — go write one instead of firing another shot.

Tested end-to-end through a real agent loop with a scripted mock adapter (8 tests: arming, denial, allowlist, lifting, partial answers, resets, fail-loud config).

Questions for the team

1. Is this direction aligned with where the guard family is going? Would you consider an enforced tier next to repeat-tool-reminder?
2. The weak point is convergence detection — I count failures and identical repeats as proxies. A goal-aware signal (did the user's stated goal advance?) would be much stronger. Any plans in that space?
3. Any appetite for a first-class "checkpoint" UI (e.g. blocking with a modal asking the user) rather than text-pattern detection?

---

中文版

一句话

进入"解决态"的 agent 会丢掉 meta-cognition，连续猛攻同一个问题——背后是三个继承自人类解题的偏执：确认偏执（只设计支持当前假设的实验）、沉没成本（已投入就舍不得换方向）、叙事偏执（想把故事收尾）。官方 repeat-tool-reminder 是建议性的——只对"逐字重复同一条调用"的 agent 递话。我做的是它的强制版：同一问题连续 2 个实验未收敛后，门禁注入三问、否决非调查类工具调用直到模型在回复正文答出三问，并阻止同方向重试。

插件：ICCuse/dsh-pain-point-check（dsh-plugin 话题）。

机制

钩子	作用
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	检测三问答案（痛点=… 排除=… 更便宜=…，也接受英文标记）并解禁。

三问：这个痛点还是最痛的吗？上一轮负结果到底排除了什么？有没有更便宜的路径？若说不出负结果排除了什么 = 没有可证伪假设，先回去写假设，别再开一枪。

已用脚本化 mock 适配器驱动真实 agent loop 端到端测试（8 个用例：触发、拦截、放行、解禁、部分作答、重置、配置校验失败）。

想请教团队

1. 这个方向跟 guard 家族的规划一致吗？是否考虑在 repeat-tool-reminder 旁加一个强制层？
2. 弱点在收敛检测——我用失败数和相同调用做代理；真正强的信号是"用户目标有没有前进"。这个方向有规划吗？
3. 有没有兴趣做一等的"检查点 UI"（比如拦截时弹窗问用户），而不是文本模式匹配？