拓冰网站定制 
人工智能AI AgentAgent 框架DeepSeek【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址https://gitcode.com/gh_mirrors/de/deepseek-harness点击查看免费下载本文基于 DeepSeek Harness 仓库内已实施的架构变更笔记2026-08-04-drop-windows-powershell-picker-fallback.md撰写围绕「原生目录选择器native directory pickerwin32 分支移除 PowerShell 两级回退」这一决策结合当前源码实现与测试用例还原问题背景、决策依据、替代方案与落地后果。读完本文你将理解该项目的仅对外部提供的工具回退、自带依赖失败即明确报错原则如何落地以及如何在类似场景中应用同一判据。背景原生目录选择器的平台分层结构DeepSeek Harness 通过dsh-host-directory-picker-native包为坐在宿主显示器前的操作者打开操作系统原生目录选择器。从 native-picker.ts 的源码结构看pickNativeDirectory是一个按平台分发的单一入口macOS调用osascriptchoose folderPOSIX path无任何回退层Windowswin32调用 koffi 支撑的IFileOpenDialog子进程Linux优先zenity仅在zenity缺失ENOENT时回退到kdialog两者都缺失时报出可操作错误install zenity or kdialog。在这条分发路径之上还存在一个组合层composition leveldsh-host-directory-picker-auto包在启动时通过 resolve.ts 的resolveDirectoryPickerBackend采样一次宿主事实绑定地址、是否 SSH 启动、是否有显示会话、Linux 上是否存在 zenity/kdialog 可执行文件决定挂载native还是browse后端并在 index.ts 中通过 Loader 把对应后端与客户端界面成对挂入内存根树。本文主角——被删除的 PowerShell 回退链——正是位于这条native后端的win32 分支内部在 koffiIFileOpenDialog子进程之下曾经还有一条两级 PowerShell 回退先尝试pwsh.exe再尝试powershell.exeWindows PowerShell 5.1两者运行同一个主动启用SetProcessDPIAware的 WinForms 脚本。被删除的链条pwsh → Windows PowerShell 5.1 级联根据变更笔记的描述被删除的 win32 回退链包含以下部件每件都对应一份真实复杂度部件作用复杂度来源两级 spawn先pwsh.exe失败后再powershell.exe5.1两个 spawn 层运行同一个WinForms 脚本WinForms 脚本提供文件夹选择 UI主动调用SetProcessDPIAware需要 DPI 修正脚本随包分发与维护回退触发拓宽从最初的ENOENT找不到命令拓宽为pwsh 的任何失败为了修复「可解析的 PowerShell 6 没有 WinForms」的回归PowerShell 6 退出码为 1而非ENOENT若不拓宽触发条件回退链会在 6 上被卡死三连败AggregateError携带全部三个原因pwsh、5.1、以及前两者之外的第三个调用方看到的错误是最具可操作性的条目反而指向 PowerShell 宿主每层 abort 重检每层 spawn 前后都要重新检查调用方是否已 abort增加控制流分支这条链的初衷是当 koffi 层不可用时仍能给出一个可用的选择器。但笔记明确指出它可能保护的每一个触发条件都是 DeepSeek Harness 自身打包或部署的失败而不是操作系统的失败。三条论证如下koffi 原生二进制随包分发koffi 作为普通可选依赖koromix/koffi-win32-x64分发无 install script。能装上这个包的宿主就一定有二进制装不上的宿主会在安装期就明确报错——此时回退代码根本不会得到加载。也就是说koffi 不可用这个前提在打包链上不成立。「上古 Windows」不可能出现本仓库支持的 Node 版本运行在远比 Vista 时代IFileOpenDialogABI 新的 Windows 世代上不存在因系统过老导致IFileOpenDialog不可用的场景。koffi/COM 缺陷有崩溃隔离即使 koffi/COM 自身有缺陷也只崩溃对话框子进程crash isolation宿主进程不受影响。对自己 bug 的正确响应是上报失败而不是静默降级到旧版对话框。决策win32 层只保留 koffi失败即原样上报变更笔记记录的最终决策是win32 层恰好就是 koffiIFileOpenDialog子进程任何失败原样上报无回退。具体来说PowerShell 链的四个部件被整体删除pwsh→ Windows PowerShell 5.1 的级联DPI 修正的 WinForms 脚本AggregateError聚合每层 abort 重检。pickNativeDirectory的 win32 分支收敛为单次调用。当前源码 native-picker.ts 正是这样实现的if (platform win32) { // The koffi-backed IFileOpenDialog child process — the modern picker with // per-monitor-v2 DPI and abort support. koffi is a packaged dependency // whose availability the install guarantees, so there is no fallback // tier: any failure surfaces as-is ... const pickDialog internals.pickWin32Dialog ?? pickWin32Directory return await pickDialog(signal) }这里pickWin32Dialog是可注入的测试钩子用于跨平台确定性测试生产默认值是pickWin32Directory——来自 win32-dialog.ts 的 koffi 对话框驱动在主线程上 spawn 一个对话框子进程子进程阻塞在模态Show内部通过消息协议映射 promiseabort 时向对话框线程的窗口持续投递WM_CLOSE150ms 重试、最多 20 次仍未响应则kill()兜底。注意它始终带有 abort 支持这是被删除的 PowerShell 链不具备的。dsh-native-command仍然保留为 POSIX 层macOSosascript、Linuxzenity/kdialog的依赖。统一后的回退判据只回退到系统提供的工具这次变更最值得提炼的是它把本包其余部分早已遵循的回退判据统一到了 win32 层回退层只存在于操作系统/桌面环境提供、且可能缺失的工具我们自己打包分发的工具失败即明确报错。对照实现验证这一判据Linux有回退zenity→kdialog都是桌面环境提供的工具宿主可能没装。因此 native-picker.ts 中zenity报ENOENT时才尝试kdialog两者都缺失时报出可操作的安装提示。启动探针 probe.ts 同样在 boot 时采样zenity/kdialog是否在 PATH 上LINUX_CHOOSER_BINARIES供-auto组合决定是否干脆挂载browse后端。macOS无回退osascript是 macOS 自带工具但按「无回退」处理任何非取消失败直接抛出仅把User canceled/-128映射为null。Windows变更后无回退koffi 是自打包依赖安装即保证可用故失败必须原样暴露。与之对应的组合层仍保留着唯一重要的回退browse后端。resolveDirectoryPickerBackendresolve.ts在任何歧义场景非 loopback 绑定、SSH 启动、Linux 无显示会话或无选择器二进制下解析为browse由 index.ts 在启动时挂载一次整个服务生命周期内保持稳定。browse是应用内的一级目录浏览 建目录交互见 directory-picker-browse/README.md服务于原生选择器够不着的远程客户端。层与层职责明确运行时层对自打包依赖失败即上报部署时由组合层决定是否使用原生交互。为什么拒绝三个替代方案笔记记录了三个被明确拒绝的替代方案各自的拒绝理由对应着不同的工程权衡方案一保留链但去掉 pwsh 质量层koffi→ Windows PowerShell 5.1拒绝理由剩下的这一层仍然是在防范我们自己打包的依赖故障仍然要付出脚本维护、拓宽触发、错误聚合的代价仍然会把我们自己的 vtable/COM 缺陷藏到旧版对话框后面。而「仅对外部提供的工具回退」的判据不接受任何 Windows 层——PowerShell 不是 DeepSeek Harness 提供的但也正是因为 PowerShell 的版本差异5.1/6/7本身不可控才需要额外的质量层。方案二原样保留链拒绝理由它是选择器表面唯一的二级运行时回退其触发条件是本就会明确报错的部署侧失败并且它把一次失败的选择操作降级为AggregateError其中最具可操作性的条目反而指向 PowerShell 宿主——错误信息对用户和开发者都构成误导。方案三原生 pick 失败时在运行时回退到browse拒绝理由directory-picker seam 的流程洞flow holes属于single类型-auto组合已在启动时选择一个后端运行时跨类型跳转会同时挂载两个后端double-mount并模糊能力边界capability boundary。换句话说browse是部署期的选择不是运行期的救火队员。这三个方案的共同教训回退层加在哪里、以什么条件触发决定了它是可靠性设计还是复杂度负债。合并与删除的旧笔记pwsh 优先 DPI 修复笔记本次变更还合并并删除了此前一份pwsh 优先的 DPI 选择器修复Agent Note——其决策在这里被完全反转其保留的理由不再指导只含 koffi 层的未来工作。笔记同时如实保留了那份旧笔记中仍然真实的技术事实这些事实解释了旧链为什么长成那样PowerShell 7 呈现现代选择器PowerShell 7 能渲染基于IFileDialog的现代文件夹选择器而 5.1 的FolderBrowserDialog被硬连到旧版SHBrowseForFolder树——这正是pwsh 优先质量层存在的 UI 原因。SetProcessDPIAware修正 DPI 上限脚本主动调用SetProcessDPIAware是为了修正 spawn 时系统 DPI 上限带来的模糊渲染。pwsh → 5.1 跳转的真实原因可解析的 PowerShell 6 没有 WinForms失败退出码为 1而非ENOENT因此旧链必须把回退触发从ENOENT拓宽为pwsh 的任何失败才能继续走到 5.1。旧笔记中被拒绝的替代方案要求 PowerShell 7、导入resolvePwshPath、在 harness 进程设置 DPI 感知随着链的删除全部失去意义——因为它们解决的都是一条已经不存在的问题链上的问题。变更后果与验证失败面收敛为单一来源win32 选择器的失败面现在只有来自单一层的一个错误调用方看到的是真实原因koffi 加载失败、COM 拒绝、对话框崩溃而不是链式聚合的错误。这与测试用例一一对应。在 native-picker.spec.ts 中可以看到测试随实现一起收缩原 pwsh/5.1 级联与三连败用例被替换为单个「失败原样上报、无回退」用例it(surfaces the Win32 dialog failure with no fallback, async () { const run vi.fnDirectoryPickerRunner() await expect(pickNativeDirectory(signal(), { platform: win32, run, pickWin32Dialog: noDialog })) .rejects.toThrow(dialog unavailable) expect(run).not.toHaveBeenCalled() // 关键断言不再 spawn 任何命令 })默认适配器测试run未注入、走真实默认路径改为驱动 Linux 层——用预中止的 signal 让默认 win32 对话框在任何宿主上都确定性地在 spawn 任何 worker 之前抛出native directory picker aborted从而保持跨平台确定性。另有断言确认 win32 层在对话框正常应答时从不 spawn 命令expect(run).not.toHaveBeenCalled()从测试侧印证了「win32 分支是单次调用」的决策。行为净删除pwsh/powershell.exe不再被本包调用WinForms 脚本、SetProcessDPIAware修正与-STA标志随之消失。这也意味着宿主机上 PowerShell 的版本分布5.1 / 6 / 7 / 无不再影响选择器的行为少了一类与环境相关的隐藏故障面。重新引入的条件笔记给出了明确的重新引入判据未来出现在我们打包链之外的 win32 机制我们不随包分发的、系统提供的对话框宿主才值得在同一判据下保留一层回退。也就是说如果未来某个 Windows 系统自带、可能缺失的对话框宿主出现可以按 Linuxzenity→kdialog的同样模式为其加一层回退但自打包的 koffi 永远走 fail-loud 路线。给架构师与维护者的经验回退判据先于回退代码先明确什么值得回退、什么必须失败再动手写 fallback。外部工具可缺失 → 回退自带依赖 → fail loud是一条可复用的通用判据。回退触发越窄越好旧链从ENOENT拓宽到任何失败来迁就 PowerShell 6 的异常退出码每拓宽一次就多吞掉一类真实错误。触发条件宽泛的回退链最终会掩盖真正需要被看到的问题。组合层回退优于运行时回退DeepSeek Harness 的做法是把跨能力native ↔ browse的切换放在启动时的一次性决策运行时只做单层失败上报。跨类型运行时跳转会 double-mount 后端并模糊能力边界。删除代码也要删除配套文档本次变更同步合并删除了被反转的旧笔记避免过时理由继续指导未来工作同时把仍真实的技术事实PowerShell 版本差异、DPI 机制留在新笔记里供后人理解那段已删除的历史。延伸阅读变更笔记原文 与 中文版native-picker.ts — 变更后按平台分发的实现win32-dialog.ts — koffiIFileOpenDialog子进程与WM_CLOSEabort 机制native-picker.spec.ts — 含「失败无回退」等用例directory-picker-auto/src/resolve.ts — 启动时 native/browse 解析决策directory-picker-auto/src/probe.ts — Linux 选择器二进制 PATH 探针directory-picker-auto/src/index.ts — 组合层挂载后端与界面成对directory-picker-native/README.md — 原生选择器后端包文档含Windows 无机制回退的限制说明赞分享人工智能AI AgentAgent 框架DeepSeek【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址https://gitcode.com/gh_mirrors/de/deepseek-harness点击查看免费下载相关推荐HyprPanel主题开发进阶使用Matugen、Pywal实现动态色彩方案HyprPanel主题开发进阶使用Matugen、Pywal实现动态色彩方案 HyprPanel是一款为Hyprland打造的高度可定制面板工具支持丰富的主Piped技术选型解析为什么选择Vue.js构建前端架构Piped技术选型解析为什么选择Vue.js构建前端架构 在当今的Web开发领域前端框架的选择直接影响项目的开发效率、性能表现和可维护性。作为一款注重隐私保音视频前端Heartrate高级用法多线程追踪与文件过滤配置详解Heartrate高级用法多线程追踪与文件过滤配置详解 Heartrate是一款简单实用的Python程序执行实时可视化工具能够帮助开发者直观地了解程序运行上一篇10分钟上手tldr-pages专家系统让命令行查询像聊天一样简单下一篇揭秘Homebrew过期包检测从依赖分析到智能更新的全流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DeepSeek Harness 架构决策解析：为什么删除 Windows 目录选择器的 PowerShell 回退链
人工智能AI AgentAgent 框架DeepSeek【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址https://gitcode.com/gh_mirrors/de/deepseek-harness点击查看免费下载本文基于 DeepSeek Harness 仓库内已实施的架构变更笔记2026-08-04-drop-windows-powershell-picker-fallback.md撰写围绕「原生目录选择器native directory pickerwin32 分支移除 PowerShell 两级回退」这一决策结合当前源码实现与测试用例还原问题背景、决策依据、替代方案与落地后果。读完本文你将理解该项目的仅对外部提供的工具回退、自带依赖失败即明确报错原则如何落地以及如何在类似场景中应用同一判据。背景原生目录选择器的平台分层结构DeepSeek Harness 通过dsh-host-directory-picker-native包为坐在宿主显示器前的操作者打开操作系统原生目录选择器。从 native-picker.ts 的源码结构看pickNativeDirectory是一个按平台分发的单一入口macOS调用osascriptchoose folderPOSIX path无任何回退层Windowswin32调用 koffi 支撑的IFileOpenDialog子进程Linux优先zenity仅在zenity缺失ENOENT时回退到kdialog两者都缺失时报出可操作错误install zenity or kdialog。在这条分发路径之上还存在一个组合层composition leveldsh-host-directory-picker-auto包在启动时通过 resolve.ts 的resolveDirectoryPickerBackend采样一次宿主事实绑定地址、是否 SSH 启动、是否有显示会话、Linux 上是否存在 zenity/kdialog 可执行文件决定挂载native还是browse后端并在 index.ts 中通过 Loader 把对应后端与客户端界面成对挂入内存根树。本文主角——被删除的 PowerShell 回退链——正是位于这条native后端的win32 分支内部在 koffiIFileOpenDialog子进程之下曾经还有一条两级 PowerShell 回退先尝试pwsh.exe再尝试powershell.exeWindows PowerShell 5.1两者运行同一个主动启用SetProcessDPIAware的 WinForms 脚本。被删除的链条pwsh → Windows PowerShell 5.1 级联根据变更笔记的描述被删除的 win32 回退链包含以下部件每件都对应一份真实复杂度部件作用复杂度来源两级 spawn先pwsh.exe失败后再powershell.exe5.1两个 spawn 层运行同一个WinForms 脚本WinForms 脚本提供文件夹选择 UI主动调用SetProcessDPIAware需要 DPI 修正脚本随包分发与维护回退触发拓宽从最初的ENOENT找不到命令拓宽为pwsh 的任何失败为了修复「可解析的 PowerShell 6 没有 WinForms」的回归PowerShell 6 退出码为 1而非ENOENT若不拓宽触发条件回退链会在 6 上被卡死三连败AggregateError携带全部三个原因pwsh、5.1、以及前两者之外的第三个调用方看到的错误是最具可操作性的条目反而指向 PowerShell 宿主每层 abort 重检每层 spawn 前后都要重新检查调用方是否已 abort增加控制流分支这条链的初衷是当 koffi 层不可用时仍能给出一个可用的选择器。但笔记明确指出它可能保护的每一个触发条件都是 DeepSeek Harness 自身打包或部署的失败而不是操作系统的失败。三条论证如下koffi 原生二进制随包分发koffi 作为普通可选依赖koromix/koffi-win32-x64分发无 install script。能装上这个包的宿主就一定有二进制装不上的宿主会在安装期就明确报错——此时回退代码根本不会得到加载。也就是说koffi 不可用这个前提在打包链上不成立。「上古 Windows」不可能出现本仓库支持的 Node 版本运行在远比 Vista 时代IFileOpenDialogABI 新的 Windows 世代上不存在因系统过老导致IFileOpenDialog不可用的场景。koffi/COM 缺陷有崩溃隔离即使 koffi/COM 自身有缺陷也只崩溃对话框子进程crash isolation宿主进程不受影响。对自己 bug 的正确响应是上报失败而不是静默降级到旧版对话框。决策win32 层只保留 koffi失败即原样上报变更笔记记录的最终决策是win32 层恰好就是 koffiIFileOpenDialog子进程任何失败原样上报无回退。具体来说PowerShell 链的四个部件被整体删除pwsh→ Windows PowerShell 5.1 的级联DPI 修正的 WinForms 脚本AggregateError聚合每层 abort 重检。pickNativeDirectory的 win32 分支收敛为单次调用。当前源码 native-picker.ts 正是这样实现的if (platform win32) { // The koffi-backed IFileOpenDialog child process — the modern picker with // per-monitor-v2 DPI and abort support. koffi is a packaged dependency // whose availability the install guarantees, so there is no fallback // tier: any failure surfaces as-is ... const pickDialog internals.pickWin32Dialog ?? pickWin32Directory return await pickDialog(signal) }这里pickWin32Dialog是可注入的测试钩子用于跨平台确定性测试生产默认值是pickWin32Directory——来自 win32-dialog.ts 的 koffi 对话框驱动在主线程上 spawn 一个对话框子进程子进程阻塞在模态Show内部通过消息协议映射 promiseabort 时向对话框线程的窗口持续投递WM_CLOSE150ms 重试、最多 20 次仍未响应则kill()兜底。注意它始终带有 abort 支持这是被删除的 PowerShell 链不具备的。dsh-native-command仍然保留为 POSIX 层macOSosascript、Linuxzenity/kdialog的依赖。统一后的回退判据只回退到系统提供的工具这次变更最值得提炼的是它把本包其余部分早已遵循的回退判据统一到了 win32 层回退层只存在于操作系统/桌面环境提供、且可能缺失的工具我们自己打包分发的工具失败即明确报错。对照实现验证这一判据Linux有回退zenity→kdialog都是桌面环境提供的工具宿主可能没装。因此 native-picker.ts 中zenity报ENOENT时才尝试kdialog两者都缺失时报出可操作的安装提示。启动探针 probe.ts 同样在 boot 时采样zenity/kdialog是否在 PATH 上LINUX_CHOOSER_BINARIES供-auto组合决定是否干脆挂载browse后端。macOS无回退osascript是 macOS 自带工具但按「无回退」处理任何非取消失败直接抛出仅把User canceled/-128映射为null。Windows变更后无回退koffi 是自打包依赖安装即保证可用故失败必须原样暴露。与之对应的组合层仍保留着唯一重要的回退browse后端。resolveDirectoryPickerBackendresolve.ts在任何歧义场景非 loopback 绑定、SSH 启动、Linux 无显示会话或无选择器二进制下解析为browse由 index.ts 在启动时挂载一次整个服务生命周期内保持稳定。browse是应用内的一级目录浏览 建目录交互见 directory-picker-browse/README.md服务于原生选择器够不着的远程客户端。层与层职责明确运行时层对自打包依赖失败即上报部署时由组合层决定是否使用原生交互。为什么拒绝三个替代方案笔记记录了三个被明确拒绝的替代方案各自的拒绝理由对应着不同的工程权衡方案一保留链但去掉 pwsh 质量层koffi→ Windows PowerShell 5.1拒绝理由剩下的这一层仍然是在防范我们自己打包的依赖故障仍然要付出脚本维护、拓宽触发、错误聚合的代价仍然会把我们自己的 vtable/COM 缺陷藏到旧版对话框后面。而「仅对外部提供的工具回退」的判据不接受任何 Windows 层——PowerShell 不是 DeepSeek Harness 提供的但也正是因为 PowerShell 的版本差异5.1/6/7本身不可控才需要额外的质量层。方案二原样保留链拒绝理由它是选择器表面唯一的二级运行时回退其触发条件是本就会明确报错的部署侧失败并且它把一次失败的选择操作降级为AggregateError其中最具可操作性的条目反而指向 PowerShell 宿主——错误信息对用户和开发者都构成误导。方案三原生 pick 失败时在运行时回退到browse拒绝理由directory-picker seam 的流程洞flow holes属于single类型-auto组合已在启动时选择一个后端运行时跨类型跳转会同时挂载两个后端double-mount并模糊能力边界capability boundary。换句话说browse是部署期的选择不是运行期的救火队员。这三个方案的共同教训回退层加在哪里、以什么条件触发决定了它是可靠性设计还是复杂度负债。合并与删除的旧笔记pwsh 优先 DPI 修复笔记本次变更还合并并删除了此前一份pwsh 优先的 DPI 选择器修复Agent Note——其决策在这里被完全反转其保留的理由不再指导只含 koffi 层的未来工作。笔记同时如实保留了那份旧笔记中仍然真实的技术事实这些事实解释了旧链为什么长成那样PowerShell 7 呈现现代选择器PowerShell 7 能渲染基于IFileDialog的现代文件夹选择器而 5.1 的FolderBrowserDialog被硬连到旧版SHBrowseForFolder树——这正是pwsh 优先质量层存在的 UI 原因。SetProcessDPIAware修正 DPI 上限脚本主动调用SetProcessDPIAware是为了修正 spawn 时系统 DPI 上限带来的模糊渲染。pwsh → 5.1 跳转的真实原因可解析的 PowerShell 6 没有 WinForms失败退出码为 1而非ENOENT因此旧链必须把回退触发从ENOENT拓宽为pwsh 的任何失败才能继续走到 5.1。旧笔记中被拒绝的替代方案要求 PowerShell 7、导入resolvePwshPath、在 harness 进程设置 DPI 感知随着链的删除全部失去意义——因为它们解决的都是一条已经不存在的问题链上的问题。变更后果与验证失败面收敛为单一来源win32 选择器的失败面现在只有来自单一层的一个错误调用方看到的是真实原因koffi 加载失败、COM 拒绝、对话框崩溃而不是链式聚合的错误。这与测试用例一一对应。在 native-picker.spec.ts 中可以看到测试随实现一起收缩原 pwsh/5.1 级联与三连败用例被替换为单个「失败原样上报、无回退」用例it(surfaces the Win32 dialog failure with no fallback, async () { const run vi.fnDirectoryPickerRunner() await expect(pickNativeDirectory(signal(), { platform: win32, run, pickWin32Dialog: noDialog })) .rejects.toThrow(dialog unavailable) expect(run).not.toHaveBeenCalled() // 关键断言不再 spawn 任何命令 })默认适配器测试run未注入、走真实默认路径改为驱动 Linux 层——用预中止的 signal 让默认 win32 对话框在任何宿主上都确定性地在 spawn 任何 worker 之前抛出native directory picker aborted从而保持跨平台确定性。另有断言确认 win32 层在对话框正常应答时从不 spawn 命令expect(run).not.toHaveBeenCalled()从测试侧印证了「win32 分支是单次调用」的决策。行为净删除pwsh/powershell.exe不再被本包调用WinForms 脚本、SetProcessDPIAware修正与-STA标志随之消失。这也意味着宿主机上 PowerShell 的版本分布5.1 / 6 / 7 / 无不再影响选择器的行为少了一类与环境相关的隐藏故障面。重新引入的条件笔记给出了明确的重新引入判据未来出现在我们打包链之外的 win32 机制我们不随包分发的、系统提供的对话框宿主才值得在同一判据下保留一层回退。也就是说如果未来某个 Windows 系统自带、可能缺失的对话框宿主出现可以按 Linuxzenity→kdialog的同样模式为其加一层回退但自打包的 koffi 永远走 fail-loud 路线。给架构师与维护者的经验回退判据先于回退代码先明确什么值得回退、什么必须失败再动手写 fallback。外部工具可缺失 → 回退自带依赖 → fail loud是一条可复用的通用判据。回退触发越窄越好旧链从ENOENT拓宽到任何失败来迁就 PowerShell 6 的异常退出码每拓宽一次就多吞掉一类真实错误。触发条件宽泛的回退链最终会掩盖真正需要被看到的问题。组合层回退优于运行时回退DeepSeek Harness 的做法是把跨能力native ↔ browse的切换放在启动时的一次性决策运行时只做单层失败上报。跨类型运行时跳转会 double-mount 后端并模糊能力边界。删除代码也要删除配套文档本次变更同步合并删除了被反转的旧笔记避免过时理由继续指导未来工作同时把仍真实的技术事实PowerShell 版本差异、DPI 机制留在新笔记里供后人理解那段已删除的历史。延伸阅读变更笔记原文 与 中文版native-picker.ts — 变更后按平台分发的实现win32-dialog.ts — koffiIFileOpenDialog子进程与WM_CLOSEabort 机制native-picker.spec.ts — 含「失败无回退」等用例directory-picker-auto/src/resolve.ts — 启动时 native/browse 解析决策directory-picker-auto/src/probe.ts — Linux 选择器二进制 PATH 探针directory-picker-auto/src/index.ts — 组合层挂载后端与界面成对directory-picker-native/README.md — 原生选择器后端包文档含Windows 无机制回退的限制说明赞分享人工智能AI AgentAgent 框架DeepSeek【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址https://gitcode.com/gh_mirrors/de/deepseek-harness点击查看免费下载相关推荐HyprPanel主题开发进阶使用Matugen、Pywal实现动态色彩方案HyprPanel主题开发进阶使用Matugen、Pywal实现动态色彩方案 HyprPanel是一款为Hyprland打造的高度可定制面板工具支持丰富的主Piped技术选型解析为什么选择Vue.js构建前端架构Piped技术选型解析为什么选择Vue.js构建前端架构 在当今的Web开发领域前端框架的选择直接影响项目的开发效率、性能表现和可维护性。作为一款注重隐私保音视频前端Heartrate高级用法多线程追踪与文件过滤配置详解Heartrate高级用法多线程追踪与文件过滤配置详解 Heartrate是一款简单实用的Python程序执行实时可视化工具能够帮助开发者直观地了解程序运行上一篇10分钟上手tldr-pages专家系统让命令行查询像聊天一样简单下一篇揭秘Homebrew过期包检测从依赖分析到智能更新的全流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考