DeepSeek Harness 的 vendor 九个包：版本号与实读全对不上

2026-08-16

先说清楚这篇要解决的问题：你想知道 DeepSeek Harness 里那份 vendored 的 Cordis 到底是哪个版本，你会去哪儿看？

仓库里有两个地方能给你答案。一个是 vendor/README.md 的 Manifest 表，九行整齐地列着目录、npm 名、上游名、版本、上游仓库和 commit；另一个是 vendor/<目录>/package.json 里的 version 字段。截至 2026-08-16 的快照 47f9438，这两处给出的答案，九行没有一行是相同的。

先弄清 `vendor/` 是干什么的

vendor/README.md:3 原文写：这个目录存放的是 Cordis 框架及其基础库的源码级 vendored 拷贝，它们被复制进这个 monorepo，而不是通过 npm 依赖引入，原文给的理由是「so that the harness fully owns its framework layer (auditable, patchable, pinned)」——让 harness 完整拥有自己的框架层，可审计、可打补丁、可钉住版本。

vendor/README.md:5 还写了两条与本文直接相关的规矩。第一，所有 vendored 包都被改名进 @deepseek-ai scope：cordis 变成 @deepseek-ai/cordis，@cordisjs/plugin-<x> 变成 @deepseek-ai/cordis-plugin-<x>。第二，原文明说「Directory names and upstream version numbers are deliberately unchanged, so the manifest below still reads as an upstream snapshot」——目录名与上游版本号刻意保持不变，因此下面这张 manifest 仍然读作一份上游快照。同一段还提到一个叫 verify-vendored-links 的 hygiene 门禁，它断言每个 vendored 名字都解析到 pnpm-lock.yaml 里的 workspace link:，且旁边没有 registry 拷贝。这条断言我们没有验证过——pnpm-lock.yaml 有六十多万字节，我们没有核对它。

差异一：九行版本号，九行都对不上

把 vendor/README.md:13-23 那张表的 Version 列，和九个目录里 package.json 的 version 字段并排放在一起，是这样：

目录	`vendor/README.md` 表中版本	`vendor/<dir>/package.json` 实读
`cosmokit/`	1.8.1（`vendor/README.md:15`）	`1.8.2`
`schemastery/`	3.18.0（`:16`）	`3.18.1`
`cordis/`	4.0.0-rc.7（`:17`）	`4.0.1`
`loader/`	1.0.0-rc.5（`:18`）	`1.0.2`
`include/`	1.0.4（`:19`）	`1.0.6`
`group/`	1.0.0（`:20`）	`1.0.1`
`timer/`	1.1.2（`:21`）	`1.1.3`
`hmr/`	1.0.15（`:22`）	`1.0.16`
`logger-console/`	1.0.0（`:23`）	`1.0.1`

最扎眼的是 cordis/ 这一行：表里写的是一个 rc（4.0.0-rc.7），文件里是一个正式版号（4.0.1）；loader/ 同样是 1.0.0-rc.5 对 1.0.2。其余七行差在补丁位。

按本站写这类内容的纪律，我只陈述差异并标明两处位置，不推断哪一处「是对的」，也不去猜为什么会这样。你需要知道的是：要引用一个 vendored 包的版本号时，两处口径不同，我们采用的是实读 package.json 的那一列。

你自己怎么核这九行

不用装任何东西，把仓库拉下来读文件就行。九个目录的 package.json 各读一次：

python -c "
import os, json
for d in sorted(os.listdir('vendor')):
    p = os.path.join('vendor', d, 'package.json')
    if os.path.isfile(p):
        j = json.load(open(p, encoding='utf-8'))
        print(d, j.get('name'), j.get('version'), j.get('private'))
"

以上为按仓库目录结构组合的核对脚本示例，以你本机的实际输出为准。这段脚本在 Windows、macOS、Linux 上写法一致；Windows 侧如果你在 PowerShell 里跑，注意把内层的双引号处理好，或者干脆把脚本存成 .py 文件再执行。跑完拿输出的第三列去对 vendor/README.md:13-23 那张表的 Version 列，你会得到和上表一样的九行。

差异二：两处文档说加了 `private: true`，九个 manifest 里一个都没有

vendor/README.md:29-50 是一份逐条列出的本地修改日志，共 18 条。vendor/README.md:31 对这份日志提了一条要求：保持它详尽——每一处与上游的分歧都必须列出。

日志的第 2 条在 vendor/README.md:34，讲的是所有 package.json 都被重新生成，其中一项原文写「added private: true」。仓库根目录的 AGENTS.md:100 也写着 vendored 包 private: true。

