Hermes Agent 社群追查重設後的任務通知缺口，背景程序中斷可能被標為已讀

Hermes Agent 社群於 10 月 12 日提出背景任務生命週期回報：Telegram 中的長時間工作在所屬代理關閉後停止，使用者卻未收到可採取行動的中斷通知。回報者後續從紀錄確認，事件走的是工作階段重設清理路徑；紀錄無法區分入口是 /new、/reset 或同一處理器的其他呼叫，因此不能將程序終止直接認定為意外錯殺。事件與後續追查

另一位參與者以當時主分支的真實程序登錄與代理清理函式進行局部測試，指出 kill_process 使用 consume_output=True，會把遭終止程序的完成結果標為已消費，使未讀完成清單與通知閘門略過它。對照中，自行結束的程序仍可通知；改為 False 後，遭終止結果也重新符合通知條件。不過，該測試未完整驅動 Telegram 與工作階段資料庫，重設後的訊息歸屬仍是另一項待驗證問題。社群測試

這與官方文件描述的背景通知契約有直接關係：notify_on_complete=true 應在程序完成後啟動新的代理回合，讓代理回報結果；一般通知模式則可送出完成或失敗狀態。工程上，啟動工作、接收退出事件及將結果送回對話，是三個需要分別驗證的環節。訊息閘道文件

官方執行環境文件也說明，執行中的程序檢查點與完成輸出分開保存，結果讀取受原始工作階段或其壓縮續接的擁有權限制。這代表跨對話接手不能只保留程序識別碼，還須處理結果歸屬與通知路由。工具執行環境文件

對部署長時間研究或批次工作的團隊，此案提醒：工作自行寫入的 running 狀態不足以證明程序仍存活。後續應觀察維護者是否加入重設期間的端到端測試，涵蓋中斷通知、持續執行工作的結果交付，以及避免重複執行的恢復流程。截至查核時，議題仍開啟並等待維護者決策，尚無連結的修補 PR；現有證據支持進一步追查，不能推論所有部署都受影響。議題狀態