讀完能做到：為排程型 AI 虛擬員工設計耐久狀態、故障恢復與資源感知排程，讓任務不必在中斷後全部重做，也不會因重試而重複寄信或建立訂單。

一個每天成功的 Demo，可能在星期一早上失控

假設採購團隊每天 8:30 啟動一個 AI 虛擬員工：從 Gmail 與 Drive 蒐集供應商報價、查詢 ERP 料號與歷史價格、產生比較表，再交給採購主管核准。

流程執行到一半，ERP API 逾時。系統重新啟動後不知道哪些附件已解析、哪些價格已查詢，只好全部再跑一次。更糟的是，寄信 API 已成功接收請求，但回應在網路中遺失；Agent 以為失敗，再寄一次，供應商便收到兩封內容不同的信。

這不是 Prompt 寫得不夠好，而是系統把長時間任務當成一次模型呼叫。

Gemini Spark 官方將 Task、Schedule 與 Skill 分別定位為「做什麼、何時做、如何做」，也提供任務進度與排程管理介面。[1] 但對企業工作流來說，Schedule 只是觸發器；真正決定任務能否續跑的，是外部保存的狀態、Checkpoint、重試政策與執行紀錄。

先建立正確心智模型：狀態不等於聊天紀錄

對話內容可以幫助 Agent 理解語境，卻不適合作為唯一狀態來源。長 Context 可能被截斷、混入其他任務，也無法可靠回答某個外部動作是否已成功。

企業級狀態應保存「已完成什麼、依據什麼、下一步是什麼」，而不是保存模型沒有輸出的內部思考過程。

Schedule／Event
      ↓
Scheduler → Task Queue → Orchestrator
                         ↓
                 Durable State Store
            Task・Checkpoint・Evidence・Decision
                  Approval・ActionResult
                         ↓
          Agent／Policy Gate／Human Approval
                         ↓
                Gmail／Drive／ERP／API

接下來用三大策略，把這個架構落成可恢復的工作流。

策略一：以顯式狀態機與 Checkpoint 取代「從頭再跑」

第一個關鍵，是把任務生命週期寫成允許與禁止的狀態轉移。

created → queued → collecting → analyzing → reviewing
        → awaiting_approval → executing → completed
        ↘ retrying／blocked／failed／cancelled

awaiting_approval 不能直接跳成 completed，failed 也不能在沒有錯誤分類時自動回到 executing。每個轉移都要保存時間、執行者、原因與工作流版本。

以上述報價任務為例，附件解析完成後立即建立 Checkpoint；ERP 查價完成後再建立一個。若 Analysis Agent 在產生比較表時中斷，恢復時應從最後一個安全節點讀取已驗證的 Evidence，而不是重新下載信件與查詢 ERP。

一份最小狀態可以長這樣：

{
  "task_id": "quote-review-20260904",
  "run_id": "run-0082",
  "workflow_version": "1.3",
  "state": "analyzing",
  "completed_steps": ["collect_mail", "parse_quotes", "lookup_erp"],
  "checkpoint_id": "cp-003",
  "evidence_ids": ["ev-mail-12", "ev-erp-31"],
  "next_step": "build_comparison",
  "retry_count": 1,
  "updated_at": "2026-09-04T09:02:00+08:00"
}

Checkpoint 不能只存一句「已完成查價」。它要指向實際 Evidence、輸入版本、Schema 版本與輸出雜湊，才能判斷舊結果是否仍可重用。若恢復時發現 ERP 資料已更新，系統應讓受影響的步驟失效，而非盲目沿用整份快照。

狀態也需要併發控制。兩個 worker 同時接手同一 Task 時，可用 lease、版本號或樂觀鎖確保只有一方能提交下一個狀態，避免最後寫入者覆蓋正確結果。

策略二：以冪等、錯誤分類與人工接管控制失敗

「失敗就重試三次」看似可靠，其實很危險。唯讀查詢可以重試，建立採購單、寄信或付款等有副作用的動作卻可能已在外部系統成功。

每個錯誤至少分成四類：

Google Cloud Workflows 的官方文件也將重試政策與冪等性分開處理，並支援 backoff 等設定。[3] 核心觀念是：只有當重複執行不會造成額外副作用，或能使用同一個冪等鍵查回既有結果時，重試才安全。

例如寄出詢價確認信時，可使用：

idempotency_key = task_id + action_type + approved_payload_hash

Action Agent 執行前先寫入 action_pending，外部服務回傳後保存 external_action_id 與 action_succeeded。若程序在兩者之間崩潰，恢復程序先用冪等鍵或外部 ID 查詢，不重新生成內容，也不自行猜測結果。

人工核准同樣是狀態。對外寄信、正式報價、付款、刪除與權限變更都應停在 awaiting_approval。若核准後收件人、價格或附件被改動，原 Approval 必須失效；系統不可把舊核准套用到新內容。

