自我改進手機 AI Agent：技能版本、回歸測試與安全回復

什麼是自我改進手機 AI Agent？先分清四個部分

自我改進手機 AI Agent 是一種能從執行結果與失敗紀錄中學習，並透過受控變更改善後續工作的手機 Agent。它會找出哪些計畫容易失敗、哪個工具使用方式不穩定、哪些驗證條件不足，再提出對規劃、執行框架或可重用技能的修正。

這裡的「自我改進」不等同重新訓練基礎模型。使用者設定的模型維持供應商提供的權重與版本，在 FoneClaw Agent 工作流程中負責語言理解、推理與規劃。FoneClaw 改進的是圍繞模型運作的執行框架、技能、驗證規則、工具使用方式與失敗恢復流程。

要理解整體架構，可以把它拆成四個部分。第一是模型，處理自然語言與計畫；第二是 Agent 執行框架，也就是 harness，包含提示、工具、協調邏輯、驗證和恢復；第三是可重用技能，保存特定手機任務的步驟、參數與停止條件；第四是 Android 執行，由 FoneClaw 完成支援的手機動作。

例如，一項「整理下載檔案並準備摘要」技能，可能因 App 版面改變而找不到目標資料夾。自我改進流程不會直接重寫模型，而是檢查失敗紀錄，找出辨識規則過度依賴畫面位置，再提出較穩定的控制項識別方式並進行測試。

示範建立技能和部署後改進技能也屬於不同階段。前者關注如何從操作範例提取規則，後者關注既有技能如何根據真實證據持續維護。想了解技能建立階段，可閱讀示範一次，教會手機 Agent：螢幕錄製、可重用技能與 Android 安全。

Self-Harness 研究如何從紀錄提出並驗證改進

手機 Agent 能否在模型完全不變的情況下變得更可靠？Self-Harness 研究提出一個三階段循環：先從執行紀錄找出弱點，再提出範圍有限的 harness 變更，最後驗證提案，通過後才接受。

第一階段是 weakness mining，也就是從成功與失敗紀錄中找出重複問題。單一失敗可能只是網路中斷、測試環境異常或資料缺漏；多次出現相同模式，才更適合被視為執行框架弱點。紀錄需要包含模型看到的輸入、採取的工具動作、回傳結果及最後成功條件。

第二階段是 bounded proposal。變更應盡量小，並明確說明它要修正哪個問題。例如，若 Agent 經常在命令回傳空值時繼續下一步，可以新增一項「空值時停止並重新取得狀態」的驗證規則，而不是全面重寫整個任務提示。

第三階段是 proposal validation。新規則要在保留案例和未見案例上測試，確認原問題改善，同時沒有破壞其他任務。只有能重現問題、證明修正有效，並通過回歸檢查的提案，才進入可接受範圍。這使自我改進成為有證據的工程流程，而不是讓 Agent 任意累加新規則。

Self-Harness 作者在 Terminal-Bench-2.0 上報告，三個固定基礎模型的 held-out pass rate 都有所提升，變更集中在執行框架而非模型權重。這項結果支持「調整 harness 也能改善 Agent 表現」的研究方向；手機環境仍需要另外測試觸控介面、應用程式版本、裝置尺寸、語言和 Android 權限。

論文對 harness 的定義很廣，包含提示、工具、runtime 機制、驗證規則、協調邏輯和失敗恢復程序。對手機 Agent 來說，這可能涵蓋如何選 App、如何辨識控制項、何時重新擷取畫面、哪一步需要確認，以及部分失敗後從哪裡接續。

Salesforce 對自我改進 Agent 的研究觀點也反映業界正從一次性 Agent 轉向有回饋、評估與持續改善的工作方式。真正適合產品環境的關鍵，是讓每次改進都可說明、可測試、可批准及可回復。

FoneClaw 如何成為受治理的自我改進手機 Agent

FoneClaw 是自我改進手機 AI Agent。它可以利用支援工作流程中的執行結果與失敗紀錄，改善模型規劃的使用方式、Agent 執行框架行為及可重用手機技能，並透過治理生命週期把變更控制在明確範圍內。

