App Intents 是 Apple 連接你的應用程式的全新API

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

十一週前,我為自己的飲水追蹤 iOS 應用程式 Water 加入了一個 Swift 檔案:LogWaterIntent.swift,80 行的 AppIntent 程式碼,加上一個宣告三種 Siri 語句變體的 AppShortcutsProvider。這個檔案如今成為我擁有的最熱門API層。²

接下來這部分,我花了一段時間才真正領悟。App Intents 並不是 Siri 的功能。它們是第三方應用程式與 Apple Intelligence 簽訂的契約,Apple Intelligence 是 Apple 自 iOS 18 開始推出、並持續在 iOS 26 中建構的系統 AI 介面層。³如果您發行 iOS 應用程式,卻仍將 App Intents 視為「有也不錯」的語音功能,那就誤判了 Apple 真正在打造的東西。App Intents 是讓 Apple 的 AI 代表您的應用程式為使用者執行動作的API。其餘的一切(Siri、Spotlight、Shortcuts、Apple Intelligence 摘要,以及 Watch 與 Vision Pro 的介面)都是這個契約的下游延伸。Foundation Models 是 iOS 26 推出的裝置端LLM,它公開了另一個獨立的 Tool 協定供應用程式內部呼叫工具;它與 App Intents 平行運作,而不是透過 App Intents 運作。

TL;DR

• App Intents 以結構化的型別宣告您的應用程式可以執行哪些動作,讓 Apple 的 AI 能直接呼叫。它們是 Apple 為第三方應用程式提供的工具使用API。
• 一個真實的生產範例:Water 中的 LogWaterIntent。80 行程式碼,包含完整的 SwiftData 寫入、HealthKit 同步、區域感知的單位換算,以及結構化的 Siri 對話回應。
• iOS 26 加入了 Foundation Models,Apple 的裝置端LLM。Foundation Models 公開了自己的 Tool 協定供應用程式內部使用工具;App Intents 仍然是 Siri / Spotlight / Apple Intelligence 跨應用程式呼叫的標準介面。同樣的方向,兩個平行契約。
• 在 2026 年沒有 App Intents 的應用程式,對 Apple Intelligence 而言是隱形的。AI 結構網會透過您宣告的 intents 進行路由,否則就會繞過您的應用程式,轉向競爭對手。
• 三年來 Apple 一直在告訴我們這件事。命名(App Intents、App Shortcuts、Apple Intelligence)是刻意為之。這個契約在每一屆 WWDC 都會在堆疊上往上提升一層。

App Intents framework 參考圖,來源:Apple Developer 文件。⁵

App Intent 究竟是什麼

LogWaterIntent 在 2026 年 2 月 8 日 commit 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 就是綱要。Apple 的 AI 看到的是 amount: Int 並且預設值為 8。當 Siri 解析「log 12 oz of water」時,會產生 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 的 NL 解析器有更多空間去匹配使用者的措辭,而您不必維護一份語句字典。systemImageName 是真正的 SF Symbols 名稱;Spotlight、Shortcuts 與 Apple Intelligence 就是透過它來呈現該動作的圖示。

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

為何這是繼 SwiftUI 之後最重要的 iOS API

iOS API可以分為兩種型態。一種是關於應用程式如何繪製自己(UIKit、SwiftUI、Metal)。另一種是關於應用程式如何與系統整合(URL scheme、Universal Links、Widget)。App Intents 屬於第三種型態:它們是 Apple 的 AI 使用您應用程式的方式。

這個演進過程值得回溯。

• iOS 10(2016)推出了 SiriKit Intents(INIntent),這是第三方應用程式首次能透過語音被呼叫的時刻。介面範圍很窄:只有一份固定的領域清單(訊息、付款、叫車),且綱要嚴格。⁸
• iOS 12(2018)透過 Siri Shortcuts 擴大了介面範圍:任何應用程式都可以捐贈 NSUserActivity 或 INIntent,並期望 Siri 提供建議。
• iOS 13(2019)新增了應用程式內部的 intent 處理,讓應用程式能直接回應 shortcut 呼叫,而不必切換到背景由系統 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 26(2025)推出了 Foundation Models 框架,Apple 的裝置端LLM。Foundation Models 公開了一個獨立的 Tool 協定供應用程式內部呼叫工具。App Intents 仍然是 Apple Intelligence 的標準跨應用程式介面,而 Tool 則是直接呼叫LLM的應用程式內部介面。兩個契約平行運作。⁴

