App Intents 是 Apple 通往你 App 的全新 API

2026 年 2 月 8 日早晨，當我雙手還埋在廚房水槽下時，我請 Siri 從我的 Apple Watch 記錄 8 盎司的飲水量。水量記錄完成。手錶上的對話框顯示還剩 32 盎司。我完全沒有碰過任何螢幕。¹

十一週前，我為我的補水追蹤 iOS App「Water」加上了一個 Swift 檔案：LogWaterIntent.swift，80 行的 AppIntent，外加一個宣告三種 Siri 片語變體的 AppShortcutsProvider。如今那個檔案，是我擁有的所有 API 介面中最炙手可熱的一個。²

接下來這一點，我花了一段時間才真正體會。App Intents 並不是 Siri 的功能。它是第三方 App 與 Apple Intelligence 簽訂的契約，而 Apple Intelligence 正是 Apple 從 iOS 18 開始推出、並一路打造到 iOS 26 的系統 AI 介面。³如果你推出了一款 iOS App，卻仍把 App Intents 當成「有了也不錯」的語音功能，那你就誤讀了 Apple 所打造的東西。App Intents 正是那個讓 Apple 的 AI 能夠以你的 App 之名、代表使用者行動的 API。其餘的一切（Siri、Spotlight、Shortcuts、Apple Intelligence 摘要，以及 Watch 與 Vision Pro 等介面）都是這份契約的下游產物。Foundation Models——這個隨 iOS 26 推出的裝置端 LLM——則為 App 內的工具呼叫公開了另一套獨立的 Tool 協定；它與 App Intents 平行運作，而非透過 App Intents。

太長不看（TL;DR）

• App Intents 以一種型別化、結構化、Apple 的 AI 可直接呼叫的方式，宣告你的 App 能做什麼。它們是 Apple 為第三方 App 提供的工具使用 API。
• 一個真實的正式環境範例：Water 中的 LogWaterIntent。80 行程式碼，完整的 SwiftData 寫入、HealthKit 同步、能感知地區設定的單位換算，以及結構化的 Siri 對話回應。
• iOS 26 加入了 Foundation Models，也就是 Apple 的裝置端 LLM。Foundation Models 為 App 內的工具使用公開了自己的 Tool 協定；App Intents 則仍是 Siri／Spotlight／Apple Intelligence 跨 App 呼叫的標準介面。方向相同，兩份平行契約。
• 一款在 2026 年沒有 App Intents 的 App，對 Apple Intelligence 而言形同隱形。AI 結構網要嘛透過你宣告的 intents 路由，要嘛繞過你的 App、轉向競爭對手。
• Apple 這三年來一直在告訴我們這件事。那些命名（App Intents、App Shortcuts、Apple Intelligence）都是刻意為之。每一屆 WWDC，這份契約都往技術堆疊上層再推進一層。

App Intents 框架參考圖，取自 Apple Developer 文件。⁵

App Intent 究竟是什麼

LogWaterIntent 在 2026 年 2 月 8 日以提交 e398c58 推出時的完整原始碼：²

import AppIntents
import SwiftData

struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    static var description: IntentDescription = "Log a glass of water to your daily intake"

    @Parameter(title: "Amount", default: 8)
    var amount: Int

    static var parameterSummary: some ParameterSummary {
        Summary("Log \(\.$amount) oz of water")
    }

    func perform() async throws -> some IntentResult & ProvidesDialog {
        let container = try ModelContainer(for: WaterEntry.self, DailyLog.self, UserSettings.self)
        let context = ModelContext(container)

        let settingsDescriptor = FetchDescriptor<UserSettings>(
            predicate: #Predicate { $0.id == "user-settings" }
        )
        let settings = try context.fetch(settingsDescriptor).first ?? UserSettings()

        let amountMl: Double
        if settings.unitSystem == .imperial {
            amountMl = Double(amount) * 29.5735
        } else {
            amountMl = Double(amount)
        }

        let todayKey = DailyLog.todayKey()
        let logDescriptor = FetchDescriptor<DailyLog>(
            predicate: #Predicate { $0.dateKey == todayKey }
        )
        let log: DailyLog
        if let existing = try context.fetch(logDescriptor).first {
            log = existing
        } else {
            log = DailyLog(date: .now, goalAmount: settings.dailyGoal)
            context.insert(log)
        }

        let entry = WaterEntry(amount: amountMl)
        log.entries.append(entry)
        try context.save()

        if settings.healthKitEnabled {
            try? await HealthKitService.shared.logWater(amount: amountMl, date: entry.timestamp)
        }

        let unit = settings.unitSystem == .imperial ? "oz" : "mL"
        let totalDisplay = settings.formatAmount(log.totalAmount)
        return .result(dialog: "Logged \(amount) \(unit). Today's total: \(totalDisplay)")
    }
}

struct WaterShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: LogWaterIntent(),
            phrases: [
                "Log water in \(.applicationName)",
                "Add water in \(.applicationName)",
                "Drink water in \(.applicationName)",
            ],
            shortTitle: "Log Water",
            systemImageName: "drop.fill"
        )
    }
}

（Water 目前正式版的這個檔案，又進一步在對話中加入了「已達標／剩餘量」的條件判斷。上方這段 2 月 8 日推出的程式碼，正是我在廚房水槽前測試的那一版。）

這裡有三件事值得特別點出來，因為大多數「App Intents 教學」都一筆帶過。

@Parameter 就是綱要（schema）。Apple 的 AI 看到的是預設值為 8 的 amount: Int。當 Siri 解析「記錄 12 盎司的水」時，它會產生 LogWaterIntent(amount: 12) 並呼叫 perform()。我這一端完全不需要做字串解析。型別系統就是綱要。⁵

parameterSummary 是這個參數的自然語言對映。Apple 用它在 Shortcuts UI、對話中、以及越來越多的 Apple Intelligence 確認面板裡呈現這個動作。這段摘要會被朗讀回給使用者聽。寫壞了，使用者聽到的就是彆扭的句子；寫對了，整個介面就會有原生的質感。⁶

perform() 回傳 IntentResult & ProvidesDialog。這就是結構化的回傳：AI 介面拿回來的不只是成功／失敗，還有一段使用者會聽到的對話字串。Apple 越來越期待 ProvidesDialog、ProvidesView 或 ReturnsValue，好讓結果能組合進 Siri、Spotlight、Watch，以及（在 iOS 26 中）Apple Intelligence 的回應鏈。⁷

底部的 AppShortcutsProvider 區塊負責註冊 Siri 片語。\(.applicationName) 這個權杖，正是 Siri 自動插入「Water」的地方。三種使用同一 intent 的片語變體，給了 Apple 的自然語言解析器更大的匹配空間，去對應使用者的措辭，而你不必自己維護一本片語字典。systemImageName 是一個真實的 SF Symbols 名稱；Spotlight、Shortcuts 與 Apple Intelligence 就是靠它來呈現這個動作的圖示。

Apple Intelligence 透過 App Intents 路由使用者請求，藉此提供裝置端 AI 功能。來源：apple.com/apple-intelligence。

為何這是自 SwiftUI 以來最重要的 iOS API

iOS 的 API 大致分成兩類。有些關乎你的 App 如何描繪自己（UIKit、SwiftUI、Metal）。有些則關乎你的 App 如何與系統整合（URL schemes、Universal Links、Widgets）。App Intents 屬於第三類：它們關乎 Apple 的AI如何使用你的 App。而那些 widget 與 Control Center 介面本身，也都是 App Intents 介面——同一個 intent 被呈現在多個地方——這點我在 iOS 26 的 Widget 介面 中有詳細追溯。

這條演進脈絡值得梳理一遍。

