目录
上一篇《一切皆插件的 DeepSeek Harness》已经写过起源：微博上有人吐槽 DSH，而我又恰好有远程访问开发机的刚需，说干就干做了个 auth-gateway 的 demo。本来想着尝个鲜就收手，结果一发不可收拾——DSH 的理念是一切皆插件，而我恰好又赶上 DeepSeek-V4-Flash 猛蹬 token 的窗口期，古法编程写一个月的东西，AI Coding 三天就能搞出来，这谁顶得住。。。
所谓工欲善其事，必先利其器——也叫差生文具多，从八月中旬上手到现在，快两个月，一共写了五个项目：
- dsh-auth-gateway：远程访问认证门禁，上一篇的主角，后续迭代了不少
- dsh-git-panel：对话工作区里的 IDEA 风格 Git 面板
- dsh-openviking-manager：OpenViking 记忆服务的配置管理器
- dsh-decision-layer： 结构化裁决层，玩一下 Jev 这类 SystemOne 模型
- dsh-hub-desktop：桌面上的 DSH 实例管理工具
五个项目刚好拼成一套：hub-desktop 管住 N 个 dsh 实例，每个实例门口站着 auth-gateway，屋里再装上各自的功能插件（git-panel / openviking-manager / decision-layer）。
特此记录，分享 & 备忘。
0x01 dsh-auth-gateway：微博吐槽 + 远程刚需
公司提供远程开发机，以往都是 ssh+ClaudeCode，最近有点腻了，刚好 dsh 发布了就来尝尝鲜，但 dsh web 只面向本机回环，想在工位之外访问自己的实例，等于裸奔。于是做了个允许远程访问的授权门禁插件：密码认证 + TOTP 双因素 + 多层防爆破 + 会话管理 + 登录审计。
本来是微博上一个小想法的 demo，@Adra1n 看到后提了个 PR 加上 OTP，然后基于这个版本一路迭代，现在到 0.8.4。上一篇算过账：一共花了 100 块钱的 DeepSeek-V4-Flash token，给梁叔叔白打工了。。。没想到一个玩具 demo，陆陆续续来了几个外部贡献者，第一个月就有了3个 PR：
- @Adra1n 的 PR #1 加了 OTP 双因素（带二维码），PR #6 又补上 OTP 密钥的 AES-256-GCM 静态加密；
- @meowtech 报告并初步修了通过域名访问时模型设置页不可用的问题，他那版包装宿主模块系统的实现后来被证实会破坏其他插件的激活语义，我改成最小介入方案重写了；
- @LuckVd 修了 dsh ≥ 0.1.2 上游 BrowserAuth 导致的转发 401，经官方 credentials 通道读取密钥、为回环一跳铸造同构 cookie，评审补齐后合入。
兼容线一路实测推进到 0.1.5-rc.2 <= dsh <= 0.2.1-alpha.1。dsh 版本号跟坐火箭似的，插件跟着跑，每次官方发版都像开盲盒，不知道这次又改坏了哪里。。。
安全人的老毛病，能做的和不能做的必须分清楚：多账号登录、角色权限这类需求，在单实例前提下就是纯扯淡，没有 OS / 容器 / 沙盒级的隔离，认证门禁只能回答「谁能进」，回答不了「谁能看什么」。
项目地址：https://github.com/xbzbing/dsh-auth-gateway
0x02 dsh-git-panel：缓解 AI Coding 的焦虑
最初搞 AI Coding 时是在 IDEA 中的代码补全，AI 一边改，我还得一边看着。随着 AI 能力的提升，人类对代码的阅读变得越来越不重要，在 TUI Agent 出现后，AI 改的什么就完全不可见了。虽然看见了也不会改变什么，但说实话还是得时不时看一眼，主要作用是缓解人类的焦虑。
古法编程时代用惯了 IDEA 的 Git 面板，改了什么、动了哪几行一目了然，这个体验确实很棒。dsh 的变更管理和dsh-better-sidebar 的 Git 插件我都用不惯，去 GitHub 搜了一圈也没有合适的，索性自己 vibe 一个 IDEA 风格的插件。
插件分 host / client 两半，在工作区加了一个常驻的「Git」标签：
- Git 总览：三栏布局，左边分支和标签，中间提交历史图（支持按信息、哈希、作者、日期搜索，悬停弹卡片看完整提交信息），右边是选中提交的文件树和差异弹窗；
- 变更记录：未提交变更列表 + 逐文件暂存 / 丢弃 + 带 Amend 复选框的提交框，右栏是差异对照；
- 文件浏览：目录树按需加载、官方文件类型图标、被 .gitignore 忽略的条目半透明，代码、文本、图片都能预览，Markdown 和 HTML 可以切「渲染」（HTML 进隔离沙箱，有 allow-scripts 但没有同源权限，不自动执行）；
- 查找和对照：源码和差异都支持 Ctrl/⌘+F 就地查找，差异有统一、并排、变更前、变更后四种视图；
- 输入框标记：输入框左边一个 zsh 风格的
<仓库名> (<分支>)，已同步绿色、有变更橙色，点一下跳面板。
实现上是刻意克制的：大部分功能只读和预览，只留轻量的操作入口（提交、amend、暂存、丢弃），更复杂的操作直接交给 dsh。
安全上照旧是职业病：所有 git 命令以 argv 数组经宿主 subprocess 服务执行，不拼接 shell 字符串，cwd 锁死仓库根，带超时和输出上限，插件不改任何 git 配置。
项目地址：https://github.com/xbzbing/dsh-git-panel（npm 包名是 @xbzbing/dsh-git-panel）
0x03 dsh-openviking-manager：多 agent 怎么共享记忆
这个插件解决的是多主机协同的问题。有同事说从本地开发机切换到远程开发机后明显感觉 ClaudeCode 变蠢了。以往协同的方式无非两种：生成一份在线文档，或者把文档提交进 git。但总有一些琐碎的小事，今天踩了个坑、某个配置的来龙去脉，写在线文档太重，提交 git 又杀鸡用牛刀，这类东西靠 agent 的本地记忆就足够了。
问题出在多实例上：A 机器上的经验，B 机器上的 agent 怎么知道？OpenViking 刚好把这个问题解了。OpenViking 是火山引擎开源、专门给 AI Agent 设计的上下文数据库。服务端部署一份，跨设备、跨会话都能读写同一套记忆。OpenViking 也有对应的 dsh 插件，但配置需要手写，所以顺手做了个管理面板。
插件本身的功能：读取、导入、原子更新配置；检查服务端 /health、/ready 和用户身份；配置格式与权限检查，外加经确认的权限修复；临时用 root_api_key 调 Admin API 建账号、建用户、轮换 Key，key 只在表单和一次同源请求期间存在，绝不落盘，页面只显示掩码。
还有几个点值得说说，OpenViking 默认按用户全局共享记忆，但我的工作中存在多个项目多个语言多种技术栈，混合到一起反而有些乱，所以我默认设置按项目共享，尽量减少跨项目的记忆：
- 会话级记忆开关：输入框左侧一个按钮，如果发现记忆混乱的情况，可以临时关闭当前会话中的 OpenViking，在解决记忆问题后再打开；
- 记忆隔离开关（
recallPeerScope，默认actor）：按主题隔离召回，防止跨主题串味，首次打开配置页自动写入并重载官方插件； - Actor peer id 默认留空：多仓库场景下让官方按每个会话 workspace 的 git 身份自动推导 peer，一个仓库一个主题，不用逐仓配置，此时日志里那条缺少显式 peer id 的提示属于正常现象，可以忽略；
- 召回调优：分数阈值、召回条数、查询扩写、请求超时等六个键，取值域严格按官方 config-schema 校验，只写
plugin段，ovcli.conf里其他键一律保留，环境变量优先级更高时字段只读并显示警告。
它不启动、不停止 OpenViking 服务端，也不替换官方的记忆插件，只管配置。
项目地址：https://github.com/xbzbing/dsh-openviking-manager
0x04 dsh-decision-layer：一个「干中学」的研究插件
9 月中旬 jev 突然火了，火是火但SystemOne 模型到底怎么用，我还没找到合适的方法。这个插件纯研究性质，主打一个「干中学」，反正玩一下。
思路是这样：agent 干活的时候，有些问题判断标准其实很明确，比如这条命令危不危险、这份产出及格不及格、这堆工具哪些跟本轮任务相关。这类问题让干活的模型自己判，既当运动员又当裁判，不如丢给同协议的裁决后端。目前接了这么几个决策点：
- 产出自检 + 任务完成核对：回合结束给产出打分，并给用户列出的交付条件逐项判定，工具证据优先，模型在回复里自述「我做完了」不算证据；理论上也可以作为模型降智的监控，如果连续低分，则会闪烁警告。
- 危险门控：破坏性工具调用执行前，用脱敏摘要（只含工具名和命令 / 路径，疑似密钥打码，不含文件内容）请后端裁决。两档模型，只有高置信判定「拒绝」才拦截，其余情况（高置信放行、低置信、后端挂了、响应不合法）一律不介入，按宿主原路径执行；
- 工具收窄：回合开始时摘掉用不上的工具，token 能少一点是一点，还能防止干扰模型判断；
- 防循环：同一调用连续重复超阈值直接拒绝，确定性判断，不走后端。
裁决后端可配置，默认是 https://api.typesafe.ai 的 jev-latest，没配 Key 就不发任何请求。但这玩意会把上下文也发出去，所以还折腾了下 tev1 模型的本地部署，配着这个插件一起跑，过程写在仓库的 docs/zh/deploy-tev1-with-plugin.md 里，纯本地模型判断，高效又安全。
但这玩意到底有没有用，有多大用，目前还没有数据支撑，我再玩一段时间试试。
项目地址：https://github.com/xbzbing/dsh-decision-layer
0x05 dsh-hub-desktop：桌面上的 DSH 实例管理工具
月末 OpenCode-go 和 mimo-code-plan 都要到期了，于是 OpenDesign 出原型、用 dsh 做了一个桌面应用现出来。应用解决两个问题：
其一，多实例管理。我手上同时跑着好几个 dsh：远程开发机一个、本地开发机一个、本地恢复实例一个。都在浏览器里面，一边看文档，一边 vibe。按 Command+Tab 切换应用但切不了浏览器页面，体验十分割裂，我需要一个能从浏览器中脱离出来的 dsh 实例。
其二，我还有一台 Windows 电脑，平时打游戏用，上面压根没配 node、pnpm 这些环境。不想装 workbudy 之类的工具，又想用上 AI 能力，还是自己写一个放心。
认证直接对接 dsh-auth-gateway 的远程访问。还增加了 SSH 通道实例，不装dsh-auth-gateway 也能远程用。本地实例启动后可以放到后台，按 Command+数字可以切换实例。额外做了一个插件管理。简直完美！唯一的问题是桌面应用不像插件，正式发布需要签名，不然不论是 Windows 还是 Mac 都会提示有风险，反正现在也只是我自己玩，有需要的朋友可以自行编译。
项目地址：https://github.com/xbzbing/dsh-hub-desktop
0x06 写在最后
dsh 确实好玩，我已经看到有原来自己做 agent 的团队直接把底层换成了 dsh。
不过目前的生态还是太乱了，没有官方的插件市场，第三方插件市场有多个，还不审核安全性。我甚至还看到一个 fork 别人仓库提交收录的哥们，我严重怀疑他要搞投毒。。。
总之，dsh 能做的定制非常多，不仅局限于做皮肤，对开发者来说，能快速做出适合自己的工具才是最重要的。
有想一起折腾 DSH 插件的，欢迎 PR 或者提 issue。
留言交流