dsh-plugin: Native OpenViking memory for DeepSeek Harness (automatic session capture + memory tools + profile injection)

[zouyuanqing]

What

A community dsh-plugin that turns OpenViking (volcengine/OpenViking, self-evolving context database) into native long-term memory for DeepSeek Harness - no separate plugin framework, no second persistence layer. Two packages, two rows in the host composition, works for every agent preset:

• @deepseek-ai/dsh-memory-openviking (host plane): publishes the memory service and automatically captures sessions - buffers session/event (user/assistant surface messages) and drains at the awaited session/flush durability checkpoint into OpenViking (batchAddMessages ? async commitSession, server-side LLM distillation into preferences/entities/events). Failure-isolated: a dead server never blocks the session loop.
• @deepseek-ai/dsh-tool-memory (global registration): five thin tools (memory_write/recall/search/profile/forget) plus an automatic <memory_profile> prompt section (session working-memory overview + cross-session recalled preferences/entities/events; 1200-char budget, 5-min cache, synchronous provider with async refresh - prompt assembly never blocks on network).

Repo: https://github.com/zouyuanqing/dsh-memory-openviking (topic dsh-plugin, tag v0.1.0, MIT).

Design notes (what we verified against the live runtime)

• Plane decision: capture hooks and tool/section registration live in the host composition ($DSH_HOME/cordis.patch.yml) so memory is infrastructure, not a per-preset option - global tools.register/systemPrompt.section are visible to every scope unless a preset explicitly restricts global tools (none shipped does).
• Recall must use context mode: @openviking/sdk 0.1.0 find/search (list mode) cannot return extracted memory leaves; POST /api/v1/search/search {mode:"context"} is the modern equivalent of the deprecated /api/v1/search/recall and returns the flat <memory> block suitable for injection (see docs/sdk-0.1.0-live-notes.md).
• Commit throttling: message-count threshold (16) or time interval (60s) - otherwise chatty sessions flood the server extraction queue.
• Session ? peer isolation: per-session actorPeerId (X-OpenViking-Actor-Peer) + peerScope are wired, but OpenViking 0.4.13 dev mode has no peers (verified: viking://user/default/peers is empty), so it is a production-multi-tenant switch.

Measured

LoCoMo-style synthetic eval (scripts in the repo): 91.7% fact-level recall (short sessions), 77.8% (40-turn sessions), cross-session & temporal 100%; 58.9% token compression per long session (memory representation vs full transcript, same heuristic as the harness token meter).

Questions for the community

1. Is host-plane registration the right pattern for cross-preset capabilities, or should the roster/preset layer expose an explicit "capability mixin" mechanism?
2. Would the harness team consider a first-class memory service contract (write/recall/search/profile) so backends other than OpenViking can plug in?
3. Any appetite for an official integration package once OpenViking 0.4.x stabilizes the peer model?

[zouyuanqing]

Update (v0.2.0) - memory is now a pure global capability + experience closed-loop

Thanks to the research and live verification since v0.1.0:

1. No dedicated "memory mode" anymore. Both rows live in the host composition ($DSH_HOME/cordis.patch.yml): memory-openviking (capture service) + tool-memory (global tool/section registration). DSH's tool registry documents that scoped registrations shadow globals - global registrations are visible to every agent scope, so all presets (standard/PTC/minimal/cordis) get the five memory_* tools and the <memory_profile> section automatically. The dedicated preset was removed; the memory-guide usage skill moved to the global skill root (~/.dsh/skills/, dsh-skill-filesystem default root).

2. Experience / trajectory / reuse-tracking closed-loop (OpenViking Agent Evolution, verified live on 0.4.13):

   • PUT /api/v1/admin/agent-evolution {enabled:true} (hot-reload; dev-mode default is off - this was why experiences never extracted)
   • create_session(memory_policy.memory_types: [..., "experiences"]) ? extraction into memories/{experiences,trajectories,cases} (observed live)
   • POST /sessions/{id}/used {contexts:[uri...]} ? "when commit() is called, active_count is updated based on this usage data to optimize future retrieval ranking" - native reuse feedback
   • outcome distribution: 5 states (success/failure/partial/unknown/unfinished) per experience; GET /agent-evolution/experiences/{trajectories,outcomes}
   • project targeting: strict k=v tags (setTags(uri, ["project=x"]) + search {tags} - verified the filter narrows to exactly the tagged entries). Note: 0.4.13 lacks the newer PATCH /sessions/{id}/config session-level event tags (404) - file-level setTags is the fallback.

3. Generic, not OpenViking-specific. New design doc docs/dsh-generic-memory-design.md mirrors DSH's own dsh-storage interface-package pattern: a @deepseek-ai/dsh-memory hub (ctx.memory + MemoryBackend contract covering write/read/forget/tracking) with the OpenViking client as one adapter; Mem0/Zep/etc. implement the same contract. This also answers the discussion's question #2 - we believe a first-class memory service contract with a backend registry is the right shape for DSH, exactly like storage/llm/session-persistence are split into interface + implementation packages.

Measured numbers are in scripts/memory-eval/ (LoCoMo-style: 91.7% fact recall short sessions, 77.8% at 40 turns, cross-session/temporal 100%, 58.9% session-level token compression). Docs added: context-injection study (skill-catalog paradigm for "lightweight catalog ? model decides to dig"), open memory-system architecture survey (Mem0/Zep/Letta/A-Mem + experience-reuse patterns), and the generic design.

Repo: https://github.com/zouyuanqing/dsh-memory-openviking (topic dsh-plugin, tag v0.2.0).

[zouyuanqing]

Update (v0.3.0) - per-input targeted injection is live

Implemented the "inject relevant memory BEFORE each turn" layer, verified end-to-end in real sessions:

Mechanism (all on the host plane, every preset):

• agent/pre-step waterfall listener reads the current direct user input (claimed messages, source.kind === 'user' only), runs a semantic context search (/api/v1/search/search {mode:"context", query:<input>}) with project-tag targeting (project=<cwd dirname> via strict k=v tags) and an untagged fallback when the tag matches nothing.
• Injects one <memory_context> clue block (category + one-line summary + URI, skill-catalog style "clues only" framing: full content via memory_recall/memory_search).
• History never accumulates: each new turn surface-replaces the previous injection (session.append("user/message", msg, {surfaceOp:{op:"replace", start, end}}) - same primitive compaction-basic uses). One injected message in the surface regardless of turn count; seq-lookup makes it compaction-proof (shadowed ? falls back to append).
• Governance: one search per turn (turn-cache), ~500-token budget, input truncation, min-score filter, uri-tier (empty-text) entries dropped, any failure silently skips - pre-step never blocks.
• A scoped-event visibility detail worth sharing: host-plane rows DO receive agent-scoped events - dsh-scope's scopeTarget filter admits untagged (root) listeners globally ("events flow up the chain"), so per-input injection works globally without touching any preset.

Bugs found & fixed while verifying in real sessions (all unit-tested):

1. tool output schema {type:'string'} vs object return ? INVALID_TOOL_OUTPUT (? object + additionalProperties: true)
2. tag-targeted search returning zero entries blanked injection (? two-level fallback)
3. token-budget uri-tier entries (no text) polluting the injected block (? filtered)
4. fresh-session profile() 404 dragging down the whole profile refresh (? independent degradation)

Measured overhead per turn: one local context search (~1.1s, embedding on Ark) - budgeted, cached, and silently skippable.

Repo: https://github.com/zouyuanqing/dsh-memory-openviking (topic dsh-plugin, tag v0.3.0, 50 unit tests). Verification recipe for anyone else building on DSH: GUI trajectory tab ? check the injected <memory_context> message next to each user turn; ask the model a memory-only question with tools forbidden to prove the injection is actually used.

[leenkcool]

#1728 可以自己提PR收录 。记得互相赞赏。

[zouyuanqing]

v0.4.0 — durability & safety hardening（独立代码审查 S1–S4 / M1–M9 / E1–E5 / A1–A4 全量修复）

Tag: v0.4.0 · commit c1413d6 · CI 绿灯（74 单测 + 离线管线契约检查）

修复摘要

P0 数据正确性

• S1 失败保留 + 指数退避重试 + 磁盘死信队列（deadLetterDir），缓冲硬上限；不再“失败即丢”
• S2 agent/disposed / session/disposed 终局提交（keepRecentMessages: 0），短会话与末尾消息不再断档
• S3 per-session 状态在 drain 链收敛后回收；非捕获子代理会话不再建状态；tool-memory 注入簿记随 disposal 清理
• S4 commit 后发出 memory-openviking/session-committed 级联事件，画像缓存立即失效（消除最长 5 分钟陈旧窗口）

P1 一致性/资源/安全

• M1 每会话串行 drain 链（早 drain 与 flush 不再并发/双触发 commit）；M2 commit() 可强制提交；M3 截断在子块内部按词边界收缩，</memory_profile> 与子块闭合标签永远完整；M4 全部注入文本消毒（记忆里的 </memory_profile> 无法提前闭合注入块）；M5 memory-context 消息永不回写（自注入防护）；M6 memory_forget 限 memories/ 命名空间 + 默认非递归 + 审计日志；M7 多租户启动告警 + README 专节；M8 session/flush 网络等待封顶 2s；M9 琐碎输入跳过检索 + 同输入复用快照

P2 工程

• E1 ensureSession 接入批量写入/提交前（服务器重启后批次不再孤儿化）；E2 cordis/schemastery/dsh-tools/dsh-llm 改 peerDependencies；E3 降级路径全部落日志；E4 GitHub Actions CI + 74 单测；E5 README 声明修正（经验抽取逻辑在 OpenViking 服务端，本包只触发 commit/tags/recall）

P3 评测方法学

• 严格命中（全部 ≥2 个稳定词元出现在同一条召回条目内）为 headline，宽松口径留作对照，新增 MRR 与 precision@5；pipeline-check.mjs 用真实 MemoryService 离线回放数据集（9/9 契约断言）；token 口径拆为“存档压缩”与“端到端每请求开销”（工具 schema 从包本身实测）；数据集扩充共享项目跨会话陷阱

两个值得社区注意的实测发现（0.4.13）

1. context 检索支持 tags 过滤，但漏转发就静默失效：POST /api/v1/search/search {mode:"context", tags:["project=x"]} 实测按标签过滤。v0.3.0 的 client 忘了转发 tags 参数 → 项目定向注入一直是无标签语义检索，且没有任何报错。插件作者对“可选参数”要格外小心。
2. commitSession 会重抽整个会话归档 → 队列饱和：长会话固定 60s commit 实测把 session_commit 队列塞到 50+ 待处理（1–2 worker × 数十秒/任务），评测都跑不完。v0.4.0 起有效 commit 间隔随会话长度自动放大。用 OpenViking 做自动记忆的同学建议对 commit 做会话长度感知的节流。

另：OpenViking 记忆文件删除不可恢复（快照层不含记忆文件、无 trash）——memory_forget 已被加固为受限 + 审计。

[etzhe]

Saw this while researching the same area — cross-linking a related idea I just opened: #5333 (#5333) asks for DSH to natively auto-inject a user's own ~/.dsh/memory/ (+ its MEMORY.md index) alongside the AGENTS.md/CLAUDE.md instruction chain.

It's adjacent but not the same as this one: #1436 targets a native memory backend (automatic session capture + memory tools + profile injection), while #5333 is about giving the user's existing markdown memory convention a first-class load point — so it isn't only picked up because an AGENTS.md rule happens to point to it. Flagging in case you want the two to be linked/consolidated.