• iOS 10（2016）引入了 SiriKit Intents（INIntent），第一次讓第三方 App 能被語音存取。當時的介面很窄：一份固定的領域清單（訊息、付款、叫車），搭配嚴格的綱要。⁸
• iOS 12（2018）以 Siri Shortcuts 拓寬了這個介面：任何 App 都能捐贈一個 NSUserActivity 或 INIntent，並期望 Siri 將其推薦給使用者。
• iOS 13（2019）加入了 App 內的 intent 處理，讓 App 可以回應捷徑的呼叫，而不必退到背景、交給系統的 Siri UI。
• iOS 16（2022）引入了 App Intents 框架：型別化、宣告式，並具備 @Parameter 與 AppShortcutsProvider。對於新開發而言，前身 INIntent 已實質上被取代。⁹
• iOS 18（2024）引入了 Apple Intelligence，並開始盡可能將 Siri 請求路由經由 App Intents。Apple Intelligence 的「個人情境」功能會從 App Entities（App Intents 的資料版本）讀取。¹⁰iOS 27 又把這一步推得更遠，加入了 App Schemas，讓 Siri 能以它早已理解的語彙，對你的 entities 進行推理並採取行動，完全不需要任何訓練片語，此處有詳述。
• iOS 26（2025）引入了 Foundation Models 框架，也就是 Apple 的裝置端 LLM。Foundation Models 為 App 內的工具呼叫公開了一套獨立的 Tool 協定。App Intents 仍是 Apple Intelligence 跨 App 的標準介面，而 Tool 則是直接呼叫 LLM 的 App 內介面。兩份契約平行運作。⁴

每一個版本，這份契約都沿著技術堆疊往上延伸一層。最初，App Intent 的使用者是一個在 Shortcuts 裡點按的人。接著是 Siri 語音。然後是 Spotlight。再來是 Apple Intelligence 摘要。如今，Apple Intelligence 以 LLM 為後盾的系統介面，會用它們來對使用者的請求採取行動。你在 2026 年推出的 App Intent 介面，正是 Apple Intelligence 將在 iOS 27、28、29 上呼叫的那一個。

上述這套模式，正是我說「App Intents 並不是 Siri 功能」時的真意。它們是整個 Apple AI 結構網的結構化工具使用 API。SwiftUI 之所以是最重要的 UI API，是因為它成了在 visionOS、watchOS 10+ 與 iOS 17+ 上撰寫 App 的唯一途徑。App Intents 在 AI 這一側，正沿著同一條弧線前進：那是 Apple 押上全部賭注的介面。

Foundation Models 推出後，現在有什麼改變

Foundation Models 是隨每一台符合 Apple Intelligence 資格的裝置一同推出的框架。硬體門檻與 Apple Intelligence 的清單相同：iPhone 15 Pro 與 15 Pro Max（A17 Pro）、iPhone 16 系列、iPhone 17 系列、iPhone Air、iPhone 17e、搭載 M1 或更新晶片的 iPad Pro、搭載 M1 或更新晶片的 iPad Air、搭載 A17 Pro 的 iPad mini、搭載 M2 或更新晶片的 Vision Pro，以及搭載 M1 或更新晶片的 Mac。值得注意的缺席者：基本款 iPhone 15／15 Plus。⁴¹²

由此可知：如果 Apple 的系統介面（Siri、Spotlight、Apple Intelligence）會呼叫你的 App，那它們就是透過 App Intents 與 App Entities 來呼叫。在系統 AI 結構網中，第三方 App 並沒有 setSystemPrompt(...) 這樣的 API。有的是 intent 註冊表。Foundation Models 為想打造自家裝置端 LLM 功能的開發者，另外加上了一套平行的 App 內 Tool 介面。而那份跨 App 的契約（Apple Intelligence 與 Siri 用來找到你的 App 的那一份）走的是 App Intents。

