手機 AI 代理失敗除錯與復原指南：根因分析、權限修復與安全重跑

失敗後五分鐘：先停止、保留狀態、判斷風險

手機 AI 代理任務失敗時，第一個動作是停止連續重跑。表面錯誤通常只告訴你「最後哪一步壞掉」，真正原因可能出現在更早的畫面讀取、能力路由、權限、核准或外部服務狀態。AgentDebugX 研究把代理除錯整理成 Detect、Attribute、Recover、Rerun 的循環，這個思路對手機任務特別有用，因為手機上的每一步都可能改變真實世界狀態。

前五分鐘可以照這個順序處理：先按下停止或取消，保留目前畫面，記下最後一個可見結果，再判斷任務屬於讀取型、可回復型或具外部效果型。讀取通知、查詢裝置狀態、整理目前畫面通常風險較低；調整音量、亮度、勿擾模式屬於可回復設定；傳送訊息、撥電話、建立行事曆、刪除資料、安裝外掛或發出網路請求，則需要先確認是否已完成。

我們在建 FoneClaw 時，很早就把「停止」和「結果可見」放進任務流程，原因就在這裡。手機 AI 代理看起來像聊天，其實正在執行一串可觀察的手機動作。只要任務已經碰到聯絡人、訊息、系統設定或第三方服務，最小安全原則就是先看清目前狀態，再決定重試哪一小段。若你想深入理解核准畫面如何建立信心，可以延伸閱讀 手機 AI 代理核准體驗：信心理據、風險提示與可確認動作設計。

• 先停止正在跑的任務，避免同一指令連續送出。
• 截取或記錄目前畫面、最後回覆、最後工具結果。
• 確認是否已傳訊、撥號、建立事件、改設定或刪除資料。
• 把接下來的動作限制在讀取狀態與修復前置條件。

建立最小失敗證據包

好的除錯證據包要能重建意圖、軌跡、裝置狀態與結果，同時保護個資。只截一張錯誤畫面通常太薄，因為根因可能在前一步的目標選錯、權限被撤回、畫面焦點不在預期 App、模型把模糊指令拆錯，或外部服務暫時拒絕請求。AgentDebugX 強調軌跡理解與結構化調查；套用到 Android 手機代理時，證據包要涵蓋「使用者想做什麼」和「手機實際走到哪裡」。

最小證據包可以包含五類內容。第一是原始意圖與期望結果，例如「幫我回覆 Alex 說晚點到」或「把會議改到下午三點」。第二是任務時間線，包含代理回覆、工具名稱或動作類型、是否需要核准、使用者是否按下確認。第三是狀態證據，像是目前畫面、目標 App 是否在前景、網路是否可用、電池或背景限制是否影響執行。第四是權限與資料來源，例如通訊錄、簡訊、通知、位置、相機、麥克風或日曆是否已授權。第五是最後結果，包含錯誤訊息、部分完成的輸出與已確認的外部效果。

在 FoneClaw 的產品設計裡，我們把工具結果、核准狀態與可見回覆視為診斷材料。讀者回報問題時，請先移除密碼、一次性驗證碼、完整電話號碼、完整地址、訊息正文、帳號權杖與私人附件。保留可重現的結構，比貼上完整個資更有幫助。若你正在建立團隊層級的稽核習慣，AI 代理身份與權限治理：逐工具核准、稽核紀錄與 FoneClaw Android 控制會把證據與權限邊界講得更完整。

把失敗分到正確層級

手機 AI 代理失敗的難點，在於同一個表面錯誤可能來自不同層級。畫面上顯示「無法完成」時，可能是模型沒有理解目標，也可能是能力路由選錯工具、目前畫面缺少必要資訊、Android 權限被撤回、工具前置條件未滿足、第三方 App 改了介面、網路服務拒絕請求，或使用者尚未完成核准。代理根因分析的第一步，就是把錯誤放到正確層。

Android 權限尤其需要獨立檢查。Android 執行階段權限說明指出，App 在使用需要權限的功能時要檢查授權狀態，使用者也可以拒絕、撤回或永久拒絕權限。這表示任務昨天能完成，今天仍可能因為權限重設、系統更新、背景限制、App 休眠或使用者設定而失敗。權限錯誤與模型錯誤在表面上都可能長得像「工具失敗」，但修復方式完全不同。

