ARTICLE · 1267969
DSH 插件升级就坏?一套流程搞定
本文写给插件创作者。插件创作者可以借这篇文章更快地完成适配。文章里还提供了我专门开发的配套Skill：
plugin-fast-adapt
https://github.com/taxueseek/plugin-fast-adapt
如果你在写 DSH 插件、或者被 DSH 升级折磨过，这个工具能帮你自动跟上新版、快速定位破坏性变更、快速验证改动、从零造插件，而且没有复杂的操作跟不必要的依赖，装上就能用。本文以 DeepSeek Harness（下文简称 DSH）的插件为例。目前主流的模型厂商基本都支持插件功能，大部分也支持用户自己开发、安装插件。DSH 已经拥有数千个第三方插件，生态非常丰富。学会了这套方法，人人都能拥有自己的插件
从提示词到插件：AI 用法的演变
AI 的实践经历了几个阶段：提示词工程（Prompt Engineering）、上下文工程（Context Engineering），再到驾驭工程（Harness Engineering）。关注点也一步步变了：最早研究怎么写提示词，后来研究怎么组织上下文，现在研究怎么驾驭 Harness 这一整套系统。复杂度也越来越高。
打个比方，Prompt 就像咒语或符箓，念对了才能生效；skill 像一个压缩包，打包了专业能力需要的上下文；插件则像在游戏里开外挂，能直接改游戏本身的规则和机制，让角色被加持神力。
用法上也有区别：Prompt 多多益善，Skill 按需启用；插件就像外挂或法宝，好用是好用，但彼此之间也会冲突，不宜装太多。而且不管是 Skill 还是插件，启用后都会占用上下文。
上下文工程的兴起，和 skill 的流行关系很大。更准确地说，上下文工程解决的是 AI 怎么拿到正确的工作上下文，skill 解决的是怎么把这些上下文、专业知识和执行流程整理成能反复使用的能力。一个专业的 skill，往往是把教程、流程、技巧，以及论文里的方法和算法汇集到一起开发出来的。
但随着模型和 Agent 的发展，很多 skill 已经被模型吃掉了。到了 Harness 时代，前一阶段的不少 skill 已经被模型内化，变成了默会知识。很多 AI 产品和 skill 积累的经验、数据，也会被吸收进模型里。现在你不一定需要一个完善的 skill：给一句提示词、一张参考图或者一个网站，用自然语言下达任务，模型就能按你的要求做出想要的效果。
skill 能补的空白越来越少，这时候就需要插件来进一步扩展模型的能力。插件不只是提供知识，还能直接改变和补全环境本身的能力，很多时候是连同工具、专业数据一起打包，交给运行中的 Harness。所以各大厂商已经不满足于 skill，纷纷推出插件功能，让人能深入 Harness 层面，做一些个性化或专业化的调整。
正因如此，大家用的工具也一步步扩展：从提示词到 skill，再到插件。到了插件这一步，和 Harness 的结合就更深了。当然，模型能力提升之后，除了直接给参考或提示词，提示词 + Skill、提示词 + 插件这样的组合用法也很好用。
插件为什么这么难适配？
原因还是复杂度，另一个就是底层 Agent 的更新迭代速度非常快。
提示词和 skill 不绑定特定环境。有些功能很简单，一个纯文本简练到就只有几个字的提示词都能当 skill 用，效果还很好。
插件就不一样了。它和 Harness 联系非常紧密，可以补全或调整 Harness 的功能，定制特定的工具和模式，扩展性很强。正因为这样，环境一变，它也更容易出问题。就像外挂改的是游戏本身，游戏一更新，外挂就容易失效。
社区在使用和适配插件时踩的坑，总结了部分，当然肯定还有其他没有列举到的问题：
启动直接炸 静默跳过 UI 挂载失效 依赖被破坏性更新弄坏
当然细节上还有很多具体的问题，为了应对真实环境当中遇到的各种问题，我也基于社区的公开实践在此基础之上，做了一个 Skill，基于快速适配的这个目的重新设计并优化了分析、适配的流程，让其更加高效自动化，让大家可以用更快的速度适配 dsh 新版本。
https://github.com/taxueseek/plugin-fast-adapt
插件开发与适配的几个方法
像 DSH 这样更新这么快的产品，做插件适配还是比较难的。我总结了几个方法，分享给大家。
第一，用第三方 agent 来更新和适配。 中国有句古话叫医者不自医，放在这里很合适。DSH 自身更新要重启服务，插件的更新、适配和测试也要重启服务，所以借助其他 agent 就很有必要。Zcode、Pi、Claude Code 等都是很好的工具，用哪家顺手就用哪家。让 agent 互相调用，围绕真实需求做测试和开发，已经是基本功了。
如果你还是更习惯于在 DSH 当中做更新跟适配可以用这个方法。日常用DSH的 APP，测试用 web
第二，根据实际需求选择产品形态。 工具不一定非得是插件，或者说不一定只提供插件。插件其实是普通人能接触到的最复杂的工具形态之一。如果需求比较简单、不需要高度定制，一个或一系列 Skill 就能很好地完成。
Skill 和插件各有长处：
- Skill
面向所有 Agent 开发。不管 Agent 怎么更新迭代，它都能运行，扩展性、兼容性和通用性都比插件强很多；只是针对特定环境做专门的适配和优化，没有插件方便。 - 插件
一般针对特定环境开发，最多再提供对其他 Agent 的兼容支持，但能力更强，更具针对性。
所以，如果一个产品的大部分需求都能用 Skill 满足，就可以优先做成 Skill。我开发的 Argo 同时提供 skill 和插件两种形态，使用方式上也支持原生搜索服务、MCP 等。不过 Argo 属于高度定制化的专业搜索工具，这么一来它的插件形态比 Skill 形态能力更强。
第三，用自动化工具减少重复工作
plugin-fast-adapt 这个 skill，是在原有社区的dsh-plugin-upgrade-skill 基础上重新开发的，为 agent 提供了更高效快捷的检查、更新跟适配的流程。可以直接查阅 DeepSeek 官方仓库的更新动态跟相关信息，确保能在第一时间获取最新版本的具体内容。避免依赖手工维护的更新信息。大幅提升这种适配的效率跟准确性。
我采用的是之前开发 Argo 等项目的思路，之前维护的项目，涉及到搜索、投资、生图、写作等多个方面，因此无法使用传统的手工维护的方式来更新迭代。开发这些项目基于我原有的相关教程、文章跟整理的一些技巧及思考，将其数字化跟标准化。
这里顺带介绍一下做这些的思路。Argo 就是个人搜索跟研究的传统手工流程的数字化 skill 化，可以说是自己蒸馏自己的典范，把原来的人肉搜索变成数字研究员。结合现在的 agent 搜索获取信息的方式，所以哪怕早年的教程跟技巧里面，具体的方式跟网站失效了，现在的搜索能力依然很强大。还有，大家的公开反馈里，发现的问题也会及时更新处理，它的搜索能力就非常完善了。
生图skill则是通过动态分享让 AI 整理跟提示词、图片进行归纳整理、反推。然后再把输出的内容、流程继续更新迭代。
所以后来就全面转向了基于 agent 的 更新迭代的思路，优化并陆续重构了多个项目，也提升了长期更新维护的速度跟效率，抛弃了原有人工维护的模式。将整个流程标准化，可以获取到最新的版本信息，以最快的速度更新迭代
之前的版本，建立在人工维护的版本卡上。过于关注每一个版本的变化，忽略了 DSH 本身的更新迭代的效率。手工维护导致它不能够在足够短的时间内跟上源头的那种更新。
原有的项目包含了论文、系列子技能跟过往老版本的适配，这个项目只基于原有项目，把老版本的适配流程做成了一个 SOP。直接对接 Deepseek 官方仓库最新版本，整个分析发现适配优化的流程进行了重新设计，大幅提升了它这个整个流程的分析跟适配效率。
github.com/taxueseek/plugin-fast-adapt
基于 Argo 、dsh-files的 dsh插件开发适配的成功经验。近期陆续完成了几个系列 Skill 的重构和更新工作。涉及搜索、agent 对话分析、投资、消除 AI 味（文章创作）及生图skill 的改进。从而可以证明这套方法论和相关实践都已经很成熟，很早之前都是这种方式批量解决常用插件的适配问题
我先是调研了项目相关的外部反馈，然后用新开发的新版 skill 拿真实环境做了个测试，测试完成之后，再重新梳理这个项目的针对性开发。在更新 DSH 版本到最新版后，针对内部和外部插件的适配问题进一步优化skill ，它现在具备这种通用且批量的这种插件更新适配的分析能力。
第四，做功能审查和优化。 这一点和第二点思路相通：不管是提示词、skill 还是插件，都能用来做代码审查和优化。这个也没有太多固定的工具。
当然，这只是做功能审查和优化。上下文的具体运作效果，还是要专门进行分析
要看一下它的上下文占用瓶颈在哪里，整个 Agent 的环境运行有什么异常，不同插件之间是否有干扰，这些也是很关键的
我这有一个配套审查 skill的提示词
/code-review 梳理一下这个XXX 的 skill及插件，保持优雅的工程质量、良好的可维护性和极佳的用户体验。以重新定义问题为导向，运用第一性原理与MECE原则、量化思维，驱动开发与测试的系统性优化
这个审查类的 skill，基本上各家都有，我这里就不再多推荐了，我之前用的是 Cursor 的，其实各家差别不大。
也有单独版的提示词
还需要代码开发的基本常识，比如：
避免硬编码 上传的内容不能暴露隐私 注意有没有版权方面的限制或约束
很多项目其实也并非完全重新造轮子，更多的时候是在现有项目基础上进行衍生或者二次开发。另外，优秀的项目其实也会有几个主要的维护者来维护。单单靠一个人，其实很难做好一个大项目。更多时候，还是要靠团队、社区来共同解决这个问题
无非是说，开源项目的人员更加宽泛，商业项目或者闭源项目更多是由一个紧密连接的小团队来完成
我还有一个新的小技巧，就是可以先让这类审查技能或审查提示进行分析，先不要改动，给出几个建议的方案。想要精修，就按照改动最小的方案来，涉及架构重构或者优化的，你就需要有一个比较好的规范。就比如说 argo 就是一个非常成功的 skill，像我的其他技能、插件，也都在参照这个标准，陆续在进行重构和优化。
奥卡姆剃刀跟第一性原理也对于这种审查优化有作用。
四、更新与修复插件的注意事项
更新插件后要重启。 插件更新完，DSH 环境并不会马上跑最新版本。一般要重启一下环境才会生效。
先让环境跑起来，再修插件。 早期我做过一个“安全模式”：先让 DSH 环境跑起来，再一个个修复插件，也可以让 agent 帮你适配。后来官方也注意到了破坏性更新的影响，用的是类似的思路。现在官方 App 一旦发现运行环境有问题，可以一键关闭所有插件，让环境按初始状态重启。也就是说，出了问题就先禁用所有插件，确保你能进入环境，再慢慢处理插件的问题。
五、DSH 的版本怎么选？
先简单说一下软件开发常见的发版流程：Alpha → Beta → RC → Stable（正式版）。
DSH 目前只有 Alpha 和 RC 两个版本。运行环境又分 web 和 App 两种。实测下来 web 版最稳定，App 版略有差异。等于说它这个是两套环境web 和 App 插件跟细节的设置上是独立的。兼容性上web 最好，App 略差一些，更新也会更滞后一点。建议直接使用web 做测试，日常用 APP 版本，就可以实现在dsh 的完整测试。
按我过往的经验，Alpha 我不怎么追，它属于比较早期的版本。一般大约一周更新一次，直接升到相对稳定的 RC 版。最近几次更新其实都是 RC 版，说明 DeepSeek 的更新也趋于稳定，不再几乎每次都是破坏性更新。当然，Alpha 对功能迭代很有必要，但如果每个版本都那么不稳定，还是很影响日常使用的。
DSH 已经更新到 0.2.1-rc.3，目前稳定性比较高。很多插件不用打补丁就能正常运行，一些作者的适配也跟上了官方的节奏，常见插件更新到新版后大多能正常使用。之前的测试也顺手修了几个插件，适配了新版。
模型搭配，我建议用 Deepseek 4.1 1017 版，GLM5.3 Flash也可以，其他强大的模型就不多说了。
