Preface¶

DeepSeek Harness (dsh for short) is an open-source Agent runtime developed by DeepSeek, with the official repository’s slogan being Everything is a Plugin: models, tools, sessions, and interfaces can all be replaced at the configuration layer without modifying the Harness core source code. When using it daily for coding, configuration modification, or troubleshooting, the main model often directly provides executable results. While these results are actionable, the concepts, trade-offs, and common pitfalls encountered during the process are not automatically preserved. A few days later when starting a new session, it is usually scattered across individual transcripts why the previous round was modified that way.

Community maintainer yuezengwu developed a tool and capability plugin called dsh-explain specifically to address this issue. It does not inject explanations into the main Agent, nor does it tie learning records to a specific working session. Instead, it maintains a cross-session learning thread locally: the work remains the original work, and the content worth learning is separated into a dedicated private channel. This article is organized after cross-verifying with the community directory page, the GitHub repository README / package.json, and the official DeepSeek Harness repository.

Two background points need to be clarified first. First, DeepSeek Harness is currently in developer preview, and the plugin explicitly adapts to 0.1.0-rc.6. Earlier private preview package version lines are not supported. Second, the DeepSeek Harness Plugin Library is an independent community directory used to retrieve and reference installation commands, and it has no official affiliation with DeepSeek / HyperGryph. It should not be treated as an official app store.

What is it¶

dsh-explain is a learning mode plugin for DSH maintained by yuezengwu, with the repository at yuezengwu/dsh-explain. The community directory categorizes it under “Tools and Capabilities”, with an MIT license, and the primary language is TypeScript. The version number in package.json is 0.1.0, and it declares a dsh.bundle patch; the client injection targets are the web-side session and settings interfaces. The GitHub repository currently has 11 stars, while the directory page shows 10 stars.

The one-sentence positioning from the repository’s Chinese README is: aggregate the content worth learning from multiple DSH working sessions into the user’s unique global learning thread; retain at most one pending explanation per source session; adapt to knowledge level and explanation preferences using the global ExplainContext.

It does not aim to “make the main model talk more verbose”, but rather to separate the explanation from the main interaction:
- The main model continues to work without knowing the existence of Explain.
- Explanations are completed by auxiliary models and only enter the learning thread.
- The learning status is stored locally in $DSH_HOME, and this status will not be copied when working sessions are resumed or forked.

The repository README also states that there are no directly duplicate plugins in the community for its product goals. Projects like dsh-advisor and dsh-memory-evolve have provided partial implementation references, but those solutions inject content into the main Agent or rely on external UIs; Explain clearly takes a different approach.

Core Features¶

The following capabilities are sourced from the repository README / README.zh-CN.md and the feature summary on the directory page, not subjective experiences from the demo environment.

One Local Learning Thread¶

There is only one learning thread per $DSH_HOME. The “Learning” Tab opened in different working sessions reads the same global data. The thread exists locally and is not copied with a specific Session.

Each top-level source session can have one pending explanation, or none. If a source session still has an unfeedbacked explanation, a second one will not be generated; other sources are not affected and can continue their own explanations. If the source Session is still in the current inventory, you can open it directly from the explanation; if the source is deleted, the history is still readable but marked as unavailable.

Active Explanations and Quick Entries¶

Users can actively initiate learning from the composer of a working session without first knowing what to ask. The commands provided in the repository documentation are as follows:
- /explain <learning request>: Request the explain agent to generate an explanation in an established or blank Session.
- /explain on, /explain off, /explain status: Toggle and query learning status.

The other two entries do not automatically submit, only writing an editable draft to the composer:
1. After selecting visible text, use the Explain quick entry in the composer toolbar.
2. On any completed assistant reply, select “Learn this reply”.

These two entries are registered by Explain itself in DSH first-party slots: the selection action is in conversation.input.left, and the precise reply action is in conversation.chat.assistant-actions. The README specifies that they do not modify or depend on dsh-selection-chat, dsh-suggested-replies, or dsh-advisor.

Auxiliary Model Scheduling and Quota¶

Active explanations, autonomous explanations, re-explanations, and compression share a global scheduler, with at most one auxiliary model request at any time. Active requests take priority over background work, but will not interrupt an already active request or re-explanation.

The default maximum number of autonomous judgments is 50 times / rolling 24 hours. The quota is retained across process restarts; failures and retries will be counted; user-triggered active explanations, re-explanations, and compression do not consume this quota.

ExplainContext and Compression¶

Explain maintains a private global ExplainContext that summarizes conversation preferences, knowledge overview, and learning progress. This context is only sent to auxiliary models and not injected into the main Agent. The main model has no knowledge of the plugin’s existence: Explain does not write to the main Session logs, modify the main model context, or block the main turn.

Auxiliary history will be compressed under two types of conditions:
- There are new structured observations or closed explanations, and the user has not operated Explain for 30 consecutive minutes.
- It is estimated that the next auxiliary request will occupy more than 50% of the selected model’s context window.

Compression only applies to auxiliary model history. The original records visible to users in the learning view will not be deleted. The first explanation entry will also save a restricted source summary of up to 2,000 characters for subsequent re-explanations; this summary is still available for re-explanation after the source Session is deleted, and will not be exposed through the learning view API.

Interface: Learning Tab and Settings Page¶

The learning thread is registered in the DSH first-party conversation.view slot, and the interface includes a “Learning” Tab. Configuration and diagnostics use the first-party settings.section, without introducing external UI hosts or requiring installation of better-sidebar.