對 App 開發者而言，有三項具體後果：

一款沒有相關 App Intent 的 App，在其類別中無法被 Siri 語音指令觸及。Apple Intelligence 會把「嘿 Siri，記錄我的飲水」這類片語，優先路由給已宣告對應 intent 的 App。我在 2026 年 2 月推出了 Water 的 intent。我對這個框架走向的判讀是：那些到 2027 年才推出 intent 的補水 App，將踏入一個路由權重早已往先行者累積的市場。同樣的邏輯也適用於購物清單、健身記錄、行事曆項目、照片搜尋。我預期 intent 宣告上的先行者優勢會以複利方式累積，一如 Apple 其他平台級押注 API 的歷程（HealthKit 類別、Spotlight 豐富結果、Live Activities 權杖）。

Apple Intelligence 的個人化讀取的是 App Entities，不只是 intents。一個 AppEntity 宣告了「這款 App 擁有這種形狀的資料」。當使用者問「我加進閱讀清單的最後一本書是哪一本」時，Apple Intelligence 會在每一個已安裝的 App 中，搜尋所有符合 Book 的 AppEntity。如果你的 App 有閱讀清單、卻沒有宣告 BookEntity，那你的資料對 Apple 的 AI 介面而言就是隱形的。Apple Intelligence 無法擷取或引用你的資料。¹¹

IntentResult & ProvidesDialog 這種回傳形狀越來越重要。Apple Intelligence 正把 intent 結果組合成橫跨 Siri、Spotlight 與 Watch 的更長回應。一個只回傳成功、卻沒有結構化對話的 perform()，會讓系統更難把它組合進連貫的回覆。ProvidesDialog 與 ProvidesView 並不是可有可無的禮貌；它們正是讓你的動作成為使用者 AI 介面中一則引用的關鍵。

如果重來，我會怎麼做

Water 累積了十一週的正式環境記錄，告訴了我三件早該更早動手的事。

推出比你以為需要的更多 intents。我只推出了一個。我本該推出四個：LogWaterIntent、CheckTodaysProgressIntent、AdjustGoalIntent、ShowHistoryIntent。每一個都對應一句使用者真的會嘗試的 Siri 片語（「我今天喝了多少水」被路由給了 Apple 的通用 AI，而不是我的 App 資料）。每一個漏掉的 intent，都是 Apple Intelligence 繞過我去路由的一筆查詢。

對話字串不是一封電子郵件的正文。我從一開始就有 ProvidesDialog，但我早期的對話是散文式的。透過 CarPlay 或 AirPods 聽到它的使用者，需要的是簡短、具體、以事實為先的結構：「已記錄 8 盎司。還差 32 盎司。」Watch 介面尤其會大刀闊斧地截斷。閒聊式的對話，是比自信陳述事實更糟的使用者體驗。我在第 4 週重寫了我的版本。²

App Entities 比我想像中更重要。我有一個 WaterEntry SwiftData 模型。我也應該宣告一個 WaterEntryEntity: AppEntity，外加它的搭檔 WaterEntryQuery: EntityQuery，好讓 Apple Intelligence 能回答「給我看我昨天什麼時候喝了水」。最精簡的橋接如下：¹¹

struct WaterEntryEntity: AppEntity {
    static var typeDisplayRepresentation: TypeDisplayRepresentation = "Water Entry"
    static var defaultQuery = WaterEntryQuery()
    var id: UUID
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(amount) oz at \(timestamp.formatted())")
    }
    @Property(title: "Amount") var amount: Int
    @Property(title: "Timestamp") var timestamp: Date
}

struct WaterEntryQuery: EntityQuery {
    func entities(for identifiers: [UUID]) async throws -> [WaterEntryEntity] {
        // Fetch matching entries from SwiftData
    }
    func suggestedEntities() async throws -> [WaterEntryEntity] {
        // Recent entries Apple Intelligence can suggest
    }
}

