當 AI 替你操作 App，「完成」到底是誰說了算？
「把下週要繳的費用記進待辦。」
假設一款台灣小團隊做的待辦 App，把「新增待辦」開放給 agent 呼叫。使用者說完這句話，螢幕回了一個「完成」。但她有工作和私人兩個帳戶；「下週」也還沒有明確日期。若剛才的回覆逾時，agent 再試一次，現在可能有兩筆待辦。這是設計上的假想情境，不是 Android 上已發生的案例。它讓一件小事變得很清楚：App 可以少一個手動填寫的步驟，不能少掉對寫入結果的責任。
三種 agent 能力，不是一個已經走通的流程
十月底的 Android 開發者公告，把幾個消息放在同一篇文章裡。Android Studio Rabbit 2 支援開發者選用 ACP coding agent；AppFunctions 讓 App 描述可供 agent 發現、呼叫的功能；A2UI for Jetpack Compose 則關乎 agent 回應如何呈現。它們分別處理「誰幫開發者寫程式」、「誰能叫用 App 功能」和「結果怎麼顯示」，不能把它們拼成所有 Android 使用者都能立即使用的一條功能鏈。
公告稱 AppFunctions 進入 beta，官方總覽頁仍標示 experimental。文件允許開發者先實作與測試，同時說明端到端使用目前只開放給有限的 App 和系統 agent。這種口徑差異不必替平台猜答案；對產品團隊而言，它表示現在適合設計介面與驗收方式，還不適合向使用者承諾普遍可用。
先寫清楚「新增」的意思
回到待辦 App。原本的新增畫面會讓人看見標題、日期、帳戶，再按下儲存。Agent 若能跳過畫面，這些選擇不會自動消失，只會躲進函式的輸入和預設值裡。
我會把可呼叫動作縮到很小：一次只建立一筆待辦，輸入必須指明標題、目標帳戶，以及足以確定的日期。帳戶不能從最近使用紀錄偷偷帶入；「下週」若可能指好幾天，就先問使用者。對同一項請求，App 也要能識別重試，避免回覆一斷線就新增第二筆。這裡說的是產品應該訂的契約，不是宣稱 AppFunctions 已替每個 App 提供防重機制。
有些動作甚至不該照這個模式直接開放。新增待辦尚可檢查和刪除；改收款帳戶、送出付款或刪除重要資料，補救成本不同。先問清楚、縮小可操作範圍，必要時讓人回到 App 親自完成，比把所有按鈕都包成函式穩妥。
權限放行之後，使用者還需要知道結果
AppFunctions 文件描述的是另一層事情：App 宣告函式、產生供系統建立索引的資訊，符合條件的呼叫端取得 EXECUTE_APP_FUNCTIONS 權限後，才能探索與呼叫。這是平台的存取門檻；某個呼叫端有權使用函式，不等於使用者已看過這次要寫入哪個帳戶、同意這筆變更。App 還得決定何時要求具體確認，以及什麼情況應拒絕執行。
執行後，回覆也不該只有「完成」。假設真的新增成功，讓使用者看得到待辦標題、日期、帳戶，並能回到那筆資料。若欄位不足，回覆缺的是哪一項；若網路或程序在寫入後中斷，先查實際資料，再決定是否重試。這時應該說「結果尚待確認」，不要把它硬歸成成功或失敗。這份可讀的動作收據，是我對產品流程的建議，不是 Google 已提供的內建回執畫面。
團隊若想先試，可以拿不含個資的測試帳戶走過三種情況：正常建立、日期不明而停下來、寫入後回覆中斷。每一種都讓另一位同事只看 App 的資料與回覆，判斷是否新增、寫到哪裡、還需不需要人處理。這是值得做的驗收設計；本文沒有在 Android 裝置上執行這項測試。
讓 agent 找得到 App 功能，是入口。使用者能查明那一步做了什麼，甚至知道它還沒做成，這個入口才不會把責任留在一句模糊的「完成」裡。
資料來源與範圍
公告與文件的能力、狀態和使用範圍依同日來源資料所保存的官方公開搜尋摘錄整理；本次未擷取官方頁面全文，也未實測 AppFunctions。待辦 App、測試帳戶與動作收據均為設計推演，不代表特定產品已上線或在台灣開放。