每一次發行,這個契約都在堆疊上向上延伸。最初 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 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 Intents 與 App Entities 來呼叫。在系統 AI 結構網中,並不存在第三方應用程式可用的 setSystemPrompt(...) API。存在的是 intent 註冊表。Foundation Models 為想要打造自己裝置端LLM功能的開發者新增了一個平行的應用程式內 Tool 介面。跨應用程式的契約(Apple Intelligence 與 Siri 用來找到您的應用程式的那個契約)是透過 App Intents 運作。

對應用程式開發者而言,有三個具體後果:

沒有相關 App Intent 的應用程式,在其類別中無法被 Siri 語音指令觸及。Apple Intelligence 會優先把「Hey Siri, log my water」這類語句路由到首先宣告對應 intent 的應用程式。我在 2026 年 2 月發行了 Water 的 intent。我對框架走向的判讀是:在 2027 年才發行 intent 的飲水應用程式,進入的是一個路由權重已經向早期推動者累積的市場。同樣的邏輯適用於購物清單、運動記錄、行事曆項目、相片搜尋。我預期 intent 宣告的先行者優勢將會持續複利,如同 Apple 其他平台押注API的歷史(HealthKit 類別、Spotlight 豐富結果、Live Activities token)所呈現的那樣。

Apple Intelligence 個人化功能不僅讀取 intents,也讀取 App Entities。AppEntity 宣告「這個應用程式擁有這種形狀的資料」。當使用者問「我加到閱讀清單的最後一本書是什麼」時,Apple Intelligence 會在每個已安裝的應用程式中,搜尋每個與 Book 匹配的 AppEntity。如果您的應用程式有閱讀清單,卻沒有宣告 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,而不是我的應用程式資料)。每個未發行的 intent,都是 Apple Intelligence 繞過我的一次查詢。

對話字串不是電子郵件的內文。我從一開始就有 ProvidesDialog,但我早期的對話寫成了散文。透過 CarPlay 或 AirPods 聽到的使用者,需要的是簡短、具體、以事實為主的結構:「8 oz logged. 32 oz to go.」Watch 介面尤其會大幅截斷文字。對話式的措辭比起以信心十足的事實傳達,使用者體驗反而更差。我在第四週重寫了我的對話。²

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 的 fetch 黏合程式碼。若要讓單一筆紀錄能在 Spotlight 中個別被搜尋(讓搜尋「water」的使用者落在正確的紀錄上),請讓 entity 符合 IndexedEntity 並在寫入時捐贈索引更新。這就是 Apple 的 Spotlight 管線在純粹 AppEntity 公開之外所期待的內容。

同樣的形態也適用於我的其他應用程式。我的購物清單應用程式 Get Bananas 已經有一個 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生態系、兩種不同的契約、同一份購物清單。這就是平行契約論作為一個已發行應用程式的具體呈現:SwiftData 模型是資料,App Intents 是 Apple 的契約,MCP 是 Anthropic 的契約,兩個介面都在同一個事實來源上運作。

何時不該發行 App Intent

拒絕也是設計的一部分。

如果您的應用程式純粹以消費為主(讀取使用者的相片、顯示新聞、播放音訊),沒有可變動的使用者狀態,App Intents 可能就沒有什麼可以公開的。Apple 的框架支援 OpenIntent(僅將應用程式開啟到某個情境),但如果唯一有用的動作就是「打開應用程式」,那 intent 就是多餘的負擔。不要為了發行而發行。

