dsh-memory
Cross-session semantic memory for DeepSeek Harness — installed into any profile, so your agent actually remembers you across sessions.
🌐 English · 简体中文
dsh-memory registers three tools for the web / headless profiles, so your agent can remember you across sessions:
memory_add— persist a fact worth keeping long-term, auto-vectorized on the way in.memory_search— recall relevant facts by semantics (cosine similarity), with a keyword fallback.memory_update— correct or retire an existing memory (supersede/retract/restore/verify/edit/set/link); the superseded entry stays traceable instead of being deleted./mem <question>— type this in the composer and the agent will callmemory_searchfirst (results render as a collapsible tool card), then answer from memory.
Under the hood: Zhipu embedding-3 (2048-dim) + SQLite (node:sqlite) + cosine similarity. Zero new infrastructure — no vector database, no sidecar containers. Hundreds to thousands of memories recall in milliseconds.
Why
Your agent forgets everything between sessions. dsh-memory gives it a durable, semantic recall layer without adding a new service to run. It solves the "who am I / what did we agree on" problem with a few hundred bytes of SQLite and one HTTP call per write.
Features
- Zero-config, never crashes — a missing Zhipu key, a missing database, a missing
toolsservice, or a failing embedding call all degrade gracefully. This plugin will never take the DSH tree down (see Design guarantee). - Semantic recall with keyword fallback —
memory_searchscores by embedding cosine similarity first, then weights keyword hits; when embeddings are unavailable it falls back to pure keyword (bigram) matching. - 8s embedding timeout — on a bad or missing network it fails fast and falls back to keyword search instead of hanging the session.
- Correction chain, not silent merging — when a fact changes, pass
replacestomemory_add: the old entry is stampedsuperseded+superseded_byand kept for traceability (it drops out of default search), while the search that would have returned it now surfaces the corrected conclusion — even when that conclusion only ranks 12th. Writing still runs one cosine pass over the library first, but it reports near-duplicates as a hint (replaced) and never silently merges two different facts. - Annotate, never filter —
scope, date and status are shown as information; they are never used as hard filters, and relevance is reported as high/medium/low instead of a threshold deciding "nothing found" (measured: genuine and absent answers overlap completely in cosine similarity). Entries over 800 chars are truncated by default, with the full length shown;full: truereturns the whole thing. - SQLite WAL + busy_timeout=5000 — applied when the DB opens; concurrent writers (e.g. DSH web + the Jarvis brain sharing one library) no longer hit
SQLITE_BUSY.
Design notes, the measured evidence behind each choice, and the assumptions that were disproved by data (so nobody re-walks them) live in LIFECYCLE.md.
Installation
This plugin follows the official DSH bundle convention (dsh.bundle in package.json), so dsh plugin recognizes it and activates it as a configuration layer — not a plain dependency.
Install into the target profile (e.g. web):
dsh plugin --profile web add dsh-memory
After installing, restart DSH web for it to take effect (the bundle layer is only composed at startup):
systemctl restart dsh # or restart however you run DSH
Local / pre-release install:
# Put this directory into the profile's node_modules and append "dsh-memory"
# to dsh.profile.bundles in package.json, then restart.
Configuration
Everything is optional — skip it all and the plugin still works (falling back to keyword search):
| Config | Description | Default |
|---|---|---|
enabled |
false disables tool registration |
true |
semantic |
false skips embeddings, keyword-only |
true |
memoryDbPath |
SQLite database path | ~/.dsh-memory/memories.db |
zhipuEnvPath |
Path to the Zhipu credentials .env file |
~/.dsh-memory/.memenv |
forceMemoryWords |
Force-memory signal words (array). When any word appears in a user message, the agent must call memory_add first, then answer |
[] (disabled by default) |
forceMemoryWords example (set in your profile's cordis.patch.yml, not in the public repo):
- id: dsh-memory
config:
forceMemoryWords:
- 记住
- 重要
- 珍贵
- 特别
- 务必
- 一定
- 必须
Zhipu credentials are read from environment variables first, then from the file at zhipuEnvPath:
ZHIPU_API_KEY=your-zhipu-key
ZHIPU_BASE_URL=https://open.bigmodel.cn/api/paas/v4/
Get a Zhipu key for free at open.bigmodel.cn (embedding-3 is billed per use).
Design guarantee
This plugin was born from a real incident: a misconfigured plugin sent a DSH web profile into a crash-loop. So dsh-memory is deliberately defensive:
apply()is wrapped in an overalltry/catch— no error is ever thrown up into the DSH tree.injectonly declarestools(a servicedsh-basealways provides). It does not depend ondsh-llm,agents, orhttp.- A missing key / database / service, or a failed embedding call → it logs and degrades, never interrupting startup.
- Errors raised inside a tool's
execute()are caught and returned as ordinary results, never bubbling up into a session exception.
Tools
memory_add— write a fact worth remembering; vectorized automatically.memory_search— semantically recall the most relevant facts for a question.memory_update— supersede / retract / restore / verify / edit / set / link an existing memory (superseded entries stay traceable)./mem— a manual override: "search memory first, then answer." If you're not sure the agent will recall on its own, type/mem <question>and it will run a semantic search, inject the results, and answer from them.
Storage schema
memories(id, text, category, source, created_at, updated_at,
status, kind, kind_source, scope, scope_source, superseded_by, last_verified_at)
memory_embeddings(memory_id, dim, vector) -- 2048-dim JSON array
memory_links(a, b, relation, created_at) -- links between related-but-different entries
memory_meta(key, value) -- schema_version
No comments yet. Be the first to write one.