無狀態 MCP 與有狀態 Agent 工作流：Android 手機代理任務狀態架構指南
MCP 2026-07-28 把協定核心推向無狀態請求，但可靠的 Android 手機 Agent 仍需要有狀態任務層。本文從 Dean 的 FoneClaw builder 視角，說明任務狀態、核准、權限、idempotency、復原與稽核該放在哪裡。
- MCP 2026-07-28 正式把協定核心推向無狀態：請求自帶必要描述，可被相容伺服器實例處理，並加入 MRTR、header routing、可快取清單、授權強化與 extensions framework。
- 無狀態 MCP 伺服器讓部署、路由、重啟與橫向擴展更容易；有狀態 AI Agent 仍要在應用層保存對話、任務、裝置、核准、授權與稽核狀態。
- 手機 Agent 任務狀態應由 host 或應用層明確擁有，MCP Tasks、explicit state handles 與 elicitation 可以協作；任務 handle 作為工作參照，使用者核准與 Android 權限由獨立狀態管理。
- 我們從 FoneClaw 目前的懸浮助手、同手機任務延續、權限復原與受治理 Android 動作學到：可靠工作流需要 idempotency、可見核准、裝置狀態重讀、結果驗證與可接續復原。
MCP 2026-07-28 改了什麼
MCP 2026-07-28 最重要的變化，可以用一句話說清楚：協定核心保持無狀態，任務記憶由 Agent 應用明確管理。Model Context Protocol 2026-07-28 規格發布說明把這次版本描述為 final release，包含 stateless protocol core、self-describing requests、MRTR、header routing、cacheable lists、authorization hardening，以及 extensions framework；Tasks 也以正式 extension 的形式出現。這項變更把傳輸層與應用層的責任分開：MCP 請求負責把足夠資訊帶到伺服器，手機 Agent 應用負責保存任務、核准、裝置與復原狀態。
過去很多 connector 設計會把協定 session 當成隱含狀態容器：初始化後假設伺服器知道 client 能力、工具清單、授權脈絡或前一輪對話。SEP-2575 Make MCP Stateless的方向，是移除 stateless-first 模型對強制初始化握手的依賴，改由每個請求攜帶足夠 metadata，讓相容伺服器實例能處理請求。這讓負載平衡、serverless、重啟與部署彈性更好，也讓協定本身更適合大規模 connector 生態。
我們在打造 FoneClaw 時，對這個方向很有感。手機任務需要狀態，而且這些狀態應該由懂任務的 host 或應用層擁有。語音、目前畫面、權限、核准、工具結果、失敗復原與稽核，都是手機 Agent 的應用狀態。若你想先理解工具與資源如何被代理安全發現，Agentic Resource Discovery 智慧代理資源發現：ai-catalog.json、工具目錄與手機代理授權邊界會補上 discovery 與信任模型。
無狀態 MCP 請求生命週期如何運作
無狀態 MCP 請求的基本思路，是把「伺服器要理解這次請求所需的資訊」放進每次 request。這些資訊可能包含 client 能力、目標工具、授權提示、metadata、版本、routing headers、cache 驗證資訊，以及指向應用狀態的明確參照。伺服器可直接依這次請求處理工作；在部署上，也就能讓任一相容實例接手請求。
discovery 仍然重要，只是它成為可快取、可重新驗證的能力查詢，而非一次握手後永久有效的假設。工具清單、資源清單和 server capabilities 可以被快取，也可以依需求重新取得。2026-07-28 規格中的 cacheable lists 與 header routing，正是為了讓這些請求在大規模服務中更好路由與快取。對手機 Agent 來說，這類能力很適合用在遠端 connector、工具目錄與插件服務能力查詢上。
explicit state handles 則補上長任務的參照方式。SEP-2567 Sessionless MCP via Explicit State Handles說明了如何用伺服器鑄造的 state handles 取代隱含 protocol session state，並把 state references 穿過後續呼叫。這對長時間任務很實用：server 可以給一個 handle，client 或 host 在後續請求中帶上它。但在手機 Agent 裡，handle 的角色是參照；完整核准、授權與裝置狀態模型由應用層保存。
換成 FoneClaw 的設計語言：MCP 請求可以無狀態，手機任務必須有明確狀態。host 要知道使用者想做什麼、哪一步已核准、Android 權限是否足夠、裝置畫面是否仍是原來狀態、外部效果是否已發生。這些資訊要寫進任務 ledger、審核紀錄和復原流程，讓每一次工具呼叫都有可追溯脈絡。
手機 Agent 必須擁有的六種狀態
我們在 FoneClaw 的經驗是，手機 Agent 的可靠性取決於誰擁有哪些狀態。MCP server 很適合提供工具、資源、任務 handle 或遠端能力；手機任務責任通常要回到 host。下面這張表，是我們評估無狀態 MCP 與有狀態 Agent 工作流時會用的六種 ledger。
| 狀態類型 | 應由誰擁有 | 手機任務中的用途 |
|---|---|---|
| 對話狀態 | Agent host 或模型上下文 | 保存使用者意圖、補充條件、語音修正與目前任務脈絡。 |
| 任務狀態 | Agent host | 記錄任務階段、待處理步驟、工具呼叫、idempotency key、取消與完成狀態。 |
| 裝置狀態 | 手機端 host 重新讀取 | 確認目前畫面、預設 App、權限、網路、雙卡提示、設定狀態與可用控制。 |
| 核准狀態 | Agent host 與使用者介面 | 保存哪個動作、哪個資料範圍、哪個結果被使用者核准。 |
| 授權狀態 | Android、服務端與 host 協作 | 處理身份、token、角色、Android 權限與 connector access。 |
| 稽核狀態 | Agent host 或合規系統 | 留下請求、工具、核准、結果、錯誤、重試與復原紀錄。 |
這六種狀態需要各自明確歸屬。核准和授權尤其要分開：使用者授權某個 connector 存取資料，是存取層狀態；使用者核准立即發送簡訊，是任務層狀態；Android 權限已開啟，是裝置層狀態。若你要把身份、逐工具核准和稽核紀錄設計得更完整，AI 代理身份與權限治理：逐工具核准、稽核紀錄與 FoneClaw Android 控制會把這層治理拆得更細。
MCP Tasks、MRTR、elicitation 與核准如何協作
MCP 2026-07-28 把 Tasks 放進 extensions framework，這對長時間工作很重要。Tasks 可以讓工作有明確 handle、狀態查詢與後續互動，長任務因此能以可參照的形式存在。MRTR 與 elicitation 則讓工具、模型與使用者輸入之間有更好的互動管道：工具可以把需要模型處理的結果帶回流程，系統也可以向使用者要求必要資訊。
手機 Agent 需要把這些協定能力接到自己的核准模型。假設一個 MCP Tasks handle 代表「準備導航和通知家人」的長任務，handle 可以讓 host 查詢進度或接續工作；要發出簡訊、撥電話或修改設定時，host 仍要顯示目標、內容、資料範圍與結果，並取得使用者核准。Task handle 是工作參照，核准 record 是使用者對具體外部效果的同意，兩者要放在不同 ledger。
取消與過期同樣重要。手機任務常因鎖屏、網路中斷、App 狀態變化、權限提示或使用者改變心意而中止。Tasks 可以協助保存長任務進度；FoneClaw 類型的 host 則需要決定：任務是否可恢復、上一次核准是否仍有效、裝置狀態是否要重讀、工具呼叫是否需要新的 idempotency key。這種協作方式，符合無狀態 MCP 與有狀態 Agent 工作流的清楚分工。
在無狀態 MCP 上執行有狀態 Android 工作流
用一個 Android 勿擾模式任務來看整個流程。使用者說：「我進會議了，幫我把勿擾模式開到一小時後，允許家人來電。」FoneClaw host 先保存對話意圖與任務狀態，接著規劃支援的 Android 設定工作。若這個任務需要呼叫一個遠端 MCP connector 取得行事曆或政策資料，MCP request 可以自帶 metadata、能力描述和明確 state reference；任一相容 server instance 都能處理這次請求。
回到手機執行時，host 會重新讀取裝置狀態：目前是否有勿擾權限、系統設定是否可用、例外規則是否需要使用者選擇。接著建立 approval record，顯示即將修改的設定、持續時間、例外對象與復原方式。這個核准是手機任務狀態的一部分；MCP handle 則負責指向相關遠端工作或資料。使用者確認後，FoneClaw 透過受治理 Android 工具執行支援設定，並用 idempotency key 標記這次外部效果，避免重試時重複套用。
執行後，host 要驗證結果：勿擾模式是否開啟、例外是否符合預期、到期時間是否保存。若權限缺少，權限復原會把使用者帶到可授權位置；若畫面變動或工具回報不一致，任務會停在可接手狀態。截至目前可取得的最新產品資訊，FoneClaw 提供懸浮助手、同手機任務延續、權限復原與快速動作；在這裡，它展示的是 host-side task continuity：使用者在 Home、懸浮助手與權限畫面之間移動時，任務仍能接回。
同樣模式也適用於可見 SMS 草稿、撥號準備與導航交給選定地圖 App。若你想看目前畫面如何由使用者主動附加，並如何成為核准與復原的一部分，Android 懸浮 AI 助手與目前畫面：提問、核准、執行與復原指南會更直觀。針對通話任務，AI代理打電話：MCP 電話工具與 FoneClaw Android 撥號器流程比較則把 MCP 工具與 Android 原生撥號流程的取捨拆開說明。
擴展 MCP 伺服器時保留手機任務可靠性
無狀態 MCP 伺服器的部署優勢很明顯：請求可被 load balancer 分發到不同實例，server 重啟後可直接依 request metadata 接續處理，serverless 與橫向擴展更容易。MCP Go SDK v1.7.0 release也把 per-request metadata、server discovery 與 2026-07-28 protocol lifecycle 作為官方 SDK 實作方向之一，並保留 legacy protocol 版本相容路徑。
但手機任務的外部效果需要額外保護。重試要先分類：純讀取可以更安全地重試；準備草稿、建立提醒、修改設定、撥號或傳送訊息都需要 idempotency、結果驗證與重複防護。若 MCP server 回傳 timeout，host 要判斷動作是否已發生；若 Android 工具執行到一半，host 要重新讀取裝置狀態，再決定重試、補償或請使用者接手。
correlation id 和 audit id 也很關鍵。一次使用者任務可能包含多個 MCP request、多個 Android tool call、一次核准、一次權限復原和一次結果驗證。FoneClaw 類型的 host 需要把這些事件串在同一條任務紀錄裡，讓使用者和開發者都能追蹤「哪個請求造成哪個結果」。若你想看錄音、摘要與手機動作如何從 MCP 類型工作流進入核准流程，AI 錄音器 MCP：會議筆記如何變成經確認的手機操作提供了另一個任務轉換案例。
安全分工與遷移檢查清單
MCP 2026-07-28 的 authorization hardening，讓 connector 生態能更清楚處理身份與存取。但對手機 Agent 來說，authentication、authorization、approval 仍是三種獨立狀態。authentication 確認誰在使用；authorization 確認某個 connector 或工具能存取什麼；approval 確認這一次具體任務是否可產生外部效果。Android 權限則是裝置層的執行前提。可靠系統會把這些狀態分開保存，再在任務流程中合併呈現給使用者。
遷移到 stateless-first MCP 時，可以用下面清單檢查。第一，移除對隱含 initialization session 的依賴，讓 request 自帶必要 metadata。第二，把 discovery 結果設計成可快取、可失效、可重新讀取。第三，使用 explicit state handles 參照 server-side 工作，但把應用任務、核准與稽核保存在 host。第四，為每個外部效果建立 idempotency key、correlation id 和驗證步驟。第五，為 legacy clients 與 servers 保留版本協商或相容路徑。第六，把 Tasks、MRTR、elicitation 與使用者核准接到同一個任務 ledger。
若未來我們設計 FoneClaw connector，要求會很清楚：MCP 層可以無狀態，手機任務層必須有狀態；connector handle 作為參照，Android 權限與使用者核准由任務層管理；每個工具呼叫都要有資料範圍、可重試規則、結果驗證與稽核事件。FoneClaw 現行產品已把同手機任務延續、權限復原與受治理 Android 動作放進 host-side 流程；MCP 類 connector 若加入架構，會服務同一個目標：讓手機任務可擴展、可恢復、可追蹤，也可由使用者接管。