能力路由本身也會造成誤判。當代理不知道該自動附上畫面、提出建議或改用替代能力時，任務可能在中段失焦。想把這層拆得更細，可以看 AI 代理能力路由指南：AutoAttach、Suggest、Fallback 如何讓 Android 任務選對能力，本文則聚焦失敗後的診斷與復原。

找出最早造成問題的步驟

Detect、Attribute、Recover、Rerun 的價值，在於它提醒我們追溯「最早造成後續失敗的步驟」。在手機任務裡，表面錯誤可能出現在最後一個送出工具，但根因可能是前面讀錯畫面、誤判聯絡人、未拿到權限、選了錯誤帳號或遺漏使用者核准。嚴格根因歸因本來就困難，所以實務上要用信心分級，而非只給一個絕對答案。

操作方式可以從失敗點往回追。先看最後可見錯誤，接著回看上一個成功步驟是否真的完成。工具回傳成功，還要確認手機狀態是否符合預期：行事曆事件是否存在、訊息是否仍是草稿、勿擾模式是否已變更、附件是否真的被選取。再往前檢查工具參數，像是聯絡人 ID、日期、檔案、App 名稱、位置、語言、帳號或核准狀態。只要某一步的輸入與當時裝置狀態不一致，就可能是最早因果點。

為了避免把猜測寫成結論，我們建議用三段式歸因：主要根因、證據、替代可能。例子可以是：「主要根因是通訊錄權限被撤回；證據是讀取聯絡人工具在同一步回傳權限不足，且系統設定顯示未授權；替代可能是目標聯絡人已被刪除，需再用通訊錄 App 驗證。」這種寫法比「AI 壞了」更可行，也讓復原步驟能對準真正前置條件。

我們在 FoneClaw 的測試裡，也把失敗樣本拆成任務、步驟、工具、狀態與使用者動作，而非只看最後一行錯誤。若你想把這套方法延伸成正式評估，可以接著看 Android 手機 Agent 基準測試指南：2026 AI Agent 評估、GUI 測試與可靠性指標，用可重複案例追蹤可靠性。

避免重複外部效果的復原與重跑

復原的核心原則是：先確認已完成效果，再修復前置條件，最後只重跑最小安全後綴。讀取型任務可以比較快重試；可回復設定要先記錄目前值；具外部效果的動作要先查明是否已經送出、建立、刪除、撥出或同步。手機 AI 代理失敗後直接重跑整個任務，最容易造成重複訊息、重複行事曆、重複通話、重複下載或重複資料變更。

復原階梯可以分成四層。第一層是只讀驗證：查目前畫面、通知、行事曆、通訊錄、裝置狀態或第三方 App 狀態。第二層是前置條件修復：重新授權、把目標 App 放回前景、恢復網路、解除省電限制、登入帳號、關閉遮擋彈窗。第三層是最小重跑：只執行尚未完成的工具步驟，並在傳送、刪除、撥號或建立外部資料前重新核准。第四層是結果確認：檢查下游狀態，確定任務已完成或已安全停止。

Android 權限指南也提醒開發者要處理拒絕、撤回與永久拒絕等狀態，並在缺少權限時優雅降級。套用到使用者側，就是先判斷有沒有替代路徑。例如無法讀取通訊錄時，可以請使用者手動選擇聯絡人；無法直接完成訊息時，可以先產生草稿；無法操作第三方 App 時，可以把步驟整理成可跟著做的清單。復原的目標是降低重複外部效果，同時讓使用者知道哪一步已完成、哪一步仍需處理。

1. 先查已完成效果：訊息、通話、行事曆、設定、檔案、外部服務。
2. 修復前置條件：權限、前景 App、網路、登入、彈窗、目標資料。
3. 只重跑失敗後綴：保留已成功步驟，避免從頭再做。
4. 在具外部效果前重新核准：讓使用者確認內容、對象與時間。
5. 完成後做狀態確認：用讀取型檢查結束任務。

多個任務同時排隊時，復原還要注意任務隔離。FoneClaw 的多對話與任務連續性設計，讓使用者能回到同一個任務上下文查看狀態。若你常在不同對話間切換，可以延伸閱讀 Android 多對話 AI Agent 任務佇列：等待、切換、隔離與復原。

用 FoneClaw 目前控制項完成診斷與復原

