前言¶
DeepSeek Harness（DSH）把能力拆成插件，多数协作可以靠目标插件暴露的扩展点完成。实际开发里还会遇到另一类需求：要改的是目标插件内部的组件、加载入口或编译后行为，而对方并没有提供对应 API。常见做法是 fork 一份、直接改 node_modules，或每次升级后手工重贴补丁——维护成本高，也容易在升级后悄悄失效。
下面介绍 dsh-harmony（GitHub：memorax-ai/dsh-harmony）。它是一套运行时 Patch 协调库，让插件在不维护 fork、不改动磁盘上已安装包文件的前提下，对另一个 DSH 插件做内存级源码变换。
这是什么¶
dsh-harmony 由 memorax-ai 维护，当前 npm 版本为 0.7.3，许可证 MIT。项目在 SkillHub 社区目录归类为工作流，GitHub 约 16 stars、2 forks。
一句话定位：在 DeepSeek Harness 运行时，对目标插件的编译代码做修补（patch）、替换（replace）和装饰（decorate），已安装包文件保持字节级不变。
设计灵感来自 C# 生态中 Andreas Pardeike 等人创建的 Harmony 项目；DSH 版 Harmony 解决的是插件之间的「内部行为改写」问题，而不是替代 DSH 自带的公开扩展点。
核心功能¶
运行时源码变换¶
Harmony 在目标插件运行前加载 Patch，在内存中改写其编译代码，再启动 Harness。Patch 通过 TSQuery 定位 TypeScript AST 节点，用 MagicString 改写源码区间；多个 Patch 按顺序依次执行，后一个 Patch 读取前一个留下的源码。
这意味着：
- 多个插件可以对同一目标各自提交 Patch，磁盘上的安装文件不受影响。
- 可以
inspect原始源码、每一步 Patch 结果以及最终变换后的源码，而不是把 bundle 当黑盒。 - 禁用或移除 Provider 后，可恢复原始行为。
Provider 与 Patch 顺序¶
Provider 可以把 Patch 放在另一个 Provider 之前或之后；单个 Patch 也可声明自己的 before / after 规则。用户还可以在 Settings → Harmony 里跨 Provider 穿插 Patch 顺序。
当若干改动必须同时成功时，可用 composite Patch：多个成员共用一个顺序位和一个开关，任一成员失败则整组不生效。
Harmony 维护全局 patchOrder，并校验保存列表中每个已注册 Patch 恰好出现一次。插件级禁用是独立的 provider/* 开关，不会清除单个 Patch 的启用状态；重新启用插件时，只会恢复插件禁用前已单独启用的 Patch。
浏览器插件的样式顺序¶
对 browser 类插件，Harmony 会按 Patch 顺序维护各 Provider 拥有的 <style data-plugin> 标签。一个 Provider 对应一组样式，该组中最后启用的 Patch 决定这组 CSS 在级联中的位置；Patch 重载后顺序会重新对齐。
版本钉扎与健康检查¶
可以为 Patch 钉住目标包版本和 expect；版本不匹配时会在 status 中明显失败，而不是等 UI 选择器漂移后才察觉问题。
CLI 与 WebUI¶
启动 WebUI 后，可在 Settings → Harmony 管理 Profile。终端侧支持对任意 Profile 做交互式或非交互式操作；命令会事务性地联系运行中的 Host 并报告 live 状态，对已停止的 Profile 则做 offline 的原子校验与更新。
安装与启用¶
环境要求：
- Node.js
^22.22.3或>=24.11.1 @deepseek-ai/dsh@0.1.0-rc.8或@deepseek-ai/dsh@0.1.1-rc.1
先做全局安装，再启动 WebUI：
npm install -g @deepseek-ai/dsh@0.1.1-rc.1
npm install -g dsh-harmony
dsh web
启动后在 Settings → Harmony 中完成配置。Profile、Desktop 集成、更新与卸载等细节见官方安装指南。
常用 CLI 示例（以 web Profile 为例）：
dsh harmony --profile web
dsh harmony status --json --profile web
dsh harmony disable my-provider/optional-patch --profile web
dsh harmony enable-provider my-provider --profile web
dsh harmony patch-order show --profile web
dsh harmony patch-order move my-provider/optional-patch --before other-provider/base --profile web
dsh harmony patch-order auto --profile web
dsh harmony provider-order move my-provider --after base-provider --profile web
dsh harmony inspect target-package --patch my-provider/optional-patch --summary --profile web
dsh harmony reload my-provider --profile web
在 TUI 中按 Tab 可在 Provider 视图与 Patch 视图之间切换。status、patch-order show、provider-order show 在健康或顺序约束失败时以状态码 1 退出；inspect --summary 省略变换后的完整源码，--patch <key> 则只查看被指定 Patch 触及的目标。reload 需要 Host 正在运行。
编写、审查或调试 Patch 前，仓库内提供了 AI agent 技能文档 use-dsh-harmony，涵盖安装、Patch 选择与编写、运行时操作和排错。
典型用法¶
何时选用 Harmony¶
README 中的对比表概括了适用边界：
| 没有 Harmony | 有 Harmony |
|---|---|
| 隐藏或复制内部 UI，并长期对齐两套实现 | 原地替换选定组件或编译调用点 |
改 node_modules、维护 fork、升级后重贴补丁 |
内存变换源码，安装包文件不变 |
| 选择器漂移后 UI 静默损坏 | 钉版本与 expect，不匹配时在 status 可见失败 |
| 把最终 bundle 当黑盒 | 可检查原始源码、每步 Patch 与最终结果 |
| 手工撤销自定义改动 | 禁用或移除 Provider 即可恢复 |
原则：目标插件已暴露的扩展点仍是首选；Harmony 填补的是「没有 API、又不想 fork」之间的空隙。它不会把编译期内部实现变成稳定公开 API，而是让这类依赖变得可排序、可检查、可回滚。
开发 Patch 时的入口提示¶
README 的 Usage 一节写道：在 vibe coding DSH 插件时，可以直接说 “What about we use dsh-harmony” 作为起点。具体 Patch 模型、Provider 声明、description 字段、composite Patch 等细节以官方文档与仓库 README 为准。
适用场景与注意¶
适合谁
- 需要修改其他 DSH 插件内部实现，但目标未提供扩展点的插件作者。
- 希望在多个插件间协调对同一目标的源码级改动，且需要明确顺序与开关的团队。
- 维护 browser 插件并需要控制 Provider 样式注入顺序的前端集成场景。
务必注意
- 权限：Harmony 以当前
dsh进程权限运行，Patch 会在运行时改写插件行为。安装或使用前应阅读源码与 MIT 许可证，确认 Provider 来源可信。 - 稳定性：依赖目标插件内部结构；目标大版本升级后 Patch 可能失效，应配合版本钉扎与
status检查。 - 生态定位：SkillHub 是面向中国用户的 DSH 插件社区目录，与 DeepSeek / 幻方无官方从属关系；DSH 本身遵循「一切皆插件」理念，Harmony 是在此之上增加的一种插件协作方式。
结尾¶
dsh-harmony 把「改别人的插件内部实现」从 fork 和改 node_modules 拉回到可编排、可观测、可撤销的运行时 Patch 流程。若你的工作流卡在扩展点与 fork 之间的空白地带，可以从安装全局包、打开 Settings → Harmony 开始试用。
