Web UI 断开，不等于 DeepSeek Harness 已停止。浏览器标签页、远程桌面或 SSH 连接都可能单独失效，但 Mac 上的进程仍在运行。反过来，页面重新连上，也不代表原任务还活着。

公开的 Harness 实现通常会区分会话、运行记录、工作区和后台执行状态；但公开文档没有承诺所有任务都能跨越休眠、退出用户、进程退出或系统重启自动续跑。你不能只看“会话还在”这个信号。应先从另一条连接验证机器和进程，再检查日志是否继续产生、工作区是否出现受控变化、产物是否符合任务阶段。

如果你使用的是带有会话持久化或批处理记录的实现，可以先查看其 README 与会话代码说明，确认当前版本到底保存了什么，而不是凭界面名称猜测恢复能力：公开 Harness 的运行与会话说明 和 会话持久化实现。

第一轮核验：只读，不恢复

先执行只读检查，避免恢复动作本身制造第二个任务：

date
who
uptime
ps aux | grep -i 'deepseek\|harness' | grep -v grep
pgrep -alf 'deepseek|harness'

然后进入原工作区，记录当前差异和最新文件：

git status --short
git diff --stat
find . -type f -mmin -30 -print | head -50

日志、锁文件、数据库或任务目录的位置以你的 Harness 配置为准。不要为了“确认一下”删除锁文件，也不要直接再次提交同一个任务。只有当任务具备明确幂等键、阶段检查点和可重复执行边界时，才考虑重跑。

注意： 当前公开资料不能替你证明某个具体版本在唤醒后一定会续跑。恢复结论必须来自同一版本、同一运行模式和同一工作区的实测。

macOS 休眠会改变 CPU、磁盘和网络的可用状态。即使任务没有立即退出，网络请求、子进程推进、文件写入和图形权限也可能出现间隔或失败。系统支持查看电源管理配置、睡眠计划和电源断言，pmset 也能显示当前设置与睡眠唤醒相关信息；但这些信息只能说明系统发生了什么，不能单独证明 Harness 任务能否续跑。

先记录休眠前后的时间关系：

pmset -g custom
pmset -g assertions
pmset -g sched
pmset -g log | tail -100

可参考 macOS 电源管理命令说明。如果任务使用 caffeinate 防止空闲休眠，也要检查该命令绑定的 PID 是否仍然存在。caffeinate -w PID 会把电源断言与指定进程的生命周期关联起来；进程退出后，防休眠断言也会释放，具体行为见 caffeinate 命令手册。

合盖进入休眠后，任务的推进状态应如何确认？

不能直接回答“会”或“不会”。合盖后可能出现 3 种结果：

• Mac 没有真正进入系统休眠，任务继续推进。
• Mac 进入普通休眠，部分进程暂停，唤醒后继续或报错。
• Mac 进一步进入更深的电源状态，网络、凭据访问或子进程恢复失败。

“显示器关闭”与“系统休眠”不是同一件事。接通电源时，你可以在系统设置中检查是否允许显示器关闭后阻止自动休眠；也可以使用有明确生命周期的 caffeinate 包裹任务。相关设置说明见 macOS 睡眠与唤醒设置。

恢复标准不是“终端窗口还在”，而是以下 4 项同时成立：

1. Harness 主进程仍有有效 PID。
2. 子进程没有持续僵死或反复拉起。
3. 日志在唤醒后出现合理的新事件。
4. 工作区和产物变化符合当前阶段，且没有重复副作用。

只满足第 1 项，不足以继续等待。

关闭浏览器、断开远程桌面、退出 macOS 用户、系统重启，是四个不同的生命周期事件。它们对用户环境、环境变量、Keychain、图形权限和用户级后台服务的影响不同。

用户级后台进程如果依赖 LaunchAgent，其加载位置和生命周期与登录用户有关。系统提供的 launchd 后台任务说明明确区分了系统级和用户级启动项。你不能因为任务文件仍然存在，就假定原进程、环境变量和凭据已经恢复。

重启后的远程 Mac，原有会话能否直接接着用？

除非当前版本和你的启动配置明确实现了自动恢复，否则不要默认会。会话记录可能恢复，进程可能没有；进程可能恢复，子进程工作目录、密钥访问或图形权限也可能不同。

重启后的检查顺序应是：

