人工智能AI AgentAgent 框架DeepSeek【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址https://gitcode.com/gh_mirrors/de/deepseek-harness点击查看免费下载本技术指南面向需要理解或接手 DeepSeek Harnessdeepseek-ai/*多包发布流程的开发者与 CI 维护者。文章以仓库中 Agent Note以产物为先的 NPM 基线发布 为核心骨架结合 scripts/release 目录下已提交的发布脚本与测试系统讲解为什么开发环境能跑不能证明发布包能用、如何用不可变 release bundle 把 pack 与 publish 彻底隔离、如何验证 tarball 内容与安装后行为以及如何在 GitHub Actions 中实现免凭据测试与受保护发布。读完本文你将掌握这套以产物artifact为先的发布架构的核心思想、九步 pack 流程、产物平面集成测试矩阵与幂等恢复策略并能直接对照仓库源码验证每一步的落地实现。一、问题monorepo 中能运行为何不能证明能发布DeepSeek Harness 是一个 pnpm workspace 构成的 monorepo发布目标是一组互相依赖、命名空间为deepseek-ai/*的 npm 包。该 Agent Note 首先点明了发布验证的核心盲区monorepo 中可运行的源码并不能证明发布后的包可运行。原因来自四个常见的隐式补位机制workspace link开发时 pnpm 把 workspace 内依赖直接链接到源码目录缺失的构建产物被邻居包补上TypeScript pathstsconfig路径映射让源码解析绕过真实的node_modules布局tsx 源码加载开发环境直接执行 TypeScript 源码绕过了构建产物工作树残留的lib/本地构建过的旧产物可能掩盖发布 tarball 中缺失的文件。即使现有的构建产物测试使用普通 Node 执行它仍然直接读取工作树中的lib/存在两个未覆盖的关键点没有验证package.json#files最终选中了什么——files字段决定了 tarball 内容但工作树测试看不到这个筛选结果没有验证包管理器安装后的文件布局——node_modules中的最终解析路径才是消费方实际面对的世界。于是可能出现一次开发模式下完全正常的执行发布后却缺少 bundle chunk、声明文件、配置或资源。第二个问题是集合一致性。发布多个互相依赖的deepseek-ai包时如果脚本每 pack 一个包就立即 publish后续 pack 或验证失败时注册表中已经存在无法作为完整基线使用的前半组版本。npm 注册表没有跨包事务因此该提案明确承认「一次性发布」不能承诺原子提交只能承诺在任何远端写入前完整生成并验证发布集合再由一个可恢复的编排命令发布这个不可变集合。此外当时提案提出时的基线发布还需要人工在本机完成版本派生、认证、pack、发布和重试后续 GitHub Actions 工作流必须复用同一套发布包与验证逻辑不能在批准发布后重新构建另一组未经消费方测试的 tarball。二、提案核心以不可变 release bundle 为发布边界针对上述问题提案给出的核心设计是发布流程以一个不可变的 release bundle发布包集合为边界把发布拆成两个语义截然不同的阶段阶段职责关键约束pack 阶段从一个确定的 Git commit 构建全部目标包、生成全部 tarball、检查 tarball 内容、通过安装后集成测试不做任何注册表写入publish 阶段只读取这组 tarball 及其 manifest元数据清单逐包上传并做最终验证禁止重建或重新 pack这个边界的价值在于测试通过的 tarball 与实际上传的 tarball 具有相同的内容身份content identity。任何一方的偏离——无论是重新 pack、从 workspace 直接发布还是批准后重建——都会破坏已验证即已发布的保证。在仓库源码中这个边界被明确落实为两个独立的 CLI 入口scripts/release/pack.ts 顶部注释直接写着 The pack step is the release boundary: it runs without credentials, produces every tarball from one commit, and hands the publish step exactly those bytespack 步骤是发布边界它在无凭据条件下运行从一个 commit 产出全部 tarball并把恰好这些字节交给 publish 步骤scripts/release/publish.ts 同样注明发布决策是逐个包、以注册表为准进行的见下文幂等恢复一节并且只从 pack 输出目录读取绝不接受 workspace 目录作为发布输入。2.1 目标包集合的发现机制基线目标集合只包含两类 manifest 中命名为deepseek-ai/*的 workspace 包packages/*/*/package.jsonapps/*/package.json根项目、website/、vendor、Python 与 native workspace不属于该 NPM 基线。关键设计是目标集合由发现机制推导而不是维护一份手工包名列表。发现过程必须主动拒绝四类异常而不是依赖人工清单的准确性重复包名不同基础版本同一基线内版本不一致意外的private发布状态private: true的包不能发布集合中的未知包。在源码中这一逻辑位于 scripts/release/families.ts 的ReleaseFamily.members()它通过 glob 模式发现 manifest逐个校验名称必须以deepseek-ai/开头、拒绝 workspace 根包deepseek-ai/dsh-root、拒绝重复包名并把每个成员解析为{ directory, name, version, manifest }。值得说明的是源码中的ReleaseFamily抽象把发布序列划分为两个 familyfamilies.tsdsh匹配packages/!(experimental)/*/package.json与apps/*/package.json全 family 共享同一版本tag 前缀为dsh-v发布 payload 执行拒绝源码与声明映射的门禁对应本文发布 payload 约定一节vendor匹配vendor/*/package.json每个包保持独立版本线发布时保留上游的src树与声明映射因为其exports[./src/*]面向源码导航删除src会发布一个 export 指向缺失文件的不一致包。源码注释还表明存在第三条发布序列native/由其他模块管理本模块只负责dsh与vendor两条序列。这印证了提案中根项目、website、vendor、Python 与 native workspace 不属于该 NPM 基线的分工表述——vendor 拥有自己的发布序列只是不在本文讨论的基线集合内。2.2 预发布版本与 dist-tag 的派生规则为了让每次 pack 产生的 tarball 具有可追溯、可重试的身份提案定义了确定性的版本派生公式base-YYYYMMDDHHmmss-short-commitbase包的稳定基础版本来自目标 commit 的根 manifestYYYYMMDDHHmmss命令启动时精确到秒的 UTC 时间戳short-commit目标 commit 的 10 位短 SHA。dist-tag 由基础版本派生dev-base提案给出的示例基础版本0.0.1、时间2026-08-04T00:32:00Z、commit909292dd7b则生成版本0.0.1-20260804003200-909292dd7btagdev-0.0.1重试语义同一 release bundle 的重试必须沿用原版本与 manifest重新 pack 会按新的命令启动时间生成新版本。这保证了恢复 重跑 publish 同一 manifest而不是重新生成另一组版本号。2.3 pack 阶段九步流程提案为 pack 阶段规定了严格有序的执行步骤每一步都在为不可变 bundle这一目标服务解析与派生将 ref 解析成不可变 commit采集 UTC 时间戳从该 commit 的根 manifest 派生版本并显示 commit、时间戳、版本、tag、注册表和输出路径。pack与release都会在昂贵操作开始前等待 Enter自动化可用--yes跳过该确认。隔离检出与约束检查在隔离的 detached worktree 中安装 frozen lockfile并在暂存前运行源码 manifest 发布约束。调用方工作树中的未提交文件和旧构建输出不得参与发布。manifest 暂存将所有目标 manifest 暂存为派生版本移除发布时的private标记并把dependencies、devDependencies、optionalDependencies与peerDependencies中的内部 workspace 依赖全部改写为同一精确版本。完整构建完整构建目标 commit再运行 publint 和已构建包不变式built-package invariants。pack为目标集合中的每个包执行 pack但不执行任何注册表写入。tarball 检查检查 tarball 内的 package manifest、文件清单、内部依赖版本、包名和版本并拒绝缺失、重复或额外的 tarball。生成 release manifest包含 commit、版本、tag、注册表、每个包的 tarball 路径、SHA-256 与 npm integrity同时生成校验和文件。隔离消费方安装与集成测试从本地 tarball 安装一个隔离消费方运行当前实现已有的安装态产物探测并将这些探测扩展为产物平面集成测试矩阵见本文第五部分。输出发布命令仅当整个集合通过时输出一个可直接执行的 publish 命令pack 命令本身始终保持无远端写入。本地release命令组合 pack 与 publish先通过 pack 确认并确定预期时间戳和版本pack 成功后等待第二次 Enter随后发布同一 manifestrelease --yes跳过两次确认。独立的pack与publish --manifest仍是 CI 分 job 和断点恢复使用的基础操作。三、当前实现边界仓库中已提交的发布脚本提案文档专门辟出当前实现边界一节说明已提交的 pack 命令实现了哪些能力。这些能力与仓库中 scripts/release 目录的代码逐一对应已实现的能力来自提案文档并经源码印证固定 commit 暂存与内部依赖精确固化对应 families.ts 的 family 发现、版本校验以及 bump.ts 的版本统一dshfamily 要求所有成员共享一个版本源码verifyVersions在 families.ts 直接断言versions.size ! 1即失败。静态与 tarball payload 检查静态 manifest 门禁与 tarball 内容门禁共用 scripts/publication-payload.ts 的validateTarballPayloadpackMember在 pack.ts 中每次 pack 后立即调用family.validatePayload(member, tarballFiles(tarball))。不可变 manifestpack 输出目录同时写入publish-order.txt记录上传顺序publish 阶段只按该顺序读取 tarball见 tarball.ts 的PUBLISH_ORDER_FILE与readPublishOrder。隔离 npm 安装把每个发布 tarball 都作为本地顶层依赖安装进 monorepo 之外的临时目录见 verify-packed-install.ts——它创建mkdtempSync临时目录、写入只含file:依赖的package.json、执行npm install --no-audit --no-fund --package-lockfalse --omitoptional并清理NODE_OPTIONS、NODE_PATH、npm_config_user_agent等环境变量杜绝宿主环境干扰。安装后的入口探测在输出 publish 命令前用普通 Node 运行安装后的dsh --version与dsh --dump-default-config两个入口再在 POSIX PTY 中启动安装后的默认 TUI等待其main-session-就绪信号并通过/exit退出。verify-packed-install.ts 中可以看到--version探测的落地运行安装目录内node_modules/deepseek-ai/dsh/lib/bin.js --version并断言输出与 tarball 声明的版本一致。Publish 按 integrity 恢复将只读注册表验证与认证身份检查分离并以完整的远端 integrity 和 dist-tag 验证结束对应 publish.ts 的实现详见本文第六部分。明确不在当前实现内属于提案范围的能力PRPull RequestCI不会调用 pack 命令安装态入口探测属于本地发布检查不是合并门禁免凭据 CI 执行、其他每个 bin 与公开运行时入口的包自有探测、workflow artifact 传递及受保护 publish job 仍属于提案范围将在 GitHub Actions 集成部分展开。四、发布 payload 约定tarball 里到底该有什么提案对发布 payload 给出了严格的门禁约定目的是让 tarball 成为消费方唯一需要的真实世界禁止项双门禁package.json#files禁止包含src和lib/types/**/*.d.ts.maptarball 内容门禁独立确认不存在任何package/src/**与package/**/*.d.ts.map——这条独立的 tarball 检查是为了防止 manifest pattern 或 pack 行为绕过静态约束。源码中的 publication-payload.ts 给出了精确实现isForbiddenPublicationFile对路径做规范化剥离package/前缀后拒绝三类路径——src、src/前缀、以及.d.ts.map/.js.map后缀validateTarballPayload遍历 tarball 成员逐一判定。注意.js.map也在拒绝之列理由如源码注释所述——map 服务于开发期编辑器导航已发布的 map 不解析任何东西所以任何 payload 都不应携带。必须收齐项运行时 JS、声明文件.d.ts、配置、资源、worker 文件和 bundle 动态 chunk必须按实际入口闭包entry closure收齐——即从每个导出入口出发、递归追踪其运行时所依赖的一切文件。源码平面与发布 payload 的分离重要设计源码 manifest 可以保留exports[./src/*]供本仓库的源码平面解析使用该 export不代表源码会进入发布 payload也不属于已发布包的消费方约定静态门禁必须分别检查源码平面与发布 payload不能通过删除 source export 来掩盖错误的 workspace 解析也不能通过发布src来修补缺失的构建产物。tarball 内部一致性约束每个 tarball 必须不含workspace:specifier所有指向本次发布集合的内部依赖与对等依赖peer dependency都必须精确等于本次派生版本禁止^、~或其他 semver 范围跨越 commit 基线除了明确仅供源码平面使用的exports[./src/*]package manifest 中声明的每个消费方入口都必须指向 tarball 内存在的文件动态 import、运行时拼接路径和非 export 资源不能只靠 manifest 检查必须由安装后执行覆盖——这正是产物平面集成测试存在的原因。五、产物平面集成测试把 tarball 当消费方来运行集成测试是 pack 阶段第 8 步运行时机是全部 tarball 生成后、任何 publish 之前。它的目标非常明确证明files选中的 payload 是完整的且发布的依赖范围能够解析。5.1 执行环境约束测试在 monorepo 外创建一个全新临时项目通过本次 release manifest 中的本地.tgz文件安装声明依赖闭包并从安装目录执行。禁止参与解析的六类事物tsxtsconfig pathsworkspace link仓库源码路径工作树lib/已发布注册表中的同版本包测试还要断言关键模块与 bin 的真实路径位于临时消费方内——仅靠行为成功不足以保证路径证据必须证明没有回退到 monorepo。源码实现 verify-packed-install.ts 印证了这些约束consumerEnvironment删除NODE_OPTIONS与NODE_PATH防止宿主注入、把DSH_HOME与DSH_AGENTS_HOME指向消费方内目录、禁用遥测packedDependencies读取所有 pack 输出目录中的.tgz将每个包映射为file:URL 依赖——这意味着测试消费方所需的全部 tarball 都来自本地 pack 输出唯一的注册表流量是外部依赖。源码注释还特别说明了一个跨序列细节harness 包把 vendored 框架声明为 peer而 vendor 属于另一条发布序列一次 PR 可能同时 bump 两条序列因此 dsh 验证会把 vendor family 的 pack 输出也一并传入--from可多次指定但发布时只发布自己的 family。5.2 客户端选择npm 还是 pnpm安装使用本次发布选择的客户端行为注册表上传必须使用npmCLI以满足私有注册表只接受 npm 客户端的策略构建编排仍可使用 pnpmtarball 测试不得先把这些包发布到真实注册表也不得在测试后重新 pack。源码中pack 用pnpm pack --pack-destinationpack.ts消费方安装与发布用npm install/npm publishverify-packed-install.ts、publish.ts与这一约定完全一致。5.3 至少覆盖的执行面测试至少覆盖以下四类执行面静态 CLI 入口 动态模式入口deepseek-ai/dsh安装后的dsh --version与dsh --dump-default-config在普通 Node 下成功。真实 TUI 启动路径安装后的默认dsh在 PTY 中完成一次无密钥 TUI 启动到达既定 ready 信号后由测试受控退出。这条路径必须加载真实 TUI 动态 chunk因此缺少类似lib/tui-*.js的发布文件会使门禁失败。每个其他已发布 bin 的包级冒烟命令每个 bin 都定义一个不会访问真实服务或修改用户状态的包级冒烟命令不同 CLI不强制共用--help测试必须运行其真实安装入口并检查约定的退出或 ready 信号。Node 兼容的公开运行时入口从安装目录加载浏览器、worker 或必须由宿主协议驱动的入口使用对应的隔离 fixture测试前置数据但输入仍只能是本次 tarball。提案特别强调这些测试验证可执行性不替代单元测试、快照、真实 API e2e 或 publint。测试 fixture 应复用现有 built-bin 和 PTY 场景的行为断言但必须把入口改为 tarball 安装结果——直接运行工作树lib/bin.js的测试不能算作本门禁。5.4 为什么只跑--help不够这是提案考虑过的替代方案中的关键一条详见本文第七部分Commander 可以在加载 TUI、Web 或 headless 动态入口之前输出帮助并退出--help无法证明默认生产启动路径完整。因此基线测试选择--version静态入口--dump-default-config动态模式入口 PTY 中完整 TUI 启动的组合确保动态 chunk 真的被加载。六、发布与幂等恢复publish 命令的执行顺序与恢复策略同样有严格规定。6.1 发布前校验publish 命令先验证以下内容再按确定顺序上传 tarballrelease manifest所有本地校验和目标注册表npm pingnpm whoami。命令只接受 pack 阶段生成的 manifest不接受 workspace 目录作为发布输入。默认注册表为https://registry.npm.harnessment.com/该地址在仓库 scripts/publish-npm-baseline.ts 中亦有引用可交叉印证每次 publish 都显式传入注册表和派生 tag避免用户级.npmrc改变目标。6.2 幂等恢复三态决策npm 不提供多包原子事务上传仍会逐包发生。编排器通过幂等恢复缩小失败面对每个包基于远端状态做三态决策远端状态动作不存在nameversion上传已存在且 integrity 与 release manifest 相同跳过已存在但内容不同立即失败dist-tag 检查只读取 tag 映射不解析默认 tag 指向的版本——因此即使无关 tag 指向的版本已不存在也不会阻断恢复。完成后必须逐包确认版本 integrity 和 dist-tag 都指向本次版本只有整个集合通过最终验证工作流才报告发布成功。失败语义如果 pack、tarball 检查或安装后集成测试失败注册表必须保持零写入。如果 publish 在部分上传后失败操作者使用同一 release manifest重跑 publish 命令来恢复不得重新 pack并生成另一个时间戳版本来代替恢复。只有修复代码或改变构建输入后需要不同 tarball 时才重新执行完整 pack 与测试。6.3 源码中的落地实现scripts/release/publish.ts 完整实现了上述语义三态决策registryState()通过npm view nameversion dist.integrity --json查询远端返回absent或present{integrity}两种状态。主循环对每个 tarball远端缺失则发布已存在且 integrity 等于本地sha512-base64则跳过已存在但不同则抛出错误提示 Bump the version, or investigate why the build is not reproducible.临时性错误的有限重试TRANSIENT_PUBLISH_CODES定义了一组写操作未落定的注册表错误码——E409、E429、E500、E502、E503、E504、ETIMEDOUT、ECONNRESET、EAI_AGAIN每次重试前先重新查询注册表因为E409可能对应一次其实已落地的写入——如果远端已存在且 integrity 与本地一致则视为成功继续。单包最多尝试PUBLISH_ATTEMPTS 4次间隔PUBLISH_SPACING_MS 2000ms并以 2 的幂退避2000ms → 4000ms → 8000ms。预发布版本不打 latest tagversion.includes(-)时为--tag next。不传--access注释说明两条序列不共享同一 access 级别命令行 flag 无法同时服务两者由每个打包后的 manifest 自行决定并由check-workspace-constraints约束各 manifest 保持其序列的级别。上传顺序严格按 pack 输出的publish-order.txt顺序执行进度以[n/total]输出跳过已有包时不等待间隔连续发布之间才有 2 秒间距。6.4 发布顺序的确定依赖拓扑为什么上传顺序必须确定因为中断后留下的是完整基线的前缀这一性质依赖顺序。ReleaseFamily.publishOrderfamilies.ts实现了确定性排序install 边dependenciesoptionalDependencies绝对遵守npm 在安装时解析这些依赖消费方先于其依赖发布会留下无法组装的窗口install 边上的环被视为缺陷直接报错而非绕行peer 边peerDependencies能排则排npm 不会替包安装 peer未满足的 peer 只是警告而非解析失败sibling 包互相声明 peer 会形成环此时该边被放弃排序并显式报告——放弃一条排序约束是对真实发布的决定操作者必须在 pack 日志中判断新增的 dropped edge 是否符合预期最终输出还会被一次后置校验兜底任何消费方排在它所安装的依赖之前的顺序都会导致失败。该排序逻辑有完整的单元测试覆盖见 scripts/release/families.spec.ts——测试覆盖了依赖先于消费方发布且同名平局按名排序、运行时依赖环被报错而非任意排序、peer 先于消费方、peer 环被绕行并报告被放弃的边、install 边在 peer 环包围下仍被遵守、拒绝消费方先于依赖的顺序、排序时忽略 devDependencies等场景。七、GitHub Actions 集成免凭据测试 受保护发布CI 集成采用两个职责分离的 job把能验证与有凭据彻底拆开。7.1 两个 job 的分工Job凭据职责pack-and-test job无凭据检出精确 commit调用与本地相同的 pack 入口运行 tarball 消费方测试上传完整 release bundle 作为工作流产物publish job受保护依赖前者成功从工作流产物下载 bundle重新校验 manifest 和校验和再调用同一个 publish 入口不能检出后重新构建关键约束publish job 必须使用同一 workflow run 生成的 bundle不能按版本号从不受信任的位置寻找 tarball。这保证了测试输入与发布输出的内容身份一致。7.2 触发策略与凭据保护PR 与普通 push 可以运行无凭据的 pack-and-test 信号从而在合并前发现 payload 回归实际私有注册表发布先通过workflow_dispatch提供输入只包括目标 refUTC 时间戳由 pack job 生成基础版本、短 SHA、tag、注册表和包清单都由仓库状态或受版本控制的配置派生稳定发布触发方式不在该基线提案范围内注册表 token 只注入 publish job并由受保护 GitHub Environment 控制人工批准、允许的分支或 tag 以及并发pack-and-test job 不得读取发布凭据工作流产物的保留期可以较短。此外scripts/release/verify.ts 实现了发布时的门禁逻辑通过RELEASE_PUBLISHtrue环境变量进入发布模式后它会校验所有成员可发布拒绝private: true并校验GITHUB_REF必须是本 family 的发布 tag如dsh-v*且该 tag 命名的版本必须确实是本 family 携带的版本——发布只发生在 GitHub Actions 中因此这些检查是工作流门禁而非本地建议。verify.ts还会在任何构建之前解析发布顺序并打印完整顺序与 dropped peer 边让 PR 上对顺序的改动可审查test-invariants 层面在 families.spec.ts 中亦有对应断言。八、考虑过的替代方案及其否决理由提案明确记录了几条被否决的路线每一条的否决理由都指向本设计的核心动机替代方案否决理由从 workspace 直接递归 publish命令会把 pack 与注册表写入交错无法在第一次写入前证明整个集合完整也容易让 workspace 解析与调用方工作树状态影响发布结果只测试工作树中构建后的lib/验证的是构建树不是package.json#files选出的 tarball工作树中存在而 tarball 中漏掉的动态 chunk 正是本提案必须捕获的失败只运行dsh --helpCommander 可以在加载 TUI、Web 或 headless 动态入口之前输出帮助并退出无法证明默认生产启动路径完整把src和声明映射一起发布以降低漏文件风险源码平面不是生产运行时的后备路径扩大 payload 会掩盖 bundle 闭包错误并把本地调试产物变成无意的发布约定要求真正的跨包原子发布npm 注册表没有相应事务不可变 release bundle、发布前全量验证、integrity 比对与幂等恢复提供可实现的边界同时明确保留部分上传短暂可见的限制在批准后由发布 job 重新构建测试通过的 tarball 与实际上传的 tarball 将不再具有内容身份工作流产物与校验和必须把测试输入直接传给发布步骤九、验收标准提案的验收标准可以归纳为七条可验证的能力也是判断该设计是否落地到位的检查清单单入口发现与确认一个 pack 入口从确定 commit 发现packages/*/*和apps/*的全部目标包以 UTC 秒级时间戳与短 commit 生成并显示版本再等待 Enter它在任何注册表写入前生成完整 release bundle并输出一个可复制的 publish 命令release在 pack 后再次等待--yes跳过两次确认。双门禁静态 manifest 门禁和 tarball 内容门禁都拒绝发布src与.d.ts.map同时保留源码 manifest 中的exports[./src/*]。不可变 bundle 与精确固化release bundle 记录完整包集合、commit、派生版本、tag、注册表和逐 tarball integrity所有内部依赖都精确固化到该版本publish 只消费该 bundle绝不重建。隔离 TUI 启动一个隔离集成测试从本地 tarball 安装消费方并用普通 Node 启动安装后的默认dshTUI删除任一所需动态 chunk 会使该测试稳定失败。全量入口覆盖所有已发布 bin 和适用的公开运行时入口都有 tarball 安装后的执行覆盖且解析路径证明没有回退到 monorepo。安全重跑publish 可在部分成功后用同一 manifest 安全重跑相同 integrity 被跳过不同 integrity 被拒绝最终验证要求所有版本与 tag 一致。CI 凭据隔离GitHub Actions 的无凭据 job 生成并测试 bundle受保护 job 上传完全相同的 bundle发布 token 只存在于后者。十、风险与边界提案最后坦诚地列出了该设计的已知风险与尚待扩展之处性能与缓存策略全量 pack、安装和启动会增加 CI 时间与工作流产物体积。实现应缓存外部依赖和 pnpm store但不得缓存或复用目标包的已安装 workspace 输出并行执行安全的消费方 probe 可以降低时延。源码中 pack.ts 的--concurrency参数已提供有界并行池支持默认 1与有凭据发布工作流的串行执行保持一致。未声明内部依赖的掩盖风险把所有 tarball 都安装为临时项目的顶层依赖可能掩盖未声明的内部依赖顶层的node_modules扁平化会意外补全缺失声明。测试生成器应按被测应用的声明式递归闭包安装并结合现有依赖门禁对依赖面接近全集的deepseek-ai/dsh仍需依靠 package manifest 与静态图检查发现未声明边。平台差异化不同平台的 optional dependency、native addon、PTY 与浏览器入口可能需要平台专属 probe。第一阶段至少在发布所用 Linux runner 和一个本地 macOS 路径上覆盖主dsh启动后续矩阵按实际发布平台扩展不能用跳过不稳定 probe 的方式把生产路径移出门禁。部分可见性不可消除恢复机制不能消除 npm 的部分可见性。发布失败期间注册表可能短暂含有本次版本的一部分包操作者与自动化必须以最终 bundle 验证结果而非单个npm publish的成功作为基线可用信号。十一、相关源码路径索引以下文件是理解本设计落地实现的最佳入口建议结合本文对照阅读.agents/notes/proposed/process/2026-08-04-artifact-first-npm-baseline-publication.zh.md本文核心依据的提案文档另有英文版 .agents/notes/proposed/process/2026-08-04-artifact-first-npm-baseline-publication.mdscripts/release/pack.tspack 边界实现--family dsh|vendor [--out dist/npm] [--concurrency 1]scripts/release/publish.ts幂等发布与恢复--family dsh|vendor --from packed directoryscripts/release/families.tsfamily 发现、版本校验、发布顺序拓扑排序、payload 校验scripts/release/verify-packed-install.ts隔离消费方安装与入口探测scripts/release/verify.ts发布前门禁private 检查、tag 检查、顺序报告scripts/release/bump.ts版本提升与 tag 规划scripts/release/tarball.tstarball 读取与publish-order.txtscripts/publication-payload.ts发布 payload 策略拒绝src、.d.ts.map、.js.mapscripts/release/families.spec.ts发布顺序、版本基线、payload 策略的单元测试。赞分享人工智能AI AgentAgent 框架DeepSeek【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址https://gitcode.com/gh_mirrors/de/deepseek-harness点击查看免费下载相关推荐DeepSeek Harness 工件优先的 NPM 基线发布immutable release bundle 设计与实现DeepSeek Harness 工件优先的 NPM 基线发布immutable release bundle 设计与实现 本篇技术指南围绕 DeepSeek人工智能AI AgentAgent 框架DeepSeekDeepSeek Harnessdsh meta 以源码检出为 workspace 启动 TUI 的设计与实现解析DeepSeek Harness dsh meta 以源码检出为 workspace 启动 TUI 的设计与实现解析 本篇指南解析 DeepSeek Harn人工智能AI AgentAgent 框架DeepSeekDeepSeek Harness 会话日志不可变设计运行时所有权边界与 dsh-invariants 开发不变式DeepSeek Harness 会话日志不可变设计运行时所有权边界与 dsh invariants 开发不变式 会话日志是 DeepSeek Harness人工智能AI AgentAgent 框架DeepSeek创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DeepSeek Harness 以产物为先的 NPM 基线发布：不可变 Release Bundle 的设计与实现
人工智能AI AgentAgent 框架DeepSeek【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址https://gitcode.com/gh_mirrors/de/deepseek-harness点击查看免费下载本技术指南面向需要理解或接手 DeepSeek Harnessdeepseek-ai/*多包发布流程的开发者与 CI 维护者。文章以仓库中 Agent Note以产物为先的 NPM 基线发布 为核心骨架结合 scripts/release 目录下已提交的发布脚本与测试系统讲解为什么开发环境能跑不能证明发布包能用、如何用不可变 release bundle 把 pack 与 publish 彻底隔离、如何验证 tarball 内容与安装后行为以及如何在 GitHub Actions 中实现免凭据测试与受保护发布。读完本文你将掌握这套以产物artifact为先的发布架构的核心思想、九步 pack 流程、产物平面集成测试矩阵与幂等恢复策略并能直接对照仓库源码验证每一步的落地实现。一、问题monorepo 中能运行为何不能证明能发布DeepSeek Harness 是一个 pnpm workspace 构成的 monorepo发布目标是一组互相依赖、命名空间为deepseek-ai/*的 npm 包。该 Agent Note 首先点明了发布验证的核心盲区monorepo 中可运行的源码并不能证明发布后的包可运行。原因来自四个常见的隐式补位机制workspace link开发时 pnpm 把 workspace 内依赖直接链接到源码目录缺失的构建产物被邻居包补上TypeScript pathstsconfig路径映射让源码解析绕过真实的node_modules布局tsx 源码加载开发环境直接执行 TypeScript 源码绕过了构建产物工作树残留的lib/本地构建过的旧产物可能掩盖发布 tarball 中缺失的文件。即使现有的构建产物测试使用普通 Node 执行它仍然直接读取工作树中的lib/存在两个未覆盖的关键点没有验证package.json#files最终选中了什么——files字段决定了 tarball 内容但工作树测试看不到这个筛选结果没有验证包管理器安装后的文件布局——node_modules中的最终解析路径才是消费方实际面对的世界。于是可能出现一次开发模式下完全正常的执行发布后却缺少 bundle chunk、声明文件、配置或资源。第二个问题是集合一致性。发布多个互相依赖的deepseek-ai包时如果脚本每 pack 一个包就立即 publish后续 pack 或验证失败时注册表中已经存在无法作为完整基线使用的前半组版本。npm 注册表没有跨包事务因此该提案明确承认「一次性发布」不能承诺原子提交只能承诺在任何远端写入前完整生成并验证发布集合再由一个可恢复的编排命令发布这个不可变集合。此外当时提案提出时的基线发布还需要人工在本机完成版本派生、认证、pack、发布和重试后续 GitHub Actions 工作流必须复用同一套发布包与验证逻辑不能在批准发布后重新构建另一组未经消费方测试的 tarball。二、提案核心以不可变 release bundle 为发布边界针对上述问题提案给出的核心设计是发布流程以一个不可变的 release bundle发布包集合为边界把发布拆成两个语义截然不同的阶段阶段职责关键约束pack 阶段从一个确定的 Git commit 构建全部目标包、生成全部 tarball、检查 tarball 内容、通过安装后集成测试不做任何注册表写入publish 阶段只读取这组 tarball 及其 manifest元数据清单逐包上传并做最终验证禁止重建或重新 pack这个边界的价值在于测试通过的 tarball 与实际上传的 tarball 具有相同的内容身份content identity。任何一方的偏离——无论是重新 pack、从 workspace 直接发布还是批准后重建——都会破坏已验证即已发布的保证。在仓库源码中这个边界被明确落实为两个独立的 CLI 入口scripts/release/pack.ts 顶部注释直接写着 The pack step is the release boundary: it runs without credentials, produces every tarball from one commit, and hands the publish step exactly those bytespack 步骤是发布边界它在无凭据条件下运行从一个 commit 产出全部 tarball并把恰好这些字节交给 publish 步骤scripts/release/publish.ts 同样注明发布决策是逐个包、以注册表为准进行的见下文幂等恢复一节并且只从 pack 输出目录读取绝不接受 workspace 目录作为发布输入。2.1 目标包集合的发现机制基线目标集合只包含两类 manifest 中命名为deepseek-ai/*的 workspace 包packages/*/*/package.jsonapps/*/package.json根项目、website/、vendor、Python 与 native workspace不属于该 NPM 基线。关键设计是目标集合由发现机制推导而不是维护一份手工包名列表。发现过程必须主动拒绝四类异常而不是依赖人工清单的准确性重复包名不同基础版本同一基线内版本不一致意外的private发布状态private: true的包不能发布集合中的未知包。在源码中这一逻辑位于 scripts/release/families.ts 的ReleaseFamily.members()它通过 glob 模式发现 manifest逐个校验名称必须以deepseek-ai/开头、拒绝 workspace 根包deepseek-ai/dsh-root、拒绝重复包名并把每个成员解析为{ directory, name, version, manifest }。值得说明的是源码中的ReleaseFamily抽象把发布序列划分为两个 familyfamilies.tsdsh匹配packages/!(experimental)/*/package.json与apps/*/package.json全 family 共享同一版本tag 前缀为dsh-v发布 payload 执行拒绝源码与声明映射的门禁对应本文发布 payload 约定一节vendor匹配vendor/*/package.json每个包保持独立版本线发布时保留上游的src树与声明映射因为其exports[./src/*]面向源码导航删除src会发布一个 export 指向缺失文件的不一致包。源码注释还表明存在第三条发布序列native/由其他模块管理本模块只负责dsh与vendor两条序列。这印证了提案中根项目、website、vendor、Python 与 native workspace 不属于该 NPM 基线的分工表述——vendor 拥有自己的发布序列只是不在本文讨论的基线集合内。2.2 预发布版本与 dist-tag 的派生规则为了让每次 pack 产生的 tarball 具有可追溯、可重试的身份提案定义了确定性的版本派生公式base-YYYYMMDDHHmmss-short-commitbase包的稳定基础版本来自目标 commit 的根 manifestYYYYMMDDHHmmss命令启动时精确到秒的 UTC 时间戳short-commit目标 commit 的 10 位短 SHA。dist-tag 由基础版本派生dev-base提案给出的示例基础版本0.0.1、时间2026-08-04T00:32:00Z、commit909292dd7b则生成版本0.0.1-20260804003200-909292dd7btagdev-0.0.1重试语义同一 release bundle 的重试必须沿用原版本与 manifest重新 pack 会按新的命令启动时间生成新版本。这保证了恢复 重跑 publish 同一 manifest而不是重新生成另一组版本号。2.3 pack 阶段九步流程提案为 pack 阶段规定了严格有序的执行步骤每一步都在为不可变 bundle这一目标服务解析与派生将 ref 解析成不可变 commit采集 UTC 时间戳从该 commit 的根 manifest 派生版本并显示 commit、时间戳、版本、tag、注册表和输出路径。pack与release都会在昂贵操作开始前等待 Enter自动化可用--yes跳过该确认。隔离检出与约束检查在隔离的 detached worktree 中安装 frozen lockfile并在暂存前运行源码 manifest 发布约束。调用方工作树中的未提交文件和旧构建输出不得参与发布。manifest 暂存将所有目标 manifest 暂存为派生版本移除发布时的private标记并把dependencies、devDependencies、optionalDependencies与peerDependencies中的内部 workspace 依赖全部改写为同一精确版本。完整构建完整构建目标 commit再运行 publint 和已构建包不变式built-package invariants。pack为目标集合中的每个包执行 pack但不执行任何注册表写入。tarball 检查检查 tarball 内的 package manifest、文件清单、内部依赖版本、包名和版本并拒绝缺失、重复或额外的 tarball。生成 release manifest包含 commit、版本、tag、注册表、每个包的 tarball 路径、SHA-256 与 npm integrity同时生成校验和文件。隔离消费方安装与集成测试从本地 tarball 安装一个隔离消费方运行当前实现已有的安装态产物探测并将这些探测扩展为产物平面集成测试矩阵见本文第五部分。输出发布命令仅当整个集合通过时输出一个可直接执行的 publish 命令pack 命令本身始终保持无远端写入。本地release命令组合 pack 与 publish先通过 pack 确认并确定预期时间戳和版本pack 成功后等待第二次 Enter随后发布同一 manifestrelease --yes跳过两次确认。独立的pack与publish --manifest仍是 CI 分 job 和断点恢复使用的基础操作。三、当前实现边界仓库中已提交的发布脚本提案文档专门辟出当前实现边界一节说明已提交的 pack 命令实现了哪些能力。这些能力与仓库中 scripts/release 目录的代码逐一对应已实现的能力来自提案文档并经源码印证固定 commit 暂存与内部依赖精确固化对应 families.ts 的 family 发现、版本校验以及 bump.ts 的版本统一dshfamily 要求所有成员共享一个版本源码verifyVersions在 families.ts 直接断言versions.size ! 1即失败。静态与 tarball payload 检查静态 manifest 门禁与 tarball 内容门禁共用 scripts/publication-payload.ts 的validateTarballPayloadpackMember在 pack.ts 中每次 pack 后立即调用family.validatePayload(member, tarballFiles(tarball))。不可变 manifestpack 输出目录同时写入publish-order.txt记录上传顺序publish 阶段只按该顺序读取 tarball见 tarball.ts 的PUBLISH_ORDER_FILE与readPublishOrder。隔离 npm 安装把每个发布 tarball 都作为本地顶层依赖安装进 monorepo 之外的临时目录见 verify-packed-install.ts——它创建mkdtempSync临时目录、写入只含file:依赖的package.json、执行npm install --no-audit --no-fund --package-lockfalse --omitoptional并清理NODE_OPTIONS、NODE_PATH、npm_config_user_agent等环境变量杜绝宿主环境干扰。安装后的入口探测在输出 publish 命令前用普通 Node 运行安装后的dsh --version与dsh --dump-default-config两个入口再在 POSIX PTY 中启动安装后的默认 TUI等待其main-session-就绪信号并通过/exit退出。verify-packed-install.ts 中可以看到--version探测的落地运行安装目录内node_modules/deepseek-ai/dsh/lib/bin.js --version并断言输出与 tarball 声明的版本一致。Publish 按 integrity 恢复将只读注册表验证与认证身份检查分离并以完整的远端 integrity 和 dist-tag 验证结束对应 publish.ts 的实现详见本文第六部分。明确不在当前实现内属于提案范围的能力PRPull RequestCI不会调用 pack 命令安装态入口探测属于本地发布检查不是合并门禁免凭据 CI 执行、其他每个 bin 与公开运行时入口的包自有探测、workflow artifact 传递及受保护 publish job 仍属于提案范围将在 GitHub Actions 集成部分展开。四、发布 payload 约定tarball 里到底该有什么提案对发布 payload 给出了严格的门禁约定目的是让 tarball 成为消费方唯一需要的真实世界禁止项双门禁package.json#files禁止包含src和lib/types/**/*.d.ts.maptarball 内容门禁独立确认不存在任何package/src/**与package/**/*.d.ts.map——这条独立的 tarball 检查是为了防止 manifest pattern 或 pack 行为绕过静态约束。源码中的 publication-payload.ts 给出了精确实现isForbiddenPublicationFile对路径做规范化剥离package/前缀后拒绝三类路径——src、src/前缀、以及.d.ts.map/.js.map后缀validateTarballPayload遍历 tarball 成员逐一判定。注意.js.map也在拒绝之列理由如源码注释所述——map 服务于开发期编辑器导航已发布的 map 不解析任何东西所以任何 payload 都不应携带。必须收齐项运行时 JS、声明文件.d.ts、配置、资源、worker 文件和 bundle 动态 chunk必须按实际入口闭包entry closure收齐——即从每个导出入口出发、递归追踪其运行时所依赖的一切文件。源码平面与发布 payload 的分离重要设计源码 manifest 可以保留exports[./src/*]供本仓库的源码平面解析使用该 export不代表源码会进入发布 payload也不属于已发布包的消费方约定静态门禁必须分别检查源码平面与发布 payload不能通过删除 source export 来掩盖错误的 workspace 解析也不能通过发布src来修补缺失的构建产物。tarball 内部一致性约束每个 tarball 必须不含workspace:specifier所有指向本次发布集合的内部依赖与对等依赖peer dependency都必须精确等于本次派生版本禁止^、~或其他 semver 范围跨越 commit 基线除了明确仅供源码平面使用的exports[./src/*]package manifest 中声明的每个消费方入口都必须指向 tarball 内存在的文件动态 import、运行时拼接路径和非 export 资源不能只靠 manifest 检查必须由安装后执行覆盖——这正是产物平面集成测试存在的原因。五、产物平面集成测试把 tarball 当消费方来运行集成测试是 pack 阶段第 8 步运行时机是全部 tarball 生成后、任何 publish 之前。它的目标非常明确证明files选中的 payload 是完整的且发布的依赖范围能够解析。5.1 执行环境约束测试在 monorepo 外创建一个全新临时项目通过本次 release manifest 中的本地.tgz文件安装声明依赖闭包并从安装目录执行。禁止参与解析的六类事物tsxtsconfig pathsworkspace link仓库源码路径工作树lib/已发布注册表中的同版本包测试还要断言关键模块与 bin 的真实路径位于临时消费方内——仅靠行为成功不足以保证路径证据必须证明没有回退到 monorepo。源码实现 verify-packed-install.ts 印证了这些约束consumerEnvironment删除NODE_OPTIONS与NODE_PATH防止宿主注入、把DSH_HOME与DSH_AGENTS_HOME指向消费方内目录、禁用遥测packedDependencies读取所有 pack 输出目录中的.tgz将每个包映射为file:URL 依赖——这意味着测试消费方所需的全部 tarball 都来自本地 pack 输出唯一的注册表流量是外部依赖。源码注释还特别说明了一个跨序列细节harness 包把 vendored 框架声明为 peer而 vendor 属于另一条发布序列一次 PR 可能同时 bump 两条序列因此 dsh 验证会把 vendor family 的 pack 输出也一并传入--from可多次指定但发布时只发布自己的 family。5.2 客户端选择npm 还是 pnpm安装使用本次发布选择的客户端行为注册表上传必须使用npmCLI以满足私有注册表只接受 npm 客户端的策略构建编排仍可使用 pnpmtarball 测试不得先把这些包发布到真实注册表也不得在测试后重新 pack。源码中pack 用pnpm pack --pack-destinationpack.ts消费方安装与发布用npm install/npm publishverify-packed-install.ts、publish.ts与这一约定完全一致。5.3 至少覆盖的执行面测试至少覆盖以下四类执行面静态 CLI 入口 动态模式入口deepseek-ai/dsh安装后的dsh --version与dsh --dump-default-config在普通 Node 下成功。真实 TUI 启动路径安装后的默认dsh在 PTY 中完成一次无密钥 TUI 启动到达既定 ready 信号后由测试受控退出。这条路径必须加载真实 TUI 动态 chunk因此缺少类似lib/tui-*.js的发布文件会使门禁失败。每个其他已发布 bin 的包级冒烟命令每个 bin 都定义一个不会访问真实服务或修改用户状态的包级冒烟命令不同 CLI不强制共用--help测试必须运行其真实安装入口并检查约定的退出或 ready 信号。Node 兼容的公开运行时入口从安装目录加载浏览器、worker 或必须由宿主协议驱动的入口使用对应的隔离 fixture测试前置数据但输入仍只能是本次 tarball。提案特别强调这些测试验证可执行性不替代单元测试、快照、真实 API e2e 或 publint。测试 fixture 应复用现有 built-bin 和 PTY 场景的行为断言但必须把入口改为 tarball 安装结果——直接运行工作树lib/bin.js的测试不能算作本门禁。5.4 为什么只跑--help不够这是提案考虑过的替代方案中的关键一条详见本文第七部分Commander 可以在加载 TUI、Web 或 headless 动态入口之前输出帮助并退出--help无法证明默认生产启动路径完整。因此基线测试选择--version静态入口--dump-default-config动态模式入口 PTY 中完整 TUI 启动的组合确保动态 chunk 真的被加载。六、发布与幂等恢复publish 命令的执行顺序与恢复策略同样有严格规定。6.1 发布前校验publish 命令先验证以下内容再按确定顺序上传 tarballrelease manifest所有本地校验和目标注册表npm pingnpm whoami。命令只接受 pack 阶段生成的 manifest不接受 workspace 目录作为发布输入。默认注册表为https://registry.npm.harnessment.com/该地址在仓库 scripts/publish-npm-baseline.ts 中亦有引用可交叉印证每次 publish 都显式传入注册表和派生 tag避免用户级.npmrc改变目标。6.2 幂等恢复三态决策npm 不提供多包原子事务上传仍会逐包发生。编排器通过幂等恢复缩小失败面对每个包基于远端状态做三态决策远端状态动作不存在nameversion上传已存在且 integrity 与 release manifest 相同跳过已存在但内容不同立即失败dist-tag 检查只读取 tag 映射不解析默认 tag 指向的版本——因此即使无关 tag 指向的版本已不存在也不会阻断恢复。完成后必须逐包确认版本 integrity 和 dist-tag 都指向本次版本只有整个集合通过最终验证工作流才报告发布成功。失败语义如果 pack、tarball 检查或安装后集成测试失败注册表必须保持零写入。如果 publish 在部分上传后失败操作者使用同一 release manifest重跑 publish 命令来恢复不得重新 pack并生成另一个时间戳版本来代替恢复。只有修复代码或改变构建输入后需要不同 tarball 时才重新执行完整 pack 与测试。6.3 源码中的落地实现scripts/release/publish.ts 完整实现了上述语义三态决策registryState()通过npm view nameversion dist.integrity --json查询远端返回absent或present{integrity}两种状态。主循环对每个 tarball远端缺失则发布已存在且 integrity 等于本地sha512-base64则跳过已存在但不同则抛出错误提示 Bump the version, or investigate why the build is not reproducible.临时性错误的有限重试TRANSIENT_PUBLISH_CODES定义了一组写操作未落定的注册表错误码——E409、E429、E500、E502、E503、E504、ETIMEDOUT、ECONNRESET、EAI_AGAIN每次重试前先重新查询注册表因为E409可能对应一次其实已落地的写入——如果远端已存在且 integrity 与本地一致则视为成功继续。单包最多尝试PUBLISH_ATTEMPTS 4次间隔PUBLISH_SPACING_MS 2000ms并以 2 的幂退避2000ms → 4000ms → 8000ms。预发布版本不打 latest tagversion.includes(-)时为--tag next。不传--access注释说明两条序列不共享同一 access 级别命令行 flag 无法同时服务两者由每个打包后的 manifest 自行决定并由check-workspace-constraints约束各 manifest 保持其序列的级别。上传顺序严格按 pack 输出的publish-order.txt顺序执行进度以[n/total]输出跳过已有包时不等待间隔连续发布之间才有 2 秒间距。6.4 发布顺序的确定依赖拓扑为什么上传顺序必须确定因为中断后留下的是完整基线的前缀这一性质依赖顺序。ReleaseFamily.publishOrderfamilies.ts实现了确定性排序install 边dependenciesoptionalDependencies绝对遵守npm 在安装时解析这些依赖消费方先于其依赖发布会留下无法组装的窗口install 边上的环被视为缺陷直接报错而非绕行peer 边peerDependencies能排则排npm 不会替包安装 peer未满足的 peer 只是警告而非解析失败sibling 包互相声明 peer 会形成环此时该边被放弃排序并显式报告——放弃一条排序约束是对真实发布的决定操作者必须在 pack 日志中判断新增的 dropped edge 是否符合预期最终输出还会被一次后置校验兜底任何消费方排在它所安装的依赖之前的顺序都会导致失败。该排序逻辑有完整的单元测试覆盖见 scripts/release/families.spec.ts——测试覆盖了依赖先于消费方发布且同名平局按名排序、运行时依赖环被报错而非任意排序、peer 先于消费方、peer 环被绕行并报告被放弃的边、install 边在 peer 环包围下仍被遵守、拒绝消费方先于依赖的顺序、排序时忽略 devDependencies等场景。七、GitHub Actions 集成免凭据测试 受保护发布CI 集成采用两个职责分离的 job把能验证与有凭据彻底拆开。7.1 两个 job 的分工Job凭据职责pack-and-test job无凭据检出精确 commit调用与本地相同的 pack 入口运行 tarball 消费方测试上传完整 release bundle 作为工作流产物publish job受保护依赖前者成功从工作流产物下载 bundle重新校验 manifest 和校验和再调用同一个 publish 入口不能检出后重新构建关键约束publish job 必须使用同一 workflow run 生成的 bundle不能按版本号从不受信任的位置寻找 tarball。这保证了测试输入与发布输出的内容身份一致。7.2 触发策略与凭据保护PR 与普通 push 可以运行无凭据的 pack-and-test 信号从而在合并前发现 payload 回归实际私有注册表发布先通过workflow_dispatch提供输入只包括目标 refUTC 时间戳由 pack job 生成基础版本、短 SHA、tag、注册表和包清单都由仓库状态或受版本控制的配置派生稳定发布触发方式不在该基线提案范围内注册表 token 只注入 publish job并由受保护 GitHub Environment 控制人工批准、允许的分支或 tag 以及并发pack-and-test job 不得读取发布凭据工作流产物的保留期可以较短。此外scripts/release/verify.ts 实现了发布时的门禁逻辑通过RELEASE_PUBLISHtrue环境变量进入发布模式后它会校验所有成员可发布拒绝private: true并校验GITHUB_REF必须是本 family 的发布 tag如dsh-v*且该 tag 命名的版本必须确实是本 family 携带的版本——发布只发生在 GitHub Actions 中因此这些检查是工作流门禁而非本地建议。verify.ts还会在任何构建之前解析发布顺序并打印完整顺序与 dropped peer 边让 PR 上对顺序的改动可审查test-invariants 层面在 families.spec.ts 中亦有对应断言。八、考虑过的替代方案及其否决理由提案明确记录了几条被否决的路线每一条的否决理由都指向本设计的核心动机替代方案否决理由从 workspace 直接递归 publish命令会把 pack 与注册表写入交错无法在第一次写入前证明整个集合完整也容易让 workspace 解析与调用方工作树状态影响发布结果只测试工作树中构建后的lib/验证的是构建树不是package.json#files选出的 tarball工作树中存在而 tarball 中漏掉的动态 chunk 正是本提案必须捕获的失败只运行dsh --helpCommander 可以在加载 TUI、Web 或 headless 动态入口之前输出帮助并退出无法证明默认生产启动路径完整把src和声明映射一起发布以降低漏文件风险源码平面不是生产运行时的后备路径扩大 payload 会掩盖 bundle 闭包错误并把本地调试产物变成无意的发布约定要求真正的跨包原子发布npm 注册表没有相应事务不可变 release bundle、发布前全量验证、integrity 比对与幂等恢复提供可实现的边界同时明确保留部分上传短暂可见的限制在批准后由发布 job 重新构建测试通过的 tarball 与实际上传的 tarball 将不再具有内容身份工作流产物与校验和必须把测试输入直接传给发布步骤九、验收标准提案的验收标准可以归纳为七条可验证的能力也是判断该设计是否落地到位的检查清单单入口发现与确认一个 pack 入口从确定 commit 发现packages/*/*和apps/*的全部目标包以 UTC 秒级时间戳与短 commit 生成并显示版本再等待 Enter它在任何注册表写入前生成完整 release bundle并输出一个可复制的 publish 命令release在 pack 后再次等待--yes跳过两次确认。双门禁静态 manifest 门禁和 tarball 内容门禁都拒绝发布src与.d.ts.map同时保留源码 manifest 中的exports[./src/*]。不可变 bundle 与精确固化release bundle 记录完整包集合、commit、派生版本、tag、注册表和逐 tarball integrity所有内部依赖都精确固化到该版本publish 只消费该 bundle绝不重建。隔离 TUI 启动一个隔离集成测试从本地 tarball 安装消费方并用普通 Node 启动安装后的默认dshTUI删除任一所需动态 chunk 会使该测试稳定失败。全量入口覆盖所有已发布 bin 和适用的公开运行时入口都有 tarball 安装后的执行覆盖且解析路径证明没有回退到 monorepo。安全重跑publish 可在部分成功后用同一 manifest 安全重跑相同 integrity 被跳过不同 integrity 被拒绝最终验证要求所有版本与 tag 一致。CI 凭据隔离GitHub Actions 的无凭据 job 生成并测试 bundle受保护 job 上传完全相同的 bundle发布 token 只存在于后者。十、风险与边界提案最后坦诚地列出了该设计的已知风险与尚待扩展之处性能与缓存策略全量 pack、安装和启动会增加 CI 时间与工作流产物体积。实现应缓存外部依赖和 pnpm store但不得缓存或复用目标包的已安装 workspace 输出并行执行安全的消费方 probe 可以降低时延。源码中 pack.ts 的--concurrency参数已提供有界并行池支持默认 1与有凭据发布工作流的串行执行保持一致。未声明内部依赖的掩盖风险把所有 tarball 都安装为临时项目的顶层依赖可能掩盖未声明的内部依赖顶层的node_modules扁平化会意外补全缺失声明。测试生成器应按被测应用的声明式递归闭包安装并结合现有依赖门禁对依赖面接近全集的deepseek-ai/dsh仍需依靠 package manifest 与静态图检查发现未声明边。平台差异化不同平台的 optional dependency、native addon、PTY 与浏览器入口可能需要平台专属 probe。第一阶段至少在发布所用 Linux runner 和一个本地 macOS 路径上覆盖主dsh启动后续矩阵按实际发布平台扩展不能用跳过不稳定 probe 的方式把生产路径移出门禁。部分可见性不可消除恢复机制不能消除 npm 的部分可见性。发布失败期间注册表可能短暂含有本次版本的一部分包操作者与自动化必须以最终 bundle 验证结果而非单个npm publish的成功作为基线可用信号。十一、相关源码路径索引以下文件是理解本设计落地实现的最佳入口建议结合本文对照阅读.agents/notes/proposed/process/2026-08-04-artifact-first-npm-baseline-publication.zh.md本文核心依据的提案文档另有英文版 .agents/notes/proposed/process/2026-08-04-artifact-first-npm-baseline-publication.mdscripts/release/pack.tspack 边界实现--family dsh|vendor [--out dist/npm] [--concurrency 1]scripts/release/publish.ts幂等发布与恢复--family dsh|vendor --from packed directoryscripts/release/families.tsfamily 发现、版本校验、发布顺序拓扑排序、payload 校验scripts/release/verify-packed-install.ts隔离消费方安装与入口探测scripts/release/verify.ts发布前门禁private 检查、tag 检查、顺序报告scripts/release/bump.ts版本提升与 tag 规划scripts/release/tarball.tstarball 读取与publish-order.txtscripts/publication-payload.ts发布 payload 策略拒绝src、.d.ts.map、.js.mapscripts/release/families.spec.ts发布顺序、版本基线、payload 策略的单元测试。赞分享人工智能AI AgentAgent 框架DeepSeek【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址https://gitcode.com/gh_mirrors/de/deepseek-harness点击查看免费下载相关推荐DeepSeek Harness 工件优先的 NPM 基线发布immutable release bundle 设计与实现DeepSeek Harness 工件优先的 NPM 基线发布immutable release bundle 设计与实现 本篇技术指南围绕 DeepSeek人工智能AI AgentAgent 框架DeepSeekDeepSeek Harnessdsh meta 以源码检出为 workspace 启动 TUI 的设计与实现解析DeepSeek Harness dsh meta 以源码检出为 workspace 启动 TUI 的设计与实现解析 本篇指南解析 DeepSeek Harn人工智能AI AgentAgent 框架DeepSeekDeepSeek Harness 会话日志不可变设计运行时所有权边界与 dsh-invariants 开发不变式DeepSeek Harness 会话日志不可变设计运行时所有权边界与 dsh invariants 开发不变式 会话日志是 DeepSeek Harness人工智能AI AgentAgent 框架DeepSeek创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考