「No App」很容易被理解成：未來不再需要應用程式，所有事情只要對 AI 說一句話就能完成。這個說法很吸引人，卻也把真正的架構變化說得太簡單。
App 不會憑空消失。航班仍要由訂位系統處理，付款仍要經過支付服務，行事曆仍有自己的資料模型與權限。正在改變的，是使用者不必每次先判斷要開哪一個 App，再照著固定選單逐步操作。入口從「選工具」上移成「表達意圖」，Agent 再負責找出能力、組合步驟、取得授權，並把結果帶回來。
No App 不等於沒有 App，而是 App 從主要入口退到能力供應層；Agent 逐漸成為理解意圖與編排服務的介面。
這也是我看待 Agent as Interface 的核心：它先解決互動摩擦，但若要成為真正的個人 Agent，還得再解決脈絡摩擦。
從 App Launcher 到 Task Orchestrator
傳統智慧型手機與桌面系統，以 App 為主要組織單位。使用者先選擇軟體，再把自己的目標翻譯成按鈕、欄位與頁面流程。如果一件事跨越三個服務，就要在三套介面之間搬移資訊。
Agent as Interface 把這個順序反過來：使用者先說明結果，例如「安排下週去東京的兩天行程，不要撞到既有會議」，系統才依這次情境決定要查行事曆、交通、住宿或公司差旅規則。這不是把所有服務合併成一個萬用 App，而是在服務之上多出一層任務編排。
這個方向已經出現在不同層次的產品與標準裡。
- Instinct 官方網站把產品描述成可透過簡訊或電話交辦、能使用手機與桌面環境的個人 Agent。這是廠商對產品能力的自述，適合當成「入口改變」的案例，不能直接當作採用成效或可靠性的獨立證明。
- Deutsche Telekom 在 2024 年展示與 Brain.ai、Qualcomm 合作的 app-free AI phone 概念，2025 年又將概念推進到以 Perplexity Assistant 為主要入口的 AI Phone 計畫。官方材料仍然提到背後的合作服務與既有 App，正好說明「看不到 App」不代表能力不再由 App 與服務提供。
- Apple 的 App Intents讓開發者把 actions、entities 與 queries 暴露給 Spotlight、Shortcuts、Siri 與 Apple Intelligence。App 還在，但它的內容與動作可以離開原本畫面，被系統級入口調用。
- Android 官方把演進方向寫成從 application launchpad 走向 active task orchestrator。Android intelligence system列出 AppFunctions、遠端 MCP、Computer Control 與 Agent-to-UI 等路徑，同時明確標示仍處於早期 preview。
這些案例不代表 No App 已經被證明優於所有既有介面。它們共同指出的是一個可觀察的方向：功能不必只存在於自己的畫面裡，而可以被描述、發現、組合與調用。
介面沒有消失，而是從固定頁面變成動態回應
當使用者以意圖為入口，純文字對話不會是唯一介面。訂旅館需要比較選項，核准採購需要看價格與風險，修正行程需要直接操作時間軸。對話適合說明目標，結構化 UI 更適合確認狀態與做出精確選擇。
A2UI 專案嘗試讓 Agent 以宣告式 JSON 描述介面，再由客戶端用可信任的原生元件呈現。它把「Agent 決定要呈現什麼」與「客戶端決定如何安全渲染」分開，截至 2026 年 10 月仍是 early-stage public preview。這個設計揭露了一個重要觀念：Agent as Interface 不是把所有操作塞進聊天泡泡，而是讓介面依任務生成，必要時仍回到按鈕、表單、圖表與確認畫面。
更早的 AIOS 研究構想則把 LLM 想像成作業層、Agent 想像成應用層，並把自然語言放在程式介面的位置。研究願景與可大規模交付的產品之間仍有距離，但它提供了一個有用的分析框架：當自然語言成為上層入口，底下仍需要資源管理、工具調用、權限與執行環境。
所以，No App 真正改變的不是「有沒有畫面」，而是三個責任的重新分配：
- 使用者說明意圖，不必先知道工具邊界。
- Agent 編排能力，把目標拆成可執行、可核准的步驟。
- 系統呈現該次任務需要的介面，讓人查看依據、修正參數與確認高風險行動。
Agent as Interface 只解決一半問題
如果 Agent 只知道這一輪對話，它即使可以叫用很多工具，仍然會反覆詢問相同資訊，也很難理解「照我的習慣處理」究竟代表什麼。這是互動摩擦與脈絡摩擦的差別。
Agent as Interface 解決互動摩擦：使用者不必在不同 App 之間找入口、搬資料、重做步驟。Personal Context 解決脈絡摩擦：系統知道這是誰的任務、任務進度、偏好與限制，過去哪些做法有效，以及什麼資訊必須重新確認。
兩者必須一起設計。只有新入口、沒有可信脈絡，Agent 可能很會操作，卻替錯的人、用錯條件完成錯的事。只有個人脈絡、沒有行動能力，系統則停留在「很懂你，但做不了事」。
我會把一個可工作的循環拆成六段：
- 意圖：使用者要達成什麼結果，而不是要打開哪個工具。
- 脈絡：這次任務最少需要哪些個人、專案與狀態資訊。
- 能力：哪些 App、API、MCP server 或裝置能完成各步驟。
- 授權：哪些可以自動執行，哪些必須先讓人確認。
- 結果：外部系統是否真的改變，而不是 Agent 只回覆「完成」。
- 回寫：本次結果要更新哪些任務狀態、規則或經驗。
No App 若只做到前三段，會是一個方便的語音遙控器；走完整個循環，才開始接近 Agent Experience。
產品設計不該從「做一個聊天框」開始
對產品團隊而言，最實際的起點不是先換首頁，而是先盤點能力與責任。
先把 App 功能改寫成可調用能力
列出真正有價值的 actions 與 entities，明確定義輸入、輸出、錯誤、權限與可重試條件。Apple App Intents、Android AppFunctions 或 MCP 都是在做類似的能力外露。沒有穩定能力層，Agent 只能以畫面自動化猜測下一步，可靠度與可維護性都較差。
再定義確認點與可逆性
搜尋資訊與提交付款不是同一風險。每個動作要標記是否可逆、影響誰、需要何種授權，以及失敗後如何補償。高風險任務應提供預覽、依據與明確確認，而不是用一句籠統的「允許 Agent 操作」涵蓋全部權限。
最後才決定用對話或畫面
目標探索可用對話，多選比較可用卡片，精確輸入可用表單，重要核准應有摘要與差異。介面由任務需要決定，不應先假設「Agent 產品就是聊天」。
真正的競爭點會移到連續性與信任
當多數服務都能被 Agent 調用，單一按鈕的位置不再是唯一差異。使用者會更在意：系統是否理解所在情境、能否延續未完成任務、會不會越權，以及結果出錯時能不能追查。
因此，我對 No App 的判斷不是「App 將消失」，而是軟體入口與價值位置正在分離。App 繼續提供資料、交易與專業能力；Agent 負責把能力組合成任務；動態介面負責在對的時刻讓人看見與決定；Personal Context 則維持跨任務的連續性。
這條路仍在早期。Instinct 的描述、Telekom 的產品方向、Apple 與 Android 的系統介面、A2UI 的協定探索，各自只涵蓋其中一段。它們沒有單獨證明完整架構已經成熟，卻足以讓我們提早改變設計問題：不要再只問「下一個 App 要長什麼樣」，而要問「當使用者只說出意圖時，我的能力如何被安全發現、正確執行，並延續成下一次可用的經驗」。
若要看互動入口之外的完整循環，可以接著閱讀Personal Context → Agent Experience：No App 處理人如何交付意圖，完整框架則進一步處理脈絡、驗證、反思與經驗回寫。