使用者設定的支援模型在 FoneClaw Agent 工作流程中提供語言理解、推理與規劃。FoneClaw 負責把計畫轉成支援的 Android 手機動作，顯示實際進度與結果，依步驟處理必要權限，並在傳送、刪除、提交或其他重要動作前提供確認。

自我改進從真實結果開始。若某項技能在不同 Android 裝置上反覆找不到相同控制項，FoneClaw 可以彙整失敗類型，區分畫面尺寸、語言、App 版本和帳號狀態，再提出針對識別方式或恢復流程的最小變更。

每個提案都需要保留原始證據、變更內容和預期影響。例如，技能版本 1.4 依按鈕文字尋找「儲存」，但在另一個語言環境中失敗；版本 1.5 可以加入控制項角色與畫面上下文判斷。變更紀錄應說明新增條件，而不是只寫「提高成功率」。

權限與確認會持續存在於改進後的流程中。新版技能若需要新的資料類型、應用程式或 Android 能力，權限差異必須先被列出並批准。改進可以讓流程更準確或更容易恢復，但不會把原本需要使用者確認的高影響動作變成無提示執行。

FoneClaw 的 Android 結果保持可見，使改進能以真實結果驗證。模型說「已建立提醒」不足以作為唯一成功條件；測試還要確認提醒確實出現在預期 App、時間和重複週期都正確。只有可觀察結果符合任務目標，技能才算通過。

若要理解模型訓練和手機執行能力的不同，可以閱讀PhoneBuddy-4B 與手機 AI Agent 訓練：為什麼 Mock-App RL 對 Android Agent 很重要。FoneClaw 的自我改進重點則是已部署 Agent 的規劃、harness 和技能治理。

一項改進從證據到上線與回復的完整生命週期

一個修正何時可以進入真實 Android 工作流程？完整生命週期至少要包含證據、最小提案、回歸測試、權限差異、審批、版本、分階段發布、監控和回復。少了任何一環，都可能把局部改善變成新的系統問題。

1. 蒐集證據：保存成功與失敗紀錄、畫面狀態、工具呼叫、權限、確認和實際結果。
2. 分類原因：區分技能缺陷、App 改版、網路問題、資料缺漏、模型判斷或測試環境異常。
3. 提出最小變更：只修改能直接解決已確認問題的提示、工具規則、驗證或恢復步驟。
4. 執行回歸測試：重跑原始失敗案例、正常案例、相鄰任務和未見變化。
5. 檢查權限差異：列出新版新增、移除或改變使用方式的 App、資料與 Android 能力。
6. 取得審批：由具備責任的產品或安全角色檢查證據、測試和影響。
7. 建立版本：保留版本號、變更說明、相依條件、測試結果和前一穩定版。
8. 分階段發布：先在測試裝置與低風險任務使用，再逐步擴大範圍。
9. 監控實際結果：查看成功率、人工介入、權限錯誤、延遲和新失敗模式。
10. 安全回復：指標惡化或出現高影響問題時，立即切回前一個穩定版本。

證據品質決定後面每一步是否可靠。若紀錄只有「失敗」兩個字，就無法分辨是按鈕不存在、權限被拒絕、畫面尚未載入，還是成功條件寫錯。手機 Agent 應記錄必要狀態，但也要控制敏感資料範圍，讓除錯資訊足以重現問題。

回歸測試不能只重跑原始案例。修正「找不到儲存按鈕」後，還要測試取消、返回、欄位未填、不同語言、較大字體和橫向畫面。技能在一個場景變好，不應讓其他合理路徑變差。

權限差異是手機技能版本管理中特別重要的一項。新版若從只讀資料改成可以寫入，或新增另一個 App，風險輪廓就已改變。審批畫面應把權限變化和功能變化放在一起，讓決策者知道改善帶來哪些新能力。

版本紀錄、身分、審批和執行結果需要互相連接。更完整的治理架構可參考AI Agent 身分、權限與稽核軌跡：手機 Agent 真正需要的安全棧。

虛構問題、過度修正與權限漂移為何會破壞技能

自我改進流程最大的風險，不只是修不好，而是把不存在的問題當成真實缺陷。2026 年 7 月的 Phantom Guardrails 研究指出，optimizer 可能虛構一個失敗，再加入沒有必要的 guardrail。若驗收只看某個錯誤是否被壓制，就可能接受多餘甚至有害的規則。

