Blog · 概念
「一切皆插件」在 DSH 里到底是什么意思
2026年8月20日 · dshbase · 改写解读
「万物皆插件」套在工具、技能上还好懂；一旦把会话、沙箱、文件系统也算进插件，很多人会卡住。DeepSeek Harness 正是在改这个词的边界——这也是为什么只数 GitHub star 的目录不够用。
本文大幅改写自近期微信公众号里对 DSH 插件理念的讨论（尤其是 APPSO《大起底》一文的问题框架），保留架构论点，去掉招聘软广，并补上我们在真实安装社区插件时看到的后果。
先理解 Harness：模型是「入职员工」，不是「整间办公室」
招到一个很强的人，不等于他立刻能干活。还要工位、账号、权限、共享盘，以及同事已经做到哪一步的记录。把「员工」换成「模型」，这整套配套就是 Harness：工具、文件、记忆、沙箱、失败恢复，以及「看资料 → 行动 → 观察 → 再决定」的循环。
同一模型，换一套 Harness，体感可以完全不同。只比模型卡、不比运行时，会漏掉真正的差距。
普通插件：给已经盖好的办公室添一台打印机
传统插件默认「主体软件已经存在」。Chrome 本来就会上网，翻译插件只是加能力。Claude Code / Codex 一类扩展大多也落在这一层：
- Tool / MCP：多一个可调用动作
- Skill / 指令文件：按需注入说明
- Hook：在工具前后做校验或日志
- Subagent：把一部分任务派出去
很有用，但主干通常是封死的：主循环怎么转、上下文怎么拼、会话怎么存、沙箱怎么接。你能添打印机，很难换整套打卡制度。
DSH 的插件：换的是办公室模块，不只是小配件
DSH 更接近「可替换的办公系统」。打卡从签到表、打卡机，到指纹、人脸、App——核心契约不变：识别人、记时间、记位置。文件系统对 Agent 也一样：上层真正关心的是能不能读/写、路径怎么表示、错误怎么返回，而不是字节落在本地盘还是远程沙箱。
所以「一切皆插件」≠「应用商店格子很多」。它是在赌：模型适配、会话日志、Agent Loop、FS、沙箱这些 harness seam，都能在稳定接口后面换成不同 Provider。
给安装者的 Cordis 一句话
运行中的 dsh 本质是 Cordis 服务树，能力挂在共享 ctx 上。插件用 inject 声明依赖；卸载时应可回收注册。官方日志硬约束是：model-visible means logged——模型看见的内容必须能从只追加会话事件流重建。组合发生在配置层（bundle → profile → home 补丁 → --patch），所以 dsh --profile web --dump-config 很重要：你能看见自己到底启动了什么。
Pi 走的是「内核极薄」；DSH 走的是「连地基也拆成砖」。自由度更大，版本错配与供应链风险也更大——这就是产品本身的取舍。
落到 dshbase：可插拔之后，验证才是产品
核心可插拔之后，「GitHub 上有仓库」几乎不再是质量信号。一个坏的 Provider 可以改掉整个 profile 的启动行为。我们只在真实安装路径通过后，才在 插件目录 标 已验证（webonly 也会走 Web/CDP），失败分类写在 审计页。
想看同一争论的「疲劳」一侧（npm vs git、ESM、缺 dsh.bundle），见 插件哲学。一句话：没有策展的模块化，只是把调试成本甩给你。
结论
DSH 有意思的地方，不是「DeepSeek 也做插件商店了」，而是它在问：当模型越来越容易被替换，围绕模型的那套「上岗配套」能不能也模块化？极客会爱这个答案；其他人仍然需要预设、已验证安装，以及一个先回答「能不能跑」而不是「有多少星」的目录。