DeepSeek Harness 文件系统缺失观测将文件不存在纳入事件门控的观察状态机杜绝被外部删除后的死循环恢复【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness导读在 DeepSeek Harness 中模型对文件的读写被一套基于事件门控event-gate的观测策略约束必须先读后改、必须基于所读版本进行受保护的写入与编辑。但当会话读到过某个文件、随后该文件被外部命令删除时旧的正向版本会永久滞留导致重新读取后重试这一恢复指令陷入不可恢复的循环。本篇文章以仓库内已实现的设计笔记 filesystem-absence-observation 为核心深入讲解dsh-fs-observation-policy如何把文件不存在提升为与文件存在并列的一等观察状态、fs/observed事件如何携带 present/absent 判别联合discriminated union以及本地与 E2B 两种 Provider 如何在发布点而非初始探测点强制createIfAbsent做到受保护的创建绝不覆盖在发布前出现的并发目标。读完你将掌握该机制的完整状态机、错误码语义、发布原子性策略及其源码实现位置。背景事件门控下的观测策略与版本守卫要理解本次缺陷修复需要先还原它所处的架构。在 file-context-as-event-gate 决策中DeepSeek Harness 将文件系统能力拆成了四层dsh-tool-fs执行器直接调用ctx.fs、dsh-fs-observation-policy事件门控插件、dsh-fsProvider 契约拥有事件词汇表以及具体的 Providerdsh-fs-local、dsh-fs-e2b。其中关键设计是dsh-fs-observation-policy自身不做任何文件 I/O它只通过三个事件参与决策fs/write-intent单槽瀑布产出写意图、fs/edit-intent单槽瀑布产出编辑版本守卫、fs/observedfire-and-forget 记录事件。策略层的核心数据结构是一个WeakMapowner, MaptargetKey, FsObservationowner 由事件携带的不透明objectactor 结构推导{ agent?: { session? } }见 policy/types.ts。版本是否仍然新鲜这一判断必须发生在 Provider 的原子变更临界区内由 Provider 通过 CAS 完成而不是策略层先stat再比较——后者会留下 TOCTOU 间隙。正是在这套只记录成功读与成功变更的目标版本的旧实现上出现了本笔记要修复的缺陷。Problem被外部删除后正向版本永久滞留形成死循环原事件门控策略只记录成功的读取与变更所产生的一个目标版本。缺陷链条如下会话读取了文件foo.ts策略记录了present(version)外部命令如用户手动删除、其他进程清理删除了该文件会话第一次受保护的变更按replaceIfVersion提交Provider 正确判定版本过期返回FS_STALE_VERSION按 guarded-mutation remedy 的约定模型看到re-read the file, then retry的恢复指令于是重新读取问题出现了重读时目标已缺失read返回FS_NOT_FOUND但旧实现不会在元数据缺失时发出fs/observed事件旧的present(version)记录永远保留于是后续写入继续选择replaceIfVersionProvider 继续拒绝已不存在的目标模型被要求重新读取然后重试却永远无法恢复——不可恢复的循环。笔记明确指出若把读取失败当作允许创建还会暴露第二条边界本地与 E2B Provider 在暂存前先探测目标然后历史上以 rename 发布在这两步之间另一个进程可能创建了目标并被覆盖——即便调用方提供的是createIfAbsent。进程内的目标锁无法保护这种跨进程的发布竞态。Decision缺失也是一等观察——present/absent 判别联合核心决策是文件不存在是一种观察结果absence is an observation受保护的创建在发布点绝不覆盖并发目标。它落成两个互相配合的改动。dsh-fs 拥有显式观察联合dsh-fs包Provider 契约事件词汇表所有者定义了观察载荷// 来源packages/fs/fs/src/types.ts export type FsObservation | { readonly kind: present; readonly version: FsVersion } | { readonly kind: absent }fs/observed事件携带该联合成功的读取与变更发出presentread的元数据缺失、或str_replace_editor的view/str_replace/insert命令的元数据缺失会在返回FS_NOT_FOUND之前同步发出absent其他读取失败不制造缺失观察例如权限错误、I/O 错误不会把状态改写为 absent。策略层三状态机unseen / absent / presentdsh-fs-observation-policy每个 owner target 存储三种逻辑状态且不注入也不调用ctx.fs见 policy/index.ts 的ObservedStateGate其注释明确 no inject —— this plugin reads no services; it operates only on its own WeakMap状态判定方式写意图write编辑守卫editunseen未观察map 中无条目createIfAbsentFS_NOT_OBSERVED必须先读absent确认缺失条目判别为absentcreateIfAbsentFS_NOT_FOUND无法编辑不存在的文件present(version)确认存在条目判别为presentreplaceIfVersion{ version: observedVersion }一次成功的创建或变更会把absent替换为其产生的present(version)从而允许后续 edit-then-edit / create-then-edit 而不必再次读取。对应源码中正是三个决策方法的实现packages/fs/fs-observation-policy/src/index.tswriteIntent(target, actor): FsWriteIntent { const owner this.owner(actor) const prior owner ? this.get(owner, target.targetKey) : undefined return prior?.kind present ? { kind: replaceIfVersion, version: prior.version } : { kind: createIfAbsent } } editIntent(target, actor): { version: FsVersion } { const owner this.owner(actor) const prior owner ? this.get(owner, target.targetKey) : undefined if (!owner || prior undefined) { throw new FsError(edit requires reading ${target.displayPath} first, FS_NOT_OBSERVED) } if (prior.kind absent) { throw new FsError(cannot edit ${target.displayPath}: not found, FS_NOT_FOUND) } return { version: prior.version } }注意writeIntent把 unseen 与 absent 统一映射到createIfAbsent而editIntent把二者区分成两个错误码——这正是删除缓存版本方案被否掉的原因之一unseen 与 confirmed absence 语义不同编辑必须能给出正确的FS_NOT_FOUND。发布点强制 createIfAbsent本地与 E2B 的无覆盖发布每个 Provider 都必须在发布点publication point而非仅初始探测点强制执行createIfAbsent。这是对 TOCTOU 的最终防线dsh-fs-local先在私有兄弟目录中暂存并fsync文件然后用硬链接hard link将暂存文件发布到目标位置链接失败后检查目标条目常规文件冲突 →FS_NOT_OBSERVED并保留对方内容不覆盖非常规条目目录/特殊文件/悬空符号链接→FS_NOT_REGULAR_FILE目标仍缺失时的失败 →FS_IO_ERROR。dsh-fs-e2b使用远程ln -T带显式的 created/existing 结果并在不可取消的提交之前通过元数据推导已提交的目标版本。替换replace和裸的无条件写入保留原有发布路径本决策不声称replaceIfVersion具备跨进程线性一致性——其版本检查与替换只受 Provider 自身锁和可检测元数据保护。这一较窄的保证对缺失恢复而言足够精确受保护的创建绝不会覆盖在发布前出现的目标。本地受保护创建依赖硬链接支持一旦某次本地发布成功暂存清理是尽力而为的因为私有残留不可能让已提交的写入变假。被否决的方案为什么不能读到不存在就删缓存设计笔记记录了四条被否决的替代方案理解它们有助于把握边界读到 not-found 就删除缓存的版本——否决。它把 unseen 与 confirmed absence 混为一谈无法让 edit 返回正确的FS_NOT_FOUND并且抹掉了fs/observed事件本应传达的状态迁移。让策略层在选择意图前自己stat——否决。这使纯事件策略依赖 Provider给每次决策增加 I/O而且在发布前仍留有 TOCTOU 间隙这正是 event-gate 架构 反复强调策略层零 stat的原因。让replaceIfVersion在目标消失时改为创建——否决。正向观察是替换的证据而非创建的证据静默改变 Provider 意图会绕过必需的缺失重读削弱陈旧保护。让删除目标死锁失败关闭fail-closed——否决。模型可见的恢复指令会因此失效会话内无法从一次正常的外部清理中恢复。恢复链与错误码语义修复后的端到端行为结合 guarded-mutation remedy修复后一次外部删除事故的完整恢复链为外部删除发生后第一次受保护变更仍失败返回FS_STALE_VERSION模型收到追加了 — re-read the file, then retry 的提示由dsh-tool-fs的remediateFsError在模型边界追加见 tool-fs/src/error.tsProvider 消息保持机器导向不变模型执行缺失重读返回FS_NOT_FOUND同时策略状态从present迁移为absent之后edit 依旧被禁止FS_NOT_FOUND不再叠加陈旧提示而write 可以重建路径按createIfAbsent原子创建若创建竞态输给了其他写者重试返回FS_NOT_OBSERVED保留胜者内容不被覆盖若遇到竞态的目录、特殊条目或悬空符号链接则返回FS_NOT_REGULAR_FILE不要求再读一次。观察载荷是包拥有的事件契约变更因此生产者、监听者、不变量、生成的 Cordis 目录、子系统文档、以及两族文件系统工具dsh-tool-fs与str_replace_editor必须一起迁移策略仍保持读一次 stat、写/编辑零 stat的预算、owner 隔离、销毁行为与可选的部署边界。验证测试如何钉死无覆盖发布笔记的验证路径有两条组装的文件系统快照钉死了模型可见的恢复链stale mutation → missing reread → guarded recreationProvider 测试在暂存之后注入一个创建者以证明无覆盖发布no-clobber publication即使目标在暂存与发布之间被并发创建受保护的创建也绝不覆盖它。这与 event-gate 的验证互为补充事件门控测试钉住了策略层不做 stat、由 Provider CAS 判定陈旧而本次测试钉住发布点原子性。小结dsh-fs-observation-policy的核心不变量可以浓缩为一句话写入/编辑的意图createIfAbsent 或 replaceIfVersion由观察状态决定而观察状态由权威的 present/absent 事件驱动版本是否新鲜、目标是否仍缺失则由 Provider 原子变更临界区内的 CAS 判定。本次修复补上了状态机缺失的一环——把文件不存在变成与文件存在等价的观察并把createIfAbsent的强制执行点从探测推进到发布点。自此外部删除不再是模型不可恢复的死胡同而是一次有明确状态迁移、有清晰错误码、有原子保护的常规恢复路径。延伸阅读文件系统缺失观察设计笔记本文主题事件门控架构决策被本次修复精化的上游设计受保护变更的模型边界恢复措辞决策策略插件实现ObservedStateGate 与三个 fs/* 监听器策略观察者类型owner 结构推导Provider 契约词汇FsObservation / FsWriteIntent / FsErrorCode模型边界恢复措辞remediateFsError【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DeepSeek Harness 文件系统缺失观测：将“文件不存在“纳入事件门控的观察状态机，杜绝被外部删除后的死循环恢复
DeepSeek Harness 文件系统缺失观测将文件不存在纳入事件门控的观察状态机杜绝被外部删除后的死循环恢复【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness导读在 DeepSeek Harness 中模型对文件的读写被一套基于事件门控event-gate的观测策略约束必须先读后改、必须基于所读版本进行受保护的写入与编辑。但当会话读到过某个文件、随后该文件被外部命令删除时旧的正向版本会永久滞留导致重新读取后重试这一恢复指令陷入不可恢复的循环。本篇文章以仓库内已实现的设计笔记 filesystem-absence-observation 为核心深入讲解dsh-fs-observation-policy如何把文件不存在提升为与文件存在并列的一等观察状态、fs/observed事件如何携带 present/absent 判别联合discriminated union以及本地与 E2B 两种 Provider 如何在发布点而非初始探测点强制createIfAbsent做到受保护的创建绝不覆盖在发布前出现的并发目标。读完你将掌握该机制的完整状态机、错误码语义、发布原子性策略及其源码实现位置。背景事件门控下的观测策略与版本守卫要理解本次缺陷修复需要先还原它所处的架构。在 file-context-as-event-gate 决策中DeepSeek Harness 将文件系统能力拆成了四层dsh-tool-fs执行器直接调用ctx.fs、dsh-fs-observation-policy事件门控插件、dsh-fsProvider 契约拥有事件词汇表以及具体的 Providerdsh-fs-local、dsh-fs-e2b。其中关键设计是dsh-fs-observation-policy自身不做任何文件 I/O它只通过三个事件参与决策fs/write-intent单槽瀑布产出写意图、fs/edit-intent单槽瀑布产出编辑版本守卫、fs/observedfire-and-forget 记录事件。策略层的核心数据结构是一个WeakMapowner, MaptargetKey, FsObservationowner 由事件携带的不透明objectactor 结构推导{ agent?: { session? } }见 policy/types.ts。版本是否仍然新鲜这一判断必须发生在 Provider 的原子变更临界区内由 Provider 通过 CAS 完成而不是策略层先stat再比较——后者会留下 TOCTOU 间隙。正是在这套只记录成功读与成功变更的目标版本的旧实现上出现了本笔记要修复的缺陷。Problem被外部删除后正向版本永久滞留形成死循环原事件门控策略只记录成功的读取与变更所产生的一个目标版本。缺陷链条如下会话读取了文件foo.ts策略记录了present(version)外部命令如用户手动删除、其他进程清理删除了该文件会话第一次受保护的变更按replaceIfVersion提交Provider 正确判定版本过期返回FS_STALE_VERSION按 guarded-mutation remedy 的约定模型看到re-read the file, then retry的恢复指令于是重新读取问题出现了重读时目标已缺失read返回FS_NOT_FOUND但旧实现不会在元数据缺失时发出fs/observed事件旧的present(version)记录永远保留于是后续写入继续选择replaceIfVersionProvider 继续拒绝已不存在的目标模型被要求重新读取然后重试却永远无法恢复——不可恢复的循环。笔记明确指出若把读取失败当作允许创建还会暴露第二条边界本地与 E2B Provider 在暂存前先探测目标然后历史上以 rename 发布在这两步之间另一个进程可能创建了目标并被覆盖——即便调用方提供的是createIfAbsent。进程内的目标锁无法保护这种跨进程的发布竞态。Decision缺失也是一等观察——present/absent 判别联合核心决策是文件不存在是一种观察结果absence is an observation受保护的创建在发布点绝不覆盖并发目标。它落成两个互相配合的改动。dsh-fs 拥有显式观察联合dsh-fs包Provider 契约事件词汇表所有者定义了观察载荷// 来源packages/fs/fs/src/types.ts export type FsObservation | { readonly kind: present; readonly version: FsVersion } | { readonly kind: absent }fs/observed事件携带该联合成功的读取与变更发出presentread的元数据缺失、或str_replace_editor的view/str_replace/insert命令的元数据缺失会在返回FS_NOT_FOUND之前同步发出absent其他读取失败不制造缺失观察例如权限错误、I/O 错误不会把状态改写为 absent。策略层三状态机unseen / absent / presentdsh-fs-observation-policy每个 owner target 存储三种逻辑状态且不注入也不调用ctx.fs见 policy/index.ts 的ObservedStateGate其注释明确 no inject —— this plugin reads no services; it operates only on its own WeakMap状态判定方式写意图write编辑守卫editunseen未观察map 中无条目createIfAbsentFS_NOT_OBSERVED必须先读absent确认缺失条目判别为absentcreateIfAbsentFS_NOT_FOUND无法编辑不存在的文件present(version)确认存在条目判别为presentreplaceIfVersion{ version: observedVersion }一次成功的创建或变更会把absent替换为其产生的present(version)从而允许后续 edit-then-edit / create-then-edit 而不必再次读取。对应源码中正是三个决策方法的实现packages/fs/fs-observation-policy/src/index.tswriteIntent(target, actor): FsWriteIntent { const owner this.owner(actor) const prior owner ? this.get(owner, target.targetKey) : undefined return prior?.kind present ? { kind: replaceIfVersion, version: prior.version } : { kind: createIfAbsent } } editIntent(target, actor): { version: FsVersion } { const owner this.owner(actor) const prior owner ? this.get(owner, target.targetKey) : undefined if (!owner || prior undefined) { throw new FsError(edit requires reading ${target.displayPath} first, FS_NOT_OBSERVED) } if (prior.kind absent) { throw new FsError(cannot edit ${target.displayPath}: not found, FS_NOT_FOUND) } return { version: prior.version } }注意writeIntent把 unseen 与 absent 统一映射到createIfAbsent而editIntent把二者区分成两个错误码——这正是删除缓存版本方案被否掉的原因之一unseen 与 confirmed absence 语义不同编辑必须能给出正确的FS_NOT_FOUND。发布点强制 createIfAbsent本地与 E2B 的无覆盖发布每个 Provider 都必须在发布点publication point而非仅初始探测点强制执行createIfAbsent。这是对 TOCTOU 的最终防线dsh-fs-local先在私有兄弟目录中暂存并fsync文件然后用硬链接hard link将暂存文件发布到目标位置链接失败后检查目标条目常规文件冲突 →FS_NOT_OBSERVED并保留对方内容不覆盖非常规条目目录/特殊文件/悬空符号链接→FS_NOT_REGULAR_FILE目标仍缺失时的失败 →FS_IO_ERROR。dsh-fs-e2b使用远程ln -T带显式的 created/existing 结果并在不可取消的提交之前通过元数据推导已提交的目标版本。替换replace和裸的无条件写入保留原有发布路径本决策不声称replaceIfVersion具备跨进程线性一致性——其版本检查与替换只受 Provider 自身锁和可检测元数据保护。这一较窄的保证对缺失恢复而言足够精确受保护的创建绝不会覆盖在发布前出现的目标。本地受保护创建依赖硬链接支持一旦某次本地发布成功暂存清理是尽力而为的因为私有残留不可能让已提交的写入变假。被否决的方案为什么不能读到不存在就删缓存设计笔记记录了四条被否决的替代方案理解它们有助于把握边界读到 not-found 就删除缓存的版本——否决。它把 unseen 与 confirmed absence 混为一谈无法让 edit 返回正确的FS_NOT_FOUND并且抹掉了fs/observed事件本应传达的状态迁移。让策略层在选择意图前自己stat——否决。这使纯事件策略依赖 Provider给每次决策增加 I/O而且在发布前仍留有 TOCTOU 间隙这正是 event-gate 架构 反复强调策略层零 stat的原因。让replaceIfVersion在目标消失时改为创建——否决。正向观察是替换的证据而非创建的证据静默改变 Provider 意图会绕过必需的缺失重读削弱陈旧保护。让删除目标死锁失败关闭fail-closed——否决。模型可见的恢复指令会因此失效会话内无法从一次正常的外部清理中恢复。恢复链与错误码语义修复后的端到端行为结合 guarded-mutation remedy修复后一次外部删除事故的完整恢复链为外部删除发生后第一次受保护变更仍失败返回FS_STALE_VERSION模型收到追加了 — re-read the file, then retry 的提示由dsh-tool-fs的remediateFsError在模型边界追加见 tool-fs/src/error.tsProvider 消息保持机器导向不变模型执行缺失重读返回FS_NOT_FOUND同时策略状态从present迁移为absent之后edit 依旧被禁止FS_NOT_FOUND不再叠加陈旧提示而write 可以重建路径按createIfAbsent原子创建若创建竞态输给了其他写者重试返回FS_NOT_OBSERVED保留胜者内容不被覆盖若遇到竞态的目录、特殊条目或悬空符号链接则返回FS_NOT_REGULAR_FILE不要求再读一次。观察载荷是包拥有的事件契约变更因此生产者、监听者、不变量、生成的 Cordis 目录、子系统文档、以及两族文件系统工具dsh-tool-fs与str_replace_editor必须一起迁移策略仍保持读一次 stat、写/编辑零 stat的预算、owner 隔离、销毁行为与可选的部署边界。验证测试如何钉死无覆盖发布笔记的验证路径有两条组装的文件系统快照钉死了模型可见的恢复链stale mutation → missing reread → guarded recreationProvider 测试在暂存之后注入一个创建者以证明无覆盖发布no-clobber publication即使目标在暂存与发布之间被并发创建受保护的创建也绝不覆盖它。这与 event-gate 的验证互为补充事件门控测试钉住了策略层不做 stat、由 Provider CAS 判定陈旧而本次测试钉住发布点原子性。小结dsh-fs-observation-policy的核心不变量可以浓缩为一句话写入/编辑的意图createIfAbsent 或 replaceIfVersion由观察状态决定而观察状态由权威的 present/absent 事件驱动版本是否新鲜、目标是否仍缺失则由 Provider 原子变更临界区内的 CAS 判定。本次修复补上了状态机缺失的一环——把文件不存在变成与文件存在等价的观察并把createIfAbsent的强制执行点从探测推进到发布点。自此外部删除不再是模型不可恢复的死胡同而是一次有明确状态迁移、有清晰错误码、有原子保护的常规恢复路径。延伸阅读文件系统缺失观察设计笔记本文主题事件门控架构决策被本次修复精化的上游设计受保护变更的模型边界恢复措辞决策策略插件实现ObservedStateGate 与三个 fs/* 监听器策略观察者类型owner 结构推导Provider 契约词汇FsObservation / FsWriteIntent / FsErrorCode模型边界恢复措辞remediateFsError【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考