DeepSeek Harness 依赖托管实践：vendor/ 目录下 Cordis 框架的源码托管、本地修改与同步流程

人工智能AI AgentAgent 框架DeepSeek【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址https://gitcode.com/gh_mirrors/de/deepseek-harness点击查看免费下载DeepSeek HarnessEverything is a Plugin以 Everything is a Plugin 为设计理念其插件运行时建立在 Cordis 元框架之上。为了让插件框架层完全可控可审计、可打补丁、版本可固定仓库没有把 Cordis 及其基础库作为 npm 依赖引入而是在vendor/目录下以**源码快照source-vendored copies**方式托管了整个框架层。本文以 vendor/README.md 为骨架结合pnpm-workspace.yaml、scripts/check-vendor-manifest.sh、scripts/rescope-vendor.ts、docs/cookbook/adding-a-vendored-package.md、docs/rescope.md及多个测试用例完整解读托管清单Manifest、18 条本地修改日志、更新同步流程以及新增一个托管包的逐文件操作清单。为什么选择源码托管而非 npm 依赖vendor/目录的定位在 vendor/AGENTS.md 中有明确说明这里存放的是Cordis 框架及其基础库的源码托管副本source-vendored copies。它们被直接复制进这个 monorepo而不是通过 npm 依赖其根本原因是harness 需要完全拥有自己的框架层——可审计auditable、可打补丁patchable、版本可固定pinned。这种做法的直接后果是一套完整的重命名rescope规则所有托管包都被重命名为deepseek-aiscopecordis→deepseek-ai/cordiscordisjs/plugin-x→deepseek-ai/cordis-plugin-x。原因在 vendor/README.md 中解释得很清楚每一个 harness 包都把cordis声明为peer dependency因此发布 harness 时实际上会连带发布这一框架层如果以上游原名发布就会在 npm registry 上抢占squat上游的包名因此必须改到deepseek-aiscope 下。关键的设计平衡是目录名和上游版本号刻意保持不变所以 Manifest 表格读起来仍然是上游快照而 pnpm-workspace.yaml 中的linkWorkspacePackages: true让那些被保留的 semver 范围能够解析到这些固定的 workspace包括对构建产物lib/的导入。配套的纪律机制是scripts/check-vendor-manifest.sh作为 pre-commit hook 运行任何被暂存staged的vendor/*/src或 vendoredbin.js变更必须同时暂存vendor/README.md否则提交失败。这条 guard 把每次本地修改都必须登记在 Local modifications 日志里从口头约定变成了机械化的强制约束。Manifest9 个托管包的完整快照清单vendor/README.md 的 Manifest 表格记录了每个托管包的目录、npm 名、上游名、版本、上游仓库和 commit SHA目录npm 名发布名上游名版本上游仓库Commitcosmokit/deepseek-ai/cosmokitcosmokit1.8.1github.com/deepseek-harness/cosmokit16f6fc058ade66e8ac5da0033d35a8d0f279f544schemastery/deepseek-ai/schemasteryschemastery3.18.0github.com/deepseek-harness/schemasterypackages/coree67cee00ad725bd1534aee930a979ea3eec6f698cordis/deepseek-ai/cordiscordis4.0.0-rc.7github.com/cordiverse/cordispackages/core56b3d4f725681cf4556c1a8695a709cc3b6eed74loader/deepseek-ai/cordis-plugin-loadercordisjs/plugin-loader1.0.0-rc.5github.com/cordiverse/cordispackages/loader56b3d4f725681cf4556c1a8695a709cc3b6eed74include/deepseek-ai/cordis-plugin-includecordisjs/plugin-include1.0.4github.com/deepseek-harness/cordispackages/includeabb0a307cb1d3b0947f455d590cf5ba922d4caa4group/deepseek-ai/cordis-plugin-groupcordisjs/plugin-group1.0.0github.com/deepseek-harness/cordispackages/groupabb0a307cb1d3b0947f455d590cf5ba922d4caa4timer/deepseek-ai/cordis-plugin-timercordisjs/plugin-timer1.1.2github.com/deepseek-harness/cordispackages/timerabb0a307cb1d3b0947f455d590cf5ba922d4caa4hmr/deepseek-ai/cordis-plugin-hmrcordisjs/plugin-hmr1.0.15github.com/deepseek-harness/cordispackages/hmrabb0a307cb1d3b0947f455d590cf5ba922d4caa4logger-console/deepseek-ai/cordis-plugin-logger-consolecordisjs/plugin-logger-console1.0.0github.com/deepseek-harness/cordispackages/logger-consoleabb0a307cb1d3b0947f455d590cf5ba922d4caa4上游工作区upstream workspace名为cordis-workspace本地 checkout 位于~/repos/cordis-workspace。从源码可以印证这套结构的实际面貌。例如 vendor/cordis/package.jsonname为deepseek-ai/cordisversion为4.0.1注意这是harness 的发布清单版本而 Manifest 表中的4.0.0-rc.7是上游源码快照的版本两者不同publishConfig.access: public、sideEffects: false、type: moduleexports同时暴露.types default与./src/*源码子路径files包含lib/index.js、lib/types/**/*.d.ts、lib/types/**/*.d.ts.map、bin.js和srcpeerDependencies 声明了deepseek-ai/cordis-plugin-include和deepseek-ai/cordis-plugin-loader均标记 optional且使用workspace:^范围dependencies 是standard-schema/spec与deepseek-ai/cosmokit。再如 vendor/schemastery/package.json版本 3.18.1它演示了条件 exports 映射import→lib/index.mjsrequire→lib/index.cjs。README 中专门解释了为什么要保留这个映射pnpm 链接的是目录本身如果缺少exportsNode 的 ESM resolver 会回退到main并加载 CJS 入口而该 CJS 入口中的惰性require(deepseek-ai/cosmokit)在 module-hook 宿主如 vitest下可能与同一链接模块的 ESM 加载产生竞争race。条件 exports 把两条加载路径显式分开杜绝了这种竞争。边界哪些留在 npm、哪些刻意不托管README 明确划出了托管边界继续留在 npm 的第三方依赖standard-schema/spec、js-yaml、chokidar、picomatch、babel/code-frame、supports-color、node-addon-require-builtin。也就是说只托管框架与基础库本身这些库的依赖树并不整体搬入。刻意不托管经验证本组包未使用reggol、cordisjs/utils、cordisjs/element以及cordisjs/unyaml它只是开发期的 YAML 导入 hook。上游 MITLICENSE文件保留在每个包的目录中如vendor/cordis/LICENSE、vendor/loader/LICENSE。18 条本地修改日志与上游的每一次分歧都必须登记vendor/README.md的 Local modifications 部分是整份文档技术含量最高的章节它要求**穷尽记录exhaustive**每一次与上游的偏离。这 18 条日志本身就构成了一部harness 如何硬化框架层的工程史。下面按主题归纳解读。面向发布的包清单重构第 2、16 条所有package.json都被重新生成新增private: true注意第 16 条后续又为cordis移除了它见下、精确的files条目包含打包运行时文件与lib/types/**/*.d.ts/.d.ts.map、缺失时补充./src/*导出、声明元数据指向lib/types并移除上游的devDependencies/scripts/repository字段。依赖与 peer 依赖范围被保留但有两个例外hmr把esbuild声明为直接 dev dependency因为其源码导入了BuildFailure类型而 pnpm 的严格 workspace 解析要求属主包声明该依赖loader要求node-addon-require-builtin^0.1.4以匹配发布应用包所使用的运行时。第 16 条是一个后续修正cordis的files列表中加入src与其余八个托管包一致。原因是 Cordis 在exports中声明了./src/*: ./src/*如果 tarball 里没有src就会发布一个指向不存在文件的导出映射同时 release 变更判定逻辑会读取files来决定 diff 是否触及 payload若包只发布构建产物就没有可匹配的跟踪路径。构建体系的重塑第 3、4、5 条tsconfig 全部重新生成统一extends仓库根目录的tsconfig.base.jsonTypeScript 中间产物输出到lib/types并声明 project references。源码内部 specifier 改造vendored TypeScript 源码中的本地相对 import/export 从上游的 specifier 形态改为显式.tsspecifier使 TypeScript 在重写时把运行时 JS 改写为.js而声明文件保留 NodeNext 安全的显式.tsspecifier。这包括loader/src/config/isolate.ts中的declare module ./entry.ts。schemastery/tsdown.config.ts与logger-console/tsdown.config.ts是仓库自有的不是上游文件它们是针对 repo-root tsdown 构建的按包构建形态覆盖双 ESMCJS 输出node/browser 分离入口读取lib/types下发出的 JS 再写出lib/下的发布运行时入口。与重新生成的 tsconfig 一样它们不属于上游同步面sync surface。Fiber 生命周期硬化第 6 条cordis/src/fiber.ts是本仓库对框架核心最深的一处本地修改它本地关闭了三个重入式销毁reentrant disposal缺口涉及 vendor/cordis/src/fiber.tseffect 的 owner-list 包装器在 setup 主体运行前注册因此从 setup 内部开始的 unload 会等待 setup 及所有已收集的 cleanup同步 setup 失败会移除包装器并回滚已收集的 cleanup。异步 cleanup 在静默quiescence前对 owner 可见Cordis 内部的 effect 组合会 join 已经运行的 cleanup而重复的公开 disposer 调用保留上游的单次结果single-shot result语义。owner 处于UNLOADING状态时拒绝创建 effectPENDING与LOADING仍合法防止 cleanup 期间的注册逃出 unload 快照。子 fiber 在internal/plugin发布前注册并接收父拥有的 disposer在激活前解析该通知新增的依赖声明排空 pending 期间附加的 effect当重入式销毁使 load epoch 在首个 checkpoint 前失效时跳过插件执行teardown 通知失败按 observer 隔离单个回调不会饿死同伴或中断 ownership cleanup。Fiber.update()返回其internal/updatewaterfall 结果使 Loader 调用方可以 await 重启同时保留同步的 config 校验。第 7 条是配套的JSDoc 充实在公共插件作者面Context、EventsService、Fiber、RegistryService、ReflectService、Service、LoggerService及其declare module ./context.ts重载添加param/returns标签与契约文档销毁语义、waterfall veto、bail 条件、错误情形。动机是网站 API-reference 生成器会渲染这些文档并对未文档化成员硬报错。这是纯注释修改无代码变更当该充实被上游化upstreamed到 fork 后可退役此条目。事务式配置协调第 8 条Loader/Include 的配置协调被改造为事务式transactionalLoader 在销毁前先导入变更后的 entry 名等待生命周期结算settlement候选应用失败时恢复之前的插件或配置。Loader settlement 在当前任务排空后重新检查受 service 门控的 fiber失败时拒绝依赖缺失的 fiber 保持 pending。Group 更新并发启动候选等待每个结果包含其所属树销毁后的兄弟启动失败live-update 失败时撤销变更与新增等待移除保留程序化选项同一性并且只在成功后持久化直接或树级变更。Include 读取并校验分离的候选内容对克隆应用补丁协调树结构然后才提交其缓存的内容/数据直接刷新失败会向上传播由调用方包含。非数组解析视为无效每次文件或 Include-config 更新都会重新应用补丁省略补丁列表时清除 overlay初始内容仅在ENOENT时回退到initial。这些行为有对应测试覆盖packages/boot/app-boot/tests/config-reload.spec.ts与packages/host/webserver/tests/webserver.spec.ts后者对应packages/host下的 web 服务器集成。HMR 的精确配置监听第 9 条hmr/src/index.ts的registerConfig()监听 module roots 之外的一个绝对配置路径包括缺失父路径下的路径串行化并合并刷新返回一个能关闭 watcher 并排空进行中工作的异步 disposer模块监听对已有基础目录做 realpath在声明 service ready 前挂接 change 监听器并使用该拼写作为 Node module-cache 同一性精确配置监听对最深的已存在监听祖先做 realpath 并恢复缺失的后缀。这些原生路径防止 Windows 短名别名与长形式 libuv 事件路径冲突同时精确配置回调保持请求的文件名。刷新失败被规范化为Error记录日志并通过并行的hmr/config-update-failed事件广播observer 失败被包含。普通 HMR watcher 发现的配置文件变更走同一条串行化路径。对应测试packages/boot/app-boot/tests/hmr-config.spec.ts。从测试源码可以看到它的引导方式bootHmr依次ctx.plugin(Loader)、ctx.plugin(Timer)、ctx.plugin(Hmr, { root, ignored, debounce, usePolling })其中包含对watch base 是文件系统别名symlink/junction场景的断言hmr/change事件与 module-cache 同一性。补丁语义的导出与修正第 11、13、14 条这是dsh --dump-config这类配置工具能工作的关键applyEntryPatches纯函数导出把include/src/index.ts中私有的applyPatches主体提取为导出的纯函数applyEntryPatches(data, patches, warn)方法委托给它并把!!jsYAML 方言导出为entryListSchema使dsh --dump-config无需启动树就能组合并打印 include 实际挂载的内容。提取的原因是配置工具绝不能重新实现并与补丁算法漂移。索引修复applyEntryPatches还会在每条insert的 entry 被添加时为其建立索引因此同一列表中的后续补丁可以配置或禁用前面补丁插入的行上游只在补丁循环前构建一次 id 索引导致插入的行无法被后续补丁触达。这一点很重要因为dsh用每个 bundle 的补丁层、profile 级与 home 级cordis.patch.yml以及任何--patchoverlays 作为同一 include 层的兄弟补丁列表组合出一个空 profile root——补丁永远不会跨 include 边界否则仅存在于表面的行无法从用户配置触达。writeTask类型放宽可选的writeTask?: NodeJS.Timeout属性放宽为NodeJS.Timeout | undefined——防抖写入器在 flush 时赋值undefined而exactOptionalPropertyTypes会拒绝普通 optional 上的该赋值。纯类型修改无行为变化。持久化的防抖写入串行化并跟踪配置文件写入以有界退避重试瞬时的EACCES/EBUSY/EPERMrename 失败观察异步 timer rejection并在 Include teardown 期间排空最新的写入。Windows 在 Loader 子进程销毁后可能短暂保留目标句柄上游 fire-and-forget 的 rename 会逃逸为未处理 rejection并可能丢失持久化的disabled状态。终态失败由异步写入器记录日志并保留在队列上使Include.stop()重新抛出它而不是静默声明持久化完成。对应测试packages/host/directory-picker-auto/tests/loader-composition.spec.ts其中注入了瞬时与终态 rename 失败。Include 子树的串行化与初始扫描抑制第 12 条串行化子树变更每个 Include 的子树变更初始应用、刷新、internal/update补丁重应用都经过一个 per-Include 队列因为 group 的事务式update不可重入——两个并发 apply 会在同一批 entries 上交错 create 与 rollback使 Include fiber 永远无法结算。HMR 主 watcher 的ignoreInitial: true初始扫描会重新公告 boot 刚刚消费过的文件其针对配置文件的add会在初始 apply 中途刷新 Include而一旦串行化失败的初始 apply 的 rollback 会销毁 HMR其 teardown drain 又在等待位于同一 apply 之后的排队刷新——一个无诊断地以 exit 13 退出的死锁。registerConfig()保留自己的ignoreInitial: falsewatcher因为注册时存在的用户补丁层必须应用一次。对应测试apps/cli/tests/built-bin.e2e.ts中的 patch-overlay boot-failure 内置二进制用例。惰性配置解析第 15 条跨cordis/src/{events,fiber}.ts、loader/src/{index,config/entry}.ts、include/src/index.ts和hmr/src/index.ts实现惰性 Loader 配置解析移植自上游 PRcordiverse/cordis#41保留原始 fiber 配置仅在声明的注入injections激活后才通过internal/config解析它Provider 替换会重新解析原始表达式pending 更新保留它HMR 传递它。解析只应用于 entry 根因此某行挂载的子插件保持调用方拥有的配置同一性。Include 声明EntryGroup.key树载体标记与 Group 相同其配置是 entry 与补丁列表因此插值保持字面量嵌套行配置中的!!js表达式在该行自己的 fiber 中惰性解析Include 自己的path因此也保持字面量。延迟失败保留所属行的诊断树 teardown 不持久化失败驱动的自销毁。对应测试packages/boot/app-boot/tests/{app-boot,user-patches}.spec.ts、packages/boot/cmdline/tests/cmdline.spec.ts、apps/cli/tests/web-agent-presets.e2e.ts以及apps/cli/tests/built-bin.e2e.ts中内置自定义 profile 用例。发布面与 scope 重命名的收尾第 16、17、18 条第 16 条已在上文说明cordis的files加入src。第 17 条deepseek-airescope每个托管 manifest 的name、托管集合内部的每个依赖条目、以及触达它们的每个模块 specifier都使用 Manifest 表npm name列中的 scope 名。目录名、版本号、依赖范围不变没有重命名任何上游运行时标识符——Symbol.for(schemastery)与 Schemastery 的vendor:元数据字段保持上游值。同步后执行pnpm run rescope-vendor --apply即可重新应用表的两列名称就是映射映射的消费方说明见 docs/rescope.md。第 18 条entrydisabled插值loader/src/config/entry.ts中disabled: !!js表达式在每次挂载决策时针对 loader 上下文求值原始节点保留在 options 中因此写回保留!!js形式。disabled是唯一被插值的元数据字段。对应测试packages/boot/app-boot/tests/user-patches.spec.ts与apps/cli/tests/windows-shell.spec.ts。早期修改第 1、10 条第 1 条hmr/src/index.ts移除了./locales/en-US.yml/./locales/zh-CN.yml导入、Configschema 上的.i18n({...})调用以及src/locales/目录——因为这些导入需要未托管的运行时 YAML loader hookcordisjs/unyaml而 i18n 文本只本地化配置描述。第 10 条跨cordis、loader、include、hmr、schemastery标记擦除导入erased imports使 Node 原生 TypeScript transform 不会把类型当作运行时导出请求。Schemastery 源码使用 ESM 默认导出且其包声明type: module其构建的 ESM/CJS 条目保留显式.mjs/.cjs扩展名。更新一个已托管包的同步流程vendor/README.md 给出更新流程共 5 步在上游工作区记录相关子模块的git rev-parse HEAD。将包的src/以及变更时的bin.js、README.md、LICENSE复制覆盖到托管目录。重新应用上面列出的本地修改如果上游已使它们不再必要则删除——无论哪种情况都要更新日志。更新 Manifest 表中的版本与 commit hash。在仓库根目录执行pnpm install pnpm run test pnpm run build。配套的重命名再应用来自 docs/rescope.mdpnpm run rescope-vendor # 报告将发生什么变化 pnpm run rescope-vendor --apply # 重写每个引用 pnpm run rescope-vendor:check # 断言后状态在 hygiene gate 中运行 pnpm run rescope-vendor --apply --reverse # 回到上游名称同步后遵循它打印的再生成步骤pnpm install更新 lockfile、pnpm run gen-third-party-notices、pnpm run verify-translation-pairing --write更新受影响的双语配对。scripts/rescope-vendor.ts拥有上述名称映射并执行重命名映射定义在文件顶部的VENDORED_PACKAGES数组中例如{ directory: cordis, upstream: cordis, scoped: deepseek-ai/cordis }、{ directory: loader, upstream: cordisjs/plugin-loader, scoped: deepseek-ai/cordis-plugin-loader }因此没有任何引用需要手工重命名。rescope 的边界什么不被改名docs/rescope.md 明确列出重命名不触碰的部分目录名与上游源码版本vendor/hmr/仍是vendor/hmr/表中记录的是被固定源码快照的上游版本托管package.json的version字段是 harness 的发布清单版本由pnpm run release:vendor递增重新同步时恢复为上游版本。依赖范围依赖条目只改 key 不改范围——cordis: ^4.0.0-rc.7变成deepseek-ai/cordis: ^4.0.0-rc.7linkWorkspacePackages让这些保留范围解析到固定 workspace。Loader 的cordis:内建前缀cordis:include和cordis:group是协议前缀不是包名。cordis.yml配置家族包括*.cordis.yml、*.cordis.snapshot.yml与cordis.patch.yml。名称中本身就含该词的 harness 包如deepseek-ai/dsh-tool-cordis。上游运行时标识符如 Schemastery 的Symbol.for(schemastery)与其vendor:元数据字段。docs/之外的散文vendor/*/README.md、包 README 与 Agent Notes 保持原样docs/内的散文与每个 Markdown fence 则跟随重命名。读者代码需要随之改变的四个位置docs/rescope.md的表位置之前之后模块导入import { Context } from cordisimport { Context } from deepseek-ai/cordis类型化事件合并declare module cordisdeclare module deepseek-ai/cordispackage.json依赖键cordisjs/plugin-hmr: ^1.0.15deepseek-ai/cordis-plugin-hmr: ^1.0.15cordis.yml插件条目name: cordisjs/plugin-includename: deepseek-ai/cordis-plugin-include如何新增一个托管包完整操作清单如果 harness 需要另一个上游 Cordis 包例如cordisjs/plugin-http同样以固定源码方式托管在vendor/下而不是添加 npm 依赖。新增指南见 docs/cookbook/adding-a-vendored-package.md其文件级检查清单如下。1. 复制源码vendor/dir/ package.json # 来自上游rescope 名称保留 exports/type可发布 release 成员无 private 标志 tsconfig.json # extends ../../tsconfig.base.json见下方配置 src/ # 上游 src/ 原样复制 README.md LICENSE # 上游如有则一并携带tsconfig.json镜像其他托管包——rootDir: src、outDir: lib/types、上游代码所需的宽松性strictness relaxations以及它导入的每个其他托管包的references条目{ extends: ../../tsconfig.base.json, compilerOptions: { rootDir: src, outDir: lib/types, noUncheckedIndexedAccess: false, exactOptionalPropertyTypes: false, noImplicitOverride: false, noUnusedLocals: false, noUnusedParameters: false }, include: [src], references: [{ path: ../cordis }, { path: ../cosmokit }] }package.json的不变量按映射docs/rescope.mdrescopename同时保留上游的exports/type声明元数据指向lib/types发布.d.ts与.d.ts.map声明产物把 cordis 依赖列在peerDependencies中与上游 manifest 一致。托管包是可发布的 release 成员所以不能设置private: true必须设置publishConfig.access: publicversion字段跟随 harness 发布序列。传递性上游依赖必须本身已托管或已存在——托管一个包往往意味着托管它的依赖树例如cordisjs/plugin-http会拉入cordisjs/fetch-file。复制后托管 TypeScript 源码中的本地相对 import/export 使用显式.tsspecifier这是与上游不同的仓库本地构建差异rewriteRelativeImportExtensions发出.js运行时导入而声明保留 NodeNext/Node16 TypeScript 消费者可解析的显式.tsspecifier。2. 注册到根配置文件变更tsconfig.base.json向paths添加npm-name: [./vendor/dir/src]tsconfig.host.json向references添加{ path: ./vendor/dir }放在packages/*条目之前vendored 代码只通过 host aggregate 进入依赖图vendor/README.md添加 Manifest 表行dir、npm 名、版本、上游仓库、commit SHA并记录任何本地修改scripts/publint-all.ts仅当托管包本身从这里发布时才需要托管依赖通常不是——跳过以下由 glob 自动覆盖无需编辑根package.jsonworkspacesvendor/*、tsdown.config.ts、vitest.config.ts、.oxlintrc.json。仅当构建配置不同于根默认双 ESM/CJS 或多项 entry——见vendor/schemastery与vendor/logger-console时才需要 per-package 的vendor/dir/tsdown.config.ts其 entry 应读取lib/types下发出的 JS。3. 注意 manifest guardscripts/check-vendor-manifest.shpre-commit hook在vendor/*/src下有暂存内容但vendor/README.md未同时暂存时失败。源码与 manifest 更新必须同批暂存提交才能通过。4. 验证pnpm install # 注册 workspace pnpm run typecheck pnpm run build pnpm run constraints再运行由 docs/development.mdtesting 政策选定的行为检查。paths源码映射在tsconfig.base.json中只出现一次并服务于所有依赖图。重要的隔离边界是 project-reference 图vendored 源码必须通过其自身的vendor/dir/tsconfig.json被引用而不是被拉进 aggregate 的严格 program。从测试与配置看这套机制的实际落地本文反复引用的测试文件在仓库中均可找到它们是理解上述机制的最好入口packages/boot/app-boot/tests/config-reload.spec.ts —— 事务式 Loader/Include 配置协调与补丁语义packages/boot/app-boot/tests/hmr-config.spec.ts —— HMR 精确配置监听含 symlink/junction 别名场景packages/boot/app-boot/tests/user-patches.spec.ts —— entrydisabled插值与用户补丁层packages/host/directory-picker-auto/tests/loader-composition.spec.ts —— Include 持久化写入的注入式失败测试apps/cli/tests/built-bin.e2e.ts —— 内置二进制的 patch-overlay 启动失败与自定义 profile 用例。配置层面pnpm-workspace.yaml 通过linkWorkspacePackages: true与overridesdeepseek-ai/cosmokit: link:vendor/cosmokit、deepseek-ai/schemastery: link:vendor/schemastery把这些固定源码接入整个 monorepo 的依赖解析scripts/check-vendor-manifest.sh 则在提交边界上强制源码改动必登记。这套组合保证了 DeepSeek Harness 的框架层既能跟随上游演进可同步、可重命名又能承载超出上游范围的硬化修改生命周期、事务性、持久化、跨平台同时把每一次分歧都沉淀为可审计的文档契约。总结DeepSeek Harness 对 Cordis 框架层的处理方式可以概括为四个原则源码托管可审计、可打补丁、版本固定、scope 重命名可发布且不抢占上游包名、差异登记18 条修改日志与 manifest guard 强制同步暂存、同步流程化5 步更新 rescope 再应用 根级验证。对于需要在自身插件架构之上做深度改造、又想保持与上游同步能力的项目来说vendor/目录的做法提供了一套完整的、有测试与门禁支撑的参考实践。赞分享人工智能AI AgentAgent 框架DeepSeek【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址https://gitcode.com/gh_mirrors/de/deepseek-harness点击查看免费下载相关推荐DeepSeek Harness 的 Vendored 包治理Cordis 框架源码级内嵌、本地修改纪律与同步流程DeepSeek Harness 的 Vendored 包治理Cordis 框架源码级内嵌、本地修改纪律与同步流程 本篇文章围绕 DeepSeek Harne人工智能AI AgentAgent 框架DeepSeekDeepSeek Harness 框架层自持有将 Cordis 以源码形式收录Vendor的决策与工程实践DeepSeek Harness 框架层自持有将 Cordis 以源码形式收录Vendor的决策与工程实践 本文基于仓库内 Agent Note 2026人工智能AI AgentAgent 框架DeepSeekDeepSeek Harness 源码级 Vendor Cordis把框架层完全握在自己手里的工程实践DeepSeek Harness 源码级 Vendor Cordis把框架层完全握在自己手里的工程实践 导读 DeepSeek Harness 构建于 Cor人工智能AI AgentAgent 框架DeepSeek上一篇Spring Profiles实战pig平台开发/测试/生产环境配置隔离最佳实践下一篇如何快速优化kiss-translator行高与间距设置提升阅读体验的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考