73 项补丁、改坏可退：开源插件 DSH Unbound 把 AI 工具控制权还给你
一、被固化的配置层
AI 编程工具的能力边界，大多写在代码里。
以
问题集中在三个地方：系统提示词由宿主固化，团队规范没法落地；审批粒度、沙箱范围、工具路径由上游决定，没有中间档；版本升级带来的行为变化，无法局部回退。
“很多人把宿主拦截误当成模型拒绝。”项目开发者说，这两层混在一起，连排查都难。
这个错位在安全评测场景里尤其明显——如果分不清是模型自身拒绝了，还是宿主在中间拦了一道，评测结论就没有意义。
二、把配置层拆出来，做成可回退的补丁系统
DSH Unbound 的做法是，在宿主之上加一层独立的配置管理，把原本混在一起的行为拆开。
第一块是提示词注入，负责保存、恢复系统提示词，并在对话中注入上下文衔接片段。配置存在本机，安装时不覆盖使用者已有的内容。
第二块是补丁管理，也是整个项目最重的部分——73 项分类补丁，每一项都能看到当前状态、单独应用或还原。所有补丁实现幂等，重复执行不会叠加；应用前自动备份原件，改坏了能退回去；升级后原文对不上会显示跳过，不会乱改文件。
第三块是执行控制，把审批策略、沙箱范围、工具路径和 Hooks 处理写进配置层，可以被界面覆盖，但不锁死环境变量。
第四块是演练工作区，包含资产测绘、环境配置、智能体、会话隧道等 10 个模块，数据存在本地 SQLite，跨会话共享。这一块与前三块在代码层面解耦，可以单独裁剪。
技术上做了一个取舍：零运行时依赖。除宿主提供的框架包，其余全部用 Node 内置模块实现。
“安装不用联网拉依赖，也不会有供应链风险，内网环境能直接用。”项目开发者说。代价是部分功能要自己写，比如 SQLite 访问、压缩解包；收益是部署确定性——装完就能跑，不会因为依赖版本冲突挂掉。
为了让“能用”变成“可验证”，项目建立了 22 项回归检查，覆盖提示词兼容、备份完整性、状态判定、诊断导出、插件注册等关键路径，并在 Windows、Linux 与 Node 20、22 组成的四组矩阵上自动执行。检查项全部可审计、可复现，不依赖人工判断。
此外，诊断导出采用字段白名单机制，输出内容不含私人提示词、账户凭据、目标地址与原始路径，且默认不自动上传。
三、开源免费，且不打算收费
项目以 MIT 许可开源，代码与安装包全部公开：66 个模块文件，53,158 行代码，31 份文档，安装包 909 KB。
没有收费版本，没有企业版，不接受商业授权。
这个选择有两层原因。一是上游许可——项目基于另一个开源插件 dsh-purge 修改，后者明确要求二次开发必须署名、禁止商业售卖，本项目按更严格的一方执行，并完整保留了上游版权声明与来源说明。二是产品属性——配置管理工具的价值在于可用性，不在稀缺性。
“要持续改进，就需要更多人用起来。”他说，收费会直接把覆盖面限死。
目标用户分三层：需要稳定工作环境的个人开发者、要求配置一致的小型技术团队，以及需要可复现演练环境的安全研究与教学场景。
目前项目处于 v1.0.0，团队只有一人。开发者是一名 2027 届在读本科生，有 AI 产品运营实习经历，日常实践 AI Agent 与 AIGC 工具链。项目的需求定义、代码开发、测试验证、文档撰写与发布维护，全部由他一人完成。
下一步的计划是扩展宿主版本适配、补充常见问题文档、引入外部贡献者，把单人维护的风险降下来。项目不寻求融资。
“现在最缺的不是钱，是有人真的用起来，告诉我哪里不对。”
项目信息
项目名称：DSH Unbound
项目定位：面向
上线时间：2026 年 10 月
当前版本：v1.0.0
开源许可：MIT（非商业，不设收费版本）
技术栈：Node.js / JavaScript，零运行时依赖
团队：一人（项目发起人 / 独立开发者）