The “Learning” entry is session-scoped, but the business data comes from the same global client store. The Hero phase of a blank Session will not display the view Tab; after entering the learning view, the composer of the current working Session is still retained. The plugin will not automatically switch you to the learning view either.

The settings page allows selecting auxiliary models, enabling learning mode, adjusting the rolling 24-hour autonomous quota, and viewing routing, quota recovery, context pressure, and the most recent compression. Ordinary configuration does not require manual YAML edits.

Local Persistence¶

Learning history, source active status, compression checkpoints, and ExplainContext are written to:

$DSH_HOME/dsh-explain/v1/thread.sqlite

Toggles and model settings are stored in $DSH_HOME/settings.yaml. The data stays on the local machine, which is what the directory page refers to as “local-first”.

Installation and Activation¶

The installation command provided on the community directory page is:

dsh plugin add github:yuezengwu/dsh-explain

For reproducible installations, the directory page recommends pinning the commit hash:

dsh plugin add github:yuezengwu/dsh-explain#commit

Replace #commit with the actual commit hash. The plugin runs with the permissions of the current dsh process, and may execute code during installation. You should inspect the source code repository and license before installing.

The repository README provides more specific details: it currently adapts to DSH 0.1.0-rc.6, and recommends installing it into the web profile. The dsh.client.platform in package.json is also web, and peerDependencies align with the 0.1.0-rc.6 set of public API packages. The installation command from the README is as follows:

npx @deepseek-ai/dsh@0.1.0-rc.6 plugin --profile web add github:yuezengwu/dsh-explain
npx @deepseek-ai/dsh@0.1.0-rc.6 web

Git repository plugins will be built during installation. If pnpm requires approval of build scripts, add dsh-explain to the profile’s pnpm-workspace.yaml according to the error message, then re-run the installation command. After installation, you need to restart the profile for the new bundle layer to be combined into the current plugin stack.

package.json also declares the Node engine as ^22.19 || >=24 and the package manager as pnpm@11.7.0. If the local Node version is too old, the build steps may fail directly.

Typical Usage¶

The following steps are all sourced from the repository documentation, not fictional operation demonstrations.
1. Install the plugin into the web profile of 0.1.0-rc.6 as described in the previous section, and launch the web interface.
2. Open the Explain section in settings, select the auxiliary model, and enable learning mode. Adjust the rolling 24-hour autonomous quota if needed.
3. Return to the working session to continue working. Explain will not modify the main model context, and main turns will proceed as before.
4. When you want to actively learn something, enter the following in the composer:

   /explain Explain why this refactoring split the state machine into two layers just now

5. You can also select a piece of text in the conversation and click the Explain quick entry; or click “Learn this reply” on a completed assistant reply. These two steps only generate an editable draft, and you will submit it after confirming the content.
6. Switch to the “Learning” Tab at the top of the session to view the global learning thread. Different working sessions will see the same thread.
7. To confirm if the plugin is running, use /explain status; temporarily turn it off with /explain off, and turn it back on with /explain on.
8. The settings page allows viewing routing, quota recovery, context pressure, and recent compression. If an exception occurs, check here first without immediately browsing SQLite.

For local development or validation, the repository also provides a method to directly install a checkout without going through npm:

dsh plugin --profile web add /absolute/path/to/dsh-explain
dsh --profile web --dump-config
dsh --profile web

This path is not necessary for daily use. Assembled Web validation requires a built DSH source code checkout, which is intended for plugin developers.

Applicable Scenarios and Notes¶

Who it is suitable for: Users who are already using the DSH web interface for development or troubleshooting, and wish to separate “completing the task” from “learning the process”. This is especially true for scenarios where many working sessions are opened under the same $DSH_HOME, and you do not want explanations to pollute the main Agent context.

What it is not suitable for: It is not a course, quiz, flashcard, or spaced repetition system. The repository’s duplicate check conclusion states that P0 will not implement these features; that is the direction of projects like dsh-edu, and Explain currently only provides an explanation loop. It is also not a general-purpose memory plugin, and will not write learning summaries back to the main model.

Points to note when using:
- Only web client injection is currently declared, do not assume that the same “Learning” Tab will appear in non-web interfaces.
- It explicitly adapts to DSH 0.1.0-rc.6. The API is still changing during the developer preview period, so you should check if the repository has been updated before upgrading to other rc versions.
- Autonomous explanations will consume auxiliary model quotas, with a default of 50 times / 24 hours. Failures and retries will also be counted.
- Learning data is stored in $DSH_HOME/dsh-explain/v1/thread.sqlite. When backing up or migrating the home directory, you need to take this file along with it, otherwise the learning thread will not be transferred.
- The quick entries only write drafts and do not automatically submit, which is an intentional design to avoid accidentally sending selections into the learning loop.
- The plugin runs with the permissions of the current dsh process. Both the community directory and official documentation remind you: inspect the source code and license before installing; pin the commit when a reproducible environment is required.

Summary¶

dsh-explain turns DSH working sessions into learning material sources without modifying the main Agent’s behavior. A local global thread, at most one active explanation per source, ExplainContext only sent to auxiliary models, plus the first-party “Learning” Tab and diagnosable settings page, constitute its currently released P0 features. The repository README records up to M6: both the selection and precise reply entries are implemented by Explain itself, and have passed the acceptance gate of DSH 0.1.0-rc.6.

Directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-explain/

GitHub: https://github.com/yuezengwu/dsh-explain