1. 确认系统启动时间和当前登录用户。
2. 确认 Harness 是否由 launchd、终端脚本或人工命令启动。
3. 检查进程、日志、锁文件和工作区差异。
4. 验证凭据是否能读取，但不要把凭据打印到日志。
5. 对最后一个已知完成阶段执行最小测试。
6. 只有满足恢复标准，才继续未完成阶段。

如果已经出现部分文件修改、测试报告缺失、发布动作状态不明，立即停止自动继续。用版本控制差异、产物哈希、任务日志和外部系统记录建立可信基线。不要让 Agent 自己推断“上一阶段大概已经完成”。

你可以把任务分为 3 类：

• 允许中断重跑：纯检查、只读分析、可覆盖生成的临时文件。确认旧进程已死后，可以清理临时目录再重跑。
• 必须保留进程：长时间编译、持续流式调用、依赖本地缓存或交互式工具的任务。优先防止休眠，并使用明确的进程监督。
• 需要人工审批：发布、写入外部系统、修改生产配置、发送不可撤销请求。状态不明时必须人工接管。

优点与缺点要同时看：

✅ 继续等待：不重复消耗、不覆盖中间结果。前提是进程、日志和副作用都可验证。
✅ 从检查点恢复：比整任务重建更快。前提是检查点包含输入、阶段和产物校验。
❌ 直接重提任务：操作简单，但可能重复提交、重复发布或覆盖人工修改。
❌ 只恢复 Web UI：界面恢复不代表执行上下文恢复，最容易造成误判。

建议为每个长任务保留一个最小状态文件，至少记录任务 ID、工作区提交、当前阶段、最后成功产物、外部副作用和人工审批点。这样唤醒后核验的是事实，而不是聊天记录里的自然语言描述。

不要只测试“页面刷新后能不能看到任务”。你需要覆盖断线、休眠、进程退出和重启四类故障。下面的清单可以直接作为验收记录：

• [ ] 记录任务 ID、工作区提交、启动命令和运行用户。
• [ ] 断开 Web UI，等待一段任务事件后，从另一条连接核对进程和日志。
• [ ] 让 Mac 进入一次受控休眠，唤醒后检查最后事件、子进程和产物。
• [ ] 手动终止 Harness 主进程，确认会话记录不会被误判为正在执行。
• [ ] 重启 Mac，确认启动服务、用户会话、凭据和工作区都能被单独验收。
• [ ] 对可恢复任务验证检查点；对不可恢复任务验证安全失败。
• [ ] 检查重复提交、重复发布、锁文件残留和半写入文件。
• [ ] 明确任务的停止条件、人工审批点和重建命令。
• [ ] 将一次完整测试记录保存到项目运维文档，而不是只留在聊天窗口。

跨工作时段运行的 Agent 任务，不能只依赖“平时没出过问题”。短期任务可以在接通电源时使用受控的 caffeinate，并让命令结束时自动释放断言。不要永久关闭所有电源管理，也不要把“防休眠”当成进程恢复方案。它只能降低系统休眠概率，不能解决用户退出、网络断开、凭据失效或进程崩溃。

如果任务要跨越工作时段运行，采购时应关注的不只是 Mac 型号，而是 4 个交付条件：是否明确保持在线、是否允许独立用户运行、是否能保留日志和工作区、是否能在重启后执行验收。你可以先阅读 KVMNODE 的 Mac 远程使用入口，再根据使用区域查看 Mac mini M4 租赁与交付说明。

本地 Mac 的优点是数据和物理环境可控，适合短时开发、需要本地接口或必须人工观察的任务。缺点是合盖、断电、用户退出和个人网络都可能打断后台执行。临时远程桌面也不是独立运行环境：连接断开不一定停任务，但无法确认状态时，你仍然要承担重复执行风险。

当任务已经通过四项中断测试，并且每次恢复都有明确证据，继续使用现有 Mac 是合理的。若任务必须跨工作时段持续运行，且不能接受休眠、用户会话变化或重启后的不确定性，就应考虑迁移到具备持续在线、独立进程责任和重启验收流程的远程 Mac 环境。KVMNODE 的 Mac 方案更适合把“机器在线”与“任务可恢复”分开管理，但最终是否租赁，仍应以你的任务是否需要长期占用、物理接口或人工审批为准。