动态

@​mattheliu 你好，补充一个状态更新，也想请教一下当前推荐的处理方式。 我们现在已经确认，dsh-hub-workshop 的 repository maintainer map 中登记的 admin maintainer 是你。 我的 Submission #23： https://github.com/omdsh-dev/ds

大家好，我们开发了 Governed Workflow for DSH： 这是一个面向 DeepSeek Harness 的治理工作流插件，主要用于让 AI Builder 在明确的 GitHub 任务权限下执行工作，并记录可审查的过程证据，降低 Agent 越权修改、误操作和自行扩大任务范围的风险。

补一条不同路线，先说清它不解决楼主的原始问题：Persisto Mate（我自己的项目，MIT）不做 Codex / Claude Code 的记忆迁移，要迁历史会话的话楼上 dsh-deja、deepDDW 的具名适配器才是答案。

如果要的是 Codex / Claude Code 里以前的会话本身（某个问题当时怎么修的、最后定了什么），其实可以不迁移：dsh-deja 直接读 ~/.codex/sessions、~/.claude/projects 这些已经在磁盘上的会话文件，DSH 自己的 ~/.dsh/sessions 也读，建一个本地索引。装上就能搜到装之前几个月的

recall 也更新到 v0.7.0 了，补个近况 + 定位澄清（和 ccch713 的 deepDDW 正好互补）： recall 的路线是「零迁移」——不导入、不建新存储，直接检索 DSH 自己的会话库（SQLite FTS5 持久化索引 + CJK 子串/多词 AND 回退）。适合「上次这个问题怎么解决的」这类从历史会话召回的场景；deepD

deepDDW 作者路过（ccch713/deepddw，MIT）。先说定位：它比上面几个轻量插件重——是一个自托管的 LAN 团队记忆服务（DSH 官方插件 + 网关），适合多设备/多人共享记忆的场景；单人轻量需求用上面 YYTbit 的 bridge 系列或 sage-mem 就

我拿我这边的真实数据跑了一下，补上了基准，也写进 README 了： 语料：31 个会话、18.7 万事件，未压缩 104 MB / zstd 49.7 MB，索引 8187 条文本、落盘 15 MB 建库：首次扫日志约 4.7s、插 FTS5 约 190ms，冷启动第一次 recall 赶得上 10s 超时；之后重启走增量 reconcile

多谢，我分条回一下。 授权这块：官方 sessionQuery 是 context-wide 的，README 写明 "No caller authorization"——会话数据对工具全可见，约束要由工具自己做。我的做法分两层：默认把当前 agent 的 cwd 放进 sessionFilters，只搜这个目录下的会话；只有当模型真的传了 all_pro

感谢分享。这条直接检索原始会话文本的路线，和侧重可审计、可交接的文件化记忆是互补的；通过 ctx.sessionQuery 回查原会话文本，也可以减少二次提取带来的信息损失。有两个实现边界想请教： 开启 all_projects: true 后，跨项目或会话召回的访问范围如何约束？如果该能力会作为模型可调用工具注入，调用方授权与结果过滤由哪一

楼上各位的记忆方案大多走"笔记提取/桥接"路线，我补一条不同路线，正好命中官方留白——检索原始会话原文： 官方 @deepseek-ai/dsh-session-query 的 README 自己写明还缺 "No model-facing tool" 和 "No caller authorization"（搜索服务在，但模型没有

@yangfei222666-9 我已经把这次讨论整理成设计 Issue：https://github.com/creativedswork/dsh-expmem/issues/1 我们先在 Issue 里确定 status、evidence、schemaVersion 和冲突语义。四模型管线保持为外部可选评审，报告可以作为 `review-r

@wangcan26 这份回答质量很高,三个边界承认得干净 —— 尤其是"SHA-256 证明的是导入了哪份内容,不是内容为真"这句,和我们踩过的坑完全一致。接受合作邀请,先交上我们的实战笔记: ① status 状态机:建议 verified 带"验证依据",否则会变成橡皮图章 我们现在的教训库用的是 candidate → applied 两级

