DSH Synapse

它是什么（机制上）

dsh-synapse 是一层纯展示插件，整理的是 DeepSeek Harness 里本来就已经存在的对话。一个 npm 包发布三份 JavaScript（index.js 宿主插件、client.js 客户端启动、app.js 画布 UI）、一份样式表，以及把 id 为 synapse 的服务注入 web profile 的 cordis.patch.yml。它没有运行时依赖——也没有 peer 依赖——已发布的 0.4.1 树是普通 ESM JavaScript，不是 TypeScript 编译产物。

装上之后，DSH 顶部会多出 会话地图 开关。页面走的是既有 DSH Web 服务上的 /synapse/… 路由（page、app.js、styles.css、deepseek-mark.svg，以及 /synapse/api/* JSON 接口）。架构文档写得很硬：不启动第二个 HTTP 进程、不建立第二套模型运行时、不替换认证与权限。在地图与原生聊天之间切换，底层仍是同一个 DSH session。

画布，以及这里的「分支」指什么

已提交的 DSH 会话事件被投影成卡片。默认 autoProjection: true 时，会话按工作目录归入标题为 DSH 任务 的工作区；每条用户提问是一张卡片，后续助手消息折进该轮，最终回复作为答案展示。卡片投影文本上限 8000 字符——超长会带截断标记，全文仍在会话详情里。

分支不是插件另造的历史。对已完成回答点 Branch，走的是 DSH 原生 fork；子卡片挂在父轮次上时，锚点取的是 session header 里持久的 seedLength 切割点，而不是画布上的任意坐标。卡片位置只是视觉元数据，从不决定会话血缘。

画布本身很常规也写得清楚：平移缩放最高 4×、拖动卡片并持久化位置、展开/收起后代子树、一键定位当前会话、Markdown 表格，以及按 callId 把工具调用与结果折进对应助手回答。

它如何接入，而不变成第二套聊天应用

宿主半（index.js）是 Cordis 的 apply(ctx, config) 插件：

• 监听 session/created、session/event，回放 ctx.sessions.list()，并在事件突发时合并投影写入；
• 在 ctx.webServer 上注册 /synapse 路由；
• 通过原生 session bridge 处理 activate-session、open-session、branch、sessions/sync 等动作。

客户端半注入 @deepseek-ai/dsh-client-runtime，且 immediately: false——用户进入地图时才加载 UI，而不是启动时急切加载。配置键只有 dataFile、autoProjection、projectionWorkspaceTitle、trustedHosts。

对进阶用户最要紧的边界声明：插件不会加系统提示词、改工具 schema、改 provider 路由、改请求头或审批上下文。它只在 DSH 提交事件之后读取。因此文档声称对模型体验无直接影响、也不使可复用的 KV-cache 前缀失效——这是结构性声明（请求路径上没有任何东西被碰），不是实测报告。

数据落在哪里

DSH session log 仍然是对话内容的权威存储。Synapse 另写 $DSH_HOME/synapse/workspaces.json（可用 dataFile 覆盖），里面只有工作区映射、卡片布局、分支锚点等组织状态。删掉这个文件只会重置画布，不会删会话；卸载插件会保留文件，便于重装后迁移恢复。

还有一层非持久状态可能进 浏览器 localStorage（拖动位置等交互偏好）。文档要求：隐私模式或 localStorage 失败不得影响 DSH 对话本身，最多损失视觉偏好持久化。

另有 8000 字符投影上限、超出 localhost/127.0.0.1 时要往 trustedHosts 里加的 /synapse Host 校验，以及 workspaces.json 旁的跨进程锁文件。锁与外部修改警告是真实的，但文档仍建议每个 profile 只跑一个 dsh web 进程——最后写入覆盖仍然可能。

前提与安装

• Node >=22.19.0（engines）。
• Harness 需支持 dsh plugin profile 插件机制（文档写 2026-08 或之后）且使用 web profile；内置 patch 不支持其他 profile。
• 从 npm 安装（项目推荐）：corepack pnpm dsh plugin --profile web add dsh-synapse。registry tarball 自带预构建的 index.js / client.js / app.js。
• 从 GitHub 安装会跑包里的 prepare："prepare": "pnpm run build" → 对三个入口文件做 node --check。这只是语法校验——没有编译器、不拉远程资源——但对 git 安装仍是安装期代码执行。pnpm 10+ 可能拦截，需要把它打印的完整 allowBuilds 键（含 tarball URL 与 commit，不是裸包名）抄进 profile 的 pnpm-workspace.yaml。
• 未声明 Harness 版本目标。 没有 dsh.compatibility，也没有 @deepseek-ai/* peer。因此本条目保持验证 L2、无 dshTarget；唯一硬声明是「web profile + 2026-08 起的插件机制」。
• 网络： 除 DSH Web 服务本身外无第三方出站。index.js 只用 node:fs/promises、node:crypto、node:path 与进程内 Cordis 事件；客户端 fetch 同源打到 /synapse/api/*。包内无遥测、分析或第三方 HTTP 客户端。
• 上架时的开放 issue 包含真实运维问题：流式 autoProjection 无上限重写 workspaces.json 并阻塞事件循环（#26）、/synapse/api/sessions/sync 超过约 32 KiB 后持续失败（#27）、<system-reminder> / AGENTS.md 注入内容被画成用户卡片（#23、#31）、归档会话仍出现在地图上（插件不过滤 DSH archivedSessionIds，#21）。检查时还有多个开放 PR。main 最近一次 push：2026-08-26。

已知限制

• 仅 web profile。 发布的 patch 对 CLI / TUI 等没有作用。
• 不是多写者存储。 同一 profile 下两个 dsh web 进程共享一个 JSON；锁与警告不能保证安全。
• 投影只是投影。 系统提醒与 agent 注入的上下文可能被画成普通用户卡片（相关 bug 未关）。归档会话不过滤。旧 v3 迁移里工具配对是按顺序，不是按 callId。
• 安全审计未验证。 没有第三方扫描记录；MIT 与干净依赖树不是审计结果。
• 维护快照。 仓库建于 2026-08-16，约 395 star / 44 fork，代码最近 push 2026-08-26，open issue 队列并不短。star 不等于维护。

什么时候用——什么时候不用

如果你的问题是「线性原生聊天里多分支长会话很难找」，而你仍想让所有操作落在同一批 DSH session 上，用它。发送、打开、fork、归档都走 DSH 自己的机制；它也是较干净的「只做界面」类插件：零依赖、路由挂在既有服务上、不碰模型请求路径。

不要指望它带来第二个 agent、任务板，或替代 DSH 会话存储。装上之后不要对同一 profile 启两个 web 实例。若你的工作区流式负载很重、体积很大，#26 / #27 等未关问题仍是现实风险——务实做法是单实例，并留意 workspaces.json 体积。

FAQ

它会替代或复制 DSH 对话吗？

都不会。权威内容仍在 session log；Synapse 只把已提交事件投影成卡片，用户动作经原生 session bridge 回传。删 workspaces.json 只丢画布布局。

分支会造出第二套历史吗？

不会。Branch 走 DSH 原生 fork，子会话按持久的 seedLength 边界挂到父轮次。画布坐标不决定会话血缘。

安装期的 prepare 做什么？

git 安装时，prepare 会跑 pnpm run build，即对 index.js、client.js、app.js 做 node --check——Node 语法检查，无编译器、无网络。registry 安装用预构建文件；项目推荐该路径以避免 build 脚本授权。

它会改模型行为或打掉 KV cache 吗？

设计上不会，源码也对得上：没有系统提示词注入、没有工具 schema 改动、没有 provider 路由变更、没有请求头改写。只在 DSH 提交事件后读取，因此原本可复用的 KV 前缀仍然可复用。

数据在哪？有什么会离开本机？

画布元数据在 $DSH_HOME/synapse/workspaces.json，交互偏好可能进浏览器 localStorage。包内没有对第三方的出站连接；客户端流量同源打到 DSH Web 服务。无遥测库。

没有 dsh.compatibility 也能用吗？

它就没有这个字段——这也是本条目停在 L2、无 dshTarget 的原因。文档只要求支持 profile 插件机制的 Harness（2026-08+）与 web profile；与任何其他 harness 版本的兼容性，双方来源都未声明。

可以装 GitHub 而不是 npm 吗？

可以，而 prepare 正是在这时执行。pnpm 10+ 可能拦截，需把打印出的完整键（含 tarball URL 与 commit，不是裸包名）写入 allowBuilds。npm tarball 是更省事的预构建路径。