缘起
在八月中旬 DeepSeek 团队终于发布了他们的 Harness 产品：DSH（DeepSeek Harness），并在 Github 上开源了。
看到消息我第一时间就去体验了下，顺便围观了他们的 Cordis 框架和相关论文。上手第一感觉就是有点简陋，但看到 DSH 的开发理念：一切皆插件，也就能理解他们发布这么一个「半成品」的原因了。实际上也确实是个半成品，版本号从 0.1.0-rc.x 开始，然后最近今天发布到 0.1.1-Alpha.x，还包括很多破坏性更新。说明产品确实还有很大的提升空间。
微博上有人把 DSH 扁的一文不值，但我却不这么认为，DSH 确实不是一个成熟产品，但有了 DSH 一些自建 agent 的小团队就可以逐步退场了——还自建个锤子，直接基于 DSH 改就行了，反正「一切皆插件」。
于是我发了这么两个微博：
dsh-0.1.1-alpha 版本看起来终于是加入了一个一次性 token，但安全性还是完全不够的，之前 rc 版本在源码里面直接提到：until a real authentication layer exists，当前确实还没有这么一个认证层。
于是说干就干，用 DSH 做了一个允许远程访问的授权门禁插件， 本来就是为了微博上的一个小想法而做的 demo，@Adra1n 看到后还给我提了一个 PR，为插件增加了 OTP，然后基于这个版本继续迭代，最终发布了 0.5.1 版本。
于是一共花了 100 块钱的 DeepSeek-V4-Flash 的 token，为 DeepSeek Harness 做了一个远程访问授权的插件，给梁叔叔白打工了。。。
项目介绍
项目地址：dsh-auth-gateway
为 DeepSeek Harness Web 提供认证门禁的 Cordis 插件：密码认证 + TOTP 双因素认证 + 多层防爆破 + 会话管理 + 登录审计，并在网关层真实拦截每一个请求（HTTP 与 WebSocket），未认证流量无法触及后端。
dsh web 本身没有任何认证层；配置平面（settings/credentials RPC）被 dsh 钉死在 loopback——官方注释写道"直到真实认证层存在"（until a real authentication layer exists），但从未实现或指定方案。本插件以进程内网关形态自行承担该角色补齐认证面：对外端口由网关独占，内部 webserver 由 bundle patch 钉在回环地址，网关是唯一入口。
实操记录
其实我确实有远程访问的需求，在公司都是在远程开发机上开发，都是 ssh+tmux 的 ClaudeCode 模式，远程访问主要是通过 cc-swtich + IM 机器人，其实挺够用的。
既然 DSH 来了就顺便玩玩，第一时间在公司的开发机部署了，验证没问题后就部署到了我的 VPS 上。赶上博客的服务器迁移，从用了十年的 DigitalOcean 搬到了 Vulr，这个 blog 就是通过 dsh-auth-gateway 远程访问 DSH 让 DSH 帮忙部署的，AI 确实帮大忙了，不然还不知道得折腾几个周末。。。
但 auth-gateway 有能做的，也有不能做的。之前 @Adra1n 提出说他想增加多账号支持，允许他和他老婆分别登录，互相看不到聊天记录。做是能做，但从资源上不隔离的话就是纯扯淡，虽然 DSH 会话看不到，但都保存在机器上，DSH 是一个拥有很高权限的智能「webshell」，那直接从 SQLite 中读取就行了。。。就这一点上，我觉得伟哥说的对 :)
留言交流