人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载v0.3.1 是 Kun 针对 Windows 平台发布的一个启动稳定性修复版本核心目标是解决部分 Windows 11 设备在从 v0.3.0 升级后无法正常启动的问题。本文基于 release/release-v0.3.1.md 与仓库内启动阶段源码src/main/runtime/kun-serve-process-cleanup.ts、src/main/main-runtime-startup.ts展开说明问题根因、修复方案WQL 预筛选 SID 所有者验证 PID 二次校验以及升级注意事项帮助 Windows 用户与开发者理解这一补丁的具体行为。一、问题背景升级 v0.3.0 后为何启动会失败Kun 桌面端GUI启动时会先确保kun serve运行时进程处于健康状态。为了避免上一次运行留下的历史kun serve进程占用端口或数据目录启动阶段需要先做一次“历史进程清理”见 src/main/main-runtime-startup.ts 中的restartAllKunServeProcessesOnce先停掉当前共享运行时再清理历史进程最后拉起替换进程。在 v0.3.0 及更早版本中Windows 平台清理历史进程的方式是遍历系统中全部Win32_Process来找出可疑进程。这在进程数量较少的机器上没有问题但在部分 Windows 11 设备上系统进程数量庞大一次性枚举全部进程需要调用 PowerShell / CIMGet-CimInstance做全表扫描对每个进程再进一步查询所有者等属性进一步放大开销总耗时超过启动阶段的等待预算主窗口还没打开启动流程就因为“历史进程扫描超时”被判定失败。这正是 v0.3.1 修复的 issue#1163描述的场景。需要说明的是issue 编号与对比链接来源于发布文档原文仅供问题定位使用不构成对外部网站的推广。二、修复核心WQL 预筛选只查“可能属于 Kun”的候选进程v0.3.1 的修复思路非常直接不在全系统进程表上做所有者查询而是先用 WQL 过滤器把候选进程缩小到极小的集合再只对这些候选做代价高昂的所有者查询。在 src/main/runtime/kun-serve-process-cleanup.ts 中可以看到本次修复引入的候选扫描脚本WINDOWS_PROCESS_CANDIDATE_SCRIPT$candidates Get-CimInstance Win32_Process -Filter Name node.exe OR Name electron.exe OR Name LIKE kun%.exe $items $candidates | ForEach-Object { [pscustomobject]{ ProcessId $_.ProcessId ParentProcessId $_.ParentProcessId ExecutablePath $_.ExecutablePath CommandLine $_.CommandLine } } ($items) | ConvertTo-Json -Compress关键点WQL 预筛选发生在 CIM 层过滤条件为Name node.exe OR Name electron.exe OR Name LIKE kun%.exe由 PowerShell/CIM 引擎在进程枚举阶段就完成过滤而不是拉回全表再在 Node.js 侧过滤。之所以选这三个名字与 Kun 的运行形态有关GUI 由 Electron 承载运行时由node脚本serve-entry.js启动独立 CLI 形态则可能是kun*.exe可执行文件。这与isAllowedKunServeExecutable的实现kun-serve-process-cleanup.ts保持一致。候选扫描阶段不做所有者查询脚本中没有GetOwnerSid、没有$currentSid这是把“重活”从第一阶段剥离出来的关键设计。回归测试 src/main/runtime/kun-serve-process-cleanup.test.ts 明确断言候选脚本包含-Filter、三个 Name 条件且不包含GetOwnerSid与$currentSid。两阶段扫描的完整流程listCurrentUserProcesseskun-serve-process-cleanup.ts在 Windows 上的实现是典型的两阶段阶段一候选扫描用WINDOWS_PROCESS_CANDIDATE_SCRIPT通过powershell.exe -NoProfile -NonInteractive -Command拉取候选进程快照解析 JSON 后用looksLikeKunServeProcess做命令形态过滤确认命令行确实形如kun serve。阶段二所有者验证对每个候选 PID 调用inspectCurrentUserProcess用按 PID 精确定位的脚本再次确认其属于当前用户。阶段二使用的脚本windowsCurrentUserProcessScriptkun-serve-process-cleanup.ts是“保留当前用户 SID 验证”的具体实现$currentSid [System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value $candidate Get-CimInstance Win32_Process -Filter ProcessId ${pid} ... $owner Invoke-CimMethod -InputObject $candidate -MethodName GetOwnerSid -ErrorAction SilentlyContinue if ($owner.Sid -eq $currentSid) { ... }它按精确 PID 只查询一个进程并调用GetOwnerSid拿到的 SID 与当前用户 SID 比对。测试用例kun-serve-process-cleanup.test.ts验证了在一个包含 37 个无关 Node 进程的快照里只对唯一命中的 Kun 候选 PID 发起了一次GetOwnerSid所有者查询其余无关进程不会触发所有者查询。三、安全性设计SID 验证与 PID 二次校验为何必须保留修复只优化了“查谁的效率”没有削弱“能不能杀”的安全性。v0.3.1 明确保留了两道校验1. 当前用户 SID 验证进程所有者必须等于当前 Windows 用户SID 比对避免误伤其他用户启动的 Kun 进程或无关进程。这正是windowsCurrentUserProcessScript中GetOwnerSid与$currentSid的作用。Unix 平台对应的逻辑是parseUnixProcessSnapshot按uid currentUid过滤kun-serve-process-cleanup.tsWindows 与 Unix 在“只清理当前用户进程”这一原则上是统一的。2. PID 二次校验fail-closed 机制清理函数clearHistoricalKunServeProcesseskun-serve-process-cleanup.ts在真正终止前会再次调用inspectProcess验证该 PID 当前仍然匹配 Kun serve 命令形态随后才通过terminateVerifiedPid终止。测试用例覆盖了关键的安全场景“PID 在信号发出前身份已变化”时终止被拒绝整体清理报错并不启动替换进程kun-serve-process-cleanup.test.ts错误信息为Could not terminate historical Kun serve process(es): ... A replacement was not started已经自然退出的进程被归入alreadyExitedPids不会重复操作kun-serve-process-cleanup.test.ts。这种“宁可失败也不误杀”的 fail-closed 语义与 src/main/kun-process-ports.ts 中terminateVerifiedPid的“验证后再杀、PID 重用前不升级 SIGKILL”策略一脉相承。清理失败时不会拉起替换在启动编排层src/main/main-runtime-startup.ts 的restartAllKunServeProcessesOnce顺序为stopSharedForReplacementAndWait→clearHistoricalKunServeProcesses→ensureReplacementRunning。测试 src/main/main-runtime-startup.replacement.test.ts 验证了正常路径严格按[stop-current, clear-history, launch-replacement]顺序执行历史清理抛错时ensureReplacementRunning不会被调用即不会启动一个可能与残留进程冲突的替换运行时。四、回归测试防止退回“遍历全部进程”的旧实现v0.3.1 增加的回归测试位于 src/main/runtime/kun-serve-process-cleanup.test.ts其中最关键的一组断言第 54-81 行Windows 扫描必须走WINDOWS_PROCESS_CANDIDATE_SCRIPT且脚本含-Filter候选脚本包含Name node.exe、Name electron.exe、Name LIKE kun%.exe候选脚本不得包含GetOwnerSid与$currentSid所有者验证被推迟到第二阶段。只要未来有人把实现改回“遍历全部Win32_Process再逐个查所有者”这组断言会立即失败。这从测试层面锁定了本次修复的边界候选枚举必须用 WQL 预筛选所有者查询必须按精确 PID 收敛。命令执行的兜底参数也值得注意进程表查询统一使用windowsHide: true、超时PROCESS_TABLE_TIMEOUT_MS30 分钟与 16MB 的maxBuffer[kun-serve-process-cleanup.ts](https://link.gitcode.com/i/051f02ebab34055506b427b884042762#L45-L46, L149-L159)避免 PowerShell 子进程弹出窗口、输出被截断或长时间挂起。五、升级说明与适用范围发布文档明确给出 v0.3.1 的升级边界release/release-v0.3.1.md项目说明目标用户受 Windows 启动问题影响的用户建议直接升级到 v0.3.1数据迁移从 v0.3.0 升级无需迁移会话、工作区或 Provider 配置其他平台macOS、Linux 和独立 TUI无需额外操作由于本次改动集中在 Windows 启动阶段的进程清理逻辑macOS/Linux 的进程扫描路径ps -axww -o pid,ppid,uid,command见 kun-serve-process-cleanup.ts未受影响因此无需额外升级动作。升级到 v0.3.1 后如果历史进程中仍有其他用户或无法验证所有者的kun serve残留新版本会如实报告清理失败而非误杀用户可以在确认无冲突后再次启动。六、小结v0.3.1 是一个小而精准的稳定性修复它没有改变 Kun 的进程清理语义仍然是“只清理当前用户、可验证为 Kun serve 的历史进程”只是把 Windows 上“查谁”的效率从全表扫描优化为 WQL 预筛选 按 PID 精确所有者验证的两阶段模型。配合回归测试对候选脚本的硬性断言该修复在后续迭代中也不易回退。对 Windows 11 用户而言升级到 v0.3.1 是解决 v0.3.0 启动失败问题的推荐路径且无需任何数据迁移操作。赞分享人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载相关推荐Kun v0.3.3 稳定性深度解析Windows 启动时的 Runtime 进程清理与自定义服务商显示名称修复Kun v0.3.3 稳定性深度解析Windows 启动时的 Runtime 进程清理与自定义服务商显示名称修复 Kun v0.3.3 是一个聚焦稳定性的修复人工智能AI Agent自主智能体桌面应用MCP Clientsscrcpy 投屏音频指南5 分钟给安卓画面加上声音scrcpy 投屏音频指南5 分钟给安卓画面加上声音 scrcpy 是一款免费开源的安卓投屏与控制工具把安卓设备的画面显示在电脑上用电脑的键盘鼠标直接操作音视频Presto 0.106 版本发布解析表扫描调度并行化、JOIN 内存记账与稳定性修复深度解读Presto 0.106 版本发布解析表扫描调度并行化、JOIN 内存记账与稳定性修复深度解读 本文基于 Presto 仓库中的官方版本发布说明 releas大数据数据库后端上一篇城通网盘直链解析教程ctfileGet 免费直链解析器一步到位指南下一篇SUSFS4KSU KernelSU 模块隐藏 Root 检测 3 步上手完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考