Hermes Agent 如何按時主動找你？拆解自動化調度與定時任務機制
摘要
Hermes Agent 能按時主動找你，不是因為它一直守在聊天窗口裏等待，而是因為自動任務把"什麼時候執行""執行什麼""結果發到哪裏"三件事保存成了一份可重複調度的配置。到點後，調度器發起一次獨立執行——它不是把舊對話機械重放，而是按任務説明重新做一遍工作，再按通知設置投遞結果。在 LightVela 上，一份自動任務的配置項是：名稱、執行時間（固定星期、固定間隔、單次執行三選一）、任務説明、生效時間段、通知方式。需要澄清一個常見誤傳：自動任務的配置裏並沒有"鎖定某個模型"這一項，因此"切換模型後要逐個同步自動任務的模型"並不成立。寫好自動任務的關鍵在任務説明：因為執行時沒有人在旁邊追問，提示詞必須自帶目標、邊界和輸出格式。
引子："主動"並不等於一直盯着你
"每天早上給我一份新聞摘要"聽起來是一句普通指令，但它和"現在給我一份新聞摘要"有本質區別。
後者是一次對話：你在場，可以隨時追問、糾正、補充。前者是一份要在你不在場時執行的工作：沒人確認它理解得對不對，沒人在結果不合預期時當場喊停，也沒人告訴它"發到哪裏我才看得到"。
所以"主動"這件事的真正難點不是"定時觸發"這個技術動作——那是最簡單的部分。難點在於：把一次有人在場的對話，改寫成一份無人在場也能正確完成的工作説明。 這篇文章講清楚這份説明由什麼構成，以及怎麼寫才靠得住。
一、一份自動任務包含什麼
在 LightVela 上創建自動任務時，需要填寫的配置項如下。
| 配置項 | 它回答的問題 | 説明 |
|---|---|---|
| 名稱 | 這份任務叫什麼？ | 用於在任務列表中識別，建議寫成可辨認的動作，而不是"任務 1" |
| 執行時間 | 什麼時候運行？ | 固定星期、固定間隔、單次執行，三者選一 |
| 任務説明 | 要完成什麼？ | 提示詞，供 Agent 執行時依據 |
| 生效時間段 | 在哪段時間內有效？ | 限定任務的有效運行時段，留空代表全天候持續運行 |
| 通知方式 | 結果發到哪裏？ | 可選開關，勾選接收執行通知的渠道 |
這裏需要明確一件常被誤傳的事：配置項裏沒有"模型"這一欄。 自動任務不會鎖定某個特定模型，因此網上流傳的"切換模型後必須逐個檢查並同步自動任務所用模型"這種説法，在這套產品形態下並不成立。切換模型後值得複查的是任務輸出的質量，而不是去找一個不存在的字段。關於模型與 Agent 的分層關係，可參考《Hermes Agent 的"大腦"可以替換嗎？模型層與 Agent 層如何分工》。
另外，執行時間是"固定星期 / 固定間隔 / 單次執行"三選一，而不是任意 Cron 表達式。理解這一點能避免按 Cron 思維去設計過於複雜的調度，然後發現填不進去。
二、三種執行時間該怎麼選
三種模式對應的是三類不同需求，選錯會導致任務行為和預期不符。
固定星期：適合與人的作息或工作週期綁定的任務。例如每週一早上彙總上週進展、每週日提醒澆花。它的特點是錨定在具體時點，適合"我希望在這個時間看到它"的場景。
固定間隔：適合與時點無關、只關心頻率的任務。例如每隔幾小時檢查一次某個信息源。它的特點是從上次執行開始計時，適合"我希望它保持這個節奏"的場景。
單次執行：適合一次性事項。例如某個特定日期提醒你辦一件事。它執行完就結束，不需要事後手動關閉。
選擇時的一個判斷依據：你的需求描述裏有沒有"幾點"。 有具體時點的用固定星期，只有頻率的用固定間隔，只發生一次的用單次執行。
三、生效時間段解決什麼問題
生效時間段容易被忽略，但它解決的是一類真實困擾：你希望任務保持某個頻率，但不希望它在某些時段打擾你。
典型場景是間隔式任務。如果你設置"每隔兩小時檢查一次"，在沒有生效時間段限制的情況下，它會全天候運行——包括凌晨。加上生效時間段後，任務只在你指定的時段內運行。
留空代表全天候持續運行。所以如果你發現任務在不該運行的時間執行了，先檢查這一項是不是留空了。
四、到點之後實際發生了什麼
這是最容易產生誤解的環節。很多人以為定時任務是"把你當初那句話再發一遍給 Agent"，這個理解會導致提示詞寫得過於依賴上下文。
實際過程是：調度器到達目標時間後，觸發一次獨立的 Agent 執行。這次執行會依據任務説明重新完成工作，而不是回放當初創建任務時的那段對話。
這個區別帶來一個重要推論：任務説明必須自帶上下文。 你在創建任務時腦子裏的背景、你和 Agent 之前聊過的細節，如果沒有寫進任務説明或已沉澱進長期記憶，執行時就不一定會被用上。
舉個對比：
- 依賴上下文的寫法："像剛才那樣幫我整理一份。" —— 執行時"剛才"已經不存在了。
- 自帶上下文的寫法："彙總過去 24 小時內未讀郵件，按發件人分組，每組不超過三條，只保留需要我回復的；輸出為條目列表，每條不超過一行。"
後者能在無人在場時穩定執行，因為它把目標、範圍、篩選標準、輸出格式都寫進去了。
五、怎麼寫一份靠得住的任務説明
結合上面的機制，一份可靠的任務説明通常包含四部分。
第一，明確的目標動作。 説清要"做什麼"，而不是"關注一下某件事"。"關注"無法判斷是否完成，"彙總並列出"可以。
第二，明確的範圍邊界。 時間範圍（過去 24 小時）、數量上限（每組不超過三條）、篩選條件（只保留需要我回復的）。沒有邊界的任務在不同時間可能產出差異極大的結果。
第三，明確的輸出格式。 是列表還是段落、要不要分組、每條多長。因為你不在場，無法當場説"太長了，短一點"。
第四，明確的例外處理。 如果沒有符合條件的內容，應該發一條"今日無待處理事項"，還是什麼都不發？這一點不寫清楚，你會分不清"任務沒執行"和"任務執行了但沒內容"。
第四點常被忽略，但它直接影響你對任務健康狀態的判斷。
六、上線一份自動任務的推薦順序
不要把"創建任務"當成一步完成的操作。推薦按下面的順序上線，能在早期發現大部分問題。
- 先在聊天裏手動驗證一次。 把你準備寫進任務説明的提示詞直接發給 Agent，看輸出是否符合預期。這一步能在沒有調度干擾的情況下先把提示詞調好。
- 根據手動驗證的結果修訂提示詞。 常見問題是輸出太長、範圍太寬、格式不穩定，這些都在這一步解決。
- 創建任務並設置執行時間。 按第二節的判斷依據選擇模式。
- 確認通知方式指向你會看到的渠道。 結果發到一個你不看的地方，等於沒執行。
- 必要時設置生效時間段。 尤其是間隔式任務，避免深夜打擾。
- 等一次真實執行，然後查看運行記錄。 這是關鍵一步——不要只確認"任務已創建"就認為完成了。 創建成功只説明配置保存了，不代表執行結果符合預期。
- 根據首次執行結果再調一輪提示詞。 真實執行環境與手動測試可能有差異，這一輪修訂往往能顯著提升穩定性。
產品側支持在任務列表中查看任務詳情、編輯修改、暫停運行或刪除任務，所以第 7 步的調整成本很低。如果一份任務暫時不需要，優先用暫停而不是刪除，配置可以留着後續複用。
七、常見問題與排查方向
| 現象 | 更可能的原因 | 建議動作 |
|---|---|---|
| 任務到點沒反應 | 任務被暫停，或當前時間不在生效時間段內 | 檢查任務狀態與生效時間段設置 |
| 執行了但沒收到結果 | 通知方式未勾選，或投遞渠道不是你在看的那個 | 檢查通知方式配置 |
| 結果內容忽長忽短、格式不穩 | 任務説明缺少範圍邊界與輸出格式 | 按第五節補齊四要素 |
| 結果和手動測試時差別很大 | 任務説明依賴了創建時的對話上下文 | 改成自帶上下文的寫法 |
| 分不清是沒執行還是沒內容 | 任務説明沒寫例外處理 | 補充"無內容時也發一條説明" |
| 深夜被打擾 | 間隔式任務未設置生效時間段 | 設置生效時間段 |
排查時的一個通用原則：先區分"沒執行"和"執行了但結果不對"。 前者去查任務狀態、生效時間段、通知配置；後者去查任務説明本身。這兩類問題的處理路徑完全不同，混在一起查會浪費時間。
八、LightVela 的做法：讓主動工作可配置、可複查
Hermes 在機制上支持讓 Agent 按計劃工作，但使用者需要自己維護運行環境與調度可靠性。LightVela 的方向是把這件事做成可配置、可複查的產品能力：
- 模板降低起步成本：不清楚該配什麼任務時，可以從現成模板中選用，再按自己的需求修改。
- 任務生命週期可管理：任務創建後可查看詳情、編輯、暫停或刪除，不必為了改一個條件而重建。
- 投遞渠道可選：通知方式作為可選開關，讓結果落到你真正會看到的渠道。
- 與其他能力解耦：自動任務與模型、技能、雲存儲各自獨立配置，切換模型不會變更自動化設置。
- 異常可追溯：執行異常時可結合診斷中心的近期日誌判斷問題所在。
小結
- 自動任務的本質是把"何時執行 / 執行什麼 / 發到哪裏"保存成一份可重複調度的配置。
- 配置項為：名稱、執行時間（固定星期 / 固定間隔 / 單次執行）、任務説明、生效時間段、通知方式。
- 配置裏沒有"模型"這一項，"換模型要同步自動任務模型"是誤傳；執行時間也不是任意 Cron 表達式。
- 到點觸發的是一次獨立執行，不是回放舊對話，所以任務説明必須自帶上下文。
- 可靠的任務説明包含四部分：目標動作、範圍邊界、輸出格式、例外處理。
- 上線順序的關鍵是最後一步：等一次真實執行並查看運行記錄，而不是隻確認任務已創建。