奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

DeepSeek Harness 的 219 个包版本全是 0.1.0-rc.5：发布口径怎么读

2026-08-16

想搞清楚 DeepSeek Harness「现在发到哪一版了」，你会先撞上三件不太搭调的事实：仓库根 package.json 的 version 是 0.1.0-rc.5；packages/ 下每一个真实 npm 包的 version 也是 0.1.0-rc.5，一个不差；而 GitHub 的 /releases 接口在我们采集时返回的是空数组，一个 Release 都没有。

这篇就只干一件事：把这个仓库的「版本口径」拆开，讲清楚哪些数字是能读的、读出来是什么意思、哪些东西根本不在这套口径里。所有事实来自我们在 2026-08-16 取的仓库快照 47f9438（分支 master）的静态阅读与统计——我们没有安装、没有构建、没有运行过这个仓库的任何一部分。

另外先把限定摆在最前面：根 README.md:9-11 自述项目处于 developer preview，原文写着「THERE WILL BE COMPATIBILITY-BREAKING CHANGES」；仓库建立于 2026-08-13，我们采集时距建仓只有三天。下面提到的每一个包名、版本号、目录结构，都可能在你读到这篇时已经变了。

一、先把「包」数对：49 是组，219 才是包

这一步不做对，后面全错。

pnpm-workspace.yaml 里 packages: 列表的实读内容是：vendor/*、packages/*/*、native/landlock-run、native/landlock-run/packages/*、apps/*、website、examples、python/sdk-runtime。

注意其中的 packages/*/* —— 是两层 glob，不是 packages/*。所以 packages/ 下那 49 个目录是组目录（group），它们自己没有 package.json，不是 npm 包；真正的包在第二层。根 AGENTS.md:13 把这条写死成一行：「packages/ @deepseek-ai/dsh-<pkg> workspaces at packages/<group>/<pkg>/」，packages/README.md:9 也写「Groups hold packages/<group>/<pkg>/」。

我们实际数出来：packages/*/* 共 219 个目录，219 个全部有 package.json，缺失为 0。

所以，凡是看到「dsh 有 49 个包」这种说法，都是把组目录当成包数了。要说 49，得说「49 个组目录」；要说包，是 219 个（截至 2026-08-16 的快照 47f9438）。

二、219 个包，一个版本号

我们对 219 个 packages/*/*/package.json 逐个读 name 与 version，结果是两个「零例外」：

  • 219 个包的 version 全部是 0.1.0-rc.5，与根 package.json（name 为 @deepseek-ai/dsh-root）完全一致；
  • 219 个包的 name 全部以 @deepseek-ai/dsh- 开头，scope 全是 @deepseek-ai，不合规数量为 0。

命名这条对应根 AGENTS.md:100 的约定原文：「Every npm package is @deepseek-ai/dsh-<name>; vendored packages are rescoped … and private: true. @deepseek-ai/cordis is a peerDependency (+ dev) of every harness package.」

两个 app 也在同一个号上：apps/cli 的 package.json 是 @deepseek-ai/dsh，版本 0.1.0-rc.5；apps/web 是 @deepseek-ai/dsh-web-frontend，同样是 0.1.0-rc.5。

这里有个读法上的直接后果，值得说明白：当一个版本号在 219 个包上重复出现时，这个号就不承载「哪个包动过」这类信息。你没法靠比较两个包的版本号来判断谁改了、谁没改；要知道某个包这次变了什么，只能回 commit 历史或 diff 去看。这不是评价这种做法好坏——monorepo 里「所有包同步一个号」和「各包独立递增」都是常见做法，我们只陈述这个仓库在快照 47f9438 上是前者。