這種「幽靈失敗」在手機 Agent 上可能表現為：某次網路延遲被誤認為 App 一定需要額外等待；測試資料缺少欄位，被解讀為所有使用者都必須新增確認；或測試裝置權限設定錯誤，導致技能加入不必要的替代路徑。修正前必須先重現問題並核對環境。

過度擬合則是另一個常見情況。技能為了解決某款手機上的按鈕位移，加入精確座標，結果在其他螢幕尺寸完全失效。較穩定的改進應依控制項語意、畫面結構與目前任務狀態判斷，而不是記住單一裝置的偶然位置。

App 版面變化會讓固定測試集快速過時。即使技能在同一批 benchmark 上持續進步，也不代表能處理新版 App、不同帳號狀態或新的權限對話框。測試集需要定期加入真實變化，同時保留歷史案例，避免只追逐最新畫面。

語言差異也不能只靠翻譯按鈕文字處理。繁體中文、英文或其他語言可能改變字串長度、排序和版面，甚至使用不同詞彙。回歸測試應檢查語意角色、控制項類型和整體上下文，而不只比對顯示文字。

權限漂移發生在技能逐版新增能力，卻沒有重新檢查總範圍。每次變更看似合理，累積後可能讓技能能讀取更多資料、操作更多 App 或執行更高影響動作。版本審批需要同時比較本次差異與技能目前的完整權限。

沙盒和手機權限處理不同問題：沙盒限制 runtime、工具和檔案範圍，Android 權限管理裝置資料及功能。兩者如何配合，可閱讀AI Agent 沙盒與手機權限：安全 Agent 為什麼仍需要邊界。技能在安裝後還會面對持續變化的輸入與行為，相關風險可見AI Agent 技能安全：為什麼手機 Agent 不能只靠安裝前掃描。

手機 Agent 變更進入真實 Android 前的檢查清單

使用者或產品團隊如何判斷一項自我改進已準備好進入實際手機？以下清單可以用在技能更新、harness 調整、驗證規則新增與恢復流程變更。每個答案都應有紀錄或測試結果，而不是只有「表現更好」的總結。

• 問題可重現嗎？相同失敗是否能在已知裝置、App 版本和資料條件下再次出現？
• 原因已確認嗎？能否排除網路、測試資料、權限設定和環境異常？
• 變更夠小嗎？是否只修改與問題直接相關的規則、工具或步驟？
• 正常流程仍通過嗎？原有成功案例和相鄰任務是否保持穩定？
• 變化環境測過嗎？是否涵蓋不同裝置尺寸、字體、語言、App 版本和帳號狀態？
• 成功條件可觀察嗎？能否從 Android 實際結果確認任務完成，而非只看模型回覆？
• 權限有變化嗎？新版是否新增資料、App、寫入能力或更長的存取時間？
• 確認點仍完整嗎？傳送、刪除、提交或其他高影響動作是否顯示實際內容？
• 版本可以識別嗎？執行紀錄是否能指出使用哪個技能和 harness 版本？
• 已分階段發布嗎？是否先在低風險裝置、測試資料和小範圍任務驗證？
• 監控指標清楚嗎？是否追蹤成功率、人工介入、延遲、權限錯誤和部分失敗？
• 回復已演練嗎？能否快速切回前一穩定版，並保留已完成工作的狀態？

回復不只代表部署舊檔案。完整 phone agent rollback 還要處理進行中的任務、已建立的草稿、部分完成的 Android 動作及新版新增的權限。系統應先停止新的執行，再標記受影響任務，切回穩定版本，最後決定哪些工作可以安全接續。

回復後也不能直接刪除失敗版本的紀錄。提案、測試、審批、發布範圍、異常指標和回復原因都應保留，讓下一次改進知道哪些方向已被證明不合適。這會防止 optimizer 日後再次提出相同變更。

自我改進手機 AI Agent 的成熟度，最終取決於它能否對每次變更回答五個問題：為什麼要改、改了什麼、如何證明更好、增加哪些權限或風險，以及如何安全回到上一版。FoneClaw 以受治理的改進生命週期處理這些問題，讓設定模型的推理能力、可重用技能和支援的 Android 動作持續進步，同時保持結果可見、權限清楚、確認有效及接續可行。