在 DeepSeek Harness（下称 DSH）里做一件事，经常要来回分支：同一段回答，你想按三种思路各追问一次。原生对话把它们排成一条时间线，越追问越长，回头想找回某条支线，只能靠滚动和记忆。dsh-synapse 想解决的正是这个问题——它把同一工作区里的会话、追问和分支组织成一张可拖拽、可缩放的画布，让分支重新变得可见。站点中文名「会话地图」，星标 478（GitHub 已 483），MIT 许可，最近提交在 1 天前。
但真正值得写清楚的不是它「长什么样」，而是它怎么接进 DSH。一个会话可视化插件最容易犯的错误，是偷偷另起一套会话历史；一旦两套历史并存，用户迟早分不清哪份才是真的。dsh-synapse 的设计选择恰好相反：它只做投影，不做所有权。
一句话定位：表现层，不是会话层
按官方架构文档的说法，Synapse 是「对话的表现与组织层」：把已有的 DSH 会话、轮次和 fork 变成一张视觉地图，但不替换拥有这些对话的系统。实现上，插件通过一个 cordis.patch.yml 把自己插进 DSH 的 web profile，直接复用现有的 DSH Web Server 与客户端运行时——它不启动第二个 HTTP 服务，不创建第二套模型或 Agent 运行时，也不接管 DSH 的鉴权与权限检查。
会话的创建、打开、追问、fork、归档，以及模型调用、工具执行、权限审批，全部仍由 DSH 原生逻辑负责；Synapse 只做投影与桥接。
投影模型：已提交事件按工作目录归组
autoProjection 默认打开。开启后，已提交的 DSH 会话事件先按工作目录（session.header.cwd）归组，再投影进对应的 Synapse 工作区。
投影的粒度是「轮」：每个用户提问变成一张会话卡片，随后的助手消息折进这一轮，最终那条助手回复作为答案展示。工具调用与结果按 callId 折叠进对应的助手回复里，而不是单独占一张卡片——实时事件靠 callId 配对，这也是长会话里地图不会炸成一片散碎卡片的原因。
投影写入会在事件突发时被合并，实时更新复用已缓存的 Markdown、只修补活跃卡片，而不是整张画布重建。
fork 连在「durable seed boundary」，不在画布坐标上
这是整个设计里最关键的一处取舍。分支会话连接到父轮的 durable DSH seed 边界，而不是连到画布上的某个任意坐标。
如果分支连线依赖画布坐标，「血缘」就变成视觉信息——拖一下卡片，父子关系就可能被重新表述。而 Synapse 把血缘锚在 DSH 自己持久化的分叉点上（session.inheritedEventCount 给出的那条切分线），画布坐标退化成纯粹的排版结果。换句话说：你怎么摆卡片，都不会改变对话之间的父子关系。
配套地，实时工具配对用 callId；而 v3 老数据迁移时没有持久化 callId，只能按顺序把每次调用和下一条结果配对，老数据里的工具归组可能不如实时投影精确。
画布元数据：可以删，删了不伤会话
Synapse 默认把画布元数据写在 $DSH_HOME/synapse/workspaces.json，里面是工作区映射、卡片布局和分支锚点这类组织性状态，不替代 session log。
由此推出一串后果：删掉它，重置的是画布组织而不是对话；卸载插件时它会被保留，重装后画布能恢复；旧 schema 加载时自动迁移。拖拽位置这类交互状态可能缓存在浏览器 local storage 里，隐私模式限制或 local storage 失效不会妨碍 DSH 对话运行，只是视觉偏好的持久化会打折。
对模型与 KV-cache 的影响：没有
插件只在 DSH 提交会话事件之后读取它们，不新增也不修改系统提示、用户请求内容、模型请求头、工具 schema 或注册表、provider 路由、审批上下文。因此它没有直接的模型体验影响，也不会让一段本可复用的 KV-cache 前缀失效。
边界与注意
单条消息投影上限 8000 字符
现象。 很长的回答在卡片里显示不全。原因。 投影文本被限制在 8000 字符，超出的部分带一个「—…（详情查看全文）」的截断标记，这是刻意的性能取舍。解决。 完整内容仍可在会话详情里查看；卡片是索引，不是全文。
覆盖配置时 patch 会整体替换该行
现象。 你只想改一个键，结果其它键回到了默认值。原因。 DSH 的 patch 会整体替换该行的 config，而不是字段级合并。解决。 通过行 id synapse 覆盖 dataFile、autoProjection、projectionWorkspaceTitle、trustedHosts 时，把需要保留的键一并重述。
snapshotEvents() 已被标记 deprecated
现象。 升级 DSH 后可能遇到画布重建相关的行为变化。原因。 重建画布需要完整事件序列，插件仍在调用 session.snapshotEvents()，而 Harness 正把完整会话日志移出内存，该方法已标记废弃，它需要一个基于存储的异步分页读来接班。解决。 把它当成每次升级 DSH 时要重点复检的依赖项。
卸载不删数据
现象。 执行 remove 之后，画布数据还在。原因。 卸载只移除插件依赖和 profile 激活层，不动 $DSH_HOME/synapse/。解决。 想彻底清理就手动删除 $DSH_HOME/synapse/；pnpm-workspace.yaml 里遗留的 allowBuilds 键没有副作用，可以顺手移除。
总结
dsh-synapse 的价值不在「把对话画成图」，而在它把图画在 DSH 已有的事实之上：session log 仍是唯一事实来源，画布只是可删的视觉组织层；想对照同类插件的中文清单与安装形态，可以先看 DeepSeek Harness Hub 插件清单，再决定要不要装。
适合与不适合
适合：需要反复分支追问、回头找某条支线的开发者；希望会话组织可视化但不想换掉原生会话的人；在意插件不污染 KV-cache、不接管模型请求的人。
不适合：还在 DSH 0.1.7-rc.2 以下的人；想同时跑多个共享同一 profile 的 dsh web 实例的人；把它当会话备份工具的人（它只存画布元数据，不存会话内容）。
标签：dsh-synapse、DeepSeek Harness、会话地图、插件架构、投影模型
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。