超過最大重試次數、資料持續衝突或恢復結果不確定時，工作流要提供人工接管。接管者需要看到最後 Checkpoint、Evidence、錯誤歷程、已發生的外部影響與可恢復選項，而不是只收到一句「Agent 執行失敗」。

策略三：讓排程同時理解期限、依賴、風險與成本

真正的智慧排程不是把 cron 寫得更複雜，而是決定「現在最該執行哪個可執行步驟」。

Spark 官方排程可依時間或事件啟動任務，也能暫停與恢復；但官方同時提醒，實際執行時間可能不是精確時刻，高流量時也可能延遲或受到併發限制。[2] 因此，時間敏感的企業流程不能把「8:30 觸發」誤當成「8:30 前一定完成」的 SLA。

排程器至少要考慮：

• deadline：距離業務期限還有多久。
• priority：任務的商業優先級。
• dependency：前置資料、工具與人工核准是否已完成。
• risk：高風險步驟是否只能在指定時段與人員在線時執行。
• budget：剩餘 Token、模型成本、API 配額與併發容量。
• retry_after：失敗後何時才允許再次執行。

同一個排程再次觸發時，也要有重疊政策：

以前述案例來說，等待主管核准時不需要每分鐘喚醒模型詢問一次。Scheduler 應將 Task 暫停，直到收到 Approval 事件或逾時事件再喚醒；若超過採購期限，則升級通知，而不是偷偷代替主管核准。

智慧排程還要能降級。高成本模型額度不足時，可以延後非急迫摘要；但涉及資料一致性或風險判斷時，不能只為省成本換成未通過評估的模型。所有降級規則都應事先寫入 Policy，而不是在執行當下由 Agent 自行決定。

一次中斷後，系統應該怎麼續跑？

完整恢復流程可以整理如下：

排程或事件觸發
      ↓
以 event_id 去重並建立 Task
      ↓
取得執行 lease → 載入最新 Checkpoint
      ↓
驗證工作流、Schema、Evidence 與權限版本
      ↓
執行下一個尚未完成的步驟
      ├── 暫時錯誤 → backoff → retrying
      ├── 永久錯誤 → failed
      ├── 資料／政策問題 → blocked → 人工接管
      ├── 高風險動作 → awaiting_approval
      └── 成功 → 保存 Checkpoint／ActionResult
                          ↓
                    下一步或 completed

這裡最重要的不是「記得上次聊到哪」，而是證明哪些工作已完成、哪些外部副作用已發生，以及接下來哪一步仍有權執行。

評估指標：可恢復也要能被量測

建議至少追蹤以下指標：

恢復成功率
= 從有效 Checkpoint 恢復並完成的任務數 ÷ 嘗試恢復的任務總數

重複副作用率
= 重複寄信、建單或更新的動作數 ÷ 外部動作總數

排程逾期率
= 超過業務 deadline 才完成的任務數 ÷ 已完成任務總數

人工接管率
= 進入 blocked 並由人員接手的任務數 ÷ 啟動任務總數

效能面再記錄佇列等待時間、P95 任務延遲、平均重試次數、每任務 Token／成本與平均恢復時間。人工核准本來就是高風險流程的正常設計，應與異常接管分開統計，否則團隊可能為了讓介入率下降而移除必要控制。

測試不能只拔掉網路一次。至少要模擬：Checkpoint 寫入後程序崩潰、外部動作成功但回應遺失、同一事件並發觸發、等待核准時工作流版本更新、權限在恢復前被撤銷，以及外部文件含有 Prompt Injection。每一種情況都要確認不會跳過核准、不會重複副作用，也不會使用已失效的 Evidence。

小摘要

AI 虛擬員工能在背景持續工作，不代表工作流自然具備可靠性。真正的續跑能力來自顯式狀態機與耐久 Checkpoint；真正的失敗恢復來自錯誤分類、冪等鍵與人工接管；真正的智慧排程則必須同時理解期限、依賴、風險、容量與成本。

Spark 可以作為 Task 與 Schedule 的使用入口，企業控制層仍要保存自己的 Evidence、Decision、Approval 與 ActionResult。這樣模型或 Prompt 即使更新，任務也能從可驗證的安全節點繼續，而不是依賴一段逐漸變長的對話猜測現況。

讀者最重要的三個帶回重點

1. 任務續跑依靠耐久狀態與 Checkpoint，不是依靠聊天紀錄；每個 Checkpoint 都要關聯實際 Evidence 與版本。
2. 重試不等於恢復；所有外部副作用都要使用冪等鍵、ActionResult 與人工核准，才能避免重複或越權執行。
3. 排程只是觸發器；智慧排程必須處理重疊任務、依賴、風險、期限、併發與成本，並在等待核准時真正暫停資源消耗。

參考資料

1. Use Gemini Spark to manage tasks and workflows，Google Gemini Apps Help，查閱日期：2026-09-04。
2. Create and manage schedules for tasks in Gemini Spark，Google Gemini Apps Help，查閱日期：2026-09-04。
3. Retry steps，Google Cloud Workflows Documentation，查閱日期：2026-09-04。