你提到的三个问题，正好对应 ExpMem 0.2.0 目前的边界。逐项回答： 来源和时间戳：有基础信息，但还不是完整审计链。 导入记录会保存 provider、原始文件路径、SHA-256、createdAt、updatedAt 和 workspace；Agent 主动写入的记录还会保存来源 Session。 这里

这条信息量很大,收藏了。我们是完全反向的路线,正好互补:你们 3 个月自动沉淀 ~800 条,我们半年手动写 ~17 条教训 + 19 条规则,数量差 50 倍 —— 但我们这边每条都强制带证据(报错原文/复现命令),无证据不写。两个真实问题想请教: 错误记忆怎么防:800 条自动沉淀里,有没有出现过"当时对、后来被证明错"的记忆被召回?"自

可以直接迁移。我们做了 DSH ExpMem，当前版本是 0.2.0。 ```sh dsh plugin --profi

我们的做法:把"记忆"拆成四层文件,不追求自动捕捉,追求可审计、可交接: MEMORY.md —— 身份 + 状态快照(我是谁 / 在管什么 / 待决策)。每个新会话第一件事读它,断片后十秒恢复上下文 LESSONS.jsonl —— 教训库,每条强制带证据(报错原文 / 文件路径 / 复现命令),candida

补一个定位不同、刚发布的方案：dsh-goodmemory v0.1.0。 先把边界说清楚：它目前不负责批量导入 Codex / Claude Code 已有的 MEMORY.md 或历史会话。如果楼主的核心诉求是原文件直接迁移，上面提到的 brid

楼上给的 DSH 原生桥接插件是一条路。补一个 Pi 生态里的成熟选项：pi-hermes-memory（跨会话持久记忆 + SQLite FTS5 全文搜索 + 密钥扫描），通过 pi2dsh 原样挂到 DSH 上即可使用。 刚在 DSH 上真机跑通的跨会

补充一下我上一条回复里漏掉的关键能力，正好回应楼主「迁移」的诉求： 历史会话可以批量导入，不需要从零积累。 我上一条说「不需要迁移」不准确——SGME 每个适配器都带 import_history 全量导入脚本，把接入前的存量会话一次性补录： 幂等可重跑：已导入的自动跳过，重复执行安全 保留真实时间戳：每个会话按实际发生时

@ylwl1997 确认了，之前 0.1.1 没发成功。现在 claude-bridge 和 meta-memory 的 0.1.1 已经发到 npm 了，inject 已修复为 ["systemPrompt"]。请再试试： ``` dsh plugin --profile your-profile add dsh-plugin-claude-bridge

已修复，v0.1.1 已发布，补上了 inject: ["systemPrompt"]。感谢反馈！

又做了一个：dsh-plugin-meta-memory 和 claude-bridge 不同，这个是原生的记忆系统： 单元式组织：debug-auth-module.unit 这种命名 每个记忆有 brief（快速扫描）和 full（完整细节）两版 自动注入相关记忆到上下文 带 CLI 工具 mm，支持 init/list/read/se

在这台 Windows 11 机器上把 koffi.view 那条分支做了最小复现尝试，结果值得记录：复现不出来，而且发现旧实现比讨论里以为的要安全。 环境：Node v24.16.0（本机自带）和 v24.18.1（官网便携版）都试了，koffi 3.1.5 和 3.3.1 都试了。复现脚本用 msvcrt 的 malloc 分配堆内存，写入带双 \0

补充一个已复现并修复的 case + 三条给维护者的具体建议。 环境：Windows 11 / Node v24.16.0 / koffi 3.3.1 / dsh 0.1.5-rc.3（本地 launcher 启动，非 npx）。 **这个 case 属于「退化/残留 host」这一支，不是 koffi.view / Node 24 崩溃那一支。

