DeepSeek Harness Plugin Hub

发布与管理完整 Harness Profiles,发现适合你的插件。

探索

插件目录环境预设文档中心动态

社区

发布插件联系我们报告问题

相关链接

Plugin Hub GitHubDeepSeek Harness 官方项目系统状态隐私说明
© 2026 DeepSeek Harness Plugin HubPowered byPaxTech

独立、非官方社区项目,与 DeepSeek 官方无隶属、授权或背书关系。

DeepSeek Harness Plugin Hub
ProfilesPlugins分类动态文档登录管理 Profiles
ProfilesPlugins分类动态文档登录
← Plugins
L

dsh-limit-break

Limit Break

持久的跨会话记忆,以及能够应对基于主机名拦截的获取阶梯——适用于 DeepSeek Harness 的四个小工具。

插件会安装到这里;不确定时保持 web。

npx -y @deepseek-ai/dsh plugin --profile web add github:Ma354/dsh-limit-break#aacea219dffd04fa3c9da2f8c0edee6100627eb1
README兼容性版本

兼容性与来源证明

Limit Break 以 dsh-limit-break 发布,当前版本为 1.6.0。Plugin Hub 会校验它的 manifest,并保存精确安装来源,便于复现安装结果。

DSH 兼容范围
*
运行环境
any
发布来源
github
Registry 更新时间
2026/10/29

版本

1.6.0stable
2026/10/29
1.5.0stable
2026/10/22
1.4.0stable
2026/10/22
查看其余 2 个版本收起版本
1.3.0stable
2026/10/21
1.2.1stable
2026/10/21

相关插件

正在加载相关插件…

最新版
1.6.0
DSH
*
HMR
重启进程
Tree shaking
未声明可安全裁剪
解包体积
未提供
文件数
未提供
Surface
any
许可证
MIT
发布源
github
GitHub
★ 0
周下载
0
最近提交
2026/10/29
查看源码 ↗
README Badge

点击下方 Badge 复制 Markdown,粘贴到 README 即可。

这是你的 Plugin?认领权益 · 优先安全扫描

验证 package.json 声明的 GitHub 仓库,即可管理这个公开页面。认领后,Hub 会优先安排当前版本的安全扫描,并在通过后公开展示结果。

认领这个 Plugin →
报告问题

相关插件

继续浏览 memory-context 分类下经过校验的插件。

Hindsight Coding Agents@vectorize-io/hindsight-coding-agents面向编程代理的仅反思式 Hindsight 长期记忆(可插拔支持多种运行框架:opencode、……),自动在后台导入(无需设置 CLI)。Contextdsh-context用于上下文洞察和管理的 DeepSeek Harness 插件,提供上下文仪表板和上下文命令,帮助了解上下文的构成及其演变过程。Memory Plugin@openviking/dsh-memory-plugin适用于 DeepSeek Harness 的 OpenViking 记忆与上下文套件Mnemondsh-mnemon面向 DeepSeek Harness 的可组合、基于视图的上下文。开箱即用的可插拔来源与策略、分层记忆和自我演进技能。

README

dsh-limit-break

Four small tools for DeepSeek Harness that came out of a self-benchmark: two things an agent is normally told it cannot do, made cheap enough to just do.

ToolWhat it does
memory_recallRanked search over a JSON fact store that outlives the session. Omit query to list everything.
memory_saveWrite or overwrite one fact: { id, statement, value?, unit?, details?, tags?, source? }.
resilient_fetchFetch with a four-rung ladder and a report of which rung answered.
memory_statsWhere the store is, how many facts, how big.

Zero npm dependencies. No import-time side effects. Everything fails soft — a broken store or a dead network returns an error object, never an exception that could take the host down.

Recall quality. memory_recall is measured, not vibed: tools/recall-bench.mjs runs 20 hand-labelled questions against the live store and prints hit@1 / hit@3 / MRR. At 1.5.0 the ranking skips English stopwords, stems, matches whole words (with a prefix fallback, so ray finds raytracer), splits dotted ids into segments, weights each query token by inverse document frequency, and rewards a whole-phrase hit: hit@1 0.75 → 0.95, MRR 0.867 → 0.975 on the same 20 questions and the same 20 facts. The one remaining miss is a genuinely ambiguous question that matches two benchmark facts.

