Introduction

When using DSH (DeepSeek Harness) for daily development, an inescapable issue arises: project specifications, architectural decisions, and pitfalls encountered all occur within specific sessions; once the session ends, they scatter. The common response is to manually copy important content into the system prompt, but the context becomes increasingly bloated, and it offers no control over retrieval scope or write permissions.

The dsh-knowledge introduced below makes this a standalone process: without modifying the DSH Agent Loop, the same plugin can use local SQLite or connect to a remote central knowledge base, offering on-demand retrieval, controlled write-back, and a Web management console. This article is organized by functionality, installation, and typical usage.

Plugin Introduction

dsh-knowledge (npm package @lemoncat7/dsh-knowledge) is maintained by lemoncat7, licensed under MIT, and belongs to the “Memory” category in DSH plugins.

Compatibility: Official version 2.3.4 is built and deployed for DeepSeek Harness 0.1.2-rc.1, requiring Node.js ^22.19.0 || >=24.0.0. The plugin is a standard DSH profile bundle (the dsh.bundle.patch in package.json points to cordis.patch.yml), and does not require a separate knowledge base container to run after installation. Simply restart the corresponding DSH profile after installation or update.

Core Features

Dual Backend: Local SQLite and Remote Central Service

The local backend is based on SQLite, using WAL, FTS5 full-text search, atomic transactions, complete version history, and idempotent extraction tasks. The remote backend is a central knowledge base with an authenticated HTTP API, serving as an access point for other DSH clients and future desktop versions. Local and remote Providers use the same interface.

Mode switching is done in the “Knowledge Base Connection” card under DSH “Settings → Plugins”: select the local source, or fill in the central service address and read-only client token, and save to verify and switch the Provider in real-time.

It is important to clarify that the remote mode does not perform implicit bidirectional synchronization: creating or modifying tools will not automatically mount the knowledge base, nor will it fall back, double-write, or sync to the other side. The result will explicitly return the actual write target, local or remote.

Write-back Performed by Independent Extraction Calls

The main model does not expose knowledge_write. After each round of answers is complete, the plugin uses a single independent extraction call to determine if knowledge was generated and to write it back. The write-back result is only used to display UI state and is removed before the next model request, not occupying session context.

Write-back strategies are globally divided into “Rigorous” and “Proactive”, stored in the authoritative knowledge base service, and remote clients automatically follow central settings.

Multiple knowledge bases can be created, with separate descriptions, default tags, extraction requirements, and dedicated write-back models; if no dedicated model is set, it follows the current session model.

Mounting only indicates “optional”: when no knowledge base is mounted, there is no recall, extraction, or write-back; mounting also does not imply that write-back is required for every answer.

Mounting and Permissions

Mounting is divided into Project and Session levels; Sessions inherit from the Project by default and can be independently overridden or disabled. Each mount supports three write modes: Recall Only, Audit Write, and Direct Write, and can be configured with include/exclude tags and additional extraction requirements.

Document change decisions are categorized into create / update / conflict / skip. Original text revisions use a unique old text anchor and the target version, executed atomically on the full document by the server.

Search and read operations are forcibly limited by the server based on current session mounts, project scope, and include/exclude tags. Read handles are signed and limited to the current session.

On-demand Retrieval

Before answering, the plugin provides a bounded mount map via the DSH official prompt assembly interface and automatically recalls up to 3 summaries that reach the relevance threshold, without automatically injecting the full document. When full content is needed, perform finding the base, then searching, and finally reading the document:

  1. knowledge_base_search: Find the base
  2. knowledge_search: Search specific base
  3. knowledge_read: Read document

When explicitly requested by the user, the model can also call knowledge_base_create / knowledge_base_update to create or modify knowledge bases (description, tags, write-back strategy, and dedicated write-back model).

Web Management Console and Note Workspace

The plugin comes with a responsive Web management console covering overview, document tree and Markdown editor, AI candidate review, and client token management. Knowledge base management is split into two workspaces: “Knowledge Bases” and “Project and Session Mounts”, supporting instant search by name, description, tags, and model.

The document interface features a note-taking software-style two-column layout paired with a dedicated note workspace: multi-level directory tree, Markdown/text file editing, image and PDF in-place browsing, page history and recovery, sharing, and import. Notes do not participate in knowledge retrieval, auto-recall, or AI write-back by default.

Knowledge documents reference notes or files via a structured “Linked Notes” list with relationships bound to stable IDs; old note:// references are safely filled back during upgrades. Documents can be marked as “Resolved” or “Collected”, forcing them into read-only archival, which requires reopening to edit or write back.

