DeepSeek Harness 快照测试指南记录 fork 与混合 spawnfork 子会话场景用 seedLength 守卫回放路由【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness本指南以 DeepSeek Harness 仓库中已落地的 Agent Note「记录 fork 与混合 spawnfork 快照场景」为核心讲解如何在 full-transcript 快照层中为 fork 子会话子代理新增录制式回归守卫subagent-fork与subagent-mixed两个场景如何构造、为何要求父项先完成一个轮次、seedLength边界如何被持久化并在回放切片中消费以及如何无密钥回放与重新录制。读完本文你将掌握 fork 子会话快照的录制原则、seed 边界路由的实现链路以及验证该守卫是否真正生效的红→绿验证方法。背景快照层为什么漏掉了 forkDeepSeek Harness 的快照测试体系分多层守卫模型路由与 transcript 正确性。其中full-transcript 快照层是最完整的一张网它会启动真实的acp-agent端到端重放嵌套 transcript。在此之前持久化 seed 边界 Agent Note 已经让 fork 子会话回放能够正确路由——dsh-llm-replay依据持久化的seedLength边界及其后的事件派生子会话脚本因此 fork 子会话继承的父前缀不会被当作子会话自身的模型调用重放。但该修复落地时没有配套的录制式 fork 场景slice(seedLength)这条切分逻辑只被llm-replay的单元测试合成子会话 fixture和持久化往返测试覆盖full-transcript 快照层当时只有 spawn 子会话场景subagent-spawn、subagent-multi结果是如果 fork 路由出现回归而单元测试恰好保持绿色这个 bug 会逃过专为捕获 transcript 回归而构建的快照层。这正是本文要解决的问题——把 fork 路由的守卫从单元测试层级提升到全 transcript 快照层级。快照基础设施已经就绪缺的只是录制场景表达 fork 场景所需的快照基础设施在当时已经全部就位两个进程内后端以两个面向模型的工具接入subagent→ spawnsubagent_fork→ fork两者都配置在cordis.yml/cordis.snapshot.yml中harness 会收集每个子会话的日志并将每个子会话的 fixture 按seedLength为键转发给回放缺的只是一个已记录的场景来驱动 fork 子会话走完这条路径。也就是说问题不在基础设施而在场景覆盖——这与快照测试的典型盲区一致测试床支持某种形态但录制语料中没有真实样例回归时无从察觉。决策针对真实 API 记录两个场景subagent-fork聚焦的 fork 回归守卫父会话先完成一个轮次以建立一个事实然后通过subagent_fork委派一个子任务。fork 子会话继承对话——其日志携带非零seedLength——因此可以从父会话的上下文中作答。这是聚焦的回归守卫子会话 fixture 里的seedLength正是回放切片所依赖的边界而且来自真实 fork 的记录而非手工合成。手工合成 fixture 只验证切分函数本身真实录制则同时验证 fork 后端是否正确写出 seed、持久化层是否完整往返、回放切片是否消费了正确的边界。subagent-mixed一份 transcript 覆盖两种传输方式父项完成一个轮次后在同一 transcript 中先通过subagent委托一次——全新 spawn 子会话seedLength为 0再通过subagent_fork委托一次——fork 子会话seedLength非零。这是 seed 边界与逐会话回放两份 Agent Note 都点名作为未来新增项的spawnfork 混合场景。它的价值在于一份 transcript 同时覆盖两种传输方式spawn 与 forkslice 的两个分支seedLength为 0 → 无操作no-opseedLength 0→ 裁剪继承前缀两个子会话按createdAt排序保证 spawn 在前、fork 在后对应回放加载逻辑中按createdAt升序、再以recordedId打破时间戳平局的排序。从录制的 fixture 可以印证这一点。subagent-mixed场景的父会话日志session.jsonl中同时出现了 4 次subagent与 4 次subagent_fork工具调用快照目录子会话日志session.1.jsonlspawn无seedLength与session.2.jsonlforkseedLength: 39并存而subagent-fork场景对应 snapshots/sdk/subagent-fork-in-process/的session.1.jsonl头部则记录着seedLength: 45。这些数字正是真实 API 调用中父前缀的长度是回放路由的载荷性产物。为什么必须有一个已完成的第一轮次fork 后端的种子来自父项的已配平完整轮次前缀。如果父项在第一个轮次就执行 fork没有已完成轮次可供继承seed 为空空 seed ≡ 全新 spawnseedLength为 0这不会覆盖 slice 分支——守卫形同虚设。因此两个场景都使用双提示词输入第一个提示词完成一个轮次——建立稍后要求子项回忆的 codeword例如快照 fixture 中的 SAFFRON第二个提示词委托 fork。从源码实现看fork 后端的种子计算在 subagent-fork-in-process 的completedTurnPrefix中它会找到父会话日志中最后一个turn/end事件并返回截至该事件的连续事件前缀若没有已完成的轮次则返回空数组随后在start中仅当 seed 非空时才透传...seed.length 0 ? { seed } : {}。这与文档描述完全一致空 seed 时子会话保持无种子状态。需要强调一点子会话 transcript 中回忆出的 codeword 只是模型行为的附带结果不是断言对象。真正承载关键约束的产物是子会话 fixture 中记录、由重放 slice 消费的seedLength。源码级拆解seedLength 的完整链路1. fork 后端在创建子会话时写入 seed 长度ForkInProcessProvider声明inheritsParentContext true源码创建子会话时传入继承前缀并在会话创建选项的meta中携带seedLength 播种前缀的长度。全新 spawn 子会话不设置等同于 0。2. 两个持久化后端完整往返seedLength是显式字段绝不从seed.length推断恢复路径中完整日志长度 ≠ 原始边界JSONL 后端toHeaderLine/fromHeaderLine在 header 行上读写可选字段seedLength缺失时省略SQLite 后端sessions表的seed_length列number | null读取时null映射回缺省属于 schema version 4 布局的一部分。3. 回放从边界之后派生子会话脚本dsh-llm-replay是这条链路的消费端核心逻辑在 llm-replay 的loadSessionScriptsparseSessionHeader读取 header 中的seedLength缺失默认 0对每个子会话 fixtureparseSessionLog(text).slice(header.seedLength)——即边界及之后的事件也就是子会话自身的模型调用注释明确说明「Child derivation begins atseedLengthso inherited parent chunks are never replayed as child calls」对 spawn 子会话seedLength为 0slice(0)是空操作spawn 场景逐字节不变——这保证了旧快照的向后兼容。理解这条链路后就能明白为什么说 fork 场景的回归会「静默错误路由」如果去掉slice(seedLength)直接回放整个子会话日志fork 子会话收到的将是父会话记录的分片而非自己的回放出的模型调用顺序完全错位但测试本身不会崩溃——这正是快照层要捕获的那类 bug。后果守卫升级与验证fork 路由切片由全 transcript 层守卫移除slice(seedLength)回放整个子会话日志会让两个新场景都变红——fork 子会话收到的是父会话记录的分片而非自己的。这个负向实验在场景落地时已验证红→绿先确认去掉切分后测试失败红再恢复切分确认测试通过绿证明守卫确实咬合。subagent-mixed的独特地位它是第一个在同一个 transcript 中驱动两种不同subagent 后端的快照场景同时覆盖了跨 spawn 和 fork 子会话的逐会话回放键控。后续若新增第三种进程内后端这个场景是扩展同类覆盖的模板。边界与限制进程外ACPsubagent 回放形态不同每个子会话是独立进程、有自己的回放仍以TODO(acp-subagent-replay)跟踪——本文场景仅限进程内重新录制会从真实 API 重新生成全部四个 fork/spawn fixturepnpm run test:snapshot:record会覆盖录制对应的 package.json 脚本为DSH_SNAPSHOTrecord vitest run --config vitest.snapshot.config.ts --update无密钥自动跳过两个新场景在无 API 密钥时自动跳过与所有已录制场景行为一致。实操如何运行与验证快照相关的命令集中在仓库根 package.json命令作用pnpm test:snapshot运行快照回放vitest run --config vitest.snapshot.config.tspnpm test:snapshot:record从真实 API 重新录制全部场景DSH_SNAPSHOTrecord ... --updatepnpm test:snapshot:refresh刷新录制DSH_SNAPSHOTrefresh ...pnpm check:ci:snapshot在 CI 门禁中执行快照检查tsx scripts/run-gates.ts ci-snapshot验证守卫咬合的负向实验步骤在 llm-replay 源码 中临时移除.slice(header.seedLength)回放整个子会话日志运行快照测试subagent-fork与subagent-mixed应同时变红——fork 子会话收到父会话的分片恢复切分两个场景回到绿色。该实验已由场景落地时的红→绿验证确认可作为 fork 路由回归的回归基准。小结subagent-fork与subagent-mixed填补了 full-transcript 快照层在 fork 路由上的覆盖缺口前者是聚焦的 fork 回归守卫后者首次在一份 transcript 中驱动 spawn 与 fork 两种后端。二者共同将slice(seedLength)的正确性从单元测试与持久化往返测试提升到「启动真实acp-agent并端到端重放嵌套 transcript」的最高守卫层级。理解「已配平完整轮次前缀 → 显式持久化seedLength→ 回放按边界切片」这条链路是扩展 DeepSeek Harness 快照场景、避免 fork 路由静默回归的基础。【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
DeepSeek Harness 快照测试指南：记录 fork 与混合 spawn+fork 子会话场景，用 seedLength 守卫回放路由
DeepSeek Harness 快照测试指南记录 fork 与混合 spawnfork 子会话场景用 seedLength 守卫回放路由【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness本指南以 DeepSeek Harness 仓库中已落地的 Agent Note「记录 fork 与混合 spawnfork 快照场景」为核心讲解如何在 full-transcript 快照层中为 fork 子会话子代理新增录制式回归守卫subagent-fork与subagent-mixed两个场景如何构造、为何要求父项先完成一个轮次、seedLength边界如何被持久化并在回放切片中消费以及如何无密钥回放与重新录制。读完本文你将掌握 fork 子会话快照的录制原则、seed 边界路由的实现链路以及验证该守卫是否真正生效的红→绿验证方法。背景快照层为什么漏掉了 forkDeepSeek Harness 的快照测试体系分多层守卫模型路由与 transcript 正确性。其中full-transcript 快照层是最完整的一张网它会启动真实的acp-agent端到端重放嵌套 transcript。在此之前持久化 seed 边界 Agent Note 已经让 fork 子会话回放能够正确路由——dsh-llm-replay依据持久化的seedLength边界及其后的事件派生子会话脚本因此 fork 子会话继承的父前缀不会被当作子会话自身的模型调用重放。但该修复落地时没有配套的录制式 fork 场景slice(seedLength)这条切分逻辑只被llm-replay的单元测试合成子会话 fixture和持久化往返测试覆盖full-transcript 快照层当时只有 spawn 子会话场景subagent-spawn、subagent-multi结果是如果 fork 路由出现回归而单元测试恰好保持绿色这个 bug 会逃过专为捕获 transcript 回归而构建的快照层。这正是本文要解决的问题——把 fork 路由的守卫从单元测试层级提升到全 transcript 快照层级。快照基础设施已经就绪缺的只是录制场景表达 fork 场景所需的快照基础设施在当时已经全部就位两个进程内后端以两个面向模型的工具接入subagent→ spawnsubagent_fork→ fork两者都配置在cordis.yml/cordis.snapshot.yml中harness 会收集每个子会话的日志并将每个子会话的 fixture 按seedLength为键转发给回放缺的只是一个已记录的场景来驱动 fork 子会话走完这条路径。也就是说问题不在基础设施而在场景覆盖——这与快照测试的典型盲区一致测试床支持某种形态但录制语料中没有真实样例回归时无从察觉。决策针对真实 API 记录两个场景subagent-fork聚焦的 fork 回归守卫父会话先完成一个轮次以建立一个事实然后通过subagent_fork委派一个子任务。fork 子会话继承对话——其日志携带非零seedLength——因此可以从父会话的上下文中作答。这是聚焦的回归守卫子会话 fixture 里的seedLength正是回放切片所依赖的边界而且来自真实 fork 的记录而非手工合成。手工合成 fixture 只验证切分函数本身真实录制则同时验证 fork 后端是否正确写出 seed、持久化层是否完整往返、回放切片是否消费了正确的边界。subagent-mixed一份 transcript 覆盖两种传输方式父项完成一个轮次后在同一 transcript 中先通过subagent委托一次——全新 spawn 子会话seedLength为 0再通过subagent_fork委托一次——fork 子会话seedLength非零。这是 seed 边界与逐会话回放两份 Agent Note 都点名作为未来新增项的spawnfork 混合场景。它的价值在于一份 transcript 同时覆盖两种传输方式spawn 与 forkslice 的两个分支seedLength为 0 → 无操作no-opseedLength 0→ 裁剪继承前缀两个子会话按createdAt排序保证 spawn 在前、fork 在后对应回放加载逻辑中按createdAt升序、再以recordedId打破时间戳平局的排序。从录制的 fixture 可以印证这一点。subagent-mixed场景的父会话日志session.jsonl中同时出现了 4 次subagent与 4 次subagent_fork工具调用快照目录子会话日志session.1.jsonlspawn无seedLength与session.2.jsonlforkseedLength: 39并存而subagent-fork场景对应 snapshots/sdk/subagent-fork-in-process/的session.1.jsonl头部则记录着seedLength: 45。这些数字正是真实 API 调用中父前缀的长度是回放路由的载荷性产物。为什么必须有一个已完成的第一轮次fork 后端的种子来自父项的已配平完整轮次前缀。如果父项在第一个轮次就执行 fork没有已完成轮次可供继承seed 为空空 seed ≡ 全新 spawnseedLength为 0这不会覆盖 slice 分支——守卫形同虚设。因此两个场景都使用双提示词输入第一个提示词完成一个轮次——建立稍后要求子项回忆的 codeword例如快照 fixture 中的 SAFFRON第二个提示词委托 fork。从源码实现看fork 后端的种子计算在 subagent-fork-in-process 的completedTurnPrefix中它会找到父会话日志中最后一个turn/end事件并返回截至该事件的连续事件前缀若没有已完成的轮次则返回空数组随后在start中仅当 seed 非空时才透传...seed.length 0 ? { seed } : {}。这与文档描述完全一致空 seed 时子会话保持无种子状态。需要强调一点子会话 transcript 中回忆出的 codeword 只是模型行为的附带结果不是断言对象。真正承载关键约束的产物是子会话 fixture 中记录、由重放 slice 消费的seedLength。源码级拆解seedLength 的完整链路1. fork 后端在创建子会话时写入 seed 长度ForkInProcessProvider声明inheritsParentContext true源码创建子会话时传入继承前缀并在会话创建选项的meta中携带seedLength 播种前缀的长度。全新 spawn 子会话不设置等同于 0。2. 两个持久化后端完整往返seedLength是显式字段绝不从seed.length推断恢复路径中完整日志长度 ≠ 原始边界JSONL 后端toHeaderLine/fromHeaderLine在 header 行上读写可选字段seedLength缺失时省略SQLite 后端sessions表的seed_length列number | null读取时null映射回缺省属于 schema version 4 布局的一部分。3. 回放从边界之后派生子会话脚本dsh-llm-replay是这条链路的消费端核心逻辑在 llm-replay 的loadSessionScriptsparseSessionHeader读取 header 中的seedLength缺失默认 0对每个子会话 fixtureparseSessionLog(text).slice(header.seedLength)——即边界及之后的事件也就是子会话自身的模型调用注释明确说明「Child derivation begins atseedLengthso inherited parent chunks are never replayed as child calls」对 spawn 子会话seedLength为 0slice(0)是空操作spawn 场景逐字节不变——这保证了旧快照的向后兼容。理解这条链路后就能明白为什么说 fork 场景的回归会「静默错误路由」如果去掉slice(seedLength)直接回放整个子会话日志fork 子会话收到的将是父会话记录的分片而非自己的回放出的模型调用顺序完全错位但测试本身不会崩溃——这正是快照层要捕获的那类 bug。后果守卫升级与验证fork 路由切片由全 transcript 层守卫移除slice(seedLength)回放整个子会话日志会让两个新场景都变红——fork 子会话收到的是父会话记录的分片而非自己的。这个负向实验在场景落地时已验证红→绿先确认去掉切分后测试失败红再恢复切分确认测试通过绿证明守卫确实咬合。subagent-mixed的独特地位它是第一个在同一个 transcript 中驱动两种不同subagent 后端的快照场景同时覆盖了跨 spawn 和 fork 子会话的逐会话回放键控。后续若新增第三种进程内后端这个场景是扩展同类覆盖的模板。边界与限制进程外ACPsubagent 回放形态不同每个子会话是独立进程、有自己的回放仍以TODO(acp-subagent-replay)跟踪——本文场景仅限进程内重新录制会从真实 API 重新生成全部四个 fork/spawn fixturepnpm run test:snapshot:record会覆盖录制对应的 package.json 脚本为DSH_SNAPSHOTrecord vitest run --config vitest.snapshot.config.ts --update无密钥自动跳过两个新场景在无 API 密钥时自动跳过与所有已录制场景行为一致。实操如何运行与验证快照相关的命令集中在仓库根 package.json命令作用pnpm test:snapshot运行快照回放vitest run --config vitest.snapshot.config.tspnpm test:snapshot:record从真实 API 重新录制全部场景DSH_SNAPSHOTrecord ... --updatepnpm test:snapshot:refresh刷新录制DSH_SNAPSHOTrefresh ...pnpm check:ci:snapshot在 CI 门禁中执行快照检查tsx scripts/run-gates.ts ci-snapshot验证守卫咬合的负向实验步骤在 llm-replay 源码 中临时移除.slice(header.seedLength)回放整个子会话日志运行快照测试subagent-fork与subagent-mixed应同时变红——fork 子会话收到父会话的分片恢复切分两个场景回到绿色。该实验已由场景落地时的红→绿验证确认可作为 fork 路由回归的回归基准。小结subagent-fork与subagent-mixed填补了 full-transcript 快照层在 fork 路由上的覆盖缺口前者是聚焦的 fork 回归守卫后者首次在一份 transcript 中驱动 spawn 与 fork 两种后端。二者共同将slice(seedLength)的正确性从单元测试与持久化往返测试提升到「启动真实acp-agent并端到端重放嵌套 transcript」的最高守卫层级。理解「已配平完整轮次前缀 → 显式持久化seedLength→ 回放按边界切片」这条链路是扩展 DeepSeek Harness 快照场景、避免 fork 路由静默回归的基础。【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 发布解读：crypto 内存泄漏修复、zlib 1.2.11 升级与 V8 展开语法回归修复)
