不是套壳：BitFun 正在怎么接 dsh-plugin，为什么第一步只做「可见、可审、不可执行」

[bobleer]

DeepSeek Harness 发布后，我最感兴趣的不是“原厂 Agent”四个字，而是它把 model、tool、session、agent loop 都放进 Cordis 插件树的做法。DSH 的插件也不是往某个目录扔一个脚本那么简单：bundle 用 cordis.patch.yml 挂载配置行，profile 再组合多个 bundle，最后由 patch 层叠加覆盖。

这套设计给底层开发者的自由度很高，但接进一个会读写真实仓库、开终端、连远程机器的桌面工作台时，第一件事不能是“能不能跑”，而应该是“用户能不能先看清它到底是什么”。

所以 BitFun 的 dsh-plugin 兼容工作，第一阶段故意做得很克制。

目前开发分支已经能识别 package.json 里的 dsh.bundle.patch 和 dsh.profile.bundles，读取 cordis.patch.yml，再把发现到的条目投影成 BitFun 的插件来源、内容哈希、信任状态、运行状态和诊断信息。缺文件、空 patch、无法解析的声明不会假装成功，而是生成明确的 invalid projection 和 diagnostics。

但边界要说清楚：现在仍是 projection-only。它不会安装 npm 包，不会执行 Cordis / JavaScript，也不依赖用户机器上已经安装的 dsh CLI；这项工作还在开发分支，尚未作为正式功能交付。

为什么不直接执行？

一方面，DSH 官方自己也明确处于 developer preview；另一方面，插件执行会同时碰到供应链来源、版本与内容是否一致、远程工作区在哪台机器运行、权限请求能否从手机端回复、断线后状态怎么恢复等问题。BitFun 不是本地聊天框，桌面、远程工作区、Remote Connect 和 detached job 可能分布在不同机器上。只把 JS 跑起来不叫兼容，把这些边界处理完整才叫。

接下来更合理的顺序是：

• 先完成 manifest / patch 的可视化预览、来源与哈希校验、信任和诊断；
• 再确定 Cordis runtime 的隔离与权限边界，避免把 VM 误当成安全沙箱；
• 然后打通安装、启用、卸载、升级和审计生命周期；
• ACP 和运行时桥接继续探索，但在真正交付前都不会写成“已经支持”。

我对 DSH 和 BitFun 的判断也不是二选一。DSH 更像一套可以换底盘零件的 Agent framework；BitFun 更像把真实仓库、终端、浏览器、远程工作区、GUI 和 Mini Apps 装进了一张能直接干活的工作台。兼容 dsh-plugin 的价值，是让喜欢搭底层的人保留那份自由度，同时让普通用户先获得可见、可审、可撤销的入口。

如果你正在写 dsh bundle / profile，愿意拿一个真实 manifest 当兼容 fixture，可以把仓库或最小复现贴在这里。越早拿真实插件验证，越不容易做出只对 demo 有效的“兼容层”。

BitFun: https://github.com/GCWing/BitFun