FoneClaw 的復原思路來自我們對手機任務的產品經驗：代理需要看得到狀態、能停下、能要求核准、能在權限缺口出現時引導修復，並把重試限制在支援的 Android 工作流程內。FoneClaw 目前以 100+ built-in tools 承接支援的手機動作，涵蓋讀取狀態、設定調整、通訊、行事曆、地圖、Web、工作流程與擴充能力。工具數量本身只是一個入口，更重要的是每一步能留下可檢查結果。

實際復原時，先回到同一個任務脈絡，查看最後回覆、工具結果與是否停在核准卡。若失敗與目前 App 畫面有關，可以由使用者主動附上目前畫面，讓代理重新理解前景 App、彈窗、按鈕與錯誤訊息。這個附件動作是刻意觸發的設計，讓使用者知道何時把畫面脈絡交給代理。若你想看目前畫面如何配合提問、核准與復原，可參考 Android 懸浮 AI 助手與目前畫面：提問、核准、執行與復原指南。

接著看失敗類型。權限失敗時，FoneClaw 會把使用者帶向可修復的位置，讓你重新授權或選擇可行替代方式；工具前置條件失敗時，先補齊目標資料或把 App 放到正確狀態；核准失敗時，檢查是否有未處理的確認卡或系統確認畫面；模型計畫不清楚時，把任務拆成更小步驟，要求先輸出草稿或先做讀取型檢查。重試按鈕適合在前置條件已修復後使用，並且先確認前一步沒有造成重複外部效果。

我們在 FoneClaw 中把停止、重試、權限復原、目前畫面、核准和結果確認放在同一條任務線上，是為了讓讀者從「代理失敗」回到「哪個手機狀態需要修復」。要確認當前可用能力與安裝資訊，請查看 FoneClaw 功能頁 與 FoneClaw 下載頁。這兩個頁面承接會變動的產品細節，本文保留可長期使用的復原方法。

寫出支援團隊能使用的回報

當同一失敗在修復前置條件後仍重現，或任務牽涉外部效果、權限循環、工具結果矛盾、畫面狀態無法判斷，就適合整理支援回報。好的回報要讓工程團隊能重建路徑，也讓產品團隊知道使用者在哪個決策點失去控制感。

回報模板可以這樣寫：裝置與 Android 版本、FoneClaw 安裝管道、目標 App、原始任務意圖、期望結果、實際結果、最後成功步驟、失敗步驟、已修復過的前置條件、是否已造成外部效果、可重現步驟、截圖或錄影、時間區間與網路狀態。敏感內容先遮蔽，保留結構即可，例如把電話號碼寫成「同一位常用聯絡人」，把訊息正文改成「短句草稿」。

請只提供診斷必要資料。密碼、一次性驗證碼、完整金流資訊、私人訊息全文、完整通訊錄、存取權杖與醫療資料，都應在未經明確同意前移除。支援回報的目的，是精準重現失敗層級與最早因果步驟，而非交出整台手機的私人內容。

用驗收測試避免同類失敗再發生

一次成功重跑只表示當下狀態已恢復，可靠性還需要驗收測試。Android App 權限最佳實務建議測試授權與撤回等不同組合；手機 AI 代理也應把權限、前景 App、網路、核准、打斷與外部服務狀態放進回歸案例。這能把單次事故變成可追蹤的產品改進。

最小測試矩陣可以包含四組：權限已授權與已撤回、目標 App 在前景與背景、使用者核准與取消、網路正常與中斷。每組都要定義通過標準、停止標準與復原證據。通過標準是任務完成且結果可驗證；停止標準是代理在不安全時停止或要求核准；復原證據是使用者能看見錯誤層級、前置條件與下一步。

我們正在把 FoneClaw 的手機代理能力往更可測、更可復原的方向推進。對團隊來說，好的自我改進循環並非讓代理自行冒進，而是把失敗案例轉成可重跑、可核准、可觀察的驗收資料。若你要建立更完整的治理流程，可以閱讀 自我改進手機 Agent 測試框架：樣本、回歸、治理與安全上線。

• 記錄失敗案例：原始意圖、根因、修復方式與最小重跑步驟。
• 測試權限組合：授權、撤回、永久拒絕與替代流程。
• 測試打斷情境：來電、通知、鎖屏、App 切換、網路中斷。
• 測試外部效果：已送出、已建立、已變更時是否避免重複。
• 定義可見證據：每次失敗都能看見狀態、原因與下一步。