DeepSeek Harness 源码级 Vendor Cordis把框架层完全握在自己手里的工程实践【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness导读DeepSeek Harness 构建于 Cordis 框架之上但并没有把 Cordis 当作普通的 npm 依赖引入而是将框架核心与基础库以固定 commit 的源码快照形式直接复制进仓库的vendor/目录通过 pnpm workspace 的linkWorkspacePackages机制让全仓库包括构建产物透明地解析到这份自持的源码。这篇文章以仓库中的 技术决策记录ADR 为主线结合 vendor/README.md 的清单与修改日志、pnpm-workspace.yaml 的解析机制、以及scripts/下的机械化守卫脚本完整还原为什么 vendor、vendor 了什么、如何保证 vendor 纪律、如何同步与新增这一整套工程方案。读完你不仅能理解这套做法的动机与代价还能直接照着仓库里的清单与 cookbook 复现同款流程。背景与问题为什么框架层不能直接npm install框架内部行为就是产品正确性的一部分DeepSeek Harness 是一个 agent harness智能体执行框架其核心的 agent loop智能体循环建立在 Cordis 框架之上。仓库启动这个工程时Cordis core 处于4.0.0-rc.6release candidate候选发布版——一个尚未正式发布的版本。问题的关键在于harness 依赖的不是 Cordis 的公开 API而是框架的内部实现细节fiber 生命周期fiber lifecycleCordis 中一个插件挂载单元fiber从加载、激活到卸载的完整生命周期管理effect disposal资源释放effect副作用在 fiber 卸载时如何被收集、回滚与清理waterfall 分发瀑布式事件分发事件沿着事件链逐级传递并允许中途否决veto的分发机制。agent loop 的正确性保证比如一轮工具调用结束后所有资源必须被确定性释放某个事件可以被下游拦截直接取决于这些内部行为的确切表现。而一个 RC 版本意味着上游随时可能在不打招呼的情况下调整这些内部语义。直接依赖 npm 包的风险决策记录明确否决了直接依赖 npm 包这条最省事的路线理由非常直接core 处于候选发布阶段上游 RC 一次 bump 就可能破坏 harness 依赖的内部行为一旦破坏由于框架行为被封装在 node_modules 里项目没有一条本地的修复路径——只能干等上游发布修复版本或者被迫 fork 后切换依赖源而这又会引入新的不确定性。这正是经典的依赖锁定困境锁版本号锁得住 semver锁不住同一版本号下内部实现是否被我们真正控制这件事。对于把框架内部语义当作正确性契约的项目唯一彻底的解法就是把源码本身拿过来。决策以源码形式 Vendor 框架层收录范围框架层全收第三方依赖留在 npm决策的核心是只持有我们依赖其内部实现的框架层而不是递归地把依赖树全部复制进来。最终的收录范围落在vendor/目录下共 9 个包目录布局见 vendor/目录npm 名发布用上游名上游版本角色vendor/cordis/deepseek-ai/cordiscordis4.0.0-rc.7框架核心Context、Service、Fiber、事件vendor/cosmokit/deepseek-ai/cosmokitcosmokit1.8.1框架与 Schemastery 依赖的共享工具库vendor/schemastery/deepseek-ai/schemasteryschemastery3.18.0配置 schemaSchema支撑每个插件的Configvendor/loader/deepseek-ai/cordis-plugin-loadercordisjs/plugin-loader1.0.0-rc.5cordis.yml加载、插件解析、仓库缓存vendor/include/deepseek-ai/cordis-plugin-includecordisjs/plugin-include1.0.4配置 include 与 patch 覆盖层vendor/group/deepseek-ai/cordis-plugin-groupcordisjs/plugin-group1.0.0嵌套插件组vendor/timer/deepseek-ai/cordis-plugin-timercordisjs/plugin-timer1.1.2可随 fiber 释放的ctx定时器vendor/hmr/deepseek-ai/cordis-plugin-hmrcordisjs/plugin-hmr1.0.15插件与配置的热更新vendor/logger-console/deepseek-ai/cordis-plugin-logger-consolecordisjs/plugin-logger-console1.0.0控制台日志导出器而真正第三方的依赖js-yaml、chokidar、standard-schema/spec、picomatch、babel/code-frame、supports-color、node-addon-require-builtin等依然留在 npm 上由 pnpm 正常解析。同时清单还明确记录了刻意不收录的包reggol、cordisjs/utils、cordisjs/element、cordisjs/unyaml后者只是 dev-time 的 YAML 导入钩子与运行时无关。布局扁平化 保留上游版本号Vendor 目录采用扁平化布局vendor/目录/下直接是src/、package.json、tsconfig.json、README.md、LICENSE一个包一层没有嵌套的 workspace 前缀。目录名与上游版本号刻意保持与上游一致比如vendor/cordis/的 manifest 记录上游版本 4.0.0-rc.7这样 vendor/README.md 里的清单读起来仍然是一份上游快照同步时 diff 一目了然。值得注意的是最初 ADR 决定保留原始 npm 包名但后续的 rescope 决策见 docs/rescope.md 与 .agents/notes/implemented/process/2026-08-10-vendor-package-rescope.md将 9 个包全部改名为deepseek-aiscope。原因是harness 的每个包都把cordis声明为 peerDependency发布 harness 就意味着连带发布这层框架如果沿用上游原名发布行为相当于在 npm registry 上抢占squat上游的包名。改名只动包名目录名、上游版本号、依赖范围、上游运行时标识符如 Schemastery 的Symbol.for(schemastery)全部不变。透明解析的关键linkWorkspacePackages: trueVendor 能否透明工作的核心机制在 pnpm-workspace.yamlpackages: - vendor/* - packages/*/* - native/landlock-run - native/landlock-run/packages/* - apps/* - website - python/sdk-runtime # Vendored framework packages keep their upstream semver ranges, while local # builds must resolve those matching names to this workspaces pinned sources. linkWorkspacePackages: truevendor/*直接进了 workspace 列表而linkWorkspacePackages: true意味着只要某个依赖声明的 semver 范围与某个 workspace 包的名字版本匹配pnpm 就把它解析到这个 workspace而不是去 registry 拉取同名包。由于 vendored 包保留了上游的版本号如^4.0.0-rc.7所有 harness 包对框架的依赖声明会原样命中这些固定的 workspace——无论是以 TypeScript 源码跑测试还是构建后的lib/产物被引用解析结果都是同一份 vendored 源码。这一点在 vendor/cordis/package.json 中有直接体现内部依赖写的是deepseek-ai/cosmokit: workspace:^、可选 peer 依赖deepseek-ai/cordis-plugin-loader: workspace:^全部显式锚定到 workspace杜绝任何 registry 副本混入的可能。Manifest 即契约vendor/README.md 与机械化守卫清单表每个包一个 commit SHAvendor/README.md 是这层框架的权威 manifest开头即说明收录动机copied into this monorepo instead of being depended on via npm, so that the harness fully owns its framework layer (auditable, patchable, pinned)可审计、可打补丁、版本锁定。清单表为每个包记录 6 个字段目录、npm 名、上游名、版本、上游仓库、commit SHA。例如cordis/上游cordis4.0.0-rc.7commit56b3d4f725681cf4556c1a8695a709cc3b6eed74cordiverse/cordispackages/corecosmokit/上游cosmokit1.8.1commit16f6fc058ade66e8ac5da0033d35a8d0f279f544hmr/、include/、group/、timer/、logger-console/统一锚定 commitabb0a307cb1d3b0947f455d590cf5ba922d4caa4。有了包 → 上游仓库 → commit的精确映射任何一次本地改动都能回溯到它基于的上游基线diff 表面始终是已知的。修改日志本地与上游的每一处分歧都必须登记Manifest 的第二部分是详尽的本地修改日志Local modifications目前记录到第 18 条覆盖了package.json重建、tsconfig.json重建、TypeScript 内部导入 specifier 改造、hmr 的 locale-YAML 移除以及一批深层的框架行为补丁后文详述。这条日志的纪律是保持穷尽——每一处与上游的分歧都必须列出。这份日志同时是同步时的重放清单上游更新后哪些补丁需要重新应用、哪些可以丢弃一目了然。三条机械化防线让vendor 纪律不依赖人肉自觉仓库用三个脚本把它变成了硬约束1. pre-commit 守卫 scripts/check-vendor-manifest.shstaged$(git diff --cached --name-only) vendor_src_changed$(echo $staged | grep -E ^vendor/[^/]/(src/|bin\.js) || true) manifest_changed$(echo $staged | grep -x vendor/README.md || true) if [[ -n $vendor_src_changed -z $manifest_changed ]]; then echo vendor manifest guard: vendored SOURCE changed without updating vendor/README.md: ... exit 1 fi逻辑简单但有效任何暂存区里vendor/*/src或 vendoredbin.js的改动必须同时包含vendor/README.md的改动否则提交被拒绝。该脚本已挂进 lefthook.yml 的pre-commit任务job 名为vendor manifest guard与 lint、第三方法务声明third-party notices等检查并列。2. lockfile 解析校验 scripts/verify-vendored-links.ts这是 hygiene卫生门禁。它扫描pnpm-lock.yaml对每个 importer 里出现的 vendored 包名断言其version以link:开头——否则构建会在不知不觉中使用 registry 副本对packages/snapshots区段断言不存在以 vendored 包名为前缀的 registry 条目如deepseek-ai/cordis4.0.0-rc.7。它把移除 workspace 链接后构建产物会静默改用 npm 副本这类隐患直接堵死linkWorkspacePackages一旦失效这个门禁会在 CI 里报错而不是等到运行时出现难以排查的框架行为漂移。3. rescope 校验 scripts/rescope-vendor.tsrescope 脚本同时承担改名与校验pnpm run rescope-vendor --check断言改名后无残留、每条 exact edit 都命中、再次--apply是幂等的。它有一个重要设计只重写带定界符的完整包名 token引号包裹的cordis、cordis/subpath、YAML 的name: cordis从而天然排除cordis.yml、Loader 的cordis:协议前缀、cordisagent preset id、cordiverse/cordis等恰好含这个词但并非包引用的场景改名的精确性由脚本而非人肉保证。本地修改日志里的关键工程补丁Manifest 的修改日志记录了 18 条本地分歧其中几条值得单独展开因为它们直接服务于 agent harness 的核心正确性fiber 生命周期加固日志第 6 条cordis/src/fiber.ts本地封堵了三处重入式reentrant释放漏洞——effect 的 owner 列表包装器在 setup 执行体运行前注册使得从 setup 内部发起的卸载能等待 setup 与所有已收集的 cleanup同步 setup 失败时移除包装器并回滚已收集的 cleanupfiber 处于UNLOADING状态时拒绝创建新 effectPENDING/LOADING仍合法防止清理期注册逃出卸载快照。此外Fiber.update()现在返回internal/updatewaterfall 的结果使 Loader 调用方在保持同步配置校验的同时可以await一次重启。事务化 Loader/Include 配置对账日志第 8 条Loader 先导入变更后的 entry 再释放旧者候选应用失败时恢复原插件/配置Group 更新并发启动候选、等待所有结果并在活更新失败时撤销变更Include 只在成功后才提交缓存内容。这些行为由 packages/boot/app-boot/tests/config-reload.spec.ts 等测试覆盖。HMR 精确配置监听与初始扫描抑制日志第 9、12 条registerConfig()监听模块根之外的绝对配置路径、序列化并合并刷新、返回可释放的异步 disposer主 watcher 使用ignoreInitial: true避免启动阶段刚消费过的文件被重复 announce、以及 Include 初始化中途被刷新导致死锁曾出现退出码 13 且无诊断的故障。applyEntryPatches导出日志第 11 条把 Include 的私有补丁应用逻辑抽取为纯函数导出使dsh --dump-config能在不启动整棵 fiber 树的情况下精确打印 Include 挂载后的配置配置工具永远不需要也不会重实现补丁算法。懒加载配置解析日志第 15 条移植上游 PRcordiverse/cordis#41原始 fiber 配置仅在声明注入激活后才通过internal/config解析保证disabled: !!js这类表达式在正确的上下文里求值。这些补丁大多不是改 bug而是把框架语义加固到 agent harness 需要的强度——这正是拥有框架层的价值你可以直接在仓库内修框架而不是去上游开 issue 然后等待。上游同步与新增包两条被写下来的流程同步既有包的五步流程Manifest 末尾写明了手动的同步过程因为上游同步是刻意保持手动的以控制 diff 面在上游 workspace 记录相关子模块的git rev-parse HEAD把包的src/以及变更的bin.js、README.md、LICENSE复制覆盖到 vendored 目录重新应用上述本地修改若上游已使其不再必要则删除对应日志条目——无论如何都要更新日志更新清单表中的版本与 commit hash在仓库根执行pnpm install pnpm run test pnpm run build。同步后还需执行 rescope 的重新应用pnpm run rescope-vendor --apply以及它提示的连锁操作pnpm install更新 lockfile、pnpm run gen-third-party-notices重生成第三方声明、pnpm run verify-translation-pairing --write重新记录受影响的双语文档对。新增一个 vendor 包的 checklist当 harness 需要另一个上游 Cordis 包例如cordisjs/plugin-http时docs/cookbook/adding-a-vendored-package.md 提供了逐文件清单核心步骤复制源码vendor/dir/下放src/上游原样、package.json改名 rescope、保留exports/type、声明元数据指向lib/types、publishConfig.access: public、tsconfig.jsonextends仓库根tsconfig.base.jsonrootDir: src并为依赖的其他 vendored 包声明references注册到根配置在 tsconfig.base.json 的paths加一项npm-name: [./vendor/dir/src]、在 tsconfig.host.json 的references加一项、在vendor/README.md清单表加一行并登记本地修改vendor/*等 glob 覆盖的 workspace/构建/vitest 配置则无需改动注意 manifest 守卫vendor/*/src的暂存变更必须与vendor/README.md的暂存变更同 commit验证pnpm install注册 workspace然后pnpm run typecheck、pnpm run build pnpm run constraints再按 docs/testing.md 的选择运行行为测试。cookbook 特别强调了一个边界事实vendor 一个包往往意味着 vendor 它的依赖树例如cordisjs/plugin-http会拉入cordisjs/fetch-file这与真正的第三方依赖留 npm的分界线并不冲突——分界线是我们是否依赖其内部实现。后果与权衡这套方案的收益和代价按决策记录总结这套方案换来的是四条明确的收益框架层完全自持可审计、可打补丁、版本锁定。上游 RC 无法再导致本项目故障框架 bug 可以在仓库内直接修复——这正是本地修改日志里 18 条补丁存在的意义源码与产物执行同一份框架构建后的包与源码测试运行的是同一代 vendored Cordis反过来一旦移除 workspace 链接构建产物会在包名不变的情况下静默改用 npm 副本——这正是verify-vendored-links门禁要拦截的失效模式diff 面始终可知commit SHA 清单 穷尽式修改日志让本地相对上游改了哪里永远可审计第三方依赖保持正常供应链js-yaml、chokidar等仍由 npm 解析没有把整个依赖树都拖进源码库。对应的代价与约束也写在文档里上游同步是手动的需要按 manifest 流程逐包操作并重放补丁——这是换取可控所付出的运维成本vendored 包保留上游代码风格lint 与严格性门禁将它们排除其tsconfig.json本地放宽了仓库较新的编译器选项如noUncheckedIndexedAccess、exactOptionalPropertyTypes等名称必须 rescope到deepseek-ai否则发布 harness 会在 registry 上抢占上游包名——这带来一套额外的改名/校验工具链。从仓库现状看这套决策不是纸面文档vendor/下 9 个包的真实源码、18 条修改日志、三个守卫脚本、两份流程文档manifest 的同步流程与 cookbook 的新增流程全部落地且互相引用。对于框架内部行为即正确性契约的工程这正是everything is a plugin背后的地基——先把地基握在自己手里再谈插件化。进一步阅读决策原文英文.agents/notes/implemented/process/2026-06-11-vendor-cordis-as-source.md中文.zh.md包清单、修改日志与同步流程vendor/README.mdworkspace 解析与安全策略pnpm-workspace.yaml守卫脚本scripts/check-vendor-manifest.sh、scripts/verify-vendored-links.ts、scripts/rescope-vendor.ts名称映射与 rescope 说明docs/rescope.md新增 vendor 包的操作指南docs/cookbook/adding-a-vendored-package.md门禁挂接点lefthook.yml【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/20 13:27:41 · 阅读 1.2k DeepSeek Harness 源码级 Vendor Cordis：把框架层完全握在自己手里的工程实践
DeepSeek Harness 源码级 Vendor Cordis把框架层完全握在自己手里的工程实践【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness导读DeepSeek Harness 构建于 Cordis 框架之上但并没有把 Cordis 当作普通的 npm 依赖引入而是将框架核心与基础库以固定 commit 的源码快照形式直接复制进仓库的vendor/目录通过 pnpm workspace 的linkWorkspacePackages机制让全仓库包括构建产物透明地解析到这份自持的源码。这篇文章以仓库中的 技术决策记录ADR 为主线结合 vendor/README.md 的清单与修改日志、pnpm-workspace.yaml 的解析机制、以及scripts/下的机械化守卫脚本完整还原为什么 vendor、vendor 了什么、如何保证 vendor 纪律、如何同步与新增这一整套工程方案。读完你不仅能理解这套做法的动机与代价还能直接照着仓库里的清单与 cookbook 复现同款流程。背景与问题为什么框架层不能直接npm install框架内部行为就是产品正确性的一部分DeepSeek Harness 是一个 agent harness智能体执行框架其核心的 agent loop智能体循环建立在 Cordis 框架之上。仓库启动这个工程时Cordis core 处于4.0.0-rc.6release candidate候选发布版——一个尚未正式发布的版本。问题的关键在于harness 依赖的不是 Cordis 的公开 API而是框架的内部实现细节fiber 生命周期fiber lifecycleCordis 中一个插件挂载单元fiber从加载、激活到卸载的完整生命周期管理effect disposal资源释放effect副作用在 fiber 卸载时如何被收集、回滚与清理waterfall 分发瀑布式事件分发事件沿着事件链逐级传递并允许中途否决veto的分发机制。agent loop 的正确性保证比如一轮工具调用结束后所有资源必须被确定性释放某个事件可以被下游拦截直接取决于这些内部行为的确切表现。而一个 RC 版本意味着上游随时可能在不打招呼的情况下调整这些内部语义。直接依赖 npm 包的风险决策记录明确否决了直接依赖 npm 包这条最省事的路线理由非常直接core 处于候选发布阶段上游 RC 一次 bump 就可能破坏 harness 依赖的内部行为一旦破坏由于框架行为被封装在 node_modules 里项目没有一条本地的修复路径——只能干等上游发布修复版本或者被迫 fork 后切换依赖源而这又会引入新的不确定性。这正是经典的依赖锁定困境锁版本号锁得住 semver锁不住同一版本号下内部实现是否被我们真正控制这件事。对于把框架内部语义当作正确性契约的项目唯一彻底的解法就是把源码本身拿过来。决策以源码形式 Vendor 框架层收录范围框架层全收第三方依赖留在 npm决策的核心是只持有我们依赖其内部实现的框架层而不是递归地把依赖树全部复制进来。最终的收录范围落在vendor/目录下共 9 个包目录布局见 vendor/目录npm 名发布用上游名上游版本角色vendor/cordis/deepseek-ai/cordiscordis4.0.0-rc.7框架核心Context、Service、Fiber、事件vendor/cosmokit/deepseek-ai/cosmokitcosmokit1.8.1框架与 Schemastery 依赖的共享工具库vendor/schemastery/deepseek-ai/schemasteryschemastery3.18.0配置 schemaSchema支撑每个插件的Configvendor/loader/deepseek-ai/cordis-plugin-loadercordisjs/plugin-loader1.0.0-rc.5cordis.yml加载、插件解析、仓库缓存vendor/include/deepseek-ai/cordis-plugin-includecordisjs/plugin-include1.0.4配置 include 与 patch 覆盖层vendor/group/deepseek-ai/cordis-plugin-groupcordisjs/plugin-group1.0.0嵌套插件组vendor/timer/deepseek-ai/cordis-plugin-timercordisjs/plugin-timer1.1.2可随 fiber 释放的ctx定时器vendor/hmr/deepseek-ai/cordis-plugin-hmrcordisjs/plugin-hmr1.0.15插件与配置的热更新vendor/logger-console/deepseek-ai/cordis-plugin-logger-consolecordisjs/plugin-logger-console1.0.0控制台日志导出器而真正第三方的依赖js-yaml、chokidar、standard-schema/spec、picomatch、babel/code-frame、supports-color、node-addon-require-builtin等依然留在 npm 上由 pnpm 正常解析。同时清单还明确记录了刻意不收录的包reggol、cordisjs/utils、cordisjs/element、cordisjs/unyaml后者只是 dev-time 的 YAML 导入钩子与运行时无关。布局扁平化 保留上游版本号Vendor 目录采用扁平化布局vendor/目录/下直接是src/、package.json、tsconfig.json、README.md、LICENSE一个包一层没有嵌套的 workspace 前缀。目录名与上游版本号刻意保持与上游一致比如vendor/cordis/的 manifest 记录上游版本 4.0.0-rc.7这样 vendor/README.md 里的清单读起来仍然是一份上游快照同步时 diff 一目了然。值得注意的是最初 ADR 决定保留原始 npm 包名但后续的 rescope 决策见 docs/rescope.md 与 .agents/notes/implemented/process/2026-08-10-vendor-package-rescope.md将 9 个包全部改名为deepseek-aiscope。原因是harness 的每个包都把cordis声明为 peerDependency发布 harness 就意味着连带发布这层框架如果沿用上游原名发布行为相当于在 npm registry 上抢占squat上游的包名。改名只动包名目录名、上游版本号、依赖范围、上游运行时标识符如 Schemastery 的Symbol.for(schemastery)全部不变。透明解析的关键linkWorkspacePackages: trueVendor 能否透明工作的核心机制在 pnpm-workspace.yamlpackages: - vendor/* - packages/*/* - native/landlock-run - native/landlock-run/packages/* - apps/* - website - python/sdk-runtime # Vendored framework packages keep their upstream semver ranges, while local # builds must resolve those matching names to this workspaces pinned sources. linkWorkspacePackages: truevendor/*直接进了 workspace 列表而linkWorkspacePackages: true意味着只要某个依赖声明的 semver 范围与某个 workspace 包的名字版本匹配pnpm 就把它解析到这个 workspace而不是去 registry 拉取同名包。由于 vendored 包保留了上游的版本号如^4.0.0-rc.7所有 harness 包对框架的依赖声明会原样命中这些固定的 workspace——无论是以 TypeScript 源码跑测试还是构建后的lib/产物被引用解析结果都是同一份 vendored 源码。这一点在 vendor/cordis/package.json 中有直接体现内部依赖写的是deepseek-ai/cosmokit: workspace:^、可选 peer 依赖deepseek-ai/cordis-plugin-loader: workspace:^全部显式锚定到 workspace杜绝任何 registry 副本混入的可能。Manifest 即契约vendor/README.md 与机械化守卫清单表每个包一个 commit SHAvendor/README.md 是这层框架的权威 manifest开头即说明收录动机copied into this monorepo instead of being depended on via npm, so that the harness fully owns its framework layer (auditable, patchable, pinned)可审计、可打补丁、版本锁定。清单表为每个包记录 6 个字段目录、npm 名、上游名、版本、上游仓库、commit SHA。例如cordis/上游cordis4.0.0-rc.7commit56b3d4f725681cf4556c1a8695a709cc3b6eed74cordiverse/cordispackages/corecosmokit/上游cosmokit1.8.1commit16f6fc058ade66e8ac5da0033d35a8d0f279f544hmr/、include/、group/、timer/、logger-console/统一锚定 commitabb0a307cb1d3b0947f455d590cf5ba922d4caa4。有了包 → 上游仓库 → commit的精确映射任何一次本地改动都能回溯到它基于的上游基线diff 表面始终是已知的。修改日志本地与上游的每一处分歧都必须登记Manifest 的第二部分是详尽的本地修改日志Local modifications目前记录到第 18 条覆盖了package.json重建、tsconfig.json重建、TypeScript 内部导入 specifier 改造、hmr 的 locale-YAML 移除以及一批深层的框架行为补丁后文详述。这条日志的纪律是保持穷尽——每一处与上游的分歧都必须列出。这份日志同时是同步时的重放清单上游更新后哪些补丁需要重新应用、哪些可以丢弃一目了然。三条机械化防线让vendor 纪律不依赖人肉自觉仓库用三个脚本把它变成了硬约束1. pre-commit 守卫 scripts/check-vendor-manifest.shstaged$(git diff --cached --name-only) vendor_src_changed$(echo $staged | grep -E ^vendor/[^/]/(src/|bin\.js) || true) manifest_changed$(echo $staged | grep -x vendor/README.md || true) if [[ -n $vendor_src_changed -z $manifest_changed ]]; then echo vendor manifest guard: vendored SOURCE changed without updating vendor/README.md: ... exit 1 fi逻辑简单但有效任何暂存区里vendor/*/src或 vendoredbin.js的改动必须同时包含vendor/README.md的改动否则提交被拒绝。该脚本已挂进 lefthook.yml 的pre-commit任务job 名为vendor manifest guard与 lint、第三方法务声明third-party notices等检查并列。2. lockfile 解析校验 scripts/verify-vendored-links.ts这是 hygiene卫生门禁。它扫描pnpm-lock.yaml对每个 importer 里出现的 vendored 包名断言其version以link:开头——否则构建会在不知不觉中使用 registry 副本对packages/snapshots区段断言不存在以 vendored 包名为前缀的 registry 条目如deepseek-ai/cordis4.0.0-rc.7。它把移除 workspace 链接后构建产物会静默改用 npm 副本这类隐患直接堵死linkWorkspacePackages一旦失效这个门禁会在 CI 里报错而不是等到运行时出现难以排查的框架行为漂移。3. rescope 校验 scripts/rescope-vendor.tsrescope 脚本同时承担改名与校验pnpm run rescope-vendor --check断言改名后无残留、每条 exact edit 都命中、再次--apply是幂等的。它有一个重要设计只重写带定界符的完整包名 token引号包裹的cordis、cordis/subpath、YAML 的name: cordis从而天然排除cordis.yml、Loader 的cordis:协议前缀、cordisagent preset id、cordiverse/cordis等恰好含这个词但并非包引用的场景改名的精确性由脚本而非人肉保证。本地修改日志里的关键工程补丁Manifest 的修改日志记录了 18 条本地分歧其中几条值得单独展开因为它们直接服务于 agent harness 的核心正确性fiber 生命周期加固日志第 6 条cordis/src/fiber.ts本地封堵了三处重入式reentrant释放漏洞——effect 的 owner 列表包装器在 setup 执行体运行前注册使得从 setup 内部发起的卸载能等待 setup 与所有已收集的 cleanup同步 setup 失败时移除包装器并回滚已收集的 cleanupfiber 处于UNLOADING状态时拒绝创建新 effectPENDING/LOADING仍合法防止清理期注册逃出卸载快照。此外Fiber.update()现在返回internal/updatewaterfall 的结果使 Loader 调用方在保持同步配置校验的同时可以await一次重启。事务化 Loader/Include 配置对账日志第 8 条Loader 先导入变更后的 entry 再释放旧者候选应用失败时恢复原插件/配置Group 更新并发启动候选、等待所有结果并在活更新失败时撤销变更Include 只在成功后才提交缓存内容。这些行为由 packages/boot/app-boot/tests/config-reload.spec.ts 等测试覆盖。HMR 精确配置监听与初始扫描抑制日志第 9、12 条registerConfig()监听模块根之外的绝对配置路径、序列化并合并刷新、返回可释放的异步 disposer主 watcher 使用ignoreInitial: true避免启动阶段刚消费过的文件被重复 announce、以及 Include 初始化中途被刷新导致死锁曾出现退出码 13 且无诊断的故障。applyEntryPatches导出日志第 11 条把 Include 的私有补丁应用逻辑抽取为纯函数导出使dsh --dump-config能在不启动整棵 fiber 树的情况下精确打印 Include 挂载后的配置配置工具永远不需要也不会重实现补丁算法。懒加载配置解析日志第 15 条移植上游 PRcordiverse/cordis#41原始 fiber 配置仅在声明注入激活后才通过internal/config解析保证disabled: !!js这类表达式在正确的上下文里求值。这些补丁大多不是改 bug而是把框架语义加固到 agent harness 需要的强度——这正是拥有框架层的价值你可以直接在仓库内修框架而不是去上游开 issue 然后等待。上游同步与新增包两条被写下来的流程同步既有包的五步流程Manifest 末尾写明了手动的同步过程因为上游同步是刻意保持手动的以控制 diff 面在上游 workspace 记录相关子模块的git rev-parse HEAD把包的src/以及变更的bin.js、README.md、LICENSE复制覆盖到 vendored 目录重新应用上述本地修改若上游已使其不再必要则删除对应日志条目——无论如何都要更新日志更新清单表中的版本与 commit hash在仓库根执行pnpm install pnpm run test pnpm run build。同步后还需执行 rescope 的重新应用pnpm run rescope-vendor --apply以及它提示的连锁操作pnpm install更新 lockfile、pnpm run gen-third-party-notices重生成第三方声明、pnpm run verify-translation-pairing --write重新记录受影响的双语文档对。新增一个 vendor 包的 checklist当 harness 需要另一个上游 Cordis 包例如cordisjs/plugin-http时docs/cookbook/adding-a-vendored-package.md 提供了逐文件清单核心步骤复制源码vendor/dir/下放src/上游原样、package.json改名 rescope、保留exports/type、声明元数据指向lib/types、publishConfig.access: public、tsconfig.jsonextends仓库根tsconfig.base.jsonrootDir: src并为依赖的其他 vendored 包声明references注册到根配置在 tsconfig.base.json 的paths加一项npm-name: [./vendor/dir/src]、在 tsconfig.host.json 的references加一项、在vendor/README.md清单表加一行并登记本地修改vendor/*等 glob 覆盖的 workspace/构建/vitest 配置则无需改动注意 manifest 守卫vendor/*/src的暂存变更必须与vendor/README.md的暂存变更同 commit验证pnpm install注册 workspace然后pnpm run typecheck、pnpm run build pnpm run constraints再按 docs/testing.md 的选择运行行为测试。cookbook 特别强调了一个边界事实vendor 一个包往往意味着 vendor 它的依赖树例如cordisjs/plugin-http会拉入cordisjs/fetch-file这与真正的第三方依赖留 npm的分界线并不冲突——分界线是我们是否依赖其内部实现。后果与权衡这套方案的收益和代价按决策记录总结这套方案换来的是四条明确的收益框架层完全自持可审计、可打补丁、版本锁定。上游 RC 无法再导致本项目故障框架 bug 可以在仓库内直接修复——这正是本地修改日志里 18 条补丁存在的意义源码与产物执行同一份框架构建后的包与源码测试运行的是同一代 vendored Cordis反过来一旦移除 workspace 链接构建产物会在包名不变的情况下静默改用 npm 副本——这正是verify-vendored-links门禁要拦截的失效模式diff 面始终可知commit SHA 清单 穷尽式修改日志让本地相对上游改了哪里永远可审计第三方依赖保持正常供应链js-yaml、chokidar等仍由 npm 解析没有把整个依赖树都拖进源码库。对应的代价与约束也写在文档里上游同步是手动的需要按 manifest 流程逐包操作并重放补丁——这是换取可控所付出的运维成本vendored 包保留上游代码风格lint 与严格性门禁将它们排除其tsconfig.json本地放宽了仓库较新的编译器选项如noUncheckedIndexedAccess、exactOptionalPropertyTypes等名称必须 rescope到deepseek-ai否则发布 harness 会在 registry 上抢占上游包名——这带来一套额外的改名/校验工具链。从仓库现状看这套决策不是纸面文档vendor/下 9 个包的真实源码、18 条修改日志、三个守卫脚本、两份流程文档manifest 的同步流程与 cookbook 的新增流程全部落地且互相引用。对于框架内部行为即正确性契约的工程这正是everything is a plugin背后的地基——先把地基握在自己手里再谈插件化。进一步阅读决策原文英文.agents/notes/implemented/process/2026-06-11-vendor-cordis-as-source.md中文.zh.md包清单、修改日志与同步流程vendor/README.mdworkspace 解析与安全策略pnpm-workspace.yaml守卫脚本scripts/check-vendor-manifest.sh、scripts/verify-vendored-links.ts、scripts/rescope-vendor.ts名称映射与 rescope 说明docs/rescope.md新增 vendor 包的操作指南docs/cookbook/adding-a-vendored-package.md门禁挂接点lefthook.yml【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考