Hermes Agent 如何按時主動找你？拆解自動化調度與定時任務機制

摘要

執行時間支持單次、定期和固定間隔。定期可按天、周或月設置，間隔可按分鐘、小時或天設置；有效時間段約束任務可運行的時段。以表單提供的選項為準，不需要輸入任意 Cron 表達式。 Agent 定時任務可以保留創建時的模型綁定。更改主模型時，若彈出任務更新提示，可選擇同步受影響任務、只切換聊天默認模型或取消；綁定無法確認的任務不會被擅自更新。同步後檢查操作結果，並核驗一次實際執行；通知和腳本任務不調用模型。

---

引子："主動"並不等於一直盯着你

"每天早上給我一份新聞摘要"聽起來是一句普通指令，但它和"現在給我一份新聞摘要"有本質區別。

後者是一次對話：你在場，可以隨時追問、糾正、補充。前者是一份要在你不在場時執行的工作：沒人確認它理解得對不對，沒人在結果不合預期時當場喊停，也沒人告訴它"發到哪裏我才看得到"。

所以"主動"這件事的真正難點不是"定時觸發"這個技術動作——那是最簡單的部分。難點在於：把一次有人在場的對話，改寫成一份無人在場也能正確完成的工作説明。 這篇文章講清楚這份説明由什麼構成，以及怎麼寫才靠得住。

---

一、一份定時任務包含什麼

在 LightVela 上創建定時任務時，需要填寫的配置項如下。

Agent 定時任務可以保留創建時的模型綁定。更改主模型時，若彈出任務更新提示，可選擇同步受影響任務、只切換聊天默認模型或取消；綁定無法確認的任務不會被擅自更新。同步後檢查操作結果，並核驗一次實際執行；通知和腳本任務不調用模型。

執行時間支持單次、定期和固定間隔。定期可按天、周或月設置，間隔可按分鐘、小時或天設置；有效時間段約束任務可運行的時段。以表單提供的選項為準，不需要輸入任意 Cron 表達式。

---

二、三種執行時間該怎麼選

三種模式對應的是三類不同需求，選錯會導致任務行為和預期不符。

執行時間支持單次、定期和固定間隔。定期可按天、周或月設置，間隔可按分鐘、小時或天設置；有效時間段約束任務可運行的時段。以表單提供的選項為準，不需要輸入任意 Cron 表達式。

固定間隔：適合與時點無關、只關心頻率的任務。例如每隔幾小時檢查一次某個信息源。它的特點是從上次執行開始計時，適合"我希望它保持這個節奏"的場景。

單次執行：適合一次性事項。例如某個特定日期提醒你辦一件事。它執行完就結束，不需要事後手動關閉。

選擇時的一個判斷依據：你的需求描述裏有沒有"幾點"。 有具體時點的用固定星期，只有頻率的用固定間隔，只發生一次的用單次執行。

---

三、生效時間段解決什麼問題

生效時間段容易被忽略，但它解決的是一類真實困擾：你希望任務保持某個頻率，但不希望它在某些時段打擾你。

典型場景是間隔式任務。如果你設置"每隔兩小時檢查一次"，在沒有生效時間段限制的情況下，它會全天候運行——包括凌晨。加上生效時間段後，任務只在你指定的時段內運行。

留空代表全天候持續運行。所以如果你發現任務在不該運行的時間執行了，先檢查這一項是不是留空了。

---

四、到點之後實際發生了什麼

這是最容易產生誤解的環節。很多人以為定時任務是"把你當初那句話再發一遍給 Agent"，這個理解會導致提示詞寫得過於依賴上下文。

實際過程是：調度器到達目標時間後，觸發一次獨立的 Agent 執行。這次執行會依據任務説明重新完成工作，而不是回放當初創建任務時的那段對話。

這個區別帶來一個重要推論：任務説明必須自帶上下文。 你在創建任務時腦子裏的背景、你和 Agent 之前聊過的細節，如果沒有寫進任務説明或已沉澱進長期記憶，執行時就不一定會被用上。

舉個對比：

• 依賴上下文的寫法："像剛才那樣幫我整理一份。" —— 執行時"剛才"已經不存在了。
• 自帶上下文的寫法："彙總過去 24 小時內未讀郵件，按發件人分組，每組不超過三條，只保留需要我回復的；輸出為條目列表，每條不超過一行。"

後者能在無人在場時穩定執行，因為它把目標、範圍、篩選標準、輸出格式都寫進去了。

---

五、怎麼寫一份靠得住的任務説明