顺带提醒一个定位上的坑：包名的尾段不等于目录名。packages/host/* 与 packages/client/* 两组的包名要带组前缀，例如目录 host/apiproxy 的包名是 @deepseek-ai/dsh-host-apiproxy，目录 client/runtime 的包名是 @deepseek-ai/dsh-client-runtime。这条规则写在 .agents/notes/implemented/architecture/2026-07-19-gui-layering-and-rpc-protocol.md:74，原文明确写「The package-name tail therefore ≠ the directory name」。另有跨组不同名的例子：test-support/client-runtime 的包名是 @deepseek-ai/dsh-client-test-runtime，interaction/commands 的包名是 @deepseek-ai/dsh-commands（不带 interaction- 前缀）。所以按目录名去 npm 上猜包名，会猜错。

三、rc.5 与「零个 Release」是并列的两件事

截至 2026-08-16，GitHub API 对该仓库 /releases 的返回是空数组——没有任何一个 Release。而 package.json 里的号已经是 0.1.0-rc.5。

这两件事只能并列陈述，不能互相解释：package.json 的 version 字段和 GitHub Release 是两套东西，前者是仓库文件里的一个字符串，后者是平台上的一个发布对象。我们采集到的就是「文件里写 0.1.0-rc.5，平台上没有 Release」，至于中间发生过什么、有没有发到 npm、rc.1 到 rc.4 是怎么回事，我们没有依据，不推断。

一个可以照实记录的旁证是快照本身：我们在本地检出上跑 git log --oneline -1，返回的是 47f9438 Merge pull request #2519 from deepseek-harness/feat/npm-public。这就是我们采集到的最新一条提交的标题，仅此而已，我们不替它解释含义。

同一时间锚点上的另外几个数字，一并放在这里，也一并声明它们不能用来推导质量或成熟度：star 132,054、fork 13,235、open issues 0。star 数在我们采集当天几十分钟内就从 131,928 变成了 132,054，该数字变动很快，以仓库当前显示为准。「13 万 star」和「open issues 为 0、建仓只有三天」是并列的事实，不构成因果。

四、有九个包不走这套口径

vendor/ 下是被 vendored 进仓的 Cordis 生态包，它们不在 0.1.0-rc.5 这条线上。docs/rescope.md（53 行）的「Name mapping」表列了 9 个，各自有各自的版本号，例如 vendor/cordis/ 上游名 cordis、发布名 @deepseek-ai/cordis、版本 4.0.0-rc.7；vendor/schemastery/ 是 @deepseek-ai/schemastery 3.18.0；vendor/loader/ 是 @deepseek-ai/cordis-plugin-loader 1.0.0-rc.5。这 9 个包按 AGENTS.md:100 的说法是 rescope 后 private: true 的。

docs/rescope.md 同时列出改名不触及的四类：目录名与版本、依赖 range（只换 key 不换 range）、Loader 的 cordis: builtin 前缀、以及 cordis.yml 配置族。

所以「这个仓库所有包都是 0.1.0-rc.5」这句话，准确的说法是：packages/*/* 下的 219 个包 + 根 + apps/cli + apps/web 是 0.1.0-rc.5，vendor/* 的 9 个包各是各的版本。 写工具去扫版本一致性时，glob 别顺手写成 */*/package.json 把 vendor 也扫进来。

五、版本号之外，还有三层「兼容承诺」要分开读

只盯 version 字段会漏掉信息量更大的几处。它们在不同文件里，语义也不一样：

第一层，仓库自述的预发布姿态。 根 AGENTS.md:5-7 的小节标题就叫「Pre-release stance: foundation over blast radius」，正文首句是「Remove this section at the first tagged release.」，并写明在没有外部消费者的前提下，宁愿要正确的地基也不要兼容垫片，重命名或重新打包可以自由进行、所有引用一起更新。

第二层，磁盘格式的版本号。 同一段里写着后端拒绝旧的 on-disk 格式，SQLite 用单调递增的 SCHEMA_VERSION，而 dsh-session 把 SESSION_FORMAT_VERSION 保持在 0 且不给兼容承诺。docs/persistence-catalog.md:11 复述了同一条：整个格式钉在 SESSION_FORMAT_VERSION = 0，原文「pre-release, no compatibility implied」。这个 0 和包版本号 0.1.0-rc.5 是两个独立的东西，别混为一谈。

