你要先把問題拆成四種狀態：瀏覽器或 Web UI 斷線、macOS 休眠、使用者會話變化，以及 Harness 主進程或子進程退出。這四種狀態的表面症狀很像，但恢復方法完全不同。

Apple 說明，Mac 進入休眠後仍然開機，但會進入低耗電狀態；筆記型 Mac 合上螢幕也可能直接觸發休眠。這不等於你的長時間程式一定會被保留並持續推進。(Apple 官方休眠說明)

先做三件事：

1. 複製或封存最後一份日誌。 不要先清理暫存目錄，也不要先刪除鎖檔。
2. 保留工作區現況。 記下 Git 差異、檔案修改時間、產物目錄與測試報告。
3. 從另一條連線驗證。 例如使用 SSH、另一個遠端桌面工作階段，或直接在本機終端機檢查進程。

DeepSeek Harness 的文件可能描述背景、會話或驗證能力，但截至 2026 年 8 月 19 日，沒有承諾所有任務都能跨越休眠、使用者退出、進程退出或系統重啟後自動續跑。實際狀態仍要依版本、啟動方式、子進程與工作區結果核對。(DeepSeek Harness README)

Mac 合蓋後 DeepSeek Harness 還會繼續運行嗎？
不能直接假設會。Mac 休眠會改變處理器、磁碟與網路活動條件；即使系統之後成功喚醒，Harness 的 API 請求、串流回應、子程式或檔案寫入也可能停在中間狀態。Apple 提供的「Wake for network access」主要是讓 Mac 因網路資源存取而喚醒，不是 DeepSeek Harness 任務續跑的保證。(Apple 電源管理說明)

場景很常見：你關閉瀏覽器、VPN 短暫斷線，或遠端桌面畫面消失；重新連線後 Web UI 顯示空白，甚至看不到原來的任務。

這時不要先按「重新提交」。先在 Mac 上檢查：

ps aux | grep -i 'deepseek\|harness'
pgrep -af 'deepseek|harness'

若你知道日誌路徑，再看最後變更時間：

tail -n 80 /path/to/task.log
stat -f '%Sm %N' /path/to/task.log

你要找的是三種信號：

• Harness 主進程仍存在。
• 日誌有新的受控事件，而不是只有 Web UI 的心跳。
• 工作區或產物有能對應到任務階段的變化。

只要三項都成立，頁面斷線比較像觀測層故障。可以重新建立 UI 連線，但不要另開一份相同任務。

如果進程存在，卻只有重複錯誤、沒有新檔案、沒有新 API 事件，應暫停等待。進程「活著」不代表任務仍在推進。

Web UI 斷開是不是代表 Agent 任務已經停止？
不是。Web UI 只是其中一個觀測入口。你必須從 Mac 可達性、進程、日誌與工作區副作用交叉確認。反過來，頁面仍顯示「執行中」也不能證明 Agent 沒有死亡；會話記錄可能只是最後一次成功寫入的畫面。

提醒： 會話還在，不等於任務還活著；頁面不在，也不等於任務已停止。恢復決策必須以進程與產物證據為準。

若最後一條任務事件的時間，接近 Mac 進入休眠的時間，先記錄電源狀態：

pmset -g
pmset -g assertions

Apple 文件指出，pmset -g assertions 可用來查看哪些程式正在建立防止系統休眠的電源要求。若沒有相關 assertion，不應把「程式正在工作」解讀成「Mac 一定不會休眠」。(Apple 開發者電源效率文件)

核驗順序如下：

第一步：對照最後事件時間。
把 Harness 日誌、系統休眠紀錄與最後一次產物修改時間放在一起看。單一時間點只能建立關聯，不能證明任務一定因休眠而中斷。

第二步：確認喚醒後的網路。
重新測試 API、DNS、SSH 與遠端儲存。如果任務在休眠前等待網路回應，喚醒後可能已經逾時，但子進程仍保留。

第三步：檢查工作區。
查看未提交差異、暫存檔、鎖檔與測試輸出。部分檔案已寫入時，不能直接從頭執行同一個寫入或發布動作。

第四步：建立停止條件。
若進程不存在、日誌在休眠前停止、產物缺少校驗資訊，或工作區同時出現互相矛盾的狀態，就停止自動續跑。

Mac 唤醒後怎麼判斷原來的任務能不能繼續？
至少要同時滿足四項：原進程仍在或有明確可恢復 checkpoint；最後事件可與工作區變化對應；外部副作用可確認；下一步不會重複提交、發布或覆寫未知結果。缺少任何一項，就先建立可信基線，再決定重建。

關閉瀏覽器、斷開遠端連線、退出 macOS 使用者、重新啟動系統，是四個不同的操作。

