← 返回列表
未验证
一个宿主平面 DeepSeek Harness Cordis 插件:把记录下来的经验蒸馏进
尚未跑自动兼容性验证,可查看页面内的依赖与入口分析。 · 最近上游提交 2026/9/15 · 已提供中文文档
DeepSeek Harness 宿主平面插件:一个有界经验层,将记录的经验教训提炼为用户全局 AGENTS.md 中受管理的一个区块,每轮都会加载。
综合分
29.1
GitHub 分
29.1
用户评分
—
★ Stars
0
周下载量
—
安装插件(需先安装 dsh CLI 引擎:npm install -g @deepseek-ai/dsh)
dsh plugin --profile web add ABccgh/dsh-agent-memory该插件未发布到 npm,走 GitHub 源安装(pnpm 若拦截 prepare 脚本,按其提示在 pnpm-workspace.yaml 的 allowBuilds 中放行后重跑)
信任档位:已验证本站已于 0 天前真实安装成功
- 是什么
- dsh 原生插件 · chat
- 装得上吗
- 本站已真实安装成功(非静态推断)
- 安全吗
- 本站尚未对该插件做风险分级(暂未覆盖,不等同于无风险)
- 还在维护吗
- 活跃:最近一次提交在 10 天前
档位由下列信号合成:本站实装验证(真实安装,当前最高到 L4)· 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。 验证判据与等级说明 →
🟢实装验证通过· 2026/9/25
由本站实装验证器在真实 dsh 环境安装成功,非静态推断。
数据截至 2026/9/24(元数据每日更新 · 实装验证按队列轮转,单条结论的验证时间见上方)
用户评分
还没有人投票,来当第一个
订阅周报,不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
由 DeepSeek 最新模型翻译生成dsh-agent-memory 一个宿主平面 DeepSeek Harness Cordis 插件:把记录下来的经验蒸馏进 ~/.dsh/AGENTS.md 里一个受管区块,而那个文件每个会话每一轮自动加载。 它与 preset 无关——因为是宿主平面,所以本部署的三个 preset(dsh-smith / dsh-forge / dsh-ck3-mod) 都获得它,不需要改任何一个 preset。 它解决的是哪一半 本部署原本就有四层记忆(AGENTS.md、技能、DECISIONS.md/PROJECT.md/BOARD.md、会话)。存储从来不是失败的那一半,检索才是。 真实代价,两个都有记录:一份「建索引要 225 秒」的估算,真实值是 2.4 秒——差 95 倍,而那条订正 早就写在 DECISIONS.md 里,当时的 agent 没读;另一次,二进制里两个字符串的相邻位置被当成 功能相关的证据,据此写出了一份指向不存在功能的「三步解锁」指引。 所以这个插件只做一件事:让必须每轮都对的那几条,不再依赖 agent 想起来去读。 两个工具 | 工具 | 作用 | | --- | --- | | memory_remember | 向 LESSONS.md 追加一条经验(结论 + 为什么 + 证据) | | memory_consolidate | 把 LESSONS.md 蒸馏进 ~/.dsh/AGENTS.md 的受管区块。写完不 consolidate 等于没写 | 受管区块由两个 HTML 注释标记界定: ... 它只重写这两个标记之间的字节。 标记之外一个字节都不动;若发现开始标记而没有结束标记, 它抛错拒绝而不是猜到哪里结束——那个文件归使用者所有,覆盖它是数据丢失而不是格式问题。 预算是硬的,这是设计而不是参数 AGENTS.md 每一轮都在上下文里。所以受管区块有上限(默认 16384 B),而且超限时工具 报错拒绝并列出最大的条目,绝不静默截断——截断会让机制看起来在工作而实际在丢经验, 比报错更糟。 把这个换算成直觉:一份典型的仓库 AGENTS.md 已经 30 KB 上下,而笔记层 DECISIONS.md + PROJECT.md 常有 372 KB ——永远不可能整体注入。 经验区块存在的意义就是只放这两层里那几条必须每轮都对的。 maxBytes 与 maxSourceBytes 的区别值得知道:前者截断一个渲染批次,后者整个静默丢弃一个文件 (默认 1 MiB)。本插件只写进那个已经在被读取的文件,不新增任何被发现的文件。 安装 dsh plugin --profile web add 然后在 profile 的 cordis.patch.yml 里加一行(name 必须是包名,不是目录): - insert: - id: agent-memory name: 'dsh-agent-memory' config: lessonsPath: 'C:\Users\\.dsh\agent-memory\LESSONS.md' targetPath: 'C:\Users\\.dsh\AGENTS.md' maxBlockBytes: 16384 改完要重启宿主才加载新的模块。区块内容本身不需要重启:dsh-agent-instructions 每轮都会重新校验指令文件。 自证 node test/falsify.mjs # 29 assertions, offline 两条断言是重点:标记之外的字节逐一保全,以及有头无尾标记时抛错。 另有 resolve 与 lstat 的语义断言——fs.resolve 不是存在性检查(它可以为不存在的路径返回稳定目标), 存在性是 lstat;把这个弄反的初版拒绝写任何尚不存在的文件,是测试抓到的,不是读代码看出来的。 ⚠️ 已知能力边界:在沙箱会话里只生成、不落盘 实测:在 workspace-write 策略的会话里,两个工具都会以 file access denied under workspace-write mode 失败,而同一会话的 dryRun 读得到。 机制在接缝上而不是路径上:插件写文件走的是被沙箱包住的 fs,dsh-fs-sandbox 按 ctx.sandboxPolicy.defaultMode 逐次判定,workspace-write 只允许写工作区之内。 这是保护在起作用,不是缺陷:agent 不该能悄悄改掉那份指导每个会话的文件。 后果要如实说清楚——区块内容是正确且完整的,只是该会话无法把它落盘。 要落盘需要一个策略允许写到工作区之外的会话,或由有该权限的写入者执行。 不得夸大 这不是学习。 本插件没有权重更新路径;模型不会因为积累了经验而变聪明。它做的是保证检索。 因此边界明确:对没有人记录过的教训它一无所知;而如果一条经验被记录、被 consolidate、被注入, 行为依然没变,那失败已经从检索转移到遵从——任何加载机制都修不好后者。 许可 MIT。与 dsh-smith 同作者。