第三层，每个组自报的「Release expectation」。 packages/README.md:11-59 有一张「Group | Role | Release expectation」表，共 47 行数据行。这一列里，e2b 那行写的是 POC（packages/e2b/README.md:5 也自述是「experimental provider-composition POC」），其余 46 行写的是 Product — stable API 或 Support — …。

这里就出现了一处需要照实标出的口径差异：packages/README.md 的这一列里出现了 Product — stable API 这种写法，而根 README.md:9-11 写的是 developer preview 且会有破坏兼容性的变更、所有包的 version 又都停在 0.1.0-rc.5。两处写的是不一样的东西，位置分别是 packages/README.md:11-59 和根 README.md:9-11；以我们实读的快照状态为准。至于哪一处更能代表实际情况，我们没有依据，不做判断。

还有一处顺带记录：这张 47 行的表与 49 个真实组目录比对，mcp/ 与 runtime-diagnostics/ 两组不在表里，而同一文件 :61 写着「New packages join existing groups; new groups update their README and this table.」——同样只陈述差异。

六、你自己怎么复核

不用信这篇的任何数字，下面这段是我们跑出上面结果用的脚本，在你自己检出的仓库根目录跑一遍就能对：

python -c "
import json,glob,collections,os
vers=collections.Counter(); bad=[]
for f in glob.glob('packages/*/*/package.json'):
    j=json.load(open(f,encoding='utf-8')); vers[j['version']]+=1
    if not j['name'].startswith('@deepseek-ai/dsh-'): bad.append((f,j['name']))
print(dict(vers), 'bad:', len(bad))
print('groups:', len([p for p in os.listdir('packages') if os.path.isdir('packages/'+p)]))
"

在我们的快照 47f9438 上，它打印的是 {'0.1.0-rc.5': 219} bad: 0 与 groups: 49。

两点提示：一是 Windows 与 Linux/macOS 下这段 Python 都能跑，但 Windows 的 PowerShell 里 python -c 的引号嵌套规则和 bash 不同，把脚本存成 .py 文件再跑更省事；二是别用 shell 的 ls packages | wc -l 去数包，那数出来的是 49 个组目录，不是 219 个包——这正是本文开头那个坑。

如果你要判断「我引用的这个包名对不对」，比对的对象应该是 packages/<组>/<包>/package.json 里的 name 字段，不是目录路径拼出来的名字（原因见第二节）。

七、这套口径能读出什么、不能读出什么

能读出的：截至 2026-08-16 的快照 47f9438 上，这是一个把 219 个包锁在同一个版本号上的单体仓；命名规范由 AGENTS.md 明文约束且全量吻合；vendored 的 9 个包被排除在这套编号之外；仓库自己在 README、AGENTS.md、persistence-catalog.md 三处都标了预发布状态。

不能读出的：从 0.1.0-rc.5 这个号推不出任何关于稳定性、可用性、成熟度的结论；从 219 这个包数推不出复杂度或工程质量的结论；从「open issues 为 0」推不出任何东西。这些我们一律不写，因为我们既没有装过它，也没有运行过它。

最后重复一次那句限定：这个仓库建立于 2026-08-13，README 自述处于开发者预览阶段并明写会有破坏兼容性的变更。上面每一个包名、每一个版本号、每一处文件行号，都请以你手上仓库的当前内容为准。

延伸阅读

本文依据 DeepSeek Harness 官方仓库（github.com/deepseek-ai/deepseek-harness）的 README、docs/ 下的 架构与子系统文档、以及 packages/ 下的源码整理，核对日 2026-08-16，对应仓库快照 47f9438（版本 0.1.0-rc.5）。 本文内容为仓库源码与文档口径，我们没有安装、也没有运行过这个项目， 因此不涉及界面外观、操作手感与运行速度的任何描述。 该仓库建立于 2026-08-13，README 自述处于开发者预览阶段并明确说明未来会有破坏兼容性的变更， 文中出现的命令、配置与默认值随时可能变动，请以仓库最新内容为准。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员