結合上面的機制，一份可靠的任務説明通常包含四部分。

第一，明確的目標動作。 説清要"做什麼"，而不是"關注一下某件事"。"關注"無法判斷是否完成，"彙總並列出"可以。

第二，明確的範圍邊界。 時間範圍（過去 24 小時）、數量上限（每組不超過三條）、篩選條件（只保留需要我回復的）。沒有邊界的任務在不同時間可能產出差異極大的結果。

第三，明確的輸出格式。 是列表還是段落、要不要分組、每條多長。因為你不在場，無法當場説"太長了，短一點"。

第四，明確的例外處理。 如果沒有符合條件的內容，應該發一條"今日無待處理事項"，還是什麼都不發？這一點不寫清楚，你會分不清"任務沒執行"和"任務執行了但沒內容"。

第四點常被忽略，但它直接影響你對任務健康狀態的判斷。

---

六、上線一份定時任務的推薦順序

不要把"創建任務"當成一步完成的操作。推薦按下面的順序上線，能在早期發現大部分問題。

1. 先在聊天裏手動驗證一次。 把你準備寫進任務説明的提示詞直接發給 Agent，看輸出是否符合預期。這一步能在沒有調度干擾的情況下先把提示詞調好。
2. 根據手動驗證的結果修訂提示詞。 常見問題是輸出太長、範圍太寬、格式不穩定，這些都在這一步解決。
3. 創建任務並設置執行時間。 按第二節的判斷依據選擇模式。
4. 確認通知方式指向你會看到的渠道。 結果發到一個你不看的地方，等於沒執行。
5. 必要時設置生效時間段。 尤其是間隔式任務，避免深夜打擾。
6. 等一次真實執行，然後查看運行記錄。 這是關鍵一步——不要只確認"任務已創建"就認為完成了。 創建成功只説明配置保存了，不代表執行結果符合預期。
7. 根據首次執行結果再調一輪提示詞。 真實執行環境與手動測試可能有差異，這一輪修訂往往能顯著提升穩定性。

產品側支持在任務列表中查看任務詳情、編輯修改、暫停運行或刪除任務，所以第 7 步的調整成本很低。如果一份任務暫時不需要，優先用暫停而不是刪除，配置可以留着後續複用。

---

七、常見問題與排查方向

排查時的一個通用原則：先區分"沒執行"和"執行了但結果不對"。 前者去查任務狀態、生效時間段、通知配置；後者去查任務説明本身。這兩類問題的處理路徑完全不同，混在一起查會浪費時間。

---

八、LightVela 的做法：讓主動工作可配置、可複查

Hermes 在機制上支持讓 Agent 按計劃工作，但使用者需要自己維護運行環境與調度可靠性。LightVela 的方向是把這件事做成可配置、可複查的產品能力：

• 模板降低起步成本：不清楚該配什麼任務時，可以從現成模板中選用，再按自己的需求修改。
• 任務生命週期可管理：任務創建後可查看詳情、編輯、暫停或刪除，不必為了改一個條件而重建。
• 投遞渠道可選：通知方式作為可選開關，讓結果落到你真正會看到的渠道。
• Agent 定時任務可以保留創建時的模型綁定。更改主模型時，若彈出任務更新提示，可選擇同步受影響任務、只切換聊天默認模型或取消；綁定無法確認的任務不會被擅自更新。同步後檢查操作結果，並核驗一次實際執行；通知和腳本任務不調用模型。
• 異常可追溯：執行異常時可結合診斷中心的近期日誌判斷問題所在。

---

小結

• 定時任務的本質是把"何時執行 / 執行什麼 / 發到哪裏"保存成一份可重複調度的配置。
• 執行時間支持單次、定期和固定間隔。定期可按天、周或月設置，間隔可按分鐘、小時或天設置；有效時間段約束任務可運行的時段。以表單提供的選項為準，不需要輸入任意 Cron 表達式。
• Agent 定時任務可以保留創建時的模型綁定。更改主模型時，若彈出任務更新提示，可選擇同步受影響任務、只切換聊天默認模型或取消；綁定無法確認的任務不會被擅自更新。同步後檢查操作結果，並核驗一次實際執行；通知和腳本任務不調用模型。
• 到點觸發的是一次獨立執行，不是回放舊對話，所以任務説明必須自帶上下文。
• 可靠的任務説明包含四部分：目標動作、範圍邊界、輸出格式、例外處理。
• 上線順序的關鍵是最後一步：等一次真實執行並查看運行記錄，而不是隻確認任務已創建。