kater20070212/deepseek-self-harness-plugin1

deepseek-self-harness-plugin

Self-Harness: a DeepSeek Harness plugin that mines your own session logs and evolves the operating rules you run on (based on arXiv 2606.09498).

包名
deepseek-self-harness-plugin
版本
0.1.0
许可证
MIT
最近更新
2026年8月17日

安装

此插件尚未提供可验证的 bundle,或兼容性检查未通过。请先阅读仓库说明。 阅读完整 README ↗

Usage

The everyday loop (no manual steps)

  1. Work normally. Every session you finish is mined automatically in the background (session/disposed → 5 s later → evidence clustered by terminal cause).

  2. Next session, you (and the agent) see the nudge. If new evidence was found, the system prompt gains a hint like:

    [self-harness] Background mining found 3 new evidence bundle(s) in your session logs. Consider running self_harness_propose

  3. Tell the agent to act — in any session, simply say:

    Run a self-harness round.

    The agent then runs the loop: self_harness_propose → submits candidates → self_harness_validate.

  4. You are the gate. Each candidate shows a diff (the exact rule being added or replaced) with its evidence cluster, rationale, and risk. Accept to apply — the rule goes live at the next model step; reject to only log it. When interactive prompts are unavailable, answer in conversation instead (the agent applies your decision with self_harness_apply).

  5. Everything is reversible. Every applied edit is a version in the lineage log with a backup; roll back any time.

One manual round, step by step

you:   Run a self-harness round.
agent: self_harness_mine                    → 4 evidence clusters (e.g. tool-error:not-found ×9 …)
agent: self_harness_propose                 → bounded brief (rules + clusters + contract)
agent: self_harness_submit_proposal         → K candidates, each anchored to one cluster
agent: self_harness_validate   → diff preview → you accept/reject
accepted → rules document hot-updates → next model step follows the new rule

You can also drive any stage yourself by name (self_harness_status, self_harness_rollback).

Example: what an accepted edit looks like

Evidence cluster tool-error:not-found (9 occurrences, e.g. "git: command not recognized" after a tool was called without checking it exists) produces the candidate:

- (end of document)
+ - Before running an external command, check it exists (e.g. Get-Command / command -v);
+   when a tool is missing, use an equivalent alternative instead of calling a
+   known-missing tool.

Lineage entry recorded for it:

{ "version": 1, "cluster": "tool-error:not-found", "surface": "harness-doc",
  "op": { "position": "append", "insert": "…" }, "status": "applied", "by": "user" }

Inspect and roll back

  • self_harness_status — version, document preview, lineage, pending candidates, evidence summary, background-mining stats, persistence path.
  • self_harness_rollback — restore any of the last 20 versions (omit toVersion for the previous one).
  • State lives in .self-harness-state.json in the workspace root; it survives restarts and plugin updates.

Model-facing tools

ToolStage
self_harness_mine① Weakness mining over recent sessions (manual run)
self_harness_propose② Returns the bounded proposal brief (then the model proposes)
self_harness_submit_proposal② Submits K candidates, each anchored to an evidence cluster
self_harness_validate③ Diff preview + interactive accept/reject gate
self_harness_apply③ Explicit accept/reject (fallback / scriptable gate)
self_harness_statusLineage, pending candidates, evidence summary, background stats
self_harness_rollbackRoll back the rules document to any of the last 20 versions

A typical round, driven by the agent itself:

self_harness_mine → self_harness_propose → self_harness_submit_proposal
→ self_harness_validate (you see the diff) → accepted edits are live next step

Or simply tell the agent: "Run a self-harness round."