DeepSeek Harness 自動化：設定與驗證任務

提醒準時送達，只完成了自動化任務的前半段；提醒要求模型做的工作，是另一件需要確認的事。DeepSeek Harness 提供了投遞記錄和關聯對話，便於分別檢查這兩個結果。

在 2026 年 10 月 3 日釋出的 dsh-v0.2.1-alpha.1 中，Automation 已成為 Web 模式的內建功能。本文依據該版本的排程指南，給出適合在自己環境中執行的驗收流程。這裡沒有可靠性實測資料，也不承諾電腦關機後任務仍能執行。

寫提醒之前，先確認模式

配置模型提供方，並選擇 Standard、Creator 或 PTC 模式。這些預設提供提醒工具；Minimal 模式不提供，受委派的子智慧體也不能使用。因此，請求無法建立計劃時，先檢查模式是否合適。

從側邊欄進入 Automation tasks，可以檢視不同對話中的任務，無需逐一開啟原對話。點選 New 會開啟新會話，並在輸入框中預填建立請求。傳送前仍需檢查草稿。

第一次試驗應選擇無害、結果清楚的任務。讓模型回覆一份固定的短清單，比一上來要求搜尋多個網站並撰寫報告，更容易判斷投遞和執行分別是否成功。基本機制確認後，再加入外部依賴。

可以傳送以下請求：

兩分鐘後，在此對話中提醒我檢查示例報告。提醒中的指令要求你回覆三項檢查：來源日期、缺失行、總數一致性。請建立一次性提醒，然後顯示儲存的任務名稱和計劃時間。

這是一次性延遲，不是週期任務。開啟任務詳情，確認儲存的規則與要求一致，並在等待期間保持 Host（宿主程序）執行。提醒到達後，檢查對話中是否出現所要求的三項內容，再開啟 Records 檢視投遞記錄。

儲存的記錄意味著提醒已持久寫入對話收件箱，不意味著模型已經完成回覆。如果記錄存在而結果缺失，應先檢查對話和模型提供方的狀態。直接重建計劃，可能為同一個需求留下多個任務。

一次性任務投遞後會變為非活動狀態，可以透過 All 或 Inactive 找到。它從只顯示活動提醒的檢視裡消失，不代表任務或歷史記錄已被刪除。

“每隔 24 小時”和“每天本地時間 09:00”表達的需求不同。前者按固定間隔計算，後者跟隨指定時區的鐘點。應按實際意圖選擇，而不是把它們當成完全等價的說法。

例如：

每天 Asia/Shanghai 時區 09:00，在此對話中提醒我檢查示例報告。任務名稱為 Daily report check。使用每日本地時間規則，不要建立一次性提醒，也不要使用固定 24 小時間隔。建立後顯示儲存的規則和下次計劃時間。

在 Rules 中核對頻率、時間和儲存的 IANA 時區。下次觸發時間會按裝置時區顯示，因此裝置時區與規則時區不同時，兩個鐘點值可能不一樣。要比較它們是否對應同一預期時刻，而不是要求顯示文字相同。

使用實行夏令時的時區時，還應留意時間跳變。該版本文件規定：每日規則遇到不存在的本地時間會跳過；遇到重複出現的本地時間，只取較早的一次。固定間隔按實際經過的時間計算，不遵循這套本地鐘點規則。

選擇活動任務，開啟 Rules，即可編輯名稱、指令和時間。修改在點選 Save changes 之前只保留在本地草稿中。儲存成功後，任務 ID、原始對話和已有投遞記錄都會保留。

更改間隔時，下一次觸發從宿主接受儲存的時間起重新計算。如果提交的是規範化後等價的規則，則不會重啟計時器。因此，只修改指令，不應被當作重新建立了一份計劃。

儲存後重新開啟或重新整理詳情，確認服務端實際儲存的值。如果無法確定修改是否成功，先檢查現有任務再重試。舊介面尚未重新整理，與寫入失敗，是兩種情況。非活動任務只讀，不能指望透過編輯已完成的一次性任務卡片，把它改成周期任務。

排程器執行在宿主中。關閉瀏覽器標籤頁，不等於停止宿主程序。試驗前先確定自己的安裝由哪個程序或桌面應用負責執行。

建立一個僅供試驗的一次性提醒，在到期前停止宿主，過期後再啟動。按照文件，重啟時會檢查已儲存任務，並補發逾期的一次性提醒。對於週期提醒，只處理最近一次錯過的觸發，不會逐次補齊停機期間的所有間隔。

不要用會修改外部狀態的重要任務來做這個試驗。文件沒有保證“恰好投遞一次”：如果訊息已寫入收件箱，但儲存任務記錄時出錯，可能出現訊息已送達卻未被記錄、隨後再次投遞的情況。報告草稿比付款、傳送訊息或不可逆檔案操作更適合做測試。

每次試驗可以保留一張簡表，避免把排程成功誤判成工作完成。

記錄會受配置的歷史保留期限和數量限制。缺失的舊記錄不能靠當前指令反推恢復。它們能證明已保留條目的投遞情況，不能當作完整的模型執行審計日誌。

在詳情中刪除試驗任務並確認後，未來投遞會停止，該任務的投遞歷史也會移除。不過，已經排入原對話的訊息不會被撤回。如果任務剛好已經到期，還需要檢查原對話中的後續工作。

該版本不支援暫停任務，也不支援每次執行都建立新會話。設計流程時，應圍繞原始對話和現有編輯功能展開。如果需要持續線上、具備完整執行跟蹤的服務，應另外確認對應設施，不能僅憑提醒功能推斷它們已經具備。

安裝和遷移背景見 Harness 0.2.1 更新解讀。先用一個可觀察的提醒弄清計時、投遞和執行各自如何體現，再把真實工作逐步加進去。