The DSH browser plugin displays “Knowledge Base” below the left workspace, opening the management panel within the current page. The interface supports light/dark themes, keyboard shortcuts, and narrow-screen layouts; status labels do not rely on color.

Installation and Enablement

Install the official version from npm:

dsh plugin --profile web add @lemoncat7/dsh-knowledge

When a specific version is required, append @version after the package name, or download a pre-built package from GitHub Releases and install it locally. The uninstall command is as follows:

dsh plugin --profile web remove @lemoncat7/dsh-knowledge

The plugin is a standard DSH profile bundle and does not require a separate knowledge base container to run. Restart the corresponding DSH profile after installation or update. For the Web version, the restart command is:

pnpm dsh web

Typical Usage

Local Mode Configuration

The default configuration uses the SQLite file in the DSH home directory:

backend: local
databasePath: !!js dshHomePath('knowledge/knowledge.sqlite')
extractionEnabled: true
defaultScope: project
autoRecallLimit: 3
autoRecallMinScore: 0.2
recallMaxChars: 5000
exposeApi: false
exposeWeb: true

The meaning of this configuration: the database is located under knowledge/ in the DSH home directory; the default scope is project; auto-recall up to 3 items with a relevance threshold of 0.2 and a maximum of 5000 characters; the authentication API is disabled by default, and the management console is enabled by default.

Creating and Modifying Knowledge Bases

Example request body for creating a knowledge base:

{
  "draft": {
    "name": "DSH Project Specifications",
    "description": "Only match dialogues related to DSH plugin development, architectural decisions, and deployment specifications",
    "defaultTags": ["dsh", "project-rule"],
    "extractionInstructions": "Only include conclusions that have been confirmed and can be reused across sessions"
  }
}

description limits the topic scope covered by this base, extractionInstructions further limits inclusion rules, and defaultTags are the default tags during write-back. For partial modification of tags or description, use PATCH /knowledge-bases/:id:

{"patch":{"description":"...","defaultTags":["..."]}}

Deploying as a Central Knowledge Base

When deployed as a central service, enable the authentication API and Web via configuration:

exposeApi: true
apiToken: !!js process.env.DSH_KNOWLEDGE_API_TOKEN
apiPrefix: /knowledge-api/v1
exposeWeb: true
webPath: /knowledge

DSH_KNOWLEDGE_API_TOKEN must be at least 24 characters, and the database only stores summaries. The server does not have TLS, so non-loopback deployments must be placed behind an HTTPS reverse proxy.

Client tokens use Bearer Token, storing only SHA-256 hashes, and support read / propose / write / admin permissions and revocation. With the configuration above, this DSH instance’s authenticated HTTP API can serve as a central knowledge base for other DSH clients.

Use Cases and Precautions

Suitable scenarios:

  • Individual developers: Accumulate project specifications, architectural decisions, and experience locally, recalling on-demand across sessions.
  • Teams: Deploy a central knowledge base, with multiple DSH clients connecting via tokens, with write-back strategies following central settings.

Precautions before use:

  1. The plugin runs with the permissions of the current dsh process; check the source code and license before installing (this project is MIT).
  2. Version matching: Official version 2.3.4 is built and verified for DeepSeek Harness 0.1.2-rc.1.
  3. When no knowledge base is mounted, there is no recall, extraction, or write-back; mounting only indicates optional.
  4. Under the local management console, any user with access to DSH Web has local management permissions; when exposing DSH to the public internet, use a reverse proxy to protect the entire site with login.
  5. Failed extraction marks idempotent tasks as failed; failed tasks can be claimed for re-execution at most twice without blocking the next round; if extraction output reaches the model limit, it retries once with double the budget (max 8192 tokens).
  6. Deleting notes referenced by knowledge documents will be rejected; permanent deletion of notes must be explicitly requested in the current message; authorization does not extend from historical messages.
  7. Share imports retain SSRF protection and can be configured for trusted origins via trustedShareOrigins.

Summary

The idea behind dsh-knowledge is to keep the Agent Loop intact, turning long-term memory into a mountable, permission-limited, and reviewable knowledge base: local single-machine use out of the box, switching to a central service when sharing is needed, with permissions enforced by the server. If your DSH instance needs to accumulate knowledge across sessions, you can install and try it following the steps above.

Directory page (community-maintained plugin directory, no affiliation with DeepSeek official): https://www.skillhub.cn/plugins/lemoncat7/dsh-knowledge

GitHub: https://github.com/lemoncat7/dsh-knowledge