AI Engineer onepage/ MCP Tasks
Cornelia Davis, Temporal · 23:54
這支影片在講：讓 Agent 撐過不會立刻完成的工作
MCP 的一般 tool call 假定請求很快結束；但發票處理、背景任務與等待人工決策都會跨過斷線與重啟。MCP Tasks 要把這段生命週期變成可查、可恢復、可持續回報的協定能力。
Published: 2026-08-02Video ID: s4r6nk5WsZw
01 / 問題
RPC 假設工作會立刻完成
網路抖動、client 離線或程序重啟時，長時間 tool call 的結果與進度很容易一起消失。
02 / 反轉
Task 不是持久連線
真正要持久的是可查詢的任務生命週期；連線只是傳遞更新的通道，不應成為工作本體。
03 / 解法
無狀態核心＋可選擴充
將長任務、進度推送與 human-in-the-loop 疊加在 MCP 核心之上，讓不需要它的工具仍保持簡潔。
Signals
影片的四個協定訊號
Runtime
23:54
從問題定義、dashboard demo，到 V1 與 V2 的演進。
Core change
RPC → updates
不只等單一回覆；server 可隨任務狀態推送進度。
Durability
Resume
client 斷線後仍能回來取得任務位置，而非從頭猜測。
Human loop
Pause
任務可等待人工提供資料，再由 backend 繼續處理。
Core story
把長任務做對的三個設計取捨
取捨 1
把「工作」與「連線」拆開
連線必然會失敗；任務狀態不該跟著蒸發。將 task ID、狀態與可恢復位置交給可耐久保存的後端，client 就能在回來後重新接上，而不是把 timeout 當成失敗。
取捨 2
把 progress 視為協定資料，不是日誌
Dashboard demo 的價值在於任務目前在哪裡變成可觀察狀態。Server 主動更新讓 client 能呈現進度、等待與下一步，而不是只顯示一個漫長 spinner。
取捨 3
將 stateful 行為留在 extension
V2 的方向不是讓每個 MCP 互動都建立長連線；核心保持無狀態，只有確實需要長時間執行、恢復與人類輸入的工具才宣告並實作 task 能力。
Practical implications
給 agent 與 MCP 團隊的實務啟發
先界定何時真的需要 task短、可重試的查詢維持普通 request/response；跨分鐘、外部等待或高成本工作的流程才值得引入狀態與恢復機制。
狀態機要先於 UI先清楚定義 queued、running、waiting-for-input、completed、failed 等生命週期與可轉移條件，再讓 dashboard 或 agent 根據它行動。
人類輸入是正式狀態不要用旁路訊息硬塞 approval 或補件；把「等待誰、需要什麼資料、恢復後去哪裡」納入 task 合約。
恢復時要有明確授權邊界重新連上不代表無條件重跑。為讀取狀態、提交輸入、取消與重試設計明確權限與 idempotency，避免重複副作用。
Use this checklist
導入 MCP Tasks 前，先檢查這五點
任務有可查詢、可恢復的識別與狀態嗎？不要只依賴一個尚未關閉的 HTTP 或 streaming 連線來辨識工作。
client 回來後知道從哪裡接續嗎？明定 resume 的資料、重送語意與已完成結果如何讀取。
進度更新是否能驅動下一個決策？回報階段、等待條件與可採取動作；避免只輸出無法行動的百分比。
等待人工輸入時，任務是否安全地暫停？把輸入格式、逾時、取消與恢復權限視為正式 API 合約。
stateful extension 是否被限制在必要範圍？無狀態核心保留部署與擴展彈性，避免將所有 tool 都拖進長連線模型。
Source video