• 關閉瀏覽器： 通常只影響觀測入口。
• 斷開遠端連線： 可能只中斷終端機或圖形工作階段，也可能連帶結束沒有脫離會話的前景程式。
• 退出 macOS 使用者： 使用者級 LaunchAgent、Keychain、圖形權限與環境變數可能改變。
• 系統重啟： 進程必定需要重新建立；原會話是否可用，要看 Harness 的持久化設計與啟動方式。

檢查目前使用者與工作目錄：

whoami
pwd
launchctl print gui/$(id -u)

如果任務依賴登入後才能取得的 Keychain 憑據、圖形化權限或使用者目錄，重新登入後不要直接沿用原任務的認證判斷。先以同一使用者驗證必要憑據，再查看工作區與進程。

遠端 Mac 重啟後 DeepSeek Harness 會自動恢復會話嗎？
不能以會話列表作為答案。你要分開確認「會話資料是否存在」與「任務執行器是否重新啟動」。若只有歷史紀錄，沒有新進程、心跳、日誌或產物，應視為未恢復。需要開機自啟時，可另行閱讀 DeepSeek Harness launchd 開機自啟設定，但自啟只解決啟動，不會自動替未知狀態作出正確的續跑決策。

這是最容易誤判的情況。你看得到原來的任務名稱、對話紀錄或最後一段輸出，但真正的主進程、子進程、測試執行器或建置工具早已退出。

先查：

pgrep -af 'deepseek|harness|node|python'
find . -maxdepth 3 -type f \( -name '*.lock' -o -name '*.pid' \) -print
git status --short
git diff --stat

再把外部副作用列出來：

• 是否已建立發布包、部署檔或報告。
• 是否已寫入資料庫、遠端儲存或佈署服務。
• 是否存在半成品與完整產物同時出現。
• 是否有鎖檔殘留，但沒有對應進程。

依任務幂等性分三類：

可以重跑： 純讀取、可覆寫的建置，且產物有明確版本。
需要恢復： 已完成部分步驟，具備 checkpoint、事件序號或可驗證中間產物。
需要人工接管： 可能重複發布、付款、刪除、推送或修改外部系統。

若你遇到的是工具反覆重新執行，而不是休眠造成的中斷，應先處理重試條件，不要把兩種問題混在一起。

當檔案已部分修改、測試結果缺失，或最後一個指令究竟有沒有完成無法判定時，停止讓 Agent 自己猜測上一階段是否完成。

使用以下可勾選清單：

• [ ] 封存最後一份 Harness 日誌與系統電源紀錄。
• [ ] 記錄目前使用者、工作目錄、Git 分支與未提交差異。
• [ ] 確認主進程、子進程、鎖檔及其父子關係。
• [ ] 對照產物檔案大小、修改時間、雜湊或版本標記。
• [ ] 確認外部 API、遠端儲存、部署服務是否已產生副作用。
• [ ] 以最小測試驗證目前工作區，而不是直接跑完整任務。
• [ ] 為下一步指定明確起點：續跑、重建或人工審批。
• [ ] 將未知完成狀態寫入事件紀錄，禁止當成成功。

恢復標準不是「畫面恢復正常」，而是你能回答三個問題：上一個已確認完成的階段是哪一個？目前工作區與產物是否一致？下一次執行是否會重複造成不可逆副作用？

如何避免長期 Agent 任務被系統休眠打斷？

先不要只依賴「Wake for network access」。Apple 將這項功能定位為讓 Mac 在存取共享資源時喚醒；它不是維持所有背景程式執行的機制。(Apple 電源管理說明)

長期任務至少要有：

• 明確的電源策略，並記錄 pmset 設定。
• 可從另一條連線查詢進程與日誌。
• 進程退出後的重啟責任，例如 LaunchAgent 或外部監控。
• 任務 checkpoint、幂等設計與產物校驗。
• 休眠、斷線、進程退出、重啟四種驗收案例。

Apple 的開發者文件也指出，程式可以透過電源活動宣告長時間工作，並用 pmset -g assertions 檢查防止休眠的要求；但是否採用、能否覆蓋所有休眠情境，仍取決於程式本身與作業系統電源行為。(Apple 開發者電源效率文件)

最後，用四項中斷測試評估現有 Mac：網路斷線後能否辨認進程狀態、休眠喚醒後是否保留可信工作區、進程退出後是否能安全重建、重啟後是否有可驗證的恢復流程。若你的 DeepSeek Harness 任務只允許短暫中斷重跑，本地 Mac 仍可使用；若任務必須跨工作時段持續運行，且需要穩定的進程責任、重啟驗收與遠端可達性，讓任務留在個人 Mac 上會把休眠、登入與桌面權限風險集中到同一台機器。這時可評估 KVMNODE 的雲端 Mac 方案，先用上述四項測試驗收，再決定是否把長期 DeepSeek Harness 工作遷移到獨立在線環境。