Runtime requirement: curl. Rung 1 of the fetch ladder is plain fetch and needs nothing; rungs 2–4 (IPv6 → IPv4 → sibling hostname) shell out to curl, so it has to be on PATH. Windows 10+, macOS and mainstream Linux all ship it. Without it the ladder degrades to rung 1 and says so in the report instead of pretending it climbed.

Why these four

Memory. A session starts from zero. A store on disk plus a read at the start is enough to beat that. Measured with two brand-new agents, zero context, the same five questions: 5/5 with the store, 0/5 without — and the control did not hallucinate, it answered "I don't have that" five times.

Network. The reflex "this host is unreachable" is wrong more often than it is right. Measured on one network, same edge IP, 75 seconds apart: api.wikimedia.org → 200 in 0.43 s, en.wikipedia.org → connection reset in 1.21 s, api.wikimedia.org again → 200 in 0.39 s. The block was keyed on the TLS hostname, not the address. So the ladder tries, in order: plain fetch → IPv6 → IPv4 → a sibling hostname of the same service whose certificate still verifies (*/wiki/Title → api.wikimedia.org/core/v1/wikipedia/<lang>/page/<Title>).

It does not disable certificate verification and does not route through a proxy that would impersonate the origin. Those are MITM, not workarounds.

Install

dsh plugin --profile <profile> add dsh-limit-break

Then restart that profile. In the desktop app, install it from Settings → Plugins instead — the desktop profile is owned by the app's plugin manager.

The package declares dsh.bundle and ships cordis.patch.yml, so dsh plugin add mounts it with no manual editing. If you are mounting it by hand, add to profiles/<profile>/cordis.patch.yml:

- insert:
    - id: limit-break
      name: dsh-limit-break

A hand-mounted entry still needs the package on the profile's dependency list — a bare insert for a package the profile does not declare is silently ignored.

The store

$DSH_HOME/memory/facts.json, schema:

{ "schema_version": 1,
  "facts": [ { "id": "", "topic": "", "statement": "", "value": "", "unit": "",
               "details": "", "source": "", "timestamp": "", "tags": [] } ] }

Plain JSON on purpose: anything that can read a file can use it, with or without this plugin. Writes are tmp-file + rename, and a save takes a .facts.lock (created O_EXCL, stolen after 15 s if its writer died) around the whole read-modify-write, so two sessions saving at the same moment both keep their facts. tools/concurrency-selftest.mjs states the numbers: 16–17 of 48 saves lost before the lock, 0 after.

Disable / remove

  • Hot: set disabled: true on the entry in cordis.patch.yml — Cordis recomposes in about a second.
  • Cold: dsh plugin remove dsh-limit-break, then restart.
  • The store is not deleted by either. It lives in $DSH_HOME/memory/ and is safe to keep.

Known limits

Measured, not guessed — each line is something a session actually hit.

  • Tools are visible only to sessions opened after the mount. A session created before the plugin mounted keeps its tool snapshot; new tools do not appear until a new session. Not fixable from the plugin side (the tool list is materialised per session).
  • Concurrent saves serialise, and wait at most 8 s. A second session saving at the same moment waits for the lock instead of losing its fact; if the holder is wedged, the save returns { ok: false, code: "memory.locked" } rather than hanging. Read paths take no lock, so a save still cannot stop a reader from seeing the previous snapshot.
  • The fetch ladder is hostname-level. It does not defeat IP-level blocks, TLS interception, or a proxy that terminates the connection; it does not skip certificate verification.
  • memory_recall ranks by keyword overlap only (id/topic/tags/statement/details), no embeddings: stopword-filtered, crudely stemmed word matching weighted by idf, so it is good at "which fact did I mean" and bad at paraphrase. tools/recall-bench.mjs states the current numbers (hit@1 0.95 on 20 questions); a query that shares no word with a fact still misses it.
  • resilient_fetch reads at most 2 MiB per response and returns at most 20 000 characters; bigger payloads are truncated, not streamed.

Privacy

Nothing leaves the machine. resilient_fetch makes the request you asked for; the memory tools read and write one local file.

License

MIT.