如果動作仰賴難以抽象化的 UI 互動(複雜的多步驟畫布工具、3D 編輯應用程式),那 intent 必要的 parameterSummary 將會退化為含糊、沒有人會真正說出口的偽自然語言。Siri 語句「以強度 7 的模糊工具編輯我的相片」技術上可行,但沒有人類會真的說出這句話。Intent 介面就成了一個沒有回報的稅。

正確的判斷準則:當存在一句使用者會自然說出、能觸發該動作的句子時,App Intent 才值得投入。「Log 8 oz of water」就是那句話。「對 layer 3 套用 sigma 2.4 的高斯模糊」則不是。如果您應用程式的動作集中在第二種模式,intents 就不是您的轉換槓桿。

結語

三年來 Apple 一直在訊號化 iOS 的系統 AI 結構網會透過 App Intents 運作。WWDC 2024 加入了透過 App Intents 路由的 Apple Intelligence。WWDC 2025 在旁邊新增了 Foundation Models 作為一個獨立的應用程式內工具呼叫介面,讓 App Intents 維持作為 Siri / Spotlight / Apple Intelligence 持續使用的跨應用程式契約。所有訊號都指向同一個方向:具型別、宣告式的 App Intent 就是第三方應用程式如今與系統簽訂的契約。

大多數 iOS 應用程式仍然把 App Intents 當作 Siri Shortcuts 在看待:有空再發行的功能。我的判讀是這個框架老化得會很糟糕。隨著 Apple Intelligence 的系統介面持續擴展(已經透過今日的 Siri、Spotlight、Shortcuts 與 Apple Intelligence 摘要),沒有宣告 intents 的應用程式很可能會發現自己被排除在路由圖之外。從我觀察 Apple 其他平台押注的經驗,先行者介面會持續複利。

Water 已經發行 LogWaterIntent 達十一週。發行一個 App Intent 所需的程式碼量,小到能放進單一檔案。不發行的代價,則隨著每一次 Apple Intelligence 的更新而增長。

如果您在 2026 年發行 iOS 應用程式,卻還沒有宣告至少一個 App Intent,您的路線圖就少了一項。把它加進去。

FAQ

iOS 開發中的 App Intent 是什麼?

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

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

App Intents(於 iOS 16, 2022 推出)取代了 INIntent,成為 Apple 主要的 intent 框架。較新的框架完全是 Swift 原生的,使用 @Parameter 之類的 property wrapper、透過 AppEntity 支援型別安全的 entity 查詢,並且是 Siri、Spotlight、Shortcuts 與 Apple Intelligence 所呼叫的介面。較舊的 INIntent 仍受支援,但不會獲得新功能。

我需要 iOS 26 才能發行 App Intent 嗎?

不需要。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 是您的應用程式所知的資料(名詞)。LogWaterIntent 是 intent。讓 WaterEntry 變成可查詢的型別則是 entity。Apple Intelligence 兩者都會用:用 intent 執行動作,用 entity 在回應中擷取與參照資料。

App Intents 與 Foundation Models 工具呼叫有何關係?

Foundation Models 公開了自己的 Tool 協定,用於直接的應用程式內LLM工具呼叫。App Intents 仍然是 Apple Intelligence、Siri 與 Spotlight 所呼叫的標準跨應用程式介面。同樣的方向(具型別、宣告式的工具使用);兩個平行契約。想要被系統 AI 介面觸及的應用程式,要發行 App Intents;想要用自訂工具呼叫自家裝置端LLM的應用程式,要發行 Tool 的符合實作。許多應用程式兩者都會發行。

App Intents 不是一項功能。它就是契約。第一個發行 intent 的應用程式拿下介面;之後才發行的應用程式,會發現介面已經被路由到別處去了。十一週前我在 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:授權流程、樣本類型與會把使用者鎖在您應用程式之外的陷阱所構成的資料來源層。

或直接跳到完整 hub:Apple 生態系列。若想瞭解更廣泛的 iOS 與 AI agent 整合背景,請參閱 iOS Agent Development 指南。

參考資料