dsh-auto-memory — native persistent memory for your agent (Claude Code-style MEMORY.md, plus auto-consolidation & forgetting)

[AskTheWay]

Repo: https://github.com/AskTheWay/dsh-auto-memory · npm: dsh-auto-memory · bilingual README

I kept starting every session from zero — re-telling the agent who I am and what I am building. dsh ships no memory subsystem (the MCP bridge configs need external servers, and nothing reaches the model unless it decides to call a tool), so I ported Claude Code's auto-memory model as a native plugin:

dsh plugin --profile demo add dsh-auto-memory

What it does:

• Typed memory files (user / feedback / project / reference) under $DSH_HOME/memory — plain Markdown, one file per memory, hand-editable
• MEMORY.md index injected into every system prompt: re-evaluated per step, byte-budgeted, and absent entirely when the store is empty
• Six tools (memory_write / read / list / delete / prune / delete_all) with Claude Code's write discipline — dedupe-and-update, absolute dates, [[name]] cross-links
• Per-workspace + user-level scopes, so projects don't leak into each other. No servers, no embeddings — just files

Why native instead of an MCP bridge: with MCP, memory only exists when the model decides to call a tool, and you run an external server. Here the index rides the system-prompt assembly that already happens every step, so recall is unconditional. (If you need semantic search over thousands of memories, the MCP servers are still the better fit.)

0.2.0 adds things Claude Code doesn't have:

• Auto-consolidation: a background pass at root-session end extracts durable new facts and files them as memories (opt-in autoSummarize, deduped, capped, silent on failure)
• Forgetting: memory_read counts references; staleAfterDays soft-hides stale zero-read memories from the index; memory_prune lists or deletes them
• memory_delete_all requires human approval — the model can't self-confirm a bulk delete

Crash-safety got the most attention: cross-process locks with orphan-lock recovery, atomic writes, and a guard for the case where a memory named memory silently destroys MEMORY.md on NTFS. 67 tests.

No-key demo:

git clone https://github.com/AskTheWay/dsh-auto-memory && cd dsh-auto-memory && node scripts/demo.mjs

On the awesome-dsh-plugin list, so it shows up in dsh-market too. Feedback welcome — especially on consolidation prompt quality and a sensible default for staleAfterDays.

[AskTheWay]

Bro, give me some advice.

[Gladess1102]

非常好的插件，轻量化记忆是对的。但你是如何解决“如何触发自动记忆”的阈值，又如何在对话中自然的通过召回回忆起该有的跨对话记忆的？这对我很重要，期待您的解答

[AskTheWay]

谢谢!这两个问题正好是设计里花时间最多的地方,分开说:

1. 写入触发的“阈值”——两层机制:

• 显式写入(提示词纪律,而非数值阈值): 系统提示词里的固定指导段给判断标准(用户陈述身份/偏好 → user;纠正工作方式 → feedback;跨会话有价值的目标/约束 → project;外部资源 → reference),工具描述再约束“先查重、同名更新、不存代码库/AGENTS.md 已有的内容”。这和 Claude Code 的做法一致——实践里模型对“值不值得记”的判断比任何数值规则都稳。
• 自动固化(0.2.0,确定性触发): autoSummarize: true 时,根会话结束(挂 agent/disposed,子代理生命周期被过滤)触发一次后台 LLM 总结,提取值得长期保留的新事实写入。三个限流:写入前查重(同名即更新)、单次条数上限(autoSummarizeMaxMemories,默认 5)、任何失败静默不影响会话。选“会话边界”而不是“每 N 轮”作触发点,是因为它天然无偏、不会轮中重复提取。

2. 召回的“自然性”——靠索引常驻,而不是靠模型想起来:

MEMORY.md(一行一条 name + description)注入系统提示词,每个请求都在场——模型不需要“决定要不要查记忆”,开局就知道自己记得什么。这是与 MCP 桥接最本质的区别:MCP 下模型不主动调工具,记忆就不存在。两段式:常驻的只有索引(有字节预算 maxBytes),正文按需 memory_read 拉取;0.2.0 还会把正文里的 [[name]] 链接展开一层摘要,减少二次调用。

“自然”的另一半在 description 的质量——它本质是写给未来会话的钩子,所以指导段要求一行讲清这条记忆是什么。

诚实的局限:没有语义检索(无 embedding)。索引到几百条后,靠 description 的字面相关性会变弱——轻量纯文件是这个项目的刻意取舍;几千条记忆 + 语义搜索的场景,MCP 服务器仍然更合适。

更细的取舍在 docs/design.md,欢迎继续讨论。