AI Agent 操作核准介面指南：建議、信心分級、理由與手機接管設計
從建議與套用、信心分級、簡短理由、任務綁定到復原，說明手機 AI Agent 操作核准介面如何讓使用者看懂即將發生的變更，並安全確認支援的 Android 任務。
- AI Agent 操作核准介面應出現在真正會改變資料、裝置狀態或對外產生結果的決策點，並清楚顯示目標、內容、影響與下一步。
- 建議、預覽與直接套用是三種不同狀態；信心分級可協助安排檢查順序，但不能代替權限、工具規則或使用者判斷。
- GitHub Issues 於 2026 年 7 月 23 日推出公開預覽的建議、信心分級與理由紀錄，提供值得參考的互動方式；其核准機制是工作流程上的便利設計，不是伺服器端安全界線。
- FoneClaw 目前透過分離執行中與等待中的任務、工作階段綁定核准、任務隔離、權限復原及 Home 執行復原，讓 Android 核准與接管維持在正確任務上。
先找出手機 Agent 真正需要確認的時刻
AI Agent 操作核准介面的第一個設計問題，不是按鈕要放在哪裡，而是哪一刻需要把決定交給使用者。查詢裝置狀態、整理文字與產生建議，通常不會立即改變外部世界；送出訊息、刪除檔案、修改系統設定、分享位置或啟動導航，則會造成可見結果。核准應靠近這個變更發生的時刻，讓使用者知道確認後會做什麼。
以訊息任務為例，手機 Agent 可以先理解「告訴怡君我會晚十分鐘到」，接著準備草稿。此時畫面應顯示收件人、文字內容、使用的通訊方式，以及目前狀態是「等待確認」。使用者可以選擇送出、修改或取消，而不是只看到一個缺乏上下文的「允許」按鈕。若同名聯絡人不只一位，流程要先要求選定對象，再進入送出確認。
確認點也要和動作影響相稱。開啟某個畫面與刪除一份檔案，不應使用完全相同的提示強度；前者可提供簡短狀態，後者則應標明檔名、位置、是否可復原與刪除後果。對連續任務而言，使用者還需要知道目前是第幾步、前一步是否完成，以及拒絕這一步會不會影響已完成的部分。
我們在 FoneClaw 將核准放進具體 Android 任務，而不是把它當成獨立彈窗。FoneClaw 目前的核准會綁定當次工作階段，任務也彼此隔離；因此確認對象、待執行動作與完成結果可以維持在同一段脈絡中。想進一步理解身份、工具權限與紀錄如何配合，可閱讀AI 代理身份與權限治理：逐工具核准、稽核紀錄與 FoneClaw Android 控制。
分清楚建議、預覽與直接套用
一個可理解的核准介面，至少要分出「建議」、「預覽」與「已套用」三種狀態。建議代表 Agent 已提出下一步，但尚未改變資料；預覽則呈現套用後會產生的內容或差異；已套用表示變更確實發生，畫面應提供結果與後續處理方式。這三種狀態若混在一起，使用者很容易把一段看似完成的文字誸認為動作已經執行。
GitHub 在 2026 年 7 月 23 日公布的公開預覽，為受支援的 GitHub Issues 變更提供類似思路。自動化可以先提出標籤、欄位、類型、關閉狀態或指派對象的建議，讓使用者逐項接受或拒絕；也可以依設定直接套用。這項設計的確切範圍是 GitHub Issues，而不是手機動作，詳情可參考GitHub Issues Agent 自動化控制公開預覽說明。
移到手機情境時，互動方式可以保留，但內容要改成 Android 使用者真正需要檢查的資訊。例如設定變更可先顯示「目前值」與「建議值」；訊息可顯示草稿與收件人；檔案整理可列出預計移動的項目和目的地；導航可先顯示目的地、交通方式與預估路線，再由使用者啟動。
| 介面狀態 | 代表意義 | 適合的操作 |
|---|---|---|
| 建議 | Agent 提出下一步，尚未改變資料 | 接受、拒絕或要求修改 |
| 預覽 | 顯示預計內容、目標與差異 | 核對對象、範圍和影響 |
| 等待確認 | 必要資料已齊全，等待使用者決定 | 執行或取消 |
| 已完成 | 動作已產生可查證結果 | 查看、復原或進行下一步 |
直接套用適合範圍清楚、容易復原且符合使用者既有設定的動作；涉及外部傳送、帳號變更或破壞性結果時，預覽與確認更重要。關鍵不是每一步都增加按鈕，而是讓畫面上的狀態名稱與實際結果一致。
用信心分級安排檢查順序
信心分級可以幫助介面決定哪些項目優先等待人工檢查，但分數本身不等於正確。Agent 可能對錯誤的聯絡人很有把握，也可能因資料不足而低估一個其實簡單的動作。因此，信心只能和動作影響、資料完整度、可復原性及使用者設定一起判斷。
GitHub 的公開預覽把受支援動作分為高、中、低信心；高信心變更可自動套用，中低信心項目則保留為建議，等待使用者查看。這種分流能減少逐項檢查的負擔，也能把注意力集中在模糊項目。不過，GitHub 明確指出，這裡的核准是工作流程上的便利設計，不是伺服器端安全控制；具備變更權限的自動化仍可能直接套用。
手機上的設計還需要加入動作影響。例如「把螢幕亮度調高一格」即使信心中等，也容易被發現並改回；「把檔案永久刪除」即使信心很高，仍值得明確確認。比較實用的判斷方式，是把信心和後果放進同一張表，而不是用單一門檻決定所有行為。
| Agent 判斷 | 動作影響 | 建議處理 |
|---|---|---|
| 高信心 | 低影響且可復原 | 依使用者設定執行並顯示結果 |
| 高信心 | 對外或不可逆 | 顯示完整預覽後確認 |
| 中信心 | 低至中度影響 | 標示疑點並等待選擇 |
| 低信心 | 任何影響 | 先補充資料，不進入執行 |
信心來源也要能被理解。比起顯示「87%」，介面更適合說「找到兩位同名聯絡人」或「日期來自訊息中的相對時間」。這些說明能讓使用者直接修正問題。若要深入比較 Agent 的工作範圍與 Android 權限，可參考AI Agent 沙盒與手機權限：安全 Agent 為什麼仍需要邊界。
核准前顯示理由、目標、影響與依據
核准畫面不需要展開模型的全部推理，但必須提供足以做決定的簡短理由。使用者至少應看見四件事：為什麼提出這個動作、要作用在哪個目標、完成後會有什麼結果，以及判斷依據來自哪段可見資訊。這比單純顯示「Agent 建議執行」更有用。
例如，行事曆建議可以寫成：「從林小姐今天的郵件找到 8 月 12 日下午 3 點會議；將在工作行事曆建立 60 分鐘活動，地點尚未提供。」這段文字同時交代來源、日期、目標行事曆與缺少欄位。使用者可以補上地點、改選行事曆、調整時間或拒絕建立，而不必重新理解整封郵件。
設定變更則應說明觸發原因與目前值，例如：「你要求降低耗電；準備將螢幕逾時從 10 分鐘改為 2 分鐘。」如果 Agent 只是從模糊要求推測，畫面應標出這是建議值。檔案操作可列出檔名、數量、來源位置與目的地；導航任務則顯示選定地點、路線類型及是否會啟動外部導航。
理由紀錄還能協助事後檢查。GitHub 的公開預覽會為受支援的 Issue 動作留下變更理由，不論動作直接套用或等待審查。手機 Agent 可借鏡這個互動原則：完成後保留精簡的「做了什麼、為什麼做、結果在哪裡」，讓使用者能確認，也讓失敗後的修正不必從頭開始。
這些理由不是安全保證。實際安全仍仰賴 Android 權限、工具規則、身份與帳號狀態、資料範圍以及動作本身的限制。核准介面負責讓決策變得可理解；底層控制則負責限制實際能做的事情。兩者配合，才能避免把一個醒目的確認按鈕誤當成完整防護。
讓核准綁定正確的對話與等待任務
手機同時處理多個 Agent 任務時，最大的介面風險之一，是使用者看到確認提示，卻不知道它屬於哪段對話。可能一個任務正在準備郵件，另一個任務正在修改行事曆，第三個任務則等待開啟系統設定。如果所有核准都只顯示「是否允許」，就容易確認到錯誤工作。
每張核准項目都應顯示任務名稱、來源對話、目前狀態、目標與等待原因。例如：「差旅行程整理｜等待確認｜建立 8 月 12 日行事曆活動」會比「建立活動？」更清楚。若任務在背景等待權限，介面也應區分「等待授權」與「等待核准」，因為前者要前往系統設定，後者則是在既有條件下做決定。
FoneClaw 目前將執行中與等待中的任務分開呈現，並透過工作階段綁定核准和任務隔離，讓一個對話中的確認不會被另一個工作沿用。當使用者切換任務時，可以先看各自的進度與待處理項目，再回到正確的確認畫面。這對訊息、郵件與設定等可能同時進行的手機工作尤其重要。
等待佇列也不該只按時間排列。較好的方式是標出影響程度、是否即將逾時，以及拒絕後能否繼續其他步驟。低影響建議可以批次查看；涉及外部傳送或不可逆結果的項目則應逐一呈現。使用者拒絕某一步後，任務可以顯示「已停止於送出前」或「保留草稿」，清楚交代已有成果。
若手機成為多個 Agent 任務的管理入口，集中檢視與接管會比零散通知更實用。相關介面規劃可延伸閱讀手機 AI Agent 控制中心：當行動端成為代理任務的審批與接管入口。
把核准模式套用到常見手機動作
不同手機動作需要不同的核准資訊。訊息和郵件最重要的是收件人、正文、附件及送出狀態；系統設定要顯示目前值、建議值與裝置影響；檔案操作要顯示目標項目、目的地及復原方式；導航則應確認地點、交通方式，以及是否只顯示路線或立即啟動。
| 手機情境 | 核准前應顯示 | 適合的停止點 |
|---|---|---|
| 訊息或郵件 | 收件人、內容、附件、傳送方式 | 保留草稿，等待送出 |
| 系統設定 | 目前值、變更值、可能影響 | 停在設定頁或變更前 |
| 檔案整理 | 檔名、數量、來源與目的地 | 預覽移動或刪除清單 |
| 導航 | 目的地、路線、交通方式 | 顯示路線，等待啟動 |
| 公開發布 | 帳號、受眾、文字與媒體 | 停在發布預覽 |
以設定為例，使用者說「幫我省電」時，Agent 不宜把廣泛目標直接變成一連串未說明的變更。介面可以先提出幾項可選建議，例如縮短螢幕逾時或調低亮度，分別顯示目前值與預期影響。使用者選定後，FoneClaw 才在支援的 Android 流程中處理必要權限與操作。
檔案整理則需要避免把「重複」、「過期」或「不重要」當成客觀事實。介面應列出判斷依據與候選項目，讓使用者先排除要保留的檔案。若刪除方式可復原，可顯示復原期限或位置；若屬永久刪除，則要使用更明確的確認內容，並避免和一般整理按鈕放在相同位置。
導航是另一種容易混淆的狀態。查到地址、顯示路線與開始導航是不同結果。當地點名稱可能重複時，核准畫面應顯示完整地址；若 Agent 根據訊息或行事曆推定目的地，也要標出來源。使用者可以更換地點、改選交通方式，或只保留路線資訊而不啟動導航。
我們在 FoneClaw 的做法，是先確認任務是否屬於支援的 Android 動作，再依影響安排資訊、權限與確認。畫面會讓使用者知道工作正在執行、等待資料、等待授權、等待核准或已完成，並提供可查證結果。這使核准成為任務的一部分，而不是突然出現、缺乏脈絡的阻擋畫面。
提供拒絕、修改、復原與觸控接管
核准介面不能只有「同意」和「取消」。取消常讓使用者不知道任務是否全部終止，也無法保留已完成的準備工作。更實用的選項包括拒絕這一步、修改內容、改選目標、稍後處理、保留草稿，以及停止整個任務。每個選項都應說明接下來會留下什麼。
例如使用者拒絕寄送郵件時，系統可以保留草稿並把任務標示為「已停止於寄送前」；若只是收件人錯誤，可以回到對象選擇，不必重新產生正文。設定變更若未套用，畫面應保留原值；若已完成且系統支援改回，則提供清楚的復原入口與目前狀態。
權限被拒絕時，Agent 應指出缺少哪項權限、它與目前步驟的關係，以及使用者可採取的替代方式。FoneClaw 目前的權限復原可協助使用者完成授權後接回任務；Home 執行復原則處理流程返回主畫面後的接續。接回時仍需重新核對目前畫面、待執行目標與先前確認是否仍然適用。
觸控接管也應是正常路徑。當畫面資訊複雜、目標不明或使用者想親自完成最後一步時，介面可以停在正確頁面，清楚指出待處理位置。使用者完成後，再由 Agent 讀取可見結果或詢問是否繼續。這種接管方式能保留已完成的準備，同時把需要精準判斷的部分交回使用者。
- 確認核准項目屬於哪個任務與對話。
- 查看目標、內容、影響與判斷依據。
- 選擇執行、修改、拒絕、稍後處理或觸控接管。
- 遇到權限問題時，只處理目前步驟需要的授權。
- 完成後核對可見結果，必要時使用復原入口。
- 若結果不明，不重複執行可能造成重複效果的動作。
完整的 AI Agent 操作核准介面，應讓使用者在決策前看懂、決策時能修改、決策後能查證，出錯時也能接回。信心分級和簡短理由可以降低檢查負擔，任務綁定則避免確認用錯地方；真正的安全與可靠性，仍由權限、工具規則、明確狀態、使用者控制和復原能力共同建立。