真正難的不是讓 agent 會按手機
剛看到有人把 AI agent 接到 Android 手機上，可以發簡訊、裝 app、拍照、打電話，底層是 Android app 加一個 socket。我的第一個反應其實不是「這很猛」，而是「好，從這一刻開始，問題變了」。
之前很多 agent workflow 的風險，還停在資訊層。抓資料抓錯、摘要歪掉、搜尋路徑繞遠路，麻煩歸麻煩，大多還能補救。手機這種東西不一樣。它一旦能動作，影響就會直接落在現實世界。發錯訊息、打錯電話、點錯一個付款頁，代價都比回答錯一段文字高很多。
在日本這邊做遊戲 AI，我的觀察是，模型夠不夠聰明通常不是最後卡住的地方。真的卡住的，往往是 action boundary。有些 NPC 行為可以放它自己決定，因為出錯頂多是體驗變怪。有些事情不行，像課金、封號、推播，這些一定要多一層 gate。agent 控手機也是同一類問題。你要先決定哪些操作可以自動做，哪些只能 draft，哪些一定要人按 approve。
如果今天是 read calendar、整理通知，permission 可以寬一點。如果是 send message、install APK、call contact，我會直接拆成三層。第一層 read only，第二層 propose action，第三層 human confirm。流程多一拍，看起來很笨，但這個一拍通常比你換更強的模型還有用。
另一個容易被低估的是 rollback。Web 上很多操作做錯還能回上一頁，手機世界常常沒有那麼乾淨。訊息送出去就是送出去了，電話撥出去就留下紀錄了。你如果沒有 event log、screen snapshot、或至少把每一步 intent 記下來，事後根本很難查。到最後你會發現，大家以為自己在做 agent，其實有一半時間在補 observability。
有趣的是，那篇下面還有人說自己把 agent 裝在 sailboat 上，接到船上的系統。這種案例我反而覺得很真實。因為一旦接到真設備，所有 abstract 的 agent 討論都會被迫落地。權限怎麼切，失敗怎麼停，誰來接手，這些不能再用一句「模型會自己處理」帶過去。
所以我現在看這類展示，最在意的已經不是 demo 能不能動，而是系統設計有沒有把風險邊界畫清楚。讓 agent 會按手機不算最難。真正難的是，你敢不敢讓它按第二次，還知道出事時要從哪裡把它拉回來。
作者：嵐山貓