用超时上限治理桌面助手资源占用

让语音助手打开 Notepad，应用启动了，后续指令却一直排队。Ankita AI 的作者 Krish Verma 遇到的并非模型理解问题，而是任务已经完成，子进程还活着，资源占用迟迟无法结束。

他的办法是给资源保留设置 120 秒上限：到点释放语音队列，应用继续运行，同时保留 Stop 的控制能力。这篇值得读的地方，是它把任务完成、进程存活和资源释放拆开处理，也坦承了超时方案解决不了什么。

为什么打开一个应用会堵住后续请求

Ankita AI 是桌面助手，语音任务由一个小型工作池执行：默认 4 个 worker，硬上限 8 个，并始终为「停止任务」等控制请求预留一个执行名额。任务工作时，还要向资源代理（resource broker）申请锁。

打开应用的任务有些特殊。启动 Notepad 后，启动动作结束了，但 Notepad 进程还在。如果立刻释放全部资源，其他任务可能抢用它正在编辑的文件。因此，原实现会把资源占用移交给仍在运行的子进程。

问题出在这个占用没有期限。编辑器不会自动关闭，卡住的命令也可能永不退出。任务一直保持 resourcesHeld: true，后面的请求就可能持续等待。

任务完成，不代表它启动的进程也该结束。

反过来，进程还活着，也未必应该继续占着语音请求的执行通道。作者要拆开的就是这两种生命周期。

120 秒上限释放了什么

改动位于 src/automation/voice-jobs.mjs。当已完成的任务仍持有资源时，retainOrRelease() 会把占用移交给 voice-processes:<job-id>，然后启动计时器。

这段代码负责在期限到达时释放占用，并通知界面更新：

const cap = this.holdMaxMs;
if (cap > 0) {
  const timer = setTimeout(() => {
    if (!entry.resourcesHeld) return;
    entry.holdExpired = true;
    if (entry.record) entry.record.holdExpired = true;
    release();
    this.emit(entry);
  }, cap);
  timer.unref?.();
  entry.resourceLifetime.finally(() => clearTimeout(timer));
}

要看的是 release()：到期触发的是资源释放，没有调用终止进程的函数。entry.resourceLifetime.finally(...) 则保证子进程提前结束时，计时器会被清除；timer.unref?.() 让这个计时器本身不成为维持 Node 进程运行的理由。

默认值在 src/automation/voice-task-policy.mjs 中统一定义为 VOICE_HOLD_MAX_MS = 120000，经 config.mjs 接入同名环境变量 VOICE_HOLD_MAX_MS，配置范围限制在 10 秒到 30 分钟之间。

超时后，面板将任务显示为「Still running」，并说明请求已完成、程序仍在后台打开，语音可以继续接受下一条请求。

但这里必须区分两种锁：助手内部的资源占用，与程序自己取得的文件锁。前者释放，不会自动消除后者。下一个任务如果需要同一个被锁文件，仍可能等待。

队列放行以后，Stop 为什么容易失效

作者之前的实现存在另一个问题：资源一旦释放，Stop 就无法再触达子进程；清理逻辑还可能把已完成任务从列表中删除。程序继续运行，助手却丢了终止它的入口。

修复首先调整 cancel() 的提前返回条件：

if (entry.finished && !entry.resourcesHeld && !entry.holdExpired) return false;

关键在 !entry.holdExpired。普通已完成、已释放的任务可以退出取消流程；因超时而释放的任务，还需要保留后续处理机会。

prune() 同样只清理满足 entry.finished && !entry.resourcesHeld && !entry.holdExpired 的条目。这样，超时记录仍然留在列表里，Stop 可以通过 entry id 找到它，再调用 entry.resourceHold.stop() 结束子进程。

这个控制接口来自 src/core/voice-worker.mjs，结构只有 { promise: childLifetime(active), stop: () => entry.cancelWorker() }：一个表示进程生命周期的 Promise，加一个停止函数。等待进程结束和主动结束进程，各有入口。

作者用测试固定了核心行为：把上限设为 60 毫秒，模拟一个永不结束的子进程，验证任务最初持有资源，到期后队列释放、holdExpired 为 true，下一条请求可以立即执行。工作池有 9 项测试，变更日志还记录了相关的 167 项语音与启动器测试通过。

这些测试支持队列行为符合预期，不能证明默认的 120 秒适合真实用户。

我的判断

我赞同默认不因超时杀掉用户主动打开的应用。用户说的是打开编辑器，未必授权助手两分钟后关闭它。保留应用、释放队列、继续提供 Stop，是一个合理的取舍。

但作者明确承认，120 秒是估计值，没有测量用户打开应用后多久会再次说话，也没有给出不同超时配置的对照数据。因此，这个默认值属于经验之谈。

和「一直等待子进程退出」相比，上限能避免无期限占用语音队列；和「到点终止子进程」相比，它保留了用户正在使用的程序，代价是后台进程、文件锁和任务记录仍要继续管理。

还有两个边界。计时器按任务分别运行，4 个长时间存活的子进程各有自己的时钟，并不共享一个总预算。为了保留 Stop 而留下的超时记录，最终如何回收，原文也没交代完整。

120 秒解决的是队列占用期限，不是子进程的全部生命周期。

能拿来做什么

• 如果 Node 服务或桌面工具会启动子进程，先检查任务完成后是否仍等待子进程退出，并分别定义请求完成、资源释放和进程结束的条件。
• 给队列占用增加超时时，连同取消入口和记录清理条件一起检查，确保放行后仍能定位并停止后台进程。
• 前端任务面板可以分别表达「请求已完成」和「程序仍运行」，让状态文字与实际控制能力一致。
• 测试这类逻辑时，可以采用短超时和永不结束的模拟子进程，重点验证后续请求能否执行，以及超时后 Stop 是否仍可用。