DeepSeek Harness 处于开发者预览阶段，这意味着运行时会变，插件必须说明自己是针对什么版本构建的。那个声明就是 dshTarget 字段，把它写对，决定了一个插件是到处都能装，还是会悄悄坏掉。
清单里有什么
插件清单是向 harness 和目录站点描述这个包的元数据。实践中它存在于 package.json 里，外加一小段 harness 专用的配置块。真正重要的字段有：
| 字段 | 用途 | 说明 |
|---|---|---|
| name | 包的身份 | 必须与发布的名称完全一致 |
| version | 发布版本 | 遵循 semver；用户会锁定这个版本 |
| type | 模块系统 | 现代插件填 module |
| keywords | 被发现 | 包含 dsh-plugin 和 deepseek-harness |
| dsh.target | Harness 兼容性 | 你实际测试过的版本 |
| license | 法律层面的清晰度 | 大多数目录站点都要求 |
| repository | 事实来源 | 目录站点用它来做收录和活跃度判断 |
凡是目录站点无法从这些字段读到的东西，它要么猜得很糟，要么留空。也正因如此，清单值得被当作面向用户的内容来对待，而不是构建元数据。
dshTarget 如何运作
dshTarget 声明你的插件是针对哪个 harness 版本构建并测试的，例如 rc.6。它是一份契约，不是猜测。用户在安装前会拿它和自己已装的 harness 对比，目录站点则用它来过滤收录。
三条规则能让它保持有用：
- 声明你实际测试过的版本。一个在
rc.5上测过、从未在rc.6上跑过的插件，就应该写rc.5。 - 在采用新运行时能力的同一次提交里更新它，而不是把它丢进一个人们会忘记的独立版本里。
- 永远不要声明超出你需要的新目标版本。声称支持某个假想中的未来版本，只会把现有的用户推开，而没有任何好处。
如何声明
在 package.json 里：
{
"name": "dsh-my-plugin",
"version": "0.3.0",
"type": "module",
"keywords": ["dsh-plugin", "deepseek-harness", "web-search"],
"license": "MIT",
"repository": "https://github.com/you/dsh-my-plugin",
"dsh": { "target": "rc.6" }
}在 README 里，也用平实的语言再说一遍，因为人总是先读 README：
已在 DSH rc.6 上测试。在更早的版本上，工具仍会注册，但
streaming 状态字段不可用。描述失败模式，而不只是描述版本号，才能把一条兼容性说明变成用户能据以行动的东西。
插件不兼容时会怎样
失败通常是可读的：运行时报告该插件加载出错，而会话的其余部分继续运行。你真正想避免的，是那种能加载、随后行为异常的插件，因为在用户看来那像是 harness 的 bug，会带来一堆令人困惑的反馈。
如果你的插件接触的是你知道变化频繁的接入面，比如界面渲染或事件负载结构，就在加载时加一个运行时检查，并用清晰的信息拒绝激活。拒绝加载是一种比加载得很糟更好的用户体验。
兼容性作为一种收录信号
目录站点会展示兼容性，因为它回答了用户在安装前会问的那个问题：这东西能在我的 harness 上跑吗。在本站，该字段出现在每个插件页面上，与验证等级和最近更新日期并列，这样你既能判断它能否运行，也能判断还有没有人在维护它。
FAQ
dshTarget 会取代 peer 依赖声明吗？
不会。它的作用是把 harness 兼容性传达给用户和目录站点。依赖范围仍然决定包的解析结果。
应该多久抬高一次？
每当你采用一项新的运行时能力，或完成一轮兼容性适配时。不必每个版本都动。
一个插件能同时支持两个 harness 版本吗？
通过单个声明做不到。如果确实需要覆盖一个范围，请在 README 里说明，并针对两个版本都做测试。
如果完全不做声明呢？
插件仍然可以安装。目录站点会把兼容性标为未知，这会明显减少安装量，因为用户无法判断它是否适配。
下一步
阅读 Cordis 生命周期指南了解这些字段背后的运行时行为，然后发布你的插件。