夜雨聆风我把 awesome-dsh-plugin 的列表翻了一遍，又扫了 GitHub 上标记 dsh-plugin 的仓库。截至 2026 年 8 月 20 日，GitHub 上这类仓库有 8,796 个，经过 awesome-dsh-plugin 社区审核收录的约 1,690 个。从 deepseek-harness 发布到现在，平均每天都有上百个新仓库冒出来。
社区里有人在用插件把 DSH 的界面、模型接入、会话管理、工具能力重新拼了一遍。比如 dsh-codex-ui 直接把 Web UI 改成 Codex 风格的侧边栏、文件树和对话导航，DeepSeek-Reasonix 做到 34,888 Stars，成了原生 Coding Agent 的主流选择。也有人往完全相反的方向走。titanwings 的 colleague-skill 把已故同事的记忆做成可交互的 AI 形象，拿了 23,569 Stars，引发了不少伦理讨论。imsai-sh 的 zhuzhiliao 是个竹知了玩具的 Web 模拟版，2,842 Stars。dsh-desk-pet 在 macOS 桌面上养了一只宠物，状态和 DSH 的会话联动。
对写代码的人来说，这挺带感。对做产品的人来说，这个场面值得停下来想几秒。
技术已经证明一件事。Agent 几乎所有东西都能被插件化，能拆开再拼回去。代码层几乎不设防。但技术边界一旦打开，产品边界最容易跟着一起失控。
这篇文章不再讲 DSH 有多牛，也不盘点哪个插件好玩。我想回答一个更实际的问题。当 Agent 走到插件满地走这一步，创业者、CTO、架构师最容易在什么地方翻车，产品决策该怎么落。
先说最容易踩的坑
过去一年，Agent 这边的新东西几乎按周出现。MCP，Skills，Harness，Plugin。很多团队的反应高度一致。每冒出一个新概念，就把产品方向重排一次。今天支持 MCP，明天做 Skills 市场，后天又想搞 Plugin 平台或者网关。
结果很常见。研发资源砸在别人早就提供的能力上。产品形态不断漂移。客户真正需要的价值，反而越来越说不清。我见过不止一个团队，半年换了三次方向，开会时连自己产品是干嘛的都讲不利索。
DSH 的插件爆炸只是把这个毛病放大了。它用极端的方式提醒所有人。技术上什么都能做，产品上却不该什么都做。
插件本身分成两段看
第一类是 Codex 化插件。只能说DSH相对复杂，主体面向的是有开发能力的群体，所以导致趋势上会先摸着石头过河，摸秃了，也就有自己东西了
社区用插件把 DSH 的 UI、模型接入、会话管理、工具能力重新组装，做成接近 OpenAI Codex 的体验，不需要动宿主源码就能对齐一大截。
DeepSeek-Reasonix 做了 prefix-cache 稳定性优化，支持中断后自动恢复。
dsh-codex-oauth 甚至让用户直接用现有的 Codex 订阅接入 DSH。
我通过接入下面几个组件，轻松就将Codex的核心功能给拼凑出来了
这一批插件说明一件事。Agent 的核心能力已经被模块化。模型、工具、界面、会话、认证，都能拆开再拼。
第二类是广告、小游戏、宠物插件。这部分就开始体现出插件生态的BUG之处了，啥玩意都有，不得不感概社区的脑洞
有人把 Web 界面改成 2005 年门户网站的样子，塞进虚构广告和弹窗。
zhuzhiliao 是个零依赖的竹知了玩具，petdex 做了跨 Agent 平台的动画宠物画廊，兼容 Codex、Claude Code 和 DSH。
这一批说明另一件事。
技术上的边界，到这里几乎消失了。
产品上的边界，只能靠人主动去守。
这才是 DSH 值得看的地方。
说它火没多大意思，它更像个够鲜活的样本，让人看清一件事。技术上什么都可以做，产品上什么都不应该做。
光看到插件多，没什么用
对架构师和产品负责人来说，真正有用的是回答三个问题。
哪些能力必须自己做。哪些能力可以直接复用生态。
面对新的热点，跟不跟，跟到什么程度。
下面这套方法可以直接拿去用。
先做能力拆分。把常见能力分成四类。
一类是核心产品能力。典型是解决客户特定问题的工作流、行业知识、效果评估、企业治理。这类必须自己掌握，它是客户愿意付钱的理由。
一类是战略壁垒能力。典型是长期沉淀的企业上下文、组织知识、决策历史、独特数据。这类必须自己掌握，而且要持续积累。别人抄走代码也抄不走积累。
一类是可复用通用能力。典型是通用工具、MCP 客户端、OAuth、通用界面、通用 Agent 运行时。这类优先复用，别自己造轮子。DSH 生态里 UI Enhancements 有 248 个插件，Tools & Capabilities 有 213 个，Sessions & Messages 有 107 个，Workflow & Automation 有 104 个。这些数字说明，通用层已经被社区填得很满。
一类是基础设施。典型是大模型供应商、沙箱、基础会话存储。这类直接复用，并且保持可替换，价格一不合适就换。
这套表不是摆样子。我建议你把团队的每一项能力往上放一遍，放完大概就清楚哪些是墙，哪些是随时能拔的插头。多数团队真正慌的是，发现自己花大力气做的，恰恰是可复用那两列。
举个例子。如果你做的是企业研发团队的 AI 转型助手，真正该自己抓在手里的，是研发流程、AI 落地方法、知识体系、工作流编排、治理和效果评估。至于大模型供应商、通用工具、沙箱、OAuth、通用运行时，没有一样值得重新造一遍。社区里 dsh-cost-meter 已经做了实时成本计量和预算告警，dsh-sentinel 做了条件驱动唤醒，governed-workflow-for-dsh 做了策略执行和合规审计。这些东西你重新做一遍，意义不大。
拿不准的时候，问四个问题。
它是不是直接决定客户拿到手的核心价值。 它能不能形成别人拿不到的长期数据或流程壁垒。 它是不是已经很成熟、变化极快、行业内通用。 换掉它的成本是否在接受范围内。
前两个答案是肯定的，倾向自己做。后两个答案是肯定的，倾向复用，并且保持可替换。
追热点前，先过检查表
每出现一个新概念，MCP、Skills、Harness、Plugin，都强制问三件事。它有没有改变客户获得价值的方式。它是不是只是降低了接入成本。我需不需要把它本身变成一门生意。
大多数时候的答案都一样。跟，但只跟到降低成本、提升体验这一层，绝不把它变成产品的核心定义。
原因很简单。MCP 让你的工具接入更方便，Skills 让你的 Prompt 模板更好管理，Plugin 让你的功能扩展更快。它们改变的是实现方式，不是客户付钱要买的那个结果。客户不会因为你用了 MCP 就多付一分钱，但会因为你的方案解决了他的问题而续费。把实现方式当成卖点，是技术路线和产品路线最容易混淆的地方。
最后说点我自己的看法
开发者应该尽量拥抱这些插件，能拼的东西越多，创新越快。
但产品负责人必须不断收缩自己的边界。技术上什么都能做，产品上不该什么都做。
技术路线可以一遍遍重来。商业问题，也就是客户真正要解决的那个问题，不能跟着一遍遍重来。
DSH 插件爆炸，只是把 Agent 从一个产品推成一个能拼来拼去的生态，用很极端的方式摆在所有人面前。
模块化带来自由，也带来失控的风险。
真正的竞争力，不在你能拼多少插件，而在你清不清楚哪些是自己的核心，哪些只是随时能换的零件。
以后再看到一个 Agent 热点，不妨先做一次技术替换测试。
测试过了，再决定跟到哪一层。
这样你不会被生态带着跑，而是让生态来加速你要解决的真正问题。