兩個小小的 Swift 型別，外加 SwiftData 的取資料黏合程式碼。若要讓個別項目能在 Spotlight 中被個別呈現（好讓搜尋「water」的使用者落在正確的項目上），請讓這個 entity 遵循 IndexedEntity，並在寫入時捐贈索引更新。這正是 Apple 的 Spotlight 管線在裸露的 AppEntity 公開之外所期待的。

同樣的形狀也適用於我的其他 App。Get Bananas，我的購物清單 App，已經有一個 SwiftData 的 @Model ShoppingItem，內含 @Attribute(.unique) var id: UUID、name、amount、section、isChecked，外加一個供 iCloud Drive 同步用的 lastModified 欄位。¹³把它包裝成 ShoppingItemEntity: AppEntity，再推出幾個 intents（AddShoppingItem、CheckOffItem、ShowList），就能把 Get Bananas 早已透過它的 .mcpb MCP 伺服器公開給 Claude Desktop 的同一個持久層，一併公開給 Apple Intelligence。¹⁴兩套 LLM 生態系，兩份不同的契約，同一份購物清單。這就是平行契約論點濃縮在單一已推出 App 上的樣貌：SwiftData 模型是資料，App Intents 是 Apple 的契約，MCP 是 Anthropic 的契約，兩個介面操作的都是同一份真實來源。

何時不該推出 App Intent

懂得拒絕，也是設計的一部分。

如果你的 App 純粹是消費導向的（讀取使用者的照片、顯示新聞、播放音訊），沒有任何可變動的使用者狀態，那 App Intents 可能根本沒有東西可以公開。Apple 的框架支援 OpenIntent（單純把 App 開到某個情境）；但如果唯一有用的動作就是「打開 App」，那這個 intent 就是多餘的負擔。別只為了有而推出一個。

如果某個動作仰賴難以抽象化的 UI 配套（一個複雜的多步驟畫布工具、一款 3D 編輯 App），那 intent 必填的 parameterSummary 就會退化成沒人真的會說的、含糊的偽自然語言。Siri 片語「用強度 7 的模糊工具編輯我的照片」技術上辦得到，但沒有人類會說出這句話。這個 intent 的介面只是一筆毫無回報的稅。

正確的準則是：當存在一句使用者會自然說出、足以觸發該動作的話時，App Intent 就值回票價。「記錄 8 盎司的水」就是那句話。「對第 3 層套用 sigma 為 2.4 的高斯模糊」則不是。如果你 App 的動作大多落在第二種模式上，那 intents 並不是你的轉換槓桿。

結語觀點

三年來，Apple 一直在釋出訊號：iOS 的系統 AI 結構網是經由 App Intents 運作的。WWDC 2024 加入了 Apple Intelligence 經由它們的路由。WWDC 2025 在一旁加入了 Foundation Models，作為一套獨立的 App 內工具呼叫介面，同時讓 App Intents 繼續作為 Siri／Spotlight／Apple Intelligence 持續使用的跨 App 契約。每一個訊號都指向同一個方向：型別化、宣告式的 App Intent，正是第三方 App 如今與系統簽訂的那份契約。

大多數 iOS App 仍把 App Intents 當成 Siri Shortcuts 看待：一個有空才推出的功能。我的判讀是，這種框架會很快過時。隨著 Apple Intelligence 的系統介面不斷延伸（如今已橫跨 Siri、Spotlight、Shortcuts 與 Apple Intelligence 摘要），沒有宣告 intents 的 App，很可能會發現自己被排除在路由圖之外。就我觀察 Apple 其他平台押注的經驗，先行者的介面會以複利累積。

Water 推出 LogWaterIntent 已經十一週了。推出一個 App Intent 所需的程式碼量，少到足以塞進單一檔案。而不推出它的代價，會隨著每一次 Apple Intelligence 的釋出而增長。

