症狀： DeepSeek Harness 持續顯示執行、請求反覆失敗，卻看不到新結果。
最快解法： 先找「重試已安排」與「下一次重試開始」兩組事件；沒有新的開始證據，或等待時間已不可控，就停止任務、保存現場，再分辨模型、網路、配置或工具問題。
這篇適合三類人：本地使用者想確認畫面上的等待是否仍有進度；遠端 Agent 維運人員需要替無人值守的後台任務設定停止界線；平台工程師則可用它建立重試紀錄、超時與上游可用性的聯合診斷流程。
先判斷：畫面等待是否真的代表 LLM retry
最容易誤判的案例是：頁面一直顯示「執行中」，但事件紀錄沒有新的模型請求，遠端工作目錄也沒有檔案變化。此時不要先增加重試次數，更不要反覆刷新 Web UI。載入動畫只能證明介面尚未收到結束狀態，不能證明任務仍在推進。
先做三項核驗：
- 查看會話事件，確認是否出現重試安排事件。
- 尋找與該安排相對應的重試開始事件，並核對時間順序。
- 檢查進程、標準輸出、工作目錄與子工具是否仍有變化。
如果只有「等待中」或「已安排」而沒有下一次請求開始，問題可能在排程器、進程中斷或連線恢復，不一定是 DeepSeek API 本身。反過來，如果模型請求已完成，下一個事件卻是工具呼叫，那麼診斷方向應轉到審批、Hook、Bash 或外部工具。
提醒： 斷開遠端連線不等於任務停止，但連線仍在也不等於任務有進度。你需要進程與事件的雙重證據，不能只看瀏覽器狀態。
第一步：重試已安排，卻沒有下一次請求
觀察信號
你可能看到一次模型失敗，接著介面長時間沒有新請求；或者事件中有「安排重試」，但找不到對應的「重試開始」。這兩者不能混為一談。
核驗動作
保存以下現場資料：
- 任務識別碼、會話識別碼與目前分支。
- Harness 版本、模型名稱、Provider 與 Base URL。
- 最後一筆模型事件及其時間。
- 重試安排事件、重試開始事件是否成對出現。
- 遠端進程列表、工作目錄與最近輸出。
- 網路斷線、系統休眠、重新啟動或權限變更紀錄。
DeepSeek API 的請求在等待推理時可能持續傳回空行，串流請求則可能收到 SSE keep-alive 註解；官方文件也說明，若請求在 10 分鐘內尚未開始推理，伺服器會關閉連線。這代表「連線尚未關閉」不能被當成「模型一定仍在工作」。(api-docs.deepseek.com)
停止條件與恢復標準
符合以下任一條件，就不要無限等待：
- 沒有新的重試開始事件。
- 進程已不存在或父進程已退出。
- 工作目錄沒有任何可解釋的狀態變化。
- 超時邊界已經超過你的任務容忍度。
- 任務依賴的遠端環境身份已經改變。
若進程仍在、事件持續增加，且工作目錄有穩定變化，可繼續觀察。若只是連線中斷，但任務狀態無法確認，先保存現場，再用新驗證任務確認環境，不要直接強行接續舊分支。
第二步：每次重試都出現同類模型錯誤
觀察信號
同一請求每次都在模型入口失敗，錯誤文字或結構高度一致。這通常更接近確定性配置問題，而不是短暫的上游波動。
核驗動作
依照以下順序檢查：
- 模型名稱是否仍在目前 DeepSeek API 文件列出的可用清單內。
- API Key 是否屬於正確帳戶，且未被撤銷或放錯環境變數。
- Base URL 是否指向你預期的介面。
- Provider 是否在 Harness 配置中被覆寫。
- 請求格式、工具欄位、JSON Schema 與
max_tokens是否符合目前介面要求。 - 用最小文字請求測試，不要一開始就帶入完整會話與全部工具。
目前官方建立對話請求文件列出的模型包含 deepseek-v4-flash 與 deepseek-v4-pro；舊模型名稱的相容安排及棄用時間，應以目前配置文件與變更紀錄為準，不要只依賴舊範例。(api-docs.deepseek.com)
DeepSeek API 的認證使用 Bearer API Key。若你改了 Key 卻仍連到錯誤的 Base URL，增加 LLM retry 只會重複同一個錯誤。(api-docs.deepseek.com)
停止條件與恢復標準
已確認模型、憑據、Base URL 或 Provider 配置錯誤時，立即停止重試。修正後先送出最小文字請求，確認取得正常回應，再逐步加入：
- 原始系統提示；
- 歷史會話；
- 串流輸出；
- 單一工具；
- 完整工具集合。
恢復標準不是「頁面不再轉圈」，而是最小請求成功、會話事件完整寫入，並能在相同環境重現一次成功的模型鏈路。
用兩組證據區分等待、錯誤與工具阻塞
下表不要用來猜測 Harness 內部實作，而是用來決定下一個核驗方向。
| 你看到的現象 | 應找的證據 | 優先排查方向 | 暫停重試的理由 |
|---|---|---|---|
| 頁面持續執行，沒有新事件 | 進程、事件時間、工作目錄 | 排程器或進程中斷 | 無推進證據 |
| 有重試安排，沒有重試開始 | 成對事件是否完整 | 等待被取消、程序退出、連線恢復 | 下一次請求未真正啟動 |
| 每次都是同類模型錯誤 | 錯誤原文、模型與 Provider | 憑據、Base URL、模型路由 | 確定性錯誤不會靠多試解決 |
| 模型回應成功，工具沒有完成 | tool call、審批、Hook、Bash 輸出 | 工具執行管線 | LLM 已經完成 |
| 進程消失或工作目錄改變 | 進程狀態、重啟紀錄、路徑 | 遠端環境身份 | 舊任務可能已失去執行條件 |
第三步：模型完成後，改查工具執行管線
DeepSeek API 的回應可能以 tool_calls 結束，而不是直接產生最終文字；這表示模型階段完成，不表示整個 Agent 任務完成。官方文件也指出，工具目前以函式工具形式傳入，並要求呼叫端驗證模型產生的參數。(api-docs.deepseek.com)
觀察信號
- 最後一筆模型回應已有完成狀態。
- 事件顯示工具呼叫，但沒有工具返回事件。
- 任務停在審批畫面、Hook 或 Bash。
- 外部工具等待檔案鎖、輸入、網路回應或人工確認。
核驗動作
先只保留一個無副作用的最小工具，確認它能：
- 被模型正確選取；
- 收到可解析的參數；
- 在限定工作目錄內執行；
- 回傳明確的成功或失敗結果；
- 將工具結果寫回會話事件。
不要為了試錯而一次放開全部權限。工具具備檔案刪除、外部寫入或遠端命令能力時，重試可能放大副作用。先用唯讀命令與固定路徑驗證，再逐項恢復權限。
停止條件與恢復標準
工具進程無輸出、等待人工審批、持續卡在外部服務，或工具返回格式無法解析時，應停止模型重試，保留工具輸入與輸出。只有在最小工具呼叫成功返回後，才算恢復工具鏈路。
經驗： 「模型成功、任務失敗」是兩個不同故障。把工具阻塞記成模型重試，會令你錯過真正需要修復的權限、Hook 或工作目錄問題。
第四步：檢查上游限流與遠端環境
DeepSeek API 文件指出，並發限制按帳戶計算，而不是按 API Key 分開計算；超過限制時會返回 HTTP 429。目前文件列出的並發上限為 V4-Pro 500、V4-Flash 2500，如你的帳戶或版本文件不同，應以當前官方資料為準。(api-docs.deepseek.com)
| 故障類型 | 可恢復的瞬時問題 | 會持續重現的環境問題 |
|---|---|---|
| API | 短暫 429、連線抖動、上游延遲 | 每次請求都被拒絕、帳戶級並發長期超限 |
| 遠端主機 | 短暫斷線但進程仍在 | 主機重啟、系統休眠、進程已退出 |
| 工作區 | 暫時無輸出但事件仍增加 | 工作目錄被刪除、路徑或掛載身份改變 |
| 憑據 | 單次讀取失敗 | Key 錯誤、環境變數未載入、Provider 被覆寫 |
核驗時，先看請求是否抵達 API，再看遠端進程是否存活。若 API 回應正常但工具沒有返回，回到工具路徑；若 API 持續 429，檢查帳戶級併發與任務排程，不要只換另一把同帳戶 API Key。
如果主機已重啟、工作目錄變更，或新的環境身份無法對應舊會話，建立新的最小驗證任務通常比強行續跑更安全。新任務需重新確認 Key、模型、路徑與工具權限。
最後用清單決定：繼續等、取消重跑，還是遷移
可勾選的停止與恢復清單
- [ ] 已找到最後一次模型請求的時間與結果。
- [ ] 已確認重試安排事件與重試開始事件是否成對存在。
- [ ] 已檢查進程仍在執行，且不是只剩介面載入狀態。
- [ ] 已保存會話事件、錯誤原文、版本、模型與配置。
- [ ] 已分辨模型錯誤與工具執行錯誤。
- [ ] 已用最小文字請求驗證 DeepSeek API 鏈路。
- [ ] 已用單一唯讀工具驗證工具回傳。
- [ ] 已排除系統休眠、重啟、路徑變更與權限改動。
- [ ] 若環境身份改變，已建立新驗證任務，而非續跑舊任務。
- [ ] 已記錄最小重現步驟，方便後續升級處理。
判斷可以很直接：
- 有新事件、有存活進程、有工作區變化： 繼續等待，但設定明確觀察界線。
- 沒有新重試開始證據，或已超出可接受等待： 取消任務並保存現場。
- 配置錯誤或環境身份已改變： 修正配置或遷移環境後，重新建立最小任務。
- 模型完成、工具阻塞： 停止 LLM retry，單獨修復工具管線。
- 無法取得任何可靠證據： 不要把「仍在等待」當作成功，直接進入現場保存與升級流程。
若你的問題只在斷線、休眠或長時間執行時出現，與其重裝 DeepSeek Harness，不如先檢查DeepSeek Harness 後台任務驗收需要哪些可交付證據，再確認遠端 Mac 是否具備穩定的進程、工作目錄與重啟恢復條件。對需要長時間執行的工作，也可比較Mac mini 雲端算力方案，把本地電腦休眠、網路中斷與權限漂移從排障範圍中移除。
相較於在本地反覆等待，現有方案常見的缺點是螢幕關閉後進程狀態難以確認、家用網路斷線會切斷觀察通道，重新啟動後工作目錄與會話又未必一致。若你只是需要臨時算力、遠端測試環境或無人值守的後台任務，租用 MACCOME 的 Mac 環境會更容易保留進程與驗收現場；但若你需要長期固定重負載，或必須直接接觸特定實體介面，自購 Mac 仍可能更合適。