博客 · 概念

一切皆插件 vs 插件疲劳

2026 年 8 月 14 日 · dshbase

DeepSeek Harness 在 HN 上最尖锐的争论线，就是它的插件架构。支持方称它是真正的新东西；反对方预测插件疲劳、最终走向混乱。两边都有道理——所以我们没有空对空地争论，而是花时间真的去测了这个生态。在 dsh 0.1.0-rc.6 上，我们安装并运行了 101 个社区插件。结果把两边的口水话都切开了。

为什么它不是 VS Code 的插件系统

VS Code 有成千上万的扩展，但它们都挂在固定的核心上：编辑器、调试器、终端。你换不掉核心。Claude Code 也一样——你能自定义 Skills 和 MCP，但产品外壳是固定的。

DeepSeek Harness 把这个颠倒了。核心本身——Agent 循环、工具、UI、沙箱——都是由插件组成的。唯一固定的只有 Cordis，一个只管加载、卸载、解析插件依赖的内核。这不是「产品上挂插件」，而是「产品就是插件」。这个架构差异是实打实的，不是营销换皮。

「Agent 时代的安卓」叙事

最接近的类比是安卓 vs 苹果。安卓把 OS 模块化，让厂商和用户能换零件；苹果保持密封整体。DSH 赌的是 Agent 走安卓路线——一个通用内核 + 可替换的能力——而不是密封电器路线。这个赌注能否兑现，是悬而未决的问题，而我们那 101 个插件的实测，正是回答它的一个数据点。

合理的担忧：插件疲劳

反对方没有错。过度模块化有真实代价——现在我们可以用数字而不是感觉来说出它们：

选择瘫痪——如果一切皆插件，先装什么？我们的审计找到 101 个插件散落在各个分类里，而只有 11 个从 npm 干净装上、开箱即用。新人没法在每张卡都点开之前判断出是哪十个。
兼容性漂移——依赖一变，插件就坏。这不是假设，它就是实测里安装失败的头号原因。
质量参差——开放生态意味着质量不均。4 个插件需要你另跑一个 Web/TUI 运行时，3 个直接装不上。

最大的数字是：101 个插件里有 81 个压根没发到 npm——只以 GitHub 源码的形式存在，用 dsh plugin add github:owner/repo 装。这同时是生态的长处（谁都能发个仓库）和短板（没有把关人、没有版本纪律、没有安装保证）。

我们真正撞上的失败模式

「兼容性漂移」和「质量参差」听起来很虚。下面是在终端里长什么样子，全部在 dsh 0.1.0-rc.6 上复现过：

ERR_PNPM_FETCH_404——你的 npm 镜像滞后于官方源，刚发布的包返回 404。这是分发问题，不是插件问题，但照样卡住安装。
ERR_REQUIRE_ESM——插件被编译成 CommonJS，却依赖了 @deepseek-ai/dsh-tools 这类 ESM-only 的包。插件必须按 ESM（"type": "module"）构建。
缺 dsh.bundle 清单——包静默地作为普通依赖装进去，永远不激活。这是最常见的静默失败：看起来装上了，Agent 就是不加载。
cannot get property "systemPrompt" without inject——插件代码读了 ctx.systemPrompt，却没声明 inject: ["systemPrompt"]。这是插件 bug，把这个原文报给作者就行。

每一条都有一行式的修复，记录在排错指南里。但这场争论的重点不在这：这才是「插件疲劳」的具体含义。不是模块化本身坏，而是没有策展的模块化，会把调试负担转嫁给用户。

DSH 的答案：先预设，再插件

DSH 目前的答案是预设：四种内置模式打包了合理的插件集合，让你不用从零开始。只有需要时才去碰裸插件。这是务实的中间路线——底层模块化，顶层合理默认。我们的实测支持这个顺序：从预设起步，再到插件目录里挑那批被策展过的子集（每张卡都标了实测状态和确切安装命令），把 GitHub 源码的长尾当成研究区，而不是新手包。

诚实的判断

插件架构确实和 VS Code、Claude Code 不同——但「不同」不等于「更好」。真正的考验是预设 + 被策展的社区能否在可组合性兑现的同时控制住混乱。我们的数字说明：可组合性是真的（一条快速长到 101 个插件的活分发渠道），但质量尾巴很长（81 个只发 GitHub、好几个需要额外 UI 运行时、好几个直接装不上）。盯着生态看：它比任何博客文章都更快地裁决这场争论——而目前为止，它是一套真正新颖的架构，配着一张真正粗糙的表面。

FAQ

「一切皆插件」是不是 VS Code 加了点花样？不是。VS Code 里编辑器核心是固定的，扩展围着它转；DSH 里 Agent 循环、工具、沙箱、UI 本身就是最小内核之上的插件。差别在于什么能被换——在 DSH 里，是所有东西。

该从 GitHub 装插件，还是只用 npm？先用在插件目录里标了「已实测」的 npm 包。GitHub 源码插件（dsh plugin add github:owner/repo）能用，但也是我们见到最多失败、最多 allowBuilds 构建提示的地方。

插件疲劳是真实风险还是标题党？是真实的，但它是策展问题，不是架构问题。解法是预设 + 被策展的目录——这两样 DSH 都自带了。