如果你在 2026 年推出一款 iOS App，卻連一個 App Intent 都還沒宣告，那你的藍圖就缺了一個項目。把它加上去。

FAQ

在 iOS 開發中，App Intent 是什麼？

App Intent 是一個型別化、宣告式的 Swift 結構，將你 App 的某個動作公開給 Apple 的系統 AI 介面。它透過 @Parameter 宣告參數，透過 parameterSummary 宣告自然語言摘要，並以一個非同步的 perform() 主體執行工作、回傳結構化結果。Apple 的 Siri、Spotlight、Shortcuts 與 Apple Intelligence 都能呼叫它。Foundation Models（Apple 的裝置端 LLM）則使用另一套獨立的 Tool 協定，來進行直接的 App 內工具呼叫。

App Intents 與較舊的 INIntent 有何不同？

App Intents（於 iOS 16、2022 年引入）取代 INIntent，成為 Apple 的主要 intent 框架。較新的框架完全以 Swift 原生方式打造，使用 @Parameter 這類屬性包裹器，透過 AppEntity 支援型別安全的 entity 查詢，並且是 Siri、Spotlight、Shortcuts 與 Apple Intelligence 呼叫的介面。較舊的 INIntent 仍受支援，但不再有新功能的開發。

推出 App Intent 需要 iOS 26 嗎？

不需要。App Intents 自 iOS 16 起即可使用。iOS 26 在一旁加入了 Foundation Models 框架，但 App Intent 宣告本身在 iOS 16 以上皆可運作。上方的範例程式碼使用了 SwiftData（iOS 17+），因此部署目標取決於你的 perform() 主體匯入了什麼。裸露的 App Intents 可回溯支援到 iOS 16；以 SwiftData 為後盾的則需要 iOS 17。

App Intent 與 App Entity 有什麼差別？

App Intent 是一個動作（動詞）。App Entity 則是你的 App 所知道的資料（名詞）。LogWaterIntent 是一個 intent。WaterEntry 變成一個可查詢的型別，則是一個 entity。Apple Intelligence 兩者都用：用 intents 來採取行動，用 entities 來在回應中擷取與引用資料。

App Intents 與 Foundation Models 的工具呼叫有何關聯？

Foundation Models 為直接的 App 內 LLM 工具呼叫，公開了自己的 Tool 協定。App Intents 則仍是 Apple Intelligence、Siri 與 Spotlight 呼叫的標準跨 App 介面。方向相同（型別化、宣告式的工具使用）；兩份平行契約。一款想被系統 AI 介面觸及的 App，要推出 App Intents；一款想以自訂工具呼叫自家裝置端 LLM 的 App，則要推出 Tool 的遵循實作。許多 App 兩者都會推出。

App Intents 不是一項功能。它是一份契約。最先推出 intent 的 App 拿下那個介面；較晚推出的 App，則會發現那個介面早已被路由到別處。十一週前，我在 Water 裡推出了一個。複利效應已經開始了。

Apple 生態系列的更多內容

這篇文章是入口。其餘四篇涵蓋了架構堆疊的其餘部分：

• 兩套 Agent 生態系，一份購物清單：Get Bananas 如何透過 iCloud Drive 裡的一個 JSON 檔案，把同一份資料公開給 Apple Intelligence（App Intents）與 Claude Desktop（MCP）。
• SwiftUI 中的 Liquid Glass：來自 Return 實際推出的三種模式：iOS 26 視覺層的正式環境模式。
• 五個 Apple 平台，三個共用檔案：多平台的推出策略，何時共用程式碼、何時為各目標分支。
• iOS 26 上的 HealthKit + SwiftUI：授權流程、樣本型別的資料來源層，以及那個會把使用者鎖在你 App 之外的陷阱。

或直接前往完整中樞：Apple 生態系列。若想了解更廣泛的「iOS 結合 AI agents」脈絡，請參閱 iOS Agent 開發指南。

參考資料