对齐一下结论，我从当前 master 源码核对了一遍，kittimzhe 说的基本准确，但有一个地方想修正： readUtf16 现状（packages/host/directory-picker-native/src/win32-dialog-bindings.ts）： ```ts const bytes = Buffer.from(koffi.vie

补两点： 路径截断和 worker 崩溃是两个坑，别混。中文路径被截断（#800 那族）在 0.1.2-alpha 线已经修了：readUtf16 改成了扫双 \0 结尾（packages/host/directory-picker-native/src/win32-dialog-bindings.ts）。但 npm 的 latest

这条与中文路径截断不同，更像是目录选择请求的异步 worker/浏览器能力边界：Firefox 需要把“请求已启动、对话框打开、用户取消、worker 退出、结果已提交”分成可观测状态。 建议补充： 为每次 picker 请求生成 request/generation ID，UI、WebView bridge、native worker 和最终 Wo

我这里提供一个临时解决方案293

补充一个按“最后成功边界”分流的办法：相似的 Windows picker 症状目前至少有四条不同分支。 对话框能打开，选完目录后 worker 直接退出：优先做干净的 Node A/B。当前讨论里的聚焦复现是 Node 22.23.2 成功、Node 24.18.1 在 UTF-16 路径物化阶段 abort；这不等于所有 Node 24

更正我自己上面那条。 我在 08-15 09:21 说这个崩溃「大概率也是 koffi 坏预编译那条链」。那是错的，而且 @echo804 在我之前五分钟就已经用复现排除掉了这条，我没读就发了。 他给的根因是 win32-dialog-bindings.ts 里 readUtf16 用的 koffi.view(addr, 32768)

补：Win32 目录选择器在 Node 24 下必崩 —— 根因 + 修复 + 现成分支（可 cherry-pick） 建议作为讨论 #30 的补充回复发布，或单独开新帖。上游暂不接受外部 PR，故以讨论形式交付。

译文待补。

Windows 原生目录选择器失败（win32 folder dialog worker 退出）——和 #800（中文路径截断）、#1503（选择器不置前/孤儿化崩溃）是同一组件的多个问题面。 临时 workaround：绕开原生选择器，手动输入路径或改用 workspace 命令创建。Windows 选择器家族坑位见第 12 章：https://gith

npm install [email protected] --no-save --ignore-scripts 使用这个方法指定koffi的版本，然后启动就可以了 临时解决方案放在293

依据#197 中提供的解决方案 以下是具体步骤： 1、安装（绕过 koffi install 脚本崩溃） ```bash npm i -g @deepseek-ai/dsh --ignore-scripts --registry=https://registry.npmjs.org **2、目录选择器（`~/.dsh/pr

如图： 系统信息：

这个从源码看是设计如此，不是漏了个下拉框。 四个模式就是 packages/preset/agent-presets/presets/ 下的四个 preset（cordis、minimal、ptc、standard），每个 preset 是一份完整组装：工具、人设、提示词段落都打包在里面。会话创建时选的那个 preset 会被冻结记进 session he

这个问题可以先把 mode 选择定义成显式的 session/request 状态转换，而不是只改 UI 下拉框： 当前流式请求进行中时不热切换；切换动作应取消/等待当前 generation，并明确显示当前请求仍使用的 mode。新 mode 从下一轮请求生效，不能让同一轮 prompt/schema/tool policy 混用两套配置。 把

用户报告在Web对话过程中无法切换使用模式，只能在新开对话时选择现有四种模式。

这个复现已经把 Firefox 与 Brave 的差异隔离出来了，但“对话框在后台”不一定等同于目录选择 worker 崩溃：建议先分别记录 picker 请求是否返回、目录是否成功选择，以及窗口激活/焦点事件。 建议补充一组最小证据：Firefox/Brave 版本、dsh web 启动方式与 host revision、点击前后的 `documen

在 dsh 0.1.0-rc.6 的 Web UI 中，Firefox 下点击“添加工作区”时原生目录选择对话框可能后台弹出，Brave 正常。