实读的结果是：grep -n '"private"' vendor/*/package.json 没有任何输出；用上面那段 Python 读九个 manifest 的 private 字段，九个结果全部是未设置。

也就是说，vendor/README.md:34 与 AGENTS.md:100 两处都写到的这个字段，在 vendor/cosmokit/package.json、vendor/schemastery/package.json、vendor/cordis/package.json、vendor/loader/package.json、vendor/include/package.json、vendor/group/package.json、vendor/timer/package.json、vendor/hmr/package.json、vendor/logger-console/package.json 这九个文件里都不存在。同样，只陈述差异与位置，到此为止。private 这个字段在包管理器里的确切语义，请以官方文档为准，本文不展开，也不据此推断任何后果。

顺便划清 `vendor/` 的边界：哪些收了，哪些没收

既然核到了这一层，把这九个包之外的边界也一并记下来，省得你去 vendor/ 里翻一个根本不在这儿的包。

vendor/README.md:25 列出的是留在 npm 上、没有被 vendored 的第三方依赖：@standard-schema/spec、js-yaml、chokidar、picomatch、@babel/code-frame、supports-color、node-addon-require-builtin。vendor/README.md:27 则列出刻意不 vendored 的一组，原文注明这个集合经验证未被使用：reggol、@cordisjs/utils、@cordisjs/element，以及 @cordisjs/unyaml（原文写它只是开发期的 YAML import hook）。

体量上，整个 vendor/ 目录的 TypeScript 源码在我们采集时是 34 个文件、6,550 行（排除 node_modules、lib、dist 与 .d.ts），其中 vendor/cordis/ 占 9 个文件、2,693 行。这九个文件逐个数下来是：context.ts 146 行、events.ts 352 行、fiber.ts 754 行、index.ts 14 行、logger.ts 270 行、reflect.ts 418 行、registry.ts 337 行、service.ts 115 行、utils.ts 287 行。也就是说，这一层「被完整拥有」的框架代码，规模是可以一个下午读完的——这也是我们敢逐行核对上面那张表的原因。

同一张表里还有一处值得注意：上游仓库不是同一个

既然已经把 manifest 表逐行读了一遍，顺带记录表内另一件事实：这九行的「上游仓库」列填的不是同一个地址。

vendor/README.md:17-18 给 cordis/ 与 loader/ 填的是 https://github.com/cordiverse/cordis（commit 以 56b3d4f7 开头）；:19-23 给 include/、group/、timer/、hmr/、logger-console/ 填的是 https://github.com/deepseek-harness/cordis（commit 以 abb0a307 开头）；:15-16 给 cosmokit/ 与 schemastery/ 填的是 https://github.com/deepseek-harness/ 下的仓库。而仓库 README.md:7 提到 Cordis 时，给读者的链接是 https://github.com/cordiverse/cordis。

我们没有访问过其中任何一个链接，这里记录的只是仓库文件里写着的字符串。

`vendor/cordis/README.md` 是另一份文档

翻 vendor/ 时很容易踩的一个坑：vendor/README.md 与 vendor/cordis/README.md 不是同一份东西。后者是 vendored 目录里保留下来的上游 README，它的口径跟本仓的 rescope 政策对不上。

具体来说：vendor/README.md:5 说全部 vendored 包已改名进 @deepseek-ai scope，而 vendor/cordis/README.md 的 Install 段写的是 yarn add cordis，Quick Start 的代码里 import 的是未加 scope 的 'cordis'，Packages 表里列的是 @cordisjs/plugin-loader 这类上游名。它的 Documentation 段给了四个相对链接，指向 ../../docs/tutorials/build-a-plugin.md、../../docs/guides/plugin-lifecycle.md、../../docs/guides/loader-config.md、../../docs/api/core.md；实读本仓，docs/tutorials、docs/guides、docs/api 这三个目录都不存在。它的 Packages 表还列了 create-cordis 与 @cordisjs/utils，而 vendor/ 下只有九个包目录，并且 vendor/README.md:27 明确把 @cordisjs/utils 列进了「刻意不 vendored（已验证该集合未使用）」的名单里。

所以，当你想照着 vendor/cordis/README.md 敲一条安装命令或抄一段 import 时，先回头看 vendor/README.md:5 的改名规则。本仓自己的 tutorial 里，import 写的是 import type { Context } from '@deepseek-ai/cordis'。

那份 18 条的修改日志本身值得读

绕回 vendor/README.md:29-50。除了第 2 条那个 private: true，这份日志里还有几条直接影响你理解 Cordis 行为的内容，比如第 6 条（:38）记的是 cordis/src/fiber.ts 的生命周期加固，其中一条是「effect 创建在 owner 处于 UNLOADING 时被拒绝（PENDING 与 LOADING 仍合法）」——这一条与 vendor/cordis/src/fiber.ts:419-422 的实读代码是一致的；第 18 条（:50）写条目的 disabled: !!js 表达式在每次挂载决策时对 loader context 求值，并明写 disabled 是唯一被插值的元数据字段。

vendor/README.md:52-60 还写了一份 5 步的同步流程，最后一步是在仓库根跑 pnpm install && pnpm run test && pnpm run build。我们没有跑过其中任何一步。

最后一层限定

以上全部数字与位置的时间锚点是 2026-08-16，对应快照 47f9438。这个仓库建立于 2026-08-13，README.md:9-11 有独立的 Developer preview 小节，原文用全大写写着 THERE WILL BE COMPATIBILITY-BREAKING CHANGES.（会有破坏兼容性的变更），根 package.json 的 version 是 0.1.0-rc.5，我们采集时该仓库没有任何 GitHub Release。也就是说，本文逐行核对的这张表、这九个 version、以及那条修改日志，随时可能在下一次提交里变成另一个样子。核对方式是长效的，具体数值不是——想引用时，请自己按上面的方式在你手上的那份快照里再数一遍。

延伸阅读

从头读起：DeepSeek Harness 是什么：建仓三天、13 万 star 的 Agent 框架
本专题共 45 篇，完整分组目录见专题页
DeepSeek Harness 的 Cordis scope：术语表说扁平，源码是父子链
DeepSeek Harness 的「一切皆插件」：Cordis 到底承担了什么

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